DIP80: phobos additions (page 3)

On Monday, 8 June 2015 at 04:22:56 UTC, Mike wrote: > On Monday, 8 June 2015 at 04:21:45 UTC, Tofu Ninja wrote: >> >> Personally I would just be happy with a d wrapper for something like freeimage being included. > > That's what Deimos is for (https://github.com/D-Programming-Deimos/FreeImage). > > Mike I guess I meant to use it as a base for image loading and storing and to build some kind of d image lib on top of it. I see no point in us trying to implement all the various image formats if we try to make a image lib for phobos.

On Monday, 8 June 2015 at 04:22:56 UTC, Mike wrote: > On Monday, 8 June 2015 at 04:21:45 UTC, Tofu Ninja wrote: >> >> Personally I would just be happy with a d wrapper for something like freeimage being included. > > That's what Deimos is for (https://github.com/D-Programming-Deimos/FreeImage). Yeah. After the problems with linking in curl, I think that we more or less decided that including stuff in Phobos which has to link against 3rd party libraries isn't a great idea. Maybe we'll end up doing it again, but in general, it just makes more sense for those to be done as 3rd party libraries and put in code.dlang.org. - Jonathan M Davis

June 08, 2015

Re: DIP80: phobos additions

Posted by Rikki Cattermole
in reply to Tofu Ninja

Permalink

Rikki Cattermole

Posted in reply to Tofu Ninja

Permalink

On 8/06/2015 4:34 p.m., Tofu Ninja wrote:
> On Monday, 8 June 2015 at 04:22:56 UTC, Mike wrote:
>> On Monday, 8 June 2015 at 04:21:45 UTC, Tofu Ninja wrote:
>>>
>>> Personally I would just be happy with a d wrapper for something like
>>> freeimage being included.
>>
>> That's what Deimos is for
>> (https://github.com/D-Programming-Deimos/FreeImage).
>>
>> Mike
>
> I guess I meant to use it as a base for image loading and storing and to
> build some kind of d image lib on top of it. I see no point in us trying
> to implement all the various image formats if we try to make a image lib
> for phobos.

Atleast my idea behind Devisualization.Image was mostly this.
The implementation can be swapped out with another easily. But the actual interface used is well made.

So while a Phobos image library might have a few formats such as PNG, it probably wouldn't include a vast array of them.
So then its just a matter of allowing 3rd party libraries to add them transparently.

On Monday, 8 June 2015 at 03:08:46 UTC, Rikki Cattermole wrote: > Gl3n should be a candidate as it is old code and good one at that. > https://github.com/Dav1dde/gl3n > But it seems like it is no longer maintained. Looks like it's been getting a couple commits monthly, so I think it's being maintained.

On Monday, 8 June 2015 at 04:34:56 UTC, Jonathan M Davis wrote: > On Monday, 8 June 2015 at 04:22:56 UTC, Mike wrote: >> On Monday, 8 June 2015 at 04:21:45 UTC, Tofu Ninja wrote: >>> >>> Personally I would just be happy with a d wrapper for something like freeimage being included. >> >> That's what Deimos is for (https://github.com/D-Programming-Deimos/FreeImage). > > Yeah. After the problems with linking in curl, I think that we more or less decided that including stuff in Phobos which has to link against 3rd party libraries isn't a great idea. Maybe we'll end up doing it again, but in general, it just makes more sense for those to be done as 3rd party libraries and put in code.dlang.org. > > - Jonathan M Davis I think that is probably pretty sad if that is actually the current stance. There are so many great libraries that Phobos could benefit from and is not because of a packaging issue.

On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: > Phobos is awesome, the libs of go, python and rust only have better marketing. > As discussed on dconf, phobos needs to become big and blow the rest out of the sky. > > http://wiki.dlang.org/DIP80 > > lets get OT, please discuss IMHO, Phobos could include thinks like this as a standard : - OAuth (1 & 2), at least it would be useful for projects like vibe.d - Create / read QR codes, maybe ? It seems we see more and more QR Codes here and there, so it could potentially be worth it - Better / full OS bindings (winapi, x11, ect.), but it would (sadly) require a very large amount of work to do so. - + what has been said already. I guess we can try to think about integrating a large amount of things that are widely used and are considered as "standards"

On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: > http://wiki.dlang.org/DIP80 > > lets get OT, please discuss Automatic randomizer for builtins, ranges, etc. Used to generate data for tests. Here's a start: https://github.com/nordlow/justd/blob/master/random_ex.d

On 6/7/2015 8:53 PM, Manu via Digitalmars-d wrote: > I've been humoring the idea of porting my engine to D. It's about 15 > years of development, better/cleaner than most proprietary engines > I've used at game studios. > I wonder if there would be interest in this? Problem is, I need all > the cross compilers to exist before I pull the plug on the C code... a > game engine is no good if it's not portable to all the consoles under > the sun. That said, I think it would be a good case-study to get the > cross compilers working against. It's a chicken-and-egg thing. Somebody's got to start and not wait for the others.

On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: > Phobos is awesome, the libs of go, python and rust only have better marketing. > As discussed on dconf, phobos needs to become big and blow the rest out of the sky. > > http://wiki.dlang.org/DIP80 > > lets get OT, please discuss There are https://github.com/9il/simple_matrix and https://github.com/9il/cblas . I will try to rework them for Phobos. Any ideas and suggestions? Some notes about portability: 1. OS X has Accelerated framework builtin. 2. Linux has blast by default or it can be easily installed. However default blast is very slow. The openBLAS is preferred. 3. Looks like there is no simple way to have BLAS support on Windows. Should we provide BLAS library with DMD for Windows and maybe Linux? Regards, Ilya

Forums