Parrot 1.2.0 released | parrot.org/ | 303 RTs left | Weekly Priority: Profiling
Set by moderator on 28 May 2009.
Coke sure. 00:08
stuff exists, most of it's not shipped with Tcl or partcl. 00:09
nothing cpan-y.
00:21 bacek_ joined 00:27 patspam joined 00:34 Zak joined
Tene asks google for partcl repo 00:40
Coke: can I have commit bit on partcl? 00:42
Coke Thought I already did that. moment. 01:01
code.google.com/u/@WRRfRF1YARJBXQd6/ ?
(same rules as parrot itself) 01:02
Tene Coke: You're right. I forgot again that my googlecode svn password isn't the same as my googlecode password. 01:04
Coke: rules? 01:05
purl <req> No Web/CGI/HTML! This includes CGI.pm, damnit! No colors/bold/autonoise/FAQs/away/mIRCage/paste! No k3wlt0k/u/ne1/plz/im/ill This means you. CGI questions go to #cgi or #cgi-bin. or see pound.perl.org/RTFM/pound.perl.guide.html for even more attitude. :) or !! or foad. diaf.
Coke license/copyright/etc.
Tene Ah.
Coke whatchaworkingon? 01:06
Tene Coke: wanted to add support to load libraries wirtten in tcl from other languages.
All I really need is a way to define things in an appropriate namespace... but if there's a standard tcl way to write a library, that would be obviously better. 01:07
Coke there may very well be. =-) 01:08
Tene And if you could tell me what loading a library from a foreign language should look like in tcl, I could implement that too. 01:09
Coke that is beyond my current level of tcl-fu. I suspect it would involve either package or load. 01:12
Tene I see something about "package provide myLib 1.0
"
oh, "namespace eval" 01:13
www.wjduquette.com/tcl/namespaces.html 01:34
Coke there ya go. =-)
Not all of that code may work in partcl. :(
Tene I know there's at least "eval namespace" 01:35
Coke yup!
package is kind of a hack.
... which should be removed entirely in favor of the library version.
Tene I'd love to show scheme and tcl interoperating in my next blog post.
Coke I think I just stubbed it out to stop getting "invalid command" errors.
ok. If you find anything that doesn't work, open a partcl ticket and I can fixit. 01:36
(or you can, that's also fine. =)
Tene A patch is fine too.
Coke: am I not running the full test suite with 'make test'? I remember complaints about test speed, but that finished in 3m. 01:39
Coke ugh. found another thing that I can't fix until stack traces exist.
Tene oh, 'make spectest'
Coke right.
Tene um, what stack traces do you need? just reporting?
Coke invoked from within 01:42
"parray"
("uplevel" body line 1)
invoked from within
"uplevel 1 $args"
Tene Coke: to work well with other languages, either the "lowercase some HLL stuff" issue in Parrot needs to be fixed, or I'll have to change .HLL 'Tcl' to .HLL 'tcl' and compreg 'TCL' to compreg 'tcl'.
Coke You can go ahead and make those changes.
Tene :)
Coke so, that stacktrace is what you'd get if you ran [uplevel 1 parray]; [unknown] grabs out the error and rethrows it as if you had run it instead of having unknown run it. 01:43
but if it can't find that, it just barfs. 01:44
dalek rtcl: r401 | coke++ | trunk/runtime/variables.pir:
use more box
 01:45
rtcl: r402 | coke++ | trunk/ (4 files):
Add basic support for -errorinfo and -errorcode to catch/return.

if the first run of an unknown results in an error, which needs stacktrace support to work. Ironically, this has slightly broken the functional parray test cases by somehome generating extra whitespace after the output.		 02:10
Coke hurm. scripts expect Tcl version 7.5b1 or later but the loaded version is 02:12
only 8.5.6
ah. library/package.tcl != [package] 02:16
dalek rtcl: r403 | coke++ | trunk/runtime/tcllib.pir:
Claim to be the version we're targeting.
 02:24
02:25 darbelo joined 02:26 ruoso joined
Coke in parrot, how can I tell if a file is executable? 02:27
02:35 janus joined
Coke msg bacek - I tested the wrong variant. I'm getting an error on :flat 03:00
purl Message for bacek stored.
Coke msg bacek (double checking on trunk)
purl Message for bacek stored.
cotto seen tewk 03:18
purl tewk was last seen on #parrot 5 days, 29 minutes and 14 seconds ago, saying: goes to search irc logs [May 27 02:46:07 2009]
Coke msg bacek getting the error on trunk, too; I suspect I've been testing the wrong thing for a few days, so it's not your fault. 03:24
purl Message for bacek stored.
03:27 Theory joined
bacek_ OH HAI 03:35
Coke: apparently not every single bug in the World is my fault :)
03:38 Andy joined
Coke lucky you, or I'd make you fixit. 03:41
I started generating invalid PIR, I think, but I'm not sure why my 'make test' didn't cover this. :|
bacek_ oh shi... 03:46
Coke prove t/tcl_misc.t, if anyone's bored. 03:48
03:49 david joined
bacek_ Coke: why don't switch to PCT? 03:55
Coke bacek: feel free to steal code.google.com/p/partcl/issues/detail?id=59 04:01
I was avoiding it for some time because it didn't support .HLL
now that it does, I have no objection. tcl may not be the best fit for it, but it should still work. 04:02
pmichaud Ugh. hll_map is really slow. 04:04
Coke initial setup or using it later? 04:07
pmichaud using it later
Coke if you can speed that up, tcl will be happy. =-)
pmichaud for now I'll just complain about it. =-)
Time to create 100000 parrot Integers: 0.058s 04:08
Time to create 100000 MyInts through hll_map: 0.315s
Coke where MyInt is a PMC or a class? 04:09
pmichaud class
Coke that might be your slowdown. try mapping Int to Float or something to see if a PMC is faster?
pmichaud it might be my slowdown, but using PMCs isn't really an option for me at present
not without basically rewriting the entire Object system.
Coke no, but it would be nice to know where the slowdown is. 04:10
a better case might be to compare creating 100K non-mapped MyInts, then.
pmichaud about to do that also
Coke and see if the mapping is adding any significant ... ok. =-)
I suspect it's mostly the class. 04:11
pmichaud mapping Integer to Float: 0.086s
creating 100K non-mapped MyInts: 0.400s
Coke see, hll_map is fast! =-) 04:12
it shaved 0.1s off! =-)
<duck>
pmichaud oh, my comparison wasn't really fair there 04:13
just a sec
creating 100K non-mapped MyInts: 0.304s
bacek_ pmichaud: how you create them? Just 'new "MyInt"'? 04:21
pmichaud new $P0 where $P0 is the class object
the first one I did was new ['MyInt'] which added the cost of the class lookup (which is why it wasn't a fair comparison)
so, using new ['MyInt'] --> 0.400s 04:22
using new myintclass --> 0.304s
using box $I0 --> 0.315s
Coke so hll_map is pretty cheap, relatively.
(to class creation itself)
bacek_ oo_get_class doesn't cache created proxies.
pmichaud there's no proxy here. 04:23
well, hll_map is cheap compared to creating the objects of the derived class, but expensive compared to what rakudo is doing now.
Coke were you just using plain integers before? 04:24
pmichaud yes
Coke ah.
I figured you were manually using the classes.
pmichaud No.
Coke well, anything you can do to speed that up, I would appreciate. =-) 04:25
pmichaud sure, but it looks as though hll_map to PMCs isn't so bad
only a 60% slowdown instead of a 500% slowdown =-)
Coke t/compilers/pge/pge_examples (Wstat: 0 Tests: 2 Failed: 0) TODO passed: 2
Files=395, Tests=11929, 255 wallclock secs ( 3.74 usr 3.12 sys + 98.60 cusr 93.01 csys = 198.47 CPU)
Result: PASS
(that on my automated midnight run. 04:26
04:31 Zak joined
Coke I don't know how this test was ever passing. wtf. 05:04
05:04 particle joined
Coke particle: hio 05:17
particle ahoy, coke
just back from sfo 05:18
05:23 Theory joined
pmichaud there are times when Parrot really frightens ms 05:36
*me
Coke ? 05:37
pmichaud nopaste coming
Coke AHA. 05:38
my partcl test failures? introduce by parrot. working on a bisect now.
"uced"
dalek TT #727 created by coke++: remove config steps 'auto:macports' and 'auto:fink' 05:39
Tene eagerly awaits nopaste 05:41
pmichaud just doing some final timings
anyway, here's the gist
bacek_ pmichaud: "$P0 = subclass 'Integer', 'MyInt'" creates Proxy for Integer... And then in 'new "MyInt"' it spent all time working out attributes... 05:42
nopaste "pmichaud" at 72.181.176.220 pasted "DON'T use keyed lookups for isa PMC types in HLLs" (26 lines) at nopaste.snit.ch/16758 05:43
"pmichaud" at 72.181.176.220 pasted "DO use lookups by namespace" (29 lines) at nopaste.snit.ch/16759
pmichaud note that I'm even pessimizing the second example by repeatedly looking up the class inside the loop
Tene pmichaud: should the "load_bytecode" calls in rakudo-generated PIR be replaced with 'load_language'? 05:44
pmichaud Tene: not yet.
Tene Why's that? 05:45
pmichaud because I want to understand exactly what load_language does first
Tene load_bytecode with a different search path.
pmichaud and the search path is... ?
Tene It looks for lang/lang.pbc with parrot_locate_runtime_file_str 05:46
Coke wonders if infinoid is awake.
pmichaud does it check the current directory also? 05:47
or just lang/lang.pbc ?
Tene Let me check...
pmichaud does it work with a devel copy of parrot, as opposed to an installed parrot?
Let's just say that I find it to be very underdocumented, and my (weak) protest is to not use it yet.
Tene It works with either.
No, doesn't look in . 05:48
pmichaud That's a problem.
Coke bah. anyone know why svn-bisect complains that --max 39300 is bigger than 39291 for parrot? 05:49
Tene I'm not sure that the solution is really to change load_language instead of improving the process of working against an uninstalled parrot.
pmichaud I'm not necessarily claiming we should change load_language. 05:50
Tene With 'load_bytecode', precompiled .pm can fail.
is the issue I was running into.
pmichaud ...and load_language fixes that?
Tene Yes.
pmichaud why is it a problem for load_bytecode and not load_language, then?
Tene should 'perl6.pbc' really be in the normal search path for 'load_bytecode'? 05:51
instead of 'languages/perl6/perl6.pbc'?
pmichaud should I have to copy perl6.pbc into my Parrot directory before I can use it with load_language?
what if I don't have write permission to that directory?
Tene I added a symlink to my rakudo checkout to lib/1.2.0-devel/languages/perl6 in my installed copy 05:52
pmichaud what if I don't have write permission to that directory...?
Coke (ah. svn-bisect is too smart for my own good)
pmichaud (as might be the case with an installed parrot)
Tene There's an environment variable for runtime search path.
Coke pmichaud: I imagine you'd put it into a local runtime/ dir.
(as opposed to the installed one.)
Tene Oh, load_language also adds to the include and dynext path.
05:52 Theory joined
pmichaud I'd _really_ like to see these paths documented somewhere. 05:53
Tene Where would you expect to see them documented? 05:54
pmichaud I don't know. I haven't seen any mailing list discussion or documentation about the changes in paths. 05:55
It just seems to "happen".
mind, I'm glad that it happens. I just learned a couple of days ago that I can create my own dynext/ directory for the dynops and dynpmcs (from looking at the tcl makefile) 05:56
but it would be really nice to see that actually written somewhere.
anyway, rakudo's startup sequence is already a little fragile, and it affects 'use' semantics and a bunch of other stuff.
I'm also about to implement BEGIN { ... } 05:57
(like, so that it really works in compiled code)
so I'd rather not muck with the startup sequence right this moment
Tene Okay.
pmichaud also, it still doesn't make sense to me that load_language works but load_bytecode doesn't
that's just... weird
Tene load_bytecode would work if I put perl6.pbc directly into the runtime directory 05:58
pmichaud and load_bytecode *should* work. Libraries can have dynops and dynpmcs too -- those aren't restricted to compilers and languages.
currently load_bytecode fails for me with precompiled .pm
Tene load_bytecode will also work if my cwd has perl6.pbc in it
pmichaud Tene: on my system, with perl6.pbc in the cwd, precompiled .pm files fail. 05:59
it looks like the same issue as TT #150 when I try it.
Tene pmichaud: run parrot under strace -estat 06:00
pmichaud Can this wait, please?
Tene does it not look for ./perl6.* ?
Sure. :)
pmichaud I've been working on postfix:<++> all day, and I'd like to finish it before going to bed tonight.
Tene not currently an issue or blocker for me whatsoever.
pmichaud and I'm getting frustrated by these little parrot oddities here and there (such as the nopastes I just gave) 06:01
Tene I'll write up what I can, and see where to add it to the docs.
pmichaud It might make sense to put it in pdd*_install
and we also need a pdd for compiler objects, so perhaps there
but overall I'd just like to see a summary (mailing list okay) of what the current state of building and installing is (and what it's expected to be) 06:02
Tene hmm. Maybe I can barter some partcl patches with Coke for that. :) 06:03
pmichaud i.e., where language bytecode files go, how one officially creates a "foo" executable that isn't the fakecutable, where libraries go, etc.
dalek TT #728 created by coke++: r39273 breaks 'make test' for tcl 06:13
Coke msg bacek hey, turns out you DO break all the code. =-)
purl Message for bacek stored.
Tene ... ouch. partcl registers a function as its compiler with compreg... not an object. 06:15
So I can't add methods to it without changing that. 06:16
Coke: permission to change that? 06:17
bacek_ Coke: hey, it's impossible
Coke Tene: that code is from when 'compile' was still an opcode. =-)
pmichaud other possibility is to register a different object 06:18
Coke You can change it, sure. I think there's a test in t/ for it.
pmichaud i.e., keep the existing compiler the same, but create a new one under a different compreg name
Coke (it's acting like PIR's compiler, not rakudo's)
no need to keep 2 compilers.
pmichaud fair enough, was just providing a stop-gap. :-)
Coke bacek_: I was being facetious, but in this case, I think r39273 is yours.
Tene Hmm... the existing compiler is registered under 'TCL', which won't work anyway...
pmichaud right.
so just register the new one under the name that will work :-) 06:19
Coke Tene: you can change it to 'tcl', too, that's fine.
pmichaud anyway.
Coke Tene: just be sure to test against r39272 of parrot.
Tene discovers yet again his inability to work with svn. 06:20
dalek rtcl: r404 | coke++ | wiki/Par (2 files):
Document our maximum-required version of parrot, track another parrot bug.
Coke Tene: hey, use a different password. 06:22
Tene: commit something so it'll cache your password. =-)
Tene Coke: it was trying to deal with reverting my local changes this time.
i decided to just rm it all and re-check-out with git-svn 06:23
Coke tene; don't forget to update your credits entry when you commit. Danke. 06:24
pmichaud well, I'm personally shocked at how hard it's turning out to be to get a reasonably-efficient postfix:<++> to work. :-| 06:28
Coke shocked?
purl I'm shocked... SHOCKED...
Coke I tend towards "recurringly disappointed" =-)
pmichaud I'm disappointed, too.
06:28 Zak joined
pmichaud but I didn't expect it to take 12 hours (with small breaks here and there) 06:29
and I'm still not done yet.
Tene: you might have missed the earlier discussion, but it turns out that we lose a ton of speed if we 'hll_map' Integer/Float to Int/Num 06:30
Tene Huh.
I did miss that.
pmichaud boxing $I0 into 'Int' takes about 5 times as long as it does to box it into an 'Integer' (which is what it currently does) 06:31
Tene That's... unfortunate.
pmichaud In fact, that likely means that the takeaway from that is that we should avoid $I and $N registers as much as possible. 06:32
I wonder if cloning is cheaper than boxing. 06:33
Tene Coke: Okay, I'll just do whatever and let you clean up the pieces. 06:34
Coke pmichaud: does rakudo handle nan? 06:35
pmichaud somewhat.
it passes some nan tests and knows how to parse it
Coke oh, duh, I can just special case it. (most floats are created with something like "box 3.2") 06:36
06:37 viklund joined
nopaste "tene" at 24.10.199.37 pasted "weird partcl build failure for Coke++" (18 lines) at nopaste.snit.ch/16760 06:37
Coke Tene: how many *.sos do you have there? 06:38
Tene Four.
Coke what do you get if you run that perl command by hand?
(from the subdir) 06:39
Tene the same output
Coke what OS?
(works for me on feather and OS X...)
Tene Fedora Linux x86_64
It worked fine when I built from svn...
Coke did you reboot^Wrealclean? 06:40
Tene yes
lemme confirm if it works from svn again....
Yes, it works from an svn checkout. wtf? 06:41
Oh... 06:42
[sweeks@kweh ops]$ file ../../dynext
../../dynext: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
where dynext is a directory in my svn checkout?
Coke yes. 06:43
should be an empty dir.
Tene ah, git can't handle empty directories
pmichaud WHAT?!? SOMETHING THAT GIT CAN'T HANDLE?!? :-)
Tene OK, everything works now. :)
Coke I would not be averse to having the directory removed and having it created as part of the build process.
Tene but... but what about workarounds? :( 06:44
Coke if that'll help you use it on git and therefore send more patches.
whee. [expr nan] -> NaN.0
pmichaud anyway, I'm done for the day, I think. I'll pick back up on this tomorrow, along with /lots/ of wonderful things to discuss/explore with jonathan++ :-)
Coke wonders how to generate a nan
Tene 'night pm
pmichaud I think Rakudo does it with 06:45
$N0 = 'nan'
Coke I mean from tcl.
pmichaud oh.
anyway, I'm gone.
Coke I want to see how realtcl formats nan.
later.
bacek_ g'night pm
06:54 UltraDM joined
Coke rant: there's no painless way to check for isNan. :| 06:57
$N0 = $P0, $S0 = $N0, if $S0 == 'NaN' is the cleanest I've found. 06:59
07:00 UltraDM joined
Coke (though that's pretty easy to turn into a macro) 07:06
Tene Oops, forgot to make it actually work right. 07:07
Coke ... that might be a problem. 07:08
dalek rtcl: r405 | tene++ | trunk/ (3 files):
Add a 'tcl' compiler object that has a 'load_library' method
 07:09
Tene Coke: can I dump a tcl file to PIR? 07:10
Coke not really. 07:11
You can do parrot -D60 tcl.pbc foo.tcl, though.
Tene Oh, the proc is named with a leading & in the namespace
Coke (maintaining the --pir option was too much work.)
Tene: yes. since I need to support &foo and $foo 07:12
in tclspeak, [foo] and [set foo]
er, and [namespace foo] =)
Tene oh, procs aren't subs, they're TclProcs. 07:13
Coke which isa Sub. 07:14
Tene Ah.
Oh, that's all... 07:16
I can't call a sub with a name that starts with an & from rakudo.
Coke aha. I blame rakudo! =-)
(Ironically, I made my subs start with that to try to adhere to perl standards, initially) 07:17
now I'm stuck with it, since of namespaces, vars, and subs, having namespaces be the real name seems the most important.
nopaste "tene" at 24.10.199.37 pasted "Having said that, Coke, this now works, as long as you invoke it from the right directory..." (3 lines) at nopaste.snit.ch/16761 07:19
dalek rtcl: r406 | tene++ | trunk/runtime/tcllib.pir:
Make load_library actually return something (mostly) useful.
Tene so Tcl is kinda like a lisp-2
nopaste "tene" at 24.10.199.37 pasted "Oops, here's the .tcl" (4 lines) at nopaste.snit.ch/16762 07:20
Tene Yeah, I have no clue how to deal with that... hopefully pmichaud will have some API ideas on how to get useful names... :( 07:21
Coke: how bad do you think it would be to return symbols without a leading sigil? 07:23
This also means that if tcl imports anything from another language, it will need to add & to incoming functions. 07:28
(and $ to incoming variables?)
Coke yes. 07:32
Unless you can make namespaces not suck.
Tene Well, if it's adding to incoming vars, I'll strip on outgoing vars for now. 07:33
Coke hokay
Tene kinda evil, but... m'eh
07:40 eiro joined 07:42 eiro joined
Tene Coke: check this out: gist.github.com/121293 07:46
Coke is the second block supposed to be tcldemo.pl ? 07:47
Tene Uh, yeah.
Coke then woot. =-)
dalek rtcl: r407 | tene++ | trunk/runtime/tcllib.pir:
Remove sigils from outgoing subs in load_library
 07:48
Tene I tend to use very short filenames, and then rename them in my pastes. Sometimes I miss parts when lieing.
Most commands that I run more than a few times in one shell, I usually set one-letter aliases for.
Now if I can just find out what foreign library *import* should look like for scheme and tcl... 07:49
Coke you broke a test.
Tene :(
Coke prove t/cmd_namespace.t
(you just need to move compiler out of the root_hll namespace. 07:50
Tene oh, into _tcl
Coke <nod>
or parrot, just not tcl. 07:51
dalek rtcl: r408 | coke++ | trunk/ (6 files):
First pass at NaN support in tcl.

  - all operators we tested nan for now properly squawk when used with NaN
  - todo the remaining NaN tests (instead of skip)		 07:53
Tene Coke: fixing...
purl it has been said that fixing is good, definitely.
Coke tene;danke.
support nan is expensive at runtime. =-)
support /of/
all the infix:: ops now have to check explicitly for nan usage in order to generate the appropriate tcl error. 07:54
tene++ 07:55
07:56 iblechbot joined
Tene getting some really weird errors... 08:01
:(
Null PMC access in get_string() 08:04
current instr.: 'compileTcl' pc 23866 (runtime/conversions.pir:367)
That line is:
.sub compileTcl
I don't get it. 08:06
Coke ok. I have to sleep soon; if you can't figure it out, open a partcl ticket with whatever you have, I'll look at it later.
Tene Okay. 08:07
'night
dalek rtcl: r409 | coke++ | trunk/ (2 files):
make [expr nan] fail properly
Coke bacek++ 08:14
Tene Coke: I'll look at it again tomorrow.
08:16 mikehh joined
Coke hokay 08:21
dalek rtcl: r410 | coke++ | trunk/ (3 files):
make function(nan) squawk with a domain error.

All nan-related test in t/cmd_expr.t now pass.		 08:26
08:34 ZuLuuuuuu joined 08:39 barney joined 09:01 masak joined 09:18 mikehh_ joined 09:23 bacek joined
bacek oh hai 09:45
09:56 mikehh joined 10:01 donaldh joined 10:19 rdice joined
bacek msg Coke problem of TT#728 in Scalar.concatenate_str. If I replace Parrot_pmc_try_reuse with pmc_new test passed. But I don't understand roots of this problem... 10:56
purl Message for coke stored.
10:57 rdice left 11:20 donaldh joined 11:49 forthat joined 11:54 muixirt joined
Infinoid bacek: (re: #728) I don't fully understand this code, but... your latter version changes semantics quite a bit, Parrot_pmc_try_reuse() updates the "dest" PMC for *all* code which keeps a pointer to it, and after the patch, only the caller gets the update 12:00
In other words, if I had a string "bar" and had 3 pointers to it (lexpad, stack and register), and another string "foo", and did a "$foo .= $bar", Parrot_pmc_try_reuse() would unset $bar in all places, which most definitely is *not* what we want 12:03
bacek Infinoid: but all calls to "try_reuse" calculate result before...
oh... 12:04
Infinoid I'm not sure my example is completely accurate, but I think that's the semantic difference
bacek It can be not very accurate, but there is some deep hiding bug in Parrot spotter in this ticket 12:06
Because second version of patch fix problem as well..
Infinoid the fact that the second version of the patch fixes the problem, to me, implies that having using Parrot_pmc_try_reuse() there breaks assumptions about the PMC not being shared/used anywhere else 12:08
bacek Hmm...
Infinoid Previously it just returned an empty string, now (with r39273) you're overwriting an existing PMC (which could be used elsewhere) with an empty string
Or do I misunderstand the idea behind Parrot_pmc_try_reuse()? 12:09
bacek No, you don't...
Infinoid ok. Sorry, but I think it sounds dangerous to overwrite PMCs without knowing who else uses them 12:10
12:10 ruoso joined
bacek There is major misundesrtand between me, pmc_reuse and parrot 12:11
And VTABLE 12:12
Consider code: $P0 = hash['key']; $P0 = 1;
Should we update stored value in this case? 12:13
Infinoid in that case I think it will call set_integer on $P0, so probably yes 12:14
bacek (If "yes" than usage of Scalar it incorrect, if "no" than we have to bury pmc_reuse) 12:15
Ah, "yes"...
ok. So we need some kind of resolution. If $Pn treated as pointer, than we hit hit bug in PGE. If not - than I'll apply my patch for try_reuse. 12:17
Infinoid All it does is call set_integer_native, it's up to the PMC to do something intelligent with that 12:18
for instance, for RPAs, I think that will set the number of entries in the array to 1
I don't think it will morph the PMC to an Integer, if that's what you were expecting 12:19
bacek In this case it call "set_string_native", but it doesn't matter...
Infinoid ok
r39273 changed quite a few things, I'm worried about what else it may have broken 12:20
The reason I'm having trouble understanding this stuff is, I'm not sure it's ever possible to detect whether your caller is the only code using this pmc or not 12:21
in some cases, like "$foo = 'bar'", I would expect all copies to be updated, in others, returning a newly created PMC sidesteps that problem (with some extra GC overhead) 12:23
Was the intention of this patch to reduce GC overhead? 12:24
bacek yes
Infinoid that's a great goal :)
bacek indeed... But...
Infinoid I don't have enough time to review the design for this stuff, but I guess it really comes down to whether the caller wants you to update all instances of the pmc, or just generate some local value which the caller might simply discard 12:25
(I have to leave soon) 12:26
bacek I just need one word about treating PMC's as pointers.
I have to go to bed soon :)
12:27 ZuLuuuuuu joined
Infinoid what about treating PMC's as pointers? 12:28
12:28 HG` joined
bacek Than there is bug somewhere else. 12:32
Infinoid where? why? I don't understand
bacek TCL of (unlikely) PGE reuse old PMC after "concat"
Infinoid are you saying it should copy the string before calling concat? 12:33
bacek $P0 = "foo"; $P1 = $P0; $P0 = concat "bar","baz"; say $P1
(copy) Yes. 12:34
before r..3 $P1 was preserved.
after - not. 12:35
Infinoid in this case, it is the caller who decides what to do with the truncated string. it might assign it back to the original variable or it might discard it, the concat method can't know
that's why it's hard to review the design of this, because the semantics vary depending on which method
bacek "<bacek> I just need one word about treating PMC's as pointers." :) 12:36
Infinoid inline op concat(out STR, in STR, in STR) :base_mem { 12:37
$1 = Parrot_str_concat(interp, $2, $3, 1);
}
I think your change is modifying $3
even though it's only supposed to be an "in", not an "inout"
the caller gets the new string as the return value, $1 12:38
bacek inline op concat(invar PMC, invar PMC, in STR) :base_core { 12:39
$1 = VTABLE_concatenate_str(interp, $2, $3, $1);
}
this one.
purl it has been said that this one is bugged too now
bacek Someone holds $1.
And I update it....
Infinoid are you sure? $P0 = concat "bar","baz" looks like two STRs
bacek Second patch for concatenate_str. So I'm 100% sure 12:40
(But my example if 100% incorrect) 12:41
It should be something like this: 12:42
$P0 = "foo"; $P99 = $P1; $P1 = concat $P0,"baz"; say $P99 12:43
(oh. My English is failing.) 12:45
Infinoid ok
bacek It should by "is 100%" few lines above.
Infinoid So the issue is, $P99 and $P1 aren't really PMCs, they are register entries (pointers to PMCs) 12:46
Before your change, $P1 would end up pointing to a new PMC, afterwards, the pointer wasn't updated and the PMC itself was overwritten
Right? 12:47
bacek indeed
Infinoid Thanks, that makes sense. This is quite a serious semantic change, no wonder it broke things
bacek Main problem is in "$P0 = hash['key']; $P0 = 1;". 12:49
We have to decide, how $Pn treated. For consistency sake. 12:50
Infinoid Let me guess... hash['key'] is updated, because you're changing the PMC instead of the pointer? 12:51
bacek yes
Infinoid Ok. Please don't do that? :) 12:52
I think any semantic change at the PIR level will require updating all the HLLs, which sounds like a Bad Thing
bacek Should we update stored value in this case?
<Infinoid> in that case I think it will call set_integer on $P0, so probably yes
Infinoid if it didn't update the stored value before, then I would be very reluctant to change that behavior 12:53
bacek (This is next line after my "$P0 = hash['key']; $P0 = 1;" question)
It did, but not always. 12:54
Infinoid Right, I think it depends on the type of PMC
If there's an underlying design issue here, I think that it should really be up to the *ops* to determine which things get overwritten, not the pmc methods themselves 12:55
bacek voted for consistency...
Infinoid but all of this is way above and beyond a simple GC optimization :) 12:56
bacek It's just another "undefined behaviour" in C++ terms...
And I want to make it "defined". 12:57
12:57 gryphon joined
Infinoid I don't have a problem with that. Though I think it would need a deprecation cycle, and a nice flame war on the list beforehand to make sure it's really correct 12:57
bacek :) 12:58
pmichaud hello
the meaning of "$P0 = hash['key']; $P0 = 1' is very clear
it's the same as
set $P0, hash['key']
bacek I will happy to remove try_reuse in favour of PMC_IS_NULL
pmichaud set $P0, 1
the first will bind $P0 to the entry in hash['key'] 12:59
the second will depend on the identity of $P0
most of Parrot's built-in PMCs treat the second like an assign
(but not always, and not all)
Infinoid at the very least, the opinions of allison and chromatic would be valuable before you make that kind of design change 13:00
bacek Hooray!
$P0 = "foo"; $P99 = $P1; $P1 = concat $P0,"baz"; say $P99
Infinoid In the meantime, can you back out r39273 until a less obtrusive optimization can be found?
pmichaud bacek: in that instance, $P99 should be unchanged. 13:01
bacek pmichaud: why?
pmichaud because it's not the same as $P1
the three argument form of concat constructs a new string, it doesn't modify an existing one.
i.e., it's not an in-place concatenation.
so then $P1 ends up pointing to the new string, and $P99 continues to point to the old one. 13:02
bacek $P1 = 1; $P1 = add $P1, 2;
$P1 = 1; $P2 = $p1; $P1 = add $P1, 2; say $P2
pmichaud in this one, $P2 is also unchanged
bacek ok. So try_reuse is wrong. 13:03
pmichaud now then
purl now then are found :P
bacek I'll remove it tomorrow
pmichaud $P1 = 1; $P2 = $P1; add $P1, 2; say $P2 # $P2 changed
because the 2-argument form of add is an inplace add
bacek try_reuse is still wrong... 13:06
dalek rrot: r39301 | barney++ | trunk (3 files):
Some tidbits in PCRE library.
 13:08
bacek we treat $Pn as something between pointers and values. So, we can't reuse them in 3-args ops.
pmichaud I don't quite understand that
Infinoid we're not really trying to map them directly onto C pointer/value semantics 13:09
bacek $P0 = hash['key']; $P1 = $P0; $P0 = 'new_value'; say $P1
pmichaud $P1 unchanged
oh, wait
no
because of the string
(I thought you meant "do something that makes a new value")
the difference is generally that set <pmc>, <pmc> 13:10
means something very different from
set <pmc>, <int>
set <pmc>, <str>
set <pmc>, <num>
Infinoid afk_coke: ping 13:11
pmichaud Personally, I think that's a design issue
i.e., it was done incorrectly
bacek Ha! So "foo_native_TYPE" shouldn't reuse dest? Like "concatenate_str"? 13:12
pmichaud we shouldn't have the set_p_i set_p_n set_p_s opcodes, we should've just stuck with assign_p_i assign_p_n assign_p_s
because the set opcodes really act more like assign
i.e., the change the value of the target PMC instead of changing the PMC register
Infinoid ...sometimes 13:13
set_p_i is useful for (for instance) resizing arrays
pmichaud Infinoid: sure, but assign_p_i does the same thing
Infinoid ah, ok.
even though it's named misleadingly in that case
I guess set_ is just as misleading 13:14
pmichaud anyway, that train left the station a long time ago, I think. 13:15
Infinoid yeah
13:15 burmas joined
bacek but... Why can't catch this train and fix it? 13:16
This code isn't cut on stone
Infinoid it is until we've gone through a deprecation cycle, at the very least 13:17
bacek 1.5 is soon :) 13:18
Infinoid but it seems like a lot of effort (code, documentation and retraining) without much gain
Infinoid would much rather have shiny new features
bacek I've spent ~6 hours investigating this issue... 13:19
pmichaud bacek: changing this would require rewriting basically all of the existing PIR codebase
bacek Just because semantic isn't clear.
Infinoid all of the HLLs, examples, tests would need to be reviewed/edited
pmichaud the semantic is clear if we remember that int, num have value semantics while pmcs and strings have reference semantics 13:20
it's very much like C in that respect 13:21
bacek $P99 = $P1; $P1 = concat $P0, "foo"; say $P99 13:22
It's not quite C-like semantic... 13:23
pmichaud sure it is
if one assumes that "concat" means "allocate a new string that is the concatenation of $P0 and "foo""
13:24 skids joined 13:25 barney joined
bacek Ok, I'll commit second version of patch from T#728 tomorrow and add big warning notice about using try_reuse from "value semantic" function. 13:25
Infinoid What about the other things changed in r39273? I'm worried there may be other fallout, our testsuite probably wasn't written with this kind of semantic change in mind 13:28
13:28 Whiteknight joined
bacek $P0 = hash['key']; $P1 = $P0; $P0 = 'new_value'; say $P1 13:29
$P99 = 'new_value'; $P0 = hash['key']; $P1 = $P0; $P0 = $P99; say $P1
Is it different?
Infinoid yes 13:30
bacek Is it different after implementing PIR optimiser with value propagation?
Infinoid in the first example, if $P0 is (for instance) a Packfile, it will stay a Packfile, and try to unpack the string
the second example uses simple pointer semantics, I think 13:31
bacek ok, I'll add PARROT_ASSERT(value) in try_reuse.
Infinoid if you can fix everything and guarantee that no PIR semantics have changed, great. Otherwise, sorry, but I think you need to back out the patch 13:33
bacek I'm happy to revert any changes if they are wrong. 13:34
Whiteknight what does try_reuse do?
bacek I scraped whole branch for this reason.
Whiteknight: try reuse pmc when C<dest> preovided 13:35
provided
Whiteknight ah, okay
Infinoid ok, I have to go... good luck with it 13:36
bacek But not all C<dest>s are equal...
pmichaud in bacek's last paste 13:41
13:29 <bacek> $P99 = 'new_value'; $P0 = hash['key']; $P1 = $P0; $P0 = $P99; say $P1
$P1 will have the value of hash['key'] 13:42
$P0 will point to $P99
let me look a bit closer
first, note that one cannot say $P99 = 'new value' unless $P99 has already been given a PMC 13:43
so without knowing that, it can't be answered in general
13:43 ZuLuuuuuu left
barney Is gist.github.com/121411 sane? When using pcre.pir in Pipp, there is a different HLL-root, so symbols are not found. 13:45
13:59 nnunley joined 14:13 mj41 joined
Tene barney: the other option is to export the PCRE namespace to your hll root 14:15
barney I'm a bit confuse. There might be a messup with .HLL '_pipp' and .HLL 'Pipp' 14:28
NotFound barney: the HLL of pcre.pir is parrot, isn't it? 14:50
Ah, is an example of use. 14:51
14:52 Steve_H joined
barney NotFound: I think so. I'm not sure whether the current .HLL carries over, when a function is called 15:01
NotFound barney: I'm almos sure that the current HLL is the one of the current context, and that depend of the sub. 15:02
Of course, when using include instead of loading, all assumptions are wrong. 15:03
barney Yes, I also think, that's how it should work. The current HLL in runtime/parrot/library/pcre.pir:127 should be 'parrot', as there is no .HLL directive 15:08
15:09 particle joined
barney When runtime/parrot/library/pcrelib.pbc has been loaded, the symbol should always be fount 15:09
s/fount/found/
15:20 donaldh joined
Tene barnmake sure that you run load-bytecode from a sub in HLL 'parrot'. 15:54
oh, no barney
NotFound examples/library/pcre.pir 16:03
25:.include 'library/pcre.pir'
This is wrong
I think that adding a new convention for extensions of files intended to be .included may be helpful to calrify things. 16:07
dalek rrot: r39302 | NotFound++ | trunk/examples/library/pcre.pir:
[examples] don't .include libraries
 16:08
kudo: b9bfabc | pmichaud++ | src/ (8 files):
Fix postfix:<++> to be faster in general, and faster still for Ints.

In order to get this to work, we also:
  * Fixed ++/-- to auto-promote to Num/BigInt as needed
  * Changed !DEREF to check isa using a class object instead of a Key
  * Refactored all of the autoincrement/decrement operators
  * Fixed infix:<does> to now work on Integer/Float/String PMCs
  * Cleaned up .succ and .pred in Bool
  * Rewrote the .succ and .pred rules for Str in PIR (was C),
   made it extensible to unicode ranges, and removed no-longer-the-right-place
   increment/decrement vtable in Perl6Str
  * Removed the not-quite-working Range.clone method -- we can inherit
   from Object anyway.		 16:12
16:13 PacoLinux joined 16:15 jhorwitz joined 16:26 iblechbot joined 16:28 Steve_H left
jonathan lol segfault 16:45
in 6 lines of PIR
NotFound jonathan: no record ;) 16:52
szbalint is that the new golf? :)
pmichaud lol
Parrot segfault golf
NotFound We crashed it for you. 16:53
dalek TT #729 created by jonathan++: Segfault on printing a String PMC assigned a null string 16:55
NotFound Uh. Don't we fixed that some time ago? 16:56
jonathan NotFound: I've fixed similar-ish bugs before.
NotFound: Having NULL pointers around for strings gets us into all kinds of trouble. 16:57
I've make test'ing a Parrot patch that re-orders some code that actually was not the source of my segfault (that ticket was) but that looked like it had potential to get us screwed too. 16:58
Actually I ended up doing something like the code that made the segfault because I had a stupid bug somewhere else. 16:59
So I'm not blocking on it, but of course fixing segfaults is good. :-)
NotFound I'll take a look at it. 17:00
jonathan NotFound++ 17:03
NotFound Ah, good, at least ASSERT_ARGS is doing his job
17:04 Whiteknight joined
dalek rrot: r39303 | jonathan++ | trunk/src/oo.c:
[core] cloned_guts is a struct, and was referencing a PMC that it appears nowhere else was. This means the PMC was unanchored from the stack (since we walk the stack looking for stuff in the PMC pool). I re-ordered the code to attach the struct to the PMC earlier, so that this shouldn't happen. (I haven't seen it happen, but it could...ran across this while trcking down an unrelated segfault).
 17:04
17:05 darbelo joined
Whiteknight hello darbelo 17:11
17:13 Whiteknight joined
NotFound "Sets the value of the string to a copy of the specified C<string>" Setting the value to NULL makes no sense, isn't it? 17:16
Anyway, that's not what the function is really doing. 17:19
jonathan NotFound: I'm not sure, I just know it shouldn't segfault. ;-)
NotFound jonathan: yeah, but not having that things cristal clear is the long term cause of segfaults. 17:20
darbelo hi Whiteknight
NotFound Well, I'll make it set NULL, but leave the ticket open asking for clarification. 17:21
Whiteknight how's the project going?
jonathan NotFound: Note that the segfault is on printing it rather than setting. But completely agree on asking for clarification. 17:22
darbelo It's moving. Writing a blog entry now the power's back to normal. 17:23
NotFound jonathan: here the segfault is a confess from ASSERT_ARGS fail
Which is correct. 17:24
#4 0xb7bea1de in Parrot_str_set (interp=0x804f040, dest=0x80f7830, src=0x0) 17:25
at src/string/api.c:211
src/string/api.c:211: failed assertion 'src' 17:27
jonathan NotFound: OK, I fear the assertion wsn't enforced here or something like that. 17:30
NotFound Let's fix one problem each time 17:31
jonathan I'm not convinced an assertion failure is much better than a segfault though. 17:32
NotFound jonathan: I am
Unless the assertion in a particular case is a bug itself, of course ;) 17:33
jonathan The point is that _either_ is an abnormal termination of the VM. 17:34
NotFound The main problem IMO is that compilers and tools are not helping us catch violations of nonnullness attributes. 17:35
jonathan Plus an ASSERT_ARGS fail means "something passed me something my declaration says I must not be passed".
(namely, a NULL.)
NotFound jonathan: yes, and we need that, or better we drop the nonnullness thing because it does more bad than good 17:36
If the compiler does not catch it, but the optimizer uses it, we're doomed. 17:37
jonathan *nod*
NotFound ASSERT_ARGS is the less evil solution to that problem.
jonathan So far as I can tell, it's mostly being used by compilers as an optimization hint, not a safety mechanism.
NotFound jonathan: yes, and the optimization hint happiliy drop all attempts of catching nullness at runtime. 17:38
jonathan yup. :-(
NotFound Because he trust us, and we tell him that is never null. 17:39
pmichaud it's not a check, it's a declaration.
(at least, that's what it sounds like to me) 17:40
NotFound "We declare that this arg will never be null. Then you can optimize to nothing all compariasons with NULL"
That's it.
And that caused a lot of hard-to-catch bugs in the past. 17:41
jonathan To me it feels well intentioned, but as much harm as help.
dalek kudo: 711bd6d | jnthn++ | (14 files):
Large refactor of method dispatch, providing deferal, eliminating some levels of indirection in method dispatch and improving performance. Also starts a refactor of roles since various past tricks will no longer fly and we should fiddle less with Parrot's Role PMC, though much remains to be cleared up there so roles are a little messy for now.
kudo: ff312ab | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
kudo: 03e90ad | jnthn++ | src/ (4 files):
Track down a couple of issues relating to enums and role punning, which were causing test fails, plus track down a bug with .perl on roles.
kudo: 2044332 | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
NotFound ASSERT_ARGS was introduced as a helper against this problems.
pmichaud oooh, I can't wait to try out the new refactor. 17:42
pmichaud fires up his benchmarking machine.
NotFound But it does not help in non-debug builds.
What we need is a compiler/lint/whatever that tell us: "attempting to pass a maybe NULL as a non-null argument" 17:43
18:06 leovle joined 18:21 rakudohudson joined 18:27 mctremel joined
dalek rrot: r39304 | NotFound++ | trunk/lib/Parrot/Pmc2c/Attribute.pm:
[cage] drop ; at end of "do .... while (0)"
 18:31
18:37 leovle left
dalek rrot: r39305 | NotFound++ | trunk/src/pmc/string.pmc:
[pmc] fix String.assign_string_native with NULL value, TT #729
 19:11
rrot: r39306 | pmichaud++ | branches/isafast:
New branch to refactor/optimize VTABLE_isa_pmc.
 19:21
19:22 donaldh joined 19:25 Steve_H joined
cotto NotFound, did you look at any other PMCs for similar bugs to the one you fixed in 39505? 19:31
Tene I wrote a little http app in ruby, using the HTTP::Daemon ad Tags libraries from Perl 6. :)
dalek website: darbelo++ | decnum-dynpmcs: week #01 19:32
website: www.parrot.org/content/decnum-dynpmcs-week-01
NotFound cotto: looks specific for String 19:43
Tene: Have you tried recently examples/nci/xlibtest.rb ? 19:44
dalek kudo: a0d09b3 | masak++ | src/classes/List.pir:
[src/classes/List.pir] C<> clarification
 20:06
20:22 particle joined 20:49 szabgab joined 21:00 Theory joined
dalek rrot: r39307 | pmichaud++ | branches/isafast/src/oo.c:
[core]: Refactor pmcproxy creation. Improves speed of <isa $P0, Proxy?>
 21:11
muixirt doesn't the parrot -O option work anymore? 21:20
dalek kudo: 6ed6997 | jnthn++ | (3 files):
Rename Role.pir to P6role.pir now it's adding methods to Rakudo's subclass of Parrot's Role PMC.
 21:32
darbelo cotto: ping 21:34
21:35 snarkyboojum joined 21:36 Whiteknight joined
cotto darbelo, pong 21:36
what happen
purl /kick cotto enough with the aybabtu already
darbelo I was looing at the pmc-related changes in the last few day and r39268 caugh my eye. 21:37
it look similar to what I'm doing in code.google.com/p/decnum-dynpmcs/so...cnum.pmc#5 but it looks like I missed the readonly PMC case. 21:38
cotto Once it stabilizes, you can just use the code bacek++ wrote.
istr that it's marked PARROT_EXPORT 21:39
and since the only way to get it stable is to use it... 21:40
darbelo I don't think it's exported. 21:41
cotto it is
see r39269
darbelo Ah. I hadn't seen that one yet. Thanks. 21:43
cotto It's good to avoid duplicating that kind of code, since all the fiddly special cases are easy to miss. 21:45
darbelo Yup. I'll kill new_if_not_a_decnum and use that. It generalizes what I was doing, so there's no point in keeping my version arround. 21:47
AND I get to dump blame on other people if it breaks :) 21:48
cotto yay!
how often are you updating Parrot? 21:49
darbelo daily-ish, but I don't always read the changes before updating.
And I spent the whole weekend with electricity issues, so I have some catching up to do. 21:50
dalek rrot: r39308 | pmichaud++ | trunk/src/oo.c:
[core]: Merge isafast branch back into trunk.
 21:51
darbelo Apparently someone decided 220 volts was way too much, and that we should just make do with 160 volts or so. 21:52
mugwump Electricity? Pfft, a luxury 21:53
cotto still enough to kill you, but not enough to be useful
sounds like a plan
mugwump www.nzherald.co.nz/nz/news/article....d=10575858 # customers were told they [...] would have to make do without power
21:54 bacek joined
darbelo mugwump: At least thy got *told* something. 21:56
cotto "buy more blankets and sweaters"
mugwump probably when they complained :)
darbelo Oh I complained, to an answering machine. A very polite answering machine at that, too. But not a very helpful one. 21:58
Hmm. Parrot_pmc_try_reuse only handles three-argument operations. 22:11
muixirt problems with the parrot -O option: sial.org/pbot/36964 22:12
dalek kudo: f43c644 | jnthn++ | src/parrot/P6role.pir:
Sometimes, git doesn't do what you want. Add p6role.pir, which it lost in the rename but didn't show as not under version control when I did git status. How awesome.
 22:13
muixirt anyone with some insights on that?
darbelo Nevermind, value is ARGIN_NULLOK.
Coke so can we back out the commit that caused TT#728? 22:21
22:22 contingencyplan joined 22:32 rg1 joined
dalek cnum-dynpmcs: r72 | darbelo++ | trunk/src/pmc/decnum.pmc:
Replace new_if_not_a_decnum with the new Parrot_pmc_try_reuse.
 22:33
pmichaud (back out commit)++ 22:36
dalek kudo: def4e6d | jnthn++ | src/ (7 files):
Do a little optimization to the deref_objectref dynop, and then eliminate the !DEREF PIR sub in favor of it. Wins a modest but worthwhile performance improvement.
mugwump is rakudo/src/parrot supposed to contain files? 22:40
jonathan yes
mugwump ah, rakudo/parrot is where parrot checkout lives
Coke pmichaud: working on reverting 39273 now. 22:41
pmichaud rakudo/src/parrot is where we store the "we're mucking about in the parrot namespace" stuff. 22:42
I'd be open to changing the dirname, though. It makes it harder for me to tab-complete src/parser/
although I've been thinking about moving src/parser to src/pct, since more than just a parser lives there.
nopaste "chromatic" at 72.90.115.31 pasted "Rakudo P6 MultiSub Building Patch for pmichaud" (58 lines) at nopaste.snit.ch/16765 22:45
dalek rrot: r39309 | coke++ | trunk/src/pmc/scalar.pmc:
TT #728 - revert r39273 until someone determines the proper implementation.
 22:48
22:49 kid51 joined
dalek kudo: 9421bca | pmichaud++ | src/pmc/perl6multisub.pmc:
Add semicolons after GETATTR/SETATTR (chromatic++).
 22:53
rtcl: r411 | coke++ | trunk/runtime/tcllib.pir:
Move the shiny new HLL compiler out of the user-visible namespace for now.
 22:54
bacek good morning
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
NotFound Ha
mugwump purl: parrot viewvc? 22:55
purl i haven't a clue, mugwump
bacek Coke: I've reverted r39273 locally already. Waiting for make test to finish before commit
22:55 particle joined
NotFound Now I underestand why no one complained about the unneeded semicolon in the GET/SET ATTR macros X-) 22:55
pmichaud bacek: it's already reverted in r39309
bacek ah... ok 22:56
22:56 skids joined
bacek launching git rebase -i 22:56
22:57 payload joined
Coke bacek: sorry, already did it, as pmichaud noted 22:58
bacek Now we have to remove all pmc_reuse. What about Scalar.subtract(Complex, PMC*dest)?
mugwump purl: parrot viewsvn? 22:59
purl mugwump: no idea
bacek actually many math VTABLEs try to reuse dest... 23:01
especially in BigInt and BigNum. 23:03
cotto mugwump, looking for trac.parrot.org/parrot/browser ?
mugwump yes, actually :) 23:04
cotto Well, there it is.
mugwump thanks
dalek rrot: r39310 | NotFound++ | trunk/t/pmc/string.t:
[test] test for fix on TT #729
23:05 tetragon joined
dalek TT #480 closed by jkeenan++: [PATCH] Display assembly filenames when compiling, like C filenames are 23:10
rrot: r39311 | bacek++ | trunk/src/pmc.c:
[core][cage] Call pmc_reuse from Parrot_pmc_try_reuse even if types are same.
 23:11
23:12 ruoso joined
dalek rrot: r39312 | bacek++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c] Don't use return with expression in void functions. ISO C forbids it. doughera++
 23:14
Coke I am not a fan of closing tickets just because they've been open for 2 months. 23:15
msg kid51 I am not a fan of closing tickets just because they've been open for 2 months. 23:16
purl Message for kid51 stored.
dalek TT #730 created by pmichaud++: [bug] IMCC chokes on unicode strings as method call names 23:17
Coke to verify, we don't currently have a way to see if a file in the OS is executable, correct? 23:19
23:20 donaldh joined
pmichaud try running it, if it failz, it's not executable :-) 23:20
NotFound Coke: A portable way? I don't even think that such a thing exists.
pmichaud: incorrect. It can be executable, but maybe you don't have permissions to execute it ;-) 23:21
Coke NotFound: parrot MAKES it portable, even if we have to do it 30 different ways on 30 different OSes. 23:22
perl5 can do it, I think we can too. =)
NotFound Coke: or we can just use our own definition of 'executable' 23:23
Coke NotFound: sure, as long it's right.
NotFound We can redefine 'right' as well
Coke NotFound: I'm sorry, I'm afraid I don't understand. 23:24
In any case, I opened a ticket, pointing back to the tcl spec for why I need it. 23:25
nopaste "bacek" at 114.73.180.229 pasted "pmc. reuse or not reuse? there is question." (18 lines) at nopaste.snit.ch/16766
bacek what is expected output for nopasted code?
NotFound Sorry, I mean: we can also redefine 'right'
bacek #define RIGHT LEFT /* Happy debugging! */ 23:26
Coke NotFound: ... not really, no.
bacek pmichaud: can you check nopaste.snit.ch/16766 please? 23:27
dalek TT #731 created by coke++: can't tell if an OS file is executable from parrot
pmichaud bacek: I think output should be 23:29
42
402
42
bacek why "add" differ from "concat"?
pmichaud it doesn't. 23:30
bacek feel inconsistency...
pmichaud although the output I thought I'd get isn't what I'm getting in current Parrot. I don't know if that means Parrot changed recently, checking.
bacek If I replace "$P2 = $P0 + $P1" with "$P2 = add $P0, $P1" it produces same results. 23:31
I don't understand why "add" and "concat" doesn't differ in treating destination pmc... 23:32
pmichaud the difference is where you're setting $P99
Tene NotFound: haven't looked at xlibtest in ages. 23:33
NotFound: cardinal is in pretty bad shape.
pmichaud bacek: first two lines, $P0 references an Integer with value 40
NotFound afk_coke: "Returns 1 if file name is executable by the current user, 0 otherwise" --> I suppose this means a check of file permissions, not executable format or something
pmichaud next two lines, $P1 references an Integer with value 2
next line, $P2 references an Integer with value 0 23:34
dalek kudo: b91e089 | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to get latest isa fixes and other stuff.
pmichaud next line, $P99 references the same Integer as $P2
23:34 mikehh joined
pmichaud okay so far? At this point we have three Integers 23:34
$P2 = $P0 + $P1 is the same thing as add $P2, $P0, $P1
bacek no. parrot -t1 calls "set P3, P2" for both "$P99 = $P2"
pmichaud that creates a new Integer, stores the result of $P0 + $P1 (42) into it, and sets $P2 to point to the new Integer 23:35
at this point there are *four* Integers 40 ($P0), 2 ($P1), 0 ($P99), and 42 ($P2)
oh, I see, I miswrote earlier 23:36
I transposed the $P2=$P99 in my head
output should be 23:37
42
0
402
42
bacek Ok. So "dest" in all VTABLEs is redundant and should not be there. 23:38
pmichaud I don't know about "all" VTABLES
depends on what happens with add $P2, $P1 23:39
NotFound Don't know if all, but I have thinked that about several of them lots of times.
bacek There is no "dest" in "add $P2, $P1" 23:40
23:41 Zak joined
pmichaud well, the result goes into $P2 in that case. 23:43
NotFound Or maybe the return value is the redundant one.
pmichaud Anyway, it wouldn't surprise me if dest is no longer used. 23:44
it used to be that add $P2, $P0, $P1 meant "add $P0 to $P1 and store the result in the PMC given by $P2"
which was often a pain if $P2 was something other than an Integer
NotFound add(invar PMC, invar PMC, invar PMC) :base_core { $1 = VTABLE_add(interp, $2, $3, $1);
pmichaud what about add(inout PMC, invar PMC) ? 23:45
bacek Now it means "and ignore $P2, create new PMC and return it. op will do the rest"
anyway, $dayjob time. 23:46
NotFound pmichaud: I don't see such op
pmichaud sorry, it's
inline op add(invar PMC, invar PMC) :base_core { VTABLE_i_add(interp, $1, $2);
}
NotFound add(invar PMC, invar PMC) :base_core {
bacek afk &
NotFound Dropping the return value looks like a clean way to me. 23:48
bacek And reuse "dest'?
pmichaud huh?
purl huh are you 2 on the same box or something?
pmichaud "drop the return value"? 23:49
NotFound Mmmm.... no, that way a null pmc can't be used
pmichaud which vtable are we referring to at the moment?
NotFound Drop from the code, not the result.
pmichaud or give me a more precise picture of whatyou're thinking of changing 23:50
NotFound Forget it, was a bad idea.
purl NotFound, I didn't have anything matching it, was a bad idea
pmichaud okay.
23:50 patspam joined
pmichaud As an example 23:50
in
inline op add(invar PMC, invar PMC, invar PMC) :base_core { $1 = VTABLE_add(interp, $2, $3, $1);
}
the $1 parameter to VTABLE_add is completely unused (by the core PMCs) 23:51
i.e., it doesn't provide anything to the calculation, nor are its contents changed.
NotFound The intended semantic is to assign to $1 or to set $1 ? 23:52
pmichaud to set $1
i.e., the return value.
NotFound Then we can drop dest
pmichaud assigning to $1 is the old semantic, which was dropped last year sometime
(with some difficulty, so please let's not change it back :-)
NotFound Then we must get rit of the dest parameter in the vtable function. 23:53
pmichaud that may want a deprecation cycle, if there are any custom PMCs using the old interface.
NotFound Agreed
darbelo that would mean that every that now has a dest will have to pmc_new() a destination and return it. Right? 23:54
pmichaud darbelo: I think that's what is happening now, yes.
for the non-inplace operations.
darbelo pmichaud: most of the arithmetic VTABLEs reuse the destination. 23:55
pmichaud they re-use the dest pointer, but not the PMC that it was referring to.
at least, not in Integer
dest = pmc_new(INTERP, VTABLE_type(interp, SELF));
that doesn't mean "change the PMC that dest was pointing to"
it actually causes dest to refer to a new PMC
but that has no effect on the $1 that was in the caller.
darbelo BigInt uses pmc_reuse()
NotFound We can stop doing that as the first step towards the deprecation. 23:56
pmichaud we can't stop doing that, no.
(depending on what "that" is in this case)
I admit I haven't looked to see what BigInt does. However, it's very likely that the existing BigInt was never updated to the new semantic, since it wasn't being used or tested anywhere.
NotFound Reusing the dest pointer, use a local variable instead. 23:57
pmichaud I would just change the parameter to be *unused and use *dest as the local variable :-)
NotFound Just to clarify the intention in the code.
23:57 zak_ joined
NotFound Yes, less work 23:57
pmichaud or *result
but *dest works.
or the parameter could be *deprecated :-)
NotFound Letting the code in a state where the end of deprecation cycle is deleting the parameter in the declaration. 23:58
pmichaud Correct.
That sounds nice.
NotFound A better english grammar will be even nicer ;) 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!