Re: Building with dub fails on Ubuntu 16.10.

2016-12-04 Thread Daniel Kozak via Digitalmars-d-learn

On Saturday, 3 December 2016 at 16:07:47 UTC, moe wrote:
On Sunday, 11 September 2016 at 02:17:21 UTC, Vlasov Roman 
wrote:

Hello, guys.
I tried to build HelloWorld with dub, but i got strange linker 
error:


[...]



I just switched from Windows to linux (arch) and got the exact 
same problem. Did you resolve this yet? I'm not very 
experienced with development on linux any hint here would be 
welcome.


On arch linux there should not be any issue. Archlinux does not 
use fPIC by default so, this error seems like you have something 
wrong with your Archlinux installation.


Re: How to use library compiled with Microsoft Visual Studio 2015 in D?

2016-12-04 Thread Jacob Carlborg via Digitalmars-d-learn

On 2016-12-05 07:44, unDEFER wrote:

Hello! I have compiled libdb (BerkeleyDB) with Microsoft Visual Studio
2015.
1) "Debug" mode. I have libdb53d.dll file. Do implib.
The linker doesn't seen symbols from the library! Do "lib -l". In the
list of symbols "db_create", linker searches "_db_create". Is it the
problem?
2) "Debug-Static" mode. I have libdb53d.lib file. Try to compile. linker
say that it has unsupported COFF format. Read about COFF2OMF, buy
extended utils to get it.
$ coff2omf libdb53d.lib
Segmentation Fault
Try like on page http://www.digitalmars.com/ctg/coff2omf.html:
$ link /lib /convert file.lib
LINK : warning LNK4044: unrecognized option '/convert'; ignored

So nothing works. How to use a library compiled with Microsoft Visual
Studio 2015 in D?


If you compile your D code with the "-m32mscoff" flag it will produce 
COFF objects and use the Visual Studio tool chain (linker and runtime). 
Compiling for 64bit (-m64) will always produce COFF objects.


--
/Jacob Carlborg


How to use library compiled with Microsoft Visual Studio 2015 in D?

2016-12-04 Thread unDEFER via Digitalmars-d-learn
Hello! I have compiled libdb (BerkeleyDB) with Microsoft Visual 
Studio 2015.

1) "Debug" mode. I have libdb53d.dll file. Do implib.
The linker doesn't seen symbols from the library! Do "lib -l". In 
the list of symbols "db_create", linker searches "_db_create". Is 
it the problem?
2) "Debug-Static" mode. I have libdb53d.lib file. Try to compile. 
linker say that it has unsupported COFF format. Read about 
COFF2OMF, buy extended utils to get it.

$ coff2omf libdb53d.lib
Segmentation Fault
Try like on page http://www.digitalmars.com/ctg/coff2omf.html:
$ link /lib /convert file.lib
LINK : warning LNK4044: unrecognized option '/convert'; ignored

So nothing works. How to use a library compiled with Microsoft 
Visual Studio 2015 in D?


Re: @property get/set or public varaible?

2016-12-04 Thread Jonathan M Davis via Digitalmars-d-learn
On Sunday, December 04, 2016 15:30:22 vladdeSV via Digitalmars-d-learn 
wrote:
> Hello!
>
> I have a question not directly related to D as it is with coding
> standards.
>
> My issue at hand is if I have one variable for a class, which I
> want to be directly accessible for anything else, should it be
>   1. public, or
>   2. private, with @property get/setters?
>
>  From what I have been told is that variables should be private.
> But if I do not want to make any checks whatsoever when setting a
> variable, I see no benefit to the private approach.
>
> Are there any other reasons to use get/setters?

The big reason to use getters and setters over public variables is that
converting public variables to property functions is _not_ seemless.
Property functions act like variables for some basic operations like
assignment, but you try and do much more than that, and they start behaving
drastically differently. For instance, what happens if someone takes the
address of a property? Or passes it by reference? As long as that property
is a member variable, it works like a variable, but if it's changed to a
property function, then those operations either have different types and
don't compile with existing code, or the operations don't work at all. Even
basic operations such as ++ don't work with property functions.

I'm sure that there are folks in the D community who favor using public
variables rather than property functions if they're not going to do anything
beyond getting or setting, but you're at serious risk of code breakage if
you do - especially if you're doing it in an API that you're distributing to
other people. For your own personal stuff or stuff that is internal to
whatever project you're doing where you can change all of the code that uses
the property, then it can work to use a public variable and then change the
code later if necessary if and when it becomes a property function. And
since most public variables don't get turned into property functions later,
you probabably will only have to deal with code breakage rarely, and it will
be easy for you to fix the few places where the property was used in a way
that works for a public variable but not for a property function. But if
you're distributing a library with a property that's a public variable, you
can't change all of the code using that property, and changing it to a
property function could easily break other people's code.

So, do what you want for internal stuff, but don't use public member
variables in libraries that you're distributing unless it's certain that
they will never be anything but public variables.

- Jonathan M Davis



Impressed with Appender - Is there design/implementation description?

2016-12-04 Thread Jon Degenhardt via Digitalmars-d-learn
I've been using Appender quite a bit recently, typically when I 
need append-only arrays with variable and unknown final sizes. I 
had been prepared to write a custom data structure when I started 
using it with large amounts of data, but very nicely this has not 
surfaced as a need. Appender has held up quite well.


I haven't actually benchmarked it against competing data 
structures, nor have I studied the implementation. I'd be very 
interested in understanding the design and how it compares to 
other data structures. Are there any write-ups or articles 
describing it?


--Jon


Re: @property get/set or public varaible?

2016-12-04 Thread ketmar via Digitalmars-d-learn

On Sunday, 4 December 2016 at 15:30:22 UTC, vladdeSV wrote:

Are there any other reasons to use get/setters?


basically, no. as you can omit parentheses in D, converting to 
getter/setter later should be seamless.


the only reason to have getter/setter in your case is a situation 
where you may want to override 'em in child class. so if you are 
using class hierarchy, take some time to think if you will ever 
need such overrides.


Re: @property get/set or public varaible?

2016-12-04 Thread angel via Digitalmars-d-learn

On Sunday, 4 December 2016 at 15:30:22 UTC, vladdeSV wrote:

Hello!

I have a question not directly related to D as it is with 
coding standards.


My issue at hand is if I have one variable for a class, which I 
want to be directly accessible for anything else, should it be

 1. public, or
 2. private, with @property get/setters?

From what I have been told is that variables should be private. 
But if I do not want to make any checks whatsoever when setting 
a variable, I see no benefit to the private approach.


Are there any other reasons to use get/setters?


Make the member variable public, if it serves your purpose.
If (and when) you feel like taking some control over setting and 
getting its value, you will upgrade it to @property 
setter/getter, making the actual member variable private.
For most reasonable use cases the upgrade should pass with no 
problems.

...
If you envision such an upgrade possibility, try to keep away 
from taking your member variable address, and other not 
method-friendly operations, that might hold the upgrade back.


@property get/set or public varaible?

2016-12-04 Thread vladdeSV via Digitalmars-d-learn

Hello!

I have a question not directly related to D as it is with coding 
standards.


My issue at hand is if I have one variable for a class, which I 
want to be directly accessible for anything else, should it be

 1. public, or
 2. private, with @property get/setters?

From what I have been told is that variables should be private. 
But if I do not want to make any checks whatsoever when setting a 
variable, I see no benefit to the private approach.


Are there any other reasons to use get/setters?


Re: How to get hash value of an object?

2016-12-04 Thread Era Scarecrow via Digitalmars-d-learn
On Tuesday, 29 November 2016 at 00:05:31 UTC, Steven 
Schveighoffer wrote:
hashOf is kind of this horrible hacky thing that nobody should 
be using. It literally takes whatever you pass it and hashes 
the local bytes.


 Ugg... Anything with pointers, classes or arrays will have huge 
problems with consistency; While anything with fixed static 
arrays or pure value-types will result in proper values.


 I'd almost prefer an option to get hashOf all inner object types 
and then xor them all together. Although this could make for a 
very complex hashOf depending on implementation of the object.



Long story short, use typeid(T).getHash().


 Hmmm maybe make any struct have hashOf disabled if it includes 
any pointers or dynamic arrays or inner objects that can't get a 
proper hash of it. While it will break things, at least you know 
what can't be hashed when you try to use it. Or maybe have that 
as a compiler option for those wanting to make use of that.


Re: Proper generic way to get the hash of something?

2016-12-04 Thread John C via Digitalmars-d-learn

On Sunday, 4 December 2016 at 06:51:24 UTC, Tofu Ninja wrote:

So what is the proper way to get the hash of something now?


This question came up a few days ago: 
http://forum.dlang.org/post/o1igoc$21ma$1...@digitalmars.com


Re: [Derelict-GL3] GLSL: Syntax error unexpected tokens following #version

2016-12-04 Thread Payotz via Digitalmars-d-learn

On Sunday, 4 December 2016 at 08:32:23 UTC, Mike Parker wrote:

On Sunday, 4 December 2016 at 08:30:40 UTC, Mike Parker wrote:


your shader, print out the result of glGetString(GL_VERSION) to


Alternatively, since you're using Derelict, you can check the 
return value of DerelictGL3.reload() or, any time after calling 
it, DerelictGL3.loadedVersion.


Actually, the fix was something anticlimactic. It had something 
to do with glShaderSource() and how I passed the arguments, it 
had nothing to do with the source code itself.

Thanks for the advice though. I'll be taking note of this.


Re: [Derelict-GL3] GLSL: Syntax error unexpected tokens following #version

2016-12-04 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 4 December 2016 at 08:30:40 UTC, Mike Parker wrote:


your shader, print out the result of glGetString(GL_VERSION) to


Alternatively, since you're using Derelict, you can check the 
return value of DerelictGL3.reload() or, any time after calling 
it, DerelictGL3.loadedVersion.


Re: [Derelict-GL3] GLSL: Syntax error unexpected tokens following #version

2016-12-04 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 4 December 2016 at 06:41:07 UTC, Payotz wrote:
So I've been trying to teach myself how to OpenGL, and there 
are errors whenever I try to compile my shaders.


Errors are : http://i.imgur.com/5hRaQL8.png


Why the screenshot? Simpler to respond to copy/pasted text.

The second line is a pretty strong hint:

"Version number not supported by GL2"

It seems you haven't created a GL30 context. Before loading your 
shader, print out the result of glGetString(GL_VERSION) to 
verify. Then make sure you create a GL3 context with whichever 
API you are using.




My shader code is as follows:
///
#version 130

attribute vec3 position;


`attribute` was deprecated in GLSL 1.3. Use `in` instead.