date:20140228


On Thursday, 27 February 2014 at 21:46:17 UTC, Simon Bürger wrote:
Sadly, this is incorrect as well. Because if such an object is 
collected by the gc, but the gc decides not to run the 
destructor, the buffer will never be free'd.


I think you misiterpret the spec. If object is collected, 
destructor is guaranteed to run. But not all objects are 
guaranteed to be collected. For example, no collection happens at 
program termination.


So it is OK to release resources in destructor that will be 
reclaimed by OS at program termination anyway. List of such 
resources is OS-specific but heap memory tends to be there.

Re: GC for noobs

On Thursday, 27 February 2014 at 18:29:57 UTC, Szymon Gatner 
wrote:
I dig flexibility, I really do, and I appreciate D's features 
that enable that, but in case of such basic thing as a resource 
management, I just want things to work without surprises by 
default.


Resource management (including memory management) is on of most 
complicated areas in programming. I can call it anything but 
basic.

Re: GC for noobs

2014-02-28 Thread Regan Heath

On Thu, 27 Feb 2014 18:29:55 -, Szymon Gatner noem...@gmail.com  
wrote:



On Thursday, 27 February 2014 at 18:06:58 UTC, John Colvin wrote:

On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner wrote:

On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:
There is also one complex and feature-reach implementation of  
uniqueness concept by Sonke Ludwig :  
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d#L281  
(Isolated!T)


Priceless for message passing concurrency.


Tbh it only looks worse and worse to me :(

Another example of code necessary to overcome language limitations.


Or, alternatively:

A language flexible enough to facilitate library solutions for problems  
that would normally require explicit language support.


I dig flexibility, I really do, and I appreciate D's features that  
enable that, but in case of such basic thing as a resource management, I  
just want things to work without surprises by default.


Amen.  (Not used religiously)

I have been around D for a long time, and I have noticed a growing trend  
of solving problems with clever but complicated library solutions when  
in *some* cases a simpler built-in solution was possible.  I realise  
Walter's time is precious and I realise that adding complexity to the  
language itself is something to be generally avoided, but I think  
sometimes we make the wrong choice.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: GC for noobs

On Friday, 28 February 2014 at 10:45:53 UTC, Regan Heath wrote:
On Thu, 27 Feb 2014 18:29:55 -, Szymon Gatner
noem...@gmail.com wrote:

On Thursday, 27 February 2014 at 18:06:58 UTC, John Colvin
wrote:
On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner
wrote:

On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:
There is also one complex and feature-reach implementation
of uniqueness concept by Sonke Ludwig :
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d#L281
(Isolated!T)

Priceless for message passing concurrency.

Tbh it only looks worse and worse to me :(

Another example of code necessary to overcome language
limitations.

Or, alternatively:

A language flexible enough to facilitate library solutions
for problems that would normally require explicit language
support.

I dig flexibility, I really do, and I appreciate D's features
that enable that, but in case of such basic thing as a
resource management, I just want things to work without
surprises by default.

Amen. (Not used religiously)

I have been around D for a long time, and I have noticed a
growing trend of solving problems with clever but complicated
library solutions when in *some* cases a simpler built-in
solution was possible. I realise Walter's time is precious and
I realise that adding complexity to the language itself is
something to be generally avoided, but I think sometimes we
make the wrong choice.

Yeah scope - scoped is IMO such a wrong choice. :)

Re: DMD Source Guidance: Unused Return Values of Strictly Pure Function Calls

2014-02-28 Thread Nordlöw


On Friday, 28 February 2014 at 10:40:04 UTC, bearophile wrote:

Nordlöw:

Did you set this as WONTFIX because of too many warnings from 
functions that may throw or just do asserts such as unittests?


It's a RESOLVED LATER. I think it was not me to tag it like 
that. And it was tagged like that because of too many warnings 
in templated functions.


Bye,
bearophile


My tested application is massive I got not false positives.

I can do some more tests...

/Per

Re: DMD Source Guidance: Unused Return Values of Strictly Pure Function Calls

2014-02-28 Thread Nordlöw

that. And it was tagged like that because of too many warnings 
in templated functions.


Were those warnings emitted also by non-void return functions?

/Per

Re: GC for noobs


On Friday, 28 February 2014 at 10:44:22 UTC, Dicebot wrote:
On Thursday, 27 February 2014 at 18:29:57 UTC, Szymon Gatner 
wrote:
I dig flexibility, I really do, and I appreciate D's features 
that enable that, but in case of such basic thing as a 
resource management, I just want things to work without 
surprises by default.


Resource management (including memory management) is on of most 
complicated areas in programming. I can call it anything but 
basic.


I didn't mean basic in the sense of easy but in the sense of 
something that has to dealt with all the time / is common 
requirement.


Programs == Algorithms + Data structures great man once said. D 
is pretty damn good at algorithms part, better than C++ thanks to 
ranges (zero cost composability codegen issues aside) but data 
strucutres... I wish I felt the same way about them.


Is it really so much to ask for? That child's finalizers are 
called before parent finalizer (assuming no circular refs, then 
again there are no weak class refst in D right)? Parent holds 
references to them for crying out loud... Why is that not the 
default and obvious behaviour? Is that a limitation imposed by GC 
somehow? My understanding is that GC has to scan from root to 
leaves so it knows the structure exactly anyway, why not just 
generate finalizer call list when traversing?

enum abuse

2014-02-28 Thread Mike


I recently saw the following line of code:

enum size = __traits(classInstanceSize, Foo);

Why enum?  Is this the equivalent of immutable auto or 
something?


Mike

Re: GC for noobs


On Friday, 28 February 2014 at 11:28:01 UTC, Szymon Gatner wrote:
I didn't mean basic in the sense of easy but in the sense 
of something that has to dealt with all the time / is common 
requirement.


Yes, it needs to be dealt with all the time but in a different 
ways. Problem is with getting sensible defaults. D makes a 
reasonable assumption that most applications don't actually care 
about tight bullet-proof resource management and defaults to GC. 
I may not like it but it fits criteria built-in resource 
management and pretty much shows that it is not as basic as one 
may think.


Programs == Algorithms + Data structures great man once said. 
D is pretty damn good at algorithms part, better than C++ 
thanks to ranges (zero cost composability codegen issues aside) 
but data strucutres... I wish I felt the same way about them.


Most problems I have with D data structures come from qualifiers, 
not from resource management. I really don't understand why this 
looks that much of a problem. That said, my background very 
influenced by plain C and that results in different habits and 
expectations.


Is that a limitation imposed by GC somehow? My understanding is 
that GC has to scan from root to leaves so it knows the 
structure exactly anyway, why not just generate finalizer call 
list when traversing?


Can't tell because of my very limited knowledge about GC 
internals. In practice I don't care because I never ever want to 
interfere with GC resource mangement -  stuff that I want to 
micro-managed is allocated from custom pools and thus is not a 
subject to unexpected destructor calls.

Re: enum abuse


On Friday, 28 February 2014 at 11:27:31 UTC, Mike wrote:

I recently saw the following line of code:

enum size = __traits(classInstanceSize, Foo);

Why enum?  Is this the equivalent of immutable auto or 
something?


Mike


enum creates compile-time placement constant. It does not create 
any symbol in resulting binary. Value of such enum gets pasted 
straight into the context when used.


Most similar thing in C terms would have been `#define size 
__traits(classInstanceSize, Foo)`, alas from preprocessor issues 
not present in D :)


It is idiomatic D way to force compile-time evaluation of 
expression.

Re: enum abuse

2014-02-28 Thread Vladimir Panteleev


On Friday, 28 February 2014 at 11:27:31 UTC, Mike wrote:

I recently saw the following line of code:

enum size = __traits(classInstanceSize, Foo);

Why enum?  Is this the equivalent of immutable auto or 
something?


A const or immutable declaration would declare a constant 
variable - meaning, unless it is optimized out at a later point, 
it will end up in the data segment and have its own address. An 
enum declares a manifest constant - it exists only in the memory 
of the compiler. Manifest constants make sense when doing 
metaprogramming. Constant/immutable declarations make sense for 
values that will be used in multiple places by code at runtime.

Re: GC for noobs


On 2/28/2014 8:43 PM, Dicebot wrote:



Most problems I have with D data structures come from qualifiers, not
from resource management. I really don't understand why this looks that
much of a problem. That said, my background very influenced by plain C
and that results in different habits and expectations.


I have a strong C background as well and have never had any complaints 
about resource management in D. Every complaint I've seen has come from 
people trying to do C++-like RAII. And, though I don't understand it 
either, it does seem to be a big issue for them.

Re: @disable this for structs


On Friday, 28 February 2014 at 01:16:41 UTC, Mike Parker wrote:
Ideally, I'd love for the compiler to pick up on this idiom and 
not generate any typeinfo in this situation.


Ideally one should use modules as namespaces :P

Re: undefined symbol: rt_finalize

2014-02-28 Thread Tolga Cakiroglu



http://dlang.org/dll-linux.html#dso7

dmd lib.d -shared -fPIC -debug -gc -g -w -wi 
-defaultlib=libphobos2.so


Problem about using shared libphobos is that I need to install 
many different libraries on the target computer. On the web 
server, I don't want to install DMD. I compiled before a DLL with 
libphobos2.so, and on web server it started asking many different 
libraries which made me unhappy.

Re: enum abuse

2014-02-28 Thread Mike


On Friday, 28 February 2014 at 11:47:35 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 11:27:31 UTC, Mike wrote:

I recently saw the following line of code:

enum size = __traits(classInstanceSize, Foo);

Why enum?  Is this the equivalent of immutable auto or 
something?


Mike


enum creates compile-time placement constant. It does not 
create any symbol in resulting binary. Value of such enum gets 
pasted straight into the context when used.


Most similar thing in C terms would have been `#define size 
__traits(classInstanceSize, Foo)`, alas from preprocessor 
issues not present in D :)


It is idiomatic D way to force compile-time evaluation of 
expression.


Damn good explanation.  I think I'll do a pull for this in the 
docs.  Thank you!

Re: Switching from Java to D: Beginner questions, multiplatform issues, etc.

2014-02-28 Thread Bienlein

This topic mentions IMHO an important point: D is not only
interesting for C++ people, but also for Java developers.
Companies that are happy with Java may have little incentive to
change to D or maybe Go. But when starting something new D can be
an alternative to Java as it also can be used for application
development to some extend (has a GC, fast build times and other
things that result in good productivity). Someone like me who has
spent his career with Smalltalk and Java and doesn't know a thing
about systems programming can get along with D quite easily.
Something like a D for Java developers user guide would make
sense IMHO.

D has better performance than Java and better productivity than
C++. Java is starting to get polluted with several things like
dependency on XML which really degrades productivity. I don't
spend my time looking for bugs in source code, but in XML
definition files (every framework has XML, some even allow you to
define logic in XML like Apache Camel). And this takes much more
time than when looking into code.

Then Java suffers from its threading model which is suitable for
general purpose programming, but not for web applications. For
WhatsApp a single machine holds over a million network
connections (see
https://www.erlang-solutions.com/about/news/erlang-powered-whatsapp-exceeds-200-million-monthly-users)
due to Erlang's threading model being able to get this
accomplished. In Go more than 100k network connections is also
not a problem (according to some tweet by Rob Pike). What seems
to attract people to Go is Go's threading model that is very well
suited for network programming and server-side web development.
But Go's language is simplistic and that probable won't change.
My impression is that this is on purpose. They want a modernized
C and that's it. So there is room for D here for server-side
development à la Go but with a high-level language. There is
really hell going on in Go's user forum. Multi-threading and
concurrency through goroutines as well as good libraries for
network programming seem to be the driving factors for Go.

D is really modelling power as well. That's the big win over Go.
No Java/EE architect will accept a language without inheritance
nor method overriding. I think there is no feature in Scala that
D doesn't have (except implicits, which is a good thing not to
have). On the contrary D has immutable types and pure functions.
Things that aren't possible in Scala due to limitations of the
JVM or need for interoperability.

-- Bienlein

Re: GC for noobs


On Friday, 28 February 2014 at 11:54:52 UTC, Mike Parker wrote:

On 2/28/2014 8:43 PM, Dicebot wrote:



Most problems I have with D data structures come from 
qualifiers, not
from resource management. I really don't understand why this 
looks that
much of a problem. That said, my background very influenced by 
plain C

and that results in different habits and expectations.


I have a strong C background as well and have never had any 
complaints about resource management in D. Every complaint I've 
seen has come from people trying to do C++-like RAII. And, 
though I don't understand it either, it does seem to be a big 
issue for them.


It really is, RAII is the most important idiom in C++, in short 
no RAII == buggy code. I mean proper C++ not 
C-with-classes-no-templates-no-exceptions bs.


So to sum up: C folks are not really happy, C++ folks are not 
really happy and C# folks are not really happy :P

Re: GC for noobs


On Friday, 28 February 2014 at 11:43:58 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 11:28:01 UTC, Szymon Gatner 
wrote:
I didn't mean basic in the sense of easy but in the sense 
of something that has to dealt with all the time / is common 
requirement.


Yes, it needs to be dealt with all the time but in a different 
ways. Problem is with getting sensible defaults. D makes a 
reasonable assumption that most applications don't actually 
care about tight bullet-proof resource management and defaults 
to GC. I may not like it but it fits criteria built-in 
resource management and pretty much shows that it is not as 
basic as one may think.




Not really different tho. Actual function call swqence might be 
different but the scheme is always the same: acquire resource, 
allocate, connect, take from pool vs release, deallocate, 
disconnect, return to pool. All of those fall under resource 
management - there is a finite amout of a resouce whether it is a 
memory, a system process, a file or a databese connection and it 
is crucial to the system stability that all of them are properly 
returned / released AND in proper order (which is of course 
reverse to acquisition).

Re: GC for noobs


On Friday, 28 February 2014 at 12:17:22 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 12:15:21 UTC, Szymon Gatner 
wrote:
It really is, RAII is the most important idiom in C++, in 
short no RAII == buggy code. I mean proper C++ not 
C-with-classes-no-templates-no-exceptions bs.


So to sum up: C folks are not really happy, C++ folks are not 
really happy and C# folks are not really happy :P


Repeating this again and again - you can use RAII. Just not 
with GC. It is importan idiom and it is supported. But it is 
not one true way so it is not supported for everything.


I know I can, my point is that it is more difficult and I don't 
like it ;)

Re: GC for noobs


On Friday, 28 February 2014 at 12:15:21 UTC, Szymon Gatner wrote:
It really is, RAII is the most important idiom in C++, in short 
no RAII == buggy code. I mean proper C++ not 
C-with-classes-no-templates-no-exceptions bs.


So to sum up: C folks are not really happy, C++ folks are not 
really happy and C# folks are not really happy :P


Repeating this again and again - you can use RAII. Just not with 
GC. It is importan idiom and it is supported. But it is not one 
true way so it is not supported for everything.

Re: custom memory management

2014-02-28 Thread Simon Bürger


On Friday, 28 February 2014 at 10:40:17 UTC, Dicebot wrote:
On Thursday, 27 February 2014 at 21:46:17 UTC, Simon Bürger 
wrote:
Sadly, this is incorrect as well. Because if such an object is 
collected by the gc, but the gc decides not to run the 
destructor, the buffer will never be free'd.


I think you misiterpret the spec. If object is collected, 
destructor is guaranteed to run. But not all objects are 
guaranteed to be collected. For example, no collection happens 
at program termination.


So it is OK to release resources in destructor that will be 
reclaimed by OS at program termination anyway. List of such 
resources is OS-specific but heap memory tends to be there.


If you are right that would mean that the current dmd/runtime 
does not follow the spec. Curious. The current implementation is 
not aware of strcut-destructors on the heap, i.e. the 
GC.BlkAttr.FINALIZE flag is not set for structs (or arrays of 
structs).


In the struct-inside-a-class example, the struct destructor is 
called by the (automatically generated) class-destructor. The gc 
only knows about class-destrcutor and calls only that one 
directly.

Re: GC for noobs


On Friday, 28 February 2014 at 12:48:47 UTC, Mike Parker wrote:

On 2/28/2014 9:15 PM, Szymon Gatner wrote:



So to sum up: C folks are not really happy, C++ folks are not 
really

happy and C# folks are not really happy :P


I'm a C folk and I'm really happy :)


C'mon, GC has to be an itch for you mallocers :)

Come to the dark side...

Re: @disable this for structs

2014-02-28 Thread Remo


On Friday, 28 February 2014 at 11:59:40 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 01:16:41 UTC, Mike Parker wrote:
Ideally, I'd love for the compiler to pick up on this idiom 
and not generate any typeinfo in this situation.


Ideally one should use modules as namespaces :P


Ideally D should have build in namespaces.

Using class to mimic namespace, but then all the functions are 
virtual per default ?

Re: custom memory management


On Friday, 28 February 2014 at 12:36:48 UTC, Simon Bürger wrote:
If you are right that would mean that the current dmd/runtime 
does not follow the spec. Curious. The current implementation 
is not aware of strcut-destructors on the heap, i.e. the 
GC.BlkAttr.FINALIZE flag is not set for structs (or arrays of 
structs).


Ah, structs are a bit tricky. Spec has override for struct 
destructors that says explicitly Destructors are called when an 
object goes out of scope so one can argue heap ignorance matches 
it. But the very next line contradicts it : Their purpose is to 
free up resources owned by the struct object.


I believe it is a DMD bug though. There is no reason why 
destructors can't be run here. Most likely it is just defect of 
current GC implementation that everyone got used to.


This bug report discussion confirms it : 
https://d.puremagic.com/issues/show_bug.cgi?id=2834


Looks like decision was to fix it once precise GC gets added.

In the struct-inside-a-class example, the struct destructor is 
called by the (automatically generated) class-destructor. The 
gc only knows about class-destructor and calls only that one 
directly.


Yes, that matches my current observations. Did not occure before 
because of C coding habits :) Lucky me.

Re: @disable this for structs

2014-02-28 Thread Tobias Pankrath


On Friday, 28 February 2014 at 12:52:38 UTC, Remo wrote:

On Friday, 28 February 2014 at 11:59:40 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 01:16:41 UTC, Mike Parker wrote:
Ideally, I'd love for the compiler to pick up on this idiom 
and not generate any typeinfo in this situation.


Ideally one should use modules as namespaces :P


Ideally D should have build in namespaces.


Why? C like tag namespaces are awful and do C++ like namespaces 
offer any benefit over modules? Keep in mind that we have no 
Koenig lookup.

Re: GC for noobs


On 2/28/2014 9:15 PM, Szymon Gatner wrote:



So to sum up: C folks are not really happy, C++ folks are not really
happy and C# folks are not really happy :P


I'm a C folk and I'm really happy :)

Re: custom memory management


On Friday, 28 February 2014 at 13:06:05 UTC, Namespace wrote:
What can still take a long time. It annoys me very much that 
with arrays I can not rely on that the struct DTors are called.


Yep, this bug has immediately got my vote :) It does require 
someone knowledgable of GC to fix in forseeable future 
unfortunately.

Re: custom memory management


On Friday, 28 February 2014 at 12:54:32 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 12:36:48 UTC, Simon Bürger wrote:
If you are right that would mean that the current dmd/runtime 
does not follow the spec. Curious. The current implementation 
is not aware of strcut-destructors on the heap, i.e. the 
GC.BlkAttr.FINALIZE flag is not set for structs (or arrays of 
structs).


Ah, structs are a bit tricky. Spec has override for struct 
destructors that says explicitly Destructors are called when 
an object goes out of scope so one can argue heap ignorance 
matches it. But the very next line contradicts it : Their 
purpose is to free up resources owned by the struct object.


I believe it is a DMD bug though. There is no reason why 
destructors can't be run here. Most likely it is just defect of 
current GC implementation that everyone got used to.


This bug report discussion confirms it : 
https://d.puremagic.com/issues/show_bug.cgi?id=2834


Looks like decision was to fix it once precise GC gets added.


What can still take a long time. It annoys me very much that with 
arrays I can not rely on that the struct DTors are called.

Re: GC for noobs


On Friday, 28 February 2014 at 12:52:28 UTC, Szymon Gatner wrote:

I'm a C folk and I'm really happy :)


+1


C'mon, GC has to be an itch for you mallocers :)

Come to the dark side...


It sometimes is. In that case we don't use GC.

Don't get me wrong - there are issues with current GC enforcement
and it is a major problem for real-time applications, there are
lot of threads with debates on topic (with me acting on
against-the-GC side). But it is a very small subset of
applications most programmers will never even write once in their
life, for everything else existing tools are pretty good.

I really think it is more of C++ architectural habit that itches
you right now :)

Re: custom memory management


On Friday, 28 February 2014 at 13:32:33 UTC, Namespace wrote:
I will vote, too. It's somewhat strange: Since it works with 
delete it should also work with the current GC, or? Someone 
should figure out why and how delete works this way. :)


Well, delete is deprecated so it can do any kind of arcane 
horrors :)


More idiomatic destroy + GC.free pair will work because destroy 
is a template function.

Re: @disable this for structs

2014-02-28 Thread Remo


On Friday, 28 February 2014 at 13:23:51 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 12:52:38 UTC, Remo wrote:

On Friday, 28 February 2014 at 11:59:40 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 01:16:41 UTC, Mike Parker 
wrote:
Ideally, I'd love for the compiler to pick up on this idiom 
and not generate any typeinfo in this situation.


Ideally one should use modules as namespaces :P


Ideally D should have build in namespaces.

Using class to mimic namespace, but then all the functions are 
virtual per default ?


No. By design namespace is a module. You don't use classes for 
namespaces, you create more modules. One may not like it but it 
is how D module system was created and it was intentional.


Right now I do not really miss namespacec in D.
I like modules in D.
What I hate already are problems with structs and ctors.
Most time while porting C++ code to D I spend a lot of time to 
resolve all the problems that happens because of struct ctors.
If I forget to do this then it still compiles but does not work 
at all...

Re: @disable this for structs


On Friday, 28 February 2014 at 13:32:13 UTC, Remo wrote:

What I hate already are problems with structs and ctors.
Most time while porting C++ code to D I spend a lot of time to 
resolve all the problems that happens because of struct ctors.
If I forget to do this then it still compiles but does not work 
at all...


It is a long-standing bug and I am sorry for that. See 
http://forum.dlang.org/post/wziedbjjmxvabubva...@forum.dlang.org

Re: @disable this for structs


On 2/28/2014 10:21 PM, Dicebot wrote:


D design is based on module as smallest composition unit. If you find
yourself in situation where you want to have two namespaces in a single
module, you should split it into two modules.


Consider this.

enum Foo {...}

interface Bar {}

struct BarManager {
   public static {
  void initialize();
  void terminate();
  ... more stuff
   }
}

This is my use-case. I don't want my users to have to refer to Foo or 
Bar with any sort of prefix except to avoid name-clashes. However, I 
want to logically group the functions to manage Bars under a single 
grouping. I don't need or want a Singleton for it. I could use free 
functions, but I use the initialize/terminate idiom a lot. As a user of 
my own library, it would be horribly annoying to have to fully qualify 
each call. Plus, now and again I have multiple namespace structs in a 
single module. If I see them as all being closely related, why should I 
split them off into different modules?





Putting impetus on caller (named imports) is good here and huge
advantage over C++ way in my opinion. It gives more control over
application naming scheme.


On the other hand, by wrapping my namespaced stuff in structs or
classes, I can have multiple namespaces per module, some things
completely outside the namespace, and the user gets a compiler error
if they don't use it. To me, that's much, much neater.


It simply does not fit with D type system, most importantly with
accessiblity attributes. I'd hate to encounter all that you mention as
benefits in some D library I am forced to use.


One of the most annoying things for me in C++ is to see something like 
some::ridiculously::long::namespace, that I then have to use on each 
type declared in that namespace. That makes me add using statements to 
the top of each module, which defeats the purpose in the first place. I 
would find it equally annoying in D if every module I imported required 
me to use a fully-qualified module name. Luckily, that isn't the case. 
We only need to do it do avoid conflicts.


My purpose for using namespaces in this way is twofold: to indicate that 
those particular functions serve a collective purpose, and to make give 
more meaning to the user code. I don't need to worry about naming 
conflicts, thanks to the module system, but I don't see the module as 
the smallest unit of organization.

Re: @disable this for structs


On Friday, 28 February 2014 at 12:52:38 UTC, Remo wrote:

On Friday, 28 February 2014 at 11:59:40 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 01:16:41 UTC, Mike Parker wrote:
Ideally, I'd love for the compiler to pick up on this idiom 
and not generate any typeinfo in this situation.


Ideally one should use modules as namespaces :P


Ideally D should have build in namespaces.

Using class to mimic namespace, but then all the functions are 
virtual per default ?


No. By design namespace is a module. You don't use classes for 
namespaces, you create more modules. One may not like it but it 
is how D module system was created and it was intentional.

Re: @disable this for structs


On Friday, 28 February 2014 at 12:59:32 UTC, Mike Parker wrote:

Ideally one should use modules as namespaces :P


I don't buy that. That works fine to resolve conflicts, but it 
doesn't work for fine-grained namespace management. And when 
using named imports, that means everything in the module then 
belongs to that namespace, which isn't at all what I want. 
Besides which, using either fully-qualified names or named 
imports puts the impetus on the caller. If I design my modules 
around namespaces with the understanding that the caller will 
type foo.bar.myfunc all the time, there are bound to be 
conflicts when they forget to do it.


D design is based on module as smallest composition unit. If you 
find yourself in situation where you want to have two namespaces 
in a single module, you should split it into two modules.


Putting impetus on caller (named imports) is good here and huge 
advantage over C++ way in my opinion. It gives more control over 
application naming scheme.


On the other hand, by wrapping my namespaced stuff in structs 
or classes, I can have multiple namespaces per module, some 
things completely outside the namespace, and the user gets a 
compiler error if they don't use it. To me, that's much, much 
neater.


It simply does not fit with D type system, most importantly with 
accessiblity attributes. I'd hate to encounter all that you 
mention as benefits in some D library I am forced to use.

Re: custom memory management


On Friday, 28 February 2014 at 13:16:40 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 13:06:05 UTC, Namespace wrote:
What can still take a long time. It annoys me very much that 
with arrays I can not rely on that the struct DTors are called.


Yep, this bug has immediately got my vote :) It does require 
someone knowledgable of GC to fix in forseeable future 
unfortunately.


I will vote, too. It's somewhat strange: Since it works with 
delete it should also work with the current GC, or? Someone 
should figure out why and how delete works this way. :)

Re: @disable this for structs


On 2/28/2014 8:59 PM, Dicebot wrote:

On Friday, 28 February 2014 at 01:16:41 UTC, Mike Parker wrote:

Ideally, I'd love for the compiler to pick up on this idiom and not
generate any typeinfo in this situation.


Ideally one should use modules as namespaces :P


I don't buy that. That works fine to resolve conflicts, but it doesn't 
work for fine-grained namespace management. And when using named 
imports, that means everything in the module then belongs to that 
namespace, which isn't at all what I want. Besides which, using either 
fully-qualified names or named imports puts the impetus on the caller. 
If I design my modules around namespaces with the understanding that the 
caller will type foo.bar.myfunc all the time, there are bound to be 
conflicts when they forget to do it.


On the other hand, by wrapping my namespaced stuff in structs or 
classes, I can have multiple namespaces per module, some things 
completely outside the namespace, and the user gets a compiler error if 
they don't use it. To me, that's much, much neater.

Re: custom memory management


On Friday, 28 February 2014 at 13:38:59 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 13:32:33 UTC, Namespace wrote:
I will vote, too. It's somewhat strange: Since it works with 
delete it should also work with the current GC, or? Someone 
should figure out why and how delete works this way. :)


Well, delete is deprecated so it can do any kind of arcane 
horrors :)


More idiomatic destroy + GC.free pair will work because destroy 
is a template function.


No, currently it is not deprecated. It is suggested to be 
deprecated. :P
And destroy doesn't finalize the data. :/ See: 
http://forum.dlang.org/thread/bug-1225...@https.d.puremagic.com%2Fissues%2F 
and 
http://forum.dlang.org/thread/bug-1227...@https.d.puremagic.com%2Fissues%2F
But that is only a workaround. I don't want to call every time 
arr.finalize because the GC is silly...
I meant that someone should analyse the internal delete code and 
implement something like this for the current GC related to 
struct arrays (and AA's).

Write variable from other function

I continue attempted to become a programmer, but I have small 
problem. I can't understand how to write/change variable from one 
function by code in another.

http://www.everfall.com/paste/id.php?nqq61th5loq3

writeln(configpath);  // I need write this one! -- this string

I remember (if I now mistake) that there is way to get access to 
vars from other class in way like MyClass2.var = 2 but probably I 
am wrong

Re: Colons and brackets


On Friday, 28 February 2014 at 04:31:03 UTC, evilrat wrote:
On Friday, 28 February 2014 at 04:19:47 UTC, Etienne Cimon 
wrote:

Hi all,

I'm a little perplexed b/c I can't seem to find anything that 
could tell me where this ends:


version(something):
code
code
code
\eof

How do you stop statements from belonging to the specific 
version of code without using brackets?


Thanks!


add version(all): after code where specific version ends.


nope

Re: Write variable from other function

2014-02-28 Thread bearophile


Suliman:


I continue attempted to become a programmer,


While D is good enough language, but D is large, so I think it's 
not the best as first language :-)



I can't understand how to write/change variable from one 
function by code in another.


In general you can't, and even if you find ways to do it, it's 
not a good idea.


A simple solution is to define a struct (or a class), with a 
member variable that you can change as you wish.




http://www.everfall.com/paste/id.php?nqq61th5loq3


D language is too much lax to accept 0/1 as bools, but in general 
it's quite better to use true/false literals.

And functions in D start with a lower case letter.

Bye,
bearophile

Re: @disable this for structs


On Friday, 28 February 2014 at 13:42:21 UTC, Mike Parker wrote:

Consider this.

enum Foo {...}

interface Bar {}

struct BarManager {
   public static {
  void initialize();
  void terminate();
  ... more stuff
   }
}

This is my use-case. I don't want my users to have to refer to 
Foo or Bar with any sort of prefix except to avoid 
name-clashes. However, I want to logically group the functions 
to manage Bars under a single grouping. I don't need or want a 
Singleton for it. I could use free functions, but I use the 
initialize/terminate idiom a lot. As a user of my own library, 
it would be horribly annoying to have to fully qualify each 
call. Plus, now and again I have multiple namespace structs 
in a single module. If I see them as all being closely related, 
why should I split them off into different modules?


I'd write it this way:

=== something/bar.d ===

interface Bar {}

=== something/barmanager.d ===

import something.bar; // possibly public import

void initialize();
void terminate();

=== app.d ===

import something.bar;
import barmanager = something.barmanager;

// refer to Bar directly and to init function via 
barmanager.initialize()

=

Or, even better, turn bar into package and have 
something.bar.manager with same usage pattern.

Re: Write variable from other function


On Friday, 28 February 2014 at 14:15:17 UTC, Suliman wrote:
I remember (if I now mistake) that there is way to get access 
to vars from other class in way like MyClass2.var = 2 but 
probably I am wrong


You want static variables, either in form of global variables 
(discouraged) or static class fields:


class MyClass
{
static int var; // note static!
}

You can't access local variables of other functions because they 
are, well, local.

Re: custom memory management


On Friday, 28 February 2014 at 14:08:11 UTC, Namespace wrote:
No, currently it is not deprecated. It is suggested to be 
deprecated. :P
And destroy doesn't finalize the data. :/ See: 
http://forum.dlang.org/thread/bug-1225...@https.d.puremagic.com%2Fissues%2F 
and 
http://forum.dlang.org/thread/bug-1227...@https.d.puremagic.com%2Fissues%2F
But that is only a workaround. I don't want to call every time 
arr.finalize because the GC is silly...


intended to be deprecated is a better word. There is not a 
smallest chance it will stay in the long term, better get used to 
it.


Quick solution would have been to merge finalize with destroy 
itself. As I have mentioned, it is a template and has all 
necessary information for traversal.


Proper solution will be to fix the struct destructor bug as it is 
the root cause for your array issues too and then patch destroy 
to only do traversal when pointers are not owned by GC.


I meant that someone should analyse the internal delete code 
and implement something like this for the current GC related to 
struct arrays (and AA's).


I am too scared of what I may find :)

Re: custom memory management


On Friday, 28 February 2014 at 14:47:31 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 14:08:11 UTC, Namespace wrote:
No, currently it is not deprecated. It is suggested to be 
deprecated. :P
And destroy doesn't finalize the data. :/ See: 
http://forum.dlang.org/thread/bug-1225...@https.d.puremagic.com%2Fissues%2F 
and 
http://forum.dlang.org/thread/bug-1227...@https.d.puremagic.com%2Fissues%2F
But that is only a workaround. I don't want to call every time 
arr.finalize because the GC is silly...


intended to be deprecated is a better word. There is not a 
smallest chance it will stay in the long term, better get used 
to it.


Quick solution would have been to merge finalize with destroy 
itself. As I have mentioned, it is a template and has all 
necessary information for traversal.


Proper solution will be to fix the struct destructor bug as it 
is the root cause for your array issues too and then patch 
destroy to only do traversal when pointers are not owned by GC.
I'm not sure if that is possible with the current gc. But I hope 
it!
I meant that someone should analyse the internal delete code 
and implement something like this for the current GC related 
to struct arrays (and AA's).


I am too scared of what I may find :)

Re: Write variable from other function

2014-02-28 Thread Jesse Phillips


On Friday, 28 February 2014 at 14:15:17 UTC, Suliman wrote:
I continue attempted to become a programmer, but I have small 
problem. I can't understand how to write/change variable from 
one function by code in another.

http://www.everfall.com/paste/id.php?nqq61th5loq3

writeln(configpath);  // I need write this one! -- this string

I remember (if I now mistake) that there is way to get access 
to vars from other class in way like MyClass2.var = 2 but 
probably I am wrong


You can not access/read/write a variable of another function.


import std.path : buildPath;
auto configpath = buildPath(getcwd(), config.txt);
if (!isConfigExist(configpath))
{
writeln(config do not exists);
writeln(configpath);  // I need write this one!

Re: @disable this for structs


On 2/28/2014 11:37 PM, Dicebot wrote:



I'd write it this way:

=== something/bar.d ===

interface Bar {}

=== something/barmanager.d ===

import something.bar; // possibly public import

void initialize();
void terminate();

=== app.d ===

import something.bar;
import barmanager = something.barmanager;

// refer to Bar directly and to init function via barmanager.initialize()
=

Or, even better, turn bar into package and have something.bar.manager
with same usage pattern.


And as a user of your library, I'm going to be extremely annoyed that I 
have to keep remembering to declare named imports to disambiguate all 
the intialize/terminate functions in all the modules that have them. If 
you're going to design your library that way, you should do it for me :)


I see modules, loosely, as a way to group immediate family and packages 
as a way to group extended family. To me, Bar and BarManager are closely 
related, so they belong in the same module. It also makes long-term 
maintenance simpler, since everything related to Bar is in one place. 
And then there's D's module-scope access to private methods/members, 
which at some level encourages this approach (and which I make good use 
of). If I were to break all of my modules up as you have in this 
example, it unnecessarily inflates the number of modules, increases the 
maintenance cost somewhat, and takes away my module access to private.


Anyway, I have a project I'm working on right now that I'll be putting 
up on github within a few weeks that serves as a more complete example. 
One of the great things about D is that it has enough room for both 
approaches.

Re: Write variable from other function


Oh thanks! I had forgot that I should declarate it's in class.
But what about return type? Look like that DMD want that I 
declarate some bool value in constructor. It's get me next error: 
Error: need 'this' for 'isConfigExist' of type 'bool()'


http://www.everfall.com/paste/id.php?qs2lsozrd3k7

Re: @disable this for structs

One feature I miss is partial static import - one that 
essentially automates `import modname = packname.modname`, 
allowing to qualify by module name only. That could have removed 
some repeating boilerplate from my code.

Re: Write variable from other function


On Friday, 28 February 2014 at 15:59:41 UTC, Suliman wrote:

Oh thanks! I had forgot that I should declarate it's in class.
But what about return type? Look like that DMD want that I 
declarate some bool value in constructor. It's get me next 
error: Error: need 'this' for 'isConfigExist' of type 'bool()'


http://www.everfall.com/paste/id.php?qs2lsozrd3k7


Methods that can be called without any specific instance (this) 
must be declared static too.


'Config` defines a class, which is a type. Normally you want to 
create an instance of the type (object of the class) before using 
it and each object has new set of variables.


When you declare variable static it makes it shared between all 
instances of that class, allowing to use it without any specific 
instance. When you declare method as static you say to compiler 
that it is not going to use any non-static fields of the class 
(normally available via this pointer) and make it possible to 
call it as `Config.method`.

Re: Write variable from other function

When you declare variable static it makes it shared between all 
instances of that class, allowing to use it without any 
specific instance. When you declare method as static you say to 
compiler that it is not going to use any non-static fields of 
the class (normally available via this pointer) and make it 
possible to call it as `Config.method`.


Thanks! I know about static, but now I need experience to work 
with class constructor. So now I can't understand what I can do 
with error: Error: need 'this' for 'isConfigExist' of type 
'bool()'

Re: Write variable from other function


On Friday, 28 February 2014 at 16:16:36 UTC, Suliman wrote:
Thanks! I know about static, but now I need experience to work 
with class constructor. So now I can't understand what I can do 
with error: Error: need 'this' for 'isConfigExist' of type 
'bool()'


Most likely you don't create an instance. This works:

http://dpaste.dzfl.pl/7c6ada9056ea

Re: Write variable from other function


On 3/1/2014 1:16 AM, Suliman wrote:

When you declare variable static it makes it shared between all
instances of that class, allowing to use it without any specific
instance. When you declare method as static you say to compiler that
it is not going to use any non-static fields of the class (normally
available via this pointer) and make it possible to call it as
`Config.method`.


Thanks! I know about static, but now I need experience to work with
class constructor. So now I can't understand what I can do with error:
Error: need 'this' for 'isConfigExist' of type 'bool()'


Here, 'this' is not referring to a constructor, but to an instance of 
the class. It means you are trying to call isConfigExist but haven't 
created an instance of Config yet.


auto config = new Config( exepath, configPath );
writeln( config.isConfigExist() );

Re: enum abuse

2014-02-28 Thread Gary Willoughby


On Friday, 28 February 2014 at 12:12:34 UTC, Mike wrote:
Damn good explanation.  I think I'll do a pull for this in the 
docs.  Thank you!


It's mentioned here right at the bottom 
http://dlang.org/enum.html which could do with fleshing out a bit.

Re: Switching from Java to D: Beginner questions, multiplatform issues, etc.

2014-02-28 Thread Jesse Phillips


On Friday, 28 February 2014 at 12:10:17 UTC, Bienlein wrote:
This topic mentions IMHO an important point: D is not only 
interesting for C++ people, but also for Java developers. 
Companies that are happy with Java may have little incentive to 
change to D or maybe Go. But when starting something new D can 
be an alternative to Java as it also can be used for 
application development to some extend (has a GC, fast build 
times and other things that result in good productivity). 
Someone like me who has spent his career with Smalltalk and 
Java and doesn't know a thing about systems programming can get 
along with D quite easily. Something like a D for Java 
developers user guide would make sense IMHO.


Well, not exactly what you are after. But there have been Java 
related guides, which could use some updating and moving to the 
new wiki:


http://wiki.dlang.org/Coming_From/Java

http://www.prowiki.org/wiki4d/wiki.cgi?ComingFrom/Java
http://www.prowiki.org/wiki4d/wiki.cgi?JavaToD

Re: Dynamically calling external libraries.

2014-02-28 Thread Setra

Marc would you be willing to post your compile script? Or did you 
just use what the wiki said to?

How to return range constructs?


Hiho,

for experimental and learning reasons I am working on a simple 
matrix library for D. And since ranges seem to be a cool feature 
of the D language I am currently trying to understand them and 
use them more in my codes.


So I thought that it would be a nice feature if I could create 
methods to return specific ranges for certain matrix instances, 
e.g. something like getRowRange(size_t row) or 
getColumnRange(size_t col) which returns a range to easily 
iterate through a single row- or column vector of a matrix 
instance with a simple foreach loop.


I store the matrix data within a single dimensional array for 
performance purposes instead of a jagged array:


private
{
T[] data;
Dimension dim;
}

The Dimension 'dim' is an object holding the number of rows and 
columns as well as some handy methods and properties such as 
isSquare etc.


So my question is: How to define such a method which returns a 
range for a single row or column vector? The range should be 
modifiable depending on whether the matrix instance is 
const/immutable or not. Or isn't that possible at all? I thought 
that it could be tricky for row vectors since their data wouldn't 
be dense in memory.


I've looked into the std.range documentation but doesn't seem to 
get a clue how to get this working. And if it works - what range 
type would fit best for my purposes - or do I need to create a 
sub-class of a certain range type specially fit for my matrix?


My try so far:

module neoLab.core.ColumnVectorRange;

import std.range;
import neoLab.core.Matrix;

final class ColumnVectorRange(T) : RandomAccessFinite!T {
private
{
T[] data;
size_t cur = 0;
size_t length = 0;
}

this(const ref Matrix m, size_t row)
in
{
assert(row  m.getDimension().rows, Row index is invalid.);
}
body
{
this.data = m.data;
this.length = m.getDimension().cols;
}

ColumnVectorRange!T save() {
// What does this do?
}

override T opIndex(size_t index) {
return this.data[index]; // this correct?
}

override T moveAt(size_t index) {
return this.data[this.cur]; // this good?
}

override size_t length() {
return this.length;
}

override alias opDollar = this.length; // Is this nessecary?

override ColumnVectorRange!E opSlice(size_t, size_t) {
// What does this do in particular?
}
}

I highly appreciate tips and answers! =)

Thanks in advance.

Robin

Re: Dynamically calling external libraries.

2014-02-28 Thread Marc Schütz


On Friday, 28 February 2014 at 16:44:02 UTC, Setra wrote:
Marc would you be willing to post your compile script? Or did 
you just use what the wiki said to?


I used exactly what I quoted in my post:

dmd main1.d -L-ldl
dmd -c dll.d -fPIC
dmd -oflibdll.so dll.o -shared -defaultlib=
LD_LIBRARY_PATH=. ./main1

But what you just wrote works correctly, too.

Are you sure you're actually using the correct object files? I.e. 
try deleting all output files first. Sometimes it's really 
trivialities like this :-)


Or it's an architectural problem? I'm on x86_64, maybe you're 
compiling 32bit code (although of course that should work, but 
you can never know)?


Which version of DMD are you using?

Otherwise you could try disassembling things or single-step 
through the call with a debugger.


But maybe someone else knows something better?

Re: How to return range constructs?


Looks like you are over-complicating things:

http://dpaste.dzfl.pl/eaca1408dc88

import std.range;

struct ColumnVectorForwardRange(T)
{
private
{
T[] data;
size_t cur = 0;
size_t length = 0;
}

ColumnVectorForwardRange!T save() @property {
return this;
}

bool empty() @property {
return !length;
}

T front() @property {
return data[cur];
}

void popFront() {
++cur;
--length;
}
}

static assert(isForwardRange!(ColumnVectorForwardRange!int));

void main() {}

Re: enum abuse

2014-02-28 Thread Mike

On Friday, 28 February 2014 at 16:32:32 UTC, Gary Willoughby 
wrote:

On Friday, 28 February 2014 at 12:12:34 UTC, Mike wrote:
Damn good explanation.  I think I'll do a pull for this in the 
docs.  Thank you!


It's mentioned here right at the bottom 
http://dlang.org/enum.html which could do with fleshing out a 
bit.


I read that before posting my question.  It didn't help my 
understanding.  That's why I think I'll add Dicebot's 
explanation, as it is far better.

Re: Dynamically calling external libraries.

2014-02-28 Thread Setra


I am using  dmd_2.065.0-0_i386.deb on a 32 bit machine.

Re: Dynamically calling external libraries.

2014-02-28 Thread Tolga Cakiroglu


On Friday, 28 February 2014 at 17:29:09 UTC, Setra wrote:

I am using  dmd_2.065.0-0_i386.deb on a 32 bit machine.


Hi Setra,

I am trying to make external libraries work as well, but having 
problems continuously. Could you test that following function in 
your library and call it from main programme. I am having 
Segmentation Fault with it, and wondering if other people has 
the same thing.


class A{
public this(){
writeln(Created);
}
}

extern(C) void foo(){
Object obj = new Object();

A objA = new A();

char[] c = new char[ 1024 ];
}

Re: Dynamically calling external libraries.

2014-02-28 Thread Marc Schütz


On Friday, 28 February 2014 at 18:05:13 UTC, Marc Schütz wrote:

On Friday, 28 February 2014 at 17:29:09 UTC, Setra wrote:

I am using  dmd_2.065.0-0_i386.deb on a 32 bit machine.


Ah, I can reproduce it with 32bit executables:

# dmd -m32 main1.d -L-ldl
# dmd -m32 -c dll.d -fPIC
# dmd -m32 -oflibdll.so dll.o -shared -defaultlib=
# LD_LIBRARY_PATH=. ./main1
+main()
libdll.so is loaded
dll() function is found
dll()
134684056
unloading libdll.so
-main()
# file ./main1
./main1: ELF 32-bit LSB executable, Intel 80386, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 
2.6.16, BuildID[sha1]=a0eb9b8af3a95d0c4fddd2daf7a476aabed4b53e, 
not stripped


Might be a compiler bug...


No, it isn't. The problem is here:
int function(int x) fn = cast(int function(int x))dlsym(lh, 
dll);


This should be:
extern(C) int function(int x) fn = cast(int function(int 
x))dlsym(lh, dll);


The calling conventions for C and D are different on x86, but 
happen to agree on x86_64 (at least the parts that are relevant 
here).


Btw, the forward declaration on top extern (C) int dll(); isn't 
used anywhere.

Re: Write variable from other function


On Friday, 28 February 2014 at 16:26:17 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 16:16:36 UTC, Suliman wrote:
Thanks! I know about static, but now I need experience to work 
with class constructor. So now I can't understand what I can 
do with error: Error: need 'this' for 'isConfigExist' of type 
'bool()'


Most likely you don't create an instance. This works:

http://dpaste.dzfl.pl/7c6ada9056ea


Big thanks! That's work!

What is the way to get from function 2 return value? For example 
I need get true or false and string value (to use it in another 
function).


bool isConfigExist()

{
configpath = exePath() ~ config.txt;
if (exists(configpath))
{
return true;
}

else
return false;

}

Now function return only bool and I need to make it's universal  
to get text also

Re: Write variable from other function




bool isConfigExist()

{
configpath = exePath() ~ config.txt;
if (exists(configpath))
{
return true;
}

else
return false;

}

Now function return only bool and I need to make it's universal
 to get text also


Probably not very good idea from me, I understand that I was 
wrong thinking!

Re: enum abuse

2014-02-28 Thread Steve Teale

On Friday, 28 February 2014 at 11:47:45 UTC, Vladimir Panteleev 
wrote:


A const or immutable declaration would declare a constant 
variable - meaning, unless it is optimized out at a later 
point, it will end up in the data segment and have its own 
address. An enum declares a manifest constant - it exists only 
in the memory of the compiler. Manifest constants make sense 
when doing metaprogramming. Constant/immutable declarations 
make sense for values that will be used in multiple places by 
code at runtime.


I'm with Mike - thanks Vlad, that makes it perfectly clear. I 
just wonder slightly why a language that prides itself so on its 
metaprogramming capabilities does not have a keyword that makes 
it obvious


Think of an abbreviation for compile-time-constant.

But yes, thanks.

BTW, why does an immutable integer type need to have an address?

Steve

Re: @disable this for structs

2014-02-28 Thread Steve Teale


On Friday, 28 February 2014 at 16:02:26 UTC, Dicebot wrote:

...

Mmm, simple question, complicated answer. But the first one was 
enough for me at this point.

Re: runtime loading D shared library as a standalone (with it's own GC etc)

2014-02-28 Thread Martin Nowak


On 02/26/2014 10:16 PM, Timothee Cour wrote:

Currently (on OSX) I can runtime load a D dll from a C program, but not
from a D program, which seems silly.

Is it possible to runtime load a D shared library as a standalone (ie
without sharing GC, runtime or any other data), treating it as if we
were loading from a C program (making no attempt at sharing druntime or
otherwise).

What do I need to change in druntime to make this possible?


Depends on why it doesn't work.

Nobody understands templates?

2014-02-28 Thread Steve Teale


All the D aficionados seem to wet their pants over
meta-programming, but I struggle to find a place to use it.

IIRC, I used it in a couple of places when I was trying to write
library stuff for MySQL, but in my current project, I use it only
once. That's when I want to stuff something onto my undo stack.

For that I have two template functions - push(T)(MybaseClass* p,
T t, int ID), and pushC, which is just the same except that it
checks the top of the stack to see if the ID there is the same as
what it is wanting to push.

This has served me very reliably, but I struggle to find other
places in the whole application where I would benefit from
templates.

Is this typical - libraries use templates, applications don't, or
am I just being unimaginative?

Steve

Re: Nobody understands templates?

2014-02-28 Thread Adam D. Ruppe

A lot of my code doesn't use very many new templates either... my 
web code does use a few magic templates which fills in a lot of 
boilerplate, but the app code - the business logic - uses almost 
no templates at all. My xml/html dom.d library also uses very few 
templates, it just doesn't fit as well as plain classes there.


I think it just depends on what you're doing... if it's generic 
or boilerplate, templates rock, but much of a program isn't 
really generic.

Re: enum abuse


On Friday, 28 February 2014 at 18:21:39 UTC, Steve Teale wrote:

BTW, why does an immutable integer type need to have an address?

Steve


So that you can pass it to function `void foo(immutable(int)* 
arg)`. It is just a normal variable after all, only immutable.

Re: Write variable from other function


On Friday, 28 February 2014 at 18:18:15 UTC, Suliman wrote:
Probably not very good idea from me, I understand that I was 
wrong thinking!


In case you really-really-really want it, such behavior can be 
achieved via std.typecons.Tuple :


import std.typecons;

auto foo()
{
return tuple(true, text);
}

void main()
{
auto ret_val = foo();
assert(ret_val[1] == text);
}

Re: How to return range constructs?


Hiho,

ok thanks - I haven't known that interfaces are not a must 
extend like in java to serve as a real interface to something. 
This is strange to me in first place but has its pros.


And when I want to build up a RandomAccessFinite I just have to 
implement the other methods as well, okay. :D
Is this performance intense to iterate over these custom ranges 
instead of iterating plainly without them or is the compiler 
optimizing the overhead away?


I have got another problem with my current implementation. My 
data field is private (as you can see from my first post) and I 
don't really want to create a public getter for it (because of 
the encapsulation) but I either don't want to copy it everytime I 
create a range for my matrix. On top of all I want to have 
seperate source files instead of one huge file (one module) where 
I can access everything (which is what I would need atm). So is 
there another way to solve this problem? Or do I really have to 
merge all my files into one big giantic file so that they are all 
in the same module?


Robin

Template error on compiling ...


Hiho,

I am currently working on a matrix library (matrices are 
templated structs) and have just implemented so-called 
ElementalOperations which perform certain tasks on mutable 
matrices.


There is an abstract ElementalOperation where three different 
ElementalOperation types inherit from. These ElementalOperations 
are structured like that:


module neoLab.core.ScaleRowOperation;

import neoLab.core.ElementalOperation;
import neoLab.core.Matrix;

final class ScaleRowOperation(T = double) : ElementalOperation
if (!hasIndirections!T)
{
private
{
size_t row = 0;
T factor = 1;
}

this(size_t row, T factor) pure nothrow {
this.row = row;
this.factor = factor;
}

override void opCall(ref Matrix m) pure nothrow {
foreach (immutable col; 0 .. m.getDimension().cols) {
m[this.row, col] *= this.factor;
}
}

override string toString() const pure nothrow {
return Scale all elements of row  ~ this.row ~
 by factor  ~ this.factor ~ .;
}
}

So it is a fairly simple concept until now and I haven't spend 
time on improving its performance as I run into a strange 
compiler error, telling me the following:


neoLab/core/ElementalOperation.d(6): Error: struct 
neoLab.core.Matrix.Matrix(T = double) if (!hasIndirections!T) is 
used as a type
neoLab/core/SwapRowsOperation.d(18): Error: struct 
neoLab.core.Matrix.Matrix(T = double) if (!hasIndirections!T) is 
used as a type


The matrix struct is defined as follows:

struct Matrix(T = double) if (!hasIndirections!T)

In the documentation hasIndirections!T reads:
Returns true if and only if T's representation includes at least 
one of the following:

- a  raw pointer U*;
- an array U[];
- a  reference to a class type C.
- an associative array.
- a  delegate.

I don't know why this error occures at all. In my opinion it 
shouldn't, or am I doing something wrong again?


Thanks in advance for help. =)

Robin

Re: enum abuse

2014-02-28 Thread Steven Schveighoffer

On Fri, 28 Feb 2014 13:21:39 -0500, Steve Teale  
steve.te...@britseyeview.com wrote:


I just wonder slightly why a language that prides itself so on its  
metaprogramming capabilities does not have a keyword that makes it  
obvious


For a *VERY* short time (I think one version perhaps), we had the  
'manifest' keyword which was supposed to mean manifest constant.


It was removed, Andrei was a very stanch supporter of enum being the  
manifest constant keyword.  This comment in an early debate about what  
became the inout feature is pretty explanatory:  
https://d.puremagic.com/issues/show_bug.cgi?id=1961#c3


And enum... you'll have to yank that out from my dead cold hands.  
Extending
enum instead of adding yet another way of defining symbolic constants is  
The

Right Thing to do. I am sure people would have realized how ridiculous the
whole manifest thing is if we first proposed it. We just can't define one
more way for each kind of snow there is.

-Steve

Re: Nobody understands templates?


On Friday, 28 February 2014 at 18:42:57 UTC, Steve Teale wrote:
Is this typical - libraries use templates, applications don't, 
or

am I just being unimaginative?

Steve


It is quite true as a generalization but in practice border line 
between application and a library is not that clear. You often 
have common modules used in various parts of an application. Kind 
of internal mini-libraries.


Also every time you catch yourself doing any sort of copy-paste, 
it is quite possible that it can be replaced by mixin / template 
mixin instead. Application that are built in more declarative way 
benefit more from such tool set than traditional imperative ones.

Re: enum abuse


On Friday, 28 February 2014 at 18:21:39 UTC, Steve Teale wrote:
On Friday, 28 February 2014 at 11:47:45 UTC, Vladimir Panteleev 
wrote:


A const or immutable declaration would declare a constant 
variable - meaning, unless it is optimized out at a later 
point, it will end up in the data segment and have its own 
address. An enum declares a manifest constant - it exists only 
in the memory of the compiler. Manifest constants make sense 
when doing metaprogramming. Constant/immutable declarations 
make sense for values that will be used in multiple places by 
code at runtime.


I'm with Mike - thanks Vlad, that makes it perfectly clear. I 
just wonder slightly why a language that prides itself so on 
its metaprogramming capabilities does not have a keyword that 
makes it obvious


D has many of those. Would you think, that inout is a wild 
modifier which transfers to const or none-const? Or that 'in' is 
short for 'const scope'? That's because Walter and Andrei won't 
like to add more keywords and reuse old ones from D1 times. It's 
not that obvious but that's D. ;)

Re: Template error on compiling ...

2014-02-28 Thread Tobias Pankrath


On Friday, 28 February 2014 at 19:09:11 UTC, Robin wrote:


override void opCall(ref Matrix m) pure nothrow {
foreach (immutable col; 0 .. m.getDimension().cols) {
m[this.row, col] *= this.factor;
}


I guess this is the culprit. You must use Matrix!(). In general 
if the compiler says that X is used as type, where X is 
something like a template, than you are using the template X 
instead of an instance where you should not.


There is probably an enhancement request to make the code above 
legal, though.

Re: Template error on compiling ...


On Friday, 28 February 2014 at 19:16:11 UTC, Tobias Pankrath
wrote:

On Friday, 28 February 2014 at 19:09:11 UTC, Robin wrote:


override void opCall(ref Matrix m) pure nothrow {
foreach (immutable col; 0 .. m.getDimension().cols) {
m[this.row, col] *= this.factor;
}


I guess this is the culprit. You must use Matrix!(). In general 
if the compiler says that X is used as type, where X is 
something like a template, than you are using the template X 
instead of an instance where you should not.


There is probably an enhancement request to make the code above 
legal, though.


Here it should probably be Matrix!T, though.

Re: Dynamically calling external libraries.

2014-02-28 Thread Setra


Thanks! That was perfect!

Re: Nobody understands templates?

2014-02-28 Thread FreeSlave

Well, when you're starting to use many templates you may end up 
with separate library.


Templates provide compile-time correctness, concepts (in Boost 
sense), policy-base design (see Modern C++ Design: Generic 
Programming and Design Patterns Applied by Andrei Alexandrescu) 
and compile-time choice of the most optimized way to do things. 
Eventually templates are here just to ease programming of 
applications and reduce boilerplate. All these things that we 
expect from libraries and that library's author must take into 
account.


D is multiparadigm language so you should not worry if you don't 
use some of its features. You may ask same question about 
delegates, attributes or user defined exceptions. The answer is 
simple: it all depends on your style, preferences and needs, your 
vision how perfect code should look like.

Re: Template error on compiling ...


Hiho,

both

opCall(ref Matrix!() m)

opCall(ref Matrix!T m)

aswell as

opCall(ref Matrix!(m))

or just

opCall(ref Matrix m)

give me all the same error as the one stated in the first post 
... :/


Nothing really seems to work here.

Robin

Re: Template error on compiling ...


On Friday, 28 February 2014 at 19:33:17 UTC, Robin wrote:

opCall(ref Matrix!() m)

opCall(ref Matrix!T m)

aswell as

opCall(ref Matrix!(m))


This one's just nonsense.


or just

opCall(ref Matrix m)


This one gives you the used as a type kind of error message.

give me all the same error as the one stated in the first post 
... :/


You're probably looking in the wrong place (for that particular
error message).

neoLab/core/ElementalOperation.d, line 6, and
neoLab/core/SwapRowsOperation.d, line 18,
are the spots the compiler complains about (so far).


module neoLab.core.ScaleRowOperation;
suggests that you're looking at neither of those two files. You 
still have to fix it there, too, though.

Re: Nobody understands templates?

2014-02-28 Thread Meta


On Friday, 28 February 2014 at 18:42:57 UTC, Steve Teale wrote:

All the D aficionados seem to wet their pants over
meta-programming, but I struggle to find a place to use it.

IIRC, I used it in a couple of places when I was trying to write
library stuff for MySQL, but in my current project, I use it 
only

once. That's when I want to stuff something onto my undo stack.

For that I have two template functions - push(T)(MybaseClass* p,
T t, int ID), and pushC, which is just the same except that it
checks the top of the stack to see if the ID there is the same 
as

what it is wanting to push.

This has served me very reliably, but I struggle to find other
places in the whole application where I would benefit from
templates.

Is this typical - libraries use templates, applications don't, 
or

am I just being unimaginative?

Steve


It really depends on what you're writing. If you look at Phobos, 
which is meant to be as general as possible, I'd estimate that 
about 70% of it is templated, possibly more. I find that general 
utilities (such as your push function) are pretty much always 
template, while most program logic isn't. If you find yourself 
writing mainly program logic with very little need for utility 
functions, then it shouldn't be surprising that you are not using 
templates that much. The one exception is when doing stuff that 
requires a lot of boilerplate; mixins and template mixins are 
extremely useful for that.

Re: GC for noobs

2014-02-28 Thread Xavier Bigand


Le 28/02/2014 13:22, Szymon Gatner a écrit :

On Friday, 28 February 2014 at 11:43:58 UTC, Dicebot wrote:

On Friday, 28 February 2014 at 11:28:01 UTC, Szymon Gatner wrote:

I didn't mean basic in the sense of easy but in the sense of
something that has to dealt with all the time / is common requirement.


Yes, it needs to be dealt with all the time but in a different ways.
Problem is with getting sensible defaults. D makes a reasonable
assumption that most applications don't actually care about tight
bullet-proof resource management and defaults to GC. I may not like it
but it fits criteria built-in resource management and pretty much
shows that it is not as basic as one may think.



Not really different tho. Actual function call swqence might be
different but the scheme is always the same: acquire resource, allocate,
connect, take from pool vs release, deallocate, disconnect, return to
pool. All of those fall under resource management - there is a finite
amout of a resouce whether it is a memory, a system process, a file or a
databese connection and it is crucial to the system stability that all
of them are properly returned / released AND in proper order (which is
of course reverse to acquisition).


I had a lot of difficulties too with the release order of resources. Of 
course I am coming from c++, in which it's to ease to manage.
I got some head-hack for the resource management, maybe a DIP must be 
done here about a module dedicated to the resource management? Or at 
least a tutorial in the wiki?



I finally solve my issues, but I am not happy, cause the way it's done 
seems to be too much error prone (resource leaks).



I used to work on mobile devices and some kind of resources have to be 
released as soon as possible. I also don't really like having a lot of 
applications running on devices never releasing resources, it can break 
the principle of multi-task OS. Just try to launch many Java/C# 
applications at the same time, you'll have to buy more memory.

How to build DMD on windows ?

2014-02-28 Thread Remo


How to build DMD on windows ?
And then run all the test for it?
README.md is pretty empty at the moment.

Of course it is possible to wait for some Fixes in DMD compiler 
may be it could be faster just to fix them by my self and then 
hope that the fix will be accepted...

Re: Nobody understands templates?

2014-02-28 Thread H. S. Teoh

On Fri, Feb 28, 2014 at 06:42:57PM +, Steve Teale wrote:
 All the D aficionados seem to wet their pants over
 meta-programming, but I struggle to find a place to use it.
 
 IIRC, I used it in a couple of places when I was trying to write
 library stuff for MySQL, but in my current project, I use it only
 once. That's when I want to stuff something onto my undo stack.
 
 For that I have two template functions - push(T)(MybaseClass* p,
 T t, int ID), and pushC, which is just the same except that it
 checks the top of the stack to see if the ID there is the same as
 what it is wanting to push.
 
 This has served me very reliably, but I struggle to find other
 places in the whole application where I would benefit from
 templates.
 
 Is this typical - libraries use templates, applications don't, or
 am I just being unimaginative?
[...]

As others have said, it depends on your needs and what you're trying to
accomplish. :) If you find that your code contains some functions that
are generically applicable, you can turn them into templates. Or leave
them as normal functions until another piece of code needs to call it
with different parameter types, then turn it into a template. A lot of
my code starts out that way and turn into templates once it becomes
clear that they are generically applicable.

It's also some degree of future-proofing: I work with numerical
software, for example, and knowing that one day I might desire to
substitute the built-in floating point types with, say, something that
can represent quadratic rationals (numbers of the form a+b*√c) exactly,
is an indication to me that functions that operate on these quantities
should be templated on the number type.

But on the other hand, if something doesn't *need* to be a template,
then don't use templates. :) It depends on what you're trying to
accomplish. Use the right tools for the job. Not every problem is a nail
to be hammered; sometimes using a screwdriver for a screw is just what
you need.


T

-- 
There are two ways to write error-free programs; only the third one works.

Re: Template error on compiling ...


On Friday, 28 February 2014 at 20:54:42 UTC, Robin wrote:

Hiho,

with

import neoLab.core.Matrix;

abstract class ElementalOperation(T = double) {
abstract void opCall(ref Matrix!T m);
abstract override string toString();
}

where I have made the abstract class templated (T = double) 
and where I have added a !T after Matrix in the opCall 
parameter list I get the following error:


/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/crt1.o: 
In function `_start':

(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
--- errorlevel 1


The error message is unrelated. undefined reference to `main'
- no main function. You can add -main to your dmd invocation to
let the compiler generate a dummy main.

When I leave the (T = double) template assignment out I get 
another error:


neoLab/core/ElementalOperation.d(6): Error: undefined 
identifier T


Well, sure, you just removed T.

With Tobias Pankrath's Matrix!() I get the following linker 
error:


/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/crt1.o: 
In function `_start':

(.text+0x20): undefined reference to `main'


Same as above: no main function.


ScaleRowOperation.o: In function

 many many many lines of unuseful error messages ...

(.text._D6neoLab4core6Matrix11__T6MatrixZ6Matrix6randomFxmxmdddZS6neoLab4core6Matrix11__T6MatrixZ6Matrix+0x145): 
undefined reference to 
`_D6neoLab4core9Dimension9Dimension4sizeMxFNaNbNdZm'

collect2: error: ld returned 1 exit status
--- errorlevel 1


Can't say much about this. Might just be fallout from previous
failures.

So, in conclusion. I still have no clue why this more or less 
simple construct does not work but gives me errors on compiling.


Matrix!T is the way to go.

Re: Template error on compiling ...


Hiho,

aww, that's a noob mistake of me.

Thanks!

Should take a closer look at the error messages next time a 
should think more about their special meaning ...


It works now while it feels strange that I have to template the 
three classes as I am only working with references to matrix and 
in my understanding this shouldn't affect the compilate. But, 
well, in the end it works now.^^


Robin

Re: Template error on compiling ...

2014-02-28 Thread Ali Çehreli


On 02/28/2014 02:21 PM, Robin wrote:

 I am only working with references to matrix and in my understanding this
 shouldn't affect the compilate.

As I understand it, Matrix is not a type; rather a type template. Only 
instances of that template like Matrix!double can be used as types.


I was interested in this thread but I could not put pieces together in 
my mind without complete code. Could you please demonstrate the problem 
with minimal code next time. Thanks. :)


Ali

Re: How to build DMD on windows ?

2014-02-28 Thread Vladimir Panteleev


On Friday, 28 February 2014 at 20:14:26 UTC, Remo wrote:

How to build DMD on windows ?
And then run all the test for it?
README.md is pretty empty at the moment.

Of course it is possible to wait for some Fixes in DMD compiler 
may be it could be faster just to fix them by my self and then 
hope that the fix will be accepted...


There is a guide for building DMD on the wiki:

http://wiki.dlang.org/Building_DMD

Maybe it should be linked to from the README...

Re: Write variable from other function

2014-02-28 Thread Ali Çehreli


On 02/28/2014 06:42 AM, Dicebot wrote:

 You want static variables, either in form of global variables
 (discouraged) or static class fields:

Luckily, there is no global namespace in D. So, when it makes sense 
module-level global variables are fine as well.


Ali

Re: How to return range constructs?


Hiho,

sorry for the double post but I can't find an edit button.

I have managed to write a custom ForwardRange based on your code 
as I wished it to behave. However, the assertion fails on 
compilation, now. The only thing I have changed is that I have 
added a constructor as well as changing the type of T[] to 
Matrix!T pointer type.


The general layout stayed the same and I don't think that a 
constructor may break the ForwardRange interface.


Do you know what's wrong here?

Here is the code:
http://dpaste.dzfl.pl/8718b09cb825

Besides that ... are there nicer workarounds to prevent using 
matrix by value instead of storing it as a pointer which is kind 
of unsafe?


Thanks in advance!

Robin

Re: Template error on compiling ...