Re: dmd failed or dub wrong?

[mogu via Digitalmars-d]

On Wednesday, 25 May 2016 at 03:07:31 UTC, Mike Parker wrote:

This is because dub is apparently compiling with warnings ...


Thanks for your answer. And sorry for that this thread should be 
in Learn section now i think.

Re: Preprocessing CSS

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 25 May 2016 at 00:15:48 UTC, sarn wrote:
Pulling Ruby in as a dependency for dlang.org would be sucky, 
but anything other than SASS or LESS (or something syntax 
compatible) is going to turn away a lot of contributors.  A 
homebrew macro system would make most run screaming, no matter 
how easy it is to learn.


The other side of the coin is that any additional dependency 
added to the build process is going to contribute in turning away 
people who want to contribute to Phobos and just want to see what 
the resulting docs will look like.


DDoc syntax is not that alien in comparison, and is pretty 
self-explanatory. I honestly think there is a lot of exaggeration 
in this thread. Some people complaining in this thread have never 
even contributed anything in the first place!


That said I don't see a lot of demand for preprocessing our CSS 
files at the moment.


And, to add a data point, I have never used (or needed) neither 
SASS or LESS, despite creating a lot of web apps and even working 
at a web design company for a bit. I don't feel like I'm missing 
out.

Re: SQLite-D alpha is here

[Stefan Koch via Digitalmars-d-announce]

On Saturday, 27 February 2016 at 16:08:21 UTC, Stefan Koch wrote:

Hello,

I am happy to announce the official alpha version of sqlite-d!

sqlite-d is a reader for the SQLite File Format 3.

In the future I will implement a SQL-like API on top of it.

Top-notch performance is one of the explicit goals of this 
project!


please note that currently only the ctfe branch is populated.

I welcome contributions!

Repo-URL : https://github.com/UplinkCoder/sqlite-d


Well not much has changed since I made this announcement.
By fixing a really jarring bug I had a slight performance 
regression.

But this is still the fastest SQLite reader I know of.

This project is currently on the back burner.
However in the next days there will be another significant 
performance improvement :)

Re: OpenGL with D tutorials

[dvrein via Digitalmars-d-learn]

On Sunday, 22 May 2016 at 21:21:33 UTC, Rishub Nagpal wrote:

On Sunday, 22 May 2016 at 12:13:07 UTC, ixid wrote:
What is the best OpenGL tutorial with D to use? I've tried to 
use d-gamedev-intro and opengl-tutorials and seem to get 
errors, files that are no longer included are needed (dgl)? 
and deprecation messages.


Perhaps use a C++ tutorial : http://www.learnopengl.com/
You can attempt to do the examples in D using GFM


Will be a great idea if someone making opengl tutorial for D? Or 
SFML + SDL or even Allegro? :D

Re: dmd failed or dub wrong?

[Mike Parker via Digitalmars-d]

On Tuesday, 24 May 2016 at 23:47:25 UTC, mogu wrote:
I use dub 0.9.25, DMD64 D Compiler v2.071.0. Create a minimal 
project and write the following codes in main function.


```
import std.math;
long i = 0;
i += 3.5.floor;
```

Then run dub will get a warning and dmd failed.

```
source/app.d(4,7): Warning: long += double is performing 
truncating conversion

dmd failed with exit code 1.
```



This is because dub is apparently compiling with warnings 
enabled. If you compile manually with -w, you will get the same 
result.


But build the app.d directly use dmd. It's OK. However if the 
last line of code above is `i = 3.5.floor;`. An error occurs.


```
Error: cannot implicitly convert expression (floor(3.5)) of 
type double to long

```

So what's the deal?


Take a look at [1] and you'll see that floating point types are 
not implicitly convertible to integrals, so the error is 
appropriate.


As for the += situation, because one operand is a double, the 
other will be converted to a double for the operation. Because of 
the implicit conversion rules, it may seem that an error should 
occur because of the assignment part in the +=. This isn't 
something I've really considered before, but I assume the rule is 
ignored here because += would not be very useful if you had to 
cast the result back to the original type. Where would you place 
the cast? That's why you get the truncation warning when 
compiling with -w instead of an error about implicit conversions.


https://dlang.org/spec/type.html#usual-arithmetic-conversions

Re: Code coverage in Phobos

[Seb via Digitalmars-d]

On Tuesday, 29 March 2016 at 20:50:57 UTC, Seb wrote:
Okay I see that for the long run we need a better way to handle 
the testing infrastructure :/


Actually the idea of achieving "100% coverage" is that we test 
every line at least once and don't let this testing by done by 
users.

So to refresh the discussion - there were two general ideas

1) Find "bad", "dangerous" modules, e.g.

/xml.d 64%
/zlib.d 60%
/experimental/allocator/typed.d 54%
/experimental/allocator/building_blocks/segregator.d 50%
/experimental/allocator/building_blocks/bucketizer.d 48%
/encoding.d 66%
/container/binaryheap.d 59%
/digest/digest.d 72%

2) Increase coverage for generic, platform-independent modules 
like std.algorithm to 100%


I know it's a lot of work, but shouldn't that make our jobs us 
maintainers easier (=catch the bugs before you have to fix 
them?). Therefore I am bumping this ;-)

Re: Dynamic Bindings to libui (x-platform GUI)

[Mike Parker via Digitalmars-d-announce]

On Tuesday, 24 May 2016 at 20:52:54 UTC, extrawurst wrote:

Hey folks,




So here are the inofficial Derelict Bindings to it: 
https://github.com/Extrawurst/DerelictLibui


I tested them on both windows and mac osx so far. Any linux 
user is welcome to test it on there aswell.


Let me know if you find any issues.

-Stephan


Cool. I've got this project on my github watchlist and have had a 
Derelict binding on my TODO list. I was waiting for it to get out 
of alpha status. I don't particularly like maintaining bindings 
to libraries I can' t be sure are going to keep a stable API. 
Doesn't look like it's been changing too much though.

Building dlang on Windows

[tsbockman via Digitalmars-d]

The win64.mak files included with druntime and phobos depend upon 
"Microsoft Visual Studio 10.0\VC" and "Microsoft 
SDKs\Windows\v7.0A", neither of which seems to be readily 
available for download from Microsoft's site anymore.


I tried changing the paths to point to VS 14.0 and Windows SDK 
7.1A, but the build failed:



// druntime win64.mak:
src\core\stdc\errno.c(12): fatal error C1083: Cannot open 
include file: 'errno.h': No such file or directory


// phobos win64.mak:
adler32.obj : fatal error LNK1107: invalid or corrupt file: 
cannot read at 0x517


1. How can I get the build working on my own system?
2. Isn't it about time to upgrade to a newer version of these 
dependencies?

[Issue 16072] New: std.container.binaryheap should be extendable for arrays

[via Digitalmars-d-bugs]

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

  Issue ID: 16072
   Summary: std.container.binaryheap should be extendable for
arrays
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

I don't see any reason why the following shouldn't work:

import std.container.binaryheap;
auto q = heapify!"a > b"([1, 4, 5]);
q.insert(2);

--

Re: Dynamic Bindings to libui (x-platform GUI)

[Basile B. via Digitalmars-d-announce]

On Wednesday, 25 May 2016 at 00:56:00 UTC, Zekereth wrote:
I had to comment out instances of uiControlVerifyDestroy on 
Linux. Seems libui was updated and removed/moved that function:


Removed uiControlVerifyDestroy(); that is now part of 
uiFreeControl() itself.


There's no problem when you build libui from the git submodule. 
Actually I think it's safer to do this because the C shared lib 
and the bindings are in sync.

Re: Does D supports REPL

[Carl via Digitalmars-d]

On Wednesday, 25 May 2016 at 00:12:24 UTC, Seb wrote:

On Tuesday, 24 May 2016 at 23:26:27 UTC, jmh530 wrote:

On Tuesday, 24 May 2016 at 20:44:57 UTC, Seb wrote:
Maybe we just need to move it to the dlang github namespace, 
s.t. it gets properly maintained and maybe even released with 
dmd/dub?


Integration with Jupyter would be cool as well, but I have 
basically no idea how to accomplish that.



Yep I would love to have a D Jupyter kernel - there is already 
PydMagic [1], which looks great (I haven't tried it yet), but 
all those other languages (C, C++, Scala, Java, Tcl, Brainfuck, 
Clojure, Ocaml, Erlang, Go, FSharp, Haskell and on the dynamic 
end: Python, JavaScript, CoffeeScript, Ruby, PHP, Perl, Octave, 
Bash, PowerShell, Lua, Julia, Prolog, J, etc.) [2] managed to 
get a working Jupyter kernel, so why don't we :O
I opened an issue at d-repl [3], maybe that's a good place to 
start a focussed discussion.


[1] https://github.com/DlangScience/PydMagic
[2] 
https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages

[3] https://github.com/MartinNowak/drepl/issues/37


It's worth noting that some of those Jupyter kernels are pretty 
quirky/limited. For example in the C kernel, every cell is an 
isolated program with a main function.


Which is not to say it wouldn't be great to have D integration, 
just that it's trickier than it may seem at first glance.

Re: Dynamic Bindings to libui (x-platform GUI)

[Zekereth via Digitalmars-d-announce]

On Tuesday, 24 May 2016 at 20:52:54 UTC, extrawurst wrote:

Hey folks,

libui is a crossplatform GUI lib written in C. This makes it a 
perfect candidate to be used in D!


What they say about libui on their site:
"Simple and portable (but not inflexible) GUI library in C that 
uses the native GUI technologies of each platform it supports."


find libui on github:
https://github.com/andlabs/libui

So here are the inofficial Derelict Bindings to it: 
https://github.com/Extrawurst/DerelictLibui


I tested them on both windows and mac osx so far. Any linux 
user is welcome to test it on there aswell.


Let me know if you find any issues.

-Stephan


I had to comment out instances of uiControlVerifyDestroy on 
Linux. Seems libui was updated and removed/moved that function:


Removed uiControlVerifyDestroy(); that is now part of 
uiFreeControl() itself.


Other than that it seems to work great on Linux. Thanks for this!

Re: with and checked with expression?

[Seb via Digitalmars-d]

On Tuesday, 24 May 2016 at 19:03:11 UTC, ArturG wrote:

would something like this be usefull?


A general word of advice - try to keep your post short & concise. 
It is more likely to get replies then.


Yes it would be to me, but I am not sure whether it would justify 
the rather uncommon #{} syntax. Does any language out there use 
it?


For the expression?, imho it is very useful - existence checks 
are very common. I know that at least ruby and CoffeeScript have 
it. Do you know more?

Re: Preprocessing CSS

[Seb via Digitalmars-d]

On Wednesday, 25 May 2016 at 00:15:48 UTC, sarn wrote:
Pulling Ruby in as a dependency for dlang.org would be sucky, 
but anything other than SASS or LESS (or something syntax 
compatible) is going to turn away a lot of contributors.  A 
homebrew macro system would make most run screaming, no matter 
how easy it is to learn.


Isn't there libsass (http://sass-lang.com/libsass) and
https://github.com/sass/sassc?
Shouldn't that make it rather easy to set it up as a dependency 
in the makefile?

Just `git clone` and `make`.

Re: Preprocessing CSS

[sarn via Digitalmars-d]

On Tuesday, 24 May 2016 at 18:47:57 UTC, Andrei Alexandrescu 
wrote:

On 05/24/2016 02:03 PM, Thiez wrote:

Does the
experience help someone getting a job in the industry?


Probably not, again with the same caveat. I speculate 
experience with one of the other CSS scripting engines would 
also not be very helpful in landing a job as a software 
engineer.


Not at a big company, but in small companies with maybe three 
engineers, broad skillsets are very much in demand.  Even if 
you're nominally a backend engineer, you can't say, "Sorry, I 
just don't *do* CSS."


On my second-last contract there were about two engineers on the 
project at any time, and I felt like I wrote nearly as much 
JavaScript and (SASS) CSS as Python.


Pulling Ruby in as a dependency for dlang.org would be sucky, but 
anything other than SASS or LESS (or something syntax compatible) 
is going to turn away a lot of contributors.  A homebrew macro 
system would make most run screaming, no matter how easy it is to 
learn.

Re: The D language online tour - tour.dlang.org

[Seb via Digitalmars-d-announce]

On Tuesday, 24 May 2016 at 23:11:07 UTC, Shammah Chancellor wrote:

On Tuesday, 17 May 2016 at 09:02:04 UTC, André wrote:

On Monday, 16 May 2016 at 20:39:26 UTC, Jack Stouffer wrote:
On Monday, 16 May 2016 at 18:02:29 UTC, Andrei Alexandrescu 
wrote:
This is great work, thanks! Please announce in social media 
as well! -- Andrei


Reddit: 
https://www.reddit.com/r/programming/comments/4jn6ks/the_online_d_language_tour/


Thanks!


Hey, great site! Really glad this was done.  The interface is a 
tiny bit confusing.  At the end of the welcome it's not clear 
you need to goto the "Basics" tab to continue on.  All the 
strings should probably just be tied together.


-S.


Could you point out why it is confusing to you.
Currently the text says:

"Either use the navigation panel at the bottom or press the right 
arrow key."


What could we add to avoid the confusion?

Re: Does D supports REPL

[Seb via Digitalmars-d]

On Tuesday, 24 May 2016 at 23:26:27 UTC, jmh530 wrote:

On Tuesday, 24 May 2016 at 20:44:57 UTC, Seb wrote:
Maybe we just need to move it to the dlang github namespace, 
s.t. it gets properly maintained and maybe even released with 
dmd/dub?


Integration with Jupyter would be cool as well, but I have 
basically no idea how to accomplish that.



Yep I would love to have a D Jupyter kernel - there is already 
PydMagic [1], which looks great (I haven't tried it yet), but all 
those other languages (C, C++, Scala, Java, Tcl, Brainfuck, 
Clojure, Ocaml, Erlang, Go, FSharp, Haskell and on the dynamic 
end: Python, JavaScript, CoffeeScript, Ruby, PHP, Perl, Octave, 
Bash, PowerShell, Lua, Julia, Prolog, J, etc.) [2] managed to get 
a working Jupyter kernel, so why don't we :O
I opened an issue at d-repl [3], maybe that's a good place to 
start a focussed discussion.


[1] https://github.com/DlangScience/PydMagic
[2] 
https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages

[3] https://github.com/MartinNowak/drepl/issues/37

Re: Sociomantic's short DConf2016 video

[Walter Bright via Digitalmars-d-announce]

On 5/24/2016 4:04 PM, Jonathan M Davis via Digitalmars-d-announce wrote:

Well, I guess that that answers the question of what they were going to do
with the interviews they were doing. :)


You should be pleased with your spot, well done!

Re: [RFC] List of contributors per module

[Brad Roberts via Digitalmars-d]

I enjoy a good ego stroking, but there are enough issues with the docs being cluttered and harder to 
digest than necessary already.  I'm not a big fan of adding more clutter.


On 5/24/16 12:22 PM, Seb via Digitalmars-d wrote:

Hei,

I recently made a PR to dlang.org which is aimed to show a list of all 
contributors to a Phobos
module based on the git history.
The idea is to give all the awesome people who have helped and contributed 
their earned credit!

https://github.com/dlang/dlang.org/pull/1307

A couple of questions from this PR are still open though:

1) How can we best integrate this with the author section?
- Should we move this into the header?
- Maybe a module could also have a current maintainer(s) (that is in charge of 
approving changes)

2) Should we show the avatars? They are loaded lazily, so they don't block the 
page load.
If neccessary out of privacy concerns, contribs.dlang.io could act as a proxy.

3) I would prefer to generate this information on deploy-time, but rolling a 
small (vibe.d) service
was a lot easier than integrating this properly in the current Makefile. Maybe 
once we migrate to
ddox this would be easier?

dmd failed or dub wrong?

[mogu via Digitalmars-d]

I use dub 0.9.25, DMD64 D Compiler v2.071.0. Create a minimal 
project and write the following codes in main function.


```
import std.math;
long i = 0;
i += 3.5.floor;
```

Then run dub will get a warning and dmd failed.

```
source/app.d(4,7): Warning: long += double is performing 
truncating conversion

dmd failed with exit code 1.
```

But build the app.d directly use dmd. It's OK. However if the 
last line of code above is `i = 3.5.floor;`. An error occurs.


```
Error: cannot implicitly convert expression (floor(3.5)) of type 
double to long

```

So what's the deal?

Re: Operator overloading through UFCS doesn't work

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, May 24, 2016 23:19:32 Elie Morisse via Digitalmars-d-learn wrote:
> On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
> > Afaik free-function operator overloads (but not in the context
> > of UFCS) were considered and turned down because D did not want
> > to get amidst discussions about adding Koenig lookup. UFCS does
> > not do Koenig lookup.
>
> I don't get it, aren't the current symbol lookup rules enough to
> make free function operator overloads useful? To me it looks like
> they are.
>
> Sorry for digging up this thread, just getting irritated by a
> restriction that seems pointless and arbitrary.
>
> Overloaded operators would suffer from the same potential abuses
> other methods are subjected to if UFCS was enabled, nothing more
> as far as I can see.

If UFCS doesn't work, because there are two free functions with the same
name which take the same arguments, then you can differentiate between them
by not using UFCS and using their full import paths, or you can alias them
so that they don't have the same name. Neither of those would be possible
with operator overloading. If overloaded operators were allowed as free
functions, then if there were ever a symbol conflict, you'd be screwed.

- Jonathan M Davis

Re: Does D supports REPL

[jmh530 via Digitalmars-d]

On Tuesday, 24 May 2016 at 20:44:57 UTC, Seb wrote:
Maybe we just need to move it to the dlang github namespace, 
s.t. it gets properly maintained and maybe even released with 
dmd/dub?


Integration with Jupyter would be cool as well, but I have 
basically no idea how to accomplish that.

Re: Operator overloading through UFCS doesn't work

[Elie Morisse via Digitalmars-d-learn]

On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
Afaik free-function operator overloads (but not in the context 
of UFCS) were considered and turned down because D did not want 
to get amidst discussions about adding Koenig lookup. UFCS does 
not do Koenig lookup.


I don't get it, aren't the current symbol lookup rules enough to 
make free function operator overloads useful? To me it looks like 
they are.


Sorry for digging up this thread, just getting irritated by a 
restriction that seems pointless and arbitrary.


Overloaded operators would suffer from the same potential abuses 
other methods are subjected to if UFCS was enabled, nothing more 
as far as I can see.

Re: Release DUB 0.9.25, new logo and updated website design

[Adrian Matoga via Digitalmars-d-announce]

On Tuesday, 24 May 2016 at 22:59:24 UTC, Adrian Matoga wrote:

(...)
1. The font is much thinner than on dlang.org main site


PR: https://github.com/dlang/dub-registry/pull/156

3. Clicking the top-left dub logo directs to 
"http://code.dlang.org/packages/; which is 404.


PR: https://github.com/dlang/dub-registry/pull/157

Re: The D language online tour - tour.dlang.org

[Shammah Chancellor via Digitalmars-d-announce]

On Tuesday, 17 May 2016 at 09:02:04 UTC, André wrote:

On Monday, 16 May 2016 at 20:39:26 UTC, Jack Stouffer wrote:
On Monday, 16 May 2016 at 18:02:29 UTC, Andrei Alexandrescu 
wrote:
This is great work, thanks! Please announce in social media 
as well! -- Andrei


Reddit: 
https://www.reddit.com/r/programming/comments/4jn6ks/the_online_d_language_tour/


Thanks!


Hey, great site! Really glad this was done.  The interface is a 
tiny bit confusing.  At the end of the welcome it's not clear you 
need to goto the "Basics" tab to continue on.  All the strings 
should probably just be tied together.


-S.

Re: Is there an easy way to convert a pointer to malloc'd memory to an array?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, May 24, 2016 19:52:17 Era Scarecrow via Digitalmars-d-learn wrote:
> On Tuesday, 24 May 2016 at 18:43:22 UTC, Adam D. Ruppe wrote:
> > On Tuesday, 24 May 2016 at 18:42:41 UTC, Gary Willoughby wrote:
> >> I have a T* pointer to the start of a malloc'd chunk of
> >> memory, the type T and the number of T's stored in the chunk.
> >>
> >> Is there an efficient way of converting this information to a
> >> D array of type T[] or even T[n]?
> >
> > Slice it:
> >
> > T[] = t[0 .. n];
>
>   You can do that??? I thought slices weren't allowed on raw
> pointers. You just blew my mind away!

A dynamic array is basically just

struct Array(T)
{
size_t length;
T* ptr;
}

It can point to any memory. Much as its the default, a dynamic array does
not need to be backed by GC-allocated memory. It's just that unlike when
it's backed by GC-allocated memory, you have to worry about keeping track of
whether that memory is currently being used and when it needs to be freed,
and the dynamic array is guranteed to not have enough capacity to grow in
place, so any kind of array operation that would require growing the array
(e.g. calling reserve or appending) would be guaranteed to reallocate,
whereas when the dynamic array is backed by GC-allocated memory, it may or
may not have to reallocate when you do something like append to it or call
reserve. But aside from worrying about keeping track of its original memory,
having a dynamic array backed by malloc-ed memory is basically semantically
identical to having it backed by the GC. T[] really doesn't care what memory
it refers to. It works either way as long as the memory it refers to
continues to be valid.

- Jonathan M Davis

Re: Sociomantic's short DConf2016 video

[Jonathan M Davis via Digitalmars-d-announce]

On Tuesday, May 24, 2016 11:06:45 Leandro Lucarella via Digitalmars-d-announce 
wrote:
> For the ones that missed it (and the ones that didn't too), here
> is a short video about the conference.
>
> https://vimeo.com/167235872

Well, I guess that that answers the question of what they were going to do
with the interviews they were doing. :)

- Jonathan M Davis

Re: Release DUB 0.9.25, new logo and updated website design

[Adrian Matoga via Digitalmars-d-announce]

On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote:

(...)


The new site is cool, except a few annoyances:

1. The font is much thinner than on dlang.org main site 
(font-weight set to 300 for no good reason), and thus much harder 
to read. Using #333 for text color instead of pure black makes it 
even harder. Come on, perhaps most of us already have some sort 
of vision defects, please do not make it worse.


2. Project READMEs now render with different font which looks 
weird. (OTOH, the README alone looks nicer and easier on eyes, 
because plain Helvetica or Arial are just better suited for 
on-screen reading than clumsy serif fonts like roboto slab).


3. Clicking the top-left dub logo directs to 
"http://code.dlang.org/packages/; which is 404.


4. List of available versions for a package is broken: the most 
recent version is repeated multiple times and is not a hyperlink.


Also, some parts of READMEs are not rendered the way they are on 
github, like: nested lists, [ ]/[x] progress ticks, syntax 
highlighting in code snippets.

Re: Is there a way to make a class variable visible but constant to outsiders, but changeable (mutable) to the class itself?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, May 24, 2016 18:28:44 Meta via Digitalmars-d-learn wrote:
> On Tuesday, 24 May 2016 at 15:07:55 UTC, Jonathan M Davis wrote:
> > On Tuesday, May 24, 2016 10:10:16 Steven Schveighoffer via
> >
> > Digitalmars-d-learn wrote:
> >> A while ago, I discovered that this works.
> >>
> >> class C {
> >>
> >> union
> >> {
> >>
> >>private int _my_var;
> >>public const int my_var;
> >>
> >> }
> >> void do_something() { _my_var = 4; }
> >>
> >> }
> >
> > Yeah. That's basically what Rebindable does, though in its
> > case, it's not really allowing you to mutate any data, just
> > what the reference refers to. Regardless, it does seem like a
> > hole in the type system.
> >
> > - Jonathan M Davis
>
> I don't believe so. H. S. Teoh recently fixed a definite bug when
> you have something like:
>
> struct S
> {
>  union
>  {
>  int n1;
>  immutable int n2;
>  }
> }
>
> But I'm pretty sure the case where n2 is const was purposely not
> fixed as it doesn't break the type system. The value of a const
> variable can be changed at any time out from under you, so a
> union of a mutable and const int does not break any type system
> guarantees.

Except that int is a _value_ type, not a reference type. So, unions aside,
once you've declared

const foo = 42;

it's impossible for the value of foo to change, and there's no real
difference between

const foo = 42;

and

immutable foo = 42;

typeof(foo) will give you const in one case and immutable in the other, but
effectively, they're identical.

- Jonathan M Davis

Re: Dynamic Bindings to libui (x-platform GUI)

[Basile B. via Digitalmars-d-announce]

On Tuesday, 24 May 2016 at 20:52:54 UTC, extrawurst wrote:

Hey folks,

libui is a crossplatform GUI lib written in C. This makes it a 
perfect candidate to be used in D!


What they say about libui on their site:
"Simple and portable (but not inflexible) GUI library in C that 
uses the native GUI technologies of each platform it supports."


find libui on github:
https://github.com/andlabs/libui

So here are the inofficial Derelict Bindings to it: 
https://github.com/Extrawurst/DerelictLibui


Thx !



I tested them on both windows and mac osx so far. Any linux 
user is welcome to test it on there aswell.


Look at the pull requests ;)



Let me know if you find any issues.

-Stephan

Re: faster splitter

[qznc via Digitalmars-d]

On Tuesday, 24 May 2016 at 19:47:52 UTC, qznc wrote:
PS: Any recommendations for a Linux dissassembler? Objdump is 
ok, but some arrows for jumps would be nice.


I discovered radare2. While it is actually a debugger (like gdb), 
it includes a nice disassembler. Example view, which shows the 
loop calling std.algorithm.find repeatedly:


   |   0x00402e08,   0 |   nop [rax+rax+0x0]
  .--> 0x00402e10,   0 |   mov rdx, [rbx]
  ||   0x00402e130 |   mov rcx, [rbx+0x8]
  ||   0x00402e170 |   mov rdi, r15
  ||   0x00402e1a0 |   mov rsi, r12
  ||   0x00402e1d0 |   call 0x409160  ; 4 = 
sym._D3std9algorithm9searching34__T4fin

  ||   0x00402e220 |   mov rcx, [rbx]
  ||   0x00402e250 |   sub rcx, rax
  ||   0x00402e28,   0 |   mov [rbx+0x20], rcx
  ||   0x00402e2c,   0 |   dec ebp
  `==< 0x00402e2e0 |   jnz 0x402e10  ; 5 = 
0x00402e10

   |   0x00402e30,   0 |   lea r15, [rsp]

Note the ASCII arrow on the left! Objdump should do that. :)

Re: What is up with building DMD (et al.) on Windows?

[Jeremy DeHaan via Digitalmars-d-learn]

On Wednesday, 11 May 2016 at 14:30:44 UTC, Vladimir Panteleev 
wrote:

On Tuesday, 10 May 2016 at 04:48:23 UTC, Jeremy DeHaan wrote:
Building DMD, Phobos, and druntime on Linux is so easy and 
straight forward. It all works as expected. What's up with 
building DMD on Windows?


For historical reasons, the Windows makefiles take a different 
approach in many aspects. One important point is that they are 
limited to the feature set of the Digital Mars make 
implementation, which is extremely basic.


There is one thing that I don't understand about the Windows 
makefiles though. The Posix makefiles for druntime and phobos use 
the dmd executable found in dmd/src/ and that makes sense. It is 
the one you should be using. That is not the case for the Windows 
makefiles though. It uses the one found on PATH even though it 
would be easy to do the same as the Posix version. Why is that?

Re: Need a Faster Compressor

[Walter Bright via Digitalmars-d]

On 5/24/2016 2:34 PM, Stefan Koch wrote:

But would one ever have to be able to reconstruct the mangle ?


Symbolic debugging, and dealing with various linker errors.


templates cannot be exported nor can instanciations.
Or can they ?


Of course they can!

Re: Sociomantic's short DConf2016 video

[Bauss via Digitalmars-d-announce]

On Tuesday, 24 May 2016 at 11:06:45 UTC, Leandro Lucarella wrote:
For the ones that missed it (and the ones that didn't too), 
here is a short video about the conference.


https://vimeo.com/167235872


Looks amazing. I hope, I can get to join the next one! :)

Re: Sociomantic's short DConf2016 video

[Nick B via Digitalmars-d-announce]

On Tuesday, 24 May 2016 at 12:36:44 UTC, Bastiaan Veelo wrote:
On Tuesday, 24 May 2016 at 11:06:45 UTC, Leandro Lucarella 
wrote:
For the ones that missed it (and the ones that didn't too), 
here is a short video about the conference.


https://vimeo.com/167235872


Well done.


agreed. A well done video.

Re: Need a Faster Compressor

[Stefan Koch via Digitalmars-d]

On Tuesday, 24 May 2016 at 21:26:58 UTC, Walter Bright wrote:

On 5/24/2016 2:06 PM, Stefan Koch wrote:

A serious question, do these templates even need a mangle ?
Is anyone ever going to call them from a different module ?
I don't think you could do that because those are voldemort 
types.


Those symbols are only temporary aren't they ?


The types do exist in the compiler, and are used in template 
name generation, generating types, etc.


But would one ever have to be able to reconstruct the mangle ?
templates cannot be exported nor can instanciations.
Or can they ?

Re: Need a Faster Compressor

[Walter Bright via Digitalmars-d]

On 5/24/2016 2:06 PM, Stefan Koch wrote:

On Tuesday, 24 May 2016 at 20:39:41 UTC, Walter Bright wrote:

On 5/24/2016 1:27 PM, Guillaume Boucher wrote:

There's no reason not to use the compression in the deco name.
 Just make sure
the references are relative and you're set.


Not totally, since you'd like to refer to types that are common across deco
names.


On Tuesday, 24 May 2016 at 20:39:41 UTC, Walter Bright wrote:

A serious question, do these templates even need a mangle ?
Is anyone ever going to call them from a different module ?
I don't think you could do that because those are voldemort types.

Those symbols are only temporary aren't they ?


The types do exist in the compiler, and are used in template name generation, 
generating types, etc.

Re: What is up with building DMD (et al.) on Windows?

[Jeremy DeHaan via Digitalmars-d-learn]

On Wednesday, 11 May 2016 at 14:30:44 UTC, Vladimir Panteleev 
wrote:

On Tuesday, 10 May 2016 at 04:48:23 UTC, Jeremy DeHaan wrote:
After DMD is built, other things keep getting built by DMC. I 
get more than a few errors due to having an eof character on 
the first line of some .h files, or something like that.


I've never seen such an error. Do you have the details?



Late reply, but I was building DMD on a different computer today 
and it reminded me of this.


After dmd.exe is built, I see the command `dmd -run 
checkwhitespace` with a bunch of files following it. The errors I 
see are from this.


Error - file 'aggregate.h' contains windows line endings at line 1
Error - file 'aliasthis.h' contains windows line endings at line 1
Error - file 'arraytypes.h' contains windows line endings at line 
1


And so on.

Re: Sociomantic's short DConf2016 video

[Andy Smith via Digitalmars-d-announce]

On Tuesday, 24 May 2016 at 11:06:45 UTC, Leandro Lucarella wrote:
For the ones that missed it (and the ones that didn't too), 
here is a short video about the conference.


https://vimeo.com/167235872


Impressive . Most Impressive.

Darth Vader references aside I have to say I'm massively 
impressed with the job Sociomantic have done with DConf.


Cheers,

A.

Re: Preprocessing CSS

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 24 May 2016 at 21:02:48 UTC, Andrei Alexandrescu 
wrote:
One question is what's the audience for our css files - D 
engineers with some Web knowledge, or Web engineers with some 
or no D knowledge?


CSS isn't really *that* hard to use straight up. I wrote one of 
those fancy css nesters/macro expanders/calculator programs 
 but I don't use it 
that much because complicating the build at all isn't really 
worth it 95% of the time.


The dlang website isn't particularly complicated either. I say 
let's just keep the code simple.

Re: [RFC] List of contributors per module

[ag0aep6g via Digitalmars-d]

On 05/24/2016 09:22 PM, Seb wrote:

3) I would prefer to generate this information on deploy-time, but
rolling a small (vibe.d) service was a lot easier than integrating this
properly in the current Makefile. Maybe once we migrate to ddox this
would be easier?


I agree that this should be done when documentation is being built. The 
information doesn't change, so loading it dynamically only makes things 
slower.


Generally, I think we should be reducing the amount of JavasScript where 
possible, not do even more with JS that could be done when generating HTML.


A relatively simple, non-disruptive way towards more static generation 
would be writing small programs that generate .ddoc files, like the 
changelog builder you've got in the making [1].


So maybe we can have a little tool that generates a 
git-contributors.ddoc which contains a bunch of contributor lists as 
Ddoc macros, one per module. Then, for example, in std/stdio.d we put 
`$(GIT_CONTRIBUTORS_STD_STDIO)` somewhere. That means touching every 
single module, but there's precedent with the PHOBOSSRC macro.


Or, since the .html files actually seem to be built individually, the 
tool could generate a bunch of git-contributors-*.ddoc files, each of 
which defines just a single GIT_CONTRIBUTORS macro. Then it could be 
included in a skeleton file, or at least there less potential for 
mistakes when it's put in all source files.



[1] https://github.com/dlang/tools/pull/186

Re: Need a Faster Compressor

[Stefan Koch via Digitalmars-d]

On Tuesday, 24 May 2016 at 20:39:41 UTC, Walter Bright wrote:

On 5/24/2016 1:27 PM, Guillaume Boucher wrote:

There's no reason not to use the compression in the deco name.
 Just make sure
the references are relative and you're set.


Not totally, since you'd like to refer to types that are common 
across deco names.


On Tuesday, 24 May 2016 at 20:39:41 UTC, Walter Bright wrote:

A serious question, do these templates even need a mangle ?
Is anyone ever going to call them from a different module ?
I don't think you could do that because those are voldemort types.

Those symbols are only temporary aren't they ?

Video wrap-up of DConf

[Andrei Alexandrescu via Digitalmars-d]

So we have https://vimeo.com/167235872 which is a beautiful review of 
DConf 2016. Who can create a nice PR for the website to display text a 
la "DConf 2016 has concluded, take a look, see you next year" and the 
video? Thx! -- Andrei

Re: Preprocessing CSS

[Andrei Alexandrescu via Digitalmars-d]

On 05/24/2016 03:54 PM, Dmitry Olshansky wrote:

Designers have no idea what DDoc is and frankly better off never
learning it. Also using DDoc for CSS is stretching the tool's purpose.


Yah, that's reasonable. I'd choose ddoc over m4 though, the latter is 
very powerful but feels like the wrong kind of power. One question is 
what's the audience for our css files - D engineers with some Web 
knowledge, or Web engineers with some or no D knowledge? Historically 
it's been more of the former, but I suspect going forward we'll have 
more of the latter. -- Andrei

Re: Preprocessing CSS

[Andrei Alexandrescu via Digitalmars-d]

On 05/24/2016 05:02 PM, Andrei Alexandrescu wrote:

On 05/24/2016 03:54 PM, Dmitry Olshansky wrote:

Designers have no idea what DDoc is and frankly better off never
learning it. Also using DDoc for CSS is stretching the tool's purpose.


Yah, that's reasonable. I'd choose ddoc over m4 though, the latter is
very powerful but feels like the wrong kind of power. One question is
what's the audience for our css files - D engineers with some Web
knowledge, or Web engineers with some or no D knowledge? Historically
it's been more of the former, but I suspect going forward we'll have
more of the latter. -- Andrei


One other nice article on css: 
https://hacks.mozilla.org/2016/05/css-coding-techniques/ -- Andrei

Re: Is there an easy way to convert a pointer to malloc'd memory to an array?

[Gary Willoughby via Digitalmars-d-learn]

On Tuesday, 24 May 2016 at 18:43:22 UTC, Adam D. Ruppe wrote:

On Tuesday, 24 May 2016 at 18:42:41 UTC, Gary Willoughby wrote:
I have a T* pointer to the start of a malloc'd chunk of 
memory, the type T and the number of T's stored in the chunk.


Is there an efficient way of converting this information to a 
D array of type T[] or even T[n]?


Slice it:

T[] = t[0 .. n];


That! ...is amazing!

Re: full copies on assignment

[John Nixon via Digitalmars-d-learn]

On Tuesday, 24 May 2016 at 15:17:37 UTC, Adam D. Ruppe wrote:

On Tuesday, 24 May 2016 at 14:29:53 UTC, John Nixon wrote:
This naively doesn’t seem right because the RHS of an 
assignment should not be altered by it.


It's because the char[] being shallow copied still leads to 
mutable stuff.


What I typically do here is just add a method `dup` to the 
struct that deep copies. Then you do `CS cs = rhs.dup;` when 
you want to construct it, like you'd do with a copy of a naked 
array.


Thank you for this suggestion, perhaps a slightly neater 
workaround.

Re: faster splitter

[Andrei Alexandrescu via Digitalmars-d]

On 05/24/2016 03:47 PM, qznc wrote:


PS: Any recommendations for a Linux dissassembler? Objdump is ok, but
some arrows for jumps would be nice.


Try http://asm.dlang.org for short tests. -- Andrei

Dynamic Bindings to libui (x-platform GUI)

[extrawurst via Digitalmars-d-announce]

Hey folks,

libui is a crossplatform GUI lib written in C. This makes it a 
perfect candidate to be used in D!


What they say about libui on their site:
"Simple and portable (but not inflexible) GUI library in C that 
uses the native GUI technologies of each platform it supports."


find libui on github:
https://github.com/andlabs/libui

So here are the inofficial Derelict Bindings to it: 
https://github.com/Extrawurst/DerelictLibui


I tested them on both windows and mac osx so far. Any linux user 
is welcome to test it on there aswell.


Let me know if you find any issues.

-Stephan

Re: Newbie to D, first impressions and feedback on the 5 (and more) first minutes.

[qznc via Digitalmars-d-learn]

On Tuesday, 24 May 2016 at 15:27:45 UTC, llaine wrote:
As written in the description I'm really new to D, I discovered 
it a few weeks ago thanks to the D Conf in Berlin.


After playing around for couple of days with it, I wanted to 
share my journey with you guys on several points.


Thanks for writing this!

The "First 5 Minutes" (or days) are an important aspect, which 
the D community tries to improve. Since active D users already 
forgot about their first contact with D, the only information on 
what to improve are newbies telling their experience.

Re: Does D supports REPL

[Seb via Digitalmars-d]

On Tuesday, 24 May 2016 at 19:43:07 UTC, cym13 wrote:

On Tuesday, 24 May 2016 at 19:38:50 UTC, Tanmoy Kar wrote:

Hi,

I came to know D today while surfing for next would be popular 
language.


I did not go the forums, still just wanted to know whether D 
supports REPL (Read-Eval-Print Loop), like scala. where we can 
do a quick check of the small code on the fly ( without going 
through the full cycle of compile - linking ,  for a quick 
test).


Nice to see that it's D.   C , C++ and now one step ahead the 
brand new D.



Thanks
Tanmoy


This works https://github.com/MartinNowak/drepl although it's 
quite quirky. Fore some reasons REPLs haven't been part of the 
D philosophy in the past, I don't think it will be in the near 
future.


There is also dabble (https://github.com/callumenator/dabble), 
but it seems to be broken.


Btw I do think it's part of the D philosophy (run fast simple 
examples), but I guess it's just not top priority at the moment.
Martin's drepl had approval btw, see e.g. 
https://twitter.com/d_programming/status/433715152655884288


Maybe we just need to move it to the dlang github namespace, s.t. 
it gets properly maintained and maybe even released with dmd/dub?

Re: Need a Faster Compressor

[Walter Bright via Digitalmars-d]

On 5/24/2016 1:27 PM, Guillaume Boucher wrote:

There's no reason not to use the compression in the deco name.  Just make sure
the references are relative and you're set.


Not totally, since you'd like to refer to types that are common across deco 
names.

[Issue 16071] New: Source file path and module name should match exactly

[via Digitalmars-d-bugs]

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

  Issue ID: 16071
   Summary: Source file path and module name should match exactly
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: pro.mathias.l...@gmail.com

Extract from https://dlang.org/spec/module.html :

```
The Identifiers preceding the rightmost are the Packages that the module is in.
The packages correspond to directory names in the source file path. Package
names cannot be keywords, hence the corresponding directory names cannot be
keywords, either. 
```

According to this definition, one cannot use a different name for the enclosing
directory, nor can one introduce virtual package namespace, e.g. :

src/foo/bar.d -> module hello.world.bar;

However this is currently allowed. Using this kind of scheme breaks separated
compilation badly, as the compiler rely on the module name for import. However,
if the module is provided via command line, the compiler will first
'importAll', and the bug won't be visible.

Even worst, the module declaration is ignored and the path is preferred in some
cases, not others:

 Import using the path 
`src/main.d -> module main; import foo.bar;`
Separate compilation: `dmd -c -o- -Isrc src/main.d` => Works
All at once : `dmd -c -o- src/main.d src/foo/bar.d` => Doesn't work


 Import using the given name 
`src/main.d -> module main; import hello.world.bar;`
Separate compilation: `dmd -c -o- -Isrc src/main.d` => Doesn't work
All at once : `dmd -c -o- src/main.d src/foo/bar.d` => Works

In addition, the specs provides the possibility to rename a file name with an
invalid identifier (e.g. `foo-bar.d` -> `module foo_bar;`), and that suffers
from the same problems.

Even DMD is affected by this, as files are e.g. `src/mars.d` but the module
name is `ddmd.mars`.

--

Re: Need a Faster Compressor

[Guillaume Boucher via Digitalmars-d]

On Tuesday, 24 May 2016 at 20:16:32 UTC, Walter Bright wrote:

On 5/24/2016 9:22 AM, Timon Gehr wrote:
Yes, it does. The compiler does not use exponential space to 
store the AST.


BTW, all types in dmd have a 'deco' string which is the AST 
linearized as a string. This string is also used to build the 
mangled names.


All the deco's are put into a hashtable, and then all types can 
be uniquely identified by their address in the hashtable. This 
reduces type comparisons to a single pointer comparison.


There's no reason not to use the compression in the deco name.  
Just make sure the references are relative and you're set.  No 
exponential space to store the AST.


Please, if you change the ABI, do it right the first time.  Some 
arbitrary compression algorithm doesn't solve the problem.

Re: Need a Faster Compressor

[Era Scarecrow via Digitalmars-d]

On Tuesday, 24 May 2016 at 20:07:02 UTC, Walter Bright wrote:

On 5/24/2016 4:55 AM, Era Scarecrow wrote:
So Walter, big question: How big before the compressor kicks 
in? What's the minimum size of the input string the compressor 
should expect?


It's currently set at 64 in the PR. But that number is just 
picked out of the air.


 64 bytes? Hmm I had the impression it was going to be far 
larger...

Re: Need a Faster Compressor

[Guillaume Boucher via Digitalmars-d]

On Monday, 23 May 2016 at 20:34:19 UTC, Walter Bright wrote:

On 5/23/2016 12:32 PM, Timon Gehr wrote:

Isn't it enough to create
references to previously embedded mangled symbols (i-th symbol 
already mangled)

while generating the mangled string?


That's been covered upthread, and VC++/g++ do that. But as 
shown, it is inadequate. There's a lot more redundancy than 
just the identifiers.


Yes, not all redundancy is covered.  However, I think all 
non-pathologic blow-ups are avoided.


Let's look at the properties of the Itanium C++ ABI mangling:

1. Guaranteed linear size name for recursive types that have 
exponential size names.
2. Compression speed can be linear to the size of the compressed 
name (i.e. no need to create an exponential garbage name just to 
compress it).
3. Decompression easy, possible without tools and speed linear to 
size of the compressed name.
4. Name retains some redundancy (in itself and when compared to 
other mangled names), well suited for a follow-up compression.


Compare this to apply some arbitrary compression algorithm to a 
name of exponential size:


1. Exponential size names remain exponential size.  Yes, up until 
the view size, some compression algorithms guarantee that, but 
they can not guarantee it in the general case.

2. Compression needs the whole name first.
3. Decompression only possible with tools.
4. Multiple mangled names can not be compressed well.

Re: Sociomantic's short DConf2016 video

[Walter Bright via Digitalmars-d-announce]

On 5/24/2016 4:06 AM, Leandro Lucarella wrote:

For the ones that missed it (and the ones that didn't too), here is a short
video about the conference.

https://vimeo.com/167235872


Sociomantic really did a great job with the conference and the video.

Re: What's wrong with my usage of std.algorithm.map in this code example?

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/24/16 4:03 PM, pineapple wrote:

I would've expected this to work, but instead I get a compile error. Is
my syntax wrong? Is this just not a case that map can handle, and I
should be doing something else?

 import std.algorithm : map;
 import std.conv : to;
 import std.stdio : writeln;
 import std.string : join;

 string test(Args...)(in Args items){
 immutable string[items.length] itemstrings =
map!(to!string)(items);


Slice assignment from range to array is not supported.

In your example, I'm curious why the efforts to specify the type? I 
think it would work with just saying auto itemstrings = ...


-Steve

Re: Idea: swap with multiple arguments

[Era Scarecrow via Digitalmars-d]

On Tuesday, 24 May 2016 at 12:22:01 UTC, H. S. Teoh wrote:
And why would you assume that it would rotate right? The 
default assumption, unless stated clearly and widely followed 
everywhere, is unclear and leads to misunderstandings.


 hmmm rotate left would be a lot easier (and cleaner) to 
implement than rotate right..? And could include tail 
optimizations? If i consider a purely functional language where 
you have access to the left-side of the argument list but not the 
right side...


//Should probably heavily incorporate move as well...
//best if only bitwise-copies are necessary to swap/rotate values
void rotate(T...)(T[] arr) {
  T temp = arr[0];

  void inner(T[] vars) {
if (arr.length > 1) {
  vars[0] = vars[1];
  inner(vars[1 .. $]);
} else {
  vars[0] = temp;
}
  }
  inner(arr);
}

Re: Idea: swap with multiple arguments

[Observer via Digitalmars-d]

On Tuesday, 24 May 2016 at 08:56:31 UTC, Jonathan M Davis wrote:
On Tuesday, May 24, 2016 02:40:24 Observer via Digitalmars-d 
wrote:
If you don't see value in it, you've neglected to learn 
PostScript.


I wasn't aware that postscript was a programming language. All 
I know about it is that it's what printers talk (sometimes), 
and I assumed that it was a protocol.


It is a full-fledged programming language, and quite nice for
manipulating graphic output to raster devices.  There was even
a Display PostScript version that targeted output to screens,
though Adobe eventually dropped support for it.  The PLRM book
(PostScript Language Reference Manual) I mentioned earlier is
the definitive description of the language.  There is also a
separate book, "Mathematical Illustrations:  A Manual of Geometry
and PostScript", by Bill Casselman, that describes how to use it
to draw 3D models.

Anyway, with respect to the current discussion, PostScript has a
rich and elegant set of operators, to handle stack operations,
math operations, array operations, dictionary (hash) operations,
string operations, control operations, file operations, graphics
operations (of course), and more.  It's definitely worth a look
for inspiration both when designing language features, and for
the clarity of its documentation (the PLRM).

Re: Need a Faster Compressor

[Walter Bright via Digitalmars-d]

On 5/24/2016 9:22 AM, Timon Gehr wrote:

Yes, it does. The compiler does not use exponential space to store the AST.


BTW, all types in dmd have a 'deco' string which is the AST linearized as a 
string. This string is also used to build the mangled names.


All the deco's are put into a hashtable, and then all types can be uniquely 
identified by their address in the hashtable. This reduces type comparisons to a 
single pointer comparison.

[Issue 15941] [REG v2.069] rbtree no longer supports classes

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #3 from Steven Schveighoffer  ---
PR: https://github.com/dlang/phobos/pull/4353

Note, this will be fixed in stable, since this is a regression.

--

Re: Need a Faster Compressor

[Walter Bright via Digitalmars-d]

On 5/24/2016 4:55 AM, Era Scarecrow wrote:

 So Walter, big question: How big before the compressor kicks in? What's the
minimum size of the input string the compressor should expect?


It's currently set at 64 in the PR. But that number is just picked out of the 
air.



 I assume speed is more important than a little loss in compression.


Yes, but it's a judgement call.

Re: [RFC] List of contributors per module

[qznc via Digitalmars-d]

On Tuesday, 24 May 2016 at 19:22:31 UTC, Seb wrote:
I recently made a PR to dlang.org which is aimed to show a list 
of all contributors to a Phobos module based on the git history.
The idea is to give all the awesome people who have helped and 
contributed their earned credit!


Is this really a good idea? The file with the most authors is 
std/traits.d with 73 authors. Really list them all?


There might be duplicates, if people use different names or email 
addresses. There should be a deduplication.




Btw if you want some more stats, I have script which gives me 
this for the phobos repo:


Top Committers (of 338 authors):
Andrei Alexandrescu  1608 commits during 8 years until 2016-04-15
k-hara646 commits during 4 years until 2016-04-28
Walter Bright 643 commits during 8 years until 2016-04-25
H. S. Teoh625 commits during 4 years until 2016-05-10
Dmitry Olshansky  517 commits during 4 years until 2016-05-20
jmdavis   501 commits during 3 years until 2014-10-26
monarch dodra 421 commits during 2 years until 2015-03-12
Martin Nowak  369 commits during 4 years until 2016-05-14
Brad Roberts  340 commits during 8 years until 2016-04-16
Vladimir Panteleev323 commits during 4 years until 2016-05-18
Andrej Mitrovic   296 commits during 4 years until 2015-10-18
Jonathan M Davis  261 commits during 5 years until 2016-05-04
Ilya Yaroshenko   208 commits during 23 months until 
2016-05-15

David Nadlinger   207 commits during 5 years until 2016-05-22
David Simcha  207 commits during 2 years until 2012-10-18
Hara Kenji193 commits during 4 years until 2016-03-24
monarchdodra  181 commits during 2 years until 2014-10-10
Denis Shelomovskij179 commits during 3 years until 2015-03-06
Don Clugston  172 commits during 5 years until 2013-12-10
Tomoya Tanjo  166 commits during 2 years until 2016-03-22
Daniel Murphy 162 commits during 4 years until 2016-05-18
Steven Schveighoffer  149 commits during 5 years until 2016-05-17
Alex Rønne Petersen   147 commits during 3 years until 2014-08-04
Robert burner Schadek  134 commits during 2 years until 2016-05-02
Lars T. Kyllingstad   117 commits during 5 years until 2016-02-25
dsimcha   109 commits during 22 months until 
2012-12-08

Jack Stouffer  94 commits during 9 months until 2016-05-18
Sean Kelly 93 commits during 6 years until 2014-10-27
Михаил Страшун 90 commits during 6 months until 2015-01-26
Shin Fujishiro 79 commits during 6 months until 2010-11-18
Nick Treleaven 79 commits during 4 years until 2016-05-04
Jonas Drewsen  75 commits during 2 years until 2014-01-13
JakobOvrum 70 commits during 3 years until 2016-04-04
Peter Alexander69 commits during 3 years until 2015-07-22
 together these authors have 80+% of the commits (9530/11853)

Files with most commits:
 411 commits: std/traits.d during 8 years until 2016-05-07
 414 commits: std/string.d during 8 years until 2016-05-11
 442 commits: std/range.d  during 5 years until 2014-11-07
 475 commits: std/conv.d   during 8 years until 2016-05-14
 653 commits: std/algorithm.d  during 7 years until 2015-01-17

Files with most authors:
64 authors: std/stdio.d
66 authors: std/file.d
68 authors: std/conv.d
71 authors: std/algorithm.d
73 authors: std/traits.d

By file extension:
   .d: 511 files
   .h: 66 files
 together these make up 80+% of the files (577/697)

Re: Need a Faster Compressor

[Walter Bright via Digitalmars-d]

On 5/24/2016 12:16 PM, Anon wrote:

As if winning the compactness war while still being a symbol linkers won't have
problems with wasn't enough, this approach also avoids generating giant symbols
in the first place. Compression and/or hashing cannot do that. If D really wants
to, it can compress symbols, but it *needs* to fix this problem properly 
*first*.


Because identifiers are generated from substrings that don't know about each 
other, to do your algorithm a scan of the combined string will still be necessary.


In any case, you should be able to implement your algorithm as a replacement for 
id_compress(). How about giving it a go?

What's wrong with my usage of std.algorithm.map in this code example?

[pineapple via Digitalmars-d-learn]

I would've expected this to work, but instead I get a compile 
error. Is my syntax wrong? Is this just not a case that map can 
handle, and I should be doing something else?


import std.algorithm : map;
import std.conv : to;
import std.stdio : writeln;
import std.string : join;

string test(Args...)(in Args items){
immutable string[items.length] itemstrings = 
map!(to!string)(items);

return join(itemstrings, ", ");
}

unittest{
writeln(test(1, 2, 3, 4));
}

Re: Is there an easy way to convert a pointer to malloc'd memory to an array?

[Era Scarecrow via Digitalmars-d-learn]

On Tuesday, 24 May 2016 at 18:43:22 UTC, Adam D. Ruppe wrote:

On Tuesday, 24 May 2016 at 18:42:41 UTC, Gary Willoughby wrote:
I have a T* pointer to the start of a malloc'd chunk of 
memory, the type T and the number of T's stored in the chunk.


Is there an efficient way of converting this information to a 
D array of type T[] or even T[n]?


Slice it:

T[] = t[0 .. n];


 You can do that??? I thought slices weren't allowed on raw 
pointers. You just blew my mind away!

Re: Preprocessing CSS

[Dmitry Olshansky via Digitalmars-d]

On 23-May-2016 23:03, Andrei Alexandrescu wrote:

On 05/23/2016 02:15 PM, Dmitry Olshansky wrote:

On 23-May-2016 19:04, Andrei Alexandrescu wrote:

Found this on reddit:
http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.


I found it interesting because I found it useful to preprocess our
style.css on dlang.org with ddoc. Somehow that got lost a while ago. How
can I find the rename style.css -> style.css.dd and then back on github?
Thx! -- Andrei


Or just use SASS or LESS or any popular tool designed for CSS, no?


I looked into those and they seemed to add additional dependencies for
little else than what could be done with ddoc immediately. -- Andrei


Designers have no idea what DDoc is and frankly better off never 
learning it. Also using DDoc for CSS is stretching the tool's purpose.


--
Dmitry Olshansky

Re: Trying to get type and name at compile time

[Edwin van Leeuwen via Digitalmars-d-learn]

On Tuesday, 24 May 2016 at 18:44:45 UTC, ag0aep6g wrote:


Seems to be a problem in ApplyLeft:


import std.meta: AliasSeq, ApplyLeft;
alias addType(T, string name) = AliasSeq!(T, name);
alias addTypeInt = ApplyLeft!(addType, int);
alias FullyInstantiated = addTypeInt!"foo";


Fails with: "std/meta.d(1114): Error: cannot interpret int at 
compile time".


I've filed an issue:
https://issues.dlang.org/show_bug.cgi?id=16070



Thanks! I've worked around it for now with some recursion :)

Using `is(...)` with an AliasSeq of only types is ok. But you 
can't use it when there's a non-type in the sequence.


That makes sense.

Thanks for the help, Edwin

Re: faster splitter

[qznc via Digitalmars-d]

On Tuesday, 24 May 2016 at 10:44:12 UTC, qznc wrote:

Unfortunately, it is slower. My current measurements [0]:

$ ./benchmark 1000 10 # large haystack, few iterations
std findtook753837231
manual find took129561980
$ ./benchmark 10 1000 # small haystack, many iterations
std findtook721676721
manual find took216418870

The nested-for-loop implementation is roughly 4 times faster!

Caveat: I'm not completely sure my benchmark is fair yet.

[0] https://github.com/qznc/find-is-too-slow


Plot twist: manual find is not always faster.

My benchmark now generates random haystack and needle. Sometimes 
Phobos clearly wins. Example:


$ ./benchmark.ldc -n39 -l1 -i1
Found at 1
std findtook289529102
manual find took368958679

This is compiled with LDC, needle is 39 chars, haystack 1 
chars, and 1 iterations. "Found at 1" means the needle 
was not found.


Very often manual find wins though. Takeaway: Manual find is too 
naive. However, something slows down std find in general. More 
research needed.


PS: Any recommendations for a Linux dissassembler? Objdump is ok, 
but some arrows for jumps would be nice.

[Issue 16063] DLL projects seem to ignore DllMain, won't link

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #2 from Rainer Schuetze  ---
I noticed this too recently. This only happens when using the MS linker (also
for 32-bit DLLs), not with optlink.

--

Re: Does D supports REPL

[cym13 via Digitalmars-d]

On Tuesday, 24 May 2016 at 19:38:50 UTC, Tanmoy Kar wrote:

Hi,

I came to know D today while surfing for next would be popular 
language.


I did not go the forums, still just wanted to know whether D 
supports REPL (Read-Eval-Print Loop), like scala. where we can 
do a quick check of the small code on the fly ( without going 
through the full cycle of compile - linking ,  for a quick 
test).


Nice to see that it's D.   C , C++ and now one step ahead the 
brand new D.



Thanks
Tanmoy


This works https://github.com/MartinNowak/drepl although it's 
quite quirky. Fore some reasons REPLs haven't been part of the D 
philosophy in the past, I don't think it will be in the near 
future.

Does D supports REPL

[Tanmoy Kar via Digitalmars-d]

Hi,

I came to know D today while surfing for next would be popular 
language.


I did not go the forums, still just wanted to know whether D 
supports REPL (Read-Eval-Print Loop), like scala. where we can do 
a quick check of the small code on the fly ( without going 
through the full cycle of compile - linking ,  for a quick 
test).


Nice to see that it's D.   C , C++ and now one step ahead the 
brand new D.



Thanks
Tanmoy

Re: Newbie to D, first impressions and feedback on the 5 (and more) first minutes.

[Seb via Digitalmars-d-learn]

On Tuesday, 24 May 2016 at 18:03:17 UTC, cy wrote:
https://p0nce.github.io/d-idioms/ I wanted to mention as well, 
if you like idioms. That guy has some good ideas.


On Tuesday, 24 May 2016 at 17:36:45 UTC, Ali Çehreli wrote:
Yes, a link from that page points to a book that *can* be 
bought but it's available online as well:


It's worth buying, but the question is who's going to be 
comfortable with reading all that? It's very involved, not 
exactly a quickly crafted tutorial to "learn D in 5 minutes."


I guess it's worth pointing out that in the future (=next week) 
the menu link "Learn" and the according text section will point 
to the new tour (tour.dlang.org), which we are still working on & 
it's exactly crafted to be a "learn D in 5 minutes".

So any feedback about the tour is highly appreciated ;-)

Re: [RFC] List of contributors per module

[Seb via Digitalmars-d]

On Tuesday, 24 May 2016 at 19:22:31 UTC, Seb wrote:

Hei,

I recently made a PR to dlang.org which is aimed to show a list 
of all contributors to a Phobos module based on the git history.
The idea is to give all the awesome people who have helped and 
contributed their earned credit!


https://github.com/dlang/dlang.org/pull/1307

A couple of questions from this PR are still open though:

1) How can we best integrate this with the author section?
- Should we move this into the header?
- Maybe a module could also have a current maintainer(s) (that 
is in charge of approving changes)


2) Should we show the avatars? They are loaded lazily, so they 
don't block the page load.
If neccessary out of privacy concerns, contribs.dlang.io could 
act as a proxy.


3) I would prefer to generate this information on deploy-time, 
but rolling a small (vibe.d) service was a lot easier than 
integrating this properly in the current Makefile. Maybe once 
we migrate to ddox this would be easier?


I forgot if you want to see this in live, you can browse the 
output of DAutotest, e.g.:


http://dtest.thecybershadow.net/artifact/website-2ebaa0abe10645832000264a7cb6499949dee786-2b1fd6809124063d6afd0801431f016f/web/phobos/std_uri.html

[RFC] List of contributors per module

[Seb via Digitalmars-d]

Hei,

I recently made a PR to dlang.org which is aimed to show a list 
of all contributors to a Phobos module based on the git history.
The idea is to give all the awesome people who have helped and 
contributed their earned credit!


https://github.com/dlang/dlang.org/pull/1307

A couple of questions from this PR are still open though:

1) How can we best integrate this with the author section?
- Should we move this into the header?
- Maybe a module could also have a current maintainer(s) (that is 
in charge of approving changes)


2) Should we show the avatars? They are loaded lazily, so they 
don't block the page load.
If neccessary out of privacy concerns, contribs.dlang.io could 
act as a proxy.


3) I would prefer to generate this information on deploy-time, 
but rolling a small (vibe.d) service was a lot easier than 
integrating this properly in the current Makefile. Maybe once we 
migrate to ddox this would be easier?

Re: Preprocessing CSS

[Dicebot via Digitalmars-d]

On 05/23/2016 07:04 PM, Andrei Alexandrescu wrote:
> Found this on reddit:
> http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.
> I found it interesting because I found it useful to preprocess our
> style.css on dlang.org with ddoc. Somehow that got lost a while ago. How
> can I find the rename style.css -> style.css.dd and then back on github?
> Thx! -- Andrei

DDOC is the single worst thing in D tooling. I wish there was less of
it, not more.

Re: Need a Faster Compressor

[Anon via Digitalmars-d]

On Tuesday, 24 May 2016 at 16:22:56 UTC, Timon Gehr wrote:
It's _exponential_ growth. We don't even want to spend the time 
and memory required to generate the strings.


The reason we have this discussion is that the worst case isn't 
rare enough to make this argument. Why compress in the first 
place if mangled names don't grow large in practice?


Since Walter is evidently still having a hard time understanding 
this, I've done a few more pathological cases, comparing LZ4 to 
Back Referencing Named Types.


For BRNT I manually replaced struct names in the mangling with 
N numeric identifiers for all but one of their 
appearances, to simulate what could actually be done by the 
compiler. No other mangling changes (e.g., for eponymous 
templates or hidden types) were applied.


auto foo(T)(T x)
{
static struct Vold { T payload; }
return Vold(x);
}


At a chain of length 10:
foo(5).foo.foo.foo.foo.foo.foo.foo.foo.foo

current: Generate a 57_581 byte symbol
lz4 -9: Generate a 57_581 byte symbol, then compress it to 412 
bytes
lzma -9: Generate a 57_581 byte symbol, then compress it to 239 
bytes

BRNT: Generate a 332 byte symbol


Upping it to twelve levels:
foo(5).foo.foo.foo.foo.foo.foo.foo.foo.foo.foo.foo

current: Generate a 230_489 byte symbol
lz4 -9: Generate a 230_489 byte symbol, then compress it to 1128 
bytes
lzma -9: Generate a 230_489 byte symbol, then compress it to 294 
bytes

BRNT: Generate a 393 byte symbol

Upping it to fourteen levels:

I'm too lazy to do more manual BRNT, so beyond this point its 
numbers are estimated based on the previously established fact 
that BRNT symbols grow linearly.


current: Generate a 922_127 byte symbol
lz4 -9: Generate a 922_127 byte symbol, then compress it to 4012 
bytes

lzma -9: Generate a 922_127 byte symbol, compress it to 422 bytes
BRNT: Generate a ~457 byte symbol

Upping it to sixteen levels:

current: Generate a 3_688_679 byte symbol
lz4 -9: Generate a 3_688_679 byte symbol, then compress it to 
15535 bytes
lzma -9: Generate a 3_688_679 byte symbol, then compress it to 
840 bytes

BRNT: Generate a ~527 byte symbol



I want to let that sink in: in the general case, BRNT beats even 
**LZMA**.




As if winning the compactness war while still being a symbol 
linkers won't have problems with wasn't enough, this approach 
also avoids generating giant symbols in the first place. 
Compression and/or hashing cannot do that. If D really wants to, 
it can compress symbols, but it *needs* to fix this problem 
properly *first*.

Re: code.dlang.org packages' docs

[Seb via Digitalmars-d]

On Tuesday, 24 May 2016 at 15:26:31 UTC, Luís Marques wrote:

Hi,

code.dlang.org could be improved with regards to the 
documentation of the packages it lists.


As low hanging fruit, I suggest that the package information 
table (version, home page, repo, license, etc.) be extended 
with the documentation URL of the respective package, instead 
of it being an ad hoc part of the Readme section, and often 
missing.


More generally, I would suggest that code.dlang.org also served 
as a centralized repository of the documentation of each 
package. For instance, the package serial-port 
() links to 
. This is 
another site, with a different visual style and doc generator 
layout, another possible point of failure, etc. I realize it 
might be challenging to generate and host all the docs at 
code.dlang.org, but I feel it would create a more 
"professional", unified and pleasant experience.


What you are proposing is sth. like "Documentation as a service".
E.g. every time I push a new git tag, please run ddoc/ddox on my 
codebase and store the result. It shouldn't be difficult to 
implement and would be a huge gain for the community. Afaik other 
languages also have this:


http://www.rubydoc.info/
https://github.com/coffeedoc/codo

In terms of resources this shouldn't be a huge deal either. For 
1K and the simple documentation HTMl I would guess it's less than 
1G and as it's static it could be conveniently served via some 
Google/AWS bucket.


Moreover having the documentation for all modules at one place, 
allows the amazing opportunity to be able to search through all 
of them at once like e.g. Hoogle 
(https://www.haskell.org/hoogle/) for Haskell allows.

Re: Preprocessing CSS

[Andrei Alexandrescu via Digitalmars-d]

On 05/24/2016 03:03 PM, Seb wrote:

On Tuesday, 24 May 2016 at 18:47:57 UTC, Andrei Alexandrescu wrote:

Is ddoc intended to generate css?


Yes. Ddoc is a general preprocessing engine, much like m4 discussed in
the article I mentioned.


I had a very hard time to get used to Ddoc and all the custom D macros,
but still I think the idea of shipping such a general engine with the
compiler is great. However we should make it more powerful then. Can't
we allow CTFE in Ddoc?
This would help a lot!


That would be the domain of more advanced formatting engines such as 
ddox. I wanted to get into ddox in the "I'll give myself 15 minutes to 
do this" manner two times - even tried to redo my personal website with 
ddox. I had to give up mostly due to documentation issues and 
installation difficulties, but to my credit - :o) - I did send Sönke a 
detailed email with what happened.



I have made a couple of improvement's to the dlang.org, but they all are
JS "post-processing" hacks, because at the moment one can't do this in Ddoc
See e.g.

https://github.com/dlang/dlang.org/pull/1288 (adding anchors)
https://github.com/dlang/dlang.org/pull/1307 (showing list of contributors)

A lot of other stuff (LaTeX support, search index, grouped overview menu
etc.) would also be possible then.


Agreed, there's a lot of opportunity there.


Andrei

Re: Idea: swap with multiple arguments

[Xinok via Digitalmars-d]

On Tuesday, 24 May 2016 at 18:51:32 UTC, Andrei Alexandrescu 
wrote:

On 05/24/2016 02:48 PM, Xinok wrote:
BTW, Phobos already has a function called bringToFront which 
can
rotate/roll ranges but the interface is a bit different 
compared to

other languages.

https://dlang.org/phobos/std_algorithm_mutation.html#.bringToFront


This may be a misunderstanding. The original discussion was 
about rotating a fixed and compile-time-known number of values, 
not a range. -- Andrei


No misunderstanding; I realize that what you're proposing is a 
variadic function which takes some arbitrary set of 
variables/l-values passed by reference. The message was directed 
at those discussing rotate/roll/etc from other languages. It 
seemed nobody was aware this functionality was already available 
in Phobos though understandable since bringToFront is an unusual 
name for this function.

Re: Can no longer build OSX druntime unittest for master

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/24/16 2:11 PM, Steven Schveighoffer wrote:

I get these errors:

Undefined symbols for architecture x86_64:
   "dyld_enumerate_tlv_storage(void (dyld_tlv_states, dyld_tlv_info
const*) block_pointer)", referenced from:
   _d_dyld_getTLSRange(void*, void**, unsigned long*) in osx_tls.o
   "__d_dyld_getTLSRange", referenced from:
   _D2rt19sections_osx_x86_6413initTLSRangesFZAv in test_runner.o
   "_getErrno", referenced from:
   _D4core4stdc5errno5errnoFNbNdNiNeZi in test_runner.o
   "_setErrno", referenced from:
   _D4core4stdc5errno5errnoFNbNdNiNeiZi in test_runner.o
ld: symbol(s) not found for architecture x86_64

What happened?


env | grep CC
CC=c++

So it was building some C files as C++ files. Not my best day... I don't 
even know why my environment was set up this way!


-Steve

Re: Preprocessing CSS

[Seb via Digitalmars-d]

On Tuesday, 24 May 2016 at 18:47:57 UTC, Andrei Alexandrescu 
wrote:

Is ddoc intended to generate css?


Yes. Ddoc is a general preprocessing engine, much like m4 
discussed in the article I mentioned.


I had a very hard time to get used to Ddoc and all the custom D 
macros, but still I think the idea of shipping such a general 
engine with the compiler is great. However we should make it more 
powerful then. Can't we allow CTFE in Ddoc?

This would help a lot!

I have made a couple of improvement's to the dlang.org, but they 
all are JS "post-processing" hacks, because at the moment one 
can't do this in Ddoc

See e.g.

https://github.com/dlang/dlang.org/pull/1288 (adding anchors)
https://github.com/dlang/dlang.org/pull/1307 (showing list of 
contributors)


A lot of other stuff (LaTeX support, search index, grouped 
overview menu etc.) would also be possible then.

with and checked with expression?

[ArturG via Digitalmars-d]

ive read some discussions about some library solution for the ?. 
operator,

has there been anything added to phobos?

wouldnt a checked with expression be a more general/longer form 
of the ?. operator?


A with expression not only allows you to do unchecked/checked 
access to members but to any operation you can do on the type,
it allows method/statement cascading so that you dont have to 
return this from methods,
thereby you can combine it with function chaining without 
breaking the cascading,
and it can also be used to wrap any statement to integrate them 
into a function chain.



some example syntax:

   T t = T # { /*same as with statement*/ };   // works only with 
aggregate types, returns its input


   T t = T #aliasName {  };   // works with any type, can use 
aliasName to refer to the input like self/this, returns its input


   RetType t = T #aliasName, RetType varName {  };   // same as 
above but can change the return type


   // extention for the above, checks the input before executing 
the block,
   // if input is null/false the block does'nt get executed the 
return value will be null/T.init/RetType.init


   T t = T #? {  };

   T t = T #?aliasName {  };

   RetType t = T #?aliasName, RetType varName {  };

   // optionally

   #{ /*empty with expression*/ };  // originally not planned but 
would work like the statement expression
// mentioned in the kill the 
comma operator thread, no input no output and allways runs block


   // for single operations, the short null checked version is 
less verbose


   t?.foo = 5;   // if t is null no assignment happens,
   // same as if(t) t.foo = 5; or t#?{ foo = 5; };

   t.child = s?.child;  // if s is null, t.child will be null,
   // same as t.child = s? s.child : null; or t.child = s#?_, 
typeof(t.child) ret{ ret = child;};


   t?.child = s?.child?;   // if t is null no assignment, if s or 
s.child is null, t.child will be null,
   // same as if(t) t.child = (s && s.child)? s.child : null; or 
t#?lhs{ s#? { child#?rhs{ lhs.child = rhs; };};};


-
some examples:

   // using it with aggregate types

   struct Foo{ string name; int val; }
   class Bar{ string name; int val; }

   Foo()#{ name = "Foo"; val = 5; }.writeln;

   new Foo() #
   {
  import std.string : capitalize;
  name = someName.capitalize;
  val = 5;
   }.writeln;

   auto foo = Foo()#n{ name = "Foo"; val = 5; n.writeln; };

   new Bar#{ name = "Foo"; val = 5; }.writeln;
   auto bar = new Bar#{ name = "Foo"; val = 5; };

   auto someBar = (someCond? getBar() : new Bar) #{ name = "Bar"; 
val = 30; };

   auto someBar = getBar.or(new Bar) #{ name = "Bar"; val = 30; };

   auto dg = (string s, int v) => new Bar#{ name = s; val = v; };


   // some other random uses

   "test"#n{ import std.string; n.capitalize; }.writeln;

   66#n, string ret{ import std.conv; ret = n.to!string; }.foo();

   // writes the return value of someFun
   someFun()#n{ n == 5? doSomething() :
n == 6? doSomethingElse() : null; }.writeln;

   // writes five or six or no match
   someFun()#n, string ret{ ret = n == 5? "five" :
  n == 6? "six"  : "no match"; 
}.writeln;


   auto res = someFun.someOtherFun #n{ foreach(i; 0 .. n) 
i.writeln; }.fun(6) #n{ n.writeln; };


   //void fun(string name, int val, string, int);

   wrap!fun#{ name = "Test"; param2 = "some string";
  param3 = 66; val = 2; }();

   auto wrappedFun = wrap!fun#{
 name = "test";
 param2 = "some string";
 param3 = 66;
 val = 2;
 };
   wrappedFun.param0 = "Test";
   wrappedFun.param2 = "some other string";
   wrappedFun.val = 70;
   wrappedFun();


   // if(c.foo) c.foo.x = 55;
   c.foo?.x = 55;
   c.foo#?{ x = 55; };


   // if(someClass && someClass.child && someClass.child.child &&
   //someOtherClass && someOtherClass.child && 
someOtherClass.child.child)
   // { someClass.child.child.x = someOtherClass.child.child.x * 
2; }


   someClass?.child?.child?.x = someOtherClass?.child?.child?.x * 
2;


   someClass#?{ child#?{ child#?lhs {
  someOtherClass#?{ child#?{ child#?rhs {
  lhs.x = rhs.x * 2;
   };};};};};};


   //if(someClass) with(someClass){
   //   x = 5; x.writeln;
   //   if(child) with(child){
   //  x = 6; x.writeln;
   //  alias lhs = child;
   //  if(child) with(child){
   // if(someOtherClass) with(someOtherClass){
   //x = 10; x.writeln;
   //if(child) with(child){
   //   x = 59; x.writeln;
   //   if(child) with(child){
   //  lhs.x = x * 2;
   //  x = 44; x.writeln;
   //} } } } } }

   // same as above
   someClass #? { x = 5; x.writeln;
  child  #? { x = 6; x.writeln;
 child #?lhs {
someOtherClass #? { x = 10; x.writeln;
 

Re: Preprocessing CSS

[Wyatt via Digitalmars-d]

On Tuesday, 24 May 2016 at 18:03:38 UTC, Thiez wrote:


If D owned a scissors factory, would you use those instead of 
knives when you eat your dinner and call it "dogfooding"?


Funny enough, scissors work quite well on food.  They're safer 
and faster than knives in many case. ;)


-Wyatt

Re: Preprocessing CSS

[Jacob Carlborg via Digitalmars-d]

On 2016-05-24 19:32, Andrei Alexandrescu wrote:


Who made that silly claim? Ah, indeed I now see how what I said could be
construed like that. Allow me to amend:

"I looked into those and they seemed to add additional dependencies for
little else than what could be done with ddoc immediately."

->

"I looked into those and for our modest needs they seemed to add
additional dependencies for little else than what could be done with
ddoc immediately."


I suspect we would like to add more and more features from Sass. You 
already talked about adding if statements to Ddoc ;)


--
/Jacob Carlborg

Re: Preprocessing CSS

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 24 May 2016 at 18:47:57 UTC, Andrei Alexandrescu 
wrote:
If they're D contributors they're likely familiar with ddoc, 
and applicability to css is trivial and immediate.


A lot of D authors are at least familiar with it as inline 
documentation, but I haven't seen nearly as many use the 
standalone ddoc generator (the files with Ddoc at the top), and 
of them even fewer have probably used it for css, where the 
syntaxes kinda clash.


Probably not, again with the same caveat. I speculate 
experience with one of the other CSS scripting engines would 
also not be very helpful in landing a job as a software 
engineer.


There's a lot of job listings for front end engineers that say 
experience with those is preferred.

Re: Idea: swap with multiple arguments

[Andrei Alexandrescu via Digitalmars-d]

On 05/24/2016 02:48 PM, Xinok wrote:

BTW, Phobos already has a function called bringToFront which can
rotate/roll ranges but the interface is a bit different compared to
other languages.

https://dlang.org/phobos/std_algorithm_mutation.html#.bringToFront


This may be a misunderstanding. The original discussion was about 
rotating a fixed and compile-time-known number of values, not a range. 
-- Andrei

Re: Idea: swap with multiple arguments

[Andrei Alexandrescu via Digitalmars-d]

On 05/24/2016 02:48 PM, Xinok wrote:

One point I've never seen mentioned though is that these ideas would
probably have limited usage in the real world.


I agree. I'd be hard pressed to find a use for swap/rotate with more 
than three arguments. It's just that generalization that seems natural 
yet with limited applicability has worked nicely in a few instances in 
the past. -- Andrei

[Issue 16070] std.meta.{ApplyLeft,ApplyRight} fail with mixed type/value arguments

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from ag0ae...@gmail.com ---
https://github.com/dlang/phobos/pull/4352

--

Re: Preprocessing CSS

[Andrei Alexandrescu via Digitalmars-d]

On 05/24/2016 02:03 PM, Thiez wrote:

On Tuesday, 24 May 2016 at 17:14:24 UTC, Andrei Alexandrescu wrote:

On 05/24/2016 10:39 AM, Gary Willoughby wrote:

On Monday, 23 May 2016 at 16:04:14 UTC, Andrei Alexandrescu wrote:

Found this on reddit:
http://blog.00null.net/post/144763147991/using-gnu-m4-as-a-css-pre-processor.

I found it interesting because I found it useful to preprocess our
style.css on dlang.org with ddoc. Somehow that got lost a while ago.
How can I find the rename style.css -> style.css.dd and then back on
github? Thx! -- Andrei


I just want to throw out there that we would get more contributors to
the website were it to use industry standard tools. i.e. Sass, Less,
etc.


That'd need to be balanced with dogfooding. -- Andrei


Is ddoc intended to generate css?


Yes. Ddoc is a general preprocessing engine, much like m4 discussed in 
the article I mentioned.



Do people who have experience with css
have experience doing this with ddoc?


If they're D contributors they're likely familiar with ddoc, and 
applicability to css is trivial and immediate.



Will experience in using ddoc for
css generation help someone in projects other than D?


Probably not, but "experience" is misapplied here - we're talking about 
trivial application here.



Does the
experience help someone getting a job in the industry?


Probably not, again with the same caveat. I speculate experience with 
one of the other CSS scripting engines would also not be very helpful in 
landing a job as a software engineer.



I'm pretty sure the answer to all of these answers is "no"


That's not the case, so the jury shall ignore the consequent :o).


Andrei

Re: Idea: swap with multiple arguments

[Xinok via Digitalmars-d]

On Monday, 23 May 2016 at 20:01:08 UTC, Andrei Alexandrescu wrote:

...


I wish to make a different point which is more general regarding 
ideas like these. I see a lot of proposals to add this or that to 
the standard library and a lot of debate pursues. One point I've 
never seen mentioned though is that these ideas would probably 
have limited usage in the real world. I think a good rule of 
thumb to consider is that the standard library should be *general 
purpose* and mostly contain common functionality, with some 
exceptions of course. We should consider whether these things 
will actually see common usage or just add bloat to the standard 
library. Also consider that once it's incorporated into Phobos, 
the responsibility of maintaining that code falls on the 
community rather than those few individuals who actually desire 
that functionality.


I'm sure this feature has some useful application in some 
specific domain but I question it's value in the community at 
large. I personally see no value in having a swap which can 
rotate three or more arguments to the left, or however we may 
choose to incorporate this functionality. On the other hand, I 
use swap() with two arguments all the time; it's very common 
functionality that most of us has likely used at least a few 
times.




BTW, Phobos already has a function called bringToFront which can 
rotate/roll ranges but the interface is a bit different compared 
to other languages.



https://dlang.org/phobos/std_algorithm_mutation.html#.bringToFront

Re: Trying to get type and name at compile time

[ag0aep6g via Digitalmars-d-learn]

On 05/24/2016 06:22 PM, Edwin van Leeuwen wrote:

That's what I assumed at first.. So why does the following fail with:
cannot interpret double at compile time? I assumed staticMap would
automatically flatten the resulting AliasSeqs.

```
import std.meta : AliasSeq, ApplyLeft, staticMap;

struct Point { double x; double y; }

template addType(T,alias name)
{
 alias addType = AliasSeq!( typeof(__traits(getMember, Point, name)),
 name );
}

alias test3 = addType!( Point, "x" );

// I expected AliasSeq!(double,"x")???
pragma(msg,test3); // tuple((double), "x")

//static assert(is(test == AliasSeq!(double,"x")));
alias ts = AliasSeq!("x","y");
alias addTypeP = ApplyLeft!(addType,Point);
alias mapped = staticMap!(addTypeP,ts);

pragma(msg,mapped);

void main() {
}
```


Seems to be a problem in ApplyLeft:


import std.meta: AliasSeq, ApplyLeft;
alias addType(T, string name) = AliasSeq!(T, name);
alias addTypeInt = ApplyLeft!(addType, int);
alias FullyInstantiated = addTypeInt!"foo";


Fails with: "std/meta.d(1114): Error: cannot interpret int at compile time".

I've filed an issue:
https://issues.dlang.org/show_bug.cgi?id=16070

[...]

I thought so, but a lot of the documentation does seem to compare it
(see the example here):
https://dlang.org/library/std/meta/static_map.html


Using `is(...)` with an AliasSeq of only types is ok. But you can't use 
it when there's a non-type in the sequence.

Re: Is there an easy way to convert a pointer to malloc'd memory to an array?

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

On Tuesday, 24 May 2016 at 18:42:41 UTC, Gary Willoughby wrote:
I have a T* pointer to the start of a malloc'd chunk of memory, 
the type T and the number of T's stored in the chunk.


Is there an efficient way of converting this information to a D 
array of type T[] or even T[n]?


Slice it:

T[] = t[0 .. n];

Is there an easy way to convert a pointer to malloc'd memory to an array?

[Gary Willoughby via Digitalmars-d-learn]

I have a T* pointer to the start of a malloc'd chunk of memory, 
the type T and the number of T's stored in the chunk.


Is there an efficient way of converting this information to a D 
array of type T[] or even T[n]?

Re: Need a Faster Compressor

[deadalnix via Digitalmars-d]

On Tuesday, 24 May 2016 at 18:30:36 UTC, Stefan Koch wrote:

On Tuesday, 24 May 2016 at 16:22:56 UTC, Timon Gehr wrote:

On 24.05.2016 01:02, Walter Bright wrote:

[...]


Speed. The title of this thread is "Need a faster compressor".


[...]


No. Just increase the recursion depth by a small number of 
levels to completely kill the speedups gained by using a 
faster compression algorithm.



[...]


Yes, it does. The compiler does not use exponential space to 
store the AST.



[...]


It's _exponential_ growth. We don't even want to spend the 
time and memory required to generate the strings.



[...]


The reason we have this discussion is that the worst case 
isn't rare enough to make this argument. Why compress in the 
first place if mangled names don't grow large in practice?


I completely agree!
However such a thing will only work if dmd is used as a 
pre-linker and If we can stablize the hash.

I.E. every run of the compiler generates the same hash.


KAMOULOX!

[Issue 16070] New: std.meta.{ApplyLeft,ApplyRight} fail with mixed type/value arguments

[via Digitalmars-d-bugs]

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

  Issue ID: 16070
   Summary: std.meta.{ApplyLeft,ApplyRight} fail with mixed
type/value arguments
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Should work:

alias Templ(T, string name) = AliasSeq!(T, name);

alias PartialL = ApplyLeft!(Templ, int);
alias FullL = PartialL!"foo";

static assert(is(FullL[0] == int));
static assert(FullL[1] == "foo");

alias PartialR = ApplyRight!(Templ, "bar");
alias FullR = PartialR!int;

static assert(is(FullR[0] == int));
static assert(FullR[1] == "bar");


--

Re: Need a Faster Compressor

[Stefan Koch via Digitalmars-d]

On Tuesday, 24 May 2016 at 16:22:56 UTC, Timon Gehr wrote:

On 24.05.2016 01:02, Walter Bright wrote:

[...]


Speed. The title of this thread is "Need a faster compressor".


[...]


No. Just increase the recursion depth by a small number of 
levels to completely kill the speedups gained by using a faster 
compression algorithm.



[...]


Yes, it does. The compiler does not use exponential space to 
store the AST.



[...]


It's _exponential_ growth. We don't even want to spend the time 
and memory required to generate the strings.



[...]


The reason we have this discussion is that the worst case isn't 
rare enough to make this argument. Why compress in the first 
place if mangled names don't grow large in practice?


I completely agree!
However such a thing will only work if dmd is used as a 
pre-linker and If we can stablize the hash.

I.E. every run of the compiler generates the same hash.

Re: Is there a way to make a class variable visible but constant to outsiders, but changeable (mutable) to the class itself?

[Meta via Digitalmars-d-learn]

On Tuesday, 24 May 2016 at 15:07:55 UTC, Jonathan M Davis wrote:
On Tuesday, May 24, 2016 10:10:16 Steven Schveighoffer via 
Digitalmars-d-learn wrote:

A while ago, I discovered that this works.

class C {
union
{
   private int _my_var;
   public const int my_var;
}
void do_something() { _my_var = 4; }
}


Yeah. That's basically what Rebindable does, though in its 
case, it's not really allowing you to mutate any data, just 
what the reference refers to. Regardless, it does seem like a 
hole in the type system.


- Jonathan M Davis


I don't believe so. H. S. Teoh recently fixed a definite bug when 
you have something like:


struct S
{
union
{
int n1;
immutable int n2;
}
}

But I'm pretty sure the case where n2 is const was purposely not 
fixed as it doesn't break the type system. The value of a const 
variable can be changed at any time out from under you, so a 
union of a mutable and const int does not break any type system 
guarantees.

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

[via Digitalmars-d-bugs]

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

--- Comment #7 from Dicebot  ---
What about public imports? Previously you have stated that mixins should be
viewed identical to imports when it comes to symbol visibility/access but that
would be not true if public ones are not propagated.

--