Parrot 1.2.0 released | parrot.org/ | 303 RTs left | Weekly Priority: Profiling
Set by moderator on 28 May 2009.
japhb oddly, given that I work with the Usenet all day long, I actually do want to be on the list. ;-) 00:00
nopaste "bacek" at 122.110.39.63 pasted "Sub,pmc additional methods." (53 lines) at nopaste.snit.ch/16797 00:03
00:03 bacek_ joined
bacek_ chromatic: any objections about nopaste.snit.ch/16797 ? It part of nopaste.snit.ch/16791 - emitting PBC from PIR 00:04
chromatic In principle no, but is there a way to accomplish the same thing without referring to raw offset positions? 00:07
bacek_ chromatic: No. At least Subs just frozen into PBC and use those offsets. 00:09
chromatic Is there something else we can pass into those methods to calculate offsets?
bacek_ without braking encapsulation? Probably no. 00:10
chromatic Perhaps with less encapsulation breaking? 00:11
bacek_ Split Sub into 2 parts. One for storing and manipulating, one for executing. 00:13
chromatic I'm really leery of adding an API that could let people break things horribly if they're not super careful. 00:14
bacek_ me too. 00:16
We can hold additional flag "live" for subs that attached to interp and disallow changing offset for them
Actually, disallow change anything in sub. 00:17
chromatic Is the Sub PMC the right place for this?
dalek rrot: r39417 | chromatic++ | trunk (5 files):
[IMCC] Allowed Unicode identifiers in method names, not only when stored in
bacek_ It's about how PBC designed... 00:18
chromatic IMCC (I can't believe I'm writing this) manipulates its own data structures before building a Sub PMC.
bacek_ And than it pokes inside Sub to set things. 00:19
chromatic Does it? 00:20
bacek_ emit_pbc_instr if I understand it correctly 00:22
compilers/imcc/pbc.c 1433 00:24
chromatic Hm, that's true. 00:26
I'd almost rather write out a serialized version and thaw it. 00:27
00:30 kesselhaus joined
bacek_ freeze if serialising, isn't it? 00:31
chromatic Right. 00:32
bacek_ So I need created Sub for freeze. Fully created... 00:36
Ok, how about check sub->seg before changing offsets? If it's non null - disallow.
oh. it will not work...
nopaste "bacek" at 122.110.39.63 pasted "chromatic what this approach?" (110 lines) at nopaste.snit.ch/16798 00:49
chromatic Tene, the segfault occurs for me (without --gc-debug) when trying to mark a context. The PMC in the register set is invalid. 00:55
I don't understand why it has to be in the Sub PMC. 00:56
bacek_ what other place to put it in without implementing full pmc_freeze logic? 00:57
Tene chromatic: That's right.
That's what I saw too
chromatic How are you creating these Subs? As PMCs? 00:58
Tene, it's weird; it's just one PMC in the register set that's wrong. 00:59
Tene Exactly.
chromatic There are 10 PMC registers, and the ninth one (i = 8) is 0x1. The tenth one is fine.
Tene That's what I saw too.
chromatic I've seen this before, but I could never track it down. 01:00
bacek_ chromatic: yes, as PMCs.
chromatic: and than put them into PackfileConstTable 01:01
chromatic Can you create all of the necessary sub information right now through the PMC interface, except for these four methods?
afk_coke if I have a PIR sub that is best suited to be a multi, is it faster in PIR to use a multi or just have a non-multi that checks for types itself? 01:02
bacek_ chromatic: almost
what I actually need is FakeSub. Which will be frozen as Sub. 01:03
chromatic And thawed as Sub, where there are no UI parts users can play with.
bacek_ I don't quite understand last question. 01:04
Ah. After thawing I don't need anything else.
chromatic Build the data with something where you can poke at its internals, then freeze and thaw it as something users can't poke at its internals.
bacek_ indeed.
Just freezing. Thawed Sub should be constant 01:05
chromatic Tene, my best idea for debugging this is annotating the REG_PMC macro to ASSERT that the PMC isn't 0x1.
Otherwise we could try hardware watchpoints after we know which context gets created appropriately.
*Something* somewhere assigns a bad value here, and I don't have time to reason through it.
Tene Hmm. I don't really understand that part of Parrot. 01:11
I'll try playing with that. 01:12
01:13 snarkyboojum joined
dalek rtcl: r437 | coke++ | trunk/runtime/conversions.pir:
split toBoolean into components - checking the boolean value of an int

timings are inconclusive.		 01:18
rtcl: r438 | coke++ | trunk/t/tcl_misc.t:
remove 3 old regression tests that were needed back around parrot 0.2
 01:23
Tene Specifically, I can't quite figure out how to add an ASSERT in the middle of a statement in C, which is where that macro expands to.
mikehh kid51: I have been failing manifest_tests - t/tools/install/dev_overall.t and overall.t - if I change mkpath to make_path it works 01:29
kid51 mikehh: Am puzzled. what is 'make_path'? Can you paste? 01:31
mikehh kid51: in File::Path 01:32
kid51: File::Path ver 2.07 Ubuntu 9,04 (both i386 and amd64) Perl 5.10 01:34
kid51 mikehh: In File::Path v2.04 I cannot locate a string 'make_path'. So I don't know how that could work. 01:35
Also, 'make manifest_tests' just ran AOK for me on Darwin and Linux.
Please open TT. 01:36
nopaste "mikehh" at 90.209.128.185 pasted "Patch that fixes manifest_tests for me" (44 lines) at nopaste.snit.ch/16799 01:38
dalek rrot: r39418 | jkeenan++ | trunk (2 files):
Eliminate the last traces of deprecated functions Parrot_readbc and

  trac.parrot.org/parrot/ticket/266.
TT #266 closed by jkeenan++: Packfile API cleanup: rename Parrot_readbc to Parrot_pbc_read, _loadbc => ... 01:40
kid51 mikehh: Can you paste your test failures? 01:41
Austin_Hastings Any idea what $P0 = getinterp ; $P1 = $P0['namespace';1] is extracting? Is the 'namespace' an array of caller data, or some other wierdness that would need an extra ;1 index? 01:44
kid51 mikehh: I doubt we'll be able to accept that patch. File::Path::make_path() was only introduced in v2.07, Nov 2008. That's much more recent than our minimum version.
But pls paste errors anyway. 01:45
nopaste "mikehh" at 90.209.128.185 pasted "manifest_tests failures" (40 lines) at nopaste.snit.ch/16800 01:51
mikehh kid51: I tried to get it to work in various ways but it seems to create the dirs with NO permissions using mkpath, but works with make_path 01:56
Austin_Hastings Aha. Yes. parrotinterpreter.pmc has a get_pmc_keyed interface that returns caller data when queried with "<key>";<level> pairs. 01:59
nopaste "back" at 122.110.39.63 pasted "Let's fake Sub!" (198 lines) at nopaste.snit.ch/16801 02:00
mikehh kid51: actually in one case the compliers directory and in the other the src directory have mode 000 02:01
bacek_ msg chromatic nopaste.snit.ch/16801 is what I actually need. And it works.
purl Message for chromatic stored.
dalek rtcl: r439 | coke++ | trunk/t/tcl_misc (2 files):
Convert most of this file to tcl, throw out some dup tests.
 02:07
nopaste "kid51" at 70.107.16.159 pasted "mikehh: does this work?" (28 lines) at nopaste.snit.ch/16802 02:17
mikehh kid51: nope - syntax error 02:31
kid51 What versions of File::Temp and File::Path are you using? 02:32
At this point, I recommend you file a new TT. My patch worked for me with the versions of those two modules that came with Perl 5.10. I cannot reproduce your failues. 02:33
this will need further investigation.
... and it's too late at night for me to begin that.
I don't know how you got a syntax error for code that I just now ran successfully. 02:34
02:36 janus joined
mikehh kid51: let me work on it a bit more - I need to look at File::Path a bit more - I have 2.07 - File::Temp 0.21 02:37
kid51 File::Path is apparently a module whose interface has, um, evolved through the years. 02:38
And in the Parrot distro we have all 3 generations of interfaces for mkpath :-)
But 2.07 is probably more recent than that shipped with 5.10 -- and we don't even require 5.10! 02:39
So we have to get it to work with either the 'traditional' or the 'modern' (but not hyper-modern) interface.
mikehh kid51: Yeah - any modules I use are generally the latest from CPAN and the latest sometimes break older code 02:40
kid51 I see that lib/Parrot/Install.pm uses the oldest interface. I'm going to change that now (or maybe tomorrow morning). 02:42
mikehh kid51: I think I need to take a break - it's coming up to 4am for me - I'll work on it later 02:50
dalek rrot: r39419 | jkeenan++ | trunk (3 files):
Use the 'modern' interface to File::Path::mkpath(), i.e., explicitly pass mode in hashref final argument.
kid51 Thanks for reporting the problem. I grepped repository and realized that there are many usages of 'mkpath' which are succeeding even though they don't match any of the specified interfaces. 02:53
02:55 darbelo joined
nopaste "bacek" at 122.110.39.63 pasted "chromatic, this FakeSub is better. Any objections?" (80 lines) at nopaste.snit.ch/16803 02:55
mikehh kid51: apologies - that patch actually worked - I messed up the test - it works now - I gotta get a nap now 03:10
kid51 np; it led me to some refactoring which you'll see committed shortly. 03:11
dalek rrot: r39420 | jkeenan++ | trunk (10 files):
Where directory mode is explicitly passed to File::Path::mkpath(), use the
 03:17
03:22 snarkyboojum joined
dalek rrot: r39421 | cotto++ | branches/pmc_pct/compilers/vtdumper/vtdumper.pir:
[vtdumper] put the freeze code back, since the vtable dump doesn't actually need to be portable
 03:23
03:24 bacek_ joined
dalek rrot: r39422 | cotto++ | branches/pmc_pct/compilers/vtdumper/vtdumper.pir:
[vtdumper] mark the generate_dump stage as a method
 04:12
04:15 david joined
dalek TT #743 created by Austin_Hastings++: Add 'inspect' method to Sub PMC 04:15
04:20 darbelo joined
cotto Austin_Hastings, ping 04:29
Austin_Hastings cotto, pinf
*ping
cotto wrt tt #743, the Sub PMC defines an inspect *VTABLE function*, not a method.
Austin_Hastings Right. 04:30
I am asking for method.
(Eventually, I am asking for introspective interfaces throughout, but I thought I'd take it slow.) 04:31
cotto Why not use $P2 = inspect $P0 ?
Austin_Hastings Because I had no idea it exists.
cotto Now you know.
purl It does the boots and shoes.
cotto Many VTABLE functions can be used like that through opcode wrappers. 04:32
no, Now you know. is And knowing is half the battle.
purl no, Now you know. is And knowing is half the battle.
purl i already had it that way, cotto.
cotto now you know 04:33
purl It does the boots and shoes.
cotto purl no, Now you know is And knowing is half the battle.
purl okay, cotto.
cotto now you know
purl now you know is And knowing is half the battle.
cotto purl no, Now you know is <reply>And knowing is half the battle.
purl okay, cotto.
cotto purl no, Now you know. is <reply>And knowing is half the battle.
purl okay, cotto.
Austin_Hastings w00t! You rock.
dalek cnum-dynpmcs: r74 | darbelo++ | trunk/src/pmc/decnumcontext.pmc:
Add get_clamp() and set_clamp() METHODs for the 'clamp' field of the decContext

and a bool PMC is returned by the getter.
cotto glad to help
Austin_Hastings Now if only there was a get_pointer opcode. Is there?
cotto no, and there shouldn't be. 04:34
Austin_Hastings :)
Well, I'm looking for a unique key for the object...
(the object is a Sub in this case)
cotto That VTABLE function is used to fiddle with a PMC's internals and should be considered dangerous (but not as dangerous as set_pointer).
that seems to be a common use case 04:35
Austin_Hastings I'd suggest doing something like "hashcode", but I'm pretty sure everyone would go "Oh, no! They did that in Java so it must be a bad idea."
darbelo Austin_Hastings, be careful, nothing guarantees that you'll get a valid pointer out of get_pointer(). 04:36
Austin_Hastings darbelo, Thanks, but I can't call it from PIR, so it does me no good. I was just bemoaning the lack of a unique-id.
darbelo Oh, didn't know you were working from PIR. Sorry. 04:37
cotto I wonder how a VTABLE function (plus opcode wrapper) dedicated to that purpose would go over. It'd be dead simple to implement.
Austin_Hastings No worries. You've got to expect the occasional (l)user.
cotto just stick something sane in default.pmc and everyone else gets it for free 04:38
Austin_Hastings cotto, How about a pmc?
cotto ?
Austin_Hastings $P0 = new 'UniqueId', my_object
cotto It seems a little heavyweight for something that simple. 04:39
Austin_Hastings I was thinking the same thing about a new vtable function.
(Since bacek was griping about the huge number of vtable functions just the other day.) 04:40
darbelo Maybe I'm over-simplifying here but wouldn't be "INTVAL get_unique_identifier() { return SELF }" sufficient? 04:41
Austin_Hastings I have no idea. Does the GC ever move things? Should this persist across serialization?
cotto darbelo, yes but it'd be good to make absolutely sure that it could never be misused.
Austin_Hastings Misused? 04:42
dalek TT #743 closed by cotto++: Add 'inspect' method to Sub PMC
cotto Austin_Hastings, we don't currently have a compacting GC, but Whiteknight++ has it on his todo list.
darbelo Ohhhh. Compacting gcs are *shiny*. 04:43
cotto misused as in someone uses it as a pointer. Returning a STRING* would probably be sufficient.
I'll hack up a patch for that and see how people respond. 04:44
Austin_Hastings Also, does the id ever change? I'm thinking in particular of class pmc's that can get changed, etc.
cotto I think bacek's problem with VTABLE functions is that there are a ton that are hardly ever used and don't make sense in most contexts.
id? 04:45
purl id is undef => a breaker
cotto as in pmc->vtable->base_type?
Austin_Hastings Cotto, when you talk about this, you need to distinguish two possibles: id as just an id, and id as some kind of metric (hashcode). One is slower than the other, but may have more uses. 04:46
Anyway, it'd probably be good to run it past @Parry.
Okay, here's a question for you internals gurus. I have created a new class and add_method'ed a 'new' sub. But it isn't being called. How can I figure out what's going on with the dispatch of this method? 04:51
cotto Austin_Hastings, when you say "id", I think of something used to tell if two PMCs have the same guts. 04:56
Austin_Hastings, unless you need to create the new sub dynamically, you can stick the code in the namespace corresponding to the class. 04:57
Austin_Hastings I did that. I did a bunch of stuff I think should make this a total no-brainer, but I'm talking to the wrong sub.
darbelo cotto, I'd think of the same PMC header, instead of the guts. Unless you meant that. 04:58
cotto darbelo, that's what I meant.
Austin_Hastings, nopaste? 04:59
Austin_Hastings gimme a sec to reorg the code
cotto darbelo, lmk if you get stuck with pct while working on the test suite. 05:00
Austin_Hastings nopaste.com/p/aEtPCOuUK
cotto What language is that? 05:02
purl I'm not sure... but it doesn't sound like any kind of English I know.
Austin_Hastings close
cotto purl++
ioc. That's your experimental language. 05:03
Austin_Hastings yep. It's not C, but it's close. :)
cotto My brain can't decide if it's C or PIR.
It's quite disorienting.
Austin_Hastings As time goes by, I hope that the percentage of PIR will approach 0. 05:04
cotto I'm not sure what kind of PAST you want to generate for that. You could cheat and see what Rakudo does. 05:07
--target=past is your friend
Austin_Hastings If it helps, here's the pir (minus annotations, which just piss me off) 05:08
nopaste.com/p/a8e1p6Ylqb
darbelo cotto: I was kinda stumped at the start, but then I just grabbed what create_language.pl generates and edited to suit my purposes. It sort-of parses most stuff now. I'll do some cleanup and commit the grammar later.
cotto darbelo, ok. 05:10
I like that nopaste.
Austin_Hastings So I guess my first question is am I doing the right thing by using get_hll_global to load up the sub? 05:13
But then I'm still stuck with wondering how $P47 is doing dispatch on "new"? 05:14
It's calling SOMETHING, and returning. But not my "new", since no output appears.
cotto You can use the 'new' opcode. It dtrt afaik. 05:15
Austin_Hastings My understanding was that it doesn't call the support code. It just creates, without initializing.
cotto actually, I need to check that
Austin_Hastings (In fact, 'new' is a builtin in close for this.)
cotto bbs: shopping 05:16
purl shopping is probably a drag. or a great time, if it's *barber* shopping! </kitch>
dalek cnum-dynpmcs: r75 | darbelo++ | trunk/src/pmc/decnum.pmc:
Add a multiply_add() method to DecNum, based on decNumberFMA().
 05:17
05:26 Zak joined
dalek cnum-dynpmcs: r76 | darbelo++ | trunk/src/pmc/decnum.pmc:
Add exp() and sqrt() METHODs to DecNum.
 05:32
05:36 mikehh joined 05:38 Austin_Hastings left
dalek cnum-dynpmcs: r77 | darbelo++ | trunk/src/pmc/decnum.pmc:
Make DecNum stringification prettier.
 05:46
cnum-dynpmcs: r78 | darbelo++ | trunk/src/pmc/decnum.pmc:
Add ln() and log10() METHODs to DecNum.
 05:57
06:04 snarkyboojum joined
cotto karma darbelo 06:04
purl darbelo has karma of 88
dalek cnum-dynpmcs: r79 | darbelo++ | trunk/src/pmc/decnum.pmc:
Add a get_eng_string METHOD. It does the same as the get_string VTABLE but using
 06:12
06:22 viklund_ joined
dalek cnum-dynpmcs: r80 | darbelo++ | trunk/src/pmc/decnum.pmc:
Add modulus() and i_modulus() VTABLEs.
 06:37
darbelo It looks like I'm running out of easy stuff. :) 06:52
I think I'll try to get some sleep before going back to the tests. 06:54
06:57 iblechbot joined
cotto Nobody should tell him that writing a grammar is the easy part. 06:58
dalek rrot: r39423 | cotto++ | branches/pmc_pct/compilers/pmcc/pmcc.pir:
[pmcc] make pmcc behave well when working with pmcs in the cwd
 07:25
rrot: r39424 | cotto++ | branches/pmc_pct/compilers/pmcc/src/parser/actions.pm:
[pmcc] start making the thawed vtable dump available
rrot: r39425 | fperrad++ | trunk (2 files):
[codingstd] fix svn properties
 08:04
08:18 HG` joined 08:22 Zak joined 08:32 flh joined 08:38 clinton joined 08:41 Zak joined 08:43 barney joined 09:05 cognominal joined 09:13 darbelo joined
darbelo cotto: ping 09:14
09:14 Zak joined 09:48 Zak joined 09:54 jq joined
dalek cnum-dynpmcs: r81 | darbelo++ | trunk/t/data/d (50 files):
Remove test data for unused decSingle, decDouble and decQuad modules.
 09:55
10:12 flh joined 10:28 NotFound joined
flh I cannot checkout parrot's source using svn: did anything change recently? 10:33
clinton flh: works for me 10:38
although it's quite slow 10:40
flh ok, it is just a problem in the current Debian testing (upgrading libneon27 from v0.28.4-1 to v0.28.4-2 does the trick) 10:49
dalek rrot: r39426 | NotFound++ | trunk/src/embed.c:
[cage] fix warning in mem_realloc_n_typed usage
 11:02
11:02 Whiteknight joined 11:12 bacek joined
dalek TT #744 created by tene++: GC Segfault with steme and rakudo 11:39
11:43 skids joined 12:03 masak joined
skids Does Markus (of "added Rational PMC code" fame) have an IRC nick/hang out here at all? 12:12
12:14 kid51 joined 12:22 NotFound joined
dalek TT #742 closed by jkeenan++: Parrot::Test::Util::create_tempfile() cannot handle DIR option on Cygwin 12:22
12:24 fperrad joined
dalek rrot: r39427 | fperrad++ | trunk/tools/dev/create_language.pl:
[languages] remove a die in read_parrot_config,
 12:33
rrot: r39428 | fperrad++ | trunk/tools/dev/create_language.pl:
[languages] add a target 'installable'
 12:37
rrot: r39429 | jkeenan++ | branches/add_library_path_remove:
Create branch to work on trac.parrot.org/parrot/ticket/455.
 12:40
kid51 Does anyone know whether 'make headerizer' should be run before or after 'make'? 12:50
Infinoid after. it depends on some autogenerated sources 12:52
which does mean it has some chicken and egg problems, sometimes. 12:53
kid51 I'm trying to work on TT #455
Infinoid so let me guess, "make" doesn't complete due to a missing prototype? 12:55
nopaste "kid51" at 68.237.16.53 pasted "errors during 'make' while trying to eliminate Parrot_add_library_path" (12 lines) at nopaste.snit.ch/16806 12:57
kid51 Since I am not a Parrot-level C programmer, I'm just blundering around.
Infinoid ok. I can try to help you figure out those warnings 12:59
kid51 I believe the file which has to be changed first is src/library.c 13:00
NotFound Are you passing a C string? 13:01
Infinoid Can you nopaste your current diff, please? (line 649 is pod for me)
kid51 Parrot_add_library_path_from_cstring is described as an interface to Parrot_add_library_path. The latter is what the TT wants to eliminate. 13:02
NotFound I think that we want't to eliminate nothing, just renaming.
Infinoid Both functions already exist 13:03
NotFound We want both the Parrot string and the C string interface.
At least I want.
Infinoid Okay. But we want to avoid two unnecessary string conversions in the common case 13:04
nopaste "kid51" at 70.85.31.226 pasted "Attempt at getting rid of Parrot_add_library_path" (57 lines) at nopaste.snit.ch/16807
NotFound The way to avoid unneeded conversions is to call the appropiate version,
kid51 NotFound: See TT #455. I have no personal opinion on the merits of this. I'm merely trying to handle an item marked for deprecation as of 1.1. 13:06
Infinoid kid51: I think that warning will go away if you call VTABLE_push_string with path_str instead of path 13:07
kid51 Yes, I was looking at that too. I'll give it a try.
Infinoid otherwise the diff looks good to me (though some callers will need to be fixed up)
NotFound kid51: nothing in the ticket contradicts what I said 13:08
Implementation details apart. 13:09
Infinoid If there's a use for the alternate form, then that's fine. (It's an extension of the ticket's requested functionality.) But if we have APIs to handle both kinds of strings, and we have current callers who convert string types before calling this API, those callers should still be fixed up 13:11
kid51 The next file to be fixed is src/packfile.c, around lines 4776 13:12
Infinoid I'd probably remove the old API temporarily anyway, just to make it easier to find the callers
yes, src/packfile.c:4776 is one of the callers
kid51 If I just do a simple search-and-replace on the function name, I get: 13:13
src/packfile.c:4776: warning: passing argument 2 of 'Parrot_add_library_path_from_cstring' from incompatible pointer type
src/packfile.c:4778: warning: passing argument 2 of 'Parrot_add_library_path_from_cstring' from incompatible pointer type
Infinoid Right, you should also change CONST_STRING(interp, "include/") to "include/"
(that's an example of the cstring to STRING conversion allison was talking about eliminating) 13:14
kid51 But that gives me: 13:15
src/packfile.c: In function 'Parrot_load_language':
src/packfile.c:4775: warning: passing argument 3 of 'Parrot_str_append' from incompatible pointer type
src/packfile.c:4776: warning: passing argument 2 of 'Parrot_add_library_path_from_cstring' from incompatible pointer type
src/packfile.c:4777: warning: passing argument 3 of 'Parrot_str_append' from incompatible pointer type
src/packfile.c:4778: warning: passing argument 2 of 'Parrot_add_library_path_from_cstring' from incompatible pointer type
Let me paste state of that file.
Infinoid oh, uck. Parrot_str_append still expects a STRING
nopaste "kid51" at 70.85.31.226 pasted "packfile.c changes" (16 lines) at nopaste.snit.ch/16808 13:16
Infinoid okay. in this case, I think NotFound is right, preserving the old API will be helpful 13:17
NotFound I don't understand what are you doing. If the function is using parrot string functions, there is no point in usung the c string version 13:18
Infinoid NotFound: It's just a repercussion of removing the STRING-based API as the ticket says, and converting the caller to use cstrings
kid51 Infinoid: Do you want to comment in TT 455? If there are real issues here, I won't proceed. 13:19
NotFound I think you are also misunderstanding the ticket
purl okay, NotFound.
Infinoid The ticket says, rename the function.
NotFound says, extend the function with a second API so we can handle both
So NotFound's version is an extension of the functionality requested in the ticket. That's my understanding, did I miss something? 13:20
NotFound "A new function 'Parrot_lib_add_path' will be added that accepts a Parrot STRING. "
Infinoid The summary line: Change name of 'Parrot_add_library_path' to 'Parrot_pf_add_library_path_from_cstring'
To me that sounds like "rename"
NotFound The ticket says that
"The C string version will simply convert the C string to a Parrot STRING and call 'Parrot_lib_add_path'." 13:21
So, the ticket ask for the two versions.
Infinoid Oh, I see. So the callers of the old function (who are right to call the old function) should now call Parrot_lib_add_path(), instead 13:22
NotFound The naming used seem confusing, anyway.
kid51 So this is more than a simple "rip out this feature" deprecation.
Infinoid It's a "rename this function to that, and add this other function to make some of the callers cleaner"
NotFound Is reanimg a function and adding another. 13:23
Infinoid You've got the "this other function" part done
kid51 Okay, that's beyond my C fu.
Infinoid kid51++ # already more than halfway there
NotFound The title of the ticket uses one name, but the description uses another. That needs clarification. 13:24
Infinoid please feel free
I can clean up the diff accordingly
kid51 I will post what I have done in the ticket so it can get wider exposure.
Infinoid oh, great. kid51++ 13:25
NotFound I think we must ask allison.
Infinoid I think it's pretty clear now
The summary misses part of the details, that's all
NotFound Infinoid: not for me. Parrot_lib_add or Parrot_pf_add? 13:26
Infinoid Parrot_lib_add, that's a typo
NotFound Ah, nice.
dalek rrot: r39430 | jkeenan++ | branches/add_library_path_remove (3 files):
Partially complete work on TT#455.
 13:27
Infinoid So we remove Parrot_add_library_path, and add Parrot_lib_add_path (which does the same thing) and Parrot_lib_add_path_from_cstring
so the naming conforms to the rest of parrot, and we have both entry points 13:28
NotFound I think we must maintain Parrot_add_library_path, reinplementing it by just calling the new API, until the end of a deprecation cycle, 13:29
Infinoid from DEPRECATED.pod: =item Parrot_add_library_path [eligible in 1.1]
so we've already done the deprecation cycle 13:30
NotFound That's seems wrong to me. We can't start a deprecation cycle before the alternative even exists,
Infinoid That sounds like a great #ps question, I don't feel too strongly about that issue 13:31
it just says "check in 1.4 or 2.0 for the new names", which seems reasonable to me
NotFound No big problem ATM, but as a general police looks wrong to me. 13:33
Infinoid I think maintaining parallel implementations of *everything* we deprecate, for an entire deprecation cycle, would be a significant extra amount of maintenance 13:35
kid51 TT 455 updated. 13:36
Infinoid I agree that it would probably be easier for partcl (for example) to keep up to date if both APIs were available and the conversion could happen anywhere within the 6 month deprecation cycle span
But that's a lot more work on the parrot side to maintain that model.
kid51 Infinoid: I interpret that line from DEPRECATED.pod as meaning: "Anyone can work on this right away; we don't have to wait till after the July release." That's why I attempted this. 13:37
Infinoid kid51: Yes, that's our policy, seems fine to me 13:38
kid51 There are several other 'eligible in 1.1' items, but this one was the only one I could grok. 13:39
NotFound Infinoid: if we don't maintain them, what's the meaning of "deprecated"? 13:43
Infinoid "don't use this" 13:44
pmichaud "deprecated" means "we don't guarantee this will work the same in the next stable release"
Infinoid or "expect this to break"
NotFound Infinoid: "don't use this, we still don't have a replacement. Bad luck" 13:45
pmichaud: that's a nice way, provided we have something that will works in the next, and also works in current. 13:46
13:48 pmichaud_ joined
pmichaud_ lost my connection to feather 13:48
NotFound: deprecation basically means that we expect the API to change 13:49
it doesn't mean that the feature will definitely be gone in the next release
Infinoid And it doesn't mean the replacement is already available
pmichaud_ correct
Infinoid (I think that's what NotFound is objecting to)
NotFound Yeah
pmichaud_ sometimes features are completely eliminated
NotFound We aren't talking about a feature, just an API minor detail change. No point to break things for that. 13:50
dalek rrot: r39431 | Infinoid++ | branches/add_library_path_remove (4 files):
Perform TT #455 API updates, get the callers working. Everything builds now.
 13:51
pmichaud NotFound: that's a slightly separate issue.
Basically a deprecation is a warning that we expect the contract to change
pmichaud looks like my session restored :-) 13:52
NotFound Changing the API without alternative is not a warning to me, is a full stop.
pmichaud iirc, most/all C-level functions in Parrot were considered unstable as of the 1.0 release 13:53
i.e., they could be changed.
Infinoid kid51: I'm running tests now, but I think this branch is almost ready for merging back to trunk
pmichaud anyway, we can declare something as deprecated even before the alternative exists 13:54
NotFound And sometimes is reasonable, when maintaining the old way is costly. But there is no point in doing that just because we can.
kid51 Infinoid: Yes I'm doing make and then will test; I'll smolder.
pmichaud if we *know* something is going to change, then we deprecate it, even if we don't know what we're going to change it to
for example
in NQP, I knew in March that the $(...) syntax was no longer going to be valid 13:55
however, at that time I had no idea what it would change to (because the Perl 6 spec didn't say yet)
so, I went ahead and deprecated $(...)
NotFound pmichaud: we can warn about that, but is highly unfriendly to use that as the official start of a deprecation cycle.
pmichaud but I couldn't say "and it will be replaced by XYZ", because XYZ wasn't defined yet
Infinoid kid51: I failed t/codingstd/pdd_format.t but I think that failure was inherited from trunk. Otherwise, looks good here
kid51 Infinoid: You are correct. That's an error in trunk. 13:59
Infinoid I don't see any instances of Parrot_add_library_path() in lua, partcl or rakudo
kid51 =item ([<var1> [:<modifier1> ...], ...]) = <var2>([<arg1> [:<modifier2> ...], ...])
Infinoid otherwise I'd post a quick patch for those 14:00
kid51 perhaps shorten 'modifier'
Infinoid I guess
pmichaud if I have a sequence of bytes in a fixed_8 string 14:03
how do I get those to be treated as a utf8 string?
kid51 Smolder report: smolder.plusthree.com/app/public_pr...ails/23243 14:04
Infinoid: Shall I merge? 14:05
Infinoid kid51: Please do. 14:06
kid51 Will do in about 10 min. 14:13
14:23 clinton left
dalek rrot: r39432 | jkeenan++ | trunk (5 files):
Merge add_library_path_remove branch into trunk, per trac.parrot.org/parrot/ticket/455. Complete deprecation of Parrot_add_library_path.
 14:24
rrot: r39433 | jkeenan++ | branches/add_library_path_remove:
Branch has been merged into trunk and is no longer needed at HEAD.
purl i already had it that way, dalek.
14:41 snarkyboojum joined 14:42 ruoso joined 14:49 HG` joined
Infinoid Tene: If you mention steme on trac.parrot.org/parrot/wiki/Languages, dalek will give you karma for your commits. :) 14:54
15:25 masak joined
flh does the Hash PMC work with non-string keys? 15:42
dalek rrot: r39434 | fperrad++ | trunk/tools (2 files):
[languages] add steme (Tene++)
 15:43
Infinoid flh: Not really. Integers and PMCs will be stringified. Keys returned from Iterators are a special case. 15:57
Anything else would beg the question "how do you run a hash function on a non-string" 15:59
16:09 Theory joined
skids ?nopaste 16:27
16:32 Psyche^ joined
nopaste "skids" at 71.192.212.78 pasted "Meanderings on Parrot's STRING hashval caching." (277 lines) at nopaste.snit.ch/16809 16:33
cotto darbelo, pong 16:48
Infinoid Are STRING hashvals stored in PBC? 16:50
darbelo cotto: The test grammar can now parse the tests ( which means I've ran out of easy stuff ;) and wanted to sanity check some code-generations ideas with you. 16:52
I used an almost-empty actions file and with "--target=parse" I ended up with this: 16:55
nopaste "darbelo" at 200.49.154.172 pasted "snippet of parsed decTest file" (11 lines) at nopaste.snit.ch/16810
16:56 bobke joined 16:59 tetragon joined
darbelo Which looks to be what I want. My idea is to not use the ->post->pir path but to just walk the tree and output text (which happens to be pir) 17:00
Is that sane? Am I abusing the toolchain? Both? 17:01
cotto looking... 17:02
jonathan darbelo: Doesn't sound too abusive but there may be a better way
darbelo: e.g. you could transform it to PAST nodes that call the 'is' function.
cotto what he said
jonathan And then just let the code generation to PIR happen from that.
cotto btw, feel free to commit early and often, even if the code is incomplete or doesn't dtrt 17:04
nopaste "darbelo" at 200.49.154.172 pasted "Here's the grammar." (56 lines) at nopaste.snit.ch/16811 17:05
darbelo The 'number' token is a mess, but I couldn't get it any simpler than that and still parse all the notations used on the decTest files. 17:06
cotto You could break it into smaller pieces, but it looks mostly sane. 17:08
17:09 dihymo joined
cotto I'd break out that middle part so you're matching quotes correctly. 17:09
i e ['] <middle part> ['] | ["] <middle part> ["] | <middle part> 17:10
dihymo if two scripts snippets are written for two parrot languages could they actually share the same context as if they were in the same language? 17:11
cotto you mean parrot-level context?
dihymo yes 17:12
jonathan dihymo: Depends exaclty what "context" means.
I guess it works at the block/sub level.
cotto darbelo, bbs
jonathan darbelo: BTW, the grammar decTest::Grammar is PCT::Grammar; 17:13
is near the bottom?
dihymo <?php $a = 5 ?> <?lisp (+ a 5) ?> <?php echo $a ?>
the last one would output 10
granted that would probably unleash skynet but... 17:14
darbelo jonathan: It's a the top of the file. Looks like a paste error.
jonathan I suspect that'd only work if each of those statements was executing in a lexical scope of its own, which implies $a is a global, plus the compilers know how to name-mangle away the $. 17:15
darbelo: ah, ok
dihymo doesn't the language implementation do the name-mangling? 17:16
17:16 Khisanth joined
dihymo i heard there was a php implementation 17:16
jonathan Yes, the language can implement the namespace interface in order to handle this.
dihymo i mean when you target a language to parrot you convert to parrot code 17:17
jonathan Right.
PHP implementation - yes, there is one underway, I don't know much about it but can probably point you at something...moment...
wiki.github.com/bschmalhofer/pipp 17:18
(Linked from www.parrot.org/languages if you want to look up other language-on-Parrot efforts.)
dihymo it would cause the sharing and development of scripts in one's favorite or the "the best language for the job" TM at that moment to explode
cool thx
jonathan blogs.gurulabs.com/stephen/2009/05/...ading.html # is a reecnt post on the language interop front 17:19
dihymo what would be great is if you could create objects in say .Net for access to their standard features, and then manipulate them in lisp 17:20
it would make foreign function interfaces obsolete
i actually have a language i'd like to implement and using a host language has been um clumsy i'd like to see what parrot could do 17:21
17:22 clinton joined
jonathan Parrot has a bunch of compiler tools that help make things easier. 17:22
skids surprised no languages/busybox yet :-) 17:38
17:38 davidfetter joined
dalek cnum-dynpmcs: r82 | darbelo++ | trunk/aux (7 files):
Add basic, not-yet functional, unMakefiled starts for a PCT-based decTest
 17:54
18:16 polyglotbot joined
cotto back 18:25
dalek kudo: 97f1415 | pmichaud++ | src/ (4 files):
Refactor assignment in terms of STORE. This brings us somewhat

eliminates a few "isa" checks, and paves the way for better rw and postcircumfix handling.		 18:31
cotto rakudo: say "hi" 18:32
perl6: say "hi"
polyglotbot OUTPUT[error:imcc:syntax error, unexpected $end ('Ć¾')ā¤ in file '/home/tene/parrot-build2/runtime/parrot/library/config.pbc' line 1ā¤hiā¤] 18:33
18:39 Zak joined
dihymo what if the statements in a language are structure based rather than token based? 18:52
in pseudo lisp it might be like this
say the context is add/subtract 18:53
so (5 6 nil) -> would respond with (nil nil 11)
(5 nil 11) -> (nil 6 nil)
(nil 6 11) -> (5 nil nil) 18:54
18:54 cotto joined 19:07 supergiantrobot joined
supergiantrobot hello 19:07
purl hey, supergiantrobot.
supergiantrobot I am trying this...
parrot -o sum.pasm sum.pir 19:08
parrot sum.pasm
But the latter command just sits
Why? 19:09
NotFound supergiantrobot: if you are trying to compiler to bytecode, the extension is pbc, no pasm 19:12
supergiantrobot right
but I want to save pasm
(for a demo)
and then run pasm
should the parrot sum.pasm work?
The docs seem to imply it does 19:13
NotFound I don't think imcc has that capability, at least with the -o optio
supergiantrobot The docs definitely think .pasm should run 19:14
NotFound A .pasm file should run, but Is a pasm what you have? 19:15
supergiantrobot yes
Hmmm
I created a new pasmand it works 19:16
the other pasm is generated
NotFound Please nopatse sum.pir 19:17
supergiantrobot It is here ... docs.parrot.org/parrot/devel/html/d...o.pod.html
NotFound Summing squares? 19:18
supergiantrobot Yes
dalek TT #745 created by Austin_Hastings++: Make `newclass ` and `newclass ` consistent 19:19
supergiantrobot Seems to loop forever
19:20 Austin_Hastings joined
Austin_Hastings Hello, #parrot. 19:20
NotFound Ah, yes, there is a comment in the generated pasm
supergiantrobot I saw
But I looked at the ticket 19:21
NotFound Using -t1, looks like it never gets to start running bytecode.
supergiantrobot weird
any suggestions? 19:22
purl any suggestions are welcome. (including ripping it out entirely :))
NotFound I'll take some look 19:23
supergiantrobot If I convert the factorial app example to pasm and run it, it core dumps 19:27
NotFound Same here 19:30
19:31 cotto joined
supergiantrobot me mac 19:31
leopard
NotFound linux i386 19:32
Breaks at line 333. That's half-demoniac ;) 19:38
Catched the segfault, r[0] is NULL at that line 19:40
dalek rrot: r39435 | NotFound++ | trunk/compilers/imcc/parser_util.c:
[cage] add an assertion
 19:44
19:56 supergiantrobot joined 20:01 Austin_Hastings left
supergiantrobot NotFound 20:07
purl NotFound is JuliƔn Albo <mailto:julian.notfound@gmail.com>
supergiantrobot Any luck?
Workaround?
purl Workaround is to force Perl to use magical string
NotFound Just catched the segfault with that assertion, nothing more by now 20:08
supergiantrobot OK
Is it supposed to work?
NotFound Don't know how to work around ir, I'm not fluent with pasm
Infinoid purl, forget Workaround 20:09
purl Infinoid: I forgot workaround
NotFound At leaste is supposed to not segfault and to not loop forever.
supergiantrobot right 20:10
NotFound Looks like get_params without args has something to do with the segfault 20:14
supergiantrobot command-line args? 20:15
NotFound The get_params opcode
supergiantrobot ah
20:17 supergiantrobot joined
NotFound Yes, if I add "0" to that line it doesn't segfault. 20:17
Looks like both the pasm generator and the pasm parser are broken, 20:18
main: 20:20
get_params
end
This minimal example segfaults
dalek rrot: r39436 | NotFound++ | trunk/compilers/imcc/parser_util.c:
[imcc] die politely on get_args and other opcodes when compiling pasm
 20:30
NotFound That catches the factorial.pasm crash, but not the sum.pasm problem 20:32
Infinoid ./src/pmc/bignum.pmc: In function 'bignum_div_bignum_float': 20:40
./src/pmc/bignum.pmc:483: warning: 'bn' may be used uninitialized in this function
Looking at the code in question, that does indeed look broken. But it apparently hasn't been touched in months, so I'm not sure why the warning suddenly showed up 20:41
NotFound Infinoid: maybe it has flourished because of the station ;) 20:43
20:44 bacek joined 20:45 jan joined 20:47 supergiantrobot joined
Infinoid Maybe it's exposed because I configured with --optimize *shrug* 20:47
NotFound Infinoid: I think so 20:48
Infinoid Coke: Is it possible to configure partcl against a parrot checkout (non-installed) yet? I want to expand my benchmarking/profiling suite a bit 20:51
opbots, names 20:52
hmm, looks like not 20:53
lua can't either, but then, lua doesn't even provide a --parrot-config option, so it doesn't get my hopes up. 20:54
NotFound I think I've now a better catch :) 20:56
dalek rrot: r39437 | NotFound++ | trunk/compilers/imcc/parser_util.c:
[imcc] die politely on get_args and other opcodes used without args when compiling pasm
 20:57
NotFound supergiantrobot: now catches both factorial.pasm and sub.pasm 20:58
s/sub/sum 20:59
Infinoid profiles rakudo build step 1 (running PGE to create src/gen_grammar.pir) 21:01
NotFound supergiantrobot++ for the report 21:03
supergiantrobot Hey 21:05
Does it work?
purl i heard Does it work was it used? =-)
supergiantrobot NotFound?
purl NotFound is JuliƔn Albo <mailto:julian.notfound@gmail.com>
NotFound supergiantrobot: no, as the comment in the generated code says, generated pasm files are b0rken 21:06
supergiantrobot Hmmm
I am working on an article
I wanted to include the PASM for sum.pir 21:07
NotFound I think you can fix them by editing the set_returns and get_params opcodes generated
supergiantrobot I am not down with PASM
How?
URL to example? 21:08
NotFound supergiantrobot: you can compile the pir to pbc and look at the disassembly
supergiantrobot k
NotFound Mmmm... not very useful for the set_returns 21:09
supergiantrobot which tools disassembles? 21:10
NotFound pbc_disassemble
Forget it, is not useful for hand written pasm 21:11
purl NotFound, I didn't have anything matching it, is not useful for hand written pasm
supergiantrobot i disassembled. 21:12
does it 21:13
not too different
NotFound I think you can just delete the no-args set_returns and get_params 21:14
supergiantrobot Deleting set_returns works 21:15
Infinoid PGE spends 65% of its time in utf8_set_position 21:18
NotFound Infinoid: no wonder 21:19
Infinoid All that overhead completely vanishes with --encoding=ascii, and the resulting profile only has 33% as many samples 21:21
jonathan Infinoid: Really? I thought recent changes optimized that somewhat... 21:25
pmichaud for compiling the grammar -- yes, we still do that as utf8
when rakudo itself runs, it's fixed width 21:26
jonathan Ah, OK.
pmichaud I hadn't tried fixing the grammar yet -- wasn't a huge priority
Infinoid quack.glines.org/upload/infinoid/k...h_utf8.png
quack.glines.org/upload/infinoid/k...t_utf8.png
21:26 payload joined
Infinoid it's pretty. 21:26
jonathan wow. 21:27
pmichaud Infinoid: You're just running the compile-rakudo-grammar step, yes?
Infinoid yes, very first thing you get when you type "make" in rakudo
pmichaud right.
jonathan Infinoid: Curious, is spending so mcuh time in compact_pool usual? 21:28
Infinoid I don't think I can optimize UTF8SKIP() any farther, but that's where it's spending all of its time
jonathan: Spending 2% in GC doesn't seem too bad to me
jonathan True.
Well, a lot of the cost is in memcpy 21:29
pmichaud okay, I'm confused.
pgc.'command_line'(args, 'target'=>'PIR', 'combine'=>1, 'transcode'=>'iso-8859-1')
it looks to me as though it's already switching to iso-8859-1
(that from runtime/parrot/library/PGE/Perl6Grammar.pir:69) 21:30
Infinoid Seems to me that PGE is a compile-time cost, so it shouldn't be as high a priority for rakudo as runtime performance
Still, it was a bit surprising.
pmichaud it is a compile-time cost for building the compiler, yes.
for parsing Perl 6 programs it's important 21:31
(ie., as part of Rakudo runtime)
but Rakudo already takes care of that.
anyway, I'm surprised that the grammar isn't already transcoding to fixed width. I wonder if the grammar has any characters outside of the iso-8859-1 set in it. 21:32
Infinoid I can try a spectest, I suppose
supergiantrobot Is there a roadmap online?
Infinoid supergiantrobot: trac.parrot.org/parrot/wiki/ParrotRoadmap
oops, dead link 21:33
supergiantrobot Thanks
Infinoid trac.parrot.org/parrot/roadmap
pmichaud the rakudo spectest won't (shouldn't) show any difference
the speed of the Perl6Grammar step doesn't matter once Rakudo is compiled
Infinoid right, but I was thinking it would show how correct it was
supergiantrobot Hmmm 21:34
A little sparse.
What's on the menu for 2.0?
Infinoid (if we hit an encoding error, it would probably show up as methods/operators not found, or the like)
supergiantrobot Perl 6?
purl Perl 6 is probably amazing.
pmichaud HLLCompiler traps transcoding errors and aborts the transcode
Infinoid ok 21:35
pmichaud so, it tries to convert the source to ascii/iso-8859-1, but if that conversion fails for some reason then things are done using whatever the input source was
(utf8 in this case)
Infinoid PGE completed successfully with --encoding=ascii, if that helps. I'm not terribly familiar with the parsing side of parrot, so please excuse my ignorance
pmichaud well, that would probably ultimately fail. 21:36
Infinoid <-- low level guy
pmichaud because the input file isn't ascii.
so, PGE will parse it okay, but the code it generates won't be correct (literals, mainly)
Infinoid Ok, that's what I was afraid of. I'll try iso-8859-1 21:37
pmichaud well, the --encoding parameter really needs to be utf8, since that's the encoding of the grammar.pg file
--encoding doesn't do any transcoding, it just tells HLLCompiler how to read the file
more to the point, valid values should be utf8 and fixed_8
because we're specifying the encoding, not the charset
Infinoid Right. So I'm really profiling the wrong thing to begin with 21:38
Infinoid looks into reducing calls to memcpy 21:39
supergiantrobot Is THE Perl 6 going to run on Parrot? 21:42
bacek good morning 21:44
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
NotFound supergiantrobot: there is no THE Perl 6
supergiantrobot: anything that meets the specifications will be called Perl 6
supergiantrobot How about A Perl 6?
purl A Perl 6 is amazing.
NotFound supergiantrobot: rakudo in perl 6 on parrot 21:45
s/in/is
nopaste "bacek" at 114.73.186.208 pasted "Possible utf8 speedup for Infinoid to check." (39 lines) at nopaste.snit.ch/16814 21:46
bacek Infinoid: can you try your benchmark with patch from nopaste?
It basically select direction of String_iter movement instead of always start from start. 21:47
Infinoid Sure, one moment 21:48
hmm, 1 out of 1 hunk FAILED -- saving rejects to file src/string/encoding/utf8.c.rej 21:49
bacek yak. I was sure that diff was against trunk...
jonathan supergiantrobot: For more info on Rakudo see www.rakudo.org - I think it's probably fair to say that it's the biggest compiler currently built on PCT.
supergiantrobot Is there a scorecard of which languages are where on Parrot?
Will do. 21:50
Infinoid I'm trying to apply it to trunk r39436, plus a couple of other (non-utf8) performance tweaks
NotFound supergiantrobot: www.parrot.org/
purl www.parrot.org/ is the new homepage and feather aka www.parrotvm.org/
nopaste "bacek" at 114.73.186.208 pasted "utf8_set_position full version for Infinoid" (25 lines) at nopaste.snit.ch/16815 21:52
bacek Infinoid: in nopaste is how utf8_set_position look after patch. Just in case
Infinoid oh, I said "non-utf8" but I did put a likely() in there and forgot about it. My bad.
Infinoid hand-merges
Reducing calls (well, macro invocations) of UTF8SKIP would indeed improve performance 21:55
profiling now
The last time, it ended up calling UTF8SKIP about 8 billion times
bacek There is still a lot of UTF8SKIP. But it should be less when we just rollback few characters 21:56
21:56 clinton left
bacek gotta go soon. 21:56
nopaste "supergiantrobot" at 24.211.234.118 pasted "draft of article about parrot for Linux Pro magazine" (452 lines) at nopaste.snit.ch/16816 21:57
Infinoid Ok, this patch didn't make much difference for the PGE use-case
65% became 63% 21:58
But I can give you per-line percentages if you want more detail
supergiantrobot If anyone has time to proof the article, I would welcome the feedback.
bacek Infinoid: yes please
Infinoid bacek: It's about the same as before... 59% of time spent in UTF8SKIP, this time in utf8_skip_forward() 22:00
supergiantrobot: Awesome. I'll have a look as soon as I'm done with this profiling stuff
jonathan supergiantrobot: will read it also
supergiantrobot Great.
My email is martin.streicher@gmail.com.
It is missing Figure 1, because I have to draw it this evening,
But it'll depict what is there in words. 22:01
bacek Infinoid: how it distributed over utf8_skip_* in utf8_set_position?
supergiantrobot If you send me a note, I'll be sure to thank you in the credits.
If you have an official role in the project, let me know what it is in the email, too. 22:02
Infinoid bacek: 2284 calls to backward, 117828 calls to forward
It's a little hard to read in kcachegrind, because those functions got inlined 22:03
If it helps, utf8_set_position's biggest caller for this PGE benchmark was get_codepoints (called 85857 times) 22:04
supergiantrobot Thank you 22:06
bacek Infinoid: oh shi... get_codepoint always start from start... 22:09
Infinoid bacek: Do you have kcachegrind installed? If so, I can send you the callgrind data 22:10
bacek No surprise it SLOW.
Infinoid If you have a better idea, we can always update or extend the API :) 22:11
bacek Infinoid: bacek@bacek.com. I'll check it later
Infinoid Ok. I'll rebase on stock trunk so your line numbers will match up 22:12
bacek I have better idea. Separate array-of-bytes and STRING... 22:18
Infinoid (email sent) 22:19
pmichaud separating array-of-bytes doesn't help a lot in PGE's case. It wants to work with characters/codepoints 22:23
and I already know some ways to optimize PGE for the utf8 case
I had already tried a version of utf8_skip_backward and also found it wasn't terribly helpful. 22:24
the trick is to keep PGE from always having to start from the beginning of the utf8 string. 22:25
bacek we shouldn't internally work with utf8. Utf8 is transport encoding only...
pmichaud agreed, but we don't have another representation.
bacek ucs2? 22:26
purl i heard ucs2 was crippled also
pmichaud at the moment, ucs2 on Parrot requires ICU.
bacek afaik ICU is mandatory for Parrot now, isn't it? 22:27
pmichaud not until 2.0
bacek ah, ok.
pmichaud (well, 1.5)
bacek gotta go. See you tomorrow. 22:28
Infinoid that Linux Pro article is a little confusing to read, I think an "if-then-else" construct is an object on the PAST level but definitely not on the PIR level (which is what I originally thought when it said "object")
I guess for me, "Parrot object" == PMC 22:30
22:31 rg joined
NotFound Will not be easier to recode the utf8 to ucs2? 22:33
Ah, don't read the last part
I don't think recoding utf8 to ucs2 will need to require icu.Is just utf8 decoding, which is just bit manipulations. 22:35
22:36 Zak joined 22:59 Zak joined 23:12 david joined 23:16 Austin_Hastings joined
NotFound Austin_Hastings: I've seen #745, but I don't think that using semicolons as namespace separator in new 'string' is supported. 23:28
jonathan It's not - use a key.
NotFound I mean newclass
jonathan Same.
If somebody has tuits, upgrading squawk to use $<foo>.ast rather than $( $<foo> ) would be nice. 23:31
NotFound So the problem is not that it does not take methods from the namespace, is just there is no the same class/namespace.
Austin_Hastings So the format that parrot reports class names in is not one of the supported ones for newclass? 23:33
NotFound Austin_Hastings: no. I thinked about that some days ago, more consistency will be helpful. 23:34
Austin_Hastings :-X 23:35
jonathan Austin_Hastings: It's just a debug/dumping format for the key. It hadn't occurred to me as confusing before, but I can see the potential for confusion. 23:36
Austin_Hastings Ahh, okay. Using newclass [ 'Foo' ; 'Bar' ; 'Dog' ] produces class-already-register error. Changing to ... 'Cat'] gets better behavior. 23:38
Amended, but I cannot close. Will one of you close out #745, please? 23:41
Do Iterator's have any kind of performance advantage when looking up the values of a hash? 23:42
That is, if I do $P0 = shift iter ; $P1 = iter[$P0] 23:43
is that faster than doing $P0 = shift iter ; $P1 = hash[$P0] ?
dalek TT #745 closed by Infinoid++: Make `newclass ` and `newclass ` consistent 23:44
Austin_Hastings Thank you, Infinoid. 23:45
jonathan Austin_Hastings: Heh, I didn't even know you *could* do that! 23:47
(on the Iterator)
Austin_Hastings Oh. Yeah.
jonathan Austin_Hastings: IIRC though, the Iterator contains a reference to the Hash PMC
Austin_Hastings It does.
purl stays quiet
jonathan In which case it'd be an extra level of indirection.
Austin_Hastings So the hash pmc's don't try to cache the last lookup or anything? 23:48
NotFound I hope not. 23:51
Austin_Hastings Actually, that'd be the job of the iterator. Seems like a common case for the indexing behavior - they ought to do it.
(Especially considering how much stuff is built on hashes...) 23:52
Well, better for me that they don't. I can generate hash[key] with no guilt.
:)

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!