Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2011-03-15

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

All times shown according to UTC.

Time Nick Message
01:35 whiteknight left #parrotsketch
03:04 ShaneC left #parrotsketch
05:32 contingencyplan left #parrotsketch
07:15 eternaleye_ joined #parrotsketch
07:19 eternaleye left #parrotsketch
08:32 lucian joined #parrotsketch
08:36 lucian left #parrotsketch
10:13 lucian joined #parrotsketch
10:22 lucian left #parrotsketch
10:29 lucian joined #parrotsketch
11:08 lucian left #parrotsketch
11:08 lucian joined #parrotsketch
11:31 lucian left #parrotsketch
11:32 lucian joined #parrotsketch
11:56 lucian left #parrotsketch
12:01 lucian joined #parrotsketch
12:50 bluescreen joined #parrotsketch
12:55 lucian left #parrotsketch
13:11 bluescreen left #parrotsketch
13:19 bluescreen joined #parrotsketch
13:21 atrodo joined #parrotsketch
13:29 bluescreen left #parrotsketch
13:38 contingencyplan joined #parrotsketch
13:40 bluescreen joined #parrotsketch
14:32 bluescreen left #parrotsketch
14:55 mikehh joined #parrotsketch
15:22 bluescreen joined #parrotsketch
16:12 bluescreen left #parrotsketch
17:05 lucian joined #parrotsketch
17:11 bluescreen joined #parrotsketch
17:22 ShaneC joined #parrotsketch
17:35 whiteknight joined #parrotsketch
17:35 * whiteknight will not be at #parrotsketch today
17:35 whiteknight WHAT I DID:
17:35 whiteknight * Started looking into TT #1886 for Coke. I think I have a solution in mind, although it's going to require some grunt-work.
17:35 whiteknight * Setup a github pages website for Rosella. Going to be adding content and tutorials to it. (http://whiteknight.github.com/Rosella/)
17:35 whiteknight * Fixes, cleanups and improved test coverage throughout Rosella.
17:35 whiteknight * Created an experimental new Rosella library for contracts and runtime assertions
17:35 whiteknight * Lots of work on the Rosella proxies library. Ability to make read-only proxies. Ability to make transparent proxies.
17:35 whiteknight * Still plugging away, slowly, at the imcc branch.
17:35 whiteknight WHAT I WILL DO:
17:36 whiteknight * Work on TT #1886 for Coke
17:36 whiteknight * Try to wrap up development on the IMCC branch and open it up for testing
17:36 whiteknight * Play around with the new contracts library for Rosella
17:36 whiteknight * Start working towards a release for Rosella (and maybe PLA)
17:36 whiteknight WHAT I AM BLOCKING ON:
17:36 whiteknight * Only 24 hours in the day? When did that happen?
18:27 ekg joined #parrotsketch
18:28 ekg left #parrotsketch
18:29 minusnine joined #parrotsketch
18:32 * lucian salutes minusnine
18:34 * minusnine waves
18:34 allison joined #parrotsketch
18:50 particle left #parrotsketch
18:53 particle joined #parrotsketch
19:03 bluescreen left #parrotsketch
19:03 kid51 joined #parrotsketch
19:03 kid51 kid51's report
19:03 kid51 * Closed http://trac.parrot.org/parrot/ticket/2037 following bacek++'s research
19:03 kid51 * Some PaFo business
19:03 kid51 * Stressful week at $job; little energy for Parrot.
19:04 kid51 * Meeting up with dukeleto tomorrow
19:04 bluescreen joined #parrotsketch
19:04 kid51 * At today's parrotsketch, we should review progress toward our 3.3 Roadmap Goals
19:04 kid51 EOR
19:05 kid51 (With advent of DST, 2030 UTC => 1630 US EDT; 1330 US PDT)
19:06 kid51 (I'll only be able to attend first 30 min of meeting today due to Perl Seminar NY.)
19:22 kid51 Change of plans: Won't be able to attend any of parrotsketch today due to $job conflict
19:22 kid51 left #parrotsketch
19:50 benabik joined #parrotsketch
19:51 bubaflub joined #parrotsketch
20:00 minusnine left #parrotsketch
20:10 plobsing joined #parrotsketch
20:12 mikehh What I did since my last report:
20:12 mikehh * building and testing parrot on amd64/i386, with gcc/g++
20:12 mikehh * some fixes
20:12 mikehh * branch testing and fixes
20:12 mikehh What I intend to do in the next week:
20:12 mikehh * testing and fixing
20:12 mikehh .eor
20:15 cotto_work *did:
20:15 cotto_work - code review, feedback
20:15 cotto_work - pushed developer tips doc (docs/project/hacking_tips.pod), improvements welcome
20:15 cotto_work - uploaded docs for the release
20:15 cotto_work - M0 roadmap progress
20:15 cotto_work -- have the basic idea behind ffi, needs a bit of refining
20:15 cotto_work - profiling runcore progress
20:15 cotto_work -- none
20:15 cotto_work *will do:
20:16 cotto_work - finish M0 ffi, start on concurrency primitives, start polishing the spec
20:16 cotto_work *blockers:
20:16 cotto_work - none
20:16 cotto_work *eor
20:19 atrodo .did
20:19 atrodo * isparrotfastyet hacking
20:19 atrodo * lorito thinking but no hacking
20:19 atrodo .todo
20:19 atrodo * isparrotfastyet
20:19 atrodo * help with the m0-spec with ernest
20:19 atrodo * lorito experiments
20:19 atrodo .eor
20:21 minusnine joined #parrotsketch
20:24 cotto_work q1q
20:26 bubaflub DID:
20:26 bubaflub Cardinal hacking
20:26 bubaflub TODO:
20:26 bubaflub More cardinal hacking
20:26 bubaflub Learn about NCI for GSoC
20:29 cotto_work hello
20:30 davidfetter joined #parrotsketch
20:31 allison hi
20:32 cotto_work could be a quiet day today
20:32 bacek aloha
20:32 bubaflub hello
20:32 davidfetter namaste
20:32 plobsing HI
20:32 mikehh hi there
20:33 cotto_work our goals for last week were:
20:33 cotto_work GOAL 1: Get more GSoC ideas on the wiki. (all)
20:33 cotto_work GOAL 2: Close tickets (all)
20:33 cotto_work GOAL 3: Produce a stable release, make life easy for gerd (all)
20:33 cotto_work GOAL 4: Be ready next week to assess status of roadmap goals
20:33 cotto_work How did we do with those?
20:34 plobsing by my count, we have 23 GSoC ideas posted on the wiki
20:35 mikehh quite a bit of activity on 1, did some test runs on 3
20:35 cotto_work The GSoC page looks excellent, though many of the tasks need specifying.
20:35 whiteknight left #parrotsketch
20:35 cotto_work Our ticket count looks about the same.
20:35 nwellnhof joined #parrotsketch
20:36 bacek q2q
20:37 cotto_work Is anyone aware of problems gerd had with the release?  It looked smooth from what I saw.
20:37 tadzik no ftp issues?
20:37 mikehh didn't see any particular ones, gerd++ mentioned server links slow
20:38 cotto_work I generated the docs from the release tarball, so that part worked fine.
20:39 cotto_work any other comments before we move to questions?
20:40 cotto_work my q: Do we want to switch back to gen_gc as the default gc for a couple weeks?
20:42 mikehh are we going (bacek++) to work on gc at all during the period of switch
20:43 cotto_work It's more likely to get tuits than gc_ms2.
20:44 bacek Unlikely. There is few improvements which can be made but I will not able to spend any time on it.
20:44 cotto_work I'm fine if we switch only after 3.3 is released.
20:45 bacek gen_gc available via Configure.pl anyway.
20:45 tadzik Rakudo moved to --gc=gms by default now. Who still wants ms2, besides Miss Deprecation Policy?
20:46 bacek no one
20:46 cotto_work tadzik: that's the big reason we're keeping it.
20:46 tadzik ok, just checking
20:46 cotto_work (as the default)
20:46 mikehh I would say switch and switch back only if we get complaints
20:46 cotto_work eoq from me then
20:46 lucian are there any significant users other than rakudo that have issues on gms?
20:47 cotto_work lucian: I don't believe so.  Partcl is the other user that needs to be aware of it, but it's been patched.
20:48 lucian cotto_work: then i'd assume defaulting to gms (and having ms2 available as a compile option) is the better choice
20:48 mikehh how about winxed, seems to work either way
20:48 lucian for stressing the new gc, if nothing else
20:49 cotto_work wfm.  Let's switch the default for 2-3 more weeks and switch back in time for the release (plus testing).
20:49 cotto_work eoq (really)
20:49 cotto_work bacek: go ahead
20:52 bacek q1: planet.parrotcode.org. Can we move it to planet.parrot.org? And how I can add my blog.bacek.com into it?
20:53 allison bacek: it's hosted by perl.org
20:53 allison bacek: afaik, the only way to add a blog to it currently is to submit a request to the perl.org admins
20:54 bacek Should we just bring it under PaFo umbrella?
20:54 allison bacek: and yes, it should be possible to set up a planet on OSU OSL instead, but would need someone with tuits to do the legwork
20:55 cotto_work bacek: I look forward to following your blog.
20:55 allison planet sites aren't difficult to set up
20:55 allison would be nice to pick one of the planet implementations that allows web submissions of new blogs to aggregate
20:55 bacek who can ask OSUOSL folks to setup one on parrot.org?
20:56 cotto_work bacek: anyone can ask.  They're pretty responsive on #osuosl on freenode.
20:57 cotto_work I think that dukeleto has access to their bug tracker.
20:57 bacek cotto_work, ok. I'll try to squeeze some time today. But if someone else can do it iwbn.
20:58 cotto_work bacek: ok
20:58 bacek q2: opsc_llvm branch
20:58 bacek Currently it's highly experimental for LLVM bindings
20:58 bacek I would like to get more eyeballs on it.
20:58 lucian bacek: to the llvm c api?
20:58 bacek lucian, yes
20:59 lucian i doubt i'll have time, but i'd like to have a look at that
20:59 bacek Major "issue" is finding proper "libLLVM.so" in runtime.
20:59 * lucian has been dreaming of writing a JIT in a HLL for a while
21:00 bacek If we can solve it than we'll have almost functional LLVM bindings in Parrot.
21:00 bacek And I can move to next target - implement JIT prototype :)
21:00 mikehh you seem to have to be specific - I have both 2.7 and 2.8 on my system, 2.9 is available
21:01 bacek mikehh, yes. Probable via Configure.pl --llvm-lib=/usr/lib/libLLVM-2.8.so
21:01 bacek or something like this
21:01 Coke both whiteknight and I have keys to planet parrot. please don't bug the perl.org admins.
21:01 bacek Coke, ok, thanks.
21:02 Coke and we've already started the dialog about moving the planet. it's just a realllly low priority.
21:05 cotto_work any other questions?
21:06 cotto_work kid51 suggested that we review our roadmap goals at the end of this #ps, but they'll be a bit fragmented since neither he nor whiteknight can make it.  I suggest we review those goals on parrot-dev.
21:08 cotto_work thoughts?  objections?
21:08 allison bacek: yah, with all things parrot.org related I should note Coke knows the most
21:08 mikehh no objectios
21:09 mikehh do we have any branches ready to merge?
21:12 cotto_work I'm sure we'll find one or two.
21:13 cotto_work Are there any other issues or questions before we close?
21:14 bluescreen left #parrotsketch
21:14 Util Late report: I attended the VM Summit at PyCon. Blog post pending. .end
21:14 cotto_work Util: looking forward to it
21:15 * lucian is curious about that
21:15 minusnine left #parrotsketch
21:16 Util lucian: anything in particular?
21:16 minusnine joined #parrotsketch
21:17 lucian Util: bits reusable in other VMs
21:18 Util There will be a bit about that.
21:19 mikehh goal setting?
21:19 cotto_work mikehh: I was just about to forget that.  Thanks.
21:20 cotto_work GOAL 1: discuss roadmap goals on parrot-dev (team leads)
21:21 cotto_work GOAL 2: merge branches, clean up (all)
21:21 cotto_work GOAL 3: work on llvm probes for the opsc_llvm branch (bacek, all)
21:21 cotto_work more are welcome
21:29 bluescreen joined #parrotsketch
21:30 cotto_work let's call it a wrap
21:31 nwellnhof left #parrotsketch
21:33 allison starting up the next meeting in the channel...
21:33 allison minusnine asked to meet with lucian and I about python-on-parrot implementations
21:34 minusnine ...but of course others' input is welcome
21:34 allison joining us are the pypy developers, here at the development sprints at PyCon
21:34 minusnine neat. ah the power of technology and collaboration.
21:34 lucian THIS IS OPENSOURCE!
21:34 * lucian kicks cvs into pit
21:35 minusnine basically, all three of us have been talking about such an implementation for a while. I thought it might be a good idea to get onto the same page as to what needs to happen and where we're going.
21:35 minusnine Specifically, allison and lucian have some strong ideas.
21:36 minusnine (I'm just tagging along and (hopefully) will do what I'm told :-)
21:36 allison lucian: could you tell us a little about pynie-ng (have I got the name right)?
21:37 lucian allison: yeah, i guess
21:37 lucian the idea is to reuse an existing pure-python compiler, rewriting the backend to target PIR or maybe Winxed
21:37 lucian then, to close the loop by implementing the core types the compiler references on parrot, likely in winxed
21:39 allison do you have a specific pure-python compiler in mind?
21:39 allison or, still evaluating options?
21:40 lucian allison: the most promising one is PyPy
21:40 lucian there are a few others, although less nice
21:40 lucian afaict, there isn't any pure python3 one
21:41 lucian s/is PyPy/is PyPy's/
21:43 allison summarizing from pypy developers...
21:43 allison they say the pure-python parser that they have is tightly coupled with the pypy interpreter
21:44 lucian allison: in that it outputs PyPy interpreter-specific bytecode?
21:44 allison that is, it's not currently intended for multiple backends
21:44 bluescreen left #parrotsketch
21:44 allison on the other side, they have the pypy static compiler, which only inputs RPython (not full Python syntax)
21:44 allison and compiles it to multiple backends
21:45 lucian allison: yes, but that generates interpreters
21:45 lucian in fact, it's an entire (and huge) translation framework
21:46 allison a translation framework for RPython, not Python
21:46 lucian allison: yes
21:46 allison (this is an important distinction as far as they're concerned)
21:46 lucian allison: also, RPython is mostly just an implementation detail of their VM-building framework
21:46 allison that is, the full object framework is implemented to run in RPython
21:46 lucian their terminology is kinda crappy
21:47 allison and we'd be running their VM on top of our VM
21:47 lucian allison: yes. which is pointless
21:47 allison yup, agreed
21:47 allison (and they also agree)
21:47 minusnine fwiw, I agree too.
21:47 Util Parrot + PyPy = FlyPy :)
21:47 lucian Util: more like divepy
21:48 lucian i'd be *SLOOOW*
21:48 lucian it'd
21:48 allison yup
21:48 lucian allison: i'm not convinced that their compiler isn't useful, however
21:48 allison there's a chance that we could bootstrap it
21:49 allison as in, run it initially in PyPy or CPython, to generate a PIR version of itself
21:49 lucian allison: i wouldn't be dissatisfied if the pynie-ng compiler depended on CPython for a while
21:49 allison and thereafter use the PIR version to regenerate the PIR version
21:50 allison yes, I'd be totally fine with a CPython dependency to get started
21:50 lucian but yes, bootstrapping would prove pynie-ng is useful
21:50 lucian the main barrier is that most reusable code is written in python2, and pynie would be python3
21:51 lucian of course, later moving to CPython3 and then to pynie-ng would also be ok
21:51 allison if we used the PyPy parser directly, pynie-ng wouldn't be python3 anymore
21:51 lucian allison: indeed
21:51 lucian although i'm not convinced that's a bad idea either
21:51 lucian i'd really like parrot to have both python2 and python3
21:52 allison given time-for-development, we're more likely to get adoption for python3
21:52 allison but, yes, both python2 and python3 would be ideal
21:52 lucian yes, i tend to agree that python3 should probably done before python2
21:52 minusnine agreed on python3 before python2
21:53 allison any chance that we could use the existing pypy parser for python2, develop it in parallel with an updated version of the same parser for python3
21:53 lucian allison: do you happen to know whether the pypy parser uses the CPython grammar file?
21:53 allison and contribute the python3 updates back to pypy?
21:53 allison yes
21:53 lucian allison: i think that's unlikely, unless pypy folks refactor their compiler to be retargetable
21:53 allison (the pypy developers say)
21:54 allison they start with the straight CPython grammar, then run it through their own version of pgen implemented in RPython
21:54 lucian i'd see pynie-ng as more of a fork of the pypy compiler than a branch
21:54 allison the Python3 parser can be a total fork
21:54 lucian allison: i see. that's annoying
21:54 allison not necessarily
21:55 lucian i'd love to have *one* python compiler with multiple backends, to be used by everyone
21:55 allison I mean, we could do a pretty straight translation of their pgen-in-RPython to pgen-in-PIR
21:55 lucian allison: can't it be in pure python?
21:56 cxreg left #parrotsketch
21:56 * lucian has little experience with compilers
21:56 lucian my internet will die for a bit
21:56 allison afaik, RPython is a subset of CPython, so runs on the straight interpreter... let me double-check with them
21:56 lucian 2mins max
21:56 allison okay, will wait for you
21:58 lucian_ joined #parrotsketch
21:59 * lucian_ is back
21:59 * allison blocking on other sprinters, just a sec
22:00 lucian_ allison: afaik RPython running on CPython still depends on the PyPy translation framework
22:02 lucian left #parrotsketch
22:02 allison answer: RPython syntax is a pure subset of CPython so it runs directly
22:02 lucian_ is now known as lucian
22:03 allison but, depending on how pgen-on-RPython was implemented, it might depend on some libraries from PyPY
22:03 minusnine grr my turn: fwiw, the passive observer needs to commute to ny perl seminar (should only be a few minutes). I'll rejoin there.
22:03 allison so, we'd need to try it out and see
22:03 minusnine please continue the discussion
22:03 allison minusnine: will update you on anything when you return
22:03 lucian allison: i see. i remember you said you tried the stdlib ast modile
22:04 allison well, I tried hacking out the CPython parser directly from the interpreter
22:05 allison I didn't try introspecting through the ast module on a running CPython interpreter
22:05 lucian allison: so parse with ast, compile from that ast to something?
22:05 allison (I was trying to avoid the full CPython interpreter)
22:06 allison scraping the ast in a running CPython interpreter might be a decent bootstrapping option
22:06 lucian allison: yes, and rewrite the parser in pure python later on
22:06 allison i.e. use it to dump PIR, and then run PIR directly on Parrot VM
22:06 lucian yep
22:07 lucian i really wouldn't mind depending on cpython for the foreseeable future, everyone has it
22:07 allison yes, pure python parser could be later (possibly based on PyPy's pgen-in-RPython)
22:07 lucian allison: and we'd get py3 for "free" http://docs.python.org/rele​ase/3.0.1/library/ast.html
22:07 allison cpython3?
22:07 lucian well, cpython3 requires installation, yes
22:08 allison or, is ast the same for both 2 and 3?
22:08 lucian allison: not quite afaik
22:09 allison makes sense
22:09 lucian ah, no http://docs.python.org/library/ast.html
22:09 allison but, it'd likely be possible to port cpython3 ast scraper to cpython2 ast scraper
22:09 lucian this has been removed in py3, but not really useful http://docs.python.org/library/compiler.html
22:09 lucian so the ast module seems identical for both
22:10 allison sweet!
22:10 allison just a sec, let me check with core python devs
22:11 lucian perhaps core devs might be convinced to rewrite in pure python?
22:12 allison rewrite which in pure python?
22:12 allison ast is slightly different in 2 and 3, 3 is somewhat simplified
22:12 allison (more details coming...)
22:12 lucian allison: rewrite the ast module
22:12 lucian it's C now afaik
22:12 plobsing left #parrotsketch
22:13 plobsing joined #parrotsketch
22:18 allison http://docs.python.org/devguide/compiler.html
22:20 allison so, the differences between 2 and 3 are functional
22:20 allison that is, they're because of the different behaviour on 2 and 3
22:20 allison but, they're both written in the same AST format
22:21 allison Zephyr Abstract Syntax Definition Language
22:21 allison (full definition linked from that page above)
22:22 lucian right
22:22 allison so, it's possible that we could have one translator for both
22:22 * lucian page still loading here
22:23 lucian ah, done
22:23 minusnine_ joined #parrotsketch
22:23 minusnine_ woohoo. back.
22:23 allison giving an initial workflow of:
22:23 allison 1) write your application in CPython
22:24 allison 2) load it in CPython, together with a PIRTranslator module
22:24 allison 3) dump your full application to PIR
22:24 allison 4) Run it on the Parrot VM
22:25 allison pretty compelling for trying out Parrot
22:25 allison minusnine: we're looking at CPython's ast
22:25 allison minusnine: http://docs.python.org/devguide/compiler.html
22:26 lucian allison: do you mean that 2) is online compilation?
22:26 lucian or are 2) and 3) just stages of the compilation?
22:26 minusnine_ yup, reading the irc logs
22:26 plobsing left #parrotsketch
22:30 allison lucian: what do you mean by "online compilation"?
22:30 allison lucian: yes, just mean stages of compilation, resulting in a version of the application in PIR
22:30 lucian allison: like PyPy does. but i don't think you meant that
22:31 allison yeah, I meant a more manual compilation process
22:31 allison just as a "first implementation"
22:31 plobsing joined #parrotsketch
22:32 lucian yeah. it might actually be relatively easy to implement
22:32 allison I mean, eventually we'd want to be able to run Python sources straight (a registered compiler module in Parrot)
22:32 allison but, not a bad way to start
22:33 allison we'd still need to implement PyObject and core types in Parrot
22:33 lucian allison: all that would be missing for that is a pure-python parser that offered the same api as the ast module
22:33 allison doable
22:33 lucian allison: yes
22:33 lucian that seems like the bulk of the work
22:33 allison yeah
22:34 allison (for both the pure-python parser later, and objects being the bulk of the work)
22:34 lucian i'm worried about corner-cases
22:35 lucian for both core types and compiler
22:35 allison minusnine: have we caught you up enough?
22:36 allison lucian: yeah, we'll have corner-cases to deal with no matter what the implementation
22:36 minusnine_ :-) yes, thanks. Apologies that I don't have much to offer with regards to strategy and tradeoffs. I'm mostly unfamiliar with the particular projects involved (though am familiar with compiler design and generally mashing systems together)
22:37 allison minusnine: we're all learning here (it's been really nice to have pypy and cpython devs here to answer questions)
22:37 minusnine_ revision: slightly familiar with compiler design. at least I got to steal some knowledge from Al Aho :-)
22:37 allison :) he's da man!
22:38 allison is this a good strategy to start on for pynie-ng?
22:39 allison (and, I'm happy to just call it "Pynie", and deprecate the old repos)
22:39 bubaflub left #parrotsketch
22:41 lucian allison: yeah, pynie sounds fine
22:41 tadzik yay, Python on Parrot!
22:41 lucian allison: also to note is that there would be two versions of the core types, too
22:41 lucian for py2 and py3
22:41 allison that's true
22:41 allison should we start on py3 for simplicity?
22:41 allison get one working?
22:42 lucian allison: yes, old style classes are just a headache
22:43 lucian i'm tempted to not implement old style classes in pynie2, but since it's for backwards compat, not very useful
22:43 allison so, basically two pieces, py3 classes, (written in winxed?) and a CPython3 module to dump AST->PIR
22:43 lucian yep, pretty much
22:44 lucian NotFound suggested maybe doing AST->winxed for simplicity
22:44 allison lucian: yeah, seems pynie2 classes will have to be backward compatible, no matter how ugly
22:44 minusnine_ agreed. supporting earlier than at least python 2.2 should probably out of scope
22:44 lucian allison: it's entirely possible that by the time pynie is usable, people would've moved to py3 more
22:44 lucian minusnine_: i'm thinking py2.7
22:45 allison lucian: ast->winexd could work too, though it's an extra stage... does winexed translate directly to PIR?
22:45 minusnine_ lucian: agreed
22:45 lucian allison: yes, winxed->pir
22:45 davidfetter py3 == way out ahead of a lot of python apps
22:45 allison lucian: I mean, ultimately we want to produce code that runs on Parrot VM with the smallest possible interpretation overhead
22:45 allison lucian: great
22:45 lucian davidfetter: yep. pynie will manage to beat cpython3 at not running anything
22:46 davidfetter lol
22:46 allison davidfetter: it is, but we (python devs) are working really hard now on python3 migration plans
22:46 davidfetter <-- python n00b
22:46 davidfetter thanks for the heads-up :)
22:46 allison davidfetter: so, by the time python3-on-parrot is strong, there will be more available
22:47 lucian allison: at least for now, if winxed compiles reasonably fast, it may be a good target
22:47 davidfetter christmas? 2011q3?
22:47 allison davidfetter: (I'm assuming we're talking 2-years-ish)
22:47 davidfetter k
22:48 * davidfetter would dearly love to be able to produce a PL/Python (sandboxed language for postgres) using parrot
22:48 lucian allison: but winxed semantics might be restrictive (or at least more restrictive than PIR's)
22:49 minusnine_ davidfetter: has parrot been integrated into postgres yet?
22:49 allison lucian: ah, good point
22:49 whiteknight joined #parrotsketch
22:49 Tene minusnine_: Yes.
22:49 davidfetter minusnine_, well, dukeleto++ did some amazing work on PL/PIR and PL/Rakudo, so yes
22:49 Tene minusnine_: you'll want to talk to dukeleto about it.
22:50 davidfetter but nothing out there's in production yet, afaik
22:50 minusnine_ Tene, davidfetter: no worries, i just missed that. that's very cool.
22:50 davidfetter it was my dumb idea, long ago, but dukeleto actually went and built it :)
22:51 davidfetter ...which turned it from a dumb idea to a cool hack ;)
22:51 Tene fwiw, looks like 6model is going to be a very good base to build an object model on.  It's more than sufficiently flexible to support Cardinal, which Parrot's objects weren't.
22:52 lucian Tene: i'll have to look into that
22:52 Tene Once I get cardinal's object model working well, I've already been planning on writing an object model for python.
22:52 davidfetter speaking of which, what stat's cardinal in atm?
22:52 davidfetter state's*
22:52 Tene davidfetter: blocked on a new object model
22:52 davidfetter heh
22:52 lucian allison: any insight on 6model
22:54 allison (just a sec, in conversation with python 2-to-3 developers)
22:54 lucian ok
22:56 lucian https://github.com/jnthn/6mo​del/blob/master/overview.pod sounds alright
22:56 lucian there are some assumptions that are a mismatch to python, though
22:56 allison I suspect 6model is going to be a terrible fit for Python
22:56 allison I certainly wouldn't wait for it or block on it
22:57 Tene allison: Why is that?
22:57 lucian Tene: for one, it has methods and it optimises for that
22:58 lucian python has no methods
22:58 allison Tene: it may be a much closer fit for ruby, as perl6 objects are heavily inspired by ruby
22:59 tadzik is python object model too primitive for that?
22:59 Tene allison: Not really; the Perl 6 representation built on 6model is totally inappropriate for ruby.
22:59 lucian tadzik: it's just very different
22:59 lucian it could be implemented with just attributes (ignoring 6model methods)
22:59 Tene Ruby's attributes are completely different, inheritance model is very different, etc.
22:59 lucian tadzik: oh, you meant methods? python methods are just attributes that are callable
22:59 allison Tene: I thought you said it was a good fit?
23:00 allison (6model and ruby)
23:00 Tene allison: I said that 6model is, not the Perl 6 representation built on 6model.
23:00 lucian allison: it might be nice if the 6model method cache could be used for python, i guess
23:00 allison Tene: or, are you saying it's sufficiently general to accomodate different object models?
23:00 lucian allison: the way i see it, 6model is a small subset of CLOS
23:01 Tene allison: That's what I'm saying.  Rakudo will use (among others) a representationc alled P6Opaque, which is built on 6model.
23:01 allison Tene: okay, that's reasonable
23:01 allison Tene: I'm reacting at a more fundamental level, having been badly burned by trying to use NQP for Python
23:01 allison Tene: so very, very wary of relying on anything Perl6-related
23:01 Tene Sure.
23:02 * lucian openly hates perl5
23:02 allison Tene: but, 6model may turn out to be different
23:02 lucian it bothers me a bit that in 6model state and behaviour are lumped together
23:02 allison lucian: at this point though, we still shouldn't block on any other implementation efforts
23:02 * minusnine_ am learning about abuses of perl5's typeglobs
23:02 lucian allison: so roll our own?
23:02 allison lucian: so if it's simple enough to roll PyObject in winexed, go for it
23:03 lucian allison: i'm not sure it is
23:03 lucian i certainly wouldn't mind getting stuff for free
23:03 plobsing left #parrotsketch
23:03 allison lucian: we can always re-implement later with 6model if it looks good
23:03 Tene For example, Perl 6 attributes are pre-declared, (mostly) known at compile-time, and per-class, such that separate attributes of the same name in classes that inherit from each other are different storage locations.  In Ruby, objects just have a flat set of attributes, completely unrelated to any classes.
23:03 Tene lucian: Explain what bothers you about 6model's treatment of state and behaviour?
23:04 lucian Tene: it assumes single dispatch
23:04 allison lucian: is it easier to implement PyObject in PIR, or Parrot's PMC macroized-C?
23:04 lucian allison: i don't have experience with the latter, but it scares me
23:04 lucian i'd say winxed/pir
23:05 allison lucian: another possibility is to see how much of PyPy's PyObject implementation we could use
23:05 allison not sure if it's in RPython or in C
23:05 lucian allison: i doubt if any. it seems to heavily depends on the object space, written in RPython, and again depending on PyPy libs
23:05 allison agreed, winexed/pir sounds like the safest option to me
23:06 allison lucian: yeah, that's a big dependency in PyPY
23:06 plobsing joined #parrotsketch
23:06 Tene lucian: I don't think that that's the case?  Multiple-dispatch isn't in the problem space that 6model is addressing.  6model provides means to build single dispatch semantics, as those are part of the object model, but you don't have to use them if they don't make sense for your language.
23:06 lucian Tene: if i don't use them, what's the point? also, what about performance, since 6model will optimise for single-dispatch, attributes-and-methods
23:07 allison Tene: the thing is, what we're trying to implement is Python's core data types, much lower-level than an object model
23:08 lucian allison: not really much lower
23:08 allison long-term, I'm open-minded on 6model
23:08 allison for now, winexed/pir seems like the best starter approach
23:08 lucian allison: all python core types are objects
23:08 allison lucian: they have a method/attribute interface, yes
23:09 lucian allison: it's an implementation detail that they just act like 'object'
23:09 lucian so it'd be nice if 6model could be used for 'object', and inherit that for 'dict' and so on
23:09 Tene lucian: First, be aware that I'm very uninformed about python's object model.
23:11 Tene Having said that, 6model provides an API for representation polymorphism and behaviours around method dispatch, attribute access, etc.
23:11 lucian Tene: in short, objects are things with attributes. attributes can be get/set pretty much from anywhere. there are functions (callables). functions can be attributes of objects, and when bound receive self (like this) as the first argument
23:12 lucian so obj.bla gets the attribute
23:12 lucian it could be a function
23:12 Tene lucian: Are attributes declared?  Do all instances of a class have the same set of attributes?
23:12 Tene Can anyone set additional attributes on an object?
23:12 Tene can I just say "obj.my_special_attr = 1" from anywhere?
23:12 lucian Tene: attributes aren't declared. instances only share class attributes
23:12 lucian Tene: yeah, pretty much
23:13 lucian Tene: think of objects like huge dicts, similar a bit to lua/js
23:13 allison lucian: er, no on the randomly created attributes, IIRC
23:13 Tene Okay, that's a lot like Ruby's attribute model.
23:13 lucian allison: it doesn't work on 'object', but it works on user-created classes
23:13 lucian it's a CPython detail afaik
23:13 Tene lucian: class attributes?  Are those just attributes on the class object?
23:13 lucian Tene: yeah, pretty much
23:13 allison lucian: on classes or instances of classes?
23:14 lucian allison: i think both. i should try before spouting crap
23:14 Tene Are those accessed through the object, or separately through the class?  If I access an attributes on an object that's not set, does it look at the class for a fallback or something?
23:14 lucian Tene: class as fallback
23:14 lucian sort of
23:15 lucian Tene: i think that's exactly what happens in fact
23:15 lucian can i paste here? my browser's acting up
23:16 cotto left #parrotsketch
23:16 Tene Sure.
23:16 lucian ah, finally https://gist.github.com/871711
23:16 lucian excuse the crappy names
23:16 lucian allison: as you can see, for user-created classes it works. try that with object() and it won't
23:17 Tene So, in 6model, your repr for user objects would have (at least) a reference to a class and a reference to a dict to store attributes in.  I don't know what inheritance is like in python, if it supports MI or can change at runtime or anything.
23:18 lucian Tene: both
23:18 lucian Tene: it's C3 though, so not weird
23:19 Tene lucian: Here's what jnthn's proposed repr for ruby looks like: https://github.com/perl6/nqp/blob/mast​er/src/metamodel/reprs/HashAttrStore.c
23:19 lucian Tene: python's objects are indeed similar to ruby's when it comes to actual usage
23:20 Tene So, object is something different, then?  What's object() ?
23:20 lucian the root object
23:20 allison mmm... this is a new definition of "simple" I'm not familiar with
23:21 allison sorry, I'm descending into sarcasm, I think I'm hungry :(
23:21 lucian allison: it does look at least a little horrible. and it's C
23:21 Tene :)
23:22 lucian Tene: so is this the common way to use 6model?
23:22 allison Tene: do you know if it's anticipated that the language implementations of object models on 6model with be implemented in macroized-C?
23:22 Util Regarding 6model's single/multiple inheritance: see http://irclog.perlgeek.de/p​arrot/2011-03-15#i_3396281
23:22 allison er, yeah, what lucian asked
23:24 allison lucian: it may be too early to know yet
23:24 lucian Util: i'm not too bothered by inheritance, it's easy after you have attributes working
23:25 Tene allison: That's just the instance representation/storage; the behaviour of things like inheritance, method lookup, etc. is just methods on an object, and so can be implemented in any HLL.
23:25 lucian well, for a certain definition of 'easy'
23:25 Tene Cardinal's will be written in Ruby.
23:25 lucian Tene: subset of ruby?
23:26 allison full-ruby without objects?
23:26 * lucian is back in 5min
23:27 allison or, full-ruby with proto-objects provided by 6model?
23:28 Tene allison: I expect it to be full ruby with possibly some custom cardinal-specific extensions.
23:28 Tene I'm fairly confident that it's bootstrappable without notable difficulty, but I haven't actually done it yet.
23:28 * allison renotes unpleasant past experiences building on top of systems that are unfinished and rapidly changing
23:29 Tene allison: "I expect it to be ..." is talking about my expectations for implementing ruby's model for cardinal, not talking about expected changes in 6model.
23:29 allison but then, that rule may apply to Parrot itself in the not-to-distant-future, if Lorito is realized
23:30 Tene Nothing I've looked at so far has changed in any way that I've noticed over the past two months or so.  I've been working on this very intermittently.  Very busy with work lately.
23:31 Tene But, you're right, there are likely to be changes.  At the very least, Parrot is planning to adopt 6model into its core.
23:31 Tene There's likely to be some amount of shuffling at that point.
23:32 Tene I'm not particularly invested in "selling 6model" or anything, just trying to be informative.
23:33 Tene FWIW, the object model for NQP is written in NQP: https://github.com/perl6/nqp/blob/mas​ter/src/metamodel/how/NQPClassHOW.pm
23:34 allison how heavy are the dependencies for 6model now?
23:34 cotto_work allison: "when" ;)
23:34 allison cotto: er, what?
23:34 cotto_work <allison> but then, that rule may apply to Parrot itself in the not-to-distant-future, if Lorito is realized
23:35 allison ah, I thought you were answering the question about 6model dependencies :)
23:35 allison "when" sounds like one of those weird perl 6 object model things
23:35 cotto_work that would be a strange answe
23:35 cotto_work r
23:35 Tene allison: NQP, although it could probably be extracted out, and likely will when imported into parrot's core.
23:36 allison it's got like, HOW and WHAT, ja?
23:36 allison NQP is right out as a dependency for pynie
23:36 allison been there, done that
23:38 Tene 'k
23:38 TimToady "NQP" is more than one thing these days
23:40 allison TimToady: I'm familiar with it as "a lightweight language, partial Perl 6 + p6 regexes, targeted at implementing compilers"?
23:41 TimToady with native reprs, it is potentially becoming a C replacment
23:41 allison particularly targeted at implementing perl 6, but general enough to implement multiple dynamic languages
23:42 allison in the sense of being a good language to write system libraries in?
23:42 TimToady potentially, but then, that's always been an underlying goal of adding a type system to Perl 6 :)
23:42 allison or, a good general-purpose low-level language?
23:43 allison or, a good way of writing very fast (static) code?
23:43 TimToady well, the "NQ" of "NQ" keeps varying...
23:43 TimToady we hope the dynamic range of p6 is that large, so not-quite that may achieve some of it
23:44 allison "NotQuite" transforming to "Very Close To"?
23:44 TimToady in spots
23:45 TimToady but we're very hopeful that the native types will turn out to be quite useful in writing fast, low-level code
23:46 TimToady and I agree, it's always hard to bootstrap a full stack
23:47 Tene allison: There's nothing in 6model that requires using the language NQP.  It can be used just fine from any language that can run on Parrot.  It currently lives in the nqp repository, and the current examples all are written in NQP.  I don't know what your issues with NQP are, and how this fits in exactly.
23:47 * lucian back
23:49 lucian Tene: i still don't see how you'll be able to run ruby code without objects
23:49 Tene allison: One of the goals of 6model, already partially realized, is allowing NQP and then Rakudo to use much more efficient representations.  NQP can currently inline native attributes (int, num, str), which cuts down GC and attribute access time quite a bit.
23:49 Tene lucian: I won't.
23:50 lucian Tene: then how would you write ruby objects in ruby?
23:50 Tene lucian: Where would there be no objects?
23:50 lucian Tene: in the ruby implementation of ruby objects
23:51 TimToady just talking to jnthn, who says nqp does not yet have compact structs of native types, but only because he's been working on other things, not because it's "something that needs hard thought"
23:51 Tene Apparently I'm making shit up, then.
23:51 Tene That's unfortunate.
23:51 Tene :/
23:52 TimToady he says the inlining stuff is already mostly there
23:52 TimToady it's mostly boxing/unboxing that needs work
23:52 Tene Maybe I got it confused with native types for variables and some of the NYI stuff in P6Opaque.c
23:53 TimToady the stuff already works on the object level, but nqp's compiler hasn't been taught to use the native stuff, basically
23:53 Tene Still, if I was wrong about that, I'd recommend that you be skeptical about the rest of what I've said.  I thought I was getting a bit more reliable these days, but apparently not.
23:54 TimToady so all he has to do is implement the equivalent of a C++ compiler--no sweat :)
23:55 TimToady but the important thing is that jnthn thinks the 6model stuff is not another hack, but "close to right" on first principles
23:56 Tene lucian: given that I don't actually have code to support my claims, I wouldn't necessarily take me that seriously here.  It certainly may be that I use a restricted subset, or something.
23:56 lucian Tene: i don't see a way out other than using a subset, for the actual types
23:56 whiteknight even "close to right", 6model is still miles ahead of Parrot's current woefully-inadequate MOP offering
23:57 plobsing left #parrotsketch
23:57 lucian whiteknight: perhaps, but not necessarily appropriate for pynie
23:57 lucian i'd like it to be, so i'd have less work to do
23:57 whiteknight lucian: is Parrot's current MOP any more suited to pynie than 6model is?
23:58 allison whiteknight: we'd likely bypass that too
23:58 whiteknight ignoring the cultural ties to perl
23:58 lucian whiteknight: not really. it's either custom or 6model, the way i see it
23:58 Tene lucian: However, to a first approximation: I don't need the object model up to compile the code for the object model, as my compiler isn't written in ruby.  If my compiler were written in ruby, it would be using whatever already-compiled object model the compiler process was using, so still wouldn't be relevant.  At the time the object model code itself is running, there's obviously an object model loaded, as that's the code that's ...
23:58 Tene ... running.
23:58 whiteknight parrot wants 6model not because it's best for everybody but because it's less wrong for everybody than what we have right now
23:59 lucian whiteknight: i don't really know 6model, but from what i've read it makes assumptions that are wrong for both python and CLOS
23:59 Tene lucian: You still haven't explained what those assumptions are?

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