On Thursday, 6 February 2014 at 10:29:20 UTC, dennis luehring wrote:
> so you're not work in the normal software development business where
> non-source code third party dependicies are fully normal :)

Not in terms of libraries no, what libraries would that be?

In terms of infrastructure, yes, but I try to avoid using features I cannot replace with alternatives and strongly prefer open source alternatives.

Am 06.02.2014 11:43, schrieb "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>":
> On Thursday, 6 February 2014 at 10:29:20 UTC, dennis luehring
> wrote:
>> so you're not work in the normal software development business
>> where
>> non-source code third party dependicies are fully normal :)
>
> Not in terms of libraries no, what libraries would that be?

all libraries that other deparments don't want you to see or you don't
need to see - so unnormal in your environment?

On 6 February 2014 20:21, <"Ola Fosheim Grøstad\" <ola.fosheim.grostad+dlang@gmail.com>"@puremagic.com> wrote:

> On Thursday, 6 February 2014 at 09:27:19 UTC, Paulo Pinto wrote:
>
>> So what do you do when different libraries require different runtimes?
>>
>
> I guess a given compiler could have a "cross compiler option" that generates libraries for all the available runtimes the compiler supports?
>
>
>  To be more specific to my previous comment. Objective-C GC required
>> special compilation flags and care needed to be taken in GC enabled code, like in C GCs.
>>
>
> I understand. I am not sure if having multiple flags that creates a combinatorial explosion would be a good idea. I think you should have a set of invidual runtimes targeting typical scenarios, supporting different sets of functionality. (embedded, kernel, multimedia, server, batch, hpc…)
>
> However, I think it would only work for the same compiler, because you really don't want to prevent innovation…
>
>
>  So no distinct runtimes were required as the generated code is no
>> different than an Objective-C developer would have written by hand.
>>
>
> You might be able to design the runtime/object code in such a way that you get link errors.
>
>
>  In any case there isn't a standard C++ ABI defined. Well, there are a
>> few, but vendors don't use them.
>>
>
> Yeah, well I am not personally bothered by it. The only time I consider using binary-only libraries is for graphics and OS level stuff that is heavily used by others so that it is both well tested and workaround is available on the net. (OpenGL, Direct-X, Cocoa etc)
>
> Not having the source code to a library is rather risky in terms of having to work around bugs by trail and error, without even knowing what the bug actually is.
>
> Thankfully, most useful libraries are open source.
>

Some that I regularly encounter: system libs, opengl, directx, fmod,
physics (havok, phyzx, etc), animation (euphoria, natural motion), bink,
lip-sync libraries, proprietary engine libraries, art-package integration
libraries (3ds max, maya, photoshop), fbx, and many, many more.
Yes these are C libs, but the idea that people don't regularly use
proprietary libs is fantasy.

On Thursday, 6 February 2014 at 11:08:51 UTC, dennis luehring wrote:
> all libraries that other deparments don't want you to see or you don't
> need to see - so unnormal in your environment?

My environment is kind of not the point (but yes that would have been un-normal :-). If it is internal then you surely have selected the compile options as a project policy and that makes this a non-issue.

It is external libraries that are an issue, and depending on closed source external libraries is risky if they cannot be replaced. Depending on your contract you might have to reimplement the entire library for scratch for free if you cannot fix a problem. And unfortunately, small players file for bankruptcy all the time, so open source is the best insurance you can get.

On Thursday, 6 February 2014 at 11:29:35 UTC, Manu wrote:
> Yes these are C libs, but the idea that people don't regularly use
> proprietary libs is fantasy.

I never claimed that people don't do it. I claimed that it is risky if you don't have a replacement for it. And I don't think one should lobotomise a development environment to support it. C++ gets traction without being very good at that. Plenty of languages that are source-distributed are getting traction too.

On 2014-02-06 04:56:28 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> On 2/5/14, 4:53 PM, Michel Fortin wrote:
>> On 2014-02-05 22:19:27 +0000, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> said:
>> 
>>> I want to make one positive step toward improving memory allocation in
>>> the D language.
>> 
>> I know. But I find your proposal confusing.
>> 
>> Perhaps this is just one piece in your master plan where everything will
>> make sense once we have all the pieces. But this piece by itself makes
>> no sense to me; I have no idea where you're going with it.
>> 
>> Is this the continuation of the old thread where you wanted ideas about
>> how to eliminate hidden allocations in buildPath? Doesn't sound like it.
> 
> Actually buildPath is a good example because it concatenates strings. It should work transparently with RC and GC strings.

That thread about buildPath started like this: "Walter and I were talking about eliminating the surreptitious allocations in buildPath". But reference counting will do nothing to eliminate surreptitious allocations. It can't be that problem you're trying to address.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Thursday, 6 February 2014 at 11:29:35 UTC, Manu wrote:
> Some that I regularly encounter: system libs, opengl, directx, fmod,
> physics (havok, phyzx, etc), animation (euphoria, natural

And just to nitpick:

1. Games are hit or miss with a very short life cycle. This is not typical. Most software have a life cycle counted in years with contractual support requirements that can be harsh, not months with very little possibility of damage claims for the end user.

2. The life cycle of games is porting when your product succeeds. You are F*CK*D if you don't have source code access and want to port to an emerging platform, so I believe you can obtain source code for libraries like Havoc and FMOD for that reason alone.

I really don't think closed source libraries should be the focus of D if it prevents having a good infrastructure.

On Thursday, 6 February 2014 at 11:59:49 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 6 February 2014 at 11:29:35 UTC, Manu wrote:
>> Some that I regularly encounter: system libs, opengl, directx, fmod,
>> physics (havok, phyzx, etc), animation (euphoria, natural
>
> And just to nitpick:
>
> 1. Games are hit or miss with a very short life cycle. This is not typical. Most software have a life cycle counted in years with contractual support requirements that can be harsh, not months with very little possibility of damage claims for the end user.
>
> 2. The life cycle of games is porting when your product succeeds. You are F*CK*D if you don't have source code access and want to port to an emerging platform, so I believe you can obtain source code for libraries like Havoc and FMOD for that reason alone.
>
> I really don't think closed source libraries should be the focus of D if it prevents having a good infrastructure.

D will never be taken serious by its target audience if no proper support is available.

In the enterprise world I work on, very few projects have 100% source code available.

--
Paulo

On Thursday, 6 February 2014 at 12:12:31 UTC, Paulo Pinto wrote:
> D will never be taken serious by its target audience if no proper support is available.

What is the target audience? Is it clearly defined?

> In the enterprise world I work on, very few projects have 100% source code available.

In my view discouraging libraries as binary blobs is a net positive, if that means you loose a specific audience I still think it is a win. Because I don't think binary blobs are positive for the eco system. I am quite certain that the plethora of libraries that you find for Python, Ruby and Perl exist due to the encouragement of source distribution and ease of library modification. (e.g. you cannot use the library without source access).

Binary blobs in C are less problematic (but still problematic) because of the language stability and compiler maturity.

Binary blobs that are DMD2 means you cannot move to DMD3 or recompile it to fix a compiler induced bug among other things. Maybe some commercial players will make DMD2 blobs available and then pull out due to lack of profit, that's not unlikely, and it sucks more than not having the libraries in the first place.

On Thursday, 6 February 2014 at 12:43:19 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 6 February 2014 at 12:12:31 UTC, Paulo Pinto wrote:
>> D will never be taken serious by its target audience if no proper support is available.
>
> What is the target audience? Is it clearly defined?
>
>> In the enterprise world I work on, very few projects have 100% source code available.
>
> In my view discouraging libraries as binary blobs is a net positive, if that means you loose a specific audience I still think it is a win. Because I don't think binary blobs are positive for the eco system. I am quite certain that the plethora of libraries that you find for Python, Ruby and Perl exist due to the encouragement of source distribution and ease of library modification. (e.g. you cannot use the library without source access).
>
> Binary blobs in C are less problematic (but still problematic) because of the language stability and compiler maturity.
>
> Binary blobs that are DMD2 means you cannot move to DMD3 or recompile it to fix a compiler induced bug among other things. Maybe some commercial players will make DMD2 blobs available and then pull out due to lack of profit, that's not unlikely, and it sucks more than not having the libraries in the first place.

You would be amazed how many times I have written FFI code that decrypts source code on load.

--
Paulo