Re: [challenge] Lazy flatten/avoiding type forward reference with map

[Andrej Mitrovic]

On 11/1/13, David Nadlinger  wrote:
> I just thought I'd be interested to see what the best solution we
> can find in terms of conciseness is.

Note that I've already asked this in D.learn:
http://forum.dlang.org/thread/mailman.43.1383090512.9546.digitalmars-d-le...@puremagic.com

[OT] Generating ddili.org with ddoc (was: Re: How to iterate using foreach on a class?)

[Ali Çehreli]

On 11/01/2013 03:51 PM, Philippe Sigaud wrote:

> What did you use to generate your website, btw?

It is a completely static web site (except the Google translate widget) 
that is produced by ddoc and a couple of Makefiles. The following is the 
Turkish readme file:


  https://code.google.com/p/ddili/source/browse/trunk/BENIOKU

The tools required for the site are just dmd and GNU make. The free pdf 
generator prince is used for the pdf versions of the books.


I just do

  make test

to produce the light-weight versions of the pages during development and

  make

to produce a single tar file to upload to the provider.

Ali

Re: How to iterate using foreach on a class?

[Philippe Sigaud]

On Fri, Nov 1, 2013 at 11:15 PM, Ali Çehreli  wrote:

>
>> You made my day! :) I can't believe that the king of D templates learned
> something from my little chapter:
>
>   
> https://github.com/**PhilippeSigaud/D-templates-**tutorial
>
> ;-) You're too kind. I should dust this text somewhat.

My understanding of D templates is now years behind the compiler (see the
new `alias Name(T) = ...` syntax in 2.064. That's cool).

Anyway, back to opApply. I should write something using it before I forget
how to use it :)

What did you use to generate your website, btw?

Re: How to iterate using foreach on a class?

[Ali Çehreli]

On 11/01/2013 02:28 PM, Philippe Sigaud wrote:

Ali:


As another shameless plug, those foreach methods are included in this

chapter:

http://ddili.org/ders/d.en/foreach_opapply.htm


OMG. I just grokked opApply.

*epiphany moment*

Thanks a lot, Ali! I tried to get it for *years*!



You made my day! :) I can't believe that the king of D templates learned 
something from my little chapter:


  https://github.com/PhilippeSigaud/D-templates-tutorial

Ali

Re: [challenge] Lazy flatten/avoiding type forward reference with map

[David Nadlinger]

On Friday, 1 November 2013 at 09:34:20 UTC, Philippe Sigaud wrote:

But can you think of a more simple/elegant workaround?



Is a standard lazy struct range authorized?


Sure. This wasn't intended as an actual challenge, as I don't 
have a "right" answer myself (or a prize, for that matter). ;)


I just thought I'd be interested to see what the best solution we 
can find in terms of conciseness is.


David

Re: How to iterate using foreach on a class?

[Philippe Sigaud]

Ali:

> As another shameless plug, those foreach methods are included in this
chapter:
> http://ddili.org/ders/d.en/foreach_opapply.htm

OMG. I just grokked opApply.

*epiphany moment*

Thanks a lot, Ali! I tried to get it for *years*!

Re: fieldPostBlit - what is wrong with this and workarounds

[Jonathan M Davis]

On Friday, November 01, 2013 14:28:55 Daniel Davidson wrote:
> On Thursday, 31 October 2013 at 19:39:44 UTC, Jonathan M Davis
> 
> wrote:
> > const and postblit fundamentally don't mix, because for it to
> > work, you have
> > to violate the type system. With postblits, the struct gets
> > memcpied and then
> > the postblit constructor has the chance to mutate the resulting
> > object to make
> > the pieces different that need to be different. However, to do
> > that mutation
> > when the object is const would mean mutating a const object
> > which violates the
> > type system. What we really need is copy constructors, but they
> > haven't been
> > added yet. At one point, Andrei was saying that he and Walter
> > had a solution,
> > but he didn't elaborate on it. I assume that it involved
> > introducing copy
> > constructors, but I don't know, and this issue has not yet been
> > resolved.
> 
> This makes sense, but I think we could have a simpler solution
> that does not involve a copy constructor addition. It seems the
> problem is postblit offers a hole in the system whereby
> developers could change immutable data. Because of that postblit
> and const don't mix. The simple fix would be take the
> implementation of postblit away from the developer. It seems the
> use case for postblit is really only to provide deep copy
> semantics by having developer throw in a bunch of dups where
> desired.

Deep copying is not the only reason to have a postblit. Smart pointers such as 
std.typecons.RefCounted require a postblit (or copy constructor if we had 
those) to do their job. Also, even if all you want is a deep copy, it's 
possible that the member being deep copied was allocated via something like 
malloc, in which case, the compiler couldn't take care of it for you.

> I am now convinced avoiding `const(T) t` as a member is wise
> advice. The suggestion of leaving it non-const and providing a
> const accessor is good - but it won't prevent module code from
> modifying it. I really want to make sure it is not being mutated.
> So I'm now leaning toward this approach:
> 
> struct S {
> const(T) *rc;
> }
> 
> so I won't have the copy/postblit issues. Doesn't this bypass the
> problems with `const(T) t`. The new risk is that somehow that
> member variable is initialized with a stack variable.

If you do that, then rc can be mutated (and so the struct can be mutated), but 
what it points to can't be. So, from the sounds if it, it does what you want. 
Though honestly, I wouldn't worry about the rest of a module mutating your 
member variable just because it has access to it. If you simply name member 
variables differently than the public API (e.g _rc instead of rc) and then 
provide a const property to access the member, then the odds are very low that 
you're going to accidentally access the member directly. And if you can't keep 
track of what's in a single module well enough to avoid this sort of problem, 
then your module is probably too big. But if you're paranoid, you can 
certainly add an extra layer indirection like you're suggesting. I wouldn't 
bother though.

- Jonathan M Davis

Re: How to iterate using foreach on a class?

[Jonathan M Davis]

On Friday, November 01, 2013 19:32:35 Dmitry Olshansky wrote:
> 01-Nov-2013 16:43, John Colvin пишет:
> > On Friday, 1 November 2013 at 12:37:20 UTC, simendsjo wrote:
> >> 2) opSlice
> >> 3) alias this
> > 
> > arguably these are the same in the context of the foreach loop. Both
> > just provide direct access to the underlying array.
> 
> No quite. I'd say alias this is frankly a bad idea to provide iteration.
> In any case returning naked underlying array is most surely short-sighted.

Pretty much anytime that you're tempted to use alias this, you should 
reconsider. It _does_ have its uses, but implicit conversions tend to cause a 
lot problems - especially in generic code. And in this case, you can simply 
declare opSlice to return the underlying array, so there isn't really any 
benefit to using alias this other than the fact that it saves you a few 
characters (which isn't even vaguely worth the cost IMHO).

> In short we have 2 ways:
> 1) Ranges
> 2) opApply
> 
> And a couple of extra things on _top_ of that to keep in mind:
> 1) Implicit conversion -> hence alias this to a range/opApply type works
> 2) opSlice is called on foreach aggregate if it's not a range or doesn't
> have opApply by itself.

Yeah. Any user-defined type that's iterable via foreach uses either the range 
API or opApply. And in general, unless the range API isn't going to work for 
you, it's recommended to use the range API rather than opApply. opSlice comes 
into play when you want to iterate over something as a range without consuming 
it. The most common place to see opSlice would likely be on containers.

- Jonathan M Davis

Re: Using reduce() with tuples created by zip()

[Philippe Sigaud]

What I'm trying to explain is that reduce takes two arguments: the growing
value and the current front. In your case, the current front is indeed a
2-tuple, but that's an unrelated issue.

You're trying to get:

reduce!( (firstElemOfPair, secondElemOfPair) => ...) (range)

to work, whereas reduce signature is:

reduce!( (onGoingValue, elem) => ...) (range)

Re: Using reduce() with tuples created by zip()

[Craig Dillabaugh]

On Friday, 1 November 2013 at 18:44:23 UTC, Philippe Sigaud wrote:
reduce!( (result, elem) => result + (elem[0]-elem[1])^^2 
)(zippedRange, 0)




This is really where my problem arose. I understood everything 
up
to here, but I sort of had this idea, "hey zip returns a tuple 
so

that somehow the compiler
was going to figure out for me that function(e) has two values"
and is thus
a binary function so this should work (the 0.0 on the end was 
my

start value):

reduce!(function(e) { return (e[1]-e[0])*(e[1]-e[0]); })(0.0)

However, of course the compiler see's the tuple as just one 
value

- which is where I made my mistake.



The problem is not tuple, it's that reduce needs a binary 
function to work.


Yes, that is more or less what I was trying to say. I was
figuring that the compiler could figure out that 'e' was really a
pair of values, thus making function(e) binary.  Of course, that
is asking too much from the compiler.

Re: Using reduce() with tuples created by zip()

[Philippe Sigaud]

reduce!( (result, elem) => result + (elem[0]-elem[1])^^2 )(zippedRange, 0)

>
> This is really where my problem arose. I understood everything up
> to here, but I sort of had this idea, "hey zip returns a tuple so
> that somehow the compiler
> was going to figure out for me that function(e) has two values"
> and is thus
> a binary function so this should work (the 0.0 on the end was my
> start value):
>
> reduce!(function(e) { return (e[1]-e[0])*(e[1]-e[0]); })(0.0)
>
> However, of course the compiler see's the tuple as just one value
> - which is where I made my mistake.
>

The problem is not tuple, it's that reduce needs a binary function to work.

Re: Shipping the DMD compiler with code

[Colin Grogan]

On Friday, 1 November 2013 at 17:07:48 UTC, John Colvin wrote:

On Friday, 1 November 2013 at 15:47:56 UTC, Colin Grogan wrote:
I have a project I may need to write that is pretty 
performance intensive, but also needs to be quite 
customiseable.


We previously had this done with Perl, and the customising 
came from adding functions to a file and the main script would 
call those functions as required.

Problem is, the Perl program is performing very slowly.

Im thinking of doing this with D, and using string mixins to 
add in customised functions at compile time. All well and good 
I think.


However, I dont want to have the hassle of telling users to 
install a D compiler on their systems.
Ideally, the user should be able to unzip this tool and run it 
with rdmd.


Is it possible to ship the D compiler with the code, and not 
have to worry about any libs and config files being missing?


I'm specifically thinking about libphobos.a and dmd.conf, can 
they just be in the same folder as the D compiler or do they 
need to be in /usr/lib and /etc ?


Thanks folks!


dmd.conf can be in the same folder as the dmd executable. All 
the rest of the linking etc. is specified in dmd.conf so you 
just need to set that up appropriately.


The legal side of things is a different matter. I quote from 
src/backendlicense.txt : "The Software is copyrighted and comes 
with a single user license, and may not be redistributed. If 
you wish to obtain a redistribution license, please contact 
Digital Mars."


Walter may be able to grant redistribution rights if you ask 
him, IIRC this has happened before?? If not, you could just add 
a tiny downloader that grabs the zip file on the clients 
machine, which contains everything you need with no 
installation necessary.


Yeah, I guess I can put this in a script that will check 
everytime the program is run if dmd (or gdc etc) exists, and if 
not go and download it.


Thanks for the info folks!

Re: Shipping the DMD compiler with code

[Colin Grogan]

On Friday, 1 November 2013 at 16:12:10 UTC, Joseph Rushton 
Wakeling wrote:

On 01/11/13 17:01, bearophile wrote:
I think you are not allowed to redistribute the DMD compiler. 
So you have to use

GDC or LDC (where LDC = LDC2).


Many things are possible if you get permission from the right 
person ... :-)


Depending on the use-case it may be preferable to ship GDC or 
LDC anyway, but if DMD is desired, ask Walter directly.  The 
worst that can happen is he says no (and if he does, it'll most 
likely be because his hands are tied).


Theres should be no issue in using gdc, and I wouldn't like to 
hassle Walter with that. He should be busy making fixing bugs in 
the new dmd release anyway! ;)

Re: Shipping the DMD compiler with code

[John Colvin]

On Friday, 1 November 2013 at 15:47:56 UTC, Colin Grogan wrote:
I have a project I may need to write that is pretty performance 
intensive, but also needs to be quite customiseable.


We previously had this done with Perl, and the customising came 
from adding functions to a file and the main script would call 
those functions as required.

Problem is, the Perl program is performing very slowly.

Im thinking of doing this with D, and using string mixins to 
add in customised functions at compile time. All well and good 
I think.


However, I dont want to have the hassle of telling users to 
install a D compiler on their systems.
Ideally, the user should be able to unzip this tool and run it 
with rdmd.


Is it possible to ship the D compiler with the code, and not 
have to worry about any libs and config files being missing?


I'm specifically thinking about libphobos.a and dmd.conf, can 
they just be in the same folder as the D compiler or do they 
need to be in /usr/lib and /etc ?


Thanks folks!


dmd.conf can be in the same folder as the dmd executable. All the 
rest of the linking etc. is specified in dmd.conf so you just 
need to set that up appropriately.


The legal side of things is a different matter. I quote from 
src/backendlicense.txt : "The Software is copyrighted and comes 
with a single user license, and may not be redistributed. If you 
wish to obtain a redistribution license, please contact Digital 
Mars."


Walter may be able to grant redistribution rights if you ask him, 
IIRC this has happened before?? If not, you could just add a tiny 
downloader that grabs the zip file on the clients machine, which 
contains everything you need with no installation necessary.

Re: Intelligent Scope Hierarchy

[Stretto]

On Friday, 1 November 2013 at 08:59:36 UTC, Namespace wrote:

On Friday, 1 November 2013 at 05:49:04 UTC, Stretto wrote:

On Thursday, 31 October 2013 at 22:03:18 UTC, Namespace wrote:

The 'it' property is only some 'singleton' approach.
You can write:

void foo() {
  auto buffer = Mallocator.allocate(42);
  /// ... many code
}

And at the end of the scope buffer is cleared because 
Mallocator's destructor call deallocateAll (if I'm not wrong).



That doesn't seem right? deallocateAll would deallocate all 
allocated objects? Even outside of foo's scope? Also, how 
would Mallocator.allocate know what to deallocate unless it 
kept a history? Why would the example code explicitly 
deallocate the object at the end of the scope if it were 
unnecessary?


Sorry, I was tired. ^^

That is the correct code:

void foo() {
Mallocator m;
auto buffer = m.allocate(42);
}

If m get out of scope, it deallocates all allocated memory.


Ok, I can see that but what if we want a "global" allocator? Then 
we need an easy way to deallocate on scope exit. I see no way to 
do that implicitly without some like I've mentioned(the 
(de)allocator needs a way to add itself to the scope exit).

Re: Linker error regarding importing and unit tests. Is this a bug?

[Gary Willoughby]

On Friday, 1 November 2013 at 15:32:54 UTC, Daniel Davidson wrote:
An alternative is to move the import statements in test1.d out 
of the unittest block, which becomes a function, to file scope. 
Then if you have multiple unittests in test1.d all are covered 
and the symbols are available.


...
version(unittest) {
  import methods;
}
unittest
{
  import std.stdio;
  writeln("test1 unit test");
  S s;
  assert(s.x.nothing());
}

Thanks
Dan


Ah right, if the unit tests are transformed into a function then 
is this a problem with the scoped import rules? It seems really 
odd, as the compiler seems to strip out the imports within the 
unit test block when that module is imported into another. This 
doesn't seem to affect the standard library only user modules.

Re: Shipping the DMD compiler with code

[Joseph Rushton Wakeling]

On 01/11/13 17:01, bearophile wrote:

I think you are not allowed to redistribute the DMD compiler. So you have to use
GDC or LDC (where LDC = LDC2).


Many things are possible if you get permission from the right person ... :-)

Depending on the use-case it may be preferable to ship GDC or LDC anyway, but if 
DMD is desired, ask Walter directly.  The worst that can happen is he says no 
(and if he does, it'll most likely be because his hands are tied).

Re: Shipping the DMD compiler with code

[bearophile]

Colin Grogan:

Is it possible to ship the D compiler with the code, and not 
have to worry about any libs and config files being missing?


I think you are not allowed to redistribute the DMD compiler. So 
you have to use GDC or LDC (where LDC = LDC2).


Bye,
bearophile

Re: How to iterate using foreach on a class?

[Ali Çehreli]

On 11/01/2013 08:32 AM, Dmitry Olshansky wrote:


In short we have 2 ways:
1) Ranges
2) opApply


As another shameless plug, those foreach methods are included in this 
chapter:


  http://ddili.org/ders/d.en/foreach_opapply.html

Ali

Shipping the DMD compiler with code

[Colin Grogan]

I have a project I may need to write that is pretty performance 
intensive, but also needs to be quite customiseable.


We previously had this done with Perl, and the customising came 
from adding functions to a file and the main script would call 
those functions as required.

Problem is, the Perl program is performing very slowly.

Im thinking of doing this with D, and using string mixins to add 
in customised functions at compile time. All well and good I 
think.


However, I dont want to have the hassle of telling users to 
install a D compiler on their systems.
Ideally, the user should be able to unzip this tool and run it 
with rdmd.


Is it possible to ship the D compiler with the code, and not have 
to worry about any libs and config files being missing?


I'm specifically thinking about libphobos.a and dmd.conf, can 
they just be in the same folder as the D compiler or do they need 
to be in /usr/lib and /etc ?


Thanks folks!

Re: Linker error regarding importing and unit tests. Is this a bug?

[Daniel Davidson]

On Friday, 1 November 2013 at 12:59:24 UTC, Gary Willoughby wrote:
I have a small test case that displays a linker error. I 
wondered if this is an issue with the tool chain or whether i'm 
doing something wrong.


I have a simple directory structure like this:

test/methods.d
test/test1.d
test/test2.d

Here is the source code for the above modules:

methods.d:

module test.methods;

import std.array;

public bool nothing(int[] x)
{
return x.empty();
}

test1.d:

module test.test1;

struct S
{
int x[];
}

unittest
{
import test.methods;
import std.stdio;

writeln("test1 unit test");

S s;

assert(s.x.nothing());
}

test2.d:

module test.test2;

import test.test1;

struct T
{
int x[];
}

I compile the following sources like this:

	rdmd --force -de -debug -I~/Desktop -m64 -main -property 
-unittest -w 


Where  is an individual file above. I do this because i 
like to compile and tests each module in isolation running the 
unit tests. When i try and compile `test2.d` i get the 
following error:


Undefined symbols for architecture x86_64:
  "_D4test7methods12__ModuleInfoZ", referenced from:
  _D4test5test112__ModuleInfoZ in test2.o
  "_D4test7methods7nothingFAiZb", referenced from:
  _D4test5test114__unittestL8_1FZv in test2.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)


If i add the following to the bottom of `test2.d` it all 
compiles fine:


unittest
{
import test.methods;
}

Any idea what's going on here?


An alternative is to move the import statements in test1.d out of 
the unittest block, which becomes a function, to file scope. Then 
if you have multiple unittests in test1.d all are covered and the 
symbols are available.


...
version(unittest) {
  import methods;
}
unittest
{
  import std.stdio;
  writeln("test1 unit test");
  S s;
  assert(s.x.nothing());
}

Thanks
Dan

Re: How to iterate using foreach on a class?

[Dmitry Olshansky]

01-Nov-2013 16:43, John Colvin пишет:

On Friday, 1 November 2013 at 12:37:20 UTC, simendsjo wrote:

2) opSlice
3) alias this


arguably these are the same in the context of the foreach loop. Both
just provide direct access to the underlying array.


No quite. I'd say alias this is frankly a bad idea to provide iteration.
In any case returning naked underlying array is most surely short-sighted.

In short we have 2 ways:
1) Ranges
2) opApply

And a couple of extra things on _top_ of that to keep in mind:
1) Implicit conversion -> hence alias this to a range/opApply type works
2) opSlice is called on foreach aggregate if it's not a range or doesn't 
have opApply by itself.


--
Dmitry Olshansky

Re: Using reduce() with tuples created by zip()

[Craig Dillabaugh]

On Friday, 1 November 2013 at 09:31:41 UTC, Philippe Sigaud wrote:

On Thu, Oct 31, 2013 at 8:59 PM, Craig Dillabaugh <
cdill...@cg.scs.carleton.ca> wrote:





Thanks, I will try both your, and Bearophile's ideas and see 
if I

can figure out how they work.




reduce takes a range and eagerly (that is, not lazily) builds a 
value from
it. In your case, it builds the squared distance between two 
points.  The
returned value can be anything: a numerical value, but also 
another range,
a complex object,  an so on. As long as it can be built 
increasingly,

you're good.

Given a range [a,b,c,..., z] and a binary function f,
reduce!(f)([a,b,c,...]) calculates f(a,b), then f(f(a,b), c), 
up to f(...

f( f( f(a,b),c), d), ...,z).

The only question is whether you give it a seed value, or if it 
takes the
first range element as seed  (f(seed, a), f(f(seed,a),b) and 
son on).

std.algorithm.reduce provides both overloads.

Note the only thing you get is the final result, not the 
internal f(f(...'s

applications.

If you want a sum:

reduce!( (result,elem) => result + elem )(range)

or

reduce!( (result,elem) => result + elem )(range, 0)

Sum of squares:

reduce!( (result, elem) => result + elem^^2 )(range, 0)

In your case, the basic element is a tuple, coming from zip. 
Access to the

two elements is done with [0] or [1]. So:

reduce!( (result, elem) => result + (elem[0]-elem[1])^^2 
)(zippedRange, 0)


This is really where my problem arose. I understood everything up
to here, but I sort of had this idea, "hey zip returns a tuple so
that somehow the compiler
was going to figure out for me that function(e) has two values"
and is thus
a binary function so this should work (the 0.0 on the end was my
start value):

reduce!(function(e) { return (e[1]-e[0])*(e[1]-e[0]); })(0.0)

However, of course the compiler see's the tuple as just one value
- which is where I made my mistake.



Of course, it would be easy to write a small n-range reduce 
helper

function, that takes n ranges and reduces them in parallel:

reduce!( (result, a, b) => result + (a-b)^^2 )(rangeA, rangeB, 
0)


Note that reduce is a versatile function: you can duplicate 
filter and map
functionalities with it. The only thing to remember is that, 
compared to
other iteration algorithm/ranges, it's eager. Don't use it on 
an infinite

range!


We could also have a slightly different version that lazily 
produces the
intermediate results as a range. IIRC, it's called 'scan' in 
Haskell. It's
sometimes interesting to have it: you can interrupt the ongoing 
calculation
when the result is 'good enough', not waiting for the entire 
input range to

be consumed.

Re: Using reduce() with tuples created by zip()

[bearophile]

Philippe Sigaud:

We could also have a slightly different version that lazily 
produces the
intermediate results as a range. IIRC, it's called 'scan' in 
Haskell.


It's already in Bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=11084

Bye,
bearophile

Re: fieldPostBlit - what is wrong with this and workarounds

[Daniel Davidson]

On Thursday, 31 October 2013 at 19:39:44 UTC, Jonathan M Davis 
wrote:
const and postblit fundamentally don't mix, because for it to 
work, you have
to violate the type system. With postblits, the struct gets 
memcpied and then
the postblit constructor has the chance to mutate the resulting 
object to make
the pieces different that need to be different. However, to do 
that mutation
when the object is const would mean mutating a const object 
which violates the
type system. What we really need is copy constructors, but they 
haven't been
added yet. At one point, Andrei was saying that he and Walter 
had a solution,
but he didn't elaborate on it. I assume that it involved 
introducing copy
constructors, but I don't know, and this issue has not yet been 
resolved.




This makes sense, but I think we could have a simpler solution 
that does not involve a copy constructor addition. It seems the 
problem is postblit offers a hole in the system whereby 
developers could change immutable data. Because of that postblit 
and const don't mix. The simple fix would be take the 
implementation of postblit away from the developer. It seems the 
use case for postblit is really only to provide deep copy 
semantics by having developer throw in a bunch of dups where 
desired.
What if the language just provided standard postblit 
functionality not defined by the user. However it is specified, 
it should be easy to implement.


struct S {
  // blit and no postblit dup -> sharing
  int[] y;

  // blit with request for postblit dup -> no sharing
  @postblit int[] x;
}

Ideally, [].dup would be made pure. Once that is done, generic 
field by field deep copy could be done and be made pure, thus 
returning optionally immutable data. While it is true the 
generated postblit will be mutating the incipient instance - that 
is fine as it is called in a construction context and dup is 
surely idempotent. Why make the developer write a function for 
simple copy?


Now, in your particular code example, you don't define postblit 
constructor,
but my guess would be that RateCurve defines one, making it so 
that a postblit
constructor is generated for T which uses the one for 
RateCurve, and the S
gets one which uses T's. And because const doesn't work with 
postblit
constructors, S becomes uncopyable, and if there's any code 
that requires that
a copy be made, then it'll fail to compile (I'm not sure 
whether the fact that
it's uncopyable will result in an error if no attempts to copy 
it are made,
but you'll definitely get an error if an attempt to copy is 
made).




Your guesses are correct.

Hopefully, this problem will be resolved, but regardless of 
that, I would
advise against ever having a const member variable in a struct. 
Even if you
don't have any postblit issues, such a struct can never be 
assigned to, and it
becomes essentially unusuable in any situation where you would 
have to assign
a value to it (e.g. if it were in an array). You can certainly 
make a struct's
member variable const if you want to, but you're going to run 
into stuff that
won't work as a result. It's far better to just provide a 
property for it
which is const (probably returning the member by const ref if 
you want to
avoid copying it when using the property) rather than making 
the member

variable itself const.

- Jonathan M Davis


I am now convinced avoiding `const(T) t` as a member is wise 
advice. The suggestion of leaving it non-const and providing a 
const accessor is good - but it won't prevent module code from 
modifying it. I really want to make sure it is not being mutated. 
So I'm now leaning toward this approach:


struct S {
  const(T) *rc;
}

so I won't have the copy/postblit issues. Doesn't this bypass the 
problems with `const(T) t`. The new risk is that somehow that 
member variable is initialized with a stack variable.


Thanks,
Dan

Linker error regarding importing and unit tests. Is this a bug?

[Gary Willoughby]

I have a small test case that displays a linker error. I wondered 
if this is an issue with the tool chain or whether i'm doing 
something wrong.


I have a simple directory structure like this:

test/methods.d
test/test1.d
test/test2.d

Here is the source code for the above modules:

methods.d:

module test.methods;

import std.array;

public bool nothing(int[] x)
{
return x.empty();
}

test1.d:

module test.test1;

struct S
{
int x[];
}

unittest
{
import test.methods;
import std.stdio;

writeln("test1 unit test");

S s;

assert(s.x.nothing());
}

test2.d:

module test.test2;

import test.test1;

struct T
{
int x[];
}

I compile the following sources like this:

	rdmd --force -de -debug -I~/Desktop -m64 -main -property 
-unittest -w 


Where  is an individual file above. I do this because i 
like to compile and tests each module in isolation running the 
unit tests. When i try and compile `test2.d` i get the following 
error:


Undefined symbols for architecture x86_64:
  "_D4test7methods12__ModuleInfoZ", referenced from:
  _D4test5test112__ModuleInfoZ in test2.o
  "_D4test7methods7nothingFAiZb", referenced from:
  _D4test5test114__unittestL8_1FZv in test2.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)


If i add the following to the bottom of `test2.d` it all compiles 
fine:


unittest
{
import test.methods;
}

Any idea what's going on here?

Re: How to iterate using foreach on a class?

[John Colvin]

On Friday, 1 November 2013 at 12:37:20 UTC, simendsjo wrote:

2) opSlice
3) alias this


arguably these are the same in the context of the foreach loop. 
Both just provide direct access to the underlying array.

Re: How to iterate using foreach on a class?

[simendsjo]

On Friday, 1 November 2013 at 11:41:52 UTC, Jonathan M Davis 
wrote:

On Friday, November 01, 2013 12:30:10 Gary Willoughby wrote:

I have a class which contains an array as a core collection of
data. I want to pass an instance of this class to a foreach 
loop

and iterate through the enclosed array. How do i do this? I've
asked this before and got an answer but i can't find anything 
now.


In general, if you want to make something work with foreach, 
you either make
it a range, or you give it an opSlice which returns a range 
(another
alternative would be define opApply, but in general, code 
should be using the
range primitives rather than opApply). Given that you're 
looking to iterate an
array, and you presumably don't want the array to be consumed 
when iterating,
the simplest would be to simply declare an opSlice on the class 
returns the

array. e.g.

class C
{
int[] foo;
auto opSlice() { return foo; }
}

Then when you use the class in a foreach loop, it'll be sliced, 
and the return
value of opSlice (the array in this case) will then be iterated 
over.


- Jonathan M Davis


So we basically have 4 ways..?
1) popFront + front
2) opSlice
3) alias this
4) opApply

Re: How to iterate using foreach on a class?

[evilrat]

On Friday, 1 November 2013 at 11:39:15 UTC, Gary Willoughby wrote:

On Friday, 1 November 2013 at 11:35:03 UTC, simendsjo wrote:
On Friday, 1 November 2013 at 11:30:12 UTC, Gary Willoughby 
wrote:
I have a class which contains an array as a core collection 
of data. I want to pass an instance of this class to a 
foreach loop and iterate through the enclosed array. How do i 
do this? I've asked this before and got an answer but i can't 
find anything now.


alias this on the underlying array


Alias this?


alias this can be used to do implicit casting like this

-
void someFunc(int x) { ... }

struct A
{
alias this someValue;
int someValue;
}

void main()
{
A a = A(5);
someFunc(a); // implicitly extracts 5 from struct A
}
---

as side note, alias this is not finished yet, so use with caution 
as it still allows only one alias this per class/struct

Re: is this invalid code

[Daniel Davidson]

On Friday, 1 November 2013 at 04:26:25 UTC, Ali Çehreli wrote:


You are not going to like my answer but this may be the 16-byte 
struct bug. Add something to RateCurve and your code works 
fine... :-/


struct RateCurve {
  private immutable(DateRate)[] _data;
ubyte b;  // <-- ADDED
}



I appreciate and hate the answer :-). I've had a variant of this 
code working for a while. The previous version had DateRate[] 
instead of immutable(DateRate)[]. Since DateRate has no immutable 
aliasing I was trying to go for a more string-like immutable by 
design class.


My hope is that is not the problem, or if it is it rears its head 
only in the context of initializers that leave that member empty. 
In this example if I provided `CFS(1.0, RateCurve([]));`  as the 
initializer then it worked fine.


What exactly is the 16-byte bug? I can't imagine 16-byte structs 
are generally a problem.


Thanks,
Dan

Re: How to iterate using foreach on a class?

[Gary Willoughby]

On Friday, 1 November 2013 at 11:41:52 UTC, Jonathan M Davis 
wrote:

On Friday, November 01, 2013 12:30:10 Gary Willoughby wrote:

I have a class which contains an array as a core collection of
data. I want to pass an instance of this class to a foreach 
loop

and iterate through the enclosed array. How do i do this? I've
asked this before and got an answer but i can't find anything 
now.


In general, if you want to make something work with foreach, 
you either make
it a range, or you give it an opSlice which returns a range 
(another
alternative would be define opApply, but in general, code 
should be using the
range primitives rather than opApply). Given that you're 
looking to iterate an
array, and you presumably don't want the array to be consumed 
when iterating,
the simplest would be to simply declare an opSlice on the class 
returns the

array. e.g.

class C
{
int[] foo;
auto opSlice() { return foo; }
}

Then when you use the class in a foreach loop, it'll be sliced, 
and the return
value of opSlice (the array in this case) will then be iterated 
over.


- Jonathan M Davis


Hmmm, that's simpler too. ta.

Re: How to iterate using foreach on a class?

[Jonathan M Davis]

On Friday, November 01, 2013 12:30:10 Gary Willoughby wrote:
> I have a class which contains an array as a core collection of
> data. I want to pass an instance of this class to a foreach loop
> and iterate through the enclosed array. How do i do this? I've
> asked this before and got an answer but i can't find anything now.

In general, if you want to make something work with foreach, you either make 
it a range, or you give it an opSlice which returns a range (another 
alternative would be define opApply, but in general, code should be using the 
range primitives rather than opApply). Given that you're looking to iterate an 
array, and you presumably don't want the array to be consumed when iterating, 
the simplest would be to simply declare an opSlice on the class returns the 
array. e.g.

class C
{
int[] foo;
auto opSlice() { return foo; }
}

Then when you use the class in a foreach loop, it'll be sliced, and the return 
value of opSlice (the array in this case) will then be iterated over.

- Jonathan M Davis

Re: How to iterate using foreach on a class?

[Gary Willoughby]

On Friday, 1 November 2013 at 11:35:03 UTC, simendsjo wrote:
On Friday, 1 November 2013 at 11:30:12 UTC, Gary Willoughby 
wrote:
I have a class which contains an array as a core collection of 
data. I want to pass an instance of this class to a foreach 
loop and iterate through the enclosed array. How do i do this? 
I've asked this before and got an answer but i can't find 
anything now.


alias this on the underlying array, or implement opApply: 
http://dlang.org/statement.html


Ah that's it, opApply! ta.

Re: How to iterate using foreach on a class?

[Gary Willoughby]

On Friday, 1 November 2013 at 11:35:03 UTC, simendsjo wrote:
On Friday, 1 November 2013 at 11:30:12 UTC, Gary Willoughby 
wrote:
I have a class which contains an array as a core collection of 
data. I want to pass an instance of this class to a foreach 
loop and iterate through the enclosed array. How do i do this? 
I've asked this before and got an answer but i can't find 
anything now.


alias this on the underlying array


Alias this?

Re: How to iterate using foreach on a class?

[simendsjo]

On Friday, 1 November 2013 at 11:30:12 UTC, Gary Willoughby wrote:
I have a class which contains an array as a core collection of 
data. I want to pass an instance of this class to a foreach 
loop and iterate through the enclosed array. How do i do this? 
I've asked this before and got an answer but i can't find 
anything now.


alias this on the underlying array, or implement opApply: 
http://dlang.org/statement.html

How to iterate using foreach on a class?

[Gary Willoughby]

I have a class which contains an array as a core collection of 
data. I want to pass an instance of this class to a foreach loop 
and iterate through the enclosed array. How do i do this? I've 
asked this before and got an answer but i can't find anything now.

Re: [challenge] Lazy flatten/avoiding type forward reference with map

[Philippe Sigaud]

> But can you think of a more simple/elegant workaround?
>
>
Is a standard lazy struct range authorized?

Re: Using reduce() with tuples created by zip()

[Philippe Sigaud]

On Thu, Oct 31, 2013 at 8:59 PM, Craig Dillabaugh <
cdill...@cg.scs.carleton.ca> wrote:

>
>>>
> Thanks, I will try both your, and Bearophile's ideas and see if I
> can figure out how they work.



reduce takes a range and eagerly (that is, not lazily) builds a value from
it. In your case, it builds the squared distance between two points.  The
returned value can be anything: a numerical value, but also another range,
a complex object,  an so on. As long as it can be built increasingly,
you're good.

Given a range [a,b,c,..., z] and a binary function f,
reduce!(f)([a,b,c,...]) calculates f(a,b), then f(f(a,b), c), up to f(...
f( f( f(a,b),c), d), ...,z).

The only question is whether you give it a seed value, or if it takes the
first range element as seed  (f(seed, a), f(f(seed,a),b) and son on).
std.algorithm.reduce provides both overloads.

Note the only thing you get is the final result, not the internal f(f(...'s
applications.

If you want a sum:

reduce!( (result,elem) => result + elem )(range)

or

reduce!( (result,elem) => result + elem )(range, 0)

Sum of squares:

reduce!( (result, elem) => result + elem^^2 )(range, 0)

In your case, the basic element is a tuple, coming from zip. Access to the
two elements is done with [0] or [1]. So:

reduce!( (result, elem) => result + (elem[0]-elem[1])^^2 )(zippedRange, 0)


Of course, it would be easy to write a small n-range reduce helper
function, that takes n ranges and reduces them in parallel:

reduce!( (result, a, b) => result + (a-b)^^2 )(rangeA, rangeB, 0)

Note that reduce is a versatile function: you can duplicate filter and map
functionalities with it. The only thing to remember is that, compared to
other iteration algorithm/ranges, it's eager. Don't use it on an infinite
range!


We could also have a slightly different version that lazily produces the
intermediate results as a range. IIRC, it's called 'scan' in Haskell. It's
sometimes interesting to have it: you can interrupt the ongoing calculation
when the result is 'good enough', not waiting for the entire input range to
be consumed.

Re: new Type[count] takes too much?

[Namespace]

It is. I don't know if it is fixed already, and I don't have the 
time to search for the thread. But afaik monarch filled the bug.

Re: new Type[count] takes too much?

[John Colvin]

On Friday, 1 November 2013 at 00:16:55 UTC, Namespace wrote:
On Thursday, 31 October 2013 at 23:48:19 UTC, Jonathan M Davis 
wrote:

On Thursday, October 31, 2013 23:06:22 Namespace wrote:

On Thursday, 31 October 2013 at 09:53:39 UTC, Jonathan M Davis

wrote:
> On Thursday, October 31, 2013 10:15:51 Namespace wrote:
>> I'm sure we had already this conversation but I don't find 
>> the

>> thread.
>> 
>> T[] buffer = new T[N]; assumes more space than stated (in

>> average
>> 2010 elements more. See: http://dpaste.dzfl.pl/af92ad22c). 
>> It

>> behaves exactly like reserve and that is IMO wrong. If I
>> reserve
>> memory with buffer.reserve(N), I want to have at least N
>> elements. That behaviour is correct. But if I use new T[N] 
>> I

>> mostly want exactly N elements and no extra space.
>> 
>> Thoughts?
> 
> You're making the assumption that it would be normal to not

> want to then
> append to something you allocated with new T[N], and I don't
> think that that's
> a valid assumption.

I disagree. If I want to append I use reserve and I think 
that is

the most common approach.


I would fully expect that most people don't bother with 
reserve or capacity
and that they simply create the array at whatever size they 
create it at and
then append to it without worrying about reserve. But we'd 
have to get real

data on that to know for sure one way or the other.

Certainly, most folks who are focusing on append performance 
seem to use
Appender, and for the most part, I would suggest that anyone 
using reserve

should be using Appender instead.

- Jonathan M Davis


Currently Appender isn't more performant than built-in arrays. 
;)


I have found it more performant. A sensible test case where it is 
slower should be filed as a bug.

Re: new Type[count] takes too much?

[Jonathan M Davis]

On Friday, November 01, 2013 01:16:53 Namespace wrote:
> Currently Appender isn't more performant than built-in arrays. ;)

If Appender is not more performant for appending than just appending to a 
naked array, then something is very wrong with Appender, because it's whole 
job is to make sure that it calls all of the appropriate functions on its 
internal array which it needs to in order to make appending efficient (e.g. 
assumeSafeAppend).

- Jonathan M Davis

Re: Intelligent Scope Hierarchy

[Namespace]

On Friday, 1 November 2013 at 05:49:04 UTC, Stretto wrote:

On Thursday, 31 October 2013 at 22:03:18 UTC, Namespace wrote:

The 'it' property is only some 'singleton' approach.
You can write:

void foo() {
   auto buffer = Mallocator.allocate(42);
   /// ... many code
}

And at the end of the scope buffer is cleared because 
Mallocator's destructor call deallocateAll (if I'm not wrong).



That doesn't seem right? deallocateAll would deallocate all 
allocated objects? Even outside of foo's scope? Also, how would 
Mallocator.allocate know what to deallocate unless it kept a 
history? Why would the example code explicitly deallocate the 
object at the end of the scope if it were unnecessary?


Sorry, I was tired. ^^

That is the correct code:

void foo() {
Mallocator m;
auto buffer = m.allocate(42);
}

If m get out of scope, it deallocates all allocated memory.