Re: Mitigating the attribute proliferation - attribute inference for functions

[Martin Nowak via Digitalmars-d]

On Sunday, 12 April 2015 at 22:45:37 UTC, Zach the Mystic wrote:
The basic suggestion is that D has a function attribute which 
expressly indicates that a function is separately compiled, 
thus eliminating all ambiguity and mystery about what can and 
can't be inferred.


Yeah, as you already seem to know, we want to get `export` in 
shape to be usable for this and other purposes.

See http://wiki.dlang.org/DIP45.

Re: Mitigating the attribute proliferation - attribute inference for functions

[H. S. Teoh via Digitalmars-d]

On Mon, Apr 13, 2015 at 01:29:15AM +, deadalnix via Digitalmars-d wrote:
 On Sunday, 12 April 2015 at 18:34:55 UTC, Andrei Alexandrescu wrote:
 On 4/12/15 12:12 AM, Walter Bright wrote:
 At one point, I had implemented it for auto return functions,
 because the source must exist for them, too, but it got a lot of
 resistance and was dropped.
 
 It's perhaps time to revisit that. I think the resistance was not
 properly motivated at all. -- Andrei
 
 Yes, I though it was more or less agreed upon, but nobody took the
 time to make it work.
 
 That would greatly help, please reconsider.

Resistance or not, I support expanding the scope of auto-inference. It's
the only feasible long-term solution to attribute proliferation.


T

-- 
I see that you JS got Bach.

Re: I came up with a new logo for the D language

[Rikki Cattermole via Digitalmars-d]

On 13/04/2015 10:01 a.m., Barry Smith wrote:

It's simple, but clean. Somewhat similar to the old one. Hope you like it.

http://s2.postimg.org/m6qcfemhl/dlang.png

Email me at barry.of.sm...@gmail.com if you want the SVG version.


I think we should integrate our solar system's planets more into the logo.
A little like what I did for The way to program - Lets think like a 
D(eveloper)'s title page.


https://github.com/rikkimax/twp-d/blob/master/manuscript/images/title_page.png

Re: I came up with a new logo for the D language

[tcak via Digitalmars-d]

On Monday, 13 April 2015 at 02:56:04 UTC, Kapps wrote:

On Sunday, 12 April 2015 at 22:02:01 UTC, Barry Smith wrote:
It's simple, but clean. Somewhat similar to the old one. Hope 
you like it.


http://s2.postimg.org/m6qcfemhl/dlang.png

Email me at barry.of.sm...@gmail.com if you want the SVG 
version.


IIRC Andrei and/or Walter were quite opposed to a logo change.


Problems about logo are 3 things:

1. The background (that glass effect) shouldn't be considered a 
part of logo. It should be changed whenever necessary.


2. The logo itself (without background) is a little wide.

3. Until you guys said, I didn't know that those are planets. 
They should be an original colourful logo maybe that makes this 
clear.


But, since no changes even considered at all, there is no need it 
give any effort I think.

Re: Mitigating the attribute proliferation - attribute inference for functions

[Dicebot via Digitalmars-d]

I think point about `export` is important. Tying definition of 
API to `export` instead of `public` fits much better definition 
of those attributes (latter only guarantees symbol access, former 
also ensures cross-binary availablity) and allows for more 
explicit migration step (as `export` is widely underused right 
now).


Also the issue you have pointed out about API templates that call 
private functions is essentially same issue as Benjamin was 
pointing out here : 
http://forum.dlang.org/post/m9lhc3$1r1v$1...@digitalmars.com


I can't propose good solution here right now but I do believe 
those 2 problems need to be solved in one step.

Re: Mitigating the attribute proliferation - attribute inference for functions

[deadalnix via Digitalmars-d]

On Sunday, 12 April 2015 at 18:34:55 UTC, Andrei Alexandrescu 
wrote:

On 4/12/15 12:12 AM, Walter Bright wrote:
At one point, I had implemented it for auto return functions, 
because
the source must exist for them, too, but it got a lot of 
resistance and

was dropped.


It's perhaps time to revisit that. I think the resistance was 
not properly motivated at all. -- Andrei


Yes, I though it was more or less agreed upon, but nobody took 
the time to make it work.


That would greatly help, please reconsider.

Re: stdout redirect

[Rikki Cattermole via Digitalmars-d-learn]

On 13/04/2015 1:12 a.m., FreeSlave wrote:

On Sunday, 12 April 2015 at 04:39:06 UTC, Philip Stuckey wrote:

why not:
import std.stdio;
stdout = File(args[4], w+);
stderr = File(args[4], w+);


It just replaces the object, not redirects output. E.g. if you use
printf somewhere it will use stdout, not file.


You will need to use writefln instead of printf. As printf uses the 
processes stdout. Changing this would be tricky and OS based.

Re: Why I'm Excited about D

[Dicebot via Digitalmars-d]

On Sunday, 12 April 2015 at 18:42:01 UTC, Andrei Alexandrescu 
wrote:

On 4/12/15 10:43 AM, Dicebot wrote:
It is much better in languages that do support dedicated 
properties
because language rules can be used to express the same notion 
without

resorting to any conventions.


Wouldn't e.g. C# allow arbitrary code in getters and setters? 
And if so, wouldn't C# code need to resort to conventions to 
avoid surprising behavior? -- Andrei


This is totally reasonable way to put it but in practice there 
are enough differences to keep it maintainable. With dedicated 
getters decision (and reviewer attention) is focused on 
definition of getter and done there once and for all. Some tough 
decisions are inevitable but it is at least possible to ensure 
that all such decisions are deliberate. In D such decision is 
done at call site which makes it very hard to review as changes 
are distributed everywhere. Though DScanner can possibly help 
here and I am really looking forward trying to it in our code 
control.


That said, I think the main reason why this notion didn't work 
well for D when @property was introduces is because of extremely 
vague range semantics. I find it important that you have 
mentioned exactly `front` and `popFront` as examples for unclear 
parens placement - problem with those is that there isn't. 
`front` may or may not be trivial getter depending on (sometimes 
arbitrary) decision by range implementor, there is no uniformity 
between those. Which makes impossible to enforce consistent 
calling style and makes drop everything approach much more 
tempting.

This week in D #13: =void tip, ddmd, if(arr) warn, dconf registration

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

http://arsdnet.net/this-week-in-d/apr-12.html

http://www.reddit.com/r/d_language/comments/32ek17/this_week_in_d_13_void_tip_ddmd_ifarr_warn_dconf/

https://twitter.com/adamdruppe/status/587459000729473024

Re: I came up with a new logo for the D language

[Kapps via Digitalmars-d]

On Sunday, 12 April 2015 at 22:02:01 UTC, Barry Smith wrote:
It's simple, but clean. Somewhat similar to the old one. Hope 
you like it.


http://s2.postimg.org/m6qcfemhl/dlang.png

Email me at barry.of.sm...@gmail.com if you want the SVG 
version.


IIRC Andrei and/or Walter were quite opposed to a logo change.

Re: This week in D #13: =void tip, ddmd, if(arr) warn, dconf registration

[Vlad Levenfeld via Digitalmars-d-announce]

On Monday, 13 April 2015 at 03:37:17 UTC, Adam D. Ruppe wrote:

http://arsdnet.net/this-week-in-d/apr-12.html

http://www.reddit.com/r/d_language/comments/32ek17/this_week_in_d_13_void_tip_ddmd_ifarr_warn_dconf/

https://twitter.com/adamdruppe/status/587459000729473024


Did not know about void initialization, that was really helpful.

Re: Why I'm Excited about D

[Idan Arye via Digitalmars-d]

On Sunday, 12 April 2015 at 18:42:01 UTC, Andrei Alexandrescu 
wrote:

On 4/12/15 10:43 AM, Dicebot wrote:
It is much better in languages that do support dedicated 
properties
because language rules can be used to express the same notion 
without

resorting to any conventions.


Wouldn't e.g. C# allow arbitrary code in getters and setters? 
And if so, wouldn't C# code need to resort to conventions to 
avoid surprising behavior? -- Andrei


I'd be surprised if there is any language that prevents you from 
causing side-effects in getters(beside functional languages that 
prevent you from causing side-effects anywhere) or 
non-setting-related side-effects in setters. These kind of 
limitations prevent many useful patterns, like 
calculating-and-caching a value the first time a getter is 
called, or updating a visual component on the screen when it's 
setters are called.


I don't think 
relying-purely-on-conventions-with-no-language-support and 
the-language-strictly-forbids-stuff are the only choices. With a 
grain (syntactic) salt a language can promote the right way by 
turning the wrong way into code smell.


If you see a getter function declared as getter(be it with C#'s 
getter declaration syntax or with D's 
doesn't-actually-do-anything @property attribute or whatever used 
in that language) that causes side-effects other than the ones 
pragmatically needed for getting the value, you can immediately 
see that something is wrong. But if you look at such a function 
at the call site you can't guess that it's doing that stuff.


In C#, if you can't rely on other developers to only use the 
getter-setter syntax for actual getters and setters, then that is 
probably the least of your worries...


In D, you don't need to not rely on other developers to do that, 
because EVERY method without arguments and EVERY function with a 
single argument are getters, and there is nothing you can do 
about it(unless you use the seems-to-be-abandoned -property flag).



BTW - the exact definition of getters and setters may vary(can 
querying a webservice be considered a getter?), but under no sane 
definition is writeln a getter!

I came up with a new logo for the D language

[Barry Smith via Digitalmars-d]

It's simple, but clean. Somewhat similar to the old one. Hope you 
like it.


http://s2.postimg.org/m6qcfemhl/dlang.png

Email me at barry.of.sm...@gmail.com if you want the SVG version.

Re: Mitigating the attribute proliferation - attribute inference for functions

[Zach the Mystic via Digitalmars-d]

Please scan this thread for any useful ideas:

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

I don't have the technical expertise to know if it's useful or 
could work. The basic suggestion is that D has a function 
attribute which expressly indicates that a function is separately 
compiled, thus eliminating all ambiguity and mystery about what 
can and can't be inferred.

Re: mixin template question

[Paul D Anderson via Digitalmars-d-learn]

On Sunday, 12 April 2015 at 04:04:43 UTC, lobo wrote:

On Sunday, 12 April 2015 at 03:51:03 UTC, Paul D Anderson wrote:
I don't understand why the following code compiles and runs 
without an error:


import std.stdio;

mixin template ABC(){
 int abc() { return 3; }
}

mixin ABC;

int abc() { return 4; }

void main()
{
 writefln(abc() = %s, abc());
}

Doesn't the mixin ABC create a function with the same 
signature as the actual function abc()?


It compiles with both included and writes abc() = 4. If I 
comment out the actual function then it writes abc() = 3. 
The actual function takes precedence, but why don't they 
conflict?


Paul


As the manual says (snippet below) the surrounding scope 
overrides mixin


http://dlang.org/template-mixin.html

---
Mixin Scope
The declarations in a mixin are ‘imported’ into the surrounding 
scope. If the name of a declaration in a mixin is the same as a 
declaration in the surrounding scope, the surrounding 
declaration overrides the mixin one:

int x = 3;

mixin template Foo()
{
int x = 5;
int y = 5;
}

mixin Foo;
int y = 3;

void test()
{
writefln(x = %d, x);  // prints 3
writefln(y = %d, y);  // prints 3
}
---

bye,
lobo


Thanks.

Re: DIP77 - Fix unsafe RC pass by 'ref'

[Walter Bright via Digitalmars-d]

On 4/11/2015 4:33 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:

On Saturday, 11 April 2015 at 09:41:07 UTC, Walter Bright wrote:

On 4/11/2015 2:28 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:

It's not acceptable that it happens behind the user's back. Costly operations
must be explicit.


Don't know of a better solution.


How about this?

http://wiki.dlang.org/User:Schuetzm/scope3#.40safe-ty_violations_with_borrowing

Btw, I also made other changes: No implied scope for @safe functions, no
overloading on scope (instead postblit and destructor are skipped), and added a
terminology section (rather important!).


A quick read of this suggests it is doing the Rust model of only one mutable 
reference at a time. Is this really viable with D?

Re: [OT] Regarding most used operating system among devs

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 9 April 2015 at 18:28:46 UTC, Marco Leise wrote:

Am Wed, 08 Apr 2015 13:05:01 +
schrieb Szymon Gatner noem...@gmail.com:


On Wednesday, 8 April 2015 at 12:34:06 UTC, Paulo  Pinto wrote:

 Since then, I always favor spaces over tabs. One space is 
 always one space.



Not to start a war but agreed ;) 2 spaces (specifically) FTW!


You see, there's the reason why we tab users use tabs.


Even though I will probably get the same response as shown here 
[1], I consider the most sensible (and imho the technically 
correct) way to be both:
- Tabs for indentation, because one tab is always one indentation 
level, regardless of the actual visual width.
- Spaces for alignment, because inside one indentation level you 
should be able to align code without interacting with the 
indentation level at all, keeping the two separate.


This way allows any reader to always have correct indentation and 
alignment, while still being able to choose how wide one 
indentation level should be rendered as.


As such: Smart Tabs FTW!

[1] http://www.emacswiki.org/emacs/SmartTabs

Re: Mitigating the attribute proliferation - attribute inference for functions

[Walter Bright via Digitalmars-d]

Attribute inference works when the source to a function must exist (i.e. be 
available to the compiler). Currently, it is done for template functions and 
function literals.


At one point, I had implemented it for auto return functions, because the source 
must exist for them, too, but it got a lot of resistance and was dropped.

Re: Mitigating the attribute proliferation - attribute inference for functions

[weaselcat via Digitalmars-d]

On Sunday, 12 April 2015 at 07:12:47 UTC, Walter Bright wrote:
Attribute inference works when the source to a function must 
exist (i.e. be available to the compiler). Currently, it is 
done for template functions and function literals.


At one point, I had implemented it for auto return functions, 
because the source must exist for them, too, but it got a lot 
of resistance and was dropped.


Is this really an issue that comes up? How often do people in D 
not have access to the source of the libraries they're working 
with?


Martin seemed to be advocating heavily for not inferring between 
packages, and using it to clean up internal functions.


Is there a reason functions marked private and package couldn't 
infer? Is the main issue with this the extra compilation time it 
would take?

Re: DIP77 - Fix unsafe RC pass by 'ref'

[matovitch via Digitalmars-d]

On Sunday, 12 April 2015 at 07:17:07 UTC, Walter Bright wrote:


A quick read of this suggests it is doing the Rust model of 
only one mutable reference at a time. Is this really viable 
with D?


I would love to see a storage class to add the rust ownership 
model to D. I surely don't know if it's feasible.

Trouble in converting C code to D

[Suliman via Digitalmars-d-learn]

So I got GDAL binding work. And now I need to understand how to 
translate C code to D.


Here is simple tutorial: http://www.gdal.org/gdal_tutorial.html 
If I right understand it's easier to take C, than C++ code 
example.


Now I am trying to get very simple example work. My code is:

  string fileTiff = 
`D:\code\RSM2DOC\data-example\03022014_101_022731_09_10_Rostov.tif`;

  if (!fileTiff.exists)
writeln(Tiff file do not exists);

  GDALDatasetH hDataset = GDALOpen( toStringz(fileTiff), 
GDALAccess.GA_ReadOnly );


  GDALDriverH  hDriver;
  hDriver = GDALGetDatasetDriver(hDataset);

  double adfGeoTransform[6];

  if( GDALGetGeoTransform( hDataset, adfGeoTransform ) == CE_None 
)

  {
writeln(adfGeoTransform[1]);
  }


function (void*, double*) is not callable using argument types 
(void*, double[6])


I can't understand why this error is rise up. It's look like 
1-to-1 with C code.


Also I can't understand at what moment adfGeoTransform get in it 
value.

Re: Mitigating the attribute proliferation - attribute inference for functions

[Walter Bright via Digitalmars-d]

On 4/12/2015 12:33 AM, weaselcat wrote:

Is there a reason functions marked private and package couldn't infer?


There's still an issue of a private function being called by a template, and the 
definition of that private function is compiled separately.



Is the main issue with this the extra compilation time it would take?


No.

Re: Wiki page: Coming From C++

[anonymous via Digitalmars-d]

On Sunday, 12 April 2015 at 03:51:50 UTC, Jakob Ovrum wrote:
I can't seem to get the compiler to error on dangling else. I 
tried the examples in the original PR[1], but they seem to 
compile without error with DMD 2.067. Is anyone able to make 
the compiler error on dangling else?


[1] https://github.com/D-Programming-Language/dmd/pull/336


It's a warning.

[Issue 5770] Template constructor bypass access check

[via Digitalmars-d-bugs]

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

--- Comment #6 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/4cd6985729ae349d869624146c5e57ec1fe8ff2b
fix Issue 5770 - Template constructor bypass access check

It had caused by the incomplete implementation of access check. Most part of
`access.c` was old code from ancient D ages.

https://github.com/D-Programming-Language/dmd/commit/b2e2f80d365728f54f602efa2cb56bdc87c69b7a
Merge pull request #4558 from 9rnsr/fix5770

Issue 5770 - Template constructor bypass access check

--

Re: DIP77 - Fix unsafe RC pass by 'ref'

[matovitch via Digitalmars-d]

On Sunday, 12 April 2015 at 04:18:54 UTC, Andrei Alexandrescu 
wrote:

On 4/11/15 5:35 AM, matovitch wrote:
I am not convinced by the dip77, what about raii managed 
classes with
costly opAssign operator (like in w0rn example) ? The goal of 
passing an

object by reference is to avoid the copy and here you guess the
parameter is ref-counted and made a (pseudo-)copy ? Then any 
allocating

opAssign should be marked @system ?


Expensive opAssign or expensive postblit? -- Andrei


Well both in the example given by w0rp. I guess D as no rule of 
five but still a rule of three (which is in fact rule of four 
with the copy-and-swap idiom) about coding posblit, opAssign and 
destructor together ?

Re: Mitigating the attribute proliferation - attribute inference for functions

[Martin Nowak via Digitalmars-d]

On Sunday, 12 April 2015 at 07:12:47 UTC, Walter Bright wrote:
At one point, I had implemented it for auto return functions, 
because the source must exist for them, too, but it got a lot 
of resistance and was dropped.


I thought that was already in, but it isn't.
https://github.com/D-Programming-Language/dmd/pull/1877#issuecomment-16353774

The resistance to the pull this isn't directed against attribute 
inference but against the problems that may arise. Looks like we 
need to come up with a comprehensive proposal, that addresses 
those problems. Anyone wants to help with a DIP?

Re: DIP77 - Fix unsafe RC pass by 'ref'

[via Digitalmars-d]

On Sunday, 12 April 2015 at 07:17:07 UTC, Walter Bright wrote:
On 4/11/2015 4:33 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= 
schue...@gmx.net wrote:

http://wiki.dlang.org/User:Schuetzm/scope3#.40safety_violations_with_borrowing


A quick read of this suggests it is doing the Rust model of 
only one mutable reference at a time. Is this really viable 
with D?


I think it is. You have to keep in mind that this is opt-in; it 
only applies to `scope` variables. I would agree that as a 
default, it wouldn't fit D at all. I think that, for all its 
usefulness, it'd be a tad too limiting for my taste if I were 
forced to use it everywhere. In Rust, it needs to be ubiquitous, 
because their goal is to get by without a GC. We on the other 
hand just want a way to make the GC easier to avoid. We also want 
to be able to use these different programming styles side by 
side, therefore an opt-in solution is good.


Besides, I too want to recommend the article Matovitch linked to, 
and Yehuda Katz' article mentioned therein, because they make a 
good point demonstrating that it gives more correctness 
guarantees than just memory safety:


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

It's a great building block for lots of nice things. In fact, 
it's quite likely the only way to get these guarantees once you 
look beyond reference counting.

[Issue 14423] struct destructors not finalized for AA values

[via Digitalmars-d-bugs]

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

Rainer Schuetze r.sagita...@gmx.de changed:

   What|Removed |Added

   Keywords||pull
 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze r.sagita...@gmx.de ---
https://github.com/D-Programming-Language/druntime/pull/1212

--

writefln patterns with mismatching compile-time known number of arguments

[JR via Digitalmars-d-learn]

I was chatting with a friend and showed him how printf(%s) 
printed random memory in C, whereas writefln(%s) in D threw an 
Exception upon execution. It's probably not a completely fair 
comparison but that's a different topic.


I admit to being confused as to why it passed compilation at all 
in the first place. Surely the %s literal is just as known at 
compilation as an enum would be.


Is there any button in D that could be leveraged to statically 
assert that the number of arguments precisely match the number of 
format specifiers, iff the pattern is static/enum/literal?


I asked in #d and had it pointed out that this could be solved 
via an overload of writefln that took the pattern as a template 
instantiation argument, to which I conceed. The main con would 
naturally be that you end up with template bloat. You could also 
have tooling (dfix/dscanner) handle it for you.


But the compiler has all the pieces of information needed to see 
it's wrong, doesn't it?


How much of this kind of thing is evaluated during the CTFE 
passes?

Re: writefln patterns with mismatching compile-time known number of arguments

[ketmar via Digitalmars-d-learn]

On Sun, 12 Apr 2015 14:18:21 +, JR wrote:

 But the compiler has all the pieces of information needed to see it's
 wrong, doesn't it?

no, it doesn't. compiler doesn't know about `std.format.format` and it's 
special abilities. while it is possible to add such checks to the 
compiler, it will introduce interdependency between compiler and phobos, 
which is not desirable.

writing CTFE `writef` version is possible without template bloat in 
binary, but it will take more memory in compile time and slows 
compilation. there were talks about having `writef!fmt(args)` in phobos, 
but nobody took that task yet.

signature.asc
Description: PGP signature

Re: A more general bsr/bsf implementation

[safety0ff via Digitalmars-d]

On Sunday, 12 April 2015 at 11:53:41 UTC, Johan Engelen wrote

My questions:
1) Is it OK to put a more general bsf/bsr in druntime or in 
Phobos? (if Phobos: in which package to put it?)


IMO I want a std.integer package for such functions.
I started writing one but I have to rewrite it.

I don't know if building up such a package by piecemeal would be 
accepted.


2) Is the current sign-extend up to size_t's width really 
intended behavior?


It's due to integer promotions, so it should only influence bsr 
(when it is called with a signed type.)

Re: Mitigating the attribute proliferation - attribute inference for functions

[Martin Nowak via Digitalmars-d]

On Sunday, 12 April 2015 at 08:55:17 UTC, Walter Bright wrote:
There's still an issue of a private function being called by a 
template, and the definition of that private function is 
compiled separately.


That's the problem of the author of that template. He would still 
have to annotate that private function manually like today.
But everything called by that function doesn't need to be 
attributed.

Re: Trouble in converting C code to D

[Suliman via Digitalmars-d-learn]

Oh in gdal.d there is comment:

 /*
  * The enum CPLErr is defined in the header file cpl_error.h. I 
have not
  * for the time being included a binding to that header, but 
have just

  * imported this single symbol from it.
  *
  * Similarly, GDALProgressFunc is defined in port/cpl_progress.h
  */

Am I right understand that binding is not file with .d extension? 
So what is this file with extern(C) and so on. It's named 
interface file?

[Issue 14440] New: CTFE Regression: Wrong values set in a matrix constructor.

[via Digitalmars-d-bugs]

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

  Issue ID: 14440
   Summary: CTFE Regression: Wrong values set in a matrix
constructor.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: devw...@gmail.com

Created attachment 1512
  -- https://issues.dlang.org/attachment.cgi?id=1512action=edit
A reduced test case.

This is a strange bug. In my dstruct library, I use a constructor which takes
an array of arguments with a fixed size for creating matrices in my library. So
you can write a constructor like this.

auto matrix = Matrix!(int, 3, 3)(1, 2, 3, 4, 5, 6, 7, 8, 9);

So the matrix can be created on the stack directly with no heap allocation,
and then it offers operations like addition and multiplication, etc.

One of my unit tests caught a CTFE regression where 'enum' is used instead of
auto. So
when the matrix is created at runtime, the 2D array held within rightly becomes
[[1, 2, 3], [4, 5, 6], [7, 8, 9]]. However, when 'enum' is used, the array
becomes [[7, 8, 9], [7, 8, 9], [7, 8, 9]]. This used to work just fine in
2.066.

I have attached a reduced test case to this bug report. Curiously, I tried
using a function instead of a constructor in a struct, and the function worked.
So the bug seems to be somehow tied to the constructor.

--

Re: Standard GUI framework inspired by Qt

[Manu via Digitalmars-d]

On 13 March 2015 at 09:54, karl via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 I'm unsure of the gamma space, Adobe should be enough to cover things (the
 curve is practically identical). Still, they are different at 0xA7 and 0xBE,
 so maybe useful for some files. GPUs and every non-specialized monitor only
 do sRGB-linear.
 So, all's good with that pull request, just gamma might be useless and
 confusing.

'gamma' is used in many performance-oriented applications, because
it's MUCH faster to calculate/convert than sRGB (which is completely
mental).

Note, I still have a LOT of work to do on that module, I'm not really
happy with it. But I wanted to try that approach out.
I think I'm leaning more towards explicit types for different
high-level colour spaces after experimenting with that design. I'll
probably leave selection of colourspace detail to template arg though
(sRGB/linear/etc).

[Issue 14440] [REG2.067] CTFE Regression: Wrong values set in a matrix constructor.

[via Digitalmars-d-bugs]

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

Martin Krejcirik m...@krej.cz changed:

   What|Removed |Added

 CC||m...@krej.cz
   Hardware|x86_64  |All
Summary|CTFE Regression: Wrong  |[REG2.067] CTFE Regression:
   |values set in a matrix  |Wrong values set in a
   |constructor.|matrix constructor.

--

[Issue 14441] New: Strange error with string ctor

[via Digitalmars-d-bugs]

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

  Issue ID: 14441
   Summary: Strange error with string ctor
   Product: D
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

auto s = string(`foo`);

Error: function expected before (), not string of type string

It should be accepted because all built-in types has a ctor.

For example auto a = int(10); works

--

[Issue 14440] [REG2.067] [CTFE] Wrong values set in a matrix constructor

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 14440] [REG2.067] [CTFE] Wrong values set in a matrix constructor

[via Digitalmars-d-bugs]

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

--- 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/7b64c8d9e45c93be287c8a5b0f5f14ec566cebaa
fix Issue 14440 - [CTFE] Wrong values set in a matrix constructor

https://github.com/D-Programming-Language/dmd/commit/444cc4e4cd4246395c2a12058a8de8ec90f134ed
Merge pull request #4583 from 9rnsr/fix14440

[REG2.067] Issue 14440 - [CTFE] Wrong values set in a matrix constructor

--

Re: Trouble in converting C code to D

[Stefan Koch via Digitalmars-d-learn]

Do have you extern(C) everywhere ?

Re: Trouble in converting C code to D

[Jacob Carlborg via Digitalmars-d-learn]

On 2015-04-12 11:19, Suliman wrote:

So I got GDAL binding work. And now I need to understand how to
translate C code to D.

Here is simple tutorial: http://www.gdal.org/gdal_tutorial.html If I
right understand it's easier to take C, than C++ code example.

Now I am trying to get very simple example work. My code is:

   string fileTiff =
`D:\code\RSM2DOC\data-example\03022014_101_022731_09_10_Rostov.tif`;
   if (!fileTiff.exists)
 writeln(Tiff file do not exists);

   GDALDatasetH hDataset = GDALOpen( toStringz(fileTiff),
GDALAccess.GA_ReadOnly );

   GDALDriverH  hDriver;
   hDriver = GDALGetDatasetDriver(hDataset);

   double adfGeoTransform[6];

   if( GDALGetGeoTransform( hDataset, adfGeoTransform ) == CE_None )
   {
 writeln(adfGeoTransform[1]);
   }


function (void*, double*) is not callable using argument types (void*,
double[6])

I can't understand why this error is rise up. It's look like 1-to-1 with
C code.

Also I can't understand at what moment adfGeoTransform get in it value.


GDALGetGeoTransform is declared to take a pointer to a double (array of 
doubles). While adfGeoTransform is declared as a static array [1] of 
doubles. Static arrays are stack allocated and passed by value, the 
function expects an array which is passed by reference. Try adding 
.ptr to adfGeoTransform in the call to GDALGetGeoTransform.


[1] http://dlang.org/arrays.html#static-arrays

--
/Jacob Carlborg

Re: Mitigating the attribute proliferation - attribute inference for functions

[Daniel N via Digitalmars-d]

On Saturday, 11 April 2015 at 21:47:20 UTC, Martin Nowak wrote:

Sorry to open yet another topic.

I'm repeatedly finding myself in situations where I write 
functions like

this.

private @property bool empty() const @safe pure nothrow 
@nogc

{
return impl is null || !impl.count;
}


FYI, I wrote an enhancement request for this already. In case the 
discussion reaches a conclusion this time around, you might want 
to update the status:


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

Re: DIP77 - Fix unsafe RC pass by 'ref'

[via Digitalmars-d]

On Saturday, 11 April 2015 at 20:40:20 UTC, deadalnix wrote:

On Saturday, 11 April 2015 at 09:28:46 UTC, Marc Schütz wrote:
It's not acceptable that it happens behind the user's back. 
Costly operations must be explicit.


Nothing is costly here.


Of course it is:
http://forum.dlang.org/post/iehijjgdlfouplcng...@forum.dlang.org

A more general bsr/bsf implementation

[Johan Engelen via Digitalmars-d]

Currently, druntime only supports bsf/bsf, i.e. finding the first 
or last bit set, on size_t [1]; bsf(size_t) and bsr(size_t) are 
compiler intrinsics.
Because only size_t is supported, it is cumbersome to write 
generic code using bsf/bsr. For example, for 64-bit code 
bsr(long(...)) will work, but not for 32-bit code. bsr(cent(...)) 
will not work either.
To improve std.math.ilogb, I need a generic bsr. So I figured I 
add that to druntime or Phobos.


I wrote more generic bsr/bsf but I stumbled across an unexpected 
result:
Currently, bsr(byte(-1))) is equal to 31 instead of 7. My general 
bsr honors the width of the input type, and returns 7 for this 
example. The problem now of course is that replacing the old bsr 
with my bsr would potentially break existing code (the existing 
code may then already be broken when considering 32-bit and 
64-bit mode).


My questions:
1) Is it OK to put a more general bsf/bsr in druntime or in 
Phobos? (if Phobos: in which package to put it?)
2) Is the current sign-extend up to size_t's width really 
intended behavior?


Thanks a bunch,
  Johan

[1] http://dlang.org/phobos/core_bitop.html#.bsr

[Issue 14440] [REG2.067] CTFE Regression: Wrong values set in a matrix constructor.

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||CTFE, wrong-code
 CC||ag0ae...@gmail.com
 OS|Linux   |All

--- Comment #1 from ag0ae...@gmail.com ---
Reduced further:

struct Matrix {
int[1][2] array2D;
this(int dummy) {
array2D[0][0] = 1;
array2D[1][0] = 2; /* writes over array2D[0][0] */
}
}
static assert(Matrix(0).array2D[0][0] == 1); /* fails */

--

[Issue 14363] [SDC] Error with inheriting nested classes in nested functions

[via Digitalmars-d-bugs]

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

--- Comment #7 from Kenji Hara k.hara...@gmail.com ---
(In reply to deadalnix from comment #6)
 (In reply to Shammah Chancellor from comment #5)
  I'm not sure about that part of SDC.  I will investigate and see if
  deadalnix has some input here.
 
 SDC does it by sticking one context in the base and one context in the child.

It's definitely different. dmd inserts at most only one context over the all
derived classes. The second context pointer in the child class need to be error
in SDC.

--

Re: DIP77 - Fix unsafe RC pass by 'ref'

[Martin Nowak via Digitalmars-d]

On Sunday, 12 April 2015 at 07:17:07 UTC, Walter Bright wrote:
On 4/11/2015 4:33 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= 
schue...@gmx.net wrote:
On Saturday, 11 April 2015 at 09:41:07 UTC, Walter Bright 
wrote:
A quick read of this suggests it is doing the Rust model of 
only one mutable reference at a time. Is this really viable 
with D?


It's a very good ownership model IMO, because it has no runtime 
overhead and often sharing/escaping isn't needed. Would at least 
be interesting to explore this in more detail for scoped 
variables.


As a side note, I find that unique ownership is strangely missing 
from our discussions, yet it's a perfect ownership model for 
resources such as a File.

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

Re: stdout redirect

[FreeSlave via Digitalmars-d-learn]

On Sunday, 12 April 2015 at 04:39:06 UTC, Philip Stuckey wrote:

why not:
import std.stdio;
stdout = File(args[4], w+);
stderr = File(args[4], w+);


It just replaces the object, not redirects output. E.g. if you 
use printf somewhere it will use stdout, not file.

Re: why cant function parameters be grouped by type ?

[ketmar via Digitalmars-d-learn]

On Sun, 12 Apr 2015 11:49:18 +, Baz wrote:

 Is there anything in the grammar that prevents this syntax ?

yes: nameless args. i would like to see 'em burned with napalm, but it 
seems to be too late to do that...

signature.asc
Description: PGP signature

Re: Mitigating the attribute proliferation - attribute inference for functions

[Martin Nowak via Digitalmars-d]

On Sunday, 12 April 2015 at 02:07:54 UTC, weaselcat wrote:
I thought as much, that's unsettling because dmd is already 
starting to feel dog slow.


We might have some sort of performance bug in the latest release.
https://issues.dlang.org/show_bug.cgi?id=14431
If you know how to use a profiler, I'd be glad for more info.

Re: Trouble in converting C code to D

[Suliman via Digitalmars-d-learn]

Jacob, thanks!

  double [6] adfGeoTransform;

  if( GDALGetGeoTransform( hDataset, adfGeoTransform.ptr ) == 0 )
  {
writeln(adfGeoTransform[1]);
  }

But could you explain why if binding have next string:

enum CPLErr
{
CE_None = 0,
CE_Debug = 1,
CE_Warning = 2,
CE_Failure = 3,
CE_Fatal = 4
}

I can't use:
if( GDALGetGeoTransform( hDataset, adfGeoTransform.ptr ) == 
CE_None )



Error: undefined identifier CE_None

Re: vibed - best approach to manage central state (cached records)

[via Digitalmars-d-learn]

On Saturday, 11 April 2015 at 19:24:22 UTC, Laeeth Isharc wrote:

Hi.

Two questions:

1. On startup I load various indexes from file storage into 
memory in the shared static this segment, and I would like to 
access these from threads serving web requests.  The data can 
be considered immutable once loaded.


What is the best way to make this data accessible?  Obviously 
static doesn't work as the threads have their own storage (I 
think this is what is happening).  __gshared works, but is 
there a better approach?


You can declare the cache as `immutable` (which is shared across 
threads) and assign to it using `assumeUnique()`. You just need 
to make sure the initialization really happens only once, i.e. do 
it in `main()` or in `shared static this()` as opposed to `static 
this()`.

[Issue 14421] Variadic args array force on heap

[via Digitalmars-d-bugs]

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

--- Comment #5 from yebblies yebbl...@gmail.com ---
(In reply to John Colvin from comment #4)
 (In reply to yebblies from comment #3)
  Is there a reason you can't overload and forward the variadic version to the
  non-variadic after calling dup?
 
 I don't understand how that would help.
 
 What I'm concerned about is if making the variadic array argument creates a
 GC allocation, then the .dup makes another one.

If you have this:

char[] foo(char[] args...)
{
return foo(args.dup);
}
char[] foo(char[] args)
{
return args;
}

void main()
{
foo('a', 'b', 'c'); // this will call first overload, and dup
foo(['a', 'b', 'c']); // this will call second, no dup
}

The array will only be copied if the variadic version is called.

--

Re: DIP77 - Fix unsafe RC pass by 'ref'

[bearophile via Digitalmars-d]

Marc Schütz:

You have to keep in mind that this is opt-in; it only applies 
to `scope` variables. I would agree that as a default, it 
wouldn't fit D at all. I think that, for all its usefulness, 
it'd be a tad too limiting for my taste if I were forced to use 
it everywhere.


I think D Zen asks for safety on default and opt-out on request.

See also @safe by default:
https://issues.dlang.org/show_bug.cgi?id=13838

Bye,
bearophile

Re: DIP77 - Fix unsafe RC pass by 'ref'

[Martin Nowak via Digitalmars-d]

On Sunday, 12 April 2015 at 12:06:50 UTC, bearophile wrote:

I think D Zen asks for safety on default and opt-out on request.


Marc talked about unique ownership vs. shared ownership, not 
about safe vs. unsafe.

Re: Trouble in converting C code to D

[Suliman via Digitalmars-d-learn]

On Sunday, 12 April 2015 at 09:36:54 UTC, Stefan Koch wrote:

Do have you extern(C) everywhere ?


Yes, at binding file. Here is a lot of string like:
extern(C) CPLErr   GDALGetGeoTransform( GDALDatasetH, double* );

[Issue 14421] Variadic args array force on heap

[via Digitalmars-d-bugs]

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

--- Comment #4 from John Colvin john.loughran.col...@gmail.com ---
(In reply to yebblies from comment #3)
 Is there a reason you can't overload and forward the variadic version to the
 non-variadic after calling dup?

I don't understand how that would help.

What I'm concerned about is if making the variadic array argument creates a GC
allocation, then the .dup makes another one.

--

Re: Reminder, use stable branches for important bug fixes

[Martin Krejcirik via Digitalmars-d]

On Friday, 10 April 2015 at 22:55:19 UTC, Martin Nowak wrote:
A small reminder, as the next point release isn't that far 
away, we're

now using stable branches to incorporate important bug fixes.


Stable is broken on autotester.

Re: Mitigating the attribute proliferation - attribute inference for functions

[Martin Nowak via Digitalmars-d]

On Sunday, 12 April 2015 at 09:42:19 UTC, Daniel N wrote:
FYI, I wrote an enhancement request for this already. In case 
the discussion reaches a conclusion this time around, you might 
want to update the status:


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


Oh great, can you help me to turn this into a DIP?
We need to define a sane behavior for when public templates call 
private functions.


One idea I'm carrying around for some time is the following.
For functions with inferred attributes the compiler could emit an 
additional alias symbol with the mangling of the function before 
the inference.
That would allow to link against that function without running 
inference and still use inference for the same function 
internally.

Note that this relies on covariant attributes, i.e.
   void foo() @safe @nogc pure nothrow
is implicitly convertible to
   void foo()

This could work out quite well, you only need to add attributes 
to your private functions to support public templates, but 
typically this should only be few entry points of your library.


One problem arising from that is testing your API.


void tmpl(T)(T t) { return func(t.foo); }
private void func(size_t v) { return v; }

unittest @safe @nogc pure nothrow
{
static struct S { size_t foo; }
tmpl(S()); // works here, but not outside of this module
}

why cant function parameters be grouped by type ?

[Baz via Digitalmars-d-learn]

Hi,
while variable declarations work in list:


uint a,b,c;


function parameters declarations don't:


void foo(uint a,b,c);


Because of this, function declarations are sometimes super-wide.
(despite of the fact that: 
http://www.brainyquote.com/quotes/quotes/a/alanperlis177279.html)


In the previous example, we could imagine that once a type 
defined, it'd valid until a new one appears (until a 
redefinition / an override).


Is there anything in the grammar that prevents this syntax ?

Thx.

[Issue 14440] [REG2.067] [CTFE] Wrong values set in a matrix constructor

[via Digitalmars-d-bugs]

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

Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Keywords||pull
Summary|[REG2.067] CTFE Regression: |[REG2.067] [CTFE] Wrong
   |Wrong values set in a   |values set in a matrix
   |matrix constructor. |constructor

--- Comment #2 from Kenji Hara k.hara...@gmail.com ---
https://github.com/D-Programming-Language/dmd/pull/4583

--

Re: why cant function parameters be grouped by type ?

[Idan Arye via Digitalmars-d-learn]

On Sunday, 12 April 2015 at 11:49:19 UTC, Baz wrote:

Hi,
while variable declarations work in list:


uint a,b,c;


function parameters declarations don't:


void foo(uint a,b,c);


Because of this, function declarations are sometimes super-wide.
(despite of the fact that: 
http://www.brainyquote.com/quotes/quotes/a/alanperlis177279.html)


In the previous example, we could imagine that once a type 
defined, it'd valid until a new one appears (until a 
redefinition / an override).


Is there anything in the grammar that prevents this syntax ?

Thx.



void foo(int a, b);


Is `b` a second int argument, or is there a user defined type 
named `b` and the second argument is nameless of type `b`?

Re: DlangUI

[Vadim Lopatin via Digitalmars-d-announce]

On Thursday, 26 March 2015 at 11:41:17 UTC, Mike James wrote:

On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote:

Hello!

I would like to announce my project, DlangUI library -

SNIP

Hi Vadim,

I have just installed the latest D 2.067.0, ran the git install 
and the build now fails. The errors are as follows:



C:\D\dmd2\gui\dlanguidub run dlangui:example1 --build=release
Building package dlangui:example1 in 
C:\D\dmd2\gui\dlangui\examples\example1\

Target gl3n 1.0.1 is up to date. Use --force to rebuild.
Building dlib ~master configuration library, build type 
release.

Running dmd...
..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\dlib\image\io\jpeg.d(681): 
Warning: instead of C-style

syntax, use D-style syntax 'ubyte[64] dezigzag'
..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\dlib\filesystem\windows\directory.d(77): 
Error: undefin

ed identifier wcslen
FAIL 
..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\.dub\build\library-release-windows-x86-dmd_2067-17

3DBA1310DF90D85EA81F6AA09FBD95\ dlib staticLibrary
Error executing command run: dmd failed with exit code 1.


C:\D\dmd2\gui\dlangui

any clues?

Thanks.

Regards, Mike.


Did you try upgrade dependencies?

dub upgrade --force-remove
dub build --force

Best regards,
 Vadim

Re: A more general bsr/bsf implementation

[Johan Engelen via Digitalmars-d]

2) Is the current sign-extend up to size_t's width really 
intended behavior?


It's due to integer promotions, so it should only influence bsr 
(when it is called with a signed type.)


Sorry for not being clear.
I understand why the current bsr behaves like it does, but what I 
meant is whether that is the desired behavior of bsr:

bsr( byte(-1) ) == 31  (32-bit size_t)
bsr( byte(-1) ) == 63  (64-bit size_t)
instead of
bsr( byte(-1) ) == 7

Re: Trouble in converting C code to D

[Jacob Carlborg via Digitalmars-d-learn]

On 2015-04-12 11:57, Suliman wrote:

Oh in gdal.d there is comment:

  /*
   * The enum CPLErr is defined in the header file cpl_error.h. I have not
   * for the time being included a binding to that header, but have just
   * imported this single symbol from it.
   *
   * Similarly, GDALProgressFunc is defined in port/cpl_progress.h
   */

Am I right understand that binding is not file with .d extension? So
what is this file with extern(C) and so on. It's named interface file?


Based on that comment it sounds like the bindings are not complete. In 
this case only CPLErr has been included from the cpl_progress.h file.


--
/Jacob Carlborg

Re: Trouble in converting C code to D

[Jacob Carlborg via Digitalmars-d-learn]

On 2015-04-12 11:53, Suliman wrote:


But could you explain why if binding have next string:

enum CPLErr
{
 CE_None = 0,
 CE_Debug = 1,
 CE_Warning = 2,
 CE_Failure = 3,
 CE_Fatal = 4
}

I can't use:
if( GDALGetGeoTransform( hDataset, adfGeoTransform.ptr ) == CE_None )


In D you need to include the name of the enum type as well: 
CPLErr.CE_None. If you want to avoid that you can use aliases:


alias CE_None = CPLErr.CE_None

Or the with-statement:

with (CPLErr)
{
  // inside this block all the members of CPLErr can be accessed 
without prefixing them with CPLErr

  if( GDALGetGeoTransform( hDataset, adfGeoTransform.ptr ) == CE_None )
  {
  }
}

--
/Jacob Carlborg

Re: Coedit - beta 1 released

[Baz via Digitalmars-d-announce]

On Wednesday, 8 April 2015 at 20:07:42 UTC, Kelet wrote:

On Wednesday, 8 April 2015 at 17:58:18 UTC, Kelet wrote:

On Tuesday, 7 April 2015 at 05:45:16 UTC, Baz wrote:
I'm pleased to announce the first beta of Coedit, the small 
IDE for the D programming language, based on DMD.


This version introduces:
- the option editor.
- metad, a meta GIT repository composed of static libraries 
easily buildable with Coedit.

- DCD integration: call tips and DDoc comments as hints.
- symbol list based on libdparse (formerly called the _static 
explorer_)


Links:
- Change log and short intro to the new features: 
https://github.com/BBasile/Coedit/releases/tag/beta_1
- Binaries for win32: 
https://github.com/BBasile/Coedit/releases/download/beta_1/coedit.beta1.win32.zip
- Binaries for Nux64: 
https://github.com/BBasile/Coedit/releases/download/beta_1/coedit.beta1.linux64.zip


Hi Baz,

I'm glad to see another IDE on the playing field. Interesting 
that it's written in FreePascal and utilizing Lazarus 
components. I always thought it was a good but underutilized 
tool set. For now, I'm just reading the wiki (which is 
well-populated), but I look forward to giving it a try 
sometime soon.


Cheers!


Hi Baz,

After a quick trial run, I'm quite impressed on how well it runs
on my rather sluggish computer. All of the features seem to be 
in

place and the documentation is well written.

My only complaint lies in the seemingly low level of integration
between coedit and DUB. DUB is quickly becoming ubiquitous in 
the

D community. While it seems like I can build and execute my
project using DUB, I have to maintain 2 separate project
configurations -- one for DUB and one for coedit.

Do you think you will ever be so inclined to have coedit support
opening a DUB package file (i.e., dub.json)? I think that would
sway me to becoming a regular user.

But perhaps I misunderstand something here..

Thanks,


I'll try to integrate DUB in version 2...so not before monthes :/
There is still as a trick the possibility to use DUB as 
pre-build-process.

Re: Why I'm Excited about D

[Dicebot via Digitalmars-d]

On Thursday, 9 April 2015 at 07:00:56 UTC, Andrei Alexandrescu 
wrote:

On 4/8/15 11:45 PM, Dicebot wrote:
It took almost an hour to bisect all changed to trace the 
failure to
this specifc line and realize that `parser.node` wasn't just 
trivial
getter but method which actually advanced internal iterator to 
next node

while returning current one.


Thanks. The matter seems like a C++ false friend. -- Andrei


Actually, C++ had the very same issue, just the other way around. 
Stuff like length() was still called like method even if trivial 
and I remember resorting to naming convention to avoid wasting 
time on following all symbol references. It was roughly the same 
rule - no side effects or costly computations in methods named 
`getXXX`, simply attached to naming convention as opposed to 
calling convention.


And it was even more unpleasant than current D state of affairs. 
I had much more pleasant experience of maintaining code in plain 
C where separation between data and code is more forced by 
language simplicity.


It is much better in languages that do support dedicated 
properties because language rules can be used to express the same 
notion without resorting to any conventions. And properly naming 
things is unreasonably time consuming so this by convention 
approach hardly works anyway.


The way I see situation in D is that it had an opportunity to 
actually get things better than in C/C++ with @property but that 
was killed in favor of seemingly nice syntax. Which feels 
completely disproportional approach to me because saving one pair 
of () per line of code is hardly comparable to being able to 
better reason about the code without resorting to IDE.


Everyone who has pointed out that naming in original snippet 
sucks is completely right. However, this is not really helping - 
bad names will inevitably slip through here and there. Which 
naturally makes me annoyed about language features that make the 
issue worse instead of largely diminishing it. Mandatory () are 
probably not that important on their own - but thet at least add 
something to to the language, while alternative is simply syntax 
sugar with no practical value.

Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.

[Dicebot via Digitalmars-d]

On Saturday, 11 April 2015 at 23:04:26 UTC, Laeeth Isharc wrote:
Thanks, v much Dicebot.  (I think you have earned the right to 
own up to making simple errors without embarrassment in case 
you change your mind - it might help someone else to say what 
it was).


Ha ha, it will hardly help anyone. I have simply forgot to 
increment package version number when doing last fix so it wasn't 
picked up as a replacement to be built.

Re: DIP77 - Fix unsafe RC pass by 'ref'

[via Digitalmars-d]

On Sunday, 12 April 2015 at 13:12:05 UTC, Martin Nowak wrote:
As a side note, I find that unique ownership is strangely 
missing from our discussions, yet it's a perfect ownership 
model for resources such as a File.

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


I'm aware of it, but didn't want to open another can of worms. I 
have a vague idea what to do about it, based on deadalnix' 
isolated idea and the already existing uniqueness concept. I 
need to make up my mind about moving though, whether the benefits 
of making the compiler know about it are worth the added 
complexity.

Re: writefln patterns with mismatching compile-time known number of arguments

[John Colvin via Digitalmars-d-learn]

On Sunday, 12 April 2015 at 14:18:23 UTC, JR wrote:
I was chatting with a friend and showed him how printf(%s) 
printed random memory in C


I'm pretty sure modern C compilers will warn about something as 
obviously wrong as this.

Re: Which D IDE do you use?(survey)

[Dicebot via Digitalmars-d]

On Friday, 10 April 2015 at 19:02:05 UTC, Idan Arye wrote:
Many of these Vim users are not really Vim users - not in the 
sense that Emacs users are Emacs users anyways. Sure, they use 
Vim - but only because it's a default editor in Unix-like 
systems. If Windows Notepad was the default text they wouldn't 
have installed Vim so they could use it - they simply would 
have used Notepad. They just want something that'll allow them 
to edit text files, and they don't care to learn anything more 
advanced than the most basic stuff they need - opening it from 
the shell to edit a file, typing text, saving, closing. Other 
simple commands - like opening another file in the same session 
- might also be basic and simple, but because they are not part 
of that workflow these users won't bother to learn them.


I am actually one of those users. Set of vim features I really 
rely on is limited to tab buffers, regex search, built-in 
autocompletion and jump to matching bracket hotkey. Reason is 
simple - working with text is never a bottleneck in my work, I 
simply don't care how effective it is. Main benefit of vim to me 
is uniformity - it is exactly the same experience on my dev 
machine and via remote shell. Rest is just collection of optional 
yummies that can be used on per need basis.

Re: A more general bsr/bsf implementation

[ketmar via Digitalmars-d]

On Sun, 12 Apr 2015 15:21:24 +, Johan Engelen wrote:

 2) Is the current sign-extend up to size_t's width really intended
 behavior?

 It's due to integer promotions, so it should only influence bsr (when
 it is called with a signed type.)
 
 Sorry for not being clear.
 I understand why the current bsr behaves like it does, but what I meant
 is whether that is the desired behavior of bsr:
  bsr( byte(-1) ) == 31  (32-bit size_t)
  bsr( byte(-1) ) == 63  (64-bit size_t)
 instead of
  bsr( byte(-1) ) == 7

i'd say that with explicitly given type it should be 7. but i don't know 
if it will break any code in druntime/phobos...

signature.asc
Description: PGP signature

Re: IMAP library

[Jens Bauer via Digitalmars-d-learn]

On Saturday, 11 April 2015 at 22:45:39 UTC, Laeeth Isharc wrote:


Yes - nice to know it can do that also.  For me I need to have 
a way of managing large amounts of email (I have about 2mm 
messages) including for natural language processing etc.  
Dovecot/sieve + pipe facility is ok, but not perfect for 
everything.  I guess it should work fine for regular ARM etc - 
perhaps not an Arduino!


I won't say it's impossible, but it would be cumbersome 
processing email on an AVR.

But there are Arduino using ARM Cortex-M microcontrollers too.

I can mention a couple of microcontrollers that have ethernet 
support (eg. they need a PHY of your choice and for instance a 
HanRun ethernet connector) - Examples are STM32F4xx from 
ST-Microelectronics and 
LPC1758/LPC1768/LPC1769/LPC177x/LPC178x/LPC43xx from NXP.
There are others from other vendors as well, but those above are 
quite popular and very easy to find as stand-alone chips or small 
evaluation boards.


I find it particularly interesting to be able to send an email to 
a device, which can then process and do some simple things (eg. 
turn stuff on/off, send back the room temparature, etc.) - also a 
mail-robot would be quite interesting as a stand-alone thing.


Have a few other things on the boil, and also constrained in 
how much time I can spend for various reasons.

I have the exact same problems. ;)

So don't plan or expect on it being finished soon, although I 
hope it might be.
It'll be ready when it's ready. When building in small steps, the 
job often gets easier.


May you be successful with ease!

Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.

[Laeeth Isharc via Digitalmars-d]

On Sunday, 12 April 2015 at 18:07:43 UTC, Dicebot wrote:

On Saturday, 11 April 2015 at 23:04:26 UTC, Laeeth Isharc wrote:
Thanks, v much Dicebot.  (I think you have earned the right to 
own up to making simple errors without embarrassment in case 
you change your mind - it might help someone else to say what 
it was).


Ha ha, it will hardly help anyone. I have simply forgot to 
increment package version number when doing last fix so it 
wasn't picked up as a replacement to be built.


Aha!  Easy to do...

Re: vibed - best approach to manage central state (cached records)

[Laeeth Isharc via Digitalmars-d-learn]

On Sunday, 12 April 2015 at 10:04:53 UTC, Marc Schütz wrote:

On Saturday, 11 April 2015 at 19:24:22 UTC, Laeeth Isharc wrote:

Hi.

Two questions:

1. On startup I load various indexes from file storage into 
memory in the shared static this segment, and I would like to 
access these from threads serving web requests.  The data can 
be considered immutable once loaded.


What is the best way to make this data accessible?  Obviously 
static doesn't work as the threads have their own storage (I 
think this is what is happening).  __gshared works, but is 
there a better approach?


You can declare the cache as `immutable` (which is shared 
across threads) and assign to it using `assumeUnique()`. You 
just need to make sure the initialization really happens only 
once, i.e. do it in `main()` or in `shared static this()` as 
opposed to `static this()`.



Thanks.


Laeeth

Re: Mitigating the attribute proliferation - attribute inference for functions

[Andrei Alexandrescu via Digitalmars-d]

On 4/12/15 12:12 AM, Walter Bright wrote:

At one point, I had implemented it for auto return functions, because
the source must exist for them, too, but it got a lot of resistance and
was dropped.


It's perhaps time to revisit that. I think the resistance was not 
properly motivated at all. -- Andrei

Probably you can run a D command line app on an android ARM device

[Laeeth Isharc via Digitalmars-d]

BTW - since we have linux on ARM, the following may be useful if 
you wish to run a D application on your Android mobile device.  
No ADB or root required.


http://kevinboone.net/android_nonroot.html

I guess you might be able to run a local web server to have a 
friendlier interface, although I have not yet tried.  Since ssh 
and rsync works, I don't see why a web server wouldn't.


Only thing is that I don't think vibe.d is available on ARM yet.  
(Please correct me if I am wrong).


The alternative is to run a full linux install in a chroot:

https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy

Mixed closures and class.outer references

[Iain Buclaw via Digitalmars-d]

Hi,

Can someone tell me what is supposed to happen in Outer.foo.Inner.bar?
 And how it should look in debug?

---
class Outer
{
int x = 42;
void foo()
{
int y = 43;
class Inner
{
void bar()
{
assert(x == 42);
assert(y == 43);
}
}
Inner b = new Inner();
b.bar();
}
}
---

What I'm currently seeing is:

Function: Inner.bar()
Params: (this=...)
typeof(this) == Inner
typeof(this.this) == Outer

No sign of the closure in Outer.foo, so how is 'y' even accessible?

Re: UFCS overrides alias this

[anonymous via Digitalmars-d]

On Sunday, 12 April 2015 at 20:19:02 UTC, Freddy wrote:


test.d
struct A{
string b;
alias b this;
}

struct MyRange{

}
char front(MyRange);
void popFront(ref MyRange);
bool empty(MyRange);

void test(A a){
a.empty;
}

$ dmd -o- test
test.d(14): Error: function test.empty (MyRange) is not 
callable using argument types (A)


Is this intended behavior?


string's empty is actually a function in std.array or std.range 
or something, called via UFCS. You don't import std's empty, so 
the call can't match even when the alias this is tried.


Add the following, which brings std's empty into the overload 
set, and it works:


static import std.range;
alias empty = std.range.empty;

Re: Why I'm Excited about D

[Andrei Alexandrescu via Digitalmars-d]

On 4/12/15 10:43 AM, Dicebot wrote:

It is much better in languages that do support dedicated properties
because language rules can be used to express the same notion without
resorting to any conventions.


Wouldn't e.g. C# allow arbitrary code in getters and setters? And if so, 
wouldn't C# code need to resort to conventions to avoid surprising 
behavior? -- Andrei

Re: IMAP library

[Laeeth Isharc via Digitalmars-d-learn]

On Sunday, 12 April 2015 at 17:27:32 UTC, Jens Bauer wrote:

I won't say it's impossible, but it would be cumbersome 
processing email on an AVR.


I do miss the days of having to work within very real hardware 
constraints to achieve something only just about achievable.  But 
part of the joy goes out of it when you know that the constraint 
is artifical.



But there are Arduino using ARM Cortex-M microcontrollers too.


Yes - I meant this in a loose, everyday, form of speaking.

I can mention a couple of microcontrollers that have ethernet 
support (eg. they need a PHY of your choice and for instance a 
HanRun ethernet connector) - Examples are STM32F4xx from 
ST-Microelectronics and 
LPC1758/LPC1768/LPC1769/LPC177x/LPC178x/LPC43xx from NXP.
There are others from other vendors as well, but those above 
are quite popular and very easy to find as stand-alone chips or 
small evaluation boards.


Tku - I have one of these modules lying around, but have not had 
time to hook it up yet and don't remember which one.  We may not 
have been delivered the world of the Jetsons, but I am still 
occasionally astonished that what was only imagination in 
childhood is now almost too ordinary to be worth remarking on 
today.


One aspect of embedded stuff I haven't seen people comment on is 
that even if D is not yet there for running for regular use on 
the controller, you still need to talk to it from the host or 
control unit, and I guess D can be quite useful there.  Also for 
processing logs, and so on.


I find it particularly interesting to be able to send an email 
to a device, which can then process and do some simple things 
(eg. turn stuff on/off, send back the room temparature, etc.) - 
also a mail-robot would be quite interesting as a stand-alone 
thing.


Yes - makes sense.  (Reminded of an article on the supposed spam 
epidemic from networked 'toasters').  Email might not be the best 
protocol for this, but it is easy.



It'll be ready when it's ready. When building in small steps, 
the job often gets easier.


May you be successful with ease!


Thank you!  And v interesting what you are doing on the 
microcontroller side, too - and I hope that goes well.



Laeeth

djinni and D

[w0rp via Digitalmars-d]

I was just watching this talk, and it is really interesting.

https://www.youtube.com/watch?v=ZcBtF-JWJhM

They are working with a C++ codebase they are sharing between 
different mobile platforms by mapping it to the languages 
specific to each platform. They explain in the talk, and as 
someone who has done a little iOS and Android development myself 
I understand this, that it's important to work with the platform 
specific tools so you can get the native look and feel specific 
to each platform. So they have a tool which generates code for 
connecting the platform languages to C++ and back. The best part 
is, this translation tool is actually free software.


https://github.com/dropbox/djinni

It uses Objective-C++ to connect to iOS with Objective-C, and JNI 
to connect to Android with Java. As I was watching this talk, my 
brain moved in a direction we can call a fanciful pipe dream.


1. Finish Objective-C support in D.
2. Finish iOS ARM support for GDC or LDC.
3. Finish Android ARM support for GDC or LDC.
4. Contribute to djinni, adding D (Objective-C) - Objective-C 
and D (JNI) - Java.

5. ???
6. Profit!

I'm pretty much just posting this to put that idea in the heads 
of others.

Re: Which D IDE do you use?(survey)

[Atila Neves via Digitalmars-d]

On Friday, 10 April 2015 at 17:59:45 UTC, Ali Çehreli wrote:

On 04/10/2015 01:28 AM, Szymon Gatner wrote:

 A lot must have changed since I  used Vim few years ago then.

I hope this is not taken as an attack on Vim users but from my 
limited observations at work, users of Emacs use it powerfully 
and users of Vim use it as a simple editor.


One example is dealing with multiple files (buffers): I and all 
the other Emacs users have dozens of files open at a time, 
switching between them seemlessly. I don't even close my Emacs 
sessions for months.


On the other hand, most of the Vim users keep a single file 
open at a time. It is painful for me to watch how a Vim user 
goes to the definition of 'struct' that is already open in a .c 
file: exit Vim, change directory to 'include', start Vim again 
with the .h file. Argh! :)


Ali


It pains me to watch vim users do this. I'm an Emacs user 
myself, but I _know_ that what they're doing isn't necessary. I 
think I know more about vim than they do.


Atila

Re: Which D IDE do you use?(survey)

[Atila Neves via Digitalmars-d]

You've gotten other answers already, so I won't repeat them here. 
Refactoring wasn't really handled though, and that part depends 
on the language you're editing in Emacs. Basically, if someone 
has already written a package for that, good. If not, not so 
good. AFAIK there isn't a D one yet (I've thought of writing one 
based on DScanner/ DCD), but I get by fine in Python and C/C++ 
with rope for the former and rtags for the latter.


Emacs is a programmable environment. The answer to can I do  
in Emacs? is invariably yes. Sometimes that yes might mean 
writing elisp though. For most tasks, someone else has done it 
already.


With emacs, the problem is seldom one of possibility, but one of 
choice. First of all the default installation is horrible, 
meaning you need to customize it for it to be useful, and when 
you get to that point you need to choose which packages to 
install for all you endeavours.


As for the original point of this forum post, I use Emacs and DCD 
(with a package I maintain, ac-dcd). Autocomplete and 
jump-to-definition in a easy-to-use way, and that takes dub 
dependencies into account to boot.


In my time Vim and Emacs were just fancy text editors, not 
IDEs. Are they really IDEs now? Do they manage pojects? Do they 
autocomplete? Do they build / deploy to device with one 
keystroke? Do they support debugging (breakpoints / variable / 
registers inspection)? Do they support refactoring?


Please don't take it as an attack or trolling but if they don't 
(and I am pretty sure they don't (maybe I am wrong about 
autocoplete)) they they are not Integrated Development 
Environments.

Re: Which D IDE do you use?(survey)

[w0rp via Digitalmars-d]

On Sunday, 12 April 2015 at 19:41:10 UTC, Atila Neves wrote:

On Friday, 10 April 2015 at 17:59:45 UTC, Ali Çehreli wrote:

On 04/10/2015 01:28 AM, Szymon Gatner wrote:

 A lot must have changed since I  used Vim few years ago then.

I hope this is not taken as an attack on Vim users but from my 
limited observations at work, users of Emacs use it powerfully 
and users of Vim use it as a simple editor.


One example is dealing with multiple files (buffers): I and 
all the other Emacs users have dozens of files open at a time, 
switching between them seemlessly. I don't even close my Emacs 
sessions for months.


On the other hand, most of the Vim users keep a single file 
open at a time. It is painful for me to watch how a Vim user 
goes to the definition of 'struct' that is already open in a 
.c file: exit Vim, change directory to 'include', start Vim 
again with the .h file. Argh! :)


Ali


It pains me to watch vim users do this. I'm an Emacs user 
myself, but I _know_ that what they're doing isn't necessary. I 
think I know more about vim than they do.


Atila


I personally use GVim with tabs and alias gvim in my terminal to 
open files in a new tab. I even use :mksession from time to time 
to save my current Vim session. Often I do like to start again, 
which I also do with my web browser, because starting from just a 
few files helps me think.

Re: Which D IDE do you use?(survey)

[Ali Çehreli via Digitalmars-d]

On 04/12/2015 10:49 AM, Dicebot wrote:

 it is exactly the same experience on my dev machine and via
 remote shell

I love Emacs's tramp mode. If I can access a host, say with ssh, then I 
can open any remote file locally, without needing to do anything 
specially other than using a URL syntax.


The cool thing is that if I 'compile' when a remote buffer is open, 
Emacs compiles on the remote system! Wow! :) Likewise, if I grep when a 
remote buffer is open, it greps remotely! Shell, etc. they all work that 
way. And, I heard that there are better modes than tramp to do the same 
but I haven't needed to try them yet.


Ali

Re: UFCS overrides alias this

[anonymous via Digitalmars-d]

On Sunday, 12 April 2015 at 20:48:57 UTC, Freddy wrote:

test.d
static import std.range;
alias empty=std.range.empty;
struct A{
string b;
alias b this;
}

struct MyRange{

}
char front(MyRange);
void popFront(ref MyRange);
bool empty(MyRange);

void test(A a){
a.empty;
}

$ dmd -o- test
test.d(16): Error: overload alias 'empty' is not a variable

No idea what dmd is doing.


Looks like order matters.

This works:

bool empty(MyRange);
alias empty = std.range.empty;

This doesn't:

alias empty = std.range.empty;
bool empty(MyRange);

I don't know if there's a reason for that or if dmd is just being 
silly.

Re: Mitigating the attribute proliferation - attribute inference for functions

[Walter Bright via Digitalmars-d]

On 4/12/2015 2:55 AM, Martin Nowak wrote:

On Sunday, 12 April 2015 at 08:55:17 UTC, Walter Bright wrote:

There's still an issue of a private function being called by a template, and
the definition of that private function is compiled separately.


That's the problem of the author of that template. He would still have to
annotate that private function manually like today.


Keeping them in sync could be a problem, as the time errors are seen would be at 
link time.



But everything called by that function doesn't need to be attributed.

UFCS overrides alias this

[Freddy via Digitalmars-d]

test.d
struct A{
string b;
alias b this;
}

struct MyRange{

}
char front(MyRange);
void popFront(ref MyRange);
bool empty(MyRange);

void test(A a){
a.empty;
}

$ dmd -o- test
test.d(14): Error: function test.empty (MyRange) is not callable 
using argument types (A)


Is this intended behavior?

Re: UFCS overrides alias this

[Freddy via Digitalmars-d]

On Sunday, 12 April 2015 at 20:35:06 UTC, anonymous wrote:
string's empty is actually a function in std.array or std.range 
or something, called via UFCS. You don't import std's empty, so 
the call can't match even when the alias this is tried.


Add the following, which brings std's empty into the overload 
set, and it works:


static import std.range;
alias empty = std.range.empty;

test.d
static import std.range;
alias empty=std.range.empty;
struct A{
string b;
alias b this;
}

struct MyRange{

}
char front(MyRange);
void popFront(ref MyRange);
bool empty(MyRange);

void test(A a){
a.empty;
}

$ dmd -o- test
test.d(16): Error: overload alias 'empty' is not a variable

No idea what dmd is doing.

However it works with

private auto empty(string s){
static import std.range;
return std.range.empty(s);
}

[Issue 14363] [SDC] Error with inheriting nested classes in nested functions

[via Digitalmars-d-bugs]

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

--- Comment #8 from deadalnix deadal...@gmail.com ---
(In reply to Kenji Hara from comment #7)
 (In reply to deadalnix from comment #6)
  (In reply to Shammah Chancellor from comment #5)
   I'm not sure about that part of SDC.  I will investigate and see if
   deadalnix has some input here.
  
  SDC does it by sticking one context in the base and one context in the 
  child.
 
 It's definitely different. dmd inserts at most only one context over the all
 derived classes. The second context pointer in the child class need to be
 error in SDC.

I see no reason for this limitation.

--

Re: writefln patterns with mismatching compile-time known number of arguments

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

On Sun, Apr 12, 2015 at 02:33:03PM +, ketmar via Digitalmars-d-learn wrote:
 On Sun, 12 Apr 2015 14:18:21 +, JR wrote:
 
  But the compiler has all the pieces of information needed to see
  it's wrong, doesn't it?
 
 no, it doesn't. compiler doesn't know about `std.format.format` and
 it's special abilities. while it is possible to add such checks to the
 compiler, it will introduce interdependency between compiler and
 phobos, which is not desirable.
 
 writing CTFE `writef` version is possible without template bloat in
 binary, but it will take more memory in compile time and slows
 compilation. there were talks about having `writef!fmt(args)` in
 phobos, but nobody took that task yet.

It's not hard to write a CTFE version of writef/writeln/etc., that takes
the format argument at compile-time, since std.format itself is already
CTFE-able.

All it takes is for somebody to step up to the plate and implement it.


T

-- 
Genius may have its limitations, but stupidity is not thus handicapped. -- 
Elbert Hubbard

[Issue 14436] Optimizer fails to remove comparison loop when comparing array against null

[via Digitalmars-d-bugs]

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

--- 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/7660158f16b9c988d8ff16592ee442051ea95ffa
Fix Issue 14436 - Optimizer fails to remove comparison loop when comparing
array against null

https://github.com/D-Programming-Language/dmd/commit/6f5a3cde5778e263d53d49f4546b668652ca89ae
Merge pull request #4574 from yebblies/issue14436

Issue 14436 - Optimizer fails to remove comparison loop when comparing array
against null

--

[Issue 14436] Optimizer fails to remove comparison loop when comparing array against null

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--