Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 17 August 2011.
whiteknight I'm not sure what you mean 00:00
plobsing how would you go about looking up the return continuation, or the current HLL, or the current sub, or other attributes of CallContext.pmc? 00:01
they have accessors, but why aren't they just registers?
but the idea does not end there
whiteknight oh, I see what you mean
plobsing I then realized, that every register accessing opcode has to do many pointer follows to even get at the register frame 00:02
it follows interp->ctx->data->bp
why isn't that just interp->bp
with ctx falling into the register frame somewhere? 00:03
turn callcontexts inside out
whiteknight so the interp points to a register frame, the first element in that frame is the CallContext? 00:04
second is the Sub, third is the lexpad, etc
plobsing yes, that's the general idea
whiteknight then in PIR, we could have special symbolic names like $Pcc, $Psub, $Plex, etc
I like this
plobsing the immediate win is the reduction in complexity of *every* op in parrot (on x86_64 by 2 instructions or 8 bytes) 00:05
and it also lets us have those cool accessors
whiteknight how is that? I mean, to get the register frame we would still need to pull it out of the CallContext
plobsing no, we'd pull the callcontext out of the interp 00:06
s/callcontext/register frame/
whiteknight right, but where do we get it from in the first place? And where do we store it when we're recursing, or saving an outer context for a lexically nested closure?
basically, we would need some kind of circular reference 00:07
plobsing we still need to shove it in a callcontext when we're not using it
whiteknight ctx->data->bp[0] == ctx, etc
plobsing what's wrong with circular references?
whiteknight nothing. It's necessary here 00:08
so CallContext.get_pointer would return the register frame for easy access. get_integer might return a packed count
cache those in the interp at the beginning of the sub call
i like the idea
plobsing ok, I'll prototype something
whiteknight plobsing++ 00:09
plobsing I didn't want to invest the amount of time just to find out it was madness
but now I know it doesn't *sound* crazy...
whiteknight I suspect it could be an easier idea than it appears, especially since much of the op code and other accessor code is generated or macroize 00:10
macroized
we need to teach IMCC to add like 5 extra slots to the beginning of each register frame 00:11
maybe [interp, callcontext (self), sub, lexpad, current namespace]?
although, maybe we don't need interp in there. That's a lot of data duplication for something that's very easy to fetch 00:12
plobsing the IMCC part should actually be pretty easy. the register allocator, as dumb as it is, could easily be told to start allocating at a higher value. 00:13
benabik Do we ever have more than one interp?
plobsing benabik: when we have threads or sandboxes
whiteknight plobsing: also need to update IMCCompiler and other places that call into IMCC, because those are responsible for allocating register frames
plobsing right 00:14
whiteknight although those places are fewer than they once were 00:17
we can cut several attributes out of the call context too, so we aren't wasting more space 00:18
plobsing exactly, it works out roughly even 00:20
whiteknight I tried merging Sub->namespace_name and Sub->namespace_stash yesterday on the train, and the results were disasterous 00:21
plobsing those do different things
whiteknight I was hoping that particular cleanup would go more smoothly, because that would mean I had a good grasp of it
->namespace_name isn't really used after the packfile is loaded
plobsing true, I guess
whiteknight once the NameSpace is loaded, we should be able to overwrite namespace_name with it, but that is the major fail
I really can't wait to get all this crap cleaned up. CallContext, Sub, NameSpace, etc. They're all rotten on the inside 00:23
dalek sella: 56fe283 | Whiteknight++ | / (2 files):
Comment out the Function routines I'm not ready for yet. Add some tests
 00:35
sella: a0d29a1 | Whiteknight++ | / (2 files):
Change Asserter.is_true and Asserter.is_false to use the istrue and isfalse opcodes
rrot-gmp: 6c1c59e | bubaflub++ | / (2 files):
more docs
 00:37
bubaflub plobsing: do you know where i should install custom thunks to? where does Parrot install it's extra thunks? 00:38
plobsing bubaflub: I'm not sure exactly. they're just a dynext, so wherever parrot installs those 00:42
bubaflub plobsing: ok, i'll take a look into it 00:43
plobsing: looks like on my system /usr/local/lib/parrot/3.6.0-devel/dynext 00:46
or $PConfig{libdir} . $PConfig{versiondir} . "/dynext" 00:47
plobsing sounds about right 00:49
dalek nxed/multi_opt_flag: 6f516b1 | NotFound++ | / (3 files):
Merge pull request #4 from Whiteknight/multi_syntax

Multi functions and methods		 00:55
nxed/multi_opt_flag: c6ac75c | NotFound++ | winxedst1.winxed:
work around stage 1 limitations to allow multi tests pass with make test1
nxed/multi_opt_flag: 8f25134 | NotFound++ | winxedst1.winxed:
use separate methods to get and set the is_multi flag, and recognize multi declarations on reopened namespaces
nxed/multi_opt_flag: 2cd7e1a | NotFound++ | t/advanced/10multi.t:
tests for multi in reopened namespace
nxed/multi_opt_flag: 747b557 | NotFound++ | / (2 files):
update NEWS and set version to 1.1.0
nxed/multi_opt_flag: 2a5ac47 | NotFound++ | / (2 files):
optimize a bit handling of the is_multi flag
nxed/multi_opt_flag: ba8694a | NotFound++ | pir/winxed_compiler.pir:
update installable compiler
nxed/multi_opt_flag: 13b1371 | NotFound++ | winxedst1.winxed:
unify scope search methods
nxed/multi_opt_flag: 81bbfb2 | Whiteknight++ | winxedst1.winxed:
fix multi to work with optional/opt_flag
whiteknight you don't realize how messy some of this crap is until you have to reimplement some of it 01:01
docs/multidispatch.pod is so far out of date, it's absolutely unusable 01:03
01:03 bubaflub joined
whiteknight i didn't think we did, and I don't see evidence to the contrary, have any way to tell MMD that a parameter is :optional or :slurpy 01:06
we don't have any way to dispatch based on value, only type 01:08
plobsing couldn't you associate multiple signatures with the same sub?
one with the option and one without?
whiteknight we don't have any way to dispatch based on the types of named parameters
plobsing slurpy is harder
whiteknight plobsing: no. Sub has a multi_sig parameter. Only one
can't have more than that right now
plobsing yet another instance of a sub owning something that should really own the sub 01:09
whiteknight exactly
all this shit needs to die in a fire
benabik whiteknight's favorite refactoring tool: acecombat.wikia.com/index.php?title...hrower-jpg 01:11
whiteknight I don't tolerate bad code very well 01:14
plobsing how I imagine whiteknight most of the time: emotibot.net/pix/444.gif 01:15
whiteknight :)
benabik plobsing++ 01:16
whiteknight what annoys me the most is that Parrot has so many problems. Instead of fixing them, we put together a deprecation policy and codified all of them forever 01:21
two and a half years later, all our developers and all our users complain about the deprecation policy, but we magically can't change it
plobsing you're missing a part. everyone complains about the cruft in parrot, but everyone thinks a different part is crufty 01:23
whiteknight even the parts that have been refactored well and recently are relying on things that suck 01:24
GC alone might be good, because it doesn't depend on much 01:25
plobsing nah, GC's design needs work.
why does it call into all the objects to mark? no other VM does that and it is inefficient 01:26
benabik compacting would be nice.
whiteknight compared to some other subsystem, it's a shining gem
compacting is a pain in the ass
plobsing stack-walking is part of GC. are you calling that shiny?
it explicitly makes use of undefined (per C std) behaviour 01:27
whiteknight comparatively
it does work, there are no obvious limitations. It isn't filled with evil hacks and code that nobody understands 01:28
compared to, say src/oo.c, it's the most beautiful code ever
although, that's hardly a fair comparison
01:34 bubaflub joined
plobsing speaking of stack-walking, how would you feel about something more like obstacks that are explicitly registered with the GC? 01:35
whiteknight how would that work?
plobsing as a replacement for stack-walking
whiteknight I'm not familiar with obstacks 01:37
plobsing for any frame that contains references to GCables, you are no longer allowed to hold it in a variable (that the C compiler might play with). in steady, you create a region of memory (either heap or stack) for all GCable variables you want to work with, and push it onto a stack maintained by GC
obstacks are like malloc/free but with a LIFO limitation
IIUC
libiberty provides an implementation gcc.gnu.org/onlinedocs/libiberty/Obstacks.html 01:38
basically, maintain a side-stack of GCable references in native code
whiteknight what if we just provided some scratch space in a register frame?
plobsing and who holds a reference to the register frame?
it needs to root somewhere 01:39
whiteknight the current register frame is rooted in the interp
plobsing hmmm
whiteknight you would be limited in how many you could store, and you wouldn't have guarantee that it would be preserved across calls, unless you set up a separate frame 01:41
plobsing I see the need to prevent users from holding direct references to parrot gcables on the stack 01:42
saying "manage your gcables by putting them in a register frame" doesn't solve that problem 01:43
whiteknight I do too, but it isn't a pressing need
compared to some of the other big cleanups and projects we've got scheduled
plobsing it does (if users use it correctly) solve the problem of rooting stack GCables somewhere GC can find them
whiteknight: stack walking is a barrier to thread safety
whiteknight is it? even if we walk all stacks in all threads? 01:44
plobsing multiple threads => multiple stacks => how does GC know where to walk?
how do you determine the stacktop of a stack that isn't the stack of the thread you are executing?
whiteknight if each thread has its own GC, the GC just walks it's current stack 01:45
plobsing I thought we were considering multiple threads managed by a single GC
whiteknight if we have a system with relatively many greenlets dispatched over relatively many OS threads, they can afford to be a little heavyweight
we're considering everything
if we go the single GC route, which is fine, we need a thread-safe GC 01:46
if not, we don't
we are missing two things right now: thread-safe code and a comprehensive design for a new threading sysem 01:47
plobsing if we don't do single GC, am I to assume messaging between kthreads will be expensive?
and will that lead to unpredictable cost of messaging between vmthreads (because they might be mapped to different kthreads)?
whiteknight that's where my idea of read-only proxies comes in. Make cross-thread reads delayed. Forbid cross-thread writes 01:48
plobsing thread safety is a big reason why I want stack walking to go the way of the dodo
and then there's the whole precice GC thing 01:49
whiteknight if we go single GC, we still want to forbid or severely restrict by default, cross-thread writes
plobsing why?
whiteknight otherwise we need a data contention mechanism like STM
plobsing don't the guys at azul have a solution for this? 01:50
whiteknight not that I am aware of
you either need to make items read-only, or use STM, or use transactions of some other variety, or use locks 01:51
I like the idea of read-only, because that only matters between kthreads. vmthreads on the same kthread see no penalty
plobsing they use java, so their decision is made. locks via synchronised and friends.
whiteknight right, and I hate locks and want to avoid them as much as possible
plobsing locks as a user interface suck, but locks are how most platforms choose to expose their concurrency control 01:52
whiteknight I'm convinced that we can avoid it in most cases 01:53
message queues, a small amount of global data, and GC 01:54
most everything else can either be read-only, used on a single thread, or shared with messages
if each item has a single kthread owner, and we have a cheap operation to change the current owner, that will go a long way
we have a nice advantage that we can bundle up an execution context in a tuple of objects, and move it around as a group 01:56
the Sub, CallContext graph and Interp can be moved around as a group, and invocations make clean barriers where we can do tricky things 01:57
bubaflub whiteknight: i've got a distutils question for ya, if you've got a moment. 01:58
whiteknight bubaflub: precious few. What's the question?
bubaflub whiteknight: can i do a register_step_before or register_step_after install?
i've seen them used for build or clean 01:59
whiteknight yeah, I don't see why not
bubaflub ok, cool.
whiteknight anything else? It's about my bed time 02:00
bubaflub nope. 02:02
whiteknight okay then, I'm out. Goodnight
02:42 preflex joined
dalek rrot-gmp: 4d9acd0 | bubaflub++ | setup. (2 files):
changes for NCI thunks:

only build NCI thunks when libffi isn't present copy thunks to a place where parrot can find them		 02:44
bubaflub ping plobsing 03:10
plobsing bubaflub: present 03:14
bubaflub plobsing: i'm thinking about modifying tools/dev/ncidef2pir.pl to use NCI::Utils and the dlfancy function when an NCI def has 't' in the return type or the parameters. any thoughts? 03:15
plobsing dlfancy doesn't support pass-by-ref currently. you'd be reducing functionality elsewhere 03:16
bubaflub plobsing: i'm only modifying it in the case that there is a 't' signature - would that still reduce functionality? 03:17
plobsing ah. probably not then. just document that pass-by-ref and 't' are currently incompatbile 03:18
bubaflub plobsing: now i'm doubting if i should do that at all - it was to make some Parrot-GMP stuff easier, but i really only have a 3 or 4 functions that used string stuff 03:20
and i'm doing just manual parrot_cstring type stuff
plobsing I'll admit, manually mangling strings sucks.
bubaflub plobsing: yeah, the whole string NCI stuff is just bothersome right now. 03:21
plobsing you could output an equivalent wrapping as dlfancy when working with cstrings but directly use the dlfunc interface (not the string sig interface)
then you could have your strings and pass-by-ref too 03:22
bubaflub: raw nci will always be bothersome. the trick is comming up with a decent wrapper so that we don't have to think about it most of the time.
bubaflub plobsing: yeah. i think as we get more and more people doing lib bindings we'll figure out something 03:23
plobsing dlfancy is more for back-compat and appeasing the immediate needs of rakudo than it is a decent wrapper
I like the direction zavolaj took
bubaflub plobsing: another nice part about having a decent wrapper is that we can change the underlying subsystem and just fix the wrapper rather than a hundred different libs
plobsing bubaflub: that assumes you'd want to change the underlying subsystem for no good reason 03:24
bubaflub hah. not exactly what i was suggesting - i meant if we'd ever need to make a small but possibly breaking change we'd only have one place to check / fix.
plobsing most of the time, when a change is being made, it is because the old way was buggy somehow. unfortunately, IME, that usually pokes through as behaviour in the interface which gets deleted. 03:25
bubaflub understood. ok, thanks for your help. 03:28
03:28 rdesfo joined 03:29 rdesfo left
dalek rrot-gmp: cac2763 | bubaflub++ | docs/tutorial.md:
more docs
 03:36
website: bubaflub++ | Parrot-GMP: Almost done 03:42
website: www.parrot.org/content/parrot-gmp-almost-done
rrot/inside-out-ctx: 136f201 | plobsing++ | / (4 files):
disambiguate bp as bp_ni - it is the $Nx and $Ix bp only
 04:45
rrot/inside-out-ctx: eec74ea | plobsing++ | / (3 files):
encapsulate base pointers in struct
rrot/inside-out-ctx: c1e6a45 | plobsing++ | include/parrot/interpreter.h:
kill unused struct
rrot/inside-out-ctx: 60adcc4 | plobsing++ | / (3 files):
duplicate bp directly in interp since it is accessed so frequently
rrot/inside-out-ctx: 3026a03 | plobsing++ | / (2 files):
kill unused, dangerously encapsulation-breaking function
rrot/inside-out-ctx: 64438ce | plobsing++ | include/parrot/context.h:
use interp bp reference in optimized build register accessors
rrot/inside-out-ctx: 2ef966f | plobsing++ | src/pmc/ (2 files):
only set a context *after* it has its registers allocated
04:50 logie joined 05:05 bubaflub joined 05:29 theory joined 06:31 Kulag joined 06:47 dalek joined, SHODAN joined 06:58 bubaflub joined 07:04 jsut_ joined 07:39 zby_home joined 07:53 mj41 joined 08:12 ajish joined, ajish left, ajish joined 08:13 rohit_nsit08 joined, ajish left 08:38 rfw joined 08:43 cotto joined
cotto ~~ 08:57
09:01 Eclesia joined
Eclesia hi 09:01
09:04 jsut joined 09:09 jsut_ joined 09:12 Kulag joined 09:20 Kulag joined 09:22 not_gerd joined
not_gerd good morning, #parrot 09:22
cotto hi not_gerd 09:23
seen soh_cah_toa
aloha soh_cah_toa was last seen in msg 1 days 4 hours ago <private message>.
09:25 lucian joined
not_gerd I started to fix the test failures on msys, and a lot of them are path issues 09:28
for now, I just added special cases to the test files
however, that's somewhat brittle
a saner approach would be to provide our own implementation of 'use Cwd;'
I don't know if that's overkill for just a single, somewhat obscure platform...
09:29 rohit_nsit08 joined
cotto Is Cwd not core? 09:38
dalek kudo/nom: b2c2669 | moritz++ | t/spectest.data:
run pointy-rw.t
tadzik Cwd was first released with perl 5
seems like it is 09:39
cotto lyup
*yup
not_gerd, would using Cwd be sufficient?
09:40 gaz joined
not_gerd cotto: the problem is that msys-perl uses unix-style virtual paths, whereas Parrot needs windows-style paths 09:42
thus, you can't compare paths returned by cwd with paths coming from parrot
cotto how much work would reimplementing be? 09:47
If it's not too much code and if the code is straightforward, I'd be happy to go that route. 09:52
not_gerd cotto: it would probably be less code as I won't have to repeat myself in every test file 09:53
cotto not_gerd, can you hack it up and submit a pull request? 09:54
not_gerd++ #for working on this 09:55
not_gerd sure, will work on it later today 09:56
I'll have to take another look at the test files to see if providing a decicated function for path comparisons might be a better approach, though 09:57
not all paths might go through the Cwd::* subs...
moritz why do so many tests compare paths anyway?
10:10 cotto joined 10:13 whiteknight joined
cotto hio whiteknight 10:15
whiteknight good morning cotto 10:23
it's funny seeing you online so early
cotto funny seeing you online so late 10:25
so there :]
whiteknight :)
cotto will be back to "normal" soonish 10:26
whiteknight++ whiteknight++ whiteknight++ for prt0.winxed 10:27
so much nicer 10:28
whiteknight unfortunately, I don't think there is any reasonable way to integrate it into the build 10:37
but it's good to get the ideas straight
cotto really? 10:39
you could chech in the generated pir
*check
whiteknight yeah, that might be what I do eventually 10:40
cotto like with ops2c
10:41 PacoLinux_ joined
whiteknight I haven't even tested this winxed code yet. I'm going to give it a spin now 10:44
10:45 ssqq joined
ssqq hello 10:47
how i log this irc with mIRC?
How to config the server name? 10:48
whiteknight ssqq this channel is already logged 10:49
irclog.perlgeek.de/parrot/today
10:53 cotto joined
ssqq I used firefox to log this , I want log here with mIRC to config the background and font 10:53
moritz then ask the mIRC folks for help 10:56
10:59 hernan joined
dalek rrot/whiteknight/frontend_parrot2: 0f113c0 | Whiteknight++ | frontend/parrot2/prt0 (3 files):
Use prt0.winxed to build the frontend. check in the generated .pir file. cotto++ for the suggestion
 11:05
11:13 cotto joined 11:38 gaz joined 11:39 zby_home joined
dalek rrot/whiteknight/frontend_parrot2: 416b1d6 | Whiteknight++ | / (2 files):
fix backtraces. Fixes several tests
 11:40
11:50 whiteknight joined 12:12 rohit_nsit08 joined 12:42 JimmyZ joined 12:48 jsut joined 13:09 kid51 joined 13:10 not_gerd joined
Eclesia and here it is : sourceforge.net/p/eria 13:12
whiteknight Eclesia++ 14:00
14:18 rohit_nsit08 joined
dalek website: rohit_nsit08++ | corellaScript : Functions and Objects 14:27
website: www.parrot.org/content/corellascrip...nd-objects
14:48 Eclesia joined
dalek sella: 6f99502 | Whiteknight++ | src/query/ (5 files):
Big cleanups to the provider API, and expose more functionality through Queryable
 14:50
sella: de24c04 | Whiteknight++ | t/query/Queryable.t:
+stub tests for some of the new Queryable methods
sella: 407cc1b | Whiteknight++ | src/query/ (4 files):
+some comments for new functions
15:02 lateau joined 15:10 lateau joined 15:14 lateau left 15:15 lateau joined 15:25 JimmyZ joined
dukeleto ~~ 15:30
15:51 lateau joined 15:52 lateau left, lateau joined 15:53 theory joined
whiteknight hello dukeleto 15:57
16:00 contingencyplan joined
dukeleto whiteknight: howdy. 16:01
can anybody get to the github web interface?
tadzik yes
16:01 lateau left
whiteknight yeah, github loaded right up 16:09
plobsing whiteknight: I've started implementing the ideas I was talking about last night on the inside-out-ctx branch. it is already 15% better on the mops_intval benchmark
dukeleto i think firefox was having a bad day. restarting seemed to fix everything. 16:11
plobsing: can you explain what the inside-out-ctx branch is about, to mere mortals? looks interesting. 16:12
plobsing dukeleto: it turns contexts, or at least the current one, on their head 16:14
instead of containing the register frame in a context PMC (takes 3 pointer follows to get from interp to the register frame), keep the register frame in the interp and keep the context in the register frame 16:15
this means we have 1 pointer follow to get the register frame
16:16 silug joined
plobsing now considering nearly every op accesses the register frame, this is potentially a huge win for code that spends a lot of time in ops (as opposed to in the runtime system) 16:16
s/runtime system/other parts of the runtime system/
mops_intval is pretty much a flat out ops execution benchmark 16:19
whiteknight dukeleto: and if we keep values in the register frame by default, we can access some important values directly in registers, instead of special-purpose ops 16:21
$Psub would be the current sub, instead of having to do $P0 = getinterp, $P1 = interp["sub"] or whatever the incantation is 16:22
plobsing: yes, I saw the commits this morning and am following along avidly
Eclesia does someone has an exemple on how I can attach properties on a function or class ? I remember it was something like setProp ... 16:39
ha found it : setprop $P0, 'BUILD', $P1 16:42
dukeleto Eclesia: setprop and getprop 16:43
Eclesia dukeleto: thanks ^^
16:45 lateau joined 16:50 lateau left
dukeleto Eclesia: github.com/parrot/parrot/blob/mast...pmc/prop.t 16:56
Eclesia dukeleto: can I set a property on a function argument ? 16:57
dukeleto Eclesia: you can set it on the think you pass in as an argument, if it is a PMC 16:58
s/think/thing/
whiteknight the mother @#%@!* hinge on my laptop screen broke again 16:59
Eclesia dukeleto: but I don't have the 'thing' yet. I only have the class. not any instance yet
dukeleto Eclesia: not sure 17:00
Eclesia: i think you can only set props on instantiated PMCs, but I could be wrong 17:01
Eclesia dukeleto: argument already have properties (I think) to store stuffs like 'optional' or 'slurp' ... 17:02
or am I wrong ?
plobsing Eclesia: those go into a "signature" that parrot reads 17:03
those are not meaningfully extensible
Eclesia plobsing: using reflexion we can get a PMC for the function. so I guess I could acces the list of it's arguments ? and them set properties on them ? 17:04
plobsing the arguments aren't objects. it is a list of integer flags, and messing with them is not supported. 17:05
but yes, you could get that list
Eclesia so my best option is to set the arguments properties in the function property list using some kind of numbering 17:07
plobsing: can I set any kind of object in the properties ? like a Hash ? 17:08
plobsing sure. or an array, which might be more what you're looking for.
Eclesia plobsing: thanks 17:09
plobsing whiteknight: is there a way to lookup a PackfileView PMC from a PackFile*? 17:12
I may just have the solution to the t/pmc/packfileview.t segfault in parrot2 17:13
dalek sella: c9f5873 | Whiteknight++ | / (2 files):
Make sure to wrap queryable results. Add several tests for hash and array behaviors in Queryable
 17:14
sella: ff49cd6 | Whiteknight++ | src/query/Queryable.winxed:
start prototyping some vtable accessors for Queryable
sella: 6fe6cd6 | Whiteknight++ | / (6 files):
refactor provider selection logic into a Factory class. Make a global default provider factory
sella: 80dc59c | Whiteknight++ | src/query/provider/Factory.winxed:
Add in a method to set a specific provider for a given role
whiteknight plobsing: what do you mean?
plobsing: I thought I fixed that failure already
plobsing you did it with a hack IIRC. 17:15
ideally, interp->packfile should always point to the currently executing packfile no? 17:16
if we could lookup the packfile pmc from the packfile struct, we could set it when we switch_to_cs
whiteknight Sub->eval_pmc is the packfile owner of the Sub. At least, it should be 17:17
so you can set it on Sub.invoke
I don't think we currently cache the PackfileView wrapper in the PackFile* struct, but we can 17:18
src/packfile/api.c:Parrot_pf_get_packfile_pmc is the place where we wrap it
plobsing is there a way we can reuse existing PMCs? if we're switching between segments a lot, with no cached mechanism, we're going to be creating more PMCs than necessary 17:19
perhaps we'll just cross that bridge when we come to it
bubaflub ~ 17:20
plobsing wow, no, not acceptable after all. PackfileView PMCs are eternal? 17:22
do we really need to always register them?
whiteknight they're eternal now, to replicate previous behavior 17:24
I want to stop GC registering them, but when we do, errors
plobsing well, allocating a new eternal pfv pmc on every cs switch is completely unacceptable. 17:26
whiteknight why would we be doing it for every switch? When we create the PackFile* we almost always wrap it in a PackfileView 17:27
all we need to do is keep a reference to the one that exists, and switch to it
plobsing exactly, that's cacheing
17:27 ajish joined
plobsing and we need to either cache or eliminate the registration before interp->current_pf can be properly kept in sync 17:28
whiteknight like I said, it should already be cached in each Sub
so we have it, we just need to switch to it
17:28 rohit_nsit08 joined
plobsing why is it cached in the sub, but not the Packfile*? 17:28
17:28 ajish left
whiteknight for GC 17:29
when we mark the Sub, we need to mark the PackfileView that owns it
plobsing ah
whiteknight we can cache it in both places
rohit_nsit08 hello #parrot 17:30
whiteknight or, we can move it so Sub->seg->pf->pmc is the PackfileView
benabik o/
whiteknight hello rohit_nsit08
rohit_nsit08 whiteknight : hello
whiteknight rohit_nsit08++ on the blog post 17:31
plobsing whiteknight: I prefer the latter
whiteknight rohit_nsit08: I haven't been able to test CorellaScript much, yet
plobsing: let's do it
damn the torpedos, full speed ahead
gets rid of an attr in Sub, anyway, and gets rid of most of the last uses of do_sub_pragmas
plobsing OK. I'm doing a lot of (what I consider to be) fixes on the inside-out-ctx branch. I'll commit that there after I get rid of these segfaults. 17:32
whiteknight awesome
let me know if you need a second pair of hands/eyes
rohit_nsit08 whiteknight: thanks, I'm fixing some loose bugs, but it is still not able to compile itself as I have told in the blog post, will try to wind up as much as possible before 22 17:33
whiteknight: I wanted to ask about the documentation
whiteknight rohit_nsit08: sure. What do you need? 17:34
rohit_nsit08 how should I submit it, and it is in html format
plobsing whiteknight: I likely won't have anything until sunday evening (eastern).
whiteknight plobsing: no rush. So much awesomeness takes time
rohit_nsit08: add it to your repo. Create a docs/ folder 17:35
rohit_nsit08: you can create a website on github pages too. But we can do that later 17:36
rohit_nsit08 whiteknight: ohh yes, I once created that . Okay I can get it done. 17:37
17:37 kid51 joined 17:45 bubaflub joined
pmichaud does commit 416b1d6 change the order strings appear in Exception.backtrace_strings ? 17:46
(it switches an unshift to a push) 17:47
oh, it's in a branch, so nm, unless that branch merges with master at some point. 17:48
whiteknight pmichaud: the order in master is wrong 17:50
but yes, it does change the order
pmichaud why is the order in master wrong?
whiteknight if you have 5 rethrows, it would have the backtraces in the order 2, 3, 4, 5, 1 17:53
clearly, the feature is under-tested
dalek kudo/nom: 484052a | tadzik++ | / (4 files):
Fix implicit code blocks detection

Paragraph and abbreviated blocks set VMARGIN not only for their contents, but for all the upcoming Pod as well. This fixes the behaviour and tests, and also adds a new test taken straight from S26.
whiteknight that ordering is only for rethrows. Frames from a single throw are unaffected
pmichaud okay. when it merges to master, be sure to check with me or someone so that we can make sure nqp's use of it is unaffected. 17:54
(or that we can patch nqp to match)
it's possible we were only ever using/seeing the single throw case. 17:55
bubaflub ping dukeleto 18:13
plobsing I'd argue that rethrow shouldn't add another backtrace 18:18
rethrow basically means (to me, as a heavy user of rethrow in Ī©Ī·) that the handler shouldn't have caught but did
and so to pass up the chain
I use rethrow because type-based handler dispatch is insufficiently general 18:19
18:26 schmooster joined
not_gerd msg cotto just sent the pull request with my msys fixes 18:40
aloha OK. I'll deliver the message.
dalek rrot/nqp_pct: f74f55f | benabik++ | docs/pct/bytecode.pod:
[docs] Document bytecode generation for PCT

This adds a simple document that gives the bare bones about how to use newPOST and what to expect if you do. The list of known issues is very short, mostly because I haven't found a good way to generate a comprehensive list.
18:45 mj41 joined
dukeleto bubaflub: pong 18:51
dalek rrot/nqp_pct: 7769a36 | benabik++ | docs/pct/bytecode.pod:
Fix POD syntax in bytecode.pod

I'm not used to writing POD, and I used =cut where I should have used
  =back
bubaflub dukeleto: i blogged recently - i've fixed most of the remaining issues. any thing else you'd like me to put together before Monday?
dukeleto bubaflub: is there anything left on your gsoc roadmap that is only partially done? 18:52
dalek website: benabik++ | GSOC 12: Coming to an end 18:53
website: www.parrot.org/content/gsoc-12-coming-end
dukeleto bubaflub: reading your blarg toast now
bubaflub dukeleto: i have some areas to fill out on the docs and could do a few more examples, but i think what i have is sufficient to illustrate how to use parrot-gmp
dukeleto bubaflub: i think you have accomplished what you set out to do. Congrats! Also, congrats on finishing your masters(!) and the new house. 18:54
bubaflub dukeleto: yup. level up. 18:55
dukeleto bubaflub: if you want a change of pace, feel free to hack on parrot-libgit2. I haven't had any tuits for it lately.
bubaflub dukeleto: Eclesia++ asked for some benchmarks; i could throw some of that together.
dukeleto: definitely, i'll take a look at libgit2. last time i looked there was some oddities loading a function.
dukeleto benabik: nice docs 18:56
bubaflub: there are some passing PIR tests, but I have some winxed tests that blow up
bubaflub: github.com/letolabs/parrot-libgit2/issues/2
18:57 fperrad joined
benabik dukeleto: I tried to spend some time figuring out what isn't working, but the answer appears to be "a lot"ā€¦ But I think it's at a reasonable point for other people to take pokes at it. Right now it's a lot of "find something broken, figure out how to get newPOST to do it". (Although I'm somewhat afraid that there are several large gaps in the newPOST->PBC portion too, which requires deeper knowledge.) 18:57
bubaflub dukeleto: ok, i'm taking a look at it now. 19:01
dukeleto: i can also help generate the NCI thunks that you need so you won't need libffi
dukeleto bubaflub: that would be awesome 19:02
bubaflub dukeleto: github.com/bubaflub/parrot-gmp/blo...winxed#L39 - basically, if they have libffi don't build and install the thunks. if they don't have it, build custom thunks and copy them to a place where parrot can find them 19:03
dukeleto: i'll look at issue #2 first though
dukeleto bubaflub: sweet 19:21
bubaflub: please add any info relevant to debugging that to the gh issue
bubaflub dukeleto: will do
dalek kudo/nom: 2d2ff44 | tadzik++ | src/core/IO.pm:
Implement cwd()
 19:30
kid51 dukeleto: ping
19:38 Eclesia joined
Eclesia back 19:38
19:51 ambs joined
dalek p: 9ba57ef | benabik++ | tools/build/Makefile.in:
Makefile: use MKPATH to make all needed paths

While PARROT_LIBRARY_DIR may exist, it may not exist inside DESTDIR. For example when building for a package manager (even one so simple as stow).
This commit adds the missing MKPATH for PARROT_LIBRARY_DIR and also moves the one for NQP_LANG_DIR/lib to immediately before the files installed into it.		 20:10
p: babcf34 | moritz++ | tools/build/Makefile.in:
Merge pull request #21 from Benabik/master

use MKPATH for PARROT_LIBRARY_DIR
moritz benabik: I've now given you commit access to the nqp repo. Have fun! 20:11
20:13 preflex joined
benabik moritz: Thanks. Haven't been poking at nqp/rakudo much during GSoC, but I'll feel free to push the fixes I make. 20:17
moritz benabik: sure 20:20
benabik: I'm too lazy to merge pull requests, so I throw out commit bits instead :-) 20:21
benabik lazy++
Eclesia NotFound: is it possible to have a more compact syntaxe of : namespace ns1 { namespace ns2 { ... ? 20:25
namespace ns1.ns2.ns3 would be nice
whiteknight plobsing: if you don't care about the backtrace of an exception prior to a backtrace, you don't have to look at it. Each is stored separately in an array, and you only nedd to look at what you want 20:28
pmichaud: Don't worry, the whiteknight/frontend_parrot2 branch is sufficiently invasive. It won't merge silently 20:30
Eclesia: I've asked for the same thing before! I'll try to put together a patch 20:33
Eclesia whiteknight: I think you already have enough stuffs to do more important :D 20:34
whiteknight Eclesia: I like to play with winxed :) 20:35
20:35 lucian joined
Eclesia just navigate between 3 and 6 levels of namespace. a shorter syntax would be appreciate 20:38
20:40 logie joined
whiteknight this might actually be a very easy patch 20:45
20:49 mj41 joined
dalek nxed/dotted_namespace: 7583768 | Whiteknight++ | winxedst1.winxed:
Enable Foo.Bar.Baz syntax for nested namespaces
 20:57
whiteknight Eclesia++ for the idea 20:58
Eclesia ^^ that was fast
whiteknight++ for the hard work :p
whiteknight I told you it was easy 21:00
Eclesia whiteknight: is the commit directly on parrot ? 21:01
Eclesia remember winxed has a separate repo, don't know if it's still the case 21:03
benabik Eclesia: That appeared to be a branch on whiteknight's fork of winxed.
Arg! I hate that packfiles aren't compatible across parrot versions. 21:06
whiteknight Yeah, thats in my fork. I need to talk to NotFound about merging it, and then he has to push it into Parrot repo
dalek nxed/dotted_namespace: 604cdd0 | Whiteknight++ | winxedst1.winxed:
Remove debugging statement
 21:15
nxed/dotted_namespace: 5a0f4ec | Whiteknight++ | t/advanced/10namespace.t:
+tests for dotted namespace syntax
whiteknight msg NotFound I just opened a pull request to add a dotted namespace syntax "namespace Foo.Bar.Baz { }". It is a pretty small patch. Let me know if it needs to be changed 21:17
aloha OK. I'll deliver the message.
dalek rrot/nqp_pct: 03152fb | benabik++ | compilers/pct/src/POST/PBCCompiler.p (2 files):
POST::PBCCompiler - fix calling init subs

1) Since we're about to call main, we should only use init instead of init and load.
2) PackfileView.subs_by_flag is now called subs_by_tag
Eclesia whiteknight: while you are on it, think about declaring complex id namespace, like : namespace 'org:eria'.'paradygm','0.156-SNAPSHOT' { 21:18
whiteknight wowsers
benabik The fact that parrot namespaces and variables can be any string makes writing a language to get at all parrot featuresā€¦ interesting. 21:19
Eclesia whiteknight: winxed does not handle complex names in namespace. at least if we can declare then but still not use them is better then nothing ^^
whiteknight let me see what I can do 21:22
Eclesia getting nice : ftp://ftp-developpez.com/jsorel/temp2/target.png . 2months sumarize in 10 files :) 21:28
whiteknight nice 21:29
dalek nxed/complex_namespace: f350d3f | Whiteknight++ | winxedst1.winxed:
Allow strings as namespace identifiers. Can now parse the example namespace 'org:eria'.'paradygm'.'0.156-SNAPSHOT' from Eclesia++
 21:32
benabik So, I get an odd error when compiling rakudo nomā€¦ When it's compiling perl6-grammar.pir to a .pbc, it says "Lossy conversion to single byte encoding". Anyone have any idea why Parrot would throw that? gist.github.com/1159684 21:33
Eclesia benabik: I seen this one when you write a string with utf characters but read it as ascii 21:34
whiteknight Eclesia: We can parse your example now, in this branch. No real way to use it
well, no pretty way to use it 21:37
benabik Eclesia: So the file is UTF-8 but IMCC is reading it as ASCII?
Eclesia benabik: just what I think. I have plenty of strange character in my langage so I encounter this error before 21:38
I think it's just a missing : filehandle.encoding("utf8"); 21:39
benabik Hm. It looks like everything's been escaped, but I be there's a string that hasn't been.
21:45 Psyche^ joined 21:46 Hunger joined
benabik I'm not finding any non-ASCII in the file. Grump. 21:51
Eclesia benabik: I'm no expert. it was just my thinking :x (I'm still a newbie : 2 month old) 21:52
benabik Eclesia: It was a good idea.
dalek rrot/nqp_pct: 9da949d | benabik++ | compilers/pct/src/POST/PBCCompiler.p (2 files):
POST::PBCCompiler - fix calling init subs

1) Since we're about to call main, we should only use init instead of init and load.
2) PackfileView.subs_by_flag is now called subs_by_tag		 21:54
benabik (Pushed wrong version of commitā€¦)
benabik--
21:55 Hunger joined
benabik Huh. The error went away when I switched off my branch. Curious. 22:03
22:37 soh_cah_toa joined
tadzik oh hi soh_cah_toa 22:44
soh_cah_toa tadzik: howdy 22:45
22:54 Psyche^ joined, jsut_ joined 23:02 bluescreen joined
dalek kudo/nom: c05ba3a | tadzik++ | src/Perl6/Actions.pm:
Fix MAIN regression
 23:05
23:09 TiMBuS joined, theory joined
dalek rrot/nqp_pct: a613ae8 | benabik++ | compilers/pct/src/PAST/Compiler.p (2 files):
PAST::Compiler - fix tempregs

1) I stored the "constant" TEMPREG_BASE in the tempreg frames. This meant that there was only one tempreg counter for all types that never decremented. Fix by cloning the Integer PMC.
2) The PIR code for tempreg() used the value before incrementing to generate the register value. Do this in NQP too, so that the generated PIR is identical.		 23:15
23:21 TiMBuS joined 23:27 coke_ joined
coke_ anyone dealing with teh inode shortage on parrotvm? 23:28
whiteknight not I 23:30
benabik ARG. Stupid inline PIR eating % signs. 23:31
I need to find a better solution for this. 23:32
23:36 TiMBuS joined
whiteknight the solution is simple. we must kill the inline PIR 23:36
benabik That's a HUGE problem. And the fact that I can't get a literal % from the format argument to the final text indicates deeper problems. 23:37
I think StringBuilder has no way of escaping a %.
Huh. It seems that it's supposed to...
Nevermind... 23:38
grump grump grump. I thought I had tried %% already.
coke_ seen mpeters? 23:39
aloha Sorry, I haven't seen mpeters.
coke_ yah, no one has.
so smolder is supposed to be cleaning up and only saving 250 reports. (just bumped it to 256 in case it needed to be changed to fire off). looks like have 995 report.html's sitting around. 23:40
coke_ wonders if we can just delete the report directories, or if this will screw up the DB.
coke_ wonders how many of those reports are for other projects... 23:42
coke_ just rips the old reports out for now and sees what happens.
benabik Diffing generated PIR is fun because I have go change all the timestamp based subids and whatnot. 23:48
Now this is as simple as two quick :%s///g calls in Vim, but finding the new number after each little change to the file... 23:49
My branch dropped the unicode: prefix off some strings. Interesting. 23:51
Ah. There's a difference between > and >= 23:52
vim++ # gvimdiff 23:54
I have now gotten my branch to generate identical PIR as master again. benabik-- for not noticing the differences earlier. 23:56
whiteknight benabik++ for perseverance 23:58

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!