Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply and context_auto_attrs merges | find out what's up with the slice opcode | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 8 November 2009.
Whiteknight just updated his kernel, hopes ubuntu becomes slightly more stable 00:01
I've spent the last 45 minutes trying to get online
darbelo Ubuntu != stable
cotto_work wb
00:02 |kesselhaus| joined
Whiteknight 9.04 was very stable, and I loved it 00:03
the 9.10 upgrade was a little more rocky
I'm fine with it though, I did adopt it pretty early. I know the risks to a major update like that
so I'm not upset, I'm just going to do what I need to do to get it working again 00:04
NotFound Whiteknight: for me upgrading to 9.10 has been easier than to 9.04 00:07
And it solved some pitfalls
Whiteknight 9.04 was 100% smooth for me. No problems whatsoever
00:07 kid51 joined
NotFound Whiteknight: an example: changing the wallpaper from the control center never worked for me. Failed silently. 00:08
00:09 plobsing joined
NotFound And the same for changing kdm settings. 00:09
Well, maybe is just kubuntu
Whiteknight i've been on gnome for a few years now 00:10
NotFound I originally installed ubuntu, but later installed the kubuntu packages, and later uninstalled the gnome ones. 00:11
Is a mutating system X-)
darbelo In my experience, ubuntu doesn't handle mutations gracefully. 00:12
NotFound Well, not exactly, in my newest laptop I don't installed it, it comes preinstalled.
Whiteknight I got ubuntu at 8.04, have upgraded early every release, and this is the first time I've had problems 00:13
so I'd say I'm very very happy with it
dukeleto my cow-orker upgraded ubuntu today and got bit by libc issues 00:14
evidently the new libc shenanigans no longer work on older dell desktops, which is quite unfortunate
darbelo "libc issues" ?
Whiteknight I am only bothered by problems that don't get attention. I can put up with any problem if I know people are actively working on it 00:15
so I don't mind a few headaches after an upgrade
dalek tracwiki: v117 | jkeenan++ | WikiStart
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
chromatic doc.cat-v.org/inferno/4th_edition/d...cification
doc.cat-v.org/inferno/4th_edition/dis_VM_design
dukeleto darbelo: libc was forked recently, because the guy who maintains it is not working with people. the libc is going through a schism right now
darbelo Ah, yes. Godd ol' mr. Drepper, right? 00:16
dalek rrot-plumage: 79842ba | japhb++ | :
Move Glue.pir's exists() and keys() to Util.nqp's .exists and .keys; fix...
TT #1255 created by jkeenan++: fix PARROT_EXPORT visibility=default for gcc other than 4.x 00:19
kthakore chromatic: do you has unix? 00:20
pmichaud japhb: there's not a way to get to PIR's keyed syntax, sorry. That's one of those "features" that makes things a bit more difficult for compilers :-|
kthakore chromatic: hi btw ..
japhb pmichaud, understood
kthakore anyone got access to a unix box with display?
kthakore needs testing done ... oh well 00:21
oh well
gym time
japhb pmichaud, I see that I forgot to put try and /or CATCH on Plumage Requests. Do they already exist, or should I add them to the list?
pmichaud add to list. 00:22
try can come quickly... CATCH I'm not so sure yet :-)
japhb pmichaud, roger dodger
pmichaud afk, dinner
japhb added. 00:23
00:26 mikehh joined
dalek TT #1256 created by jkeenan++: src/pmc/class.pmc: Need a pluggable MRO in instantiate() PMC 00:29
rrot: r42392 | jkeenan++ | trunk/src/pmc/class.pmc:
Change an RT # to a TT #. Remove references to closed RT tickets.
 00:33
purl dalek: that doesn't look right
00:42 szabgab joined 00:52 darbelo left
dalek TT #1257 created by jkeenan++: src/io/utf8.c: Does the amount read in Parrot_io_read_utf8() need to be ... 00:52
rrot: r42393 | jkeenan++ | trunk/src/io/utf8.c:
Change an RT # to a TT #.
 00:53
purl dalek: that doesn't look right
TT #1258 created by jkeenan++: Method cache not always invalidated 00:56
00:58 Zak joined
dalek TT #1259 created by jkeenan++: src/debug.c: Correctly handle comparisons of PMCs with constants 01:02
kid51 There are no longer any tickets in RT owned by 'nobody'. All 30 remaining RT tickets have owners.
And with that ... 01:03
dalek rrot: r42394 | jkeenan++ | trunk/src/debug.c:
Change an RT # to a TT #.
purl dalek: that doesn't look right
kid51 rests
01:03 abqar joined
pmichaud 22:12 <bacek_at_work> japhb, for performance reason. You can avoid second symbolic lookup during iteration 01:20
fwiw, I don't quite understand this comment. 01:21
(and would like to understand it better.)
bacek_at_work pmichaud, $S0 = shift it; $P1 = hash[$S0].
hash[$S0] is symbolic lookup.
pmichaud and you're saying that 01:22
bacek_at_work We have to calculate new hashvalue, iterate over buckets, etc.
pmichaud $P0 = shift it
$P0.value
is faster?
bacek_at_work yes
jonathan lol
pmichaud ...but I've been told recently that PCCMETHODS are incredibly slow
wehreas hash[$S0] is a vtable method
jonathan bacek_at_work: I highly doubt it.
For the reasons pmichaud just mentioned.
pmichaud I'd like to see a performance comparison. 01:23
jonathan $P0.'value' creates probably two gcables.
At least.
(The CallSignature and the returns thingy)
pmichaud In fact, I've been told recently that PCCMETHODS can consume almost all of the benefit that might come from implementing a given function in C 01:24
jonathan hash[$S0] creates none.
pmichaud (obviously depends on the function, but still, that it's a huge amount of overhead)
jonathan In fact, looking up the method to call involves a lookup in a hash. :-)
pmichaud lol
via the vtable method 01:25
jonathan Right
pmichaud *snicker*
jonathan So I think by definition you *have* to be doing more work!
pmichaud okay, I think I understand now.
thanks.
chromatic What's your new understanding, pmichaud? 01:26
jonathan Full marks for another refactor that's probably made Parrot slower again though. :-/ 01:27
diakopter it if did call itself, it'd loop forever... 01:30
pmichaud what jonathan said.
diakopter oh, you're saying two hash lookups instead of 1
pmichaud diakopter: we're saying that instead of a hash lookup, we now have a hash lookup (in a different hash) and a PCCMETHOD call
diakopter ok; thnx 01:31
01:33 jonathan left
Whiteknight the pcc refactor has dividends yet to pay 01:36
pmichaud Whiteknight: I seriously look forward to those. See my latest message to parrot-dev. :)
Whiteknight when did you send it? 01:37
pmichaud last week
on thursday morning
Whiteknight oh, okay. I have that one 01:38
pmichaud "things parrot can do to help rakudo". #1 was finish reaping dividends from the pcc refactor
kiwichris I have found the PDD "Embedded and Extending Parrot. Nice. Is there more I may have missed ? 01:39
Whiteknight chromatic: is there any progress on the CallSignature + Context merger? 01:40
chromatic bacek stalled wondering which part of the code has the responsibility of creating the merged PMC. 01:41
I suggested he start a writeup on the wiki where we can resolve the questions.
Whiteknight ah, that is a good question
plobsing kiwichris: there's a bit more under various pages at docs.parrot.org/parrot/latest/html/...loper.html
kiwichris plobsing, thanks. 01:42
I want to understand the constraints the VM when embeddeding. For example can I have more than one intrpt running in different thread active ? 01:43
chromatic Yes. 01:44
By design, interpreters should never interfere with each other. In practice, there may be bugs that we need to fix.
kiwichris My concern is exit(3) being called. 01:45
It stops everything.
Sorry to be a pain and head back to this topic.
Whiteknight the exit opcode calls the exit() libc function 01:46
so yeah, that's a bit of a problem
kiwichris Another one. If I start an interp and it exits, with my RTEMS specific exit path and avoids libc exit, can I start a new interp and it should run ? 01:48
chromatic Yes. 01:51
I recommend starting a parent interpreter, then creating children of that interpreter and running code in them though.
kiwichris Great. I getting an assert in pt_add_to_interpreters. I will take a look. Should I raise a ticket with the details ?
chromatic, the RTEMS shell is just a thread that can run parrot. I am not sure how the parent/child interp model works. 01:53
chromatic It's sort of like the init process model on Unix. 01:54
Every interpreter has a parent interpreter, except for the first interpreter which has no parent.
If you want to create a new interpreter, it needs a parent.
kiwichris chromatic, interesting. So I do a new but do not call runcode ? 01:55
chromatic Exactly. 01:57
kiwichris chromatic, then I create a child and a thread and let that thread call runcode ?
chromatic Yes.
01:58 eternaleye joined
kiwichris chromatic, nice. I like this. It is a sort of embedded fork. 01:58
01:58 elmex joined
kiwichris chromatic, does runcode ever return ? 01:59
chromatic, when run as a child ?
chromatic Yes, when the code run ends. 02:00
kiwichris chromatic, many thanks. I will wander away and play with this.
02:02 s1n joined
chromatic If you look at the source code for Parrot::Embed in the Parrot distribution, you'll see similar embedding. 02:03
There's a file called Embed.xs which creates a parent interpreter at the start and uses it as the parent for all subsequent interpreters.
02:04 integral joined
plobsing I fixed the libjit_framebuilder nci.t problems on i386 on the weekend. What do I need to do before it can be merged? 02:06
chromatic If kid51 and Whiteknight have looked over it and approve of their respective parts, we'll discuss it in #ps tomorrow and it should be good. 02:08
Whiteknight I looked at it last week, need to check again
okay, how do I get libjit? 02:24
I thought I had it on my system, but I don't seem to see it now
plobsing ftp://ftp.gnu.org/gnu/dotgnu/libjit/ 02:25
Whiteknight there it is 02:26
chromatic No Ubuntu packages; you'll have to make a .deb with checkinstall. 02:29
plobsing is there somewhere I can request a package for ubuntu? not being packaged makes installation a pain. 02:30
chromatic No idea; good question. 02:32
diakopter bugs.debian.org/cgi-bin/bugreport.cgi?bug=514063 02:34
as debian, so ubuntu 02:35
dalek rrot-plumage: aa58298 | japhb++ | :
[plumage] Remove hack for old NQP
 03:07
rrot-plumage: 88e52c3 | japhb++ | :
[TESTS] Test cleanup, stage 1: Refactor MAIN(), git rid of ARGS and G:PI...
rrot-plumage: 2c2e0a4 | japhb++ | :
[TESTS] Test cleanup, stage 2: Add 01-sanity.t to test testing framework
rrot-plumage: 8303084 | japhb++ | :
[TESTS] Test cleanup, stage 3: Rename glue.t -> 02-glue.t, util.t -&g...
dukeleto wow, japhb++ is on a roll 03:10
japhb indeed. :-)
dukeleto japhb: nice refactoring. i dig it 03:11
japhb dukeleto, thanks! :-)
japhb is currently filling in 03-util.t to improve coverage of Util.nqp 03:12
dukeleto i have still been thinking of how to make the harness not depend on Util.nqp 03:13
is it evil to inline slurp() and rx() in the harness?
japhb Hmmm. I think rx() may be able to go away once we have the P6Regex happy place. I'll think about slurp() when I'm done with current task. 03:14
(P6Regex happy place is blocked on lack of continuable matches in NQP-rx at the moment.) 03:15
dukeleto, if you haven't been watching it, pmichaud and I have been doing low-friction task management for NQP-rx here: wiki.github.com/perl6/nqp-rx/plumage-requests 03:16
03:27 hercynium_ joined
dukeleto japhb: yes, i have taken a look at plumage-requests, but i will again, since it seems that you two have been burning the candle at both ends lately 03:31
japhb dukeleto, yeah, making up for health problems the last few weeks 03:32
03:35 janus joined 03:37 Essobi_ joined
cotto why does plumage need float support? 03:39
03:41 JimmyZ joined
japhb cotto -- will be used for user interface stuff. 03:41
03:44 Andy joined
dalek rrot-plumage: 5a3959b | japhb++ | :
[CORE] Util.nqp: Add missing SYNOPSIS entries
 03:46
rrot-plumage: 8101383 | japhb++ | :
[TESTS] Fill out hash method tests in 03-util.t
japhb ... and with this next push, time to take a break. 03:55
pmichaud purl message bacek I apologize for some of my earlier comments and remarks about HIK performance; upon reflection my statements were likely more condescending than deserved. I shall try to be more constructive with my comments in the future. 03:56
purl Message for bacek stored.
pmichaud thanks, purl
dalek rrot-plumage: dec4bd5 | japhb++ | :
[TESTS] 03-util.t: Add tests for set_from_array()
 03:57
04:02 kurahaupo joined 04:12 pdcawley__ joined 04:18 kid51 joined 04:32 pdcawley_ joined 04:59 nopaste joined
bacek_at_work pmichaud, no worries. trac.parrot.org/parrot/wiki/Parrot...version=13 :) (And perfectly accept same in my address) 05:02
kurahaupo ping bacek ? 05:05
purl I can't find bacek in the DNS.
kurahaupo Is doesn't work; should it? $P0 = new 'Integer' ; $P0 = .MIN_INT ; neg $P0 ; $S0 = typeof $P0 ; is($S0, 'BigInt', 'promotion worked') 05:08
s/Is/This
chromatic I don't know if we perform overflow detection with neg wraparound. We probably should. 05:09
kurahaupo We do (so far) for add & sub...
bacek_at_work kurahaupo, there is no VTABLE_neg in Integer. So it uses Scalar.neg, which doesn't check for overflows. I agree with chromatic, we should check it. 05:11
chromatic Except that neg_i_i can't autopromote. 05:12
bacek_at_work I think it should throw exception than 05:14
kurahaupo It seems like we have a problem. Is an Integer PMC simply a Box in which to put an INTVAL, with identical behaviour to an integer register ($I0 etc), or is it a "small version of BigInt" ? 05:15
I would argue for the former: if you *want* a BigInt, just ask for one.
chromatic I have no better idea than an exception.
kurahaupo So should Integer do *any* promotions at all? 05:16
chromatic I think so.
dukeleto kurahaupo: in which case?
kurahaupo (This is apropos converting t/pmc/bigint.t to PIR, BTW)
dukeleto kurahaupo++ # fellow soldier in the Perl->PIR test army
kurahaupo: we need lots more tests for edge cases 05:17
kurahaupo The test suite appears to test autopromotion of addition (and subtraction also works). When I added tests for abs(MININT) and neg(MININT) they both failed.
chromatic Good, we can fix them then. 05:18
kurahaupo And the "correct" behaviour should be .... ?
kurahaupo is leaning towards ripping out the autopromotion and throwing exceptions on all overflow cases 05:19
chromatic That simplifies the implementation, but won't that lead to bugs in certain cases?
Bugs of usage, I mean.
kurahaupo Exceptions are our friends 05:20
diakopter is this an error in PAST __dump: parrot.pastebin.com/f3f8bd543 line 30 is missing the var name? 05:21
chromatic Do you want to wrap every integer operation in an exception handler? 05:22
kurahaupo screws up face with a *yuck* expression
dukeleto kurahaupo: min/max and friend have lots of bugs lurking near auto-promotion boundaries 05:24
kurahaupo I'm pretty sure we don't need to put an exception handler, say, around an integer iterator over a range where both endpoints are integers. IOW it's cheaper to check the values for prospective overflow, which can then be subject to CSE-type optimisation
Having checked them, you can be sure they won't overflow and trigger an exception. 05:25
You only blow up if your checking is faulty, which you probably want to know about.
We might conceivably want to add opcodes for "add-modulo-2^N" (N=32 or 64) 05:26
dukeleto floor and ceiling have lots of bugs/unspecc'ed behavior as well
kurahaupo: that might be a nice candidate for a dynop 05:27
kurahaupo Don't floor & ceil just do whatever the FPU does? 05:28
kurahaupo wonders why every time he starts looking at code, it's like upending a can of worms... 05:29
dukeleto kurahaupo: look at t/op/inf_nan.t 05:31
kurahaupo: they are called "yak holes" and they are deep and wide
kurahaupo Back to bigint.t -- what should I assert as the "correct" behavour for abs & neg?
dukeleto kurahaupo: the hairiest yaks burrow into the earth and live in recursive underground dens of complexity 05:32
kurahaupo dukeleto: are those holes sort of like a TARDIS?
dukeleto kurahaupo: what is the $64,000 dollar question? i haven't backlogged
dukeleto has given up on backlogging. i just jump in the river and start swimming 05:33
kurahaupo: have you split the test file up?
kurahaupo: into foo-old.t and foo.t ?
kurahaupo dukeleto: sounds like a good idea, which I've kindof done but probably not in the way you mean. 05:34
The 0.064 million dollar question is: given that "add" autopromotes an Integer PMC to a BigInt PMC, but neg and abs don't, how should I fix it? The old bigint.t tests for the former but not the latter. 05:35
chromatic Add TODO tests for the latter and we'll see how they look. 05:37
dukeleto kurahaupo: add tests, like chromatic says 05:38
kurahaupo: if you want to write tests in PIR, svn copy a file called bigint-old.t, then make bigint.t the new, PIR tests
kurahaupo: that way you don't have to translate all tests at once 05:39
kurahaupo: t/op/inf_nan.t is a good example for how the PIR test should look
kurahaupo: an then send an email to parrot-dev, giving the link of the trac ticket that the patch is attached to, and ask what the proper behavior should be 05:40
then allow the proper amount of bike-shedding, and then make the tests Just Do The Right Thing That Everyone Agrees On 05:41
easy, huh ?
kurahaupo piece of gateau.
I like the idea of introducing the PIR tests a few at a time -- I'm only at line 400 of 1200 so far; I hope nobody mods the file before I can get it checked in! 05:42
05:46 fperrad joined
dukeleto kurahaupo: we will hit them with a big stick 05:49
kurahaupo: definitely submit a patch of what you have so far, so that we can tell you if you are on the right track 05:50
kurahaupo: you can always overwrite the patch on the trac ticket with the newest version of the patch
kurahaupo: incremental translation was needed, because nothing was getting done, since translating an entire file at a time is a huge undertaking 05:51
kurahaupo: look for other *-old.t files for tests which need to be translated to PIR
06:07 bacek joined
bacek o hai 06:09
JimmyZ helloooooooooooo. 06:10
dalek rrot: r42395 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] pge allows multi source files
 06:14
JimmyZ whiteknight? 06:27
purl it has been said that whiteknight is mailto:wknight8111@gmail.com or the grand master funk or wknight8111.blogspot.com/
dalek rrot: r42396 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] step 'test' try first to run 'perl t/harness'
 06:31
06:37 TiMBuS joined
dalek rrot: r42397 | fperrad++ | trunk (2 files):
[library] improve variable interpolation
 06:37
dukeleto bacek: good localtime() 06:44
bacek: thanks for those links to realtime gc algorithms, there is really cool stuff going on there
bacek: i am concerned that parrot on RTEMS will have to turn off the current gc to be actually real-time. 06:45
bacek: but we can support a RTEMS-compatible real-time gc
06:48 mokurai1 joined 07:20 uniejo joined 08:17 mikehh joined 08:24 payload joined, Zak joined 08:26 payload joined 08:55 davidfetter joined, payload joined 08:57 payload1 joined 09:05 payload joined 09:10 payload1 joined
dalek rrot: r42398 | barney++ | trunk/NEWS:
Went over the news for 1.8.0.
 09:14
09:18 AndyA joined
mikehh We are still failing t/src/warnings.t - test : 2 with --optimize on i386 and amd64 with both g++ and gcc- see TT #1187 09:37
I am getting testr failure as well 09:38
bbiab 09:39
10:54 payload joined
bacek dukeleto, we have to properly encapsulate our GC. Then we can provide RT version of it. 11:00
11:22 mikehh joined
dalek rrot: r42399 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
[languages] now works with a Configure.pir or a setup.pir (distutils), instead of Configure.pl.
 11:46
12:00 kid51 joined
kid51 libjit_framebuilder branch: Have spotted one codingstd error. Am in process of testing correction. Otherwise, passes 'make fulltest' on Linux/i386 and Darwin/PPC. 12:02
12:06 payload joined
dalek rrot: r42400 | jkeenan++ | branches/libjit_framebuilder/config/gen/libjit/frame_builder_libjit_c.in:
Correct codingstd error: c_indent.
 12:14
TT #1232 closed by jkeenan++: t/src/warnings.t: Test fails when Parrot built with g++ and --optimize 12:24
12:24 plobsing joined 12:25 nopaste joined 12:32 payload joined 12:52 cognominal joined 12:54 bluescreen joined 12:56 whiteknight joined 13:12 bluescreen joined
whiteknight good morning #parrot 13:20
plobsing morning whiteknight 13:21
whiteknight hello plobsing
I wasn't able to get libjit installed and tested last night before bedtime
13:21 gaz joined
whiteknight I swore I already had it, but I must have lost it at some point 13:22
plobsing that's alright. 13:23
whiteknight no it's not. I should have done it earlier
plobsing so I've been thinking about lorito. If we specify the output of the parser as a tree, we can avoid specifying a language for it for the time being, and I can start hacking away at a prototype 13:28
with a throwaway language
whiteknight it's not just the output of the parser, lorito is supposed to be the way that ops are defined 13:29
right now they are defined in C
plobsing lorito = ops defn + backend
(s)
whiteknight right
plobsing and I'm interested in hacking on the backend
whiteknight each lorito op should correspond in a trivial way to a jittable operation 13:30
ok
so are you talking about the output of the lorito parser?
plobsing yes
and I'll make a makeshift parser
whiteknight okay, but that's where I'm getting confused. if lorito is trivially simple, the output won't be a "tree" 13:31
plobsing but then it'll be a pain to write the ops.
and we want to expose as much of the VM as possible to the JIT, so it makes sense to define it in a structured language
whiteknight the more structure it has, the more parsing effort it takes to JIT it 13:32
plobsing there are already good examples of converting structured languages to JIT
whiteknight how structured are you talking? because ops are already written in C and that's far too high level to be JIT'd efficiently
plobsing not to mention, most JITs operate on a level similar to C operations (eg: store this in such and such an array)
whiteknight we would basically need to write a whole C parser just to do JIT at runtime 13:33
13:33 ruoso joined
plobsing um. no. the JIT is free to store the information about jittable things *in a way that is most conveniant to that JIT* 13:34
so, for llvm, that would be .bc files
whiteknight okay, so that's where my thought process is derailed
plobsing how so?
whiteknight we have .ops files (Written in some language X), gets converted to the JIT-native format at build time, and then the JIT assembles those building blocks together at runtime? 13:35
plobsing that's what I thought we were doing all along.
whiteknight right, so I'm trying to figure out what you think language X should be
because we also need to be able to convert that directly to machine code at build time to support our non-JIT runcores 13:36
plobsing something like C.
whiteknight ok. so how is it like C? same syntax? Same capabilities? etc?
plobsing I was thinking of doing a prototype with pascal (because I have porcupine + libjit's dynamic pascal at my disposal)
note however I don't propose pascal for the final product
whiteknight is that how libjit does it natively, in pascal? 13:37
plobsing no. it has a pascal interpreter
as an example
whiteknight okay
I'm not sure I would recommend pascal as the final product either, especially since that won't work so well with LLVM
plobsing my understanding is that pascal is easier to parse, and operates at a similar level to C, but with a better type system
the better type system ties into the strengths of several VMs, which have better type systems to C 13:38
whiteknight I'm sure the pascal people say that :) Everybody has good things to say about their own product and bad things to say about the competition 13:39
ease of parsing is why I think we need something lower level than C or Pascal
and if we had to decide between the two, something more like C would be better (since our codebase is mostly in C), I think 13:40
13:40 payload joined
whiteknight but, that's just my initial impression 13:41
13:41 tetragon joined
plobsing whiteknight: JIT's are mostly designed to JIT structured languages initially 13:41
structured, static languages
whiteknight I'm not sure I understand what you mean by that
plobsing llvm, libjit, jvm
whiteknight LLVM for instance operates on an assembly-like language natively 13:42
with opcodes and labels
plobsing yes. but there are several projects which use structured, static languages that target it
it does it very well
whiteknight Right, but you still need to parse the structured language into the lower-level representation for LLVM to consume natively 13:43
plobsing and you can do that at compile time
no big deal
purl Yes it is! I hate you I hate you
plobsing the feeling is mutual purl
whiteknight it's been said before that we don't want to maintain our own C parser in the repo. 13:44
I think we can extend that by analogy to anything that's equally high-level
however, since we already have NQP in the repo, it's not unthinkable to use that 13:45
plobsing what is ncigen then? does it not parse C and generate NCI defn's?
whiteknight or, a subset of that
ncigen, I believe, parses a list of simplified signatures only
plobsing oic
README was misleading
whiteknight: I don't think nqp or anything that targets execution on parrot is a good idea. 13:46
whiteknight src/call_list.txt
13:46 payload joined
plobsing no. that's nativecall.pl 13:46
whiteknight oh, then I may be confused
plobsing compilers/ncigen
whiteknight far too many of these stupid little tools laying around 13:47
plobsing whiteknight: my argument for a structured lorito is that it makes it less painful, which means we can use it more extensively
the more extensive our use of lorito, the more the vm is exposed to JIT, and the better we can inline our hot path
whiteknight we aren't against bootstrapping. And we can check in generated files and use them to build parrot from scratch 13:48
plobsing for example, i could imagine all of our pmc's available for inlining
13:48 payload joined
whiteknight or, a two-stage build process where the first stage parrot isn't JIT capable 13:48
plobsing no more vtable lookups in tight loops 13:49
whiteknight and it generates the JIT libraries for the second stage
agreed: vtable lookups and indirect calls get expensive
missed branch predictions, cache misses, etc 13:50
plobsing anyways, I've got to get to $work.
I hope you consider making lorito structured for the reasons I've detailed above. 13:51
13:58 payload joined 14:06 payload1 joined 14:08 payload joined, mberends joined, PerlJam joined 14:48 Austin_away joined 14:57 patspam joined 15:13 bubaflub joined
Essobi whispers 'Anger is a gift.' 15:18
whiteknight not what I want for xmas this year 15:19
15:21 Psyche^ joined
Essobi hahaha 15:21
you're the second person who said that
PerlJam I'll take anger for xmas ... i'll just regift it :) 15:22
15:23 cognominal joined 15:30 redbrain joined
redbrain bbredbrain: status 15:31
bbredbrain Debian-ARM-Feroceon: offline
Debian-PPC-G5-test: idle, last build 2h16m56s ago: build successful
Debian-UltraSparcII: idle, last build 2h05m05s ago: failed test
Debian-x86-test: idle, last build 2h31m40s ago: build successful
purl Since Wed Oct 28 01:13:35 2009, there have been 2542 modifications and 1287 questions. I have been awake for 13 days, 14 hours, 17 minutes, 6 seconds this session, and currently reference 809289 factoids. Addressing is in optional mode.
whiteknight impressive
redbrain some bsd comming soon :)
whiteknight redbrain++
redbrain might be some weeks though becasuse i have some work to do and want to get back to playing around with parrot :) 15:32
crules.org:8010/builders/Debian-Ult...s/warnings
whiteknight hey, no rush. You need to be having fun too :) 15:34
I wonder what all those casting problems are caused from
redbrain thanks its kind of cool isn't it though going to setup some buildbots for my programming language project too ...eventually :P 15:35
NotFound Are you talking about making lorito a language even more complex than pir? I've supposed that the idea was just in the opposite direction. 15:36
whiteknight NotFound: That seems to be plobsing's idea, yes 15:37
and I have to admit that I am swayed by it
PerlJam making lorito more complex than pir? 15:38
redbrain anyways i'll be back later going to make some lunch :)
NotFound If we talk seriously about using a pascal-alike language for writting ops, I'll just quite the project.
Seriously.
purl I'm totally freaking serious.
15:45 payload joined
whiteknight It wouldn't be pascal 15:47
if we were going to use a language of that level, it would be C
which raises the prospect, what if C *was* lorito?
LLVM is certainly capable of compiling C down to LLVM bytecode
redbrain are you redesigning pir?
whiteknight and all we need at runtime is just that bytecode, we don't need to do any parsing at runtime 15:48
NotFound I think the intention of a lot people was mainly to avoid the need to use C in lots of places.
whiteknight redbrain: bnot really. We're adding a new abstraction layer "Lorito" that will nicely interface PIR with a JIT engine
at the moment, PIR is not easy to JIT
NotFound: yes, true. But if it means we don't need to rewrite everything, that might be a benefit 15:49
NotFound At the moment, pir mostly works. Something that a lot of proposals seems to not care about.
whiteknight NotFound: what do you mean by that? It does work, but I don't think it's ideal
redbrain i was talking to llvm guys few weeks ago and they were saying if you have like a runtime with a basic switch loop and you turn the runtime functions into a library you can compile it with llvm-gcc so you turn it into bytecode which llvm does the jitting for you because apartently there is some trick with linking against it
NotFound whiteknight: talking about writing a full C compiler is fantasy. 15:50
redbrain NotFound: yeah very true my first experience with compiler stuff i started writing a basic c-compiler it worked but only for very limited subset of c
whiteknight NotFound: I disagree. We don't need a full C compiler, just whatever subset the ops use
but that's not even the issue, LLVM *is* the C compiler 15:51
we use LLVM to compile the .ops files to bytecode, and then use LLVM at runtime to JIT them
so if Lorito is C, all the ops are already written in Lorito and we already have a Lorito compiler 15:53
NotFound whiteknight: try to compile any .pbc file with a limited subset of C.
whiteknight NotFound: we don't compile .pbc files. it's a two-stage process 15:54
we compile C files to LLVM BC files. Then we use the PBC to lookup functions in the BC file, combine them together into methods, JIT them, and execute the machine code 15:55
it's the same way we use .pbc files to lookup functions in the Fast Core 15:56
NotFound What's a BC file?
redbrain yeah thats quite cool :)
whiteknight "BC" is my shorthand there for "LLVM Bytecode"
15:57 AndyA joined
NotFound So the plan is to us full embrace LLVM? 15:57
whiteknight That's what Allison said, yes
redbrain even though llvm is beast its probably the safest option since its activly developed etc 15:58
whiteknight libjit is active too
but that's neither here nor there, really
LLVM does come with an impressive suite of tools 15:59
And there are good possibilities for Parrot to integrate closely with LLVM
pmichaud #ps in 150 16:00
redbrain yeah good point
NotFound I'm not against using LLVM or any other platform, but I supposed we pretending to be plaftorm independent.
moritz is there any platform parrot runs on and llvm doesn't? 16:01
whiteknight I have been arguing for JIT engine independence, yes
LLVM I think is shakey on Windows
but in development
I think the goal is that Parrot will run everywhere, but if we have LLVM too it will just be faster 16:02
redbrain i always wondered how do things like llvm or libjit handle like multi threaded apps wanting to access the same jitted function etc 16:03
NotFound I think if we are going to a way like that, we can also consider targeting jvm, or cli. 16:04
whiteknight I'm not sure JVM or CLI provide any benefits to Parrot
NotFound whiteknight: same for llvm
whiteknight LLVM gives us JIT and AOT
and it gives us those things without additional overhead 16:05
A translator from PBC -> CLI would be interesting, but not really a benefit
NotFound whiteknight: you seems to assume that that means speed and some other benfits, but I haven't seen any proof of that.
16:06 darbelo joined
whiteknight NotFound: you need proof that JIT brings speed benefits? 16:06
NotFound whiteknight: yes.
16:07 fperrad joined
NotFound Our previous JIT is a good counter example. 16:07
whiteknight our previous JIT was not a real JIT
and didn't do anything that a good JIT does
NotFound whiteknight: and we can't say same about our future JIT, beacause it doesn't exist.
whiteknight look at projects like smalltalk, or unladen swallow which is approaching 5x speedups
NotFound: We're desiging our future JIT right now. We're desigining it to improve speed 16:08
darbelo IIRC the JIT removal gave us a ~1% speed improvement, by virtue of the struct pruning.
just to give NotFound more ammo.
whiteknight it's not the same thing. Our old JIT wasn't a real JIT
you can't compare it to LLVM
NotFound whiteknight: give me the resources of google and I buy you at least a 10x speed improvement ;) 16:09
whiteknight And, our old JIT *did* improve runtime performance
it wasn't much, but there was a measurable improvement with it
especially when combined with cgoto and PIC
I don't have the numbers handy
NotFound whiteknight: at the cost of an immense lose on developpers time and patience. 16:10
whiteknight NotFound: no question.It wasn't good. But it was a performance improvement
and a real JIT will be a bigger improvement without draining developers
NotFound I don't buy at that cost.
darbelo whiteknight: The frame builder gives more bang for the buck 30% on start up time. vs I don't know 5% at runtime? 16:11
whiteknight the frame builder is a special case. There are direct tradeoffs to be made 16:12
A "smart" frame builder would precompile stubs used by Parrot internally, and delay others until runtime
but we're still early in that development 16:13
We got rid of old JIT for a reason, and are replacing it for a reason. We expect improvements 16:14
darbelo True. Hm. Speaking of that. I think plobsing's branch is ready to merge, have you looked at it? 16:15
whiteknight I tried last night but ran out of time 16:17
will tonight, if nobody beats me to it
darbelo I looked at it, but I'm hardly a domain expert. 16:19
NotFound Don't take me too seriously, I'm in a bad mood because of dayjob things.
szbalint Function aware (as opposed to simplistic op dispatch) JIT in today's world is a necessity, so that a. you don't have to go microoptimizing things for mediocre performance b. to counterbalance the encapsulation penalties c. to be fast enough as a platform for implementing languages on top of. As far as I know the old JIT implementation was quite op specific and didn't do anything about the C/PIR barrier crossings that take up a lot of the execution time... 16:20
redbrain yeah to be honest jitting is somethin i need to learn more about but i am still not convinced it will beat a really well cleanly written runtime because the amount of code to manage the jit and dispatching is an overhead 16:25
though i still think jitting is a good idea
since it gives many more possibilties
NotFound szbalint: however people keeps using perl, python, and other languages old versions without any jit.
And even non jitted jvm's 16:27
szbalint yes, that's why I said a., for Perl 5
NotFound Perl 5 works. Many teoric better designed projects don't. 16:29
dalek rrot: r42401 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add getenv/setenv OS utilities
 16:30
16:32 Zak joined
dalek a: 4ec9b26 | fperrad++ | t/object.t:
untodo a test
 16:33
a: e81e58d | fperrad++ | setup.pir:
add custom targets
whiteknight redbrain: JIT is a tradeoff: increased startup time (compilation) in exchange for improved performance over the life of the program 16:39
for short programs it's useless, but for longer programs the costs amortize over time
if we use a trace-based approach, we can determine where the biggest gains are, and only compile critical paths to save on startup time 16:40
redbrain whiteknight: yeah thats the thing thats been in the back of my mind :P, though i find it head bending as in what can you jit do you compile the program basicly or jit bits and pieces as they are called throughout the program managing that seems quite hard 16:41
NotFound whiteknight: I've been hearing for years people saying that with that approach java, or cli, will beat C. I've failed to see demonstrations.
whiteknight yeah, that's true. It's hard to keep track of everything
NotFound: it's never going to beat C. Anybody who says that doesn't know what they are talking abou 16:42
redbrain and what happens if your calling un-jitted libraris etc tbh i wouldn't know where to start and then how do you jit the only thing i can think of doing it is building some kind of shared library with the jitted functions and call it with dlsym functions
whiteknight A VM+JIT will be a normal VM though. I can find lots of examples to prove that
szbalint NotFound: Perl 5 works on top of 15 years worth of optimizations and XS, and if you want reasonable speed you're using XS.
whiteknight redbrain: it's simple. At the machine code level we just jump control flow to the entry point of the library. JIT can do that very easily 16:43
JIT isn't some magical process: It's just a normal compiler that compiles code down to normal machine code
NotFound szbalint: and other approaches work on... They work? 16:44
redbrain yeah that makes more sense but if your generating machine code can you literly ./jittedprogram ? :P
whiteknight the magic comes from doing the compilation lazily at runtime
redbrain: yes, that's a possibility. AOT (ahead-of-time) compilation can be used to convert our bytecode down to native optimized executables
szbalint NotFound: you mean that you're doubting whether JIT for Parrot could work? 16:45
whiteknight ...which would use the same mechanism at JIT, just writing the machine code to a file instead of executing it
NotFound whiteknight: that is one of the things I dislike. A trend to think that we just switch to using some jit library, and magically all will be beautiful.
szbalint: We don't have a JIT that works. That is a reality, not a belief. 16:46
whiteknight NotFound: no, it's definitely not that simple. There are modest gains to be had from a naive approach
but the real gains come from deeper integration with the JIT engine, and complex algorithms built on top of JIT
redbrain whiteknight: wooo thanks very much i think i see how that works properly now i tried starting a thread on comp.compilers some time ago on this got quite interesting compilers.iecc.com/comparch/article/09-07-079 i built a basic jit for some small functions like + / ... but i just generated x86 code and turned it into a shared library i could call with dlsym and i knew this couldnt be the right way to do it :) 16:47
whiteknight nice! 16:48
szbalint NotFound: As far as I know there isn't any JIT in Parrot atm, so it can't have any properties. Worthwhile JIT has been done elsewhere with good results, so _building_ one is in the realms of possibilities
whiteknight JIT is very hard to do properly. That's why we would rather use a good existing one then try to create our own 16:49
NotFound szbalint: "not work" is not a property, is the absence of a property. A non existent thing obvoiusly don't have that property.
whiteknight let's not digress into an argument about the philosophy of being 16:50
szbalint indeed
NotFound And I don't dount that is possible and interesting to work on a JIT. I doubt that we must fully commit to one that isn't ever designed.
s/ever/even 16:51
whiteknight Here are the facts: (1) Parrot does not have a JIT right now, (2) Parrot has less-than-optimal performance right now, (3) JIT has been demonstrated to improve performance in other VMs
NotFound: I think it is getting designed quite well. We still have lots to discuss though 16:52
a lot of it needs to be put on paper eventually
NotFound To be burnt? ;) 16:57
NotFound is the Spanish Inquisition 16:58
szbalint I don't find you unexpected.
darbelo hides his books. 16:59
17:01 theory joined, kj joined
NotFound Thinking about the philosophical point... Is possible to set a property on PMCNULL? 17:02
darbelo hopes not. 17:05
NotFound Answer: no. Null uses his vtable defaults of throwing.
whiteknight we can try to test it. I assume not
17:23 Andy joined 17:38 bubaflub joined
kurahaupo regrets UTC+13 and ponders the necessity for sleep which keeps him away from interesting discussions about JIT 17:40
dalek rrot: r42402 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] revert the :anon logic.
 17:41
17:42 allison joined
kurahaupo good morning Allison 17:43
s/morning/$localtime
dalek lscript: ed47d61 | fperrad++ | setup.pir:
improve readability
 17:45
lscript: aa9c056 | fperrad++ | setup.pir:
clean up
purl well, clean up is a breeze
darbelo ps in ???
dalek rkdown: 29d36d7 | fperrad++ | setup.pir:
code tidy
moritz 44
date --utc is very helpful ;-)
dalek l: 91aa291 | fperrad++ | setup.pir:
code tidy
 17:47
darbelo I know what time it is. I wasn't sure if ps was synched to a clock or the sun.
;)
17:51 iblechbot joined, mokurai joined, barney joined
dalek a: f7bbc12 | fperrad++ | setup.pir:
build Lua libraries in a custom step, after the build of the Lua compiler.
 17:51
17:55 mikehh joined
whiteknight will miss part of #ps today 17:56
whiteknight will try to backlog
17:57 payload joined
allison kurahaupo: good morning 17:59
kurahaupo has to leave for $DAYJOB[0]; $DAYJOB[1] =~ s/work/UMTS seminar/ 18:02
diakopter initially read 'seminary' there 18:03
bubaflub any seminary fans here? 18:04
diakopter guesses that any wouldn't answer that question.. 18:10
darbelo isn't religious enough to enter a seminary. 18:11
18:16 chromatic joined
bubaflub fair nuff. loaded quesiton. 18:17
18:18 whiteknight joined, pdcawley__ joined
whiteknight allison: I don't see the AllisonTasklist page on the wiki 18:24
18:26 ilia joined
allison whiteknight: do you see it now? 18:26
whiteknight: (it looks like I kept hitting "Preview" but not "Save")
whiteknight ah yes, it's there now
pmichaud I have that problem too.
I keep hitting Preview and then later wonder "where did my page go...?"
allison whiteknight: my 'f' key is dying on this laptop too, need to fix that 18:27
pmichaud doesn't that make it harder to swear? ;-)
dalek tracwiki: v1 | allison++ | AllisonTasklist
tracwiki: trac.parrot.org/parrot/wiki/Alliso...ction=diff
whiteknight uck no it doesnt 18:28
allison pmichaud: it does kind of take the orce out of "uck" :)
diakopter kind o, even 18:29
allison diakopter: aye, tryin' out me luck o the irish 18:30
dalek tracwiki: v2 | allison++ | AllisonTasklist 18:31
tracwiki: trac.parrot.org/parrot/wiki/Alliso...ction=diff
cotto_work #ps in -1
allison cotto: thanks
cotto_work www.makinggoodsoftware.com/2009/11/...developer/ 18:37
18:37 hudnix joined 18:40 mokurai left, mokurai joined
moderator Parrot 1.7.0 "African Grey" is out! | Testing hackathon November 14 and 15 -- improve opcode coverage | find out what's up with the slice opcode | Latest modified TT's: icanhaz.com/parrotbugs 18:41
dalek tracwiki: v3 | allison++ | AllisonTasklist 18:41
tracwiki: trac.parrot.org/parrot/wiki/Alliso...ction=diff
tracwiki: v4 | allison++ | AllisonTasklist 18:44
tracwiki: trac.parrot.org/parrot/wiki/Alliso...ction=diff
chromatic cotto_work, it's from last Thursday, entitled "List of possible rakudo needs from Parrot" -- I can forward if you don't have it. 18:47
cotto_work just found it
18:59 whiteknight joined 19:01 AndyA joined
whiteknight I hadn't ever even heard of libffi 19:02
dalek tracwiki: v1 | cotto++ | RakudoTasklist
tracwiki: initial version from pm's parrot-dev post with some formatting adjustments
tracwiki: trac.parrot.org/parrot/wiki/Rakudo...ction=diff
19:02 AndyA_ joined
whiteknight but it looks very interesting from what I see 19:02
cotto_work It looked promising from what I could tell. 19:03
whiteknight dukeleto: didn't we already have a Kea project on Parrot somewhere? 19:05
chromatic There's a Kea-CL, I think.
whiteknight maybe that's what I'm thinking of 19:06
and when is this testing hackathon going to be? (needs to be advertised on the wiki) 19:07
cotto_work Should the bitwise ops->dynops migration be marked as a milestone? 19:08
chromatic November 14 and 15, whiteknight.
whiteknight w00t 19:09
19:09 ilia joined
bubaflub should i just hangout here to help out with the hackathon this weekend? 19:10
dukeleto whiteknight: kea-cl seems to be defunct
whiteknight: and kea != kea-cl :)
whiteknight gotcha, it was a very fuzzy memory 19:11
Austin Is there any chance of getting a better diagnostic message from the C3 linearization subsystem?
whiteknight Austin: what kind of diagnostic?
dukeleto whiteknight: kea is a mountain parrot that occasionally feeds on sheep. or velociraptors...
cotto_work: did someone say dynops?
Austin *Any* would be nice. Currently, I get 7"Could not build C3 linearization: ambiguous hierarchy" on a class with essentially one parent. 19:12
chromatic bubaflub, that would be great.
dukeleto has anyone benchmarked the speed difference between a plain op and a dynop?
Austin coughs.
Dukeleto, I could have sworn you just asked about benchmarks.
dalek tracwiki: v6 | whiteknight++ | AllHackathons
tracwiki: add info about testing hackathon this month
tracwiki: trac.parrot.org/parrot/wiki/AllHac...ction=diff
dukeleto Austin: ?
Austin If you can't do it with "helloworld.pir" or "fibonacci.pir" and a sandglass, it isn't done. 19:13
chromatic Any measurable difference would surprise me.
bubaflub chromatic: is the hackathon primarily focused on getting tests converted to PIR? anything homework i should have done (besides a functioning build of parrot from trunk) before the weekend comes?
Austin :-(
chromatic bubaflub, converting tests to PIR will be good. I'd like to increase test coverage of opcodes as well. 19:14
A working build and some familiarity with PIR and our test layout should suffice.
bubaflub cool. i'm not too familiar with opcodes. any recommended reading?
whiteknight testing hackathon is on the wiki and on the calendar now
dukeleto Austin: i do lots of parrot benchmarks, have you not seen them? 19:15
chromatic docs/overview.pod is a good place to start.
Austin Whiteknight: I declared a class in NQP ("class Kakapo::Test::Undef") and then tried to add an existing class ("Testcase") as a parent using the P6object calls (add_parent). Naturally, it blew up. (??!) But I have no idea why, since the only diagnostic is "ambiguous hierarchy".
dukeleto bubaflub: you want to hack on dynops? Bring me a broom.
whiteknight Austin: so you want a printout of the hierarchy? 19:16
Austin dukeleto: I have not. Where are they?
whiteknight: That would be spectacular. Or an explanation of which two classes were in conflict, or something.
whiteknight gotcha
dukeleto Austin: here is an example that I sent to p5p: www.xray.mpe.mpg.de/cgi-bin/w3glimp...tml?49#mfs 19:19
Austin dukeleto: Looks great! Can we somehow get that added to parrot? "make bench" or something? 19:21
I tried to do some opcode benchmarking, and came up against the imcc O(N^2) limit.
dukeleto Austin: it has perl 5 cpan module deps right now, but we can attempt to write it in PIR/NQP if we want 19:22
chromatic Austin, benchmark PBCs instead.
Austin Chromatic: Thanks for the tip. Why do you suppose I was running imcc?
dukeleto tool_bench is the rewrite of euler_bench that is not tied to the euler project problems
Austin dukeleto: Why don't we just eat the cpan deps?
What are the euler project problems? And if tool_bench is the "way forward," does it work yet? 19:24
whiteknight i would like to have a more comprehensive suite of benchmarks 19:25
cotto_work dukeleto, I wouldn't expect much of a penalty for dynops apart from the time it takes to load them.
chromatic Austin, I'd only run IMCC if I wanted to benchmark the parsing cost of dynops.
Austin seen bacek?
purl bacek was last seen on #parrot 8 hours, 24 minutes and 46 seconds ago, saying: dukeleto, we have to properly encapsulate our GC. Then we can provide RT version of it.
Austin chromatic: So how do I compile pir down to pbc? 19:26
whiteknight it may be good practice to write a benchmark that targets a particular subsystem before we do any performance-related work to that subsystem
dukeleto cotto_work: that is what i would want to benchmark. but also to verify that they do not incure a large run-time cost, for some unknown reason
chromatic ./parrot -o output.pbc input.pir
dukeleto whiteknight: i really like that idea
cotto_work dukeleto, That's certainly a good idea. I'm all for sanity checks.
Austin chromatic: Perhaps I'm confused, but isn't that running imcc?
(Because that's what I always do to compile pbcs) 19:27
whiteknight dukeleto: so first goal might be a benchmark that exercises the hell out of PCC
darbelo Austin: Yes, but runing the pbc is IMCC-free 19:28
NotFound If you want to absolutely avoid imcc code you must embed, because parrot main calls imcc_main
darbelo Austin: for some values of IMCC-free
chromatic You avoid IMCC's big-O blowup there.
By running the PBC directly, I mean. 19:29
Austin darbelo: My problem lies in the effort to get from pir to pbc. I generated a fairly long pir file mechanically, and then tried to compile it.
dukeleto whiteknight: so do fib.pir and primes.pasm *not* excercise the hell out of pcc?
whiteknight: how do we properly excercise the hell out of pcc?
whiteknight dukeleto: maybe they do. if so, we can evaluate that 19:30
a good PCC benchmark probably has a few phases: lots of sub calls, lots of method calls, lots of tailcalls and method tailcalls, lots of closures, etc
darbelo Austin: I guess you are in trouble then. I don't think anyone here is willing to invest the time to knock an exponent off IMCC's O()
Austin Actually, I was wondering about generating the pbc directly. 19:31
From what I recall, Bacek had something working in the pbc generation space.
darbelo That was a way for pir programs to emit pbc. 19:32
Austin Works for me.
I'll have to get with him and find out. 19:33
darbelo Austin: If you want pir -> pbc it doesn't help you.
Austin darbelo: I want ->pbc. My benchmarks are of the form "repeat this set of opcodes 10,000 times". I can write that in nqp. 19:34
(For somewhat large values of 10,000, ideally.)
19:34 desertm4x joined
NotFound Austin: Maybe a exponential chain of macros can be parsed easily by imcc? 19:36
treed Anyone have tips for having one git-svn repo that you use on two machines? 19:37
(rsync or whatever)
cotto_work easy karma for someone who wants to add a note to DEPRECATED.pod for trac.parrot.org/parrot/ticket/1260
Austin NotFound: AFAICT, the problem lies in the symbol table. Per chromatic, it is a common table, searched linearly.
treed Apparently you can't really do it with normal git operation.
chromatic Searched linearly several times, some of them in nested loops.
Austin :) 19:38
dalek TT #1260 created by cotto++: [DEPRECATION] bitwise ops and VTABLE functions
Austin We have a winnah!
treed: I'd recommend putting the two machines on the git side of that equation.
chromatic cotto_work, are you handling the wikification of Patrick's message? 19:40
darbelo purl: msg plobsing Can you submit a CLA to the PaFo so we can get you a commit bit?
purl Message for plobsing stored.
cotto_work chromatic, it's under RakudoTasklist 19:41
darbelo purl: msg plobsing See www.parrot.org/files/parrot_cla.pdf
purl Message for plobsing stored.
chromatic Thanks, cotto_work. 19:42
nopaste "NotFound" at 213.96.228.50 pasted "Austin: something like that" (48 lines) at nopaste.snit.ch/18629
cotto_work also, someone should update DEPRECATED.pod to match trac.parrot.org/parrot/ticket/866 . I just updated it to deprecate only the VTABLE functions mentioned in the tt. 19:46
Austin NotFound: Any way via macro do generate a unique label? 19:48
*do=to
whiteknight Austin: none that I am aware of 19:49
purl i already had it that way, whiteknight.
NotFound Austin: I think is a feature that never worked.
Austin :)
whiteknight dukeleto: where are fib.pir and primes.pasm?
treed Austin: Sure, but I tried setting one as a remote of the other and push/pulling, but weird things happened that may be related to git-svn. I think it's recommended that you not push/pull git-wise when dealing with git-svn.
dukeleto whiteknight: examples/benchmark
NotFound But my trick is nice, anyway ;) 19:50
whiteknight ah right, I was looking in t/benchmark for some reason
Austin Yeah, it kind of blows up on repeated labels. 19:53
darbelo Austin: I've never used it, but I think the packfile PMC can do what you want.
Austin Can I say "unless_null foo, +3" or something?
cotto_work Austin, that works
NotFound Austin: but if local label worked, surely you'll have the problem with the symbol table.
cotto_work (iirc) 19:54
Austin NotFound: That's what I was going to test.
How big is "$P11 = new [ 'Undef' ]"?
darbelo one opcode.
Size of the opcode? You don't want to ask. 19:55
Austin Looks like "3"
chromatic Three, but the third is a reference to a constant. 19:56
19:56 joeri joined
Austin Sure, but the 3 is for a branch offset. 19:56
whiteknight primes.pasm doesn't appear to call any functions 19:57
chromatic primes.pasm is about math, PMC, and opcode dispatch.
whiteknight fib doesn't call nearly as many as I am thinking of, and not with multiple types of signatures 19:58
chromatic: right
I want a benchmark that pushes PCC to the limit
Austin Hmm, it still takes a while.
cotto_work chromatic, could you do a quick sanity check on TT #1260?
whiteknight a quick loop that makes 100K function calls would be a good start
Austin Do we have the source code to that url-rewrite bot that was here for a while?
whiteknight something similar with permutating argument lists would be very nice 19:59
chromatic fib.pir recurses a lot.
Austin Because rewriting TT#1111 as a trac.parrot.org url would be a good service.
whiteknight chromatic: that's a step in the right direction, but not nearly so comprehensive as I think we need
darbelo Austin: The web irclog does that.
whiteknight if we want to improve PCC performance, we need a comprehensive way of measuring that
chromatic It's sane to me, cotto_work.
Austin That's cool.
cotto_work Thanks chromatic. 20:00
whiteknight fib.pir makes one type of sub call: I->I
chromatic I agree we need more comprehensive benchmarking, but I focused on fib.pir because we're never going to get any faster than that type of sub call at its slowest.
whiteknight fair enough
I would like to know what the relative speed differences are between named and positional parameters, for instance 20:01
or how expensive it is to do :slurpy and :flat args
20:16 patspam joined
NotFound The PackfileAnnotations PMC does not have METHOD type. This is intentional? 20:19
chromatic Where would you expect it? 20:20
20:20 theory joined
NotFound All other derived of PackfileSegment, except directory, have it. 20:20
And if you want to be able to query the type of a directory entry, you need it. 20:21
dukeleto whiteknight: what about oofib.pir ? 20:22
whiteknight: i hear what you are saying, you want benchmarks for different calling conventions. i don't think we have that right now
whiteknight speaking of benchmarks, I would like to get some setup for parrot-linear-algebra eventually 20:25
especially being able to compare timings between BLAS calls and pure-PIR versions of the same algorithms 20:26
chromatic Perhaps we should benchmark some NQP-rx examples.
That'll give us some concrete numbers to help Rakudo and other HLLs.
dukeleto whiteknight: i can do some PLA benchmarks with euler_bench for you. let me know what you want. 20:27
chromatic: we definitely need nqp-rx benchmarks. it got a lot slower to compile. i hope it got faster to run.
whiteknight what is euler-bench?
dukeleto whiteknight: euler_bench is what i use to benchmark parrot, currently 20:28
whiteknight ok. What does it do?
dukeleto whiteknight: it is being rebranding tool_bench, but that is still being written
whiteknight or, where is the code?
purl somebody said the code was already out
dukeleto whiteknight: www.xray.mpe.mpg.de/cgi-bin/w3glimp...tml?49#mfs
purl, euler_bench?
purl i heard euler_bench was what i use to benchmark parrot, currently
dukeleto purl, forget euler_bench 20:29
purl dukeleto: I forgot euler_bench
dukeleto purl, euler_bench is github.com/notbenh/euler_bench and what dukeleto uses to benchmark parrot
purl dukeleto: i don't know
dukeleto purl, euler_bench is github.com/notbenh/euler_bench
purl OK, dukeleto.
dukeleto purl, euler_bench is also what dukeleto uses to benchmark parrot 20:30
purl no idea, dukeleto
dukeleto purl, die in a fire
purl HALP
diakopter purl, euler_bench is also that which dukeleto uses to benchmark parrot
purl okay, diakopter.
whiteknight github down 20:33
purl yes
whiteknight github up?
diakopter purl, github down is true
purl ...but github down is <reply>yes...
diakopter purl, github up is true
purl OK, diakopter.
diakopter purl, no, github up is NEVER 20:34
purl okay, diakopter.
diakopter github up?
purl github up is, like, NEVER
diakopter purl, no, github up is <reply>NEVER
purl okay, diakopter.
diakopter github up?
purl NEVER
diakopter heh
darbelo purl: github? 20:35
purl github is a repository-centric social network for hackers where $friending eq $cloning_a_repo -- github.com/ or a cocoaruby interface to git : github.com/Caged/gitnub/wikis/home or really nice or a good place or neat enough to take nperez's tags ands tarball them up for me
chromatic dukeleto, I think a recent CodeString commit fixed parsing time. (Variable-width string encodings are evil.) 20:36
whiteknight gitorious? 20:39
purl gitorious is getting a lot of work atm, it seems.
20:41 jan joined
whiteknight I like the angry-looking unicorn that is the github error page 20:41
and i especially like how they say to check twitter for status updates, but that hasn't been updated since the 7th 20:42
cotto_work At least you know there'll be a writeup once they get it fixed.
dukeleto #github on freenode is the best way to get ahold of the github guys 20:43
whiteknight meh, I don't care enough to join another irc network 20:44
darbelo purl: fleanode?
purl i don't know, darbelo
darbelo So useless sometimes... 20:45
whiteknight purl isn't useless! 20:46
we could use her to weight down papers in a drafty room
darbelo whiteknight: Electronic bits don't weight.
japhb darbelo, sure they do! Just very, very little. 20:47
20:48 bacek joined
dukeleto whiteknight: irssi can be connected to as many networks as you need :) 20:48
darbelo: irc.freenode.net
purl irc.freenode.net is home of the mirror universe #perl that isn't full of assholes. or where you can find a #perl that's supposedly actually got something to do with perl
20:48 mikehh joined
darbelo japhb: I study engineering. Too small to measure := doesn't exist ;) 20:49
japhb whiteknight, plobsing: Saw this a couple days ago, kept forgetting to link it here: blog.vlad1.com/2009/11/06/canvasarr...nvasarray/
darbelo, you just need vast quantities, that's all. :-) 20:50
dukeleto chromatic: i am interested to see if parsing time is noticeably faster
darbelo: get a smaller epsilon :)
darbelo japhb: Too large to fund == Doesn't exist either. 20:51
;)
20:51 bubaflub joined
japhb whiteknight, plobsing: The above link is about how the WebGL people are dealing with NCI where you will be filling, modifying, and reading fast arrays of (sometimes mixed) native types. They essentially separate the concept of a raw buffer and a type mapping into a chunk of that buffer. You can have many type mappings into the same buffer, but those type mappings act as if they were just arrays of the proper type. 20:53
darbelo dukeleto: Oh, I know where fleanode is, I just wanted to know what purl had to say about it.
japhb darbelo, Funding really large things just requires using some of the creative math during the proposals that you'll end up using on the project itself ... 20:54
dukeleto darbelo: i see, says the blind man 20:55
japhb "... as he spit into the wind -- 'It's all coming back to me now.'" 20:56
dukeleto japhb: i like that! 20:57
whiteknight dukeleto: chatzilla can be connected to other networks too. I don't care, not gonna do it. Too lazy 20:58
dukeleto whiteknight: alrighty then.
whiteknight never underestimate the force of laziness
japhb whiteknight, if you're lazy I'm a can of pickles.
dukeleto whiteknight: i am on too many channels anyway. you don't want to go down the path of >20 irssi panes 20:59
whiteknight on my personal laptop I have xchat setup to open ~20 channels on startup 21:00
but here at work, I'm not able to keep up with all that crap
so I don't
japhb: That's a very interesting link. I wonder if/how we could apply that to Parrot-Linear-Algebra
japhb: I would be very happy to setup any types that you need for OpenGL, of course 21:01
dukeleto yes, PLA seems like a good place to put types that OpenGL needs
whiteknight PLA is really focusing on fast 2D data buffers 21:02
japhb Just being able to get a pointer to the raw buffer (as opposed to the array object header) would be nice.
whiteknight the numeric ones have bindings to BLAS, but you don't need to do that
japhb: I could set up get_pointer for that purpose 21:03
does OpenGL need a float array, or an integral one?
dukeleto whiteknight: i would assume both
whiteknight yeah, but I want to ask before I start throwing shit together haphazardly
japhb whiteknight, yes. :-) Part of the interest of that article I linked is that very often you need a mixed type array, or a single large buffer with multiple type blocks within it.
I know that may be outside of the bounds of PLA, 21:04
whiteknight japhb: we have a PMCMatrix2D type which does that
japhb but something to think about.
The other thing (longer term) is being able to lock memory that's being handed off to the video driver.
whiteknight doesn't acheive the same separation between data/metadata though
japhb nodnod
whiteknight lock memory? what do you mean by that? 21:05
write-protect it?
japhb keep it from being paged out.
or gc moving it to a new location
whiteknight oh, and how would we accomplish that?
darbelo whiteknight: With a very clever method you will devise.
whiteknight you know what would be really hot? Passing databuffers off to the GPU for fast vectorized mathematical processing 21:06
japhb mlock?
whiteknight, POGL began working on that a few years back.
whiteknight when we lock it is it write-protected?
japhb Had some basics working on that to, but then he got a job taking all of his tuits. 21:07
whiteknight, well, that's mmap then
whiteknight japhb: I'm trying to figure out what you need and what you mean by "lock"
japhb whiteknight, two thingsL
1. OS told not to page the memory out to swap. 21:08
2. GC told not to move the buffer.
whiteknight Okay, that should be simple then
what would you need first? FloatMatrix or IntMatrix? 21:09
or something entirely different?
japhb FloatMatrix is most valuable. 21:10
NotFound allison: ping
dalek TT #1261 created by NotFound++: Document NCI type 'p' behavior for PMCNULL/NULL values
whiteknight japhb: okay
japhb Not everything, but *most* GL functionality can use float as a fallback type, just possibly slower than the "native" type for the operation
Number two most valuable is actually byte arrays -- for color buffers/textures. 21:11
And then at the third tier you get into wanting everything else.
allison NotFound: pong 21:12
NotFound allison: what dalek just said
whiteknight japhb: Matrixy has need of a char buffer for it's weird string handling 21:13
so that type will be forthcoming
21:14 bluescreen joined
allison NotFound: looking... 21:14
whiteknight anyway, I have to pack up and go. Later
japhb fperrad, backloggin #parrotsketch I notice you saying you wanted to "fix Plumage on Windows" ... um, what's not working? I thought we had everything resolved ...? 21:15
NotFound japhb: we must fix Windows X-)
cotto_work NotFound, MS have been trying that for years.
NotFound cotto_work: you sure? ;) 21:16
fperrad japhb, not all solved, but we made some progress
japhb NotFound, first, go back in time. Second, hire an operating system architect with taste.
fperrad, OK. What's still broken? 21:17
dalek rrot: r42403 | pmichaud++ | trunk/runtime/parrot/library/P6object.pir:
[p6object]: Make add_parent smarter about adding HLL-specific method types.
japhb fperrad, now that I can pass for moderately healthy, I'm anxious to get back into the world domination game ....
NotFound japhb: my flux condenser is broken, must fix it first.
fperrad japhb, I've problem with $ENV{HOME} and with space in pathname 21:18
allison NotFound: looks great! change "his" to "its" on line 95, change line 97 to "If this is a return type and the value is NULL, PMCNULL is returned,", and change "some damn thing" to "something" on line 99 (I know, that was there before, but figure we might as well clean it up while we're in there)
NotFound The "some damn thing" is not mine ;)
allison: better we can get rid of that part, the UnmanagedStruct usage seems to be consolidated. 21:19
dalek kudo: 01c042f | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to get p6object and other fixes.
NotFound parrot-mysql depends on it.
allison NotFound: aye, I saw that was in the original, just figured we might as well change it while we're editing
japhb fperrad, OK. So what is the $ENV{HOME} problem? That env var doesn't exist, I'm guessing? And I assume the space in path problem is during run/qx calls, yes? 21:20
allison NotFound: okay, go ahead and edit the text about UnmanagedStruct
NotFound allison: ok, thanks
fperrad japhb, $ENV{HOME} exists but it isn't complete, see 21:21
NotFound allison: BTW the UnmanagedStruct usage was already taken for granted in later parts of the draft.
fperrad HOME=\\Documents and Settings\\fperrad
HOMEDRIVE=D:
japhb fperrad, oh, interesting. 21:22
That's just ... wow.
I'm guessing it's for remappable network drives?
allison NotFound: it's probably been partially updated
NotFound Mmmm... I think I was misreading the phrase... The damm thing is not the Unmanaged, but the thing pointed by it. 21:23
japhb fperrad, I've got some Plumage refactorings in a local branch (pending NQP-rx enhancements). I can either there, or if the branch is blocked for too long, turn home-dir fetch into a method with some logic behind it. 21:24
NotFound allison: I think the "or other" is the confusing part. Just "pointer to something" will be clean. 21:26
japhb fperrad, HOMEDRIVE issue now added to Plumage TODO
dalek rrot-plumage: a66dee9 | japhb++ | :
[META] More TODOs
japhb fperrad, where are you seeing the "space in path" problems, exactly? (So I can figure out the scope of what needs to be fixed.) 21:27
21:27 jsut_ joined
fperrad japhb, it's my default env, I try without success to set $ENV{HOME} to current directory (./) 21:27
For a first time, I prefer set $ENV{HOME}
japhb I'm not sure I understand. Prefer over what? 21:28
21:29 mikehh joined
fperrad japhb, Plumage could use its own env variable (for example PLUMAGE_HOME), instead of HOME 21:29
japhb fperrad, I don't mind having that as an override, but we still need to detect a proper default.
I really don't want to get back to "early cpan" days when you had to answer a couple dozen questions just to get started. 21:30
zero configuration to get the average person started. configuration is there for power users and special cases.
fperrad japhb, I agree with zero configuration 21:31
21:32 kj joined
NotFound As long as you don't use NOZEROCONF=true to deactivate it, as linux network conf uses in some systems X-) 21:34
21:34 AndyA joined
dalek rrot: r42404 | NotFound++ | trunk/docs/pdds/draft/pdd16_native_call.pod:
[nci] fix doc of 'p' type, TT #1261
 21:34
japhb pmichaud, (still backlogging #ps): why do you want the new NQP-rx-in-parrot binary to be called 'parrot-nqp' instead of just 'nqp' as it is now. What is the benefit to dehuffmanizing there? 21:35
cotto_work NotFound, ping 21:36
NotFound pong 21:37
cotto_work NotFound, can you add a notice to DEPRECATED.pod about TT #1260 and update the entry for TT #866?
dalek TT #1261 closed by NotFound++: Document NCI type 'p' behavior for PMCNULL/NULL values
cotto_work Both should be pretty quick changes. The change for TT #866 is just to make the list of deprecated VTABLE functions explicit, and they're listed in the TT's first post. 21:38
NotFound cotto_work: There is no one with an worse english than me for that task? ;) 21:39
cotto_work I saw that you'd just committed something and I don't want it to get dropped on the floor.
NotFound I always have problems for writing understandable DEPRECATED entries.
cotto_work If you prefer, I can msg cotto.
21:39 theory joined
NotFound Please do. 21:40
cotto_work msg cotto update DEPRECATED.pod for TT 1260 and TT #866 21:41
purl Message for cotto stored.
cotto_work botsnack
purl thanks cotto_work :)
japhb checks wiki.github.com/perl6/nqp-rx/plumage-requests ... aww, I was hoping for a visit from the magical feature gnomes during the night! :-) 21:47
21:49 patspam joined
dalek rrot: r42405 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] improve unlink
 21:51
a: cfdfc77 | fperrad++ | setup.pir:
some refactor and fix targets for test
 21:52
21:53 mikehh joined
nopaste "fperrad" at 78.113.94.6 pasted "(for japhb) can't configure Plumage on linux" (24 lines) at nopaste.snit.ch/18630 21:58
japhb looking 21:59
fperrad, how recent is your nqp-rx?
fperrad japhb, I work with nqp, not with nqp-rx 22:01
nopaste "NotFound" at 213.96.228.50 pasted "Object.invoke patch, makes 'object()' works" (17 lines) at nopaste.snit.ch/18631
NotFound allison: ping
chromatic Clever, but do we need to add 'Pi' to the start of the PCC string? (I forget if we removed that in the rush to improve speed.) 22:02
NotFound chromatic: for the simple test I have, it works.
chromatic Also you're missing a space around the assignment operator. 22:03
But I nitpick.
NotFound As always :)
Be happy don't used hard tabs ;) 22:04
pmichaud japhb: (nqp versus parrot-nqp) -- the parrot standard appears to be that language translators should be named "parrot-*"
japhb: I'm happy to install it as 'nqp', though.
japhb: I just need someone official-ish to tell me what to do there :)
japhb bak
fperrad, Plumage requires nqp-rx. We were seriously blocked on features missing in old nqp, so needed to switch. 22:05
fperrad, since nqp-rx will (soon) ship with parrot, that's not going to hurt our users, thankfully.
diakopter I don't suppose someone wants to fix a bug (at least, it seems like a bug to me) in __dump for PAST nodes... 22:06
it's blocking me, somewhat..
pmichaud what's the bug?
purl the bug is www.cbttape.org/funny/bug3.jpg or img227.imageshack.us/img227/2596/featureiu1.jpg
japhb pmichaud, hmm, OK. I certainly prefer the language translators to just be called by their simple name. As important as parrot is to us, it doesn't really matter to the end user who just wants to get things done.
So my vote is just plain 'nqp', as it is right now. 22:07
pmichaud japhb: that kinda doesn't work if the language is 'python', though. :-|
diakopter pmichaud: parrot.pastebin.com/f3f8bd543 line 30 is missing the var name
japhb pmichaud, I didn't realize there was a language for which the code name was the same as the original language name ...
fperrad japhb, thanks, I'll install nqp-rx 22:08
pmichaud japhb: there may not be. I suppose it could be installed as 'pynie'
japhb You're saying to install particle as parrot-tcl?
22:08 Whiteknight joined
japhb pmichaud, I can see both arguments, but my preference is to use the project name, not parrot- plus the language name. 22:09
pmichaud japhb: I'm saying I'd like to know what parrot's official standard is, and to use that :)
japhb: I personally don't have a strong preference when it comes to nqp versus parrot-nqp
japhb pmichaud, I know. I'm under the assumption there isn't a standard, and trying to influence a future choice. :-) 22:10
pmichaud well, it is mentioned in pdd30, iirc
dalek TT #1262 created by NotFound++: Simple patch for the overriding of invoke for objects 22:17
NotFound Certainly the pcc refactor has simplified things :) 22:18
fperrad japhb, could you take a fresh parrot-MT19937 and play with setup.pir (distutils). 22:25
Plumage needs a support for setup.pir interface
japhb Can you give me the 100-word overview of what setup.pir/distutils is? Configure replacement, make replacement, both, neither? 22:26
fperrad, ^ 22:29
fperrad japhb, setup.pir replaces Configure & generated Makefile,
$ parrot setup.pir
$ parrot setup.pir test
$ parrot setup.pir install
setup.pir uses the library distutils.pir (in the parrot tree)
darbelo fperrad: You a python user? 22:30
fperrad japhb, yes but I prefer Perl 22:31
darbelo Just wondering about the influences to distutils.pir
japhb fperrad, OK, interesting. Where is the master source for setup.pir? (I didn't find it in the parrot tree.) 22:32
fperrad japhb, each project has its setup.pir
darbelo japhb: If he's using the python custom, it's specific to each project
Eh. What he said. 22:33
fperrad japhb, setup.pir is just data + a call setup()
japhb fperrad, I meant, where do you keep the "canonical version", that you copy/paste into each new project? Or does distutils have a function to create a skeleton for you?
fperrad, ah, OK
fperrad japhb, tools/dev/mk_language_shell.pl generates it 22:35
japhb What's the repo url for parrot-MT19937? 22:37
fperrad japhb, github.com/fperrad/parrot-MT19937
japhb Wow ... distutils.pir feels like it would be WAY simpler in NQP 22:38
darbelo japhb: Well, that *is* the point of NQP ;) 22:39
japhb darbelo, yeah, but even more than usual. Browse the source a bit. My carpal tunnels hurt just reading it. 22:40
darbelo reads it 22:41
22:43 payload joined
darbelo PIR is such a *high* level assembler. 22:44
;)
NotFound Only a bit not so high as macroassembler ;) 22:45
japhb fperrad, is setup.pir with no arguments basically configure, or build, or both? 22:46
fperrad japhb, 'build' is default target
japhb fperrad, so no configure step at all?
(I should say, no *separate* configure step) 22:47
fperrad japhb, no Configure step
japhb, see setup.pir examples, I put links in the top distutils.pir 22:48
japhb fperrad, sure, just confirming that it wasn't an accident of example choice, but really intended to be no configure step.
Which you just did?
er, s/\\?/./ 22:50
fperrad japhb, the goal is : remove Configure step and remove Makefile/make/shell dependencies 22:51
NotFound fperrad++ 22:52
japhb fperrad, understood
holy cow ... well, I will say one thing ... setup.pir is FAST 22:58
fperrad, incoming 22:59
NotFound japhb: Even without jit? ;) 23:00
japhb fperrad, U CAN HAZ PLUEMIJ SETUP
NotFound, one hell of a lot faster than make .... 23:01
fperrad japhb, you would say : parrot is fast
darbelo japhb: make doesn't JIT either :)
dalek rrot-plumage: 9ce5135 | japhb++ | :
[plumage] Support setup.pir tool for new mt19937 project
rrot: r42406 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] use nqp.pbc instead of parrot_nqp.exe
 23:10
23:15 kid51 joined 23:27 plobsing joined, payload joined
plobsing hi parrot 23:28
darbelo hi plobsing
dalek rrot: r42407 | jkeenan++ | branches/auto_libjit:
Branch has been superseded by libjit_framebuilder branch.
darbelo saw my purl-o-grams?
plobsing yes. thanks. 23:29
darbelo Let me know when you send the CLA so I can nominate you on the next #parrotsketch
plobsing will do. 23:30
kid51 Last call for comments on these 4 TTs: 23:31
trac.parrot.org/parrot/ticket/1194
trac.parrot.org/parrot/ticket/1234
trac.parrot.org/parrot/ticket/1235
trac.parrot.org/parrot/ticket/1236
darbelo I have a problem with TT#1194
23:32 hercynium joined
kid51 Yes? 23:32
darbelo You waited too much to do it ;)
Other thatn that it looks goog to me
chromatic +1 to all four of your suggestions, kid51. 23:33
japhb plobsing, I sent a link to you earlier, but you may have been offline at the time. 23:35
plobsing, it's here: blog.vlad1.com/2009/11/06/canvasarr...nvasarray/ 23:36
plobsing saw it
japhb ah, ok
plobsing I was considering something similar
japhb excellent
plobsing the only weakness with that approach is requiring at least 2 pmcs for every C object
this of course makes the common case suboptimal
I propose a variant of this where the first PMC created with a pointer "owns" a pointer 23:37
other pmcs can refer to this but, defer to the original for GC purposes
NotFound +1 for all also
plobsing of course there should be a way of transfering ownership 23:38
japhb plobsing, then that owning PMC needs to have the API for locking memory etc.
dalek rrot: r42408 | jkeenan++ | trunk/t/op/hacks.t:
Delete useless test file per trac.parrot.org/parrot/ticket/1234.
japhb right
TT #1234 closed by jkeenan++: t/op/hacks.t: Delete useless test file
plobsing japhb: thats the thing, other PMCs will have the same interface and just forward to the owner for that kind of thing 23:39
japhb plobsing, nodnod 23:40
plobsing japhb: regarding your issues with struct creation; we should be able to freeze the descriptor into the PBC 23:41
23:41 wknight8111 joined
dalek rrot: r42409 | jkeenan++ | trunk/t/op/sysinfo.t:
Eliminate dependence on Perl 5 '%Config' in tests. Cf.: trac.parrot.org/parrot/ticket/1235.
 23:41
plobsing then we won't have to push tokens onto the array at runtime.
dalek TT #1235 closed by jkeenan++: t/op/sysinfo.t: Improper dependence on Perl 5 %Config
japhb plobsing, nice. 23:43
damn, fperrad left.
purl, msg fperrad With my last push, I believe I've got a fix in for your HOMEDRIVE requirement. The remaining problem is spaces in paths ... and I need to find out exactly where that fail is occurring, so could use debugging help from you. 23:44
purl Message for fperrad stored. 23:45
kid51 Whiteknight: Do you have more hours in the day than the rest of us? Is that how you manage to juggle all these github projects in addition to Parrot? :-)
Whiteknight kid51: not nearly so much juggling as you think 23:46
I can keep a few things from hitting the ground
plobsing: I'm getting test failures in libjit_framebuilder witout libjit installed
t/pmc/nci.t fails test 611
dalek rrot-plumage: bdd12b6 | japhb++ | :
[CORE] Util.nqp: Add user_home_dir() portability function
 23:47
rrot: r42410 | jkeenan++ | trunk/MANIFEST:
Fix MANIFEST to reflect recently deleted file.
 23:48
chromatic Whiteknight, is that on 32-bit Linux? 23:49
plobsing Whiteknight: what is the title of the test?
Whiteknight 64-bit linux
"nci_ssc"
plobsing without you say? 23:50
chromatic That's new. 23:52
pmichaud poll: $PARROT_INSTALL/bin/nqp or $PARROT_INSTALL/bin/parrot-nqp ? 23:53
moritz nqp 23:54
rakudo doesn't ship a parrot-perl6 binary either
pmichaud well, the slight difference is that nqp will be part of the parrot distro, while rakudo won't. 23:55
(er, that _could_ be a perceived difference)
moritz it will be?
dalek rrot: r42411 | jkeenan++ | trunk (71 files):
Merge auto_format_no_Config branch into trunk. Eliminate dependence on Perl 5 '%Config' in auto::format and corresponding test. Transfer that lookup to init::defaults.
rrot: r42412 | jkeenan++ | branches/auto_format_no_Config:
Branch has been merged into trunk and is no longer needed at HEAD.
moritz thought it was decided the other way round
purl i already had it that way, dalek.
moritz pmichaud: then I retract my vote
pmichaud nqp will continue to live in its own repository. But Parrot will snapshot it into its repo so it can be built along with Parrot. 23:56
dalek TT #1236 closed by jkeenan++: config/auto/format.pm: Replace direct dependence on Perl 5 %Config
plobsing Whiteknight: I changed that test to better exercise short->long promotion
pmichaud i.e., obtaining parrot provides nqp and its libraries as well.
plobsing it did asser 2*3=6
now it asserts -2*3=-6
Whiteknight plobsing: okay, I'll give it another go in a little while
plobsing I'm trying to reproduce now

Powered by Cro and the Raku® Programming Language.

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

Thank you!