Parrot 2.4.0 "Sulfur Crest" Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere | Priorities: fix io_ops mess in corevm/coretest, review and update documentation before release
Set by moderator on 8 June 2010.
Coke returns, having missed ps 00:01
cotto_work same for r47496
"returns stats as required by enum which" isn't entirely helpful
dalek rrot: r47494 | NotFound++ | trunk (2 files):
some more functionality in ByteBuffer
 00:02
rrot: r47495 | mikehh++ | branches/gc_massacre/src/gc/gc_ms2.c:
add missing documentation
rrot: r47496 | mikehh++ | branches/gc_massacre/src/gc/gc_ms.c:
add missing documentation
rrot: r47497 | NotFound++ | trunk/src/pmc/bytebuffer.pmc:
drop const that upset some compiler
kudo: 4ae2183 | jonathan++ | src/core/Cool-str.pm:
Fix dodgy split signatures.
kudo: 4578afc | jonathan++ | src/pmc/ (8 files):
Apply patch from cognominal++ to remove now unrequired need_ext from our PMCs.
kudo: 5e6fa97 | jonathan++ | src/metamodel/ClassHOW.pir:
Add a (most likely accidentally) missing :load, which gets perl6.pbc loadable
mikehh cotto_work: yeah I see your point - was just trying to fix codetest failures - let me think about it 00:04
cotto_work which I appreciate, btw
bacek_at_work aloha 00:11
whiteknight hello bacek_at_work 00:12
cotto_work aloha, bacek_at_work
Coke bacek_at_work: hio 00:13
mikehh bacek_at_work: hi
purl hola, mikehh.
cotto_work waits for a combinatorical explosion 00:15
davidfetter powerset(boom!) 00:17
00:42 cotto_work joined 00:56 abqar joined
dalek rrot: r47498 | NotFound++ | trunk (2 files):
ByteBuffer set_integer_keyed_int
 01:08
rrot: r47499 | NotFound++ | trunk/src/pmc/bytebuffer.pmc:
empty lines after =item
bacek_at_work NotFound, we need byte-level granularity of data in ByteBuffer. Not "word" level. 01:20
cotto_work I was thinking that too 01:21
use the lowest byte of value and throw an exception if it's >255 01:22
or <0
which looks not unlike an ice cream cone to me 01:23
chromatic Or a sideways fire flower!
cotto_work I suppose that also brings endianness into the mix. Whee. 01:27
Coke has anyone opened a TT on the dynop loading order issue? 01:47
(someone in rakudo land is tripping over it, want to give him a ticket reference. I don't see one...)
chromatic I thought we had one, courtesy of duke. 01:48
Coke doesn't look like it. 01:50
probably ended up mailing list only. 01:51
bacek_at_work trac.parrot.org/parrot/ticket/1663
?
Coke ah, fperrad. 01:52
cotto_work dynops ticket is trac.parrot.org/parrot/ticket/1663 01:55
dynops ticket?
purl dynops ticket is trac.parrot.org/parrot/ticket/1663
cotto ohai 02:11
02:16 TiMBuS joined 02:20 szabgabx__ joined 02:34 tcurtis joined 02:47 gbacon joined 02:48 janus joined 03:04 plobsing joined 03:23 LoganLK joined 03:32 JimmyZ joined 03:35 mikehh joined 04:13 fperrad joined 04:14 fperrad_ joined
dalek rrot: r47500 | jimmy++ | trunk/src (2 files):
random consting
 04:26
rrot: r47501 | tcurtis++ | branches/gsoc_past_optimization (4 files):
Add .match and .transform methods to PAST::Node when PAST/Pattern.pbc is loaded.
tcurtis That commit message is inaccurate. Be prepared for abuse of tools/dev/mk_manifest_and_skip.pl in a moment. 04:28
04:42 Khisanth joined
dalek rrot: r47502 | tcurtis++ | branches/gsoc_past_optimization/MANIFEST:
regen manifest. Also, the previous commit was inaccurate. .match and .subst methods are added to PAST::Node.
 04:43
TT #474 closed by jimmy++: [PATCH] improved parrot.spec for SUSE 04:44
TT #474: trac.parrot.org/parrot/ticket/474
05:30 snarkyboojum joined 05:44 Essobi joined 05:56 snarkyboojum joined 06:03 uniejo joined
Coke who is gp aaaat zimt.uni-siegen.de ? 06:18
cotto is he sending stuff to parrot-dev? 06:19
06:19 uniejo joined
Coke trying to join -members. 06:20
dalek rrot: r47503 | tcurtis++ | branches/gsoc_past_optimization (5 files):
Make codetest happy and more importantly implement global matching.
 06:21
moritz Coke: zimt.uni-siegen.de sounds like gerd 06:25
cotto he has a different address listed in CREDITS though 06:27
same school apparently
moritz gp = gerd pokorra maybe? 06:28
cotto plausble
plausible
purl, gerd?
purl gerd is gastroesophageal reflux disease (or something that makes you want to vomit, c.f. the Perl debugger internals) or Gerd Pokorra
cotto I guess I don't get to complain about "cotto" being a kind of salami. 06:29
06:31 he joined
Coke seen drforr? 06:45
purl drforr was last seen on #perl 6 hours, 10 minutes and 59 seconds ago, saying: purl, paste enema 06:47
07:23 baest joined 07:44 cognominal joined
mikehh NotFound: ping 08:10
08:12 ttbot joined
dalek rrot: r47504 | plobsing++ | branches/dynop_mapping:
creating branch to deal with dynop opnum mapping issues
 08:32
mikehh plobsing: ping 08:33
plobsing mikehh: pong 08:34
dalek TT #1676 created by mikehh++: t/pmc/io.t fails make corevm/make coretest 08:35
TT #1676: trac.parrot.org/parrot/ticket/1676
mikehh plobsing: I just created a ticket for the remaining coretest failures - TT #1676
plobsing: but also test 1 in t/pmc/io.t is still failing TODOed - NotFound++ fixed the relevant TT #1659 in other tests 08:37
08:37 gbacon joined, clinton joined
plobsing mikehh: timely destruct untodoed at r47506. 08:40
the other tests are all "$x (ops)" clones of other tests and should move to dynops testing
08:41 ingy joined
plobsing I'll do that in the morning. Now, I sleep. 08:41
mikehh plobsing: yes - 'night to you
dalek rrot: r47505 | plobsing++ | branches/dynop_mapping (2 files):
implement bytecode packing/unpacking code to support per-segment mappings
 08:48
rrot: r47506 | plobsing++ | trunk/t/pmc/io.t:
avoid use of open op in timely destruction test
09:22 sorear joined 10:22 ambs joined 10:24 gerd joined
moderator Parrot 2.5.0 release time is on 15th at 12:00 UTC | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere | Priorities: fix io_ops mess in corevm/coretest, review and update documentation before release 10:37
10:39 aukjan joined
dalek rrot: r47507 | mikehh++ | trunk/MANIFEST.generated:
add entries to MANIFEST.generated
 11:00
mikehh make corevm/make coretest - t/pmc/io.t - Failed tests: 25, 27, 29, 31 11:18
all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#34275), fulltest) at r47507 - Ubuntu 10.04 amd64 (g++)
t/op/annotate-old.t - TODO passed: 1 in testf
dalek rrot: r47508 | mikehh++ | trunk/t/op/annotate-old.t:
remove TODOed test in testf which now passes
 11:33
11:37 whiteknight joined
whiteknight good morning, #parrot 11:41
mikehh hi there whiteknight 11:44
whiteknight hello mikehh. how are you today? 11:47
mikehh whiteknight: passable, even tending to fine, and you 11:48
just testin' and a couple of fixes 11:49
whiteknight I am doing well, though tired. The kid hasn't been sleeping well because he's teething 11:50
and the parents only sleep as well as the kid
mikehh oh dear, I know what you mean, I think I have passed that though, my grandkids are now 8, going on 9, although I still help looking after them, passed the teething bit 11:52
whiteknight yeah, I'm enheartened by the light at the end of the tunnel 11:54
11:54 gbacon joined
mikehh it's a learning experience, ever changing 11:54
bacek whiteknight, In Soviet Russia generations of people did live waiting for light at the end of the tunnel. 12:02
Apparently, it was incoming train.
jnthn In Soviet Russia, the light at the end of the tunnel doesn't wait for you. 12:04
bacek jnthn, ŠæрŠøŠ²ŠµŃ‚ :)
12:05 JimmyZ joined
jnthn ŠŸŃ€ŠøŠ²ŠµŃ‚ :) 12:06
bacek jnthn, how is preparations for trip to Kiev going? 12:08
There is some buzz in Russian blogosphere about having "read Rakudo developer" at "Perl Mova" happening :) 12:09
jnthn Little behind on slide writing.
Ooh. :-)
jnthn is looking forward to being in Kiev again.
In summer too. Only went in winter before.
mikehh got to go out for a bit - bbl 12:11
bacek jnthn, Kiev is much nicer in Summer.
But it was about 20 years ago, when I visited Kiev... 12:13
...shi^W sigh. 12:14
jnthn imagines it's changed in various ways since 20 years ago. 12:15
bacek Slightly :)
whiteknight just a wee bit 12:21
jnthn I imagine ŠœŠ°Š¹Š“Š°Š½ ŠŠµŠ·Š°Š»ŠµŠ¶Š½Š¾ŃŃ‚Ń– wasn't called that 20 years ago. 12:22
12:29 tetragon joined
dalek kudo: f7ddcf5 | moritz++ | (3 files):
try to actually run MAIN subs; most code by patrickas++
 12:29
kudo: b0d427b | moritz++ | src/ (2 files):
second attempt at MAIN sub
kudo: 3657ad7 | moritz++ | src/Perl6/Actions.pm:
add TODO comment wrt MAIN sub
kudo: c77e278 | moritz++ | src/ (2 files):
check for eval()ness by walking the call chain
kudo: d33a958 | moritz++ | src/glue/run.pir:
IN_EVAL needs to count the number of eval()s, since there is always one in the
kudo: 9f05efa | moritz++ | src/glue/run.pir:
exit early in MAIN_HELPER
kudo: 11366ab | moritz++ | src/glue/run.pir:
make IN_EVAL more robust, with input from jnthn++
kudo: a546773 | moritz++ | (4 files):
Merge branch 'MAIN'
whiteknight is there a release date scheduled for rakudo star? 12:38
I'm sure I've heard one before, but I can't remember
particle ~june 22 12:39
whiteknight ok, good
12:44 JimmyZ_ joined 13:01 gbacon joined
Coke midway through yapc? not bad. =-) 13:03
by the time folks can check patrick's slides...
jnthn, bacek: do you get russian spam? (I'm wondering if i get it because of my sur/domain name.) 13:04
particle the release will be held until there's something good to release, so it's not a hard date 13:07
13:14 atrodo joined 13:16 aukjan joined
jnthn Coke: Yes, but I don't mind it too much in that it keeps my ability to read Cyrillic alive. ;-) 13:17
dalek rrot: r47509 | NotFound++ | trunk (2 files):
ByteBuffer methods to get the content as string with the charset and encoding specified
 13:29
NotFound mikehh: pong 13:42
dalek rrot: r47510 | NotFound++ | trunk/t/pmc/bytebuffer.t:
ByteBuffer test for set with negative index, and force usage of the mark vtable function
 13:45
mikehh NotFound: sorted it out with plobsing++ 13:48
NotFound k
13:49 ash_ joined 13:54 hudnix joined
ash_ the llvm people came out with a new lldb, so debugging the llvm should become a lot easier soon, i know that was a complaint from the unladen swallow people when they used the llvm 14:03
whiteknight ash_: I saw that 14:04
and it's library-based, so maybe we could create our own specialized debugging tools with it
14:05 plobsing joined 14:10 ash__ joined
ash__ sorry whiteknight 14:11
14:11 Andy joined
ash__ lost connection 14:11
whiteknight it's okay, I forgive you 14:12
:)
ash_ i didn't know it was library based, thats cool 14:13
14:16 gbacon joined
ash_ downloading lldb now 14:17
i hope it makes it to other platforms
some of the open source things Apple has done don't get much attention outside of apple 14:18
like AutoZone the gc system 14:19
thats a pretty impressive gc
autozone is the gc system used in objective c 2.0 14:22
whiteknight I wonder if we could borrow that for parrot?
ash_ www.opensource.apple.com/source/libauto/ if your interested 14:23
its under an apache license, they use it in the objetive-c runtime on OS X and macruby uses it, i don't know what they use on the iphone though,
i gotta take my girlfrend to class, brb & 14:24
atrodo Were they trying to invoke the thought of cheap auto parts? Because that's the only thing I can think of
whiteknight this is a pretty impressive-looking GC 14:26
the hashing algorithm they use looks decent too, though I would want to see more info on it 14:28
all tests pass on linux x86 clang with and without --optimize 14:31
atrodo Have you found any documentation on the specifics of how it works? 14:32
14:33 kevinshaum joined
whiteknight nope 14:34
atrodo shucks. I hate it when people make cool code and don't explain how it works
whiteknight me too. Hate that a lot
dalek rrot: r47511 | plobsing++ | trunk (3 files):
[coretest] move old ops tests to dynops test
 14:35
14:35 bubaflub joined, Chandn joined 14:42 patspam joined
ash_ back 14:43
yeah, autozone seems neat, but its kinda a black box
whiteknight yeah, there isn't a lot of documentation, but the code I've seen so far is pretty easy to interpret 14:44
and it helps that it's written in C++ and not Objective-C
ash_ yeah
Searching their developer's site doesn't give anymore documentation either, so you know 14:46
www.opensource.apple.com/source/lib...E.html?txt might be helpful
(they apparently removed that readme in later version, the one marked libauto-141 and libauto-141.1 14:47
)
libauto-77.1 is from OS X 10.5, libauto-141 was for snow leopard, and 141.1 was an update for 10.6.2, so you know 14:49
atrodo The readme wasn't real informative of a lot of the how 14:51
main thing I noticed was it's not compacting and it runs in it's own thread
whiteknight readmes never are
dalek rrot: r47512 | NotFound++ | trunk (2 files):
avoid excesive reallocations when grown a ByteBuffer byte by byte, add a test to exercise that, and fixes a cast
ash_ i thought it might be neat, maybe after GSoC is over, to look into using libauto on OS X so you can call Obj-C directly and share objects between parrot and the obj-c runtime, like macruby does, it might be neat to use parrot for gui stuff on OS X eventually 14:54
dukeleto 'ello 15:06
NotFound ByteBuffer reviews wanted. 15:08
15:17 Hunger- joined, gbacon joined, wagle_ joined, japhb joined
Chandon Didn't netsplits go out of style at some point? 15:18
Like parachute pants...
atrodo I would have thought so
particle yes, about the time irc went out of style
15:19 whiteknight joined, he joined, arnsholt joined, purl joined, athomason joined, NotFound joined
whiteknight NotFound: I've been following your ByteBuffer, it looks nice. Definitely a few features I want to add to it 15:19
but nothing urgent 15:20
15:22 preflex joined, lucian joined, dukeleto joined 15:27 theory joined
jnthn NotFound: Does it copy a Parrot string that you want to look at the bytes of? 15:27
er, does it *always* copy...
...or only lazily if you modify something?
15:29 Andy_ joined
NotFound jnthn: lazily 15:29
jnthn \\o/ 15:30
NotFound++
NotFound I had no intention to do it that way initially, but looked at the rakudo version and changed my mind. 15:32
jnthn Makes me glad I bothered. :-) 15:33
ash_ in the makefile if you have a few lines of something you want to include or not include can you do that? in the config/gen/makefiles/root.in 15:44
15:44 khairul joined
ash_ i think i found a solution, nevermind 15:45
whiteknight All tests pass, linux x86 with clang 1.1, gcc 4.4, g++ 4.4, icc 11.1 with and without --optimize 15:46
(/me wrote a script, watched it for hours)
purl msg allison if you have a moment, I would really like to see a copy of portal.acm.org/citation.cfm?id=5648...N=74201017 15:48
purl Message for allison stored.
ash_ whiteknight: clang 2.0 is out (also there was a 1.5 in there too) 15:58
16:11 whiteknight_ joined 16:12 davidfetter joined 16:14 Themeruta joined 16:18 gbacon joined 16:26 theory joined
ash_ can you use the gdb with parrot for debugging pmcs? 16:37
Coke s/for debugging pmcs// sure. 16:38
that is, in general it works. pmcs are rough because of all the #line and #file directives. 16:39
If i'm trying to debug something hairy there, I tend to strip all that out of the .c file, rebuild, and then debug the /c/, not the /pmc/
purl Hmm. No matches for that, Coke.
whiteknight I still can't figure out why we have all those bullshit #line and #file directives when they cause so much trouble 16:42
and the --no-line-directives option to configure.pl doesn't work to strip them out 16:43
ash_ hmm, i am just adding a punch of printf's but i might do what you said Coke 16:45
i don't like just adding printf's but sometimes its hard to get around that 16:46
whiteknight ash_: I was using the ubuntu package, which is why I have LLVM2.7/Clang1.1 16:48
it's much easier doing it that way than it is to build the damn thing from source 16:49
ash_ yeah, makes sense, i mostly have the newer clang because they added a bunch of C++ support i wanted to try 16:50
it can build boost now, so thats pretty impressive
whiteknight ash_: Is there like a webpage or something that talks about the 2.0 release? 16:51
I find this damn llvm.org website so difficult to navigate sometimes
ash_ not yet, they don't have a tag for it yet, its kinda the current development release, but they had a blog post about it and some some posts in the dev mailing list, i am using trunk llvm r104365, and trunk clang r104336, built with cmake, its pretty nice, i like clangs error messages way better than the gcc 16:55
whiteknight agreed. The error messages are much much nicer 16:56
clang is my default compiler of choice now
ash_ those revisions work together and are pretty stable, and can build boost, but you can try just the most recent trunk of both llvm and clang but i have had hit or miss experiences with using the full trunk, sometimes they work fine and sometimes i cant even compile them 16:58
whiteknight I don't really need the C++ support, so I may just stick with 1.1 for now 17:00
ash_ llvm 2.8 should come with 2.0 clang 17:04
they are on a 3 month release schedule and 2.7 came out in April, so the next release will be in late July or early August
whiteknight okay, that's good 17:06
I like updating to fixed releases
ash_ can you say printf("%s", foo); where foo is: STRING foo; ? 17:24
NotFound ash_: use "s" and parrot io functions. 17:26
"%Ss"
ash_ are there a list of the parrot io functions somewhere? or a header? 17:27
NotFound include/parrot/io.h 17:29
And some in include/parrot/extend.h
ash_ cool, thanks, that hels 17:31
helps*
17:35 aukjan joined
ash_ i keep getting a seg fault with something i added but when i try to run it with the gdb i get a different error, its complaining it can't find a pbc 17:42
in the gdb
NotFound ash_: use gdb with a dumped core. 17:43
ash_ make 17:45
oops, wrong window
purl sudo rm -rf /
18:14 tcurtis joined 18:32 hercynium joined 18:40 theory joined
dalek rrot: r47513 | NotFound++ | trunk (2 files):
ByteBuffer get_iter using an ArrayIterator
 18:41
Coke spent his lunch hour trying to figure out what is eating the CONTROL_RETURN. 18:44
atrodo Any luck? 18:45
Coke the only thing in the chain that looks likely is /compilers/pct/src/PCT/HLLCompiler.pir
18:45 ambs joined
Coke er, I mean ../PAST/Compiler.pir; whoops. 18:46
18:46 wagle joined
Coke AIGH. I am no longer sure what I mean. moment. 18:46
ah, I do mean compiler.pir, and it looks like it was a recent change. one of my dev boxes hadn't been updated so it looked different. 18:47
allison purl message whiteknight paper emailed 18:56
purl Message for whiteknight stored.
18:56 wagle joined
Coke allison: Dunno if you want to touch it again, but there's a ticket for 'aftermath of TT #389' with your name on it. =-) 18:57
whiteknight allison++ 19:00
Coke atrodo: giving up trying to follow the path of the code now and just bisecting. it's easier. :P 19:03
dalek TT #1675 closed by dukeleto++: Cannot load perl6.pbc from PIR 19:04
TT #1675: trac.parrot.org/parrot/ticket/1675
atrodo :D It's a sad when bisect is easier 19:05
19:09 cognomore joined 19:15 szabgabx joined
GeJ Bonjour everybody. 19:30
davidfetter hi GeJ 19:32
tcurtis Bonjour, GeJ. 19:33
Tene I disagree. It's great when we can have tools do work for us.
Coke I'm very glad there is a tool for this. it is sad that I cannot suss out what's going on. =-) 19:39
ooh, looks like it might be bacek... 19:44
... or moritz. 19:48
moritz hm?
moritz feels hilighted
what did I break?
Coke it would be nice if "update ext/nqp-rx" had some pointer back to the source. 19:49
cotto_work you may have broken something and made coke crabby
Coke moritz: can you show me what in nqp-rx was captured in r46901?
19:49 tcurtis joined
Coke DING. it was 46901 that broke partcl-nqp. 19:50
moritz: this is the failure where catch { return } started saying that return was just doing a parrot .return() instead of throwing a CONTROL_RETURN exception.
moritz Coke: seems it was the regex interpolation stuff by bkeeler++, which was later on revised by pmichaud++ 19:51
oh wait, no
allison Coke: i can look at 389 aftermath, is there a separate number for the ticket? 19:52
pmichaud looks at 46901
moritz Coke: cd src/nqp-rx; git log # then search for b228f8ff29919b90c10c883d4922973b3679dea7
Coke allison: yup.
moritz Coke: and the changes below that went into that bootstrap update
(contains changes to HLL::Compiler.eval(), autoprint hooks..) 19:53
Coke allison: TT#1672
catch uses .eval(), so that's suspicious. =-) 19:54
allison Coke: thanks! 19:55
Coke pmichaud, moritz: I wonder if it would be nice to have each sub show the original HLL (in this case, NQP) source in a comment before it. 19:57
allison Coke: that is certainly odd, since unmarked subs should be stored in the namespace
Coke: it's only methods and vtables that get the special treatment 19:58
Coke allison: no, only subs marked with :nsentry are stored, yes?
moritz Coke: to the extend where it's possible (nqp and perl6 subs are compiled into several .pir subs, in general) yes
Coke I'm pretty sure namespace just checks for isa sub.
allison Coke: if a sub is marked with :method or :vtable, then yes it needs :nsentry
Coke: but if it's unmarked, it should be stored as a sub 19:59
Coke: so, absolutely, certainly a bug
Coke allison: yes, but this isn't a pir .sub =-)
so there's no marking at all.
allison Coke: yah, but it's a Sub PMC, which is all the code cares about
Coke: (it doesn't actually have any way of telling if the sub was created from a .sub or directly) 20:00
TimToady phoan
Coke allison: trac.parrot.org/parrot/browser/trun...e.pmc#L160
allison: right. but there's no way to mark a new 'Sub' with :nsentry.
allison Coke: will look more after call 20:01
20:01 ambs joined
Coke TimToady, allison: I have nothing really sixy this week (again). will bail. 20:02
pmichaud: ah. def10fd60c43741c13d6de45b7386568922c412f made 'eval' an NQP method. 20:03
allison Coke: also look at line 139
dalek rrot: r47514 | tcurtis++ | branches/gsoc_past_optimization (7 files):
PAST::Pattern.transform(PAST::Node, invokable) implemented and partially tested!
20:03 Psyche^ joined
moritz tcurtis++ # looks like good progress 20:03
allison Coke: that's checking if the sub is a vtable entry
Coke ok. so there's no handling in there for just a straight :sub ? 20:04
er, .sub
?
20:05 theory joined
pmichaud Coke: so, what is the return exception issue you're seeing? 20:08
Coke pmichaud: the code in eval() is throwing a CONTROL_RETURN. the try block outside the eval() never sees it. 20:09
if eval is now an NQP sub/method where it was not before, that might explain it. 20:10
pmichaud Coke: this is HLL::Compiler's eval() that is throwing the CONTROL_RETURN?
allison Coke: no special handling, it falls down past line 388, gets checked for NCI and multi, then gets stored as an ordinary entry
Coke: but, there must be something going wrong in the logic, since it's not getting stored
Coke pmichaud: partcl-nqp's catch calls partcl compiler's eval calls nqp's eval calls pct's hllcompiler's compile calls past compiler. I think. 20:11
pmichaud checking 20:12
20:12 estrabd joined
Coke the partcl code is puts "Got [catch return], should be 2" 20:12
-> "Got 0, should be 2" # the CONTROL_RETURN exception is gone, so it looks like a normal exit. (TCL_OK, or just .return()) 20:13
If that's it, it's probably fixable by moving forward on the elimination of CONTROL_RETURN from NQP that you discussed. 20:14
pmichaud I'm guessing that perhaps HLL::Compiler.eval() shouldn't catch any exceptions.
Coke that would be fine.
pmichaud ohhhh, I see what's happening.
Coke \\o/ 20:16
wozzit?
<- in suspenders. 20:18
tcurtis pmichaud++ and bacek++ for NQP multis. They made writing the PAST::Transformer subclass for the .transform method on PAST::Patterns much more pleasant.
cotto_work nice. I should update opsc to use those. 20:19
no more need for "poor man's multi" now 20:20
whiteknight nqp has multis now?
cotto_work yes indeed
check out tcurtis' latest commit 20:21
pmichaud Coke: (sorry, was on phone) 20:22
yes, since eval() was moved to be written in NQP, it now has a return handler (as all NQP subs do). So, the real problem is a lack of a true lexical return. 20:23
Coke is it possible to temporarily avoid the issue by making that not a method but an anonymous block? 20:24
cotto_work ooc, would it be worth adding a restrict macro to Parrot?
pmichaud Coke: it has to be a method to be invokable by a method call. (Or perhaps I'm misunderstanding)
the other potential issue is that the exception type numbers changed with my recent patch for parrot's 'exit' opcode.
Coke nope. wasn't sure if the trick we used to write [return] in partcl would be applicable here. 20:25
darbelo Oh crap. The headerizer isn't working on windows for some reason.
dalek nxed: r493 | julian.notfound++ | trunk/winxedst0.cpp:
pirops in stage 0
pmichaud so the part of partcl-nqp that says
# XXX using numeric type ids is fragile.
# XXX using numeric type ids is fragile.
Coke pmichaud: didn't impact any of the #'s I am relying on, I think.
pmichaud is especially true at this point.
It definitely affected CONTROL_LOOP_LAST and CONTROL_LOOP_NEXT, I think.
Coke and yes, I double checked when I saw that one had been added. =-)
pmichaud one possible "workaround" would be to have partcl-nqp throw an exception type other than CONTROL_RETURN 20:26
(I agree, that's a hacky workaround)
Coke So, what's the fix? How can you make a method that doesn't have any handlers?
I can do that as a stopgap until the pct change to avoid _return altogether. 20:27
pmichaud well, nqp change, but yes.
because it's not just eval that may catch the return exception, but any subs and/or methods that it calls.
the version of partcl-nqp that I'm seeing now has: 20:29
} elsif $parrot_type == 65 { # CONTROL_LOOP_LAST
but runtime/parrot/include/except_types.pasm says
.macro_const CONTROL_LOOP_LAST 66
(doesn't affect _this_ problem, but it's definitely a mismatch) 20:30
eventually nqp will support pasm::except_types::CONTROL_LOOP_LAST to avoid this issue :-)
Coke if I change CONTROL_RETURN to <some random #> my simple test that was failing works. but everything else fails. 20:34
so I'll have to look at that when time permits.
*sigh*
pmichaud oh, yeah
<some random #> is going to make it look like a non-control exception
*sigh*
so then the CATCH block would get it. 20:35
Coke that's just an issue in [catch], I got that.
pmichaud are there other CATCH blocks getting in the way?
Coke so I'll have to look at that when time permits. 20:36
pmichaud okay.
Coke I do so not enjoy it when all my parrot hacking time is spent in this fashion. (and it's not just this particular nqp issue, in case you feel singled out, pmichaud . =-) 20:41
pmichaud I don't. :-)
PerlJam Coke: it's all the other NQP issues too? ;>
Coke it's just not fun anymore. Ah well. 20:42
-Ocrap ! 20:43
atrodo Is that an optimizing flag to add or remove crap? 20:44
Coke see also -Ofun
dalek nxed: r494 | julian.notfound++ | trunk/winxedst (2 files):
fix pirop statement and use getstd... ops instead of the interp stdhandle method
 20:49
21:30 hercynium joined
dalek nxed: r495 | julian.notfound++ | trunk/winxedst1.winxed:
special case for assign indexed expr to identifier to generate the apprpiate
 21:32
rrot: r47515 | tcurtis++ | branches/gsoc_past_optimization/runtime/parrot/library/PAST (4 files):
Add and update POD docs.
 21:41
21:46 kevinshaum left
cotto_work NotFound, ping 21:46
nopaste "cotto" at 192.168.1.3 pasted "potential surprise when using ByteBuffer" (38 lines) at nopaste.snit.ch/21119
cotto_work NotFound: ^ 21:47
NotFound cotto_work: pong
Mmmm 21:48
cotto_work It's easy to see why that happens but it has the potential to catch people by surprise.
NotFound cotto_work: I fail to see what is supposed to do 21:49
cotto_work The naive expectation would be that it'd put 123 into every byte in the buffer 21:50
NotFound cotto_work: that 'i = 0' shouldn't be i = size ?
cotto_work yes. I'm stupid.
though that gives non-deterministic results 21:51
nopaste "cotto" at 192.168.1.3 pasted "potential surprise when using ByteBuffer" (38 lines) at nopaste.snit.ch/21120
cotto_work ignore that
tcurtis Are there any emacs users here who know how to get cperl-mode not to interpret the rest of a NQP source file after "=begin foo" as being a comment? 21:52
NotFound cotto_work: I was wondering if getting a byte out of boudns should throw instead of returning 0.
cotto_work That'd make errors easier to detect.
+1 21:53
purl 1
tcurtis cotto_work: I'm not seeing anywhere in your paste where you jump back to start.
NotFound cotto_work: I'll look at it tomorrow, now is late for me. 21:54
cotto_work srsly. I need to check my code more carefully.
tcurtis++
cotto--
NotFound cotto_work: like all the people in the world :D 21:55
People that code, that's it.
cotto_work it behaves as expected when I fix my code.
dalek rrot: r47516 | mikehh++ | trunk/t/dynoplibs/io-old.t:
add svn properties
 21:58
rrot: r47517 | mikehh++ | trunk/src/pmc/bytebuffer.pmc:
add missing ASSERT_ARGS
cotto_work . o 0 (Where's irl ctrl-z when I need it?)
dalek nxed: r496 | julian.notfound++ | trunk/winxedst0.cpp:
special case for assign indexed expr to identifier to generate the apprpiate
 22:01
nopaste "cotto" at 192.168.1.3 pasted "what I should have nopasted in the first place" (40 lines) at nopaste.snit.ch/21121
22:04 lucian_ joined
ash_ if you have a pointer to a type, is it bad practice for the pointer to point to more than 1 of the type? like int *a = malloc(sizeof(int) * 2); or should that be a int **a? 22:05
NotFound ash_: is common practice in C. 22:06
dalek nxed: r497 | julian.notfound++ | trunk/winxedst0.cpp:
stage 0 lacked the predef ord, fixed
nxed: r498 | julian.notfound++ | trunk/winxedst1.winxed:
codingstd: a hard tab
NotFound ash_: you can also use calloc for more clarity.
ash_ thats true, i should probably do calloc 22:07
darbelo int **a would be a pointer to a pointer to an int, not a pointer to two ints.
ash_ darbelo: i know, i think i am being stupid with my pointers 22:08
darbelo Generally, in c, pointers and arrays are equivalent in most cases. 22:09
NotFound Specially when you alloc it. 22:10
ash_ so... if I have say: int *a; and I want foo to make a be an array of ints with the values 2, 3 or w/e; would the signature for foo need to be: void foo(int **);? or just void foo(int *); 22:12
darbelo Dammit. Oversquashed the commits.
dalek rrot: r47518 | darbelo++ | branches/gsoc_nfg/src/string (3 files):
Cleanup and headerize
 22:14
darbelo int arr[2] = {2, 3}; /* arr is a pointer to int */ 22:15
NotFound ash_: to access the array content you just need a pointer. If you want to be able to modify 'a', a pointer to pointer. 22:16
tcurtis ash_: are you wanting to pass in a pointer to the address where you want the result to be stored? like "int arr[2]; foo(arr);" Or do you want to do "int *arr; foo(&arr);"?
ash_ well i was trying to simplify my example a bit... 22:17
cotto_work NotFound, should I add a TODO test corresponding to the (fixed) nopaste?
ash_ i could point to where its not working, but that would probably not help much, i just think my pointers are not pointing to the right things 22:18
NotFound cotto_work: TODO what, throwing when out of bound?
darbelo Pointers rarely point to the right thing. It's part of the fun with C.
cotto_work no, the inconsistency between byte-level addressing word-sized r/w 22:19
ash_ i think somewhere i am making my pointer point to a stack variable thats disappearing later in the program, thats why i am getting a seg fault, but i'll see
cotto_work s/word/INTVAL/ 22:20
NotFound cotto_work: There is no word-sized r/w
INTVAL is used just because that's the vtable wants.
ash_ i didn't have any problems before i was using a void*, but the pmc's need those i thing? or can i have a pmc attr thats not parrot type? 22:22
bacek aloha, humans 22:23
cotto_work aloha, bacek 22:24
NotFound cotto_work: This nopaste? nopaste.snit.ch/21121
bacek NotFound, consider adding .push_byte/.shift_byte/etc METHODs. Than we can use vtable to migrate freeze/thaw to ByteBuffer.
cotto_work NotFound: yes 22:25
bacek, wouldn't METHODs be slow? 22:26
NotFound cotto_work: Are you too tired? 22:27
bacek cotto_work, yes. But do we need extreme performance in this case?
cotto_work Just ignore me.
I'll start saying things tomorrow.
NotFound cotto_work: if i >= size ... looks wrong. 22:28
22:28 kid51 joined
NotFound bacek: we are near the release, I'm implementing the functionality intender for the encode/decode purpose and less prone to break things ;) 22:30
dalek rrot: r47519 | tcurtis++ | branches/gsoc_past_optimization (3 files):
Add support for PAST::VarList in PAST::Walker::Dynamic.
 22:31
rrot: r47520 | darbelo++ | branches/gsoc_nfg/src/string/api.c:
Better handling of NULL grapheme tables in concatenation.
rrot: r47521 | tcurtis++ | branches/gsoc_past_optimization/runtime/parrot/library/PAST/Transformer/Dynamic.pir:
Add support for PAST::VarList to PAST::Transformer::Dynamic.
bacek NotFound, yes. But if people will start using vtables to access bytes we will not able to move freeze/thaw to ByteBuffer at all...
NotFound bacek: I don't see the problem. 22:32
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#34293), fulltest) at r47517 - Ubuntu 10.04 amd64 (g++)
bacek NotFound, we do need fast way of iterating ByteBuffer by "words" for freeze/thaw. VTABLEs are fastest way. But we use them for "bytes" 22:33
NotFound bacek: giving that its name is ByteBuffer, no wonder.
mikehh that's the first time I can report that for trunk since r46932 22:34
NotFound s/giving/given 22:35
bacek "Byte" is just half of it. "Buffer" can be universal from storage/access view. 22:36
mikehh kid51: I get all tests passing now - how about you?
NotFound bacek: I think that for INTVAL access we already have ResizableIntegerArray 22:38
bacek NotFound, it's too high level. There is no way to shift u16 from RIA on 64-bits platform. 22:39
Which means we can't use it for freeze/thaw. 22:40
uint16_t
kid51 mikehh: Am running tests on 2 OSes right now. Will post within the hour. 22:41
mikehh kid51: great - hoping we're ok for the release now 22:42
bacek anyway, $dayjob time 22:43
NotFound bacek: If we need a specialized PMC for such complex need better to crate one than complicate and unoptimize the main purpose of ByteBuffer
dalek kudo: f50c359 | jonathan++ | src/Perl6/Actions.pm:
When we write my ($x is rw) := 42, make sure that we don't try and re-apply the
 22:44
NotFound Which is byte level access, as his name manifests.
dalek rrot: r47522 | darbelo++ | branches/gsoc_nfg/src/string/grapheme.c:
Handle cloning on NULL tables.
 22:48
kid51 mikehh: Unfortunately, I'm getting one failure on make coretest on darwin/ppc 22:53
mikehh kid51: unfortunately I don't have access to that platform - but ticket it unless you can figure it out and fix it 22:56
kid51: is it a darwin specific test? 22:58
nopaste "kid51" at 192.168.1.3 pasted "After make corevm, one failure on darwin/ppc" (11 lines) at nopaste.snit.ch/21122 23:00
kid51 "no ICU lib loaded" 23:01
Not Darwin-specific. Suspect that test presumes ICU loaded. But I know I don't have it here.
Do you want me to create a TT? 23:03
make coretest passed on linux/i386; only that one failure on coretest on darwin/ppc 23:04
mikehh kid51: that is a new test and if it is ICU related it needs to test for that and skip if necessary 23:09
ash_ any C guru's that are bored and want to help me out a bit? i have a file that's independent of the whole of parrot that isolates my issue, it only requires a C compiler and libffi headers 23:11
cotto_work anyone feeling like answering can't answer without seeing the code 23:14
ash_ gist.github.com/ea759b72f3ce3be7f724 23:16
kid51 mikehh: matter of fact, it fails under 'make test' as well
ash_ Excuse my random and many prints, i had most of the code in a pmc before and was having issues with the gdb putting in break points 23:17
cotto_work why does that gist have a private clone URL?
nm. download link works fine 23:18
ash_ if you want to check out the gist to work with, you can clone it so git will manage your changes
or you can make a fork
its kinda like a mini git repo
actually its a full git repo, its a bit less than the normal github project 23:19
so... in theory, lines 520, 526 and 530 should function the exact same, but 530 causes a segfault 23:20
the ffi_cif struct type has an element ffi_type *arg_types; that appears to be on the sig.cif, i can't for the life of my figure out why 23:22
i have a few things in there to let it act like it was in parrot (hence the macros for PARROT_INTERP etc.), but most of that shouldn't matter to much i don't think 23:26
dalek TT #1677 created by jkeenan++: t/pmc/bytebuffer.t: Fails when ICU is not present 23:28
TT #1677: trac.parrot.org/parrot/ticket/1677
23:36 theory joined 23:37 tetragon joined 23:58 snarkyboojum joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!