On 13 Jan 2015 at 9:51, Benedek Thaler wrote:
All you need is a mentor. Or, if you feel like mentoring another student in Pipeline this summer ...?
I'd rather like to participate as a student, it's my last chance.
You may be surprised at how often you return to university study in the future. I have two undergrads, a Masters and a PGCert, and I'm taking a third undergrad in maths by distance. Right now I'd qualify as a student for GSoC myself :)
I would though Benedek try to be flexible about your choice of project if you want to be sure to get a mentor (Vicente is already very overloaded every year). For example, a very attractive intermediate GSoC might be working on Boost.Fiber, specifically I am thinking some form of awareness of i/o in Fiber maybe. And Fiber ought to be up for its second review shortly, after which it enters Boost. From my short review of Fiber this week, it has very considerably improved over the review last year.
Actually, since Pipeline would be a fiber user, it's a great idea. Inter-thread fiber migration is something a good scheduler would need. Probably we can came up with something with Oliver when the time comes.
I should absolutely stress that I was only giving an example of flexibility, and that I don't mean to imply that Oliver should mentor anyone for GSoC on Fiber. I haven't even raised the idea with him. But do "think around" Pipelines where you can. And please do try to scare up a prearranged GSoC mentor preferably before GSoC begins (you have until March 16th, no rush). Prearranging a mentor is quite like finding a doctoral thesis supervisor, it takes time and persuading. FYI, longer term for AFIO I intend a coroutine capable Filesystem TS API wrapper for AFIO such that you can use std::filesystem and std::fstream from coroutines and you get "free" asynchronous file i/o. I think that ought to satisfy Robert's good point that AFIO right now is a pain to use for simple tasks. With the v1.3 engine later this month AFIO now provides all the facilities that the Filesystem TS does (and considerably more), and there would be no technical obstacle to a Fibre friendly Filesystem TS implementation. I would hope any such Filesystem TS implementation really ought to implement Alexander's enhancements to transparently support process local filesystems (https://alamaison.github.io/2014/01/09/proposal-generic-filesystem/), though note that I personally would far prefer uri:// prefixing than separate C++ APIs e.g.; zip:://c:/temp/foo.zip/Readme.txt. That way we can keep the complete Filesystem TS API. I'll be extending AFIO with uri prefixing in the v1.4 engine, specifically temp://x to create temporary files. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/