Parrot 3.10.0 "Apple Pi" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 2 December 2011.
00:52 whiteknight joined 00:54 alvis joined 00:59 jsut_ joined
whiteknight masak: ping 01:07
dukeleto ~~ 01:15
whiteknight hello dukeleto 01:16
dukeleto whiteknight: wazzup 01:17
whiteknight dukeleto: nothing much. you? 01:18
masak requested a new sprintf format sequence be added. The more I look at this code, the more angry I am that I agreed to do it 01:19
the sprintf implementation is terrible
dukeleto whiteknight: which sprintf is terrible? 01:22
whiteknight there is really only one implementation 01:28
lots of different wrapper functions for it
cotto That's a very organic piece of code. 01:39
needs to be composted
whiteknight the SPRINTF_OBJ, which contains the state of the translator, is a global singleton 01:40
which means sprintf is inherently not thread-safe
cotto I thought that was a problem with most *printf variants. 01:55
whiteknight we could make it thread-safe by simply not using the global object 02:00
cotto That was a bad response. Even if sprintf is usually non-thread-safe, we don't need to continue the pattern. +1 to fixing if it makes you angry enough. 02:07
*bad response from me
whiteknight Eventually I may go in and rewrite most of this crap 02:12
certainly reorganize some of these files
whiteknight says that about all the code 02:16
cotto ~ 03:30
03:37 Psyche^ joined 05:27 alvis joined 06:07 preflex_ joined 06:33 alvis joined 07:10 baest joined
masak whiteknight: sorry for (indirectly) making you angry. :/ 09:01
09:16 contingencyplan joined
masak ok, I've now killed off %C in the Perl 6 spec: github.com/perl6/specs/commit/8ef1...e17e02bc7b 09:45
moritz masak++ # making Perl 6 smaller and simpler 10:22
nom: printf('foo %s') 10:28
p6eval nom e6fee1: OUTPUTĀ«Null PMC access in get_string()ā¤ in sub sprintf at src/gen/CORE.setting:1841ā¤ in sub printf at src/gen/CORE.setting:1846ā¤ in block <anon> at /tmp/K8fijDG3rR:1ā¤ in <anon> at /tmp/K8fijDG3rR:1ā¤Ā»
moritz that's kind of a problem too for us 10:29
we don't know how many arguments (and of what type) printf wants, and get Null PMC access when there are too few arguments
masak Perl 5 gives a 'Missing argument' warning (but formats the string anyway), which feels more sensible. 10:32
moritz we could have an sprintf that takes a callback 10:56
and sprintf calls it for each argument it needs to obtain, together with the type
so that sprintf('%s %d', &foo) would call &foo once with argument 'string', and once with argument 'int' 10:57
or so
(low-level, of course)
so that in the Perl 6 runtime library we can introspect our arguments, and fiddle them in a way that parrot can work with them
11:41 whiteknight joined
whiteknight good morning, #parrot 11:42
tadzik good morning whiteknight 11:46
how are things?
masak whiteknight: I de-spec'd %C :) 11:50
whiteknight masak: I wasn't stressing about %C. I wanted to do it. My stress came from finally seeing the sprintf code internals and realizing how much it needs to be cleaned 11:51
11:51 mj41 joined
tadzik :) 11:53
masak whiteknight: right. I guess it still needs to be cleaned.
but I don't feel we need %C.
whiteknight okay, but let the record show I was both willing and eager to do it 11:54
masak absolutely. whiteknight++ 12:01
let's apply that willing-eagerness to features we actually care about ;)
whiteknight sure, what's next on the list? 12:02
tadzik DESTROY I guess
as in "call me just before I get GC'd"
whiteknight yeah, I figured you might say that 12:03
dalek sella: d62d4c2 | Whiteknight++ | s (5 files):
Several fixes and cleanups to iterable. Add in a factory type for sources. Add in a method for Tap
 12:13
sella: 38f4d8c | Whiteknight++ | src/ (4 files):
Refactor out iterable source common logic into a new base class. Add in on_data and on_iterator methods to mirror what stream has
sella: b55d9a1 | Whiteknight++ | / (3 files):
Update Harness to use iterable instead of stream.
sella: 7ce07f8 | Whiteknight++ | src/ (6 files):
Completely update Harness to use Iterable instead of Queryable and Stream. Some fixes to bugs found in Iterable during the process
sella: 3a74120 | Whiteknight++ | / (17 files):
Merge branch 'iterable'
masak yes, DESTROY 12:15
whiteknight masak: do you guys have anything like a failing test case I can start with? 12:24
tadzik I can write one quickly
oh, there is S12-construction/destruction.t in roast 12:25
I wonder if it can be written better, moving this to #perl6 12:26
with lazy enough GC I'm afraid that test will never pass :/ 12:29
masak: what do you think about gist.github.com/1539638 ? 12:31
masak tadzik: I think I do not know enough about the workings of GC hooks to tell you if that is a good test or not :) 12:32
though to me it looks at least like a stab in the right direction.
tadzik masak: I just think that the spectest is a bit bogus
imagine that GC chooses to run after all the test cases. DESTROY may work, but spectest will fail
whiteknight what if we had an opcode at the parrot level to manually destroy a PMC (and trigger finalizers at that moment)? 12:36
moritz tadzik: notice that 6model already has some DESTROY-like callbacks for memory deallocation
it "just" needs to call into Perl 6 code
tadzik oh
masak tadzik: hm. maybe have DESTROY set a global flag, and test the flag at the END phase of the test file? 12:37
tadzik masak: what if the flag gets GC'd before the class? 12:38
moritz tadzik: grep for gc_mark and gc_free in nqp/src/6model
masak tadzik: yes, this is the general problem. :/ 12:42
so maybe your 'pass' solution is cleaner.
is the GC guaranteed to run on objects that survive till the very end of the program. 12:43
12:43 bluescreen joined
tadzik but...but what if Test.pm gets collected before? :D 12:43
masak in many languages, it isn't.
s/program\\./program?/
13:05 jsut joined
whiteknight masak: I don't know if Parrot runs one last "finalize" GC run at the end of the program 13:19
I know that the code for that exists, but I also know that it frequently gets commented out as a "performance improvement"
masak right, that's always a risk. 13:25
and then DESTROY gets labeled as "not guaranteed to run".
and then people decide to use different mechanisms. 13:26
whiteknight right
the question is, what is the common case? Are short scripts that don't utilize DESTROY common, (in which case GC finalization can dominate execution time) 13:27
especially if you're running multiple instances, such as in a test suite
tadzik I guess most of the times no one will use DESTROY for anything
it'd be useful for ie freeing non-Perl6 resources 13:28
or flushing data to files
whiteknight Parrot will do whatever Rakudo needs, of course. It just isn't straight-forward because of the tradeoffs
masak tadzik: right, but absent any guarantees that DESTROY will run... it'll just be like in C++ and Java, where people call explicit home-made finalizers. 13:29
tadzik yeah
dalek rrot: 8c4a2b1 | Whiteknight++ | src/pmc/ (5 files):
Iterator PMC and family now implement the 'iterator' role.

If we test for this role, HLLs can easily implement and transparently use their own iterator types, and can easily detect when an object is an iterator (vs some other kind of data)		 13:31
whiteknight What if Parrot had a kill_this_pmc op which immediately killed and finalized a PMC? And then Rakudo could keep a queue of PMCs needing finalization and kill them explicitly at program end? 13:32
The costs of GC finalization are in sweeping through huge swaths of PMCs like arrays and contexts which don't need finalization
so if you separate out the ones that absolutely need finalization (filehandles, network resources, etc) we can get the same results with none of the costs
masak sounds intriguing. 13:36
13:37 jsut_ joined
masak is some sensible order guaranteed at the end of the program? that's a separate question from "is GC guaranteed at the end of the program?" 13:38
i.e. if object B has a reference to object A, will Parrot guarantee that the GC collects A before B?
dalek kudo/nom: 5b58e03 | tadzik++ | lib/Test.pm:
Cleanup Test.pm
 13:42
whiteknight masak: Ah, the million dollar question 14:06
currently we don't guarantee order of destruction in any way, shape or form
Let's say we have an opcode "finalize_all" which takes an array. It iterates over that array calling finalizers, then it iterates the array a second time to collect PMCs 14:07
we can't guarantee order that the finalizers are called it (save for the order of the array)
but we can guarantee that all finalizers are called before all of them are swept
there's a reason this problem hasn't been solved adequately yet, and it's not because writing the code takes time 14:13
masak of course, for things like circular references, this condition cannot be upheld. 14:28
14:56 PacoAir joined 14:58 mtk joined
dalek sella/query_2: 14a8a39 | Whiteknight++ | s (9 files):
Rough hewn version of what the new query library will look like.

Remove Stream. Add a new Sort namespace with the hybrid sort and a cleaned up version of Timsort from the benchmarks. Better detection of iterators with Parrot's new
  'iterator' role. All Queryables are in-place, since that object type is intended to be for performance		 16:06
sella/query_2: 058c486 | Whiteknight++ | / (10 files):
Several cleanups.

Remove uses of old qsort method from the codebase. Add Sort, Shuffle, and GroupBy iterators, to replace eager methods of the same names. Fixes so we build.
17:27 PacoLinux joined 17:30 PacoAir joined 17:51 estrabd joined 19:02 davidfetter joined 19:31 fperrad joined 19:56 particle joined 20:03 jsut joined 20:29 bluescreen joined 20:47 perlite joined
dalek kudo/nom: a8c513b | moritz++ | src/core/Hash.pm:
make Hash.push a bit more efficient and correct
 21:23
21:48 bluescreen joined 22:25 mj41 joined 22:31 PacoAir joined
aloha (parrot/parrot) Issues opened : 239 (Add an exception handler around check for can __dump.) by KrisShannon : github.com/parrot/parrot/issues/239 22:56
23:29 jsut_ joined 23:44 davidfetter 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!