Re: Idempotent partition around median of 5?

[Andrei Alexandrescu via Digitalmars-d]

On 02/06/2016 01:42 PM, tn wrote:

On Saturday, 6 February 2016 at 13:06:37 UTC, Andrei Alexandrescu wrote:

Could you please add two simple calculations? Assuming uniform random
distribution of data, compute the average number of swaps as a
weighted average of orderings. Also, show the number of lines (one
test or one swap per line) as a proxy for generated code size. That
should provide good insights.


This now prints the numbers of comparison and swap lines and computes
the average numbers of swaps. In addition, it also runs the same tests
for permutations of 5 elements some of which might be equal (an example
of such permutation would be [1, 2, 0, 2, 3], on the other hand [1, 2,
0, 2, 4] should not be included since it is identical). However, in this
case the average number of swaps is perhaps not so meaningful.

http://dpaste.dzfl.pl/2012caf872ec


Awesome, thanks. Will need to try at least a few of these out. At a 
quick glance, partition5d seems to be the sweet spot - it's small and 
does only 3.13/2.57 swaps on average. -- Andrei

Re: Google Summer of Code 2016

[Craig Dillabaugh via Digitalmars-d]

On Friday, 15 January 2016 at 20:46:59 UTC, Tavi wrote:
On Friday, 15 January 2016 at 16:06:00 UTC, Craig Dillabaugh 
wrote:

On Friday, 15 January 2016 at 15:11:39 UTC, Tavi wrote:
On Thursday, 14 January 2016 at 18:56:21 UTC, Craig 
Dillabaugh wrote:
Deadline is getting closer, any new project ideas are 
welcome. Starting to get some contact from students now.



FlatBuffers for DLang - http://google.github.io/flatbuffers/


Are you volunteering as a potential mentor :o)


I haven't started anything seriously in D yet, so I would not 
be qualified for such mentoring.
Being an efficient cross platform serialization library started 
at Google (already supporting C++, Java, C#, Go, Python and 
JavaScript), may be a good candidate for GSOC.


Anyone interested and capable of mentor a student interested in 
doing FlatBuffers for D.

[Issue 15647] Casting from one C++ interface in a hierarchy to another is a noop

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/91a859cdad8cbbe5b6c20a0f8eb4e1da07e1f70a
fix Issue 15647 - Casting from one C++ interface in a hierarchy to another is a
noop

https://github.com/D-Programming-Language/dmd/commit/3a1a7e2196497d2dbd233a4bb4c2b2c7a7d3ebb2
Merge pull request #5402 from WalterBright/fix15647

fix Issue 15647 - Casting from one C++ interface in a hierarchy to an…

--

[Issue 15647] Casting from one C++ interface in a hierarchy to another is a noop

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Things that keep D from evolving?

[cy via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad 
wrote:

This prevents fast GC: Pointers.


Would it be possible to write a fast garbage collector that just 
didn't track any pointers? Just offer a head's up that if you use 
"this collector" and pointers on collectable data, you're gonna 
have a bad time? How limited would you be if you couldn't use 
pointers in your code? Do all D references count as pointers, or 
is it only the T* types? Does Nullable!T count as one of those 
pointers that can't be tracked quickly?

[Issue 15490] [REG 2.067] Error variable __nrvoretval cannot be modified at compile time when using -inline

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/b56fa1d1b02c93151f0a25d868f4459cac8d6a4d
fix Issue 15490 - Error variable __nrvoretval cannot be modified at compile
time when using -inline

CTFE interpretr can recognize a form `CommaExp(DeclaraationExp(v), VarExp(v))`
as
a CTFEable variable declaration when `v._init` is `null`. In other cases, for
examle a sole `DeclarationExp` should have v._init for CTFE-ability.

Supply `VoidInitializer` to allow inlining the temporary for NRVO.

https://github.com/D-Programming-Language/dmd/commit/31232a9c64e799c439af5e3501b20cf9b7e7372b
Merge pull request #5415 from 9rnsr/fix15490

[REG 2.067] Issue 15490 - Error variable __nrvoretval cannot be modified at
compile time when using -inline

--

[Issue 11837] String literals should convert to const(void)*

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--

[Issue 15650] Closure variable access broken if only referenced in contract

[via Digitalmars-d-bugs]

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

David Nadlinger  changed:

   What|Removed |Added

Summary|Closure variable access |Closure variable access
   |broken in contracts |broken if only referenced
   ||in contract

--

[Issue 15650] New: Closure variable access broken in contracts

[via Digitalmars-d-bugs]

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

  Issue ID: 15650
   Summary: Closure variable access broken in contracts
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@klickverbot.at

The following test case, an adapted version of runnable/test10981.d, fails
using DMD 2.070 (OS X, but that's irrelevant):

---
auto foo(int i)
{
class X1
{
void in_nested() in {
import core.stdc.stdio;
printf("%d\n", i);
assert(i);
} body {}
}

return new X1;
}

void main() {
auto a = foo(1234);
a.in_nested();
}
---

The problem seems to be that the frontend assumes that variable references from
contracts *never* make the variable in question a closureVar, irrespective of
whether the variable accessed is in the direct parent function or further up
the chain.


[1]
https://github.com/D-Programming-Language/dmd/blob/9d1edd1e78031e5760cc7cf923dd0bf9b1f8e7e6/src/declaration.d#L2232

--

[Issue 11837] String literals should convert to const(void)*

[via Digitalmars-d-bugs]

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

--- Comment #19 from Andrei Alexandrescu  ---
Related discussion: https://github.com/D-Programming-Language/dmd/pull/5411.
I'll close this now.

--

Re: Proposal: Database Engine for D

[Chris Wright via Digitalmars-d]

On Sat, 06 Feb 2016 13:41:03 +, Piotrek wrote:

> On Saturday, 6 February 2016 at 00:14:08 UTC, Mengu wrote:
>> and while we were talking the talk, rust community rolled out something
>> good called diesel. check it out at http://diesel.rs/.
>>
>> we need tools that get things done. we do not need tools that makes
>> things more complex than they already are.
> 
> Almost no one (including me) is interested in ORM for SQL.

You mean, a high-level query language abstracting across multiple 
databases, expressed in terms of my object model rather than physical 
tables. You're talking about HQL, not Hibernate as a whole.

Nobody wants to write manual serialization and deserialization code. Not 
when there's a reliable, low-cost alternative. And if I could just write 
my object model and have an automated system create my database tables 
and upgrade scripts for me, that would be cool too.

> The point is
> ORM+SQL is limiting and sooner or later you fallback to SQL.

The HQL I recall would be bad for reporting and aggregation, but since I 
never needed that, perhaps I just didn't find the relevant options and 
syntax.

I find HQL slightly nicer to work with than SQL, but since the databases 
themselves aren't speaking it, it's not so handy. I found one query that 
I needed where HQL could do it in two minutes and hand-written SQL could 
do it in fifty milliseconds. That's rare, but it does happen.

Re: What's going to replace std.stream?

[cy via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 08:24:59 UTC, Jakob Ovrum wrote:

foreach(chunk; File("path/to/file").byChunk(16 * 1024))


Ohh, cool so the streaming...ish logic is in std.stdio now. I 
thought that module was only for text output.

[Issue 15490] [REG 2.067] Error variable __nrvoretval cannot be modified at compile time when using -inline

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Why can't compile time expressions do ___?

[cy via Digitalmars-d-learn]

I'm not clear on why you aren't allowed to allocate memory with 
compile time execution, or why access to the filesystem is 
restricted. (Unless you pass -J/ I think?)

Re: Detecting exception unwinding

[cy via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 14:25:21 UTC, Ola Fosheim Grøstad 
wrote:

See, even Python supports this. :-)


And D supports the "with" statement in python, in the form of 
"scope()" statements. The D way is slightly less misleading too, 
as


with somethingThatFails() as e:
  print(e)

doesn't make it obvious that neither __enter__ nor __exit__ will 
be called if you raise an exception in the creation of the 
object, or that if you raise an exception in __enter__, then 
__exit__ won't be called.


auto e = somethingThatFails()
scope(failure) cleanup(e);

makes more sense to me, since it's blatantly obvious that the 
construction (and entering) process isn't covered by the cleanup 
routine.

Re: Dynamic Ctors ?

[Ali Çehreli via Digitalmars-d-learn]

On 02/06/2016 10:05 AM, Voitech wrote:

> create manually, constructor
> for each of T... parameter types

You can use string mixins (makeCtor and makeCtors):

string makeCtor(T)() {
import std.string : format;

return format(q{
this (%s t) {
import std.stdio : writefln;
writefln("Ctor for %%s", %s.stringof);
}
}, T.stringof, T.stringof);
}

// Note: Use a pragma(msg) to see what it generates:
// pragma(msg, makeCtor!int);

string makeCtors(T...)() {
string result;
foreach (Type; T) {
result ~= makeCtor!Type();
}
return result;
}

mixin template foo(T...) {

class Inner {
mixin (makeCtors!T());
}
}

mixin foo!(int, string);

void main() {
auto i = new Inner(42);
auto s = new Inner("hello");
}

Output:

Ctor for int
Ctor for string

Ali

Re: Proposal: Database Engine for D

[David DeWitt via Digitalmars-d]

On Saturday, 6 February 2016 at 13:41:03 UTC, Piotrek wrote:

On Saturday, 6 February 2016 at 00:14:08 UTC, Mengu wrote:
and while we were talking the talk, rust community rolled out 
something good called diesel. check it out at 
http://diesel.rs/.


we need tools that get things done. we do not need tools that 
makes things more complex than they already are.


Almost no one (including me) is interested in ORM for SQL. The 
point is ORM+SQL is limiting and sooner or later you fallback 
to SQL.




I wouldn't say almost no one.  I know Sql Alchemy is very popular 
and used by a lot of ppl. Ive used and not used ORMs on numerous 
projects and sometimes they make sense and sometimes they do not. 
 I agree its not needed but alot of these tools are used by 
average developers and not having them isn't going to help D.   
Not that we don't need them but when ppl say "Well I like D but 
find there are missing libraries I want"  A decent ORM would 
prolly be one of them.  Basically if Rust continues to get these 
libraries and they are decent then they will def attract more ppl 
to the language instead of them possibly coming to D if that is 
important which I know has been brought up before and I think 
projects and tools like these with further attract ppl.

Re: Why can't compile time expressions do ___?

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

On Saturday, 6 February 2016 at 22:13:55 UTC, cy wrote:
I'm not clear on why you aren't allowed to allocate memory with 
compile time execution


You can... use the built-in new operator or arrays, etc.

or why access to the filesystem is restricted. (Unless you pass 
-J/ I think?)


CTFE is a "pure" environment, it is supposed to only depend on 
the code and passed compile options (which may indeed include a 
path with -J that you are allowed to read files from). It doesn't 
actually run a complete program on the installed computer / OS, 
it just does some computations.


This is meant to be a security thing (which IMO is dubious) and a 
platform issue: D code can be compiled independently of an 
operating system.

An IO Streams Library

[Jason White via Digitalmars-d]

I see the subject of IO streams brought up here occasionally. The 
general consensus seems to be that we need something better than 
what Phobos provides.


I wrote a library "io" that can work as a replacement for 
std.stdio, std.mmfile, std.cstream, and parts of std.stream:


GitHub:  https://github.com/jasonwhite/io
Package: https://code.dlang.org/packages/io

This library provides an input and output range interface for 
streams (which is more efficient if the stream is buffered). 
Thus, many of the wonderful range operations from std.range and 
std.algorithm can be used with this.


I'm interested in feedback on this library. What is it missing? 
How can be better?


I'm also interested in a discussion of what IO-related 
functionality people are missing in Phobos.


Please destroy!

Re: What's going to replace std.stream?

[Jakob Ovrum via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 06:29:56 UTC, cy wrote:
Let's say I have a socket, and a file, and I want to send the 
contents of that file to the socket. What's the best way to do 
that? Yes I'm aware that in Linux, you can use a combination of 
a pipe and splice(2) to keep all buffers kernel side for that, 
but I was thinking more generally. The traditional C way is to 
read() into a buffer, then write() it out, until the input is 
exhausted. But apparantly in D we're not supposed to do that?


It's just that I tried to use std.stream, and found that the 
whole module had been marked as deprecated some time last year. 
What exactly is going to replace it? Some sort of lazy file 
contents accessor, that can take advantage of zero copy things 
like splice() when hooked together? A source/sink paradigm 
maybe?


I don't see anything analagous to what std.stream does in 
phobos... has it just not been made public yet?


There are some third party libraries that implement streams [1], 
but your example can be done like:


foreach(chunk; File("path/to/file").byChunk(16 * 1024))
socket.write(chunk);

[1] e.g. http://code.dlang.org/packages/io

Re: Things that keep D from evolving?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC 
implementations?


This prevents fast GC: Pointers.

This prevents precise GC: internal Pointers + FFI.

Go now has <10ms latency for small heaps, <20ms latency for up to 
100GB heaps and <40ms latency for up to 250GB heaps.


But IIRC when calling a  C function in Go, the function called 
should not retain pointers or go down indirections?


https://talks.golang.org/2016/state-of-go.slide#37


So, basically, if you want fast memory release, forget using the 
GC in D.



What makes it impossible to have ref counted classes?


Nothing.

What are some other technical / design problems you 
encountered? (other than poor implementation and lack of 
resources)


Lack of focus on what most programmers expect from system level 
programming.

Re: Proposal: Database Engine for D

[Craig Dillabaugh via Digitalmars-d]

On Thursday, 31 December 2015 at 17:14:55 UTC, Piotrek wrote:
The goal of this post is to measure the craziness of an idea to 
embed a database engine into the D language ;)


I think about a database engine which would meet my three main 
requirements:

  - integrated with D (ranges)
  - ACID
  - fast

Since the days when I was working on financing data SW I become 
allergic to SQL. I though that NoSQL databases would fill the 
bill. Unfortunately they didn't. And I want to have an ability 
to write a code like this without too much effort:


  struct Person
  {
   string name;
   string surname;
   ubyte age;
   Address address;
  }

 DataBase db = new DataBase("file.db");
 auto coll = db.collection!Person("NSA.Registry");
 auto visitationList = coll.filter!(p => p.name == "James");
 writeln (visitationList);

And other things like updating and deleting from db. I think 
you get my point.


So I started a PoC project based on SQLite design:
https://github.com/PiotrekDlang/AirLock/blob/master/docs/database/design.md#architecture

The PoC code: 
https://github.com/PiotrekDlang/AirLock/tree/master/src/database


Can you please share your thoughts and experience on the topic? 
Has anyone tried similar things?


Piotrek


I've scanned this thread, but haven't seen if any 'decisions' 
have been more, or if it is just more of the usual back-and-forth 
with nothing being decided.  However, I did have one (Ok two) 
questions.


1. Is there a GSOC project in here somewhere?
2. Who would want to mentor such a thing?

Re: Idempotent partition around median of 5?

[Timon Gehr via Digitalmars-d]

On 02/06/2016 02:00 PM, Andrei Alexandrescu wrote:

On 02/05/2016 08:58 PM, Timon Gehr wrote:

On 02/06/2016 02:39 AM, Andrei Alexandrescu wrote:

On 02/04/2016 03:30 PM, Timon Gehr wrote:

At most 6 comparisons, <=3 swaps, idempotent (optimal number of swaps):


What is the minimum number of comparisons? Thx! -- Andrei


There is no partition algorithm that uses <= 5 comparisons in all cases.
(If that is what you're asking.)


Was asking about this particular one. For example, the maximum
comparisons is 6, but it would be good to know the average number of
comparisons. I know I could read through the code, but it's hairy.
Thanks! -- Andrei



All versions posted in this thread do 6 comparisons on all code paths.
(It is not possible to do better.)

BTW, the code I had posted earlier suffers from the following flaws:

- Branches were cut off too early, so -version=SHORT didn't actually 
find the shortest code. [1]


- The code (by necessity) only performs the optimal number of swaps if 
all input elements are different. While it leaves already partitioned 
integer arrays in the same state as they were encountered, if multiple 
input elements are equal, the generated algorithm will sometimes swap 
them, violating idempotence if input elements can compare equal but be 
different. However, tn's versions fix this: they never perform any swaps 
if the input array is already partitioned.




[1] This seems to be the shortest code that satisfies the specification 
I have given (<=6 comparisons, optimal number of swaps) for permutations 
and that performs all the comparing before all the swapping:


void partition5(ref int[5] a){

if(a[0]

Re: Detecting exception unwinding

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 06:08:41 UTC, cy wrote:
Sorry, years of python programming have made me shy of 
destructors. It just looks a little less "magic" to me if I 
specify the destruction explicitly after creating the object, 
using the "scope(exit)" syntax.


That is error-prone!

In Python you are supposed to use the with-statement to get RAII 
like behaviour. So you use __enter__ and __exit__ methods on the 
context-manager. From the Python docs:


«The context manager’s __exit__() method is invoked. If an 
exception caused the suite to be exited, its type, value, and 
traceback are passed as arguments to __exit__(). Otherwise, three 
None arguments are supplied.»


See, even Python supports this. :-)

Re: Idempotent partition around median of 5?

[Andrei Alexandrescu via Digitalmars-d]

On 2/6/16 9:26 AM, Timon Gehr wrote:

[1] This seems to be the shortest code that satisfies the specification
I have given (<=6 comparisons, optimal number of swaps) for permutations
and that performs all the comparing before all the swapping:


Thanks. Tried this just now, it's better than the pre-discussion 
baselines but Ivan's still beats it (by a little). Then I just tried 
tn's partition5c which beats Ivan's.


I should also add that returns are starting to diminish. Idempotence did 
make a large difference. Then reducing max swaps made a smaller 
difference (at least for the uints I'm working with).


BTW my testbed is a careful implementation of BFPRT on random arrays of 
uint of various sizes.



Andrei

Re: Vision for the first semester of 2016

[Piotrek via Digitalmars-d-announce]

On Friday, 29 January 2016 at 02:18:38 UTC, Rikki Cattermole 
wrote:
Right now, image library is more or less ready for next 
feedback.
Windowing is almost there, really just needs a bit of testing 
and its done.


So in other words, the hold up, is me.


Where can I find the code to be tested? You have too many 
projects on github :)


Piotrek

Re: Things that keep D from evolving?

[ZombineDev via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 15:14:06 UTC, Kagamin wrote:

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:

What language semantics prevent precise


Lack of resources. Precise GC needs to know which fields are 
pointers. Somebody must generate that map. AFAIK there was an 
experiment on that.


That information has already been present for a couple of releases
(http://dlang.org/spec/traits.html#getPointerBitmap), however 
currently the precise GC is slower than the conservative one, 
because of the overhead the the extra metadata has. For more 
info, you can read the comments on these two PRs:

https://github.com/D-Programming-Language/druntime/pull/1022
https://github.com/D-Programming-Language/druntime/pull/1057

Re: foreach seems to work with opIndex()

[H. S. Teoh via Digitalmars-d-learn]

On Sat, Feb 06, 2016 at 03:11:22PM +, ZombineDev via Digitalmars-d-learn 
wrote:
> On Saturday, 6 February 2016 at 15:02:16 UTC, H. S. Teoh wrote:
> >On Sat, Feb 06, 2016 at 02:43:52PM +, Tofu Ninja via
> >Digitalmars-d-learn wrote:
> >>Foreach seems to work if there is an opIndex() with no arguments
> >>that returns a range interface, is this documented? I can't seem to
> >>find anything that say this is supposed to happen. I am not really
> >>complaining, its nice, but I just didnt really expect it because I
> >>feel like I remember this being an error some time ago.
> >
> >Not really sure, but opIndex() with no arguments is supposed to be
> >the current way of implement the [] slicing operator for user-defined
> >types.  I'm not sure when foreach started supporting that, but it's
> >certainly a nice thing!
> >
> >
> >T
> 
> I thought that opSlice() was supposed to be that operator. At least
> this is what's used in std.container (e.g.
> http://dlang.org/phobos/std_container_array.html#.Array.opSlice).

That's the old use of opSlice(), which is still supported for backward
compatibility. The new use of opSlice, after Kenji's multidimensional
array PR, is to translate x..y notation into a type that opIndex can
understand. Namely, this:

x[1, 2..3, 4, 5..6]

is translated into:

x.opIndex(1, x.opSlice(2,3), 4, x.opSlice(5,6))


T

-- 
I am Ohm of Borg. Resistance is voltage over current.

Re: New D book available for pre-order: D Web Development

[Saurabh Das via Digitalmars-d-announce]

On Wednesday, 22 July 2015 at 15:29:20 UTC, Kai Nacke wrote:

Hi all!

Did you notice that development of LDC has been a bit slowly in 
the past? The reason is my book D Web Development, available 
now for pre-order: 
https://www.packtpub.com/web-development/d-web-development


[...]


Congratulations!

I've asked to have this added to our office library :)

[Issue 15626] extern(C++) calling crash

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/6d01b29c86aab514cf40d6657bad866c9f7fb4e8
fix Issue 15626 - extern(C++) calling crash

https://github.com/D-Programming-Language/dmd/commit/a7b358a2824bab8421b0455b613d2b899f40
Merge pull request #5403 from WalterBright/fix15626

fix Issue 15626 - extern(C++) calling crash

--

[Issue 15626] extern(C++) calling crash

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Things that keep D from evolving?

[rsw0x via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 17:46:48 UTC, rsw0x wrote:
On Saturday, 6 February 2016 at 17:46:00 UTC, Ola Fosheim 
Grøstad wrote:

On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote:
Can't be done with the root class because classes never 
trigger RAII outside of (deprecated) scope allocations.


Not sure what you mean. The class instance doesn't have to 
trigger anything?


You "retain(instance)" to increase the refcount and 
"release(instance)" to decrease refcount or destroy the 
instance.


Might as well manually free and delete instead.


Er, malloc and free* : )

Re: Things that keep D from evolving?

[rsw0x via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 17:46:00 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote:
Can't be done with the root class because classes never 
trigger RAII outside of (deprecated) scope allocations.


Not sure what you mean. The class instance doesn't have to 
trigger anything?


You "retain(instance)" to increase the refcount and 
"release(instance)" to decrease refcount or destroy the 
instance.


Might as well manually free and delete instead.

Re: Things that keep D from evolving?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote:
Can't be done with the root class because classes never trigger 
RAII outside of (deprecated) scope allocations.


Not sure what you mean. The class instance doesn't have to 
trigger anything?


You "retain(instance)" to increase the refcount and 
"release(instance)" to decrease refcount or destroy the instance.

Re: Idempotent partition around median of 5?

[tn via Digitalmars-d]

On Saturday, 6 February 2016 at 13:06:37 UTC, Andrei Alexandrescu 
wrote:
Could you please add two simple calculations? Assuming uniform 
random distribution of data, compute the average number of 
swaps as a weighted average of orderings. Also, show the number 
of lines (one test or one swap per line) as a proxy for 
generated code size. That should provide good insights.


This now prints the numbers of comparison and swap lines and 
computes the average numbers of swaps. In addition, it also runs 
the same tests for permutations of 5 elements some of which might 
be equal (an example of such permutation would be [1, 2, 0, 2, 
3], on the other hand [1, 2, 0, 2, 4] should not be included 
since it is identical). However, in this case the average number 
of swaps is perhaps not so meaningful.


http://dpaste.dzfl.pl/2012caf872ec

Output:

testing 'partition5a'
  Code: comparisons = 63, swaps = 107, total = 170
  With all orderings of distinct elements:
0 swaps: 4 instances
1 swaps: 32 instances
2 swaps: 68 instances
3 swaps: 16 instances
Average number of swaps: 1.8
  With all orderings of potentially nondistinct elements:
Error, not idempotent: [0, 0, 0, 0, 0] => [0, 0, 0, 0, 0]
testing 'partition5b'
  Code: comparisons = 17, swaps = 21, total = 38
  With all orderings of distinct elements:
0 swaps: 4 instances
1 swaps: 20 instances
2 swaps: 42 instances
3 swaps: 40 instances
4 swaps: 14 instances
Average number of swaps: 2.3
  With all orderings of potentially nondistinct elements:
0 swaps: 36 instances
1 swaps: 122 instances
2 swaps: 200 instances
3 swaps: 146 instances
4 swaps: 37 instances
Average number of swaps: 2.04806
testing 'partition5c'
  Code: comparisons = 10, swaps = 12, total = 22
  With all orderings of distinct elements:
0 swaps: 4 instances
1 swaps: 14 instances
2 swaps: 25 instances
3 swaps: 30 instances
4 swaps: 26 instances
5 swaps: 16 instances
6 swaps: 5 instances
Average number of swaps: 3.06667
  With all orderings of potentially nondistinct elements:
0 swaps: 36 instances
1 swaps: 92 instances
2 swaps: 130 instances
3 swaps: 138 instances
4 swaps: 92 instances
5 swaps: 42 instances
6 swaps: 11 instances
Average number of swaps: 2.60628
testing 'partition5d'
  Code: comparisons = 7, swaps = 8, total = 15
  With all orderings of distinct elements:
0 swaps: 4 instances
1 swaps: 14 instances
2 swaps: 24 instances
3 swaps: 29 instances
4 swaps: 26 instances
5 swaps: 16 instances
6 swaps: 6 instances
7 swaps: 1 instances
Average number of swaps: 3.1
  With all orderings of potentially nondistinct elements:
0 swaps: 36 instances
1 swaps: 100 instances
2 swaps: 128 instances
3 swaps: 133 instances
4 swaps: 94 instances
5 swaps: 39 instances
6 swaps: 10 instances
7 swaps: 1 instances
Average number of swaps: 2.57486
testing 'partition5e'
  Code: comparisons = 6, swaps = 8, total = 14
  With all orderings of distinct elements:
0 swaps: 4 instances
1 swaps: 12 instances
2 swaps: 19 instances
3 swaps: 25 instances
4 swaps: 25 instances
5 swaps: 18 instances
6 swaps: 11 instances
7 swaps: 5 instances
8 swaps: 1 instances
Average number of swaps: 3.5
  With all orderings of potentially nondistinct elements:
0 swaps: 36 instances
1 swaps: 88 instances
2 swaps: 100 instances
3 swaps: 123 instances
4 swaps: 106 instances
5 swaps: 53 instances
6 swaps: 25 instances
7 swaps: 9 instances
8 swaps: 1 instances
Average number of swaps: 2.89649

Re: Things that keep D from evolving?

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

On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad 
wrote:
Nothing prevents you from creating your own reference counting 
mechanism.


A struct wrapper doesn't give the things you need to reliably 
handle inheritance.


interface A {}
interface B {}
class C : A, B {}

void use(RefCounted!A) {}

RefCounted!C c;
use(c);



With alias this tricks, you can handle one level of inheritance, 
you could make it return a RefCounted!A or B, but not both. 
Multiple alias this could solve this... but that PR is in limbo 
again AFAIK.


Of course, you could just write some named function to return the 
right interface and tell the user to call it, but it won't be an 
implicit conversion like it is with interfaces normally.


(BTW, for the record, I have no problem with named functions, it 
just is different than the built-in thing.)

Re: Things that keep D from evolving?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 17:46:48 UTC, rsw0x wrote:

Might as well manually free and delete instead.


Not really, this was used in Objective-C before ARC.

But you can always move retain/release/borrow/unborrow into your 
own pointer struct like shared_ptr.

Re: Proposal: Database Engine for D

[Charles via Digitalmars-d]

On Saturday, 6 February 2016 at 13:41:03 UTC, Piotrek wrote:


For the rest there is my proposal ;) : a language embedded DB. 
As far as I can tell none of the known PLes has this "killer" 
feature.


Piotrek


SAS does, and has for quite a few decades now. Its a pretty big 
corporate language used for statistics and analysis. It does work 
exceptionally well, easily handling well over 100M records within 
a single table. They implement a table per file (sas7bdat). That 
said, the binary table format is proprietary, and while there 
have been attempts to reverse engineer it none have been 
completely successful.

Re: Things that keep D from evolving?

[rsw0x via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 17:36:28 UTC, Ola Fosheim Grøstad 
wrote:
On Saturday, 6 February 2016 at 17:22:03 UTC, Adam D. Ruppe 
wrote:
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim 
Grøstad wrote:
Nothing prevents you from creating your own reference 
counting mechanism.


A struct wrapper doesn't give the things you need to reliably 
handle inheritance.


I don't think I suggested using a struct wrapper? :-) That just 
cause issues with alignment or requires a more complex 
allocator.


You can either build the refcount into the root class or use an 
extra indirection like C++'s shared_ptr.


Can't be done with the root class because classes never trigger 
RAII outside of (deprecated) scope allocations.
Can't be done with indirection because you still hit the same 
issue.

Applies to storage classes aswell, btw.

Re: Things that keep D from evolving?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 17:22:03 UTC, Adam D. Ruppe wrote:
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim 
Grøstad wrote:
Nothing prevents you from creating your own reference counting 
mechanism.


A struct wrapper doesn't give the things you need to reliably 
handle inheritance.


I don't think I suggested using a struct wrapper? :-) That just 
cause issues with alignment or requires a more complex allocator.


You can either build the refcount into the root class or use an 
extra indirection like C++'s shared_ptr.

Re: Dynamic Ctors ?

[Voitech via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 18:05:05 UTC, Voitech wrote:
Hi, i have a variadic args template, with a class inside 
something like:


template foo(T...){


class Inner(){

...
...
}



}

Now i want to make Inner create or i will create manually, 
constructor for each of T... parameter types, but don't know 
what is syntax for it. I found that there is possibility to 
initialize T... types static variables with AliasSeq!(T) but 
how to do this automatically, or with static ifs,for 
constructors ?

I tried ...

template foo(T...){
alias Types=AliasSeq!(T);
Algebraic!(T) value;
this(Types value)
this.value=value;
}
}
But this dosn't work


This gives  Error: memcpy cannot be interpreted at compile time, 
because it has no available source code

Dynamic Ctors ?

[Voitech via Digitalmars-d-learn]

Hi, i have a variadic args template, with a class inside 
something like:


template foo(T...){


class Inner(){

...
...
}



}

Now i want to make Inner create or i will create manually, 
constructor for each of T... parameter types, but don't know what 
is syntax for it. I found that there is possibility to initialize 
T... types static variables with AliasSeq!(T) but how to do this 
automatically, or with static ifs,for constructors ?

I tried ...

template foo(T...){
alias Types=AliasSeq!(T);
Algebraic!(T) value;
this(Types value)
this.value=value;
}
}
But this dosn't work

Re: Dwarf Exception Handling now on FreeBSD!

[Walter Bright via Digitalmars-d]

On 2/6/2016 6:15 AM, Jonathan M Davis wrote:

I know that the druntime and Phobos unit tests pass on 11 (which is what I'm
currently running), and I'm fairly sure that they do on 10 (I don't know about
9), but I have no idea what the state of the dmd tests are on anything newer
than 8. I'll have to see if I can find time to at least see what's currently
working and report issues.

- Jonathan M Davis


Thanks, Jonathan!

Re: An IO Streams Library

[cym13 via Digitalmars-d]

On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:
I see the subject of IO streams brought up here occasionally. 
The general consensus seems to be that we need something better 
than what Phobos provides.

[...]


From what I can see without testing it, very nice work, thanks!

More a little surprise than anything serious though, why did you 
choose to go with "println" instead of "writeln" and such? I find 
it more confusing than anything given phobos choice.

Re: Is this a bug in std.typecons.Tuple.slice?

[Marco Leise via Digitalmars-d-learn]

Am Sat, 06 Feb 2016 11:02:37 +
schrieb tsbockman :

> On Saturday, 6 February 2016 at 08:47:01 UTC, Saurabh Das wrote:
> > I think we should add a static assert to slice to ensure that 
> > the current implementation is not used in a case where the 
> > alignment doesn't match. This is better than failing without 
> > any warning.
> 
> If we pursue the deprecation route, I agree that this is a 
> necessary step.

That would hurt the least, yes. It's more like a .dup with
start and end parameter then.

> > We could add new (differently named) functions for slicing 
> > non-aligned tuples.
> >
> > I agree that my approach of removing the ref may break existing 
> > code, so if introduced, it should be named differently.
> >
> > I am not comfortable with tuple(42, true, "abc").slice(1, 3) 
> > being different in type from tuple(true, " abc").
> 
> Why? What practical problem does this cause?

For me it is mostly a gut feeling. Historically types
mimicking other types have often evoked trouble for example in
generic functions or concretely - if you look at my other post
- in D's AA implementation.

-- 
Marco

Re: An IO Streams Library

[Jason White via Digitalmars-d]

On Sunday, 7 February 2016 at 01:59:43 UTC, Rikki Cattermole 
wrote:

Actually I think there are plenty of use cases not implemented.
Done properly as a full replacement and rework of Phobos will 
mean you need to do almost everything in e.g. std.stdio and 
std.socket but with better abstractions.


I think I'll tackle implementing sockets next. I might need that 
for another project of mine.


Once this gets polished enough, it would be great to eventually 
replace those modules in Phobos. However, it would be difficult 
to do this without compatibility breakages. For example, since 
std.stdio.File uses FILE* under the covers and this uses plain 
old file descriptors, programs that rely on that behavior would 
break.


Of course your goal may not be inline with my assertions of 
reworking Phobos. So feel free to ignore, it just would be a 
shame since it really needs some love.


My primary goal is to provide a more useful and powerful IO 
library than what Phobos provides since that is what I need for 
my other projects. That goal is not necessarily counter to 
reworking Phobos. ;)

[Issue 14730] Wrong closure var access with -inline

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 14730] Wrong closure var access with -inline

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/6f0f6db976af6fe6ebbaba05b968a354a58994ad
fix Issue 14730 - Wrong closure var access with -inline

https://github.com/D-Programming-Language/dmd/commit/2d0bcf1fbd4db3d4a96c5413cdda292c0f151ed4
Merge pull request #4765 from 9rnsr/fix14730

Issue 14730 - Wrong closure var access with -inline

--

Re: An IO Streams Library

[Rikki Cattermole via Digitalmars-d]

On 07/02/16 3:43 PM, Jason White wrote:

On Sunday, 7 February 2016 at 01:59:43 UTC, Rikki Cattermole wrote:

Actually I think there are plenty of use cases not implemented.
Done properly as a full replacement and rework of Phobos will mean you
need to do almost everything in e.g. std.stdio and std.socket but with
better abstractions.


I think I'll tackle implementing sockets next. I might need that for
another project of mine.


I wouldn't actually implement it based upon std.socket.
Use libasync instead.
https://github.com/etcimon/libasync

There has been talk about getting that into Phobos but it still needs 
time to mature.


One other important thing to note about sockets.
For anything performance related you need to have a central way to 
implement an event loop.


The one I've implemented is designed to work as a replacement for 
libasync's and to be used in Phobos.

https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/platform.d

If you do intend to make it compatible, you can ignore all of the 
windowing and related methods. Just keep things like optimizedEventLoop, 
eventLoopIteration, setAsDefault and thePlatform, defaultPlatform all in 
there.


We can combine later on, I just want it to be compatible when it comes time.


Once this gets polished enough, it would be great to eventually replace
those modules in Phobos. However, it would be difficult to do this
without compatibility breakages. For example, since std.stdio.File uses
FILE* under the covers and this uses plain old file descriptors,
programs that rely on that behavior would break.


There is nothing wrong with breakage. Its old code. Its time to update.
But there must be a clear upgrade path.


Of course your goal may not be inline with my assertions of reworking
Phobos. So feel free to ignore, it just would be a shame since it
really needs some love.


My primary goal is to provide a more useful and powerful IO library than
what Phobos provides since that is what I need for my other projects.
That goal is not necessarily counter to reworking Phobos. ;)


Okay sweet. Also if you can, it would be great to see you on IRC.

Re: An IO Streams Library

[Rikki Cattermole via Digitalmars-d]

On 07/02/16 1:48 PM, Jason White wrote:

I see the subject of IO streams brought up here occasionally. The
general consensus seems to be that we need something better than what
Phobos provides.

I wrote a library "io" that can work as a replacement for std.stdio,
std.mmfile, std.cstream, and parts of std.stream:

 GitHub:  https://github.com/jasonwhite/io
 Package: https://code.dlang.org/packages/io

This library provides an input and output range interface for streams
(which is more efficient if the stream is buffered). Thus, many of the
wonderful range operations from std.range and std.algorithm can be used
with this.

I'm interested in feedback on this library. What is it missing? How can
be better?

I'm also interested in a discussion of what IO-related functionality
people are missing in Phobos.

Please destroy!


I posted a link to your repo a couple days ago in IRC.
Honestly? I like it. It looks reasonably well made.

There is a bit of work regarding interfaces + ranges.
I.e. Sink really should be inheriting from OutputRange!ubyte

Its no where near Phobos quality and that is ok for now.
I do think given time it could be a reasonably good base to rework 
std.socket, std.stdio, std.stream, std.cstream and std.mmfile into a 
completely new set of modules.


Most of that code it would end up replacing is I think almost 10 years 
old either way its from D1 and I think we can do better.

[Issue 11581] Given T..., new T[0] does not work

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/d93d396842d84c57ddbbaf29e2509c9a9310978c
fix Issue 11581 - Given T..., new T[0] does not work

Defer the indexing form check until NewExp::semantic.

https://github.com/D-Programming-Language/dmd/commit/b583111eb52760ee7c29cc4d862109bc806f2471
Merge pull request #4878 from 9rnsr/fix11581

Issue 11581 - Given T..., new T[0] does not work

--

[Issue 15524] [REG2.069] 64bit app with anon-class crashes in contract

[via Digitalmars-d-bugs]

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

--- Comment #1 from Kenji Hara  ---
Introduced in: https://github.com/D-Programming-Language/dmd/pull/4788

--

Re: Is this a bug in std.typecons.Tuple.slice?

[tsbockman via Digitalmars-d-learn]

On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote:
We should start a new thread in "General" to ask whether people 
care about the `ref`-ness of `Tuple` slices is really the 
deciding factor.


I made a poll: 
http://forum.dlang.org/post/inswmiscuqirkhfql...@forum.dlang.org

Does anyone care if Tuple.slice() returns by ref?

[tsbockman via Digitalmars-d]

I want to do a quick survey of the community, to help figure out 
the best way to fix Phobos issue 15645:  Tuple.slice() causes 
memory corruption.


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

BACKGROUND: Currently, Tuple.slice() returns an actual slice: an 
interior pointer to some part of the original Tuple.


However, alignment issues require that the return type be 
something other than a standard Tuple to maintain memory safety. 
My PR adds a hidden padding member to the beginning of the return 
type: https://github.com/D-Programming-Language/phobos/pull/3973


Saurabh Das has submitted an alternative, and arguably more 
elegant solution (WIP): 
https://github.com/D-Programming-Language/phobos/pull/3975


His version simply returns the slice by value, rather than 
reference. This solves the memory safety issue, but it is a 
potentially significant breaking change.


THE QUESTION: Does anyone care? Is anyone writing code that 
depends upon the ref-ness of Tuple.slice()'s return type?


(If we go with Saurabh Das' approach, we'll deprecate the old 
slice() by ref method, so it there won't be any *silent* breakage 
either way.)


VOTE HERE: 
http://www.polljunkie.com/poll/rtjndn/fixing-ds-tupleslice-issue-15645


RESULTS (so far): 
http://www.polljunkie.com/poll/kpnmtk/fixing-ds-tupleslice-issue-15645/view

voldemort stack traces (and bloat)

[Steven Schveighoffer via Digitalmars-d]

I have a library where I was using very many voldemort types a la std.range.

While debugging I had an exception triggered, but I found that the 
library *pauses* significantly while printing the exception.


What I found is essentially that using voldemort types results in 
horrible stack traces.


To demonstrate the problem:

struct S(T)
{
void foo(){ throw new Exception("1");}
}

auto s(T)(T t)
{
struct Result
{
void foo(){ throw new Exception("2");}
}
return Result();
}

void main(string[] args)
{
version(bad)
auto x = 1.s.s.s.s.s;
else
S!(S!(S!(S!(S!(int) x;

x.foo;
}

Building without bad version, and running, I get this as the stack frame 
for the foo call:


4   testexpansion   0x000103c3fc14 pure @safe 
void 
testexpansion.S!(testexpansion.S!(testexpansion.S!(testexpansion.S!(testexpansion.S!(int).S).S).S).S).S.foo() 
+ 144



Now, if I compile with version=bad:

4   testexpansion   0x00010fb5dbec pure @safe 
void 
testexpansion.s!(testexpansion.s!(testexpansion.s!(testexpansion.s!(testexpansion.s!(int).s(int).Result).s(testexpansion.s!(int).s(int).Result).Result).s(testexpansion.s!(testexpansion.s!(int).s(int).Result).s(testexpansion.s!(int).s(int).Result).Result).Result).s(testexpansion.s!(testexpansion.s!(testexpansion.s!(int).s(int).Result).s(testexpansion.s!(int).s(int).Result).Result).s(testexpansion.s!(testexpansion.s!(int).s(int).Result).s(testexpansion.s!(int).s(int).Result).Result).Result).Result).s(testexpansion.s!(testexpansion.s!(testexpansion.s!(testexpansion.s!(int).s(int).Result).s(testexpansion.s!(int).s(int).Result).Result).s(testexpansion.s!(testexpansion.s!(int).s(int).Result).s(testexpansion.s!(int).s(int).Result).Result).Result).s(testexpansion.s!(testexpansion.s!(testexpansion.s!(int).s(int).Result).s(testexpansion.s!(int).s(int).Result).Result).s(testexpansion.s!(testexpansion.s!(int).s(int).Result).s(testexpansion.s!(int).s(int).Result).Result).Result).Result).!

Result.foo
() 
+ 144


I believe what is happening is both the template parameter and the 
argument type are being printed, but both are the same! And each level 
of nesting results in another doubling of the printouts. So you have an 
exponential effect, and the resulting stack trace is horrendously useless.


what's more, the template bloat factor skyrockets:

dmd -c testexpansion.d
ls -l testexpansion.o
-rw-r--r--+ 1 steves  staff  5664 Feb  7 00:06 testexpansion.o

dmd -c -version=bad testexpansion.d
ls -l testexpansion.o
-rw-r--r--+ 1 steves  staff  15312 Feb  7 00:07 testexpansion.o

as a final test, I tried this:

auto s(T)(T t)
{
return S!(T)();
}

And the resulting .o file:
-rw-r--r--+ 1 steves  staff  7104 Feb  7 00:11 testexpansion.o

With obviously the exception code printing in the less verbose form. So 
the cost in template bloat of using a voldemort type over a private type 
is 8k here, more than double the existing size. With more nesting, I'm 
sure that factor gets worse.


Is there a better way we should be doing this? I'm wondering if 
voldemort types are really worth it. They offer a lot of convenience, 
and are much DRYer than separate private template types. But the bloat 
cost is not really worth the convenience IMO.


Thoughts?

-Steve

Attributes on static constructors

[Brian Schott via Digitalmars-d]

std.socket has a line that looks like this:

shared static this() @system

http://dlang.org/spec/grammar.html#StaticConstructor states that 
function attributes are only valid on "static" and "shared 
static".


Compiler bug or spec bug?

Re: Attributes on static constructors

[Brian Schott via Digitalmars-d]

On Sunday, 7 February 2016 at 06:15:29 UTC, Brian Schott wrote:
... that function attributes are only valid on "static" and 
"shared static".


And by that I mean "static and shared static destructors".

Re: Does anyone care if Tuple.slice() returns by ref?

[tsbockman via Digitalmars-d]

On Sunday, 7 February 2016 at 07:00:04 UTC, Saurabh Das wrote:

On Sunday, 7 February 2016 at 03:16:48 UTC, tsbockman wrote:
(If we go with Saurabh Das' approach, we'll deprecate the old 
slice() by ref method, so it there won't be any *silent* 
breakage either way.)


Can we keep the old by ref slice() method, but add guards to 
disallow cases where the alignment is off?


Honestly, I think it will just confuse people if the slice-by-ref 
method only works on some seemingly-random subset of Tuple 
instantiations - especially since the subset that worked would be 
platform dependent.


We should either fix it, or deprecate it.

Re: Things that keep D from evolving?

[Marco Leise via Digitalmars-d-learn]

Am Sat, 06 Feb 2016 11:47:02 +
schrieb Ola Fosheim Grøstad
:

> Of course, Swift does not aim for very high performance, but for 
> convenient application/gui development. And frankly JavaScript is 
> fast enough for that kind of programming.

My code would not see much ref counting in performance critical
loops. There is no point in ref counting every single point in
a complex 3D scene.
I could imagine it used on bigger items. Textures for example
since they may be used by several objects. Or - a prime
example - any outside resource that is potentially scarce and
benefits from deterministic release: file handles, audio
buffers, widgets, ...

-- 
Marco

Re: Custom hash table key is const, how to call dtors?

[cy via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 03:57:16 UTC, Marco Leise wrote:

No, but they could have dtors because they contain malloc'd 
data. E.g. string literals that don't live on the GC heap.


Character arrays allocated with glibc malloc are immutable? News 
to me...

[Issue 14992] static array local variables always require .init

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/e2be39899a71f1d82d8d23ebf52c97f8efb13485
fix Issue 14992 - static array local variables always require .init

Add one more special case for static array of struct initialization with zero,
similar to the special case for struct initialization.

https://github.com/D-Programming-Language/dmd/commit/8388211efea46340e1ada6b3b889452efd40ccd5
Merge pull request #5014 from 9rnsr/fix14992

Issue 14992 - static array local variables always require .init

--

[Issue 14918] Undefined reference when using a static array of pollfd's

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14918
Issue 14918 depends on issue 14992, which changed state.

Issue 14992 Summary: static array local variables always require .init
https://issues.dlang.org/show_bug.cgi?id=14992

   What|Removed |Added

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

--

Re: Things that keep D from evolving?

[Marco Leise via Digitalmars-d-learn]

Am Sat, 06 Feb 2016 23:18:59 +
schrieb Ola Fosheim Grøstad
:

> Things that could speed up collection:
> - drop destructors so you don't track dead objects

Interesting, that would also finally force external resources
off the GC heap and into deterministic release. That needs a
solution to inheritance though. Think widget kits.

-- 
Marco

Re: Is this a bug in std.typecons.Tuple.slice?

[tsbockman via Digitalmars-d-learn]

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
I understand that. We just have a different perspective on the 
problem. Your priorities:


- don't break what's not broken
- .slice! lends on opSlice and should return by ref

My priorities:

- type of .slice! should be as if constructing with same
  values from scratch
- keep code additions in Phobos to a minimum

Why do I insist on the return type? Because surprisingly simple 
code breaks if it doesn't match. Not everything can be covered 
by runtime conversions in D.


I think the key question is, do users care about being able to 
modify the original `Tuple` instance indirectly through `slice`?


If yes, then the only workable solutions I can see are:

1) My current proposal (insert a hidden padding member at the 
beginning of the slice `Tuple`)


2) Don't return a `Tuple` at all - return a dedicated 
`TupleSlice` type that is implicitly convertible to `Tuple`. This 
approach would work with the example you came up with, but 
implementing `TupleSlice` well could be very complex, I think.


If not, then I have no fundamental objection to Saurabh Das' 
approach, although I think the PR needs work.


We should start a new thread in "General" to ask whether people 
care about the `ref`-ness of `Tuple` slices is really the 
deciding factor.

Re: An IO Streams Library

[Jason White via Digitalmars-d]

On Sunday, 7 February 2016 at 01:01:21 UTC, cym13 wrote:

From what I can see without testing it, very nice work, thanks!

More a little surprise than anything serious though, why did 
you choose to go with "println" instead of "writeln" and such? 
I find it more confusing than anything given phobos choice.


Thanks!

There are a couple reasons for using print/println/etc. over 
write/writeln/etc.:
 1. A module-level definition of write(Stream s, ...) would clash 
with the stream's definition of write(...).
 2. Do we mean text-serialization or byte-for-byte output when we 
say write()? With print(), it's clear that we want the arguments 
to be converted to a text representation and have that written 
that to the stream. With write(), it's clear we're writing out 
the binary representation to the stream.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 07/02/16 4:23 AM, Piotrek wrote:

On Friday, 29 January 2016 at 02:18:38 UTC, Rikki Cattermole wrote:

Right now, image library is more or less ready for next feedback.
Windowing is almost there, really just needs a bit of testing and its
done.

So in other words, the hold up, is me.


Where can I find the code to be tested? You have too many projects on
github :)

Piotrek


https://github.com/rikkimax/alphaPhobos

Re: Custom hash table key is const, how to call dtors?

[Marco Leise via Digitalmars-d-learn]

Am Sun, 07 Feb 2016 01:05:28 +
schrieb cy :

> On Saturday, 6 February 2016 at 03:57:16 UTC, Marco Leise wrote:
> 
> > No, but they could have dtors because they contain malloc'd 
> > data. E.g. string literals that don't live on the GC heap.
> 
> Character arrays allocated with glibc malloc are immutable? News 
> to me...

err... well... you got a point there, but then new string(100)
is probably allocated with malloc, too deep down in druntime.

immutable really means that there is no mutable reference to
the data. At any point in your code you can cast something to
immutable when you that no mutable references will exist
thereafter. We do this all the time during construction of
immutable stuff, because when something is newly created,
there is only one unique reference that is turned immutable
after construction and you are set.

You can go the same route with other MM schemes such as
malloc, just that without a GC you are responsible for not
freeing the immutable data as long as there are references to
it. For example (and this applies to Ds GC'd AA, too) you must
not delete entries while you iterate over the keys. There is
no way to say "Hey I just borrowed the list of keys, please
disallow any writes to it."

For now, issues related to dtor-constness need to be fixed.
Then working with immutable data structures is a lot less of a
mine field.

-- 
Marco

Re: Is this a bug in std.typecons.Tuple.slice?

[tsbockman via Digitalmars-d-learn]

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
Why do I insist on the return type? Because surprisingly simple 
code breaks if it doesn't match. Not everything can be covered 
by runtime conversions in D. It still took me a while to come 
up with something obvious:


uint[Tuple!(uint, ulong)] hash;

auto tup = tuple(1u, 2u, 3UL);

hash[tup.slice!(1, 3)] = tup[0];

 compiles?  works?
original Tuple : yesno
Saurabh Das changes: yesyes
your changes   : no no


Thank you for the example.

If multiple alias this ever makes it into the language (see 
https://wiki.dlang.org/DIP66 and 
https://github.com/D-Programming-Language/dmd/pull/3998), this 
could be fixed quite easily. But, I do not see any way to fix it 
with the tools currently available.

Re: Is this a bug in std.typecons.Tuple.slice?

[Saurabh Das via Digitalmars-d-learn]

On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote:

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
I understand that. We just have a different perspective on the 
problem. Your priorities:


- don't break what's not broken
- .slice! lends on opSlice and should return by ref

My priorities:

- type of .slice! should be as if constructing with same
  values from scratch
- keep code additions in Phobos to a minimum

Why do I insist on the return type? Because surprisingly 
simple code breaks if it doesn't match. Not everything can be 
covered by runtime conversions in D.


I think the key question is, do users care about being able to 
modify the original `Tuple` instance indirectly through `slice`?


If yes, then the only workable solutions I can see are:

1) My current proposal (insert a hidden padding member at the 
beginning of the slice `Tuple`)


2) Don't return a `Tuple` at all - return a dedicated 
`TupleSlice` type that is implicitly convertible to `Tuple`. 
This approach would work with the example you came up with, but 
implementing `TupleSlice` well could be very complex, I think.


If not, then I have no fundamental objection to Saurabh Das' 
approach, although I think the PR needs work.


The PR definitely needs work - it was proposed to outline the 
direction. I haven't worked at all on Phobos and I am not yet 
knowledgeable on writing library-quality code in D.


I'm hoping to contribute back to Phobos this year - so pointing 
out as many flaws will help learn faster :) In particular - the 
inout problem in the PR - I'm not sure yet on how to fix that.


Thanks,
Saurabh



We should start a new thread in "General" to ask whether people 
care about the `ref`-ness of `Tuple` slices is really the 
deciding factor.

Re: Attributes on static constructors

[Jakob Ovrum via Digitalmars-d]

On Sunday, 7 February 2016 at 06:15:29 UTC, Brian Schott wrote:

std.socket has a line that looks like this:

shared static this() @system

http://dlang.org/spec/grammar.html#StaticConstructor states 
that function attributes are only valid on "static" and "shared 
static".


Compiler bug or spec bug?


I'm not sure what you mean. Looking at the section you linked, it 
looks like the issue is that it states that function attributes 
are only valid for module destructors. Seems like an oversight.

Re: Is this a bug in std.typecons.Tuple.slice?

[Marco Leise via Digitalmars-d-learn]

Am Sat, 06 Feb 2016 07:57:08 +
schrieb tsbockman :

> On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote:
> > I don't want to sound dismissive, but when that thought came
> > to my mind I considered it unacceptable that the type of
> > Tuple!(int, bool, string).slice(1, 3) would be something
> > different than Tuple!(bool, string). In your case
> > Tuple!(TuplePad!4LU, bool, string). That's just a matter of
> > least surprise when comparing the types.
> >
> > I'll let others decide, since I never used tuple slices.
> 
> I'm not sure which approach is ultimately better, but aside from 
> the performance implications, your "needed change" could break a 
> lot of valid code in the wild - or it might break none; it really 
> just depends on whether anyone actually *uses* the `ref`-ness of 
> the `Tuple.slice` return type.

True.
 
> (It appears that Phobos, at least, does not. But there is no 
> guarantee that the rest of the world is using `Tuple` only in the 
> ways that Phobos does.)
> Leaving aside bizarre meta-programming stuff (because then 
> *anything* is a breaking change), my PR does not break any code, 
> except that which was already broken: the type of the slice is 
> only different in those cases where it *has* to be, for alignment 
> reasons; otherwise it remains the same as it was before.

I understand that. We just have a different perspective on the
problem. Your priorities:

- don't break what's not broken
- .slice! lends on opSlice and should return by ref

My priorities:

- type of .slice! should be as if constructing with same
  values from scratch
- keep code additions in Phobos to a minimum

Why do I insist on the return type? Because surprisingly
simple code breaks if it doesn't match. Not everything can be
covered by runtime conversions in D. It still took me a while
to come up with something obvious:

uint[Tuple!(uint, ulong)] hash;

auto tup = tuple(1u, 2u, 3UL);

hash[tup.slice!(1, 3)] = tup[0];

 compiles?  works?
original Tuple : yesno
Saurabh Das changes: yesyes
your changes   : no no

What I like most about your proposal is that it doesn't break
any existing code that wasn't broken before. That can't be
emphasized enough.

-- 
Marco

[Issue 14788] Incorrect rejection of inout function call

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/565ff8d8c6496208dd51c751a9b1d947b70dd36c
fix Issue 14788 - Incorrect rejection of inout function call

https://github.com/D-Programming-Language/dmd/commit/0a15e859e6ffb5e7180bf49169f61da998d4466a
Merge pull request #4810 from 9rnsr/fix14788

Issue 14788 - Incorrect rejection of inout function call

--

[Issue 9378] std.internal.digest.sha_SSE3 breaks if compiled with PIC

[via Digitalmars-d-bugs]

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

Dicebot  changed:

   What|Removed |Added

 CC||pub...@dicebot.lv

--- Comment #2 from Dicebot  ---
Any idea if this applies only to DMD or LDC is likely to have problems to?

--

Cpa Email List

[AtiaAk via Digitalmars-d]

You can't take arbitrary fixings and hope to heat something 
heavenly. You require particular fixings and an equation for 
achievement. On the off chance that you are purchasing email 
records with unfit prospects, it can without much of a stretch 
end up being a formula for debacle.


A decent advertiser takes on a similar mindset as a shopper. 
Customers are keen and they realize what they need to purchase. 
At the point when customers get messages from an obscure source 
or a source they don't remember, they would generally disregard 
or erase the email.


Be that as it may, if the email originates from a perceived 
source such as a respectable organization or from a site the 
agreed to 5 minutes prior, the odds of them investigating the 
email is fundamentally higher. This is because of the way that 
when customers perceived something, they are all the more ready 
to trust that sender of the messages.

see more   http://www.latestdatabase.com/cpa-email-list/

Re: Does anyone care if Tuple.slice() returns by ref?

[Saurabh Das via Digitalmars-d]

On Sunday, 7 February 2016 at 03:16:48 UTC, tsbockman wrote:
(If we go with Saurabh Das' approach, we'll deprecate the old 
slice() by ref method, so it there won't be any *silent* 
breakage either way.)


Can we keep the old by ref slice() method, but add guards to 
disallow cases where the alignment is off?

Re: An IO Streams Library

[Jason White via Digitalmars-d]

On Sunday, 7 February 2016 at 01:20:26 UTC, Rikki Cattermole 
wrote:

I posted a link to your repo a couple days ago in IRC.
Honestly? I like it. It looks reasonably well made.


Thanks. I saw a link to it in a recent thread in Learn. I figured 
I'd finally make a proper post on it.



There is a bit of work regarding interfaces + ranges.
I.e. Sink really should be inheriting from OutputRange!ubyte


I haven't had much use for the interfaces, which is why they 
aren't fleshed out. Do you have any particular use cases for this 
in mind?



Its no where near Phobos quality and that is ok for now.


I agree. The documentation needs work and I imagine there are 
lots of use cases that aren't well supported. Increased 
visibility and usage definitely helps with finding the warts.


I do think given time it could be a reasonably good base to 
rework std.socket, std.stdio, std.stream, std.cstream and 
std.mmfile into a completely new set of modules.


Most of that code it would end up replacing is I think almost 
10 years old either way its from D1 and I think we can do 
better.

Re: An IO Streams Library

[Rikki Cattermole via Digitalmars-d]

On 07/02/16 2:55 PM, Jason White wrote:

On Sunday, 7 February 2016 at 01:20:26 UTC, Rikki Cattermole wrote:

I posted a link to your repo a couple days ago in IRC.
Honestly? I like it. It looks reasonably well made.


Thanks. I saw a link to it in a recent thread in Learn. I figured I'd
finally make a proper post on it.


There is a bit of work regarding interfaces + ranges.
I.e. Sink really should be inheriting from OutputRange!ubyte


I haven't had much use for the interfaces, which is why they aren't
fleshed out. Do you have any particular use cases for this in mind?


I have no use case other then range compatibility.


Its no where near Phobos quality and that is ok for now.


I agree. The documentation needs work and I imagine there are lots of
use cases that aren't well supported. Increased visibility and usage
definitely helps with finding the warts.


Actually I think there are plenty of use cases not implemented.
Done properly as a full replacement and rework of Phobos will mean you 
need to do almost everything in e.g. std.stdio and std.socket but with 
better abstractions.


Of course your goal may not be inline with my assertions of reworking 
Phobos. So feel free to ignore, it just would be a shame since it really 
needs some love.

Re: Is this a bug in std.typecons.Tuple.slice?

[tsbockman via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote:

[...]


I should also point out that, since there is no way to actually 
find out whether anyone is using the `ref`-ness of the return 
type in the wild, the approach that you and Saurabh Das are 
taking really ought to include changing the symbol name and 
deprecating the old one.


Otherwise you could introduce subtle bugs into previously valid 
code; not every significant effect of removing `ref` will cause 
an error message at compile time *or* run time - some will just 
silently change the behaviour of the program, which is awful.

Re: Idempotent partition around median of 5?

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 6 February 2016 at 07:06:27 UTC, Ivan Kazmenko wrote:

1. Primitive types (cheap swap, cheap comparison).

2. Heavy structs A (expensive swap, cheap comparison - e.g., 
compare one field of primitive type).


3. Heavy structs B (expensive swap, expensive comparison - 
e.g., call a heavy external function).


4. Heavy classes (cheap swap - pointers only, expensive 
comparison).


So there's perhaps no single best solution.


That's right, but other factors are more important: preventing 
pipeline stalls. If you are collecting from 5 different 
cachelines in an array you are likely to get several 40-120 
cycles delays unless you do prefetching, and if you do, you need 
to have other instructions to fill in the latency gaps.


But also instructions have latency and concurrency issues. Which 
is why your version did reasonably well as it made the 
compares/swaps independent so that they could be concurrently 
scheduled.


Yet, Haswell has SIMD instructions that can do 8-16x 32-bit 
max/min operations per cycle, with a latency of only 1 cycle, and 
4-8x 64bit compares with a latency of 1 cycle.


So if you use as  small fixed N, like 5, it makes very little 
sense to count compares/swaps.


What makes sense is to focus on how you can avoid branching and 
build an algorithm with no pipeline stalls.


If sorting large arrays you also might want to look at 
multi-threaded parallel sort functions.

Re: Things that keep D from evolving?

[NX via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad 
wrote:

What makes it impossible to have ref counted classes?


Nothing.


Then why do we need DIP74 ? And why documentation says RefCounted 
doesn't work with classes?

Re: Bug or intended?

[Kagamin via Digitalmars-d-learn]

I'd say support for this scenario is not implemented yet.

Re: Is this a bug in std.typecons.Tuple.slice?

[tsbockman via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote:

I don't want to sound dismissive, but when that thought came
to my mind I considered it unacceptable that the type of
Tuple!(int, bool, string).slice(1, 3) would be something
different than Tuple!(bool, string). In your case
Tuple!(TuplePad!4LU, bool, string). That's just a matter of
least surprise when comparing the types.

I'll let others decide, since I never used tuple slices.


I'm not sure which approach is ultimately better, but aside from 
the performance implications, your "needed change" could break a 
lot of valid code in the wild - or it might break none; it really 
just depends on whether anyone actually *uses* the `ref`-ness of 
the `Tuple.slice` return type.


(It appears that Phobos, at least, does not. But there is no 
guarantee that the rest of the world is using `Tuple` only in the 
ways that Phobos does.)


Leaving aside bizarre meta-programming stuff (because then 
*anything* is a breaking change), my PR does not break any code, 
except that which was already broken: the type of the slice is 
only different in those cases where it *has* to be, for alignment 
reasons; otherwise it remains the same as it was before.

Things that keep D from evolving?

[NX via Digitalmars-d-learn]

So I came here to ask about things that prevent D to become 
better.


What language semantics prevent precise & fast GC implementations?

What makes it impossible to have ref counted classes?

What are some other technical / design problems you encountered? 
(other than poor implementation and lack of resources)


Enlighten! :)

Re: Proposal: Database Engine for D

[Sebastiaan Koppe via Digitalmars-d]

On Saturday, 6 February 2016 at 00:14:08 UTC, Mengu wrote:
and while we were talking the talk, rust community rolled out 
something good called diesel. check it out at http://diesel.rs/.


we need tools that get things done. we do not need tools that 
makes things more complex than they already are.


I saw the examples on the site. In every case I prefer reading 
SQL instead of a complicated function chain with semantics I have 
yet to learn; SQL I already know.


A nice thing is the `less boilerplate` example. But I think they 
took a wrong approach by deriving the class from Queryable. I 
like D's approach better.

Re: Proposal: Database Engine for D

[Piotrek via Digitalmars-d]

On Saturday, 6 February 2016 at 00:14:08 UTC, Mengu wrote:
and while we were talking the talk, rust community rolled out 
something good called diesel. check it out at http://diesel.rs/.


we need tools that get things done. we do not need tools that 
makes things more complex than they already are.


Almost no one (including me) is interested in ORM for SQL. The 
point is ORM+SQL is limiting and sooner or later you fallback to 
SQL.


Additionally there is no critical mass for this kind of big 
project (combining all the SQL engines - good luck).


Andrei suggested a CTFE sql parser, so people who like SQL (not 
me) can benefit from the D metaprogramming power.


For the rest there is my proposal ;) : a language embedded DB. As 
far as I can tell none of the known PLes has this "killer" 
feature.


Piotrek

Re: Deprecation policy

[Jonathan M Davis via Digitalmars-d]

On Friday, 5 February 2016 at 11:11:40 UTC, Daniel Murphy wrote:
There are other things holding up deprecated features other 
than lack of time/energy.


- Walter/Andrei have declared features deprecated for 
ideological reasons, yet they're still useful and don't have 
good alternatives.
- Walter/Andrei have refused or extended reasonable deprecation 
paths because they will break code


So implementing a deprecation typically means five minutes of 
writing a compiler patch, an hour of removing ancient uses from 
obscure druntime code, 12 months of waiting for review and 3 
weeks of arguing with Walter and/or Andrei and/or anyone else 
who can't be bothered updating their code.


See https://issues.dlang.org/show_bug.cgi?id=4733 for why I 
don't bother any more.


Yeah. I can definitely understand that. And issue# 4733 was 
definitely a mess.


- Jonathan M Davis

[Issue 15649] New: Wish: forum.dlang.org: It would be nice to see new (unreaded) posts marked somehow

[via Digitalmars-d-bugs]

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

  Issue ID: 15649
   Summary: Wish: forum.dlang.org: It would be nice to see new
(unreaded) posts marked somehow
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: golovanov_ale...@mail.ru

forum.dlang.org already know wich posts is new for user - there is info in
topics list "Replies" column, like "93 (64 new)".
And those "(64 new)" is clickable link like
http://forum.dlang.org/first-unread/lygasrzucqdiatvuu...@forum.dlang.org.

It would be nice to see those new posts marked by color border or somehow else.
If this is possible.
Thanks.

--

Re: Things that keep D from evolving?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 11:33:05 UTC, rsw0x wrote:
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim 
Grøstad wrote:
reference counting is incredibly slow, DIP74 attempts to 
partially amend that in D as it can't be done any other way 
besides compiler help.
IIRC, it essentially just allows RC inc/dec to be elided where 
possible


_Automatic_ reference counting can be slow. Manual reference 
counting can be very efficient (but takes programmer skill).


The better solution is to adopt borrow-semantics and only use 
reference counting for ownership. Just like you ought to use 
unique_ptr and shared_ptr in C++.


Of course, Swift does not aim for very high performance, but for 
convenient application/gui development. And frankly JavaScript is 
fast enough for that kind of programming.

Re: Proposal: Database Engine for D

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 6 February 2016 at 13:41:03 UTC, Piotrek wrote:

On Saturday, 6 February 2016 at 00:14:08 UTC, Mengu wrote:
and while we were talking the talk, rust community rolled out 
something good called diesel. check it out at 
http://diesel.rs/.


we need tools that get things done. we do not need tools that 
makes things more complex than they already are.


Almost no one (including me) is interested in ORM for SQL. The 
point is ORM+SQL is limiting and sooner or later you fallback 
to SQL.


A good ORM-like interface is mandatory for working with NoSQL 
databases...

Re: Dwarf Exception Handling now on FreeBSD!

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 3 February 2016 at 20:18:52 UTC, Brad Roberts wrote:

On 2/3/16 11:28 AM, Jonathan M Davis via Digitalmars-d wrote:
On Sunday, 31 January 2016 at 06:34:26 UTC, Walter Bright 
wrote:

32/64 support now on Linux and FreeBSD.

  https://github.com/D-Programming-Language/dmd/pull/5376

Turns out that FreeBSD is close enough to Linux that it "just 
worked".


It's always nice when that happens, especially when there's 
not much FreeBSD-specific work going on,
and the autotesters have generally been on older versions of 
FreeBSD such that issues on the newer
versions don't always get noticed (e.g. for a while there, the 
shared library stuff passed the tests
on FreeBSD 8 but not later; fortunately Martin got that fixed 
though).


- Jonathan M Davis


I haven't put much time into investigation, but the last time I 
tried it, neither 9 nor 10 passed the test suite.  If someone 
puts in the effort to get either or both of those working, I'd 
be happy to upgrade some of the freebsd testers to newer 
versions.  There's currently 4 freebsd machines, so plenty of 
room to have a mix of versions.  Not enough to test every 
combination of version and bitness, but enough to allow 
randomness to expose issues.


I know that the druntime and Phobos unit tests pass on 11 (which 
is what I'm currently running), and I'm fairly sure that they do 
on 10 (I don't know about 9), but I have no idea what the state 
of the dmd tests are on anything newer than 8. I'll have to see 
if I can find time to at least see what's currently working and 
report issues.


- Jonathan M Davis

Bug or intended?

[rsw0x via Digitalmars-d-learn]

I was playing around with alias templates and came across this, I 
reduced it to:


---
struct A(alias C c){

  auto foo(){
return c.i;
  }
}

struct B{
  C c;
  A!c a;
}

struct C{
  int i;
}
---

It gives me a "need 'this' for 'i' of type 'int'" error.

Re: foreach seems to work with opIndex()

[Tofu Ninja via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 15:02:16 UTC, H. S. Teoh wrote:
Not really sure, but opIndex() with no arguments is supposed to 
be the current way of implement the [] slicing operator for 
user-defined types. I'm not sure when foreach started 
supporting that, but it's certainly a nice thing!



T


It feels a little weird because none of the range functions like 
map support calling opIndex so you can omit the [] in foreach but 
not with map. Just feels inconsistent.

Re: Things that keep D from evolving?

[Kagamin via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:

What language semantics prevent precise


Lack of resources. Precise GC needs to know which fields are 
pointers. Somebody must generate that map. AFAIK there was an 
experiment on that.



fast GC


Fast GC needs to be notified about pointer changes, C won't do 
that and for some reason people don't want to rely on C code not 
changing GC pointers.

Re: Conflicting UDA

[Márcio Martins via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 15:01:44 UTC, Marc Schütz wrote:
On Saturday, 6 February 2016 at 13:36:32 UTC, Márcio Martins 
wrote:

[...]


`@(mylib.ignore)` should work. You could open an enhancement 
request to enable the paren-less syntax.


Thanks, that does work indeed and is not that verbose...

Cheers!

Re: foreach seems to work with opIndex()

[ZombineDev via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 15:02:16 UTC, H. S. Teoh wrote:
On Sat, Feb 06, 2016 at 02:43:52PM +, Tofu Ninja via 
Digitalmars-d-learn wrote:
Foreach seems to work if there is an opIndex() with no 
arguments that returns a range interface, is this documented? 
I can't seem to find anything that say this is supposed to 
happen. I am not really complaining, its nice, but I just 
didnt really expect it because I feel like I remember this 
being an error some time ago.


Not really sure, but opIndex() with no arguments is supposed to 
be the current way of implement the [] slicing operator for 
user-defined types. I'm not sure when foreach started 
supporting that, but it's certainly a nice thing!



T


I thought that opSlice() was supposed to be that operator. At 
least this is what's used in std.container (e.g. 
http://dlang.org/phobos/std_container_array.html#.Array.opSlice).

Re: Idempotent partition around median of 5?

[tn via Digitalmars-d]

On Friday, 5 February 2016 at 21:42:41 UTC, Xinok wrote:

On Friday, 5 February 2016 at 15:13:56 UTC, tn wrote:

On Thursday, 4 February 2016 at 20:30:57 UTC, Timon Gehr wrote:
At most 6 comparisons, <=3 swaps, idempotent (optimal number 
of swaps):


...



Inspired by this, I made four other versions of the function 
that are shorter but make more swaps (at most 4, 6, 7 and 8 
swaps respectively). Each makes 6 comparisons and should be 
idempotent.


http://dpaste.dzfl.pl/1c53d8f432f7

...


Very nice! I'm curious, to both you and Timon, how did you go 
about writing these and coming up with the solutions? I'm not 
sure if I could come up with these results myself and so 
quickly at that.


I basically just started from Timons solution and made is smaller 
by replacing branches by swaps. The outermost structure of Timons 
code looks like this:


  if (a[0] < a[1]) {
do something 1
  } else {
do something 2
  }

I replaced the above by

  if (a[0] < a[1]) {
swap(a[0], a[1]);
  }
  do something 1

So adding one swap just about halved the size of the code. Now 
"do something 1" again has two branches:


  if (a[2] < a[3]) {
do something 1.1
  } else {
do something 1.2
  }

So we can do the same trick again and replace it by

  if (a[2] < a[3]) {
swap(a[2], a[3]);
  }
  do something 1.1

And so on. (When doing subsequent swaps we also need to make sure 
to not break the conditions achieved by the previous swaps.)


However, the swap of a[0] and a[1] in the first replacement would 
break idempotence, so I also had to change which elements are 
compared (and swapped). So in my code we first compare a[0] and 
a[2], then a[1] and a[3], and so on.

Re: Idempotent partition around median of 5?

[tn via Digitalmars-d]

On Saturday, 6 February 2016 at 01:46:58 UTC, Andrei Alexandrescu 
wrote:

On 02/04/2016 03:30 PM, Timon Gehr wrote:
At most 6 comparisons, <=3 swaps, idempotent (optimal number 
of swaps):


Oh, also: could you let that bad boy run and let it find 
anything that does idempotent partition in 6 compares and 0-7 
swaps? Then slowly tighten the number of swaps until you find 
the best balance between number of swaps and code size. -- 
Andrei


That is kind of what I tried to do by hand. My function 
partition5e seems to be practically identical to Ivans solution 
and partition5a is just a copy of Timons solution. Function 
partition5b, partition5c and partition5d are in between of those 
with various tradeoffs between the number of swaps and code size.

Re: Is this a bug in std.typecons.Tuple.slice?

[tsbockman via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 08:47:01 UTC, Saurabh Das wrote:
I think we should add a static assert to slice to ensure that 
the current implementation is not used in a case where the 
alignment doesn't match. This is better than failing without 
any warning.


If we pursue the deprecation route, I agree that this is a 
necessary step.


We could add new (differently named) functions for slicing 
non-aligned tuples.


I agree that my approach of removing the ref may break existing 
code, so if introduced, it should be named differently.


I am not comfortable with tuple(42, true, "abc").slice(1, 3) 
being different in type from tuple(true, " abc").


Why? What practical problem does this cause?

Re: New D book available for pre-order: D Web Development

[Joakim via Digitalmars-d-announce]

On Saturday, 30 January 2016 at 17:58:23 UTC, Jacob Carlborg 
wrote:

On 2016-01-30 18:33, barberian wrote:

Yes, in fact the ebook it's expensive in this case, and where 
I live we
"unfortunately" need to convert the pound multiplying by 6, 
ouch!


How can two things be cheaper than one? It doesn't add up. Is 
there a mistake?


Many publishers want to disincentivize ebook sales while 
artificially pushing up print sales, that's probably why.  Part 
of it is that they already have money invested in printing 
presses and the like, so they don't want that investment 
demolished by everyone buying ebooks.  Another piece is that they 
may feel, rightly or wrongly, that they don't have much to 
contribute to ebook sales, so they use such weird pricing to try 
and suppress pure ebook sales alone, because someday they will go 
out of business if they just sell ebooks.


Strictly speaking, it is irrational, or at the very least too 
skewed towards dying technology and business models.  But then 
people do dumb things all the time, especially those whose 
business is heading for obsolescence. :)

Re: Idempotent partition around median of 5?

[Andrei Alexandrescu via Digitalmars-d]

On 02/05/2016 08:58 PM, Timon Gehr wrote:

On 02/06/2016 02:39 AM, Andrei Alexandrescu wrote:

On 02/04/2016 03:30 PM, Timon Gehr wrote:

At most 6 comparisons, <=3 swaps, idempotent (optimal number of swaps):


What is the minimum number of comparisons? Thx! -- Andrei


There is no partition algorithm that uses <= 5 comparisons in all cases.
(If that is what you're asking.)


Was asking about this particular one. For example, the maximum 
comparisons is 6, but it would be good to know the average number of 
comparisons. I know I could read through the code, but it's hairy. 
Thanks! -- Andrei