Parrot 0.9.1 Released | parrot.org/ | < 1 week to Parrot 1.0!
Set by moderator on 10 March 2009.
00:09 AndyA joined 00:31 Eevee joined 00:48 rob joined
dalek rrot: r37465 | allison++ | trunk/DEPRECATED.pod:
[cage] Add deprecation notice for 'Parrot_add_library_path'.
 01:31
01:49 AndyA joined
dalek tracwiki: v135 | allison++ | ParrotRoadmap 01:51
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/bekdri
02:10 Woody4286 joined 02:32 Woody4286 joined 02:59 bacek joined 03:24 zpmorgan joined
zpmorgan when pasting PIR into parrot through the terminal, using "parrot -", it requires two ^D's to tell it to compile 03:28
dalek tracwiki: v9 | jkeenan++ | Parrot%20Virtual%20Machine%20Workshop%202009 03:39
tracwiki: Better hyperlink display
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/bekd9i
03:42 janus joined 04:04 Debolaz joined 04:05 skv joined 04:07 Theory joined
zpmorgan It's great that Warnock’s Dilemma is in parrot's glossary 04:07
I'm guessing it's not important
04:08 GeJ joined 04:13 skv joined, GeJ joined 04:18 slavorg joined 04:23 Tene joined 04:26 aagam joined, aagam left 04:40 Debolaz joined 05:36 Woody4286 joined 05:41 samlh joined
dalek rrot: r37466 | cotto++ | trunk (3 files):
[docs] remove some references to examples/io and remove a warning from make html
 05:42
06:03 tuxdna joined
dalek rrot: r37467 | cotto++ | trunk/DEPRECATED.pod:
[docs] add deprecation notice about Parrot_new_INTVAL_hash
 06:17
rrot: r37468 | allison++ | trunk/ports/ubuntu (3 files):
[ubuntu] Some things about Ubuntu packaging are just different. Storing
 07:07
07:10 uniejo joined
dalek rrot: r37469 | allison++ | trunk/ports/debian/control:
[debian] Storing the generated file causes more problems than it solves.
 07:11
rrot: r37470 | allison++ | trunk/ports/ubuntu/control.in:
[ubuntu] Wants a more recent version of Standards.
 07:15
07:28 Eevee joined
dalek rrot: r37471 | allison++ | trunk/ports/ubuntu/control.in:
[ubuntu] All Sections specify 'universe'.
 07:38
rrot: r37472 | allison++ | trunk/ports/debian/changelog:
[debian] Temporary date on changelog.
 08:02
rrot: r37473 | allison++ | trunk/ports/debian/parrot-doc.docs:
[debian] Generated doclist from testing tarball.
 08:06
08:14 masak joined
dalek rrot: r37474 | chromatic++ | trunk/src/jit/i386/jit_defs.c:
[JIT] Removed special case code for set_i_p_ki and set_p_ki_i opcodes which

into aren't the real guts of FIA PMCs anymore, now that they use real PMC attributes. This fixes three JIT failures on x86 for me; now all tests pass.		 08:21
cotto chromatic++ for finding that 08:28
08:40 clunker3 joined
dalek rrot: r37475 | fperrad++ | trunk (5 files):
[external languages] restore empty directory languages & makefiles/languages.in.

The parrot infrastructure should be welcoming to external languages. The file languages.in lists all known languages. If the name 'languages' is a problem, it could be renamed.		 09:20
a: 7251868 | (Francois Perrad)++ | config/makefiles/root.in:
fix Makefile when no crypto
 11:23
shorten dalek's url is at xrl.us/bekfdo
11:33 ujwalic joined 12:05 korshak joined
dalek rrot: r37476 | rurban++ | trunk/ports/cygwin/parrot-1.0-1.cygport:
[ports] mv 0.8.2 => 1.0
 12:06
12:06 korshak left
dalek rrot: r37477 | rurban++ | trunk/ports/cygwin/parrot-1.0-1.cygwin.patch:
[ports] mv 0.8.2 => 1.0
 12:10
rrot: r37478 | rurban++ | trunk/ports/cygwin/parrot-1.0-1.src.patch:
[ports] mv 0.8.2 => 1.0
 12:14
12:20 DietCoke joined
dalek rrot: r37479 | rurban++ | trunk/ports/cygwin/libparrot1.hint:
[ports] 0.8.2 => 1.0
 12:26
rrot: r37480 | rurban++ | trunk/ports/cygwin (7 files):
[ports] update cygwin release to 1.0 (not yet finished)
 12:31
rrot: r37481 | rurban++ | trunk/ports/cygwin/parrot-1.0-1.src.patch:
[ports] src patch not needed for 1.0, just 0.9.1
 12:35
12:36 donaldh joined
dalek a: 58a5a8e | (Francois Perrad)++ | src/pmc/luauserdata.pmc:
disable finalizer for LuaUserData PMC
 12:54
shorten dalek's url is at xrl.us/bekfn3
13:06 gryphon joined 13:21 korshak joined 13:40 skv_ joined 13:58 korshak left 14:08 Andy joined 14:21 skv joined 14:28 skv_ joined 14:35 rdice joined 14:38 skv_ joined
dalek rrot: r37482 | pmichaud++ | trunk/DEPRECATED.pod:
Some PCT-related deprecations for 1.0.
 14:52
14:53 Tene joined
moritz so, tomorrow is the big release day? 14:59
Infinoid guess so 15:00
15:06 PacoLinux joined 15:20 donaldh joined
dalek rrot: r37483 | coke++ | trunk/DEPRECATED.pod:
[docs] Try to standardize formatting/notifications.
 15:26
15:28 particle joined 15:43 Patterner joined 15:46 AndyA joined
dalek rrot: r37484 | pmichaud++ | trunk/docs/pdds/pdd20_lexical_vars.pod:
Update pdd20 -- resolves TT #243
 15:57
16:10 Theory joined
dalek tracwiki: v136 | pmichaud++ | ParrotRoadmap 16:10
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/bekgaj
dalek rrot: r37485 | pmichaud++ | trunk/docs/pdds/pdd26_ast.pod:
[pct]: Add documentation of subid attribute for PAST::Block to pdd26.
 16:15
a: 5087a18 | (Francois Perrad)++ | src/lib/luapackage.pir:
use .STAT_EXISTS
 16:16
shorten dalek's url is at xrl.us/bekgbx
dalek a: d71495b | (Francois Perrad)++ | (2 files):
search pbc using load_bytecode instead of stat
shorten dalek's url is at xrl.us/bekgbz 16:17
dalek a: 396ba52 | (Francois Perrad)++ | (3 files):
Hack for Parrot 1.0, in order to load external library.

so libraries are put in library/lua/*.pbc
shorten dalek's url is at xrl.us/bekgb7
dalek tracwiki: v137 | pmichaud++ | ParrotRoadmap 16:19
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/bekgch
16:25 mikehh joined
mikehh I am getting a codetest failure - t/codingstd/pod_syntax.t - examples/pir/io.pir - I think it is the final =cut in that file 16:31
it passes if I remove it - from r37466
all other tests pass - Kubuntu Intrepid i386 16:32
moritz podchecker says it's OK 16:36
mikehh yeah I know - try prove --verbose t/codingstd/pod_syntax.t 16:37
As I mentioned I think it is the final unmatched =cut 16:39
which podchecker seems to ignire
moritz mikehh: you're right 16:40
dalek rrot: r37486 | moritz++ | trunk/DEPRECATED.pod:
fix some POD in DEPRECATED.pod (podchecker complained)
moritz perldoc $file complains about it as well
moderator Parrot 0.9.1 Released | parrot.org/ | 1 day to Parrot 1.0! 16:44
dalek rrot: r37487 | moritz++ | trunk/examples/pir/io.pir:
[cage] POD fix by mikehh++ in io.pir
 16:44
16:55 gryphon joined 17:36 cognominal joined 17:37 bacek joined 17:51 Theory_ joined 18:06 Limbic_Region joined
dalek rrot: r37488 | allison++ | trunk (5 files):
[cage] Reverting fperrad's r37475, as barney's addition of

should be building from an installed Parrot instead of working in a languages/ directory within a parrot build tree, or building parrot within their working directory. But, fetch_languages.pl is a reasonable step in the mean time.		 18:16
Coke_afk allison: ping 18:35
mikehh codetest fails - t/codingstd/pdd_format.t - pdd20_lexical_vars.pod has 1 lines > 78 chars: 35 - from r37484 18:38
allison Coke: pong 18:39
18:39 rurban joined
Coke allison: regarding deprecation notes: if there are any remaining marked "BEFORE 1.0", they should be switched to "eligible in 1.1" just before the release. 18:39
(since that will mark their first ``official'' appearance. 18:40
allison Coke: okay, I'll add a step to the release manager guide
Coke allison: it's a one time thing.
only coming up because we're doing our first prod release.
allison we won't be using "BEFORE 1.4"?
Coke "eligible in 1.1" 18:41
(some of them are already "eligible in 1.5"
allison And then "eligible in 1.5", okay, no additional step
Coke right.
allison Coke: why are some of them "eligible in 1.5" now?
Coke: since, the notice will be in 1.0 18:42
Coke because pmichaud put them in for "in july 2009"
so I made it consistent.
Don't know why he wanted to skip a release
s/skip/include/
allison mmmm... maybe he meant the changes would appear in the July 2009 release?
that is, would be made between 1.0 and 1.4?
Coke doubt it, because he used eligible in 1.1 elsewhere. 18:43
pmichaud: ping.
mikehh test passes if I change "no LexInfo, no LexPad" at the end of the line to "no LexInfo/no LexPad" 18:44
allison Coke: if we don't hear from him, I'll change to "eligible in 1.1", just in case (because they are eligible then, even if he doesn't make the changes until 1.5) 18:45
Coke mikehh: or we just remove the extra leading spaces. fixed.
allison: works for me. 18:46
I am somewhat freaked out that we have a 353 line list of things we're deleting. =-)
allison Coke: :) 18:47
Coke: well, it's better than deleting them all now, and shipping with something that hasn't been well tested
rurban with VERSION 1.0 I get "Too few components to VERSION file contents: '1.0' (should be 3 or 4)! at lib/Parrot/BuildUtil.pm line 62"
Coke allison: some of those I think you already bumped until after 1.0 in the tickets; probably easiest just to update them en masse at this point; I doubt we're closing any more before tomorrow.
rurban: see mailing list.
allison rurban: VERSION is 1.0.0, not 1.0
Coke (version is really 1.0.0)
thanks for checking the release process. =-) 18:48
18:48 barney joined
allison Coke: the one I'm not sure about is the ATTR conversion, as cotto was making rapid progress on that 18:48
rurban Will the tarball also be parrot-1.0.0.tar.gz ? 18:49
allison rurban: yes
Coke: will go ahead and update all the others
Coke allison: danke.
Coke tries to figure out if he can afford yapc this year. 18:51
s/tries to/should/; as I'm actually working on work atm.
18:52 AndyA joined, ujwalic joined
ujwalic japhb: ping 18:53
dalek rrot: r37489 | coke++ | trunk/docs/pdds/pdd20_lexical_vars.pod:
Fix coding standard test failure, reported by mikehh++
18:53 korshak joined
Coke allison: I will try to respond to your language checklist for partcl, but I know trunk is broken wrt parrot right now; haven't even had a chance to examine your patches. 18:53
but at this point, you shouldn't wait for me to play catchup.
allison Coke: the only question that's important is "any blockers" 18:54
Coke allison: I have no clue, I haven't touched partcl in over a month. =-)
allison Coke: that is, is there anything from Tcl that should stop us from shipping 1.0
Coke: so, that means "no blockers"
ujwalic Coke: build prob. 18:55
allison Coke: I mean, Tcl isn't tracking trunk anyway, right?
Coke yes.
allison: it was working on trunk for a while.
I know it doesn't now.
ujwalic: with partcl? yah.
but I can adjust partcl to fix that, probably, doesn't need parrot to worry about it.
allison: I'll just reply to that email.
allison Coke: cool 18:56
dalek rrot: r37490 | rurban++ | trunk/ports/cygwin/parrot-1.0.0-1.cygwin:
[ports] mv 1.0 1.0.0
 18:58
allison Coke: oh, and I compiled Tcl on trunk a few weeks ago when I was testing building from an installed Parrot, just needed a small patch 19:00
Coke allison: Saw the patches you sent; I'll probably apply those before I try to fix anything myself.
will also be stealing rakudo's "build parrot for me" trick.
should simplify things.
hopefully i can get the folks that were interested in APL commit bits and hacking on things, too. 19:01
allison Coke: that'd be cool
dalek rrot: r37491 | rurban++ | trunk/ports/cygwin/parrot-1.0.0-1.cygport:
[ports] mv 1.0 1.0.0
 19:03
japhb ujwalic: pong
ujwalic :)
in glutcbDisplayFunc(PARROT_INTERP, PMC *sub) how are we passing first argument 19:04
in *.pir we are only calling it with a sub ... glutDisplayFunc (draw)
japhb ujwalic: It's implicit, because of the signature. 19:05
Tene pmichaud: AST user docs are listed as "on track". What have you done for that so far?
japhb looking for spec ref
ujwalic: all the signatures used are listed in runtime/parrot/library/OpenGL_funcs.pir 19:06
ujwalic ok
japhb ujwalic: src/call_list.txt has comments at the top that describe all the type meanings 19:07
'J' is under 'special stuff', and is an implicit pass of Parrot_Interp.
dalek tracwiki: v14 | allison++ | ChrootSetup
japhb ujwalic: make sense?
dalek tracwiki: trac.parrot.org/parrot/wiki/Chroot...ction=diff
shorten dalek's url is at xrl.us/bekg6e
dalek rrot: r37492 | rurban++ | trunk/ports/cygwin/parrot-1.0.0-1.cygwin.patch:
[ports] fix wrong rename from r37490
ujwalic japhb: yes 19:08
japhb excellent. :-)
ujwalic which POD mentions about it ? 19:09
"NCI conventions and definitions" does not mention it 19:10
japhb ujwalic: I think honestly the POD is (heavily) out of date WRT reality on this one.
ujwalic and "Example Callback" is not complete
ok
japhb There was some talk a few months ago about improving it, but I think it went nowhere. 19:11
ujwalic i'll go through the 'C' of code then ;)
rurban step gen::makefiles died during execution: Can't open languages/Makefile.tmp languages.in missing? 19:12
japhb Especially given the aborted discussion re: a more complete signature space (so that more different C calling conventions could be exposed to NCI -- right now, Parrot NCI only handles a small subset of that space)
dalek tracwiki: v15 | allison++ | ChrootSetup
tracwiki: trac.parrot.org/parrot/wiki/Chroot...ction=diff
shorten dalek's url is at xrl.us/bekg65
japhb ujwalic: feel free to enter a Trac ticket with patch. ;-)
ujwalic japhb: i'll try ... thanks 19:13
japhb np
19:15 Theory joined
rurban I need some dummy file in languages for the tarball to contain this dir 19:15
sjn pmichaud: ping 19:18
19:20 donaldh joined
allison rurban: none of the languages exist in the parrot repository anymore 19:21
rurban I know, but the tar will miss the dir languages then. I just fell over this. A tar misfeature 19:22
allison rurban: there is no dir languages/ anymore (perhaps I'm missing what you're getting at?)
sjn pmichaud: have you written the Rakudo #15 press release yet? could you send me a preview? 19:23
rurban ah, I see. svn up fixes it
ujwalic rurban: trac.parrot.org/parrot/changeset/37488 19:24
rurban parrot.spec also needs several updates. perl6 and languages needs to be removed 19:26
nopaste "rurban" at 93.82.93.200 pasted "parrot.spec 1.0.0" (73 lines) at nopaste.snit.ch/15889 19:28
ujwalic japhb: is libray/OpenGL_funcs.pir == library/OpenGL.pbc ? 19:32
japhb: got it :) 19:36
dalek tracwiki: v16 | allison++ | ChrootSetup
tracwiki: trac.parrot.org/parrot/wiki/Chroot...ction=diff
tracwiki: v17 | allison++ | ChrootSetup
tracwiki: trac.parrot.org/parrot/wiki/Chroot...ction=diff
shorten dalek's url is at xrl.us/bekhbu
dalek's url is at xrl.us/bekhbw
19:38 rg joined
Tene allison: is docs/user/pir/exceptions.pod approximately what was wanted for pdd23 user docs? I just committed another section. 19:40
Coke tene: you broke 'codetest' 19:41
dalek rrot: r37493 | tene++ | trunk/docs/user/pir/exceptions.pod:
Add more exceptions docs.
Coke # /Users/coke/research/parrot/docs/user/pir/exceptions.pod:52: 274 cols
Tene Coke: what's codetest?
oh, I need linebreaks in the pod. 19:42
Coke 'make codetest' 19:44
danke.
allison Tene: looking... 19:46
dalek rrot: r37494 | tene++ | trunk/docs/user/pir/exceptions.pod:
Add line breaks for codetest. Coke++
allison Tene: looks great! 19:48
Tene Coke: better? 19:52
19:52 korshak left
rg tene: looks good. If you could put in two more things: 1. a note that exception handlers are run in the context of the throw statement (you'll remember it took me a long time to grasp that ;)) 19:52
2. that it's very easy to produce an infinite loop by throwing (or even just causing) an exception from with an exception handler and that you really want to be using the filters you described. 19:54
Coke (too easy. :|) 19:55
dalek rrot: r37495 | rurban++ | trunk/ports/cygwin (3 files):
[ports] added README (again), rm cygwin.patch, updated deps and cygport
 19:56
rurban Should I remove ports/cygwin/README? It's rather large because it contains the whole package list and history
dalek pp: 6f29413 | (Bernhard Schmalhofer)++ | (4 files):
Put *.pbc files into library/pipp_library
 19:57
shorten dalek's url is at xrl.us/bekher
Tene rg: thank you 19:59
dalek pp: 3b93228 | (Bernhard Schmalhofer)++ | .gitignore:
Let git ignore pipp.pbc
 20:02
shorten dalek's url is at xrl.us/bekhfo
rurban what about src/thread.c:503 ? 'interp' is used uninitialized in this function 20:08
dalek rrot: r37496 | allison++ | trunk/DEPRECATED.pod:
[cage] Update deprecation items listed as "BEFORE 1.0" to "eligible in 1.1".
 20:17
rrot: r37497 | coke++ | trunk/t/examples/library.t:
Skip PCRE test that can cause failures, with ticket.
 20:21
rrot: r37498 | allison++ | trunk/lib/Parrot/Docs/HTMLPage.pm:
[docs] Linking the Parrot logo in the html generated docs to www.parrot.org.
 20:26
rg rurban: i'm surprised that even compiles 20:28
seen cotto 20:29
purl cotto was last seen on #parrot 12 hours, 43 seconds ago, saying: chromatic++ for finding that
rurban I'm surpised that this passes the tests at all. with optimize interp would be random, with debugging just NULL.
dalek rrot: r37499 | allison++ | trunk/lib/Parrot/Docs/Section/Parrot.pm:
[docs] Don't include the Examples link in the generated html TOC, because it
 20:30
rg it looks like most of the code just ignores interp in that function. it'll probably only be used in case of some failure
and by function i mean VTABLE_get_pointer. the default just returns the second argument. 20:32
cotto rg, did you want something?
allison rurban: the ports directory never gets included in the tarball, so size isn't as much of a concern as usual, but if ports/cygwin/README isn't needed, it can be removed
20:32 bsdz joined
rg cotto: can you look at what rurban found: rurban: what about src/thread.c:503 ? 'interp' is used uninitialized in this function 20:33
rurban ok, so I leave it there. It might be useful to any fellow packager
cotto sure
rg it got introduced in r37195 20:34
rurban I get lots of failures when building in lndir'ed dirs now. worked before on cygwin-1.5. I think it's a cygwin-1.7 bug (still beta)
bsdz hi, anyone around who can give me any pointers to overriding valflags in PAST/Compiler.pir to assign Complex numbers like strings. Basically I need to set valflags['Complex'] = 's~*:e'
should I file a trac or is there some user stuff I can do in my grammar or actions? 20:35
cotto should I be looking at the current trunk or r37195
bsdz yes
cotto I'd guess the latter
rurban cotto: It's in trunk also
rg cotto: doesn't matter. r37195 introduced the line in question and it hasn't changed since.
bsdz sorry crossed wires there 20:36
rurban It looks very broken but no tests fail. maybe we have no coverage there
rg rurban: like i said. the default just returns the second argument, so it might be hard to trigger. 20:37
cotto It looks like thread_func has some test coverage (112 calls as of r30881, which is the most recent make cover results I have) 20:38
rurban r30881 < r37195 20:39
cotto wow. that is broken 20:40
(gdb) p interp
$1 = (Parrot_Interp) 0x25
rurban API change needed?
cotto nm. it's sane in thread_func 20:41
I see what you're getting at. 20:42
cotto feels silly for missing the obvious
rurban At least we have found it one day before, not after 20:44
cotto yes 20:45
rurban++ for catching that
Coke I'm intentionally skipping twip this week, btw.
allison bsdz: not quite sure what you're getting at, but sounds like a mailing list question might be in order 20:48
Tene rg: perhaps in a "Warnings" section at the end? 20:49
bsdz allison: i perhaps jumped the gun and already filed a trac. problem is when capturing strings holding complex numbers like "5i" or "10.5j". PCT does not quote them when passing to a Complex PMC. 20:50
rurban cotto: I even added it to ticket yesterday: TT #446
allison bsdz: a trac ticket is also good 20:52
bsdz allison: cool
rg tene: for point 2. sure. for point 1. you could just add a sentence to the first paragraph
Tene I also need a section on 'resume'. 20:54
allison: what docs should I work on next?
allison Tene: docs to write or docs to review? 20:55
Tene allison: Um, either, I guess. Which should I be doing?
allison Tene: from the roadmap, "user documentation, objects, pmc, dynops" 20:57
dalek rrot: r37500 | tene++ | trunk/docs/user/pir/exceptions.pod:
[exceptions.pod]: Add a note about EHs running in the context of the corresponding throw.
 20:58
20:59 contingencyplan joined
allison Tene: looks like objects and pmcs are kind of covered from the other files in docs/user/pir... 21:00
cotto rurban, I have a fix that doesn't need an api change. It's not terribly pretty, but it seems to work. 21:01
rurban as long as it works
purl well, as long as it works is all I need.. trying it now.
21:01 simonp joined
Tene allison: is there a plan for making exception types useful to user code (outside of control exceptions)? Or do you expect that role to be taken care of by a hierarchy of exception classes eventually? 21:02
nopaste "cotto" at 96.26.202.243 pasted "fix for uninitialized interp bug" (14 lines) at nopaste.snit.ch/15890
cotto allison, is that patch ok to apply if make fulltest passes? 21:03
(or make test. I'm not sure if fulltest is passing anyway) 21:04
allison Tene: yes on useful to user code. are they not currently? or, more importantly how are they not currently? and let's fix it.
Tene allison: less runtime/parrot/include/except_types.pasm
allison cotto: looks good
purl O_O
simonp i was curious if the project had any abuse problem with the buildbot irc interface, i.e. anyone can force a build.
Tene Those don't look useful in general for user code. 21:05
allison cotto: (and fulltest is passing on all the platforms I have access to)
cotto ok. I'll go with fulltest.
allison Tene: ah, yes, the low-level integer types aren't generally useful for high-level languages (are mostly intended for internal use) 21:06
Tene allison: Right.
allison Tene: message and payload are the ways to store custom information in exceptions 21:08
purl Message for and stored.
dalek rrot: r37501 | allison++ | trunk (1 files):
[doc] Renaming some introductory files.
allison Tene: which can include any information the HLL wants to include for deciding if it wants to handle a particular exception
Tene allison: so exception types aren't meant to be useful to user code. Okay. 21:09
allison Tene: subclassing is possible (I suspect Perl 6 will have a whole hierarchy of exception subclasses), but not necessary
Tene: they could be, but we'd have to change from a C enum to a user-extensible list of types, so not possible currently 21:10
Tene: and, I'm not sure if languages want to interact with exceptions by type number
Tene allison: Would it be useful to extend EH.pmc to be able to filter by the class of the exception? 21:11
just like it does by type and severity?
allison Tene: if any language needs it, sure 21:12
Tene Okay. I'll keep that in mind.
allison Tene: would rather go by class lookup than class type number though
Tene: that is, accept the usual STRING, Key, Array, Namespace lookup arguments
Tene save those and look up every time, or look them up when setting the filter and save the class? 21:13
allison Tene: better to lookup once 21:14
Tene nods.
allison Tene: but will have to check "isa" everytime, so the parents are checked too
Tene: (unless we want to take the more restrictive option and only test the class of the current exception) 21:16
Tene no, "isa" is correct.
purl okay, Tene.
Tene It would be really interesting to see a comparison of the exception hierarchies of several languages we want to support to see if there are any common intersections. 21:18
I would really love for a "catch IOException" in whatever language to catch all IO exceptions from any language. 21:19
allison: So, is trac.parrot.org/parrot/ticket/242 mostly done? 21:21
allison Tene: yes! slap it with a "done" status 21:24
Coke allison: one problem with convert partcl to work against an installed parrot - I can't install parrot on my primary development platform. =-)
allison Coke: you can install it in a local directory, which is no different than a build directory 21:25
Coke: or, you mean it simply won't install at all?
Coke You cannot run an installed parrot on osx. 21:26
allison Coke: the rpath problem
Coke ayup.
allison Coke: well, you can, you just can't delete the build directory :)
Coke: debian and ubuntu actually complain about rpath too 21:27
Coke: differently, but they complain
rg iirc wasn't that that osx won't link against non-existing shared libs? 21:28
Coke rg: with the current build process, yes.
it's fixable.
last time I tried, though, I failed. =-)
just going to be painful to update partcl. :| 21:29
allison rg: trac.parrot.org/parrot/ticket/344
Tene allison: is docs/user/pir/exceptions.pod the right location for that document? I remember that was being discussed earlier?
allison Coke: you can skip that for now, IIRC I sent the "get Partcl to compilel" patch separately from the building from install 21:30
Tene: yes
Tene: I've renamed the other files in that directory to make more sense
Coke/rg: essentially, we need to stop hardcoding blib/lib into our build flags 21:31
Coke allison: partcl still won't compile with that with recent updates to parrot. Pretty sure I rely on a config step that's missing. 21:32
Coke will try it out, but laptop is dying.
allison Coke: okay, I did get it to compile and build with both patches, but didn't try with just one patch
Coke meh. not like anyone uses the damn thing anyway. Kinder, perhaps, to just let it die. =-) 21:33
I'll check more later.
allison Coke: nah, it's a quick fix, really 21:34
rg allison: i thought it was introduced to keep users from having to explicitly configure their runtime linker (like with LD_LIBRARY_PATH)
allison rg: but in this case, we're linking to blib/lib even after we've installed parrot, which is bad 21:35
rurban The problem is libparrot_ldflags whcih is not replaced for the frozen install config
allison rurban: partly, yes 21:36
rg i don't think i follow, but i don't care either way. i believe at the time it was introduced i argued to make it the packager's problem ;P
dalek rrot: r37502 | cotto++ | trunk/src/thread.c:
[thread] don't use an uninitialized interp
 21:50
Tene btw, my Parrot presentation from last week is online: www.opensourcetv.tv/
cotto only 80 minutes? 21:52
Tene It's just scheme. 21:54
It's a bit... not good. I deleted everything and had to start over the night before. :) 21:55
It was fun, though.
Coke Now I know what Tene looks like.
<locking on target>
21:55 simonp left
Tene Aw, I'm all flustered at the start and stuttering. :) 21:56
cotto xrandr++ 21:57
Tene allison: state of the 'load_lang' opcode or whatever it was called? 21:58
allison Tene: after 1.0 22:00
Tene: but, pretty much done
Tene allison: how long after 1.0? I'm giving a presentation on Wednesday. :) 22:01
allison 'load_language' and 'load_hll_bytecode'
Tene: I wouldn't rely on it for Wednesday :)
Tene :) Okay.
allison Tene: or, tell them how you want it to work, and tell me what you told them ;) 22:02
Tene I'll see if I can just locally hack up rakudo's eval.
For some special cases.
allison Tene: oh, what did you want to use it for? 22:03
Tene i wanted to demo running multiple languages in the same interpreter.
allison Tene: I'm thinking of the "load the libraries for language X and add it's directories to the search paths"
Tene iirc, rakudo's eval still tries to load 'languages/$lang.pbc'
allison Tene: okay, yeah, same 22:04
Tene: (just checking)
Tene Apparently rakudo's eval doesn't respect a :lang parameter at all right now. Huh. 22:05
Coke allison: trying your patch, should I expect to be able to build against an /uninstalled/ parrot in another directory? 22:06
hurm. looks like not.
allison Coke: no, I didn't import Patrick's "build from parrot build dir" changes 22:09
Coke: just the installed build
Coke: I could add a Rakudo-style "download parrot, install it into a working directory, and build from it" option 22:10
Coke: I'll be adding it to Pynie later this week anyway
jonathan Tene: I changed eval to care about lexicals recently but did not intentionally break the :lang parameter...
Tene: OTOH I fear it's probably untested so I'd not have known if I had. :-| 22:11
Tene jonathan: I guess maybe I never implemented or something. There's no sign there that anything ever cared about :lang.
jonathan Tene: Really?
I'm *sure* I saw it...
Tene So was I. 22:12
oh, control.pir
not eval.pir
nm
yes, it just literally loads languages/$foo/$foo.pbc 22:13
Coke allison: I wonder if parrot_config should JFW out of a build dir. 22:15
(and have an install_parrot_config that gets installed as parrot_config)
allison Coke: you mean, the build version of parrot_config should set build paths for lib, bin, etc? 22:16
Coke: instead of making people choose between "build_dir" and "bin_dir" 22:17
Coke: yes, there's something to be said for that
rurban we have prefix for that magic 22:18
allison rurban: it's not about prefix, because in the build_dir they have completely different relative paths 22:19
rurban I added a installed key to decide upon that also
allison rurban: aye, but even then the paths are completely different. If the build parrot_config set build paths, then installed wouldn't even be necessary
(installed flag, that is) 22:20
rurban yes, that would be easy to fix
allison rurban: and, there's no reason for the installed_parrot_config to even keep a "build_dir" variable
rurban yes
I just built my first cygwin cygport 1.0.0 and I'm testing that now with the languages 22:21
22:21 ilia joined 22:27 Woody4286 joined
cotto Parrot has corrupted me. I can't type "pm" without accidentally typing "pmc". 22:37
moritz lol 22:38
dalek rrot: r37503 | rurban++ | trunk/ports/cygwin (4 files):
[ports] 1.0.0 rc
 22:39
moritz I'm running a fulltest on amd64 linux right now, with --optimize 22:40
22:40 donaldh_ joined
moritz (been doing that for 30 min) 22:40
so far looks clean
rurban solaris amd64 passed fulltest
cotto Python is weird. It's like all the functions aren't wearing pants. 22:41
donaldh_ cotto: how so?
rg rurban: wow, how did you manage that?
rurban rg: I'm back home :) 22:42
cotto There's no closing brackets.
rurban just openbsd behaves weird, andy dougherty found the same weirdnesses
rg for me solaris either fails the configure tests (if not using gcc) or the math tests (with gcc) 22:43
donaldh_ gotcha!
rurban rg: I used sunpro cc
rg: but your solaris is ppc, right?
rg sparc, yes.
rurban but it used to work before AFAIR 22:44
rg hmm i might get it to work with gcc in path 22:45
rurban the math tests need libmieee
rg yes, there's no way to get parrot working on solaris with gcc. 22:46
(if working means passing all tests)
rurban I'll run a solaris amd64 gcc smoke next, after openbsd 22:47
donaldh_ What are the performance expectations for 1.0 ?
Tene There aren't any.
donaldh_ Is just working enough? 22:48
22:48 Whiteknight joined
rurban well, faster than perl5 for sure 22:49
rg rurban: somebody implement perl5 for parrot, then we'll talk ;P
moritz the last comparisons I've seen (mostly IO, malloc and free) weren't very convincing, compared to perl 5 22:50
rurban you could compare pipp to php, or ruby to our
donaldh_ moritz: quite. my comparisons are rather depressing.
GeJ Good morning everyone 22:51
moritz well, at least parrot has some perspective (WRT optimization)
rurban donaldh: numbers?
Tene cardinal on unoptimized parrot several months ago was about 10% of cruby's speed
rg there is the calling conventions refactor branch, which is supposed to bring some improvement
Tene about a year ago
donaldh_ Something that takes ~2s in PHP on my puny Buffalo linkstation takes 1m30s in PIR and 15min written in Rakudo.
dalek kudo: 84920ea | (Moritz Lenz)++ | docs/ChangeLog:
[docs] update ChangeLog a bit
 22:52
shorten dalek's url is at xrl.us/bekh5v
rurban that's really depressing. But there's lot of optimization potential around 22:53
donaldh_ Running callgrind, it all appears to be GC and IO
Looking at the code for puts, using it frequently will put a lot of pressure on GC. 22:54
Tene Supposedly the generational GC is very close to being mergeable.
Is what I've heard.
donaldh_ Commenting out prints inside a loop removes 1/3 of execution time. 22:56
Coke tene: hah. 23:00
Tene Coke: :)
donaldh_ I'll happily spend a bit of time seeing if I can identify some optimizations.
Coke (speed) partcl was .. hundreds? thousands? of times slower than tcl. 23:01
hundreds, I think.
might have gotten down under 100 at some point.
Tene specifically, cardinal was aroun 10x slower after parsing. 23:02
with precompiled.
moritz has high hopes for the PGE LTM refactor and parsing speed
Coke I have no desire to get partcl working. Sad.
donaldh_ My test case parsing time is really not a huge concern, but I'll never serve web pages if it takes 15 min to generate a graph. 23:03
moritz DEPRECATED.pod 23:04
sorry
allison donaldh_: optimization is on the roadmap for 3.0, but we'll start on it between 1.0 and 2.0 too, so all identification work is helpful
moritz donaldh_: that's why the november wiki precompiles (nearly?) everything to PIR 23:05
donaldh_ moritz: correct me if I'm wrong, but Rakudo compiles once to bytecode, right? 23:06
moritz donaldh_: no
dalek rrot: r37504 | moritz++ | trunk/DEPRECATED.pod:
[cage] break overlong lines, make codetest happy
 23:07
rrot: r37505 | allison++ | trunk/DEPRECATED.pod:
[cage] Add info about Keys to class lookup notice.
 23:11
23:12 chromatic joined
chromatic Have I mentioned that calling conventions are a mess, varargs are undebuggable, and that problem in the shootout where a STRING's contents somehow suddenly turn invalid isn't going to get fixed? 23:12
jonathan chromatic: The design is a mess or the implementation? 23:16
If the second, yes, agree.
Also I want :capture...
chromatic I can't answer the question about the design, because I can't understand the design.
jonathan And a pony.
chromatic I just want to stop casting to and from C varargs, which are impenetrable to the debugger and require us to count and count and count some more, in addition to parsing argument streams for FIXED AND KNOWN ARITY C FUNCTIONS. 23:17
s/streams/strings/
jonathan I hear you.
allison chromatic: yes, varargs are going
chromatic I *think* the problem is that somehow we corrupt the C stack somewhere, but danged if I can figure out how.
Arguments get processed to and from a mixture of PBC, C data structures, C code, and Perl 5 (not kidding here) code. 23:18
jonathan allison: Do you think we stand any chance of getting back the performance we lost when unifying the MMD systems?
chromatic: Oh, the joy of the C debugger jumping into Perl 5! 23:19
I've seen that plenty of times. :-|
allison jonathan: oh, yes, definitely
chromatic I'd love to see a plan for getting back that speed.
allison jonathan: I'll even bring back MMD function pointers, if I have to, but we'll get it back
23:20 donaldh joined
chromatic Ugh, more C boundaries to cross. 23:21
allison chromatic: no, fewer (the idea being to not cross the boundary back-and-forth several times)
chromatic I'd love to see how you invoke a C function pointer without using C calling conventions.
donaldh_ It seems that performance improvement is not about optimization when it's orders of magnitude away from what it needs to be.
allison see, the thing about the MMD refactor is that it didn't actually change the underlying MMD implementation at all, it only exposed it by removing a layer of C function pointers that were hiding it in 90% of the use cases 23:22
moritz donaldh_: why not? if things are optimized that happen *very* often?
chromatic Because you can't optimize away major design problems.
donaldh_ moritz: maybe it's just semantics but that kind of refactor isn't an optimization in my book. 23:23
allison chromatic: bringing back the C function pointers is the last-resort, that is I know we can always get the speed back by going back to the old hack (or something similar)
chromatic: but the better solution is to fix the underlying MMD implementation, which didn't change in the last refactor
jonathan allison: The layer of C function pointers you used *were* an MMD implementaiton. I'm not arguing that it was a good one in all ways and that aiming for one unified one was a bad thing.
s/you used/you removed/
chromatic Removing all of the string manipulation for *each* MMD invocation would help.
jonathan But in reality we had one fast but limited MMD system and one slower but more flexible one and removed the first. 23:24
allison jonathan: technically speaking, yes we had two MMD systems (that were interacting in strange ways, which is why we removed one)
jonathan allison: I'm not disagreeing with the motives or the aim. 23:25
Just pointing out that the layer of C function pointers were actually doing something. ;-)
allison jonathan: yup
chromatic I'm blocked on fixing all sorts of difficult bugs because the current calling conventions implementation is completely inscrutable. 23:26
allison chromatic: agreed
donaldh_ allison: are we talking about PCCINVOKE here?
allison chromatic: it's also tightly embedded, so our attempts to gently push it aside are unsuccessful. Leading me to think the only solution is a wholesale replacement. 23:27
chromatic Three failed branches are a good indication the current approaches aren't workable. 23:28
allison donaldh_: yes but more, the collection of functions that handle dispatch from various different locations
chromatic: the thing is, we really only need a handful of ways of invoking, and instead we've got 20 or more 23:29
chromatic We also need less code and more readable code.
allison chromatic: yup
chromatic Look at the 60-line prelude crammed into a METHOD in a PMC and try to understand it.
allison it's just unnecessary 23:30
but, it really isn't that complex of a refactor, much less so than IO
chromatic There are some 1180 METHODs on PMCs. 23:31
Each of them has around 100 lines of boilerplate.
Sorry, 1120. 23:32
allison chromatic: is my blanket deprecation notice on "any functions not named with Parrot_<system>..." enough, or should I include an explicit deprecation notice for calling conventions
chromatic: because the C API is completely changing
(though the PIR API is staying the same) 23:33
chromatic That should only apply to functions used outside of their subsystems, right?
allison chromatic: since we eliminate PARROT_API, the distinction is less clear
23:34 tetragon joined
allison chromatic: but there are some public API functions for, say, invoking subroutine PMCs that have to change 23:34
chromatic We're eliminating PARROT_API?
allison chromatic: no, we renamed it to PARROT_EXPORT months ago
chromatic: with the plan to add PARROT_API back to things that are actually part of the public API 23:35
chromatic That's right. I had it backwards.
allison chromatic: (once we define what that is)
chromatic: but, the public API definition is part of the 1.4 roadmap
chromatic: in the meantime, anything that's not static could potentially be public 23:36
chromatic We shouldn't define it anyway until we reorganize subsystems and their headers. 23:39
allison chromatic: yes 23:40
chromatic And by the way, patching the JIT like I did last night (this morning) reconfirmed my suspicions about the minimal opcode idea I've mentioned. 23:41
The combinatorial explosion we have there makes our current JIT approach infeasable.
allison I was looking over our ops yesterday, and thinking many of them could probably be dynops instead. 23:42
chromatic To JIT any non-trivial op, you have to write heavily-macroed C code which generates mostly-naive and very platform-specific ASM code to duplicate the existing C code of the ops.
If we could define ops in PIR/PBC, yes. 23:43
allison chromatic: well, that's a different problem, a bootstrapping one 23:44
Tene Is there currently grant money potentially available for parrot tasks? 23:45
chromatic Free JIT for dynops... they're first class citizens for optimizations that way.
allison chromatic: but also not much advantage over subs, at that point 23:46
chromatic Funny thing, that. You'd think I know a little about Forth.
One difference, which may or may not be very material: argument handling 23:47
When *compiling* an op versus a sub, you can rejigger where the op gets its arguments.
(at least we have that option in a memory transfer system, as opposed to a stack based machine) 23:48
You don't really get to do that with subs until you inline them aggressively, which is probably closer to the JIT optimization pass.
dalek tracwiki: v138 | tene++ | ParrotRoadmap 23:49
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/bekic8
23:50 contingencyplan joined
allison I could use some additional eyes on NEWS. 23:53
dalek rrot: r37506 | allison++ | trunk/NEWS:
[release] Initial entries in NEWS.
allison This month has a lot of release preparation work. 23:54
chromatic: yes, potential
purl potential is like, almost NIL in the real world!
chromatic PBC would have to change a lot once that's in place. 23:56
allison chromatic: if they're defined in PIR, then they're just Subs, really
chromatic: even if handled slightly differently 23:57
chromatic They don't have the overhead of argument passing, and they're not continuation points.
Although the unification of subs and ops is interesting. 23:58
Tene what ever happened to pirc? is that still coming?
allison (we're talking 3.0 or beyond here, and highly speculative, for the folks in the bleachers) 23:59
AFAIK, yes pirc is coming along
Tene kk
allison and still to replace IMCC ASAP

Powered by Cro and the Raku® Programming Language.

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

Thank you!