www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [GSOC] more ideas

reply Trass3r <un known.com> writes:
I don't want to edit the ideas wiki page without getting another opinion,  
so what about:


- helping with getting dmd produce x64 code on Windows.

To quote Walter:

"To do 64 bits on Windows requires:

1. 64 bit OMF
2. 64 bit librarian
3. 64 bit generating dmd
4. 64 bit C compiler
5. 64 bit symbolic debug info
6. 64 bit debugger
7. 64 bit C runtime"

The first step would be to examine if MinGW's tools could be used.


- making D run on other architectures like ARM, PowerPC, ...?
GDC and LDC theoretically support these but I guess druntime and the like  
could cause difficulties.
Especially ARM could be useful for targeting the mobile phone sector.
Mar 24 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 24 Mar 2011 20:54:56 +0200, Trass3r <un known.com> wrote:

 I don't want to edit the ideas wiki page without getting another  
 opinion, so what about:

Me too - how about an image library? Being able to load/save popular image formats from/to RGB pixel arrays would be a great start, with everything else a bonus. There's gd bindings here, but it's only a thin wrapper around the C interface: http://www.algonet.se/~afb/d/ Lack of an image library keeps me going back to Delphi+PngImage for such tasks. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Mar 24 2011
next sibling parent reply Simon <s.d.hammett gmail.com> writes:
On 24/03/2011 19:39, Vladimir Panteleev wrote:
 On Thu, 24 Mar 2011 20:54:56 +0200, Trass3r <un known.com> wrote:

 I don't want to edit the ideas wiki page without getting another
 opinion, so what about:

Me too - how about an image library? Being able to load/save popular image formats from/to RGB pixel arrays would be a great start, with everything else a bonus. There's gd bindings here, but it's only a thin wrapper around the C interface: http://www.algonet.se/~afb/d/ Lack of an image library keeps me going back to Delphi+PngImage for such tasks.

I've got bindings for libjpeg and libpnd done. Whipping up a few more bindings for other c image format libs wouldn't be difficult. Just having a single source for basic IO of the more popular formats would be good. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Mar 24 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-03-24 22:16, Simon wrote:
 On 24/03/2011 19:39, Vladimir Panteleev wrote:
 On Thu, 24 Mar 2011 20:54:56 +0200, Trass3r <un known.com> wrote:

 I don't want to edit the ideas wiki page without getting another
 opinion, so what about:

Me too - how about an image library? Being able to load/save popular image formats from/to RGB pixel arrays would be a great start, with everything else a bonus. There's gd bindings here, but it's only a thin wrapper around the C interface: http://www.algonet.se/~afb/d/ Lack of an image library keeps me going back to Delphi+PngImage for such tasks.

I've got bindings for libjpeg and libpnd done. Whipping up a few more bindings for other c image format libs wouldn't be difficult. Just having a single source for basic IO of the more popular formats would be good.

Derelict (http://dsource.org/projects/derelict/) contains bindings for DevIL (http://openil.sourceforge.net/). -- /Jacob Carlborg
Mar 24 2011
parent Simon <s.d.hammett gmail.com> writes:
On 24/03/2011 21:35, Jacob Carlborg wrote:
 On 2011-03-24 22:16, Simon wrote:
 On 24/03/2011 19:39, Vladimir Panteleev wrote:
 On Thu, 24 Mar 2011 20:54:56 +0200, Trass3r <un known.com> wrote:

 I don't want to edit the ideas wiki page without getting another
 opinion, so what about:

Me too - how about an image library? Being able to load/save popular image formats from/to RGB pixel arrays would be a great start, with everything else a bonus. There's gd bindings here, but it's only a thin wrapper around the C interface: http://www.algonet.se/~afb/d/ Lack of an image library keeps me going back to Delphi+PngImage for such tasks.

I've got bindings for libjpeg and libpnd done. Whipping up a few more bindings for other c image format libs wouldn't be difficult. Just having a single source for basic IO of the more popular formats would be good.

Derelict (http://dsource.org/projects/derelict/) contains bindings for DevIL (http://openil.sourceforge.net/).

Yes I know, but I don't like devil's interface. It would be nicer to have a suite of simple 1to1 wrappers to the lower level libraries for greater flexibility. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Mar 24 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Vladimir Panteleev wrote:
 On Thu, 24 Mar 2011 20:54:56 +0200, Trass3r <un known.com> wrote:
 
 I don't want to edit the ideas wiki page without getting another 
 opinion, so what about:

Me too - how about an image library? Being able to load/save popular image formats from/to RGB pixel arrays would be a great start, with everything else a bonus.

I was going to suggest *exactly* the same thing. Just loading the file into raw bytes, and saving the raw bytes into a file. And even just PNG, BMP, JPEG would be a huge step forward. Optionally GIF as well, now that the patents have expired.
Mar 25 2011
next sibling parent Don <nospam nospam.com> writes:
Don wrote:
 Vladimir Panteleev wrote:
 On Thu, 24 Mar 2011 20:54:56 +0200, Trass3r <un known.com> wrote:

 I don't want to edit the ideas wiki page without getting another 
 opinion, so what about:

Me too - how about an image library? Being able to load/save popular image formats from/to RGB pixel arrays would be a great start, with everything else a bonus.

I was going to suggest *exactly* the same thing. Just loading the file into raw bytes, and saving the raw bytes into a file. And even just PNG, BMP, JPEG would be a huge step forward. Optionally GIF as well, now that the patents have expired.

I've added this to the list. Feel free to modify / extend it.
Mar 25 2011
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 25/03/2011 08:45, Don wrote:
 Vladimir Panteleev wrote:
 On Thu, 24 Mar 2011 20:54:56 +0200, Trass3r <un known.com> wrote:

 I don't want to edit the ideas wiki page without getting another
 opinion, so what about:

Me too - how about an image library? Being able to load/save popular image formats from/to RGB pixel arrays would be a great start, with everything else a bonus.

I was going to suggest *exactly* the same thing. Just loading the file into raw bytes, and saving the raw bytes into a file. And even just PNG, BMP, JPEG would be a huge step forward. Optionally GIF as well, now that the patents have expired.

Like Jacob mentioned, Derelict has interfaces for DevIL, and also SDL_Image if I recall correctly. Why isn't that good enough? I don't know about DevIL, but I've used SDL_Image before, and I think the API was perfectly fine. I mean, it was quite small, so there is not much that needs to be adapted to make it more D-like. -- Bruno Medeiros - Software Engineer
Mar 26 2011
parent Don <nospam nospam.com> writes:
Bruno Medeiros wrote:
 On 25/03/2011 08:45, Don wrote:
 Vladimir Panteleev wrote:
 On Thu, 24 Mar 2011 20:54:56 +0200, Trass3r <un known.com> wrote:

 I don't want to edit the ideas wiki page without getting another
 opinion, so what about:

Me too - how about an image library? Being able to load/save popular image formats from/to RGB pixel arrays would be a great start, with everything else a bonus.

I was going to suggest *exactly* the same thing. Just loading the file into raw bytes, and saving the raw bytes into a file. And even just PNG, BMP, JPEG would be a huge step forward. Optionally GIF as well, now that the patents have expired.

Like Jacob mentioned, Derelict has interfaces for DevIL, and also SDL_Image if I recall correctly. Why isn't that good enough? I don't know about DevIL, but I've used SDL_Image before, and I think the API was perfectly fine. I mean, it was quite small, so there is not much that needs to be adapted to make it more D-like.

Maybe there's not much work to be done. But I am CERTAIN that such a thing belongs in Phobos.
Mar 26 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 25/03/2011 08:45, Don wrote:
 Vladimir Panteleev wrote:
 On Thu, 24 Mar 2011 20:54:56 +0200, Trass3r <un known.com> wrote:

 I don't want to edit the ideas wiki page without getting another
 opinion, so what about:

Me too - how about an image library? Being able to load/save popular image formats from/to RGB pixel arrays would be a great start, with everything else a bonus.

I was going to suggest *exactly* the same thing. Just loading the file into raw bytes, and saving the raw bytes into a file. And even just PNG, BMP, JPEG would be a huge step forward. Optionally GIF as well, now that the patents have expired.

Another one that might be work looking at is DWT itself, it has support for loading and saving the BMP,JPEG,GIF,PNG,TIFF formats. It should be thread-safe, and not have the same license issues that LGPL has. On the other hand its image loading capabilities may not be clearly separated from the whole of the DWT library. It may even be that the code to save/load images is not performed by DWT itself, but rather uses the underlying widget platform (win, gtk) to do the imageloading. However I took a quick glance at the source (like http://hg.dsource.org/projects/dwt2/file/ddbfe84d86df/org.eclipse.swt.gtk.linux.x86/src/org/eclipse/swt/internal/im ge/JPEGFileFormat.d ), and that doesn't seem to be the case. -- Bruno Medeiros - Software Engineer
Apr 07 2011
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Trass3r Wrote:

 1. 64 bit OMF
 2. 64 bit librarian
 3. 64 bit generating dmd
 4. 64 bit C compiler
 5. 64 bit symbolic debug info
 6. 64 bit debugger
 7. 64 bit C runtime"
 
 The first step would be to examine if MinGW's tools could be used.

No way. They're GPL.
 GDC and LDC theoretically support these but I guess druntime and the like  
 could cause difficulties.

8. 64 bit druntime. just one more task to do. As long as L/GDC works, one can try to compile druntime and work on it.
Mar 24 2011
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 3/24/11 10:31 PM, Kagamin wrote:
 The first step would be to examine if MinGW's tools could be used.

No way. They're GPL.

So? David
Mar 24 2011
next sibling parent dsimcha <dsimcha yahoo.com> writes:
On 3/24/2011 7:26 PM, Jonathan M Davis wrote:
 On 2011-03-24 15:04:45, David Nadlinger wrote:
 On 3/24/11 10:31 PM, Kagamin wrote:
 The first step would be to examine if MinGW's tools could be used.

No way. They're GPL.

So?

I wouldn't think that the GPL would be a problem for build tools. It (and LGPL) _is_ a problem for libraries, but you're not linking with tools or generally doing anything with their code. You're just using them. So, I wouldn't think that the GPL would be a problem. dmd's front-end is licensed on the GPL. Phobos, on the other hand, is licensed under Boost (except for a few older modules which haven't been replaced or relicensed yet). There's a big difference between a tool and a library with regards to how licenses affect them. - Jonathan M Davis

In case there was any ambiguity, the GPL FAQs specifically state that, except in a few corner cases, the output of GPLed programs is **NOT** covered by the GPL. http://www.gnu.org/licenses/gpl-faq.html#GPLOutput
Mar 24 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Jonathan M Davis Wrote:

 I wouldn't think that the GPL would be a problem for build tools. It (and 
 LGPL) _is_ a problem for libraries, but you're not linking with tools or 
 generally doing anything with their code. You're just using them.

Well, if Digital Mars doesn't plan to redistribute them, then ok.
Mar 24 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 25.03.2011 07:08, schrieb Kagamin:
 Jonathan M Davis Wrote:

 I wouldn't think that the GPL would be a problem for build tools. It (and
 LGPL) _is_ a problem for libraries, but you're not linking with tools or
 generally doing anything with their code. You're just using them.

Well, if Digital Mars doesn't plan to redistribute them, then ok.

The Linux version of DMD already uses GCC tools for linking. Why shouldn't Digital Mars redistribute GNU tools for linking? I don't think the GPL forbids that, as long as the sources of those binaries are available somewhere.
Mar 25 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 Am 25.03.2011 07:08, schrieb Kagamin:
 Jonathan M Davis Wrote:
 I wouldn't think that the GPL would be a problem for build tools. It
 (and LGPL) _is_ a problem for libraries, but you're not linking with
 tools or generally doing anything with their code. You're just using
 them.

Well, if Digital Mars doesn't plan to redistribute them, then ok.

The Linux version of DMD already uses GCC tools for linking. Why shouldn't Digital Mars redistribute GNU tools for linking? I don't think the GPL forbids that, as long as the sources of those binaries are available somewhere.

It doesn't need to. The Linux install usually already has it, and if it doesn't, it's easy to install it. So, it's not exactly onerous to require that it be installed (not to mention, you typically want your installed gcc to be the same version which everything on your system was built with). So, there's no need to redistribute any GNU anything. The situation isn't as straightforward for Windows though, since MinGW and the like are not typically installed (though there are plenty of developers who do have it installed). So, requiring MinGW would be kind of questionable. Not to mention, didn't someone find a linker that can link both COFF and OMF files on Windows and mostly works with dmd (IIRC, the debugging symbols don't currently work)? That sounds a lot more desirable than dealing with the GNU tools on Windows (which already have the whole COFF vs OMF problem). - Jonathan M Davis
Mar 25 2011
prev sibling parent Trass3r <un known.com> writes:
 Not to mention, didn't someone find a linker that can link both COFF and  
 OMF
 files on Windows and mostly works with dmd (IIRC, the debugging symbols  
 don't
 currently work)? That sounds a lot more desirable than dealing with the  
 GNU
 tools on Windows (which already have the whole COFF vs OMF problem).

Nobody knows how mature it really is, it isn't open source and you never know if the author will cease support/make it commercial whatever someday. The object format has to be adapted for x64 anyway. And I doubt something like OMF64 even exists.
Mar 25 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-24 15:04:45, David Nadlinger wrote:
 On 3/24/11 10:31 PM, Kagamin wrote:
 The first step would be to examine if MinGW's tools could be used.

No way. They're GPL.

So?

I wouldn't think that the GPL would be a problem for build tools. It (and LGPL) _is_ a problem for libraries, but you're not linking with tools or generally doing anything with their code. You're just using them. So, I wouldn't think that the GPL would be a problem. dmd's front-end is licensed on the GPL. Phobos, on the other hand, is licensed under Boost (except for a few older modules which haven't been replaced or relicensed yet). There's a big difference between a tool and a library with regards to how licenses affect them. - Jonathan M Davis
Mar 24 2011
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Trass3r (un known.com)'s article
 I don't want to edit the ideas wiki page without getting another opinion,
 so what about:
 - helping with getting dmd produce x64 code on Windows.
 To quote Walter:
 "To do 64 bits on Windows requires:
 1. 64 bit OMF
 2. 64 bit librarian
 3. 64 bit generating dmd
 4. 64 bit C compiler
 5. 64 bit symbolic debug info
 6. 64 bit debugger
 7. 64 bit C runtime"
 The first step would be to examine if MinGW's tools could be used.

I can see using MinGW's tools as a dead-end, rather than a step in the right direction. (Besides, wouldn't DMD Windows have to output object files in COFF format?)
 - making D run on other architectures like ARM, PowerPC, ...?
 GDC and LDC theoretically support these but I guess druntime and the like
 could cause difficulties.
 Especially ARM could be useful for targeting the mobile phone sector.

Sadly, no one cares.
Mar 24 2011
parent Trass3r <un known.com> writes:
Am 25.03.2011, 00:52 Uhr, schrieb Iain Buclaw <ibuclaw ubuntu.com>:
 == Quote from Trass3r (un known.com)'s article
 I don't want to edit the ideas wiki page without getting another  
 opinion,
 so what about:
 - helping with getting dmd produce x64 code on Windows.
 To quote Walter:
 "To do 64 bits on Windows requires:
 1. 64 bit OMF
 2. 64 bit librarian
 3. 64 bit generating dmd
 4. 64 bit C compiler
 5. 64 bit symbolic debug info
 6. 64 bit debugger
 7. 64 bit C runtime"
 The first step would be to examine if MinGW's tools could be used.

I can see using MinGW's tools as a dead-end, rather than a step in the right direction. (Besides, wouldn't DMD Windows have to output object files in COFF format?)

Care to elaborate? Yes, outputting COFF would be 1 step if this direction was pursued.
Mar 24 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-25 16:58, Trass3r wrote:
 Not to mention, didn't someone find a linker that can link both COFF and
 OMF
 files on Windows and mostly works with dmd (IIRC, the debugging symbols
 don't
 currently work)? That sounds a lot more desirable than dealing with the
 GNU
 tools on Windows (which already have the whole COFF vs OMF problem).

Nobody knows how mature it really is, it isn't open source and you never know if the author will cease support/make it commercial whatever someday. The object format has to be adapted for x64 anyway. And I doubt something like OMF64 even exists.

Yes. It would be _very_ nice if you could link D code with Microsoft's linker. The OMF vs COFF thing is really annoying. - Jonathan M Davis
Mar 25 2011
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 24/03/2011 18:54, Trass3r wrote:
 I don't want to edit the ideas wiki page without getting another
 opinion, so what about:

BTW, students are free (in fact a bit encouraged according to some organizations) to bring forth their own ideas. It is of course better if the student is involved in a proposal that he/she is more interested and passionate about. -- Bruno Medeiros - Software Engineer
Mar 26 2011
prev sibling parent so <so so.so> writes:
On Sat, 26 Mar 2011 16:45:35 +0200, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:

 On 25/03/2011 08:45, Don wrote:
 Vladimir Panteleev wrote:
 On Thu, 24 Mar 2011 20:54:56 +0200, Trass3r <un known.com> wrote:

 I don't want to edit the ideas wiki page without getting another
 opinion, so what about:

Me too - how about an image library? Being able to load/save popular image formats from/to RGB pixel arrays would be a great start, with everything else a bonus.

I was going to suggest *exactly* the same thing. Just loading the file into raw bytes, and saving the raw bytes into a file. And even just PNG, BMP, JPEG would be a huge step forward. Optionally GIF as well, now that the patents have expired.

Like Jacob mentioned, Derelict has interfaces for DevIL, and also SDL_Image if I recall correctly. Why isn't that good enough? I don't know about DevIL, but I've used SDL_Image before, and I think the API was perfectly fine. I mean, it was quite small, so there is not much that needs to be adapted to make it more D-like.

As far as i know DevIL isn't thread-safe. Another issue with these libraries i think is the license.
Mar 26 2011