Re: Monads compared to InputRanges?

[Max Klyga]

On 2013-12-04 01:53:39 +, Shammah Chancellor said:


On 2013-12-03 23:49:47 +, Max Klyga said:


On 2013-12-03 23:02:13 +, Shammah Chancellor said:


On 2013-12-03 21:51:20 +, Max Klyga said:


On 2013-12-03 02:45:44 +, Shammah Chancellor said:

I'm not particularly familiar with the syntax being used in the variet 
of monad examples.   I'm trying to figure out how this is different 
from UFCS on InputRanges.   It seems like std.algorithm implements 
something which accomplished the same thing, but much easier to 
understand?


Can somebody maybe do a compare and contrast for me?

-Shammah


Monads and input ranges are different things. I'll try to briefly 
explain monads. Hope this will not worsen the situation by being too 
confusing.


InputRanges provide a generic way for iterating over something.

UFCS can be used to create a range interface on things that do not provide it.

Monads are an abstraction for composing things within some context 
(concatenating lists, composing operations on nullable values, 
composing asynchronous operations). That sounds a bit too general and 
vague, because it is. One can think about as a design pattern.

Monad has two operations:
 - make a monad out of a value
 - apply a function that takes a value and returns a new monad of the 
same kind to value inside a monad


second operation has a different meaning for different monad kinds but 
generally it means 'execute this code within current context'


for nullable values this means 'execute only if there exist a value'
for asynchronous operations this means 'execute this when the value is ready'

This operation is commonly named 'bind' or 'flatMap'

Some languages provide syntax sugar for monads (Scala's for, Haskell's do)
Monads are easier to understand once you've seen enough examples of 
things that are monads.


Suppose you have a list of movies and want to produce a list of names 
of all actors stating in those movies.

In scala you would typically write something like this:

for (movie <- movies; actor <- movie.actors) yield actor.name

Compiler rewrites that to

movies.flatMap(movie => movie.actors).map(actor => actor.name)
  ^
   -- this function takes a list 
element and returns a new list, effectively creating a list of lists 
and then flattening it by concatenating all the lists into one, hence 
the name 'flatMap'. It transforms and then flattens.


Another popular example for Monads are optional values (similar to 
nullables but forcing you to check for presence of value and explicitly 
avoiding null dereferencing)


A common pattern for working with optional values is returning null 
from your function if your input is null


So if say we are parsing JSON and we want to process only values that 
contain certain field, that in turn contains another field. Example in 
pseudo-scala:


	for (value <- json.get("value"); // type of value is Option(JsonNode) 
meaning that actual json node might be absent
	   anotherValue <- value.get("another")) // this is executed only 
if value is present

doSomethingFancy(anotherValue) // ditto

and again, compiler will rewrite this into

	json.get("value").flatMap(value => 
value.get("another")).foreach(anotherValue => 
doSomethingFancy(anotherValue))


Once again we see that flat map is used. The pattern is same - get the 
value out of the box, transform it to another box of the same kind in 
the context meaningful for this particular box kind


So the main benefit is being able to compose things in a consistent 
way. Once you grasp the whole idea its fun finding out that some thing 
you've been doing can be viewed as a monad. People created quite a lot 
of different monads to this date.



I get the gist of that, but it seems like the range concept with UFCS 
provides the same thing? E.G.  range.map().flatten().map()?


Does it really not accomplish the same thing -- am I missing some key 
point of monads?


You look only at the syntax side of the question.

range.map(...).flatten.map(...) might look similar and it could be 
possible to squeeze monads to work with this api, but the thing is that 
not every monad could provide a meaningful map function and as a whole 
calling flatten after every map is a bit tiresome.


That may work for some monads, like List, because its effectively a range.
It will also work for Maybe monad. It could be viewed as a range of 0 
or 1 elements.
But things get bad when we try to define other monads in terms of range 
interface.


Current map implementation by design doesn't know anything about range 
it processes. If we try to define Promise monad as a range it will 
practically be useless unless we provide a custom map implementation 
for promises, because std.algorithm.map will return a wrapper range 
that will call popFront() that will block and wait for the value but 
that defeats the purpose entirely as we wanted the result to b

Re: alias this leads to compilation error in one of two similar contexts

[Carl Sturtivant]

This is intended behavior change from 2.064.

http://dlang.org/class#field-init
[...]
Kenji Hara


Interesting, useful, and a surprise. Thank you!

Re: floating point comparison basics

[ed]

On Wednesday, 4 December 2013 at 01:52:09 UTC, bearophile wrote:

H. S. Teoh:

The first rule of floating-point comparisons is that you never 
use ==.


So I suggested to disallow the == among FP numbers in D (and 
allow FP comparisons with "is" or with specialized functions, 
including one function that does what == does today).



For the original poster, for general FP comparisons I suggest 
std.math.feqrel, it's not fast, it's not const-correct, but 
it's good.


Bye,
bearophile


Thanks, I will look into it.

I've implemented my comparison function and it gives the same 
results as approxEquals ... yay! ...only took me several hours to 
achieve about 10 LOC but I finally understand it


Cheers,
Ed

Re: Monads compared to InputRanges?

[Shammah Chancellor]

On 2013-12-03 23:49:47 +, Max Klyga said:


On 2013-12-03 23:02:13 +, Shammah Chancellor said:


On 2013-12-03 21:51:20 +, Max Klyga said:


On 2013-12-03 02:45:44 +, Shammah Chancellor said:

I'm not particularly familiar with the syntax being used in the variet 
of monad examples.   I'm trying to figure out how this is different 
from UFCS on InputRanges.   It seems like std.algorithm implements 
something which accomplished the same thing, but much easier to 
understand?


Can somebody maybe do a compare and contrast for me?

-Shammah


Monads and input ranges are different things. I'll try to briefly 
explain monads. Hope this will not worsen the situation by being too 
confusing.


InputRanges provide a generic way for iterating over something.

UFCS can be used to create a range interface on things that do not provide it.

Monads are an abstraction for composing things within some context 
(concatenating lists, composing operations on nullable values, 
composing asynchronous operations). That sounds a bit too general and 
vague, because it is. One can think about as a design pattern.

Monad has two operations:
 - make a monad out of a value
 - apply a function that takes a value and returns a new monad of the 
same kind to value inside a monad


second operation has a different meaning for different monad kinds but 
generally it means 'execute this code within current context'


for nullable values this means 'execute only if there exist a value'
for asynchronous operations this means 'execute this when the value is ready'

This operation is commonly named 'bind' or 'flatMap'

Some languages provide syntax sugar for monads (Scala's for, Haskell's do)
Monads are easier to understand once you've seen enough examples of 
things that are monads.


Suppose you have a list of movies and want to produce a list of names 
of all actors stating in those movies.

In scala you would typically write something like this:

for (movie <- movies; actor <- movie.actors) yield actor.name

Compiler rewrites that to

movies.flatMap(movie => movie.actors).map(actor => actor.name)
  ^
   -- this function takes a list 
element and returns a new list, effectively creating a list of lists 
and then flattening it by concatenating all the lists into one, hence 
the name 'flatMap'. It transforms and then flattens.


Another popular example for Monads are optional values (similar to 
nullables but forcing you to check for presence of value and explicitly 
avoiding null dereferencing)


A common pattern for working with optional values is returning null 
from your function if your input is null


So if say we are parsing JSON and we want to process only values that 
contain certain field, that in turn contains another field. Example in 
pseudo-scala:


	for (value <- json.get("value"); // type of value is Option(JsonNode) 
meaning that actual json node might be absent
	   anotherValue <- value.get("another")) // this is executed only 
if value is present

doSomethingFancy(anotherValue) // ditto

and again, compiler will rewrite this into

	json.get("value").flatMap(value => 
value.get("another")).foreach(anotherValue => 
doSomethingFancy(anotherValue))


Once again we see that flat map is used. The pattern is same - get the 
value out of the box, transform it to another box of the same kind in 
the context meaningful for this particular box kind


So the main benefit is being able to compose things in a consistent 
way. Once you grasp the whole idea its fun finding out that some thing 
you've been doing can be viewed as a monad. People created quite a lot 
of different monads to this date.



I get the gist of that, but it seems like the range concept with UFCS 
provides the same thing? E.G.  range.map().flatten().map()?


Does it really not accomplish the same thing -- am I missing some key 
point of monads?


You look only at the syntax side of the question.

 range.map(...).flatten.map(...) might look similar and it could be 
possible to squeeze monads to work with this api, but the thing is that 
not every monad could provide a meaningful map function and as a whole 
calling flatten after every map is a bit tiresome.


That may work for some monads, like List, because its effectively a range.
It will also work for Maybe monad. It could be viewed as a range of 0 
or 1 elements.
But things get bad when we try to define other monads in terms of range 
interface.


Current map implementation by design doesn't know anything about range 
it processes. If we try to define Promise monad as a range it will 
practically be useless unless we provide a custom map implementation 
for promises, because std.algorithm.map will return a wrapper range 
that will call popFront() that will block and wait for the value but 
that defeats the purpose entirely as we wanted the result to be mapped 
asynchronously when it will be available and n

Re: floating point comparison basics

[bearophile]

H. S. Teoh:

The first rule of floating-point comparisons is that you never 
use ==.


So I suggested to disallow the == among FP numbers in D (and 
allow FP comparisons with "is" or with specialized functions, 
including one function that does what == does today).



For the original poster, for general FP comparisons I suggest 
std.math.feqrel, it's not fast, it's not const-correct, but it's 
good.


Bye,
bearophile

Re: How to install dmd2 in centos 5.3 x64

[Puming]

On Tuesday, 3 December 2013 at 17:47:47 UTC, Dejan Lekic wrote:

On Tuesday, 3 December 2013 at 10:43:06 UTC, Puming wrote:

Hi:

I followed the steps in http://dlang.org/dmd-linux.html, but 
when I build a simple hello world program with:


rdmd hello.d

I get the following error:

rdmd hello.d
/usr/bin/ld: cannot find -l:libphobos2.a

I have copied dmd2/linux/lib64/libphobos2.a to /usr/lib64, but 
ld still can't find it.


Now I really wish all our servers are using ubuntu server..

Could anybody shed some light on where the problem is? I don't 
have much experience in linux except using apt-get in ubuntu.


Thanks.

Puming.


What architecture that CentOS box is, and give us your 
/etc/dmd.conf please.


model name  : Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz

Linux 2.6.18-308.el5 #1 SMP EST 2012 x86_64 x86_64 x86_64 
GNU/Linux


I'm using the the dmd.conf in dmd.2.064.2.zip



[Environment]

#DFLAGS=-I%@P%/../../src/phobos -I%@P%/../../src/druntime/import 
-L-L%@P%/../lib64 -L-L%@P%/../lib32 -L--no-warn-search-mismatch 
-L--export-dynamic
DFLAGS=-I%@P%/../../src/phobos -I%@P%/../../src/druntime/import 
-L-L%@P%/../lib64 -L-L%@P%/../lib32 -L--export-dynamic


I commented out the -L--no-warn-search-mismatch because when 
building there's an error:


/usr/bin/ld: unrecognized option '--no-warn-search-mismatch'

Re: floating point comparison basics

[ed]

On Tuesday, 3 December 2013 at 23:17:29 UTC, H. S. Teoh wrote:

Thanks for the reply and the link, it gives me more confidence 
that I'm understanding things a bit better. I finally feel like 
I've opened the lid on the black box of float precision.


I found a great set of articles which I'm working through now.
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

It seems that Phobos approxEqual is (one of the) agreed upon 
methods from all sources I've read.  Another involves computing 
the ULPs as integers and comparing those for equality. Both 
approaches are very similar in terms of code though.


Next year I have a whole semester on numerical computing, 
covering floating point numbers, machine imprecision and how to 
deal with etcI'm determined to ace that subject :D


Cheers,
Ed

Re: Monads compared to InputRanges?

[Max Klyga]

On 2013-12-03 23:02:13 +, Shammah Chancellor said:


On 2013-12-03 21:51:20 +, Max Klyga said:


On 2013-12-03 02:45:44 +, Shammah Chancellor said:

I'm not particularly familiar with the syntax being used in the variet 
of monad examples.   I'm trying to figure out how this is different 
from UFCS on InputRanges.   It seems like std.algorithm implements 
something which accomplished the same thing, but much easier to 
understand?


Can somebody maybe do a compare and contrast for me?

-Shammah


Monads and input ranges are different things. I'll try to briefly 
explain monads. Hope this will not worsen the situation by being too 
confusing.


InputRanges provide a generic way for iterating over something.

UFCS can be used to create a range interface on things that do not provide it.

Monads are an abstraction for composing things within some context 
(concatenating lists, composing operations on nullable values, 
composing asynchronous operations). That sounds a bit too general and 
vague, because it is. One can think about as a design pattern.

Monad has two operations:
 - make a monad out of a value
 - apply a function that takes a value and returns a new monad of the 
same kind to value inside a monad


second operation has a different meaning for different monad kinds but 
generally it means 'execute this code within current context'


for nullable values this means 'execute only if there exist a value'
for asynchronous operations this means 'execute this when the value is ready'

This operation is commonly named 'bind' or 'flatMap'

Some languages provide syntax sugar for monads (Scala's for, Haskell's do)
Monads are easier to understand once you've seen enough examples of 
things that are monads.


Suppose you have a list of movies and want to produce a list of names 
of all actors stating in those movies.

In scala you would typically write something like this:

for (movie <- movies; actor <- movie.actors) yield actor.name

Compiler rewrites that to

movies.flatMap(movie => movie.actors).map(actor => actor.name)
  ^
   -- this function takes a list 
element and returns a new list, effectively creating a list of lists 
and then flattening it by concatenating all the lists into one, hence 
the name 'flatMap'. It transforms and then flattens.


Another popular example for Monads are optional values (similar to 
nullables but forcing you to check for presence of value and explicitly 
avoiding null dereferencing)


A common pattern for working with optional values is returning null 
from your function if your input is null


So if say we are parsing JSON and we want to process only values that 
contain certain field, that in turn contains another field. Example in 
pseudo-scala:


	for (value <- json.get("value"); // type of value is Option(JsonNode) 
meaning that actual json node might be absent
	   anotherValue <- value.get("another")) // this is executed only 
if value is present

doSomethingFancy(anotherValue) // ditto

and again, compiler will rewrite this into

	json.get("value").flatMap(value => 
value.get("another")).foreach(anotherValue => 
doSomethingFancy(anotherValue))


Once again we see that flat map is used. The pattern is same - get the 
value out of the box, transform it to another box of the same kind in 
the context meaningful for this particular box kind


So the main benefit is being able to compose things in a consistent 
way. Once you grasp the whole idea its fun finding out that some thing 
you've been doing can be viewed as a monad. People created quite a lot 
of different monads to this date.



I get the gist of that, but it seems like the range concept with UFCS 
provides the same thing? E.G.  range.map().flatten().map()?


Does it really not accomplish the same thing -- am I missing some key 
point of monads?


You look only at the syntax side of the question.

range.map(...).flatten.map(...) might look similar and it could be 
possible to squeeze monads to work with this api, but the thing is that 
not every monad could provide a meaningful map function and as a whole 
calling flatten after every map is a bit tiresome.


That may work for some monads, like List, because its effectively a range.
It will also work for Maybe monad. It could be viewed as a range of 0 
or 1 elements.
But things get bad when we try to define other monads in terms of range 
interface.


Current map implementation by design doesn't know anything about range 
it processes. If we try to define Promise monad as a range it will 
practically be useless unless we provide a custom map implementation 
for promises, because std.algorithm.map will return a wrapper range 
that will call popFront() that will block and wait for the value but 
that defeats the purpose entirely as we wanted the result to be mapped 
asynchronously when it will be available and not block.
What about other monads? Defining IO or

Re: Monads compared to InputRanges?

[Timon Gehr]

On 12/04/2013 12:02 AM, Shammah Chancellor wrote:


I get the gist of that, but it seems like the range concept with UFCS
provides the same thing? E.G.  range.map().flatten().map()?



Well, informally speaking, this is roughly an instance of a Monad.


Does it really not accomplish the same thing -- am I missing some key
point of monads?


The quick answer is that they are more general and would also capture 
eg. rooted trees with map and flatten operations, not just linear sequences.

Re: floating point comparison basics

[ed]

OK, I've had a look into the code in std.math finally understand 
it, I think. I was confused about maxRelativeError and 
maxAbsoluteError then I found this also:


http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
(...If you want to count numbers near zero but of opposite sign 
as being equal then you need to add a maxAbsoluteError check 
also. ...)



So my understanding is this:

1. If comparing to 0.0 then "fabs(lhs) < maxAbsoluteError" is OK
2. If comparing two floating point values X, Y: 
"fabs((lhs-rhs)/rhs) < maxRelativeError" is OK.


Reading elsewhere on the web (bad idea I know) I get the 
impression the ordering of lhs and rhs matters. Some code, as in 
the link above, is written as:


if(fabs(rhs) > fabs(lhs)) {
relErr = fabs((lhs-rhs)/rhs);
} else {
fabs((lhs-rhs)/lhs);
}
if(relErr < maxRelErr) { return true;}
else {return false;}

Why does Phobos not check lhs < rhs? Does this imply that in some 
cases:


approxEqual(X, Y) != approxEqual(Y, X) ??

Thanks,
Ed

Re: floating point comparison basics

[H. S. Teoh]

On Tue, Dec 03, 2013 at 11:03:48PM +0100, ed wrote:
> Hi All,
> 
> I'm learning programming and chose D because it is the best :D But,
> I've hit floating point numbers and I'm stuck on some of the basics.
> 
> What is the proper way to do floating point comparisons, in
> particular I need to check if a value is zero?

The first rule of floating-point comparisons is that you never use ==.
Well, not *literally* never (there are some cases where it's useful),
but you should never use == by default, and every time you do, you'd
better have a good reason for it.

As for why, see below.


> For example, given "real x = someCalculatingFunction();" how do I
> check if X is zero in a robust way.
> 
> if(x == 0.0) {} // <-- Will this work as expected?

Most likely, it will not. Unless you explicitly set x to 0.0 somewhere.
If x is the result of some complex computations, most likely it will not
be *exactly* 0.0. The correct way to compare floats is to write:

if (abs(x - y) < Epsilon)
{
// x and y are approximately equal
}

for some small-enough value of Epsilon.  Or, in your case:

if (abs(x) < Epsilon)
{
// x is approximately zero
}

So the first thing to know about floating-point is that it's only an
approximation, and because of that, (1) it is NOT the same as the real
numbers in mathematics, and (2) operations on floating-point values do
not always follow the same rules as mathematics.

For example:

float a = 1.0 / 5.0;
assert(a == 0.2);  // <--- this will FAIL

This is because 1/5 in binary has a non-terminating digit expansion
(much like 1/3 in decimal has a non-terminating digit expansion
0....). Since we can only store a finite number of digits in a
float, the digits have to be truncated past a certain point, and that
introduces a slight round-off error. The round-off error introduced by
the division operation in 1.0 / 5.0 is slightly different from the
round-off error introduced by converting the literal 0.2 into binary, so
1.0 / 5.0 == 0.2 fails to hold.

Another gotcha is that (x+y)+z is not always the same as x+(y+z), unlike
in mathematics.  If x is a very large number relative to y, (x+y) could
be truncated to just x, so writing (x+y)+z becomes the same as writing
x+z; but if z is of intermediate magnitude, then (y+z) could be a value
different from z, and so x+(y+z) will produce a different answer than
(x+y)+z.


[...]
> PS: I have read this great article and the links it provides:
> http://dlang.org/d-floating-point.html
> 
> Most of it makes sense but I'm struggling to tie it all together
> when it comes time to apply it.

Two rules of thumb with floating-point values:

(1) Never use == unless you have a good reason for it (and if you don't
know what constitutes a good reason, you don't have one, so don't use
it). Instead, compare abs(a-b) with a small constant value,
conventionally named Epsilon, that represents "close enough" for your
purposes (and this will differ depending on what you're trying to do in
your program).

(2) Don't assume that floating-point operations behave the same way as
mathematical operators. For example, x*x - y*y and (x+y)*(x-y) are the
same thing in math, but in floating-point arithmetic, the former is
vulnerable to catastrophic cancellation (which may produce garbled
results for certain inputs), whereas the latter will give a reasonably
accurate answer for all inputs. When in doubt, consult well-researched
resources on floating-point arithmetic, such as:

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html


T

-- 
Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are 
gone to milk the bull. -- Sam. Johnson

Re: Monads compared to InputRanges?

[Shammah Chancellor]

On 2013-12-03 21:51:20 +, Max Klyga said:


On 2013-12-03 02:45:44 +, Shammah Chancellor said:

I'm not particularly familiar with the syntax being used in the variet 
of monad examples.   I'm trying to figure out how this is different 
from UFCS on InputRanges.   It seems like std.algorithm implements 
something which accomplished the same thing, but much easier to 
understand?


Can somebody maybe do a compare and contrast for me?

-Shammah


Monads and input ranges are different things. I'll try to briefly 
explain monads. Hope this will not worsen the situation by being too 
confusing.


InputRanges provide a generic way for iterating over something.

UFCS can be used to create a range interface on things that do not provide it.

Monads are an abstraction for composing things within some context 
(concatenating lists, composing operations on nullable values, 
composing asynchronous operations). That sounds a bit too general and 
vague, because it is. One can think about as a design pattern.

Monad has two operations:
  - make a monad out of a value
  - apply a function that takes a value and returns a new monad of the 
same kind to value inside a monad


second operation has a different meaning for different monad kinds but 
generally it means 'execute this code within current context'


for nullable values this means 'execute only if there exist a value'
for asynchronous operations this means 'execute this when the value is ready'

This operation is commonly named 'bind' or 'flatMap'

Some languages provide syntax sugar for monads (Scala's for, Haskell's do)
Monads are easier to understand once you've seen enough examples of 
things that are monads.


Suppose you have a list of movies and want to produce a list of names 
of all actors stating in those movies.

In scala you would typically write something like this:

for (movie <- movies; actor <- movie.actors) yield actor.name

Compiler rewrites that to

movies.flatMap(movie => movie.actors).map(actor => actor.name)
   ^
    -- this function takes a list 
element and returns a new list, effectively creating a list of lists 
and then flattening it by concatenating all the lists into one, hence 
the name 'flatMap'. It transforms and then flattens.


Another popular example for Monads are optional values (similar to 
nullables but forcing you to check for presence of value and explicitly 
avoiding null dereferencing)


A common pattern for working with optional values is returning null 
from your function if your input is null


So if say we are parsing JSON and we want to process only values that 
contain certain field, that in turn contains another field. Example in 
pseudo-scala:


	for (value <- json.get("value"); // type of value is Option(JsonNode) 
meaning that actual json node might be absent
	   anotherValue <- value.get("another")) // this is executed only 
if value is present

doSomethingFancy(anotherValue) // ditto

and again, compiler will rewrite this into

	json.get("value").flatMap(value => 
value.get("another")).foreach(anotherValue => 
doSomethingFancy(anotherValue))


Once again we see that flat map is used. The pattern is same - get the 
value out of the box, transform it to another box of the same kind in 
the context meaningful for this particular box kind


So the main benefit is being able to compose things in a consistent 
way. Once you grasp the whole idea its fun finding out that some thing 
you've been doing can be viewed as a monad. People created quite a lot 
of different monads to this date.



I get the gist of that, but it seems like the range concept with UFCS 
provides the same thing? E.G.  range.map().flatten().map()?


Does it really not accomplish the same thing -- am I missing some key 
point of monads?  

floating point comparison basics

[ed]

Hi All,

I'm learning programming and chose D because it is the best :D 
But, I've hit floating point numbers and I'm stuck on some of the 
basics.


What is the proper way to do floating point comparisons, in 
particular I need to check if a value is zero?


For example, given "real x = someCalculatingFunction();" how do I 
check if X is zero in a robust way.


if(x == 0.0) {} // <-- Will this work as expected?

I see some code from others in my class doing this (mostly C++):

# if(fabs(x) < 1e-10) {} // <-- I've heard this is bad, is it?
# if(fabs(x) < std::numeric_limits::min()) {}
# if(fabs(x) < std::numeric_limits::epsilon()) {}
# if(!(fabs(x) > 0.0)) {}

# double eps = 1/(1/x);
# if(!(fabs(eps) > 0.0)) {}

So you can see we're all confused!

Thanks,
Ed

PS: I have read this great article and the links it provides:
http://dlang.org/d-floating-point.html

Most of it makes sense but I'm struggling to tie it all together 
when it comes time to apply it.

Re: Monads compared to InputRanges?

[Max Klyga]

On 2013-12-03 02:45:44 +, Shammah Chancellor said:

I'm not particularly familiar with the syntax being used in the variet 
of monad examples.   I'm trying to figure out how this is different 
from UFCS on InputRanges.   It seems like std.algorithm implements 
something which accomplished the same thing, but much easier to 
understand?


Can somebody maybe do a compare and contrast for me?

-Shammah


Monads and input ranges are different things. I'll try to briefly 
explain monads. Hope this will not worsen the situation by being too 
confusing.


InputRanges provide a generic way for iterating over something.

UFCS can be used to create a range interface on things that do not provide it.

Monads are an abstraction for composing things within some context 
(concatenating lists, composing operations on nullable values, 
composing asynchronous operations). That sounds a bit too general and 
vague, because it is. One can think about as a design pattern.

Monad has two operations:
 - make a monad out of a value
 - apply a function that takes a value and returns a new monad of the 
same kind to value inside a monad


second operation has a different meaning for different monad kinds but 
generally it means 'execute this code within current context'


for nullable values this means 'execute only if there exist a value'
for asynchronous operations this means 'execute this when the value is ready'

This operation is commonly named 'bind' or 'flatMap'

Some languages provide syntax sugar for monads (Scala's for, Haskell's do)
Monads are easier to understand once you've seen enough examples of 
things that are monads.


Suppose you have a list of movies and want to produce a list of names 
of all actors stating in those movies.

In scala you would typically write something like this:

for (movie <- movies; actor <- movie.actors) yield actor.name

Compiler rewrites that to

movies.flatMap(movie => movie.actors).map(actor => actor.name)
  ^
   -- this function takes a list 
element and returns a new list, effectively creating a list of lists 
and then flattening it by concatenating all the lists into one, hence 
the name 'flatMap'. It transforms and then flattens.


Another popular example for Monads are optional values (similar to 
nullables but forcing you to check for presence of value and explicitly 
avoiding null dereferencing)


A common pattern for working with optional values is returning null 
from your function if your input is null


So if say we are parsing JSON and we want to process only values that 
contain certain field, that in turn contains another field. Example in 
pseudo-scala:


	for (value <- json.get("value"); // type of value is Option(JsonNode) 
meaning that actual json node might be absent
	   anotherValue <- value.get("another")) // this is executed only 
if value is present

doSomethingFancy(anotherValue) // ditto

and again, compiler will rewrite this into

	json.get("value").flatMap(value => 
value.get("another")).foreach(anotherValue => 
doSomethingFancy(anotherValue))


Once again we see that flat map is used. The pattern is same - get the 
value out of the box, transform it to another box of the same kind in 
the context meaningful for this particular box kind


So the main benefit is being able to compose things in a consistent 
way. Once you grasp the whole idea its fun finding out that some thing 
you've been doing can be viewed as a monad. People created quite a lot 
of different monads to this date.

Re: stdout - autoflushing

[Adam D. Ruppe]

On Tuesday, 3 December 2013 at 20:36:22 UTC, Benji wrote:

I am using Xubuntu, 64bit, and GDC as compiler


Any IDE? I've seen ide consoles buffer differently because the 
runtime sees the target as a pipe instead of a user-interactive 
terminal.

Re: stdout - autoflushing

[Jesse Phillips]

On Tuesday, 3 December 2013 at 20:36:22 UTC, Benji wrote:

On Tuesday, 3 December 2013 at 19:33:47 UTC, Ali Çehreli wrote:

On 12/03/2013 09:12 AM, Benji wrote:

Hello,
in order to have correctly displayed output (before reading 
something

from stdin),
I must call stdout.flush().


I am surprised that you need that. What is your platform?

Normally, stdin and stdout are "tied". Reading from stdin 
flushes stdout automatically.


Ali


I am using Xubuntu, 64bit, and GDC as compiler


I haven't seen this behavior, though I haven't used GDC (debian 
is close enough right). This has been how I've retrieved user 
data:

https://github.com/JesseKPhillips/JPDLibs/blob/cmdln/cmdln/interact.d#L60

Re: stdout - autoflushing

[Ali Çehreli]

On 12/03/2013 12:36 PM, Benji wrote:

On Tuesday, 3 December 2013 at 19:33:47 UTC, Ali Çehreli wrote:

On 12/03/2013 09:12 AM, Benji wrote:

Hello,
in order to have correctly displayed output (before reading something
from stdin),
I must call stdout.flush().


I am surprised that you need that. What is your platform?

Normally, stdin and stdout are "tied". Reading from stdin flushes
stdout automatically.

Ali


I am using Xubuntu, 64bit, and GDC as compiler


I've known this to be the case for cin and cout of C++. So, I've been 
assuming that to be universally true. Apparently not for C and D 
behavior is based on C. I wish std.stdio gave us C++'s 'tie'.


Ali

P.S. This makes some of the examples at ddili.org incorrect as I never 
call flush. :-/

Re: stdout - autoflushing

[Benji]

On Tuesday, 3 December 2013 at 19:33:47 UTC, Ali Çehreli wrote:

On 12/03/2013 09:12 AM, Benji wrote:

Hello,
in order to have correctly displayed output (before reading 
something

from stdin),
I must call stdout.flush().


I am surprised that you need that. What is your platform?

Normally, stdin and stdout are "tied". Reading from stdin 
flushes stdout automatically.


Ali


I am using Xubuntu, 64bit, and GDC as compiler

Re: Freeing memory from C

[Chris]

On Tuesday, 3 December 2013 at 16:52:29 UTC, Ali Çehreli wrote:

On 12/03/2013 06:45 AM, Chris wrote:

> I became aware of uninitialized variable. I think that the
latter
> behavior is the correct one (segfault > crash). But why did
it work
> correctly in the other D program, how did the C variable get
initialized?

Undefined behavior sometimes manifests itself as working 
correctly. :)


True. The weird thing was that it seemed to work correctly in one 
program, i.e. during the test runs it calculated the right value 
of "int length;" and returned the string that was expected while 
it wasn't even initialized (!), and failed immediately in the 
other program defaulting to value -5180 or something (which is 
correct).


Regarding your original question, I suggest that the C library 
provides a function that frees the memory itself. The D code 
should just call that function with the pointer at hand.


Ali


You are right of course. Especially because I will need the C 
library for other languages like Python and I don't think they 
can handle it the way D can. Today the "hack" of freeing it from 
D worked well. The memory was freed correctly.

Re: stdout - autoflushing

[Ali Çehreli]

On 12/03/2013 09:12 AM, Benji wrote:

Hello,
in order to have correctly displayed output (before reading something
from stdin),
I must call stdout.flush().


I am surprised that you need that. What is your platform?

Normally, stdin and stdout are "tied". Reading from stdin flushes stdout 
automatically.


Ali

Re: stdout - autoflushing

[Benji]

On Tuesday, 3 December 2013 at 17:49:32 UTC, H. S. Teoh wrote:

On Tue, Dec 03, 2013 at 06:12:20PM +0100, Benji wrote:

Hello,
in order to have correctly displayed output (before reading
something from stdin),
I must call stdout.flush().
Sometimes, it's really annoying, especially when it is 
necessarry to

call it 10 times.

For example:
write("Enter some string: ");
stdout.flush();
string a = readln();
write("And again please: ");
stdout.flush();
string b = readln();
...

Is there any way to prevent this?


What about:

void prompt(A...)(string fmt, A args)
{
writef(fmt, args);
stdout.flush();
return readln();
}

auto a = prompt("Enter your name: ");
auto b = prompt("Enter your age: ").to!int;
... // etc.


T


Thanks, I didn't think about that (I'm beginner)

Re: How to install dmd2 in centos 5.3 x64

[Dejan Lekic]

On Tuesday, 3 December 2013 at 10:43:06 UTC, Puming wrote:

Hi:

I followed the steps in http://dlang.org/dmd-linux.html, but 
when I build a simple hello world program with:


rdmd hello.d

I get the following error:

rdmd hello.d
/usr/bin/ld: cannot find -l:libphobos2.a

I have copied dmd2/linux/lib64/libphobos2.a to /usr/lib64, but 
ld still can't find it.


Now I really wish all our servers are using ubuntu server..

Could anybody shed some light on where the problem is? I don't 
have much experience in linux except using apt-get in ubuntu.


Thanks.

Puming.


What architecture that CentOS box is, and give us your 
/etc/dmd.conf please.

Re: stdout - autoflushing

[H. S. Teoh]

On Tue, Dec 03, 2013 at 06:12:20PM +0100, Benji wrote:
> Hello,
> in order to have correctly displayed output (before reading
> something from stdin),
> I must call stdout.flush().
> Sometimes, it's really annoying, especially when it is necessarry to
> call it 10 times.
> 
> For example:
> write("Enter some string: ");
> stdout.flush();
> string a = readln();
> write("And again please: ");
> stdout.flush();
> string b = readln();
> ...
> 
> Is there any way to prevent this?

What about:

void prompt(A...)(string fmt, A args)
{
writef(fmt, args);
stdout.flush();
return readln();
}

auto a = prompt("Enter your name: ");
auto b = prompt("Enter your age: ").to!int;
... // etc.


T

-- 
If you think you are too small to make a difference, try sleeping in a closed 
room with a mosquito. -- Jan van Steenbergen

stdout - autoflushing

[Benji]

Hello,
in order to have correctly displayed output (before reading 
something from stdin),

I must call stdout.flush().
Sometimes, it's really annoying, especially when it is necessarry 
to call it 10 times.


For example:
write("Enter some string: ");
stdout.flush();
string a = readln();
write("And again please: ");
stdout.flush();
string b = readln();
...

Is there any way to prevent this?

Thread affinity?

[Rob T]

In core.thread I don't see a portable way to pin a thread to a 
specific core, or at least pin the thread to whatever core it is 
currently running in.


I found this solution, but it's for Windows only.

http://www.gamedev.net/blog/1140/entry-2254424-setting-thread-affinity-on-windows-in-d/

I can find solutions for pthread coded in C/C++, but I'm not sure 
how to apply these solutions when using the D Thread class. I may 
be able hack something out, but I need to be sure it's safe and 
correct.


http://stackoverflow.com/questions/1407786/how-to-set-cpu-affinity-of-a-particular-pthread

Any help is appreciated.

--rt

Re: Freeing memory from C

[Ali Çehreli]

On 12/03/2013 06:45 AM, Chris wrote:

> I became aware of uninitialized variable. I think that the latter
> behavior is the correct one (segfault > crash). But why did it work
> correctly in the other D program, how did the C variable get initialized?

Undefined behavior sometimes manifests itself as working correctly. :)

Regarding your original question, I suggest that the C library provides 
a function that frees the memory itself. The D code should just call 
that function with the pointer at hand.


Ali

Re: Is anything private by default when declared in a module?

[eles]

On Monday, 2 December 2013 at 21:28:48 UTC, lomereiter wrote:

On Monday, 2 December 2013 at 20:53:10 UTC, Namespace wrote:


OMG now I get it why in 2.064 importing std.regex makes visible 
std.uni.isWhite all of a sudden.


Unicorns cannot be white, as they are already pink & invisible. 
At least the std ones...


http://en.wikipedia.org/wiki/Invisible_Pink_Unicorn

Re: Is anything private by default when declared in a module?

[H. S. Teoh]

On Tue, Dec 03, 2013 at 04:16:04PM +0100, Adam D. Ruppe wrote:
[...]
> BTW private names should be outright invisible outside the module.
> At least private things at module scope. I get really annoyed with
> "public symbol foo from module bar conflicts with private symbol foo
> from module baz". Gee, I wonder which one I wanted to use???

Yeah, that's pretty annoying. Once I wrote a module that exports a
symbol that just so happens coincided with a private symbol in
std.regex, and the compiler complained all over the place about it.
Pretty annoying. Worse yet, the code *worked* when the code that
referenced that symbol was in the same module, but when it was moved out
during code reorg, it started to fail compiling. I was not very happy
with that. (And doesn't that go against what TDPL says, too?)


> But that's a separate issue.
> 
> >https://d.puremagic.com/issues/show_bug.cgi?id=314
> 
> wait, I thought Kenji fixed that? The comments don't say why it was
> reopened... did it just break too much Phobos code or was the fix
> wrong in some other way?

The pull linked to in the bug hasn't been merged yet.


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see 
through walls. It was called the "window".

Re: Is anything private by default when declared in a module?

[Adam D. Ruppe]

On Tuesday, 3 December 2013 at 07:34:37 UTC, Jonathan M Davis 
wrote:
They create a conflicting symbol in the importing module's 
scope.

That's why you should never use them at this point.


Well, that's sometimes useful, it helps get rid of conflict 
errors quickly, easily, and explicitly.


It should just be a private name in the new scope unless the 
import was public.


BTW private names should be outright invisible outside the 
module. At least private things at module scope. I get really 
annoyed with "public symbol foo from module bar conflicts with 
private symbol foo from module baz". Gee, I wonder which one I 
wanted to use???


But that's a separate issue.


https://d.puremagic.com/issues/show_bug.cgi?id=314


wait, I thought Kenji fixed that? The comments don't say why it 
was reopened... did it just break too much Phobos code or was the 
fix wrong in some other way?

Re: Freeing memory from C

[Adam D. Ruppe]

On Tuesday, 3 December 2013 at 12:43:08 UTC, bearophile wrote:
You can file an enhancement request for the documentation, or 
fix the docs yourself.


https://github.com/D-Programming-Language/dlang.org/pull/427

Re: How to install dmd2 in centos 5.3 x64

[Jordi Sayol]

El 03/12/13 14:10, Puming ha escrit:
> On Tuesday, 3 December 2013 at 11:17:27 UTC, Jordi Sayol wrote:
>> El 03/12/13 11:43, Puming ha escrit:
>>> Hi:
>>>
>>> I followed the steps in http://dlang.org/dmd-linux.html, but when I build a 
>>> simple hello world program with:
>>>
>>> rdmd hello.d
>>>
>>> I get the following error:
>>>
>>> rdmd hello.d
>>> /usr/bin/ld: cannot find -l:libphobos2.a
>>>
>>> I have copied dmd2/linux/lib64/libphobos2.a to /usr/lib64, but ld still 
>>> can't find it.
>>>
>>
>> $ rdmd -L-L/usr/lib64 a.d
>>
> 
> still get the same error.

Is "libphobos2.a" the same arch than the program you're building?

> 
>> You can permanently add this to dmd command-line by creating
> 
> I was using the default dmd.conf in the .zip package
> 
> 
>> "dmd.conf" file: 
>>
>>> Now I really wish all our servers are using ubuntu server..
>>>
>>> Could anybody shed some light on where the problem is? I don't have much 
>>> experience in linux except using apt-get in ubuntu.
>>
>> On Debian based systems, like Ubuntu, you can use "d-apt" repository: 
>> 
> 
> Yes, I was using that at home.
> 
>>
>>>
>>> Thanks.
>>>
>>> Puming.
> 
> 

-- 
Jordi Sayol

Re: Freeing memory from C

[Chris]

On Tuesday, 3 December 2013 at 14:18:35 UTC, John Colvin wrote:

On Tuesday, 3 December 2013 at 13:05:20 UTC, Mike Parker wrote:

On 12/3/2013 9:31 PM, John Colvin wrote:


You should be fine to free in that way as long as you haven't 
done

anything crazy like separately static linking libc.



I wouldn't advise this in the general case. When you have 
complete end-to-end control, sure. But if, for example, you're 
using a dynamic binding to load a shared library, all bets are 
off. Most likely on Linux and Mac you'll be fine. But on 
Windows, the shared lib could have been compiled with DMC, 
GCC, MSVC, or who knows what else.


Fair point.

What I should have said is:

This is fine as long as you know you that both the C code and D 
code will be using the same so/dll/dylib C runtime.


It's worth noting that the situation is not specific to D: it's 
exactly the same as freeing memory in C that you got from a 
library. If they are using different runtimes, or even 
different instances of the same runtime, all bets are off. At 
best, your memory won't get freed, at worst it will cause 
corruption.


As with all C code I can only say I _hope_ I know what I'm doing. 
The C code is compiled into a library and linked to the D program 
 at compile time. It's one executable. So I hope that's fine.


I noticed a strange behavior though. In my C code I had an 
uninitialized variable[1], the "int length;" mentioned above. 
When I compiled it to a library and linked it with my program, 
everything worked fine, the string was allocated correctly and 
came out as expected, i.e. the length was calculated correctly 
with "length += otherlength;". However, when I moved the same 
library to my vibe.d project, compiled and linked, I got a 
segmentation fault and the program crashed. It wasn't until then, 
that I became aware of uninitialized variable. I think that the 
latter behavior is the correct one (segfault > crash). But why 
did it work correctly in the other D program, how did the C 
variable get initialized?



[1] a D habit not to write "int i = 0;", but just "int i;", being 
the spoiled D-brat I am

Re: Freeing memory from C

[Chris]

On Tuesday, 3 December 2013 at 13:05:20 UTC, Mike Parker wrote:

On 12/3/2013 9:31 PM, John Colvin wrote:


You should be fine to free in that way as long as you haven't 
done

anything crazy like separately static linking libc.



I wouldn't advise this in the general case. When you have 
complete end-to-end control, sure. But if, for example, you're 
using a dynamic binding to load a shared library, all bets are 
off. Most likely on Linux and Mac you'll be fine. But on 
Windows, the shared lib could have been compiled with DMC, GCC, 
MSVC, or who knows what else.


Fortunately, I have end-to-end control. It is a bit of a hack and 
I'm not too happy with it. But as long as it doesn't leak, it'll 
do for now.

Re: Freeing memory from C

[John Colvin]

On Tuesday, 3 December 2013 at 13:05:20 UTC, Mike Parker wrote:

On 12/3/2013 9:31 PM, John Colvin wrote:


You should be fine to free in that way as long as you haven't 
done

anything crazy like separately static linking libc.



I wouldn't advise this in the general case. When you have 
complete end-to-end control, sure. But if, for example, you're 
using a dynamic binding to load a shared library, all bets are 
off. Most likely on Linux and Mac you'll be fine. But on 
Windows, the shared lib could have been compiled with DMC, GCC, 
MSVC, or who knows what else.


Fair point.

What I should have said is:

This is fine as long as you know you that both the C code and D 
code will be using the same so/dll/dylib C runtime.


It's worth noting that the situation is not specific to D: it's 
exactly the same as freeing memory in C that you got from a 
library. If they are using different runtimes, or even different 
instances of the same runtime, all bets are off. At best, your 
memory won't get freed, at worst it will cause corruption.

Re: How to install dmd2 in centos 5.3 x64

[Puming]

On Tuesday, 3 December 2013 at 11:17:27 UTC, Jordi Sayol wrote:

El 03/12/13 11:43, Puming ha escrit:

Hi:

I followed the steps in http://dlang.org/dmd-linux.html, but 
when I build a simple hello world program with:


rdmd hello.d

I get the following error:

rdmd hello.d
/usr/bin/ld: cannot find -l:libphobos2.a

I have copied dmd2/linux/lib64/libphobos2.a to /usr/lib64, but 
ld still can't find it.




$ rdmd -L-L/usr/lib64 a.d



still get the same error.


You can permanently add this to dmd command-line by creating


I was using the default dmd.conf in the .zip package



"dmd.conf" file: 


Now I really wish all our servers are using ubuntu server..

Could anybody shed some light on where the problem is? I don't 
have much experience in linux except using apt-get in ubuntu.


On Debian based systems, like Ubuntu, you can use "d-apt" 
repository: 


Yes, I was using that at home.





Thanks.

Puming.

Re: Freeing memory from C

[Mike Parker]

On 12/3/2013 9:31 PM, John Colvin wrote:


You should be fine to free in that way as long as you haven't done
anything crazy like separately static linking libc.



I wouldn't advise this in the general case. When you have complete 
end-to-end control, sure. But if, for example, you're using a dynamic 
binding to load a shared library, all bets are off. Most likely on Linux 
and Mac you'll be fine. But on Windows, the shared lib could have been 
compiled with DMC, GCC, MSVC, or who knows what else.

Re: How to install dmd2 in centos 5.3 x64

[Puming]

On Tuesday, 3 December 2013 at 11:10:13 UTC, lomereiter wrote:

Did you install binaries or build the compiler from source?


I used the dmd.2.064.2.zip, because when I install the rpm 
binary, it says there are dependency issues.

Re: Freeing memory from C

[bearophile]

Chris:

std.c.stdlib.free() is mentioned on the "How to interface to C" 
page (http://dlang.org/interfaceToC.html). So maybe that needs 
an update.


You can file an enhancement request for the documentation, or fix 
the docs yourself.


I'll file a little bug report for the other library deprecation 
problem.


Bye,
bearophile

Re: Freeing memory from C

[Chris]

On Tuesday, 3 December 2013 at 12:31:16 UTC, John Colvin wrote:

On Tuesday, 3 December 2013 at 10:57:51 UTC, Chris wrote:
I have a C module that dynamically allocates memory for a 
string like so:


char *result = (char*)malloc(length + 1); // 'length' has been 
calculated


When I call it from D (via extern (C)), is it ok to free it 
from there like so:


void callFunction() {
 auto result = callToCFunction(); // Returns above *result
 // ...
 std.c.stdlib.free(result);
}

The problem is that, as it is now, *result is allocated in a 
different place in the C module (not in "callToCFunction()) 
and cannot be freed before D has called it.


If D cannot free it in this way, I'll have a serious memory 
leak and I'll have to rewrite the existing C module (which is 
probably better given the awkward situation above).


You should be fine to free in that way as long as you haven't 
done anything crazy like separately static linking libc.


core.stdc.stdlib; is the correct module to use, std.c.* only 
exist for backwards compatibility.


Ok. Thanks for the answer. std.c.stdlib.free() is mentioned on 
the "How to interface to C" page 
(http://dlang.org/interfaceToC.html). So maybe that needs an 
update.

Re: Freeing memory from C

[John Colvin]

On Tuesday, 3 December 2013 at 10:57:51 UTC, Chris wrote:
I have a C module that dynamically allocates memory for a 
string like so:


char *result = (char*)malloc(length + 1); // 'length' has been 
calculated


When I call it from D (via extern (C)), is it ok to free it 
from there like so:


void callFunction() {
  auto result = callToCFunction(); // Returns above *result
  // ...
  std.c.stdlib.free(result);
}

The problem is that, as it is now, *result is allocated in a 
different place in the C module (not in "callToCFunction()) and 
cannot be freed before D has called it.


If D cannot free it in this way, I'll have a serious memory 
leak and I'll have to rewrite the existing C module (which is 
probably better given the awkward situation above).


You should be fine to free in that way as long as you haven't 
done anything crazy like separately static linking libc.


core.stdc.stdlib; is the correct module to use, std.c.* only 
exist for backwards compatibility.

Re: How to install dmd2 in centos 5.3 x64

[Jordi Sayol]

El 03/12/13 11:43, Puming ha escrit:
> Hi:
> 
> I followed the steps in http://dlang.org/dmd-linux.html, but when I build a 
> simple hello world program with:
> 
> rdmd hello.d
> 
> I get the following error:
> 
> rdmd hello.d
> /usr/bin/ld: cannot find -l:libphobos2.a
> 
> I have copied dmd2/linux/lib64/libphobos2.a to /usr/lib64, but ld still can't 
> find it.
> 

$ rdmd -L-L/usr/lib64 a.d

You can permanently add this to dmd command-line by creating "dmd.conf" file: 


> Now I really wish all our servers are using ubuntu server..
> 
> Could anybody shed some light on where the problem is? I don't have much 
> experience in linux except using apt-get in ubuntu.

On Debian based systems, like Ubuntu, you can use "d-apt" repository: 


> 
> Thanks.
> 
> Puming.
> 

-- 
Jordi Sayol

Re: How to install dmd2 in centos 5.3 x64

[lomereiter]

Did you install binaries or build the compiler from source?

Freeing memory from C

[Chris]

I have a C module that dynamically allocates memory for a string 
like so:


char *result = (char*)malloc(length + 1); // 'length' has been 
calculated


When I call it from D (via extern (C)), is it ok to free it from 
there like so:


void callFunction() {
  auto result = callToCFunction(); // Returns above *result
  // ...
  std.c.stdlib.free(result);
}

The problem is that, as it is now, *result is allocated in a 
different place in the C module (not in "callToCFunction()) and 
cannot be freed before D has called it.


If D cannot free it in this way, I'll have a serious memory leak 
and I'll have to rewrite the existing C module (which is probably 
better given the awkward situation above).

How to install dmd2 in centos 5.3 x64

[Puming]

Hi:

I followed the steps in http://dlang.org/dmd-linux.html, but when 
I build a simple hello world program with:


rdmd hello.d

I get the following error:

rdmd hello.d
/usr/bin/ld: cannot find -l:libphobos2.a

I have copied dmd2/linux/lib64/libphobos2.a to /usr/lib64, but ld 
still can't find it.


Now I really wish all our servers are using ubuntu server..

Could anybody shed some light on where the problem is? I don't 
have much experience in linux except using apt-get in ubuntu.


Thanks.

Puming.

Re: Associative array references

[Atila Neves]

On Monday, 2 December 2013 at 16:52:51 UTC, bearophile wrote:

Atila Neves:


How would that go in this case?


An example usage:

void main() {
int[float][string] aa;
aa["foo"][1.5] = 1;
}

Bye,
bearophile


Oh. That makes sense. Doh!

I guess I was focussing on "key to AA of..." and that's why I 
wrote it that way.

Re: Associative array references

[Atila Neves]

On Tuesday, 3 December 2013 at 03:14:46 UTC, Jesse Phillips wrote:

On Monday, 2 December 2013 at 13:30:44 UTC, Atila Neves wrote:
It seems that assigning an AA to another makes both point at 
the same data only if the first array has data to begin with. 
Is that the expected behaviour?


Atila


You've been hit by the null associative array not being the 
same as an empty associative array. See discussion:


http://forum.dlang.org/post/wovnuggqtscsbgnjc...@forum.dlang.org


Sigh. If at least there was a way to declare them empty...

Re: enum value vs. immutable

[Maxim Fomin]

On Tuesday, 3 December 2013 at 08:28:23 UTC, Ali Çehreli wrote:


That works for some types as both enum and immutable have their 
problems:


* enum is no good for arrays and AAs as it is very likely to be 
unnecessarily slow.


* immutable is no good for types that contain mutable 
references at least during assignment:


struct S
{
int i;
int[] others;
}

void main()
{
auto a = S(42);
immutable b = a;
// Error: cannot implicitly convert expression (a) of type S to 
immutable(S)

}


Kenji is working on this
http://wiki.dlang.org/DIP49


> It is C++ism like follwoing code:
>
> struct S { public: this(type){} ... }
>
> or
>
> static Type t; // in module scope

Both of those do happen. ;)

Ali


Yes, this isn't good at all.

Re: Monads compared to InputRanges?

[Ali Çehreli]

On 12/02/2013 06:45 PM, Shammah Chancellor wrote:

> I'm not particularly familiar with the syntax being used in the variet
> of monad examples.   I'm trying to figure out how this is different from
> UFCS on InputRanges.   It seems like std.algorithm implements something
> which accomplished the same thing, but much easier to understand?

I think so. I could understand ranges but I still cannot understand 
monads! :p (That category theory thing is always in the way.)


> Can somebody maybe do a compare and contrast for me?

Me too! :)

> -Shammah
>

Ali

Re: enum value vs. immutable

[Ali Çehreli]

On 12/01/2013 11:48 PM, Maxim Fomin wrote:

>> 1) Prefer enum first because enum values can be used for template
>> instantiations.
>
> You can instatiate templates not only with enums. Main pro for enums is
> that they are CT values.

The confusion is, some const values are CT values as well.

>> 3) Prefer const last as it erases immutable attribute if present. (We
>> can't know just by looking at a reference to const whether the
>> original value has been immutable or mutable.)
>
> It is interesting to know where such advices come from. Const in D is
> useless except as as parameter qualifier, method qualifier, tool to
> alias const data and non-const data and as qualifier of some field -
> member of aggregate.
>
> Writing code like
>
> const int i = SOME_VALUE;
>
> is loosing advantages of immutable or enum while gaining nothing in 
return.


That works for some types as both enum and immutable have their problems:

* enum is no good for arrays and AAs as it is very likely to be 
unnecessarily slow.


* immutable is no good for types that contain mutable references at 
least during assignment:


struct S
{
int i;
int[] others;
}

void main()
{
auto a = S(42);
immutable b = a;
// Error: cannot implicitly convert expression (a) of type S to immutable(S)
}

> It is C++ism like follwoing code:
>
> struct S { public: this(type){} ... }
>
> or
>
> static Type t; // in module scope

Both of those do happen. ;)

Ali

Re: equivalent of python join?

[Ali Çehreli]

On 12/02/2013 11:32 PM, Jacob Carlborg wrote:

> On 2013-12-03 07:36, CJS wrote:
>> In python a common performance tip for joining many strings together is
>> to use the join method. So, for example, instead of
>> "a" + "b" + "c"
>> use
>> ''.join(["a","b","c"]).
>> The idea is to avoid creating temporary objects that are immediately
>> thrown away. It's obviously overkill for such a small number of strings,
>> though.
>>
>> Is there any equivalent method/advice when concatenating many strings
>> together in D?
>
> There's std.algorithm.joiner[1] and std.array.join[2]. I don't know if
> they're any more efficient than using "~".

They are more efficient in the sense that they are lazy.

> There's also
> std.array.Appender[3] if you want to do a lot of appending and want the
> most efficient way.
>
> [1] http://dlang.org/phobos/std_algorithm.html#joiner
> [2] http://dlang.org/phobos/std_array.html#.join
> [3] http://dlang.org/phobos/std_array.html#.Appender

There is also the more general std.range.chain. It can join any type of 
range as long as the element types are the same:


import std.stdio;
import std.range;
import std.algorithm;

void main()
{
auto a_lazy_range_of_ints
= chain(5.iota,
[ 10, 9, 20, 8 ].filter!(a => a < 10));

// writeln consumes the range eagerly
writeln(a_lazy_range_of_ints);

// Prints [0, 1, 2, 3, 4, 9, 8]
}

Ali