Priorities for this week: irclog.perlgeek.de/parrotsketch/201...#i_3348283 | Post closed tickets in your report. | Note: This channel is for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 1 March 2011.
01:35 whiteknight left 03:04 ShaneC left 05:32 contingencyplan left 07:15 eternaleye_ joined 07:19 eternaleye left 08:32 lucian joined 08:36 lucian left 10:13 lucian joined 10:22 lucian left 10:29 lucian joined 11:08 lucian left, lucian joined 11:31 lucian left 11:32 lucian joined 11:56 lucian left 12:01 lucian joined 12:50 bluescreen joined 12:55 lucian left 13:11 bluescreen left 13:19 bluescreen joined 13:21 atrodo joined 13:29 bluescreen left 13:38 contingencyplan joined 13:40 bluescreen joined 14:32 bluescreen left 14:55 mikehh joined 15:22 bluescreen joined 16:12 bluescreen left 17:05 lucian joined 17:11 bluescreen joined 17:22 ShaneC joined 17:35 whiteknight joined
whiteknight will not be at #parrotsketch today 17:35
WHAT I DID:
* Started looking into TT #1886 for Coke. I think I have a solution in mind, although it's going to require some grunt-work.
* Setup a github pages website for Rosella. Going to be adding content and tutorials to it. (whiteknight.github.com/Rosella/)
* Fixes, cleanups and improved test coverage throughout Rosella.
* Created an experimental new Rosella library for contracts and runtime assertions
* Lots of work on the Rosella proxies library. Ability to make read-only proxies. Ability to make transparent proxies.
* Still plugging away, slowly, at the imcc branch.
WHAT I WILL DO:
* Work on TT #1886 for Coke 17:36
* Try to wrap up development on the IMCC branch and open it up for testing
* Play around with the new contracts library for Rosella
* Start working towards a release for Rosella (and maybe PLA)
WHAT I AM BLOCKING ON:
* Only 24 hours in the day? When did that happen?
18:27 ekg joined 18:28 ekg left 18:29 minusnine joined
lucian salutes minusnine 18:32
minusnine waves 18:34
18:34 allison joined 18:50 particle left 18:53 particle joined 19:03 bluescreen left, kid51 joined
kid51 kid51's report 19:03
* Closed trac.parrot.org/parrot/ticket/2037 following bacek++'s research
* Some PaFo business
* Stressful week at $job; little energy for Parrot.
* Meeting up with dukeleto tomorrow 19:04
19:04 bluescreen joined
kid51 * At today's parrotsketch, we should review progress toward our 3.3 Roadmap Goals 19:04
EOR
(With advent of DST, 2030 UTC => 1630 US EDT; 1330 US PDT) 19:05
(I'll only be able to attend first 30 min of meeting today due to Perl Seminar NY.) 19:06
Change of plans: Won't be able to attend any of parrotsketch today due to $job conflict 19:22
19:22 kid51 left 19:50 benabik joined 19:51 bubaflub joined 20:00 minusnine left 20:10 plobsing joined
mikehh What I did since my last report: 20:12
* building and testing parrot on amd64/i386, with gcc/g++
* some fixes
* branch testing and fixes
What I intend to do in the next week:
* testing and fixing
.eor
cotto_work *did: 20:15
- code review, feedback
- pushed developer tips doc (docs/project/hacking_tips.pod), improvements welcome
- uploaded docs for the release
- M0 roadmap progress
-- have the basic idea behind ffi, needs a bit of refining
- profiling runcore progress
-- none
*will do:
- finish M0 ffi, start on concurrency primitives, start polishing the spec 20:16
*blockers:
- none
*eor
atrodo .did 20:19
* isparrotfastyet hacking
* lorito thinking but no hacking
.todo
* isparrotfastyet
* help with the m0-spec with ernest
* lorito experiments
.eor
20:21 minusnine joined
cotto_work q1q 20:24
bubaflub DID: 20:26
Cardinal hacking
TODO:
More cardinal hacking
Learn about NCI for GSoC
cotto_work hello 20:29
20:30 davidfetter joined
allison hi 20:31
cotto_work could be a quiet day today 20:32
bacek aloha
bubaflub hello
davidfetter namaste
plobsing HI
mikehh hi there
cotto_work our goals for last week were: 20:33
GOAL 1: Get more GSoC ideas on the wiki. (all)
GOAL 2: Close tickets (all)
GOAL 3: Produce a stable release, make life easy for gerd (all)
GOAL 4: Be ready next week to assess status of roadmap goals
How did we do with those?
plobsing by my count, we have 23 GSoC ideas posted on the wiki 20:34
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
cotto_work Our ticket count looks about the same. 20:35
20:35 nwellnhof joined
bacek q2q 20:36
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?
mikehh didn't see any particular ones, gerd++ mentioned server links slow
cotto_work I generated the docs from the release tarball, so that part worked fine. 20:38
any other comments before we move to questions? 20:39
my q: Do we want to switch back to gen_gc as the default gc for a couple weeks? 20:40
mikehh are we going (bacek++) to work on gc at all during the period of switch 20:42
cotto_work It's more likely to get tuits than gc_ms2. 20:43
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.
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?
bacek no one 20:46
cotto_work tadzik: that's the big reason we're keeping it.
tadzik ok, just checking
cotto_work (as the default)
mikehh I would say switch and switch back only if we get complaints
cotto_work eoq from me then
lucian are there any significant users other than rakudo that have issues on gms?
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:47
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
lucian for stressing the new gc, if nothing else
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
eoq (really)
bacek: go ahead
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:52
allison bacek: it's hosted by perl.org 20:53
bacek: afaik, the only way to add a blog to it currently is to submit a request to the perl.org admins
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
cotto_work bacek: I look forward to following your blog. 20:55
allison planet sites aren't difficult to set up
would be nice to pick one of the planet implementations that allows web submissions of new blogs to aggregate
bacek who can ask OSUOSL folks to setup one on parrot.org?
cotto_work bacek: anyone can ask. They're pretty responsive on #osuosl on freenode. 20:56
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.
cotto_work bacek: ok 20:58
bacek q2: opsc_llvm branch
Currently it's highly experimental for LLVM bindings
I would like to get more eyeballs on it.
lucian bacek: to the llvm c api?
bacek lucian, yes
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.
lucian has been dreaming of writing a JIT in a HLL for a while
bacek If we can solve it than we'll have almost functional LLVM bindings in Parrot. 21:00
And I can move to next target - implement JIT prototype :)
mikehh you seem to have to be specific - I have both 2.7 and 2.8 on my system, 2.9 is available
bacek mikehh, yes. Probable via Configure.pl --llvm-lib=/usr/lib/libLLVM-2.8.so 21:01
or something like this
Coke both whiteknight and I have keys to planet parrot. please don't bug the perl.org admins.
bacek Coke, ok, thanks.
Coke and we've already started the dialog about moving the planet. it's just a realllly low priority. 21:02
cotto_work any other questions? 21:05
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:06
thoughts? objections? 21:08
allison bacek: yah, with all things parrot.org related I should note Coke knows the most
mikehh no objectios
do we have any branches ready to merge? 21:09
cotto_work I'm sure we'll find one or two. 21:12
Are there any other issues or questions before we close? 21:13
21:14 bluescreen left
Util Late report: I attended the VM Summit at PyCon. Blog post pending. .end 21:14
cotto_work Util: looking forward to it
lucian is curious about that 21:15
21:15 minusnine left
Util lucian: anything in particular? 21:16
21:16 minusnine joined
lucian Util: bits reusable in other VMs 21:17
Util There will be a bit about that. 21:18
mikehh goal setting? 21:19
cotto_work mikehh: I was just about to forget that. Thanks.
GOAL 1: discuss roadmap goals on parrot-dev (team leads) 21:20
GOAL 2: merge branches, clean up (all) 21:21
GOAL 3: work on llvm probes for the opsc_llvm branch (bacek, all)
more are welcome
21:29 bluescreen joined
cotto_work let's call it a wrap 21:30
21:31 nwellnhof left
allison starting up the next meeting in the channel... 21:33
minusnine asked to meet with lucian and I about python-on-parrot implementations
minusnine ...but of course others' input is welcome 21:34
allison joining us are the pypy developers, here at the development sprints at PyCon
minusnine neat. ah the power of technology and collaboration.
lucian THIS IS OPENSOURCE!
lucian kicks cvs into pit
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
Specifically, allison and lucian have some strong ideas.
(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)?
lucian allison: yeah, i guess 21:37
the idea is to reuse an existing pure-python compiler, rewriting the backend to target PIR or maybe Winxed
then, to close the loop by implementing the core types the compiler references on parrot, likely in winxed
allison do you have a specific pure-python compiler in mind? 21:39
or, still evaluating options?
lucian allison: the most promising one is PyPy 21:40
there are a few others, although less nice
afaict, there isn't any pure python3 one
s/is PyPy/is PyPy's/ 21:41
allison summarizing from pypy developers... 21:43
they say the pure-python parser that they have is tightly coupled with the pypy interpreter
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
allison on the other side, they have the pypy static compiler, which only inputs RPython (not full Python syntax) 21:44
and compiles it to multiple backends
lucian allison: yes, but that generates interpreters 21:45
in fact, it's an entire (and huge) translation framework
allison a translation framework for RPython, not Python 21:46
lucian allison: yes
allison (this is an important distinction as far as they're concerned)
lucian allison: also, RPython is mostly just an implementation detail of their VM-building framework
allison that is, the full object framework is implemented to run in RPython
lucian their terminology is kinda crappy
allison and we'd be running their VM on top of our VM 21:47
lucian allison: yes. which is pointless
allison yup, agreed
(and they also agree)
minusnine fwiw, I agree too.
Util Parrot + PyPy = FlyPy :)
lucian Util: more like divepy
i'd be *SLOOOW* 21:48
it'd
allison yup
lucian allison: i'm not convinced that their compiler isn't useful, however
allison there's a chance that we could bootstrap it
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
allison and thereafter use the PIR version to regenerate the PIR version
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
the main barrier is that most reusable code is written in python2, and pynie would be python3
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
lucian allison: indeed
although i'm not convinced that's a bad idea either
i'd really like parrot to have both python2 and python3
allison given time-for-development, we're more likely to get adoption for python3 21:52
but, yes, both python2 and python3 would be ideal
lucian yes, i tend to agree that python3 should probably done before python2
minusnine agreed on python3 before python2
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?
allison and contribute the python3 updates back to pypy?
yes
lucian allison: i think that's unlikely, unless pypy folks refactor their compiler to be retargetable
allison (the pypy developers say)
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
allison the Python3 parser can be a total fork
lucian allison: i see. that's annoying
allison not necessarily
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
lucian allison: can't it be in pure python?
21:56 cxreg left
lucian has little experience with compilers 21:56
my internet will die for a bit
allison afaik, RPython is a subset of CPython, so runs on the straight interpreter... let me double-check with them
lucian 2mins max
allison okay, will wait for you
21:58 lucian_ joined
lucian_ is back 21:59
allison blocking on other sprinters, just a sec
lucian_ allison: afaik RPython running on CPython still depends on the PyPy translation framework 22:00
22:02 lucian left
allison answer: RPython syntax is a pure subset of CPython so it runs directly 22:02
22:02 lucian_ is now known as lucian
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.
allison so, we'd need to try it out and see
minusnine please continue the discussion
allison minusnine: will update you on anything when you return
lucian allison: i see. i remember you said you tried the stdlib ast modile
allison well, I tried hacking out the CPython parser directly from the interpreter 22:04
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?
allison (I was trying to avoid the full CPython interpreter)
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
allison i.e. use it to dump PIR, and then run PIR directly on Parrot VM
lucian yep
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)
lucian allison: and we'd get py3 for "free" docs.python.org/release/3.0.1/library/ast.html
allison cpython3?
lucian well, cpython3 requires installation, yes
allison or, is ast the same for both 2 and 3? 22:08
lucian allison: not quite afaik
allison makes sense 22:09
lucian ah, no docs.python.org/library/ast.html
allison but, it'd likely be possible to port cpython3 ast scraper to cpython2 ast scraper
lucian this has been removed in py3, but not really useful docs.python.org/library/compiler.html
so the ast module seems identical for both
allison sweet! 22:10
just a sec, let me check with core python devs
lucian perhaps core devs might be convinced to rewrite in pure python? 22:11
allison rewrite which in pure python? 22:12
ast is slightly different in 2 and 3, 3 is somewhat simplified
(more details coming...)
lucian allison: rewrite the ast module
it's C now afaik
22:12 plobsing left 22:13 plobsing joined
allison docs.python.org/devguide/compiler.html 22:18
so, the differences between 2 and 3 are functional 22:20
that is, they're because of the different behaviour on 2 and 3
but, they're both written in the same AST format
Zephyr Abstract Syntax Definition Language 22:21
(full definition linked from that page above)
lucian right 22:22
allison so, it's possible that we could have one translator for both
lucian page still loading here
ah, done 22:23
22:23 minusnine_ joined
minusnine_ woohoo. back. 22:23
allison giving an initial workflow of:
1) write your application in CPython
2) load it in CPython, together with a PIRTranslator module 22:24
3) dump your full application to PIR
4) Run it on the Parrot VM
pretty compelling for trying out Parrot 22:25
minusnine: we're looking at CPython's ast
minusnine: docs.python.org/devguide/compiler.html
lucian allison: do you mean that 2) is online compilation? 22:26
or are 2) and 3) just stages of the compilation?
minusnine_ yup, reading the irc logs
22:26 plobsing left
allison lucian: what do you mean by "online compilation"? 22:30
lucian: yes, just mean stages of compilation, resulting in a version of the application in PIR
lucian allison: like PyPy does. but i don't think you meant that
allison yeah, I meant a more manual compilation process 22:31
just as a "first implementation"
22:31 plobsing joined
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)
but, not a bad way to start
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
allison doable
lucian allison: yes
that seems like the bulk of the work
allison yeah
(for both the pure-python parser later, and objects being the bulk of the work) 22:34
lucian i'm worried about corner-cases
for both core types and compiler 22:35
allison minusnine: have we caught you up enough?
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)
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 :-)
allison :) he's da man!
is this a good strategy to start on for pynie-ng? 22:38
(and, I'm happy to just call it "Pynie", and deprecate the old repos) 22:39
22:39 bubaflub left
lucian allison: yeah, pynie sounds fine 22:41
tadzik yay, Python on Parrot!
lucian allison: also to note is that there would be two versions of the core types, too
for py2 and py3
allison that's true
should we start on py3 for simplicity?
get one working?
lucian allison: yes, old style classes are just a headache 22:42
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
lucian yep, pretty much
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
minusnine_ agreed. supporting earlier than at least python 2.2 should probably out of scope
lucian allison: it's entirely possible that by the time pynie is usable, people would've moved to py3 more
minusnine_: i'm thinking py2.7
allison lucian: ast->winexd could work too, though it's an extra stage... does winexed translate directly to PIR? 22:45
minusnine_ lucian: agreed
lucian allison: yes, winxed->pir
davidfetter py3 == way out ahead of a lot of python apps
allison lucian: I mean, ultimately we want to produce code that runs on Parrot VM with the smallest possible interpretation overhead
lucian: great
lucian davidfetter: yep. pynie will manage to beat cpython3 at not running anything
davidfetter lol 22:46
allison davidfetter: it is, but we (python devs) are working really hard now on python3 migration plans
davidfetter <-- python n00b
thanks for the heads-up :)
allison davidfetter: so, by the time python3-on-parrot is strong, there will be more available
lucian allison: at least for now, if winxed compiles reasonably fast, it may be a good target 22:47
davidfetter christmas? 2011q3?
allison davidfetter: (I'm assuming we're talking 2-years-ish)
davidfetter k
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)
minusnine_ davidfetter: has parrot been integrated into postgres yet? 22:49
allison lucian: ah, good point
22:49 whiteknight joined
Tene minusnine_: Yes. 22:49
davidfetter minusnine_, well, dukeleto++ did some amazing work on PL/PIR and PL/Rakudo, so yes
Tene minusnine_: you'll want to talk to dukeleto about it.
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.
davidfetter it was my dumb idea, long ago, but dukeleto actually went and built it :)
...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.
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.
davidfetter speaking of which, what stat's cardinal in atm?
state's*
Tene davidfetter: blocked on a new object model
davidfetter heh
lucian allison: any insight on 6model
allison (just a sec, in conversation with python 2-to-3 developers) 22:54
lucian ok
github.com/jnthn/6model/blob/maste...erview.pod sounds alright 22:56
there are some assumptions that are a mismatch to python, though
allison I suspect 6model is going to be a terrible fit for Python
I certainly wouldn't wait for it or block on it
Tene allison: Why is that? 22:57
lucian Tene: for one, it has methods and it optimises for that
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
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.
lucian tadzik: it's just very different
it could be implemented with just attributes (ignoring 6model methods)
Tene Ruby's attributes are completely different, inheritance model is very different, etc.
lucian tadzik: oh, you meant methods? python methods are just attributes that are callable
allison Tene: I thought you said it was a good fit?
(6model and ruby) 23:00
Tene allison: I said that 6model is, not the Perl 6 representation built on 6model.
lucian allison: it might be nice if the 6model method cache could be used for python, i guess
allison Tene: or, are you saying it's sufficiently general to accomodate different object models?
lucian allison: the way i see it, 6model is a small subset of CLOS
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
Tene: I'm reacting at a more fundamental level, having been badly burned by trying to use NQP for Python
Tene: so very, very wary of relying on anything Perl6-related
Tene Sure.
lucian openly hates perl5 23:02
allison Tene: but, 6model may turn out to be different
lucian it bothers me a bit that in 6model state and behaviour are lumped together
allison lucian: at this point though, we still shouldn't block on any other implementation efforts
minusnine_ am learning about abuses of perl5's typeglobs
lucian allison: so roll our own?
allison lucian: so if it's simple enough to roll PyObject in winexed, go for it
lucian allison: i'm not sure it is 23:03
i certainly wouldn't mind getting stuff for free
23:03 plobsing left
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.
lucian: Explain what bothers you about 6model's treatment of state and behaviour?
lucian Tene: it assumes single dispatch 23:04
allison lucian: is it easier to implement PyObject in PIR, or Parrot's PMC macroized-C?
lucian allison: i don't have experience with the latter, but it scares me
i'd say winxed/pir
allison lucian: another possibility is to see how much of PyPy's PyObject implementation we could use 23:05
not sure if it's in RPython or in C
lucian allison: i doubt if any. it seems to heavily depends on the object space, written in RPython, and again depending on PyPy libs
allison agreed, winexed/pir sounds like the safest option to me
lucian: yeah, that's a big dependency in PyPY 23:06
23:06 plobsing joined
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
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:07
lucian allison: not really much lower 23:08
allison long-term, I'm open-minded on 6model
for now, winexed/pir seems like the best starter approach
lucian allison: all python core types are objects
allison lucian: they have a method/attribute interface, yes
lucian allison: it's an implementation detail that they just act like 'object' 23:09
so it'd be nice if 6model could be used for 'object', and inherit that for 'dict' and so on
Tene lucian: First, be aware that I'm very uninformed about python's object model.
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
so obj.bla gets the attribute 23:12
it could be a function
Tene lucian: Are attributes declared? Do all instances of a class have the same set of attributes?
Can anyone set additional attributes on an object?
can I just say "obj.my_special_attr = 1" from anywhere?
lucian Tene: attributes aren't declared. instances only share class attributes
Tene: yeah, pretty much
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
Tene Okay, that's a lot like Ruby's attribute model.
lucian allison: it doesn't work on 'object', but it works on user-created classes
it's a CPython detail afaik
Tene lucian: class attributes? Are those just attributes on the class object?
lucian Tene: yeah, pretty much
allison lucian: on classes or instances of classes?
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?
lucian Tene: class as fallback
sort of
Tene: i think that's exactly what happens in fact 23:15
can i paste here? my browser's acting up
23:16 cotto left
Tene Sure. 23:16
lucian ah, finally gist.github.com/871711
excuse the crappy names
allison: as you can see, for user-created classes it works. try that with object() and it won't
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:17
lucian Tene: both 23:18
Tene: it's C3 though, so not weird
Tene lucian: Here's what jnthn's proposed repr for ruby looks like: github.com/perl6/nqp/blob/master/s...ttrStore.c 23:19
lucian Tene: python's objects are indeed similar to ruby's when it comes to actual usage
Tene So, object is something different, then? What's object() ? 23:20
lucian the root object
allison mmm... this is a new definition of "simple" I'm not familiar with
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
Tene :)
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?
Util Regarding 6model's single/multiple inheritance: see irclog.perlgeek.de/parrot/2011-03-15#i_3396281
allison er, yeah, what lucian asked
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
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'
Tene Cardinal's will be written in Ruby.
lucian Tene: subset of ruby?
allison full-ruby without objects? 23:26
lucian is back in 5min
allison or, full-ruby with proto-objects provided by 6model? 23:27
Tene allison: I expect it to be full ruby with possibly some custom cardinal-specific extensions. 23:28
I'm fairly confident that it's bootstrappable without notable difficulty, but I haven't actually done it yet.
allison renotes unpleasant past experiences building on top of systems that are unfinished and rapidly changing
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
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:30
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
There's likely to be some amount of shuffling at that point.
I'm not particularly invested in "selling 6model" or anything, just trying to be informative. 23:32
FWIW, the object model for NQP is written in NQP: github.com/perl6/nqp/blob/master/s...lassHOW.pm 23:33
allison how heavy are the dependencies for 6model now? 23:34
cotto_work allison: "when" ;)
allison cotto: er, what?
cotto_work <allison> but then, that rule may apply to Parrot itself in the not-to-distant-future, if Lorito is realized
allison ah, I thought you were answering the question about 6model dependencies :) 23:35
"when" sounds like one of those weird perl 6 object model things
cotto_work that would be a strange answe
r
Tene allison: NQP, although it could probably be extracted out, and likely will when imported into parrot's core.
allison it's got like, HOW and WHAT, ja? 23:36
NQP is right out as a dependency for pynie
been there, done that
Tene 'k 23:38
TimToady "NQP" is more than one thing these days
allison TimToady: I'm familiar with it as "a lightweight language, partial Perl 6 + p6 regexes, targeted at implementing compilers"? 23:40
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
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 :)
allison or, a good general-purpose low-level language?
or, a good way of writing very fast (static) code? 23:43
TimToady well, the "NQ" of "NQ" keeps varying...
we hope the dynamic range of p6 is that large, so not-quite that may achieve some of it
allison "NotQuite" transforming to "Very Close To"? 23:44
TimToady in spots
but we're very hopeful that the native types will turn out to be quite useful in writing fast, low-level code 23:45
and I agree, it's always hard to bootstrap a full stack 23:46
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
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.
lucian: I won't.
lucian Tene: then how would you write ruby objects in ruby? 23:50
Tene lucian: Where would there be no objects?
lucian Tene: in the ruby implementation of ruby objects
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.
That's unfortunate.
:/
TimToady he says the inlining stuff is already mostly there 23:52
it's mostly boxing/unboxing that needs work
Tene Maybe I got it confused with native types for variables and some of the NYI stuff in P6Opaque.c
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.
TimToady so all he has to do is implement the equivalent of a C++ compiler--no sweat :) 23:54
but the important thing is that jnthn thinks the 6model stuff is not another hack, but "close to right" on first principles 23:55
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
whiteknight even "close to right", 6model is still miles ahead of Parrot's current woefully-inadequate MOP offering
23:57 plobsing left
lucian whiteknight: perhaps, but not necessarily appropriate for pynie 23:57
i'd like it to be, so i'd have less work to do
whiteknight lucian: is Parrot's current MOP any more suited to pynie than 6model is?
allison whiteknight: we'd likely bypass that too 23:58
whiteknight ignoring the cultural ties to perl
lucian whiteknight: not really. it's either custom or 6model, the way i see it
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 ...
... running.
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
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?

Powered by Cro and the Raku® Programming Language.

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

Thank you!