On 3/15/2014 6:44 AM, Johannes Pfau wrote:
> Then in cairo.d
> version(CAIRO_HAS_PNG_SUPPORT)
> {
>     extern(C) int cairo_save_png(char* x);
>     void savePNG(string x){cairo_save_png(toStringz(x))};
> }

try adding:

  else
  {
       void savePNG(string x) { }
  }

and then your users can just call savePNG without checking the version.

Am Sun, 16 Mar 2014 12:28:24 +0100
schrieb Rainer Schuetze <r.sagitario@gmx.de>:

Are we still in the same discussion?
The only thing I miss is that among the several ways to
express function signatures in D, some don't allow you to
specify all attributes. My memory is blurry, but I think it
was function literals that I used to write stubs for runtime
loaded library functionality.

> […] though I would prefer avoiding string mixins, maybe by providing a function type as prototype:
> 
> alias export extern(Windows) void function() fnWINAPI;
> 
> @functionAttributesOf!fnWINAPI HANDLE GetCurrentProcess();

That is too pragmatic for my taste. Something that you define in code should be usable as is. It is like taking the picture of a red corner sofa just to describe the color to someone.

In that specific case, why does this not work for you?:

nothrow extern(Windows) {
  HANDLE GetCurrentProcess();
}

-- 
Marco

Manu wrote:
> Whole program optimisation can't do anything to improve the situation; it
> is possible that DLL's may be loaded at runtime, so there's nothing the
> optimiser can do, even at link time.

Not really true. If you know the instance type then you can inline.

It is only when you call through the super class of the instance that you have to explicitly call a function through a pointer.

With a compiler switch or pragmas that tell the compiler what can be dynamically subclassed the compiler can assume all leaves in the compile time specialization hierarchies to be final.

Am Mon, 17 Mar 2014 04:37:10 +0000
schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang@gmail.com>:

> Manu wrote:
> > Whole program optimisation can't do anything to improve the
> > situation; it
> > is possible that DLL's may be loaded at runtime, so there's
> > nothing the
> > optimiser can do, even at link time.
> 
> Not really true. If you know the instance type then you can inline.
> 
> It is only when you call through the super class of the instance that you have to explicitly call a function through a pointer.

About two years ago we had that discussion and my opinion
remains that there are too many "if"s and "assume"s for the
compiler.
It is not so simple to trace back where an object originated
from when you call a method on it. It could be created though
the factory mechanism in Object using a runtime string or it
could have been passed through a delegate like this:

  window.onClick(myObject);

There are plenty of situations where it is virtually
impossible to know the instance type statically.
Whole program analysis only works on ... well, whole programs.
If you split off a library or two it doesn't work. E.g. you
have your math stuff in a library and in your main program
you write:

  Matrix m1, m2;
  m1.crossProduct(m2);

Inside crossProduct (which is in the math lib), the compiler could not statically verify if it is the Matrix class or a sub-class.

> With a compiler switch or pragmas that tell the compiler what can be dynamically subclassed the compiler can assume all leaves in the compile time specialization hierarchies to be final.

Can you explain, how this would work and where it is used?
  -nosubclasses=math.matrix.Matrix
would be the same as using this in the project, no?:
  final class FinalMatrix : Matrix {}

-- 
Marco

On 17 Mar 2014 00:05, "Walter Bright" <newshound2@digitalmars.com> wrote:
>
> On 3/16/2014 1:04 AM, Iain Buclaw wrote:
>>
>> Indeed other stuff needs to be done, it just so happens that thanks to sys.posix's bad design splitting out other modules into ports will be
more a
>> pain.  But it shows how *no one* in that thread who responded either
against the
>> first pull, or went off and hijacked the second had a Scooby about the
issue
>> being addressed.  Didn't even have the curiosity to give alternate
suggestions.
>
>
> The 731 pull added more files under the old package layout.
>

I acknowledged that in the original PR comments. I said it wasn't ideal before you commented. I had made a change after you commented to make things a little more ideal.  But came across problems as described in my previous message above when I tried to do the same with more modules.

No one really gave any feedback I could work with.  But 731 is the idea that people I've spoken to agree with (at least when they say separate files they make no reference to packaging it), and no one has contended it in 11666 either.  It just needs some direction when it comes to actually doing it, and I feel the two showstoppers are the sys.linux/sys.windows lark, and the absence of any configure in the build system.

> The 732 added more files to the config system, which I objected to.
>

Better than creating a new ports namespace.  But at least I toyed round the idea. It seems sound to move things to packages and have

version (X86)
  public import x86stuff;
version (ARM)
  public import armstuff;

But it just doesn't scale beyond a few files, and I think I showed that through the PR, and I'm satisfied that it didn't succeed and that became the logical conclusion.

Everyone in the conversation however never once used the words ARM, MIPS, PPC, X86... The strange fixation on the word POSIX had me scratching my head all the way through.

On 3/17/2014 12:23 AM, Iain Buclaw wrote:
> No one really gave any feedback I could work with.

I'll take the files you created and simply do it to show what it looks like. I infer I've completely failed at explaining it otherwise.

On 17 Mar 2014 01:25, "Walter Bright" <newshound2@digitalmars.com> wrote:
>
> On 3/15/2014 6:44 AM, Johannes Pfau wrote:
>>
>> Then in cairo.d
>> version(CAIRO_HAS_PNG_SUPPORT)
>> {
>>     extern(C) int cairo_save_png(char* x);
>>     void savePNG(string x){cairo_save_png(toStringz(x))};
>> }
>
>
> try adding:
>
>   else
>   {
>        void savePNG(string x) { }
>   }
>
> and then your users can just call savePNG without checking the version.

If I recall, he was saying that you must pass -fversion=CAIRO_HAS_PNG_SUPPORT to every file that imports it was the problem, because you want PNG support, not stubs.

It's more an example where you need a build system in place for a simple hello world in cairoD if you don't want to be typing too much just to get your test program built. :)

On 17 Mar 2014 07:40, "Walter Bright" <newshound2@digitalmars.com> wrote:
>
> On 3/17/2014 12:23 AM, Iain Buclaw wrote:
>>
>> No one really gave any feedback I could work with.
>
>
> I'll take the files you created and simply do it to show what it looks
like. I infer I've completely failed at explaining it otherwise.
>

If it's in any relation to your comments in the PR, my opinion is that they are irrelevant to to PR in question, but they *are* relevant in their own right and warrant a new bug/PR to be raised.

On 3/17/2014 12:39 AM, Iain Buclaw wrote:
> If I recall, he was saying that you must pass -fversion=CAIRO_HAS_PNG_SUPPORT to
> every file that imports it was the problem, because you want PNG support, not stubs.

Stub out the functions for PNG support. Then just call them, they will do nothing if PNG isn't supported. There is NO NEED for the callers to set version.


> It's more an example where you need a build system in place for a simple hello
> world in cairoD if you don't want to be typing too much just to get your test
> program built. :)

If you need to -fversion=CAIRO_HAS_PNG_SUPPORT for every file that imports it, you have completely misunderstood the design I suggested.

1. Encapsulate the feature in a function.

2. Implement the function in module X. Module X is the ONLY module that needs the version. In module X, define the function to do nothing if version is false.

3. Nobody who imports X has to define the version.

4. Just call the function as if the feature always exists.

5. If you find you still need a version in the importer, then you didn't fully encapsulate the feature. Go back to step 1.

On 17 March 2014 08:06, Walter Bright <newshound2@digitalmars.com> wrote:
> On 3/17/2014 12:39 AM, Iain Buclaw wrote:
>>
>> If I recall, he was saying that you must pass
>> -fversion=CAIRO_HAS_PNG_SUPPORT to
>> every file that imports it was the problem, because you want PNG support,
>> not stubs.
>
>
> Stub out the functions for PNG support. Then just call them, they will do nothing if PNG isn't supported. There is NO NEED for the callers to set version.
>
>
>
>> It's more an example where you need a build system in place for a simple
>> hello
>> world in cairoD if you don't want to be typing too much just to get your
>> test
>> program built. :)
>
>
> If you need to -fversion=CAIRO_HAS_PNG_SUPPORT for every file that imports it, you have completely misunderstood the design I suggested.
>
> 1. Encapsulate the feature in a function.
>
> 2. Implement the function in module X. Module X is the ONLY module that needs the version. In module X, define the function to do nothing if version is false.
>
> 3. Nobody who imports X has to define the version.
>
> 4. Just call the function as if the feature always exists.
>
> 5. If you find you still need a version in the importer, then you didn't fully encapsulate the feature. Go back to step 1.

Right, but going back full circle to the original comment:

"For example cairoD wraps the cairo C library. cairo can be compiled without or with PNG support. Historically cairoD used version(CAIRO_HAS_PNG_SUPPORT) for this."

Requires that cairoD have this encapsulation you suggest, but also requires detection in some form of configure system that checks:

1) Is cairo installed? (Mandatory, fails without)
2) Does the installed version of cairo have PNG suport (If true, set
build to compile a version of module X with
version=CAIRO_HAS_PNG_SUPPORT)