• Trass3r (17/17) Mar 24 2011 I don't want to edit the ideas wiki page without getting another opinion...
• Vladimir Panteleev (11/13) Mar 24 2011 Me too - how about an image library? Being able to load/save popular ima...
• Simon (8/18) Mar 24 2011 I've got bindings for libjpeg and libpnd done.
• Jacob Carlborg (5/25) Mar 24 2011 Derelict (http://dsource.org/projects/derelict/) contains bindings for
• Simon (7/32) Mar 24 2011 Yes I know, but I don't like devil's interface.
• Don (5/13) Mar 25 2011 I was going to suggest *exactly* the same thing. Just loading the file
• Don (2/17) Mar 25 2011 I've added this to the list. Feel free to modify / extend it.
• Bruno Medeiros (8/21) Mar 26 2011 Like Jacob mentioned, Derelict has interfaces for DevIL, and also
• Don (3/25) Mar 26 2011 Maybe there's not much work to be done. But I am CERTAIN that such a
• so (4/25) Mar 26 2011 As far as i know DevIL isn't thread-safe.
• Bruno Medeiros (13/26) Apr 07 2011 Another one that might be work looking at is DWT itself, it has support
• Kagamin (4/15) Mar 24 2011 8. 64 bit druntime.
• David Nadlinger (3/5) Mar 24 2011 So?
• Jonathan M Davis (10/16) Mar 24 2011 I wouldn't think that the GPL would be a problem for build tools. It (an...
• dsimcha (4/20) Mar 24 2011 In case there was any ambiguity, the GPL FAQs specifically state that,
• Kagamin (2/5) Mar 24 2011 Well, if Digital Mars doesn't plan to redistribute them, then ok.
• Daniel Gibson (5/10) Mar 25 2011 The Linux version of DMD already uses GCC tools for linking.
• Jonathan M Davis (13/27) Mar 25 2011 It doesn't need to. The Linux install usually already has it, and if it
• Trass3r (5/12) Mar 25 2011 Nobody knows how mature it really is, it isn't open source and you never...
• Jonathan M Davis (4/18) Mar 25 2011 Yes. It would be _very_ nice if you could link D code with Microsoft's l...
• Iain Buclaw (4/21) Mar 24 2011 I can see using MinGW's tools as a dead-end, rather than a step in the r...
• Trass3r (3/22) Mar 24 2011 Care to elaborate?
• Bruno Medeiros (7/9) Mar 26 2011 BTW, students are free (in fact a bit encouraged according to some
• Kagamin (2/16) Mar 26 2011 In this case they should be distributed as a separate package (in this c...
• Kagamin (3/11) Mar 26 2011 May be, he's fed up with gdc development? :)

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.

"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

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

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

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

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.

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.

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

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.

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.

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

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.

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

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

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

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.

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.

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

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.

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

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.

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.

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

Kagamin <spam here.lot> writes:

Daniel Gibson Wrote:

 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.

In this case they should be distributed as a separate package (in this case
there's no need for redistribution: you can just link to mingw.sf.net
directly). Will people be fine that the main dmd package can't link anything, I
don't know. Mingw seems to live fine with that.

Kagamin <spam here.lot> writes:

Trass3r Wrote:

 Am 25.03.2011, 00:52 Uhr, schrieb Iain Buclaw <ibuclaw ubuntu.com>:
 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.

May be, he's fed up with gdc development? :)
https://bitbucket.org/goshawk/gdc/changesets