Camelia, the Perl 6 bug

IRC log for #parrot, 2010-12-06

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:04 lucian chromatic: seems to be about 3-4 files of 0.5k lines each
00:04 lucian that includes the gc framework in pypy i think
00:04 lucian not sure if i'm missing anything
00:04 chromatic That could be some 3 or 4k lines of C then.
00:06 lucian chromatic: hmm. sad that you can't write a GC in a GC-ed language :)
00:06 lucian well, you can if it's RPython
00:06 chromatic Or an ML derivative or Smalltalk.
00:07 chromatic Probably Haskell, but my first Pugs patch led me to find a bug in Haskell's GC, which is both ironic and metacircularly type safe.
00:07 * lucian wishes D was more mature and parrot used it
00:07 lucian chromatic: heh
00:10 lucian chromatic: i'm wondering if PyPy's could be reused without having to write all of parrot in RPython. probably not
00:12 chromatic I'm sure there are concepts we can borrow, but its GC probably makes assumptions about memory allocation that Parrot currently can't.
00:13 Infinoid kid51: I think it's a reference to Lorito
00:15 jsut_ left #parrot
00:19 lucian chromatic: ah, i miscounted
00:20 lucian semispace is 700 loc
00:20 lucian generational is 600 loc extra
00:21 jsut joined #parrot
00:21 lucian hybrid is 560 loc extra, complete with ascii graphics of the memory model (how cool is that?)
00:21 lucian it all depends on the pypy backend memory handling
00:23 chromatic How does any MOP work change Lorito work?
00:23 * lucian is still confused about what exactly lorito is
00:24 chromatic It's our RPython.
00:24 lucian the wiki gave me a somewhat different impression
00:25 nwellnhof joined #parrot
00:25 lucian lorito looked to me to be very low-level, a textual representation of bytecode
00:25 * whiteknight has to take out trash. be back in ~10
00:25 cotto chromatic, I assume that there are ways that Lorito can make the mop implementation easier or harder
00:25 lucian with higher level system languages (RPython-style) targeting lorito
00:25 chromatic I don't see how.
00:26 chromatic To me, that's like saying that C can make the MOP easier or more difficult.
00:26 chromatic To the degree that C or Lorito does, it does so for every other part of Parrot.
00:27 jnthn I agree with chromatic here to some degree. Yes, Lorito *could* make it impossible to implement a MOP efficiently, but if it does, it probably hurts a bunch of other subsystems too.
00:27 * tcurtis will be afk for a while due to eating dinner.
00:27 lucian what worries (and confuses) me is how PMCs/objects will look like in a MOP world
00:27 lucian but i also don't see how that affects the implementation language
00:27 lucian or the other way around
00:28 chromatic From the Lorito POV, a PMC or Object is a chunk of memory.
00:28 cotto If nothing else, I want to be sure not to do anything braindead.
00:29 jnthn chromatic: From the 6model point of view, everything (other than unboxed types) is a chunk of memory, the first thing of which happens to be a pointer to an S-Table. :)
00:29 chromatic jnthn, does your representation model prefer accessing attributes/methods as offsets into a chunk of memory?
00:30 jjore left #parrot
00:30 jnthn The representation model isn't really about methods. But attributes, yes.
00:30 jnthn How much it wants to twiddle depends on the representation though.
00:31 jjore joined #parrot
00:31 chromatic I'm assuming you want to store methods efficiently and look them up super efficiently, even resolvable statically when possible.
00:31 chromatic But sure, attributes stored that way.
00:32 jnthn chromatic: Yes/no. The authoritative information on methods is however the meta-object decides to store them - probably in a hash table.
00:32 jnthn chromatic: The meta-object can choose to pubhlish a v-table.
00:32 chromatic In that case, Lorito needs to make hash tables possible and allow offset access into chunks of memory.
00:33 jnthn chromatic: Which hangs off the S-table.
00:33 lucian but then again, hash tables are common enough that if they weren't possible in lorito, it wouldn't be much use anyway
00:33 chromatic Right.
00:34 jnthn So anything statically resolved (or at lesat, that still needs a virtual lookup) is just a couple of pointer follows away to the invokable thingummy.
00:34 gg411 joined #parrot
00:34 AndChat- left #parrot
00:35 lucian jnthn: i like your 6model thing
00:35 lucian it's similar in concept to how i'd see python objects bootstrapped
00:35 chromatic What's an s-table, by the way?
00:35 jnthn chromatic: There's one of them per (meta-object, REPR) pairing.
00:36 jnthn chromatic: s came form "shared" (as in, shared between all objects with a specific REPR and HOW)
00:36 jnthn er, s/a specific/the same/
00:37 jnthn chromatic: A few other things hang off it, but that's the main idea.
00:37 chromatic Why the pairing of REPR and MO?
00:37 jnthn chromatic: For the common use case there's only one of them for a given type declration, because most people only ever use a given class with one representation.
00:38 chromatic Why the separation?
00:39 jnthn chromatic: Using diferent REPRs with one MO is what representation polymorphism means.
00:39 jnthn chromatic: http://6guts.wordpress.com/2010/10/15/slides-a​nd-a-few-words-on-representation-polymorphism/ explains the thinking behind this.
00:40 chromatic Ah right, i'd read that.  Thanks.
00:41 chromatic Makes sense.
00:41 nwellnhof also seems to be a useful generalization outside of perl6
00:41 lucian jnthn: interesting
00:45 * jnthn needs sleep, gotta do some $dayjob tomorrow :)
00:45 cotto jnthn, 'night
00:45 cotto thanks for dropping by
00:51 AndChat| joined #parrot
00:51 gg411 left #parrot
00:56 tcurtis left #parrot
01:09 tcurtis joined #parrot
01:49 tcurtis left #parrot
02:01 AndChat| left #parrot
02:02 gg411 joined #parrot
02:05 whiteknight plobsing: ping
02:07 AndChat| joined #parrot
02:07 plobsing whiteknight: pong
02:07 whiteknight plobsing: I have some small ideas for NCI stuff that I wanted to run past you
02:07 plobsing shoot
02:08 whiteknight I'm thinking we create an abstract NCIThunkBase PMC types, and all NCI thunk generators inherit from that and expose a common interface
02:08 whiteknight so the libffi stuff gets ported to a PMC type inheriting from it
02:08 whiteknight should lead to a lot less boilerplate code for people looking to implement new variants
02:08 plobsing there is already an implicit API required of thunk generators. unfortunately, it is only well defined in the code and in my head.
02:09 whiteknight right, but I'm saying we create a PMC for it and inherit
02:09 whiteknight same general idea, but less work for implementors
02:09 lucian is raw libffi exposed at pir-level?
02:10 plobsing I don't see much in the way of boilerplate in the current ffi thunk implementation. Care to give examples?
02:10 lucian languages might already have a ffi implemented on libffi
02:10 plobsing lucian: no. it is abstracted
02:10 plobsing so that you could use something more efficient, should you choose.
02:10 whiteknight plobsing: for instance, in class_init where we register the generator. We can abstract that away into a method, and let the user select generators on the fly
02:10 gg411 left #parrot
02:11 whiteknight and a method to clear the cache when we want to switch
02:11 plobsing why clear the cache? they should all behave the same way, even if they are different under the hood.
02:11 plobsing and clearing the cache is about 3 lines of PIR
02:11 whiteknight timing comparisons, etc
02:13 whiteknight it was kind of bugging me that the libffi implementation was so different from other implementations, and I was looking to unify and share code where possible
02:13 plobsing which other implementations? the static one? the libjit one?
02:14 plobsing I agree a well defined interface would be of benefit. I don't see a base class as the ideal mechanism for doing that.
02:14 whiteknight well the libjit one you have, and the LLVM one that exists in my head
02:14 whiteknight that's fine too. It was just an idea
02:14 whiteknight you're the expert, so I wanted your input
02:18 plobsing I can put up a doc somewhere detailing the thunk generator side of NCI. Where should it sit? POD inside src/nci/libffi.c? I don't like making new documentation files (we already have too many scattered about).
02:18 whiteknight that's good
02:19 kid51 What does MOP mean again?
02:19 whiteknight metaobject protocol
02:20 cotto aloha, mop?
02:20 aloha cotto: I have no idea.
02:20 cotto aloha, mop is meta-object protocol
02:20 aloha cotto: Okay.
02:21 whiteknight I was hoping to see bacek here tonight
02:21 cotto it's a bad time for him unfortunately
02:21 whiteknight yeah, I know
02:21 whiteknight next time
02:22 whiteknight next time we can shift the time ahead 8 hours to get other hemispheres involved
02:22 cotto In general my Sundays should be less constrained
02:22 lucian left #parrot
02:23 Util kid51: MOP is very simply explained in jnthn's excellent slides: http://www.jnthn.net/paper​s/2010-osdc.fr-rakudo.pdf
02:32 nwellnhof left #parrot
02:34 * Coke wonders if the 6guts blog is in the planet six family.
02:38 kid51 Posted summary of action items to parrot-dev.  Corrections?   Respond to that post.
02:39 kid51 Coke:  It *ought* to be.
02:40 Coke I haven't read any blog posts by jnthn lately, so I'm guessing not. You have a url?
02:40 * Coke finds http://6guts.wordpress.com/feed/
02:41 Coke ah, he hasn't posted since nov 01
02:43 * dukeleto enjoyed PDS greatly
02:44 whiteknight yes, it was excellent
02:44 cotto I'm making a note here: huge success.
02:44 whiteknight cotto: it seems like you and I should have a chat about roadmap items. Where/when you want to do that?
02:45 shockwave joined #parrot
02:45 cotto Do weekday evenings work for you in general?
02:46 whiteknight yessir
02:46 shockwave Hello.
02:46 whiteknight what "works for me" is far less restrictive than what "works for my wife"
02:46 whiteknight but yes, weekday nights are good
02:46 whiteknight hello shockwave
02:47 cotto whiteknight, how about Monday evening.
02:47 whiteknight perfecy
02:47 whiteknight perfect
02:47 cotto 6PM PST?
02:47 Coke dukeleto: reading through old tickets - rejecting tickets /just/ because they are old: -1.
02:48 shockwave I just finished reading your latest blog entry. So... that Parrot api branch is going... well?
02:48 Coke er, reading through *PDS.
02:48 dukeleto Coke: old != not touched in >= 1 year
02:48 cotto so 8PM for you iirc
02:48 dukeleto Coke: but more criteria are welcome
02:48 dukeleto Coke: some tickets are unclosable and are just dead weight
02:48 whiteknight shockwave: very well. Primary development is complete. We're working out bugs and kinks, but otherwise it's going very well
02:49 whiteknight cotto: 8pm is good
02:49 cotto alright
02:49 whiteknight shockwave: are you on Mac?
02:49 shockwave whiteknight: Windows 7
02:49 dukeleto whiteknight: Getting PL/Parrot to work on the new embed_api branch could be a fun GCI task. What do you think?
02:49 Coke just because a ticket hasn't been touched does not a priori mean it is untouchable.
02:49 dukeleto whiteknight: getting it to compile
02:49 shockwave whiteknight: If I were to start using it tomorrow, are there some things that I couldn't yet do with it?
02:50 dukeleto Coke: i agree. But still, some tickets are ancient and unclosable.
02:51 dukeleto whiteknight: also, i have a github repo for GCI task templates. It should make your life easier
02:53 whiteknight shockwave: it depends what all you want to be doing. We have everything you need to create an interpreter, load bytecode, create objects and call methods
02:53 whiteknight dukeleto: PL/Parrot on embed_api is a good task, yes
02:53 whiteknight dukeleto: github repo for it sounds very good too. I'll check it out
02:54 atrodo whiteknight> how far away are we from being able to load a compiler, pass it some code, and get a callable?
02:54 atrodo code == a string
02:54 dukeleto whiteknight: https://github.com/leto/gci
02:54 dukeleto whiteknight: feel free to fork it, it has some templates and I started keeping track of tasks that I create in there
02:54 whiteknight atrodo: Don't have a function yet to register a compiler, but that's high on the priorities list
02:54 dukeleto whiteknight: there is a parrot task template and a parrot translation task template
02:55 whiteknight atrodo: especially if we want to move IMCC out of libparrot eventually, it will need that interface
02:55 dukeleto whiteknight: it has a bunch of links and instructions pre-populated, so you only have to write the task description
02:55 whiteknight dukeleto: awesome. I think we may want it for GSoC too, or something like it
02:55 atrodo whiteknight> good, that's the big thing I struggled with
02:55 dukeleto whiteknight: indeed. I've learned that I need to create meta-tasks and instantiate them multiple times
02:55 whiteknight atrodo: what compiler are you trying to register/use?
02:56 atrodo whiteknight> any besides IMCC
02:56 whiteknight dukeleto: good, we're becoming more efficient!
02:56 whiteknight atrodo: ah, good choice :)
02:56 atrodo whiteknight> but i think i was focusing on nqp-rx
02:56 whiteknight ok
02:57 shockwave whiteknight: Well, it sounds like you're confident the new API should allow developers to work effectively with Parrot. That's good.
02:57 atrodo whiteknight> https://github.com/atrodo/draak/blob​/master/src/TDraak/parrotdrv.pas#L96 was what I had gotten
02:57 whiteknight shockwave: in the branch, I've implemented most of the Parrot core utilities in the new API. Anything you can do with the Parrot executable from the command line, you can do through the API ow
02:57 whiteknight now
02:58 shockwave @whiteknight: That's great to hear.
02:58 dukeleto jnthn: i am reading your slides now. These are awesome!
02:58 whiteknight atrodo: oh cool. I keep meaning to read more about draak
02:59 atrodo whiteknight> If i remember correctly,  The key with "not imcc" was that using IMCC was fairly easy since it was exposed as a deceptively named function
02:59 whiteknight atrodo: there are lots of deceptively-named functions in Parrot
03:00 dukeleto atrodo: every subsystem has tight coupling to IMCC. It wasn't written as an isolated subsystem
03:00 shockwave anyone: I have a couple of questions about some general aspects of Parrot. First,
03:00 atrodo It was something like "compile_string".  "Perfect!  This will do what I want.  Oh wait, only PASM and PIR.  Drat"
03:01 whiteknight shockwave: ask away
03:01 whiteknight atrodo: in the new API, you'll get a compiler PMC, and call a method on it to compile
03:02 atrodo whiteknight++ # Much nicer sounding
03:02 shockwave Is it possible for a HLL language compiled to PIR to make use of C++ libraries? Specifically, the runtime I'll be using to embed Parrot is C++, and the native libs are essentially all written in C++. I've been searching the web for some information about the ability for Parrot to work with C++, but couldn't find much about it.
03:03 dukeleto shockwave: i believe it is possible
03:03 whiteknight shockwave: At the moment, I don't think we have explicit support for C++. I think our libffi system might be able to do it
03:03 dukeleto shockwave: winxed uses C++ at the core, iirc
03:04 whiteknight dukeleto: yes, but winxed embeds Parrot, not the other way around
03:04 shockwave dukeleto: Oh, yes. That's true. That was written by NotFound, correct?
03:04 shockwave whiteknight: Is libffi a core Parrot project, or an external project?
03:04 whiteknight it's external
03:04 whiteknight Parrot has optional bindings to it
03:05 shockwave whiteknight: I'm sorry, was I mean to ask was if the bindings are official or external. But, you answered the question. Thanks.
03:05 nopaste "plobsing" at 192.168.1.3 pasted "framebuilder.pod" (72 lines) at http://nopaste.snit.ch/26721
03:06 plobsing whiteknight: ^^ framebuilder documentation draft ^^
03:06 dukeleto shockwave: parrot will detect if you have libffi
03:06 whiteknight shockwave: we have bindings for it built-in. The Parrot configure process detects libffi and activates the bindings if it is installed
03:06 whiteknight plobsing++
03:06 dukeleto shockwave: it is used in our Native Call Interface (NCI) subsystem, which is just another word for FFI
03:06 shockwave whiteknight: sweet.
03:07 shockwave dukeleto: Awesome.
03:07 dukeleto shockwave: that came in when the gsoc_nci branch landed
03:07 dukeleto shockwave: it has not been put to full potential yet, though
03:07 whiteknight plobsing: to your knowledge, it is possible to call a C++ method through libffi?
03:08 whiteknight (the libffi docs I find are less than helpful)
03:09 shockwave ping NotFound
03:10 plobsing whiteknight: sure. sort of. C++ that abides the platform's C ABI should work fine.
03:10 whiteknight plobsing: so extern "C"?
03:10 shockwave whiteknight: you read my mind
03:11 plobsing you can't get at the functions using dlfunc unfortunately, due to name mangling. But you can generate a NCI PMC with a pointer and a signature.
03:11 shockwave That means then that it will only be possible to work with C++ global functions. Which, essentially is working with C.
03:11 plobsing not at all.
03:11 plobsing you just need a pointer to the method.
03:11 whiteknight plobsing: But a C++ method needs to pass the object reference too, which is typically out of band from the other args
03:12 whiteknight I don't think our NCI PMC allows specifying a C++ object
03:12 plobsing I'd expect C++ to use hidden parameters on the stack.
03:12 whiteknight (it *could* be made to do that, but I don't think it does)
03:12 plobsing all a C++ object is is a pointer
03:12 whiteknight on x86 for instance, C++ passes the object in ecx
03:12 whiteknight not on the stack
03:12 plobsing not C ABI
03:13 plobsing look, we can go down the slippery slope of supporting bindings to language X. but then we need to support Fortran, Modula-2, Pascal, whatever some dumb researcher thought was a good idea at the time.
03:15 plobsing for better or worse, C is a near-universal lowest-common-denominator.
03:15 plobsing for more complicated cases, you'll need to generate small shims
03:16 plobsing it's not so hard to do programatically
03:16 whiteknight no, it isn't
03:16 whiteknight I have been kicking around the idea of creating a C++ wrapper for the new API
03:16 whiteknight but that's a few weeks off, at least
03:18 dalek parrot/embed_api2: 3562b6b | (Mariano Wahlmann)++ | / (2 files):
03:18 dalek parrot/embed_api2: Unfished work implemented API functions
03:18 dalek parrot/embed_api2: review: https://github.com/parrot/parrot/commit/3562b6b4ba
03:18 dalek parrot/embed_api2: b5a2b99 | (Mariano Wahlmann)++ | / (23 files):
03:18 dalek parrot/embed_api2: Unfished work implemented API functions
03:18 dalek parrot/embed_api2: review: https://github.com/parrot/parrot/commit/b5a2b99e1e
03:18 dalek parrot/embed_api2: 0814f94 | (Mariano Wahlmann)++ | src/embed/api.c:
03:18 dalek parrot/embed_api2: Merged changes with branch
03:18 dalek parrot/embed_api2: review: https://github.com/parrot/parrot/commit/0814f941e9
03:18 dalek parrot/embed_api2: f0bd1e1 | (Mariano Wahlmann)++ | / (4 files):
03:18 dalek parrot/embed_api2: First cut of load_language, set_compiler, get compiler
03:19 dalek parrot/embed_api2: review: https://github.com/parrot/parrot/commit/f0bd1e1cf7
03:19 whiteknight bluescreen++
03:19 whiteknight atrodo: I think the api fairy just granted your wish
03:19 shockwave @plobsing: I understand what plobsing is saying, that its not possible to support every language out there. But, as a user, I actually need to be able to make things happen with Parrot. I *need* to be able to use C++. I don't care how hackish it is to make it happen, but if I can't use it, then it is not possible to a user like myself to create the software I'm lookig to make.
03:19 shockwave ^ I didn't mean to direct that at plobsing. That was a comment to no-one in particular.
03:19 * atrodo loves the api fairy
03:20 whiteknight shockwave: What you can do is create a series of small shim extern "C" functions, each one redirects to a C++ method call
03:20 whiteknight and call those from parrot
03:22 shockwave whiteknight: Ok, at least that's something; there's a way to make things happen.
03:22 bluescreen_ left #parrot
03:22 plobsing I would suggest you generate those shims programatically. You may need several very similar ones.
03:23 shockwave @plobsing: Do you mean by using something like swig?
03:24 whiteknight oh, I hadnt thought of swig
03:24 plobsing shockwave: possibly. or maybe something simpler. I generated a whole whack of libjit-shims for the libjit frame builder using a perl script.
03:24 whiteknight shockwave: probably not swig, but something like it, yes
03:24 whiteknight should be trivial with a short perl script or something
03:25 shockwave Ok, I'll explore that option.
03:25 shockwave Thanks for the answers. I have another question.
03:25 whiteknight sure
03:27 shockwave The whole reason I created a programming language was to write the logic for a 3D videogame I'll be working on (hopefully, starting this week). The videogame will be real time. I'll need...
03:27 shockwave I'm not too familiar with Parrots GC.
03:28 shockwave As you can image, with a real time system, the GC can become a bottleneck. Essentially, is it possible to control the GC?
03:28 shockwave Meaning, can I tell it not to collect?
03:29 shockwave ... when to collect memory, how much should be its buffer? Essentially, how flexible is the GC in terms of the runtime managing it.
03:30 plobsing gc pauses may be a problem. you can force a collect run (do it often enough, and they won't take as long). You can block GC by using the sweepoff instruction.
03:31 whiteknight there is an API function to turn it on/off
03:31 plobsing to see how bad our GC pauses are at the moment, try running examples/sdl/raw_pixels.pir.
03:31 plobsing there's a noticeable 0.5s? blip now and then
03:32 shockwave I would be interested in doing something like so: Tell the GC to allocate 100 mb, and not to auto-collect under any circumstances. Then, at some point, tell it to either/both: 1) perform a full collection. 2) Collect only for n milliseconds.
03:32 theory joined #parrot
03:33 cotto 2) is a realtime gc unless my brain deceives me
03:33 preflex left #parrot
03:34 whiteknight 1) should be possible without much work
03:35 whiteknight we have a function to trigger GC. We should be able to expose that through the API
03:35 whiteknight trouble is doing it in a way that doesn't expose too many details of GC internals
03:35 whiteknight short answer: very possible to manually trigger a collection
03:36 dukeleto shockwave: very interesting application. it sounds like you would greatly benefit from a real-time GC, which we don't have
03:36 shockwave whiteknight: Meaning that currently that ability is not exposed, but it's possible to code it in?
03:36 dukeleto shockwave: i am interested in real-time GC's for use on the RTEMS real-time embedded operating system
03:36 whiteknight shockwave: right. We have the ability internally. I should be able to expose it through the API cleanly
03:37 whiteknight shockwave/dukeleto: if somebody finds us a good algorithm for a real-time GC, we can start working on implementation
03:37 shockwave @dukeleto: it's just a 3D game. But, as you probably know, for a game, 30 millis at the wrong time destroys the illusion.
03:37 shockwave 30 millis of a blocking operation^^^
03:38 preflex joined #parrot
03:38 whiteknight shockwave: running Parrot (and therefore it's GC) on a separate thread might be nice, if possible
03:38 whiteknight do pause-y kinds of things in the backgroun
03:39 dukeleto whiteknight: JIT will require a seperate thread, so that feature will have to come soon
03:39 whiteknight brb
03:39 whiteknight true
03:44 kid51 left #parrot
03:56 shockwave Thank you for the answers, guys. To be honest, I'm at a point where I have to make some real, tough, descisions. In particular, will I be using Parrot as my runtime or not? I'm not sure if Parrot has what I need at the moment, and the honest truth is that I'm not sure when those features would be implement. I'm don't blame anyone for anything, it's just the state of affairs.
03:57 shockwave It would have been really nice to use Parrot, but I just may not be able to do it, because we may not be ready for each other.
03:58 shockwave I would like to say that I have nothing but respect for the people that I have dealt with in connection with Parrot. And that I hope thing go well for you guys.
03:59 shockwave As of now, I have to thing about my options at this point. Hopefully, we'll meet again in the future.
03:59 shockwave Regards,
03:59 shockwave Vladimir
03:59 plobsing ciao. good luck with the game.
04:00 shockwave @plobsing: thanks
04:00 shockwave left #parrot
04:00 cotto shockwave, best of luck.  I hope we can improve Parrot to the point where it's suitable for such applications.
04:03 whiteknight on that note, I'm off to bed
04:03 whiteknight goodnight
04:03 whiteknight left #parrot
04:27 cotto NotFound, ping
04:27 cotto aloha, clock?
04:27 aloha cotto: cotto: LAX: Sun, 20:27 PST / CHI: Sun, 22:27 CST / NYC: Sun, 23:27 EST / UTC: Mon, 04:27 UTC / LON: Mon, 04:27 GMT / BER: Mon, 05:27 CET / TOK: Mon, 13:27 JST / SYD: Mon, 15:27 EST
04:29 plobsing double cotto
04:34 cotto ?
04:34 plobsing aloha's clock is buggy.
04:34 aloha plobsing: Okay.
04:35 plobsing um... that was unintended
04:36 plobsing 's clock?
04:36 plobsing aloha's clock?
04:36 aloha plobsing: 's clock is buggy.
04:36 plobsing aloha: forget 's clock
04:37 aloha plobsing: I forgot about 's clock.
04:58 dalek TT #766 closed by cotto++: Documentation keyword tagging
04:58 dalek TT #766: http://trac.parrot.org/parrot/ticket/766
04:58 sorear what's wrong with aloha's clock?
04:59 sorear it has the right answer for LAX
04:59 plobsing aloha: clock?
04:59 aloha plobsing: plobsing: LAX: Sun, 20:59 PST / CHI: Sun, 22:59 CST / NYC: Sun, 23:59 EST / UTC: Mon, 04:59 UTC / LON: Mon, 04:59 GMT / BER: Mon, 05:59 CET / TOK: Mon, 13:59 JST / SYD: Mon, 15:59 EST
05:00 plobsing note the doubled up name
05:00 sorear ah
05:01 plobsing karma plobsing
05:01 aloha plobsing has karma of 200.
05:01 plobsing is now known as plobsing--
05:01 sorear PTR2INTVAL was inherited from the p5vm.  you should ask on #p5p why it is needed
05:01 plobsing-- aloha clock?
05:01 aloha plobsing--: plobsing--: LAX: Sun, 21:01 PST / CHI: Sun, 23:01 CST / NYC: Mon, 00:01 EST / UTC: Mon, 05:01 UTC / LON: Mon, 05:01 GMT / BER: Mon, 06:01 CET / TOK: Mon, 14:01 JST / SYD: Mon, 16:01 EST
05:01 plobsing-- karma plobsing
05:01 aloha plobsing has karma of 200.
05:01 plobsing-- aw, can't hack karma that way
05:02 plobsing-- is now known as plobsing
05:02 sorear IRC clients do not receive messages they send
05:11 bacek_at_work aloha, clock?
05:11 aloha bacek_at_work: LAX: Sun, 21:11 PST / CHI: Sun, 23:11 CST / NYC: Mon, 00:11 EST / UTC: Mon, 05:11 UTC / LON: Mon, 05:11 GMT / BER: Mon, 06:11 CET / TOK: Mon, 14:11 JST / SYD: Mon, 16:11 EST
05:11 bacek_at_work clock is fixed now
05:16 dalek parrot: f9c7b11 | cotto++ | src/call/args.c:
05:16 dalek parrot: add no-op spaces to pcc call parsing
05:16 dalek parrot: review: https://github.com/parrot/parrot/commit/f9c7b116f3
05:16 dalek parrot: 59bed18 | cotto++ | / (8 files):
05:16 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
05:16 dalek parrot: review: https://github.com/parrot/parrot/commit/59bed186e9
05:18 cotto dukeleto, ping
05:21 zby left #parrot
05:22 zby joined #parrot
05:25 * cotto is on a rampage of some sort
05:28 dalek parrot: b84615a | cotto++ | src/pmc/class.pmc:
05:28 dalek parrot: remove a pluggable MRO comment; if we want one we can figure out how to add it
05:28 dalek parrot: review: https://github.com/parrot/parrot/commit/b84615acd2
05:30 dalek TT #891 closed by cotto++: [TODO] allow spaces in nci function signatures
05:30 dalek TT #891: http://trac.parrot.org/parrot/ticket/891
05:30 dalek TT #1208 closed by cotto++: Optimize Parrot_pbc_read to do fewer stat() calls
05:30 dalek TT #1208: http://trac.parrot.org/parrot/ticket/1208
05:30 dalek TT #1256 closed by cotto++: src/pmc/class.pmc:  Need a pluggable MRO in instantiate() PMC
05:30 dalek TT #1256: http://trac.parrot.org/parrot/ticket/1256
06:03 dalek TT #1247 closed by cotto++: ar can't read libparrot.a on Mac OS 10.5.2
06:03 dalek TT #1247: http://trac.parrot.org/parrot/ticket/1247
06:21 davidfetter joined #parrot
06:33 PerlJam left #parrot
06:33 PerlJam joined #parrot
06:45 cotto bacek_at_work, thanks for the reply on the PTR2INTVAL ticket
06:45 cotto aloha, clock?
06:45 aloha cotto: LAX: Sun, 22:45 PST / CHI: Mon, 00:45 CST / NYC: Mon, 01:45 EST / UTC: Mon, 06:45 UTC / LON: Mon, 06:45 GMT / BER: Mon, 07:45 CET / TOK: Mon, 15:45 JST / SYD: Mon, 17:45 EST
06:45 cotto is now known as clock
06:45 clock aloha, clock
06:46 clock is now known as cotto
06:52 dalek parrot/leto/embed_grant: f390d57 | dukeleto++ | t/src/embed.t:
06:52 dalek parrot/leto/embed_grant: [t] Add a test for returning a Float PMC
06:52 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/f390d57bc5
06:59 cotto dukeleto, ping
07:01 theory left #parrot
07:10 * cotto sleeps
07:54 bacek joined #parrot
07:57 dukeleto # pop_pmc() not implemented in class 'ResizableFloatArray'
07:57 dukeleto really?
07:59 chromatic I believe it.
07:59 chromatic It'd be nice to avoid the m*n combinatorial explosion of typed registers and typed PMCs, if we had a good type inferencer which could make auto(un)boxing cheaper.
08:00 dukeleto chromatic: i realize the errors in my wasy
08:01 dukeleto ways, even.
08:06 chromatic Me too, such as it's midnight.
08:10 dalek parrot/leto/embed_grant: 43f8566 | dukeleto++ | t/src/embed.t:
08:10 dalek parrot/leto/embed_grant: [t] Tests for returning a ResizablePMCArray
08:10 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/43f85662ea
08:12 chromatic left #parrot
08:19 bacek aloha, humans
08:32 davidfetter left #parrot
08:35 davidfetter joined #parrot
08:42 fperrad joined #parrot
08:45 bacek fperrad, ping
08:47 fperrad bacek pong
08:48 bacek fperrad, I couldn't reproduce Lua's failures on my box.
08:49 bacek it is still failing on yours?
08:49 fperrad I'll check with a recent Parrot
08:50 bacek fperrad, ok, thanks.
09:11 Kulag left #parrot
09:12 Kulag joined #parrot
09:19 rfw left #parrot
09:28 lucian joined #parrot
09:31 Kulag left #parrot
09:32 Kulag joined #parrot
09:45 Kulag left #parrot
09:45 Kulag joined #parrot
09:52 davidfetter left #parrot
10:04 fperrad bacek, lua looks better, but still few segfaults in dynext/lua_group.so (Parrot_LuaTable_mark),
10:04 fperrad see http://smolder.parrot.org/app​/projects/report_details/1525
10:12 davidfetter joined #parrot
10:18 jsut_ joined #parrot
10:23 jsut left #parrot
10:26 dip joined #parrot
11:05 donaldh joined #parrot
11:09 davidfetter left #parrot
11:11 davidfetter joined #parrot
11:34 lucian left #parrot
11:57 davidfetter left #parrot
12:00 lucian joined #parrot
12:12 lucian left #parrot
12:18 lucian joined #parrot
12:29 Kulag left #parrot
12:29 Kulag joined #parrot
12:44 Coke (casting macros) Andy Lester might also know.
12:53 donaldh left #parrot
13:43 Patterner left #parrot
13:43 Psyche^ joined #parrot
13:43 Psyche^ is now known as Patterner
13:43 bluescreen joined #parrot
13:44 whiteknight joined #parrot
13:48 whiteknight good morning #parrot
13:49 lucian whiteknight: good afternoon :)
13:51 whiteknight hello lucian, how are you today?
13:52 lucian whiteknight: fine, I have a 4-page project proposal to write :)
13:53 whiteknight ah, I remember those days. I have fond memories of school
13:53 bluescreen good morning
13:55 whiteknight hello bluescreen, how are you:
13:55 whiteknight ?
13:55 bluescreen good back at the office...
13:55 whiteknight yeah. Mondays are the worst
13:56 bluescreen lol... even worst since I've spent last week in a training institute
13:56 bluescreen so I've 500 emails
13:56 whiteknight ouch
13:56 bluescreen 200 of them are an email thread of a baby born
13:57 whiteknight must have been a cute baby
13:57 bluescreen or the ugliest .... :D
13:57 bluescreen anyway nice PDS yesterday
13:58 whiteknight thanks! We had been planning it for a while
13:59 bluescreen I kept on thinking on the current state of PPDs/Docs in general and examples... It's really a lot of work to maintain them
13:59 whiteknight yes, it's a lot of work, and we haven't been keeping up with any of it
13:59 bluescreen and most of them are proof of concepts when parrot began
13:59 bluescreen like we can do opengl bindings or things like that
14:00 * Coke args as tickets with merit are closed because no one has done them yet.
14:01 whiteknight Coke: I think there is a disagreement over what constitutes "merit"
14:01 bluescreen the more i think about the more i think we should we rid of them and maybe start a new project for tutorials/examples
14:02 bluescreen in fact other projects like rakudo serve more as tutorials and examples than some of our docs and examples
14:03 whiteknight right, but reading the code is rarely as easy as reading the docs
14:03 lucian fwiw, i think an opengl binding on parrot isn't very useful for existing languages
14:03 whiteknight and users aren't going to be reading code to figure out how to do the things they want
14:03 Coke whiteknight: clearly.
14:03 Coke (re: merit)
14:03 whiteknight maybe as a last resort, but by that point there is already a level of frustration
14:04 whiteknight The only ticket closed this morning that I thought could have stayed alive was that MRO ticket
14:05 bluescreen yeah i agree we should provide a minimal set of docs.. and that should be all we care about
14:05 whiteknight but then again, I'm not going to implement it myself, and it probably conflicts with our efforts to build a new MOP, so whatever
14:05 whiteknight bluescreen: as was pointed out yesterday, the most important docs are for the user-facing things like the new API
14:06 bluescreen yes. I agree on that
14:06 whiteknight those docs should be complete, accurate, and helpful
14:06 moritz ... and up-to-date
14:07 whiteknight right, that falls under "accurate" in my mind
14:07 bluescreen but do you think we should maintain examples as well? the opengl one is a perfect example
14:09 whiteknight The OpenGL code should move out of the main Parrot repository and into it's own repository I think
14:09 whiteknight and the maintainers of it can include any docs or examples they want
14:09 bluescreen whiteknight: thats my point...
14:12 dalek tracwiki: v9 | coke++ | DocsTasklist
14:12 dalek tracwiki: Don't lose #766</a>, which is a good idea, even if no one wants to work on it right now.
14:12 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Do​csTasklist?version=9&amp;action=diff
14:39 whiteknight left #parrot
14:42 whiteknight joined #parrot
14:43 silug joined #parrot
15:48 plobsing left #parrot
15:48 allison joined #parrot
15:53 bluescreen left #parrot
15:56 allison_ joined #parrot
15:56 allison_ left #parrot
16:01 PerlJam left #parrot
16:02 PerlJam joined #parrot
16:10 bluescreen joined #parrot
16:26 dmalcolm joined #parrot
16:29 preflex left #parrot
16:31 preflex joined #parrot
16:35 cotto_work ~~
16:38 AndChat| left #parrot
16:41 gg411 joined #parrot
16:41 gg411 left #parrot
16:42 plobsing joined #parrot
16:47 theory joined #parrot
16:57 bluescreen whitekinght: +1 parrot_debugger
17:12 whiteknight thanks! I am really thinking it's not worth our time
17:13 whiteknight we do need to update pbc_merge to use the new API though. I had forgotten about that one
17:21 plobsing pbc_merge might be hairy. it pokes packfiles in ugly ways.
17:23 whiteknight doing this API work I've found several areas where we need to radically change packfiles to suck less
17:24 whiteknight I'm sure pbc_merge will expose more of those area
17:25 cotto_work whiteknight: where are you documenting those?
17:25 whiteknight cotto_work: I have an etchasketch in my head. Works great until I got jostled
17:26 cotto_work also, the third paragraph of your last blog entry looks truncated
17:26 whiteknight I'm actually writing lots of blogposts on all the things I find, though I'm not publishing nearly as often as I write them
17:27 whiteknight my drafts/ folder is becoming quite large
17:28 bluescreen whiteknight: I'm goint to implement tonight ( tomorrow maybe) Parrot_api_call_method
17:29 whiteknight cotto_work: yes, it does look truncated. Weird.
17:29 whiteknight bluescreen: I think I already did that
17:29 bluescreen really?
17:29 whiteknight double-check that I haven't put something in already
17:30 bluescreen i just pulled it and it doesn't seems to be there
17:30 whiteknight src/embed/pmc.c ata the bottom. Parrot_api_call_sub
17:30 bluescreen there you go
17:31 whiteknight basically a copy of Parrot_ext_call, but with CALLIN/CALLOUT macros added
17:31 gg411 joined #parrot
17:31 bluescreen I'm still thinking is way too much for the embedder
17:31 gg411 left #parrot
17:31 gg411 joined #parrot
17:31 whiteknight bluescreen: If you can think of a better way, put in a prototype
17:32 bluescreen yes... standardize compilers
17:32 bluescreen and call the standardized method
17:32 whiteknight bluescreen: That's for compilers. What about other object types?
17:33 bluescreen why would you need to call methods for them
17:33 bluescreen with that kind of power we're breaking the api encapsulation
17:34 whiteknight no you're not. You can create objects, call methods on them.
17:34 plobsing embedders should have roughly the amount of access PIR provides
17:34 whiteknight plobsing: exactly. Eventually PIR will be external to libparrot, and will only interact with libparrot through Lorito and the API
17:35 whiteknight bluescreen: Think about using libparrot as an object runtime instead of as the execution core. like a GObject replacement
17:36 whiteknight in that case, libparrot doesn't execute a "main" method, but would create and operate on objects
17:36 plobsing and the object registry is a reference counter of sorts
17:37 plobsing very much like GObject
17:39 whiteknight PMCs are really the primary interface to libparrot. You create them, pass them in, manipulate them, pass them out
17:39 whiteknight and methods are really the preferred public interface to PMCs
17:39 bluescreen yeah... I'm thinking libparrot as a VM, something that only interacts with the world in a controlled and defined way
17:39 bluescreen but this other way we're letting the real world interact with the objects
17:40 whiteknight so long as the objects provide a good interface, there's no reason to disallow access to them
17:41 plobsing I'd argue that the vtable-method duality is a horrible interface.
17:41 cotto_work plobsing: that's one of things in the crosshairs of the new object model
17:42 bluescreen whiteknight: in that case shouldn't we allow the "real world" create objects such as PMC_int PMC_float so the Parrot_api_call_method uses them
17:43 plobsing good. nuke it from space!
17:43 bluescreen otherwise they get 50% of the power
17:44 plobsing bluescreen: are you advocating for a Parrot_api_new_class()
17:47 whiteknight bluescreen: yes. The user will be able to create arbitrary objects by type name
17:47 whiteknight and the user will be able to register custom type libraries
17:47 whiteknight and the user will be able to create new types on the fly
17:48 * whiteknight is going to have to increase his blog publishing frequency to clear out the backlog of topics I need to talk about publicly
17:49 dukeleto whiteknight: i am not happy about how parrot_debugger's tests are commented out
17:49 bluescreen then I guess my idea of libparrot being just an interpreter are really gone
17:50 plobsing bluescreen: is there any VM out there that is "just an interpreter"?
17:50 dukeleto whiteknight: i spent a good amount of time adding tests to the debugger, then PaulTheGreek changed how the parrot_debugger worked and commented all the tests out
17:51 bluescreen good question... smalltalk's vm
17:51 bluescreen the image communicates with real world through primitives and not the other way around
17:51 plobsing smalltalk isn't just an interpreter. it's an OS (in the emacs-y sense).
17:52 preflex left #parrot
17:52 bluescreen pblosing: it's a VM in the strict sense ;)
17:55 whiteknight libparrot has to do a bunch of stuff that doesn't involve executing any bytecode. It has to help compilers create bytecode for instance, or do analysis on bytecode
17:55 whiteknight so those things are all going to avoid ever entering a runloop, but you'll still have objects and things you want to examine
17:55 preflex joined #parrot
17:56 whiteknight imagine a Parrot object server which creates objects and serializes them to a memcached instance for use later in other parrot instances
17:56 whiteknight that probably won't execute much bytecode, but will need to be able to create and manipulate objects
17:57 plobsing whiteknight: how can you avoid entering a runloop when examining bytecode? self-hosted, bootstrapped packfiles is something I see comming out of Lorito.
17:57 whiteknight plobsing: right. Not everything that parrot should support is currently supported
17:58 whiteknight but Lorito is coming like a freight train, and it's stupid to ignore the changes that come with it
17:59 plobsing what I'm getting at is that no operation should be assumed to not enter the runloop. doing everything in C should be rare.
18:00 whiteknight plobsing: no, you're right. But there's a difference between doing small operations and executing a bytecode starting from :main
18:00 whiteknight maybe not much of a difference, internally
18:01 whiteknight The question is whether the program runs on top of libparrot, or whether libparrot plays a small role within the larger program
18:01 whiteknight we need to support an array of use-cases
18:02 plobsing there is too much difference ATM. :main (and esp. :load) is special cased in the packfile loading code. its ugly and wrong.
18:02 whiteknight yes. Thanks
18:02 whiteknight very special, very wrong
18:03 bluescreen whiteknight: then we need to export an emun with the object types the api supports creating, and a destroy function
18:03 dukeleto PL/Parrot depends on something that is ":load :anon :main"
18:03 whiteknight bluescreen: I was thinking about creating objects by name.
18:04 dukeleto supposedly those 3 things together mean something special that is different than each individually.
18:04 bluescreen ok... how is our Deprecation policy when it comes to names
18:04 dukeleto PL/Parrot wouldn't work without that.
18:04 whiteknight oh, really? ENEEDSDOCS
18:04 plobsing yes. static typeids are inflexible.
18:04 atrodo EMAKESNOSENSE
18:05 atrodo if it's a special case, it should be a special name, not a magical combination of non-special things
18:05 whiteknight but that's part of the problem right there. PIR is stupid. People keep jamming more things into PIR to satisfy millions of little use-cases. Everything goes ugly
18:06 plobsing ":load :anon :main" is special? how? The only special magic combo I know of is ":anon :immediate"
18:08 plobsing whiteknight: a big problem of PIR is people kept adding *declarative* means of specifying functionality without providing an underlying *imperative* API.
18:08 dukeleto plobsing: perhaps I am wrong. I think i tried :immediate at some point, but PL/Parrot doesn't use it anymore
18:09 lucian plobsing: at first i thought PASM was the purely imperative layer with a 1:1 mapping to bytecode
18:09 whiteknight plobsing: Yes. Toss it on the pile of problems. PIR is a mishmash with no design or forethought put into it. Then people act surprised when it's a shitpile of half-ideas
18:10 plobsing lucian ah, if only that were true...
18:10 whiteknight lucian: you thought WRONG. And even if it was, PASM can't be used anyway
18:10 whiteknight because PASM doesn't support all the crap like compiler directives that PIR does
18:11 plobsing whiteknight: that's the declarative crap I'm talking about.
18:11 whiteknight plobsing: trust me, I know all the crap you're talking about :)
18:11 lucian whiteknight: yeah, i realised eventually. but it's very jarring
18:11 whiteknight lucian: right. It's exactly the opposite of what it should be
18:12 whiteknight The layers closest to the machine should be easiest for the machine to use, and expose more of the dirty bits
18:12 whiteknight languages closer to the user should be nicer and hide the garbage
18:12 lucian whiteknight: i think following JVM design closely except where it's a bad idea for dynamic languages would be a good rule of thumb
18:12 plobsing whiteknight: one of my medium-term objectives is to provide a simle 1:1 textual representation of pbc. I call it pasm2.
18:12 lucian and JVM bytecode is fully imperative
18:13 whiteknight lucian: That's a good idea in theory. Architecturally JVM is pretty different from Parrot
18:13 lucian plobsing: please call it something different :)
18:13 whiteknight call it "PASM"
18:13 lucian whiteknight: i know, stack and everything. but the JVM is quite more dynamic than java. partly because of its Self heritage
18:13 plobsing what about "second pasm" or "spasm"?
18:13 lucian plobsing: awesome
18:14 whiteknight lucian: yeah, I understand that. We can definitely borrow whatever makes sense. I just am doubtful that there is too much to borrow at this stage
18:15 lucian whiteknight: would be nice to borrow the GCs and JIT, but that's not exactly possible
18:15 bluescreen would be nice to borrow its budget :D
18:15 lucian bluescreen: +1
18:15 plobsing lucian: based on what I've read about dalvik, pbc isn't that far off. we've got a numbers table, a strings table, an object table, and a bytecode segment. those are almost analogous to what's in a .class file.
18:16 lucian plobsing: dalvik is quite cool, yes
18:16 lucian there's a nice video about it from a tech talk i think
18:17 whiteknight lucian: I think using LLVM for our JIT will be very powerful for now. We can improve on that later if we think it's possible/necessary. In terms of GC there may be some things to copy, yes
18:17 lucian ideally, google would use replace dalvim with a well-funded parrot :)
18:17 lucian whiteknight: uh, i don't know
18:18 lucian all the projects that use llvm for jit so far have had huge trouble
18:18 whiteknight historically, the biggest problem with Parrot's GC was it's lack of encapsulation. Now that we've got it cleaned up the only thing standing between us and new cores is developer man-hours
18:18 lucian it's not really good for a jit at all
18:18 atrodo lucian> google has a strong NIH mentality
18:18 Coke so does parrot. ;)
18:18 Coke at least historically.
18:18 whiteknight lucian: I've never heard that. There are other projects which make good use of LLVM
18:18 lucian Coke: meh, there's icu4c
18:18 whiteknight I know PyPy had problems
18:19 lucian rubinius, unladen-swallow, vmkit
18:19 lucian they all had problems with the fact that llvm isn't a very good vm
18:19 lucian it's almost like generating C code and compiling it one function at a time
18:20 lucian compilation time is hugely prohibitive with llvm
18:20 plobsing llvm has non-linear behaviours sometimes, and doesn't map to dynamic languages well. this is true. but everybody <3s llvm. so we're doing it.
18:20 whiteknight lucian: that may be. We won't know till we try
18:20 lucian and a tracing jit is just impossible
18:20 whiteknight lucian: what would you prefer? libjit?
18:20 lucian there are other code generators, better suited to vms
18:20 whiteknight suggest a few
18:20 dukeleto lucian: rubinius does tracing JIT with LLVM, if I heard correctly
18:20 lucian whiteknight: ideally there's be several backends
18:20 plobsing I might try to use libjit in parallel (allows more dynamicism). Aparently they support macho now.
18:20 lucian dukeleto: yes, but they had (and still have) huge issues with llvm itself
18:21 whiteknight maybe we need to get in touch with Rubinus people to get a good firsthand account of their issues
18:21 lucian JavaScriptCore has a nice assembler, it's used in TraceMonkey too now
18:21 lucian whiteknight: +1
18:21 whiteknight JavaScript engines are a little different
18:21 whiteknight those things are optimized to hell and back. There is likely not much for us to reuse
18:21 lucian whiteknight: possible
18:22 lucian oh, mono also have a llvm backend
18:22 plobsing luajit is a good candidate to steal examples from. they are a register-based vm for a dynamic language.
18:22 whiteknight yes, Mono is the example that makes me most hopeful
18:22 whiteknight plobsing: yes
18:22 lucian they had to fork llvm and they still have issues with compilation time
18:22 lucian and for example exceptions can't be implemented on llvm efficiently, at least not right now
18:23 whiteknight this is an area where the bikeshedding is thick. We can argue about JIT backends all day long and not come up with clear winners or losers
18:23 lucian so if mono detects exception handling, it switches back to the other jit
18:23 whiteknight so we need to pick one that looks good enough and just go with it
18:23 lucian whiteknight: if lorito is good enough, the cost for multiple backends might be low
18:23 whiteknight I'm all for an informed initial decision, but we're never going to be 100% right
18:24 whiteknight lucian: If lorito has ~64 ops or less, anything will be cheap enough
18:24 cotto_work lucian: that's my hope
18:24 atrodo whiteknight> that's awfully high number of ops ;)
18:24 lucian i think i mentioned this before, it might be a good idea to use an existing VM framework
18:24 whiteknight in the simple case we contain a lookup table for op-translations to JIT-speak, dump those into a buffer, and pass it off to the JIT engine
18:25 whiteknight for libjit it's not a table so much as a library of builder routines, but same principal
18:25 whiteknight principle
18:25 whiteknight I like LLVM because I *really* want to see Parrot have an AOT
18:25 cotto_work atrodo: fine.  Lorito will have one op.
18:25 whiteknight most JIT-specific solutions won't offer all the crap we need to make ELF or even PE files
18:26 lucian whiteknight: that is a very nice feature, indeed
18:26 bacek left #parrot
18:26 lucian hopefully enough projects squeeze JITs out of llvm that i'll get better
18:26 whiteknight lucian: what I like about AOT is that you can run it through the optimizer guantlet without having to worry about runtime. Just keep optimizing and-reoptimizing it
18:26 whiteknight then when you run the precompiled binary, it will be much faster than any JIT
18:26 lucian whiteknight: that hits diminishing returns, though
18:27 Coke Do we have a feed or mailing list that shows all the diffs of commits, or are we stuck with commit messages only?
18:27 lucian and quite quickly for very dynamic code
18:27 whiteknight lucian: of course, but performing all compilation and optimization overhead once is always going to be faster than doing it at runtime
18:27 whiteknight JIT always has overhead.
18:27 plobsing whiteknight: we can get AOT without llvm. just go down the emacs/run-a-core-dump-file route.
18:27 whiteknight plobsing: Is that portable?
18:27 lucian whiteknight: but it also has more performance
18:28 cotto_work Coke: dukeleto has a perl script that could be modified to send out full commits.  He doesn't have the tuits to get it working and hosted.
18:28 whiteknight lucian: wrong. How would a JIT have better performance than an AOT?
18:28 atrodo cotto_work> I think SUBLEQ would do perfect for the job
18:28 lucian at least better potential, for dynamic code
18:28 plobsing wherever emacs runs without taking 5 minutes to start up (most places that aren't windows), it works. it was not a serious proposition. I have serious emacs-hate after looking under the covers.
18:28 lucian whiteknight: JITs often have better performance these days
18:28 rfw joined #parrot
18:29 lucian as I said, especially for dynamic code
18:29 Coke looking at https://github.com/parrot/parr​ot/commits/master/src/io/api.c, how can I see the diffs introduced by the last commit?
18:29 lucian when you don't know the types of a certain function at compile time, there's not much you can do AOT
18:30 lucian you can do some type inference, but you have to be very careful not to break the semantics of languages running on top
18:30 lucian and that too has quickly diminishing returns for dynamic code
18:30 * Coke can do it the hard way, nevermind.
18:30 plobsing I agree with lucian. AOT has to generate very general, pessimistic native code.
18:31 plobsing that said, we have hot paths in packfile load which don't specialize much.
18:31 lucian heh, there's an interesting and vaguely related discussion in #rubinius
18:32 plobsing is it logged?
18:32 dalek parrot: e2ee0da | Coke++ | config/gen/makefiles/root.in:
18:32 dalek parrot: Fix build dep. broken in b57705c09687e759569e
18:32 dalek parrot: review: https://github.com/parrot/parrot/commit/e2ee0dab05
18:33 Coke git--
18:33 Coke ok. I did "git checkout <branch>". I did "git checkout <master>". I did a pull. I commit something. I did a push. I get an error:
18:33 Coke ! [rejected]        embed_api2 -> embed_api2 (non-fast-forward)
18:34 Coke this is not the first time this has happened. Why is it trying to do ANYTHING to that branch?
18:34 plobsing git push tries to push everything. if you want to only push one branch, specify it
18:34 lucian plobsing: not sure, if nothing else it's logged in my client
18:34 Coke (note that the push to master actually worked.)
18:34 Coke plobsing: I didn't change or commit anything in that branch.
18:34 Coke why is there anything to push?
18:35 plobsing git push = make remote state equal to my state. Default state is global. you need to pair that down.
18:36 Coke all I did with git on that branch was to check it out, then check out master. (in between I tried to build it, but I would not expect that to impact teh local git status of that branch.)
18:36 Coke plobsing: what is different about my state on that branch?
18:36 plobsing it is behind the remote. your client is trying to rewind history.
18:37 plobsing Coke: the command you are looking for is 'git push origin master'
18:37 Coke plobsing: no.
18:37 Coke I am NOT looking for that. I'm trying to figure out why this branch is out of sync with the remote.
18:37 Coke (this is like excel asking me if I want to save my changes when I didn't change anything. ;)
18:38 dukeleto Coke: wazzup?
18:38 dukeleto Coke: you want to update your local master branch?
18:38 Coke dukeleto: please review.
18:38 lucian plobsing: llvm discussion in #rubinius https://gist.github.com/730706
18:39 dukeleto Coke: git pull --rebase is probably what you want
18:39 dukeleto Coke: it is described in git_workflow.pod
18:40 dukeleto Coke: hmmm
18:40 dukeleto Coke: you are doing this on embed_api2 ?
18:40 dukeleto Coke: i would do "git fetch"
18:40 dukeleto Coke: then "git checkout embed_api2 && git rebase origin/embed_api2"
18:40 Coke dukeleto: if I do a "git fetch; git push", I still get the error about the embed_api2 branch.
18:40 dukeleto Coke: assuming your local branch is embed_api2
18:41 dukeleto Coke: yes, because fetch is only part of it
18:41 dukeleto Coke: you need the "git rebase origin/embed_api2" when you are on the embed_api2 branch
18:41 dukeleto Coke: before you push again
18:41 cotto_work dukeleto: is pull --rebase the way to avoid useless merge commits?
18:42 dukeleto cotto_work: yes
18:42 dukeleto cotto_work: i describe it a bit in git_workflow.pod
18:42 Coke dukeleto: ok. if I do "git checkout embed_api2", I'm told I'm 7 commits behind; does "git pull" only affect the current local branch?
18:43 * cotto_work will read the fine manual
18:43 dukeleto Coke: yes, "git pull" == "git pull origin master", which means "merge remote changes in master to the current branch I am on"
18:44 dukeleto Coke: what you need now is "git rebase origin/embed_api2"
18:44 dukeleto Coke: while you are on your local embed_api2 branch
18:44 dukeleto Coke: that will get those 7 commits
18:44 Coke "git pull" when checked out to that branch also works, it seems.
18:45 Coke Ok. thank you.
18:45 dukeleto Coke: yes, but it creates useless merge commits
18:45 dukeleto "git pull" = "git fetch" + "git merge"
18:45 dukeleto if you have already done a fetch, then a pull just wastes some bandwidth by asking for stuff you already have, then does a merge
18:46 dukeleto "git rebase" = "git fetch" + "git rebase"
18:46 dukeleto arg
18:46 dukeleto sorry.
18:46 dukeleto "git pull --rebase" = "git fetch" + "git rebase"
18:46 PerlJam it's worth it IMHO to make an alias:  git pullr  == git pull --rebase
18:47 dukeleto PerlJam: there is a config setting to tell git that you always want to do a rebase when pulling, but I don't use it, because I don't want it all the time
18:47 dukeleto i have "g" alias to git, and "pr" aliased to "pull --remote", so I just type "g pr"
18:48 dukeleto https://github.com/leto/Util/​blob/master/config/.gitconfig
18:48 PerlJam dukeleto: aye, that's why I make the alias :)
18:48 dukeleto i only use "git pull --rebase" to update the master branch.
18:49 dukeleto If I want to sync up a feature branch, i do: "git fetch && git rebase origin/some_branch"
18:49 atrodo dukeleto> can you remind me real quick how to delete a branch on a remote?
18:50 dukeleto atrodo: git push origin :foo
18:50 dukeleto atrodo: will delete the remote branch foo
18:50 atrodo that's right, the colon
18:50 dukeleto atrodo: it is part of the general case of "git push origin foo:bar"
18:50 dukeleto atrodo: which means push local branch foo to remote branch bar
18:51 atrodo dukeloet> oh, neat, didn't know that
18:51 dukeleto atrodo: if foo is empty, you are pushing an "empty" branch to the remote one, which deletes it.
18:51 dukeleto atrodo: this is all described in git_workflow.pod
18:51 atrodo dukeleto> thanks
18:51 dukeleto Coke: take a look at "Keeping branches updated" section in git_workflow.pod
18:51 dukeleto It is all described in there.
18:52 dukeleto Coke: actually, "Maintain a branch" just below it, is more of what you want
18:54 PerlJam dukeleto: is git_workflow.pod "parrot standard" git usage?  Or just some notes you wrote down?
18:55 dukeleto PerlJam: it is as close to "official parrot standard usage" as you will get.
18:56 dukeleto PerlJam: They are not "just some notes." They are what Parrot devs should do to use git. Nothing is written in stone, but those guidelines should make everyone's life easier and not harder.
18:56 dukeleto Please let me know if they aren't.
18:56 dukeleto If anyone is thinking "this garbage is wrong", then please let me know. I would love feedback.
18:57 dukeleto PerlJam: the section on "signing off on commits" is the least official, and there is a note there saying as much.
18:57 dukeleto PerlJam: we will use what works for us, and change what doesn't
18:58 dukeleto Most of what is there is the "standard" way to use Git, I didn't make up anything esoteric.
18:58 PerlJam the reason I asked was that there are always some biases with such a flexible tool at git.  I just wanted to be sure that git_workflow.pod is where to look for those biases if ever there is a question.
18:58 dukeleto For people familiar with Git, all those instructions will be what they expect, for the most part.
18:59 dukeleto PerlJam: yes, git_workflow.pod is where to look.
18:59 dukeleto PerlJam: if you take a look, there are no restrictions with how to use git locally, on your machine. It is mostly "this is how branch creation and pushing should work"
18:59 dukeleto People are free to do whatever crazy stuff they want, locally.
19:00 PerlJam right, I'm looking now :)
19:00 PerlJam --no-ff is important for merges, for instance.
19:00 PerlJam (as far as biases go)
19:01 dukeleto PerlJam: that is something that I think is valuable, but if someone does a merge without --no-ff, I won't tar and feather them.
19:01 PerlJam dukeleto++ nice document
19:04 Kulag left #parrot
19:04 Kulag joined #parrot
19:07 dukeleto PerlJam: thanks. I took a good amount of time thinking about it
19:08 dukeleto PerlJam: not many projects have nice document like that, and i knew that wouldn't fly for us.
19:13 dukeleto I am sure there are still some holes in my git docs, but they cover 80% of what you need
19:16 Kulag left #parrot
19:20 Kulag joined #parrot
19:20 nwellnhof joined #parrot
19:21 * lucian still sometimes struggles with git
19:24 rfw ohi Kulag
19:26 whiteknight git definitely feels to me like it's one layer of abstraction too low for the average developer
19:26 * lucian prefers hg
19:26 dukeleto whiteknight: which is why there are so many GUIs on top of git
19:26 whiteknight I've never used hg
19:26 lucian it's very similar go git, but that one layer of abstraction higher
19:26 lucian s/go/to/
19:27 Kulag ohi rfw
19:27 lucian well, perhaps 0.5 layer
19:27 dukeleto Kulag: howdy Kulag
19:27 whiteknight dukeleto: It's not just interface. The operations you need to perform, and the concepts you need to keep in your head are too much most of the time
19:27 lucian (git still has commit/pull/push/merge)
19:28 whiteknight local branches, and their relationships to remote branches, etc. Sometimes you just want to say "This local branch is that remote branch, don't mention anything else to me ever"
19:28 dukeleto whiteknight: i hear what you are saying, but it is a VCS designed by kernel developers. What do you expect? ;)
19:29 dukeleto whiteknight: git has a bit too much flexibility for the average developer, i agree
19:29 lucian dukeleto: hg is also designed by kernel devs
19:29 whiteknight dukeleto: It *is* what I expect, considering it's history
19:29 dukeleto lucian: i didn't know that
19:29 whiteknight one day somebody is going to come up with a really great, simple wrapper for git that hides the details, and it will be awesome
19:30 lucian whiteknight: there is. it's called hg-git :)
19:31 PerlJam git is pretty awesome as-is.  It's just like Perl
19:31 lucian meh, git's interface isn't that bad
19:32 lucian dukeleto: iirc, hg was a competitor to git initially, when kernel devs were looking for a replacement to perforce
19:32 fbrito joined #parrot
19:33 PerlJam lucian: I don't think yo recall correctly.
19:33 dukeleto lucian: kernel devs used BitKeeper before git
19:33 PerlJam s/yo/you/
19:33 lucian right, bitkeeper
19:33 lucian w/e :)
19:34 dukeleto lucian: Perl 5 used perforce before git
19:34 PerlJam lucian: I don't know if you can say that hg was a competitor to git before git existed either
19:35 lucian PerlJam: my wording was poor. both projects began as efforts to replace bitkeeper
19:35 lucian mostly in isolation from one another
19:42 fperrad left #parrot
19:55 nwellnhof left #parrot
20:02 preflex left #parrot
20:04 perlite_ joined #parrot
20:07 preflex joined #parrot
20:07 perlite left #parrot
20:07 perlite_ is now known as perlite
20:08 atrodo If i remember correctly Linus looked at hg before he started git, thought it was close but not fast enough for his needs
20:11 lucian atrodo: and instead of optimising it he wrote git :)
20:12 lucian it doesn't matter much, all the popular DVCSes are very good
20:14 dukeleto as someone who has only used git as a DVCS, and then trying hg, it seems painfully slow.
20:15 atrodo I have yet to try hg
20:15 PerlJam I tried hg for all of about 2 seconds
20:16 PerlJam I had bzr, hg, and git and git won very quickly.
20:19 jnthn PerlJam: What put you off hg, ooc?
20:21 moritz last I tried hg, it didn't automatically pipe to a pager for too long outputs
20:21 PerlJam jnthn: I don't think it was anything specific; git just "fit my brain" better/faster than hg
20:21 PerlJam (it was about 3 years ago when I tried them)
20:22 jnthn PerlJam: k
20:22 moritz and they have a confusion "revision number", which doesn't uniquely identifies commits across repos
20:22 moritz so it's kinda... confusing if you're not used to it
20:22 moritz apart from that, I remember it as "better than svn" :-)
20:22 preflex left #parrot
20:23 moritz actually, "much better than SVN"
20:23 PerlJam for a long time I was in the camp of "svn is good enough" but as soon as I started banging my head against merging, I quickly went to "svn is crap!  there must be something better!"
20:24 dalek parrot/embed_api2: aef7ea1 | (Mariano Wahlmann)++ | src/embed/api.c:
20:24 dalek parrot/embed_api2: Fixed stdin,stdout and stderr Andy++ pointed out
20:24 dalek parrot/embed_api2: review: https://github.com/parrot/parrot/commit/aef7ea1821
20:26 preflex joined #parrot
20:47 mikejw joined #parrot
20:53 whiteknight bluescreen++
20:55 AndChat| joined #parrot
20:57 AndChat| left #parrot
20:59 whiteknight opbots trust bluescreen
20:59 slavorg Ok
20:59 slavorgn Ok
20:59 whiteknight yay, it's nice when bots listen to me
20:59 bluescreen lol
21:00 gg411 left #parrot
21:00 lucian PerlJam: hg used to be much slower, yes. nowadays it's much faster
21:01 lucian bzr is a bit silly-slow
21:03 nwellnhof joined #parrot
21:14 whiteknight you know what I hate most about svn?
21:14 whiteknight properties
21:14 whiteknight Somebody at work keeps setting code files to svn:mime-type = application/octet-stream which breaks our diffs and codereview software
21:15 whiteknight and there's no good way to figure out who is doing it besides doing a million propget calls in a binary search
21:16 lucian you know what i hate most? operations are cwd-sensitive
21:16 plobsing isn't there a way to automate it? I thought we had an svn-bisect script kicking around somwhere.
21:17 plobsing my favorite gripe: cannot even handle fast-forward merges without hand-holding (I've seen this myself).
21:23 atrodo plobsing> that would explain why users of svn never branch
21:24 plobsing first rule of svn merging: don't branch. second rule: why are you still here?
21:26 whiteknight when I used svn, I would make many branches
21:26 whiteknight the key is to keep them very small
21:27 whiteknight my current company never branches, and it's screwing with my head
21:28 moritz just use git-svn for merging :-)
21:29 whiteknight for very small branches, that's unnecessary
21:29 plobsing problem is sometimes you don't know in advance how small or short-lived a branch will be
21:29 whiteknight true
21:29 whiteknight I'm heading home, be back later
21:30 whiteknight left #parrot
21:40 Coke (svn-bisect) -it's on CPAN
21:41 Coke http://search.cpan.org/~infinoid/​App-SVN-Bisect-1.1/bin/svn-bisect
21:41 Coke msg Infinoid you can remove the reference to my now defunct module from svn::bisect.
21:41 aloha OK. I'll deliver the message.
21:51 mikejw left #parrot
21:55 bluescreen left #parrot
22:00 zby__ joined #parrot
22:00 zby left #parrot
22:01 donaldh joined #parrot
22:06 dalek parrot/nwellnhof/compiler_flags: d2c2cc4 | nwellnhof++ | config/ (8 files):
22:06 dalek parrot/nwellnhof/compiler_flags: [configure] Don't use compiler and linker flags from Perl
22:06 dalek parrot/nwellnhof/compiler_flags: review: https://github.com/parrot/parrot/commit/d2c2cc40f1
22:10 dukeleto nwellnhof++ # compiler_flags
22:10 zby joined #parrot
22:11 zby__ left #parrot
22:11 dukeleto nwellnhof: let me know if you need help or testing
22:11 Matt_ joined #parrot
22:12 gg411 joined #parrot
22:14 plobsing left #parrot
22:30 lucian left #parrot
22:31 lucian joined #parrot
22:32 dalek parrot/nwellnhof/compiler_flags: 6f4e99e | nwellnhof++ | config/init/ (2 files):
22:32 dalek parrot/nwellnhof/compiler_flags: [configure] Remove more usages of $Config
22:32 dalek parrot/nwellnhof/compiler_flags: review: https://github.com/parrot/parrot/commit/6f4e99e246
22:32 nwellnhof dukeleto: See my mail to parrot-dev
22:57 plobsing joined #parrot
23:06 dalek parrot/nwellnhof/compiler_flags: b15d1f4 | nwellnhof++ | config/init/optimize.pm:
23:06 dalek parrot/nwellnhof/compiler_flags: [configure] Fix comments
23:06 dalek parrot/nwellnhof/compiler_flags: review: https://github.com/parrot/parrot/commit/b15d1f4670
23:18 silug left #parrot
23:38 kid51 joined #parrot
23:39 whiteknight joined #parrot
23:42 whiteknight good evening, #parrot
23:43 nwellnhof good evening, whiteknight
23:44 whiteknight hello nwellnhof. Excellent work on that flags branch
23:44 whiteknight I have some things to add for Win64/MSVC
23:44 cotto_work hio whiteknight
23:44 whiteknight hello cotto_wor
23:44 nwellnhof whiteknight: the embed_api branch cleans up the handling of GC command line options AFAICS
23:44 whiteknight hello cotto_work
23:45 whiteknight nwellnhof: yay! I'm being useful
23:45 nwellnhof whiteknight++ for that
23:45 nwellnhof i'm thinking about adding a second GC threshold flag.
23:45 whiteknight yeah, I needed to do something about it it. using enums from src/gc/gc_private.h in src/main.c seemed bad to me
23:46 whiteknight that's fine. Do you know where to add it?
23:46 nwellnhof in the embed_api branch? no.
23:46 nwellnhof but it's probably easy to find out.
23:47 bluescreen joined #parrot
23:47 whiteknight embed_api2. I renamed it when I updated to trunk recently
23:48 nwellnhof do you have an idea when it will be merged?
23:48 whiteknight in include/parrot/api.c there is a structure called Parrot_Init_Args. That gets passed into the function Parrot_api_make_interpreter, which sets options like GC flags that need to be set before the itnerpreter is initiaized
23:49 whiteknight I would like to merge as quickly as possible, but probably won't happen before 2.11
23:49 nwellnhof yes, i've noticed Parrot_Init_Args. it's good to use a single struct for that.
23:50 nwellnhof i've also been thinking about using configuration files for that.
23:50 nwellnhof that would be useful for GC options.
23:50 whiteknight there are lots of things we could do, the problem is trying to set settings on the GC after the Parrot_Interp is created, but before we are able to return a Parrot_PMC to the user
23:51 kid51 nwellnhof: Re new branch, remember to run:  perl Configure.pl --test
23:52 nwellnhof kid51: ah yes. i only ran that by accident once ;)
23:52 kid51 But, so far, all the tests look good!
23:52 fbrito hey guys :D. I have VTABLE_elements() for arrays. what should I use to get the size of a PMC key?
23:52 nwellnhof kid51: also passes here
23:53 kid51 Periodically, I measure the test coverage:  http://thenceforward.net/parrot/cov​erage/configure-build/coverage.html
23:53 whiteknight fbrito: good question. let me look
23:54 kid51 I'll run coverage analysis on the branch now; that page will refresh in several minutes
23:56 Matt_ I have a question for GCI: Is there any way to get a filename out of a PackFile? (ticket: 1833: http://trac.parrot.org/parrot/ticket/1833)
23:56 * kid51 smoke tests latest changes to embed_api2 branch
23:56 Matt_ I ended up adding a member to the PackFile struct to pull this off
23:57 fbrito whiteknight: I saw that it is common to use VTABLE_shift_pmc() to iterate over PMC keys
23:57 whiteknight fbrito: yeah, that's probably what you're going to have to do
23:57 whiteknight there doesn't look to be an easy function to do that
23:58 whiteknight Matt_: What function generates that error message?
23:58 fbrito whiteknight: ok, thanks anyway :D
23:59 whiteknight fbrito: sorry, you have to do it the hard way :)
23:59 Matt_ whiteknight: PackFile_unpack generates the first error, the function returns 0, and the calling function reports the second error

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

Parrot | source cross referenced