Parrot 1.8.0 Zygodactyly released | Parrot 1.9.0 to be released Tues 15 Dec
Set by moderator on 14 December 2009.
japhb kid51, I doubt it. 00:00
I'm not sure we have any tools that can get that kind of info except maybe the profiler, and it's not doing HLL profiling 00:01
00:01 tetragon joined
Tene pmichaud: available for questions about pdd31? 00:01
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#30923), fulltest) at r43056 - Ubuntu 9.10 amd64 (g++ with --optimize)
pmichaud Tene: Tene sure 00:02
(although I may get interrupted)
japhb afk for a break to mentally digest 00:03
Tene 1) it looks like parse_name is specced as returning an array. This seems to prohibit things like Foo::Bar:ver<5.1.3>:auth<FOO>, or do you expect that those named items would just have some special representation in the array of strings? ['Foo','Bar',':ver...'] ? 00:04
2) Why have you separated load_module from get_module instead of deferring that choice to the HLL? What are the guidelines for when to call load_module and when to call get_module?
00:06 bacek joined
kid51 msg fperrad After Tuesday release, can you test Win32-patch in trac.parrot.org/parrot/ticket/886#comment:7? Thanks. 00:08
purl Message for fperrad stored.
kid51 msg particle After Tuesday release, can you test Win32-patch in trac.parrot.org/parrot/ticket/886#comment:7? Thanks.
purl Message for particle stored.
pmichaud (got interrupted) 00:10
I wasn't particularly dealing with the :from/:ver part of the specification yet. 00:11
I think parse_name is traditionally more about runtime symbol names than module names. (Granted the runtime symbol names need those designations as well.) 00:12
My expectation at this point would be that :ver, :auth, etc should perhaps be more hash-like than array-like, so perhaps we generalize parse_name to return a Capture
or perhaps that's actually a HLL-level decision
since a HLL has to decide internally how it wants to handle naming of multiple-versions of a module 00:13
so yes, in that case (I'm thinking out loud here) using some special representations in the array of strings seems most appropriate
or the HLL decides that it should really be ['Foo';'Bar:ver<2.3>'] 00:14
in some sense the array of strings needs to be treated as opaque data by foreign HLLs
Tene That seems distasteful to me. I'd rather see a capture, or even better, a hash-interface with required attribute 'name', maybe with other defined-but-optional keys.
but, I'm not too picky there. 00:15
seems like ['Foo';'Bar:ver<2.3>'] would invite parsing it twice, which seems a bit silly.
pmichaud why twice?
Tene first to split on ::s, second to pull out the named parts from the last element. 00:16
If you're already parsing the name in the first place, wy not fully parse it there?
pmichaud in some sense, this is also why pdd31 starts to introduce the idea of opaque modules
er, opaque module handls
*handles
my impression of pdd21 (namespaces) was that parse_name was more about variable names than module names 00:17
dalek rrot: r43057 | darbelo++ | branches/pmc_freeze_cleanup/src/pmc_freeze.c:
Avoid leaks on exceptions.
Tene That also seems a bit off to me... you have your opaque handles, and then you have a standard function with a standard return value to actually get information out of them... why not just specify some standard for the return of module loading in the first place?
and skip the opaque handle part.
i expect that your answer to load_module/get_module will touch on what I'm missing there. 00:18
pmichaud my main reason for load_module and get_module separation was to have a way to ask a language "give me the handle to a module you've already loaded" versus "load this module, please" 00:20
I don't think that the only available request should be "load this module and tell me if you failed"
I think we should be able to ask a module "did you load this already?" 00:21
s/module/hll/
I could agree to upgrading parse_name a bit -- I just didn't want pdd31 at this point to stray too far from what we have already
Tene What I mentioned is what we were already using. 00:22
for module loading.
pmichaud ?
I didn't quite follow that last comment. 00:23
Tene svn.parrot.org/parrot/trunk/runtim...parrot.pir -- load_library accepts an array specifying a name and optional named arguments 00:24
Coke pmichaud: wiki.github.com/perl6/nqp-rx/requests - any pointers for me on item #2 in coke wants? 00:25
Tene github.com/tene/steme/blob/master/s.../steme.pir -- same thing in steme, and in rakudo master
Coke pmichaud++ # completing HG.
00:26 fperrad joined
pmichaud Tene: okay, yes, load_library was already accepting an array specifying a name and optional named arguments.... I'm not sure I see the issue 00:27
Tene pmichaud: In that case, I'm imagining something, so feel free to ignore it.
pmichaud in some ways what I wrote in pdd31 was meant to clarify and update things we had done before, as well as provide some new interfaces 00:28
Tene pmichaud: so, when would you use get_module vs load_module ?
pmichaud I'd use get_module if a knew a particular module had already been loaded. 00:29
or if I wanted to query if a particular module was loaded.
in writing the code for HLL::Compiler, it turned out to be a nicer refactor if the "return a module handle" part was separate from the "load a module" part
especially if we end up with languages that share module handles but perhaps have different load semantics
Tene does load_module fail if a module is already loaded? 00:30
pmichaud no
it's kind of like the distinction between "get_namespace" and "make_namespace"
Tene Okay, I get it.
Oh, more... 00:31
japhb is going to be needing the ability to query HLLs for library information, for plumage. "Do you have module Foo::Bar? What version is it? Is it more than 5.10 but less than 6.8?"
pmichaud makes sense, I'd propose some api extensions then 00:32
Tene Seems to me that this should also be exposed through the HLL API, yes?
pmichaud but be careful of that question's phrasing
Coke Tene: btw, check out tcl's [package]
pmichaud it's more like "what versions of Foo::Bar do you have?"
as opposed to "do you have Foo::Bar" 00:33
Tene IME, "Give me all available information about Foo::Bar" is appropriate, yes?
pmichaud sure, that works
darbelo purl: msg plobsing I applied two patches by tewk++ to the branch today, and made some changes afterwards, let me know what you think of them. In particular of r43058. 00:34
purl Message for plobsing stored.
Tene pmichaud: if get_module/load_module returned something with a defined interface instead of opaque, we already have that query. ;)
pmichaud my goal for pdd31 was to get a document started more than decide that we had finished it. And to have a nqp-based implementation for it.
Tene Okay. 00:35
pmichaud I'm fine if we define an interface for that
however
I really want to avoid imposing requirements on hlls at this stage of the game (more)
Coke me posits >> as an end of line marker indicating "more". =-) 00:36
pmichaud at this stage of the game, I'd prefer that a defined interface be adopted by convention and experience than defined a-priori 00:37
Tene Coke: but is Ā» allowed? What about ā‰« ?
pmichaud so, rather than encoding something specific in "Compiler API" part of pdd31, I'd prefer that we leave it as "opaque" but then say "here's the module information that HLL::Compiler returns by default, and its defined interface" 00:38
and then create such and object in HLL::Compiler
*an
Tene pmichaud: but you *are* defining something as the return value of get_exports. Is that different? 00:39
pmichaud yes
or, it may not be
the biggest difference is that at this point, I'm more interested in getting exported symbol information from a library than meta-information from it 00:41
it's entirely possible that they should be unified
Tene Okay. I think I understand now. Thanks.
pmichaud but more to the point I was trying to follow allison's dictum (from the previous pdd31) that the requirements imposed on hll writers had to be minimal
I was also trying to create something that could handle export details with simple symbol table entries, instead of having to fill out an entire PMC data structure 00:42
nopaste "coke" at 72.228.52.192 pasted "nqp-rx question..." (27 lines) at nopaste.snit.ch/19083
pmichaud Coke: your question is in my queue, but it'll be about an hour before I can get to it. dinner just landed on the table 00:43
00:43 plobsing joined
pmichaud oh, for the nopaste 00:43
you need
+ Partcl::Grammar.O(':prec<15>, :assoc<unary>', '%unary'); 00:44
otherwise it think it's a binary operator
Coke woot.
00:46 fperrad joined
pmichaud oh 00:46
Coke (that did it, pushing) 00:47
dalek rtcl-nqp: 71f4a01 | coke++ | (2 files):
implement [expr !]
 00:48
rrot: r43058 | darbelo++ | branches/pmc_freeze_cleanup (2 files):
Add a dummy self-reference and a #define to the visit_info structure to preserve

on this branch and pass al freeze/thaw tests. This should allow us to merge our changes back to trunk without waiting for a deprecation boundary.		 00:50
darbelo purl: msg plobsing I don't know if I'll be available in the next 16 or so hours. So, eel free to revert any changes I've made that you disagree with. We should probably figure out a common strategy for the pmc_freeze_cleanups too.
purl Message for plobsing stored.
plobsing I was just going to say you're on a roll!
darbelo Heh, my roll's mostly tewk++'s work. And it's finished for today. 00:51
plobsing Although I'm not quite sure about limiting the scope of the packfile if we're moving to packfile generation in stead of using a STRING as a buffer 00:52
But it is definitely cleaner in the short term. 00:53
darbelo I figured we could try a two step approach: first clean up as much as we can while staying ccompatible, do a round of HLL-testing and merge back to trunk as soon as posible.
Then re-branch and do the compat-breaking stuff so it can land right after 2.0 is released. 00:54
That way we get two branch that live less than a month and are easier to merge to trunk. 00:55
But I have to go now. I'll try to get back nline in a few hours. See ya!
plobsing darbelo++ # good plan
chromatic Great plan. 00:56
00:57 abqar joined
dalek rtcl-nqp: 5c9d4dd | coke++ | src/Partcl/commands/main.pm:
fix unset's arg handling.
 00:59
01:10 fperrad joined 01:16 patspam joined 01:19 Whiteknight joined 01:32 fperrad joined
pmichaud Coke: (item #2, interpolating captured components) -- at the moment that's a bit expensive to implement naively, and the non-expensive approach requires a nqp refactor. 01:34
not a big refactor, but a non-trivial one.
(actually it's more of a regex refactor than an nqp one) 01:37
dalek rrot: r43059 | pmichaud++ | failed to fetch changeset:
[nqp]: Update with latest sources.
 01:38
01:38 jsut_ joined 01:49 JimmyZ joined 02:00 fperrad joined 02:05 egalia joined
dalek TT #604 closed by pmichaud++: pge, debug and visibility, tools 02:08
Coke pmichaud: ok. any way to get that behavior in the Action? I tried, but $<extra> was an RPA, which was not what I expted.ected. 02:23
02:25 fperrad joined
dalek rtcl-nqp: fbaf3fc | coke++ | TODO:
this is impacting multiple test files.
 02:31
rtcl-nqp: db16f1a | coke++ | src/Partcl/commands/file.pm:
Add several placeholder builtins; gets us further through several .t files
kid51_at_dinner make fulltest: Darwin/PPC: PASS at r43056 02:39
dukeleto 'ello
kid51 dukeleto, hello 02:40
JimmyZ good morning, #parrot
dukeleto JimmyZ: howdy
we have a release tomorrow, exciting! 02:42
dukeleto has been swamped in meatspace
cotto not really, but that's the point of monthly releases ;) 02:43
kid51 meatspace?
purl i think meatspace is as opposed to the cyber kind.
nopaste "kid51" at 70.85.31.226 pasted "linux/i386: context_unify3 branch: r43059: make corevm/coretest has many test failures" (2994 lines) at nopaste.snit.ch/19085 02:53
03:15 kid51 joined
dukeleto cotto: i still find our monthly release exciting, but I hope the release manager doesn't ;) 03:30
make fulltest PASS on r43059 darwin/x86 03:36
03:49 diakopter joined 03:59 integral joined 04:48 iblechbot joined 04:56 ZeroForce joined
dukeleto wow, evidently .include 'blah.pbc' is allowed and makes funny things happen 04:57
cotto I'd guess that you're not saying it makes parrot tell a funny joke. 04:59
dukeleto cotto: silent death 05:01
where do I go to learn about making a fakecutable?
chromatic man pbc_to_exe 05:03
(let's see if pervasive laziness applies also to documentation)
dukeleto chromatic: No manual entry for pbc_to_exe 05:06
ack -a pbc_to_exe docs/ returns nothing # :(
chromatic What would you like to know? 05:07
dukeleto chromatic: i want to make an executable out of Tapir 05:09
chromatic: i have a .pir file which includes 2 pbc's
chromatic I haven't tried this and advise you to fire up your bug client, but I'd turn them all into PBC files, use pbc_merge, and then pbc_to_exe on the result. 05:10
dukeleto chromatic: i want to make a binary that bundles the all three together, without the 2 PBC's which are included having to be installed
chromatic: ooh, i haven't used pbc_merge before
chromatic: trying now 05:11
cotto chromatic, how current is the packfile pdd? 05:15
chromatic I thought I read that it's very close, barring some changes to annotations. 05:17
... but I don't know much about packfiles.
dukeleto chromatic: creating the fakecutable worked, but I got: 05:19
A method named 'is_pass' already exists in class 'Tapir;Stream'. It may have been supplied by a role.
chromatic: is that a bug on my part or pbc_to_exe ?
chromatic Do you have :init and :load on any sub in your code?
dukeleto chromatic: yes 05:21
chromatic: i add attributes to an object in a method that has both :init and :load
chromatic: that was the first way I got it to work. what is the correct way? 05:22
chromatic I think only :init is necessary.
However... this is a messy part of PIR/PBC isomorphism.
dukeleto chromatic: i only have an is_pass method defined in one place in one class 05:24
chromatic: same error if I only use :init
chromatic Okay, switch it to :load. 05:25
dukeleto chromatic: that seems to make stuff work, but some tests fail, which I shall investigate. can you explain to me the difference between having :load, :init and both? 05:28
chromatic :load executes only when loading from bytecode.
:init executes right after compilation.
The effects of :init should be frozen into PBC. 05:29
dukeleto chromatic: i need that stuff because one of my classes instantiats the other inside 05:30
chromatic: Class '[ 'Tapir' ; 'Stream' ]' not found 05:31
current instr.: 'parrot;Tapir;Parser;parse_tapstream' pc 155 (lib/Tapir/Parser.pir:88)
now I get that error, when i only have :load
nopaste "chromatic" at 72.87.39.97 pasted "bacek: this patch fixes many, many segfaults on context_unify3, but it's not quite correct" (25 lines) at nopaste.snit.ch/19087
chromatic Hm. 05:32
Last idea, try :init :anon.
msg bacek Please see nopaste.snit.ch/19087 for a partial cure to context_unify3 woes.
purl Message for bacek stored.
plobsing msg darbelo r43056 introduced bugs for me (amd64) in t/pmc/packfile*. It appears that the packfile makes PF_fetch* use functions from src/byteorder.c to read the buffer. Still investigating. 05:35
purl Message for darbelo stored.
bacek_at_work chromatic, I did remove pop_context from invoke_from_sigobject...
At least I think so...
chromatic Still here for me. 05:36
Now I'm not getting the output from the plan(test_number) calls in pure-PIR test files, but I'm not getting seggies and I'm getting the rest of the output. That helps.
dukeleto chromatic: :anon looks promising. why does that help?
bacek_at_work chromatic, trac.parrot.org/parrot/changeset/43...ext_unify3 05:37
it's... weird.
chromatic :anon :init trips the "Do something special with bytecode" magic.
dukeleto chromatic: that sounds ..... magical
chromatic shhhhh 05:38
See my message about PBC constants from last week.
bacek_at_work, maybe I didn't get a recent rebase. 05:39
bacek_at_work chromatic, latest changeset is r43046 in branch
chromatic Checking. 05:40
Could be I was working off of an old version.
Yep, looks that way. 05:44
dukeleto chromatic: i have a fakecutable for Tapir passing its own test suite! thanks! chromatic++ 05:47
chromatic What did you have to do, dukeleto? 05:48
bacek_at_work, some of the failures come from CURRENT_CONTEXT(interp) being PMCNULL.
In t/compilers/imcc/reg/alloc_1.pir, the context is PMCNULL in the invokecc op. 05:49
bacek_at_work chromatic, I'll put assert from your nopaste and try to find out real problem. Later today. 05:50
chromatic I'll keep poking at it too. 05:53
dukeleto chromatic: i had to use :load :anon and load_bytecode on the PBC's instead of include()'ing PIR 06:01
bacek_at_work chromatic, major problem afair was with attributes. Which prevent Test::More from work.
chromatic I see that. 06:03
dukeleto it looks like load_bytecode 'foo.pir' works. should it? 06:04
chromatic There's no other way to load PIR. 06:05
dukeleto chromatic: .include() ? 06:07
chromatic: i was thinking that load_bytecode should only work for *.pbc files. is that correct?
chromatic: this is the commit where i changed over to a fakecutable in tapir: leto.net/gitweb/?p=tapir.git;a=comm...733a3faeb0 06:16
dalek pir: 7ae5c81 | dukeleto++ | t/03-parse_tapstream_error.t:
[t] Add a basic test for a passing exit code

  (kadath)(~/git/tapir master )$ ~/svn/parrot/parrot t/harness.pir t/*.t
t/00-sanity.t ................. failed 0/0 tests, exit code = 1 t/01-parse_plan.t ............. failed 0/0 tests, exit code = 1 t/02-parse_tapstream.t ........ failed 0/0 tests, exit code = 1 t/03-parse_tapstream_error.t .. failed 0/0 tests, exit code = 1 FAILED 4 test(s) in 4/4 files		 06:23
pir: b2e6ebd | dukeleto++ | (8 files):
Make a fakecutable and PBC's which can be more easily dropped into external projects # chromatic++

Thanks to chromatic++ for showing me the ":load :anon" black magic trick.
pir: 445fd64 | dukeleto++ | (3 files):
load_bytecode should use the PBC's and update 'make clean'
dukeleto github just came back up 06:24
dukeleto is using Tapir to run the Regexp::Common test suite 06:25
what is the best way to time PIR code in PIR? i want to print out the runtime of the test suite. do I have access to anything other than walltime from PIR? 06:27
cotto dukeleto, interesting question. There's no pir-level integration with the profiling runcore atm. 06:28
what were you hoping for interface-wise? 06:29
dukeleto cotto: it would be nice if I could get something like : 0 wallclock secs ( 0.04 usr 0.01 sys + 0.02 cusr 0.01 csys = 0.08 CPU) in PIR
diakopter cotto or bacek_at_work: do you have a couple of minutes to look at examples/benchmarks/primes.pasm with me?
cotto diakopter, did you mean chromatic or was that intentional? 06:30
diakopter intentional
cotto what about it?
diakopter line 51
if you run: parrot primes.pasm what does it output for "last"
cotto looks OK to me. ;) 06:31
4999
diakopter ok. I have parrot r42559 06:32
and it outputs 5001 06:33
for last
on amd64
linux
cotto that's odd 06:34
also, unexpected
diakopter is that the right way to invoke? parrot primes.pasm ?
cotto It seems to be. I don't see any arg processing. 06:35
diakopter also, primes_i.pasm is misdocumented; its max candidate is 10000, not 50000 06:36
cotto Those could use some cleanup. 06:37
diakopter interestingly, primes_i.pasm has the same algorithm 06:38
but does the right thing
sounds like a misoptimization 06:40
does anyone have linux amd64 who'd be willing to build parrot r42559 (release 1.8.0 it appears)? 06:41
anyway, the machine on which I'm experiencing the issue is the machine that hosts rakudo/rakudo-ng for p6eval on #perl6 on freenode 06:44
afk& # please reply; I'll backlog
# also, I'd be glad to give a shell account to anyone on that machine if you'd like to diagnose it 06:45
cotto diakopter, I'll have 64-bit linux at work. I can play with it then if nobody beats me to it. 06:48
NotFound diakopter: I fixed that problem 1-2 weeks ago 06:49
cotto sweet. I don't have to do anything. 06:52
NotFound++
NotFound r42611 -> [examples] fix primes.pasm to show the same "last is" as the other versions 07:05
diakopter oh? cool. what was the problem 07:08
oh 07:09
cotto I was kinda hoping for some exotic platform-dependent bug that could be tickled from pasm, but a non-bug is a good second choice. 07:11
NotFound I located that problem when checking a benchmark comparaison that PacoLinux was doing with Winxed. 07:25
07:45 ZeroForce joined
chromatic bacek_at_work, what's the use of Parrot_pcc_[gs]et_signature()? 08:11
Isn't a context its own signature, or is that storage for the signature of an impending call?
Do we need to remove Parrot_pcc_get_signature calls from a lot of the code?
08:25 bacek joined 08:28 riffraff joined
dalek rrot: r43060 | gerd++ | trunk/NEWS:
rid of the first item of: Converted Contexts to GC structures (NEWS)
 08:30
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#30926), fulltest) at r43059 - Ubuntu 9.10 amd64 (g++) 08:49
cotto good news for release day 09:13
09:47 bacek joined 09:50 payload joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#30933), fulltest) at r43060 - Ubuntu 9.10 amd64 (gcc) 09:50
chromatic bacek, this is tricky. I made Parrot_pcc_get_signature check for PMCNULL and return the CallContext itself, but that didn't help too much. 09:51
bacek chromatic, erm...
chromatic Just a hunch. 09:52
bacek chromatic, are you trying to fix attributes problem?
chromatic I hadn't reached that point yet.
bacek ah, ok.
chromatic I figured as long as some of the IMCC tests failed, there's little point in trying something more complex.
bacek which one? 09:53
chromatic t/compilers/imcc/syn/op_20.pir
src/call/context.c:792: failed assertion 'Parrot_pcc_get_regs_used(interp, ctx, REGNO_STR) > idx'
bacek "someone" didn't pop context after
..use 09:54
(afk for few minutes)
chromatic get_params maybe should do that.
No... Continuation.invoke() seems better. 09:56
Though Parrot_continuation_rewind_environment() appears to do so. 09:57
JimmyZ hello chromatic 10:06
chromatic Hello. 10:10
JimmyZ chromatic: Does array.pmc needs to change to use GET_ATTR syntax? 10:13
chromatic: s/needs/need/
chromatic array.pmc is rarely used. It's probably not worth your time to update. 10:23
JimmyZ chromatic: ok, I had updated it, but just change SELF.foo() to STATICSELF.foo() :) 10:24
chromatic Okay. 10:26
10:29 bacek joined
bacek chromatic, yes, rewind_env usually DTRT 10:31
(I just found at lease one case of using uninitialised CallContext. Fixed in r43061)
dalek rrot: r43061 | bacek++ | branches/context_unify3 (5 files):
Allocate CallContext in pcc_prepare_call if it wasn't allocated before
 10:41
rrot: r43062 | fperrad++ | trunk/t/op/arithmetics.t:
[t] fix the use of PIR todo
rrot: r43063 | fperrad++ | trunk/t/op/io.t:
[t] fix the use of PIR todo
rrot: r43064 | fperrad++ | trunk/t/pmc/float.t:
[t] fix the use of PIR todo
chromatic t/compilers/imcc/syn/regressions_2.pir looks suspicious. 10:51
The continuation in returncc is wrong. 10:53
I wonder if it's uninitialized.
bacek chromatic, I'm working on t/compilers/imcc/syn/pcc_7.pir... something goes very wrong here 10:55
chromatic Something's definitely wrong in our continuation handling. 10:56
dalek rrot: r43065 | chromatic++ | branches/context_unify3/src (2 files):
[ops] Reformatted code; no functional changes.
 10:57
rrot: r43066 | chromatic++ | branches/context_unify3/src/call/context.c:
[PCC] Fixed a C90 violation; no functional changes.
bacek chromatic, Coroutine.invoke is wrong 10:58
10:58 payload joined
chromatic It's a big wad of code. 10:59
bacek line 146.
We already pushed new context at this point
I'll try to fix it
chromatic Ahh yes. 11:00
Is it as easy as grabbing ->from_ctx?
bacek chromatic, something like this 11:11
chromatic t/compilers/imcc/syn/regressions_2.pir segfaults because in Continuation.invoke from the returncc, the Continuation's pc (cc->address) is NULL.
bacek I'll look at it after fixing Coro 11:14
chromatic Hmm, if I add the end opcode, everything works. 11:16
It reaches the end of the sub and tries to return, even though it has nowhere to go. 11:17
... meaning something wrong in the initial context or its Cont.
... but only if it's the first sub in a file (not marked :main) and if there's been a push_eh. 11:27
That's all I can do tonight. 11:31
moritz t/pmc/eval.t failed test 12 in 'make testr' 11:34
bacek chromatic, good night. I'm still fighting with Coro... 11:37
dalek rrot: r43067 | bacek++ | branches/context_unify3/src/ops/core.ops:
Remove setting caller_ctx in op get_params.
 12:19
rrot: r43068 | bacek++ | branches/context_unify3/src/pmc/coroutine.pmc:
Update Corotine.invoke to use already pushed CallContext.
12:40 payload joined
bacek msg chromatic Sigh... r43065... merge_signature_for_tailcall. I've lost last hour trying to find out why branch is more broken than before... 12:49
purl Message for chromatic stored.
12:50 JimmyZ joined, whiteknight joined
moritz oh noes, context_unify3 killed my computer 12:57
I ssh'ed into my home computer and ran 'make coretest' there, foolishly without resource limits 12:58
12:58 barney joined
moritz now I can't reach it anymore 12:58
whiteknight urg.
I haven't looked hard at that branch yet, I think I should 12:59
Coke "Already up-to-date. 13:01
"Already up-to-date."?
purl i heard "Already up-to-date." was the saddest messages there is.
dalek rtcl-nqp: cb7399b | coke++ | src/Partcl/commands/ (3 files):
make p6.vim happier.
 13:12
rtcl-nqp: 2d7ce87 | coke++ | (3 files):
Add several placeholder builtins; gets us further through several .t files
Coke msg tene any luck figuring out my CONTROL issue? 13:15
purl Message for tene stored.
whiteknight win32-msvc15: all tests pass (but perl failed uploading the archive to smolder for some reason) 13:25
oh nevermind. It did upload to smolder, but perl exited with an error anyway 13:28
great
Coke Hey, anyone want to write some NQP? =-)
whiteknight how much, and for what?
Coke bits. for partcl. 13:29
some builtins could use some work.
13:30 mj41 joined 13:31 JimmyZ joined
Coke [string] has a lot of subcommands that a) have tests, b) have a description on tcl.tk, and c) have the hook where the code goes. 13:31
whiteknight I dont know anything about TCL 13:32
Coke not really a problem. =-)
whiteknight I'm more of a PIR guy than an NQP guy. 13:33
Coke here's your chance to learn! =-)
(nqp really is much nicer than pir.)
JimmyZ yes 13:34
whiteknight I won't debate that it's a cleaner language. I'm just more comfortable at lower-levels
Coke is led on by WK! 13:35
13:35 lucian joined
whiteknight what do you need written? I can take a look 13:37
13:37 mikehh joined 13:39 payload joined 13:47 tetragon joined
Coke whiteknight: there's just lots of stuff to do; for example, implementing [string length <foo>] 13:49
[string] is in src/Partcl/commands/string.pm - look for eq 'length' for the code for that subcommand.
whiteknight it's in the partcl-nqp repo? 13:50
Coke www.tcl.tk/man/tcl8.5/TclCmd/string.htm#M38 has the tcl info on tht subcommand. t/cmd_string.t has tests.
(yes.)
I've been trying to do the error handling as I go, but even the base functionality will get us a few more tests.
(At the pir level, this is just the length opcode.) 13:51
whiteknight: I can add you as a contributor. github id?
whiteknight "Whiteknight"
Coke done. have fun. =-) 13:52
dalek rrot: r43069 | whiteknight++ | trunk/PLATFORMS:
Update win32-x86-msvc9.0 which passed all tests this morning (smolder #30939)
 13:56
whiteknight urg, I just got hijacked by work. No time to hack partcl today :( 14:05
or, at least not until my boss leaves
Coke heh. 14:11
ooh. [string is <class> -failindex should be pretty trivial if I do everything as a rule.) 14:13
14:14 patspam joined
Util Trying to build a PBC bytecode string in a PIR test, I run into this issue. This line of code: $S0 = "\\xFE" 14:19
causes the error: "Malformed string".
Is there an easy workaround?
Coke set a binary encoding on the string? 14:20
Util Coke: on the string itself, or on the string register? And how do you set it? 14:21
Coke string.
$S0 = binary:"\\xFE" # untested.
Util Coke: Worked! Thanks! 14:22
Coke tested. works here.
Util: np.
Util: I think that's part of the unicode endian marker. 14:24
14:24 mikehh joined
Coke so you'll always have FFFE or FEFF to indicate the order. 14:24
... but those aren't valid strings either. *shrug*. =-)
but since you're not writing unicode, it don't matter. 14:25
14:31 ruoso joined 14:38 mikehh joined
whiteknight is trying to run as many tests as possible before the release 14:50
speaking of, when is Gerd planning to put it out?
pmichaud good morning, #parrot 15:01
whiteknight good morning pmichaud
dalek rrot: r43070 | whiteknight++ | trunk/PLATFORMS:
update PLATFORMS to show OpenSolaris2009.06-x86-gcc3.4.3, a new platform where Parrot builds but fails two math-related tests. See smolder #30941.
Coke moritz: you were timtowdi.org, yes? 15:05
moritz Coke: aye
whiteknight atan, acos, and asin all fail tests on OpenSolaris 15:06
I wonder why that is
fperrad pmichaud have you seen irclog.perlgeek.de/parrot/2009-12-12#i_1828932 ? 15:07
pmichaud fperrad: looking 15:08
fperrad: in what sense do you mean "crashes"? 15:09
it doesn't compile, it compiles but gives an error, ... ? 15:10
15:10 kthakore left
fperrad fails with a back trace 15:10
pmichaud is it possible to come up with a smaller example that exhibits the error?
Coke moritz: what was the hostname? 15:11
moritz timtowtdi.org 15:12
purl i think timtowtdi.org is now unblocked, ie svn shoudl work again.
Coke ... i must have spelled it wrong 100 times. thanks. =-)
moritz purl: timtowdi.org is misspelled 'timtowtdi.org' 15:13
purl OK, moritz.
Coke moritz: that should help, danke ^_^ 15:15
15:16 bubaflub joined
dalek rrot: r43071 | coke++ | trunk/PLATFORMS:
alphabetize
 15:17
nopaste "fperrad" at 93.11.7.221 pasted "a fragment of grammar with the problem (for pmichaud)" (38 lines) at nopaste.snit.ch/19089 15:24
15:34 shockwave joined
shockwave This is kind of a generic question. Can a language targetting parrot, which is strongly typed and object oriented, be made to support covariant return types on overriden methods, and contravariant arguments on normal methods? 15:36
15:38 Psyche^ joined
NotFound shockwave: I think that the only good answer to such question is a working implementation. 15:43
shockwave @NotFound, well, I'm asking in theory. 15:44
15:44 bubaflub joined
NotFound shockwave: in theory, the answer is always yes. 15:44
shockwave @NotFound, I will try it soon. But I wouldn't mind a "probably", or better yet "Definietly" 15:45
Ok. I guess I'm just going to have to try and see for myself. 15:46
Thanks, @NotFound
NotFound shockwave: What kind of language, a version of one that already exists, or created from scratch? 15:49
15:49 rhr joined
NotFound Just curious 15:50
shockwave from scratch 15:51
purl from scratch is fun
Coke shockwave: can you explain the covariant/contravariant a bit? 15:58
and what is the difference between "overridden" and "normal" ? is normal actually "inherited" ? 15:59
shockwave @Coke, Wikipedia does a better job than me: en.wikipedia.org/wiki/Covariance_an...science%29
@Coke, en.wikipedia.org/wiki/Covariance_an...r_science) 16:00
@Coke, a normal method would be a method added to a class, as usual.
@Coke, an overriden method is one declared in a subclass that matches the signature of a method in the base class. 16:01
@Coke, an overriten method is like a C++ virtual method. 16:02
Coke I am not as convinced as notfound that you can do that out of the box, no.
esp. when it comes to return types. 16:03
shockwave @Coke, neither of them, co- or contra?
Coke I have only used parrot objects for infrastructure stuff, not to support an actual language's object system, though. 16:04
I would definitely ask on list first.
shockwave @Coke, For the language I'm designing, the compiler is written in C++, and translates the code down to PIR. The compiler's analyser finds out alot of information about the type as it goes along. And, of course, it has this information available when translating to PIR. 16:05
NotFound Coke: I don't said it has to be easy, just possible ;) 16:06
Coke NotFound: I didn't get the impression he was asking if he could handroll everything he wanted in pir, but if the vm supported this. 16:12
I don't think parrot's object model supports that.
shockwave Coke: Since I'm going to compile down to PIR, if it can be done via PIR, and it's doable for me. 16:13
then* it's doable for me.
Coke shockwave: I am thinking you'd have to hand roll your argument checks inside the method. 16:14
shockwave Coke: I don't mind that, as long as there is a way to get it accomplish.
Coke: My goal is for the language to support things that are important to me. The implementation will get better as time comes along. 16:15
(^^^ that's about my language)
NotFound And having a language that needs that will be a good way to see if something can be added to parrot to support it. 16:17
shockwave @NotFound, sweet.
I'll probably have a working implementation of this in about 3 months. I'm 3 and 1/2 months into it, and I'm making good progress. 16:18
NotFound But note that parrot is not specially intended to strong typed languages.
shockwave @NotFound, I know. I just like the scripting language to be strongly typed in order to catch certain types of errors I usually make, specially when changing large portions of the code. 16:19
The language is designed to support large codebases. I feel that having strong typechecks aids alot when changing code in large codebases like that. 16:20
NotFound Good to know I'm not the only one writing a compiler targetting pit in C++ X-) 16:22
s/pit/pir
shockwave :-) 16:23
16:26 darbelo joined 16:34 shockwave left
diakopter dukeleto: more comparison results: optimized parrot takes 1.441s on fib.pir; mono 2.6 takes 0.071s for the same program 16:35
... now to port arriter 16:37
Coke woof. 16:48
moritz I guess mono has the advantage of type analysis on its side, as well as a working JIT 16:49
NotFound diakopter: What language, C# ? 16:53
diakopter NotFound: yes
NotFound diakopter: Can you add the C# version to examples/benchmarks? 16:55
diakopter I submitted a parrot CLA a year or two ago; I never heard back 16:56
NotFound I think two years aho pafo wasn't even born ;) 16:57
s/aho/ago 16:58
diakopter nevertheless: parrot.pastebin.com/d5db9dbdf
16:58 davidfetter joined
NotFound Thanks, I'll add it. 16:58
diakopter oh wait. 17:00
forgot to sw.Stop(); after the _fib() call. So it was including the I/O time. without the I/O time, mono outputs: fib(28) = 317811 17:01
Elapsed: 00:00:00.0000592
dukeleto diakopter: if you submitted a CLA and never heard back, you should send it again :) 17:02
diakopter sigh. ID10T error
17:02 theory joined, gerd joined
cotto diakopter, once you send one in, you can ping particle every 5 minutes to see if it's arrived yet. 17:02
diakopter make that Elapsed: 00:00:00.0111256 17:03
NotFound: corrected parrot.pastebin.com/d698eef30
Coke what's the name on the CLA? 17:05
diakopter Matthew Wilson
I'm quite sure I submitted it before the parrot foundation existed 17:06
Coke then it's not a PaFO CLA, but a perl CLA, yes?
diakopter I guess
Coke parrot cla? 17:07
cla?
purl cla is Contributor License Agreement or www.perlfoundation.org/contributor_..._agreement or www.parrot.org/foundation/legal or www.parrot.org/files/parrot_cla.pdf
gerd I want to checkout parrot for release 1.9.0 17:08
NotFound gerd: uh, sorry, forgot to ask
Just committed r43072 17:09
Coke NotFound: did you update manifest? fix svn props?
gerd Can I start?
NotFound gerd: pleas wait a moment...
gerd Okay no problem 17:10
17:10 Zak joined
dalek rrot: r43072 | NotFound++ | trunk/examples/benchmarks/fib.cs:
[examples] C# version of benchmark/fib, diakopter++
 17:11
NotFound gerd: done, r43073 17:14
gerd Okay so I will start to update to 1.9.0 17:15
cotto woohoo! release time! 17:18
moritz doughnuts for our release manager! 17:19
davidfetter mmm...doughnuts :d 17:21
gerd make fulltest is running 17:22
Result: FAIL 17:25
Test Summary Report
-------------------
t/op/annotate.t (Wstat: 11 Tests: 29 Failed: 0)
Non-zero wait status: 11
Parse errors: Bad plan. You planned 33 tests but ran 29.
Files=222, Tests=7085, 89 wallclock secs ( 1.58 usr 1.98 sys + 31.15 cusr 41.47 csys = 76.18 CPU)
dalek rrot: r43073 | NotFound++ | trunk (2 files):
[cage] update MANIFEST and svn props
 17:27
Coke gerd: hurm. I've done fulltest 2c today and not seen tha failure. 17:29
bad skip logic?
bubaflub Coke: t/op/annotate.t passes on my rig 17:30
gerd Okay I will checkout again and try I again
bubaflub gerd, if that happens again, can you run prove -v t/op/annotate.t and then nopaste the output
so we can get a better look at the error 17:31
Coke (note that you might need to run it in a specific core, since you were using fulltest)
theory seen chromatic 17:35
purl chromatic was last seen on #parrot 6 hours, 4 minutes and 10 seconds ago, saying: That's all I can do tonight.
theory fucking slacker
dalek kudo/master: 55f51dc | pmichaud++ | docs/spectest-progress.csv:
"2009-12-15 00:00",7ef3861,32225,504,543,2027,35172,38173,453
gerd make fulltest is running again 17:36
dalek nxed: r265 | julian.notfound++ | trunk/ (2 files):
operator [ ] in stage 1
 17:38
gerd make fulltest fails again
japhb By the way, did we institute the "cooling off period" after the release and before new branches are merged? Or did that get tabled or voted down?
gerd The output of prove follows: 17:39
cotto_work japhb, I don't remember anything like that.
gerd prove -v t/op/annotate.t --also fail 17:41
Failed 4/33 subtests
japhb IIRC, it was a suggestion after one of the times where merges happened immediately after the release was cut, and the HLLs didn't have time to test against it, and flag any problems, before the trunk went all to hell again.
Like I said, I don't remember what happened to the suggestion, though.
cotto_work japhb, actually I do remember something like that. I bet pmichaud would remember since he probably felt the most pain. 17:43
particle actually i think it was a merge just before a release that meant the 2-days-later rakudo release wouldn't work with the just-cut-parrot release 17:49
bubaflub gerd: can you get me the output of running just that test file? 17:50
something like prove -v t/op/annotate.t would do
or even ./parrot t/op/annotate.t
gerd ok 26 - annotations for caller sub returend with level 1
ok 27 - annotations from caller sub returned at point of call with level 1
ok 28 - annotations for outer sub returend with level 1
ok 29 - annotations from outer sub returned at point of call with level 1
Failed 4/33 subtests
Test Summary Report
-------------------
t/op/annotate.t (Wstat: 11 Tests: 29 Failed: 0)
Non-zero wait status: 11
japhb particle: Actually, now that you mention it ... didn't parrot's release get cut on a branch, and then merges happened before a trunk revision existed that contained the true release?
gerd Parse errors: Bad plan. You planned 33 tests but ran 29.
Files=1, Tests=29, 0 wallclock secs ( 0.03 usr 0.01 sys + 0.01 cusr 0.02 csys = 0.07 CPU)
Result: FAIL
[gz016@vgerd2 trunk]$ 17:51
bubaflub gerd: that's strange, it's not running the last test 17:54
let me look at this a bit and i'll get back to you.
barney Looks fine on 32bit Linux
bubaflub yeah, i'm building on Mac OS X 10.6
gerd: what system/architecture are you running? 17:55
i.e. what does `uname -a` output?
Coke japhb: that happened once.
gerd uname -a 17:56
Linux vgerd2.zimt.uni-siegen.de 2.6.29.6-217.2.8.fc11.x86_64 #1 SMP Sat Aug 15 01:06:26 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
purl Infobot 0.43.3 alpha (oznoid+#perl)
japhb Coke: yes. I was asking if we'd made a policy around it, or not.
gerd I run it on an 64 bit machine
Coke until rakudo stops relying on their being a trunk version that corresponds to a release version, please avoid it.
s/their/there/
japhb :-)
Coke *once - happened a few times, but only caused trouble after rakudo. 17:57
17:58 mikehh joined
diakopter NotFound: here's a C# edition of arriter parrot.pastebin.com/d6a197928 18:01
whiteknight might not be able to attend #ps. Work meeting conflict
diakopter optimized parrot: 0.813s mono: 0.078s 18:03
Coke diakopter: depressing. 18:04
but faster than partcl vs. tcl
diakopter Coke: have you seen Eagle? 18:06
eagle.to/ 18:07
I'd be glad to run some benchmarks with eagle-on-dlr-on-mono-on-linux
18:08 whiteknight joined
darbelo clock? 18:08
purl darbelo: LAX: Tue 10:08am PST / CHI: Tue 12:08pm CST / NYC: Tue 1:08pm EST / LON: Tue 6:08pm GMT / BER: Tue 7:08pm CET / IND: Tue 11:38pm IST / TOK: Wed 3:08am JST / SYD: Wed 5:08am EST /
cotto_work #ps in 19 18:11
Let's see some reports!
diakopter dukeleto: which of the benchmarks is parrot particularly/comparatively good at 18:12
Coke diakopter: nope
diakopter: (benchmarks) sure. glad to help implement whatever's needed to run the benchmark on partcl. 18:13
18:14 chromatic joined
Coke ps? 18:25
purl well, ps is postscript or process status or see "parrotsketch" or non-vector?! or annoying.
Coke "parrotsketch"?
parrotsketch?
purl parrotsketch is, like, a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
Coke clock?
purl Coke: LAX: Tue 10:25am PST / CHI: Tue 12:25pm CST / NYC: Tue 1:25pm EST / LON: Tue 6:25pm GMT / BER: Tue 7:25pm CET / IND: Tue 11:55pm IST / TOK: Wed 3:25am JST / SYD: Wed 5:25am EST /
Coke so, ps in 5? =-)
japhb yup
Util and reports sooner!
darbelo Coke++ # best #ps report EVAR! 18:28
18:28 mikehh joined
japhb #ps now 18:30
diakopter optimized parrot takes 0.866s on stress2.pasm; mono takes 0.085s on parrot.pastebin.com/d28362df0 18:33
NotFound: ^^ another to commit if you wish
darbelo 10x? Ouch. 18:34
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#30942), fulltest) at r43073 - Ubuntu 9.10 amd64 (g++ with --optimize) 18:35
Util mikehh: which GC book? 18:36
diakopter those are fixed arrays, but I can try it with ArrayList if you like 18:37
NotFound diakopter: not a good moment right now. Can you attach it to a ticket? 18:38
mikehh Util: Garbage Collection by Richard Jones
gerd I run the Configure without optimize now I will run it wiht optimize
bubaflub gerd: that might not fix your problem, but you are welcome to give it a shot 18:40
mikehh Util :full title Garbage Collection: Alogrithms for Automatic Dynamic Memory Management by Richasrd Jones and Rafael Lins 18:41
Util mikehh: found it; thanks 18:42
mikehh Util: you might want to check www.cs.kent.ac.uk/people/staff/rej/...cbook.html 18:45
gerd I can starting to go to version 1.9.0 anyway, should I start?
darbelo pmichaud++ 18:46
Util mikehh: thanks! BTW, local university library has: Garbage collection in the District of Columbia. April 1, 1918.
FAIL
Coke i have a git repo with a remote branch. how do I create a local branch to work on it?
moderator Parrot 1.8.0 Zygodactyly released | Parrot 1.9.0 to be released Tues 15 Dec | Priorities: documentation review, tutorials, and context_unify3 branch 18:46
moritz Coke: git checkout -b branchname --track origin/brancname 18:47
chromatic I usually use git co -b local_branch_name remotes/branch
moritz newer gits --track automatically, I think
chromatic Should explain it. 18:48
I don't know the difference between origin/branch and remotes/branch. That could be a git-svn artifact here.
pmichaud ("cooling off period") there's not a problem with things landing shortly after a release. It's things changing shortly before a release that cause pain. 18:50
dalek nxed: r266 | julian.notfound++ | trunk/ (2 files):
try statement in stage 1
moritz chromatic: "origin" is just the default name of a remote
Coke pmichaud: does "make spectest" have to pass on rakudo-ng before it -> master?
chromatic Thanks, moritz.
barney make fulltest succeeds on 32bit Linux
Coke (hurm. I thought I just checked out ng and ran make spectest and had it pass 100%) 18:51
Util moritz: I think that "origin" is a GitHub-specific convention
pmichaud I'm not aiming for everything pass... but we need to be passing much more than we are now.
moritz Coke: ng's spectest doesn't run all the files that master runs 18:52
pmichaud oh, 100% pass on ng just means it's 100% pass of the limited set of tests it chooses to run
Coke ah.
got some todo passed, btw.
pmichaud I want it to be passing on-the-same-order-of-tests that master is
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#30943), fulltest) at r43073 - Ubuntu 9.10 amd64 (gcc with --optimize)
pmichaud master is currently at 84.5% of the test suite, so I'd want master to be at least in the 70%ish range
Coke is there a test target I can run in ng that highlights the failures?
particle bubaflub: what's your real name? 18:53
bubaflub Bob Kuo
pmichaud Coke: I'm not aware of one
bubaflub could be under Robert
particle received last week
bubaflub particle: awesomesauce
particle i wish we had a space for irc nick there, i don't know names<->nicks well enough yet 18:54
Coke particle: ... it's email. they can always mention it in the email. =-)
particle email? to a po box? 18:55
cotto_work Anything is possible. 18:56
18:56 mikehh joined
dalek tracwiki: v7 | cotto++ | CottoTasklist 18:56
tracwiki: trac.parrot.org/parrot/wiki/CottoTa...ction=diff
darbelo particle: Sure, print it out ...
particle you people are all thinking backwards 18:57
i received robert kuo's paper-based cla in my physical mailbox.
darbelo .ton era ew oN
Coke particle: post it notes. 18:58
turns out it's even easier to annotate physical paper. =-)
whiteknight I tried 3 times to fax my CLA 19:00
I don't have a scanner to scan+email it
Coke what happened when you faxed it?
(it gets turned into an attachment and emailed to us)
19:01 mikehh joined
whiteknight I was getting an error about "this number does not exist" or something 19:02
particle did you use a 1? 19:03
kids today don't remember life before mobile phones... 19:04
chromatic "Oh no, I dialed a six instead of a seven... now I have to start over, and this number has nines in it!"
bubaflub rotary phones are coming back in style
cotto_work looks forward to a mobile rotary phone 19:05
bubaflub one of our house phones had a little switch for pulse/tone dialing
whiteknight I used a 1, I tried 3 separate times 19:07
it might be my fax machine, and my mad fax skillz are lacking
Coke pmichaud: should be deprecate pge and old-nqp? 19:08
*we
darbelo Aren't they already?
Coke darbelo: not officially. 19:09
pmichaud Coke: I think yes.
or, if not deprecate them, at least mark them as "unmaintained"
Coke pmichaud: as do I. I don't want to have to maintain both tiers.
s/tiers/versions/
diakopter on the ArrayList (essentially ResizablePMCArray) edition of stress2, mono takes 0.26s 19:13
gerd Should I do the "svn commit" to 1.9.0 now? 19:16
chromatic Do it! 19:17
gerd Done 19:18
Patterner yay!
moritz gerd++ 19:20
cotto_work gerd, did crow.pir ever get fixed? 19:21
barney gerd++
cotto_work gerd++
dalek rrot: r43074 | gerd++ | trunk (10 files):
update to version 1.9.0
19:22 kj joined
gerd cotto_work: no crow.pir seem not to be fixed 19:24
cotto_work how annoying 19:25
dukeleto 'ello 19:28
gerd: crow.pir was broken since before 1.7.0 release. i wrote the 1.7.0 release by hand
19:29 lucian joined
dukeleto gerd: also, let me know when things go out, so I can tweet/dent appropriately 19:29
Coke (there's a ticket for crow.pir) 19:30
dukeleto Coke: we should deprecate/unmaintain pgegrep and friends as well 19:33
cotto_work It's nice that we have enough volunteers that any given committer only has to care about the release process maybe once a year.
darbelo I'd expect that if they had to care more we would have less. 19:34
particle how did crow break? it's a simple script...
darbelo The json compiler is the actual broken piece. 19:36
crow.pir simply exposes it.
dalek rrot: r43075 | barney++ | trunk/ChangeLog:
Fixed a date in ChangeLog.
 19:38
rrot: r43076 | gerd++ | tags/RELEASE_1_9_0:
tagged release 1.9.0
darbelo $P0 = get_root_global [ 'JSON' ], '$escapes' is handing a NULL PMC, to the displeasure of the next line, which tries to use that PMC.
particle ah 19:39
dukeleto it should be data_json 19:40
19:43 mikehh joined
darbelo dukeleto: If I do that I get ""load_language" couldn't find a compiler module for the language 'data_json'" 19:44
And what's up with the json/data_json thing? Can't we have just one name for the thing? 19:47
dukeleto darbelo: see the long parrot-dev conversations about it 19:48
darbelo: some people decided that data languages should be prefixed with data_ and JSON in all caps causes some problems in the build chain on some platforms or some junk
darbelo: other people didn't like that but then nothing more happened 19:49
darbelo: patches welcome!
purl rumour has it patches welcome is ponies welcome or Set Objectives, Achieve Results! or swahili for "Put up or shut up."
19:53 bacek joined
diakopter in the realm of better (for parrot) news (perhaps), addir.pir is slightly faster than addit.cs on mono parrot.pastebin.com/d32e97340 I say "perhaps" because varargs_adder is coercing to double every time by stringifying each operand and parsing to double *every* time. 19:56
addit.pir I mean 19:57
C# operator + can work among double and int, but doesn't coerce from string to numeric, afaik. 19:58
Coke My solution? rip out json. 20:04
(I was kind of annoyed at the whole mess, as it seemd to work fine before the switch.) 20:05
not annoyed enough to undo it, though. 20:06
20:08 whiteknight joined, patspam joined 20:14 darbelo joined
whiteknight what's the status of the release? 20:15
nopaste "chromatic" at 72.87.39.97 pasted "bacek, this Continuation patch fixes some tests and breaks some others" (14 lines) at nopaste.snit.ch/19091 20:16
cotto_work whiteknight, it's been tagged
whiteknight cotto_work: awesome 20:17
Coke someone let me know when there's an ftp-able version. 20:22
dukeleto tag it and bag it 20:27
cotto_work can I frag it? 20:28
dukeleto cotto_work: only if you clean up after
cotto_work You're no fun anymore.
bacek chromatic, sorry, I will not have time to do any work on context_unify3 this morning. 20:31
chromatic, btw, can you revert r43065 please? 20:32
gerd Coke: the release in on the ftp-server I am still working on the website 20:35
dukeleto gerd++ 20:36
gerd: let us know if you need help with something
chromatic All of it, or the commit to src/call/args.c? 20:37
bacek src/call/args.c 20:41
purl src/call/args.c is reporting "17 unused assert macros" when run through t/codingstd/c_args_assert.t
Coke docs.parrot.org updated.
purl, forget src/call/args.c
purl Coke: I forgot src/call/args.c
Coke may take a day or so to get through the cache. 20:42
(accessible immediately as: docs.parrot.org/parrot/1.9.0/html/
dalek tracwiki: v8 | cotto++ | CottoTasklist 20:51
tracwiki: rearranging and cleanup
tracwiki: trac.parrot.org/parrot/wiki/CottoTa...ction=diff
Coke <the critic>Patch my code! Patch my code!Patch my code!Patch my code!</the critic> 20:58
dalek rrot: r43077 | chromatic++ | branches/context_unify3/src/call/args.c:
[PCC] Reverted mistaken change from r43065.
 20:59
darbelo Oh, we have a bsdlint target. 21:02
Too bad it uses options that this bsd's link doesn't support ;) 21:03
s/link/lint/
21:10 patspam joined
dalek rrot: r43078 | bacek++ | branches/context_unify3/src/ops/core.ops:
Revert "Remove setting caller_ctx in op get_params."
 21:15
bacek chromatic, get_params' setting of caller_ctx is wrong. I don't have time to fix it now... 21:17
$dayjob time 21:18
21:18 hercynium joined 21:23 joeri joined, joeri left 21:36 payload joined
dukeleto sure seems quiet in here 21:53
Coke AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGH 21:54
dukeleto that is much better
21:55 joeri joined
Tene TURNS THE VOLUME UP TO 11 21:55
Coke Tene: any chance to look at my various CONTROL issues? 21:57
Tene Coke: I think the gf is planning to go out tonight, so I might be able to. My life has been kind of falling apart lately. Could you send me email talking about all of it 21:59
?
Tene at allalone.org
dalek nxed: r267 | julian.notfound++ | trunk/ (2 files):
switch, break and some fixes in stage 1
 22:02
Tene Argh... the parrot Getopt::Obj is *almost* usable from HLLs, but it doesn't use the right namespaces.
.namespace ["Getopt::Obj"] instead of ['Getopt';'Obj']
darbelo Ouch. 22:03
Tene ><
NotFound Tene: yes, I was planing to ask about that in #ps one of this weeks.
But is usable from Winxed anyway ;)
darbelo Changing that to the right namespace would break code, right? 22:04
Tene This also means that any attempt to work around it is going to be a pain, because ["Getopt::Obj::Spec"] isn't actually nested.
chromatic Seems like a bugfix to me.
Tene Oh, maybe... if we just grab the namespaces and install them into the old names at :load time, it might work.
Coke (life falling apart) it's not that important. =-) 22:05
my problem, that is.
Tene Coke: I'd love to work on Parrot tonight.
Coke k.
NotFound Tene: I was thinking about trying that, but lacked the time.
darbelo I'm guessing that "::" was a valid namespace separator in the past. Right?
Tene darbelo: no. 22:06
darbelo: it's just a name that looks separated.
oh, I also need to fix the newclass stuff.
darbelo That's just silly code then.
Tene darbelo: ack 'namespace.*::' runtime/ 22:07
There's a lot of it.
NotFound Maybe the easy way is just to duplicate the code, deprecate the old, and delete it at the end of cycle,
Tene NotFound: it is arguable that some of those libraries should move out of parrot core...
chromatic Can we get a list of the afflicted libraries? 22:08
22:08 bacek joined
Tene All of SDL 22:08
Data::Dumper
purl Data::Dumper is written entirely in Perl, so it ought to work anywhere that Perl does! :-) or a good alternative to Storable. or or YAML for when you don't want my eyeballs poked with lots of {[ ]},s
moderator Parrot 1.9.0 released | parrot.org/ 22:08
Tene Getopt::Obj 22:08
NotFound Tene: my comment was only for GetOpt
chromatic No backwards compatibility concerns for SDL; patch away.
Coke Tene: done. 22:09
Tene Argh, can't, really need to get back to $realjob.
AFK
chromatic Anyone can do it!
Coke darbelo: (silly) that code predates the ability to have multi-part keys, mmkay?
chromatic ATTENTION ALL LURKERS: spread holiday cheer (unless you hate holidays, are not particularly cheerful, or have a mean boss watching over your shoulders now). 22:10
Coke BAH HUMBUG!
Coke queues up patrick stewart as scrooge to cheer for the ghosts.
22:12 he joined
darbelo Coke: Point taken. 22:12
purl Hey, give that back!
Coke AFK 22:18
dukeleto hearts Parrot Getopt::Obj 22:20
current dev release still points to ftp://ftp.parrot.org/pub/parrot/releases/devel/1.8.0/ 22:21
can someone fix www.parrot.org/release/developer and make the damn thing automatic or something? 22:22
dukeleto takes a breath
i am almost offended that SVK is still listed on parrot.org/download 22:23
but i guess people still use it, even though it has been end-of-lifed
chromatic It's still better than straight SVN, last time I tried straight SVN. 22:24
dukeleto chromatic: I guess I can't say, since I have never used SVK
NotFound They killed SVKenny? 22:25
chromatic I've used a few VCSs; SVK was one of the least annoying.
22:25 iblechbot joined, cbarrett joined
moritz when i tried to use SVK I wasn't up to the distributed model 22:26
I guess I'd handle it better now
chromatic Git is an improvement over SVK, but SVK was a huge improvement over SVN.
moritz mercurial also seems nice, though I haven't used it extensively yet
chromatic It was okay. It didn't bother me much, but I didn't do much with it. 22:27
It was definitely slower than Git the last time I used it, but that was a year ago.
moritz I think it still is
pmichaud speed is one of git's explicit goals
moritz but for the relatively small project I used it on (eigen, a linear algebra lib in C++) it was fine speed-wise 22:28
dukeleto pmichaud: hence the hand-tuned SHA1 code in assembly ;)
moritz they surely use that a lot :-) 22:30
tewk_ dukeleto, didn't know about hand-tuned assembly, I'll have to go look at that :) 22:31
PerlJam dukeleto: how come git isn't listed on parrot's download page? 22:32
Tene I tried to use SVK once. Read through some instructions, but I couldn't actually get it to do anything at all. 22:33
dukeleto PerlJam: because there is still push-back for supporting git and it is an un-official mirror. but if you wanted to add something about our un-official github mirror, that would be awesome 22:36
tewk_: block-sha1/sha1.c in the git repo is filled with asm 22:37
i have updated the URL redirects 22:41
japhb Coke, I've now got my account on blogs.perl.org, with first post already up: blogs.perl.org/users/geoffrey_broadwell/ ... can you add it to Planet Parrot, please? 22:42
dukeleto www.parrot.org/release/current and www.parrot.org/release/developer are now correct
darbelo japhb: ping 22:49
japhb darbelo, pong
darbelo Your name pops up in various of the data_json files, do you have any clues that might help fix crow.pir? 22:50
japhb darbelo, looking 22:51
darbelo TT #1326
japhb rebuilding parrot; will try to fix when that is done 22:53
darbelo japhb: No hurry, I'm not doing a release 'till January ;) 22:54
22:55 payload joined, kid51 joined
Coke japhb: what's the RSS feed? 23:01
purl i heard the RSS feed was doable
japhb Coke, lemme check
Coke I see no obvious links on the top level url. 23:02
japhb Hmmm, from the page source it looks like blogs.perl.org/users/geoffrey_broadwell/atom.xml
dalek tracwiki: v137 | gerd++ | WikiStart 23:03
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
Coke japhb: done. 23:04
good luck on this one. =-)
japhb Coke: thanks!
Coke I didn't see a previous entry for you.
so, no clue what happened.
japhb huh.
Maybe it got deleted when it was filled with FAIL 23:05
Coke checks svn repo.
japhb will chuckle ruefully if the old feed was just *never added*
Coke hurm.
it does look like that's possible. :|
my apologies for any angst.
japhb ... which might be because there were problems with u.p.o feeds, so no one bothered. 23:06
Not a big deal.
purl not a big deal is relative
Coke nah, those work.
"worked", anyway.
japhb What's the url for PP anyway? 'planet.parrot.org' doesn't work 23:07
Coke parrotcode 23:08
purl parrotcode is in the same cvs are parrot or editable by coke, chromatic and allison
dalek website: gerd++ | Parrot 1.9.0, "Blue-fronted Amazon" Released!
website: www.parrot.org/news/2009/Parrot-1.9.0
Coke ... do we actually have sponsors atm?
not organizationally, anyway. 23:09
japhb Ah, OK, got it
I'm not listed in the Subscriptions list
Coke ISTR when it worked, it took a while to refresh.
japhb k
Coke so, check in an hour, a day, and then complain to me.
japhb will do
Coke (or just email ask and cc me.)
japhb :-)
Coke I'm going to remove Chip and Leo; Anyone see an issue with that? 23:10
japhb not I
Coke Done. 23:13
afk 23:19

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!