Parrot 2.5.0 Released! | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere | Priorities: merge gc_massacre, remove deprecated items, add deprecation notices for 2.6, close tickets.
Set by moderator on 25 June 2010.
whiteknight bacek: you're going to replace Parrot's POST with PIRATE's POST? 00:09
bacek_at_work whiteknight, yes.
whiteknight bacek_at_work: you duplicate all the necessary functionality? 00:10
bacek_at_work whiteknight, what do you mean? At the end of the day we will emit PBC from POST without IMCC
And I (and cotto++) _implementing_ new functionality.
whiteknight nice
your POST will be able to do all that current POST can do, and more? 00:11
bacek_at_work It's extension of current POST. Less stringish, more semantic.
00:11 hercynium joined
whiteknight okay 00:12
nice
bacek_at_work So, workflow will be HLL->PAST->(optimizations)->POST->(optimizations)->PBC.
For PIRATE: PIR->POST->(optimizations)->PBC (without PAST phase)
whiteknight very nice 00:13
what is speed like? Is the POST->PBC transformation as fast (or faster?) than current POST->PIR->IMCC->PBC? 00:14
bacek_at_work POST->PBC is fast. PIR parsing is really slow...
whiteknight fast fast?
bacek_at_work I don't know. It's orders of magnitude faster than parsing... 00:15
whiteknight is it faster than IMCC? 00:16
(that's all that realy matters)
bacek_at_work no. It doesn't really matter if "pirate" can produce better PBC. 00:17
bacek@illusion:~/src/pir$ cat t.pir
.sub main
say "Hello, World!"
.end
bacek@illusion:~/src/pir$ ./installable_pir --stagestats t.pir
purl .sub main is the entry right?
bacek_at_work Stage 'parse': 0.0551929473876953 sec
Stage 'post': 2.19345092773438e-05 sec
Stage 'pbc': 0.0018608570098877 sec
Hello, World!
purl rm -fr /
bacek_at_work purl, forget .sub main
purl bacek_at_work: I forgot .sub main
bacek_at_work bacek@illusion:~/src/pir$ ./installable_pir --stagestats fib.pir 00:18
Stage 'parse': 1.10337996482849 sec
Stage 'post': 2.50339508056641e-05 sec
Stage 'pbc': 0.00861501693725586 sec
fib(28) = 317811 1.76277303695679s
so, making PBC takes milliseconds. Parsing - seconds... 00:19
whiteknight okay, that's good 00:20
Overall, will the new system be faster than the old system, if we skip PIR/IMCC? 00:21
bacek_at_work Unlikely. Parrot isn't fastest bird. And we fly on half wings. 00:22
whiteknight we need soooo much optimization 00:26
bacek_at_work indeed 00:29
self-hosted pirate with even few enabled optimizations will be good start. 00:30
whiteknight yeah 00:33
We need to optimize Parrot so PIRATE runs faster 00:34
bacek_at_work Most of it is algorithmic nqp optimizations... 00:37
whiteknight probably true 00:51
okay, this kakapo error has eaten enough time today. I'm going to bed 01:05
goodnight
01:06 abqar_ joined 01:09 patspam joined 01:15 Coke joined
dalek rtcl-nqp: 74889b4 | mdiep++ | (2 files):
Fix the subroutine reference for [lsort -integer], passing 3 TODO tests
 01:27
sorear bacek_at_work: are you aware of the plan to move POST out of Parrot and into NQP-rx?
bacek_at_work sorear, nope... When it was decided? 01:31
sorear I don't know
bacek_at_work I don't know either... 01:32
afk # meetings
sorear pmichaud told me, but I don't remember enough details to do a loggrep
dalek rtcl-nqp: 770cdcb | mdiep++ | (2 files):
Implement [lsort -real]
 01:33
atrodo So, who or where do I report NQP bugs? 01:37
sorear github issue tracker 01:41
perl6/nqp-rx
alternatively pmichaud if he's on
atrodo cool. I see if I can catch him tomorrow then. 01:52
dalek rtcl-nqp: 66c822f | Coke++ | docs/overview.pod:
slight improvement to docs.
 01:56
rtcl-nqp: 9406010 | Coke++ | (2 files):
[array get] returns '' if called on a non-array.
rtcl-nqp: e3a399e | Coke++ | (2 files):
handle last edge cases of [array names]
rtcl-nqp: 297e2ca | Coke++ | (3 files):
Add ^ and $ support to ARE
rtcl-nqp: dd7abe2 | Coke++ | src/ (5 files):
use more idiomatic nqp
rtcl-nqp: dabdbaa | Coke++ | src/Partcl/commands/main.pm:
make [puts] lookup channel ids instead of hardcoding them.
rtcl-nqp: ff91a97 | Coke++ | (2 files):
flesh out [gets]; handle arbitrary channels & varName param.
rtcl-nqp: 8373f83 | Coke++ | (2 files):
Merge branch 'master' of github.com:partcl/partcl-nqp
rtcl-nqp: 2086b00 | Coke++ | (2 files):
Merge branch 'master' of github.com:partcl/partcl-nqp
sorear karma Coke
purl coke has karma of 4600
02:01 kid51 joined
kid51 msg Util Thanks for feedback on branch; will apply your suggestions Monday. 02:16
purl Message for util stored.
02:33 tcurtis joined 02:36 ash_ joined
dalek rrot: r47892 | jkeenan++ | branches/cfunctionsdocs/config/gen/platform (3 files):
Documentation corrections suggested by Util++.
 02:41
02:57 Andy joined
dalek rrot: r47893 | petdance++ | trunk/t/tools/pbc_disassemble.t:
remove unused IO::File use
 02:57
02:58 theory joined
dalek kudo: 9993ee9 | pmichaud++ | src/builtins/Parcel.pir:
Refactor Parcel assignment to be lazier, use &infix:<=>. Fixes RT #75950.
 03:04
03:07 janus joined
dalek rtcl-nqp: 5380b9b | Coke++ | (3 files):
stub out [binary] enough to run t/binary.t
 03:09
kthakore howdy hai 03:35
03:36 TiMBuS joined 03:42 LoganLK joined
dalek rtcl-nqp: ab9b0d2 | Coke++ | (3 files):
Stub a little more [info] so we can run the test file to completion.
 03:49
tcurtis Hi, kthakore. 03:50
03:59 Austin joined
Austin So parrot 25 won't build for me at all - out of memory in pmc2c.pl even with 1gig of assigned ram. 04:01
How badly did pmc2c get changed recently?
Coke Austin: what is "parrot 25"? 04:04
Austin The release 2_5_0 tag
Coke and welcome back!
purl it's good to be home again.
Austin Thanks.
Coke I don't think pmc2c has changed much at all.
it was ops2c that got the big change. 04:05
Austin Now that the US is out of the world cup, I guess I can do some parrot...
:)
Well, that's frabjous.
Coke you can always just hack on partcl-nqp again! 04:15
Austin No I can't - I can't get parrot to build. :(
I wonder if this is a path issue again... (installed vs built)
04:29 eternaleye joined
cotto What's all this about moving POST into nqp? 04:42
I guess it makes sense if POST is produced by nqp-based compilers.
wb Austin. You may be glad to know that it's my job to work out a new more user-friendly deprecation policy. 04:43
NotFound And developer-friendly, I hope. 04:54
cotto A little less than the current one. The basic idea is that no deprecation gets committed until there's a page on the wiki that describes how users can upgrade their code to accommodate it. 04:56
NotFound Looks a lot more friendly to me. 04:57
cotto by "developer" I mean "core Parrot hacker". I consider anyone else to be a user.
You get to wear both hats.
NotFound I consider myself a core parrot and I hate all last month deprecations. 04:58
Just last month because I don't want to make more memory right now ;) 04:59
plobsing wait, each deprecation item gets its own wiki page? that seems like only a slight improvement. What would be really good is a compendum of all deprecation changes between releases. 05:01
cotto not quite
each version transition gets its own wiki page 05:02
plobsing ok. does that page contain a list of change descriptions or a list of change wiki pages? 05:03
cotto That's something I'll figure out. The index page would probably have a short summary of all deprecations and a link to a page with more thorough descriptions. 05:05
05:12 fperrad joined
dalek kudo: aea3bbc | pmichaud++ | src/Perl6/ (2 files):
Add statement_mod_cond:sym<when>. Resolves RT #75916.
 05:29
cotto pmichaud, ping 05:32
dalek rrot: r47894 | NotFound++ | trunk/t/pmc/filehandle.t:
test FileHandle is_closed
 05:58
kudo: 05684c0 | pmichaud++ | src/Perl6/Actions.pm:
Change handling of return value in empty statementlist. Partially resolves RT
 06:26
purl dalek: that doesn't look right
cotto I'd appreciate eyeballs on trac.parrot.org/parrot/wiki/ParrotDeprecations . It's quite incomplete, but I'd like to know if the format is ok or if there's something I'm missing. 06:53
06:56 baest_ joined
moritz looks nice 07:03
dalek tracwiki: v1 | cotto++ | ParrotDeprecationsFor2.6 07:05
tracwiki: initial version with a couple examples
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
tracwiki: v1 | cotto++ | ParrotDeprecations
tracwiki: initial version, appalingly incomplete
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
tracwiki: v2 | cotto++ | ParrotDeprecations
tracwiki: make link more prominent
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
tracwiki: v3 | cotto++ | ParrotDeprecations 07:38
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
tracwiki: v1 | chromatic++ | LinearScanRegisterAllocation
tracwiki: initial description of algorithm
tracwiki: trac.parrot.org/parrot/wiki/LinearS...ction=diff
07:52 eternaleye joined
dalek tracwiki: v3 | cotto++ | HowToDeprecate 08:28
tracwiki: rough outline, needs fleshing out
tracwiki: trac.parrot.org/parrot/wiki/HowToDe...ction=diff
08:30 clinton joined 08:45 eternaleye joined
moritz tcurtis: Tree::Pattern::Match stores the original node in $!from... 08:52
tcurtis: the Regex matches store the matching *position* in from
tcurtis: and the matches string in $!orig
tcurtis: it would be less confusing if you adapted the same terminology
dalek rrot: r47895 | plobsing++ | branches/dynop_mapping (3 files):
fixup op_func_table hijacking in event handling
 08:58
tcurtis moritz: So, $!orig would be preferable for storing the node that matched? 08:59
moritz tcurtis: yes
actually only the name of the accessor counts :-) 09:00
nopaste "moritz" at 192.168.1.3 pasted "I want to search for assignment ops with known "returns" type as second argument - reasonable?" (15 lines) at nopaste.snit.ch/21625
moritz tcurtis: does the code in the nopaste look sane? 09:01
tcurtis moritz: yes. Also, is there any other information about the match that you think might be useful to provide accessors for other than what node matched and whether the match succeeded? 09:03
moritz tcurtis: I don't know, maybe the a pointer to the parent node, if any? 09:04
I don't think I need it for my purposes
btw how do you debug PAST trees? with _dumper() ?
I found that _dumper prints to STDOUT by default, so the dumper output ends up in the .pir files, because rakudo's Makefile uses > shell redirection :/ 09:07
bacek moritz, check github.com/bacek/pir/blob/master/t/test_post.pir for "workaround idea" 09:09
Starting from line 25 09:10
moritz oh, setstdout
purl setstdout is in src/io/io.ops
moritz bookmarks
bacek++ # thanks
bacek moritz, you welcome :)
tcurtis Data::Dumper is what I usually use, as well as --target=my_optimization_method_name, and often liberal dose of other output statements. Downside being that the output does interfere with actually compiling the code. So far, all of the optimizations I've worked on have been simple enough that looking at the optimized PAST is easier than looking at the generated PIR and running it, though, so it hasn't been a big problem for me. 09:16
nopaste "moritz" at 192.168.1.3 pasted "dump to STDERR, inspired by bacek++" (12 lines) at nopaste.snit.ch/21626 09:19
moritz that's what I use now
moritz -> gone
tcurtis I'm going to bed now(past 4 AM for me now). moritz, as always, if you have any more suggestions or questions or problems or whatever, let me know. I'll add a .orig accessor tomorrow(probably will keep the .from as an alias for now at least, since what documentation is available still mentions it, and someone else might be using Tree::Pattern without my knowing and thus might be aware of the change). bacek, I'm probably going to alternate between writing tes 09:25
the newly generalized stuff and working on that optimization for PIRATE.
09:59 gbacon joined 10:05 cygx joined
mikehh msg whiteknight, I ran splint against src/hash.c in hash_allocator, there are some real nasties according to it including: src/hash.c:826:10: Variable old_bi used after being released 10:12
purl Sorry, I've never seen whiteknight, before.
mikehh msg whiteknight - I ran splint against src/hash.c in hash_allocator, there are some real nasties according to it including: src/hash.c:826:10: Variable old_bi used after being released 10:15
purl Message for whiteknight stored.
cygx what's the status of asynchronous sockets? do they work as advertised in socket.pmc?
mikehh cygx: I doubt it - we certainly don't have much in the way of tests for it 10:20
10:22 mmcleric joined
cygx mikehh: ok, thanks; I'll give it a try when I have some more free time later this week and see what I'll find 10:28
bacek cygx, they are not async. I know just because I've implemented them. And was too lazy/busy to fully implement AIO... 10:30
cygx bacek: any chance for async sockets before R*? 10:33
bacek cygx, unlikely. It's a big chunk of work.
Especially for cross-platform AIO.
sorear cygx: just use blizkost already 10:35
cygx sorear: that's the most likely outcome; are you interested in writing some nice Perl6 wrappers for Perl5 async sockets? ;) 10:39
dalek tracwiki: v63 | sorear++ | ParrotQuotes 10:40
tracwiki: renaming POST with NFG
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
sorear cygx: not at this time 10:41
10:51 lucian joined
moritz runtime/parrot/library/postgres.pir doesn't declare a .HLL 11:06
is that intentional? or an accidental omission?
dalek rrot: r47896 | chromatic++ | branches/hash_allocator/src/hash.c:
[src] Improved hash_value_to_number();

as a STRING or a PMC. They numify to 0.0 now; we can throw an exception as necessary.		 11:25
rrot: r47897 | chromatic++ | branches/hash_allocator/src/hash.c:
[hash] Fixed uses of PARROT_DATA_TYPE enum.
rrot: r47898 | chromatic++ | branches/hash_allocator/src/hash.c:
[hash] Tidied code and fixed compiler warnings.
rrot: r47899 | moritz++ | trunk/runtime/parrot/library/Pg.pir:
[Pg] update documentation; connectdb is not a class method these days (and not tested as being one)
bacek moritz, ping 11:33
moritz bacek: pong
bacek moritz, please reopen TT#1692 (pg). We _do_ want tests for everything shipped with Parrot. 11:34
moritz done. 11:35
bacek thanks!
dalek TT #1692 created by moritz++: postgres libraries don't work from foreign HLLs 11:37
TT #1692: trac.parrot.org/parrot/ticket/1692
TT #1692 closed by moritz++: postgres libraries don't work from foreign HLLs
TT #1692: trac.parrot.org/parrot/ticket/1692
TT #1692 reopened by moritz++: postgres libraries don't work from foreign HLLs
TT #1692: trac.parrot.org/parrot/ticket/1692
moritz bacek: would adding a .HLL 'pg_test' to the start of the test file be enough? 11:38
bacek: then all tests are run in a different HLL, and act as a test for TT#1692
bacek moritz, I have no idea. But I would like to have same policy for Parrot as Rakudo have (from testing perspective) 11:39
11:39 nopaste joined
moritz understandable 11:41
dalek rrot: r47900 | moritz++ | trunk/runtime/parrot/library/Pg.pir:
[Pg] be in the parrot HLL
 11:42
11:55 ruoso joined
cygx I'm currently building parrot + rakudo on cygwin 11:59
one minor problem: make install didn't install cygparrot*.dll, ie the rakudo build couldn't find it, so I moved it to usr/local/bin manually
moritz cygx: please submit a ticket for that 12:00
cygx: by sending a mail to rakudobug@perl.org
cygx I now get another failure, though: cannot find -lparrot ; make: *** [src/pmc/perl6_group.dll] Error 1
moritz: wouldn't that be a parrot bug? 12:01
moritz cygx: if it's parrot's 'make install' then yes 12:02
cygx moritz: yes, sorry I wasn't clear - parrot's make install works, but doesn't install a file necessary for building rakudo via --parrot-config=... 12:03
moritz cygx: then a parrot bug, yes
12:11 awhitworth joined
whiteknight Good morning, #parrot 12:14
bacek Good morning, awhitworth^W whiteknight 12:16
12:23 ruoso joined
dalek TT #1693 created by cygx++: `make install` doesn't install all files necessary to build Rakudo on ... 12:26
TT #1693: trac.parrot.org/parrot/ticket/1693
whiteknight hello bacek, how are you? 12:27
12:31 ruoso joined
bacek whiteknight, I'm still aliv^W operational. 12:34
whiteknight rough weekend? 12:40
12:43 whiteknight joined
bacek whiteknight, rough Monday actually. 12:44
whiteknight oh. Mondays are the worst 12:46
I just started mine. Not looking forward to it
mikehh hi there, whiteknight
whiteknight hello mikehh 12:48
I got your messages.
mikehh whiteknight: yeah, I ebentually managed to install splint and get it running, it reports quite a few problems 12:49
eventually 12:50
purl it has been said that eventually is a big word.
whiteknight purl forget eventually
purl whiteknight: I forgot eventually
mikehh whiteknight: do you have a copy of it
Coke attempts to be a bacek-style robot on partcl-nqp
whiteknight mikehh: splint? no
mikehh or any lint for that matter? 12:51
arnsholt whiteknight: I've found a quick fix for the next thing you found in NQP 12:53
But I'm pretty sure it's not a very good fix =) 12:54
whiteknight arnsholt: yeah, I saw your comment 12:56
I only noticed because Kakapo had a "next()" built-in to emulate that funcitonality before NQP-RX added it, so when I updated kakapo, all it's uses of next() now create evil failures
mikehh: no lint either. I used to have it 12:57
nopaste "mikehh" at 192.168.1.3 pasted "splint output for hash_allocator for src/hash.c at r47898" (409 lines) at nopaste.snit.ch/21630 13:02
mikehh whiteknight: fun reading :-} 13:03
btw it reduced from 146 to 131 warnings after chromatic's patches 13:07
Coke hey, anyone want to write some regexp tests... (in tcl?) 13:15
almost no actual tcl knowledge required. =-) 13:16
mikehh Coke: :-}
whiteknight chromatic patched the branch? 13:17
13:18 mmcleric joined
mikehh yeah, r48986-9 13:18
still fails though 13:19
whiteknight: I tried some changes, but it still failed to work
13:22 plobsing joined
mikehh sorry r48989 was morritz, r47986-8 13:23
too many r's, keep forgetting to use completion :-{ 13:25
whiteknight I'm going to look at it again in a little bit. I'm taking one last look at kakapo before I give up in disgust
arnsholt whiteknight: Well, the next() thing should be mostly a matter of regex search and replace
Coke anyone using nqprx who has done their own HLL .annotations for error handling on top? 13:26
arnsholt Rakudo perhaps? 13:28
moritz yes, rakudo does it 13:32
github.com/rakudo/rakudo/blob/maste...Printer.pm for example
Coke moritz: \\o/ rakudo did something I can steal. :P 13:34
er, :)
13:36 JimmyZ joined
Coke moritz++ ; that definitely looks promising. 13:36
must not look at it until after $DAYJOB.
moritz Coke: maybe it would be worth to generalize, and move into nqp 13:37
Coke moritz: maybe, but tcl's backtraces are unique, of course. 13:44
jnthn Coke: You implement a method 'backtrace' in your Compiler object (your subclass of HLL::Compiler) 13:46
Coke: Rakudo's one just calls the thingy moritz++ pointed to, since I didn't want to write something like that in PIR
Coke jnthn: just adding "sub backtrace" to the class doesn't seem to get it invoked when you error out. 13:51
jnthn Needs to be method, not sub
13:51 kid51 joined
Coke shiny! 13:52
13:52 cygx left
Coke jnthn++ 13:56
13:56 bubaflub joined
Coke now I just need to figure out where to add in my own annotations, and how to ignore the PIR ones. 13:57
... and completely reformat the backtrace.
but this would have been MUCH more difficult without pct. \\o/
jnthn Coke: How are you doing code gen? 14:01
PCT?
purl hmmm... PCT is the Parrot Compiler Toolkit
jnthn stfu bot
Coke jnthn: with partcl-nqp, using nqp-rx and pct, yes.
jnthn Coke: In that case, I think provided you are setting :node($/) in your Actions.pm, then the .annotate 'line', 42 ones will already be being set for you. 14:02
14:02 Andy joined
kthakore jnthn: yeah that is it! Abuse that guy! 14:05
14:05 mmcleric_ joined 14:06 PacoLinux joined, mmcleric joined
nopaste "coke" at 192.168.1.3 pasted "tcl backtraces" (17 lines) at nopaste.snit.ch/21634 14:08
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#34621), fulltest) at r47900 - Ubuntu 10.04 amd64 (g++ with --optimize) 14:11
dalek rrot: r47901 | plobsing++ | branches/dynop_mapping/t/native_pbc (6 files):
native_pbc platform updates
 14:12
mikehh pir/PIRATE (feeef08) build ok/ test ok 14:17
partcl-nqp (ab9b0d2) builds with parrot r47900 - test PASS - Ubuntu 10.04 amd64 (g++ with --optimize) 14:23
dalek kudo: c18d372 | pmichaud++ | src/binder/bind.c:
Fix @a is copy (and %h is copy) when passed a scalar array or hash. Fixes RT
 14:51
14:58 patspam joined 15:03 fperrad joined
mikehh rakudo (05684c0) builds on parrot r47900 - make test PASS, spectest_smolder -> #34622 (pugs r31481) PASS - Ubuntu 10.04 amd64 (g++ with --optimize) 15:04
31 TODO PASSes in 8 files
15:11 lucian_ joined
atrodo Some time ago, when some of the core ops became dynops, there was an issue with changes to the op numbers. How was that finally solved? 15:34
JimmyZ removed ops.num? 15:38
IIRC
Coke I don't think it was solved. 15:43
if you dynload ops in one order in a pir library, save it out to PBC, then in your main pir, load the libs in a different order , then try to run your pbc, I think it still goes boom. 15:44
which I'd really like to get solved before 2.6
15:48 JimmyZ left, davidfetter joined
davidfetter hello 15:48
16:04 Chandon joined
Chandon In ops, does :check_event actually do anything? 16:04
cotto_work good mroning 16:06
whiteknight Chandon: I thought it did
cotto_work istr that too
Chandon whiteknight: I'm pretty sure that local branches aren't calling check_events in scheduler.c. 16:07
whiteknight hmmm
Chandon What would :check_events actually be doing. Inserting code into the op definition in core_ops.c? 16:08
Err, :check_event
16:12 theory joined
whiteknight I think so 16:13
can you name an op that has :check_events? 16:14
Chandon Only local_branch and end in core.ops. 16:15
16:15 ash_ joined
whiteknight hmm...that's interesting. Doesn't look like those call into the scheduler 16:16
I could have sworn they did
Chandon As far as I can tell, the only thing that actually calls into the scheduler is the sleep op.
And that does it because sleep is implemented in the scheduler. 16:17
whiteknight There is a check_events op
Maybe :check_events tells IMCC to insert the check_events op directly into the PBC
have a debugger handy? Set a break point in Parrot_check_events and Parrot_check_events__, and see when (if ever) they get called 16:18
ash_ does parrot have a select? (the C one for synchronous I/O multiplexing)
Chandon I've got print statements in the two functions that should get called in scheduler.c. They definitely don't get called on local_branch. 16:19
whiteknight ash_: No, not yet 16:20
Chandon: but they do get called?
ash_ alright, just wondering
whiteknight ash_: Plenty of plans for AIO with things like select/poll, but nothing implemented yet 16:21
ash_ yeah, someone was asking in #perl6 so i was just curious if any of it was implemented yet and maybe just not linked in rakudo
whiteknight cotto_work: where does the source code for opsc live? 16:23
cotto_work compilers/opsc
whiteknight ah, I was looking in runtime/
Chandon whiteknight: Parrot_cx_check_tasks never (except apparently by the check_tasks opcode); Parrot_cx_schedule_tasks once per run of Parrot, but then not again on my test cases. 16:24
whiteknight hmmm....
we have tests for things like tasks and timers, so I know that they do work somehow
Chandon The timers test works by calling sleep explicitly, which will call Parrot_cx_schedule_tasks. 16:25
whiteknight ha. So it's an example of a bad test
so we need to make check_events do what you need, if it doesn't yet 16:27
Chandon Yes. How do we do that? 16:29
whiteknight Step 1: Identify exactly what you need for your project 16:30
Step 2: We figure out what the hell the software thinks it's doing currently
Step 3: ???
Step 4: Profit!!
have you seen docs/dev/events.pod? 16:32
(that just turned up in a search)(
be back in a bit, going to lunch 16:33
16:40 hercynium joined 16:43 tcurtis joined
Coke does Compiler::evalfiles() add 'file' annotations by default? 16:43
hurm. where is the default parrot backtrace code? 16:46
that will help me figure out how it's getting any file names at all.
16:46 contingencyplan joined
jnthn Coke: It doesn't 16:50
Coke: But see Actions.pm in Rakudo
grep for iirc $?FILE
Coke jnthn: how do you skip levels that are not perl6? 16:53
is that the p6type check? 16:54
17:01 fperrad joined
jnthn Coke: I don't as such - that is actually telling me what is just a nested block and what is not 17:04
It actually skips a bit too much
17:05 bkuhn joined
whiteknight Chandon: There is lots of interesting-looking code in src/runcore/main.c. Looks like it loads information about check_events opcode into a table, but I haven't traced through where that table is used 17:07
Chandon whiteknight: For the moment, I've just cheated and added explicit calls to Parrot_cx_check_tasks to a couple of opcode definitions. 17:08
whiteknight okay, that should work too
hah, looks like evc_func_table is populated with information about check_events, but is never used anywhere 17:10
cotto_work welcome to Parrot
;)
\\
whiteknight Chandon: Okay, that's good for now. Going forward I think we're going to want a better solution 17:12
we need to modify opsc to output the function calls you need in response to the :check_events flag. Then we need to add that flag to more ops
just end and local_branch are no good
dalek rrot: r47902 | tcurtis++ | branches/gsoc_past_optimization/runtime/parrot/library/Tree/Pattern/Match.nqp:
Change .from to .orig for greater similarity with Perl 6 regexes. Keep .from as an alias for now.
purl dalek: that doesn't look right
17:16 bubaflub joined
whiteknight pmichaud: ping 17:26
cotto_work ooh. me too.
seen pmichaud 17:27
purl pmichaud was last seen on #parrot 1 days, 1 hours, 12 minutes and 35 seconds ago, saying: whiteknight: alas, I have to run off for ~30 mins also [Jun 27 16:14:44 2010]
Chandon whiteknight: What's the case where local_branch isn't good enough? 17:36
cotto_work Chandon, the discussion on python's "newthreading" proof of concept code at lwn.net/Articles/393822/ may be of interest to you. 17:40
17:42 Coke joined
dalek rrot: r47903 | khairul++ | branches/gsoc_instrument (3 files):
Completed stubbing gc functions.
 17:45
cotto_work msg khairul Instead of a huge if/else if block, you can store pointers in a hash and use that. 17:47
purl Message for khairul stored.
cotto_work msg khairul You can use parrot_new_pointer_hash to get a hash that maps between strings and C pointers. 17:51
purl Message for khairul stored.
cotto_work whiteknight, PIRATE adds some methods to core PMCs. 17:55
see the bottom of github.com/bacek/pir/blob/master/pir.pir 17:56
Is that what your post to parrot-dev is talking about? 17:57
whiteknight cotto_work: Kakapo does too, but does it in a much larger-scale and does it from NQP 18:00
but that's only a small bit of what it's about. In short, what I really want is the ability to easily access the list of methods from the namespace
what I really really want is just to figure out what was the motivation behind the design decision so that when I go in to make changes, I don't break something I don't understand 18:02
kthakore anyone got a simple ticket for a newb?
dalek rrot: r47904 | tcurtis++ | branches/gsoc_past_optimization/runtime/parrot/library/Tree/Pattern.nqp:
Change a .from call to .orig.
 18:03
purl dalek: that doesn't look right
tcurtis whiteknight: is the "from the namespace" part necessarily required?
whiteknight tcurtis: what do you mean? The methods are in the namespace PMC 18:06
tcurtis whiteknight: So, you have a namespace PMC and you're trying to get at its methods? In that case, nevermind. 18:12
whiteknight: I thought you were talking about something that could be done with "pir::get_class__PP(ResizablePMCArray).methods", for example(although I'm not sure how to do it in a way that works on both P6metaclass classes and normal Parrot classes without explicitly checking which the class is and acting appropriately). 18:14
whiteknight: by the way, github.com/perl6/nqp-rx/issues/#issue/4 is confusing. The example of a generated sub name that is hellish for debugging and the example of what would be ideal appear to be the same(although there's probably some underscores or such accidentally being interpreted as markdown, given that most of the middle of it is randomly italicized). 18:18
whiteknight The current naming scheme of nested blocks in NQP is just "_block1234" 18:21
multiple Parrot Subs could create 1 NQP sub
so if multiple Parrot Subs are part of a single NQP sub, they should be named similarly 18:22
<SubName>_block<ID>
particle your examples are still the same in that ticket
tcurtis The issue doesn't display like that, though.
whiteknight oh. Maybe github filtered out the <>
particle would you rather see block naming, or annotations, or both? 18:23
whiteknight fixedish
dalek nxed: r524 | NotFound++ | trunk/winxedst1.winxed:
fix +, - and * operators for 'val op val' case
 18:26
18:38 tcurtis joined, ash_ joined
dalek rrot: r47905 | tcurtis++ | branches/gsoc_past_optimization/t/library/pastpattern.t:
Add tests for .orig, and replace .from with .orig where it's not actually testing .from.
 18:52
Coke whiteknight: do you care about those block names because of diagnostic output? 18:54
whiteknight Coke: yeah, diagnostics and debugging
Coke (in which case, you can override backtrace to get more HLL friendly output)
whiteknight if you look at issue #5 I added, There was a problem I found in generated PIR code 18:55
Coke as I am working on today for partcl. (cribbing from rakudo)
whiteknight and that's a huge pain to track down in that output soup
Coke I haven'd had that trouble in partcl - I search for the name of the sub, which is right next to the subid, which brings me to the code I need. 18:56
So, it hasn't been a pain point for me yet. 18:57
whiteknight Sure, it's not impossible. But a little help would always be nice
it would especially make things like back traces much nicer to understand
Coke ah, I take it as an encouragement to actually customize your backtrace. =-) 19:00
but yah, nicer defaults ++
whiteknight I've never been a huge fan of the "this thing is so bad that I feel forced to fix it" encouragement 19:02
I find it often leads to "this thing is so bad that I'm going to abandon it and work on something else" 19:03
atrodo whiteknight> That's what I do 19:14
19:15 kj joined
NotFound That's why PCC got unfixed so much time X-) 19:16
cotto_work tcurtis, good blog post. It's nice to see what you're up to and even nicer that you're planning on some PIRATE hacking. 19:21
I fixed up a bit of code that needed html escaping. 19:28
ash_ whiteknight: do you think it would be okay if tomorrow during the parrot sketch i asked if I could work on the llvm runcore for the remainder of my gsoc? 19:29
Coke whiteknight: it's a question of degree, I think. You're not going to make it perfect for everyone, you can only have a sane default. the default is sane enough for me. YMMV. 19:30
or at least, i have enough other crap I'm trying to fix that I hadn't noticed so much.
19:31 simcop238 joined
whiteknight ash_: did you talk to plobsing about it? 19:32
tcurtis cotto_work: thanks.
whiteknight Coke: you're right. I'm not trying to make it perfect. But appending the name I give to the sub to all the parts of that sub is a very very small thing to make it easier for everybody 19:33
it's not like those subs don't have names
most of them, anyway
purl i heard most of them was because of the stupid 01_request failure
ash_ he said its alright, he just wants me to make sure the libffi stuff is rock solid before moving on 19:34
whiteknight is the libffi stuff rock-solid?
(we may want to start merging that to trunk if so)
at the very least, other work -> new branch 19:35
ash_ not 100% rock solid yet (a few failing tests still) but i am working on it, i just wanted to make sure others knew about my project 19:36
tcurtis If I want to unconditionally jump to a label, should I use branch or jump? 19:38
whiteknight jump, I think
tcurtis answered his own question. 19:39
Branch.
whiteknight what's the difference between the two?
particle branch === goto
whiteknight then what is jump? 19:40
tcurtis According to docs.parrot.org/parrot/latest/html/...e.ops.html , branch is "Branch forward or backward by the amount in $1" and jump is "Jump to the address held in register $1." 19:41
particle and labels are offset from the branch
whiteknight oh, gotcha.
tcurtis particle: indeed, that's the thing I was uncertain about. 19:42
19:43 LoganLK joined
tcurtis bacek, cotto: about to push optimization of "if 1 < 2 goto some_label"(although it is suboptimal, replacing "if 2 < 1 goto some_label" with a noop instead of just removing the op altogether). 19:47
correction: not optimization of that. 19:48
cotto_work do it naough
tcurtis the start of optimization of that: specifically, it only works for eq.
on a related note, is there any way to do pir:: with a dynamically chosen op? Other than eval? 19:49
whiteknight I doubt it
tcurtis Does NQP have eval? 19:52
particle it doesn't have a runtime 19:53
you can call a pir compiler
cotto_work It doesn't have much of a runtime. 19:54
whiteknight grumbles something about kakapo
cotto_work tcurtis: how do you want to use a runtime-chosen pir op?
tcurtis cotto_work: something like "pir::{$/<pirop>.orig)($/[0]<value>.orig, $/[1]<value>.orig)" 19:55
So I don't have to write out each conditional op variant. 19:56
cotto_work that sounds very runtimey 20:00
NotFound tcurtis: that sounds like "How to compile at runtime?" 20:01
arnsholt tcurtis: Even if NQP doesn't provide it directly, you can get it through Parrot 20:02
Get the compiler object and use that to evaluate arbitrary strings
NotFound arnsholt: that doesn't qualify as "Other than eval" 20:03
20:06 ambs joined
sorear opbots names 20:07
ambs Coke: finally I find you here, so I can thank you "personally" :)
sorear opbots trust arnsholt
slavorg Ok
slavorgn Ok
tcurtis is going to attempt the NQP::Compiler.eval approach. 20:08
sorear opbots trust szabgab 20:09
slavorgn Ok
slavorg Ok
sorear opbots believe ttbot
slavorgn Ok
slavorg Ok
sorear opbots beleive ilbot2
opbots believe ilbot2
slavorgn Ok
slavorg Ok
sorear opbots trust bubaflub
slavorgn Ok
slavorg Ok
sorear opbots trust atrodo 20:10
slavorgn Ok
slavorg Ok
tcurtis bacek: is there any particular reason why NQP isn't loaded in PIRATE?
atrodo Hurray! I knew my day would come if I just waited long enough! 20:11
cotto_work clock?
purl cotto_work: LAX: Mon 1:11pm PDT / CHI: Mon 3:11pm CDT / NYC: Mon 4:11pm EDT / LON: Mon 9:11pm BST / BER: Mon 10:11pm CEST / IND: Tue 1:41am IST / TOK: Tue 5:11am JST / SYD: Tue 6:11am EST /
cotto_work bacek is in SYD. He's probably not up yet. 20:12
tcurtis msg bacek is there any particular reason why NQP isn't loaded in PIRATE?
purl Message for bacek stored.
dalek TT #1694 created by NotFound++: load_bytecode semantic differs between .pir and .pbc loading 20:16
TT #1694: trac.parrot.org/parrot/ticket/1694
GeJ Bonjour everyone. 20:24
tcurtis Hello, GeJ. 20:26
20:30 masak joined
masak what's the object returned from pir::open__PSS on this line github.com/rakudo/rakudo/blob/maste.../IO.pm#L98 , and where can I read more about it? 20:31
dalek rrot: r47906 | darbelo++ | failed to fetch changeset:
Sync with trunk.
cotto_work masak, most likely a FileHandle
src/pmc/filehandle.pmc in parrot
masak cotto_work: so, my ultimate goal is to use it to read binary, not-necessarily-utf8, data. is it at all possible?
there's an .encoding method four lines down. is there a value for that method which means 'no encoding, just raw bytes'? :) 20:34
masak guesses "no"
cotto_work binary might be what you're after
masak \\o/ 20:35
so I just s/utf8/binary/ ?
cotto_work I'd guess that'd work.
masak does a happy little dance
thank you, Parrot!
cotto_work parrot welcomes you 20:36
I'm reasonably sure that that'll work. 20:38
GeJ Hi tcurtis
masak I'm about to try it.
GeJ Hej masak.
masak Hi GeJ! long time no see! 20:39
Australia, wasn't it?
GeJ Close, New Caledonia. 1 hour ahead of bacek.
masak le Caillou. nice. 20:40
GeJ been there?
masak no, only now reading the Wikipedia entry.
GeJ heh. 20:41
masak whoa -- en.wikipedia.org/wiki/File:Hienghen..._Poule.JPG
looks like a dreamy place.
atrodo Looks like an evil mad scientist's lair
GeJ If your not picky about Interwebs connectivity, it is. 20:42
atrodo: shhhhhh, It's a WIP.
atrodo silence
GeJ Hum, under gcdebug runcore, regressions.t fails on FreeBSD 7 but not at home (FreeBSD 8). 20:44
what did I do wrong this time?
masak cotto_work: ok. preliminary results. using 'binary' works, but calling e.g. .slurp after that yields the same result as with 'utf8'. how do I get at the bytes?
cotto_work you could use a ByteBuffer 20:45
tcurtis cotto_work: support for {eq,ne,lt,le,gt,ge}_ic_ic_ic implemented in the post-optimizations branch. now just for the _num/_str variants.
masak cotto_work: I'd very much like that. how can I connect it with the filehandle? 20:46
NotFound binary isn't a encoding, is a charset.
darbelo Speaking of that, that distinction needs to die. 20:47
NotFound darbelo: fully agree
masak ok, but that's politics. I'm trying to program my way to a result. how do I do that?
cotto_work NotFound: you're correct. I need to figure out a way to separate them in my head. 20:48
darbelo cotto_work: No, we need a way to make them not-separate in the code.
NotFound darbelo: but in the meantine we need to work with live parrots. 20:49
Or go to the some infamous pet shop X-)
cotto_work masak, create a bytebuffer, drop down to PIR and do bb = str to make sure that the set_string_native VTABLE function is called
From there, the ByteBuffer will let you directly address the bytes 20:50
masak cotto_work: right. that's good.
cotto_work: and having the encoding set to 'binary' will prevent the .slurp from dying, yes? 20:51
cotto_work: see, the problem right now is that reading a non-utf8 file dies during the reading.
hm. 'binary' does seem to help against this. \\o/ 20:52
atrodo gist.github.com/450522 # I think this is NQP-rx bug, but haven't had a chance to file the bug report yet 20:54
cotto_work "fixed_8" might be the proper encoding.\\
masak ok.
cotto_work That's my guess, at least.
masak that seems to work just as well.
bacek Good morning, humans 20:55
masak bacek! \\o/
NotFound Looks like FileHandle uses only two encodings: "utf8" and whatever.
bacek masak, |o/
tcurtis, why do you need "NQP" in pirate?
masak NotFound: I'm after the whatever right now, but I'm willing to call it 'fixed_8' if that makes people here happy :) 20:56
tcurtis bacek: I don't. NQP::Compiler.eval might have been a marginally more convenient way to deal with the plethora of conditional ops.
But the way I'm doing it now is surprisingly manageable(although I haven't gotten to the _num and _str variants).
bacek tcurtis, erm. Explain more?
(about .eval) 20:57
cotto_work Hmmm. The 'encoding' value only seems to be significant in its equality to 'utf8' 20:58
dalek kudo: 2acfad3 | moritz++ | src/Perl6/Grammar.pm:
complain about infix:<!%>. Closes RT #76170
kudo: cccc121 | moritz++ | (2 files):
re-enable Cool.rindex

parrot String. Also enable rindex.t
kudo: 1734e43 | moritz++ | src/core/Signature.pm:
properly reflect capture/parcel binding in signature introspection
darbelo In my experience, parrot's string and io subsystems alternate between knowing too much and too little about each other.
NotFound darbelo: given that until recently even the string subsystem doesn't knew much about itself, no wonder. 21:00
cotto_work That seems to be the case here.
tcurtis bacek: There are 18 different conditional comparison ops, each with an appropriate INTVAL-returning comparison op(with some overlap).
cotto_work $fh.encoding('asdfasdfsda') should fail more noisily than it does.
tcurtis When optimizing away constant conditionals, in determining whether to replace gt_ic_ic_ic, for example, with noop or a branch, one should use isgt. 21:01
bacek tcurtis, yes.
tcurtis, no. Why "isgt"? 21:02
bacek need coffee...
purl clowns'll eat me
tcurtis Because gt is the branching operator. You just want to whether the condition is true or not.
s/want to/want to know/ 21:03
NotFound Note that such conditionals can have secondary effects, as in: if ((i = j) > x) ...
bacek tcurtis, ah, "isgt" for folding. Yes.
NotFound, there is no such op in pir.
tcurtis NotFound: even if there were, it wouldn't be a constant conditional(or at least not in the sense of having constant arguments.. 21:04
bacek tcurtis, you can use POST::Constant.type for select proper comparison op. 21:05
NotFound I hope so, but pir sugar sometimes gives unexpected results.
tcurtis bacek: there's three way I know of to execute a pir:: op selected at runtime: if-elsif chain, a hash of subs, and eval. 21:06
bacek NotFound, POST is desugared already :)
NotFound Too much syntactic sugar gives to semantic cavities X-) 21:07
bacek tcurtis, choose from is-else of hash :)
s/of/or/
GeJ G'Day bacek
tcurtis I've been using a hash. I thought it would be more unpleasant than it is.
bacek tcurtis, we can ask pmichaud for given/when in NQP :) 21:08
dalek kudo: d18b5e7 | masak++ | src/core/Buf.pm:
[Buf] now does Positional and .[]
 21:09
tcurtis One question, though: is it possible for pir::isgt__IPP to differ from pir::isgt__ISS, pir::isgt__III, or pir::isgt__INN when the arguments are already of the appropriate type? 21:11
bacek tcurtis, erm. All variables in nqp are pmcs. You have to explicitly "cast" them to proper type. 21:14
Or I totally misunderstood question.
Yes, I am...
tcurtis bacek: if you have PMCs that you know are Integers, and no HLL mapping is involved, isgt__IPP($a, $b) should be the same as isgt__III($a, $b), right? 21:15
bacek Yes, it should.
tcurtis has just realized he doesn't have to worry about _str and _num variants of ops since they take PMC arguments. 21:16
dalek nxed: r525 | NotFound++ | trunk/examples/Mysql.winxed:
read options from json file in example Mysql
bacek cotto_work, what about implementing LinearScanRegisterAllocator for pirate? It shouldn't be too hard. 21:17
cotto_work I was thinking about that. It seems natural. 21:18
Were you suggesting I do it or asking whether it seems like a good idea?
bacek cotto_work, look at POST::Compiler. line 24. 21:22
We just need different allocator there :)
cotto_work sounds like fun 21:25
bacek cotto_work, -Ofun ftw! :) 21:26
cotto_work imma maka a new alligator 21:27
s/ka/ke/ 21:28
bacek tcurtis, (minor style rant) can you use .orig.value instead of .orig().value()? It's less noisy :)
tcurtis bacek: yes. I only recently realized NQP supports .foo 21:29
21:29 kid51 joined
masak cotto_work: I just put out a blog post. you're in it :) use.perl.org/~masak/journal/40422 21:30
bacek tcurtis, otherwise it looks pretty cool! 21:32
cotto_work plans on using his newfound fame for profit
21:32 whiteknight joined
cotto_work speaking of fame, hi whiteknight 21:33
tcurtis whiteknight: Why not just declare your method as a normal sub and use ".param pmc self"? 21:34
dalek r: c20b371 | bacek++ | src/POST/Compiler.pm:
Minor cleanups.
 21:37
21:40 wagle joined
GeJ Hi whiteknight. 21:43
whiteknight hello GeJ
tcurtis: that's just part of the problem 21:44
cotto_work I'd appreciate feedback on HowToDeprecate and ParrotDeprecations on the wiki. 21:48
tcurtis bacek: How should I go about writing tests for it? Modify the POST testing to target my stage instead? Or create a copy of the POST testing stuff that targets my stage instead? 21:49
bacek tcurtis, I think separate set of tests will be better.
tcurtis, you can pass optional "stages" parameter to sub test_post (in t/test_post.pir) to avoid code duplication. 21:50
tcurtis bacek: okay. Also, should I add my stage to the stages list in the PBC tests? 21:51
bacek tcurtis, hmm... Interesting question. 21:52
I think so. Just because without optimizations we'll generate broken PBC.
Or will not able to generate it at all. 21:53
whiteknight it bugs me that chromatic (and now allison) keep misreading my emails with an error bias towards me being more of a goober
last time I got in an argument with those two on the list none of my problems were addressed, I eventually gave up in despair, and I still have the problems I had 21:54
A little bit of "Andrew is not completely incompetent and might just be having a real problem" medicine would be nice, every once in a while 21:56
21:57 allison joined
darbelo whiteknight: You are not completely incompetent and might just be having a real problem. 21:57
allison is going to knock some heads together
are chromatic and whiteknight here?
whiteknight i am
darbelo whiteknight is.
chromatic isn't
allison I'll knock him later
whiteknight I have to go actually. baby emergency 21:58
allison you two are at logger heads, pause and listen to eachother
(quick answer)
sorear bacek: how will --target=pir work after PCT's POST is replaced with PIRATE?
21:58 chromatic joined
bacek sorear, not yet. But I can add it. 21:58
chromatic I'm read for my head knocking.
darbelo sorear: EVEN BETAR! 21:59
sorear chromatic++ tireless notes backlogging
NotFound cotto_work: HowToDeprecate: In "if possible, maintain backwards-compatibility" I'd change "If possible" to "Unless absolutely impossible"
cotto_work bacek: it seems that turning PIRATE's POST into PIR will be relatively simple.
NotFound: wfm 22:00
bacek cotto_work, it is. Just not current priority.
cotto_work so post->pir will just be an alternative to post->pbc
oic
darbelo Nice and roundtrippy. 22:01
NotFound allison: Can you take a quick look at TT #1689 ? 22:02
allison NotFound: sure 22:06
tcurtis bacek: I don't think the test_post method does support a stages parameter. 22:15
bacek tcurtis, why? 22:16
Ah, yes. It's hardcoded atm. But you can add it. ".param string stages :optional"
tcurtis Will do. 22:17
darbelo allison: I also have some questions I want to run past you, if you have the time. 22:18
allison NotFound: +1 on deprecating is_tty
darbelo: sure
darbelo I'm having some issues with the charset-encoding distinction and NFG. Mostly because I have to add new behaviour at both levels, but I'm starting to doubt the distinction is gaining us much. 22:20
bacek cotto_work, do you have "Remember the Milk" account?
darbelo, +1 to have only "unicode" charset.
cotto_work no, but I can get one on the quickfast
allison darbelo: the best work there is Simon Cozen's unicode chapter in Advanced Perl Programming 22:21
cotto_work why?
allison darbelo: it is an important distinction, though, that doesn't necessarily mean that parrot's particular implementation of the distinction is the best way to handle it
bacek cotto_work, I want to try it for pirate's todo list.
NotFound cotto_work: HowToDeprecate should document how to choose the 'eligible' release. 22:24
darbelo My problem is that transcoding stuff into NFG is easy, but I can't really find a clean way to transcode it back to other formats, since part of the logic is hidden away in the chrset layer. 22:25
allison darbelo: transcoding it back should be a simple substitution
darbelo: that is, you should be able to use NFG on *any* variable-width encoding, not just unicode 22:26
NotFound On any unicode that is unicode? 22:27
darbelo Yes, but in order for NFG to deliver on it's promise of indexability it's iterators have to return negative codepoints, which confuses the hell out of all of the other encodings.
cotto_work bacek, cotto.rtm 22:29
allison darbelo: that's true, but then codepoints don't have any meaning across encodings anyway
darbelo Our various unicode encodings assume that iteration over a string will give them valid unicode codepoints for them to re-encode. 22:30
allison darbelo: so the transcoding will have to refer to the original encoding, which will refer back to the string for the actual meaning of the fake codepoint
cotto_work there you are
allison the fake codepoint is valid, but only in the context of the original string 22:31
bacek cotto_work, check it. Do you see "parrot" shared list?
allison and, because of various normalization forms, we should already have the expectation that a codepoint in one encoding may transcode to multiple codepoints in another
(if we don't, then that certainly is broken) 22:32
darbelo I'm looking at utf8.c's to_encoding() implementation right now, and I don't think it does.
cotto_work bacek: not so far 22:33
NotFound Looks like you are looking for the slower strings ever.
bacek cotto_work, it's "pending" on my side... 22:34
darbelo NotFound: Not what I was looking for, but what I found...
allison: our utf8 transcodeing simply calls "src_iter.get_and_advance(interp, &src_iter);" and utf8_encode()'s the result. 22:35
NotFound If string codepoint length can be changed by reencoding it, will be better to use StringBuilder or ByteBuffer for *any* string operation. 22:36
darbelo NotFound: With inmutable string reencoding is a 'copy'ish operation. 22:37
allison darbelo: it's not the string iteration that needs to change, we are dealing with only one fake codepoint
darbelo: it's the utf8_encode process that needs to respect the multiple real codepoints packed within that fake codepoint
darbelo My problem is, really, with the utf8_encode() call.
allison darbelo: aye 22:38
darbelo That's kind of the point I was trying to make, though I think I mis-stated it. 22:39
NotFound utf8 functions operates with codepoints. If you provide a encoding-normalization-whatever that doesn't use real codepoints, the iterators for that things should take care, IMO 22:41
22:42 japhb joined
darbelo NotFound: I have to return the 'faked' codepoint. In a way, what I'm doing here is extend the Unicode charset. 22:43
whiteknight back
NotFound darbelo: Universal is not wide enough? 22:44
darbelo Universal is not regular enough.
kid51 whiteknight: Did you see that the Philadelphia perlmongers are planning a hackfest?
whiteknight kid5: yes
kid51 Would you be interested in attending? 22:45
darbelo NFG makes sure you can have 'random-access' strings with really weird symbols in them.
NotFound darbelo: At the cost of complicating and slowing down 99.999% of usages? 22:46
darbelo I surely hope not.
kid51 grrrr: Major verizon.net outage: Can't get to my email. www.verizon.net gets 503 error 22:48
NotFound If you need to change utf8_encode, that already is complicating a frequent usage.
darbelo Well... That's why I'm trying to avoid it. 22:49
allison: The way I see it, the underlying issue is that the various Unicode-related encodings assume they are getting something that's already unicode. 22:50
If we tried to support, say, GBK. We'd run into the same issues. 22:51
whiteknight kid51: not likely. I'm not much of a perl guy
kid51 whiteknight: However, this group is pretty language-agnostic: hackadelphia.org/ 22:52
darbelo Which, incidentally, is what JimmyZ's problems wiht paths are all about.
whiteknight oh, I thought it was PHL
kid51 Well, I read about it first on the phl.pm mailing list.
NotFound darbelo: that's because all our charsets are unicode subsets, even if we ignore that fact.
kid51 But I just subscribed to the list which Chris Nehren described in the course of that thread. 22:53
So this may be capable of evolution :-)
NotFound ascii is an unicode subset. Latin-1 is an unicode subset. Binary, we don't transcode it.
darbelo NotFound: We'll have to stop assuming that at some point. 22:54
NotFound darbelo: fine, write an ebcdic charset for example.
whiteknight kid51: I'll see about it, but it's not likely I'll go
darbelo No need to, NFG is a Unicode superset. That's why I'm in trouble now ;) 22:55
NotFound darbelo: no wonder you are in trouble if you try to create an infinite charset in finite machines. 22:56
darbelo ;) 22:57
allison: Re-stating my case: "Our strings are less than graceful when we encounter anything that's not a unicode subset, and I think the way we split charsets and encodings is partly to blame there."
sorear on the plus side, it's countable
NotFound sorear: good point :D 22:58
pdd28 says: "Parrot will provide both grapheme-aware and codepoint-aware string operations, such as iterators for string traversal and calculations of string length." 23:02
darbelo NotFound: The pdd lies. 23:03
NotFound Then kill it.
We have enough problems with misdocumented current features, no need to add misdocumenting of inexistent ones. 23:04
darbelo allison: What do you think of, once I get NFG feature-complete, re-evaluating the boudaries of our charset-encoding split and see if we can make it better? 23:05
allison darbelo: sounds like a worthy task 23:06
darbelo I think it'll be a better stretch goal than what I originally planned.
allison darbelo: and yes, I do think there's some unicode bias in the current implementation 23:07
NotFound I think there is not enough unicode bias.
allison darbelo: that may be a task for after GSoC
NotFound: are you more of the "all and only unicode" perspective? 23:08
NotFound allison: yeah
tcurtis NotFound: what about things that aren't in Unicode? 23:09
darbelo That approach has to pay the 'Transcode on the way in.' tax, but is easier to implement.
Tene whiteknight: I'm having mail issues today... not sure if my mail is going to make it to the list or not.
NotFound darbelo: not at all.
darbelo tcurtis: As we were just discussing, we already suck at those ;)
allison the problem with is is that unicode can't actually represent all character sets
so, it's a lossy transcoding
losing data when handling strings is not good 23:10
Tene whiteknight: summary of my mail: why can't you just set :nsentry on the methods? Isn't that flag designed specifically for that purpose, and added to provide a way to get the old semantics as part of the TT #389 work?
darbelo NotFound: Really? Then how do you manipulate them? 23:11
chromatic A canonical internal representation, enforced at the system boundaries, doesn't require a lossy representation.
NotFound darbelo: we do it right now.
allison chromatic: no existing encoding can represent all character sets
chromatic: so, we would have to invent our own, which is... excessive 23:12
NFG is just an optimization on an existing encoding
darbelo NotFound: No we don't. We fake it with the binary charset, which has limitations.
NotFound darbelo: binary data isn't a charset and isn't an encoding,. 23:13
chromatic Is it tractable to use the canonical representation wherever possible, and check for conversions where it isn't?
darbelo NotFound: I agree, but that's what we are doing with JimmyZ's GBK paths. We call it binary and hope nothing breaks. 23:14
allison Tene: yes, though I don't think we currently have a way to set :nsentry at runtime, which may be the complete solution to his problem
chromatic How often will we have to deal with unrepresentable encodings?
allison chromatic: never if Parrot is never used in the real world
NotFound darbelo: that is just working around the current filesystem names and env vars poor implementation. 23:15
allison chromatic: it's not a matter of unrepresentable encodings, but character sets that can't be transcoded to whatever encoding we pick as the one true encoding 23:16
chromatic How many character sets are these? CJKV? Hangul? Pinyin?
NotFound What we have now are things called "ascii":"fixed_8" and "iso-..." that are perfectly workable as unicode encodings.
No need to transode, they are already unicode based.
darbelo NotFound: parrot has to take GBK from the system and give GBK abck to the system, how do we do that without transcoding? 23:17
allison chromatic: good support for multiple character sets is one of the original founding principles of Parrot, one of those competitive advantages
NotFound darbelo: adding encodings if needed, as we already do.
allison chromatic: and besides, the abstraction that makes multiple character sets possible is just plain good design 23:18
chromatic I favor good support for multiple character sets. 23:19
allison chromatic: (not necessarily saying that what we have now is the best possible implementation of the abstraction)
chromatic Our current abstraction is fairly lousy design.
allison it has definite weak points
chromatic Even so, variable width encodings are painful.
allison and, Simon wanted to completely replace it with NFG 23:20
or, at least completely replace it
it was too huge of a refactor step, though
so we took the strategy of adding NFG and then gradually refactoring
23:22 bluescreen joined
allison on the whole, weighing priorities, our character set refactors need to respond to customer needs 23:23
NotFound I think that using the phrase "character set" is a problem by itself.
allison NFG is a priority for speed in NQP
NotFound: again, I like Simon's terminology 23:24
books.google.com/books?id=WMmlodYkd...mp;f=false
ack, awful link
darbelo purl: shorten that
purl That URL is at xrl.us/bhp8af [books.google.com]
darbelo allison: I do worry that NFG won't really deliver that much speed until chrsets and encodings get some refactoring. 23:25
allison darbelo: the key thing is reducing combining characters to single entities 23:26
chromatic Remember when Infinoid sped up PGE's parsing speed some 40% by rearranging some code between charsets and encodings? 23:27
darbelo I've had to add quite a few charset-level special cases for the new encodings.
allison darbelo: that's all NFG provides, it won't give any other speed gains
NotFound allison: there is a lot of literature about that, but in spite of it people keeps talking and thinking about particular encodings when someone says "unicode" 23:28
allison darbelo: keep a list of those special cases, because they're going to be the biggest candidates for generalizations
darbelo allison: Exactly, I think we can gain more by adjusting the boundaries in a few places than by special-casing NFG all over.
Tene Oh, my mail did go through. :) 23:29
allison darbelo: sounds like a good next step after we have the first working NFG implementation (even though it does require some intermediate special casing for NFG) 23:31
23:35 davidfetter joined
kid51 observes his verizon.net email has come back to life. 23:36
chromatic I'm still waiting for the head knocking before I respond to Austin's message.
darbelo allison: In a way, my future plan can be thought of as "Replace conditional with delegation." See if we can shift the places where NFG needs special handling onto the encoding, and shift the places where we duplicate code across encodings back to the charset. 23:37
NotFound I don't have a codepoint for a knocked head smiley-
darbelo NotFound: Use a regular smiley and add a 'COMPOSING KNOCK' char. 23:38
You can add more than one if you think it's needed :)
NotFound That reminds me the times of impact printers. a - backspace - apostrophe... 23:39
chromatic Is there a "PLEASE LET US SOLVE THE REAL PROBLEM" grapheme? 23:40
cotto_work darbelo knows all kinds of secret unicode characters
NotFound At least that thing was for real world usages.
Tene chromatic: head knocking? 23:41
chromatic Apparently "I will revert any commit which adds such a feature" sounds more aggressive than I intended.
darbelo Tene: irclog.perlgeek.de/parrot/2010-06-28#i_2491436
Tene darbelo: thanks 23:42
NotFound chromatic: I tought the chainsaw-commiting role was adjudicated to cotto.
chromatic Sometimes you shouldn't delegate matters of principle. 23:43
cotto_work That's only for deprecation policy violations.
Though in those cases it will be enforced, once the policy is not-disagreed upon.
darbelo not-disagrees with people who wield chainsaws. 23:46
NotFound enters next room, looking for the rocket launcher 23:47
A parrot scriptable Doom engine will be great. 23:49
cotto_work fast nqp-generated parsers would be great 23:50
23:52 ruoso joined 23:53 Psyche^ joined 23:57 hercynium 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!