Parrot 2.1.1 Released! | parrot.org/ | Tasks: PCC deprecations branch, HLL subclassing and MMD branch
Set by moderator on 19 February 2010.
dalek kudo/master: 6884da0 | jonathan++ | src/core/ (2 files):
Bring loads of methods for EnumMap (previously Mapping) and Hash back. Rewrite those that used to be in PIR into Perl 6. Some that don't do mutations but were only in Hash are now in both; I see no good reason for them not to also be in EnumMap.
00:01
kudo/master: 7452234 | jonathan++ | t/spectest.data:
We pass S03-smartmatch/scalar-hash.t again.
kudo/master: 3b44842 | jonathan++ | (3 files):
Move Regex.ACCEPTS to core.
bacek_at_work darbelo, pong
darbelo It looks like the build infrastructure in your PIR compiler has bitrotted, do you have any pointer towards salvaging it? 00:04
cotto_work If you figure that out, it may be easier to get ops_pct working again against head. 00:07
darbelo cotto_work: It's not the *code* that I'm trying to salvage (right now). It's the build procedure that's hosed. 00:09
cotto_work oh
darbelo The makefile references tools that have been removed from the repo.
dalek rrot: r44423 | mikehh++ | trunk/t/oo/new-old.t:
fix perlcritic failure - fix perl coda
00:11
darbelo Maybe I should just not bother with necromacy and try to make it work with distutils...
dalek nxed: r427 | julian.notfound++ | trunk/examples/pirado.winxed:
improve pirado, with some temporary tricks, making it able to work with some two
00:13
bacek_at_work darbelo, not yet. 00:14
kid51 mikehh: Any words of wisdom about the perlcritic errors? 00:15
mikehh kid51: just going through them now - fixing the easy ones first :-} 00:16
kid51: I am not sure about things like TODO violations 00:17
00:17 patspam joined
mikehh kid51: should we be testing ext/Parrot-Embed/t/pipp.t 00:19
kid51 I'm amazed we're down to 27 failures.
IIRC, files in ext/ are outside our scope. But I'm not very familiar with ext/ myself. 00:20
mikehh there are some multiple failures in some of the files
kid51 mikehh: I will take care of: t/steps/auto/snprintf-01.t and t/tools/ops2pm/08-sort_ops.t 00:22
dalek m-dynpmcs: dc1a7c1 | darbelo++ | t/gdbmash.t:
Make temp file deletion smarter to cover the fact that the OS pmc is dumb.
00:24
m-dynpmcs: 4fbd6be | darbelo++ | t/gdbm (2 files):
Undo typo in filename.
m-dynpmcs: 3b748cf | darbelo++ | t/gdbmhash.t:
Give each test it's own db file.
m-dynpmcs: 04ff353 | darbelo++ | LICENSE:
Add LICENSE file.
rrot: r44424 | mikehh++ | trunk/t/op/exit.t:
fix perlcritic failure - fix perl coda
00:28
rrot: r44425 | jkeenan++ | trunk/t/steps/auto/snprintf-01.t:
[codingstd] Cut out some comments that contained the deadly 'TODO' string, which was triggering perl-hyper-critic.
mj41 mikehh: TapTinder test each commit to trunk on many clients. Is it possible to put more files with codingstyle fixes to one commit? 00:43
dalek rrot: r44426 | jkeenan++ | trunk/t/tools/ops2pm/08-sort_ops.t:
[codingstd] Delete inline comments that contained TODO; tests that had been TODO-ed are now passing.
00:44
rrot: r44427 | mikehh++ | trunk/t/op/sysinfo.t:
fix perlcritic failure - fix perl coda and TODO -> todo
rrot: r44428 | mikehh++ | trunk/t/tools/ops2pm/05-renum_op_map_file.t:
fix perlcritic failure - missing perl coda
rrot: r44429 | mikehh++ | trunk/ext/Parrot-Embed/t/pipp.t:
fix perlcritic failure - missing perl coda, but still 2 TODOs in the file
mj41 Time to sleep, dobrou noc. 00:46
mikehh mj41: at the moment I am doing some tests after each commit, and I also like to avoid too much change at once in case there is a problem
I should say before each commit 00:47
dalek kudo/master: 90b5153 | jonathan++ | src/ (3 files):
Minor optimization to BUILDALL and .can. Takes 10s or so off the spectest run for me.
00:48
kudo/master: a7874a7 | jonathan++ | src/builtins/ (2 files):
Rip out the .fixup_cloned_sub macro - we don't need it any more. Should make .clone a tiny, tiny bit cheaper by saving a (useless) check.
00:51 integral joined
darbelo purl: msg bacek I forked your PIR compiler at github.com/darbelo/pir and started adding a new build procedure. It kind of builds, but needs more necromancers before it works properly. 00:54
purl Message for bacek stored.
dukeleto darbelo: cool! we need more development on PIR compilers 01:00
dalek rrot: r44430 | mikehh++ | trunk/compilers/ncigen/t/NCIGENAST (2 files):
fix perlcritic failure - add use strict/use warnings
01:02 abqar joined
dalek rrot: r44431 | mikehh++ | trunk/compilers/ncigen/t (3 files):
fix perlcritic failure - add use strict/use warnings
01:17
Coke msg chromatic - thanks for fixing that very old MMD bug. 01:20
purl Message for chromatic stored.
cotto_work Would it be possible to use lexicals to make todo in PIR's Test::More saner? 01:25
cotto_work heads home 01:27
purl Slacker!
dalek rrot: r44432 | mikehh++ | trunk/compilers/ncigen/t/parse_00.t:
remove dubious construct in test
01:33
01:42 kid51 joined
mikehh kid51: down to 12 files now 01:48
dalek rrot: r44433 | mikehh++ | trunk/compilers/pirc/t (5 files):
fix perlcritic failure - add use strict/use warnings
01:50
rrot: r44434 | plobsing++ | trunk (2 files):
remove last references to Parrot_call_sub() and Parrot_call_sub_ret_int() that have already been removed
mikehh kid51: if you want to look at the rest, I've had enough for the moment - it is 2am for me 01:59
dalek TT #1145 closed by plobsing++: extend/embed API functions for calling subs/methods
kid51 mucho gracias, miguelito
mikehh anyway make test passes, will try fulltest in a few hours 02:00
dalek rrot: r44435 | jkeenan++ | trunk/examples/languages/abc/t/01-tests.t:
[codingstd] No 2-argument-form for 'open'.
02:06
rrot: r44436 | jkeenan++ | trunk/t/examples/pod.t:
[codingstd] quiet critic re TODO in comment.
02:07
TT #1476 created by jkeenan++: t/compilers/pct/past.t: Complete desired tests 02:16
rrot-data-structures: 54e716d | Whiteknight++ | (4 files):
add some stuff I should have added last commit
02:19
rrot: r44437 | jkeenan++ | trunk/ext/Parrot-Embed/t/pipp.t:
[codingstd] TODO -> todo to shut up the perl-hyper-critic.
02:23
rrot: r44438 | jkeenan++ | trunk/t/compilers/pct/past.t:
[codingstd] Convert TODO request for more tests to TT #1476.
plobsing embedding question: is it possible to call into parrot with a variable signature/number of arguments for a single call site? 02:25
All I'm seeing is Parrot_ext_call which uses varargs (which suck IMHO)
dukeleto plobsing: i don't know if what you want exists 02:28
02:34 nbrown_ joined
dukeleto plobsing: why do varargs not work for you? 02:36
plobsing can't be built at runtime
Personally, I would prefer an array. 02:37
nice, simple, works anywhere, for anyone.
I could live with using an aggregate PMC too. 02:39
dalek TT #1477 created by plobsing++: [embed] expose non-vararg-based sub/method call-ins 02:49
rrot: r44439 | jkeenan++ | trunk/t/compilers/imcc/imcpasm/optc.t:
perlcritic.t objected to prototypes in Perl 5 subroutines. Modify subroutine used to generate permutations to not use prototypes.
02:56
rrot: r44440 | jkeenan++ | trunk/t/native_pbc/integer.t:
perlcritic.t objected to prototypes in Perl 5 subroutines. Modify subroutine to not use prototypes.
rrot: r44441 | jkeenan++ | trunk/t/native_pbc/number.t:
perlcritic.t objected to prototypes in Perl 5 subroutines. Modify subroutine to not use prototypes.
03:12
rrot: r44442 | jkeenan++ | trunk/t/native_pbc/string.t:
perlcritic.t objected to prototypes in Perl 5 subroutines. Modify subroutine to not use prototypes.
rrot: r44443 | jkeenan++ | trunk/t/op/calling.t:
[codingstd] perlcritic complained about variable declaration in conditional statement. Fixed.
rrot: r44444 | jkeenan++ | trunk/t/op/calling.t:
Correct spelling error.
rrot: r44445 | jkeenan++ | trunk/t/pmc/exporter.t:
Delete string 'TODO' in comment; already superseded by a Trac ticket number.
TT #1478 created by jkeenan++: t/pmc/iterator.t: split test 03:23
kid51 Two more commits to be reported, but all perlcritic.t complaints have been addressed. 03:25
kid51 goes for beer.
dalek rrot: r44446 | jkeenan++ | trunk/t/pmc/iterator.t:
[codingstd] Replace 'XXX' in comment with TT #1478.
03:29
rrot: r44447 | jkeenan++ | trunk/t/pmc/sub.t:
[codingstd] perlcritic complained about variable declaration in conditional statement. Fixed.
kudo/master: 4f74e3b | (Solomon Foster)++ | src/core/Rat.pm:
Make Rat.Num return +/- Inf if the denominator is 0.
03:30
kid51 r44447: make codetest PASS 03:35
Coke kid51++ 03:49
mikehh++
kid51 must sleep 03:50
purl $kid51->sleep(8 * 3600);
04:09 cognominal joined
Coke enjoys his upgraded netflix subscription. 04:11
04:19 janus joined
Coke $ svn up 04:21
svn: Can't find a temporary directory: Internal error
sounds like a server bug. 04:22
I opened a ticket with osuosl. 04:25
damnit. I had a big commit for the warnings stuff. =-)
Coke hurls feather.perl6.nl/~coke/warnings.pm in case anyone wants to review it. 04:45
compare to config/auto/warnings.pm on rm_cflags branch. 04:46
04:53 TiMBuS joined 04:57 dalek joined
dalek nie: r113 | allisonrandal++ | trunk/Grammar/Actions.nqp:
Modify AST generation to delete keyed items as well as entire
05:17
Coke svn restored. 06:27
dalek rrot: r44448 | coke++ | branches/rm_cflags/config/auto/warnings.pm:
Allow specification of warnings for skipping or adding per-file

generate ccwarn?filename.c, also. Improve the docs. Rename try_warning to valid_warning & memoize it. Fix bugs in spec of 'warnings' data. Remove a redundant spec in --cage that was already in the basic warnings. Do not generate config information for each individual warning, eliminate
   now-unused function in the process.
Inline _set_ccwarn
06:38
rrot: r44449 | coke++ | branches/rm_cflags/config/auto/warnings.pm:
Construct the warnings data structure in smaller pieces.
nie: r114 | allisonrandal++ | trunk/Lib/test/bootstrap/dicts.py:
Test element deletion by element count, rather than the 'in' keyword,
06:53
parrot: 23de4a5 | (Joshua Tolley)++ | src/plparrot.c:
Initialize the interpreter only once. This fixes the crashes I've been having all the time.

src/handler, doesn't fix the problem where make installs everything into the wrong place. PostgreSQL still looks for plparrot.so in $libdir, but the installer puts it in $libdir/src. This hasn't been failing immediately in my case, because there's an old plparrot.so already there. That makes debugging
  ... less simple. :) But that's also a fix for another night.
06:56
07:00 chromatic joined
Coke chromatic: hio 07:03
07:06 fperrad joined 07:07 cotto joined
Coke do folks have any thoughts on taking everything in parrot config and making it available as a variable in an included makefile? 07:09
(all prefixed with something to avoid conflicts with env vars.) 07:10
07:10 he_ joined
dalek rrot: r44450 | coke++ | branches/rm_cflags (3 files):
- Change optional @@ syntax from URL-like ? to a more parrotish ::

  - Split out cc_warn from cc_flags in the makefile
07:11
Coke hurm. nevermind, that would be helpful but not for the problem I'm working on right now. 07:14
darbelo: rm_cflags should probably build now with sun cc as long as you don't --optimize. 07:25
dalek rrot: r44451 | coke++ | branches/rm_cflags (3 files):
Don't run with "unused" by default. (it wasn't in trunk).

Don't bother overriding unused if we're not using it. imclexer's overrides are not (at the moment) respected, doc it.
07:27
parrot: fa1081e | (David Fetter)++ | Makefile:
Removed awful hack. 9.0's pg_regress now uses the new CREATE OR
07:31
07:55 bacek joined
bacek o hai 07:56
darbelo, ping
08:03 iblechbot joined
Coke darbelo: bah, I lied. more fixes necessary. 08:09
dalek rrot: r44452 | coke++ | failed to fetch changeset:
merge latest changes from trunk
08:18
nopaste "mj41" at 147.229.5.176 pasted "NotFound: pbc_disassemble.exe hanging" (45 lines) at nopaste.snit.ch/19753 08:43
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32368), fulltest) at r44452 - Ubuntu 9.10 amd64 (gcc with --optimize) 09:22
09:27 chromatic joined 09:51 bacek joined
dalek rrot: r44453 | fperrad++ | trunk (2 files):
[gdbmhash] add methods open/close.
09:57
10:06 AndyA joined 10:18 lucian joined
Austin kthakore: It didn't go. Both of the perl modules failed to build, leaving me with no way to verify/diagnose my sdl installation. 10:25
10:52 payload joined 10:58 mikehh joined
Austin msg Tene Here's one that's particularly bothersome at the moment. If a calls b calls c, and c throws an exception which is caught by a, then a rethrows the exception, the backtrace printed should mention c as the origin, not a. 11:08
purl Message for tene stored.
11:46 plobsing joined 11:51 lucian joined 12:00 bkuhn joined 12:07 payload joined 12:11 payload1 joined
kthakore Austin: what os are you on? 12:27
Austin andlinux
purl i heard andlinux was a full solution, and it saves you a lot of pain or at www.andlinux.org/
kthakore Austin: what errors have you been getting for ALien::SDL? 12:28
Austin It's basically ubuntu running under windows
nopaste "Austin" at 68.37.46.53 pasted "AlienSDL errors" (10 lines) at nopaste.snit.ch/19756 12:30
kthakore ah you seem to have an older version of File::PAth? 12:31
Austin For some value of older? I'm running perl 5.10
kthakore Austin: I dunno how
maybe cpan File::Path ? 12:32
Austin: I have to head to work
talk to you in a bit
Austin l8r
12:35 mikehh joined 12:39 cosimo joined
Austin msg kthakore I googled a bit and did an install of sdl-dev+debian, which apparently installs the kitchen sink, too. At this point, the parrotSDL test run fails on the very first test with an error about SDL_ttf not initialized. 12:41
purl Message for kthakore stored.
12:43 cosimo joined 12:51 whiteknight joined 12:52 mikehh joined
whiteknight good morning #parrot 12:59
dalek kudo/master: 59c65be | moritz++ | t/spectest.data:
re-enable S03-junctions/associative.t
13:12
Austin Good morning, whiteknight 13:14
I have a somewhat novel idea for you, after you've had that first cup of coffee 13:15
13:15 [hudnix] joined
whiteknight I don't drink coffee. I'm receptive to novel ideas starting at 5 AM 13:17
Austin Okay.
Pretend for a minute that we get to wave our magic fairy wands and solve a bunch of coding problems - this isn't about cost.
Let's say we have a string.
We can assign a number to that string using a global string enumerator. 13:18
It will be dense: 1, 2, 3, ...
Given that mechanism, we can assign a number to every method name.
You with me so far? 13:19
'new' = 1, 'isa_tty' = 2, etc. 13:20
Right now, the vm deals with opcodes.
An opcode that runs on a pmc (as opposed to one like 'getinterp') is a lookup of an entry in that pmc's vtable. 13:21
If we can enumerate all method names, we can (pretend to) build a really big vtable for each object. 13:22
The opcodes become "call_method $object, #22" because the first #n vtable entries are reserved already.
(So our enumerator has to return #n + 1, 2, ...)
We start with a "blank" vtable that has however-many copies of a pointer to a function that does "lazily resolve vtable function or method name" for its invocant. 13:24
As objects exercise more and more ops/methods, they fill in their (shared or not) vtables, so it doesn't have to be a giant initial effort. 13:25
The payoff is, I think, that vtable and method calls use the same mechanism. 13:27
Calls to static methods - where the method name is a constant - can be num-ified at load time. Calls to variable -named methods (callmethod($obj, $meth_name, @args)) have to do a hash/enum, but then the dispatch problem is solved, since any already-dispatched method is cached in the vtable. 13:29
What do you think? 13:30
purl I think Austin should try flossing more often!
13:30 d4l3k_ joined
Austin heh 13:32
purl++
13:32 [hudnix] joined 13:33 mikehh_ joined 13:38 eirik joined, plobsing_ joined, dngor joined, Hunger joined, Coke joined, pmichaud joined, jsut joined, Ryan52 joined, tetragon joined, zostay_ joined, fperrad joined, szabgab joined 13:39 PacoLinux joined 13:40 japhb joined, payload joined, darbelo joined, hercynium joined
Austin Apparently my idea was so brilliant it knocked people of #irc. 13:41
How ya like me now!
kthakore Austin: not much 13:57
purl same here, dude
Austin :)
kthakore Austin: how do I check the message?
Austin say "messages" to purl
purl, messages 13:58
kthakore purl, messages
well that is not a good message :|
Austin Then you can say "messages erase" to clear them
kthakore ok
PerlJam Austin: did you figure out a way to make parrot uber-fast, uber-small, backwards compatible, and just generally awesome such that there's nothing left to do? 13:59
kthakore messages erase
purl, messages erase
purl kthakore: what?
kthakore purl, KILL THE MESSAGE
purl kthakore: sorry...
Austin messages?
purl To access purl's messages, msg me with the word "messages".
Austin purl, messages
kthakore Austin: ok done
Austin PerlJam: How about fast-er? 14:00
kthakore Austin: I might have to make config.pir
Austin kthakore: Why?
kthakore Austin: to get all the boiler plate generated
Austin Ah
kthakore for the SDL-dev locations and what not
Austin Is this really a location problem?
kthakore my idea is similar to what I am doing in perl5
Austin: yes
Austin: NCI needs the location absoulte and accesible 14:01
to load the C function hook
Austin That seems wrong.
PerlJam Austin: faster is always good :)
kthakore Austin: yesh!
Austin: shouldn't it look in PATH for the libraries
like any sane program? 14:02
Austin Depends on what libraries..
.so libraries, sure.
.pbc libraries, not so much
14:04 ruoso joined
kthakore Austin: well these SDL libs are .sop 14:08
.so
Austin: so why doesn't NCI look for them in PATH
Austin I don't know. Ask Whiteknight.
kthakore whiteknight: ping! 14:09
Austin (I don't know much about the innards.)
whiteknight ?
kthakore Austin: me neither
whiteknight: why doesn't NCI look for .so libs in PATH
whiteknight I have no idea. probably should
are you sure it doesnt?
kthakore whiteknight: why do I have to give it the name and absolute path
whiteknight: yeah pretty sure
whiteknight: see teh github.com/kthakore/parrotSDL/blob/...er/SDL.pir 14:11
whiteknight: I either give it an env var 14:12
or it looks only in /usr/lib
whiteknight: ignore rest of PATH
whiteknight well that's not right. File a ticket 14:14
kthakore whiteknight: yay! 14:15
trac?
purl well, trac is a web-based software project management and bug/issue tracking system emphasizing ease of use and low ceremony. It provides an interface to the Subversion revision control systems, integrated Wiki and convenient report facilities. projects.edgewall.com/trac/ or Python, SQLite and ClearSilver or killing killtrac or a bug-tracking tool or at trac.parrot.org/parrot/ or slow or REALLY slow
whiteknight It should use Parrot' normal file-loading mechanism, which uses PATH
kthakore whiteknight: I will check again but even Austin is having that problem with ttf
plobsing_ kthakore: are you sure you shouldn't be using LD_LIBRARY_PATH in stead? 14:18
kthakore plobsing_: but not all platforms use LD_LIBRARY_PATH 14:21
plobsing_: most do use PATH
plobsing_: I don't know what it uses but it should find the lib in /usr/local/lib 14:22
plobsing_ kthakore: I was under the impression the two uses were disjoint. PATH for programs, LD_LIBRARY_PATH for shared libs 14:23
Austin See nopaste - searching seems limited.
Is snit.ch down?
purl, ping nopaste.snit.ch
purl nopaste.snit.ch: 10 packets transmitted, 10 received, 0% packet loss, time 9013ms, rtt min/avg/max/mdev = 230.306/230.673/231.698/0.564 ms
nopaste "Austin" at 68.37.46.53 pasted "search paths" (33 lines) at nopaste.snit.ch/19757 14:24
Austin Works via browser, but the nopaste script can't talk to port 8001 14:25
kthakore plobsing_: whiteknight ^^ see that doesn't work for NCI
we need /usr/lib and /usr/local/lib 14:26
at the very least
plobsing_ kthakore: Parrot uses the system's dlopen function. This is a Good Thing.
it avoids reinventing the wheel
kthakore plobsing_: ok thats fine and everything
not faulting how it is done
but where it looks! 14:27
plobsing_ which your system provides a way of setting.
kthakore ok ... then how do I fix it to look at /usr/local 14:28
or other locations in PATH and LD_CONFIG_PATH
plobsing_ ... system dependant, but most unix-like operating systems use LD_LIBRARY_PATH 14:29
kthakore ok 14:36
...
14:36 bluescreen joined
Austin Woot! 14:49
kthakore: I modified SDL.pir to add some extra filenames to check - libSDL_ttf-2.0.so.0 seems to have done it 14:50
Now I'm at the stopwatch problem
kthakore ah ok
Austin: hooray
Austin Null PMC access in isa
kthakore yeah that is where I am stuck too
Austin I think you need to write a general purpose "try to load X with these suffixes" function. 14:51
kthakore plobsing_: isnt that another thing. why is libSDL_tff sufficent to get it try all links?
Austin: don't you mean NCI should handle that ;)
Austin: yes I think that is what you mean 14:52
Austin: good point sir!
kthakore tips his hat and twirls his mustache
Austin kthakore: NCI should definitely not handle this part.
kthakore crap
...
ssssssshhhhhhh
14:53 ruoso joined
Austin The "find a path" part is handled (correctly, it turns out) by the system. The .so, -2-0.so-0-0, _1.2.so.0 stuff seems to be at the whim of whoever built the library. 14:53
kthakore Austin: yeah that is problabwhat I cam going to have make SDL::Loader
Austin: make a perl script that generates a quick parrot hash? with all the right names of the libs 14:54
Austin: and have setup.pir run that
Austin Oh, and your problem is that $P0 is not initialized.
Austin slaps kthakore in the head! 14:55
You change from .local pmc class to $P0
s/$P0/class/ should do it
"Could not find non-existent sub store_global" 14:56
kthakore Austin: didn't write this man!
Austin: I am fixing it!
Austin Oh, sure. Blame the other guy.
kthakore goes cries in the corner
Austin: so where is this?
Austin StopWatch 14:57
kthakore ah ok
Austin Once you fix the $p0 -> class problem
kthakore man this chan is brutal!
Austin: ok
yes suh
right away suh
Austin I suspect store_global ought to be set_hll_global (opcode)
kthakore ok
Austin In fact, if you search for store_global, that __onload sub looks very confused. Double check all the registers - I think it doesn't work. 14:58
kthakore ok 15:00
Austin You get the $P0 thing fixed?
kthakore yeah 15:01
working on it suh
please don't hit me
Austin ;-
kthakore the opcode set_hll_global was not found 15:02
I am using it at line 255
as you said
15:03 he_ left
Austin Huh? 15:05
15:06 lucian joined 15:15 bubaflub joined
kthakore Austin: ok if I fix the class I get could not find non existant sub store_global 15:16
Austin Yeah.
kthakore Austin: so I made it the set_hll_global
Austin Try replacing that with set_hll_global [ 'SDL::NAmespace'], 'globalName', $P99
kthakore but it dies too
ok
Austin Pretty much same args order, I think. 15:17
kthakore ok
what is the find_global alternative?
Austin $P99 = get_hll_global ['SDL::Namespace'], 'variable' 15:19
kthakore ok 15:20
Austin Btw, it works for functions, too - $P0 = get_hll_global [ 'SDL' ], 'function' 15:21
kthakore Austin: yay!!! 15:24
it works
Austin Progress?
purl well, Progress is progress
kthakore yeah
Austin Woot!
kthakore++
kthakore putting it up now
Austin: now STOP HITTING ME in public
Austin: it is up 15:25
Austin Two days, 3 git repos, and I can't remember how many packages installed, all because you changed variable names in mid-routine?
kthakore come on #sdl
Austin: I DIDN"T DO IT 15:26
kthakore cries
15:27 iblechbot joined
nopaste "tene" at 76.27.121.193 pasted "whiteknight: example of auto-resume non-fatal exceptions. Rakudo uses this for warnings." (16 lines) at nopaste.snit.ch/19758 15:29
kthakore Austin: huh?
Austin: I was about to start demo work in #sdl 15:30
Austin: ok maybe later
whiteknight tene: okay, thanks. I wasn't sure if it worked or not
but I'm happy to see that it does
Austin kthakore: I'm glad it's working, but I've got my own crappy code to debug... :(
kthakore heheh
Austin: can I hit you now
kthakore slaps Austion 15:31
WHy is you crappy code not working!!
Austin Because I spent too much time working on that SDL stuff!
Tene whiteknight: Yes, I implemented it, so I'm glad to see it still working.
whiteknight: I really like your blog post about exceptions. I'm going to condense it into some cleanup notes.
I think I'll have time today to work on it. 15:32
afk $work
kthakore Austin: :p
Austin: thanks for the help
Austin np 15:33
15:35 silug_ joined 15:39 mikehh joined 15:47 Psyche^ joined 15:52 ruoso joined 15:57 theory joined
whiteknight Tene: I'm glad you like it! I really want to be clear that I'm complaining about the spec, not about your work with it 16:01
because you've done a lot of really good work
darbelo bacek: pong 16:10
NotFound whiteknight: there is some problem with oplib.pmc First, it doesn't set the custom_mark flag, but even fixing that it crashes sometimes. If I delete the "singleton" specifier, it doesn't fail. Maybe there is some problem in the GC about marking singletons? 16:13
whiteknight NotFound: that's possible. I think singletons are created in the constant pool, so the cache object it uses might not get marked 16:14
so either remove singleton, which is a hack, or change the cache to be a constant PMC
NotFound Looks like the other singletons in the repo doesn't need to mark anything.
darbelo NotFound: Singletons are immortal. 16:15
NotFound darbelo: yes, but his data is not.
whiteknight: I think constant hashes with non constant data have related problems. 16:16
darbelo NotFound: It will only be destroyed during final celanup. The alternatives are to leak, crash or both.
NotFound darbelo: if a singleton has some PMC data, it needs to be marked. 16:17
whiteknight NotFound: so that's a good point. Maybe remove the singleton tag 16:18
darbelo NotFound: Sure, you can set the custom_mark flag, just be careful with the custom_destroy one.
NotFound darbelo: I've do that, but still crashes. 16:19
I think removing the singleton tag is the way to go. Is just an attempt of optimization, I think. 16:20
It doesn't really need to be unique.
darbelo NotFound: Making sigletons work right is a better choice. 16:21
;)
NotFound darbelo: yes. I can create a ticket: "Fix parrot" X-)
16:22 Andy joined
darbelo We should have a ticket for sigleton order-of-destruction bugs since last year. 16:22
16:22 kurahaupo joined
darbelo I opened it ;) 16:22
NotFound This isn't an order of destruction problem. The var is never destroyed before crashing. 16:23
darbelo NotFound: I'm looking at it now, and the init() vtable is wrong. 16:25
singletons shouldn't play with the pointers that {get,set}_pointer manipulate.
16:26 patspam joined
darbelo NotFound: Can you try nopaste.snit.ch/19759 ? 16:27
NotFound darbelo: I don't see any pointer manipulated by both. get and set uses OPLIB_PMC_INSTANCE and init uses OPLIB_OPCODE_CACHE
darbelo NotFound: Precisely. They should both touch the same pointer. 16:28
The code in pmc.c uses get_pointer and set_pointer to ensure the unicity of the PMC. 16:29
NotFound darbelo: no effect
darbelo NotFound: Oh, my bad. wrong nopaste. 16:30
Gimmie a sec...
NotFound darbelo: I've already tried setting one ot both to NULL or to PMCNULL,
16:31 kurahaupo joined
kthakore NotFound: japhb: can you guys answer this www.reddit.com/r/perl/comments/b5q6...eye_candy/ 16:33
see reticulator's comments
NotFound BTW I don't see why we need the static PMC pointers, anyway. The singleton support should take care of all that,
Tene whiteknight: of course. no offense taken. My main blocker on exceptions work was a lack of experience to inform me how it *should* work. I tried updating PDD23, but I was mostly just able to make it consistent, not able to evaluate sanity. 16:34
whiteknight NotFound: you're right. Parrot should have a built-in mechanism to properly support singletons WITHOUT requiring the ugly get_pointer/set_pointer inteface it uses now 16:35
Better would probably be an Integer->PMC hash in the interpreter that keyed type id number to instance, and looked it up there
NotFound kthakore: Answer what question? 16:36
kthakore NotFound: when will you guys start NCI redesign? 16:38
NotFound kthakore: To have threaded callbacks? We don't even have a usable thread system rigth now. 16:39
kthakore well what needs to be done 16:40
dalek kapo: 4a69f1e | austin++ | (11 files):
More changes in support of Close.
16:41
darbelo NotFound: You do need *one* static pointer. And that one should only be touched by get/set_pointer. The cache should be an attr. 16:44
See nopaste.snit.ch/19760 16:45
That's what I wanted to paste the first time. 16:46
16:53 kurahaupo joined 16:57 theory joined
NotFound darbelo: still crashes 16:59
Coke (rethrow doesn't seem to rethrow) - there's a ticket for that.
darbelo Damm, do you have a simple test case?
Coke I remember being confused by the explanation as to why rethrow wasn't working like I expected.
NotFound darbelo: that depends on what you accept as 'simple'. Using packfile.winxed -d a_large_file.pbc 17:00
Coke Austin: see TT#1283 17:01
darbelo Simple < "100 lines of PIR"
Austin Coke: hell, yeah. 17:02
NotFound darbelo: packfile.winxed compiled to pir is 1196 lines long, I suppose it doesn't qualify.
dalek kapo: 950bb09 | austin++ | (6 files):
Added NameSpace.string_name options.
17:03
darbelo I'm getting a winxed checkout now. If you can show me a 2-line invocation that breaks reliably I'll take that.
NotFound darbelo: winxed --stage=2 examples/packfile.winxed -d winxedst2.pbc 17:04
I saved you one line ;) 17:05
Or you can first compile packfile to pbc, to shorten it: 17:06
darbelo Nice, except that my g++ is too ancient for winxed.
17:06 cotto joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32382), fulltest) at r44453 - Ubuntu 9.10 amd64 (g++ with --optimize) 17:07
NotFound darbelo: uh, that's a problem, I don't have a distributable stage 1 precompiled yet.
darbelo: What g++? The intention was that it builts with any reasonably recent version. 17:09
darbelo g++ (GCC) 3.3.5 (propolice) 17:10
Austin Is there a way, in pir, to create a continuation?
NotFound darbelo: should work. Where it fails?
17:12 kurahaupo1 joined
NotFound Austin: t/pmc/continuation.t 17:12
Austin NotFound++ 17:13
darbelo NotFound: nopaste.snit.ch/19763
NotFound darbelo: looks odd. Maybe you have mixed several g++ versions? 17:15
darbelo I should only have the one that ships in the OpenBSD base system.
17:16 AndChat| joined
NotFound Note that is a g++ header who fails to include another header. 17:16
darbelo Shit. There's something awfully wrong in /usr/include 17:23
Coke reads andrew's blog post and has a hard time getting past all the insults. 17:29
Coke marks them unread for later. 17:30
kurahaupo Firefox says: Warning: The stylesheet nopaste.snit.ch/style was loaded as CSS even though its MIME type, "text/html", is not "text/css". 17:39
NotFound I think that the "errorson" model is hard to understand an implement in a multi language and multi model scenery. 17:44
s/model/module
We may need that each sub set his wanted state at start. 17:45
kurahaupo Sounds like a candidate for an attribute on the sub? 17:46
NotFound Sounds like a mess to me. Is far easy to select what behaviour is desired by just using the appropiate opcodes.
kurahaupo Not our fault other people design stupid languages 17:47
Austin NotFound++ 17:49
kurahaupo NotFound++
Austin I think that's a relic of everyone having to write pir: "I don't want an exception, 'cause that's a lot of work to set up. Just return null"
NotFound Even within the same sub, one may want to check for a name in one place, and take for granted it can get other. For the first it uses a check, for the second soemthing that throws if not found. 17:50
Austin Sure. if $namespace.contains('qsort') { qsort(@array) } 17:51
particle austin: it's a relic of the exception system not having been implemented for a long time
Austin particle: You think?
purl No, I'm a bot.
particle and of static thinking in a dynamic world
parrot's design changed significantly as perl 6 grew
initially, parrot was designed as a vm for a perl 5-like language 17:52
perl 6 was a perl 5-like language at first
that changed.
Austin NotFound: Would it make sense to implement the control exceptions as a set of searchable RPA stacks with continuations, instead?
NotFound I don't want to blame any one, just want a workable design and a path towards it. 17:53
Austin We're more than a year in, so i think we can blame it all on Obama, now.
NotFound We can always blame Nixon. 17:54
Austin: what will be the difference between that and the current way? It already has stacks of exception handlers. 17:55
Ah, you mean to separate the control ones? 17:56
Austin Yes.
NotFound Better ask the rakudo guys, I've never used control exceptions. 17:57
Winxed uses good old goto ;) 17:58
nopaste "Austin" at 68.37.46.53 pasted "return 1; (nqp->pir)" (7 lines) at nopaste.snit.ch/19765
Austin O
I'm thinking that the cost of setting up and executing all those control exceptions is really wasted, since the control stuff is all about invoking a non-local continuation with an optional parameter. 17:59
NotFound The reason is that I don't plan to allow resumable exceptions in Winxed.
Austin :)
18:00 bacek joined
NotFound Austin: well, if the initial design was based in excpetions used for exceptional conditions, it makes sense that it doesn't try to make them faster to build and throw. 18:01
If heavily used for control flow, agreed that a faster way will be a big gain. 18:02
Austin Ignoring that, it's a case of an exception being an all-purpose thing. But a control-transfer is just a longjmp. Somebody registers the target, somebody else invokes it.
NotFound Austin: ah, you mean then to use a plain continuation instead of wrapping it in a full exception handler? 18:03
Austin Just about, yeah.
NotFound Looks good and doable. 18:04
nopaste "Austin" at 68.37.46.53 pasted "Exception overhead in nqp" (74 lines) at nopaste.snit.ch/19766
18:04 davidfetter joined
Austin If you look at hte last half or so, you'll see what price pmichaud has to pay to use control exceptions. 18:05
NotFound Yes, I had the idea that it used something like that.
Austin FYI: Type 58 is a "return" exception. 18:06
NotFound An initial path may be to use a PMC derived from exceptionhandler easier to initialize. Later it can be change to no inherit from exceptionhandler, if wanted. 18:07
Austin So "return 1" takes a 2-line sequence (create an Integer, set it to 1) and adds 4 lines of build an exception,set the type, set the payload, throw the exception. 18:08
I was thinking of just using a continuation. Then use something like find_dynamic_lex to locate the handler. 18:09
whiteknight Coke: insults?
purl insults are against the MOTD
NotFound And nqp can't define his own opcodes to shorten it because we want nqp to be light weight, I see.
pmichaud the cost isn't in the opcodes 18:10
Austin Actually, I was thinking the opcodes could come later, if at all, and make things even more direct. Kind of like 'vivify'
whiteknight Exception systems tend not to be very performant because they are usually not intended to be used frequently
18:11 chromatic joined
NotFound pmichaud: yes, but having to generate a lot more of them isn't also good. 18:11
Austin Is anyone else having trouble with the nopaste script talking to snit.ch ?
pmichaud let me just say that having an equivalent opcode to perform the same sequence wouldn't provide significant performance benefit. all it might do is make the PIR code look a little neater 18:12
Austin But if it could stop the nesting? 18:13
pmichaud ...stop the nesting?
I don't understand
Austin Don't exceptions wind up with a nested run loop for a bit? 18:14
pmichaud for longer than a bit, even.
but continuations suffer the same problem. 18:15
Austin Really?
pmichaud see the thread at lists.parrot.org/pipermail/parrot-d...03479.html -- especially the later messages in the thread
Bob Rogers' messages are particularly relevant: 18:16
lists.parrot.org/pipermail/parrot-d...03517.html
NotFound Continuations work with contexts, not with the C stack, I think, so they must have the same problems.
pmichaud lists.parrot.org/pipermail/parrot-d...03536.html 18:17
(actually, just read the whole thread)
18:17 bluescreen joined
pmichaud but it points out that Parrot continuations in general have a runloop issue, not just exceptions 18:17
NotFound I fully agree. 18:18
pmichaud In lists.parrot.org/pipermail/parrot-d...3548.html, Bob Rogers provides a proof-of-concept patch for helping out the runloop with exceptions problem, but also says
1. This only works for the ExceptionHandler class; it should be
refactored so it works for all continuation classes.
anyway, getting better control over subroutine exit semantics (which would include "return" handling) has been on Rakudo's priority list for a long time now, and explicitly mentioned whenever someone asks me "how can Parrot help Rakudo?" 18:19
Austin What is it that is needed, other than "go faster" ? 18:21
pmichaud the ability to explicitly force a caller subroutine to exit (and return specific values)
and to roll up the intermediate runloops in the process
NotFound pmichaud: I'm not sure if that patch takes into account resumable exceptions
pmichaud NotFound: I'm not sure if it does either. But the other messages in the thread identify a way to deal with exceptions in general
my proposal was lists.parrot.org/pipermail/parrot-d...03511.html 18:22
Austin So if there was a stack of 'return' (as separate from loop-next) continuations, and one could invoke $context.control_stack<return>[-4]($result) 18:23
would that do it?
pmichaud at any rate, it's worth noting that in Rakudo's case, the PIR code generated for "return 1" is in fact "&return"(1) 18:24
(might not be yet, but that's what it will end up being for a time)
Austin: yeah, that's something along the lines of what I had been imagining. 18:25
Austin My only hesitation is naming
pmichaud well, I was thinking more of:
Austin Some of the control structures in Perl want names. How to attach them? 18:26
pmichaud $context[-4].return($result)
i.e., go up a certain number of caller contexts, get its return continuation, and invoke it.
in the Perl 6 context that gets a little trickier, though, as in addition to invoking the return continuation we have to perform constraint checks on the argument 18:27
s/argument/return value/
Austin Isn't that the responsibility of the caller?
pmichaud no
Austin (IOW: [-4])
So the continuation would point to a constraint checking postamble...
pmichaud oh, yes, that's a possibility
another possibility is that there's a constraint checking postamble that is performed whenever the subroutine exits 18:28
Austin That would call the body? 18:29
pmichaud I don't have specific details as yet.
I just know that Parrot is missing some pieces we need for Perl 6. :)
NotFound darbelo: I'm going to commit a patch dropping the singleton tag, if youn don't object. 18:30
Austin :)
darbelo NotFound: Not at all, it looks to me like it's tehere as a (premature) optimization. 18:31
pmichaud I also know that Perl 6 tends to look at return handling as exception-based (even to the point of being able to catch return exceptions)
NotFound darbelo: anyway we can test and restore it later, if looks convenient,
pmichaud although optimizers are free to omit the exception creation/handling if they can determine that it's safe to do so
Austin Hmm 18:32
pmichaud it gets a lot trickier though when returning from nested lexical scopes
Austin Who would catch a return exception?
pmichaud the outer sub catches it
Austin Yeah.
pmichaud oh, you mean other than that
Austin So to get between outer and inner ...
you have to be part of the outer, or part of the inner.
pmichaud sub foo() { CONTROL { ...catch return exception here... }; if $x { return 5; } }
foo() can catch the return exception and do something with it before exiting. 18:33
Austin Does perl6 have goto?
pmichaud yes, perl6 has goto
Austin ('cause it does now, for sure..)
pmichaud that's just another exception, generally :-)
it might end up being a continuation as well, but we have to have a mechanism to handle block exit semantics when jumping from one scope to another 18:34
Austin How would that interact with the forcing-a-caller issue?
If I want to force a 'caller' to return a value, I need a way to identify the caller - not some code that jams a continuation or exceptionhandler on a stack someplace. 18:35
pmichaud well, one can look up the caller stack to find the caller of interest
Austin Also, if I did the force-a-caller thing, would any Control::Return handlers inside the caller see the return event? 18:36
pmichaud or, a compiler can know who the caller is
the force-a-caller thing would need to be able to detect intermediate Control::Return handlers, yes. It's an optimization, not a "always do it this way" sort of thing. 18:37
anyway, I have to run some errands -- bbl 18:38
bacek Morning... 18:42
18:43 ruoso joined
davidfetter oi ruoso 18:43
dalek rrot: r44454 | NotFound++ | trunk/src/pmc/oplib.pmc:
drop singleton tag from OpLib PMC and set custom mark on it
18:45
whiteknight I keep wanting to ask pmichaud about those exit routines
because it seems to me that the problem is every HLL subroutine is composed of several nested PIR subroutines, and then we need a way to "exit" from the whole group 18:46
Austin Yeah 18:47
darbelo bacek: pong
Austin Throw a Control::Return exception
whiteknight it seems to me more that the solution would involve flattening out so 1 Perl6 sub == 1 PIR sub
Austin Nope.
whiteknight nope?
The only reason I can see to have the nested conglomeration of subs is to implement nested lexical scopes 18:48
Austin Blocks that can "return" get a return handler (58) added to them.
whiteknight: Correct. Especially for reused symbols like $_
bacek darbelo, I can just give you commit bit to pirpct git repo.
Austin for @list { say $_ ; for @inner_list { say $_ ; for @inner_inner_list { say $_; } } } 18:49
darbelo bacek: Excellent. I've just got the compiler to run.
whiteknight Austin: right. But if you look at the output of other compilers, eg a C compiler, even though the language enforces nested lexical scopes, the output ASM has no notion of them
Austin Yep.
bacek darbelo, I just have to find how to do it :) 18:50
whiteknight the ASM code doesn't know variable names, just allocates different storage for each and flattens
Austin But parrot doesn't have memory.
It does have lexpads.
darbelo It doesn't do anything, except not die at the moment.
whiteknight what do you mean, doesn't have memory?
darbelo But I'm told not dying is important...
Austin Whiteknight: How can you allocate local storage in parrot?
.local pmc foo
whiteknight Austin: we allocate local storage for registers 18:51
a smarter code generator would allocate more registers
Austin And give them names.
whiteknight why give them names?
Austin So your code can find them?
bacek darbelo, can you try to push in my repo?
18:52 hicx174 joined
darbelo Sure, give me a second. I think I lost my local clone. 18:52
Austin A C compiler can re-use a name by assigning the same name (different lexical vars) to different local addresses.
whiteknight Austin: string names can be done now. We have that. symbolic names at the PIR level are useless
Austin: the C compiler doesn't have names. Just registers and memory locations
at least, the output of it
Austin Right, but the input did.
So if I say, in C: { int x = 0 ; for (;;) { int x = 1; ...} ... } 18:53
there's two vars there
"outer x" and "inner x"
whiteknight Austin: right, but that's just a constraint of naming imposed by the parser
internally to the compiler, and in the generated output, the two aren't even remotely related 18:54
Austin A dumb C compiler, like myself, might simply say: okay, "outer x" is [bp + 4] and "inner x" is [bp + 8]
8 ]
whiteknight right, and that would be fine
Austin In parrot, we can't do that. Everything has to have a name.
You can call 'em p0 and p1, or '$_' and '$foo', but there's names. 18:55
If you try to put them in registers, then you need a way to map the name to a register when some subroutine tries to search for a dynamic variable.
Because C doesn't have "eval"
whiteknight Austin: that could be accomplished quite easily, and with far less overhead, with some sort of name stack 18:57
Austin Could it?
whiteknight I believe so
Austin With closures and everything?
whiteknight Pushing a name on a stack would update the register number refrence, in the way that lexicals keep track of that info now 18:58
closures would then inherit those name mappings
so yes, I think it would work
Again, keeping in mind that logically separate variables have distinct storage with a name mapping that doesn't change
Austin That sounds a lot like perl5's "local" 18:59
whiteknight with sufficiently smart optimizers, everything fails (including the current implementation)
Austin: that's not a horrible model
Austin I didn't say it was. But there might be some documentation of all the things wrong with it - somebody else has probably already done that work.
particle stack is a dirty word. 19:00
tewk Austin, see en.wikipedia.org/wiki/Lambda_lifting 19:03
darbelo bacek: done. pushed all of my commit s to the other repo. 19:04
bacek darbelo, excellent! 19:05
darbelo I'll un-fork it now ;)
Doing 'parrot setup.pir' leavs you with a not-very-functional installable_pir fakecutable. 19:07
bacek darbelo, it's very-very old code. And yes, require a lot on necromancy to resurrect :) 19:08
darbelo goes fetch his necronomicon.
NotFound notfound.posterous.com/how-to-build...nokia-n900 19:16
davidfetter iaaa! 19:17
19:19 theory joined 19:36 ruoso joined, AndyA joined
pmichaud 18:57 <whiteknight> Pushing a name on a stack would update the register number refrence, in the way that lexicals keep track of that info now 19:37
fwiw, at one time Parrot used to have something very much like this. but then it was eliminated. 19:38
i.e., lexpads were maintained on a stack, so that a single hll subroutine with nested lexicals could potentially correspond to a single parrot sub
I never quite understood why that approach was eliminated. (on the other hand, I didn't quite understand how to make things work with it either -- this was long before we were dealing with lexical vars in any sort of hll) 19:39
19:45 joeri joined
TimToady phone 20:00
20:00 s1n joined 20:01 lucian joined
whiteknight pmichaud: I wish I had joined Parrot earlier so I could have witnessed some of those kinds of decisions 20:02
and "stack" isn't a dirty word. 20:03
darbelo Yes it is, we're a register vm.
bacek CPS actually
davidfetter ? 20:04
whiteknight a per-context lexical names stack could potentially be a huge performance svings for HLLs that make heavy use of lexicals and nested scopes
Parrot being register-based means we don't have aglobal control flow stack
it doesn't mean we can't use stacks for other purposes, especially when those are the right thing to do
pmichaud whiteknight: I don't think those decisions were made with open discussion, fwiw :)
bacek "register-based" and "control flow" are orthogonal.
whiteknight bacek: sort of 20:05
davidfetter fwiw?
purl i think fwiw is for what it's worth.
whiteknight bacek: unless we're creating storage on the stack
davidfetter purl, fwiw is also www.youtube.com/watch?v=Wm6NeM-6vBE
purl okay, davidfetter.
davidfetter fwiw
bacek whiteknight, we are not.
davidfetter oops
fwiw?
purl somebody said fwiw was for what it's worth. or www.youtube.com/watch?v=Wm6NeM-6vBE
whiteknight bacek: right. But some VMs DO use a stack for storage and for flow control
I think JVM and .NET both do 20:06
darbelo For the record, I was just being glib :)
whiteknight and that doesn't matter, because those two VMs blow parrot's ass out of the water in terms of performance
bacek whiteknight, yes.
for many reasons
whiteknight so it's hard to say that "stacks are evil" when we have significantly worse performance than most stack VMs
NotFound Lots of money, for example ;)
whiteknight: Who says evil isn't fast? ;) 20:07
chromatic It's hard to say that Parrot uses registers when we spend so much time copying values in and out of "registers". 20:08
whiteknight One saving grace is that we can push expensive tasks like register allocation to compile-time and amortize savings over multiple bytecode uses
Parrot really should make much higher use of the "compile to bytecode and run the bytecode" paradigm, then we could offload a lot more processing to the compiler for amortized savings 20:09
chromatic Sure, but if you read the Inferno papers, they say "Maybe the biggest benefit of the register approach is not spending all that time copying memory around."
whiteknight chromatic: I think that's misguided. Copying a P value to a new register is no more expensive than copying a register pointer to a call list
chromatic Copying a pointer is more expensive than not copying a pointer. 20:10
whiteknight chromatic: so how would you make a call without taking either a pointer to a register or copying the contents of that register in the call?
chromatic Read the Inferno paper.
whiteknight I believe I have. Link? 20:11
We're not using native hardware registers, so every modification is memory access in any case
whether we store an index, store a pointer, or copy a pointer, it's all the same expense 20:12
bacek not quite true
We allocate storage for registers/copy values/allocate storage fro return values/copy pointers to return values/ 20:13
On every single bloody call...
chromatic www.usenix.org/events/vee05/full_pa...-yunhe.pdf 20:15
bacek Oh gosh... I almost forgot how I hate ImageIO/Packfiles... 20:18
whiteknight either we need to copy pointers to new register sets, or we need to have a sliding window register system 20:20
in either case, we're moving data between calls
bacek which is harder to implement on CPS VM...
(sliding window)
whiteknight exactly
chromatic If you know that a target register is a return value....
whiteknight the PCC system could get significantly cleaner and faster if we have Lorito and if we rewrite the top 30% of Parrot in Lorito 20:21
bacek it will not
At least I can't imagine how Lorito can help with PCC
whiteknight once we enter the the Lorito runloop we never exit it, never descend far into C, and then never need to worry about getting parameters as a va_list*
if we don't have multiple input formats, we don't need CallContext as a serialization format, and we can save a lot of effort 20:22
bacek it's unified now
every Sub call going through PCC
whiteknight bacek: If everything is written in Lorito, we don't need Parrot_pcc_invoke_from_c_args
bacek from_op
whiteknight bacek: yes, but PCC is more complicated because of multiple argument formats
bacek we still need it
whiteknight one argument format, one code path, fewer checks and branches 20:23
PerlJam whiteknight: has anyone worked out what the "top 30% of parrot" is ?
whiteknight chromatic: yes, I have seen this paper before. Thanks for the link
PErlJam: ops and PMCs mostly. A few APIs
PerlJam: any code path that nests into a new runloop or results in a new PIR function call 20:24
bacek it's about 90% of parrot :)
*incoming*
whiteknight 90% of the top 33% :)
dalek rrot: r44455 | bacek++ | branches/boehm_gc_2/compilers/imcc (6 files):
Use consistent string allocations
20:25
rrot: r44456 | bacek++ | branches/boehm_gc_2/compilers/imcc/pcc.c:
One more malloc replace in IMCC
rrot: r44457 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
Comment out GC_FREE. It's faster.
rrot: r44458 | bacek++ | branches/boehm_gc_2/src/main.c:
Reorder variable declaraions to prevent compiler warnings. Don't call GC_init. It's useless.
rrot: r44459 | bacek++ | branches/boehm_gc_2/src/pmc/callcontext.pmc:
Reorder ATTRs in CallContext to enable typed allocations in Boehm GC.
rrot: r44460 | bacek++ | branches/boehm_gc_2/include/parrot/settings.h:
Switch default GC to MS.
rrot: r44461 | bacek++ | branches/boehm_gc_2/compilers/imcc (2 files):
HACK: Don't clear memory in IMCC. It's allocated in strange way and causes segfaults...
rrot: r44462 | bacek++ | branches/boehm_gc_2 (2 files):
Actually use typed allocation for CallContext.
whiteknight ...well, that ends the conversation 20:28
bacek++
bacek Boehm is slower than our MS GC on small live objects set...
And I almost gave up on it... 20:29
chromatic Boehm isn't precise, is it?
bacek It's conservative.
But I use typed allocations with memory layout bitmaps 20:30
PerlJam Is there a standard parrot benchmark in the repo for comparing GCs?
bacek PerlJam, I use "fib2.nqp"
nopaste "bacek" at 114.73.160.181 pasted "fib2.nqp" (17 lines) at nopaste.snit.ch/19768
bacek this one
Boehm is about 17 seconds, MS - 19. 20:31
chromatic Do you have Callgrind numbers for each? 20:34
bacek nope. valgrind can't work with Boehm... 20:35
chromatic Oh, right. 20:36
cotto_work How so? 20:37
bacek ==31706== Process terminating with default action of signal 11 (SIGSEGV) 20:40
==31706== Access not within mapped region at address 0xBED3F000
==31706== at 0x4417B88: GC_push_all_eager (in /usr/lib/libgc.so.1.0.3)
dalek rrot: r44463 | bacek++ | failed to fetch changeset:
Merge branch 'master' into boehm2
20:42
20:45 magnachef joined
nopaste "bacek" at 114.73.160.181 pasted "Meh... I BROKE IT..." (20 lines) at nopaste.snit.ch/19770 20:47
chromatic You get both pieces as a consolation prize. 20:48
20:55 hercynium joined 21:09 AndyA_ joined
dalek rrot: r44464 | bacek++ | trunk/compilers/imcc/pbc.c:
Use zeroed allocations for constants
21:15
21:22 hercynium joined 21:43 TonyC joined 21:53 darbelo joined 22:04 lucian joined 22:11 desertm4x joined
dalek rrot: r44465 | NotFound++ | trunk/t/pmc/oplib.t:
update oplib test, no more a singleton
22:21
22:31 bacek joined
Coke botsnack 22:32
purl thanks Coke :)
Coke does the oplib pmc work with dynpmcs? or just core? 22:33
errr... dynops, not dynpmcs.
NotFound Coke: don't know, never used dynpmcs yet. 22:34
It looks a interpreter table, so whatever that table does. 22:35
dynops
dalek rrot: r44466 | NotFound++ | trunk/t/pmc/oplib.t:
some more oplib testing
22:37
darbelo NotFound: I fixed my g++ issues and now winxed builds (With some "class Foo has virtual functions but non-virtual destructor" warnings) an passes all of make test. 22:40
NotFound darbelo: good
darbelo Apparently, I installed my development tools from a corrupt archive, but never did enough c++ coding to notice. 22:41
NotFound darbelo: the warning are pointless because it never destructs anything. It uses a 'infinite memory' garbage collector ;)
darbelo So, it leaks like a sieve and *likes* it? 22:42
Makes for straightforwad code I guess...
Austin The inf gc has a certain performance bonus...
NotFound darbelo: yes, the compiler has a short live, the driver calls it an gets the pir result. 22:43
The plan was to use some smart pointer, but that way will force to use a c++ 0x compliant to some degree or force to install boost. This way is more portable. 22:45
dalek kapo: e98c9a7 | austin++ | (2 files):
Force Mimus::Maker to get methods from all parent classes.
22:46 Whiteknight joined
darbelo For a bootstrap stage, I'm all in favor of portablity over 'correctness'. 22:46
NotFound Yeah
darbelo I'm guessing you mean for the bootstrapped compiler to be the main one. 22:47
NotFound Yes, but the speed difference with the stage 0 is high. Need more thinking. 22:48
22:50 kurahaupo joined
NotFound Welcome to the Winxed user's club, BTW ;) 22:51
darbelo 'user' is an overstatement. I haven't even learned the syntax yet! 22:52
NotFound Feel free to ask. 22:53
Austin What is src/dynoplibs/math.ops? 22:55
Is that available by default, or do I have to jump through hoops?
NotFound The idea is that anyone with rudiments of javascript and knowledge of pir should easily understand the parrot related examples.
Austin .loadlib math_ops
NotFound Austin: t/dynoplibs/math.t looks like that, yes. 22:57
Austin Do I have to dlfunc the functions, or does the loadlib take care of that for me? (They're ops, in this case.) 22:59
darbelo Austin: loadlib does the trick.
Austin Walkin' a mile to get a random number...
NotFound I think the .loadlib directive takes care of the underground work. 23:00
Austin I hope that's an opcode, not a directive.
NotFound Don't know, the internals of dynops are black magic for me. 23:01
darbelo Austin: opcode, it's defined in src/ops/core.ops 23:02
NotFound I suppose pir needs the directive form to be able to parse the opcodes. 23:03
darbelo Not really. 23:04
I've always used it as $P0 = loadlib "lib"
Austin We'll find out in just a sec. Anyone got a good test case for Array.unsort? 23:06
darbelo [ 1,2,3,5 ] ?
Austin Problem with changing algorithms in midstream is all those declared variables with the wrong name... 23:11
Well, that isn't working. 23:13
Apparently there's more to be done to get dynamic ops working.
:(
darbelo Austin: can you show what code isn't working? 23:16
Austin darbelo: It's the .loadlib directive 23:17
I'm doing nqp, not pir, so there's no way to generate a directive.
I can get nqp to emit the rand opcode, but that doesn't work because the whole loadlib thing happens at pir-compile time, I guess. 23:18
darbelo And using the loadlib opcode doesn't work?
Austin darbelo: right. It loads the library, but doesn't do whatever magic is required to make the opcodes work 23:19
darbelo Hmm. The opcode form only works with dynpmcs becouse those don't need to tell IMCC about syntax changes. 23:27
23:27 hercynium joined
darbelo Austin: But having dynops inaccesible from NQP feels wrong. You should consider asking pmichaud about that. 23:32
Austin ? 23:37
I didn't understand the part about no syntax changes... isn't a dynop a syntax change (new opcode#, new string to parse, whatever)? 23:38
darbelo Yes, dynpmcs don't add any opcodes so they work without needing a directive.
I just realized all of my loadlib uses were for dynpmcs, not dynops. 23:39
That's why I though it worked.
Austin Ahh, here we go. The directive loads the lib at compile time, the opcode loads it at runtime.
darbelo Yeah. 23:40
pmichaud if it's not loaded at compile time, imcc doesn't recognize the opcode 23:42
ooc, what happens if one does Q:PIR { .loadlib "math" } ? Does imcc require .loadlib directives to be outside of Parrot subs? 23:43
darbelo Yep. .loadlib inside a sub bails out. 23:44
pmichaud ouch.
I'm going to guess that we need some special handling in NQP to be able to tell Parrot to .loadlib
I'm not sure what that should look like
Austin #pragma loadlib ? 23:45
darbelo 'use' with a fake namespace root?
pmichaud well, I'd like it to be perl 6 syntax. 'use' might work. 23:46
Austin A special block
like INIT { }
pmichaud along a similar vein, I'd like there to be a way to specify .HLL within NQP 23:47
haven't figured that one out yet either, but the syntax involved is likely similar
might end up being a specialized pir:: pseudo-op, or something similar.
23:52 s1n left