Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2
Set by moderator on 18 January 2009.
00:01 TiMBuS joined 00:09 AndyA joined 00:18 Whiteknight joined 00:25 Rahly joined
dalek r35731 | Whiteknight++ | trunk/src/gc: 00:41
: [GC] apply a patch from jimmy++ to simplify a debug condition for TT#84
review: www.parrotvm.org/svn/parrot/revision?rev=35731
01:04 Tene_ joined 01:22 particle joined 01:25 tetragon joined
bkuhn Hey, can someone suggest the best example to look at if my goal is wrap an object in C and have it appear as an object in Parrot? 01:34
01:35 kid51 joined
dalek r35732 | julianalbo++ | trunk/src: 02:03
: allow packfile.c to compile with c++ again
review: www.parrotvm.org/svn/parrot/revision?rev=35732
Infinoid bkuhn: a generic object? or something in particular? (Generally that's what PMCs are for.) 02:06
bkuhn Yeah, I'm starting to discover that. I have a data structure in C that I want to present as an object in PIR. Seems that I should just use the NCI and wrap it with PIR code that makes it an objection. Am I on the right track? 02:07
s/an objection/an object/ :) 02:08
Infinoid NCI is for calling functions; PMCs are for representing objects in PIR. together, they fight crime.
if you just want something generic you can pass around, you can probably just use UnmanagedStruct or Pointer as-is. If you want to implement some methods to call on it and that sort of thing, you should probably write a PMC for it, and src/pmc/ is full of examples 02:09
bkuhn Yes, I have some crime I want to fight. It sounds like these are the guys I need.
NotFound bkuhn: if you cat treat the structure as an opaque object, NCI migth be fine. If not, yoy can have more problems.
bkuhn Yeah, I have been looking at examples in the code of opaque objects. I can probably do so and have C function operate on it when I need to reach into it. 02:10
Infinoid great 02:11
02:14 mdiep joined 02:19 jimmy joined
jimmy Anyone helps me to take a look at TT #153? 02:20
NotFound jimmy: Why do you want to modify this function? 02:23
jimmy PMC_IS_NULL did the same action. 02:24
NotFound jimmy: PMC_IS_NULL is mapped to that function in extern/embed usage.
Or at least that was the intention some time ago. 02:25
jimmy PMC_IS_NULL is global.
at least, it works for pmc.c
NotFound jimmy: is a macro, there is no scope for macros. 02:26
mdiep there should be a comment in the source to that effect then
NotFound mdiep: agree, and maybe his declaration must be moved to extend.h 02:28
By the way, some day we must drop the PARROT_CATCH_NULL thing. There are a lot of things that depends on catch null PMC 02:30
jimmy yes, seems that there is a TT on it. 02:31
Coke_distracted jonathan: ping. 02:32
02:32 galeron joined
galeron hi 02:32
What's with the perl channel? 02:33
NotFound jimmy: in any case, currently we cannot implement PMC_is_null by using PMC_IS_NULL, because PMC_IS_NULL can be defined as calling PMC_is_null, depending on what and why we are compiling.
galeron Not anymore perl oriented?
jimmy move PMC_IS_NULL out of PARROT_IN_CORE condition
Infinoid no idea.
galeron There's a bunch of new ops going crazy. 02:34
jimmy NotFound: and then we can remove it.
galeron Where's the perl channel?
purl hmmm... the perl channel is there elite holds discussions
jimmy galeron: irc.freenode.org/perl6
galeron Oh it's moved from here? 02:35
Sigh
Infinoid I think #perl is for perl5
jimmy yep
Infinoid (according to www.perlfoundation.org/perl5/index....c_channel)
shorten Infinoid's url is at xrl.us/becyuw
Infinoid the one jimmy mentioned is specific to perl6.
galeron Not exactly, it's some server admin spouting racial slurs and making bans
NotFound jimmy: we can, but I think that that way just add confusion to the code. 02:36
Infinoid That sounds about average, from what I've heard.
galeron The perl channel used to be a lot better before.
Oh well freenode it is I guess. 02:37
Later
Thanks.
Infinoid good luck, galeron
NotFound jimmy: the reason for the functions is to not depend of exposing an internal variable to the outside world, even if wrapped in a macro. 02:39
jimmy however, PMC_IS_NULL must be defined, why not define it outside?
Infinoid indeed. if I remember right, exporting variables from a DLL doesn't work
jimmy ah 02:40
NotFound: thanks. I know that now. 02:42
NotFound BTW, what is that ASSERT_ARGS(PMC_is_null) thing?
Infinoid NotFound: it enforces NULL checks on ARGIN()/ARGMOD()/ARGOUT() parameters by use of runtime asserts 02:44
NotFound Infinoid: It enforces it in a function where all arguments can be null? 02:45
jimmy maybe we should use BEGIN_ASSERT_ARGS, END_ASSERT_ARGS too make MSVC debug works.
Infinoid no. that's why you declare those parameters as ARGIN_NULLOK() or the like
jimmy but, it is ugly. 02:46
Infinoid if it isn't NULLOK, it gets checked.
yeah, it's ugly. but it seems to be better than the alternative
NotFound Is as ugly as hell. 02:47
Infinoid agreed. unfortunately, the problem it fixes is even uglier
it has exposed (and allowed us to fix) a few bugs already
NotFound Infinoid: and there is some reason to not have a semicolon at his end? 02:48
jimmy yes, makes gcc and msvc more happy. 02:49
Infinoid NotFound: more specifically, msvc doesn't have an equivalent of __attribute__((unused)), and so we need to define it to nothing on that architecture. the semicolon caused tons of C90 warnings in that case
NotFound jimmy: usually there are ways to make the compilers happy without disturbing the programmers.
bkuhn Is embed.pod still current instructions for embedding an interpreter? 02:50
jimmy Hadn't found another way yet. 02:51
Infinoid NotFound: the "proper" solution (in my opinion) would be to fix gcc's handling of __attribute__((nonnull)). The current implementation in gcc 4.x is a bit ... half-written, and often hurts more than it helps.
NotFound Infinoid: my personal view is that we must no use that feature because is a known source of problems for no clear benefit, but I know that opinion is not majoritary. 02:53
Infinoid I advocated getting rid of __attribute__((nonnull)) at one point, too. I was voted down. 02:54
NotFound And the not C99 thing, i fixed problems ot that nature just by adding an scope in several places. 02:55
scopes usually does not harm the compilers nor the programmers 02:56
Infinoid C90, you mean?
the ugly lack of semicolon was due to "mixed declarations and code" errors on MSVC 02:57
I think I can dig up a nopaste if you want details.
jimmy yep, ugly.
NotFound Infinoid: yes, that problem. You fix it just by moving the declarations in a scope.
Infinoid by "scope", you mean adding curly braces? I would love to do that, but with 1800 functions to maintain, it's not very easy 02:58
NotFound I agree that adding a scope to all functions will also be ugly.
Infinoid it's much easier when you are generating the code like with ops2c or pmc2c, but for the bare C files, it's ... time-consuming
this is one of the few things I *do* like about XS :) 02:59
NotFound Infinoid: is some cases there is not even need to add an empty scope, you just need no move the declarations to the appropiate branch of an if.
Infinoid that sounds like a much nicer solution 03:00
for what it's worth, they did something similar to the perl5 codebase. It was Nicholas Clark who suggested it for parrot
NotFound Infinoid: in particular cases is. But for a general prelude to all functions...
Infinoid www.nntp.perl.org/group/perl.perl6....49677.html
shorten Infinoid's url is at xrl.us/bea6n7
Infinoid if you are selective about what functions it applies to, the problem, then, is how do you enforce it as a codingstd 03:01
NotFound Infinoid: the ugliness I see in that ASSERT_ARGS thing is the it remembers me too much of the macro abuse in XS. 03:02
Infinoid what. you don't like my beautiful macros? :P 03:03
I agree that XS is ugly and should be avoided at all costs. I also admit that the current implementation isn't pretty to look at.
jimmy ;(
:(
NotFound Infinoid: I like some macros, but the code that depends too much on them is ususally ugly.
Infinoid the only thing I like about it is that it *works* 03:04
if you've got a better way, I'm certainly open to suggestion
NotFound Don't be afraid, I like to at least have a way to check that pesky nonnulled null problems. 03:05
jimmy wonders Is there a better way?
Infinoid fixing gcc would make me happy
that is, in my mind, the best possible solution. because it can also generate warnings/errors from the perspective of the caller, which is more useful (in my opinion) than just indicating the function that broke 03:06
NotFound jimmy: there is no way, at least until a day when we have a way to check that non-nullness in all usages of the function at compile time. 03:07
Infinoid I'd have gcc generate runtime checks
if the optimizer is relying on it, then the assumption needs to be validated
jimmy as somebody said: removing all functions is the better way.:D 03:08
Infinoid and then it can decide the runtime check isn't necessary when it's just passing a notnull argument to another function being called
kinda like how constness is inherited
it only needs to do the check at the roots of the tree
NotFound Infinoid: I think that is not enough. If we promise to the compiler that will never be called with null, we must have a way to check.
Infinoid yes. I just think it would be nice if gcc could do that check, generating runtime to do it if necessary 03:09
runtime code, I mean.
NotFound Infinoid: if you add runtime checks, you are pessimizing instead of optimizing. 03:10
Infinoid if you have one function with a nonnull argument, which calls another, which calls another, you only need to do the check at the base of the call stack
currently gcc generates compile-time checks when it can, and just shrugs and drops it on the floor the rest of the time 03:11
...but optimizes based on it regardless
NotFound Infinoid: funny you mention the const thing, is also a recurrent problem. 03:12
Infinoid yeah. but I'm primarily concerned with seatbelts, not optimization 03:13
NotFound And possibly related to this one: every place where we have a cast to solve a contness problem, we a have pointer that change type, effectively disabling known information about nonnullness available.
Infinoid hmm, that's a good point. unfortunately, I don't know of a practical way to enforce it other than at function entry 03:14
NotFound Well, that is one more point to keep working in const consistency. 03:15
Infinoid well... on the other hand, hmm
for ARGIN(), that variable shouldn't be modified anyway 03:16
I think I asked about making that one const by default, but Andy said for some reason it wouldn't work
for the others, the ARGMOD() contract is only for its value at the beginning of the function, it doesn't necessarily mean the function can't modify the variable later on 03:17
and so I'm not sure it needs to be sanity checked after that point
...but will the optimizer get confused about this?
NotFound Infinoid: I don't have a clear image of what exactly does that modifiers. 03:18
Infinoid ARGIN() means a pointer is being passed into the function which won't be modified. 03:19
ARGOUT() means a pointer is being passed into the function which won't be read; it will only be written to.
ARGMOD() means both may occur.
the ASSERT_ARGS() stuff makes sure those pointers are not NULL
NotFound The pointed to thing, I suppose. 03:20
Infinoid it doesn't care about the pointed to thing, it's only looking at the pointers themselves
but if the pointer itself is modified, for example, by ptr = realloc(ptr, size, whatever), and then you have a check to make sure ptr isn't NULL, will the optimizer strip out the check in that case? 03:21
I don't know if the __attribute__((nonnull)) is for the variable's initial value, or if it follows the variable even if it's been reassigned.
I'm a little confused about this 03:22
NotFound Infinoid: the comments in the source says "The pointer target" 03:24
Infinoid yeah, that's the difference between ARGIN/ARGOUT/ARGMOD. 03:26
but the difference between ARGxx and ARGxx_NULLOK is about the pointer, not the pointer target
sorry if I misunderstood your earlier comment
NotFound The net changed it ;) 03:27
Turning to the original point, the PMC_is_null function: the macro in that case is just to aid enforcing in a policy that all functions have it? 03:32
Infinoid the macro is nice because then you can skip a function call 03:34
03:34 Ademan joined
Infinoid I gather the function is *only* there for embedders. 03:34
jimmy yes,
NotFound The ASSERT_ARGS macro, I mean. 03:35
jimmy It had'nt been used yet.
ah, I meant PMC_is_null
Infinoid oh. yes 03:36
NotFound Both args can be NULL, so there is nothing to check.
Infinoid well, there's 2 parts to it
NotFound In fact, the interpreter is always NULL in the current implementation.
Infinoid (typing)
first, the test (t/codingstd/c_arg_assert.t) checks that all ASSERT_ARGS_* macros emitted by the headerizer are actually used 03:37
second, I made the headerizer emit them for *everything* to reduce the number of "wtfs" when someone changes the NULLOK tagging on a parameter and all of a sudden codingstd tests fail
in other words, to reduce test flapping.
but I don't feel too strongly about the second part, so I don't mind it being changed
NotFound That is another problem, people frequently forgot, or don't care, to run headerizer. 03:38
In fact I was just abotu to commit a headerize whe we started talking. 03:39
Infinoid yes, indeed. and the codingstd failures don't show up until you have done so
headerizer has still been a pretty useful tool for this purpose :) 03:40
NotFound Infinoid: is not my favourite thing, but I agree is useful. 03:41
Infinoid it's far better than doing it by hand... 03:42
03:42 particle1 joined
NotFound In fact I was just (one more time) fixing c++ buildability, and this things are someway complicating it, but it can just that I'm not yet used to them. 03:44
Infinoid what's the problem? I haven't tried to build for c++ for a while. 03:45
dalek r35733 | julianalbo++ | trunk/include/parrot (2 files):
: update headerizing
review: www.parrotvm.org/svn/parrot/revision?rev=35733
NotFound The usual ones of casting dropping or adding constness. 03:46
Infinoid ah. (picky compilers)++
NotFound Infinoid: but c++ bulidability is a must, I located, fixed and prevented lots of problems thanks to it. 03:47
Infinoid NotFound++
NotFound Now to realclean and configure for g++ again... 03:50
Coke tries to get mdiep back into hacking on partcl and nearly fails due to parrot bugs. 03:53
dalek r35734 | allison++ | trunk/runtime/parrot/include: 03:58
: [pdd30install] Apply change to reduce full pathname to just module pathname. (Reini Urban) Fix part of TT #123.
review: www.parrotvm.org/svn/parrot/revision?rev=35734
04:37 allison joined
allison is committing parrot changes from Windows today 04:38
strange, but not too painful 04:39
a bit like doing development through a porthole window
NotFound This is an "You are enter a military zone" warning of sort?
allison heh, yes :)
Coke hey, allison. 04:47
purl allison is, like, Allison Randal <mailto:allison@perl.org>
allison hey, coke 04:48
Coke that -t1 segfault I just posted seems to be IO related. 04:54
04:58 Andy joined
Infinoid msg moritz Now that we're following the advice from Nicholas Clark in RT #61242, is there any chance you can check whether you still get segfaults building with --optimize? 04:58
purl Message for moritz stored.
allison Coke: mailing list or ticket? 05:01
NotFound I'm unable to fix c++ build now, too much interrelated things to look for. 05:08
cotto allison, re ATTRs, does the suggestion you made on the list ( rt.perl.org/rt3/Ticket/Display.html...txn-521960 ) account for multiple inheritance?
shorten cotto's url is at xrl.us/becy7g
allison cotto: nope, but C PMCs can't really multiply inherit anyway 05:09
cotto ISTR that some do
let me check 05:10
Coke allison: ticket.
TT #193 05:11
cotto Some of the LuaFunction does, but I don't think there are any others.
so multiple inheritance isn't a concern? 05:12
s/Some of //
because that'll make the code *much* simpler 05:13
allison cotto: it's a problem if two parents have attributes of the same name but a different type
cotto: or, if attempting to use a child pmc with a different struct layout with the parent's struct description
otherwise, multiple inheritance will still work 05:14
cotto Do those cases fall in the "don't do that" category or should the code deal gracefully with them?
allison cotto: but, yes, you can go with single inheritance assumptions for now
cotto: the general answer to both is "if you use the standard vtable function/method interface, you won't have problems" 05:16
cotto I'd rather not write something that we know will have to be changed later.
vtable++
allison C-level PMC inheritance has to be changed anyway, so better not to write a hack now that has to be ripped out later
using ATTR declarations isn't required, it's just a convenience, so we're providing the most common case in the convenience 05:17
more complex cases may have to step outside the convenience 05:18
Coke: yup, looks like an IO bug. What platform? Or have you duplicated it on several?
cotto Does that mean I should hold off on the UnionVal deprecation (as far as it'd need an inheritance update) until C-level PMC inheritance can be fixed?
Coke osx/86 for me. I'm guessing that's mdiep's core platform as well. 05:19
cotto: makes sense to me.
allison cotto: you don't need a UnionVal to declare your own data struct 05:20
cotto: so, no
cotto: look at LuaFunction and see what it needs 05:21
NotFound Did we have some policy about trac account names? Must be the same as in the svn repository? 05:25
Coke I don't think that was said, but I imagine it'll be easier if you keep them the same. 05:26
NotFound That can be delayed until we migrate the repo 05:27
Then, can someone give permissions to the NotFound trac account? 05:28
Coke sure. 05:29
you should now have developer access
NotFound Thanks. Must log out and in?
Coke maybe? 05:30
(probably)
allison NotFound: when the svn repository migrates, your svn name will be the same as your trac name 05:32
cotto allison, it looks like it uses PMC_struct_val and PMC_pmc_val similarly to the Sub PMC (and other related PMCs)
allison NotFound: (or, you can maintain two trac accounts, if you'd prefer)
cotto: does it inherit from Sub?
cotto It also uses VTABLE functions from Sub and LuaAny. 05:33
is that what you mean?
allison cotto: the main question is, does it add any new struct members, or could it just use the ones from Sub?
NotFound allison: I like better to change the snv one
allison cotto: if it's not using anything but PMC_struct_val and PMC_pmc_val, it's likely that it can just use a direct copy of Sub's ATTR declarations 05:34
cotto It's also using PMC_metadata and PMC_sub. 05:35
That's all. 05:36
allison is it a known problem that ActivePerl won't even make it through configure on MSVC 2008 Express Edition? 05:40
Cygwin also won't make it through configure 05:41
only Strawberry Perl/MSVC seems to work 05:42
Coke does SDL work anywhere?
allison: strawberry/ming should also work.
allison Coke: don't know, haven't tried it
Coke (which is the default make suggested for strawberry)_ 05:43
allison Coke: I'm not customizing the options here, just taking the defaults, so it may be using ming instead of msvc 05:44
Coke if you type "nmake", you get msvc.
if you use mingw32-make, you get the strawberry toolchain. 05:45
NotFound I don't see any change in the trac, "leave as new" is still the only option available :?
allison I typed 'nmake' but 'mingw32-make' is what was scrolling past on the screen
Coke allison: configure might have hardcoded the choice it told you to make. 05:46
I thought cygwin worked, though. (haven't tried it in some time.)
for the longest time (pre you) I had trouble with cygwin; in the past year or so it's been pretty stable when I try it once every quarter or so.
NotFound Cygwin does not require his own version of perl? 05:47
Coke I thought it did. 05:48
read the cygwin readme in parrot root.
(yes)
allison Coke: yes, looks like it's setting an environment variable for MAKE at the top of the Makefile (setting it to mingw32-make) 05:49
NotFound: yes, I'm using the Cygwin version of Perl
Coke: any special incantations you invoke when you try Cygwin every quarter or so? 05:50
Coke nope. 05:51
oh, yes. there's one.
(it's in the readme. =-)
parrot/runtime/parrot/library/SDL.pir
no, that's not it.
Parrot builds out of the box under Cygwin after
C<export PATH=`pwd`/blib/lib:$PATH>
that's it.
without that, you'll fail hard trying to link against libparrot. 05:52
NotFound Coke: I take some looks at SDL a month ago, seems broken.
Coke Then I won't bother trying to fixup the examples. :| 05:55
dalek r35735 | allison++ | trunk/examples/tge/branch (2 files):
: [cage] Update TGE examples so they'll actually compile and run. Found while attempting to test Reini Urban's path change for TT #123.
review: www.parrotvm.org/svn/parrot/revision?rev=35735
NotFound I think it uses still the :: in namespaces
dalek r35736 | coke++ | trunk/examples/library:
: update opcode usage.
review: www.parrotvm.org/svn/parrot/revision?rev=35736
NotFound Coke: the trac account looks unchanged 05:58
Coke NotFound: did you have an account that was all lowercase? 06:00
NotFound Coke: one sec...
Coke should be fixed. 06:01
trac seems to let me add permissions to things that don't exist.
so I added it to 'notfound', saw it was set, and moved on.
just added it to "NotFound" and removed the wrong permission.
NotFound I was creatig "notfound" now 06:02
Will delete it
Deleted notfound and login as NotFound 06:03
06:03 particle joined
NotFound Ah, yes, now I have cute new buttons 06:04
Coke: thanks
allison Coke: yes, adding permissions to a name that doesn't exist as a user creates a group 06:06
Coke: that's how the 'developer' group was created
06:17 jkva joined
dalek r35737 | allison++ | trunk/runtime/parrot/library/SDL: 06:29
: [pdd30install] Shorten library path, 'library/' prefix unnecessary. For TT #123 (Reini Urban).
review: www.parrotvm.org/svn/parrot/revision?rev=35737
moritz good morning 06:30
Infinoid: optimized make still segfaults for me (during ./miniparrot config_lib.pasm) on 64bit linux 06:31
dalek r35738 | allison++ | trunk/runtime/parrot/library/Test: 06:34
: [pdd30install] Shorten library path, 'runtime/parrot/library/' prefix unnecessary. For TT #123 (Reini Urban).
review: www.parrotvm.org/svn/parrot/revision?rev=35738
Infinoid moritz: hmm. ok, thanks. is that --optimize -specific? I think that might be TT #179 06:36
moritz Infinoid: I'm trying without --optimize now... 06:37
uhm, yeah, segfaults at the same stage 06:40
how very inconvenient
Infinoid TiMBuS: I just noticed your comments and patch to TT #179. That's ... odd. What your patch really does is prevent the get_type() method from actually being implemented, since it no longer parses correctly. 06:41
(METHODs are sorta like XS. In METHODs, the return value is specified in the RETURN() macro, not on the function declaration line.) 06:43
I'd be interested to know if that patch helps on other x86-64 machines 06:45
06:47 HG` joined 06:48 mdiep joined, justin joined 06:49 mc_ joined
mc_ hello all 06:49
purl It's a crazy world, but hello to you too!
mdiep hi mc_ 06:50
mc_ any channel rules somewhere? this is my first time here
oops: nickname already used 06:51
moritz well, that happens 06:52
channel rules: be polite, stay on topic
mdiep we're a pretty easygoing group
khatar pastebin prefered? do i have to introduce myself? 06:53
mdiep purl: nopaste?
purl rumour has it nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
moritz nopaste preferred, no need for an introduction IMHO 06:54
mdiep you can tell purl who you are though.
purl: mdiep?
purl well, mdiep is Matt Diephouse <mailto:matt@diephouse.com> matt.diephouse.com/parrot or .
06:54 namenlos joined
khatar (sorry: i'm comming from france in where we're just strangled by rules and law 06:54
ok 06:55
newbie questions welcome?
mdiep no, purl mdiep is Matt Diephouse <mailto:matt@diephouse.com>
purl okay, mdiep.
moritz khatar: sure
khatar ok
i've tried en.wikibooks.org/wiki/Parrot_Virtua...troduction yesterday 06:56
shorten khatar's url is at xrl.us/beczd7
khatar read the .pir, understood a part of it
i try to squaak -e 'say 42' 06:57
and it fail
moritz has to run to catch the bus, bbl
hope somebody else can help you
khatar data or instructions ?
mdiep how does it fail? 06:58
khatar mdiep, syntax error
i added a ;
but it desn't change 06:59
mdiep looks 07:00
Coke mdiep: hey. 07:02
mdiep Coke: ho.
Infinoid khatar: looks like the implementation in languages/squaak/ has suffered a bit of bitrot; I can't run a simple "say" command either 07:03
mdiep me neither
Coke mdiep: looks like [unknown] will require [return -options -level N] where N is 1 or 2, depending on what you try to unknown.
level 1 is easy (it's just tcl_return)
Infinoid goodnight all
Infinoid z & 07:04
07:04 Theory joined
Coke anything higher than one might require a slight redo on on our control flow exceptions. 07:04
(to basically track how far down we are, and let the control exception keep propagating until the level is reached.
mdiep Coke: I will try to take a look 07:05
Coke mdiep++
bah. woke up at 11am local time, so I'm still wide awake now. 07:06
khatar ok. so i didn't fucked up :) 07:10
mdiep lol, no
07:10 namenlos joined
Coke reclaims at least 4 more partcl spec tests... 07:27
07:34 alvar joined
Coke +3 more... 07:39
mdiep: hurm. haven't seen any commit messages for a few days. 07:40
mdiep: Any objections to me making tclarray a class instead of a PMC? 07:44
(right now it's just there to be a placeholder; I need something I can easily add attributes to for [array search] and friends. 07:45
dalek r35739 | allison++ | trunk/tools/dev: 07:48
: [cage] Fix simple typo in install_files.pl. (Reini Urban)
review: www.parrotvm.org/svn/parrot/revision?rev=35739
mdiep Coke: have at it! 07:50
Coke anyone know how to say a class does a role from PIR? 07:53
mdiep I think there's a roles array that you modify and push the role onto. 07:57
or an attribute, maybe?
Coke in c, it looks like it's a string.
mdiep an array of strings?
Coke so if I do hash and array, it's "hash array"
mdiep oh
Coke also, "ew" 07:58
mdiep that's less than ideal
yes. ew ew ew ew ew.
Coke looks like I need to modify "provides_str", but I don't see a way to get at that from pir.
mdiep there's an addrole opcode 07:59
Coke I think that's for adding actually roles 08:01
I don't think provides_str actually provides roles.
mdiep there's also an add_role vtable 08:04
looks like that might do what you want
Coke roles != provides. 08:05
mdiep ohhh
maybe 08:06
Coke hits the list. 08:11
I would not be upset if the response was "create a dummy role and use that." if it also mean that this got ripped out. 08:13
mdiep heads to bedd 08:18
err... bed
Coke mmm.
I should have done that 4 hours ago.
~~
08:21 iblechbot joined 08:24 particle1 joined
Coke chromatic++ 08:40
08:49 jimmy joined 09:21 bacek joined
jonathan morning all 10:05
purl afternoon, jonathan
10:36 barney joined
dalek r35740 | fperrad++ | trunk/config/auto: 10:37
: [OpenGL] MinGW
: - gives reference & external link
review: www.parrotvm.org/svn/parrot/revision?rev=35740
10:44 particle joined 10:46 kj joined 10:56 masak joined 11:06 gaz joined 11:14 nopaste joined 11:22 ruoso joined
dalek r35741 | bernhard++ | trunk: 11:27
: [Pipp] NEWS item about constants
review: www.parrotvm.org/svn/parrot/revision?rev=35741
r35742 | bernhard++ | trunk:
: [docs] fix a typo
review: www.parrotvm.org/svn/parrot/revision?rev=35742
r35743 | bernhard++ | trunk/src:
: [codingstd] Move ASSERT_ARGS(sub_pragma) to top of function
review: www.parrotvm.org/svn/parrot/revision?rev=35743
11:32 ruoso joined 11:40 kj joined 11:46 ruoso joined 12:00 ruoso joined 12:13 Hinrik joined 12:15 ruoso joined 12:20 Hinrik joined 12:30 ruoso joined 12:44 ruoso joined 12:52 tomyan joined
dalek r35744 | fperrad++ | trunk/t/codingstd: 12:56
: [codingstd]
: SVN keyword Id must by followed by a column
review: www.parrotvm.org/svn/parrot/revision?rev=35744
r35745 | fperrad++ | trunk (6 files): 12:58
: [codingstd]
: fix malformed SVN $Id
review: www.parrotvm.org/svn/parrot/revision?rev=35745
12:58 ruoso joined 13:04 particle1 joined 13:09 bacek joined
dalek r35746 | bernhard++ | trunk/languages/pipp/docs: 13:12
: [Pipp] add ling to namespaces FAQ
review: www.parrotvm.org/svn/parrot/revision?rev=35746
r35747 | bernhard++ | trunk/languages/pipp/docs: 13:13
: [Pipp] type hints are TODO
review: www.parrotvm.org/svn/parrot/revision?rev=35747
r35748 | bernhard++ | trunk/languages/pipp/docs:
: [Pipp] edit cycle over internals.pod
review: www.parrotvm.org/svn/parrot/revision?rev=35748
r35749 | bernhard++ | trunk/languages/pipp (2 files):
: [Pipp]mark leading backslash in 'name', leading backslash is not allowed
: in namespace declaration
review: www.parrotvm.org/svn/parrot/revision?rev=35749
13:13 ruoso joined
dalek r35750 | bernhard++ | trunk/t/codingstd: 13:27
: [codingstd] unexpanded SVN tags are OK for git-svn users and for new
: files
review: www.parrotvm.org/svn/parrot/revision?rev=35750
13:28 ruoso joined 13:42 ruoso joined 13:50 tetragon joined
dalek r35751 | bernhard++ | trunk/languages/pipp/src/pct (2 files): 13:50
: [Pipp] Eliminate token constant_name
review: www.parrotvm.org/svn/parrot/revision?rev=35751
r35752 | bernhard++ | trunk/languages/pipp/t/php: 13:51
: [Pipp] FOO in different namespace block
review: www.parrotvm.org/svn/parrot/revision?rev=35752
14:01 ruoso joined 14:03 pjcj joined 14:07 gryphon joined, bacek joined 14:19 ruoso joined
dalek r35753 | jonathan++ | trunk/languages/perl6: 14:29
: [rakudo] Make proclaim accept a junction rather than thread over it, but give a warning; moritz++ for input on how to handle this.
review: www.parrotvm.org/svn/parrot/revision?rev=35753
r35754 | jonathan++ | trunk/languages/perl6/src/classes (2 files): 14:32
: [rakudo] Handling of junction auto-threading for the single dispatch case with positional arguments. Note that it won't work for built-ins written in PIR; those will start working when we switch to a PIR prelude.
review: www.parrotvm.org/svn/parrot/revision?rev=35754
jonathan gah!
a Perl 6 prelude!!
dalek r35755 | jonathan++ | trunk/languages/perl6/t: 14:33
: [rakudo] Add S03-junctions/autothreading.t to the spectests list.
review: www.parrotvm.org/svn/parrot/revision?rev=35755
14:34 masak joined 14:35 ruoso joined 14:42 Whiteknight joined 14:50 ruoso joined
dalek r35756 | bernhard++ | trunk/languages/pipp (3 files): 14:50
: [Pipp] Add support for constants with fully qualified name.
: Keep the trailing '\\' in namespace names.
review: www.parrotvm.org/svn/parrot/revision?rev=35756
14:53 PacoLinux joined 14:55 riffraff joined
riffraff hi everyon 14:58
barney Hi 15:00
riffraff entered the scene 15:01
riffraff someone knows if there is a way of visualizing what PGE is doing ? I seem to have generated some crazily slow interaction of rules, but I cannot understand what is wrong :/ 15:02
15:03 Andy joined
jonathan At Parrot level, --trace 4 will show you what is being called... 15:03
But it'll be a lot of output.
Whiteknight jonathan, when you get a chance could you add some clarification to TT#158?
15:04 ruoso joined
riffraff ah i never understood what the arguments to trace were supposed to be :) 15:05
thanks
dalek r35757 | bernhard++ | trunk/languages/pipp/t/php: 15:15
: [Pipp] fix expected test output
review: www.parrotvm.org/svn/parrot/revision?rev=35757
jonathan Whiteknight: I'm only talking there about add_method method (not vtable method) in Class PMC. 15:17
And it should actually be just ripping out some code, rather than anything hard. 15:18
15:18 donaldh joined 15:19 ruoso joined 15:25 particle joined
dalek r35758 | bernhard++ | trunk: 15:27
: NEWS about Pipp and m4
review: www.parrotvm.org/svn/parrot/revision?rev=35758
15:30 masak joined
dalek r35759 | jonathan++ | trunk/languages/perl6/src (2 files): 15:43
: [rakudo] Make auto-threading work in the multi-dispatch case.
review: www.parrotvm.org/svn/parrot/revision?rev=35759
masak help, my Parrot doesn't build. :/ 15:45
gist.github.com/49027
jonathan masak: I built on Win32 this morning, so either it's a compiler specific one or something introduced very recently... 15:46
masak I should add that I just switched to this computer.
so yes, it's probably something to do with that. 15:47
jonathan Hmm.
I don't see anything this morning that woulda been likely to do it.
So I suspect the latter.
masak still, a bit worrying.
it should just build out of the box.
jonathan Indeed. 15:49
Hmm. I struggle to see recent patches that may have caused that. :-| 15:50
masak maybe I just have a stricter compiler than everybody else. 15:51
jonathan Erm.
Which one?
That error looks odd. 15:52
Like, header not in sync...but it's in generated code. :-|
Coke-zzz jonathan: trace -4 is also broken again.
jonathan Again?!
15:52 jhorwitz joined
Coke unless you just fixed it. 15:52
masak gcc says it's 4.0.1 here.
Coke there's a ticket for -t4 and for -t1 :| 15:53
jonathan Coke: Nope. I seem to remember someone (might have been me even) fixing --trace=4 a while back.
--trace 1 is broken too?
Coke I was going to ask you about it, since you're the only one who modified the code since I fixed it.
jonathan: in some cases, yes.
-t1 segfaults with the "right" bytecode.
jonathan Hmm. 15:54
Ticket #?
Coke t1: trac.parrot.org/parrot/ticket/193
t4: trac.parrot.org/parrot/ticket/122 15:55
dalek r35760 | pmichaud++ | trunk/languages/perl6/docs:
: [rakudo]: spectest-progress.csv update: 290 files, 6352 passing, 0 failing
review: www.parrotvm.org/svn/parrot/revision?rev=35760
Coke t4's not got a nice reproducible test case.
jonathan Oh, I remember the previous fix now... 15:56
I pointed you at what to copy/paste. :-)
I don't remember updating Perl6MultiSub though. 15:57
With anything additional.
15:57 ruoso joined
jonathan So doubt it's the same kinda problem. 15:57
Coke yah; you committed something to disable GC in the middle of the fix here; no clue what that's for.
jonathan Weird errors.
16:07 Whiteknight joined
Coke Whiteknight: I will gladly take you up on your offer to fix my problem! =-) 16:07
Whiteknight and which problem is that? I blindly offer to fix so many of them 16:09
Coke Whiteknight: where are you looking to see if the override is supported or not? src/pmc/class.pmc ?
whtrac.parrot.org/parrot/ticket/195
er, Whiteknight : trac.parrot.org/parrot/ticket/195
jonathan I suspect Object.pmc. 16:10
Whiteknight src/pmc/object.c, after it's been generated by pmc2c
and src/pmc/object.pmc too.
Coke ah. that actually seems like an easy fix,then.
finding the right place to put your 3 lines of code? 97% of the job. 16:11
16:12 ruoso joined
dalek r35761 | fperrad++ | trunk/config/gen: 16:13
: [OpenGL] MinGW
: - find includes without using environment variable INCLUDE
review: www.parrotvm.org/svn/parrot/revision?rev=35761
Whiteknight Coke: it will be a relatively easy fix. I'll play with it tonight after work
or maybe during my lunch break, if I eat in 16:14
jhorwitz jonathan: ping
jonathan jhorwitz: pong
OH! Yes, I forgot about that ticket you wanted me to look at. Sorry. :-( 16:15
jhorwitz had a chance to look at RT #62326 yet?
LOL
you read my mind
jonathan OK, let me finish getting a fix in for something else I just discovered, and then some more tests, then I'll look at that one. 16:16
jhorwitz awesome. 16:17
16:22 bkuhn joined
Infinoid good morning 16:23
jonathan morning, Infinoid 16:24
Coke Whiteknight: I added a patch to the ticket that adds tests. 16:26
er, /am adding/ my internets are slow. 16:27
there, added. 16:28
only tricky bit is that we should probably still 'does' what our parent does.
Though I would not cry if I could do that check in PIR.
16:31 ruoso joined
masak gradually realizes how little he can do without a built Parrot 16:31
I think this computer is one of those osx_64 thingies.
Whiteknight masak, why isn't your parrot built?
masak anyone else have one of those?
Whiteknight: because it doesn't build. :/ 16:32
gist.github.com/49027
Whiteknight where does the build fail?
masak see gist.
Whiteknight wow, that's a weird error, but it should be easy enough to fix I think 16:33
I don't have a darwin PC, so I can't really test it
Infinoid uh. I would think a realclean would fix that
pmc_default.h is generated from default.pmc
masak Infinoid: why do I need a realclean when it's the first time I try to build? 16:34
masak tries the realclean anyway
16:34 Casan joined
Infinoid masak: I don't know. if the prototype in pmc_default.h doesn't match the declaration in default.c, and they were both generated at the same time by pmc2c, then it seems pmc2c is emitting the wrong stuff 16:34
if its your first time building, then that rules out an old pmc_default.h 16:35
masak the osx_64 thing was a false lead, btw. 16:36
aye, building after make clean produces the same error.
Infinoid ok. what's the definition look like, and what's the prototype look like? 16:37
for me, they are both PARROT_EXPORT INTVAL Parrot_default_is_same(PARROT_INTERP, PMC *pmc, PMC *value) 16:38
(with various amounts of whitespace inserted)
masak INTVAL is_same(const PMC* value) and PARROT_API extern INTVAL Parrot_default_is_same(Interp *, PMC*, PMC* value), respectively.
dalek r35762 | jonathan++ | trunk/languages/perl6/src/parser: 16:39
: [rakudo] When we had a multi foo() rather than a multi sub foo() we didn't call !SIGNATURE_BIND nor did we set the block type to Sub. Fix that.
review: www.parrotvm.org/svn/parrot/revision?rev=35762
Infinoid masak: you want to look at the generated default.c, not the default.pmc
moritz so the difference is a const?
masak oh.
Infinoid though "extern" smells a little off
hmm. it isn't "const" in my checkout, oddly 16:41
masak Parrot_default_is_same(Interp *interp, PMC* pmc, const PMC* value) and PARROT_API extern INTVAL Parrot_default_is_same(Interp *, PMC*, PMC* value), then.
Infinoid I've added const to my copy, and rebuilt src/pmc/default.o 16:42
both the definition and the prototype were updated properly, no build error.
masak any idea why I'm the only one getting this error? 16:43
Infinoid not yet. I think we can rule out 64 bitness, as I'm on linux x86-64 16:44
I'm guessing you get the same error if you do this?
rm src/pmc/pmc_default.h src/pmc/default.c; make src/pmc/default.o
Coke perhaps running the preprocessor on that file would be instructive?
Infinoid its the pre-preprocessor (pmc2c) that seems to be broken.
Coke have we done a diff on the generated .c on his platform vs. a building platform? 16:48
masak Infinoid: aye, same error. 16:49
Infinoid well, the difference seems to be that his .c file has "const" and his .h file doesn't 16:50
masak: though, my .pmc file doesn't have a const, either. is this a trunk checkout, or some branch?
16:51 ruoso joined
masak Infinoid: checking. 16:51
16:51 Tene joined
masak oh! 16:51
erm.
found it, guys.
it's trunk, but it's r19310...
Coke BWAHAHAHA
jonathan ....wow!
Infinoid :) 16:52
masak sorry to take up your time :)
Coke yah, you owe us a cookie. =-)
Infinoid mmm, cookie
masak this is what happens when you specify revision numbers in svn-externals...
masak svn ups 16:53
Coke wow, I figured that was going to be much older than a year.
(it's only, what, about 17 months) 16:54
er, 19
Infinoid yarly. That is a *huge* number of commits
17:07 davidfetter joined 17:10 ruoso joined
jonathan jhorwitz: *Think* I have a fix, doing make spectest to be sure I didn't break anything. 17:11
jhorwitz excellent! 17:12
purl EGG-see-lent!
17:14 gryphon joined
dalek r35763 | jonathan++ | trunk/languages/perl6/src/parser: 17:21
: [rakudo] Fix say A::b() to actually call A::b.
review: www.parrotvm.org/svn/parrot/revision?rev=35763
jonathan jhorwitz: And there was the patch. :-) 17:26
jhorwitz yay, jonathan++ 17:27
jonathan Heh, that randomly fixed a completely unrelated bug too. 17:28
17:29 ruoso joined
jhorwitz even better :) 17:30
confirmed -- works on my end. :) 17:31
17:31 AndyA joined
jhorwitz now if we can get TT #185 ironed out, mod_perl6 will work again. 17:31
davidfetter w00t! 17:32
dalek r35764 | jonathan++ | trunk/languages/perl6/t: 17:36
: [rakudo] Add (probably passing since rvar merge) S12-attributes/inheritance.t to spectest.data.
review: www.parrotvm.org/svn/parrot/revision?rev=35764
17:41 ruoso joined 17:46 particle1 joined 18:00 donaldh joined 18:08 Whiteknight joined, tomyan left
dalek r35765 | infinoid++ | trunk/src/pmc: 18:15
: Merge ssh://infinoid@10.0.254.2/home/infinoid/parrot-dev/test
review: www.parrotvm.org/svn/parrot/revision?rev=35765
r35766 | moritz++ | trunk:
: [NEWS] mention Junction autothreading in Rakudo's section
review: www.parrotvm.org/svn/parrot/revision?rev=35766
Infinoid erk. commit message fail
was supposed to be "As tomorrow is Release Day, temporarily work around TT #179." 18:16
(that'll teach me to make sure I do a rebase before the dcommit) 18:17
dalek r35767 | kjs++ | trunk/compilers/pirc (2 files): 18:18
: [pirc] update README file and TODO file.
review: www.parrotvm.org/svn/parrot/revision?rev=35767 18:19
Infinoid tries again with further clarification 18:21
dalek r35768 | infinoid++ | trunk/src/pmc:
: As tomorrow is Release Day, temporarily work around TT #179.
: Note: this causes pmc2c to not emit the PackfileFixupEntry.get_type()
: method, as it no longer parses correctly.
review: www.parrotvm.org/svn/parrot/revision?rev=35768
r35769 | kjs++ | trunk (2 files): 18:23
: [pirc] remove unused bctest.c file that contained a test framework for bytecode generation. PIRC's bcgenerator works nicely now, and compilers/pirc/src/bcgen.c contains a fairly re-usable bytecode generation interface (except there's 1 thing to make it completely independent from pirc/src/*).
: + update MANIFEST.
review: www.parrotvm.org/svn/parrot/revision?rev=35769
Infinoid just overwrote TT #179's main description by typing his comment into the wrong text box. 18:26
Infinoid isn't having a very good day 18:27
moritz one could also complain about track in this one
I personally don't find it appropriate to force bug submitters to learn a markup just so that trac can uses its wiki capabilities...
Infinoid yeah... and the comment box and description box aren't visually distinct enough (or maybe I'm just used to those things existing on separate pages) 18:31
Whiteknight Coke, I think I got your does issue solved. I'm building and testing now 18:38
dalek r35770 | kjs++ | trunk/compilers/pirc/src: 18:41
: [pirc] add function doc.
review: www.parrotvm.org/svn/parrot/revision?rev=35770
tewk :q 18:44
moritz E37: No write since last change (add ! to override)
jonathan seems to have got the named argument auto-threading stuff working 19:14
commits when make spectest has (hopefully) completed successfully...going for dinner now
19:20 jrockway joined 19:24 ruoso joined 19:29 chromatic joined 19:52 Tene joined
Infinoid oh, cool, I can reproduce the miniparrot segfault in an ubuntu chroot here. 19:57
jonathan Cool, that should give a better chance of it being findable. :-) 20:02
Infinoid Oh, my. I'm stepping through the creation/initialization of the Scheduler PMC, and it seems Parrot_go_collect() got called. I'm starting to strongly suspect it was freed during its own initialization phase. 20:06
chromatic Sounds plausible, if it's vtable goes 0xdeadbeef.
s/it's/its/
need lunch
20:07 particle joined
Infinoid it does. 20:07
purl stays quiet
jonathan staying quiet fail! 20:08
dalek r35771 | jonathan++ | trunk/languages/perl6/src (2 files): 20:12
: [rakudo] Handle auto-threading of named arguments correctly. (The named ones that passed in the single dispatch case seem to have done so as a result of a Parrot bug; this gets them passing for real and also handles the multi-dispatch case.)
review: www.parrotvm.org/svn/parrot/revision?rev=35771
nopaste "Infinoid" at 96.238.213.50 pasted "Scheduler->vtable goes deadbeef in the middle of its own init function." (55 lines) at nopaste.snit.ch/15358
Infinoid I would assume the current stack contains a few local variables that point to the Scheduler object. Which (I guess) means the GC's stack scanner didn't find it. 20:13
jonathan 121 PMC * const pmc = get_new_pmc_header(interp, base_type, 0); 20:19
(gdb)
122 VTABLE_init(interp, pmc);
I'd guess it's on the stack there for sure. As pmc.
Unless somehow it is optimized to just keep it in a register...
...but that'd get shuffled onto the stack during the call.
So hmm, it must be. 20:20
Infinoid Yeah. I start to get a little paranoid about gcc optimizations playing tricks like offsetting the pointer on the stack after some point in the child function when it only needs to reference a particular member from then on
but I'm not quite desperate enough to be poring through the disassembly just yet.
jonathan Infinoid: One thing to check. Somewhere I think we set the point in the stack that we walk down to. 20:21
We're not by any chance creating that PMC *before* setting up that variable, are we?
Infinoid I'm not too familiar with the internals of the GC. any particular place I should start?
jonathan I think it's a member of interpreter... 20:22
Infinoid starts flipping through parrot_interp_t
jonathan void *lo_var_ptr; 20:23
Infinoid (gdb) print interp->lo_var_ptr 20:24
$3 = (void *) 0x0
so, my next question is, is that good or bad?
jonathan Is that at the point of the segfault? 20:25
Infinoid its just after the 0xdeadbeef
but ... if it excludes stack locations with addresses less than 0, I'm not so sure that's the worst thing that can happen
its a starting point tho, I'll see if I can learn more about how this stuff works. 20:26
thanks!
jonathan /* Create a local variable on the system stack. This represents the
"top" of the stack. A value stored in interp->lo_var_ptr represents
the "bottom" of the stack. We must trace the entire area between the
top and bottom. */
Infinoid: It appears to be at least set in runops_int 20:28
But only if it's not already set.
Infinoid ok. if we assume a stack model that counts downward (I don't remember which way x86 counts), you're starting to make more sense
jonathan Thing is, we're likely setting up the scheduler before we've run any ops. 20:29
Infinoid I seem to recall there's some simple stack-like API for telling the GC not to run during a section of code... that might be a quick fix 20:30
jonathan IMCC sets it in imcc_run
Which is called from main.c 20:31
Whiteknight src/cpu_dep.c 20:32
it's ugly as hell, but that's the stack-walking code 20:33
jonathan Infinoid: aha.
See make_interpreter
Whiteknight I know it works for x86, I don't know if it is as reliable for x86_64
jonathan in inter_create.c
interp->lo_var_ptr = NULL;
And later in that function
Parrot_cx_init_scheduler(interp);
Note also that *before* that we unblock GC!! 20:34
/* Okay, we've finished doing anything that might trigger GC.
* Actually, we could enable DOD/GC earlier, but here all setup is
* done
*/
lol
Infinoid heh
in other words, "but since we got here, life is happy, daisies and butterflies"
jonathan Sugget moving the two lines and that comment like, down several :-)
Infinoid that makes a lot of sense. 20:35
jonathan *amused*
pmichaud jonathan: ping
jonathan pmichaud: hi 20:36
Infinoid Parrot_cx_init_scheduler is where all this crashy stuff comes from, so I think you must be right :)
jonathan pmichaud: Is that a reply to my ping, or a ping of your own? ;-)
pmichaud re: r35771 -- so, are we basically planning to do our own argument passing for a while until Parrot catches up to us?
(ping of my own -- didn't see an earlier ping)
Infinoid cool, that triggered a different crash
jonathan Infinoid: It's just possible you want to set the lo_var_ptr...
pmichaud I'm in-and-out today, lots of stuff going on around the house (no school for kids)
jonathan looks up which patch that was 20:37
pmichaud r35771 is the one that handles named arguments, I think.
nopaste "Infinoid" at 96.238.213.50 pasted "miniparrot crash after moving the unblock-GC stuff below the call to Parrot_cx_init_scheduler()" (12 lines) at nopaste.snit.ch/15359
jonathan pmichaud: Don't quite get what you mean. 20:38
We need to detect which argument to thread on.
Oh, you're commenting on my comment about the Parrot bug?
pmichaud yes (more)
chromatic Re: scheduler in a register, the stack scanner uses setjmp to store register contents in a memory structure which we can scan during system area scanning.
pmichaud in r35771, are we only doing this for junction calls?
jonathan pmichaud: Yes.
pmichaud or for every dispatch?
Infinoid fetching thai takeout, brb 20:39
jonathan The Parrot bug in question is that it will let a positional argument fill a named slot.
pmichaud right
I'm hoping that gets fixed, soon.
actually
jonathan So before, when my dispatcher wasn't looking for junctions in named slots, it just worked by accident.
pmichaud I'm hoping that gets fixed. I'm despairing of "soon".
jonathan I didn't know quite why because I knew it wasn't meant to work yet...
pmichaud okay. If what you're doing is only for junctions then I'm great with that. 20:40
jonathan ('cus I hadn't written the code to auto-thread named args...)
pmichaud I haven't had much opportunity to watch the patches in detail this weekend
jonathan Oh, even when the Parrot bug is fixed, we'd still need to find which named argument is the right one to thread over.
pmichaud (or do much rakudo-related over the weekend)
jonathan This isn't a workaround for a Parrot bug. The Parrot bug just worked around my lack of implementation of named arg auto-threading. ;-)
pmichaud jonathan: yes, got it. 20:41
jonathan: understood, and it's fine.
jonathan OK. Sorry the comment message wasn't clear on that.
I didn't commit anything over the weekend either...
So you've only got todays. :-)
pmichaud okay.
thanks. 20:42
you pinged me for something?
jonathan Yeah
I'm getting to the point where the p6 prelude is starting to matter.
pmichaud same here.
this week we *have* to resolve the repository issues.
jonathan Yes, agree. 20:43
pmichaud so that may be delayed by another week
jonathan But basically my reasons are:
(not disagreeing, just want you to understand what I'm needing out of it)
1) Auto-threading of built-ins will just fall out of us having the p6 prelude
So say(1|2) etc (not to mention the operators) won't work until we do that. 20:44
pmichaud iirc, say doesn't autothread. :-)
but yes, I understand the point :-)
jonathan 2) To handle the later parts of my grant, I need to start making various things (e.g. Array) into parametric roles.
I epicly do not want to hand-role those in pir. 20:45
uh, handroll
;-)
pmichaud yes, understood on both parts.
jonathan OK.
say doesn't? Heh. I didn't know that bit. :-)
pmichaud well, it takes a slurpy list as an argument, so no autothreading there :-)
jonathan Oh, yes. 20:46
pmichaud and we really want it to output a junction.
jonathan That makes sense. :-)
How does it output a junction?
Or is that unspec?
pmichaud "1|2" iirc.
it's almost like a call to .perl
moritz right
jonathan Yes. But not quite. :-)
Do junctions stringify in this way generally?
pmichaud yes.
jonathan Or is this special to say/print?
OK, good. 20:47
That's quite easy to write.
Stringify the eigenvalues and join on the appropriate separator.
pmichaud I think it's already written, or is fairly close.
jonathan Does it paren nested junctions too?
rakudo: say 1|2;
polyglotbot OUTPUT[Junction<0xb6a60988>ā¤]
jonathan Close. ;-)
pmichaud rakudo: say ~(1|2);
jonathan rakudo: say (1|)2.Str;
polyglotbot OUTPUT[Junction<0xb6a4b580>ā¤]
OUTPUT[Statement not terminated properly at line 1, near "|)2.Str;"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤called from Sub 'parrot;Perl6;Grammar;eat_terminator' pc 31408 (src/gen_grammar.pir:3387)ā¤called from Sub 'parrot;Perl6;Grammar;statementlist'
..pc 30056 (src/gen_grammar.pir:2854)ā¤called from S...
jonathan fail 20:48
pmichaud fail.
jonathan rakudo: say (1|2).Str;
polyglotbot OUTPUT[Junction<0xb69d01a0>ā¤]
jonathan epic fail
purl i guess epic fail is chopping chili and go pee without washing hands
pmichaud anyway, easy to do when we need it.
jonathan Easier than most of the code I've been comitting of late, yes.
pmichaud yes, I understand the need for prelude, and it's likely to be immediately following the repository stuff.
jonathan wants something easy to work on now. :-)
OK, great.
pmichaud that means that I'll be doing my milestones out of sequence as well, but maybe we can work that out. 20:49
and I just ordered a new notebook last night, so I'll need some way to pay for it :-)
jonathan OTOH, it gives you something on your milestone that you can tick off as done.
Ooh, seems like with today's work I've about done my January grant tasks too. :-) 20:53
Now I need to go back and do those bits I didn't do in December. ;-)
(I've had last week and half of this week as pretty much uninterupted time, so decided to get the big/hard things in during that.) 20:54
dalek r35772 | chromatic++ | trunk (3 files): 21:11
: [src] Added a test for TT #24, where \\xab escapes in literal PIR don't work
: correctly for iso-8859-1 encoding.
review: www.parrotvm.org/svn/parrot/revision?rev=35772
chromatic lathos, the test I added in r35772 relates to the Unicode escaping bug we looked at the other day. 21:12
nopaste "Infinoid" at 96.238.213.50 pasted "This hacky patch fixes the miniparrot segfault." (36 lines) at nopaste.snit.ch/15360 21:17
Infinoid jonathan++ for suggesting it 21:18
21:18 Theory joined
chromatic Seems to me we already have code like that somewhere. 21:19
Infinoid yeah, it just runs too late.
chromatic Could we call it earlier? 21:20
Infinoid as long as it's called before the unblock_GC functions in make_interpreter(), I think it closes this race 21:21
chromatic Are you working on a slightly less hacky patch along those lines then?
Tene chromatic: re ops review: count_eh was broken and completely unused and untested, last I checked.
Infinoid chromatic: I certainly can. 21:22
without the patch, there's a window between the unblock_GC functions and the lo_var_ptr initialization code in imcc_run(), during which, if the gc is called, it fails horribly. Parrot_cx_init_scheduler() is within that window.
chromatic Tene, I thought so too. 21:23
Tene count_eh can be a method on something
jonathan I'm not sure why it's hacky in a way... 21:25
Infinoid jonathan: well, first off, the prototype isn't in a headerfile and I haven't documented it at all 21:26
jonathan I mean, the fix is to set lo_var_ptr, AFAICT.
chromatic Adding a static function in one place when we already have a function which does the same thing in another place, just at the wrong time, is hacky.
Infinoid I don't think the existing initializer is in a dedicated function, c.
chromatic Hm, I thought it was. Perhaps it should be.
Infinoid it's just at the top of imcc_run()
well, that's what I plan to do with my patch
jonathan Sure, then if there's another function we should call that. But the _idea_ behind this fix isn't hacky, is more what I meant. 21:27
Infinoid Glad to hear it. (I'm not at all familiar with this stuff.)
GeJ Good morning everyone 21:28
Infinoid hi GeJ 21:29
uh. and there's another initializer at the top of runops_int(), which is also too late. 21:32
GeJ I'm sorry I can't bother anymore with conversion patches. But $job got in the way. Hopefully, I should be able to resume my Parrot activity in a few days. 21:34
21:37 kj joined
Infinoid chromatic: Was Parrot_init_stacktop() the function you were thinking of? 21:51
chromatic That sounds right.
Infinoid any objection to my calling that from mem_setup_allocator()? 21:52
jonathan Infinoid: Thing is, how deep is that? 21:53
It's not about how early you call it, so much as where the stack is at the point you call it... 21:54
Infinoid jonathan: yeah. mem_setup_allocator() is called from make_interpreter(). The alternative is to call it from make_interpreter(), directly.
Either way I think it will work.
jonathan Perhaps. ;-)
chromatic t/op/trans.t fails with -j
specifically the atan2 test
Infinoid I was just thinking it should be part of the GC init, hence looking at mem_setup_allocator()... 21:55
chromatic Infinoid, the only complication is when Parrot's run embedded from another process.
Provided all of the tests pass (we have tests for that), it's a workable fix.
Infinoid Great. I think I can address the stack-position issue too. With Parrot_init_stacktop(), it isn't about where you call it from, it's about where you got the pointer you're passing to it. 21:56
chromatic Makes sense. 21:58
dalek r35773 | kjs++ | trunk/compilers/pirc (4 files): 22:06
: [pirc] add some #if for comments. + add tests
review: www.parrotvm.org/svn/parrot/revision?rev=35773
Infinoid Sadly, Parrot_init_stacktop() also calls init_world_once(), which also crashes. 22:08
The yaks are lining up.
jonathan hands Infinoid a shaver 22:10
chromatic Why in the world does this not assign to NREG(1) under JIT? 22:11
NREG(1) = atan2((FLOATVAL)NREG(2), (FLOATVAL)NREG(3));
jonathan chromatic: Is the op jitted? 22:12
chromatic I don't believe so, no.
I stuffed fprintf() calls in the body of the op in src/ops/core_ops.c and they print during normal and JIT operations. 22:13
Atan_n_n_n: 1, 1 = 0.785398163397448 (0.785398163397448)
Atan_n_n_n: 1, 1 = nan (0.785398163397448)
The second case prints NREG(2), NREG(3), NREG(1), and the results of the atan2 call directly. 22:14
jonathan What does the NREG macro resolve to? 22:16
chromatic The appropriate N register based on the register number of the opcode address + offset.
jonathan Under JIT too? 22:17
chromatic Yes.
dalek r35774 | jonathan++ | trunk/languages/perl6/src (2 files): 22:20
: [rakudo] Make //= work (but see RT#61880 for discussion on this patch).
review: www.parrotvm.org/svn/parrot/revision?rev=35774
22:22 TiMBuS joined 22:27 particle1 joined
dalek r35775 | infinoid++ | trunk (5 files): 22:31
: [core] The GC is being called too early, and didn't have enough stuff
: set up yet to scan the stack effectively. This caused early frees of
: critical objects (in this case, the Scheduler) and crashed miniparrot
: during the build process. Initialize the stack pointer stuff earlier,
: before the GC is enabled. This fixes TT #179.
review: www.parrotvm.org/svn/parrot/revision?rev=35775
r35776 | infinoid++ | trunk/src/pmc:
: Undo the TT #179 workaround... reenable building of the get_type() method.
review: www.parrotvm.org/svn/parrot/revision?rev=35776
Infinoid chromatic: Please sanity check r35775 for me, if you have a moment.
chromatic Looking now. 22:32
It looks sane. 22:33
Infinoid thanks! 22:35
PerlJam, TiMBuS: do either of you have a moment to see whether miniparrot still segfaults in the current trunk? (I was able to reproduce it locally, and seem to have fixed it here.)
22:35 gravity joined
TiMBuS Infinoid, yeah i just did a svn checkout and it compiled fine 22:36
Infinoid TiMBuS++, thanks for all your testing help
TiMBuS no problem. it gets you motivated to help out when its not working heh 22:37
kj or mapping) 22:41
mmm.
jonathan: hi
jonathan kj: hi 22:44
purl que tal, jonathan.
jonathan muy bien, purl... 22:45
purl i guess muy bien is spanish right?
Infinoid purl: Your attacks upon us will not go unpunished. You are in contravention of the New Paradigm.
purl OK, Infinoid.
jonathan Yes purl.
kj not sure if all my messages arrive. crap irc client today
anyway, I'm trying to find out where debug mappings are stored in bytecode
apparently, the mappings are there, when running pbc_disassemble
jonathan For PIR file/line numbers?
They go in a debug seg. 22:46
kj well, for each .sub, there's a line like 'Current Source Filename <filename>'
if you pbc_disassemble a pbc file
Andy ping pmichaud 22:47
purl I can't find pmichaud in the DNS.
kj and I can't really find out where 1) the debug segment is created, and 2) when this information is stored in that debug segment
jonathan It's all in pbc.c in imcc
In one routine
I think emit_bytecode or something 22:48
The main one that emits the bytecode.
kj yes I know that one
NotFound kj: I looked for that some months ago when working with the debugger, and failed miserably
jonathan But basically it stores for each op an entry in the data part of the segment.
kj that doesn't promise much good.
jonathan: ok, thanks
jonathan That holds the line number that this op was on.
It's pretty dumb, but works. 22:49
kj ah now I notice the difference between pirc-generated pbc and imcc-generated pbc
hadn't noticed before
22:51 TonyC joined
jhorwitz chromatic: ping 22:57
dalek r35777 | kjs++ | trunk/compilers/pirc/src (2 files):
: [pirc] store PIR source line in the instruction for each, ehm, source line :-)
review: www.parrotvm.org/svn/parrot/revision?rev=35777
chromatic pong 22:58
jonathan kj: There is the mapping section with filenames in the header too, if you didn't already do that bit.
kj no, don't think so. 22:59
jhorwitz chromatic: been working on TT #185, but my fixes exposed other problems. question -- would it make sense for subs with empty labels ('') to be automatically marked :anon?
chromatic as in .sub '' ? 23:00
jhorwitz correct
kj what really troubles me is that the generated PBC can be disassembled nicely, but fails massively when running
chromatic Makes sense to me.
jhorwitz how would that be done?
chromatic In IMCC, when you parse the sub declaration rule, you need to set VT_ANON or whatever the right flag is on the resulting Sub object. 23:02
kj setting :anon in imcc: around line 1105 in imcc.y 23:03
jhorwitz ok i'll try that out. 23:04
kj that's also the part where other flags are set, as 'sub_proto' indicates flags
well, not really, the flags are really set in the actions for sub_proto; aruond line 1330
but I guess you can add it later
chromatic Hm, I wonder if this has ever worked. 23:11
NotFound How do we make references to trac tickets in source comments? TT#num ?
chromatic TT #num
NotFound With a space?
chromatic Please.
As of July last year, the JIT atan2 test triggered NAN. How odd. 23:12
dalek r35778 | allison++ | trunk/src: 23:16
: [install] Include configured 'libdir' and 'includedir' in default search path for libraries and include files.
review: www.parrotvm.org/svn/parrot/revision?rev=35778
r35779 | julianalbo++ | trunk/compilers/imcc: 23:22
: add assertion that catches TT #162 segfault
review: www.parrotvm.org/svn/parrot/revision?rev=35779
r35780 | kjs++ | trunk/compilers/pirc/src (3 files): 23:26
: [pirc] add debug segment and debug info. Not finished yet, but at least pbc_disassemble does now print it.
review: www.parrotvm.org/svn/parrot/revision?rev=35780
23:30 iblechbot joined
dalek r35781 | kjs++ | trunk/compilers/pirc/src (2 files): 23:36
: [pirc] fix source lines for debug info.
review: www.parrotvm.org/svn/parrot/revision?rev=35781
23:43 Whiteknight joined
dalek r35782 | kjs++ | trunk/compilers/pirc/src (2 files): 23:44
: [pirc] Eh. debug linenrs are /not/ fixed yet, but the problem is identified. + add some comments. Will fix Another Day.
review: www.parrotvm.org/svn/parrot/revision?rev=35782
23:49 kid51 joined
Whiteknight Coke here? 23:51

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!