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.
NotFound nine: ping 00:06
whiteknight: ping 00:07
unping 00:12
00:29 kid51 joined 00:40 nbrown joined
dalek rrot: 8f6cec8 | NotFound++ | include/parrot/pointer_array.h:
simplify Parrot_pa_insert, avoiding allocating a chunk when there are
 01:10
bacek_at_work ~~ 01:21
!pr
aloha Open pull requests for parrot/parrot.github.com : 0 pull requests open ()
bacek_at_work hmmm
!pr
aloha Open pull requests for parrot/parrot : 1 pull requests open (gitster:1)
01:31 davidfetter joined 01:41 benabik joined
dalek itor: d2ddd6e | NotFound++ | examples/text.winxed:
fix example text very slow on large files
 01:44
02:28 Nol888 joined 02:32 jiang joined 02:37 jiang joined 02:38 shell joined, jiang left
cotto ~~~ 03:26
04:21 rfw joined 04:29 davidfetter joined
dalek itor: 217ce20 | NotFound++ | src/GuitorNci.winxed:
regroup a bit xlib functions by signature
 05:00
05:06 davidfetter joined
dalek itor: 478b2d0 | NotFound++ | src/Guitor.winxed:
change creation and destruction of XftDraw in text drawing
 05:36
05:58 alvis joined
dalek kudo/nom: 1a9a4a5 | moritz++ | src/core/Num.pm:
return integers from rounders
 06:07
kudo/nom: 638029b | moritz++ | t/spectest.data:
run perl.t
itor: a19e697 | NotFound++ | src/Guitor.winxed:
get 'detail' in focus events
 06:17
06:18 JimmyZ joined
dalek kudo/nom: 011993e | moritz++ | t/spectest.data:
remove conflict marker, JimmyZ++
 06:29
06:43 JimmyZ joined
dalek kudo/nom: 6d0867e | moritz++ | t/spectest.data:
fix t/spectest.data, JimmyZ++ again
 06:47
07:55 mj41 joined 08:01 code_in_the_shell joined 09:24 AzureStone joined 09:33 lucian joined
dalek kudo/nom: 0eed6ff | moritz++ | t/spectest.data:
run operator overloading tests
 11:15
11:36 jsut_ joined 11:40 nbrown joined
dalek kudo/nom: 68d0b8f | moritz++ | src/Perl6/Grammar.pm:
fix circumfix dispatch, jnthn++
 12:36
12:42 Nol888 joined 12:45 alin joined 12:52 alin joined
dalek sella: 67899c4 | Whiteknight++ | s (4 files):
Add an inst_wxheader install step to add winxed header files to the install. Include all the Rosella include files
 13:04
sella: a8ff7fa | Whiteknight++ | s (5 files):
several cleanups
sella: 45f985a | Whiteknight++ | setup.winxed:
cleanups
sella: 485a25e | Whiteknight++ | s (9 files):
Add include files for the rest of the stable libs.

Update CommandLine.Arguments to parse positionals after flags have been parsed. Update mk_winxed_header to have a --rosella mode that does some Rosella-specific stuff.
13:32 Yuki_N joined 13:47 JimmyZ joined 14:55 JimmyZ joined 15:25 contingencyplan joined
nine NotFound: pong 15:29
15:31 Psyche^ joined
NotFound nine: I've made a tiny change to Parrot_pa_insert in master. Can you check if that change has some effect on your problem? 15:34
nine NotFound: I'll gladly do. But I finally understood for which kind of buf I should be looking. And as long as those bugs are there, any change to Parrot_Pointer_Array (like my "workaround") can only hide or reveal these bugs. 15:37
NotFound That was the idea, seeing if the change has some effect that can reveal the problem. 15:39
It avoids creting a chunk when there is no need for it, so the behaviour should be a bit more predictable. 15:40
nine mls told me to add if (!Parrot_gc_pool_is_owned(interp, self->pmc_allocator, item)) abort(); to gc_gms_mark_pmc_header which revealed plenty of points where my thread still accesses the main threads's data directly.
NotFound That probably should be permanently added, idef'ed on PARROT_DEBUG, and some other macro if the debug build goes excesively slow. 15:42
nine Yes. Till now the assumption that there is only one GC active in the whole process was baked into many places. I should have guessed that changing such things will be difficult 15:44
The line will help discover many more of these...
moritz what's an easy way to print a backtrace from PIR? 16:49
ah, getinterp -> context -> .backtrace 16:54
hm, but that doesn't give me the strings 17:02
sigh
benabik The backtrace appears to be an array of hashes? 17:16
dukeleto msg tadzik github.com/tadzik/Module-Starter needs a license. what is your preference? 17:30
aloha OK. I'll deliver the message.
dalek imera: 64cba3b | dukeleto++ | LICENSE:
add a license file
 17:33
17:40 davidfetter joined 17:42 fperrad joined
tadzik dukeleto: MIT, as usual 18:15
18:16 jsut joined
cotto ~~ 18:38
tadzik ~~ 19:09
nine woohoo....one step forward! 19:21
benabik two steps back? 19:22
nine hope not :) 19:23
Just got a very simple test program to run stable without any strange workarounds or memory leaks
There are just too many globals in Parrot... 19:25
19:38 davidfetter_ joined
moritz sounds like p5 :/ 19:38
19:38 mj41 joined
moritz and I'm afraid it's typical for a piece of software that hasn't embraced concurrency from the very start 19:38
dukeleto moritz: at least we don't have a global interpreter lock :) 19:44
moritz: parrot has at least been thinking about concurrency from the start. There was some kind of implementation of Software Transactional Memory in the early days. 19:45
moritz: but i agree, we have not embraced from the start
sorear does Parrot support two threads sharing a single heap yet?
or do you still have to use proxy objects like Perl5? 19:46
dukeleto sorear: reasonably sure we still require proxy objects, but whiteknight/bacek would know best
sorear: a lot is changing in parrot threads currently, not sure of the current status 19:47
sorear I think there are valid arguments for a Perl5/Python like setup where two threads are not allowed to use the same heap concurrently 19:48
it allows much more flexibility with regards to lock-free data structures
dukeleto sorear: nobody in the python world seems to like the GIL 19:49
sorear like how Perl 5 caches the stringification of numbers
dukeleto: didn't early versions of Python use per-dictionary locks? 19:50
dukeleto sorear: ENOCLUE
all i know is Perl 5 caches multiple representation of a SV inside the SV, not sure how perl 5 threads deal with that 19:51
i.e. stringification of a float, numification of an int 19:52
which is why Perl 5 variables end up being 22 bytes each, empty
or something around that
it is convenient, but surely not memory-efficient
PerlJam 22? I didn't think they were that small
dukeleto PerlJam: 22 bytes if empty, iirc. But everything could have changed since I last looked. 19:53
PerlJam: that depends on perl version and the phase of all of saturns moons, as well :)
sorear dukeleto: perl 5 threads do not share access to the same SV, ever
dukeleto sorear: so caching stringification of a number does not happen, unless there is an additional caching layer 19:54
PerlJam yeah, the last time I looked (years ago) I recall that they were something on the order of 60 bytes empty. and I know some optimization have happened in the mean time, but I still didn't think they'd gotten down to 22 bytes
sorear dukeleto: perl 5 is even worse off than Python - since there's no GIL, an interpreter cannot be shared between threads 19:55
dukeleto: perl 5 threads are evolutionarily related to the perlwin32 fork(2) emulation
PerlJam: a SV is of highly variable size 19:56
PerlJam: a SV has a "head" (always 4 words) and a "body" (changes size depending on what is stored)
dukeleto sorear: interesting 19:57
sorear the "head" contains the flags, the refcount, a pointer to the body, and a spare word 19:58
"small" types like SVt_IV use the spare word, so my $x = 5; is only 16 bytes on x86 19:59
also, don't be mislead by the size of the structs in sv.h; the allocation is frequently smaller
e.g. if the flags say there is a valid numeric value, it might be found 16 bytes after the start of the data depending on offsetof(xiv_u.xivu_iv, struct xpviv) 20:02
so, SvANY(sv) will point (no body allocated for SVt_IV) to ... 16 bytes before the spare word 20:03
every SVt_XXX define establishes the size of the allocated data area, and how much is subtracted from the pointer 20:04
moritz wonders what price perl 5 pays for such trickeries
is that why people are afraid of writing XS code?
20:05 lucian joined
sorear moritz: well, it does make shared-memory multitasking effectively impossible 20:11
although there are quite a few people who will tell you that SMP is on the way out anyway and message-passing is the only way to be truly scalable 20:12
... I have to wonder if these people are Perl 5 and Python programmers with a good dose of the Stockholm
moritz: the Perl 5 memory management hacks are pretty well hidden behind the API 20:15
SvPV() gets a string value from any type of SV
20:17 senf_statt_oel joined 20:21 dmalcolm joined 20:32 zby_home joined
dalek itor: 2cffb81 | NotFound++ | src/Guitor (2 files):
improve selections, select, copy and middle button paste in EditBox
 20:40
benabik o/ #particle 20:48
Uhm.
#parrot
benabik should perhaps rely on tab-completion less.
particle fine, i won't wave back :P 20:49
20:49 lucian joined
benabik particle: Should we rename the channel so my first wave was accurate? 20:51
particle i am large, i contain multitudes.
\\o #benabik :)
benabik :-) 20:53
20:56 alin joined 21:08 patspam joined
nine sorear: Parrot in the threads branch does indeed use proxy objects for shared data and uses green threads for scheduling updates to shared data on the data owning thread. The upside of this system is that single threaded code runs completely lock free. So unlike Perl 5 nobody pays the penalty of thread support just because it's compiled in 21:16
sorear: of course the downside is that writing to shared data is rather expensive... 21:17
sorear nine: ...do you know what the Perl 5 "thread performance penalty" is? 21:23
nine sorear: frankly, no. Either it's an urban myth or substantial. But reminds me that I wanted to try it out sometime... I've heard from many different sides that it's a big hit 21:26
sorear nine: it's substantial but Parrot has to pay it 21:27
nine What do you mean?
sorear nine: without threads enabled, Perl 5 uses globals everywhere 21:28
nine: with threads enabled, Perl 5 passes a Perl5Interpreter *my_perl pointer to every single function
now, does every single Parrot function take a Parrot_Interp pointer?
nine sorear: pretty much 21:29
sorear the performance penalty of using threads in Perl 5 has to do with all the extra parameter passing
21:30 whiteknight joined
nine So Parrot is paying this penalty before it even got thread support... 21:31
sorear nine: popular wisdom in #p5p is that the thread penalty is around 10% for most workloads
dalek itor: 8bfe957 | NotFound++ | src/Guitor.winxed:
add a method getTextxOff to Drawable that forwards to its font
 21:32
sorear nine: be careful with old documentation. old Perl versions had something called "5005threads" which were quite different from the modern system (called "ithreads") 21:33
21:36 rfw joined
dalek rrot/threads: 8f6cec8 | NotFound++ | include/parrot/pointer_array.h:
simplify Parrot_pa_insert, avoiding allocating a chunk when there are
 21:39
rrot/threads: f356ba9 | nine++ | / (4 files):
Merge branch 'master' into threads
rrot/threads: 5587496 | nine++ | src/gc/gc_gms.c:
Let only the GC in the main thread mark PMCNULL since it's shared between all threads.
rrot/threads: a3afd65 | nine++ | src/gc/mark_sweep.c:
Only mark code segments in the main thread
rrot/threads: a95919a | nine++ | src/pmc/sub.pmc:
Don't mark pack file views in secondary threads

Pack files (code) is considered read only and handled by the main thread. No need to mark it in secondary threads.
rrot/threads: fd880a8 | nine++ | src/pmc/parrotinterpreter.pmc:
Create proxies for iglobals in clone_interpreter
rrot/threads: 894d6e2 | nine++ | src/pmc/parrotinterpreter.pmc:
Create a proxy for HLL_info in clone_interpreter
rrot/threads: 39f333d | nine++ | src/pmc/parrotinterpreter.pmc:
Create a proxy instead of cloning class_hash in clone_interpreter
rrot/threads: f874fce | nine++ | src/pmc/parrotinterpreter.pmc:
Remove some vtable/class_hash code thats hopefully covered by the proxy
rrot/threads: 260ad57 | nine++ | src/pmc/parrotinterpreter.pmc:
Use a proxy for pbc_libs as well
nine whiteknight: would be great if you could have a look at these commits and tell me if they make any sense to you. I think I don't know even half of what I should know to meddle with this stuff ;) 21:43
whiteknight nine: okay, I can look later 21:49
21:52 perlite_ joined
nine Is there a way how I can create a PMC that represents the current interp? Parrot_pmc_new would call Parrot_ParrotInterpreter_init which would create a whole new interp. I just need a PMC where I can set ->interp 21:58
NotFound nine: VTABLE_get_pmc_keyed_int(interp, interp->iglobals, IGLOBALS_INTERPRETER); 22:01
Is what the getinterp opcode does.
nine NotFound: interp->iglobals is exactly what I need to give a new value to :)
NotFound: the PMC that's stored there is owned by the thread that created this interp. To be able to return it from getinterp I need it to belong to this interp itself 22:02
NotFound I think new_noinit and VTABLE_set_pointer will do the job. 22:04
PMC *p = Parrot_pmc_new_noinit(interp, enum_class_ParrotInterpreter); VTABLE_set_pointer(p, interp); 22:07
Ups... : VTABLE_set_pointer(interp, p, interp); 22:08
nine NotFound: many thanks! Works perfectly 22:09
dalek rrot/threads: 171e5fd | nine++ | src/pmc/parrotinterpreter.pmc:
Create a new PMC to hold a thread's interpreter

The ParrotInterpreter PMC in a thread interp's iglobals was created by another thread. Using a proxy still leads to memory corruption. Use code suggested by NotFound++ to create a local PMC to refer to the interpreter, so the getinterp op works as intended.		 22:22
22:31 schmooster joined
whiteknight nine: If the interp already has a PMC, and most do at interp creation, there is a function to get it 22:40
oh, wait. I'm thinking of something else
nevermind, do whatever NotFound said 22:41
22:41 nbrown joined
whiteknight nine: if the main thread is paused, PMCNULL won't get collected by a different thread, right? 22:49
I mean, only the main thread would sweep it anyway
23:23 senf_statt_oel left 23:46 snearch 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!