Camelia, the Perl 6 bug

IRC log for #parrot, 2011-03-10

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:10 cotto_work Is this idea workable:
00:10 nopaste "cotto_work" at 192.168.1.3 pasted "trivial M0 FFI concept" (5 lines) at http://nopaste.snit.ch/36594
00:20 whiteknight looks a lot like what I have been envisioning
00:20 whiteknight of course, that kind of example is trivial. How do you pass arguments and receive a return value?
00:20 whiteknight keeping in mind that floating point return values are passed in a different place on x86, and other platforms may have even weirder systems
00:25 cotto_work whiteknight: yes, there's a lot of extra complexity in argument and callbacks.
00:28 bubaflub joined #parrot
00:30 whiteknight so ignoring those complexities, what do you think the M0 syntax looks like for passing args and receiving returns from C?
00:30 whiteknight that's the much more interesting problem
00:36 lucian left #parrot
00:37 tcurtis joined #parrot
00:40 cotto_work whiteknight: that's what I'm thinking about.
00:43 tcurtis left #parrot
00:49 dalek Rosella: a73456f | Whiteknight++ | / (2 files):
00:49 dalek Rosella: Don't fail as hard when we have a null expectation (one with no options set). Add in some new quantifiers. Add in some tests for Expectations
00:49 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/a73456fbdb
00:49 dalek Rosella: f74a400 | Whiteknight++ | / (3 files):
00:49 dalek Rosella: Add in a will_do expectation modifier to execute a sub for side-effects. Add in a test file for several Will variants
00:49 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/f74a4009a5
00:52 plobsing_ cotto_work: if M0 is what we're going to be writting most of our VM in, we shouldn't be doing dlfunc for every C call we need to make. we need a way to express static calls and library dependancies to allow the native code generator and OS to do what they do best.
00:53 whiteknight the compiler can probably take function calls to "Parrot_*" and turn them into static cals
00:54 plobsing_ not if we're dlfuncing them.
00:54 cotto_work that sounds magical.  I don't like the idea of the extra complexity of having two ways to call a function, but plobsing_ makes sense.
00:54 kid51 is now known as kid51_at_dinner
00:54 whiteknight Parrot should recognice that calls to itself don't need dlfuns
00:54 whiteknight my fingers are stupid tonight
00:55 * cotto_work goes home with things to think about
00:57 plobsing_ I'm not sure this is a resolvable issue given the current design. The only approach I can see (I'm not very imaginative) is having some kind of "big table of compilation context", which the compiler has available. Any function we'd want to use would exist in that table. It is basically the M0 analog of the GOT.
00:58 plobsing_ I'm not sure that would work either, but it's the best I can come up with.
01:02 ShaneC what is M0?
01:03 ShaneC the pir replacement?
01:03 sorear no
01:03 sorear M0 is our C replacement
01:03 sorear PIR replacement will be M1 or maybe M2
01:03 sorear if PIR is M2, M1 will be more PASM
01:03 ShaneC is it similar to the .pmc syntax or something different?
01:07 plobsing_ left #parrot
01:10 whiteknight the .pmc file syntax is like a really bad mismash of C
01:11 woosley joined #parrot
01:11 whiteknight and the .ops file is an equally bad, but different mismash of C
01:11 whiteknight and PIR is a really really bad mismash of everything everybody ever suggested they must want
01:12 whiteknight the idea of M0 is that we create a new, common base language that is used to implemnt everything at the lowest level
01:13 whiteknight and then we can start building up all the other thigns we need: PIR, PMCs, Ops, etc, on top of that common layer
01:14 whiteknight in the process, we can cut out a lot of marshalling logic to switch between C/PIR calling conventions, and we can expose everything from top-to-bottom to the JIT and other optimzers
01:14 whiteknight similar in many respects to the PyPy project: Write everything in Python, and compile, JIT, and optimize it all as one
01:19 davidfetter left #parrot
01:19 cotto ~~
01:20 kid51_at_dinner is now known as kid51
01:23 cotto plobsing++ for the answers on parrot-users
01:29 dalek parrot: f4feafc | petdance++ | / (2 files):
01:29 dalek parrot: The mem_sys_allocate and related functions cannot take a zero-length size any more.  They also are guaranteed to not return NULL.
01:29 dalek parrot: review: https://github.com/parrot/parrot/commit/f4feafc81e
01:29 dalek parrot: 94c5359 | petdance++ | / (3 files):
01:29 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
01:29 dalek parrot: review: https://github.com/parrot/parrot/commit/94c5359dfc
01:37 bubaflub left #parrot
01:39 mtk left #parrot
01:39 kid51 Darwin/PPC: make fulltest PASS at commit 792a139882
01:46 mtk joined #parrot
01:49 Coke msg kid51 that file did actually have more than just debugging tips.
01:49 aloha OK. I'll deliver the message.
01:50 kid51 Coke: I'm looking at it right now.
01:51 kid51 It has 5 subheads -- but the only 2 sections of those that are well developed both start out "Debugging"
01:51 kid51 and two others have Profiling in their names.
01:52 kid51 So why is debugging_profiling.pod not a good name?
01:52 kid51 cotto requested a better name; is there something better still we have not thought of yet?
01:54 kid51 I'm not wedded to that name.  If you have something better, I won't object.
01:56 cotto "debugging_profiling" implies that it's about debugging profiling.  I was thinking more like "advanced tips for hacking on parrot"
01:58 kid51 So, how about "advanced_hacking_tips.pod"?
01:58 kid51 I just think "protips" sounds like a variation on "Qtips"
01:59 whiteknight left #parrot
01:59 cotto http://knowyourmeme.com/memes/protip
01:59 kid51 cotto: I have never heard of that usage/meme
02:00 kid51 or perhaps simply "advanced_hacking.pod"
02:00 kid51 cotto: You have a preference?
02:01 cotto thinking
02:01 plobsing_ joined #parrot
02:02 cotto hacking_tips wfm
02:02 cotto "advanced" means too many different things to different people
02:04 cotto I can change that
02:06 dalek TT #2037 closed by jkeenan++: darwin/ppc build failure
02:06 dalek TT #2037: http://trac.parrot.org/parrot/ticket/2037
02:07 dalek parrot: e3b4b86 | cotto++ | / (4 files):
02:07 dalek parrot: change name of hacking tips doc
02:07 dalek parrot: review: https://github.com/parrot/parrot/commit/e3b4b8696a
02:08 kid51 cotto: docs/index/developer.json -- Is that a file that needs to be edited manually when we add/subtract/rename files under docs?
02:09 cotto yes
02:09 cotto I'm pretty sure, at least
02:18 dalek parrot: e39cc22 | petdance++ | src/hash.c:
02:18 dalek parrot: consting pointers.  Much progress at making hashes const-happy.
02:18 dalek parrot: review: https://github.com/parrot/parrot/commit/e39cc22980
02:18 dalek parrot: 646eacd | petdance++ | / (4 files):
02:18 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
02:18 dalek parrot: review: https://github.com/parrot/parrot/commit/646eacda0c
02:30 sigue left #parrot
02:42 sigue joined #parrot
02:47 bubaflub joined #parrot
02:49 tcurtis joined #parrot
02:52 tcurtis left #parrot
03:04 kid51 left #parrot
03:29 bubaflub left #parrot
03:36 dalek parrot: 1cad94c | petdance++ | src/longopt.c:
03:36 dalek parrot: make optlen be a size_t
03:36 dalek parrot: review: https://github.com/parrot/parrot/commit/1cad94c9b2
03:52 dalek parrot: c02eba5 | petdance++ | / (2 files):
03:52 dalek parrot: Note that Parrot_vsnprintf() could possibly leave the buffer untouched.  This means the buffer is ARGMOD(), not ARGOUT()
03:52 dalek parrot: review: https://github.com/parrot/parrot/commit/c02eba5483
03:57 particle left #parrot
03:57 dalek parrot: 0fc3c4c | petdance++ | / (2 files):
03:57 dalek parrot: Parrot_ns_find_global_from_op can return NULL
03:57 dalek parrot: review: https://github.com/parrot/parrot/commit/0fc3c4c3be
03:58 particle joined #parrot
04:06 dalek parrot: d20e406 | petdance++ | config/gen/makefiles/root.in:
04:06 dalek parrot: remove the splint-all target. make SPLINT_SOURCE not quite so crazy inclusive
04:06 dalek parrot: review: https://github.com/parrot/parrot/commit/d20e4066be
04:42 ShaneC left #parrot
04:46 particle1 joined #parrot
04:49 particle left #parrot
05:00 ShaneC joined #parrot
05:11 cotto ~~
05:13 dalek parrot: 636b42a | petdance++ | / (4 files):
05:13 dalek parrot: shimming unused interps.  Changed an int to size_t.
05:13 dalek parrot: review: https://github.com/parrot/parrot/commit/636b42ab9d
05:21 benabik left #parrot
05:24 davidfetter joined #parrot
05:36 arnsholt left #parrot
05:39 arnsholt joined #parrot
05:47 ShaneC any particular reason why all nci types are signed?
05:50 plobsing_ not really
05:50 plobsing_ we just haven't got around to adding those types
05:51 ShaneC fair enough, shouldn't harm anything i'm doing, just curious
05:51 plobsing_ you can fairly easily convert signed to unsigned using StructView's 'Union' view
05:51 ShaneC i do have one question about nci though
05:52 ShaneC i'm trying to call a function that takes a pointer to a char buffer, i assume 't' is the right nci prototype for that, but how can i set the buffer size of a parrot string?
05:53 plobsing_ 't' is deprecated for a number of reasons that fall directly out of what you just said
05:53 ShaneC any planned workaround or will i need to write some c?
05:53 plobsing_ 1) Parrot strings are *immutable*. You cannot pass them to C code which modifies them internally without breaking *everything*.
05:54 ShaneC ah, makes sense
05:54 ShaneC even if the buffer were large enough im guessing parrot keeps track of string length at least
05:54 ShaneC which would then be wrong
05:54 plobsing_ 2) the things C programmers want to do with strings don't match what Parrot strings are. the concept of "setting the buffer size" does not make sense for Parrot strings.
05:54 jsut_ joined #parrot
05:55 ShaneC i imagine you could do sort of a perl-5-esque $string = ' ' x $bufferSize; to reserve space
05:55 plobsing_ the workaround is to use a buffer type. And not the suggestively-named but ill-suited "ByteBuffer" type.
05:55 plobsing_ PtrBuf is probably what you want
05:55 plobsing_ you can allocate these with StructView
05:56 plobsing_ although you could NCI to any allocator you choose.
05:56 ShaneC would that require me to change any c or recompile parrot?
05:57 ShaneC i have no problem with doing that, but just trying to understand if this can be pure-pir or not
05:57 plobsing_ no recompilation or patching necessary.
05:57 ShaneC with a PtrBuf, would i be able to convert that to a parrot string?
05:58 sorear parrot strings are not strings of 'char'
05:58 plobsing_ Parrot provides the means of translating between native buffers and Parrot strings
05:58 sorear they are strings of Unicode characters in an unspecified encoding
05:58 plobsing_ you will have to use NCI to access them however
05:58 plobsing_ I intend to provide some utilities to make this easier at some point
05:59 ShaneC thanks, i'll dig into the PtrBuf stuff now
05:59 jsut left #parrot
05:59 plobsing_ because I see this is something people want to do frequently (which is why we have a couple of ways built into the NCI to do it, even though these are each wrong in their own special way)
06:03 petdance left #parrot
06:05 ShaneC addressing this seemingly simple ticket has led me down quite a few rabbit holes ;-)
06:06 plobsing_ what ticket?
06:07 ShaneC http://trac.parrot.org/parrot/ticket/955
06:09 bacek ~~
06:09 plobsing_ the ticket suggests that implementation as a dynop is a good idea. any reason you aren't going with that?
06:11 ShaneC after a little discussion here it seemed like it really doesn't belong with FileHandle.open, and doing it as a pure-pir class seemed like a straightforward approach
06:11 plobsing_ sounds like a good reason
06:12 ShaneC create a file on init, provide access to its filename, delete it on destroy
06:13 bacek ShaneC, there is a pitfall with .destroy methods of PIR classes.
06:13 ShaneC ?
06:13 ShaneC could be moved to an explicit method for now
06:13 bacek This is one of not-overriden methods.
06:13 ShaneC what do you mean?
06:14 bacek With "explicit" method it's less-than-awesome.
06:14 plobsing_ so we're talking about the equivalent of insecure mktemp?
06:14 bacek ShaneC, .destroy will not be invoked automatically from GC.
06:15 ShaneC plobsing_: if mktemp's behavior is preferred, i figured that ticket would not exist
06:15 plobsing_ ShaneC: mk *S* temp's behaviour should be preferred.
06:16 ShaneC in either case, if there exists a standard function that does exactly what is needed, why the ticket?
06:17 plobsing_ because it is not exposed to parrot at the current time
06:17 plobsing_ hence the ticket
06:18 ShaneC bacek: is there a proper way to delete the file at the proper automagical time?
06:18 bacek ShaneC, use mkstemp?
06:20 ShaneC that handles deleting the file?
06:21 bacek actually, open file, remember fd, remove file.
06:21 bacek store fd in FileHandle
06:21 bacek FileHandle.destroy will close it.
06:22 ShaneC the windows version of mkstemp does not return a filehandle and does not create the file
06:23 ShaneC which doesn't mean mkstemp couldn't be used elsewhere, but windows will need code to clean up the file somewhere
06:24 ShaneC bacek: earlier discussion about the ticket also suggested that some places may open/close the same temp file multiple times
06:24 ShaneC or pass it to an external process
06:25 bacek pass filename of filehandle?
06:26 plobsing_ Security isn't a priority for the testsuite, which is the use-case that reveals the need for such a feature.
06:26 plobsing_ But many use cases should be concerned with security.
06:26 ShaneC (apologies for my poor understanding of the *nix behavior of this, but) didn't you say mkstemp removed the file?
06:26 bacek erm. Is there way to delete file from parrot? I couldn't find one
06:26 ShaneC so the only way to get at it would be through the existing handle
06:27 plobsing_ ShaneC: no, mkstemp does not automagically remove the file. It creates and opens the file in a secure, race-condition free way.
06:27 plobsing_ mktemp is very easily attackable
06:28 plobsing_ bacek: we have os.rm(file)
06:29 bacek ah, ok
06:29 cotto I've wondered why that's a method on OS and if there's a better place for it.
06:30 bacek so, why don't just expose mkstemp via dynops?
06:30 ShaneC mkstemp is different on windows
06:30 ShaneC although that could be hidden i suppose
06:31 plobsing_ cotto: OS is a collection of things that don't really fit well anywhere right now
06:31 ShaneC any tips on where to look to learn about implementing a new dynop?
06:31 bacek ShaneC, src/dynops/io.ops
06:31 ShaneC thanks
06:32 ShaneC src/dynoplibs?
06:33 plobsing_ cotto: I've been thinking that functionality would be better provided by an NCI collection inspired by Perl 5's POSIX module.
06:33 cotto plobsing_, I wouldn't object to that, given a smooth transition for users.
06:34 plobsing_ cotto: it's nothing more than a pipe(3) dream at the moment
06:35 fperrad joined #parrot
06:35 cotto plobsing++
06:35 bacek ShaneC, yes, dynoplibs
06:35 Khisanth left #parrot
06:39 cotto ShaneC, welcome to yak-shaving 101
06:39 ShaneC i just hope i can actually have a patch to submit one of these days!
06:39 ShaneC definitely seems to be getting closer though ;-)
06:40 ShaneC gradually making my way up the steep slope of becoming familiar with a large code base
06:47 Khisanth joined #parrot
06:53 dalek parrot: 7ede0e1 | bacek++ | / (2 files):
06:53 dalek parrot: Remove useless commented out stuff from ops
06:53 dalek parrot: review: https://github.com/parrot/parrot/commit/7ede0e1c53
06:54 dalek parrot/opsc_llvm: 3a42442 | bacek++ | t/library/llvm/06-builder.t:
06:54 dalek parrot/opsc_llvm: Add more tests
06:54 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/3a4244265d
06:59 rurban_ joined #parrot
07:02 rurban left #parrot
07:02 rurban_ is now known as rurban
07:06 bacek cotto, ping
07:07 cotto bacek, pong
07:08 bacek cotto, did you ever try to freeze/thaw parsed Ops::OpsFile?
07:08 bacek It breaks horribly for me...
07:08 cotto bacek, I never played with that.
07:09 bacek ookey.
07:09 cotto What kind of application are you thinking about?
07:10 bacek "JIT"
07:10 bacek I do need more info than in op_info_t
07:10 bacek preferably - originally parsed op.
07:11 cotto is it not feasible or practical to add that info to op_info_t?
07:11 bacek It's feasible. But I don't know how much info I'll need yet
07:11 cotto so it easier for prototyping to just dump everything
07:12 bacek exactly
07:12 bacek but parsing will take 60 seconds for each test run
07:12 bacek which kind of waste of time
07:12 cotto very much
07:12 cotto I can see why you want that.
07:13 cotto there's some potential for build improvements if that can be made to work
07:14 bacek this is too.
07:16 bacek sigh... I hate handling of LABELs...
07:33 davidfetter left #parrot
07:43 particle1 left #parrot
07:59 theory left #parrot
08:27 lucian joined #parrot
08:32 lucian left #parrot
09:00 dalek parrot: c361e4f | bacek++ | src/ops/ (4 files):
09:01 dalek parrot: Don't pessimize prematurely. Use optimizable accessors.
09:01 dalek parrot: review: https://github.com/parrot/parrot/commit/c361e4f09e
09:01 dalek parrot/opsc_llvm: 7ede0e1 | bacek++ | / (2 files):
09:01 dalek parrot/opsc_llvm: Remove useless commented out stuff from ops
09:01 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/7ede0e1c53
09:01 dalek parrot/opsc_llvm: c361e4f | bacek++ | src/ops/ (4 files):
09:01 dalek parrot/opsc_llvm: Don't pessimize prematurely. Use optimizable accessors.
09:01 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/c361e4f09e
09:01 dalek parrot/opsc_llvm: 4008a6b | bacek++ | / (47 files):
09:01 dalek parrot/opsc_llvm: Merge branch 'master' into opsc_llvm
09:01 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/4008a6b653
09:16 contingencyplan left #parrot
09:17 woosley left #parrot
09:26 mtk left #parrot
09:29 Khisanth left #parrot
09:33 mtk joined #parrot
09:39 Khisanth joined #parrot
10:13 dod left #parrot
10:27 dalek parrot/gerd/JSON_nqp: d92f11c | (Gerd Pokorra)++ | t/compilers/data_json/to_parrot_2.t:
10:27 dalek parrot/gerd/JSON_nqp: change documentation in test to use the correct filename
10:27 dalek parrot/gerd/JSON_nqp: review: https://github.com/parrot/parrot/commit/d92f11cd7b
10:30 cosimo left #parrot
10:32 dalek parrot: 717ab39 | bacek++ | NEWS:
10:32 dalek parrot: Update NEWS for opsc_full_parse branch merge.
10:32 dalek parrot: review: https://github.com/parrot/parrot/commit/717ab39d02
11:06 lucian joined #parrot
11:18 lateau_ joined #parrot
11:34 plobsing_ left #parrot
11:38 plobsing joined #parrot
12:21 dalek Rosella: 4e98e6b | Whiteknight++ | / (9 files):
12:21 dalek Rosella: Start fleshing out proxy builders for Array and Hash types
12:21 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/4e98e6bf3f
12:25 darbelo joined #parrot
12:42 sigue left #parrot
12:44 mj41 left #parrot
12:51 Kulag left #parrot
12:56 dukeleto ~~
12:59 darbelo ~~
13:00 sigue joined #parrot
13:00 dukeleto darbelo: howdy!
13:01 * dukeleto is hanging out in Ithaca, NY for the next 1.5 weeks
13:05 sigue left #parrot
13:05 sigue joined #parrot
13:10 woosley joined #parrot
13:11 Kulag joined #parrot
13:27 Coke that's almost in my neck of the woods.
13:28 dukeleto Coke: almost :)
13:29 dukeleto Coke: i will hopefully meet up with kid51 while I am here for some strategic discussions
13:34 whiteknight joined #parrot
13:35 dukeleto smolder is still down. This sucks.
13:35 whiteknight how long has it been down?
13:37 Coke it's even further away from him. ;)
13:37 Coke dukeleto: we have keys. why don't we restart it?
13:39 Coke (teh website is up...)
13:42 Drossel joined #parrot
13:42 Kulag left #parrot
13:44 Coke anyone mind if I kill smolder to see if I can restart it?
13:45 moritz forgiveness > permission
13:45 Coke I was willing to wait a few seconds on this one. ;)
13:48 Coke Ok. I think I restarted smolder. No clue if it will help with any perceived problems, but now I know where the big red button is.
13:55 Drossel left #parrot
14:05 Kulag joined #parrot
14:08 particle joined #parrot
14:42 mikehh left #parrot
14:43 dukeleto Coke: looks like that helps. I just submitted a smolder result
14:45 * moritz too
14:48 Coke ok. All I did was kill one of the smolder processes that was running - all of them seemed to get the hint and die, then I just sudo'd to root, su'd to nobody, and rename the daemon command. (pulled from the initial PS)
14:49 Coke So, the next time someone reports a problem, anyone with access to parrotvm @ osu can do that.
14:49 dukeleto Coke: it needs to be a single script that somebody can run, and it needs to be in our docs somewhere, or nobody but you will ever do it
14:50 dukeleto Coke: restarting it in a cron job would be better
14:50 dukeleto smolder is nice, but it has horrible memory leaks in it's dependencies that no one seems to want to fix
14:51 dukeleto Coke: just trying to make sure you are not the one that always get stuck doing it
14:51 whiteknight how do I call set_p_p_ki from NQP?
14:52 whiteknight NQP-rx
14:52 Coke Key is an IMCC literal. I don't think you can do that without Q:PIR
14:53 whiteknight yeah, I was afraid that was the answer
14:55 Coke I could be mistaken. This is the part where'd I normally ask pmichaud.
14:58 jnthn whiteknight: What Coke said, but why do you want to do that?
14:59 jnthn Just get the thing the [$i] it.
14:59 whiteknight jnthn: I'm trying to test my new proxy library, which uses a bunch of vtable overrides
14:59 whiteknight and I'm trying to write a test in NQP that can call into my get_*_keyed_int overrides
14:59 whiteknight and nothing that I've tried so far does that
14:59 jnthn You can't directly call into them from PIR even, afaik.
14:59 rurban_ joined #parrot
14:59 moritz you can do  thing[$I0]
15:00 moritz which calls them
15:00 jnthn Yeah but that doesn't call get_*_keyed_int unless get_*_keyed forwards to it.
15:00 jnthn Which is stupid but that's Parrot keys.
15:00 whiteknight moritz: I've tried that, it looks like it's calling the pmc-keyed vtables instead of the int-keyed ones
15:00 whiteknight yes, parrot keys are stupid all the way around
15:00 jnthn whiteknight: Yes, it does. :/
15:00 jnthn whiteknight: You can only directly call the get_*_keyed_int variant from C-land.
15:00 jnthn *variant
15:01 moritz this is even more broken than I thought :-)
15:01 whiteknight the set_*_p_ki ops look like they call the keyed_int vtables
15:01 whiteknight but I can't seem to generate a call to set_p_p_ki
15:01 jnthn heh
15:01 whiteknight when I do $P0[1] = foo, I get set_p_p_kp instead, it seems
15:02 rurban left #parrot
15:02 rurban_ is now known as rurban
15:02 jnthn If you work out a way let me know...I ran into this epic bunch of broken a few weeks ago.
15:02 whiteknight which suggests to me that either those ops are dead, or there is some kind of super-secret syntax which I am missing
15:02 whiteknight aloha coverage?
15:02 aloha whiteknight: coverage is http://cv.perl6.cz or http://tapir2.ro.vutbr.cz/cover/cover-results/
15:02 jnthn It actually gets worse than that too, when you realize what's inside the key is a register reference, so if you pass it to a v-table override, it now refers to the wrong register!
15:02 whiteknight FFFUUUUUU
15:02 jnthn Yes, that's what I said.
15:03 dukeleto seems like that is broken by design
15:04 whiteknight okay, according to the coverage report, it does seem like Parrot_set_p_p_ki is being hit by code somewhere
15:08 mikehh joined #parrot
15:11 whiteknight okay, nevermind. I added in some debugging statements and it looks like $P0[0]=$P1 is generating a call to Parrot_set_p_kic_p
15:11 whiteknight and that should be calling VTABLE_set_pmc_keyed_int
15:14 NotFound whiteknight: you need a int register, not an Integer PMC.
15:16 NotFound If not, one vtable can call the other or not, depending on each pmc.
15:20 Coke I am reminded of bacek's "rip out keys" ticket.
15:22 NotFound I'm tempted to write a ticket: "Rip out proposals to rip out things without providing alternatives", but it will rip out itself.
15:23 moritz :-)
15:23 Kulag left #parrot
15:24 moritz so, why do we need keys?
15:24 Kulag joined #parrot
15:24 NotFound To call vtable keyed thngs.
15:25 moritz we could just redispatch foo[thing] depending on the type of 'thing'
15:25 moritz s/redispatch/dispatch/
15:25 moritz imcc knows if 'thing' is PMC, string or int
15:25 NotFound moritz: we already do, partially.
15:26 plobsing we need keys to be able to be able to be able to form references to registers in a controlled fashion
15:26 plobsing without keys, we would wind up creating agregates for keyed lookups
15:27 plobsing and churning the GC
15:27 moritz and keys are not GCed?
15:27 NotFound moritz: literal keys in pir are constants
15:27 plobsing keys are references to registers and can be reused
15:28 plobsing allowing PMCs to do this more generally would break encapsulation in a huge way
15:28 plobsing so we have 1 type that can do it
15:28 plobsing and anything that wants to read PBC only needs to know how to deal with that type
15:28 whiteknight Keys are aggregate pmcs
15:29 whiteknight in fact, each element in the key is a separate pmc, joined together in a linked list
15:29 whiteknight a single ResizablePMCArray would have less churn than a multi-level key PMC
15:29 plobsing nope. you'd need to repopulate the RPA
15:29 plobsing every lookup
15:29 NotFound whiteknight: a RPA can't point to registers.
15:29 plobsing and you'd need to create a new RPA to handle recursion
15:29 whiteknight plobsing: not if it was setup as a constant in the bytecode
15:30 NotFound whiteknight: $P0[$I0] -> Not a constant
15:30 plobsing whiteknight: translate this to an RPA $P0[$P1, 0]
15:30 whiteknight we would have to add functionality to RPA to handle register references, but that's hardly a showstopper
15:30 whiteknight or, we write a subclass of RPA to handle it
15:30 plobsing whiteknight: that violates encapsulation on registers
15:31 NotFound whiteknight: if we add Key functionality to RPA the 'mess' level will be worse, not better.
15:31 plobsing encapsulation upon which tools for analysing and manipulating bytecode rely
15:31 whiteknight plobsing: if we took the same register reference logic from Key, and put it into a new array type, how would that violate encapsulation any worse than we do right now?
15:31 plobsing none. and you could even call that array type Key.
15:31 plobsing problem solved
15:31 whiteknight there is nothing fundamentally special about Keys that could not be changed or reimplemented. The only thing that sets Keys apart is how poorly they are designed
15:32 plobsing the linked-list aspect is just an implementation detail that we can remove
15:32 NotFound Then the proposition is to rework the internals of Key, not to rip it out.
15:32 whiteknight and the Key PMC type isn't even the worst part of the whole system. The keyed ops are all terrible
15:32 moritz so is a key a bit like an SV in perl5?
15:33 whiteknight differentiating between intkey and key in the ops is stupid
15:33 NotFound BTW, we may need less runtime created keys just by allowing both Keys and Arrays in some usages.
15:33 NotFound But tha may need to use iterators, then one more GCable in each usage.
15:34 whiteknight we should be able to have a set_p_p_p op, and I should be able to pass in *anything* as the key, not just a compile-time-created Key PMC
15:34 whiteknight I should be able to pass in a scalar, an array type, whatever
15:34 NotFound whiteknight: we can do that right now, using pasm syntax to avoid imcc messing with the ops.
15:34 NotFound the operands
15:35 plobsing whiteknight: you can: $P0 = $P1[$P2]
15:35 plobsing or should be able to do so using that syntax
15:35 NotFound But the callee in lots of places expect only Keys
15:35 plobsing which is why we need a better encapsulating API, not to rip out keys
15:36 plobsing also I think we should have a different syntax for "single-element key" vs. "I am using this thing as a key"
15:37 plobsing eg: $P0 = $P1[$P0] vs $P0 = $P1{$P0}
15:37 NotFound plobsing: we have it, in pasm
15:37 plobsing NotFound: orly?
15:37 woosley left #parrot
15:37 NotFound set_p_p_p $P0, $P1, $P0
15:38 plobsing you can do that from PIR too
15:38 NotFound plobsing: I mean, pasm syntax without pir sugar.
15:39 plobsing ah
15:41 NotFound whiteknight: the difference between intkey and key is probably a big performance impact.
15:42 NotFound Not for HLL that never generates them, of course.
15:45 JimmyZ joined #parrot
15:47 whiteknight plobsing: In the case of $P0 = $P1[$P2], is $P2 passed in raw, or is it wrapped up into a Key PMC?
15:48 plobsing I suspect it is special-cased raw.
15:48 plobsing but you should do what NotFound suggested
15:51 NotFound I think I tested that some days ago, and it got wrapped.
15:51 whiteknight so if set_p_p_p works, why do we need set_p_p_k?
15:51 whiteknight or is that just to simplify logic in IMCC
15:52 moritz to avoid the PMC in the case of constant keys?
15:52 sorear why not just have set_p_p_i, set_p_p_s, set_p_p_p and kill off Key entirely?
15:52 whiteknight that's what I keep asking
15:53 NotFound sorear: because vtables keyed expect keys
15:53 sorear we already deprecated and removed the special magic that was multidimensional keys' reason for existing
15:53 whiteknight NotFound: we can change them to not expect keys
15:53 plobsing sorear: what special magic is that?
15:53 sorear plobsing: autovivification blah blah
15:53 plobsing sorear: that was just for core PMCs
15:54 plobsing there is nothing saying some other PMC can't autoviv
15:54 NotFound The magic that Key does and no other thing does is referencing registers.
15:55 NotFound Thining better, lexpads also does it.
15:55 NotFound But not for int and string registers.
15:55 plobsing yes, and in a completely different way
15:56 NotFound Anyway, if you want to get rid of keys, first think abou how to provide its functionality, or how to remove that functionality.
15:58 plobsing I'd lean towards the former. Most arguments against Keys have been of the latter type ("Keys are dumb"), and haven't really gotten anywhere.
15:59 plobsing for extra credit, think about how to unify our variadic ops with the key-replacement functionality.
16:00 NotFound Can't we avoid variadic ops just by storing the variadic part in a constant?
16:00 theory joined #parrot
16:01 plobsing NotFound: we could. Key constants provide equivalent functionality.
16:03 NotFound I've think about that several times, but my imcc-fu is not godd enough.
16:03 plobsing the PCC part of IMCC is the worst part
16:10 whiteknight I've wanted to get rid of the variadic ops for a long time
16:11 whiteknight saying that they are somehow requiring keys to stay around is not an argument which sways me
16:13 plobsing whiteknight: I'm not saying that. I'm saying they are equivalent to keys. We can replace one for the other.
16:14 ambs joined #parrot
16:14 plobsing you could eliminate keys quickly by replacing keyed ops with variadic ops that passed along an opcode_t iterator as its "Key"
16:14 plobsing you could eliminate variadic ops by referencing the variadic registers using a key
16:15 plobsing a replacement for Keys would therefore also be a replacement for variadic ops
16:15 plobsing 2 birds, one really big stone
16:16 NotFound Myabe we can use some bizarre quantum effect to eliminate both while each still using each other ;)
16:17 plobsing Heisenburg's Technical Debt Principle: so long as you make everyone focus on how quickly you are eliminating technical debt, noone will know how much technical debt you have
16:19 Patterner left #parrot
16:19 Psyche^ joined #parrot
16:19 Psyche^ is now known as Patterner
16:19 NotFound We should renegotiate technical debt with financial engineering and make a bubble with it.
16:19 NotFound It will add a new meaning to "software crisis"
16:21 NotFound Maybe that is what facebook is doing now.
16:24 plobsing facebook has a PHP problem. they say "I know, I'll use C++!" now they have bigger problems.
16:25 atrodo i am just always amazed that facebook works as often as it does everytime i hear about their setup
16:27 darbelo left #parrot
16:30 NotFound They should use winxed instead.
16:30 NotFound And pay me several thousand millions for consultant service.
16:32 plobsing I always have trouble parsing long scale numbers
16:33 atrodo I think he said 30$, give or take
16:34 * JimmyZ doesn't want to use winxed if parrot isn't faster than php
16:35 NotFound I've never tried a comaprative.
16:37 * plobsing never wants to use PHP again. ever. even if it is faster than everything.
16:37 moritz it's like "I won't use Perl before it's fasther than Assembly" :-)
16:37 cotto_work ~~
16:38 tadzik oh, I know people like this
16:38 cotto_work I won't use assembly until it's faster than Perl.
16:39 tadzik "what do you mean dynamic typing? This can't be faster than C++ then? So why to use it?". I hope my co-students will grow up before they graduate :)
16:39 * JimmyZ doesn't say slower is bad, but parrot is so slower that almost nobody want to use it on a website
16:45 plobsing http://try.rakudo.org/
16:45 plobsing use parrot. on a website.
16:45 NotFound JimmyZ: given that there are people that serve static pages using frameworks backed up by a database, I doubt lack of speed disallows anything.
16:46 plobsing lack of sanity on the other hand...
16:46 atrodo cotto_work> I saw your nopaste last night, and wanted to wonder outloud, is an ffi call different than any other call at a M0 level?
16:47 NotFound JimmyZ: btw if you want to do a comparative yo can try to rewrite winxed examples/fly in php ;)
16:47 cotto_work Sadly, there are opengl bindings for php.
16:47 plobsing atrodo: dispatching to a runloop or to C based on argument type is magical
16:50 JimmyZ yes, there is phpopengl on sf.net
16:50 NotFound Then is should be an easy task.
16:51 NotFound s/is/it
16:52 NotFound I remember one time a guy told me its favourite Basic compiler was faster than C. The demonstration was a program with a few lines in Basic and lots in inline assmbler.
16:53 plobsing NotFound: that's what I call dedication to a cause
16:53 NotFound plobsing: I usually use uglier words.
16:54 cotto_work atrodo: in theory they don't have to be if the interp is smart enough to generate machine code from M0, but otherwise the difference will be jumping to other M0 code vs calling native code.
16:54 hercynium joined #parrot
16:59 darbelo joined #parrot
17:03 dngor left #parrot
17:11 atrodo hmmm.  Well, here's another musing then.  There has to be some kind of stub that turns the arguments passed to ffi onto the c stack, right?  Or am I missing something else?
17:12 cotto_work atrodo: I don't think you're missing anything
17:12 cotto_work we need thunks to be generated one way or another
17:13 atrodo Then, are all calls outside of M0 ffi?
17:13 cotto_work what else would they be?
17:13 cotto_work ah
17:13 plobsing full ffi is way too much to be in M0
17:13 cotto_work atrodo: are you asking about Parrot-internal vs everything else?
17:14 mtk left #parrot
17:14 atrodo Well, if you have to call a thunk somewhere, then why not C code that acts like a thunk and bypasses the call to nativce C
17:14 atrodo to native C stack.  Hmm, not sure how to word that exactly
17:14 cotto_work plobsing: I agree.  The question is "What primitives can M0 supply that will be sufficient to build a full ffi?"
17:18 plobsing be able to call functions and function pointers. the signature of both is known statically and the reference of the first is known statically. these need to be exposed to M0. doing things similar to anything currently described as "ffi" runs counter to this.
17:18 atrodo cotto_work> more or less that's the path I'm going down
17:19 cotto_work plobsing: does M0 also need to expose a way to look up the name of a function?
17:20 plobsing cotto_work: pointer -> name lookup? definitely not.
17:20 mtk joined #parrot
17:20 cotto_work plobsing: no.  name -> pointer lookup
17:21 atrodo cotto_work> basically dlfunc?
17:21 plobsing cotto_work: no. that can be accomplished by static ccalling dlfunc
17:21 atrodo cotto_work> or something more?
17:21 plobsing meaning a full NCI can be built on top of M0
17:21 cotto_work atrodo: basically dlfunc
17:22 plobsing M0's NCI does not need to be and should not be built around dlfunc
17:23 cotto_work plobsing: So the M0 interp would call dlfunc during compilation (or interpretation) to look up a function name without directly exposing dlfunc?
17:23 cotto_work er, to look up a function poitner
17:23 cotto_work *pointer
17:24 plobsing cotto_work: that could work
17:25 cotto_work plobsing: what were you thinking?
17:25 plobsing but it might make interpretation pretty slow
17:26 plobsing cotto_work: I'm not entirely sure
17:27 atrodo cotto_work> so would these function pointers would be wrapped PMCs?
17:28 cotto_work atrodo: not sure
17:30 pjcj left #parrot
17:31 plobsing cotto_work: somehow you need to limit lookups to constant reference and calls to constant signature (to enforce static knowledge of both)
17:32 contingencyplan joined #parrot
17:34 cotto_work plobsing: yes.  I'm thinking about the best way to do that.
17:34 pjcj joined #parrot
17:35 pjcj left #parrot
17:36 pjcj joined #parrot
17:44 cotto_work A slow first implementation is fine if it doesn't preclude a faster implementation once we understand the problem space better.
17:45 Coke ... that sounds like parrot
17:46 JimmyZ left #parrot
17:53 lucian left #parrot
17:53 Andy left #parrot
17:53 theory left #parrot
18:03 mj41 joined #parrot
18:05 atrodo cotto_work> what if M0 only exposed a thunk API?
18:07 atrodo wrapping the function pointer/signature in a PMC
18:08 dngor joined #parrot
18:10 cotto_work atrodo: that sounds too high-level for M0
18:12 atrodo cotto_work> I was imagining it would be a call to a C level function with the context/interp
18:12 darbelo left #parrot
18:17 cotto_work atrodo: where are you thinking that the thunks would live?
18:17 davidfetter joined #parrot
18:18 whiteknight NotFound: ping
18:20 atrodo cotto_work> they'd have to be written in c, wouldn't they?  Or am I missing the question?
18:23 cotto_work atrodo: right.  How would those functions be accessible to M0 and how would an M0 interp know to turn a sequence of instruction into a call to the right thunk?
18:23 benabik joined #parrot
18:25 atrodo cotto_work> I would imagine it would controlled by a PMC that holds the address of the thunk (unless the thunk never changes), the function pointer and the signature
18:26 whiteknight msg NotFound: I found a winxed bug. I submitted an issue #22.
18:26 aloha OK. I'll deliver the message.
18:29 ShaneC left #parrot
18:30 cotto_work atrodo: for now I'm trying to think about this without the abstraction of PMCs.  Once we know what M0 instructions need to be generated and what the interp will need to do with them, we can figure out how they'll interact with the object system.
18:31 cotto_work i.e. thinking about this in the simplest terms possible
18:31 atrodo hmmm, okay.  I'm at a loss at this point then
18:32 cotto_work I think we're closer to asking the right questions.
18:34 Andy joined #parrot
18:39 lucian joined #parrot
18:40 Coke Once we have M0, does there need to be any difference between a PMC and a class?
18:43 darbelo joined #parrot
18:43 cotto_work Coke: PMCs and object will be the same thign
18:45 ShaneC joined #parrot
18:45 Coke +1
18:47 NotFound whiteknight: looking
18:48 NotFound Mmmm... I thought a recent fix should caover that usage. Fail.
18:50 whiteknight I have an easy workaround now, but it was a little surprising at first
18:50 NotFound Looks like a silly mistake.
18:52 NotFound Caught!
18:55 whiteknight awesome
18:58 dalek winxed: r855 | NotFound++ | trunk/winxedst1.winxed:
18:58 dalek winxed: fix a mistake in null call arguments, Issue 22, whiteknight++
18:58 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=855
18:58 dalek winxed: r856 | NotFound++ | trunk/pir/winxed_compiler.pir:
18:59 dalek winxed: update installable compiler
18:59 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=856
18:59 benabik left #parrot
19:01 cotto_work andy++
19:01 Andy ?
19:01 whiteknight Andy always deserves karma, whether he knows it or not
19:02 Andy what now?
19:02 cotto_work in this case, adding PARROT_CANNOT_RETURN_NULL to the malloc family functions
19:03 cotto_work jfdi ftw
19:10 dodathome joined #parrot
19:19 NotFound There must be some reason for that amazing preference for zero: Parrot_ex_throw_from_c_args(INTERP, NULL, 0,
19:20 benabik joined #parrot
19:20 NotFound Don't people realize that zero is EXCEPTION_BAD_BUFFER_SIZE ?
19:21 NotFound I propose to unshift EXCEPTION_PROGRAMMER_TOO_LA​ZY_TO_CHECK_EXCEPTION_TYPES to exception_type_enum
19:22 cotto_work EXCEPTION_WHATEVER
19:22 NotFound No, it must be something embarrassing.
19:23 darbelo left #parrot
19:23 NotFound "the first types are real exceptions and have Python exception names" ---> Oh, nice, foreign legacy values.
19:24 plobsing EXCPTION_NO_APPROPRIATE_EXCEPTION_TYPE_FOUND
19:24 cotto_work NotFound: yeah.  That's pretty great.
19:24 NotFound plobsing: that will be a lie in most cases.
19:25 plobsing I used to look for exception numbers. Then I realized I couldn't find ones that really fit half the time, and that the people submitting bug reports haven't even looked at the number yet
19:27 whiteknight one day I hope we can move away from exception type numbers and start using proper subclasses of Exception for those things
19:27 whiteknight then it becomes moot, because you won't be passing a NULL type there. We'll have ASSERT_ARGS to prevent that kind of crap
19:28 NotFound The NULL in another song.
19:28 NotFound is
19:28 plobsing whiteknight: then that constant will merely become enum_class_Exception
19:29 plobsing the fact of it is that the number, or type of the exception is not being communicated to users, and that users would probably ignore it anyways
19:29 NotFound I can't imagine how that parameter might be used.
19:30 NotFound The NULL, I mean.
19:30 plobsing I thought it could be used with setjmp for resumable exceptions from C
19:30 plobsing or at least that was the intent
19:34 NotFound I completely fail to imagine how resuming to C can be used/useful.
19:35 NotFound Coupling pir handling with C level failures will be the most bizarre thing.
19:35 plobsing well we know that *now*
19:35 plobsing can you hop in your time machine and go back to say 2003 and beat some sense into whoever wrote this mess?
19:36 NotFound But I don't believe in resumable exceptions, so my view can be biased-
19:37 plobsing resumable exceptions are somewhat like inside-out AOP. considering AOP is inside-out to begin with, you'd expect to do a full 360 and get what you started with. Unfortunately, it doesn't work that way :(
19:37 Hackbinary left #parrot
19:42 whiteknight as far as I am aware, we only support resumable exceptions because Rakudo needs them
19:42 whiteknight which is a pretty good reason to do it
19:43 plobsing but resume-to-C exceptions?
19:44 whiteknight no, those I'm pretty sure are stupid
19:44 whiteknight especially since Parrot_ex_throw_from_c_args is marked DOES_NOT_RETURN or whatever, and much of our codebase expects that we do not resume at that point
19:44 whiteknight maybe we should make it explicit that exceptions can only be resumed if thrown from PIR
19:45 whiteknight and end this mess forever
19:45 plobsing if you're doing that, go all the way. Exceptions can only be resumed if they only *touch* PIR.
19:46 whiteknight no, you're right. That's what it should be
19:46 whiteknight thrown from PIR, handled by PIR, resumed back to PIR
19:46 NotFound Looks sane to me.
19:47 whiteknight the less we interact with exceptions from C, the better
19:48 whiteknight the embedding API has to go through a lot of contortions to prevent them leaking out into embedding code
19:48 whiteknight IMCC writes its own exceptions system for basically the same reason
19:49 NotFound So we have a lot of code to prevent ugly effects of features that are impossible to use.
19:49 whiteknight right
19:49 atrodo seems totally legit to me
19:50 plobsing impossible to use sounds like a challenge ;-)
19:51 plobsing although I'll grant that they are impossible to use for anything useful
19:51 whiteknight exceptions may be something we really want to talk about overhauling this year
19:52 NotFound plobsing: given the status of the code base, I think they are imposiible to use at all.
19:52 whiteknight the embed api cleanup was a key enabling factor for that kind of work. The IMCC stuff is going to isolate and simplify a lot of exception handling there, which will be nice
19:53 plobsing whiteknight: how is the IMCC work comming?
19:53 whiteknight plobsing: I've been mulling over the last steps in my head. As soon as I can convince myself that it would be more fun to work on that than on Rosella, I'll finish it
19:54 whiteknight so far, it's not an argument I've been able to win
19:54 NotFound You can fill a winxed Issue: "It's too fun"
19:55 whiteknight although now that mockobjects are working the way I want them to, I have no other big Rosella projects in mind in the near-term
19:55 atrodo whiteknight> hint, rewrite IMCC in winxed
19:55 whiteknight atrodo: It's more tempting than you think
19:55 plobsing whiteknight: IMCC compregs are some of the last things that use "J" NCI signatures (which I'm trying to rip out)
19:55 whiteknight plobsing: in the branch, those are all gone
19:55 NotFound atrodo: there is an early attempt of that in winxed examples
19:55 atrodo whiteknight> that makes those some of my favorite jokes to tell
19:56 whiteknight plobsing: if you're going to be blocking on that issue, I'll push forward on it tonight
19:56 plobsing whiteknight: I may or may not be blocking on that issue soon.
19:56 whiteknight okay, I'll definitely work on it tonight. It shouldn't be too too much more work
19:56 plobsing I'm currently struggling with pmc2c to make multis use NativePCCMethods in stead of NCI
19:56 whiteknight that's assuming that I know about all the remaining bugs
19:56 whiteknight Oh, goodluck with that
19:57 plobsing I hate our tools. So much.
19:57 whiteknight tell me about it
19:58 whiteknight if winxed were part of core Parrot, I would rewrite our old perl tools in winxed just for the sheer fun of it
19:58 theory joined #parrot
19:58 * lucian dislikes nci
19:58 plobsing lucian: for this particular usage, or in general, and if so why?
19:58 whiteknight If I didn't mind a 37-stage recursive build with no clear bootstrapping stage, I would rewrite parrot in winxed
19:59 NotFound whiteknight: maybe someday... ;)
20:00 plobsing whiteknight: just do what Ωη does - package all the generated files
20:00 plobsing users don't need to bootstrap
20:00 lucian plobsing: in general, because it seems to claim to only support a subset of dyn lib usage
20:01 NotFound And what winxed itself does for the benefit of plumage installs
20:02 NotFound In fact we can ship winxed with parrot just by adding two pir generated files.
20:02 plobsing lucian: sure. but the same can be said of C.
20:02 plobsing or anything else that isn't assembly
20:03 lucian plobsing: i may be wrong, but i understood that nci doesn't support certain things that libffi does
20:03 benabik left #parrot
20:03 plobsing lucian: yes. that is in order to make it easier for implementations where libffi isn't available.
20:04 plobsing if you'd like, you can create a wrapper to libffi, bundle it up, and tell users that don't have it to get lost.
20:04 lucian plobsing: are there interesting platforms without libffi?
20:05 plobsing lucian: most windows platforms
20:05 lucian plobsing: uh, no
20:05 NotFound That counts as "interesting"?
20:05 plobsing NotFound: from a "how the hell do people put up with this?" perspective, yes
20:05 lucian i mean it works on windows
20:06 plobsing lucian: there are APIs that libffi is incapable of calling
20:06 lucian plobsing: like COM you mean?
20:07 plobsing some proprietary C compiler can come out tomorrow with a "best ABI yet" calling convention that is totally incompatible with anything else. boom, all of a sudden incompatible
20:07 plobsing or how about if systems start getting written in Go, and shared objects contain functions with multi-returns?
20:08 lucian plobsing: can NCI handle that better?
20:08 plobsing no, it cannot. I'm making the point that, whatever the system, it will not cover all cases, and therefore the fact that our NCI doesn't cover all cases is not much of a fault.
20:09 NotFound There's nothing I can do, a total eclipse of the ABI.
20:09 lucian plobsing: but isn't choosing the system that covers the most cases (and has the most usage already) better?
20:09 plobsing the only VM I know of that is capable of such things is Factor. but that's because they've built in their own assembler.
20:11 plobsing lucian: more is better, everything else being equal. however, if exposing libffi's capabilities add significantly to the complexity of both the API and the implementation, it is important to take that into consideration as well.
20:12 lucian plobsing: does it? i would guess it would do the opposite
20:12 plobsing Any sufficiently capable FFI system will reinvent half of C's type system. Poorly.
20:13 whiteknight more or less poorly than C's type system?
20:13 dalek parrot: 8ca9a58 | petdance++ | / (6 files):
20:13 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
20:13 dalek parrot: review: https://github.com/parrot/parrot/commit/8ca9a58c75
20:13 dalek parrot: c2b6ced | petdance++ | config/gen/makefiles/root.in:
20:13 dalek parrot: ratcheting down some splint warnings
20:13 dalek parrot: review: https://github.com/parrot/parrot/commit/c2b6ced6a1
20:13 whiteknight a poor reimplementation of a poor system might turn out quite nicely
20:13 lucian plobsing: perhaps. but is NCI's poor implementation better than libffi's poor implementation?
20:13 whiteknight "oh no, we failed to fail as badly"
20:13 lucian whiteknight: the best example i know of that is wine
20:13 Andy cotto_work: The PARROT_CANNOT_RETURN_NULL stuff isn't likely to be much use, because few things acutally use them.
20:14 Andy If I can work it into the GC API, then we've got something.
20:14 plobsing lucian: parrot's NCI is capable of bootstrapping full LibFFI, if you choose to do so. we prefer to hide the choice of library as an implementation detail.
20:15 plobsing partly because we don't want to make libffi a hard dependancy, and partly because libffi is inherently inefficient.
20:15 lucian plobsing: are there better docs on NCI?
20:15 plobsing better than what?
20:15 lucian docs.parrot.org
20:16 plobsing no idea. I haven't used those in months. probably not. mostly it is by example, or read the source.
20:17 NotFound whiteknight: talking about bootstrapping problems, I wonder if it might be possible to rewrite winxed tests using Rosella.
20:18 whiteknight NotFound: I've been treating Rosella as the "standard library" for winxed, in my head
20:18 whiteknight but yes, that does create a pretty big bootstrapping problem
20:18 whiteknight because Rosella itself uses most winxed syntax
20:19 NotFound As long as they are not used by the compiler nor required for programas unless they explicitly ask, there must not be problem to have a bunch of libraries declared as "standard".
20:20 whiteknight like I said, it's all in my head. Some of the libraries are starting to seem pretty useful to me
20:20 NotFound That was the intention, wasn't it?
20:21 whiteknight about 50%
20:21 whiteknight the rest was me having fun (20%) and avoiding work on IMCC (30%)
20:22 whiteknight :)
20:23 NotFound Avoiding to write pir was the main reason that came winxed to existence :D
20:24 NotFound Having fun... that's more or less the same.
20:24 * lucian thinks programmer laziness is the biggest drive for useful programs
20:24 whiteknight yes, the amount of PIR you have to write is inversely proportional to the amount of fun you have
20:24 bacek ~~
20:24 bacek Good morning, humans
20:24 whiteknight hello bacek
20:25 bacek aloha, whiteknight
20:25 Coke as a constrast, I find writing PIR to be much more straightforward than getting PCT to do what I want. YMMV.
20:26 benabik joined #parrot
20:26 NotFound Coke: that's why I choosed to directly generate the pir.
20:28 * Coke wonders why Andy just did a merge from master to master.
20:29 Coke ENOREBASE?
20:29 whiteknight he just wanted to show master who's the boss
20:29 Andy Coke: I don't know why that happens.
20:29 Coke that's a pretty big commit with a lot of changes then.
20:30 Coke You might want to do "git pull -rebase" instead of "git pull"
20:31 Coke er, --rebase
20:31 plobsing alias pullr = pull --rebase
20:31 plobsing in gitconfig
20:32 Coke I prefer 'rb', but yah. ;)
20:32 bacek bad idea
20:33 plobsing bacek: why?
20:33 bacek better to put 'rebase = "true"' into .git/config 'branch "master"' section
20:33 plobsing that's neat
20:34 tadzik and has to be done for every repo
20:34 bacek and [branch] autosetuprebase = always
20:34 bacek than new branches will be rebased by default
20:34 benabik Don't need the '= "true"'.  Just 'rebase' on a line of its own is enough.
20:35 bacek It's without quotes anyway :)
20:35 whiteknight not even. All you need is the word "rebase" in a file hidden somewhere in /opt/local/
20:37 lucian it can even be in a different language, git will try and use dictionaries
20:37 lucian it will even deal with rot13
20:37 * lucian has probably gone too far
20:38 plobsing lucian: I heard you liked version control. So I put your gitconfig in a git repo so you can commit while u commit.
20:39 whiteknight sup dawg. I herd you liek git. So I put git in a repository so you can git get git while you git git.
20:39 lucian heh
20:40 whiteknight as a general observation, I don't think we are referring to each other as "dawg" enough in the channel
20:40 cotto_work +1
20:40 cotto_work er, +1 dawg
20:40 whiteknight word
20:40 lucian is now known as dawg
20:41 atrodo dawg, too true
20:41 dawg whiteknight: better?
20:41 whiteknight much better
20:41 whiteknight *much better, dawg
20:43 bacek cotto, jfyi minimal freeze/thaw fail is "class Foo{}; pir::thaw__ps(pir::freeze__sp(Foo.new))"
20:44 cotto_work hard to get more minimal than taht
20:44 cotto_work *that
20:44 cotto_work bacek: do you know what causes it to fail?
20:45 bacek cotto_work, no idea...
20:46 whiteknight is that in master?
20:46 cotto_work ./parrot-nqp -e "class Foo{}; pir::thaw__ps(pir::freeze__sp(Foo.new))" fails nicely for me
20:46 cotto_work in master
20:47 cotto_work no segfaults, which I guess is nice
20:47 whiteknight Can't shift from an empty array?
20:47 cotto_work not even if you wish really hard
20:47 whiteknight no, is that the error you're getting?
20:48 cotto_work that too
20:48 bacek whiteknight, this one
20:49 plobsing left #parrot
20:50 ambs left #parrot
20:50 M_o_C joined #parrot
20:51 whiteknight I assume the problem has something to do with NQP/P6object?
20:51 whiteknight or is it pure-parrot?
20:51 bacek P6object
20:51 whiteknight okay
20:55 bacek meh... Capture PMC isn't freezing properly.
20:57 whiteknight somebody actually uses Capture?
20:57 whiteknight I didn't realize NQP was using it
20:59 bacek PCT is using it
20:59 bacek PCT::Node is Capture
20:59 whiteknight it doesn't look like Capture implements VTABLE_freeze or VTABLE_thaw
21:06 fperrad left #parrot
21:07 Andy Coke: I usually DO a git pull --rebase.
21:07 Andy I even have git pull --rebase origin master to "gprom"
21:07 dalek parrot: 47dd195 | bacek++ | t/pmc/capture.t:
21:07 dalek parrot: Add todoed tests for Capture.freeze/thaw.
21:07 dalek parrot: review: https://github.com/parrot/parrot/commit/47dd19546d
21:07 dalek parrot: 4ca6805 | bacek++ | / (2 files):
21:07 dalek parrot: Implement Capture.freeze/thaw. Closes #2047
21:07 dalek parrot: review: https://github.com/parrot/parrot/commit/4ca680573d
21:08 bacek It was quick :)
21:09 dalek TT #2047 created by bacek++: Capture PMC doesn't freeze/thaw.
21:09 dalek TT #2047: http://trac.parrot.org/parrot/ticket/2047
21:09 dalek TT #2047 closed by bacek++: Capture PMC doesn't freeze/thaw.
21:09 dalek TT #2047: http://trac.parrot.org/parrot/ticket/2047
21:12 whiteknight so quick that you fixed it before you opened the ticket, apparently
21:13 NotFound Tunnel effect commit!
21:15 * bacek waves from THE FUTURE
21:18 * dukeleto barfs from the past
21:20 plobsing_ joined #parrot
21:20 * atrodo ponders from the present
21:24 dalek parrot: 276554b | bacek++ | src/pmc/capture.pmc:
21:24 dalek parrot: Set custom_mark flag in Capture.thaw when needed.
21:24 dalek parrot: review: https://github.com/parrot/parrot/commit/276554b22b
21:27 Coke Andy: perhaps dukeleto knows why you're getting those merge commits, then.
21:27 Coke dukeleto: in re: andy's commits to master today.
21:28 dmalcolm joined #parrot
21:28 Andy Coke: I think that one was an attempted rebase that failed.
21:28 Andy I only had the one, right?
21:28 Coke a pair: one real commit, one rebase
21:29 mtk left #parrot
21:30 whiteknight left #parrot
21:30 mtk joined #parrot
21:30 dalek parrot: fabdef9 | petdance++ | config/gen/makefiles/root.in:
21:30 dalek parrot: improve splint error messages
21:30 dalek parrot: review: https://github.com/parrot/parrot/commit/fabdef9ddd
21:46 Andy left #parrot
21:48 dukeleto Coke: the merge commits are from doing "git pull origin master"
21:55 hercynium left #parrot
21:56 dawg left #parrot
22:03 dodathome left #parrot
22:07 cotto_work bacek++
22:20 jnthn left #parrot
22:28 jnthn_ joined #parrot
22:30 M_o_C left #parrot
22:52 plobsing_ left #parrot
22:59 Coke dukeleto, andy: sounds like had diagnosed it right, then, as he said he had a failed rebase.
22:59 dukeleto Coke: failed rebase?
23:00 rurban_ joined #parrot
23:00 dukeleto Coke: git_workflow.pod describes the situation in detail
23:01 dukeleto Coke: meaning he gave up on the rebase and just did a pull ?
23:01 dukeleto Coke: not a huge deal
23:01 dukeleto Coke: just annoying when history is filled with useless merge commits
23:02 rurban left #parrot
23:02 rurban_ is now known as rurban
23:51 dmalcolm left #parrot
23:52 plobsing joined #parrot
23:52 kid51 joined #parrot

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced