Parrot 4.2.0 "Ornithopter" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 21 March 2012.
cotto nbrown, hio 00:02
Justin hello 00:04
cotto hi Justin 00:06
nbrown cotto: hi, whiteknight said I could talk to you or dukeleto about m0
whiteknight yessir
nbrown cotto: my main issue is that Jimmy and I seem to be developing at odds right now and I'm trying to figure out how to move forward 00:07
cotto nbrown, we're the usual suspects in that area
nbrown cotto: execellent :) 00:08
cotto nbrown, ok. what's the question?
whiteknight cotto: When you have a moment, I'd like your feedback about security 00:09
nbrown cotto: I'm trying to implement the spec and in order to do it I put in some detection of which register is being operated on in the deref operation so that it can tell the difference between IN registers and SP registers since the first are value based and the second are pointer based. Is that the correct approach?
cotto: I think Jimmy wants to pursue a register that is a union of different types 00:10
cotto nbrown, let me dig up the spec for a second 00:12
nbrown cotto: I got all of the m0 tests except the hash and poke caller tests working using that method and single precision floats over the weekend, but had my commits basically reverted because of the conflict of my approach and jimmy's... 00:13
cotto: I'm not complaining in the least, I'm just trying to understand the path ahead so I can help rather than hinder :)
right now, I'm taking a break from the c implementation to take a look at the perl implementation and get it to pass all tests again with double precion floats instead of single precision 00:15
cotto nbrown, M0 registers are just a bunch of bytes that are interpreted to be INSP by the op that's operating on them. Why does deref need to know about the type of a register at all? 00:17
nbrown Well, we could move that logic to the ops instead I guess 00:18
00:18 kurahaupo joined
nbrown cotto: but I'm not 100% sure about that... 00:19
cotto because M0 is low-level and simple, there are ops that won't make sense (and therefore shouldn't be generated by anything that generates M0)
nbrown i agree, give me a second 00:21
well, deref needs to understand the size of the data that it's loading into the register (like int and float = 4 bytes vs SP = 8 bytes) 00:23
cotto yeah. that's why I don't like inconsistently-sized registers 00:24
nbrown and S&P registers hold addresses while I&N hold values
sure, but it's the registers of the constants that we load that cause the issue
00:25 dngor_ joined
nbrown the smaller I&N values cause issues. You need to zero out the register prior to loading to ensure that future goto_if's work as expected for example 00:26
that issue confused me for a while
cotto I can see why.
dumbness is fine, but sharp edges like that are lta
nbrown I agree
I don't think the perl implementation had that issue because it zeroed out the registers on creation unlike c 00:27
my implementation also used single precision floats to align with the perl assembler, but I plan to clean that up soon 00:28
but that caused me to have to play pointer games instead of just casting whenever we wanted do numerical math ops 00:29
I wasn't loving it, but I didn't see another way around it 00:30
cotto: when you get a chance, could you take a look at my branch and let me know what you think? github.com/nbrown/parrot/tree/m0-c-new-ops 00:31
cotto nbrown, sure 00:32
nbrown cotto: I know it's not pretty, but I'm just getting back into c programming
cotto: on my machine it tends to crash the m0_integration.t test, but only because it can't handle the hash and poke_caller tests. It passes the rest of them 00:33
cotto: thanks, I'd appreciate it 00:34
cotto those are the tricky tests 00:37
nbrown cotto: true, plus I hadn't implemented the gc_alloc and whatnot required for the poke_caller
cotto: I was gonna take a shot at the hash one this week, but if I'm headed in the wrong direction, I want to get better aligned first 00:38
cotto nbrown, sure
00:42 workbench joined
cotto Hmmm. The spec doesn't specify floating point precision. 00:45
that's kinda important
nbrown cotto: yes it does
cotto: let me find it 00:46
"N registers are 8 bytes wide. By default, instructions which work with N registers will assume IEEE 754 64-bit semantics." 00:47
cotto ah. I was looking for "double" and "single".
nbrown cotto: although those by default statements worry me a little
cotto: how does one get anything other than the default interpretation? 00:48
cotto nbrown, I'm not sure what "by default" there means.
nbrown cotto: the phrase by default also shows up "By default, instructions which work with integer values will assume that I registers are unsigned." 00:49
cotto: I'm glad I'm not the only one
cotto nbrown, feel free to remove that. It doesn't make the spec easier to understand. 00:51
nbrown cotto: cool, I'll submit a pull request that removes that phrase as appropriate 00:53
cotto nbrown, you don't have a commit bit?
nbrown nope
cotto: i played with m0 a little last year, disappeared forever and am just getting back into it 00:54
cotto nbrown, welcome back then
nbrown cotto: thanks
01:05 benabik joined 01:12 alvis```` joined
bacek_at_work aloha, humans 01:13
cotto aloha, bacek_at_work 01:19
bacek_at_work hio cotto
whiteknight hello bacek 01:28
bacek_at_work whiteknight 01:29
quick question: should C<current_object> be part of C<Context> or C<CallSignature>
whiteknight context, I think
bacek_at_work (related to unmerge_context)
whiteknight, why?
it's "object for next call" 01:30
whiteknight no, you're right
signature
bacek_at_work ok
whiteknight don't ask me a third time!
benabik whiteknight: why?
;-D
It's it's "object for next call", why is it _current_ object? 01:31
bacek_at_work benabik, legacy of dark age
actually, it was part of interp before I moved it into CallContext. 01:32
now it's time for next move :)
actually... 01:33
Why do we need "current_object"?
Isn't it just first parameter in Signature for method calls?
Or I missed something really obvious?
benabik Sometimes it's Parrot that's missed the really obvious. 01:34
bacek_at_work benabik, yeah... Looks like it always goes in pairs: push_pmc and set_object. Smells like a bit of redundancy for me. 01:38
benabik Does anything _use_ current object? 01:39
bacek_at_work benabik, erm... May be some "introspection like API"? 01:40
definitely not through standard PCC call mechanizm
dalek rrot/bacek/unmerge_context: 186a1c5 | bacek++ | src/pmc/callsignature.pmc:
Reorder static functions in CallSignature PMC
 01:43
rrot/bacek/unmerge_context: ff07689 | bacek++ | / (2 files):
Hack to disable set/get object
bacek_at_work whiteknight, if you can have a look.
whiteknight, t/op/exceptions.t ................... 22/32 Can't exec "./winxed": No such file or directory at t/op/exceptions.t line 706. 01:44
looks like there is some wrong tests which shouldn't be executed after make corevm/coretest
whiteknight bacek_at_work: current_object is used to tell whether a function is a method or not
bacek_at_work whiteknight, from where? 01:45
whiteknight I don't know if we *should* do that
bacek_at_work we are putting implicit unpack of "self" inside :methods
why do we need more?
and afaiu self == current_object 01:46
or even "===" 01:47
(After my latest commit parrot build in full. And only few not related tests failed) 01:50
Even TGE passed all tests
something like this gist.github.com/2288708 01:52
whiteknight we need to kill implicit self
benabik whiteknight: +1 01:53
Tene +1
bacek_at_work whiteknight, erm... Why? 01:54
aloha, gist.github.com/2288708 01:55
aloha bacek_at_work: [ unmerge_context test results -- Gist ]
bacek_at_work whiteknight, anyway. Even with explicit "self" equivalence of "current_object" and "self" still hold 01:57
I would like to kill C<current_object>. Right now
it's not used in rakudo and nqp. 01:59
And it's not needed for PCC
Looks like leftover 02:00
from previous PCC refactor
cotto, any objections?
dalek sella: 6725abf | Whiteknight++ | VERSION:
[Build] Update VERSION
sella: b9f2783 | Whiteknight++ | s (5 files):
[Xml] Re-write the Xml parser using the same lookahead technique as I used with the Json parser. This should (in theory) allow both parsers to handle non-ascii strings
aloha [ [Build] Update VERSION * 6725abf * Whiteknight/Rosella * GitHub ]
aloha [ [Xml] Re-write the Xml parser using the same lookahead technique as I us... * b9f2783 * Whiteknight/Rosella * GitHub ]
benabik ... Is aloha announcing commits now? 02:01
bacek_at_work benabik, nope... Just link titles 02:02
I'll unload this module
benabik Ah. Pity, that's a useful feature. But somewhat unnecessary to do for dalek.
bacek_at_work I think I can set it up to ignore github commit links 02:03
but not now
cotto bacek_at_work, just leaving. will take a gander after dinner
whiteknight bacek: I'll look at it tomorrow. Right now is bed time
02:06 PerlJam joined 02:07 Util joined, pmichaud joined, tadzik joined 02:12 Coke joined, masak joined 02:16 he joined
Justin @benabik, hello are you still on. I have a quick question 02:22
benabik Justin: shoot
Justin I saved the timeline for last. Im trying to figure out how to break the core project down into smaller blocks. Besides adding the permissions/restrictions I was thinking of dividing this project into 3 main pieces, Interface, permissions/restrictions and implementation. WHat do you think? 02:23
RIght now I am working off limited knowledge so I know there are key aspects that I am missing
any suggestions?
benabik Well, I'm not completely certain of your project, but it sounds good. I generally just keep trying to break things into smaller sensible bits. 02:24
02:29 aloha joined 02:30 bacek_at_work joined
dalek rrot: 53a07f9 | petdance++ | src/platform/generic/dl.c:
Added ASSERT_ARGS calls
 02:51
rrot: 5b6d3dc | petdance++ | src/platform/generic/dl.c:
the arg to remove_handle_entry() can be NULL
 02:52
bacek_at_work cotto, meh... We even have test to check that "current_object" === "self". github.com/parrot/parrot/blob/mast...ths.t#L651 03:02
aloha (parrot/parrot) Issues opened : 754 (M0 double precision) by nbrown : github.com/parrot/parrot/issues/754 03:04
03:28 Justin joined 04:04 Justinlh joined, Justinlh left
dalek rrot: c32af4b | bacek++ | src/platform/generic/dl.c:
Fix push_handle_entry signature. NULL handles are kind of valid
 05:34
rrot/kill_current_object: 8f5eff6 | bacek++ | / (17 files):
Get rid of CallContext.current_object. It's useless
bacek_at_work msg cotto I would like to merge kill_current_object branch asap :) 05:36
aloha OK. I'll deliver the message.
06:15 alvis joined 06:21 fperrad joined
moritz all rakudo spectests pass on top of parrot/kill_current_object 06:23
bacek_at_work++
bacek_at_work moritz, making parrot better one step at the time :)
moritz increasing bacek_at_work's karma one at a time :-) 06:24
bacek_at_work moritz, :)
dalek Heuristic branch merge: pushed 23 commits to parrot/ayardley/parrot_github_release by ayardley 06:30
07:25 lucian_ joined
dalek rrot/kill_current_object: de3545f | moritz++ | src/pmc/sub.pmc:
remove unused variable
 08:02
08:40 lucian joined 08:45 pjcj joined
dalek rrot/pcc_reorder_signatures: ef150bc | bacek++ | / (3 files):
Add CallContext.temporary_context to preserve existing behaviour of CallContext creation on caller side
 08:46
rrot/pcc_reorder_signatures: d13f53c | bacek++ | / (2 files):
Rename merge_signature to merge_context to reflect reality
rrot/pcc_reorder_signatures: 33c9658 | bacek++ | / (2 files):
Fix get_next_context accessor
bacek oh shi... 08:47
nine ?
bacek wrong branch pushed
nine oops 08:48
dalek rrot/bacek/unmerge_context: 53a07f9 | petdance++ | src/platform/generic/dl.c:
Added ASSERT_ARGS calls
 08:57
rrot/bacek/unmerge_context: 5b6d3dc | petdance++ | src/platform/generic/dl.c:
the arg to remove_handle_entry() can be NULL
rrot/bacek/unmerge_context: c32af4b | bacek++ | src/platform/generic/dl.c:
Fix push_handle_entry signature. NULL handles are kind of valid
rrot/bacek/unmerge_context: 8f5eff6 | bacek++ | / (17 files):
Get rid of CallContext.current_object. It's useless
rrot/bacek/unmerge_context: de3545f | moritz++ | src/pmc/sub.pmc:
remove unused variable
rrot/bacek/unmerge_context: 2ed595c | bacek++ | / (18 files):
Merge remote-tracking branch 'origin/kill_current_object' into bacek/unmerge_context

Conflicts:
  \tinclude/parrot/context.h
  \tsrc/call/context_accessors.c
  \tsrc/ops/core_ops.c
  \tsrc/pmc/callsignature.pmc
  \tsrc/pmc/sub.pmc
bacek hmm... 08:58
should have used --no-ff for it...
or squash
or whatever...
dalek rrot/bacek/unmerge_context: 0bcab54 | bacek++ | t/pmc/context.t:
Fix test.
 09:06
rrot/bacek/unmerge_context: c2b429c | bacek++ | config/gen/makefiles/root.in:
Fix dependencies.
rrot/bacek/unmerge_context: 0cbf8d0 | bacek++ | t/pmc/callsignature.t:
Fix test.
rrot/bacek/unmerge_context: 3b856b9 | bacek++ | t/op/cc_params.t:
Fix test
rrot/bacek/unmerge_context: d2867c1 | bacek++ | t/pmc/parrotinterpreter.t:
Fix test.
bacek who the heck wrote result_info op? 09:23
hmm...
nm
09:30 Timbus joined
dalek rrot/bacek/unmerge_context: 1b6fa60 | bacek++ | t/src/embed/pmc.t:
Fix test
 10:13
rrot/bacek/unmerge_context: 4c84bf3 | bacek++ | t/src/embed/api.t:
Fix test
10:49 kid51 joined
bacek YAY! 10:49
dalek rrot/bacek/unmerge_context: 4e7b290 | bacek++ | t/pmc/callcontext.t:
Remove outdated test
rrot/bacek/unmerge_context: e790524 | bacek++ | / (6 files):
Move return_flags to Context. CallSignature hold only params, not expected returns
bacek ok, this branch is ready 10:50
kind of
kid51 ?
What is the purpose of the branch? What would a code reviewer want to look at? 10:51
bacek kid51, it's undoing my 2 years old branch of merging Context and CallSignature. 10:52
just to prepare to switch of allocating of Context on callee side
which will help with clearing of quite few parrot guts. 10:53
actually...
Context is already allocated on callee side. I just need a bit of tailcall optimisations
kid51 Suppose I were to do a diff between master and branch. Which files would I really want to study to see the differences?
bacek context.pmc, callsignature.pmc, src/call/*c 10:55
kid51 Thx 10:56
bacek msg moritz If you have time can you benchmark bacek/unmerge_context branch? I expect it to be 5% _slower_ in current state. 10:57
aloha OK. I'll deliver the message.
kid51 Will we eventually recover that 5%? (For some definition of "eventually"? ;-) ) 10:58
bacek kid51, yes, of course :) 11:01
11:03 benabik joined
dalek rrot/bacek/unmerge_context: 14b30aa | bacek++ | t/ (2 files):
Fix leftover renames.
 11:11
rrot/bacek/unmerge_context: 481932d | bacek++ | src/embed/api.c:
Fix embed call for reset callsignature.
rrot/bacek/unmerge_context: b7c6805 | bacek++ | src/ops/core (2 files):
More aggressively reuse CallSignature for subsequent calls
 11:15
bacek kid51, ^^^ This should recover some of it :)
moritz bacek: nqp build fails on parrot/bacek/unmerge_context 11:46
sixmodelobject.c: In function ‘decontainerize’:
sixmodelobject.c:70: error: ‘enum_class_CallContext’ undeclared (first use in this function)
which kinda makes benchmarking a lot harder :-) 11:47
dalek rrot/bacek/unmerge_context: c9f7a9f | jkeenan++ | MANIFEST:
Update MANIFEST to reflect recent addition/subtraction.
 11:58
11:59 benabik joined
kid51 src/pmc/callsignature.pmc will need POD 12:17
benabik What is this 'documentation' you speak of? We know not of that in these lands. 12:26
12:31 PacoAir joined
dalek sella: f31dfc2 | Whiteknight++ | src/ (2 files):
[Xml] Some parser fixes after the upgrade
 13:15
sella: 8850f9f | Whiteknight++ | src/unstable/xml/ (2 files):
[Xml] Refactor node handling and Document to be simpler. Don't store multiple references to each tag in the document. Fix raw text handling
13:17 whiteknight joined
whiteknight good morning, #parrot 13:17
nine Good afternoon, whiteknight 13:20
whiteknight hello nine. How are you doing today? 13:21
nine whiteknight: tired. Same as the last week or two. I guess I'm in serious need of vacation 13:23
whiteknight yeah, you and me both 13:27
we finally doped the kid up with some allergy medicine last night, so we were able to get a few hours of uninterrupted sleep 13:28
nine Funny how such a basic thing can become such a luxury 13:29
whiteknight seriously 13:32
benabik o/ whiteknight 13:34
moritz currently the small one wakes up once around 10:30pm, and then sleeps through until 6am. What a joy! 13:35
(that is, that's how it was the last two nights)
whiteknight moritz: ours has been waking up around 3am, which is totally awesome 13:36
moritz whiteknight: the awesomeness of that is probably a question of perspective 13:38
whiteknight my perspective is extremely sarcastic
nine With everyone here just craving sleep it's a wonder that we make any progress at all ;) 13:39
whiteknight nine: progress is also a matter of perspective
We certainly do move a lot of code around, for good or ill
nine true, true 13:40
moritz liked 8f5eff69ddce5d95bf60ee70653acde7a5b57a46
whiteknight link? 13:44
moritz whiteknight: github.com/parrot/parrot/commit/8f...e7a5b57a46 13:45
whiteknight oh yeah, bacek is a whirlwind
13:57 Justinlh joined 13:58 JimmyZ joined 14:08 Justin joined 14:16 Justin joined
dalek rrot/m0: b6705e1 | jimmy++ | src/m0/ (2 files):
add prototype of new ops
 15:32
rrot/m0: ab85c1c | jimmy++ | src/m0/ (2 files):
fixed thinko
 15:42
15:42 alester joined, lucian joined
dalek rrot/m0: f35c986 | jimmy++ | / (5 files):
Merge pull request #754 from nbrown/m0-double-precision

M0 double precision		 15:45
JimmyZ aloha: help 15:46
aloha JimmyZ: Ask me for help about: msg, convert, status, vars, karma, auth, chanop, seen, maths, github::announce, infobot, clock, translate, github::pullrequests, loader, xkcd (say 'help <modulename>').
(parrot/parrot) Issues closed : 754 (M0 double precision) by nbrown : github.com/parrot/parrot/issues/754 15:50
16:11 dmalcolm joined 16:12 rich joined
dalek kudo/nom: 1bbf9eb | pmichaud++ | src/core/Any.pm:
Fix slicing of non-lists with infinite ranges (RT #112216, timotimo++).
 16:44
16:55 nopaste joined 17:14 lateau joined 17:15 lateau left, lateau joined 17:16 lateau left 17:20 lucian_ joined
dukeleto ~~ 17:55
17:57 Justin joined
whiteknight hello dukeleto 17:59
18:01 alvis joined
nine Does anyone have an idea what context_gc_mark is about? 18:19
dalek kudo/nom: 4373f09 | moritz++ | src/core/ (2 files):
throw typed X::OutOfRange exception from Any.at_pos
 18:21
whiteknight nine: I think it marks interp->current_context and tree 18:27
nine whiteknight: ack tells me it's only used in src/sub.c (it's a static int). I think it's dead code 18:32
whiteknight oh, I might be thinking of something else
try ripping it out and see what happens
benabik Looks dead to me 18:35
18:35 rich joined
benabik The whole function Parrot_sub_context_start looks dead to me. 18:35
Wait... I misspelled my ack 18:36
Well, it looks pointless anyway.
nine no smoke so far 18:37
Coke smoke! I am reminded to hack on muddle more.
nine Well, removed code is debugged code
Coke nine++ 18:38
nine whiteknight: seems like my success message on Sunday was a bit premature. I still run into random GC problems and segfaults when creating and scheduling a million very short lived tasks 18:39
whiteknight nine: we should be fine with 900,000 or less 18:40
:)
nine The thing is: I added assertions making sure that each PMC is on the interp where it belongs. I added tons of those in every GC function I could find. But still foreign PMCs show up in the work_list and dirty_list but not before. 18:41
whiteknight weird 18:42
what kinds of PMCs are these? The type might tell you where they are coming from
Can you add the assertions to the work_list and dirty_list insertion functions? 18:43
Actually, I think those are macros
nine It's mostly CallContexts and Continuations but not only. I've seen Proxys as well. Since pretty much all I do is creating tasks which do nothing these are just the most common objects so I don't think their type is really revealing. 18:46
And the strangest thing of all: these PMCs are not from the main thread. They are from other child threads which should never happen at all since all child threads communicate exclusively with the main thread.
whiteknight That is weird 18:48
yeah, my best suggestion is to add asserts to the macros for adding things to those lists
nine The only explanation I could imagine would be that the GC maybe scanning foreign memory blocks for pointers. But I've yet to confirm this with some assertion. 18:49
whiteknight even then, the GC's pointer detection would make sure it's in the pool of the current interp
The GC does have functions to allocate memory blocks which might contain pointers 18:53
nine I already have assertions in those places. 18:54
whiteknight okay
nine Oh, now it even found a ParrotInterpreter PMC. A rare catch
whiteknight and you have no idea how it ends up on that list?
nine gc_gms_check_sanity found it in the objects list for generation 1 18:55
whiteknight wtf
18:59 hercynium joined 19:00 nopaste joined
nine Just checked every place where objects end up in the work_list, dirty_list and objects lists. Each one is protected by an assertion. There should be no way a foreign PMC might make it onto those lists. 19:00
It's fitting that gc_gms_check_sanity is the one finding those since this is clearly an insane situation :) 19:04
benabik gc_gms_check_sanity() { return FALSE; } 19:09
whiteknight those lists are linked-lists, right? Are there functions that move an item from one list to another? 19:11
nine They are Parrot Pointer Arrays 19:13
whiteknight we may have to ask bacek if he has insight 19:15
I can fire it up tonight and take a look 19:21
nine Any help would be greatly appreciated 19:22
whiteknight yeah, sure 19:24
nine whiteknight: I pushed my current work version to git@github.com:niner/parrot.git threads_playground
whiteknight okay
nine btw. it's #ps time 19:30
whiteknight blah! I can never remember this damned meeting 19:38
...is anybody else in there? 19:39
19:50 marcel_r joined
nine Good night, #ps 20:14
Good night, #parrot even 20:15
whiteknight goodnight 20:23
20:32 perlite_ joined 20:58 lucian_ joined 22:14 hercynium left 22:25 betterworld joined 22:45 nbrown joined 23:02 benabik left 23:14 kid51 joined 23:57 whiteknight 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!