date:20151103

proper range usage

2015-11-03 Thread Alex via Digitalmars-d-learn


Hi everybody,

first of all: this question is going to be unclear, because I'm 
lack of the "buzz word" I would like to ask about, sorry for this 
in advance.


I try to describe the problem, where I stuck and hope somebody 
could think just a step further. Just a hint where to read about 
the way of solution would be enough, I think.


Starting with chapter 73 in the recent "Programming in D" book 
(the revision of 2015-10-24), about "foreach with structs and 
classes" I would like to implement either the opAssign method or 
the three range member functions in a simple struct.
Let's say, the example of NumberRange struct in the example on 
page 486 is enough. In terms of .front(), .popFront() and .empty: 
I understand what the first two things do, but I have a problem 
with the empty property:


In my case, the container class can't become empty. Even if it 
contains one single element, in this case the example should 
return true for begin == end, it is not empty. At the same time, 
my container is surely always finite, so I can't define the empty 
property to false as shown on page 568, last line.


A further problem/wish is: I don't want to store my elements 
explicitly as members. So taking the simplest example on page 486 
has a further meaning for me: It does not contain an array as 
member and it is not meant to.


So far from me. I hope, I could describe my problem good enough 
and I hope somebody could help me out. Still, the solution is 
important, but I also would like to know what a weird thing I'm 
describing in terms of... well... some structure... not to say 
pattern :)


Thanks in advance
Alex

Re: why to (not) support "older" compiler versions

2015-11-03 Thread drug via Digitalmars-d


On 03.11.2015 11:22, Johannes Pfau wrote:


I guess it's to be compatible with the latest DMD, LDC and GDC. GDC
currently only provides the 2.066.1 frontend.

A bit offtopic - will the situation change with ddmd accepted? I mean 
the situation with different frontend version in different compilers.

why to (not) support "older" compiler versions

2015-11-03 Thread yawniek via Digitalmars-d

i have seen many PR's and also Forum entries that deal with the 
problem of newer features of the compiler not being able and then 
patching or working around that to support older compiler 
versions.


since it is really easy to keep up with compiler versions and 
even switch
(and not many features are being removed from dmd) what are good 
reasons to keep backward compatiblity?


the latest example i saw was replacing groupBy by a loop to keep 
compatiblity with 2.066.

while not a big thing, it adds up.

since still a lot of useful features do get added into phobos at 
a fairly fast pace,
would it not be better to to keep targeting just the two most 
recent versions and moving

the ecosystem a little bit further.
For people entering the world of D it would be much more 
encouraging to read a lot
of concise code using all the nice features we have instead of 
just lipstick'd C.

Bidirectional Filter

2015-11-03 Thread Nordlöw via Digitalmars-d-learn

Is there a reason why std.algorithm.iteration.filter() doesn't 
propagate bidirectional access?

Re: Bidirectional Filter

2015-11-03 Thread Jakob Ovrum via Digitalmars-d-learn


On Tuesday, 3 November 2015 at 08:41:11 UTC, Nordlöw wrote:
Is there a reason why std.algorithm.iteration.filter() doesn't 
propagate bidirectional access?


http://dlang.org/phobos/std_algorithm_iteration.html#filterBidirectional

Re: proper range usage

2015-11-03 Thread Alex via Digitalmars-d-learn

On Tuesday, 3 November 2015 at 08:23:20 UTC, Ali Çehreli wrote:

> "Programming in D" book (the revision of 2015-10-24)

Oooh! That smells very fresh. :)

:)

> In my case, the container class can't become empty. Even if
it contains
> one single element, in this case the example should return
true for
> begin == end, it is not empty.

That problem is solved by the convention that 'end' is one 
beyond the last valid element. So, when there is only the 
element 42, then begin==42 and end==43. Only when the last 
element (42 in this case) is consumed, begin==end.

This part is dangerous, and I'm not sure how dangerous it is. 
Now, I have to dive into my structure a little bit deeper:

Say, I have three classes:

class B //current structure
{
M[] _ms;
P[] _ps;
P[M] assoc;
}

struct M
{
int id;
alias id this;
}

struct P
{
int id;
alias id this;
int begin;
int end;
}

The idea is, that P structs are disjunct (and contigous, if this 
does matter) arrays of M's. And the question is, what happens, if 
I set the end property of a P to a number, which belongs to 
another P.
At the current time class B contains arrays of different M's 
(constant, big one, say order of 10^6 elements, elements itself 
are not very large, say about 5 members and a bunch of properties 
calculated at runtime) as well as an array of P's (at the 
beginning not so big one, but growing fast) and the array of 
associations between the M's and P's. In my program I implement 
this array as int[int], and reassign the associated values at the 
same time as the array of P's is growing.

Here I have to deliver the "buzz words", so I'm trying to 
implement a set partition algorithm with disjoint sets. With the 
standard question how to achieve the fastest cutting of the whole 
array into its single components. The application in my case are 
just some constraints which say, how the cutting is allowed.

Such ranges are called generators.

ok, cool! Thx.

Re: why to (not) support "older" compiler versions

2015-11-03 Thread Johannes Pfau via Digitalmars-d

Am Tue, 03 Nov 2015 08:08:26 +
schrieb yawniek :

> i have seen many PR's and also Forum entries that deal with the 
> problem of newer features of the compiler not being able and then 
> patching or working around that to support older compiler 
> versions.
> 
> since it is really easy to keep up with compiler versions and 
> even switch
> (and not many features are being removed from dmd) what are good 
> reasons to keep backward compatiblity?
> 
> the latest example i saw was replacing groupBy by a loop to keep 
> compatiblity with 2.066.
> while not a big thing, it adds up.
> 

I guess it's to be compatible with the latest DMD, LDC and GDC. GDC
currently only provides the 2.066.1 frontend.

Re: proper range usage

2015-11-03 Thread Ali Çehreli via Digitalmars-d-learn

On 11/02/2015 11:59 PM, Alex wrote:

> "Programming in D" book (the revision of 2015-10-24)

Oooh! That smells very fresh. :)

> In my case, the container class can't become empty. Even if it contains
> one single element, in this case the example should return true for
> begin == end, it is not empty.

That problem is solved by the convention that 'end' is one beyond the 
last valid element. So, when there is only the element 42, then 
begin==42 and end==43. Only when the last element (42 in this case) is 
consumed, begin==end.

> A further problem/wish is: I don't want to store my elements explicitly
> as members. So taking the simplest example on page 486 has a further
> meaning for me: It does not contain an array as member and it is not
> meant to.

Such ranges are called generators. As long as .front returns the current 
element, and popFront() advances to the next one, you don't need to 
store any array. (You seem to say the same thing, so I don't understand 
the question.)

Ali

Re: proper range usage

2015-11-03 Thread Alex via Digitalmars-d-learn

... and yes, each P's M's are meant to be the same, as the 
associated M's in the B's class to the P. If you understand, what 
I mean ;)

Re: I have this game engine...

2015-11-03 Thread Joakim via Digitalmars-d


On Tuesday, 3 November 2015 at 07:30:44 UTC, Johannes Pfau wrote:

Am Tue, 3 Nov 2015 09:16:47 +1000
schrieb Manu via Digitalmars-d :

I have a samples directory which it would be theoretically 
possible to run and see that they don't crash as part of a 
test run. Also, I'd like to annotate my whole engine quite 
comprehensively with unittests. It's something that I'm keen 
to work on, and then it further helps to assure those 
toolchains remain working.


But how exactly would you run these? All CI machines are 
x86_64. I guess emulators could be a possibility as long as 
they run headless. We'd need some way to get feedback from the 
emulator though (test passed/failed). If you're talking about 
running tests on the x86_64 architecture that should be easy.


There's a Dreamcast emulator for Android/ARM:

https://github.com/reicast/reicast-emulator

You could run it inside the Android emulator on Travis: :)

http://docs.travis-ci.com/user/languages/android/

I'm sure their servers can handle an emulator of a 200 MHz MIPS 
core with 16 MB of RAM running inside an ARM emulator. ;)

Re: I have this game engine...

2015-11-03 Thread Joakim via Digitalmars-d


On Tuesday, 3 November 2015 at 08:36:46 UTC, Joakim wrote:

There's a Dreamcast emulator for Android/ARM:

https://github.com/reicast/reicast-emulator

You could run it inside the Android emulator on Travis: :)

http://docs.travis-ci.com/user/languages/android/

I'm sure their servers can handle an emulator of a 200 MHz MIPS 
core with 16 MB of RAM running inside an ARM emulator. ;)


Whoops, it runs on linux/x64 also, no need for the Android 
intermediary.

Re: Second CT-Parameter of isRange Predicates

2015-11-03 Thread Atila Neves via Digitalmars-d

On Tuesday, 3 November 2015 at 03:26:47 UTC, Jonathan M Davis 
wrote:
On Monday, 2 November 2015 at 15:00:23 UTC, Andrei Alexandrescu 
wrote:

On 11/02/2015 09:43 AM, Nordlöw wrote:

On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
On Monday, 2 November 2015 at 14:33:44 UTC, Andrei 
Alexandrescu wrote:

https://github.com/D-Programming-Language/phobos/pull/3786


Sent an ICBM its way. -- Andrei


Why not extend existing traits with a second `E`-parameter 
instead of

adding a new one?


I think it's very well worth it in terms of expressability.


I'd say it's a minor convenience.


I'm actually a bit surprised at the suggestion, since I would 
have expected most code to either not care what the ElementType 
was or to have to test something about it other than simply 
testing for an exact type.


Am I the only one who ever writes `int[]` or `Struct[]` in a 
function signature?


Atila

Re: Capturing FILE and __LINE in a variadic templated function

2015-11-03 Thread Jonathan M Davis via Digitalmars-d-learn

On Tuesday, November 03, 2015 07:35:40 Nordlöw via Digitalmars-d-learn wrote:
> On Tuesday, 3 November 2015 at 06:14:14 UTC, Jonathan M Davis
> wrote:
> > You should pretty much never use __FILE__ or __LINE__ as
> > template arguments unless you actually need to. The reason is
> > that it will end up creating a new instantiation of the
> > template pretty much every time that it's used, which is going
> > to be mean a _lot_ of extra code bloat if you use the template
> > much. And in some, rare circumstances that may be exactly what
> > you want. But it almost never is.
> >
> > - Jonathan M Davis
>
> So why is this pattern is used all over std.experimental.logger?

I don't know. I haven't looked at std.experimental.logger much. I do vaguely
recall there being a discussion about that and there being something that
prevented it from using __FILE__ and __LINE__ as runtime arguments, but I
don't remember the reason. If I had to guess though, it would be be because
of variadic arguments, since AFAIK, you can't have any function parameters
after the variadic ones (even if they have default arguments), which makes
it so that you can't put __FILE__ and __LINE__ as default arguments at the
end like you'd normally do. Maybe that would be a good reason for a language
enhancement that made it possible. It doesn't make sense when you want to be
able provide arguments other than the default arguments to those trailing
parameters, but it does make sense when you just want to use the default
arguments - which really only makes sense with stuff like __FILE__ and
__LINE__, but it would allow us to get rid of all of the template bloat that
std.experimental.logger is going to generate if it's taking the __FILE__ and
__LINE__ as template arguments.

- Jonathan M Davis

Chrome OS folding into Android, Android coming to laptops

2015-11-03 Thread Joakim via Digitalmars-d

https://www.thurrott.com/mobile/7541/google-doesnt-quite-deny-chrome-os-android-story

Paulo and I looked into the future and predicted this in June:

Paulo: "Eventually Google will realize [Chromebooks] are as
useful as WebOS and will merge them with Android."

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

Me: "ChromeOS strikes me as google trying to use their one hammer
everywhere, even when there are no nails, ie they're built around
the web so they made an OS out of it. But it's frankly kind of a
dumb idea, I don't see it lasting.

They're working on a multi-window mode for Android, early
versions of which have been found by those spelunking through the
recent Android M preview. Once that's done, I suspect they'll
start putting Android on laptops too and kill off Chrome OS."

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

Android and iOS are gunning for laptops next, with their recently
announced Pixel C and iPad Pro, I'm sure desktops will soon
follow. When those two platforms went after Windows
Mobile/Phone, they burned it to the ground:

http://bgr.com/2011/12/13/apple-and-google-dominate-smartphone-space-while-other-vendors-scramble/

Why does this matter for D? Well, D's still barely on mobile.
Dan has been providing ldc builds that cross-compile to iOS since
July and nobody has confirmed that it works for them. I provided
patches that'd let anyone compile a mostly working Android
cross-compiler build of ldc soon afterwards, no confirmed usage
of that either (several people have run the test runner I made
available this weekend, thanks to them).

Mobile is a giant opportunity for Ahead-of-Time (AoT) compiled
languages like D. The web revolution during the '90s and '00s
led to the rise of scripting languages, like ruby or python,
because they could be run easily on the server and used with a
web frontend. The current mobile revolution has led to a
resurgence of AoT-compiled languages, with Obj-C taking off and
Java and C# finally going AoT-compiled on Android and WP.

However, there is no single cross-platform AoT-compiled language
you can use on all of these mobile platforms. There is no modern
language you can use on all of them, as Swift is still iOS-only.
D could be that language, the mobile wave is one D cannot afford
to miss.

DConf 2016 venue: beautiful Heimathafen Neukölln

2015-11-03 Thread Andrei Alexandrescu via Digitalmars-d-announce


http://dconf.org/2016/venue.html

We're pleased to announce that DConf 2016 will take place in Heimathafen 
Neukölln, the crucible of modern Berliner Volkstheater ("People's 
Theater"). We should feel right at home amid the energy, provocative 
contrasts, and colorful creativity on Karl-Marx-Straße.


Early-bird registration to open soon. See you there, and if you ever 
wanted to wear some quirky accessory (that bandana? orange sneakers? 
vintage DConf shirt?) - bring it with you!



Andrei

Re: foreach loop

2015-11-03 Thread Namal via Digitalmars-d-learn


On Tuesday, 3 November 2015 at 14:52:19 UTC, Adam D. Ruppe wrote:

On Tuesday, 3 November 2015 at 14:47:14 UTC, Namal wrote:
I remember it is possible to get the index for each element in 
the foreach loop, but I forgot how to do it. Can you help me 
out please. Thx.


for many of them it is as simple as:

foreach(index, element; array) { }


Thank you. I am still struggling with the functional ways of D. 
Now how could I write this foreach loop the functional way?


bool[] arr = [ture, false, ture, ...];

int count;
foreach(i;arr){

  if(!i)
count++;
}
writeln(count);

1 2 >

1 - 100 of 175 matches

Mail list logo