Files changed (36)
-* Maybe GC framework integration preparation tasks, or l3 interpreter improvements; to be discussed
-* Merlinux new hire has a filming background. Holger discussed the possibilities with Bea. There may
- [12:58] <pedronis> <ericvrp> Last: improved nighly benchmark cronjob Next: optimizations and a little genjs, Blockers: bit ill
- [13:00] <pedronis> we should take into account that there is still some preparation for the review and discussions for core people
- [13:01] <hpk> let me note that sometime this month, latest mid february there will be a codespeak migration to a new environment
- [13:01] <hpk> helios who hosted codespeak.net for three years now - finally said the traffic is getting too much
- [13:04] <pedronis> cfbolz, arigo: the question is what kind of work is best done before the sprint vs at the sprint
- [13:08] <arigo> there's always refactoring external function calls, but again it might be done during the sprint too
- [13:08] <hpk> cfbolz: bea requested to put the deliverable reports online visibly somewhere, makes sense IMO
- [13:09] <hpk> cfbolz: ok, i was just refering to what small things can be done before the sprint :)
- [13:10] <pedronis> arigo, cfboly: I think some small l3 progress may make sense but is probably best to discuss it a bit on #pypy
- [13:10] <hpk> arigo: i think refactoring external function calls makes sense at the sprint, also documenting it to allow people to better work on porting ext-modules
- [13:11] <pedronis> ok, I think that's it for this topic, someone want to discuss something else in the last 10 mins?
- [13:12] <hpk> just a side note: i am going to talk to �Prof. Leuschel on monday regarding Summer-of-PyPy specifics - he likes the idea and HHU being a carrier
- [13:14] <hpk> a nicer description page, also linking the 22C3 papers which are nicely in the book of proceedings, btw.
- [13:15] <hpk> arigo: i guess you don't mind that i talk to leuschel as long as you don't have to worry about EU issues :)
- [13:16] <hpk> i have one more thing i'd like to mention (i did already to some people but here more people may get it)
- [13:17] <hpk> we have a new person starting at merlinux who has a background in filming and movies
- [13:18] <hpk> i discussed with Bea who heads the dissemination works and such - and she likes the idea of getting some non-text documentation about sprints and such
- [13:18] <hpk> thea idea is to get some material on the website that allows people insights (maybe including interviews with developers or so) other than reading text reports
- [13:19] <stakkars> fine with me. Make sure to tell in advance, so I can clean the craziest T-shirts
- [13:22] <stakkars> OT: does anybody know how much space we have in Palma, are there limitations on # of people?
- <adim> LAST: helped Nicolas to prepare the "SolutionsLinux" exhibition / talked about PyPy to everyone passing around the Logilab's stand
- <hpk> and also (i mentioned this to arigo already) i'd like to do a bit of py lib sprinting as a sub-track
- <arigo> I expect the sprint to be pretty much a "what are you interested in?" kind of sprint, with not too many pypy corers there
- * hpk thinks that we will need an internal core sprint between now and may because both japan and pycon are likely not allowing us to tackle the tough stuff
- <hpk> being able to write GCs would be cool - but i am a bit skeptical (without really being able to judge)
- <arigo> I believe we can make socket-on-ctypes a topic, but it also seems to be a very demanded topic
- <arigo> I know that both Holger and Christian are considering hiring people and giving socket as work :-)
- * hpk could try to write a draft announcement until saturday morning, cannot promise to do it earlier
- <mwh> i think at this point we want to nominate one or two people to write the announcement, not try to write it now?
- <arigo> hpk: I guess you mean in general playing with mostly app-level code that uses the new pypy features
- <arigo> hpk: you can already do a lot with the thunk space, I'm not sure what non-app-level extensions you have in mind
- <arigo> yes, particularly how to fit them in the Python language, and how to hook them on microthreads
- <hpk> arigo: am mostly thinking about distribution of objects including their functions (so that not only object state is transparently moving between servers but also the code ...)
- <arigo> hpk: that's also a design topic :-) I don't see clearly if and how to fit this in the thunk space in particular
- <hpk> mwh: do we still assign to the task of finalizing the announcement? Or do you do a draft with armin or Samuele or what?
- <aleale> I have had the need to be able to filter in generative test. I havent found a way to name the generative tests so that -k works.
- <ericvrp> When I had some RPython code that would not annotate I would have liked a feature that simulates manual --pdb option and then looking for a translator object so t.view() can be done to see the offending block
- * hpk sidenotes that py.log is going to be refined soon - but we will ensure that pypy's usage will be fixed accordingly
- [12:56] <ericvrp> LAST: stackless optimization and transformation, NEXT: more of that, BLOCKERS: -
- [12:59] <hpk> mwh: having short "result presesntation and rough planning" daily sessions and otherwise work more in sub-groups
- [13:00] <hpk> arigo: can you also prepare our architecture session talk a bit before the conference?
- [13:01] <mwh> we've got a fair few topics to get though today, don't want to talk about this for two long
- [13:05] <arigo> there is a non-concrete idea about Leysin, but more mid-end-of-March than early April
- [13:07] <hpk> well, it seems that early april is more likely to fit at least with carl, michael and me
- [13:07] <mwh> it seems getting logilab and tismerysoft in the same place at some point would be a good thing
- [13:09] <hpk> ericvrp: ok, i thought that because you don't come to pycon ... but then you'd like to go to tokyo, i see
- [13:13] <hpk> fine with me, mwh: i think it's enough for now to mention it prominently in the minutes
- [13:14] <mwh> this is auc's topic, but basically i think the question is particularly about whether there are concrete plans for microthreads
- [13:17] <arigo> auc: the answer is that it's mostly easy for any of us to build whatever you need, but it must be more well-defined
- [13:18] <arigo> auc: but for example, do you need threads that can block on system calls without blocking other threads
- [13:19] <mwh> if not, would it make sense to schedule some irc session to get the relevant parties together?
- Jul 14 13:01:32 --- #pypy-sync :[freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
- Jul 14 13:04:24 <hpk> the idea is to really stick to the 30 minutes, we will end the meeting at 13:30
- Jul 14 13:06:03 <hpk> last week: begin interpreter-docs, fix codespeak/website issues, fix testresults page, some eu/managementissues
- Jul 14 13:06:03 <hpk> next week: finish interpreter docs, write external (oslevel) functions, prepare codespeak-move
- Jul 14 13:06:03 <hpk> blocking: (slightly) terminology cleanup / missing glossary / (maybe llvm-state)
- Jul 14 13:06:28 <arigo> last week: rtyper; progress in translate_pypy; polished framework for external func calls.
- Jul 14 13:07:00 <pedronis> DONE: translate_pypy progress, instatiate of classes with Armin...; solved some attributes that were attached too high the hierarchy, some support for pyobjs ops in the llinterp, and more work with Arre on translate_pypy; refactored rtyper to use argument.py for args parsing and call_args support
- Jul 14 13:07:01 <pedronis> NEXT: more translate_pypy work, possibly refactor specialisation to treats override and memos as builtins, refactor gencapi usage to go through external func table
- Jul 14 13:07:03 <pedronis> ISSUES: a bit worried about rtyping mem usage but too soon too really tell
- Jul 14 13:09:53 * stakkars is sorry to be late, the machine decided to run a windows update right now :-(
- Jul 14 13:10:19 <arre> Last week: Fixing some problems related to unicode, Work on annotation/rtyper to be able to process PyPy
- Jul 14 13:10:28 <arre> Next week: annotation/rtyper and/or implementing modules os and math, if there is enough time take the week off.
- Jul 14 13:10:41 <arre> Blockers: Not knowing the darker corners of the annotator/rtyper (In the process of being solved through having Samuele close by)
- Jul 14 13:11:02 <stakkars> :-) there is a random shuffling algo in the annotator, and I got seed 49
- Jul 14 13:12:15 <hpk> i think that weakref is not a priority and we should wait a bit with cfbolz's work on GC
- Jul 14 13:12:58 <hpk> aleale: let's discuss possible work areas for you this off this pypy-sync meeting with Samuele and maybe others
- Jul 14 13:13:10 <hpk> generally i'd like to be signalled ahead of the meeting if one doesn't know what to work on
- Jul 14 13:13:45 <hpk> you probably all have read that the technical board thinks we should do a in-between internal sprint
- Jul 14 13:15:57 <hpk> ok, that means: samuele, christian, holger, armin fulltime and cfbolz (-1 day)
- Jul 14 13:17:16 <hpk> ok, so the 25th-31st sprint is fixed then and i will prepare it, please arrive on the 24th evening or 25th morning and mail me about accomodation wishes
- Jul 14 13:18:25 <hpk> for the upcoming releases (0.6.2 and 0.7/1.0) it has been discussed that we want to use the issue tracker
- Jul 14 13:18:43 <hpk> it should be clear to everyone (e.g. regarding the parser issues) that it is neccessary to look there
- Jul 14 13:21:23 <hpk> next topic: - list current main areas of work regarding reaching Deliverable D05.2
- Jul 14 13:24:13 <hpk> pedronis: ok, i suggest to add separatable issues into the ISSUES.txt for everyone to see (if they are not solved/solveable isntantly)
- Jul 14 13:24:15 <pedronis> the only worry is a bit memory usage but hard to tell until we go trough more blocks
- Jul 14 13:27:11 <cfbolz> it doesn't matter much for the rooms, I think I did a mistake in the mail to you :-(
- Jul 14 13:28:07 <stakkars> I have a fixed date on 24.09. in Kiel and on 27.08., everything else is fine.
- Jul 14 13:28:50 <hpk> stakkars: the 27th August would be in the sprint, but maybe you can just travel a day?
-.. _`Heidelberg sprint announcement`: http://codespeak.net/pypy/index.cgi?extradoc/sprintinfo/Heidelberg-sprint.html
- Jul 21 13:04:46 <hpk> activity reports: i suggest the following order: hpk,aleale,ludal,adim,pedronis,arre,cfbolz,
- Jul 21 13:05:05 <hpk> LAST: interpreter documentation, organizing hildesheim sprint, codespeak migration planning, mentoring so
- Jul 21 13:05:23 <aleale> BLOCKERS: need to understand exceptions better (interpreter level, annotation of, etc), a wedding, an immanent move to Germany
- Jul 21 13:05:31 <ludal> last week : parser work, pysymbol and pytoken, switching to using integers for rule names instead of strings
- Jul 21 13:05:31 <ludal> next week : vacation + eventually resolving annotation problems + astbuilder to make annotation work further
- Jul 21 13:05:57 <pedronis> Last: bug fixing in annotator and rtyper, progress rtyping PyPy adding rtyper features, implemented hook to control rtyping order, integrated suggestion to continue rtyping even after errors
- Jul 21 13:05:59 <pedronis> Next: sprint (we are down to 57 rtyping problems with the translation snapshot)
- Jul 21 13:06:00 <pedronis> Issues: tried to annotate the trunk, now annotation finishes but quite some involved SomeObject problems related to parser code
- Jul 21 13:07:39 <cfbolz> LAST: finalized sprint room, trying to get cheap accomodation, looking for the cheapest publich transport tickets
- Jul 21 13:07:39 <cfbolz> NEXT: checking network connectivity in the sprint room, Hildesheim sprint
- Jul 21 13:08:34 <hpk> ludal: before you leave to holiday could you send a mail to pypy-dev about the status?
- Jul 21 13:08:59 <hpk> this way the hildesheim group knows where it could start to work if it wants to
- Jul 21 13:09:23 <ludal> sure, actually I'm not leaving paris so I'll be available online from time to time and hopefully following developpements of the sprint
- Jul 21 13:10:22 <cfbolz> have to check network connectivity: it is possible that we need some sort of VPN client to access the network
- Jul 21 13:11:08 <hpk> network connectivity: we should have our own router/machine that makes the VPN transparent if possible
- Jul 21 13:11:52 <cfbolz> the problem is that the local admins from the rechenzentrum are kind of inflexible
- Jul 21 13:13:47 <hpk> cfbolz has a room in a living group (WG) that costs 200-300 euro and two people could sleep there for the sprint week
- Jul 21 13:14:30 <hpk> is anyone basically interested? (hotels are kind of expensive in heidelberg)
- Jul 21 13:15:37 <hpk> (rxe: if you want to send your activity reports, just paste your three LAST/NEXT/BLOCKERS lines in)
- Jul 21 13:16:34 <hpk> cfbolz: i think the people using the room should pay, maybe they can get a receipt?
- Jul 21 13:17:58 <hpk> arre, pedronis, ludal: ok, this is lasting too long, write cfbolz a mail if you are interested
- Jul 21 13:18:31 <cfbolz> I guess the hardest HD sprint issues are solved, now that we have the room?
- Jul 21 13:19:23 <hpk> next topic: compliance tests failures after 2.4.1 merge: how/when to tackle?
- Jul 21 13:19:50 <hpk> any opinions on this? (i guess you all noticed that we have only ~50% compliance tests passing)
- Jul 21 13:22:59 <hpk> i suggest that we task the hildesheim sprint crew to discuss this and come up with a strategy when/how to tackle the problem
- Jul 21 13:24:32 <hpk> ok, we will send according infos to pypy-dev and possibly pypy-funding (it's a critical EU issue in some ways)
- Jul 21 13:24:47 <hpk> next topic: 0.6.2 release: status / when do we think to actually do it? Do we still?
- Jul 21 13:25:27 <hpk> ludal: does the parser/compiler now run on top of Python 2.3 providing 2.4 semantics?
- Jul 21 13:26:30 <hpk> ok, then the main blocker for a 0.6.2 release is the compliance/test situation
- Jul 21 13:27:00 <hpk> so we should re-discuss it next week (after the hildesheim crew dicussed it) if nobody objects
- Jul 21 13:27:44 <hpk> ok, then last (somewhat optional) topic: - re-assigning tasks (related to NEXT activities)
- Jul 21 13:28:33 <hpk> like mentioned earlier, i think that the hildesheim crew might interfer with the os-level calls (aleale) and parser (ludal) developments
- Jul 21 13:29:15 <hpk> i think that the hildesheim crew should be allowed to work on whatever it wants and try to signal via IRC or pypy-dev/commits
- hpk most of you know alreada that beginning of august there is a codespeak hardware/hosting migration planned
- Aug 04 13:00:36 <rxe> LAST: llvm work with Eric (pbc, operations, bpnn, richards, readability of source
- Aug 04 13:00:36 <rxe> NEXT: would be nice to translate pypy itself - not too far off - but will probably be busy wit
- Aug 04 13:00:55 <hpk> LAST: hildesheim2-sprint + after-work/reporting, small fixes + cleanup here and there
- Aug 04 13:01:10 <nik> NEXT: app-level optimizations for _sre, some array improvements. after that (= next week) i'm probably be free for work on general compliance.
- Aug 04 13:01:52 <arigo> LAST: fixing bugs in translate_pypy; getting a stand-alone executable instead of an ext module
- Aug 04 13:01:52 <arigo> NEXT: clean-ups (e.g. the Translator class); work on compliance tests; more bugs shown by translate_pypy
- Aug 04 13:02:07 <cfbolz> LAST: Hildesheim sprint, lltypesimulation on top of memory simulator, looking ways to integrate lltypesimulation with llinterp
- Aug 04 13:02:07 <cfbolz> NEXT: integrating lltypesimulation into lltinterp, enhancing llinterp to be able to use simulated GC (finding roots)
- Aug 04 13:02:30 <pedronis> Last: sprint, fix obscure(tm) intermittent annotator problem, fix what prevented "import code" to succeed
- Aug 04 13:02:33 <pedronis> Issues: when we try very clever approaches we should try to think of and add sanity checks
- Aug 04 13:03:15 <hpk> however, we should talk a bit about how to approach compliancy under its own topic
- Aug 04 13:05:29 <hpk> cfbolz: i'd suggest to define closed as "enough room for the active developers to pair with each other"
- Aug 04 13:05:56 <hpk> because i think that is really the issue, the more newbies or not-up-to-speed people the less the active developers can pair with each other
- Aug 04 13:07:48 <adim> Keeping sprints open around conferences seems a good idea, but having more "closed" ones around "deadlines" should be possible too
- Aug 04 13:08:21 <ericvrp2> I would suggest at least 1-2 days for people that might live nearby and want to get the feeling
- Aug 04 13:09:03 <hpk> for example, i am not worried about heidelberg, because there are quite a lot of people registered that know PyPy reasonably well
- Aug 04 13:11:07 <cfbolz> no, I agree. Open would mean something like after EP where really lots of people showed up rather spontaneously
- Aug 04 13:11:08 <hpk> ok, i would like to summarize that the general opinion is that closed sprints are ok, but we want to be careful to a) not do them to often b) not harshly exclude interested developers c) look that we don't go against the open-source spirit
- Aug 04 13:11:19 <arigo> makes sense to always allow nearby people to show up. We should only recommend to other people to fly to an "open" sprint if they have to fly anyway
- Aug 04 13:14:54 <hpk> i guess that we don't go for any 0.6 release anymore and directly tackle 0.7 at heidelberg
- Aug 04 13:15:44 <hpk> nik: compliance, move to 2.4.1 and the parser running on top of cpython both 2.4 and 2.3
- Aug 04 13:19:22 <arigo> a) I propose that whoever starts seriously looking at a test, says so in the failure_list.txt
- Aug 04 13:19:52 <arigo> and then he follows up there too when he found the problem, and finally says if/when the problem is fixed or if he can't fix it
- Aug 04 13:22:01 <hpk> cfbolz: but counting a whole test file just containing one failure as a complete failure is certainly "good for the EU" :-)
- Aug 04 13:23:03 <hpk> arigo: i agree to a) and b) but regarding c): i think we should prepare for counting differently before heidelberg - just in case
- Aug 04 13:24:00 <cfbolz> yes, but armin's point is valid as well: no matter how we count, it's annoying that a lot of tests fail now that passed once
- Aug 04 13:26:02 <hpk> ericvrp2: consider one test file with 10000 tests all failing, and one test file with 1 test passing -> compkliancy 50%
- Aug 04 13:26:54 <ericvrp2> hpk: I agree with you, but changing that now (unless 5 minutes work) doesn't sound very productive
- Aug 04 13:27:21 <arigo> hpk: I think that time is better spent trying to fix the tests themselves, for now
- Aug 04 13:27:51 <hpk> ok, fine by me (but i still want to to look _a bit_ into the test reporting, anyway, so i might give that a look as well)
- Aug 04 13:28:35 <nik> one suggestion: it would help if the whole compliancy suite was run daily on some server
- Aug 04 13:28:54 <hpk> nik: yes, i had that on codespeak.net but stopped it when the server was getting unstable
- Aug 11 13:03:00 <hpk> NEXT: some more codespeak-migration, open issues, at least three non-pypy days
- Aug 11 13:03:35 <cfbolz> LAST: polished my lltype implementation on top of the memory simulation: it works quite well now (only 9 tests of all tests that use llinterp fail)
- Aug 11 13:04:00 <nik> NEXT: not much, will be at a conference in brussels from sunday until the sprint
- Aug 11 13:04:22 <pedronis> Last: 2.4.1 tests, open issues, float ops/math and errors, a bit of tracker gardening, slottified lltype
- Aug 11 13:08:12 --> mwh (Nemail@example.com) has joined #pypy-sync
- Aug 11 13:10:23 <pedronis> well, the fact is that those aspects are related to interaction with other ext (possibly user) modules
- Aug 11 13:12:07 <ericvrp> The LLVM backend is progressing slowly but steadily. We currently have about 10 exception raising operations todo,
- Aug 11 13:12:09 <ericvrp> which is straightforward. The other open issue is the handful of external (suggested_primitive) functions that need
- Aug 11 13:12:10 <ericvrp> to be implemented. After a standalone version works, we need to refactor (of
- Aug 11 13:12:13 <ericvrp> The benchmarks bpnn and Richards produce standalone executables already. (python llvm2/demo/richards l)
- Aug 11 13:12:15 <ericvrp> We encountered three bugs in the LLVM toolchain which after being reported to the LLVM team were all fixed very quickly. Which, in a way, gives me a good feeling. But discovering, reporting and waiting for fixes/workaround is what is costing us most of the time currently. I hope to have a working standalone mid next-week.
- Aug 11 13:12:17 <ericvrp> The current llvm file can be found at http://codespeak.net/~ericvrp/download
- Aug 11 13:13:52 <ericvrp> the only progress that counts (pypy) is still to come and I am not 100% sure if that will work first time round as did the C backend
- Aug 11 13:14:17 <ericvrp> about the speed: I don't know if the C backend does any gcc optimizations currently?!?
- Aug 11 13:15:35 <hpk> ah, ok, nevermind, that's not too important right now but interesting neverhteless
- Aug 11 13:17:43 <hpk> and carl, can you say a few words regarding GC and how it is supposed to integrate into PyPy?
- Aug 11 13:18:02 <cfbolz> I did some groundwork, and hope that I can now actually start to work writing GCs
- Aug 11 13:18:27 <cfbolz> there is an Address class that provides raw access to memory and should be used by the GC implementation. this class is annotated with SomeAddress
- Aug 11 13:18:52 <cfbolz> on top of this there is the lltypesimulator: a class that behaves like the _ptr type of lltype
- Aug 11 13:19:17 <cfbolz> the next thing I'm doing is imeplemting GC hooks into the llinterp for the
- Aug 11 13:21:40 <hpk> doesn't it make sense to divide the discussion into "import thread" support and "new threading facilities"?
- Aug 11 13:22:15 <hpk> i mean we do need to offer the thread module, and e.g. stackless ideas or having multiple object spaes is a different issue, isn't it?
- Aug 11 13:23:24 <hpk> arigo, pedronis: i am fine with raising and discussing this on pypy-dev, though, if further immediate comments cannot be made
- Aug 11 13:24:34 <hpk> stakkars: this is just the first discussion, more to follow and the pypy-dev thread is there as well