Parrot 2.10.1 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot Developer Summit 2300 UTC today | Please test rakudo with bleeding edge parrot!
Set by moderator on 5 December 2010.
lucian chromatic: seems to be about 3-4 files of 0.5k lines each 00:04
that includes the gc framework in pypy i think
not sure if i'm missing anything
chromatic That could be some 3 or 4k lines of C then.
lucian chromatic: hmm. sad that you can't write a GC in a GC-ed language :) 00:06
well, you can if it's RPython
chromatic Or an ML derivative or Smalltalk.
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
chromatic: heh
chromatic: i'm wondering if PyPy's could be reused without having to write all of parrot in RPython. probably not 00:10
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:12
Infinoid kid51: I think it's a reference to Lorito 00:13
00:15 jsut_ left
lucian chromatic: ah, i miscounted 00:19
semispace is 700 loc 00:20
generational is 600 loc extra
00:21 jsut joined
lucian hybrid is 560 loc extra, complete with ascii graphics of the memory model (how cool is that?) 00:21
it all depends on the pypy backend memory handling
chromatic How does any MOP work change Lorito work? 00:23
lucian is still confused about what exactly lorito is
chromatic It's our RPython. 00:24
lucian the wiki gave me a somewhat different impression
00:25 nwellnhof joined
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
cotto chromatic, I assume that there are ways that Lorito can make the mop implementation easier or harder
lucian with higher level system languages (RPython-style) targeting lorito
chromatic I don't see how.
To me, that's like saying that C can make the MOP easier or more difficult. 00:26
To the degree that C or Lorito does, it does so for every other part of Parrot.
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.
lucian what worries (and confuses) me is how PMCs/objects will look like in a MOP world
but i also don't see how that affects the implementation language
or the other way around
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.
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
jnthn The representation model isn't really about methods. But attributes, yes. 00:30
How much it wants to twiddle depends on the representation though.
00:31 jjore joined
chromatic I'm assuming you want to store methods efficiently and look them up super efficiently, even resolvable statically when possible. 00:31
But sure, attributes stored that way.
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
chromatic: The meta-object can choose to pubhlish a v-table.
chromatic In that case, Lorito needs to make hash tables possible and allow offset access into chunks of memory.
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
chromatic Right.
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
00:34 gg411 joined, AndChat- left
lucian jnthn: i like your 6model thing 00:35
it's similar in concept to how i'd see python objects bootstrapped
chromatic What's an s-table, by the way?
jnthn chromatic: There's one of them per (meta-object, REPR) pairing.
chromatic: s came form "shared" (as in, shared between all objects with a specific REPR and HOW) 00:36
er, s/a specific/the same/
chromatic: A few other things hang off it, but that's the main idea. 00:37
chromatic Why the pairing of REPR and MO?
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.
chromatic Why the separation? 00:38
jnthn chromatic: Using diferent REPRs with one MO is what representation polymorphism means. 00:39
chromatic: 6guts.wordpress.com/2010/10/15/slid...ymorphism/ explains the thinking behind this.
chromatic Ah right, i'd read that. Thanks. 00:40
Makes sense. 00:41
nwellnhof also seems to be a useful generalization outside of perl6
lucian jnthn: interesting
jnthn needs sleep, gotta do some $dayjob tomorrow :) 00:45
cotto jnthn, 'night
thanks for dropping by
00:51 AndChat| joined, gg411 left 00:56 tcurtis left 01:09 tcurtis joined 01:49 tcurtis left 02:01 AndChat| left 02:02 gg411 joined
whiteknight plobsing: ping 02:05
02:07 AndChat| joined
plobsing whiteknight: pong 02:07
whiteknight plobsing: I have some small ideas for NCI stuff that I wanted to run past you
plobsing shoot
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
so the libffi stuff gets ported to a PMC type inheriting from it
should lead to a lot less boilerplate code for people looking to implement new variants
plobsing there is already an implicit API required of thunk generators. unfortunately, it is only well defined in the code and in my head.
whiteknight right, but I'm saying we create a PMC for it and inherit 02:09
same general idea, but less work for implementors
lucian is raw libffi exposed at pir-level?
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
plobsing lucian: no. it is abstracted
so that you could use something more efficient, should you choose.
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
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.
and clearing the cache is about 3 lines of PIR
whiteknight timing comparisons, etc
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?
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
that's fine too. It was just an idea
you're the expert, so I wanted your input
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
kid51 What does MOP mean again? 02:19
whiteknight metaobject protocol
cotto aloha, mop? 02:20
aloha cotto: I have no idea.
cotto aloha, mop is meta-object protocol
aloha cotto: Okay.
whiteknight I was hoping to see bacek here tonight 02:21
cotto it's a bad time for him unfortunately
whiteknight yeah, I know
next time
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
Util kid51: MOP is very simply explained in jnthn's excellent slides: www.jnthn.net/papers/2010-osdc.fr-rakudo.pdf 02:23
02:32 nwellnhof left
Coke wonders if the 6guts blog is in the planet six family. 02:34
kid51 Posted summary of action items to parrot-dev. Corrections? Respond to that post. 02:38
Coke: It *ought* to be. 02:39
Coke I haven't read any blog posts by jnthn lately, so I'm guessing not. You have a url? 02:40
Coke finds 6guts.wordpress.com/feed/
ah, he hasn't posted since nov 01 02:41
dukeleto enjoyed PDS greatly 02:43
whiteknight yes, it was excellent 02:44
cotto I'm making a note here: huge success.
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
cotto Do weekday evenings work for you in general? 02:45
whiteknight yessir 02:46
shockwave Hello.
whiteknight what "works for me" is far less restrictive than what "works for my wife"
but yes, weekday nights are good
hello shockwave
cotto whiteknight, how about Monday evening. 02:47
whiteknight perfecy
perfect
cotto 6PM PST?
Coke dukeleto: reading through old tickets - rejecting tickets /just/ because they are old: -1.
shockwave I just finished reading your latest blog entry. So... that Parrot api branch is going... well? 02:48
Coke er, reading through *PDS.
dukeleto Coke: old != not touched in >= 1 year
cotto so 8PM for you iirc
dukeleto Coke: but more criteria are welcome
Coke: some tickets are unclosable and are just dead weight
whiteknight shockwave: very well. Primary development is complete. We're working out bugs and kinks, but otherwise it's going very well
cotto: 8pm is good 02:49
cotto alright
whiteknight shockwave: are you on Mac?
shockwave whiteknight: Windows 7
dukeleto whiteknight: Getting PL/Parrot to work on the new embed_api branch could be a fun GCI task. What do you think?
Coke just because a ticket hasn't been touched does not a priori mean it is untouchable.
dukeleto whiteknight: getting it to compile
shockwave whiteknight: If I were to start using it tomorrow, are there some things that I couldn't yet do with it?
dukeleto Coke: i agree. But still, some tickets are ancient and unclosable. 02:50
whiteknight: also, i have a github repo for GCI task templates. It should make your life easier 02:51
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
dukeleto: PL/Parrot on embed_api is a good task, yes
dukeleto: github repo for it sounds very good too. I'll check it out
atrodo whiteknight> how far away are we from being able to load a compiler, pass it some code, and get a callable? 02:54
code == a string
dukeleto whiteknight: github.com/leto/gci
whiteknight: feel free to fork it, it has some templates and I started keeping track of tasks that I create in there
whiteknight atrodo: Don't have a function yet to register a compiler, but that's high on the priorities list
dukeleto whiteknight: there is a parrot task template and a parrot translation task template
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
whiteknight dukeleto: awesome. I think we may want it for GSoC too, or something like it
atrodo whiteknight> good, that's the big thing I struggled with
dukeleto whiteknight: indeed. I've learned that I need to create meta-tasks and instantiate them multiple times
whiteknight atrodo: what compiler are you trying to register/use?
atrodo whiteknight> any besides IMCC 02:56
whiteknight dukeleto: good, we're becoming more efficient!
atrodo: ah, good choice :)
atrodo whiteknight> but i think i was focusing on nqp-rx
whiteknight ok
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> github.com/atrodo/draak/blob/maste...rv.pas#L96 was what I had gotten
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
now
shockwave @whiteknight: That's great to hear. 02:58
dukeleto jnthn: i am reading your slides now. These are awesome!
whiteknight atrodo: oh cool. I keep meaning to read more about draak
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
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,
atrodo It was something like "compile_string". "Perfect! This will do what I want. Oh wait, only PASM and PIR. Drat"
whiteknight shockwave: ask away 03:01
atrodo: in the new API, you'll get a compiler PMC, and call a method on it to compile
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.
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
dukeleto shockwave: winxed uses C++ at the core, iirc
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?
whiteknight: Is libffi a core Parrot project, or an external project?
whiteknight it's external
Parrot has optional bindings to it
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 nopaste.snit.ch/26721
plobsing whiteknight: ^^ framebuilder documentation draft ^^ 03:06
dukeleto shockwave: parrot will detect if you have libffi
whiteknight shockwave: we have bindings for it built-in. The Parrot configure process detects libffi and activates the bindings if it is installed
plobsing++
dukeleto shockwave: it is used in our Native Call Interface (NCI) subsystem, which is just another word for FFI
shockwave whiteknight: sweet.
dukeleto: Awesome. 03:07
dukeleto shockwave: that came in when the gsoc_nci branch landed
shockwave: it has not been put to full potential yet, though
whiteknight plobsing: to your knowledge, it is possible to call a C++ method through libffi?
(the libffi docs I find are less than helpful) 03:08
shockwave ping NotFound 03:09
plobsing whiteknight: sure. sort of. C++ that abides the platform's C ABI should work fine. 03:10
whiteknight plobsing: so extern "C"?
shockwave whiteknight: you read my mind
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.
plobsing not at all.
you just need a pointer to the method.
whiteknight plobsing: But a C++ method needs to pass the object reference too, which is typically out of band from the other args
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.
whiteknight (it *could* be made to do that, but I don't think it does)
plobsing all a C++ object is is a pointer
whiteknight on x86 for instance, C++ passes the object in ecx
not on the stack
plobsing not C ABI
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:13
for better or worse, C is a near-universal lowest-common-denominator. 03:15
for more complicated cases, you'll need to generate small shims
it's not so hard to do programatically 03:16
whiteknight no, it isn't
I have been kicking around the idea of creating a C++ wrapper for the new API
but that's a few weeks off, at least
dalek rrot/embed_api2: 3562b6b | (Mariano Wahlmann)++ | / (2 files):
Unfished work implemented API functions
 03:18
rrot/embed_api2: b5a2b99 | (Mariano Wahlmann)++ | / (23 files):
Unfished work implemented API functions
rrot/embed_api2: 0814f94 | (Mariano Wahlmann)++ | src/embed/api.c:
Merged changes with branch
rrot/embed_api2: f0bd1e1 | (Mariano Wahlmann)++ | / (4 files):
First cut of load_language, set_compiler, get compiler
whiteknight bluescreen++
atrodo: I think the api fairy just granted your wish
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.
^ I didn't mean to direct that at plobsing. That was a comment to no-one in particular.
atrodo loves the api fairy
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
and call those from parrot
shockwave whiteknight: Ok, at least that's something; there's a way to make things happen. 03:22
03:22 bluescreen_ left
plobsing I would suggest you generate those shims programatically. You may need several very similar ones. 03:22
shockwave @plobsing: Do you mean by using something like swig? 03:23
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.
whiteknight shockwave: probably not swig, but something like it, yes
should be trivial with a short perl script or something
shockwave Ok, I'll explore that option. 03:25
Thanks for the answers. I have another question.
whiteknight sure
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
I'm not too familiar with Parrots GC.
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
Meaning, can I tell it not to collect?
... when to collect memory, how much should be its buffer? Essentially, how flexible is the GC in terms of the runtime managing it. 03:29
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:30
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.
there's a noticeable 0.5s? blip now and then
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
03:32 theory joined
cotto 2) is a realtime gc unless my brain deceives me 03:33
03:33 preflex left
whiteknight 1) should be possible without much work 03:34
we have a function to trigger GC. We should be able to expose that through the API 03:35
trouble is doing it in a way that doesn't expose too many details of GC internals
short answer: very possible to manually trigger a collection
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?
dukeleto shockwave: i am interested in real-time GC's for use on the RTEMS real-time embedded operating system
whiteknight shockwave: right. We have the ability internally. I should be able to expose it through the API cleanly
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.
30 millis of a blocking operation^^^
03:38 preflex joined
whiteknight shockwave: running Parrot (and therefore it's GC) on a separate thread might be nice, if possible 03:38
do pause-y kinds of things in the backgroun
dukeleto whiteknight: JIT will require a seperate thread, so that feature will have to come soon 03:39
whiteknight brb
true
03:44 kid51 left
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:56
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:57
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:58
As of now, I have to thing about my options at this point. Hopefully, we'll meet again in the future. 03:59
Regards,
Vladimir
plobsing ciao. good luck with the game.
shockwave @plobsing: thanks 04:00
04:00 shockwave left
cotto shockwave, best of luck. I hope we can improve Parrot to the point where it's suitable for such applications. 04:00
whiteknight on that note, I'm off to bed 04:03
goodnight
04:03 whiteknight left
cotto NotFound, ping 04:27
aloha, clock?
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
plobsing double cotto 04:29
cotto ? 04:34
plobsing aloha's clock is buggy.
aloha plobsing: Okay.
plobsing um... that was unintended 04:35
's clock? 04:36
aloha's clock?
aloha plobsing: 's clock is buggy.
plobsing aloha: forget 's clock
aloha plobsing: I forgot about 's clock. 04:37
dalek TT #766 closed by cotto++: Documentation keyword tagging 04:58
TT #766: trac.parrot.org/parrot/ticket/766
sorear what's wrong with aloha's clock?
it has the right answer for LAX 04:59
plobsing aloha: clock?
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
plobsing note the doubled up name 05:00
sorear ah
plobsing karma plobsing 05:01
aloha plobsing has karma of 200.
05:01 plobsing is now known as plobsing--
sorear PTR2INTVAL was inherited from the p5vm. you should ask on #p5p why it is needed 05:01
plobsing-- aloha clock?
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
plobsing-- karma plobsing
aloha plobsing has karma of 200.
plobsing-- aw, can't hack karma that way
05:02 plobsing-- is now known as plobsing
sorear IRC clients do not receive messages they send 05:02
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
bacek_at_work clock is fixed now
dalek rrot: f9c7b11 | cotto++ | src/call/args.c:
add no-op spaces to pcc call parsing
 05:16
rrot: 59bed18 | cotto++ | / (8 files):
Merge branch 'master' of github.com:parrot/parrot
cotto dukeleto, ping 05:18
05:21 zby left 05:22 zby joined
cotto is on a rampage of some sort 05:25
dalek rrot: b84615a | cotto++ | src/pmc/class.pmc:
remove a pluggable MRO comment; if we want one we can figure out how to add it
 05:28
TT #891 closed by cotto++: [TODO] allow spaces in nci function signatures 05:30
TT #891: trac.parrot.org/parrot/ticket/891
TT #1208 closed by cotto++: Optimize Parrot_pbc_read to do fewer stat() calls
TT #1208: trac.parrot.org/parrot/ticket/1208
TT #1256 closed by cotto++: src/pmc/class.pmc: Need a pluggable MRO in instantiate() PMC
TT #1256: trac.parrot.org/parrot/ticket/1256
TT #1247 closed by cotto++: ar can't read libparrot.a on Mac OS 10.5.2 06:03
TT #1247: trac.parrot.org/parrot/ticket/1247
06:21 davidfetter joined 06:33 PerlJam left, PerlJam joined
cotto bacek_at_work, thanks for the reply on the PTR2INTVAL ticket 06:45
aloha, clock?
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
clock aloha, clock 06:45
06:46 clock is now known as cotto
dalek rrot/leto/embed_grant: f390d57 | dukeleto++ | t/src/embed.t:
[t] Add a test for returning a Float PMC
 06:52
cotto dukeleto, ping 06:59
07:01 theory left
cotto sleeps 07:10
07:54 bacek joined
dukeleto # pop_pmc() not implemented in class 'ResizableFloatArray' 07:57
really?
chromatic I believe it. 07:59
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.
dukeleto chromatic: i realize the errors in my wasy 08:00
ways, even. 08:01
chromatic Me too, such as it's midnight. 08:06
dalek rrot/leto/embed_grant: 43f8566 | dukeleto++ | t/src/embed.t:
[t] Tests for returning a ResizablePMCArray
 08:10
08:12 chromatic left
bacek aloha, humans 08:19
08:32 davidfetter left 08:35 davidfetter joined 08:42 fperrad joined
bacek fperrad, ping 08:45
fperrad bacek pong 08:47
bacek fperrad, I couldn't reproduce Lua's failures on my box. 08:48
it is still failing on yours? 08:49
fperrad I'll check with a recent Parrot
bacek fperrad, ok, thanks. 08:50
09:11 Kulag left 09:12 Kulag joined 09:19 rfw left 09:28 lucian joined 09:31 Kulag left 09:32 Kulag joined 09:45 Kulag left, Kulag joined 09:52 davidfetter left
fperrad bacek, lua looks better, but still few segfaults in dynext/lua_group.so (Parrot_LuaTable_mark), 10:04
see smolder.parrot.org/app/projects/rep...tails/1525
10:12 davidfetter joined 10:18 jsut_ joined 10:23 jsut left 10:26 dip joined 11:05 donaldh joined 11:09 davidfetter left 11:11 davidfetter joined 11:34 lucian left 11:57 davidfetter left 12:00 lucian joined 12:12 lucian left 12:18 lucian joined 12:29 Kulag left, Kulag joined
Coke (casting macros) Andy Lester might also know. 12:44
12:53 donaldh left 13:43 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner, bluescreen joined 13:44 whiteknight joined
whiteknight good morning #parrot 13:48
lucian whiteknight: good afternoon :) 13:49
whiteknight hello lucian, how are you today? 13:51
lucian whiteknight: fine, I have a 4-page project proposal to write :) 13:52
whiteknight ah, I remember those days. I have fond memories of school 13:53
bluescreen good morning
whiteknight hello bluescreen, how are you: 13:55
?
bluescreen good back at the office...
whiteknight yeah. Mondays are the worst
bluescreen lol... even worst since I've spent last week in a training institute 13:56
so I've 500 emails
whiteknight ouch
bluescreen 200 of them are an email thread of a baby born
whiteknight must have been a cute baby 13:57
bluescreen or the ugliest .... :D
anyway nice PDS yesterday
whiteknight thanks! We had been planning it for a while 13:58
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
bluescreen and most of them are proof of concepts when parrot began
like we can do opengl bindings or things like that
Coke args as tickets with merit are closed because no one has done them yet. 14:00
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
in fact other projects like rakudo serve more as tutorials and examples than some of our docs and examples 14:02
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
whiteknight and users aren't going to be reading code to figure out how to do the things they want
Coke whiteknight: clearly.
(re: merit)
whiteknight maybe as a last resort, but by that point there is already a level of frustration
The only ticket closed this morning that I thought could have stayed alive was that MRO ticket 14:04
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
bluescreen: as was pointed out yesterday, the most important docs are for the user-facing things like the new API
bluescreen yes. I agree on that 14:06
whiteknight those docs should be complete, accurate, and helpful
moritz ... and up-to-date
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
whiteknight The OpenGL code should move out of the main Parrot repository and into it's own repository I think 14:09
and the maintainers of it can include any docs or examples they want
bluescreen whiteknight: thats my point...
dalek tracwiki: v9 | coke++ | DocsTasklist 14:12
tracwiki: Don't lose #766</a>, which is a good idea, even if no one wants to work on it right now.
tracwiki: trac.parrot.org/parrot/wiki/DocsTas...ction=diff
14:39 whiteknight left 14:42 whiteknight joined 14:43 silug joined 15:48 plobsing left, allison joined 15:53 bluescreen left 15:56 allison_ joined, allison_ left 16:01 PerlJam left 16:02 PerlJam joined 16:10 bluescreen joined 16:26 dmalcolm joined 16:29 preflex left 16:31 preflex joined
cotto_work ~~ 16:35
16:38 AndChat| left 16:41 gg411 joined, gg411 left 16:42 plobsing joined 16:47 theory joined
bluescreen whitekinght: +1 parrot_debugger 16:57
whiteknight thanks! I am really thinking it's not worth our time 17:12
we do need to update pbc_merge to use the new API though. I had forgotten about that one 17:13
plobsing pbc_merge might be hairy. it pokes packfiles in ugly ways. 17:21
whiteknight doing this API work I've found several areas where we need to radically change packfiles to suck less 17:23
I'm sure pbc_merge will expose more of those area 17:24
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
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
my drafts/ folder is becoming quite large 17:27
bluescreen whiteknight: I'm goint to implement tonight ( tomorrow maybe) Parrot_api_call_method 17:28
whiteknight cotto_work: yes, it does look truncated. Weird. 17:29
bluescreen: I think I already did that
bluescreen really?
whiteknight double-check that I haven't put something in already
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
bluescreen there you go
whiteknight basically a copy of Parrot_ext_call, but with CALLIN/CALLOUT macros added 17:31
17:31 gg411 joined
bluescreen I'm still thinking is way too much for the embedder 17:31
17:31 gg411 left, gg411 joined
whiteknight bluescreen: If you can think of a better way, put in a prototype 17:31
bluescreen yes... standardize compilers 17:32
and call the standardized method
whiteknight bluescreen: That's for compilers. What about other object types?
bluescreen why would you need to call methods for them 17:33
with that kind of power we're breaking the api encapsulation
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
whiteknight plobsing: exactly. Eventually PIR will be external to libparrot, and will only interact with libparrot through Lorito and the API
bluescreen: Think about using libparrot as an object runtime instead of as the execution core. like a GObject replacement 17:35
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
very much like GObject 17:37
whiteknight PMCs are really the primary interface to libparrot. You create them, pass them in, manipulate them, pass them out 17:39
and methods are really the preferred public interface to PMCs
bluescreen yeah... I'm thinking libparrot as a VM, something that only interacts with the world in a controlled and defined way
but this other way we're letting the real world interact with the objects
whiteknight so long as the objects provide a good interface, there's no reason to disallow access to them 17:40
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
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:42
plobsing good. nuke it from space! 17:43
bluescreen otherwise they get 50% of the power
plobsing bluescreen: are you advocating for a Parrot_api_new_class() 17:44
whiteknight bluescreen: yes. The user will be able to create arbitrary objects by type name 17:47
and the user will be able to register custom type libraries
and the user will be able to create new types on the fly
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:48
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
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
bluescreen good question... smalltalk's vm 17:51
the image communicates with real world through primitives and not the other way around
plobsing smalltalk isn't just an interpreter. it's an OS (in the emacs-y sense).
17:52 preflex left
bluescreen pblosing: it's a VM in the strict sense ;) 17:52
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
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
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
that probably won't execute much bytecode, but will need to be able to create and manipulate objects
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
but Lorito is coming like a freight train, and it's stupid to ignore the changes that come with it 17:58
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. 17:59
whiteknight plobsing: no, you're right. But there's a difference between doing small operations and executing a bytecode starting from :main 18:00
maybe not much of a difference, internally
The question is whether the program runs on top of libparrot, or whether libparrot plays a small role within the larger program 18:01
we need to support an array of use-cases
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
very special, very wrong
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"
whiteknight bluescreen: I was thinking about creating objects by name.
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
dukeleto PL/Parrot wouldn't work without that.
whiteknight oh, really? ENEEDSDOCS
plobsing yes. static typeids are inflexible.
atrodo EMAKESNOSENSE
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
plobsing ":load :anon :main" is special? how? The only special magic combo I know of is ":anon :immediate" 18:06
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
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
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
because PASM doesn't support all the crap like compiler directives that PIR does
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 :)
lucian whiteknight: yeah, i realised eventually. but it's very jarring
whiteknight lucian: right. It's exactly the opposite of what it should be
The layers closest to the machine should be easiest for the machine to use, and expose more of the dirty bits 18:12
languages closer to the user should be nicer and hide the garbage
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
plobsing whiteknight: one of my medium-term objectives is to provide a simle 1:1 textual representation of pbc. I call it pasm2.
lucian and JVM bytecode is fully imperative
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 :)
whiteknight call it "PASM"
lucian whiteknight: i know, stack and everything. but the JVM is quite more dynamic than java. partly because of its Self heritage
plobsing what about "second pasm" or "spasm"?
lucian plobsing: awesome
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:14
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
lucian bluescreen: +1
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.
lucian plobsing: dalvik is quite cool, yes 18:16
there's a nice video about it from a tech talk i think
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 :)
whiteknight: uh, i don't know
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
lucian it's not really good for a jit at all
atrodo lucian> google has a strong NIH mentality
Coke so does parrot. ;)
at least historically.
whiteknight lucian: I've never heard that. There are other projects which make good use of LLVM
lucian Coke: meh, there's icu4c
whiteknight I know PyPy had problems
lucian rubinius, unladen-swallow, vmkit 18:19
they all had problems with the fact that llvm isn't a very good vm
it's almost like generating C code and compiling it one function at a time
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.
whiteknight lucian: that may be. We won't know till we try
lucian and a tracing jit is just impossible
whiteknight lucian: what would you prefer? libjit?
lucian there are other code generators, better suited to vms
whiteknight suggest a few
dukeleto lucian: rubinius does tracing JIT with LLVM, if I heard correctly
lucian whiteknight: ideally there's be several backends
plobsing I might try to use libjit in parallel (allows more dynamicism). Aparently they support macho now.
lucian dukeleto: yes, but they had (and still have) huge issues with llvm itself
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
whiteknight: +1
whiteknight JavaScript engines are a little different
those things are optimized to hell and back. There is likely not much for us to reuse
lucian whiteknight: possible
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.
whiteknight yes, Mono is the example that makes me most hopeful
plobsing: yes
lucian they had to fork llvm and they still have issues with compilation time
and for example exceptions can't be implemented on llvm efficiently, at least not right now
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
whiteknight so we need to pick one that looks good enough and just go with it
lucian whiteknight: if lorito is good enough, the cost for multiple backends might be low
whiteknight I'm all for an informed initial decision, but we're never going to be 100% right
lucian: If lorito has ~64 ops or less, anything will be cheap enough 18:24
cotto_work lucian: that's my hope
atrodo whiteknight> that's awfully high number of ops ;)
lucian i think i mentioned this before, it might be a good idea to use an existing VM framework
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
for libjit it's not a table so much as a library of builder routines, but same principal 18:25
principle
I like LLVM because I *really* want to see Parrot have an AOT
cotto_work atrodo: fine. Lorito will have one op.
whiteknight most JIT-specific solutions won't offer all the crap we need to make ELF or even PE files
lucian whiteknight: that is a very nice feature, indeed 18:26
18:26 bacek left
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
then when you run the precompiled binary, it will be much faster than any JIT
lucian whiteknight: that hits diminishing returns, though
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
whiteknight lucian: of course, but performing all compilation and optimization overhead once is always going to be faster than doing it at runtime
JIT always has overhead.
plobsing whiteknight: we can get AOT without llvm. just go down the emacs/run-a-core-dump-file route.
whiteknight plobsing: Is that portable?
lucian whiteknight: but it also has more performance
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?
atrodo cotto_work> I think SUBLEQ would do perfect for the job
lucian at least better potential, for dynamic code
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.
lucian whiteknight: JITs often have better performance these days
18:28 rfw joined
lucian as I said, especially for dynamic code 18:29
Coke looking at github.com/parrot/parrot/commits/m.../io/api.c, how can I see the diffs introduced by the last commit?
lucian when you don't know the types of a certain function at compile time, there's not much you can do AOT
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
and that too has quickly diminishing returns for dynamic code
Coke can do it the hard way, nevermind.
plobsing I agree with lucian. AOT has to generate very general, pessimistic native code.
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
plobsing is it logged? 18:32
dalek rrot: e2ee0da | Coke++ | config/gen/makefiles/root.in:
Fix build dep. broken in b57705c09687e759569e
Coke git-- 18:33
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:
! [rejected] embed_api2 -> embed_api2 (non-fast-forward)
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
lucian plobsing: not sure, if nothing else it's logged in my client
Coke (note that the push to master actually worked.)
plobsing: I didn't change or commit anything in that branch.
why is there anything to push?
plobsing git push = make remote state equal to my state. Default state is global. you need to pair that down. 18:35
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
plobsing: what is different about my state on that branch?
plobsing it is behind the remote. your client is trying to rewind history.
Coke: the command you are looking for is 'git push origin master' 18:37
Coke plobsing: no.
I am NOT looking for that. I'm trying to figure out why this branch is out of sync with the remote.
(this is like excel asking me if I want to save my changes when I didn't change anything. ;)
dukeleto Coke: wazzup? 18:38
Coke: you want to update your local master branch?
Coke dukeleto: please review.
lucian plobsing: llvm discussion in #rubinius gist.github.com/730706
dukeleto Coke: git pull --rebase is probably what you want 18:39
Coke: it is described in git_workflow.pod
Coke: hmmm 18:40
Coke: you are doing this on embed_api2 ?
Coke: i would do "git fetch"
Coke: then "git checkout embed_api2 && git rebase origin/embed_api2"
Coke dukeleto: if I do a "git fetch; git push", I still get the error about the embed_api2 branch.
dukeleto Coke: assuming your local branch is embed_api2
Coke: yes, because fetch is only part of it 18:41
Coke: you need the "git rebase origin/embed_api2" when you are on the embed_api2 branch
Coke: before you push again
cotto_work dukeleto: is pull --rebase the way to avoid useless merge commits?
dukeleto cotto_work: yes 18:42
cotto_work: i describe it a bit in git_workflow.pod
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?
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"
Coke: what you need now is "git rebase origin/embed_api2" 18:44
Coke: while you are on your local embed_api2 branch
Coke: that will get those 7 commits
Coke "git pull" when checked out to that branch also works, it seems.
Ok. thank you. 18:45
dukeleto Coke: yes, but it creates useless merge commits
"git pull" = "git fetch" + "git merge"
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
"git rebase" = "git fetch" + "git rebase" 18:46
arg
sorry.
"git pull --rebase" = "git fetch" + "git rebase"
PerlJam it's worth it IMHO to make an alias: git pullr == git pull --rebase
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
i have "g" alias to git, and "pr" aliased to "pull --remote", so I just type "g pr"
github.com/leto/Util/blob/master/c....gitconfig 18:48
PerlJam dukeleto: aye, that's why I make the alias :)
dukeleto i only use "git pull --rebase" to update the master branch.
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?
dukeleto atrodo: git push origin :foo 18:50
atrodo: will delete the remote branch foo
atrodo that's right, the colon
dukeleto atrodo: it is part of the general case of "git push origin foo:bar"
atrodo: which means push local branch foo to remote branch bar
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.
atrodo: this is all described in git_workflow.pod
atrodo dukeleto> thanks
dukeleto Coke: take a look at "Keeping branches updated" section in git_workflow.pod
It is all described in there.
Coke: actually, "Maintain a branch" just below it, is more of what you want 18:52
PerlJam dukeleto: is git_workflow.pod "parrot standard" git usage? Or just some notes you wrote down? 18:54
dukeleto PerlJam: it is as close to "official parrot standard usage" as you will get. 18:55
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
Please let me know if they aren't.
If anyone is thinking "this garbage is wrong", then please let me know. I would love feedback.
PerlJam: the section on "signing off on commits" is the least official, and there is a note there saying as much. 18:57
PerlJam: we will use what works for us, and change what doesn't
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.
dukeleto For people familiar with Git, all those instructions will be what they expect, for the most part.
PerlJam: yes, git_workflow.pod is where to look. 18:59
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"
People are free to do whatever crazy stuff they want, locally.
PerlJam right, I'm looking now :) 19:00
--no-ff is important for merges, for instance.
(as far as biases go)
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, Kulag joined
dukeleto PerlJam: thanks. I took a good amount of time thinking about it 19:07
PerlJam: not many projects have nice document like that, and i knew that wouldn't fly for us. 19:08
I am sure there are still some holes in my git docs, but they cover 80% of what you need 19:13
19:16 Kulag left 19:20 Kulag joined, nwellnhof joined
lucian still sometimes struggles with git 19:21
rfw ohi Kulag 19:24
whiteknight git definitely feels to me like it's one layer of abstraction too low for the average developer 19:26
lucian prefers hg
dukeleto whiteknight: which is why there are so many GUIs on top of git
whiteknight I've never used hg
lucian it's very similar go git, but that one layer of abstraction higher
s/go/to/
Kulag ohi rfw 19:27
lucian well, perhaps 0.5 layer
dukeleto Kulag: howdy Kulag
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
lucian (git still has commit/pull/push/merge)
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? ;)
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
whiteknight dukeleto: It *is* what I expect, considering it's history
dukeleto lucian: i didn't know that
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
lucian whiteknight: there is. it's called hg-git :) 19:30
PerlJam git is pretty awesome as-is. It's just like Perl 19:31
lucian meh, git's interface isn't that bad
dukeleto: iirc, hg was a competitor to git initially, when kernel devs were looking for a replacement to perforce 19:32
19:32 fbrito joined
PerlJam lucian: I don't think yo recall correctly. 19:33
dukeleto lucian: kernel devs used BitKeeper before git
PerlJam s/yo/you/
lucian right, bitkeeper
w/e :)
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
lucian PerlJam: my wording was poor. both projects began as efforts to replace bitkeeper 19:35
mostly in isolation from one another
19:42 fperrad left 19:55 nwellnhof left 20:02 preflex left 20:04 perlite_ joined 20:07 preflex joined, perlite left, perlite_ is now known as perlite
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:08
lucian atrodo: and instead of optimising it he wrote git :) 20:11
it doesn't matter much, all the popular DVCSes are very good 20:12
dukeleto as someone who has only used git as a DVCS, and then trying hg, it seems painfully slow. 20:14
atrodo I have yet to try hg 20:15
PerlJam I tried hg for all of about 2 seconds
I had bzr, hg, and git and git won very quickly. 20:16
jnthn PerlJam: What put you off hg, ooc? 20:19
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
(it was about 3 years ago when I tried them)
jnthn PerlJam: k 20:22
moritz and they have a confusion "revision number", which doesn't uniquely identifies commits across repos
so it's kinda... confusing if you're not used to it
apart from that, I remember it as "better than svn" :-)
20:22 preflex left
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!"
dalek rrot/embed_api2: aef7ea1 | (Mariano Wahlmann)++ | src/embed/api.c:
Fixed stdin,stdout and stderr Andy++ pointed out
 20:24
20:26 preflex joined 20:47 mikejw joined
whiteknight bluescreen++ 20:53
20:55 AndChat| joined 20:57 AndChat| left
whiteknight opbots trust bluescreen 20:59
slavorg Ok
slavorgn Ok
whiteknight yay, it's nice when bots listen to me
bluescreen lol
21:00 gg411 left
lucian PerlJam: hg used to be much slower, yes. nowadays it's much faster 21:00
bzr is a bit silly-slow 21:01
21:03 nwellnhof joined
whiteknight you know what I hate most about svn? 21:14
properties
Somebody at work keeps setting code files to svn:mime-type = application/octet-stream which breaks our diffs and codereview software
and there's no good way to figure out who is doing it besides doing a million propget calls in a binary search 21:15
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.
my favorite gripe: cannot even handle fast-forward merges without hand-holding (I've seen this myself). 21:17
atrodo plobsing> that would explain why users of svn never branch 21:23
plobsing first rule of svn merging: don't branch. second rule: why are you still here? 21:24
whiteknight when I used svn, I would make many branches 21:26
the key is to keep them very small
my current company never branches, and it's screwing with my head 21:27
moritz just use git-svn for merging :-) 21:28
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
whiteknight true
I'm heading home, be back later
21:30 whiteknight left
Coke (svn-bisect) -it's on CPAN 21:40
search.cpan.org/~infinoid/App-SVN-B...svn-bisect 21:41
msg Infinoid you can remove the reference to my now defunct module from svn::bisect.
aloha OK. I'll deliver the message.
21:51 mikejw left 21:55 bluescreen left 22:00 zby__ joined, zby left 22:01 donaldh joined
dalek rrot/nwellnhof/compiler_flags: d2c2cc4 | nwellnhof++ | config/ (8 files):
[configure] Don't use compiler and linker flags from Perl
 22:06
dukeleto nwellnhof++ # compiler_flags 22:10
22:10 zby joined 22:11 zby__ left
dukeleto nwellnhof: let me know if you need help or testing 22:11
22:11 Matt_ joined 22:12 gg411 joined 22:14 plobsing left 22:30 lucian left 22:31 lucian joined
dalek rrot/nwellnhof/compiler_flags: 6f4e99e | nwellnhof++ | config/init/ (2 files):
[configure] Remove more usages of $Config
 22:32
nwellnhof dukeleto: See my mail to parrot-dev
22:57 plobsing joined
dalek rrot/nwellnhof/compiler_flags: b15d1f4 | nwellnhof++ | config/init/optimize.pm:
[configure] Fix comments
 23:06
23:18 silug left 23:38 kid51 joined 23:39 whiteknight joined
whiteknight good evening, #parrot 23:42
nwellnhof good evening, whiteknight 23:43
whiteknight hello nwellnhof. Excellent work on that flags branch 23:44
I have some things to add for Win64/MSVC
cotto_work hio whiteknight
whiteknight hello cotto_wor
nwellnhof whiteknight: the embed_api branch cleans up the handling of GC command line options AFAICS
whiteknight hello cotto_work
nwellnhof: yay! I'm being useful 23:45
nwellnhof whiteknight++ for that
i'm thinking about adding a second GC threshold flag.
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
that's fine. Do you know where to add it? 23:46
nwellnhof in the embed_api branch? no.
but it's probably easy to find out.
23:47 bluescreen joined
whiteknight embed_api2. I renamed it when I updated to trunk recently 23:47
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
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.
i've also been thinking about using configuration files for that. 23:50
that would be useful for GC options.
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
kid51 nwellnhof: Re new branch, remember to run: perl Configure.pl --test 23:51
nwellnhof kid51: ah yes. i only ran that by accident once ;) 23:52
kid51 But, so far, all the tests look good!
fbrito hey guys :D. I have VTABLE_elements() for arrays. what should I use to get the size of a PMC key?
nwellnhof kid51: also passes here
kid51 Periodically, I measure the test coverage: thenceforward.net/parrot/coverage/c...erage.html 23:53
whiteknight fbrito: good question. let me look
kid51 I'll run coverage analysis on the branch now; that page will refresh in several minutes 23:54
Matt_ I have a question for GCI: Is there any way to get a filename out of a PackFile? (ticket: 1833: trac.parrot.org/parrot/ticket/1833) 23:56
kid51 smoke tests latest changes to embed_api2 branch
Matt_ I ended up adding a member to the PackFile struct to pull this off
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
there doesn't look to be an easy function to do that
Matt_: What function generates that error message? 23:58
fbrito whiteknight: ok, thanks anyway :D
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!