harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: Google Summer of Code 2009
Date Tue, 03 Mar 2009 11:38:50 GMT
Sian,

Thanks for your answer. I feel I was not able to express logging idea
well. Let me clarify. The point was to improve other projects using
and spreading Harmony code. This would make us more popular.

Let me provide some context for anti-plagiarism, and advocate it a
bit. Five suspicious entries at the last year contribution to Harmony
were actually obtained via manual scan. So this task was proved to be
useful for Harmony. How would it improve Harmony further? One may
apply the tool and clean the rest of our code base.

Well, may be it would be more reasonable to suggest this task for incubator.
Thanks.

On Tue, Mar 3, 2009 at 2:17 PM, Sian January <sianjanuary@googlemail.com> wrote:
> Hi Alexei,
>
> Personally an anti-plagiarism tool wouldn't be a high priority for me
> as I think there are lots of other project ideas that help us complete
> the JDK or improve our current code, which to me is more interesting.
> Just my opinion though - others may think differently.
>
> Logging/globalization sounds ok as long as it's useful for the Harmony
> project.  If it's more for the labs/incubator idea it might make sense
> to get a GSoC project under the labs instead rather than under
> Harmony.
>
> Thanks,
>
> Sian
>
>
>
> 2009/3/3 Alexei Fedotov <alexei.fedotov@gmail.com>:
>> Hello folks,
>>
>> I'm sorry for asking again. Do you think it is ok to position
>> anti-plagiarism tool or logging re-use as Harmony GSoC project (and
>> place them on Wiki), or do you think they are out of Harmony scope?
>>
>> Thanks.
>>
>>
>>
>> On Fri, Feb 27, 2009 at 1:07 PM, Alexei Fedotov
>> <alexei.fedotov@gmail.com> wrote:
>>> Hello folks,
>>> Let me try to share my ideas on GSoC project. I need your feedback on this.
>>>
>>> 1. I believe a tool from [1] should be replaced with one based on
>>> Google Code search, preferably using its nice java API. The tool
>>> should have a sort of configurable AI, e.g. understand that misspels
>>> in comments are more important than typical performance optimizations.
>>> This would help us and others checking bulk contributions.
>>>
>>> 2. I want to start incubating a project [2] (mentors welcome), but it
>>> have logging with incompatible license. Re-using a logger from Harmony
>>> VM in this project would solve this problem. Also, one might find a
>>> better way to our localization - symbolic identifiers are hard to
>>> maintain. I simply love my fine logger, so in case of possible org
>>> difficulties with the project [1], it can be replaced with another one
>>> with ugly logging.
>>>
>>> What do you think?
>>>
>>> With best regards, Alexei
>>>
>>> [1] https://issues.apache.org/jira/browse/HARMONY-15
>>> [2] http://markmail.org/thread/yiyyqtyb7f7csxui
>>>
>>>
>>>
>>> On Fri, Feb 27, 2009 at 12:14 PM, Mark Hindess
>>> <mark.hindess@googlemail.com> wrote:
>>>>
>>>> In message <fc2fc95c0902230906k50896634tfc45df549348c690@mail.gmail.com>,
>>>> Sian January writes:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Do we want to propose any projects for Google Summer of Code 2009?  It
>>>>> was quite successful last year for Harmony, with two students
>>>>> completing the programme, so definitely worth doing in my opinion.
>>>>>
>>>>> http://code.google.com/soc/
>>>>>
>>>>> Thanks,
>>>>> Sian
>>>>
>>>> I've a couple of items on my todo list that might make an interesting
>>>> GSoC project.  While looking at file descriptor usage between Harmony
>>>> and RI I noticed that the RI typically reads jar files with an
>>>> open/mmap/close sequence and then uses the mapped memory to access the
>>>> file.  Harmony uses open and uses seek/read to access the file.  There
>>>> are a couple of issues here:
>>>>
>>>>  * some applications that use lots of jar files will not work on Harmony
>>>>    because they will run out of file descriptors even though they will
>>>>    work on the RI
>>>>
>>>>  * code with memory access rather than seek/read will be a lots simpler
>>>>    to read/maintain
>>>>
>>>>  * what are the performance implications?
>>>>
>>>> I'd quite like to investigate this but don't seem to be finding the time.
>>>>
>>>> It might also be interesting to explore the possibility of exploiting
>>>> parallelism (compare gzip/pigz).
>>>>
>>>> It might also be worth seeing if there is any performance benefit to using
>>>> the inflateBack api (compare gzip/gun - gun is in the zlib source examples
>>>> directory).
>>>>
>>>> If people think these ideas are concrete enough to explore then I'll add
>>>> an item to the wiki.
>>>>
>>>> Regards,
>>>>  Mark.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> С уважением,
>>> Алексей Федотов,
>>> http://people.apache.org/~aaf/
>>>
>>
>>
>>
>> --
>> С уважением,
>> Алексей Федотов,
>> http://people.apache.org/~aaf/
>>
>
>
>
> --
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>



-- 
С уважением,
Алексей Федотов,
http://people.apache.org/~aaf/

Mime
View raw message