Re: version and configuration

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 14:41:45 UTC, Spacen Jasset
It appears that I can't put this in a module and import it 
elsewhere to test the version specifications as they are all in 
their own namespaces. Is this then a dead end for having a 
feature configuration file?


Correct, version doesn't get imported. You're better off using 
enums or ordinary variables.

Re: Mixin templates accessing mixed out scope

[Prudence via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 17:11:04 UTC, anonymous wrote:

On Saturday 12 September 2015 16:30, Ali Çehreli wrote:


Reduced:

[...]

Error: type SingleStore is not an expression


Reduced further:


class MyStore
{
class SingleStore
{
static void New() // Removing 'static' compiles
{
new SingleStore();
}
}
}


And now the problem can be spotted:

SingleStore is a nested class. That means, instances of it are 
bound to MyStore instances. But New is static, so it doesn't 
have a MyStore to which it could attach the `new SingleStore`.


That error message is pretty awful. I filed an issue: 
https://issues.dlang.org/show_bug.cgi?id=15049


like most D errors ;/ it's the #1 problem I'm struggling with in 
D. Remember there's another error with remove, that isn't 
releated to SingleStore.


As for a fix: I guess SingleStore isn't supposed to be a nested 
class. Mark it static then.


NO! That is the whole point!

SingleStore is a momento that wraps the key value pair, e.g.,

auto t = DeleteStore.New("mycooldelegate", (int x) { return true; 
});


t is suppose to be a single store.

then

t.Remove();

removes the delegate from the store.

Note I don't have to know the actual key or delegate!! Which is 
the whole point!


Else it would lool like this:

store[][string] mydelegatestore;

auto dg = (int x) { return true; };
mydelegatestore["mycooldelegate"] ~= dg;

then

mydelegatestore["mycooldelegate"].remove(d => dg == d);

which requires remembering both the key and the delegate, which 
makes using inline lambdas infeasible(because you'll never be 
able to remove them).


I see no reason why SingleStore has to be static. The mixin 
template should insert all that stuff into the class, which, by 
the way, works...


I've also used that New pattern all that time and it works, maybe 
not for nested classes. Moving SingleStore outside the template 
works.




I've fixed the issue with that, it's not as pretty but works. 
Still have the remove error:









import std.stdio;
import std.concurrency;



extern (C) int getch();
import std.string;
import std.concurrency;
import core.time;
import core.thread;
import std.container.array;
import std.typecons;







public class SingleStore(TKey, TValue)
{
public TValue Value;
public TKey Key;
public TValue[][TKey] Store;
public auto Remove()
{
import std.algorithm;
		remove!(c => Value == c")(Store[this.Key], 
SwapStrategy.unstable);	 // Not working, can't disambiguate

}

public static auto New(TKey k, TValue v, ref TValue[][TKey] s)
{
auto o = new SingleStore!(TKey, TValue)(k, v);  
o.Store = s;
return o;
}

private this(TKey k, TValue v)
{
Key = k;
Value = v;
}
}

public mixin template ObjectStore(TKey, TValue)
{
public static TValue[][TKey] store;

public static auto New(TKey k, TValue v)
{
(store[k]) ~= v;
auto o = SingleStore!(TKey, TValue).New(k, v, store);
o.store = store;
return o;
}


}


class MyStore
{
mixin ObjectStore!(string, bool delegate(int));


}

void main()
{
	auto s = MyStore.New("x", (int x) { return true; }); // works, 
stores delegate in MyStore


	s.Remove();  // Doesn't work because std.algorithm's remove 
isn't working


getch();
}

(The whole point of nesting was so I wouldn't have to explicitly 
create a pointer to the store in SingleStore. Should have worked, 
probably another one of D's bugs)

Re: Floating point in the type system

[via Digitalmars-d]

On Saturday, 12 September 2015 at 19:02:16 UTC, Robert wrote:
For what it's worth, I was investigating this initially as a 
discussion about adding type-level values in Rust, and how to 
handle unusual cases like this.


C++ does not allow it. And frankly, having more than a single 
integer value type as a value parameter in C++ templates is a 
pointless PITA.


I think Go got literal constant values right: make them untyped 
until bound.

Re: Type helpers instead of UFCS

[BBasile via Digitalmars-d]

On Saturday, 12 September 2015 at 20:54:09 UTC, Enamex wrote:
On Saturday, 12 September 2015 at 20:40:35 UTC, Adam D. Ruppe 
wrote:

On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote:

- code completion in IDE. It'will never work.


Why not? I haven't actually tried it, but it seems like a 
pretty easy problem, except perhaps with complex templates.



- noobs, code is unreadable.


meh


[...]
With a dedicated syntax, specific functions/groups-of-functions 
could be easily recognized as extensions of a type and could 
even be made to be recognized by templates


You've got the idea. IDE plugins can not decently provide 
completion based on the UFCS possibilities. With something like a 
type helper, it's more likely to work.

Re: module std.stream is deprecated - Will be removed by phobos version 2.070

[Jonathan M Davis via Digitalmars-d]

On Saturday, 12 September 2015 at 14:26:10 UTC, Jacob Carlborg 
wrote:

On 2015-09-12 03:23, Jonathan M Davis wrote:

Though, now that I think about it, we should probably also put 
it in

undead now.


I think it can be put in undead as soon as something is 
deprecated or to-be-deprecated in the documentation.


That's probably a good policy, but it hadn't occurred to me until 
we were discussing it here.


- Jonathan M Davis

Re: Calling D from C, C++, Python…

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 09:47:55 UTC, Jacob Carlborg 
wrote:
Well, if your D function doesn't use anything of the runtime I 
guess it's not necessary.


Right. If you don't call into the threading system in the 
druntime, you should be ok. Keep in mind though that the GC uses 
the threads and the new expression, array literals, array 
append, and others use the GC.


Runtime.initialize is also what calls static and module 
constructors... and might have responsibility for fixing up 
dynamic casting of class objects in a shared lib too, I'm not 
sure about that.


But if you avoid the bulk of the runtime functions, indeed you 
can get away without initializing it. Just that null thread 
handle is likely to cause segfaults in places where you might not 
expect if you don't.


It is best to initialize it. Lots of C libraries need an init an 
teardown call, so surely the Python interop provides some 
solution for it. idk what it would be though.

[Issue 12210] dlang.org home page example - Run button does not work

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12210

Vladimir Panteleev  changed:

   What|Removed |Added

 Depends on||15051

--

[Issue 15051] New: Code that runs fine on dpaste.dzfl.pl refuses to run on dlang.org

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15051

  Issue ID: 15051
   Summary: Code that runs fine on dpaste.dzfl.pl refuses to run
on dlang.org
   Product: D
   Version: D2
  Hardware: All
   URL: http://dpaste.dzfl.pl/81b0c9d09e3f
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nazriel6...@gmail.com
  Reporter: thecybersha...@gmail.com
Blocks: 12210

E.g.:


import std.regex;

static reFloatingPoint = ctRegex!`[0-9]+\.[0-9]+`;

void main() {}


When run from dlang.org (click "Edit" under any example, paste code, click
"Run"), it results in:

Compilation output (255: Unknown signal 255)
unable to fork: Cannot allocate memory

However, it runs fine on dpaste.dzfl.pl.

This is blocking e.g. the floating-point example on dlang.org.

--

Re: Reasons to use D

[via Digitalmars-d]

On Saturday, 12 September 2015 at 18:48:52 UTC, Adam D. Ruppe 
wrote:
On Saturday, 12 September 2015 at 18:44:44 UTC, Ola Fosheim 
Grøstad wrote:
Arrayviews ("slices") are available as a type so you can do it 
like this:


Yeah, there's also the Array.slice and String.substring that 
work kinda similarly in old standard javascript.


Array.slice create value copies, not reference views. I don't 
think there is a "slice" for Array. :-/


But there's still a lot of type-specific verbiage in there, 
whereas with D, it is always the same [a .. $] for almost 
anything so it is one thing to remember instead of three or 
more.


Yes. So, let's create a TypeScript like subset of:D.

Compile GC-based D-JS -> JavaScript + TypeScript definitions.

The problem is that you might need a little bit of Dependent 
Typing in order to provide types for the browser API. I.e. return 
type depending on parameter values? Not sure.

Rust style memory management

[Freddy via Digitalmars-d]

So I saw this video: 
https://air.mozilla.org/guaranteeing-memory-safety-in-rust/ and 
was amazed. Is there any way we can implement this in D? What 
language extensions would be required?


My idea on implement this would be to add 3 new pointer (and 
array) types : [owned,shared immutable,borrow mutable] and depend 
on casting raw pointers to the new types.


Thoughts?

Re: Type helpers instead of UFCS

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote:

- code completion in IDE. It'will never work.


Why not? I haven't actually tried it, but it seems like a pretty 
easy problem, except perhaps with complex templates.



- noobs, code is unreadable.


meh

Re: shared array?

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 22:36:00 UTC, Laeeth Isharc 
wrote:
Thank you for this.  How large is the allocation for closure 
for a delegate?  Just a pair of pointers?


It depends on what the delegate needs to capture. It makes a copy 
of the local variables the function is referencing. (Usually 
pretty small I'd gamble; how big are your typical function's 
arguments and local vars?)

Re: Type helpers instead of UFCS

[Idan Arye via Digitalmars-d]

On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote:
That's why I propose the new keywords 'helper' and 'subject' 
that will allow to extend the properties pre-defined for a 
type, as long as the helper is imported:


---
module myhelper;
helper for subject : string


Do we really need a 3-keyword chain? What's wrong with a simple 
`helper : string` or `helper(string)`?



{
void writeln()
{
import std.stdio;
writeln(subject);
}
}
---


Why `subject` to refer to the string the function gets called on? 
What's wrong with good old `this`, which is used for this purpose 
everywhere else?

Re: shared array?

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote:
Using it at all is a problem because one doesn't know when and 
where.


It is called when the collect function is called and where it was 
called from.


D's garbage collector isn't magic, it is just a function that 
frees memory when the pool runs low.


It's like playing Russian roulette. It doesn't matter if only 
1/6 times will kill you. It's totally different than 0/6.


The big difference is the garbage collector doesn't actually kill 
you.


Memory corruption, use-after-free, and double-free bugs on the 
other hand often do terminate your process.

Re: Moving forward with work on the D language and foundation

[BBasile via Digitalmars-d-announce]

On Friday, 28 August 2015 at 12:28:43 UTC, Russel Winder wrote:
On Thu, 2015-08-27 at 16:01 +, BBasile via 
Digitalmars-d-announce wrote:

[…]

That's courageous, particularly past 50 yo. It's a different 
culture, past 50 yo in Europe people choose security, but in 
USA, past 50 yo some people still take the risk to try 
something new. Awesome.


I say "bollocks" to your accusation that Europeans post 50 are 
a bunch of useless idiots.


I call double "bollocks" on the claim that only in the USA do 
people do anything.


https://www.google.fr/maps/@51.4602279,-0.1695423,3a,68.5y,2.82h,52.97t/data=!3m6!1e1!3m4!1shQpIZlKwZL_k_IzgQSA-aw!2e0!7i13312!8i6656!6m1!1e1

I say that you could still sort your waste. Never mind the 
Bollocks.

Re: Reasons to use D

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 12 September 2015 at 16:34:42 UTC, Meta wrote:
Maybe because the static type system allows for overloading and 
so all of these utility functions don't have to do a million 
different things depending on what you pass to them.


Yea. Another huge thing to me is the slice operator. I use it for 
a lot of stuff and it is consistent for strings and other arrays. 
(well, utf issues aside, but D's rule there is simple enough to 
remember too)

Re: Calling D from C, C++, Python…

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 18:20:37 UTC, Brad Roberts 
wrote:
You can get away with it in some circumstances, but it's at 
your own risk.


Yeah, I agree.

Re: I guess this is a bug?

[anonymous via Digitalmars-d-learn]

On Saturday 12 September 2015 20:28, Random D user wrote:

> prints (with option B):
> bar: 0.00, 0.00   // BUG??
> baz: 1.00, 2.00

Looks like a bug to me. Please file an issue at https://issues.dlang.org/

Re: Reasons to use D

[via Digitalmars-d]

On Saturday, 12 September 2015 at 18:23:55 UTC, Adam D. Ruppe 
wrote:

On Saturday, 12 September 2015 at 16:34:42 UTC, Meta wrote:
Maybe because the static type system allows for overloading 
and so all of these utility functions don't have to do a 
million different things depending on what you pass to them.


Yea. Another huge thing to me is the slice operator. I use it 
for a lot of stuff and it is consistent for strings and other 
arrays. (well, utf issues aside, but D's rule there is simple 
enough to remember too)


Arrayviews ("slices") are available as a type so you can do it 
like this:


a = new Uint32Array([7,2,3,6]) // a is [7, 2, 3, 6]
b = a.subarray(1,3) // b reference [2, 3]
b[0] = 8 // now a is [7, 8, 3, 6]
a.set([5,9], 2) // now a is [7,8,5,9]

Destructuring is coming too. So you can destructure arrays as if 
they are tuples. E.g.:


var a,b;
[a,b] = [2,4]
[a,b] = [b,a]

I think it might work in TypeScript or some of the other 
compilers already.

[Issue 15036] SimpleDllMain assumes various symbols are available unqualified

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15036

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull
 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/D-Programming-Language/druntime/pull/1385

--

[Issue 15043] [e2ir] dmd still crashes when trying to set a delegate from __traits(getOverloads)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15043

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|nob...@puremagic.com|k.hara...@gmail.com

--- Comment #2 from bb.t...@gmx.com ---
he knows the topic.

--

Re: Moving forward with work on the D language and foundation

[BBasile via Digitalmars-d-announce]

On Saturday, 12 September 2015 at 22:28:49 UTC, BBasile wrote:

On Friday, 28 August 2015 at 12:28:43 UTC, Russel Winder wrote:
On Thu, 2015-08-27 at 16:01 +, BBasile via 
Digitalmars-d-announce wrote:

[…]

That's courageous, particularly past 50 yo. It's a different 
culture, past 50 yo in Europe people choose security, but in 
USA, past 50 yo some people still take the risk to try 
something new. Awesome.


I say "bollocks" to your accusation that Europeans post 50 are 
a bunch of useless idiots.


I call double "bollocks" on the claim that only in the USA do 
people do anything.


Never mind the bollocks.

:handshake:


https://www.youtube.com/watch?v=aKLpeNJ9zZo

don't let your dishes just in front of your house.

Re: Rust style memory management

[Adam D. Ruppe via Digitalmars-d]

Try using the -dip25 switch to dmd, it does one more step in D 
toward making a borrow thingy. Nowhere near the level Rust does 
it, but combined with other library things like destructors, 
prohibiting copying, etc., it can kinda make a owned thing with 
borrowed bits.

[Issue 15049] New: bad error message when trying to instantiate a nested class in a static method

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15049

  Issue ID: 15049
   Summary: bad error message when trying to instantiate a nested
class in a static method
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: diagnostic
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Found by Prudence, reduced by Ali Çehreli and myself:
http://forum.dlang.org/post/sggmxddjpqpaookmw...@forum.dlang.org

The following code is invalid, but the error message should be improved:


class MyStore
{
class SingleStore
{
static void New()
{
new SingleStore(); /* line 7 */
}
}
}

test.d(7): Error: type SingleStore is not an expression


SingleStore is a nested class. That means, instances of it are bound to MyStore
instances. But New is static, so it doesn't have a MyStore to which it could
attach the `new SingleStore`.

When moving New to MyStore the error gets better:


class MyStore
{
class SingleStore
{
}
static void New()
{
new SingleStore(); /* line 8 */
}
}

test.d(8): Error: 'this' is only defined in non-static member functions, not
New
test.d(8): Error: 'this' for nested class must be a class type, not _error_


That's still a bit stilted, but a lot better than the other one.

--

Re: I guess this is a bug?

[Random D user via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 18:28:02 UTC, Random D user 
wrote:

or is it some obscure feature conflict?

[...]


Oh... and I'm using win 64-bit and dmd 2.068.1, but this behavior 
was present earlier than that...

Re: Reasons to use D

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 12 September 2015 at 18:59:11 UTC, Ola Fosheim 
Grøstad wrote:
Array.slice create value copies, not reference views. I don't 
think there is a "slice" for Array. :-/


Right, that's why I said "kinda similarly"... the copy is really 
important if you want to mutate it, but it is good enough for 
viewing (tho poorly performing by comparsion).



Compile GC-based D-JS -> JavaScript + TypeScript definitions.


That's basically what my D->JS thing did back in 2011.

The problem is that you might need a little bit of Dependent 
Typing in order to provide types for the browser API. I.e. 
return type depending on parameter values? Not sure.


That doesn't actually happen very often, and when it does, you 
can do a function overload like string foo(string s) { return s;} 
vs int foo(int i) { return i; } and it works in D land pretty 
well. Then use a pragma(mangle) to make both refer to the same 
browser function.


That actually worked somewhat well in my dtojs but it was a mild 
hassle too once function callbacks got more involved. You can 
template them in D but then it bloats the generated JS for no 
real reason since they all have identical dynamically typed code! 
I suppose that is solvable too but i never got around to it and 
just went back to writing normal javascript. (I write small JS 
files anyway, it is an ok language for small scripts.)

Re: Type helpers instead of UFCS

[BBasile via Digitalmars-d]

On Saturday, 12 September 2015 at 20:40:35 UTC, Adam D. Ruppe 
wrote:

On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote:

- code completion in IDE. It'will never work.


Why not? I haven't actually tried it, but it seems like a 
pretty easy problem, except perhaps with complex templates.



- noobs, code is unreadable.


meh


meh too.

Re: Moving forward with work on the D language and foundation

[BBasile via Digitalmars-d-announce]

On Friday, 28 August 2015 at 12:28:43 UTC, Russel Winder wrote:
On Thu, 2015-08-27 at 16:01 +, BBasile via 
Digitalmars-d-announce wrote:

[…]

That's courageous, particularly past 50 yo. It's a different 
culture, past 50 yo in Europe people choose security, but in 
USA, past 50 yo some people still take the risk to try 
something new. Awesome.


I say "bollocks" to your accusation that Europeans post 50 are 
a bunch of useless idiots.


I call double "bollocks" on the claim that only in the USA do 
people do anything.


Never mind the bollocks.

:handshake:

Re: Rust style memory management

[deadalnix via Digitalmars-d]

On Saturday, 12 September 2015 at 23:21:48 UTC, welkam wrote:

On Saturday, 12 September 2015 at 20:17:04 UTC, Freddy wrote:
So I saw this video: 
https://air.mozilla.org/guaranteeing-memory-safety-in-rust/ 
and was amazed. Is there any way we can implement this in D? 
What language extensions would be required?


My idea on implement this would be to add 3 new pointer (and 
array) types : [owned,shared immutable,borrow mutable] and 
depend on casting raw pointers to the new types.


Thoughts?



There is something in std.typecons
http://dlang.org/phobos/std_typecons.html

Never tried and didnt get into details, but sounds something 
like rust


No that's can't provide the guarantee that are wanted here. You 
can't provides these guarantee without language support.

Re: Rust style memory management

[deadalnix via Digitalmars-d]

On Saturday, 12 September 2015 at 20:33:39 UTC, Adam D. Ruppe 
wrote:
Try using the -dip25 switch to dmd, it does one more step in D 
toward making a borrow thingy. Nowhere near the level Rust does 
it, but combined with other library things like destructors, 
prohibiting copying, etc., it can kinda make a owned thing with 
borrowed bits.


I really wish we don't move that way. dip25 is at best a glorious 
hack and the kind of things that incrase language complexity 
without giving much in return.

Re: Mixin templates accessing mixed out scope

[Prudence via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 14:30:16 UTC, Ali Çehreli wrote:

On 09/12/2015 06:37 AM, Prudence wrote:


Says the creating new SingleStore is not an expression


Reduced:

mixin template ObjectStore(TKey)
{
class SingleStore
{
static void New()// Removing 'static' compiles
{
new SingleStore();
}
}
}

class MyStore
{
mixin ObjectStore!(int);
}

void main()
{
auto s = new MyStore();
}

Error: type SingleStore is not an expression

Ali


Are you saying this is a bug or something else? The only 
alternative I can think of is to use string mixins but this 
method should work?

I guess this is a bug?

[Random D user via Digitalmars-d-learn]

or is it some obscure feature conflict?

struct Foo
{
this( float x_, float y_ )
{
// option A
//x = x_;
//y = y_;

// option B
v[0] = x_;
v[1] = y_;
}

union
{
struct
{
float x = 0;
float y = 0;
}
float[2] v;
}
}

struct Bar
{
Foo foo = Foo( 1, 2 );
}

Bar bar;
Bar baz = bar.init;

printf( "bar: %f, %f\n", bar.foo.x, bar.foo.y );
printf( "baz: %f, %f\n", baz.foo.x, baz.foo.y );
-
prints (with option B):
bar: 0.00, 0.00   // BUG??
baz: 1.00, 2.00

prints (with option A):
bar: 1.00, 2.00
baz: 1.00, 2.00
-
Luckily the option A works as I expected and is good enough for 
me...

Massive linker error after upgrade to DMD 2.068.1-1

[rcorre via Digitalmars-d-learn]

After upgrading from DMD 2.068.0-1 to DMD 2.068.1-1, my project 
began producing a large linker error (when built using dub).


I was able to trace it down to a single line:

target = target.adjacent(Diagonals.yes).randomSample(1).front;

target is of type RowCol 
(https://github.com/rcorre/dtiled/blob/master/src/dtiled/coords.d#L36),
which has an `adjacent` property that leverages chain, only, and 
take.


When I comment this line out (or build on a system with DMD 
2.068.0-1), I can build fine. When uncommented, I see (post 
ddemangle):


http://dpaste.com/1PJB35V

I've tried to break this down into a reduced example to prove 
that I can call randomSample on the range returned by 
RowCol.adjacent (http://dpaste.com/13G9WDE). This runs fine, so 
it seems to be a deeper issue with my build environment (full 
project at https://github.com/rcorre/damage_control if you're 
curious).


I don't want to turn this into "please debug my project for me", 
but do people have general hints on how to track down issues like 
this?


Thanks!

Side note: I see src/transition.d in the output, but I don't see 
how it is relevant to the error (it isn't even imported by the 
file causing the error).

Re: Operator overloading or alternatives to expression templates

[Bahman Movaqar via Digitalmars-d]

On Fri, 11 Sep 2015 21:40:58 +0200, Martin Nowak 
 wrote:

Does anyone have a different idea how to make a nice query language?
db.get!Person.where!(p => p.age > 21 && p.name == "Peter")


Django's approach is, IMO,  the cleverest and least magical one while 
keeping it expressive and efficient:


Person.objects.filter(age__gt=21, name__eq='peter')

The input of `filter` is keyword argument style. So, filter can 
access the dynamic argument names, in addition to their values. This 
makes it easy to understand user's intent without the need to 
overloaded operators or black magic (like repeated reflections 
Hibernate uses) and the syntax stays clean from user's perspective as 
well.


--
--
Bahman Movaqar

Re: shared array?

[Laeeth Isharc via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 06:23:12 UTC, Jonathan M 
Davis wrote:
Aside from the few classes in Phobos, its GC usage is almost 
entirely restricted to when it allocates arrays or when it has 
to allocate a closure for a delegate, which can happen in some 
cases when passing predicates to range-based algorithms. 
Avoiding functions that need to allocate arrays avoids that 
source of allocation, and using functors or function pointers 
as predicates avoids having to allocate closures. So, you 
_can_ end up with GC allocations accidentally in Phobos if 
you're not careful, but on the whole, the assertion that 
Phobos uses the GC heavily is FUD - or at least a 
misunderstanding. But as we make more of the functions use 
lazy ranges rather than arrays (particularly with regards to 
strings), and we make more of the code @nogc, it becomes even 
clearer that the GC isn't involved. Also, improvements to how 
lambdas are handled should reduce how often closures have to 
be allocated for them.


Thank you for this.  How large is the allocation for closure for 
a delegate?  Just a pair of pointers?


On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote:

I don't think it's that simple.

Saying that it doesn't use it most of the time is not an 
answer/solution. Using it at all is a problem because one 
doesn't know when and where. I realize there is a switch 
now(-vgc), and maybe that is the solution, but you say "well, 
phobos only uses 0.01% on the GC", yet since you either don't, 
can't, or won't know where that is, then it might as well be 
100% if you would like to potentially get off the GC one day.


It's like playing Russian roulette. It doesn't matter if only 
1/6 times will kill you. It's totally different than 0/6.


But if you hardly use the GC, how long is it really going to take 
to run?

Re: Rust style memory management

[welkam via Digitalmars-d]

On Saturday, 12 September 2015 at 20:17:04 UTC, Freddy wrote:
So I saw this video: 
https://air.mozilla.org/guaranteeing-memory-safety-in-rust/ and 
was amazed. Is there any way we can implement this in D? What 
language extensions would be required?


My idea on implement this would be to add 3 new pointer (and 
array) types : [owned,shared immutable,borrow mutable] and 
depend on casting raw pointers to the new types.


Thoughts?



There is something in std.typecons
http://dlang.org/phobos/std_typecons.html

Never tried and didnt get into details, but sounds something like 
rust

Re: Floating point in the type system

[Robert via Digitalmars-d]

On Saturday, 12 September 2015 at 15:13:27 UTC, Robert wrote:

Hi all,

I came across this example, and wondered what your thoughts on 
it are:





It seems a little unusual to me.

Robert


For what it's worth, I was investigating this initially as a 
discussion about adding type-level values in Rust, and how to 
handle unusual cases like this. In the process we've managed to 
break the Idris type system: 
https://github.com/idris-lang/Idris-dev/issues/2609. There's been 
quite a lot of interesting discussion about it on the IRC 
channels for all three languages :) I'd be interested to know how 
other languages handle this, if anyone knows.

Re: Operator overloading or alternatives to expression templates

[Martin Nowak via Digitalmars-d]

On Friday, 11 September 2015 at 23:47:42 UTC, Andrei Alexandrescu 
wrote:

1. Use lambdas, which seem to already do what you want:

db.get!Person.filter!(p => p.age > 21 && p.name == "Peter")

The way this'd go, the db.get!Person() call returns an input 
range of Person. Presumably introspection is being used to bind 
fields in the query such as "age" and "name" to static field 
names in struct Person. Then good old std.algorithm.filter 
takes care of the rest.


I'm instantiating the lambda with a fake p to capture the 
expression so I can translate it to whatever SQL, MongoDB, 
columnar db is used.



2. If you want to embed real SQL into D, use string-based DSLs.


Strings don't capture context, aren't typechecked, and require a 
complex CTFE parser.


db.get!Person.where!"age > 21 & name = ?"(name);

Re: Rust style memory management

[Enamex via Digitalmars-d]

On Saturday, 12 September 2015 at 20:17:04 UTC, Freddy wrote:
So I saw this video: 
https://air.mozilla.org/guaranteeing-memory-safety-in-rust/ and 
was amazed. Is there any way we can implement this in D? What 
language extensions would be required?


My idea on implement this would be to add 3 new pointer (and 
array) types : [owned,shared immutable,borrow mutable] and 
depend on casting raw pointers to the new types.


Thoughts?


There's been:
http://wiki.dlang.org/User:Schuetzm/scope1
http://wiki.dlang.org/User:Schuetzm/scope2
http://wiki.dlang.org/User:Schuetzm/scope3

And at least one earlier proposal that's been accepted already. 
It requires the '@safe' annotation to work and is quite limited 
to anything more general. Although the basic opinion was that it 
covered a large proportion of the inherently unsafe cases that 
Rust aims to cover compared to C++ or unsafe D (but Rust's 
approach is more 'safe by proof' vs D's 'safe by prohibiting 
known unsafe').

Type helpers instead of UFCS

[BBasile via Digitalmars-d]

UFCS is good but there are two huge problems:
- code completion in IDE. It'will never work.
- noobs, code is unreadable.

That's why I propose the new keywords 'helper' and 'subject' that 
will allow to extend the properties pre-defined for a type, as 
long as the helper is imported:


---
module myhelper;
helper for subject : string
{
void writeln()
{
import std.stdio;
writeln(subject);
}
}
---

this will allow IDE plugins to provide better completion.

for example if 'Peter' types

---
void foo()
{
import myhelper;
"foobarbaz".
}
---

after the dot, 'Peter' can get ".writeln".
Why ? because a clear grammatical construction will allow an IDE 
plugin to work on a type and provides additional helpers that 
would be hard to put in the list without any specific grammatical 
construction.


...

Re: module std.stream is deprecated - Will be removed by phobos version 2.070

[Jonathan M Davis via Digitalmars-d]

On Saturday, 12 September 2015 at 14:24:21 UTC, Jacob Carlborg 
wrote:
The problem with adding notifications in the documentation is 
that if a user already has implemented code that uses the 
particular model and have no need to change the code. Or the 
user already is familiar with the module there's no reason to 
read the documentation to see the notification or to notice the 
documentation is gone.


It only (hopefully) prevents new users to use the module.

Would it be better to add the deprecation immediately and let 
be deprecated for a longer period? Or use something like 
'pragam(msg, "WARNING: deprecated ...")' if someone is using 
the "-de" flag.


std.stream got a note in its documentation (something like 3 
years ago) rather than being deprecated, because we didn't have a 
replacement yet. We just knew that we definitely wanted to 
replace it. But we have yet to actually come up with a 
replacement, and when it was brought up at dconf that the note 
had been on std.stream for years and yet the module was still 
there, Andrei said that we should just kill it and that maybe 
this was a sign that streams weren't all that important. So, 
we're now actually deprecating it even though we don't have a 
replacement yet.


It used to be that marking something as deprecated immediately 
made that code fail to compile, which is why we used to mark 
stuff as "scheduled for deprecation" in its documentation for a 
while before actually deprecating it, but deprecated was fixed a 
while ago so that it doesn't result in a compilation error by 
default (hence the -de flag that you mentioned), and when that 
change was made, we stopped marking stuff as "scheduled for 
deprecation."


Normally, what we've been doing for a while now is to just 
immediately deprecate a symbol (or module) and then wait about a 
year before removing it from the docs, and then wait about 
another year before removing it from the code. So, the result is 
that existing code has about two years to be changed before it'll 
stop compiling due to the symbol going away. It's just that 
anyone compiling it will be bugged by deprecation messages unless 
they use a flag to shut them off (which they shouldn't, because 
then they'll miss all deprecation messages, but folks are free to 
shoot themselves in the foot if they really want to). So, at this 
point, there really isn't much point in general in saying 
anything in the documentation before deprecating a symbol, and we 
haven't been doing that.


The one exception that's come up is that deprecating a symbol and 
introducing its replacement in the same release causes problems 
for folks who need their code to build with both the current 
release and master (as is the case with Vladimir). So, in a few 
cases, we've marked a symbol as scheduled for deprecation when we 
add its replacement and then have deprecated it in the next 
release and continued the deprecation cycle as normal. But most 
of the time, we've just gone straight to deprecated, and we 
aren't doing a lot of deprecating these days, so it's nowhere 
near the issue it was when we were doing mass renamings and 
whatnot several years ago.


- Jonathan M Davis

Re: Why does reverse also flips my other dynamic array?

[Ali Çehreli via Digitalmars-d-learn]

On 09/12/2015 02:29 PM, Marco Leise wrote:

> Note that often the original dynamic array has additional
> capacity beyond its length. This can be used to ~= additional
> items without causing a reallocation, but is lost when you
> do the assignment "b = a".

Actually, the capacity is still there, useful to the runtime. 
Interestingly, the first dynamic array that is appended the new element 
becomes the owner of that capacity. The capacity of the other dynamic 
array becomes 0.


import std.stdio;

void main(){

  int [] a = [1,2,3,4,5];
  int [] b = a;

  writeln(a.ptr, " ", b.ptr);
  writeln(a.capacity, " ", b.capacity);
  a ~= 42;// <-- change to b, now b owns the capacity
  writeln(a.ptr, " ", b.ptr);
  writeln(a.capacity, " ", b.capacity);
}

Ali

Re: Hello World Example with Glade?

[Mike McKee via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 09:03:53 UTC, Russel Winder 
wrote:
Once you get to a GtkD application bigger than "Hello World" 
create a project and use Dub.


Oh yes, Dub. That's the ticket. Thanks, mate.

Re: Reasons to use D

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 12 September 2015 at 11:36:47 UTC, Sebastiaan Koppe 
wrote:
I suppose you mean changing the contents of an existing script 
element. I was talking about inserting a new inline-script via 
html().


oh yeah, you are right. That's one thing I do like about D 
though: I find it so much easier to remember (perhaps because I 
wrote most the libs I use myself). I forget the difference 
between stuff like substr and substring in Javascript or chop and 
chomp in Ruby and so on. I have to refer to the docs to remember 
this stuff, even when I write it all the time.


I find D's ways to be much easier to store in the brain, despite 
D arguably being a bigger, more complex language.

Re: Floating point in the type system

[Ola Fosheim Grostad via Digitalmars-d]

On Saturday, 12 September 2015 at 16:08:31 UTC, Robert wrote:
assert and runtime assert failing. I'm just curious to 
understand the reasoning behind this, whether it's intentional, 
and whether it matters at all.


Types need to mangle to the same name, but using floats in a type 
name is usually not a good idea. Try pi... How many decimals? A 
roundoff error and you get a new type.

Re: Better lambdas!!!!!!!!!!

[Prudence via Digitalmars-d]

On Saturday, 12 September 2015 at 10:44:05 UTC, Pierre Krafft 
wrote:

On Saturday, 12 September 2015 at 03:32:51 UTC, Prudence wrote:
On Saturday, 12 September 2015 at 02:13:11 UTC, Pierre Krafft 
wrote:
On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence 
wrote:
On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli 
wrote:

On 09/10/2015 10:55 AM, Prudence wrote:
> How bout this:
>
> void myfunc(double delegate(int i, int z, float f)) {}
>
>
> myfunc((int i, int z, float f) { return i*z*f; } }
>
> vs
>
> myfunc({ return i*z*f; })   // Names of parameters are
inferred from
> signature.

Considering other features of the language, that's pretty 
much impossible in D. What if there is another i in scope:


int i;
myfunc({ return i*z*f; });

Now, should it call another overload of myfunc that takes 
(int z, int f) because i is something else?


Should the compiler analyze the body of the code and decide 
which symbols could be parameters? And then go through all 
overloads of myfunc? etc.?


Ali


As I said, it could throw a warning or error. It, in some 
sense, is already a a problem with nested blocks that hide 
outside variables, is it not?


The compiler doesn't need to scan anything. It knows the 
which parameters from the definition!



-> void myfunc(double delegate(int i, int z, float f))  <- 
Compiler knows to use the names here as the default names in 
for the parameters when.



when used:

myfunc({ return i*z*f; }); <- Oh, there are the names, we 
know what they are because the signature is tells us. The 
compiler does the following:



1. Sees we have a block without any parameters defined. 
i.e., a lambda.


2. It looks up the signature of myfunc to find out what the 
names are


3. It sees that they are i z and f

4. Now it knows and it effectively rewrites the code as

myfunc((i,z,f) { return i*z*f; });

Surely this is not difficult, 4 steps?


You're making your code more brittle for a small gain. The 
suggestion makes parameter usage order important and the 
compiler can't warn about my typos.

Consider:
myfunc({return "x:"~x~"y:"-y;}) getting changed to 
myfunc({return "y:"~y~"x:"~x;});

Or the typo in
myfunc({return i*z+f*j;});

Lambdas are already very concise. This proposal doesn't give 
any benefits outside of very simple lambdas. Such lambdas are 
already so simple that they could use some standard functions 
instead (like sum, to!T, and bind).



What does this have to do with my proposal? Those issues exist 
regardless of the simplification.


myfunc({return "x:"~x~"y:"-y;}) getting changed to
myfunc({return "y:"~y~"x:"~x;});

huh? What do you mean the suggestion makes parameter usage 
order important? They are important, it has nothing to do with 
the suggestion? Are you saying that you want to reserve the 
right to do something like


myfunc(string delegate(string x, string y));

and

myfunc((y,x){ "y:"~y~"x:"~x; })

? If so, or unless I'm missing something, that's bad no matter 
what. Changing the order and reversing the names is more than 
just confusing, it's hard to read and most people will gloss 
over that fact. Be consistent with your parameters and maybe 
you'll have less bugs?




Or the typo in

myfunc({return i*z+f*j;});

Again, what does this have to do with anything? A typo is a 
typo and is always a mistake. The above example has the same 
effect regardless if the parameters are explicit or deduced.



myfunc((i,z,f) {return i*z+f*j;});

j is still a problem. If j is defined outside the lambda then 
regardless of specific or implicit parameter names, it will 
not cause any problems.


In either case, the compiler can see that j is either 
referenced outside the scope or undefined. It has nothing to 
do with the parameters used.



Of course maybe I'm missing something, but essentially are not 
almost all uses of lambda's simply copying the parameter 
signature of the delegate. It already infers types... you 
could say that leads to typo's too...


 myfunc({return "x:"~x~"y:"-y;});
is infered to mean myfunc((x,y){return "x:"~x~"y:"-y;});
while
 myfunc({return "y:"~y~"x:"~x;});
is infered to mean myfunc((y,x){return "y:"~y~"x:"~x;});
which is not what I expect since the lambda I want is 
myfunc((x,y){return "y:"~y~"x:"~x;});

This can lead to subtle bugs which are very hard to see.

In the typo example there could be two overloaded functions 
differing only in that one takes a delegate having 3 parameters 
and one taking a delegate having 4 parameters. If we explicitly 
write the lambda parameters the typo will be found since j is 
undefined. But when parameters are inferred the compiler will 
see that {return i*z + f*j;} matches the function taking a 
lambda with 4 parameters.


Inferred parameter types are on the brink of what I can allow. 
They can risk typos, but not as easily since you write the 
parameters twice (declaration and usage). They can also 
silently change if the function taking the delegate has the 
parameter type changed. I don't want 

Re: Mixin templates accessing mixed out scope

[anonymous via Digitalmars-d-learn]

On Saturday 12 September 2015 16:30, Ali Çehreli wrote:

> Reduced:
[...]
> Error: type SingleStore is not an expression

Reduced further:


class MyStore
{
class SingleStore
{
static void New() // Removing 'static' compiles
{
new SingleStore();
}
}
}


And now the problem can be spotted:

SingleStore is a nested class. That means, instances of it are bound to 
MyStore instances. But New is static, so it doesn't have a MyStore to which 
it could attach the `new SingleStore`.

That error message is pretty awful. I filed an issue:
https://issues.dlang.org/show_bug.cgi?id=15049

As for a fix: I guess SingleStore isn't supposed to be a nested class. Mark 
it static then.

[Issue 15050] DPaste is always passing an empty second argument to programs

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15050

Vladimir Panteleev  changed:

   What|Removed |Added

 Blocks||12210

--

[Issue 12210] dlang.org home page example - Run button does not work

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12210

Vladimir Panteleev  changed:

   What|Removed |Added

 Depends on||15050

--

[Issue 15050] New: DPaste is always passing an empty second argument to programs

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15050

  Issue ID: 15050
   Summary: DPaste is always passing an empty second argument to
programs
   Product: D
   Version: D2
  Hardware: All
   URL: http://dpaste.dzfl.pl/32757e6f96b0
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nazriel6...@gmail.com
  Reporter: thecybersha...@gmail.com

import std.stdio;

void main(string[] args)
{
writeln(args);
}

This will print e.g.:

["./f342", ""]

This is blocking e.g. the float-rounding example on dlang.org.

--

Re: Mixin templates accessing mixed out scope

[anonymous via Digitalmars-d-learn]

On Saturday 12 September 2015 19:36, Prudence wrote:

> On Saturday, 12 September 2015 at 17:11:04 UTC, anonymous wrote:
[...]
>> class MyStore
>> {
>> class SingleStore
>> {
>> static void New() // Removing 'static' compiles
>> {
>> new SingleStore();
>> }
>> }
>> }
[...]
>> As for a fix: I guess SingleStore isn't supposed to be a nested 
>> class. Mark it static then.
> 
> NO! That is the whole point!

So New is supposed to create a SingleStore that's associated with a MyStore?

That static can't work like that then. It doesn't escape just the first 
level (SingleStore), but all levels (SingleStore and MyStore). That is, a 
static method isn't bound to any object. But you need a MyStore to construct 
a (nested) SingleStore. You have to pass a MyStore somehow.

It can come via `this.outer`:

class MyStore
{
class SingleStore
{
SingleStore New()
{
return new SingleStore;
}
}
}
void main()
{
auto ms = new MyStore;
auto ss1 = ms.new SingleStore;
auto ss2 = ss1.New();
}

But here you need a SingleStore object to call New on. Not what you want, I 
think.

Or the MyStore can come via parameter:

class MyStore
{
class SingleStore
{
static SingleStore New(MyStore ms)
{
return ms.new SingleStore;
}
}
}
void main()
{
auto ms = new MyStore;
auto ss = MyStore.SingleStore.New(ms);
}


Or you can move New a level up, into MyStore, and then plain `this` is the 
needed MyStore:

class MyStore
{
class SingleStore
{
}
SingleStore NewSingleStore()
{
return new SingleStore;
}
}
void main()
{
auto ms = new MyStore;
auto ss = ms.NewSingleStore();
}

Re: Calling D from C, C++, Python…

[Brad Roberts via Digitalmars-d-learn]

On 9/12/15 9:20 AM, Adam D. Ruppe via Digitalmars-d-learn wrote:

On Saturday, 12 September 2015 at 09:47:55 UTC, Jacob Carlborg wrote:

Well, if your D function doesn't use anything of the runtime I guess it's not 
necessary.


Right. If you don't call into the threading system in the druntime, you should 
be ok. Keep in mind
though that the GC uses the threads and the new expression, array literals, 
array append, and
others use the GC.

Runtime.initialize is also what calls static and module constructors... and 
might have
responsibility for fixing up dynamic casting of class objects in a shared lib 
too, I'm not sure
about that.

But if you avoid the bulk of the runtime functions, indeed you can get away 
without initializing it.
Just that null thread handle is likely to cause segfaults in places where you 
might not expect if
you don't.

It is best to initialize it. Lots of C libraries need an init an teardown call, 
so surely the Python
interop provides some solution for it. idk what it would be though.


I think it's safest to say (and it belongs in the spec somewhere) that executing D code before 
initializing the runtime results in undefined behavior, or something along those lines.  You can get 
away with it in some circumstances, but it's at your own risk.

[Issue 12210] dlang.org home page example - Run button does not work

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12210

Vladimir Panteleev  changed:

   What|Removed |Added

   Assignee|thecybersha...@gmail.com|nazriel6...@gmail.com

--- Comment #10 from Vladimir Panteleev  ---
Some fixes:

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

Some issues are still blocked on some DPaste-specific problems.

(In reply to Gerald Jansen from comment #9)
> Perhaps this is a slightly different issue but it is related so I'll just
> mention it here. The example in the section "Convenience" under the
> paragraph starting with "Automatic memory management makes for safe, simple,
> and robust code.", crashes with message:
> 
> Application output: (1 Hangup)
> Exiting main.
> std.exception.ErrnoException@std/stdio.d(385): Cannot open file `text.txt'
> in mode `rb' (No such file or directory)
> 
> ... and a bunch of incomprehensible junk (for a casual visitor)
> 
> Having examples that don't run is probably worse than no examples. Perhaps
> the priority of this issue should be increased. Perhaps the more general
> issue is how to continuously test and ensure that all example code
> highlighted on dlang.org runs correctly.

The example is correct, and works as expected in the absence of a text.txt
file. It is meant to illustrate RAII, there isn't much value in including it in
Edit-and-Run, so I added support for excluding examples and excluded it.

--

Re: Reasons to use D

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 12 September 2015 at 18:44:44 UTC, Ola Fosheim 
Grøstad wrote:
Arrayviews ("slices") are available as a type so you can do it 
like this:


Yeah, there's also the Array.slice and String.substring that work 
kinda similarly in old standard javascript. But there's still a 
lot of type-specific verbiage in there, whereas with D, it is 
always the same [a .. $] for almost anything so it is one thing 
to remember instead of three or more.

[Issue 15036] SimpleDllMain assumes various symbols are available unqualified

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15036

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15036] SimpleDllMain assumes various symbols are available unqualified

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15036

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/957d83f1c342e44229d148027a449c956a42c122
fix Issue 15036 - SimpleDllMain assumes various symbols are available
unqualified

https://github.com/D-Programming-Language/druntime/commit/15cde5050c8341fec3c8b5f5ad83eac2a92fe6f3
Merge pull request #1385 from CyberShadow/pull-20150912-184323

fix Issue 15036 - SimpleDllMain assumes various symbols are available…

--

Re: Operator overloading or alternatives to expression templates

[Dmitry Olshansky via Digitalmars-d]

On 12-Sep-2015 23:08, Martin Nowak wrote:

On Friday, 11 September 2015 at 23:47:42 UTC, Andrei Alexandrescu wrote:

1. Use lambdas, which seem to already do what you want:

db.get!Person.filter!(p => p.age > 21 && p.name == "Peter")

The way this'd go, the db.get!Person() call returns an input range of
Person. Presumably introspection is being used to bind fields in the
query such as "age" and "name" to static field names in struct Person.
Then good old std.algorithm.filter takes care of the rest.


I'm instantiating the lambda with a fake p to capture the expression so
I can translate it to whatever SQL, MongoDB, columnar db is used.


2. If you want to embed real SQL into D, use string-based DSLs.


Strings don't capture context, aren't typechecked, and require a complex
CTFE parser.

db.get!Person.where!"age > 21 & name = ?"(name);




What if we add generic string interpolation a-la:

s"$age > 21 && name = ${someobj.field}"

would translate to:
AliasSeq!("",age," > 21 && name = ", someobj.field, "");

Thoughts? I think it was proposed before by Timothy Cour.

--
Dmitry Olshansky

Re: Operator overloading or alternatives to expression templates

[Martin Nowak via Digitalmars-d]

On Friday, 11 September 2015 at 23:19:54 UTC, Timon Gehr wrote:
Does anyone have a different idea how to make a nice query 
language?

db.get!Person.where!(p => p.age > 21 && p.name == "Peter")



You could give up on operator syntax.


That's what I did in the prototype, p.age.gt(21), but it's 
somewhat ugly.

Re: Type helpers instead of UFCS

[Enamex via Digitalmars-d]

On Saturday, 12 September 2015 at 20:40:35 UTC, Adam D. Ruppe 
wrote:

On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote:

- code completion in IDE. It'will never work.


Why not? I haven't actually tried it, but it seems like a 
pretty easy problem, except perhaps with complex templates.



- noobs, code is unreadable.


meh


There's the bigger problem that extending a type via UFCS is 
'open'; there can always be more functions where the first 
parameter accepts that type you're using.


With a dedicated syntax, specific functions/groups-of-functions 
could be easily recognized as extensions of a type and could even 
be made to be recognized by templates (when the type is passed as 
type parameter or alias param) even though they're not in its 
definition. Kinda like type classes.


But, anyway...

Re: Reasons to use D

[via Digitalmars-d]

On Saturday, 12 September 2015 at 20:03:09 UTC, Adam D. Ruppe 
wrote:

That's basically what my D->JS thing did back in 2011.


Nice, so now you will do it again in 2016 ? ;)

That actually worked somewhat well in my dtojs but it was a 
mild hassle too once function callbacks got more involved. You 
can template them in D but then it bloats the generated JS for 
no real reason since they all have identical dynamically typed 
code!


Yes, you need to convert the D into a JS-specific IR and then fix 
it in an optimization step before code gen.


But function overloading isn't enough, unless you accept casting, 
since javascript can return anything. I guess you can use 
template parameters when you request literal strings like 
«document.createElement("div")», but in other situations it might 
be more tricky. I don't think function overloading is enough if 
you want to avoid casting.


But the TypeScript definition files might make it somewhat 
easier, and might be a good starting point as they expose typing 
issues. I don't think they are too hard to parse partially:


https://github.com/Microsoft/TypeScript/blob/master/lib/lib.core.es6.d.ts
https://github.com/Microsoft/TypeScript/blob/master/lib/lib.es6.d.ts
https://github.com/Microsoft/TypeScript/blob/master/lib/lib.dom.d.ts
etc

Although I think one  should only include what browsers have in 
common. So it is a tedious job that probably involves writing a 
test program that test what different browsers support and upload 
results to a web server...


I suppose that is solvable too but i never got around to it and 
just went back to writing normal javascript. (I write small JS 
files anyway, it is an ok language for small scripts.)


It's ok if you only write a few hundred lines of javascript, but 
the IDE code completion you get with typing really makes a 
difference.

Re: Floating point in the type system

[via Digitalmars-d]

On Saturday, 12 September 2015 at 19:02:16 UTC, Robert wrote:
handle unusual cases like this. In the process we've managed to 
break the Idris type system: 
https://github.com/idris-lang/Idris-dev/issues/2609.


I don't know Idris, but you can't easily unify over floats, 
because they are samples on an interval, and don't behave like 
real numbers, but more like underspecified intervals from 
interval arithmetics.


If you want to unify over reals, you probably should do it 
symbolically.


Or just treat float values as literal symbols in the type system. 
It is useful for configuration: Frequency!342.234


Sometimes it is worthwhile to have an unsound type system. Both D 
and Dart have somewhat unsound type systems. It puts a burden on 
the programmer, but can be useful.

Re: Floating point in the type system

[Xinok via Digitalmars-d]

On Saturday, 12 September 2015 at 16:08:31 UTC, Robert wrote:
On Saturday, 12 September 2015 at 15:49:23 UTC, Atila Neves 
wrote:

What do think is unusual?

Atila


It's unusual, because `float.nan != float.nan`, so one might 
expect that `typeof(Foo!(float.nan) != Foo!(float.nan))`, 
whereas this is clearly not the case, even with both the static 
assert and runtime assert failing. I'm just curious to 
understand the reasoning behind this, whether it's intentional, 
and whether it matters at all.


(1) f = f2; // This is assignment, not comparison
(2) alias VAL = f; // This is not a data member so is not 
involved in comparisons or assignments


change "alias VAL" to "float VAL" and then you might see the 
behavior you expect.

Re: A collection of DIPs

[NX via Digitalmars-d]

On Saturday, 12 September 2015 at 15:54:53 UTC, Adam D. Ruppe 
wrote:

D programs *never* have a GC thread.

Remember, the D GC isn't magic and isn't actually even that 
complicated, it is just an ordinary function call.


That's what I was afraid of :'(

Re: Reasons to use D

[Meta via Digitalmars-d]

On Saturday, 12 September 2015 at 16:32:52 UTC, Adam D. Ruppe 
wrote:
oh yeah, you are right. That's one thing I do like about D 
though: I find it so much easier to remember (perhaps because I 
wrote most the libs I use myself). I forget the difference 
between stuff like substr and substring in Javascript or chop 
and chomp in Ruby and so on. I have to refer to the docs to 
remember this stuff, even when I write it all the time.


I find D's ways to be much easier to store in the brain, 
despite D arguably being a bigger, more complex language.


Maybe because the static type system allows for overloading and 
so all of these utility functions don't have to do a million 
different things depending on what you pass to them.

Re: Floating point in the type system

[anonymous via Digitalmars-d]

On Saturday 12 September 2015 18:08, Robert wrote:

> It's unusual, because `float.nan != float.nan`, so one might 
> expect that `typeof(Foo!(float.nan) != Foo!(float.nan))`, whereas 
> this is clearly not the case, even with both the static assert 
> and runtime assert failing. I'm just curious to understand the 
> reasoning behind this, whether it's intentional, and whether it 
> matters at all.

I don't know what the compiler actually does, but it looks like the 
comparison of template value arguments doesn't use equality, but something 
more akin to `is` instead (bitwise equality).

If that's right, then `is(Foo!(float.nan) == Foo!(float.nan))` holds because 
`float.nan is float.nan` holds.

Same behavior with a struct instead of float:

struct S
{
bool opEquals(S other) {return false;}
}
struct Foo(S s)
{
}
static assert(S.init != S.init); /* not equal */
static assert(S.init is S.init); /* but bit for bit identical */
static assert(is(Foo!(S.init) == Foo!(S.init)));

Re: Why does reverse also flips my other dynamic array?

[Marco Leise via Digitalmars-d-learn]

Am Sat, 12 Sep 2015 10:55:50 +
schrieb "Namal" :

> > Why is also b flipped here? This doesn't happen if I use static 
> > arrays.
> 
> nvm. I need to .dup that.

Correct, static arrays are value types and copied on
assignment. Dynamic arrays on the other hand are generally
slices of memory on the garbage collected heap represented by
just a pointer to the first element and a length. When you
assign those you only get a second reference to the same data.

Note that often the original dynamic array has additional
capacity beyond its length. This can be used to ~= additional
items without causing a reallocation, but is lost when you
do the assignment "b = a". (This is so you can't accidentally
append different items to both a and b and have them overwrite
each other.) You can query the actual capacity with a.capacity.

Just felt like writing down some knowledge you might need
along the way. :)

-- 
Marco

Re: shared array?

[Laeeth Isharc via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote:
Saying that it doesn't use it most of the time is not an 
answer/solution. Using it at all is a problem because one 
doesn't know when and where. I realize there is a switch 
now(-vgc), and maybe that is the solution, but you say "well, 
phobos only uses 0.01% on the GC", yet since you either don't, 
can't, or won't know where that is, then it might as well be 
100% if you would like to potentially get off the GC one day.


"you either don't, can't, or won't know where that is"

just check the signature, no ? eg

http://dlang.org/phobos/std_string.html
pure nothrow @nogc @system inout(char)[] fromStringz(inout(char)* 
cString);

 ^

[Issue 15052] New: dmd/std/utf.d error on variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15052

  Issue ID: 15052
   Summary: dmd/std/utf.d error on variable
std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUn
itImpl.r
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: pedrolo...@gmx.com

Created attachment 1550
  --> https://issues.dlang.org/attachment.cgi?id=1550=edit
the utf.d file

dmd  2.068.1-1

it fails when using dub to compile a file. 

/usr/include/dlang/dmd/std/utf.d(3128): Error: variable
std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r only parameters
or stack based variables can be inout
/usr/include/dlang/dmd/std/utf.d(3278): Error: template instance
std.utf.byCodeUnit!(inout(char)[]) error instantiating
/usr/include/dlang/dmd/std/string.d(386):instantiated from here:
byDchar!(inout(char)[])

actually this is not just one error it is a load of them,

--

Re: Massive linker error after upgrade to DMD 2.068.1-1

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 20:05:28 UTC, rcorre wrote:
After upgrading from DMD 2.068.0-1 to DMD 2.068.1-1, my project 
began producing a large linker error (when built using dub).


I was able to trace it down to a single line:

target = target.adjacent(Diagonals.yes).randomSample(1).front;

target is of type RowCol 
(https://github.com/rcorre/dtiled/blob/master/src/dtiled/coords.d#L36),
which has an `adjacent` property that leverages chain, only, 
and take.


When I comment this line out (or build on a system with DMD 
2.068.0-1), I can build fine. When uncommented, I see (post 
ddemangle):


http://dpaste.com/1PJB35V

I've tried to break this down into a reduced example to prove 
that I can call randomSample on the range returned by 
RowCol.adjacent (http://dpaste.com/13G9WDE). This runs fine, so 
it seems to be a deeper issue with my build environment (full 
project at https://github.com/rcorre/damage_control if you're 
curious).


I don't want to turn this into "please debug my project for 
me", but do people have general hints on how to track down 
issues like this?


Thanks!

Side note: I see src/transition.d in the output, but I don't 
see how it is relevant to the error (it isn't even imported by 
the file causing the error).


there was talk of adding symbol name compression some time ago ( 
to reduce lib size ( and maybe make ddemangle not fail on long 
syms?). This might be the cause of your problems i.e. the new 
compiler emitting references to compressed names but built with 
the old compiler using the not compressed ones. Try rebuilding 
everything and see if that fixes it.

[Issue 15052] dmd/std/utf.d error on variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15052

pedrolopes  changed:

   What|Removed |Added

 CC||pedrolo...@gmx.com
   Severity|blocker |critical

--

[Issue 15052] dmd/std/utf.d error on variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15052

pedrolopes  changed:

   What|Removed |Added

  Component|dmd |phobos

--

Re: Looking for someone that could work on 32 bits support for SDC

[deadalnix via Digitalmars-d]

On Sunday, 13 September 2015 at 01:17:17 UTC, Brandon Ragland 
wrote:

x86 would be easiest to target.

I've checked out the repo, built it so far, and indeed some 
failures but no big deals.


Currently paging through to get a hold on what's in there. 
(I'll be the first to admit I don't know squat about the LLVM 
compiler).


A good place to start is :

http://llvm.org/docs/LangRef.html

You can uncomment things here : 
https://github.com/SDC-Developers/SDC/blob/master/libd-llvm/src/d/llvm/backend.d#L115


and see what kind of IR is outputed. Frankly you don't need to 
know much more than this to get started.


Don't go paralyzed because you don't know everything. Start doing 
something and see what is actually blocking you.

Re: Does a synchronization yield on waiting thread?

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/12/15 10:48 PM, Prudence wrote:

It would seem to be the logical thing to do?

That is, suppose two threads are sharing a resource. Thread A has it
locked. B is "waiting". Is B in a loop burning cycles running in the
background(regardless of thread.sleep, which only alleviates the
problem) or does it yield completely and somehow inform the lock to
resume it when A has unlocked the resources?


If you are using D mutexes or synchronized statements, it uses the OS' 
mechanisms (e.g. pthreads). For all supported OSes, this means it is 
asleep and waiting for the OS to awaken it when it has locked the resource.



The first one burns cycles and can have timing problems. I.e., What if A
locks and unlocks at the same rate that B checks? (I suppose a random
sleep time would help with this) (


You don't have to worry about this. If A unlocks a resource that B is 
waiting for the lock, it cannot lock it again before B gets it.


-Steve

Re: Type helpers instead of UFCS

[BBasile via Digitalmars-d]

On Saturday, 12 September 2015 at 22:44:41 UTC, Idan Arye wrote:

On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote:
That's why I propose the new keywords 'helper' and 'subject' 
that will allow to extend the properties pre-defined for a 
type, as long as the helper is imported:


---
module myhelper;
helper for subject : string


Do we really need a 3-keyword chain? What's wrong with a simple 
`helper : string` or `helper(string)`?



{
void writeln()
{
import std.stdio;
writeln(subject);
}
}
---


Why `subject` to refer to the string the function gets called 
on? What's wrong with good old `this`, which is used for this 
purpose everywhere else?


no 'helper' is enough:

http://www.israpresse.net/wp-content/uploads/2015/05/625088-34.jpg

Re: Looking for someone that could work on 32 bits support for SDC

[BBasile via Digitalmars-d]

On Wednesday, 9 September 2015 at 20:33:43 UTC, deadalnix wrote:

All is in the title.

ARM/Mips/pNaCl/WebAssembly require 32bits to work. These are 
valuable targets IMO.


I can provide support, but I just don't have the bandwidth to 
pull it by myself. If someone could step up, that'd be great.


Do you think that libd is 32bit ready ?

https://github.com/SDC-Developers/SDC/pull/141

Re: reading file byLine

[deed via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 12:51:04 UTC, Namal wrote:
Anyway, there is no .reverse for strings I guess, what is the 
way to completely reverse a string in D?


What do you want to do? Do you want to keep your data in original 
order, but get a reversed view of it for something, or do you 
actually want to reverse your original array?


You can use `retro` to simply read your array backwards, i.e.:
string s = "Some text";
s.retro.writeln;   // `txet emoS`
s.writeln; // `Some text`
s.retro.find("e"); // `Some te` (Surprising to me. Error? 
2.067.1)

s.retro.until("e").writeln;// `tx`
s.find("e");   // `Some`

The string is still kept in original order, but `retro` returns a 
range reading the array backwards. If you want to store a 
reversed string in memory, that's possible too, of course. One 
way of doing it, is to convert your retro range to a string:


s = s.retro.to!string;
s.writeln; // `txet emoS`

This will allocate new memory for the reversed copy and assign it 
to `s`.
Reverse is an algorithm that swaps values at different indices 
and since `string` is an alias for `const(char)[]`, it's not 
allowed. It means that each element of the array is const, so you 
cannot mutate any elements, but you can append or remove elements 
or assign the slice to view another part of the string or some 
other string. Hence, a `s.reverse` will give you an error. If you 
use `char[]` instead of `const(char)[]` you can use reverse and 
reuse the same memory for the reversed `char[]`. To illustrate:


char[] t = ['a', 'b', 'c'];
std.algorithm.reverse(t);
t.writeln; // `cba`

// s[0] = s[$-1];  // Error, cannot mutate const elements
auto r = s.retro;
s.length = 0;
r.each!(e => s ~= e);
s.writeln; // s has the reversed string, obtained 
through
   // a temporary range object, setting 
length to
   // zero and appending the elements 
from the
   // range, which is allowed for 
const(char)[]

[Issue 15019] [ICE] Heisencrash on OS X 32-bit with non-trivial projects

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15019

--- Comment #13 from Vladimir Panteleev  ---
I think I found the cause of the memory corruption, but not the root cause of
the bug.

If you apply these patches:

https://github.com/CyberShadow/dmd/commit/2d424ac899535d975a6265b094c7f3fec217f4c5
https://github.com/CyberShadow/dmd/commit/0ea57be391b0a8307c1b5bf907506f74892ffe1d

you will see that the assert fails with the given test case, although the DMD
test suite passes with these asserts. It looks like DMD is trying to create a
relocation outside of the data segment? Here's the backtrace:

  * frame #0: 0x0001001d9a66 dmd`util_assert(file=0x000100322900,
line=278) + 22 at util2.c:55
frame #1: 0x0001001d072d dmd`local_assert(line=278) + 29 at
tassert.h:29
frame #2: 0x0001001d00d7
dmd`Outbuffer::setsize(this=0x000121e7d320, size=4100) + 55 at outbuf.c:278
frame #3: 0x00010022e767 dmd`Obj::bytes(seg=2, offset=4100, nbytes=4,
p=0x000100344f98) + 167 at machobj.c:2288
frame #4: 0x0001001b93c6 dmd`addtofixlist(s=0x000100cf9b40,
soffset=4100, seg=2, val=0, flags=16) + 374 at cgen.c:594
frame #5: 0x0001002325b6 dmd`Obj::reftoident(seg=2, offset=4100,
s=0x000100cf9b40, val=0, flags=16) + 150 at machobj.c:2469
frame #6: 0x00010019c9c5 dmd`el_ptr(s=0x000100cf9b40) + 261 at
el.c:1710
frame #7: 0x0001001606ca dmd`toElem(this=0x7fff5fbfd108,
fe=0x000121120be0)::ToElemVisitor::visit(FuncExp*) + 138 at e2ir.c:1154
frame #8: 0x00010008e986 dmd`FuncExp::accept(Visitor*) + 34 at
expression.d:6324
frame #9: 0x00010015a332 dmd`toElem(e=0x000121120be0,
irs=0x7fff5fbfd970) + 66 at e2ir.c:5485
frame #10: 0x00010016254c dmd`toElem(this=0x7fff5fbfd198,
pe=0x00012131e4d0)::ToElemVisitor::visit(PtrExp*) + 44 at e2ir.c:3690
frame #11: 0x00010009ad0e dmd`PtrExp::accept(Visitor*) + 34 at
expression.d:9738
frame #12: 0x00010015a332 dmd`toElem(e=0x00012131e4d0,
irs=0x7fff5fbfd970) + 66 at e2ir.c:5485
frame #13: 0x00010016204b dmd`toElem(this=0x7fff5fbfd328,
ce=0x000121120b90)::ToElemVisitor::visit(CallExp*) + 1179 at e2ir.c:3605
frame #14: 0x000100099f16 dmd`CallExp::accept(Visitor*) + 34 at
expression.d:9464
frame #15: 0x00010015a332 dmd`toElem(e=0x000121120b90,
irs=0x7fff5fbfd970) + 66 at e2ir.c:5485
frame #16: 0x000100166625 dmd`toElem(this=0x7fff5fbfd788,
ae=0x0001205dc9d0)::ToElemVisitor::visit(AssignExp*) + 8453 at e2ir.c:2949
frame #17: 0x0001000a3476 dmd`AssignExp::accept(Visitor*) + 34 at
expression.d:12155
frame #18: 0x00010015a332 dmd`toElem(e=0x0001205dc9d0,
irs=0x7fff5fbfd970) + 66 at e2ir.c:5485
frame #19: 0x00010015b8a8 dmd`toElemDtor(e=0x0001205dc9d0,
irs=0x7fff5fbfd970) + 88 at e2ir.c:5578
frame #20: 0x00010014f3a2
dmd`S2irVisitor::visit(this=0x7fff5fbfd890, s=0x000121120b00) + 130 at
s2ir.c:846
frame #21: 0x00010011aa73 dmd`ExpStatement::accept(Visitor*) + 31 at
statement.d:1247
frame #22: 0x00010014f242 dmd`Statement_toIR(s=0x000121120b00,
irs=0x7fff5fbfd970) + 66 at s2ir.c:1283
frame #23: 0x00010014f446
dmd`S2irVisitor::visit(this=0x7fff5fbfd930, s=0x000121121f10) + 134 at
s2ir.c:862
frame #24: 0x00010011bd83 dmd`CompoundStatement::accept(Visitor*) + 31
at statement.d:1587
frame #25: 0x00010014f242 dmd`Statement_toIR(s=0x000121121f10,
irs=0x7fff5fbfd970) + 66 at s2ir.c:1283
frame #26: 0x00010014f6b5
dmd`S2irVisitor::visit(this=0x7fff5fbfda60, s=0x000121121e40) + 149 at
s2ir.c:922
frame #27: 0x00010011c4d3 dmd`ScopeStatement::accept(Visitor*) + 31 at
statement.d:1763
frame #28: 0x00010014f242 dmd`Statement_toIR(s=0x000121121e40,
irs=0x7fff5fbfdad0) + 66 at s2ir.c:1283
frame #29: 0x00010014f588
dmd`S2irVisitor::visit(this=0x7fff5fbfdbc0, s=0x000121121e60) + 280 at
s2ir.c:895
frame #30: 0x00010011c173 dmd`UnrolledLoopStatement::accept(Visitor*) +
31 at statement.d:1677
frame #31: 0x00010014f242 dmd`Statement_toIR(s=0x000121121e60,
irs=0x7fff5fbfdc00) + 66 at s2ir.c:1283
frame #32: 0x00010014f6b5
dmd`S2irVisitor::visit(this=0x7fff5fbfdcf0, s=0x000121118060) + 149 at
s2ir.c:922
frame #33: 0x00010011c4d3 dmd`ScopeStatement::accept(Visitor*) + 31 at
statement.d:1763
frame #34: 0x00010014f242 dmd`Statement_toIR(s=0x000121118060,
irs=0x7fff5fbfdd58) + 66 at s2ir.c:1283
frame #35: 0x00010014fd9b
dmd`S2irVisitor::visit(this=0x7fff5fbfde50, s=0x000121118020) + 331 at
s2ir.c:198
frame #36: 0x000100123e23 dmd`IfStatement::accept(Visitor*) + 31 at
statement.d:3287
frame #37: 0x00010014f242 dmd`Statement_toIR(s=0x000121118020,
irs=0x7fff5fbfe328) + 66 at s2ir.c:1283
frame #38: 0x00010014f446

[Issue 15053] New: Runtime.cArgs not @nogc

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15053

  Issue ID: 15053
   Summary: Runtime.cArgs not @nogc
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: m...@philpax.me

When using @nogc code and/or C standard library functions, accessing the
standard C main arguments is useful. Unfortunately, cArgs is not @nogc:

---
import core.stdc.stdio;
import core.runtime;

@nogc:
void main()
{
// NG
printf("%s\n", Runtime.cArgs.argv[0]);
}
---

--

Re: Enumap -- a lightweight AA alternative when your keys are enums

[rcorre via Digitalmars-d-announce]

On Friday, 11 September 2015 at 03:25:58 UTC, SimonN wrote:


It doesn't seem to matter whether I put const int, or int, in 
the foreach statement.


What's the idiomatic way to loop over a const Enumap? :-)

-- Simon


I've released v0.4.0, which implements foreach with ref, and 
(hopefully) atones for my crimes against const-correctness. You 
should be able to modify values in a loop and work with 
const/immutable Enumaps.


Thanks for the feedback!

[Issue 15052] dmd/std/utf.d error on variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15052

pedrolopes  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from pedrolopes  ---
Solves!

clean all phobos files and reinstalled DMD.
old files from phobos had not been replaced during some DMD update
installation.

--

Re: Looking for someone that could work on 32 bits support for SDC

[Brandon Ragland via Digitalmars-d]

On Friday, 11 September 2015 at 01:35:09 UTC, deadalnix wrote:
On Friday, 11 September 2015 at 01:12:21 UTC, Brandon Ragland 
wrote:

[...]


Sure. First thing first, try to checkout the project and get it 
to build and pass the tests (well, some tests will fail, but 
you should get 0 regressions).


Step 2 would be to modify the test runner to be able to run in 
64 or 32 bits. Some tests will have a different result in 32 
bits, notably the ones that use the pointer size somewhere. 
(tests/runner.d)


Step 3 add a m32/m64 flags to SDC. It is using the getopt from 
phobos and that should be fairly straightforward. 
(sdc/src/main.d)


Step 4 go through the codegen (libd-llvm) and update it to take 
the flag into account. (that's the big chunk). There may be 
some places in the frontend that assume 64 bits pointers, but 
if so, not many.


Step 5 go through the runtime and do the same. There shouldn't 
be many here as well, but I'm not sure.


In a first instance, I guess the right move is to target x86 
because it is fairly close to x64 so it should work with 
minimal changes in the runtime.


You can jump in IRC if you want to talk more about the details.


x86 would be easiest to target.

I've checked out the repo, built it so far, and indeed some 
failures but no big deals.


Currently paging through to get a hold on what's in there. (I'll 
be the first to admit I don't know squat about the LLVM compiler).

Re: Adjacent Pairs Range

[deed via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 10:17:19 UTC, Nordlöw wrote:
How do I most elegantly iterate all the adjacent pairs in an 
`InputRange` using Phobos?


Something like

[1,2,3,4] => [(1,2), (2,3), (3,4)]


Why not just:

zip(arr[0 .. $-1], arr[1 .. $])

?

Re: Operator overloading or alternatives to expression templates

[Andrei Alexandrescu via Digitalmars-d]

On 09/12/2015 04:08 PM, Martin Nowak wrote:

On Friday, 11 September 2015 at 23:47:42 UTC, Andrei Alexandrescu wrote:

1. Use lambdas, which seem to already do what you want:

db.get!Person.filter!(p => p.age > 21 && p.name == "Peter")

The way this'd go, the db.get!Person() call returns an input range of
Person. Presumably introspection is being used to bind fields in the
query such as "age" and "name" to static field names in struct Person.
Then good old std.algorithm.filter takes care of the rest.


I'm instantiating the lambda with a fake p to capture the expression so
I can translate it to whatever SQL, MongoDB, columnar db is used.


Yah, understood. Problem here is the approach is bound to run into walls 
at every few steps. Say you fix the comparisons to work. Then you have 
operators such as LIKE that are necessary yet not representable in D. So 
more tricks are in order. This is what I've seen with ET in C++ - an 
endless collection of tricks to achieve modest outcomes at enormous costs.



2. If you want to embed real SQL into D, use string-based DSLs.


Strings don't capture context, aren't typechecked, and require a complex
CTFE parser.

db.get!Person.where!"age > 21 & name = ?"(name);


Understood as well. I figure from the example you have binding in mind, 
which is good. At some point you need to bite the bullet and write a 
parser for the relational query language you want there.



Andrei

Re: Build It And They Will Not Come

[Bahman Movaqar via Digitalmars-d-announce]

On 09/13/2015 08:51 AM, Meta wrote:
> It's funny, people are willing to suspend their disbelief for demons
> from hell, but not for the lack of a flashlight and duct tape. It's
> probably because it was an annoying game mechanic, and taping a
> flashlight to a gun is something so simple and mundane that you *can't*
> suspend your disbelief at Doom Guy being unable to find a way to use
> both at once somehow.

Have you ever tried taping 8 different flashlights to 8 different
weapons ranging from a pistol to a badass BFG while carrying a
light-tank-load of ammunition?  I'm not even talking about finding tapes
in that demon-infested compound with those jammed office doors that once
you open them an imp (in the best case) tries to plasma-whack you!

Cut the doom guy some slack!  We owe him our very existence!

:-)

-- 
Bahman Movaqar



signature.asc
Description: OpenPGP digital signature

Does a synchronization yield on waiting thread?

[Prudence via Digitalmars-d-learn]

It would seem to be the logical thing to do?

That is, suppose two threads are sharing a resource. Thread A has 
it locked. B is "waiting". Is B in a loop burning cycles running 
in the background(regardless of thread.sleep, which only 
alleviates the problem) or does it yield completely and somehow 
inform the lock to resume it when A has unlocked the resources?


The first one burns cycles and can have timing problems. I.e., 
What if A locks and unlocks at the same rate that B checks? (I 
suppose a random sleep time would help with this) (


"Yielding", OTOH, has B burn no cycles waiting in a loop. This 
can lead to optimization and prioritization and all that(after an 
unlock, all the threads waiting can be called, but in what order).


Obviously yielding is more complex and requires the threads kept 
track of(an array for each lock/unlock pair) but far more 
efficient.


I'm hoping D does this, but not holding my breath.

Re: Build It And They Will Not Come

[Meta via Digitalmars-d-announce]

On Saturday, 12 September 2015 at 14:25:46 UTC, Nick Sabalausky 
wrote:
That's pretty similar to how I felt about Doom3: People 
complained how "unrealistic" it was to not be able to duct tape 
the flashlight to the gun, but...For crap's sake, it's a game 
about a demon invasion from hell and one guy single-handedly 
holding them all off. Realism and believability were obviously 
never the point. :)


'Course, that game had other issues, but realism (or lack of) 
was never one of them.



But maybe I'm misremembering. Saw it a long time ago.


Never saw it myself, but that's what I'd heard it was about.


It's funny, people are willing to suspend their disbelief for 
demons from hell, but not for the lack of a flashlight and duct 
tape. It's probably because it was an annoying game mechanic, and 
taping a flashlight to a gun is something so simple and mundane 
that you *can't* suspend your disbelief at Doom Guy being unable 
to find a way to use both at once somehow.

Re: Looking for someone that could work on 32 bits support for SDC

[deadalnix via Digitalmars-d]

On Sunday, 13 September 2015 at 02:19:27 UTC, BBasile wrote:

On Wednesday, 9 September 2015 at 20:33:43 UTC, deadalnix wrote:

All is in the title.

ARM/Mips/pNaCl/WebAssembly require 32bits to work. These are 
valuable targets IMO.


I can provide support, but I just don't have the bandwidth to 
pull it by myself. If someone could step up, that'd be great.


Do you think that libd is 32bit ready ?

https://github.com/SDC-Developers/SDC/pull/141


Building on 32 bits and generating 32 bit code are 2 different 
things.


No I don't think libd can compile on a 32 bits system ATM, but I 
do not expect it to be that far away from being able to do so.

Re: A collection of DIPs

[NX via Digitalmars-d]

On Friday, 11 September 2015 at 19:30:56 UTC, ponce wrote:
Some of us use and need @nogc all the time. The other parts of 
an application can use the GC: best of both worlds.


Is there even a compiler switch to disable GC altogether so the 
program doesn't have a GC thread? No, I can't see it...

Re: std.allocator ready for some abuse

[bitwise via Digitalmars-d]

On Saturday, 12 September 2015 at 06:30:42 UTC, bitwise wrote:
On Saturday, 12 September 2015 at 00:31:27 UTC, Andrei 
Alexandrescu wrote:

[...]


This sounds like the default setup I'll be using. The 
containers will use a Mallocator by default, so I will have to 
add the ranges when the contained type is found to have 
indirections.


[...]


Alternatively, GC.addRange() could return a value indicating 
whether or not the range had actually been added(for the first 
time) and should be removed.


   Bit

Difference between back (`) and double (") quoted strings

[Bahman Movaqar via Digitalmars-d-learn]

Is there any or they are just simply syntactically equivalent?
Are there any official docs on this?

-- 
Bahman Movaqar

http://BahmanM.com - https://twitter.com/bahman__m
https://github.com/bahmanm - https://gist.github.com/bahmanm
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)



signature.asc
Description: OpenPGP digital signature

Re: Multidimension AA's and remove

[NX via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 05:54:13 UTC, NX wrote:

import std.stdio : writeln, std.algorithm.mutation : remove;


Ooops, this is so wrong! Corrected version:

void main()
{
import std.stdio : writeln;
import std.algorithm.mutation : remove;

int[][string] heh = [ "heh":[ 0, 10, 15, 20 ] ];
heh["heh"][0] = 5;
writeln(heh); // ["heh":[5, 10, 15, 20]]
heh["heh"] = remove!(c => (c == 15))(heh["heh"]);
writeln(heh); // ["heh":[5, 10, 20]]
}

Re: Better lambdas!!!!!!!!!!

[Ola Fosheim Grostad via Digitalmars-d]

On Friday, 11 September 2015 at 23:15:58 UTC, Jonathan M Davis 
wrote:
style lambdas in D. However, given the complexity of C++ 
templates, as I understand it, there are no plans to ever 
support them in C++ interop (since it would pretty much mean 
putting a C++ compiler in the D compiler), in which case, 
there's no need to worry about C++ lambdas anyway, because they 
all involve templates.


No, you have to generate c++ sourcecode. No need to build in the 
compiler.

Re: shared array?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, September 11, 2015 23:29:05 Laeeth Isharc via Digitalmars-d-learn 
wrote:
> On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe wrote:
> > On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote:
> >> Oh really?!?! I thought slicing used the GC? Is this a recent
> >> development or always been that way?
> >
> > Always been that way. A D slice is just a C pointer + length
> > packed together. A slice simply increments the pointer and/or
> > decrements the length - no allocation needed.
> > (btw the garbage collector is actually pretty nice, why are you
> > avoiding it anyway?)
>
> Seems to be quite a lot of FUD wrt use of standard library and
> GC, which means also perhaps we don't communicate this point very
> well as a community.  Making Phobos GC-optional perhaps is an
> ultimate answer.  But people seem to think that you're back to C
> without the GC.

Aside from the few classes in Phobos, its GC usage is almost entirely
restricted to when it allocates arrays or when it has to allocate a closure
for a delegate, which can happen in some cases when passing predicates to
range-based algorithms. Avoiding functions that need to allocate arrays
avoids that source of allocation, and using functors or function pointers
as predicates avoids having to allocate closures. So, you _can_ end up with
GC allocations accidentally in Phobos if you're not careful, but on the
whole, the assertion that Phobos uses the GC heavily is FUD - or at least a
misunderstanding. But as we make more of the functions use lazy ranges
rather than arrays (particularly with regards to strings), and we make more
of the code @nogc, it becomes even clearer that the GC isn't involved. Also,
improvements to how lambdas are handled should reduce how often closures
have to be allocated for them.

Probably the may issue that actually requires a language change is that
exceptions currently pretty much have to be GC-allocated whereas they really
should be reference-counted (though possibly still GC-allocated, just not
left for a garbage collection cycle), but exceptions are thrown rarely,
meaning that the fact that they're GC allocated is really only a problem if
you're trying to avoid the GC completely rather than just minimize its use,
so it's rarely a problem. And there are plans to support reference-counted
types in the language, in which case, the exception types would be change to
use that Object hierarchy rather than the normal one.

So, we have improvements to make, but for the most part, I think that the
idea that Phobos requires a GC is FUD. It's not completely false, but folks
seem to think using Phobos means heavy GC usage, and for the most part,
that's not true at all.

- Jonathan M Davis

Re: std.allocator ready for some abuse

[bitwise via Digitalmars-d]

On Saturday, 12 September 2015 at 00:31:27 UTC, Andrei 
Alexandrescu wrote:

On 09/11/2015 07:46 PM, bitwise wrote:

[...]


Say you have a container that uses its own allocator inside, 
yet offers the user to store objects with indirections that use 
the GC. Then indeed the container would need to call addRange 
and removeRange on its own internal structures.


This sounds like the default setup I'll be using. The containers 
will use a Mallocator by default, so I will have to add the 
ranges when the contained type is found to have indirections.


If, on the contrary, the container imposes that its own held 
objects use the container's allocator as well (a rare but not 
implausible design), it wouldn't need to do that.


I don't understand exactly what you mean, but here is a more 
verbose version of my concern:


Lets say someone's allocator calls GC.addRange on the memory it 
allocates before a container gets it. The container would call 
GC.addRange when it gets it, but then call GC.removeRange before 
calling allocator.deallocate(). The allocator which think's the 
block has already been registered with the GC could possibly 
reuse it, thinking it's registered with the GC alreadybut 
that allocator may pass the memory to a container which chooses 
not to call GC.addRange, because it thinks it's using an 
allocator that does that for it. That second container may now 
store types with indirections, which would be unreachable, and 
get freed, and..chaos.


I suppose that as a general rule, a container could always add 
ranges it gets from an allocator to the GC, which would prevent 
the above problem...but only for containers that abide by the 
rule. It sounds like you're saying that although it may not be 
needed sometimes, that no harm would be done.


I think a better solution though would be for the GC to have 
something like GC.hasRange(). The container could check the state 
of the memory it receives and take appropriate action. I don't 
see anything in the current GC docs which would allow you to tell 
if a range had already been added to the GC.


Bit

[Issue 15026] cannot array assign to a slice return value

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15026

anoneu...@gmail.com changed:

   What|Removed |Added

 CC||anoneu...@gmail.com

--- Comment #2 from anoneu...@gmail.com ---
The first example doesn't look to me like it should compile. Is it not
equivalent to this?

void test()
{
(cast(int[]) null) = 2;
}

The second example works if you use opIndexAssign instead of opSlice:

struct Foo
{
int[] opIndexAssign(int v)
{
return null;
}
}

void test()
{
Foo foo;
foo[] = 2;
}

--

Re: How To: Passing curried functions around

[Bahman Movaqar via Digitalmars-d-learn]

On Friday, 11 September 2015 at 21:06:32 UTC, Ali Çehreli wrote:

On 09/11/2015 02:04 PM, Ali Çehreli wrote:

The same keyword has a different use with
templates:


And the official documentation:

  http://dlang.org/template.html#TemplateAliasParameter



Thanks again!

Re: Reasons to use D

[Bahman Movaqar via Digitalmars-d]

On Friday, 11 September 2015 at 17:58:49 UTC, bachmeier wrote:
On Friday, 11 September 2015 at 14:17:03 UTC, Bahman Movaqar 
wrote:
On Friday, 11 September 2015 at 13:15:03 UTC, Adam D. Ruppe 
wrote:

"3. The documentation poor."

I agree but so is the documentation for virtually 
everything else I've ever used too. I'd take D's over Ruby's 
for example.


Couldn't help but to drop in and count two exceptions: 
Racket's docs[1] and Java API docs[2].


[1] http://docs.racket-lang.org/
[2] http://docs.oracle.com/javase/7/docs/api/


I'd add Guile. It's fun to read the manual.


/me nods
Another fun manual is Gforth's.

Re: Difference between back (`) and double (") quoted strings

[NX via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 08:13:33 UTC, Bahman Movaqar 
wrote:
Is there any or they are just simply syntactically equivalent? 
Are there any official docs on this?


What if I told you, you should search the official reference 
before asking such things in the forum?


http://dlang.org/lex.html#WysiwygString

Wysiwyg: What you see is what you get

  writeln(`\asd"fg"hj
hmph'`);


\asd"fg"hj
haha'

Re: Hello World Example with Glade?

[Mike McKee via Digitalmars-d-learn]

On Friday, 11 September 2015 at 20:29:05 UTC, Mike Wey wrote:
You should be able to drop the -L-ldl and -I/usr/ flags, as 
they are included in the pkg-config output.


I just tested and you are correct. Now, is there a way that I can 
edit /etc/dmd.conf and make it so that I don't need to do this 
pkg-config stuff all the time?

[Issue 12210] dlang.org home page example - Run button does not work

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12210

--- Comment #9 from Gerald Jansen  ---
Perhaps this is a slightly different issue but it is related so I'll just
mention it here. The example in the section "Convenience" under the paragraph
starting with "Automatic memory management makes for safe, simple, and robust
code.", crashes with message:

Application output: (1 Hangup)
Exiting main.
std.exception.ErrnoException@std/stdio.d(385): Cannot open file `text.txt' in
mode `rb' (No such file or directory)

... and a bunch of incomprehensible junk (for a casual visitor)

Having examples that don't run is probably worse than no examples. Perhaps the
priority of this issue should be increased. Perhaps the more general issue is
how to continuously test and ensure that all example code highlighted on
dlang.org runs correctly.

--