www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Requesting for project ideas

reply "Ishan Thilina Somasiri" <ishanthilina gmail.com> writes:
Hi,

I'm posting this on bhalf of a group of 4 students from the final
year of Department of Computer Science and Engineering,University
of Moratuwa, Sri Lanka. We are required to do a 8 months long
project in our final year. The
project should consist of both a research and development
component and
an implementation. Our group is interested in areas such as,

    * Information security
    * Cloud
    * Parallel computing
    * Compilers
    * Operating Systems
    * Distributed systems


We’d like to know if the D programming language project has any
project
ideas that falls within our interest areas.

For more information about the members of our group, please refer
the
following links.

Ishan Thilina Somasiri -
http://lk.linkedin.com/pub/ishan-somasiri/25/bab/951/
Amila Surendra -
http://www.linkedin.com/pub/amila-surendra/25/9a3/392
Hasala Surasinghe -
http://www.linkedin.com/pub/hasala-surasinghe/34/927/b2
Rajith Siriwardana - http://www.linkedin.com/in/rajithsiriwardana

We’d be really glad if you could extend your support on this.

Thank you for your valuable time.
Jan 02 2013
next sibling parent "angel" <andrey.gelman gmail.com> writes:
Cool !
It's like 'Google summer of code' ...
Jan 02 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Ishan Thilina Somasiri:

 We are required to do a 8 months long project in our final
 year. The project should consist of both a research and
 development component and an implementation. Our group
 is interested in areas such as,

    * Information security
    * Cloud
    * Parallel computing
    * Compilers
8 months is a lot of time, so projects like the projects of Google Summer of Code risk being too much small. Some smaller projects are: - Use LLVM to Just-in-time compile just the longer running compile-time functions (CTFE), for the LDC compiler (the functions that run quickly at compile-time are better left to the interpreter, because LLVM JIT has lot of overhead, it's not fast). - Implement Windows exceptions for the LDC compiler. - Implement efficiently the vector operations of the D language, and related matters. A larger and more rearch-y project is to try to plug Z3 (http://z3.codeplex.com/ ) in the D front-end to run some contracts at compile-time. And generally to study how to improve a fortified version of the D language ("Strong-D"?) to be used in high integrity programming, where Ada/SPARK are used. Another medium sized project is to use some parts of the C/C++ static analyser of Clang (http://clang-analyzer.llvm.org/ ), to create a similar tool for D-LDC. Surely others will give you more ideas. Surely there is no lack of stuff to work on, because compared to the universe of tools/compilers for C/C++ the D ecosystem is almost a greenfield. Bye, bearophile
Jan 02 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 2 January 2013 at 16:15:00 UTC, Ishan Thilina
Somasiri wrote:
 Hi,

 I'm posting this on bhalf of a group of 4 students from the 
 final
 year of Department of Computer Science and 
 Engineering,University
 of Moratuwa, Sri Lanka. We are required to do a 8 months long
 project in our final year. The
 project should consist of both a research and development
 component and
 an implementation. Our group is interested in areas such as,

    * Information security
    * Cloud
    * Parallel computing
    * Compilers
    * Operating Systems
    * Distributed systems


 We’d like to know if the D programming language project has any
 project
 ideas that falls within our interest areas.

 For more information about the members of our group, please 
 refer
 the
 following links.

 Ishan Thilina Somasiri -
 http://lk.linkedin.com/pub/ishan-somasiri/25/bab/951/
 Amila Surendra -
 http://www.linkedin.com/pub/amila-surendra/25/9a3/392
 Hasala Surasinghe -
 http://www.linkedin.com/pub/hasala-surasinghe/34/927/b2
 Rajith Siriwardana - 
 http://www.linkedin.com/in/rajithsiriwardana

 We’d be really glad if you could extend your support on this.

 Thank you for your valuable time.
I think the strongest need for D right now is a better GC. A very good start would be to make the GC precise on the heap. Compiler support have been implemented some time ago, but the GC implementation is lacking behind. I'd be happy to personally help on that one. Other people here are very competent as well.
Jan 02 2013
parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Wednesday, 2 January 2013 at 17:06:09 UTC, deadalnix wrote:
 On Wednesday, 2 January 2013 at 16:15:00 UTC, Ishan Thilina
 Somasiri wrote:

 I think the strongest need for D right now is a better GC. A 
 very
 good start would be to make the GC precise on the heap. Compiler
 support have been implemented some time ago, but the GC
 implementation is lacking behind.

 I'd be happy to personally help on that one. Other people here
 are very competent as well.
+1 for the GC. Making it precise (and maybe generational) would easily be a nice project for 2 people at least. As well as allocators. For other projects, D still doesn't have a nice unified interface to databases. As for distributed computing, a port of Apache Hadoop and HBase to the D language that shows better performance and memory characteristics than the Java version would be nice, and it would shed the light on the language.
Jan 02 2013
next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 3 January 2013 at 04:40:59 UTC, SomeDude wrote:
 For other projects, D still doesn't have a nice unified 
 interface to databases.
Actually, there is a project called adbi for the database interface. A full featured precise, generational, concurrent GC would be a nice project for 3 or 4 people.
Jan 02 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 3 January 2013 at 04:40:59 UTC, SomeDude wrote:
 +1 for the GC. Making it precise (and maybe generational) would 
 easily be a nice project for 2 people at least. As well as 
 allocators.
Generational seems completely unrealistic.
Jan 03 2013
parent reply "Thiez" <thiezz gmail.com> writes:
On Thursday, 3 January 2013 at 10:17:19 UTC, deadalnix wrote:
 Generational seems completely unrealistic.
Why?
Jan 03 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 3 January 2013 at 11:26:11 UTC, Thiez wrote:
 On Thursday, 3 January 2013 at 10:17:19 UTC, deadalnix wrote:
 Generational seems completely unrealistic.
Why?
Tracking reference from old gen to new gen require read/write barriers. Plus, it is unclear what the win is, generational GC is way less interesting when the GC cannot move.
Jan 03 2013
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-01-03, 12:40, deadalnix wrote:

 On Thursday, 3 January 2013 at 11:26:11 UTC, Thiez wrote:
 On Thursday, 3 January 2013 at 10:17:19 UTC, deadalnix wrote:
 Generational seems completely unrealistic.
Why?
Tracking reference from old gen to new gen require read/write barriers. Plus, it is unclear what the win is, generational GC is way less interesting when the GC cannot move.
The read/write barriers are a problem. However, D is designed to allow a moving collector, at least in some cases. -- Simen
Jan 03 2013
prev sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 3 January 2013 at 11:40:37 UTC, deadalnix wrote:
 On Thursday, 3 January 2013 at 11:26:11 UTC, Thiez wrote:
 On Thursday, 3 January 2013 at 10:17:19 UTC, deadalnix wrote:
 Generational seems completely unrealistic.
Why?
Tracking reference from old gen to new gen require read/write barriers. Plus, it is unclear what the win is, generational GC is way less interesting when the GC cannot move.
Last time I talked with Walter (on reddit) regarding this he mentioned papers on "mostly copying GCs" where one can have a generational imprecise GC which moves most of the data but not all of it. For example, without stack maps we don't know where in the stack are pointers, so we don't move objects possibly referenced from stack. However those referenced only from the heap can be moved since we have precise heap info. I recall this is the current situation of Rainer's mostly precise GC used in VisualD - it has precise maps of the heap but not of the stack. +1 to better GC as a project. An easier but still possibly interesting goal would be changing current (or better Rainer's) GC to use parallel marking and lazy sweeping, same things that were done for Ruby interpreter recently. That should make GC pauses much shorter and it doesn't require rewriting most of the GC.
Jan 03 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 3 January 2013 at 18:54:32 UTC, thedeemon wrote:
 +1 to better GC as a project. An easier but still possibly 
 interesting goal would be changing current (or better Rainer's) 
 GC to use parallel marking and lazy sweeping, same things that 
 were done for Ruby interpreter recently. That should make GC 
 pauses much shorter and it doesn't require rewriting most of 
 the GC.
I think we'd better look for performance boost in concurrency than parallelism here. Both TL and immutable are very concurrent GC friendly.
Jan 03 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-02 17:14, Ishan Thilina Somasiri wrote:
 Hi,

 I'm posting this on bhalf of a group of 4 students from the final
 year of Department of Computer Science and Engineering,University
 of Moratuwa, Sri Lanka. We are required to do a 8 months long
 project in our final year. The
 project should consist of both a research and development
 component and
 an implementation. Our group is interested in areas such as,

     * Information security
     * Cloud
     * Parallel computing
     * Compilers
     * Operating Systems
     * Distributed systems


 We’d like to know if the D programming language project has any
 project
 ideas that falls within our interest areas.
* Since you ask and mentioned compilers I would say a lexer/parser/front end written in D. This should be usable as a library which the following could be build upon: * Syntax highlighter * Compiler * Refactoring * Static analyzer * Various other features usually found in an IDE There are several other developers working on lexers/parsers, perhaps helping out with existing project could be a good idea. * Implementing support for extern (Objective-C), aka ABI compatibility with Objective-C. This is already worked on but the project has staled: http://michelf.ca/projects/d-objc/ * Implementing support for the new WinRT in Windows 8. * I think it would be really cool if D could get support for AST (Abstract Syntax Tree) macros. Other ides for Phobos are: * New XML module * Finishing an allocator design + new containers * A package dealing with cryptographic -- /Jacob Carlborg
Jan 02 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 2 January 2013 at 17:39:06 UTC, Jacob Carlborg 
wrote:
 * Since you ask and mentioned compilers I would say a 
 lexer/parser/front end written in D. This should be usable as a 
 library which the following could be build upon:

 * Syntax highlighter
 * Compiler
 * Refactoring
 * Static analyzer
 * Various other features usually found in an IDE

 There are several other developers working on lexers/parsers, 
 perhaps helping out with existing project could be a good idea.
Indeed, I work on SDC, and a lot of work need to be done. However, I'm not sure how to staff 4 person on it, and i'm sure the GC things is more beneficial for D in general (and is in the scope).
 Other ides for Phobos are:

 * New XML module
Tango.xml is known to be one of the fastest xml lib ever made. Maybe we should simply use it (or change its interface to be more phobosish while keeping the internals).
Jan 02 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-02 22:26, deadalnix wrote:

 Indeed, I work on SDC, and a lot of work need to be done. However, I'm
 not sure how to staff 4 person on it, and i'm sure the GC things is more
 beneficial for D in general (and is in the scope).
Just need to figure out what needs to be done and assign different tasks.
 Tango.xml is known to be one of the fastest xml lib ever made. Maybe we
 should simply use it (or change its interface to be more phobosish while
 keeping the internals).
I would prefer that, Tango also has a package for cryptographic. But this will most likely never happen. The licensees are not compatible and there has been some trouble around this is the past. -- /Jacob Carlborg
Jan 02 2013