Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27

[Jeremy White]

Hi Folks,

It's that time of year again - summer of code is going to start up soon.

Maarten, you've been coordinating things for us for a while now - are
you still game?  Would you like help?  Anyone else willing to volunteer
to help admin the process?

Cheers,

Jeremy

---

Conservancy Projects,

I want to draw your attention to the fact that Google's Summer of Code
program for 2012 is now accepting applications.

Carol Smith wrote at 11:43 (EST) on Saturday:
> We're pleased to announce that Google Summer of Code will be happening
> for its eighth year this year:
>
> [1] - http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-...
> [2] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc201...
> [3] - http://www.google-melange.com/gsoc/events/google/gsoc2012

In particular, take a look at [3], which has the calendar for the SoC
2012 program.

[Austin English]

I assisted last year and would be happy to do so again, or take over if
Maarten doesn't want to.

Cheers,
Austin

On Feb 10, 2012 1:24 PM, "Jeremy White"  wrote:
> Hi Folks,
>
> It's that time of year again - summer of code is going to start up soon.
>
> Maarten, you've been coordinating things for us for a while now - are
> you still game?  Would you like help?  Anyone else willing to volunteer
> to help admin the process?
>
> Cheers,
>
> Jeremy
>
> Conservancy Projects,
>
> I want to draw your attention to the fact that Google's Summer of Code
> program for 2012 is now accepting applications.
>
> Carol Smith wrote at 11:43 (EST) on Saturday:
> > We're pleased to announce that Google Summer of Code will be happening
> > for its eighth year this year:
> >
> > [1] -

http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-...
> > [2] -

http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc201...
> > [3] - http://www.google-melange.com/gsoc/events/google/gsoc2012
>
> In particular, take a look at [3], which has the calendar for the SoC
> 2012 program.

[Maarten Lankhorst]

Hey Jeremy,

Op 10-02-12 20:23, Jeremy White schreef:
> Hi Folks,
>
> It's that time of year again - summer of code is going to start up soon.
>
> Maarten, you've been coordinating things for us for a while now - are
> you still game?  Would you like help?  Anyone else willing to volunteer
> to help admin the process?

I'll apply wine again this year, but I want to ask everyone to help 
update our summer of code project wiki page.

http://wiki.winehq.org/SummerOfCode

I feel like we're not getting enough accessible projects that also have 
the correct length. I'm looking for something that's non-trivial but can 
still be done incrementally, having huge delta's to winehq has proven to 
not lead to meaningful contributions, and some of the projects on that 
list are too small, too complicated or might not be integrated into wine 
because it would be above a student's level get it done
right.

I have my doubts about these for example:
- Message mode pipes - if AJ doesn't know how to do it, how can a 
student do it right?
- Sandboxing, what's to prevent an app from simply doing syscalls in 
assembly, a real sandbox is not going to work
- Richedit windowless mode - There's no way this can be a student 
project until someone does the thiscall that works both ways, this has 
been the biggest stumbling block to implementing it.
- TestSuite - All previous attempts have failed, I believe that 
compiling testsuites for other projects would be a good project instead, 
fixing all problems that show up and don't show up on windows. Improving 
winetestbot to something more standardized and maintained would be nice 
too, but hardly a summer of code project, since it's too short.

But that's just my opinion, feel free to add your own projects to that 
list. :-)

~Maarten

[Jerome Leclanche]

On Sat, Feb 11, 2012 at 2:50 PM, Maarten Lankhorst
wrote:
> Hey Jeremy,
>
> Op 10-02-12 20:23, Jeremy White schreef:
>
> Hi Folks,
> > It's that time of year again - summer of code is going to start up soon.
> >
> > Maarten, you've been coordinating things for us for a while now - are
> > you still game?  Would you like help?  Anyone else willing to volunteer
> > to help admin the process?
> >
> > I'll apply wine again this year, but I want to ask everyone to help
>
> update our summer of code project wiki page.
>
> http://wiki.winehq.org/**SummerOfCodehttp://wiki.winehq.org/SummerOfCode
>
> I feel like we're not getting enough accessible projects that also have
> the correct length. I'm looking for something that's non-trivial but can
> still be done incrementally, having huge delta's to winehq has proven to
> not lead to meaningful contributions, and some of the projects on that list
> are too small, too complicated or might not be integrated into wine because
> it would be above a student's level get it done
> right.
>
> I have my doubts about these for example:
> - Message mode pipes - if AJ doesn't know how to do it, how can a student
>
> do it right?
> - Sandboxing, what's to prevent an app from simply doing syscalls in
>
> assembly, a real sandbox is not going to work
> - Richedit windowless mode - There's no way this can be a student project
>
> until someone does the thiscall that works both ways, this has been the
> biggest stumbling block to implementing it.
> - TestSuite - All previous attempts have failed, I believe that compiling
>
> testsuites for other projects would be a good project instead, fixing all
> problems that show up and don't show up on windows. Improving winetestbot
> to something more standardized and maintained would be nice too, but hardly
> a summer of code project, since it's too short.
>
> But that's just my opinion, feel free to add your own projects to that
> list. :-)
>
> ~Maarten

The problem with GSOC projects, in my opinion, is that too many people see
them as "projects"; the kind that needs to be finished by a deadline and
have visible changes, new gui or this sort of thing.

While there are interesting bits that could be done that way, having looked
at a lot of bugs and their lifetime it feels to me there are areas of wine
that could just use generic improvements, which are the kind that help wine
the most: gradually implemented, tends to have a visible impact on bugs,
many different areas to pick from, etc.
The uniscribe/bidi improvements over the past few releases are a good
example of a project that could have been picked up by someone familiar
with/willing to familiarise themselves with the area.

J. Leclanche

[Marcus Meissner]

On Sat, Feb 11, 2012 at 03:56:43PM +0000, Jerome Leclanche wrote:
> On Sat, Feb 11, 2012 at 2:50 PM, Maarten Lankhorst
> wrote:
> > Hey Jeremy,
> >
> > Op 10-02-12 20:23, Jeremy White schreef:
> >
> > Hi Folks,
> > > It's that time of year again - summer of code is going to start up soon.
> > >
> > > Maarten, you've been coordinating things for us for a while now - are
> > > you still game?  Would you like help?  Anyone else willing to volunteer
> > > to help admin the process?
> > >
> > > I'll apply wine again this year, but I want to ask everyone to help
> >
> > update our summer of code project wiki page.
> >
> > http://wiki.winehq.org/**SummerOfCodehttp://wiki.winehq.org/SummerOfCode
> >
> > I feel like we're not getting enough accessible projects that also have
> > the correct length. I'm looking for something that's non-trivial but can
> > still be done incrementally, having huge delta's to winehq has proven to
> > not lead to meaningful contributions, and some of the projects on that list
> > are too small, too complicated or might not be integrated into wine because
> > it would be above a student's level get it done
> > right.
> >
> > I have my doubts about these for example:
> > - Message mode pipes - if AJ doesn't know how to do it, how can a student
> >
> > do it right?
> > - Sandboxing, what's to prevent an app from simply doing syscalls in
> >
> > assembly, a real sandbox is not going to work
> > - Richedit windowless mode - There's no way this can be a student project
> >
> > until someone does the thiscall that works both ways, this has been the
> > biggest stumbling block to implementing it.
> > - TestSuite - All previous attempts have failed, I believe that compiling
> >
> > testsuites for other projects would be a good project instead, fixing all
> > problems that show up and don't show up on windows. Improving winetestbot
> > to something more standardized and maintained would be nice too, but hardly
> > a summer of code project, since it's too short.
> >
> > But that's just my opinion, feel free to add your own projects to that
> > list. :-)
> >
> > ~Maarten
>
> The problem with GSOC projects, in my opinion, is that too many people see
> them as "projects"; the kind that needs to be finished by a deadline and
> have visible changes, new gui or this sort of thing.
>
> While there are interesting bits that could be done that way, having looked
> at a lot of bugs and their lifetime it feels to me there are areas of wine
> that could just use generic improvements, which are the kind that help wine
> the most: gradually implemented, tends to have a visible impact on bugs,
> many different areas to pick from, etc.
> The uniscribe/bidi improvements over the past few releases are a good
> example of a project that could have been picked up by someone familiar
> with/willing to familiarise themselves with the area.

A GSoC really needs to be measurable somehow... Partially as psychological
aspect for both student and project (to see that somehting was achieved),
but also for fairness and proof if anyone would ever ask.

Helping developing parts is not well measurable :/

Ciao, Marcus

[Dylan Smith]

On Sat, Feb 11, 2012 at 9:50 AM, Maarten Lankhorst
wrote:
> I have my doubts about these for example:
> - Richedit windowless mode - There's no way this can be a student project
>
> until someone does the thiscall that works both ways, this has been the
> biggest stumbling block to implementing it.

Actually, that stumbling block has been implemented.  The next step is
implementing ITextServices::TxDraw.

[Maarten Lankhorst]

Hey Dylan,

Op 11-02-12 18:48, Dylan Smith schreef:
> On Sat, Feb 11, 2012 at 9:50 AM, Maarten Lankhorst 
> <[e-mail] > wrote:
> I have my doubts about these for example:
> - Richedit windowless mode - There's no way this can be a student
> project until someone does the thiscall that works both ways, this
> has been the biggest stumbling block to implementing it.
>
>
> Actually, that stumbling block has been implemented.  The next step is 
> implementing ITextServices::TxDraw.

Are you sure? I don't see any example calls being wrapped to ITextHost 
for example..

~Maarten

[Dylan Smith]

On Sat, Feb 11, 2012 at 2:27 PM, Maarten Lankhorst
wrote:
> Are you sure? I don't see any example calls being wrapped to ITextHost
> for example..

Yup, I worked on it myself.  All those ITextHost_*(...), which you can
easily grep for in editor.c, are using macros in editor.h:

--- snip ---
#ifdef __i386__ /* Use wrappers to perform thiscall on i386 */
#define TXTHOST_VTABLE(This) (&itextHostStdcallVtbl)
#else /* __i386__ */
#define TXTHOST_VTABLE(This) (This)->lpVtbl
#endif /* __i386__ */
 /*** ITextHost methods ***/
#define ITextHost_TxGetDC(This) TXTHOST_VTABLE(This)->TxGetDC(This)
...
--- end snip ---

So for i386 it will use the itextHostStdcallVtbl, which is defined in
txthost.c to pop the This pointer off the stack and into a register, then
grab the pointer to the vtable, and jump to the thiscall method.

--- snip ---
#define STDCALL(func) __stdcall_ ## func
#define DEFINE_STDCALL_WRAPPER(num,func,args) \
   extern typeof(func) __stdcall_ ## func; \
   __ASM_STDCALL_FUNC(__stdcall_ ## func, args, \
                   "popl %eax\n\t" \
                   "popl %ecx\n\t" \
                   "pushl %eax\n\t" \
                   "movl (%ecx), %eax\n\t" \
                   "jmp *(4*(" #num "))(%eax)" )

DEFINE_STDCALL_WRAPPER(3,ITextHostImpl_TxGetDC,4)
...

const ITextHostVtbl itextHostStdcallVtbl = {
    NULL,
    NULL,
    NULL,
    __stdcall_ITextHostImpl_TxGetDC,
...
--- end snip ---

The ITextHost interface is also implemented in txthost.c for non-windowless
richedit controls.  That interface is implemented using thiscall wrappers
which do the reverse of the standard call wrappers.