Re: Anyone using DMD to build 32bit on OS X?

[Jacob Carlborg via Digitalmars-d]

On 2016-01-10 21:58, bitwise wrote:


Awesome!

Is there a way I can have a look at the code? I'd like to start looking
into how this will fit together with shared library support.


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

--
/Jacob Carlborg

Re: Beta D 2.070.0-b1

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-01-11 00:58, Martin Nowak wrote:


[¹]: https://github.com/MartinNowak/project_tester


Can one request for adding projects to this?

--
/Jacob Carlborg

Re: Anyone using DMD to build 32bit on OS X?

[Jacob Carlborg via Digitalmars-d]

On 2016-01-10 23:15, Guillaume Piolat wrote:


I'm using 32-bit support of DMD and I would strongly prefer if it wasn't
removed. At least staying the same as today.

The problem is that I don't control what bitness users want, because of
network effects some users still use 32-bit software. Every product in
this space is Universal Binaries with both 32-bit and 64-bit arch.


Fair enough.


You can drop OSX 10.6, which is not officially supported anyway, it
would bring compat the same as LDC. No problem as far as I'm concerned,
very few people are using 10.6 (at least that's what they say in polls).


Ok, that would mean 10.7 for 64bit and 10.6 (or whatever the current 
requirements are) for 32bit.



I have a question, does your work solves shared libraries leaking after
unload, or is it unrelated? :)


I doesn't solve the problem but it's a prerequisite for solving dynamic 
libraries. That's why I started working on this :)


--
/Jacob Carlborg

Re: [dlang.org] getting the redesign wrapped up

[Jacob Carlborg via Digitalmars-d]

On 2016-01-10 21:23, Andrei Alexandrescu wrote:


You're right, sorry about getting too enthusiastic. Should we undo? --
Andrei


That depends on how many new issues have appeared, how much trouble they 
cause and how much trouble it is do a rollback. It might be easier to 
roll forward.


--
/Jacob Carlborg

Re: Setting up dmd properly

[Robert M. Münch via Digitalmars-d-learn]

On 2016-01-11 01:47:54 +, Jason Jeffory said:


and how does one link in compiled static libraries into a dub project?

I tried adding stuff like

"lflags" : ["+C:\\MyLibs\\"],

with the .lib file in it, but that doesn't work. (I'd expect to have to 
supply the file name somewhere, at least)


Thanks.


I agree with all your other points. Telling explicit what's going on 
would help a lot in daily business. Not only for D but all compiler 
stuff. But it seems to be tradition to not do this.


Anyway, regarding the static libs. I used this on a Win64 project and it works:

   "lflags" : [
 "D:\\develop\\cairo\\cairo\\src\\release\\cairo-static.lib",
 "D:\\develop\\cairo\\libpng\\libpng.lib",
 "gdi32.lib"
   ],


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: [dlang.org] getting the redesign wrapped up

[Saurabh Das via Digitalmars-d]

On Sunday, 10 January 2016 at 22:11:51 UTC, anonymous wrote:

On 10.01.2016 19:04, Saurabh Das wrote:

What is the canonical way to report bugs on the website?


Website bugs go into the same bug tracker as compiler and 
library bugs:


https://issues.dlang.org/

Select "dlang.org" for component.

OK. I'll report issues there. Will do a thorough review later 
this week.


On mobile, the red "your code here" merges with the code 
itself.


Yeah, that's not good. I'm not sure what the best fix for this 
would be. Do you have anything in mind?


Move the "your code here" to next to the buttons would be a good 
move. Alternatively, fade out the code below and hide the "your 
code here" when the box is in focus.

Writing large data to file

[Domain via Digitalmars-d]

I am writing a split-liked tool, and want to write some large 
data (>4GB) to a single file. But this is not possible while 
using std.file.write, at least on windows. And I need dig into 
the source code to find out the reason (Windows API WriteFile 
uses DWORD as the input size). So why not call WriteFile multiple 
times inside write function, or at least return the number of 
bytes has been written, than I can append the left myself.

Re: extern(C++, ns)

[Jason Jeffory via Digitalmars-d]

On Friday, 8 January 2016 at 13:50:56 UTC, Walter Bright wrote:

On 1/8/2016 12:11 AM, Jacob Carlborg wrote:

Walter, should "ns.a()" work in the above example?


No:

1. first "ns.a" looks up "ns". Finds it in the current module, 
"main.ns".

2. Looks "a" up in "main.ns". "a" is not there. Error.

"a()" works because:

1. Look up "a" in current module. Doesn't find it.
2. Look up "a" in import "foo".
   1. doesn't find it. Look in imported scope "foo.ns". finds 
it.

3. Look up "a" in import "bar".
   1. doesn't find it. Look in imported scope "bar.ns". Doesn't 
find it.


Found only one "a" in the imports. We have da winnah!

I think name lookup rules are straightforward in D. I explain 
them over and over, for years, and nobody but me understands 
them. I find it very frustrating.


Lol, that either tells you that you've got it wrong or that your 
just too smart!


How bout this, add compiler functionality where one can 
contribute patches to dmd, and then experimentally use them?


If Manu has such capabilities, he could check his "theory" about 
quite easily(his code would just work)... at leas then everyone 
would know what the real issue is.


As much time that has been wasted arguing over this stuff, the 
feature and fix could have been implemented already.


e.g.,
dmd ... -expermental-nsmodule 




Not that it matters, my own personal logic tells me that 
namespace resolution should be consistent with D module name 
resolution. To treat all namespaces sort of coming from a global 
chunk of symbols just seems wrong. The whole point in the first 
place was to get around that. Reverting back to C like scope 
resolution for something that was suppose to get away from it 
doesn't make sense logically.


Basically there are two choices,

D Namespaces are module bound(moduleA.ns2 is different than 
moduleB.ns2) or they are not(moduleA.ns2 is the same as 
moduleB.ns2).


How bout this for a solution?

Create a new namespace keyword, _namspace or inline namespace or 
whatever, it behaves one way and the other behaves the other 
way?? This way, everyone wins Who cares about people that 
"might abuse" something... that's trying to solve a problem that 
doesn't exist yet. If people want to shoot themselves in the 
foot, let them, they will learn, and like everything else, one 
will become deprecated over time, it's nothing new.


It's like trying to prevent people from walking because someone 
once fell in a man-hole. 99.9% of people are good at walking. 
Punish them for the edge case? Maybe the issue is the man hole 
instead?


I imagine it would be easier to write a utility that parses the 
C++ code and does some magic to make it work in D than getting D 
to support something that it already does differently.

Re: extern(C++, ns)

[Manu via Digitalmars-d]

On 11 January 2016 at 11:59, Walter Bright via Digitalmars-d
 wrote:
> On 1/10/2016 5:20 PM, Manu via Digitalmars-d wrote:
>>
>> This design doesn't give us anything, and you seem to be resisting
>> making an argument for its existence. We don't need to do this, we
>> don't need to waste any more time.
>
>
> I appreciate that, but without knowing exactly what your issue is, I can't
> draw any sort of conclusion.

I can't say without spending a whole bunch of time trying to work it
out. What I can consistently show is that when I substitute
'extern(C++, ns)' for 'extern(C++)', all problems vanish (subsequent
link errors aside).
It would seem that name resolution is more complex than normal, and it
gets complicated or breaks in edge cases. Then I need to spend time
trying to understand how it is that my case is complex, and trying to
workaround it (or produce sufficient examples).
But the whole dance is pointless. If we could just recognise that the
ns scope only increases complexity, there's no good reason for it, and
there's no opt out.
Just let the symbols be exactly where they're declared like any
regular D code, and if you really want this namespace scoping feature,
can we take that as a separate enhancement request and discuss/design
it? I'd suggest it should be opt-in, since I can't imagine a case
where I would ever want that behaviour.

Re: extern(C++, ns)

[Rikki Cattermole via Digitalmars-d]

On 11/01/16 4:05 PM, Manu via Digitalmars-d wrote:

On 11 January 2016 at 12:38, Andrei Alexandrescu via Digitalmars-d
 wrote:

On 1/10/16 8:20 PM, Manu via Digitalmars-d wrote:


I'll continue to try and reduce the structure of the problem, but I
still just wish you'd remove the namespace scope. Everything would be
fixed instantly, I am certain of this.



Do you have other examples that should work but don't? Thx! -- Andrei


I only have the code I'm working on. I just don't have free time
available to me to work on home/side projects the last 6 months >_<
I used some gaps while other staff were on Christmas holidays to make
an effort at this, but that time has passed.

I'll do another pass over my code as I am able, since bugs have been
fixes the situation has changed, and I effectively need to repeat all
the experiments I've done.


Would it be possible to send the code to Walter to take a look at and 
maybe have a go with?

Re: extern(C++, ns)

[Walter Bright via Digitalmars-d]

On 1/10/2016 7:05 PM, Manu via Digitalmars-d wrote:

I'll do another pass over my code as I am able, since bugs have been
fixes the situation has changed, and I effectively need to repeat all
the experiments I've done.



Thank you. I also suggest that you come here for help sooner so you don't spend 
so much time beating your head on the wall.

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

Ok. So I tried it out and having some issues ;/ got it basically 
to compile but 2 problems:



1. I have to get dub to include the lib, not a big deal, 
shouldn't be issue if I can get the right lib in. (not sure if I 
have to do all that conversion just or not, and glfw has several 
libs for different VS versions and such... not sure what that's 
all about).


2. I had to commend out the following code dealing with the 
keyboard callback:


// Set the required callback functions
//glfwSetKeyCallback(window, _callback);

gives the error

function app.key_callback (GLFWwindow* window, int key, int 
scancode, int action, int mode) is not callable using argument 
types ()


I tried with and without address passing. I can cast though

glfwSetKeyCallback(window, cast(GLFWkeyfun)_callback);

works(no errors, at least), and if that's correct, leaves only 
the lib issue.




alternate thing I tried but gladLoadGL undefined
	//(gladLoadGL()); // optionally you can pass a loader to this 
function
	//writefln("OpenGL Version %d.%d loaded", GLVersion.major, 
GLVersion.minor);






import std.stdio;

import glad.gl.all;
import deimos.glfw.glfw3;



// Window dimensions
const GLuint WIDTH = 800, HEIGHT = 600;

void main()
{

glfwInit();
// Set all the required options for GLFW
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);

	// Create a GLFWwindow object that we can use for GLFW's 
functions
	GLFWwindow* window = glfwCreateWindow(WIDTH, HEIGHT, 
"LearnOpenGL", null, null);

glfwMakeContextCurrent(window);
if (window == null)
{
writeln("Failed to create GLFW window");
glfwTerminate();
return;
}

// Set the required callback functions
//glfwSetKeyCallback(window, _callback);

	//(gladLoadGL()); // optionally you can pass a loader to this 
function
	//writefln("OpenGL Version %d.%d loaded", GLVersion.major, 
GLVersion.minor);


/*
if (!gladLoadGLLoader(cast(GLADloadproc) glfwGetProcAddress))
{
writeln("Failed to initialize OpenGL context");
return;
}*/

// Define the viewport dimensions
glViewport(0, 0, WIDTH, HEIGHT);

// Game loop
while (!glfwWindowShouldClose(window))
{
		// Check if any events have been activated (key pressed, mouse 
moved etc.) and call corresponding response functions

glfwPollEvents();

// Render
// Clear the colorbuffer
glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);

// Swap the screen buffers
glfwSwapBuffers(window);
}

// Terminates GLFW, clearing any resources allocated by GLFW.
glfwTerminate();
return;
}


// Is called whenever a key is pressed/released via GLFW
void key_callback(GLFWwindow* window, int key, int scancode, int 
action, int mode)

{
writeln(key);
if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
glfwSetWindowShouldClose(window, GL_TRUE);
}

[Issue 11268] Cannot use non-constant CTFE pointer in an initializer

[via Digitalmars-d-bugs]

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

Elie Morisse  changed:

   What|Removed |Added

 CC||syniu...@gmail.com

--- Comment #7 from Elie Morisse  ---
Still there:

struct A {
uint d;
}

immutable A abc = { 42 };
immutable(uint)* xyz = 


Error: cannot use non-constant CTFE pointer in an initializer '(42u).d'


I need to initialize a global variable with the address of a global struct
variable member and the workaround to get past that error was to do it in a
static ctor but that's not great since this is inside a template mixin meant to
be used in tons of places.

Although I'm only interested in the address the CTFE interpreter always
"resolves" abc into the literal.

--

Re: extern(C++, ns)

[Andrei Alexandrescu via Digitalmars-d]

On 1/10/16 8:20 PM, Manu via Digitalmars-d wrote:

I'll continue to try and reduce the structure of the problem, but I
still just wish you'd remove the namespace scope. Everything would be
fixed instantly, I am certain of this.


Do you have other examples that should work but don't? Thx! -- Andrei

Re: [dlang.org] getting the redesign wrapped up

[Brad Roberts via Digitalmars-d]

On 1/10/2016 3:09 PM, Iain Buclaw via Digitalmars-d wrote:

On 10 January 2016 at 23:33, anonymous via Digitalmars-d
> wrote:

On 10.01.2016 22:18, Iain Buclaw via Digitalmars-d wrote:

I echo this, and would add a further point that you should have
tested all
sub-domains before uploading.  Release archive is not looking well.

http://downloads.dlang.org/


Uhm, where can I fix that? downloads.dlang.org
 isn't part of the of dlang.org
 repository, is it?



This is on Amazon S3.

Brad, this is your domain.  Can you have a look?  (Not sure if you
monitor your emails :-)


These days I just pay for it.  Our very capable release manager manages 
the content of it.

Hot ( https://t00ls-inbox.ru/ ) sell webmail, craiglist mailer, email leads business, rdp admin, smtp send inbox, cpanel

[smtpinbox via Digitalmars-d-announce]

SELLING PHP MAILER SEND INBOX , UNLIMITED SMTP, RDP ADMIN, 
WEBMAIL, CPANEL, SHELL C99 GOOD UPLOAD , LEADS DATABASE, EMAIL 
PASS CHECK ACCOUNT, SCAMPAGE , ACCOUNT ( ALIBABA , DATING ) , 
Craigslist Email Harvester


* Provider Webmail unlimited inbox 100% all domain
* Provider craiglist mailer with rdp admin support spam deliver 
100% , Craigslist Email Harvester Pro 2015
* Provider leads all country (electronic, alibaba, bank all 
country , paypal leads, Jobseeker leads..) . ALL  email verify 
all domain, leads fresh daily
* Sell rdp localhost inbox all domain ( RDP earthlink ,  cloud , 
comcast , verizon fresh dayly )
* Provider Shell hosting bullet support scampage avoid defecte 
phising
*  Sell scampage alibaba, yahoo, google documents, dropbox ,pdf 
email pass, boa bank, chase bank, hsbc bank... ect


List price

SMTP : $9
MAILER : $10
RDP ADMIN : $8
CPANEL: $7
WEBMAIL: $7
SHELL C99 : $5

More we can chat on Yahoo Messenger : ru.smtpinbox
Or visit our website: https://t00ls-inbox.ru/

Re: Setting up dmd properly

[Jason Jeffory via Digitalmars-d-learn]

On Monday, 11 January 2016 at 01:24:44 UTC, Jason Jeffory wrote:

On Monday, 11 January 2016 at 01:22:28 UTC, Jason Jeffory wrote:
Dmd's setup construction is a bit weird and has some difficult 
issue tracking.


How about if dmd supported, if it already doesn't, some ways 
to help the user check the configuration of dmd. It would be 
quick and easy to implement.


e.g.,

dmd -showinfo

Target Arch: x86
Libraries: C:\Mylib;C:\Another\Lib\Somewhere
Modules: C:\MyModules;
Version: 2.062
etc...

This way, issues between 64 and 32 paths can easily be seen... 
figuring out exactly what sc.ini is doing is easier, etc...


We know it is accurate because it would come from the compiler 
itself. No guessing.


Probably a dmd app could be created that does this instead? 
Basically I've ran into issues before setting up D because of 
path issues(again, the sc.ini file is pretty crappy... 
littered with duplicate symbols and different paths with 
"hacks" for different compilers and all that(it's just not 
sain)). It tends to make me hesitant dealing with dmd in some 
cases. Something that should take a min to do can take hours 
trying to track down some weird issue simply because of a 
typo... and there's no way to know exactly what the compiler 
is "seeing"... I really hope something like this already 
exists.


Also, any linked in libraries could report there format and 
such. I've had problems figuring out certain coeff libs issues 
and all that. Knowing exactly what's going on is a good thing, 
right?!?!?


and how does one link in compiled static libraries into a dub 
project?


I tried adding stuff like

"lflags" : ["+C:\\MyLibs\\"],

with the .lib file in it, but that doesn't work. (I'd expect to 
have to supply the file name somewhere, at least)


Thanks.

Re: extern(C++, ns)

[Walter Bright via Digitalmars-d]

On 1/10/2016 5:20 PM, Manu via Digitalmars-d wrote:

This design doesn't give us anything, and you seem to be resisting
making an argument for its existence. We don't need to do this, we
don't need to waste any more time.


I appreciate that, but without knowing exactly what your issue is, I can't draw 
any sort of conclusion.

Re: extern(C++, ns)

[Manu via Digitalmars-d]

On 11 January 2016 at 12:38, Andrei Alexandrescu via Digitalmars-d
 wrote:
> On 1/10/16 8:20 PM, Manu via Digitalmars-d wrote:
>>
>> I'll continue to try and reduce the structure of the problem, but I
>> still just wish you'd remove the namespace scope. Everything would be
>> fixed instantly, I am certain of this.
>
>
> Do you have other examples that should work but don't? Thx! -- Andrei

I only have the code I'm working on. I just don't have free time
available to me to work on home/side projects the last 6 months >_<
I used some gaps while other staff were on Christmas holidays to make
an effort at this, but that time has passed.

I'll do another pass over my code as I am able, since bugs have been
fixes the situation has changed, and I effectively need to repeat all
the experiments I've done.

Re: extern(C++, ns)

[Walter Bright via Digitalmars-d]

On 1/10/2016 6:54 PM, Manu via Digitalmars-d wrote:

It would seem that name resolution is more complex than normal, and it
gets complicated or breaks in edge cases. Then I need to spend time
trying to understand how it is that my case is complex, and trying to
workaround it (or produce sufficient examples).
But the whole dance is pointless. If we could just recognise that the
ns scope only increases complexity, there's no good reason for it, and
there's no opt out.
Just let the symbols be exactly where they're declared like any
regular D code, and if you really want this namespace scoping feature,
can we take that as a separate enhancement request and discuss/design
it? I'd suggest it should be opt-in, since I can't imagine a case
where I would ever want that behaviour.


I'd like to distinguish what's going wrong:

1. a bug in the implementation
2. a bug in the design
3. a bug in your mental model of how it works
4. unawareness of a feature in D designed for the situation

before throwing it all away and rebooting the design. Note that I have been able 
to help you when you've got an example illustrating the issue you're having.

Re: ndslice, using a slice in place of T[] in template parameters

[Jay Norwood via Digitalmars-d-learn]

On Monday, 11 January 2016 at 00:50:37 UTC, Ilya Yaroshenko wrote:
I will add such function. But it is not safe to do so (Slice 
can have strides not equal to 1). So it is like a hack ([0, 
0, 0])[0 .. ret.elementsCount]).


Have you made comparison between my and yours parallel versions?
https://github.com/9il/examples/blob/parallel/image_processing/median-filter/source/app.d
-- Ilya


Thanks.  No, I haven't studied it previously, but I see how you 
used the 'hack' in your code, and it works out to the statement 
below in my case.


medians[i] = median(vec, ([task,0])[0 .. bigd]);

which compiled.  It ran in the faster time without the .array 
copying.

parallel time medians msec:87

That 'hack' seems to be related to the third from below.
https://dlang.org/spec/arrays.html
b = a;
b = a[];
b = a[0 .. a.length];

[Issue 12391] DirEntries throws in foreach

[via Digitalmars-d-bugs]

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

--- Comment #3 from Timothee Cour  ---
ping on this.

I made local modifications to my git repo as this error was a blocker:

auto h = directory.length ? opendir(directory.tempCString()) : opendir(".");


if(!h) {
auto s = strerror(errno).to!string;
import std.stdio;
stderr.writeln("ERROR: ", __FILE__,":",__LINE__,"
",directory , " ",s);
return false;
}

--

[your code here]

[Saurabh Das via Digitalmars-d]

The D code part on the front page has only 2 examples currently. 
I thought we should add to that. As per the instructions, I'm 
posting one sample here for approval:


// Find anagrams of words
void main()
{
import std.stdio, std.algorithm;
string[][string] anagram_info;
File("/usr/share/dict/words")
.byLine
.each!(w => anagram_info[w.dup.sort.idup] ~= w.idup);
stdin
.byLine
.map!(l => anagram_info.get(l.sort.idup, []))
.each!writeln;
}


PS: I'm new to writing idiomatic D, so there could be 
improvements to this example. Do point them out :)

[Issue 15364] BitArray.len should be private

[via Digitalmars-d-bugs]

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

--- Comment #3 from b2.t...@gmx.com ---
If you land here because some code is broken in phobos 2.070 note that you can
fix by using the copy constructor that takes a size_t & void* (len,ptr) as
parameter.

--

Re: cairo(D) / x64 / unresolved externals / don't know why

[Benjamin Thaut via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 22:22:03 UTC, Robert M. Münch wrote:
I made to compile a bunch of libs on Win64 and got my D project 
compiled as well. Only problem left are some strange unresolved 
externals.


Linking...
dmd 
-of.dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60481557B0\webchat.exe .dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60481557B0\webchat.obj ..\vibe-d-0.7.26\lib\win-amd64\libeay32.lib ..\vibe-d-0.7.26\lib\win-amd64\ssleay32.lib ..\cairoD\cairoD.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-ft-1.0.2\lib\DerelictFT.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-util-2.0.4\lib\DerelictUtil.lib C:\Users\robby\AppData\Roaming\dub\packages\x11-1.0.9\x11.lib ..\vibe-d-0.7.26\vibe-d.lib wsock32.lib ws2_32.lib advapi32.lib user32.lib -LD:\develop\cairo\cairo\src\release\cairo-static.lib -LD:\develop\cairo\libpng\libpng.lib -Lgdi32.lib -m64 -m64 -m64 -m64 -m64 -m64 -g



cairo-static.lib(cairo-image-source.obj) : error LNK2001: 
unresolved external "__imp__hypot"


and some more missing in other .obj files:

"__imp__ctime64"
"__imp_ldiv"
"__imp_strncpy"
"__imp_rand"

IMO this all looks like msvcrt standard lib stuff so wondering 
why it's not found. Do I explicitly have to link to the msvcrt 
lib?


You should not need to link manually against msvcrt, dmd does 
this for you. You can view the linker commands that are stored 
inside a object file via microsoft dumpbin tool "dumpbin 
/DIRECTIVES your.obj".


You should check the declarations of the functions that cause a 
unresolved external error. If they have a "export" in front of 
them, remove the export. I can not think of any other reason why 
dmd would otherwise reference a import symbol. Import symbols are 
symbols used for dll linking and start with "__imp_"


Out of curiosity, why do you pass "-m64" 6 times to dmd? Once 
would be enough.


For debug builds targeting windows 64 I would also highly 
recommend using "-gc -op" instead of "-g". This will give a much 
better debugging experience in Visual Studio.

Using libraries for (Postgre)SQL for bilingual (C++ and D) project

[Eliatto via Digitalmars-d-learn]

Hello! I have a project, which consists of 2 parts: web part 
(based on vibe.d) and core part (C++/Qt 5.5.x). Core will be used 
in a shared object (c-style exported functions). Both parts must 
interact with PostgreSQL. Core dynamic library will be 
contributor to my database (INSERTS/UPDATES), while vibe.d part 
will use SELECTs for views.
Which C++ and D libraries for SQL queries should be used in order 
to minimize boilerplate code? I don't mind against ORM, using 
plain old objects (PODs) with special attributes.

BTW, I've read about https://github.com/chrishalebarnes/quill.d.

Re: Using libraries for (Postgre)SQL for bilingual (C++ and D) project

[Vadim Lopatin via Digitalmars-d-learn]

On Monday, 11 January 2016 at 07:29:02 UTC, Eliatto wrote:
Hello! I have a project, which consists of 2 parts: web part 
(based on vibe.d) and core part (C++/Qt 5.5.x). Core will be 
used in a shared object (c-style exported functions). Both 
parts must interact with PostgreSQL. Core dynamic library will 
be contributor to my database (INSERTS/UPDATES), while vibe.d 
part will use SELECTs for views.
Which C++ and D libraries for SQL queries should be used in 
order to minimize boilerplate code? I don't mind against ORM, 
using plain old objects (PODs) with special attributes.

BTW, I've read about https://github.com/chrishalebarnes/quill.d.


DDBC contains PostgreSQL driver.
https://code.dlang.org/packages/ddbc

API is similar to ODBC/JDBC.

[Issue 15541] New: ndslice package should have detailed assert messages

[via Digitalmars-d-bugs]

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

  Issue ID: 15541
   Summary: ndslice package should have detailed assert messages
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

--

[Issue 15541] ndslice package should have detailed assert messages

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|ilyayaroshe...@gmail.com

--

[Issue 15532] iota(5).sliced(2,2) should throw

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|ilyayaroshe...@gmail.com

--

[Issue 15542] New: pure function with no argument returning different values (with void-initialized static array)

[via Digitalmars-d-bugs]

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

  Issue ID: 15542
   Summary: pure function with no argument returning different
values (with void-initialized static array)
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

void main(){
  auto a1=test4;
  int[6]temp;
  auto a2=test4;
  assert(a1==a2);// passes but...
  writeln(test4);
  writeln(test4);
}

pure
int test4(){
  int[4]a=void;
  return a[0]+a[1]+a[2]+a[3];
}

// prints different valuse:
-1907472476
-1907439709

DMD64 D Compiler v2.069-devel-6b2b521

which brings the question:
should "pure" disallow void-initialized stack allocated data?

--

[Issue 15543] [ndslice] assumeSameStructure has useless flag

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|ilyayaroshe...@gmail.com

--

[Issue 12391] DirEntries throws in foreach

[via Digitalmars-d-bugs]

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com
   Severity|normal  |major

--

[Issue 13055] @nogc std.string.sformat

[via Digitalmars-d-bugs]

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #2 from Timothee Cour  ---
ping. 
just ran into this again
http://forum.dlang.org/thread/mailman.3496.1452412496.22025.digitalmar...@puremagic.com
formatted assert error messages inside nogc functions

--

[Issue 15541] [ndslice] package should have detailed assert messages

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

Summary|ndslice package should have |[ndslice] package should
   |detailed assert messages|have detailed assert
   ||messages

--

[Issue 15532] [ndslice] iota(5).sliced(2,2) should throw

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

Summary|iota(5).sliced(2,2) should  |[ndslice]
   |throw   |iota(5).sliced(2,2) should
   ||throw

--

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 09.01.2016 23:36, Jack Stouffer wrote:

On Friday, 8 January 2016 at 22:32:59 UTC, anonymous wrote:

[...]

4) Fonts

[...]

One nitpick here: can you change the function signatures to use a
monospace font (any will do really)?


Done.


Also, can you institute this change
to the function signatures as well:
https://github.com/D-Programming-Language/dlang.org/pull/1169


It's already in. You have to look at the pre-release docs. The release 
docs are built with an older dmd.


Example: 
http://d-ag0aep6g.rhcloud.com/phobos-prerelease/std_algorithm_searching.html#.commonPrefix



5) Justified Text

[...]

See my arguments here:
https://github.com/D-Programming-Language/dlang.org/pull/1152


I'm going the conservative route for now, keeping the text justified. I 
don't think hyphenation/justification is worth the troubles, but Andrei 
is the one that would have to be convinced here.



6) Red For Clickables Only?

[...]

I would take the converse of your conclusion because I have to disagree
with the use of red for links. People expect links to be blue and
underlined and darker when they are already visited; it's one of the
only design standards that exists on the web.

If you change links to be blue, then you can keep red as a highlight color.


I think that standard is pretty weak, more of a default really.

We want a red site, not a blue one. Links are the site's number one 
source of color. Blue links would make for a blue site with a red bar on 
top.


Re visited links: I removed the :visited styling without thinking too 
much about it, as I don't consider it very important. Am I wrong?

Re: flag -ignore_nogc to allow breaking nogc rules during debugging [analog to debug for pure]

[rsw0x via Digitalmars-d]

On Sunday, 10 January 2016 at 09:17:20 UTC, Timothee Cour wrote:
this would make error handling trivial and solve issues such as 
this:


FORUM:formatted assert error messages inside nogc functions 
http://forum.dlang.org/thread/CANri+EyNyrhMWGCSqZHx_vXDJFSrwhOrV=j2katz6t9-upt...@mail.gmail.com


usage:

during development:
dmd -debug -ignore_nogc other_flags foo.d
during release:
dmd other_flags foo.d

@nogc
void test(int a){

version(ignore_nogc)
  assert(a==1, text("a = ", a));
else
  assert(a==1, "a = ?");

}


is there a valid reason that debug shouldn't just ignore @nogc?
this is also an issue with contracts iirc

Function accepts const ubyte[], const char[], immutable ubyte[], immutable char[]

[zabruk70 via Digitalmars-d-learn]

Hello.

1st Novice question:

i want function, operates sometimes with char[], sometimes with 
ubyte[].

internally it works with ubyte.
i can use overloading:

void myFunc(ubyte[] arg) {...};
void myFunc(char[] arg) { ubyte[] arg2 = cast(ubyte[]) arg; ...}

It is OK. But i want 2 params (arg1, arg2),
so i need write 4 overloading functions.

I fill templated needed, can anybody show me the way?


And 2nd question:

what if additionally to written above, function shuld return 
ubyte[] or char[] ?

can compiler guess what return type need from code?
something like:

char[] cc = myFunc()
ubyte[] bb = myFunc()

Thanks.

Re: issue porting C++/glm/openGL to D/gl3n/openGL

[Johan Engelen via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 10:35:34 UTC, Johan Engelen wrote:

It's pretty strange that there is no "translate" method...


Didn't see it in the online docs, but in the source there is the 
"translate" method that you should use.

Re: issue porting C++/glm/openGL to D/gl3n/openGL

[Johan Engelen via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote:


I thought just swapping the order would fix things:

transform = transform.rotate(0.78539, vec3(0.0f, 0.0f, 1.0f));
transform = transform.translation(vec3(0.5f, -0.5f, 0.0f));

but now the square is moved to the lower right corner but no 
rotation happened?


(Disclaimer: I know absolutely nothing about gl3n.)

Note that you wrote "translatION", instead of "translatE". 
Reading the documentation, "translation" does not apply but 
instead it sets the matrix to a certain translation. See the 
difference between "rotate" and "rotation" methods. It's pretty 
strange that there is no "translate" method...

Re: flag -ignore_nogc to allow breaking nogc rules during debugging [analog to debug for pure]

[Timothee Cour via Digitalmars-d]

just more fine-grained control ... but either way.
having an escape away from nogc would be needed.


On Sun, Jan 10, 2016 at 1:56 AM, rsw0x via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Sunday, 10 January 2016 at 09:17:20 UTC, Timothee Cour wrote:
>
>> this would make error handling trivial and solve issues such as this:
>>
>> FORUM:formatted assert error messages inside nogc functions
>> http://forum.dlang.org/thread/CANri+EyNyrhMWGCSqZHx_vXDJFSrwhOrV=j2katz6t9-upt...@mail.gmail.com
>>
>> usage:
>>
>> during development:
>> dmd -debug -ignore_nogc other_flags foo.d
>> during release:
>> dmd other_flags foo.d
>>
>> @nogc
>> void test(int a){
>>
>> version(ignore_nogc)
>>   assert(a==1, text("a = ", a));
>> else
>>   assert(a==1, "a = ?");
>>
>> }
>>
>
> is there a valid reason that debug shouldn't just ignore @nogc?
> this is also an issue with contracts iirc
>

Re: flag -ignore_nogc to allow breaking nogc rules during debugging [analog to debug for pure]

[Guillaume Piolat via Digitalmars-d]

On Sunday, 10 January 2016 at 12:33:19 UTC, Timothee Cour wrote:

just more fine-grained control ... but either way.
having an escape away from nogc would be needed.



Is it a bit annoying to use, but have you aware of: 
http://p0nce.github.io/d-idioms/#Bypassing-@nogc ?

[Issue 14751] std.array.array doesn't work with ranges of immutable classes

[via Digitalmars-d-bugs]

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

Jack Applegame  changed:

   What|Removed |Added

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

--- Comment #2 from Jack Applegame  ---
Reasons of this issue and issue 15313 are the same.
Fixing issue 1513 also fixed this one.

--

flag -ignore_nogc to allow breaking nogc rules during debugging [analog to debug for pure]

[Timothee Cour via Digitalmars-d]

this would make error handling trivial and solve issues such as this:

FORUM:formatted assert error messages inside nogc functions
http://forum.dlang.org/thread/CANri+EyNyrhMWGCSqZHx_vXDJFSrwhOrV=j2katz6t9-upt...@mail.gmail.com

usage:

during development:
dmd -debug -ignore_nogc other_flags foo.d
during release:
dmd other_flags foo.d

@nogc
void test(int a){

version(ignore_nogc)
  assert(a==1, text("a = ", a));
else
  assert(a==1, "a = ?");

}

Re: Function accepts const ubyte[], const char[], immutable ubyte[], immutable char[]

[Tobi G. via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 10:10:46 UTC, zabruk70 wrote:

Hello.

1st Novice question:

i want function, operates sometimes with char[], sometimes with 
ubyte[].

internally it works with ubyte.
i can use overloading:

void myFunc(ubyte[] arg) {...};
void myFunc(char[] arg) { ubyte[] arg2 = cast(ubyte[]) arg; ...}

It is OK. But i want 2 params (arg1, arg2),
so i need write 4 overloading functions.

I fill templated needed, can anybody show me the way?


No you actually don't have to write all possible overloads.

For example:
(surely not the best solution)

import std.traits;

ubyte[] myFuncImpl(ubyte[] a, ubyte[] b)
{
return a ~ b;
}

ubyte[] myFunc(T1,T2)(T1[] a, T2[] b)
if(is(Unqual!T1 == ubyte) || is(Unqual!T1 == char)
|| is(Unqual!T2 == ubyte) || is(Unqual!T2 == char))
{
return myFuncImpl(cast(ubyte[]) a, cast(ubyte[]) b);
}



And 2nd question:

what if additionally to written above, function shuld return 
ubyte[] or char[] ?

can compiler guess what return type need from code?


No. Your function call signature would be completely the same..

The way to do this is to make the function a template and pass 
the return parameter to it.

So you're able to do something like:

auto val = myReturnFunc!int();


togrue

Re: sliced().array compatibility with parallel?

[Marc Schütz via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 01:16:43 UTC, Ilya Yaroshenko wrote:

On Saturday, 9 January 2016 at 23:20:00 UTC, Jay Norwood wrote:
I'm playing around with win32, v2.069.2 dmd and 
"dip80-ndslice": "~>0.8.8".  If I convert the 2D slice with 
.array(), should that first dimension then be compatible with 
parallel foreach?


[...]


Oh... there is no bug.
means must be shared =) :

shared double[1000] means;



I'd say, if `shared` is required, but it compiles without, then 
it's still a bug.

Re: formatted assert error messages inside nogc functions

[Timothee Cour via Digitalmars-d]

update: with @nogc @trusted pure this becomes even uglier:


@nogc @trusted pure
void test(int a){
  if(!(a==3)){
debug{
char[100]buf; //TODO:make sure big enough
// would like to use 'auto s=sformat(buf, "a = %s", a);' but not nogc:
https://issues.dlang.org/show_bug.cgi?id=13055
auto m=snprintf(buf.ptr, buf.length, "a = %d", a);
assert(m0);
assert(0, buf[0..m]);
}
else{
  assert(0);
}
  }
}


On Sat, Jan 9, 2016 at 11:54 PM, Timothee Cour 
wrote:

> Is there a better way than the example below to have an informative (ie
> formatted with runtime values) error message inside a nogc function?
>
> @nogc
> void test(int a){
>   char[100]buf; //TODO:make sure big enough
>   //auto s=sformat(buf, "a = %s", a);/// not nogc even though it accepts a
> buf
>   auto m=snprintf(buf.ptr, buf.length, "a = %d", a);
>   assert(m0);
>   assert(a==3, buf[0..m]);
> }
>
>

Re: Flipboard collection of D articles

[florin via Digitalmars-d-announce]

On Sunday, 10 January 2016 at 04:43:49 UTC, Jack Stouffer wrote:

On Friday, 8 January 2016 at 08:43:52 UTC, florin wrote:
So if there are any Flipboard users around interested in 
adding stuff there, please let me know and I will invite you 
to manage the said collection.


Sure, I'm @jackstouffer on flipboard.


Apparently flipboard is actually emailing the invitations, does 
not allow me to add by username. Here's the link generated by 
flipboard: http://flip.it/_U0Iz . Let me know if this works. 
Ideally I should have sent this in private mode, but the forums 
does not appear to support this.

[Issue 15538] final switch statement raises an exception even though all cases are covered und certain conditions

[via Digitalmars-d-bugs]

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

Johannes  changed:

   What|Removed |Added

   Severity|enhancement |major

--

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 09.01.2016 11:35, Jacob Carlborg wrote:

I'm not sure that I like that some of the headers (learn, packages) are
clickable on the main page. This also causes some icons to be black
(gray?) and some to be red. How about a link at the end of the section
with the title "Read more", or similar?


Agreed. I unlinked Learn and Packages. The links were duplicated in the 
text already anyway.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 09.01.2016 22:43, Andrei Alexandrescu wrote:

On 1/8/16 5:32 PM, anonymous wrote:

[...]

5) Justified Text

[...]

Justified font only looks good in conjunction with hyphenation. I'd say
make text justified on browsers that support css hyphenation (all but
Chrome I recall?) and left align on the others.


I.e., revert the change. Done.

By the way, in Ubuntu I don't see any hyphenation in Firefox. It works 
in Windows, though.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 09.01.2016 23:24, Vladimir Panteleev wrote:

On Friday, 8 January 2016 at 22:32:59 UTC, anonymous wrote:

[...]

Once this is merged, would you be OK with working together on updating
the forum to the new design?


Sure.


3) New Pages

[...]

Perhaps also link to (or even replace with) the wiki pages:

http://wiki.dlang.org/Articles
http://wiki.dlang.org/Development_tools


Added links. About replacing, let's see later.


6) Red For Clickables Only?

[...]

Perhaps just use bold without a color change for symbol highlighting?


That works pretty well with the new de-emphasized template constraints 
and a monospaced font (as per Jack Stouffer's request). So uncolored, 
bold symbols and red borders it is.

[Issue 15540] [ndslice] sliced ignores ReplaceArrayWithPointer for named ranges

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|ilyayaroshe...@gmail.com

--

[Issue 15543] New: [ndslice] assumeSameStructure has useless flag

[via Digitalmars-d-bugs]

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

  Issue ID: 15543
   Summary: [ndslice] assumeSameStructure has useless flag
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

--

Re: Bug in csv or byLine ?

[Keywan Ghadami via Digitalmars-d-learn]

On Friday, 8 January 2016 at 13:53:06 UTC, Guillaume Chatelet 
wrote:

On Friday, 8 January 2016 at 13:22:40 UTC, Tobi G. wrote:
On Friday, 8 January 2016 at 12:13:59 UTC, Guillaume Chatelet 
wrote:

On Friday, 8 January 2016 at 12:07:05 UTC, Tobi G. wrote:
No, sorry. Under Windows DMD v2.069.2 it works perfectly in 
both cases.


Which compiler do you use?


- DMD64 D Compiler v2.069.2 on Linux.
- LDC 0.16.1 (DMD v2.067.1, LLVM 3.7.0)


I ran it now under Linux/Ubuntu DMD64 D Compiler v2.069.2

But both still worked..

Are there some characters in your input data which are invalid 
and not displayed in the forum?

(multiple empty lines after the actual csv data for example)

togrue


Indeed there's an empty line at the end of the csv.

Interestingly enough if I try with DMD64 D Compiler v2.069, the 
Fail version runs fine but the normal version returns:
std.csv.CSVException@/usr/include/dlang/dmd/std/csv.d(1246): 
Row 3's length 1 does not match previous length of 2.
I still do not understand half of the syntax(still learning) but 
my guess is that it is a bug in the csv reader:
In 
https://github.com/D-Programming-Language/phobos/blob/67c95e6de21d5d627e3c57128b4d6e332c82f785/std/csv.d line 1020 calls popfront on the input without checking that it input is empty.
But this only happen in special case if the last line is \r\n if 
i understand it correctly.
I might be totally wrong because it does not match your 
stackstrace and i did not yet understand everything about this.

Re: What are you planning for 2016?

[bachmeier via Digitalmars-d]

On Saturday, 9 January 2016 at 21:40:02 UTC, jmh530 wrote:

On Saturday, 9 January 2016 at 19:39:44 UTC, Jakob Jenkov wrote:
The communication is the easy part. The time consuming part 
is converting R objects to D objects and vice versa. I've had 
to learn the internals of R at the same time that I've 
learned D. I've been working on it in my spare time for more 
than two years.


Would it have been possible to make a D API for data analysis 
instead? Or is that too big a job?


You could program anything in D that would run in R and it 
would probably be faster (unless the R code is using some 
optimized C/C++ code already). The issue is that D libraries 
for data analysis aren't as developed and don't have as many 
people working on them as R. You might be more productive 
calling an R library than re-writing the same functionality in 
D.


In many cases, such as graphics, speed is not an issue so a 
rewrite won't help. By integrating R inside D, an existing R user 
gives up nothing - you can choose how much to write in D vs R.

Re: sliced().array compatibility with parallel?

[Russel Winder via Digitalmars-d-learn]

On Sun, 2016-01-10 at 01:46 +, Jay Norwood via Digitalmars-d-learn
wrote:
> 
[…]
>  // processed non-parallel works ok
>  foreach( dv; dv2){
>  if(dv != dv){ // test for NaN
>  return 1;
>  }
>  }
> 
>  // calculated parallel leaves out processing of many values
>  foreach( dv; dvp){
>  if(dv != dv){ // test for NaN
>  return 1;
>  }
>  }
>  return(0);
> }

I am not convinced these "Tests for NaN" actually test for NaN. I
believe you have to use isNan(dv).

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Flipboard collection of D articles

[florin via Digitalmars-d-announce]

On Saturday, 9 January 2016 at 16:23:05 UTC, jamonahn wrote:

On Friday, 8 January 2016 at 08:43:52 UTC, florin wrote:
However as I'm programming less and less in D lately 
/@sunre/d-programming-language-e87f94iky


Florin


May I ask why / what language you are now using?  I just 
recently became a big fan of D, and just watched your 2014 
talk.  Is the network messaging framework still in use / 
maintenance?  Just getting to your github now.


Hi, I guess you got me confused :) While I did wish I'd at least 
attend a Dconf, I've never given a talk on D.


Most of my work is related to machine learning where there's no 
getting around C/C++ for CUDA and BLAS stuff. Also efficiency 
trumps pretty much everything in this field. However I am still 
very fond of D, it's the language that introduced me to generic 
programming.

Re: Function accepts const ubyte[], const char[], immutable ubyte[], immutable char[]

[zabruk70 via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 11:13:00 UTC, Tobi G. wrote:

ubyte[] myFunc(T1,T2)(T1[] a, T2[] b)


Tobi, big thanks!!!
I should learn templates...

Re: [dlang.org] getting the redesign wrapped up

[Andrei Alexandrescu via Digitalmars-d]

On 1/10/16 9:05 AM, anonymous wrote:

On 09.01.2016 22:43, Andrei Alexandrescu wrote:

On 1/8/16 5:32 PM, anonymous wrote:

[...]

5) Justified Text

[...]

Justified font only looks good in conjunction with hyphenation. I'd say
make text justified on browsers that support css hyphenation (all but
Chrome I recall?) and left align on the others.


I.e., revert the change. Done.

By the way, in Ubuntu I don't see any hyphenation in Firefox. It works
in Windows, though.


Probably we need to fix that, but it's a preexisting matter so don't 
worry about it. Do you have a PR in place yet? Thx! -- Andrei

Re: Wait-free thread communication

[David Nadlinger via Digitalmars-d]

On Saturday, 9 January 2016 at 22:44:53 UTC, Ola Fosheim Grøstad 
wrote:
Yes. But my experience from writing custom multi-single queues 
is that it can end up harder than it looks to get it working 
and efficient. […] (Intuition is often wrong in this area...)


I wholeheartedly agree with that statement. However, if one 
doesn't understand atomics well enough to correctly implement 
even a simple single-single queue, I'm not sure whether one would 
be able to correctly port an existing implementation either.


Then again, the primitives might be similar enough between C++11 
and D so that a literal translation is possible without 
understanding what is going on.


 — David

[Issue 15545] New: csv Reader line feed '\r' failure

[via Digitalmars-d-bugs]

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

  Issue ID: 15545
   Summary: csv Reader line feed '\r' failure
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: gruen_tob...@web.de

If a file uses '\r' line feeds and the last character is a linefeed 
(empty line after the data)
Csv Reader will throw a exception at the end of the file.
In case of '\n' or "\r\n" as line-feed this is not the case.

// Will fail
enum failData = 
"name, surname, age
Joe, Joker, 99\r";

enum nonFailData = 
"name, surname, age
Joe, Joker, 99\r\n";

import std.csv, std.stdio;

void main(string[] args)
{
auto reader = csvReader(failData);

foreach(entry; reader)
{
writeln(entry);
}
}


togrue

--

Re: Dub pre-build hook

[Chris Wright via Digitalmars-d-learn]

On Sun, 10 Jan 2016 16:34:51 +, Chris Wright wrote:

> Is there a way to write a pre-build hook in Dub?
> 
> Specifically, I want to write unittests in a separate package to the
> rest of my source code. This requires a module that imports all my
> unittest modules. It's safer to automatically generate this than to rely
> on my memory.
> 
> My other alternative is to write a D script that assembles this file and
> then invokes dub, and always invoke dub via that script.

I write this and immediately see preBuildCommands and preGenerateCommands. 
I'm not sure what the difference is, though. I think preBuildCommands is 
the way to go (and preGenerateCommands is maybe for generating project 
files). I'll give it a shot and see how it turns out.

Re: issue porting C++/glm/openGL to D/gl3n/openGL

[WhatMeWorry via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 10:38:07 UTC, Johan Engelen wrote:

On Sunday, 10 January 2016 at 10:35:34 UTC, Johan Engelen wrote:

It's pretty strange that there is no "translate" method...


Didn't see it in the online docs, but in the source there is 
the "translate" method that you should use.


That's it!  Excellent catch.  Thank you.

gll3n has translate(), rotate(), and scale() and matrix operators.


It also has translation(), rotation(), and scaling() which

/// Returns a translation matrix (3x3 and 4x4 matrices).
/// Returns an identity matrix with an applied rotate_axis around 
an arbitrary axis (nxn matrices, n >= 3).

/// Returns a scaling matrix (3x3 and 4x4 matrices);

Re: [dlang.org] getting the redesign wrapped up

[Saurabh Das via Digitalmars-d]

On Sunday, 10 January 2016 at 17:17:44 UTC, Andrei Alexandrescu 
wrote:

On 1/10/16 10:23 AM, anonymous wrote:

On 10.01.2016 16:11, Andrei Alexandrescu wrote:

Do you have a PR in place yet?


Here we go:
https://github.com/D-Programming-Language/dlang.org/pull/1187


...aand we're live. Congratulations and many thanks to the 
folks who worked on this! -- Andrei


Congratulations to everyone who's worked on this!

What is the canonical way to report bugs on the website? On 
mobile, the red "your code here" merges with the code itself.

Re: Flipboard collection of D articles

[Laeeth Isharc via Digitalmars-d-announce]

On Sunday, 10 January 2016 at 10:48:39 UTC, florin wrote:

On Saturday, 9 January 2016 at 16:23:05 UTC, jamonahn wrote:

On Friday, 8 January 2016 at 08:43:52 UTC, florin wrote:
However as I'm programming less and less in D lately 
/@sunre/d-programming-language-e87f94iky


Florin


May I ask why / what language you are now using?  I just 
recently became a big fan of D, and just watched your 2014 
talk.  Is the network messaging framework still in use / 
maintenance?  Just getting to your github now.


Hi, I guess you got me confused :) While I did wish I'd at 
least attend a Dconf, I've never given a talk on D.


Most of my work is related to machine learning where there's no 
getting around C/C++ for CUDA and BLAS stuff. Also efficiency 
trumps pretty much everything in this field. However I am still 
very fond of D, it's the language that introduced me to generic 
programming.


Hi Florin.

What do you make of Ilya's proposal on BLAS?  What would you need 
to be able to use D there ?  Or is it tricky as you are working 
with other libraries on top of that ?


There are people here with private CUDA libraries that may be 
open sourced in time.  (I understand that in the meantime one 
needs to get stuff done).



Laeeth

Re: sliced().array compatibility with parallel?

[Jay Norwood via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 11:21:53 UTC, Marc Schütz wrote:


I'd say, if `shared` is required, but it compiles without, then 
it's still a bug.


Yeah, probably so.  Interestingly, without 'shared' and using a 
simple assignment from a constant (means[i]= 1.0;), instead of 
assignment from the sum() evaluation, results in all the values 
being initialized, so not marking it shared doesn't protect it 
from being written from the other thread.  Anyway, the shared 
declaration doesn't seem to slow the execution, and it does make 
sense to me that it should be marked shared.

Dub pre-build hook

[Chris Wright via Digitalmars-d-learn]

Is there a way to write a pre-build hook in Dub?

Specifically, I want to write unittests in a separate package to the rest 
of my source code. This requires a module that imports all my unittest 
modules. It's safer to automatically generate this than to rely on my 
memory.

My other alternative is to write a D script that assembles this file and 
then invokes dub, and always invoke dub via that script.

Re: GDC includes from LDC

[John Colvin via Digitalmars-d]

On Sunday, 10 January 2016 at 16:23:24 UTC, Russel Winder wrote:

Iain,

Playing with the SCons tests, I am heading to the hypothesis 
that, at least on Debian Sid, if both gdc and ldc packages are 
installed, then gdc picks up the D source files from the ldc 
package in preference to the ones from the gdc package.



scons: Building targets ...
gdc -I. -c -o foo.o foo.d
scons: building terminated because of errors.

STDERR 
=
/usr/include/d/core/stdc/config.d:28:3: error: static if 
conditional cannot be at global scope

   static if( (void*).sizeof > int.sizeof )
   ^
scons: *** [foo.o] Error 1


|> dpkg -S /usr/include/d/core/stdc/config.d 
libphobos2-ldc-dev: /usr/include/d/core/stdc/config.d


I think this is the same problem I have on OS X.

Re: [dlang.org] getting the redesign wrapped up

[Saurabh Das via Digitalmars-d]

On Friday, 8 January 2016 at 22:32:59 UTC, anonymous wrote:

My implementation of the redesign is pretty much complete.

Check it out: http://d-ag0aep6g.rhcloud.com/

This is an implementation of a design done by one Ivan Smirnov, 
brought forward by Jacob Carlborg [1].


The dark forum widgets on the home page are in iframes. Their 
styling will need to be updated at the source, which is 
forum.dlang.org.


Another external dependency is the This Week in D script. Adam, 
it would be nice if the `setTwid` function could take the date 
separately. That would allow me to word the text without having 
"This Week in D" there twice.


Other than those two little things I consider this done. From 
my side it could be merged immediately.


But I'm sure there are a thousand things wrong with this. Here 
are some topics to get you started:


1) Legalities

I mentioned this before, but noone reacted. Can we use Ivan's 
work? Do we have his ok? Do we need it? Jacob mentioned that he 
can't in contact with him anymore. Is that a problem?


2) Reviewing the code

https://github.com/aG0aep6G/dlang.org/commits/Ivan-Smirnov's-redesign

This is just one giant commit (the others are independent minor 
fixes). GitHub refuses to show the diff for the style.css file, 
because it's too big. Is this acceptable, or do I need to split 
it up somehow? If I need to split it up, any advice on how to 
do that?


3) New Pages

Aside from the overall style changes and menu reorganization, I 
also added overview pages for the articles and for the tools:


http://d-ag0aep6g.rhcloud.com/articles.html
http://d-ag0aep6g.rhcloud.com/tools.html

They feature new text that should be proofread.

4) Fonts

Vladimir Panteleev has spoken out against web fonts [2]. His 
argument is that they can look fine on one system but bad on 
another. Indeed the recently changed code font on dlang.org 
looks pretty bad for me while the default 'monospace' looks 
just fine, which is why I reverted that in the redesign.


The redesign uses a web font for its main font, though: Roboto 
Slab. It looks good for me, but I'm not able to test it on a 
large variety of device/OS/browser combinations. Maybe it's 
fine, or maybe we should stay away from web fonts 
categorically. I don't really have an opinion on this.


5) Justified Text

Andrei loves it, everybody else hates it. I killed it as the 
mockup didn't have it. Is that ok, or is justified text a must?


6) Red For Clickables Only?

Currently, the site uses red almost exclusively for clickable 
stuff. But it's also used as a highlight color for 
non-clickable things. For example in phobos signatures:


http://d-ag0aep6g.rhcloud.com/phobos/object.html#.Object

The left borders of the signature boxes are red, and the 
documented symbol is highlighted with red.


Red does not signal clickability here. I don't like that and 
I'd prefer to go with another color for generic highlighting, 
reserving red for clickable stuff.


7) The Logo

As requested by Andrei, this does not feature a logo change for 
now. I'm going to make a pull request for the slicker logo 
variant [3] when this is through.



[1] http://forum.dlang.org/post/n53ps0$2j8f$1...@digitalmars.com
[2] 
http://forum.dlang.org/post/xezfeilxblfkibldv...@forum.dlang.org

[3] https://gist.github.com/aG0aep6G/0803ec5ae49f6afb0196


Again, thanks for doing this. The new design overall looks much 
more modern and approachable.


Some feedback I do have:

Fonts
---
I do not have any problem with Web Fonts. In particular the web 
fonts created by Google are highly tested and render pretty 
similarly on many device/browser combinations. This is from 
practical experience.


On the font used, Roboto Slab: I feel that the serif nature of 
the font makes it clash with the clean design. A sans serif font 
would look much better.


Justified Text

I'm with Andrei on this one. Justified text is preferable to 
aligned text for large paragraphs which span the reading width of 
the page. It always makes it easier to read. For mini-paragraphs, 
sometimes left aligned does look better.


"Your Code Here" widget
-
The widget that displays and allows you to run code in the 
browser has been a staple of the D website for a long time now. 
It's a great feature. There is one issue here: When the code 
length is large, it takes half the screen before any actual 
content begins. The grayed out header colour looks funny.


I suggest displaying the first 7-9 lines of code in the box and 
either making the box scrollable, or making it so that clicking 
on the box expands it to show the entire code.


The "Sort lines" example is about the right size. The "Round 
floating point numbers" is a bit large.


PS: Sorry if there were opportunities to give feedback on this 
earlier and somehow I missed it. I do hope you consider this even 
it if comes a bit late.


Thanks,
Saurabh

Re: sliced().array compatibility with parallel?

[Jay Norwood via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 03:23:14 UTC, Ilya wrote:
I will add significantly faster pairwise summation based on 
SIMD instructions into the future std.las. --Ilya


Wow! A lot of overhead in the debug build.  I checked the 
computed values are the same.  This is on my laptop corei5.


dub -b release-nobounds --force
parallel time msec:448
non_parallel msec:767

dub -b debug --force
parallel time msec:2465
non_parallel msec:4962

on my corei7 desktop, the release-no bounds
parallel time msec:161
non_parallel msec:571

[Issue 15545] csv Reader line feed '\r' failure

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||b2.t...@gmx.com
   Assignee|nob...@puremagic.com|b2.t...@gmx.com

--

Re: D Cross Platform Status + OpenGL Status ?

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 9 January 2016 at 19:43:03 UTC, Jakob Jenkov wrote:
What is the status of cross compiling D to multiple platforms? 
I know it is possible, but how easy is it? How many issues do 
you have to mess with on different platforms?


The desktop ones are easy. ARM linux isn't to bad (use gdc or 
ldc). Android, iOS are in the works and have some support.


idk about Windows Phone, but I plan to take a look soonish.

And what about OpenGL support? Is that easy? And does it work 
easily across platforms?


You can call opengl functions the same as C.

Re: Function accepts const ubyte[], const char[], immutable ubyte[], immutable char[]

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

On Sunday, 10 January 2016 at 10:10:46 UTC, zabruk70 wrote:

void myFunc(char[] arg) { ubyte[] arg2 = cast(ubyte[]) arg; ...}



void myFunc(const(void)[] arg) {
   const(ubyte)[] arg2 = cast(const(ubyte)[]) arg;
   // use arg2
}


A `const(void)[]` type can accept any array as input. void[] is 
any array, const means it will take immutable, const, and mutable 
as well. Then you cast it to one type to use it.


what if additionally to written above, function shuld return 
ubyte[] or char[] ?


That depends on what you're doing, but you might also just want 
to return const(void)[], which the user will have to cast to 
something for them to use.

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 15:27, Bastiaan Veelo wrote:

Can I ask not to use dotted frames?


I agree that they're ugly, but they've been ugly before the redesign, 
too. Let's do such stuff in separate pull requests.

Re: sliced().array compatibility with parallel?

[Jay Norwood via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 12:11:39 UTC, Russel Winder wrote:

 foreach( dv; dvp){
 if(dv != dv){ // test for NaN
 return 1;
 }
 }
 return(0);
}


I am not convinced these "Tests for NaN" actually test for NaN. 
I

believe you have to use isNan(dv).


I saw it mentioned in another post, and tried it.  Works.

Re: [dlang.org] getting the redesign wrapped up

[Jack Stouffer via Digitalmars-d]

On Friday, 8 January 2016 at 22:32:59 UTC, anonymous wrote:

My implementation of the redesign is pretty much complete.

Check it out: http://d-ag0aep6g.rhcloud.com/


Congratulations on getting this merged!

Re: [dlang.org] getting the redesign wrapped up

[Bastiaan Veelo via Digitalmars-d]

On Sunday, 10 January 2016 at 14:04:44 UTC, anonymous wrote:
Example: 
http://d-ag0aep6g.rhcloud.com/phobos-prerelease/std_algorithm_searching.html#.commonPrefix


Can I ask not to use dotted frames? It may be my eyes, but I get 
dizzy reading the tables.
Maybe format tables like the cheat sheet at the top of the page, 
which I think looks beautiful.


Thanks!

[Dlang] Delegate Syntax Question

[Jack via Digitalmars-d-learn]

Hello. So I was trying to pass a delegate as an argument in a 
function and was wondering if I'm writing the correct code for it.


You see my code is :


//


class Foo()
{
 void bar()
 {
 writeln("Hello World");
 }
}

class Bar()
{

void delegate() action;

  void setAction(void delegate() dele)
  {
   action = dele;
  }

}

void main()
{
Foo foo = new Foo();
Bar bar = new Bar();
bar.setAction();
bar.action();
}

/

Is this correct? Because I've been having trouble calling the 
delegate when passing the method and I read many documentation 
concerning function and delegates. I'm just confused. 
(Disclaimer: My code's pattern is the same as above but it's not 
really my exact code)

Re: [Dlang] Delegate Syntax Question

[anonymous via Digitalmars-d-learn]

On 10.01.2016 15:32, Jack wrote:

//


class Foo()


Those parentheses make this a (zero parameter) class template. I suppose 
you just want a plain class. Drop them then.



{
  void bar()
  {
  writeln("Hello World");
  }
}

class Bar()


ditto


{

void delegate() action;

   void setAction(void delegate() dele)
   {
action = dele;
   }

}

void main()
{
Foo foo = new Foo();
Bar bar = new Bar();
bar.setAction();
bar.action();
}

/

Is this correct? Because I've been having trouble calling the delegate
when passing the method and I read many documentation concerning
function and delegates. I'm just confused. (Disclaimer: My code's
pattern is the same as above but it's not really my exact code)


Aside from the mentioned parentheses (and a missing import), 
everything's correct.

[Issue 15544] New: Escaping fields to a heap delegate must be disallowed in @safe code

[via Digitalmars-d-bugs]

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

  Issue ID: 15544
   Summary: Escaping fields to a heap delegate must be disallowed
in @safe code
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: slud...@outerproduct.org

>From https://github.com/rejectedsoftware/vibe.d/issues/570

The following code currently compiles fine, but results in a dangling reference
to "this.x" when the delegate gets called after the life time of the
originating "Test" instance. At least in @safe code, taking the address of a
struct field of "this" within a non-scoped delegate must instead result in a
compile-time error.

---
void delegate() @safe _del;

struct Test {
  int x = 42;
  @safe void test() {
_del = { assert(x == 42); };
 }
}
---

--

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 08.01.2016 23:32, anonymous wrote:

My implementation of the redesign is pretty much complete.

Check it out: http://d-ag0aep6g.rhcloud.com/


No blocking issues in sight so far. Time to make a pull request:

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

Re: [dlang.org] getting the redesign wrapped up

[anonymous via Digitalmars-d]

On 10.01.2016 16:11, Andrei Alexandrescu wrote:

Do you have a PR in place yet?


Here we go:
https://github.com/D-Programming-Language/dlang.org/pull/1187

Re: Linking a DLL to a DLL with packages

[Benjamin Thaut via Digitalmars-d-learn]

Am 09.01.2016 um 16:45 schrieb Thalamus:


Hi Benjamin,

I wouldn't say I need DLLs to work fully _really_ badly. The only
non-negligible issue with single very large binaries that's crossed my
mind is patching, but we're years away from having to worry about that
too much. That being said, I'm definitely willing to do some testing,
especially for something that helps us down the road. I'll follow up
with you offline. Thanks!



Great, some help with bugfixing and testing would be greatly apreciated. 
I didn't get any e-mail from you yet, I assume you didn't send one?


Kind Regards
Benjamin Thaut

GDC includes from LDC

[Russel Winder via Digitalmars-d]

Iain,

Playing with the SCons tests, I am heading to the hypothesis that, at
least on Debian Sid, if both gdc and ldc packages are installed, then
gdc picks up the D source files from the ldc package in preference to
the ones from the gdc package.


scons: Building targets ...
gdc -I. -c -o foo.o foo.d
scons: building terminated because of errors.

STDERR =
/usr/include/d/core/stdc/config.d:28:3: error: static if conditional cannot be 
at global scope
   static if( (void*).sizeof > int.sizeof )
   ^
scons: *** [foo.o] Error 1


|> dpkg -S /usr/include/d/core/stdc/config.d
libphobos2-ldc-dev: /usr/include/d/core/stdc/config.d

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Variant and immutable struct

[Vlad Leberstein via Digitalmars-d-learn]

Okay, I've cleared up some misconception.

On Wednesday, 6 January 2016 at 03:22:47 UTC, Vlad Leberstein 
wrote:
The same happens with immutable class(there is related thread 
with workaround at 
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Sending_an_immutable_object_to_a_thread_73866.html)

This is irrelevant here.

On Wednesday, 6 January 2016 at 03:22:47 UTC, Vlad Leberstein 
wrote:
I'm trying to put an immutable struct into std.variant.Variant 
but get some compilation error(but only when struct has at 
least one member). Stripped down example(tested on Linux dmd64 
v2.069.2):


import std.variant : Variant;


immutable struct Test {
int member; 
}

int main() {
Test v;
Variant test = v;
return 0;
}

Qualifier applied to definition of aggregate type just marks all 
it's members with the qualifier and doesn't change the type 
itself(as I thought initially).


So the problem with current implementation of std.variant.Variant 
is that it tries to modify(from the point of view of Type System) 
existing struct instance containing immutable members. I've done 
a little bit of hacking on Variant and came up with the following 
modification of "tryPutting":

...
static bool tryPutting(A* src, TypeInfo targetType, void* target)
{
alias UA = Unqual!A;
alias MutaTypes = TypeTuple!(UA, 
ImplicitConversionTargets!UA);

alias ConstTypes = staticMap!(ConstOf, MutaTypes);
alias SharedTypes = staticMap!(SharedOf, MutaTypes);
alias SharedConstTypes = staticMap!(SharedConstOf, 
MutaTypes);

alias ImmuTypes  = staticMap!(ImmutableOf, MutaTypes);

static if (is(A == immutable))
alias AllTypes = TypeTuple!(ImmuTypes, 
ConstTypes, SharedConstTypes);

else static if (is(A == shared))
{
static if (is(A == const))
alias AllTypes = SharedConstTypes;
else
alias AllTypes = TypeTuple!(SharedTypes, 
SharedConstTypes);

}
else
{
static if (is(A == const))
alias AllTypes = ConstTypes;
else
alias AllTypes = TypeTuple!(MutaTypes, 
ConstTypes);

}

foreach (T ; AllTypes)
{
if (targetType != typeid(T))
{
continue;
}

static if (is(typeof(*cast(T*) target = *src)))
{
T* zat = cast(T*) target;
if (src)
{
assert(target, "target must be non-null");
*zat = *src;
}
}
else static if ((is(T == const(U), U) ||
is(T == shared(U), U) ||
is(T == shared const(U), U) ||
is(T == immutable(U), U)) &&
is(typeof(*(cast(U*) (target)) = 
*(cast(UA*) src)))

)
{
U* zat = cast(U*) target;
if (src)
{
assert(target, "target must be non-null");
*zat = *(cast(UA*) (src));
}
}
else static if(is(T == struct))
{
if (src)
{
assert(target, "target must be non-null");
		memcpy((cast(void*) target), (cast(const(void*)) src), 
A.sizeof);

}
}
else
{
// type is not assignable
if (src) assert(false, A.stringof);
}
return true;
}
return false;
}
...

As I'm not very good at D, I would like to get some feedback 
about this solutions' viability. AFAIU memcpy-ing struct here is 
safe because all target arguments ever passed to tryPutting are 
internal to implementation(and SHOULD be void-initialized but 
it's currently not working AFAIK). Maybe postblit should also be 
called for new instance, but I'm not sure about current state of 
qualified postblit.


Any help would be greatly appreciated!

Re: [dlang.org] getting the redesign wrapped up

[Robert burner Schadek via Digitalmars-d]

congratulations

Re: [dlang.org] getting the redesign wrapped up

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 10 January 2016 at 17:17:44 UTC, Andrei Alexandrescu 
wrote:

On 1/10/16 10:23 AM, anonymous wrote:

On 10.01.2016 16:11, Andrei Alexandrescu wrote:

Do you have a PR in place yet?


Here we go:
https://github.com/D-Programming-Language/dlang.org/pull/1187


...aand we're live. Congratulations and many thanks to the 
folks who worked on this! -- Andrei


@anonymous, thank you for the great work and congratulations on 
getting it merged and live.


@Andrei, I am once again disappointed and frustrated at your 
attitude towards your fellow dlang.org maintainers. Please allow 
proper time for code review for pull requests, but at this point 
I feel like talking to a wall.

Re: Anyone using DMD to build 32bit on OS X?

[Jack Stouffer via Digitalmars-d]

On Sunday, 10 January 2016 at 17:12:40 UTC, Jacob Carlborg wrote:
The easiest would be to drop the 32bit support all together. 
Other options would be to continue to use emulate TLS on 32bit 
or implement native TLS for 32bit as well. I would prefer to 
not have to do this for 32bit as well.


I would suggest dropping 32bit OSX support, especially since it 
doesn't exist anymore. Mountain Lion, which was released in 2012, 
was the last version to ship a 32bit version. And you're right, 
DMD doesn't even have a 32bit binary for download.


Also, the probability of extra bugs in the 32bit OSX is high, due 
to the fact that no one uses it.

Re: Bug in csv or byLine ?

[Tobi G. via Digitalmars-d-learn]

The bug has been fixed...

Re: Bug in csv or byLine ?

[Tobi G. via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 09:41:16 UTC, Keywan Ghadami wrote:
On Friday, 8 January 2016 at 13:53:06 UTC, Guillaume Chatelet 
wrote:
I still do not understand half of the syntax(still learning) 
but my guess is that it is a bug in the csv reader:
In 
https://github.com/D-Programming-Language/phobos/blob/67c95e6de21d5d627e3c57128b4d6e332c82f785/std/csv.d line 1020 calls popfront on the input without checking that it input is empty.
But this only happen in special case if the last line is \r\n 
if i understand it correctly.
I might be totally wrong because it does not match your 
stackstrace and i did not yet understand everything about this.


Yes. It looks like there is no case to handle '\r' - line endings 
correctly.

https://github.com/D-Programming-Language/phobos/blob/67c95e6de21d5d627e3c57128b4d6e332c82f785/std/csv.d?L=1020#L1020
If '\r' is the last character it will fail, (because it tryes to 
read the next character).


enum data =
"name, surname, age
Joe, Joker, 99\r";  // WILL FAIL


import std.csv, std.stdio;

void main(string[] args)
{
auto reader = csvReader(data);

foreach(entry; reader)
{
writeln(entry);
}
}


togrue

Re: [dlang.org] getting the redesign wrapped up

[Saurabh Das via Digitalmars-d]

On Sunday, 10 January 2016 at 17:02:59 UTC, Saurabh Das wrote:

[...]
The grayed out header colour looks funny.


I meant it looks funny when it spans half the height of the page 
when the example code is long. It looks fine otherwise :)

Anyone using DMD to build 32bit on OS X?

[Jacob Carlborg via Digitalmars-d]

I've implemented native TLS in DMD on OS X for 64bit. Now the question 
is, does it need to work for 32bit as well?


The easiest would be to drop the 32bit support all together. Other 
options would be to continue to use emulate TLS on 32bit or implement 
native TLS for 32bit as well. I would prefer to not have to do this for 
32bit as well.


As far as I know we haven't released a 32bit binary of DMD for a very 
long time. It would be very rare to find a Mac that cannot run 64bit 
binaries.


Native TLS on OS X would mean that the runtime requirements for the 
binaries produced by DMD on OS X would be OS X 10.7 (Lion) or later. 
Hopefully that should not be a problem since it's several years (and 
versions) old.


--
/Jacob Carlborg

Re: [dlang.org] getting the redesign wrapped up

[Andrei Alexandrescu via Digitalmars-d]

On 1/10/16 10:23 AM, anonymous wrote:

On 10.01.2016 16:11, Andrei Alexandrescu wrote:

Do you have a PR in place yet?


Here we go:
https://github.com/D-Programming-Language/dlang.org/pull/1187


...aand we're live. Congratulations and many thanks to the folks who 
worked on this! -- Andrei

Re: Bug in csv or byLine ?

[Jesse Phillips via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 18:09:23 UTC, Tobi G. wrote:

The bug has been fixed...


Do you have a link for the fix? Is there a BugZilla entry?

[Issue 9476] Support native TLS on Mac OS X

[via Digitalmars-d-bugs]

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

--- Comment #14 from Jacob Carlborg  ---
https://github.com/D-Programming-Language/dmd/pull/5346

--

Re: Anyone using DMD to build 32bit on OS X?

[bitwise via Digitalmars-d]

On Sunday, 10 January 2016 at 17:12:40 UTC, Jacob Carlborg wrote:
I've implemented native TLS in DMD on OS X for 64bit. Now the 
question is, does it need to work for 32bit as well?


The easiest would be to drop the 32bit support all together. 
Other options would be to continue to use emulate TLS on 32bit 
or implement native TLS for 32bit as well. I would prefer to 
not have to do this for 32bit as well.


As far as I know we haven't released a 32bit binary of DMD for 
a very long time. It would be very rare to find a Mac that 
cannot run 64bit binaries.


Native TLS on OS X would mean that the runtime requirements for 
the binaries produced by DMD on OS X would be OS X 10.7 (Lion) 
or later. Hopefully that should not be a problem since it's 
several years (and versions) old.


Awesome!

Is there a way I can have a look at the code? I'd like to start 
looking into how this will fit together with shared library 
support.


Thanks,
   Bit

[Issue 15547] New: 64-bit struct alignment in core.sys.windows.setupapi inconsistent with msvc

[via Digitalmars-d-bugs]

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

  Issue ID: 15547
   Summary: 64-bit struct alignment in core.sys.windows.setupapi
inconsistent with msvc
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: tr...@gmx.com

Using 2.070.0-b1

32-bit sizeof SP_DEVICE_INTERFACE_DETAIL_DATA_A
msvc: 5
D:5

64-bit sizeof SP_DEVICE_INTERFACE_DETAIL_DATA_A
msvc: 8
D:5 <--

Line 872 in setupapi.d has align(1): should be 4 or 8, mingw-w64 has 8 msvc 4.
Tried to fix it myself but I couldn't figure out how to make it work for both
32 and 64-bit without duplicating all the structs.

--

Re: [dlang.org] getting the redesign wrapped up

[deadalnix via Digitalmars-d]

On Sunday, 10 January 2016 at 17:17:44 UTC, Andrei Alexandrescu 
wrote:

On 1/10/16 10:23 AM, anonymous wrote:

On 10.01.2016 16:11, Andrei Alexandrescu wrote:

Do you have a PR in place yet?


Here we go:
https://github.com/D-Programming-Language/dlang.org/pull/1187


...aand we're live. Congratulations and many thanks to the 
folks who worked on this! -- Andrei


That's awesome. Now :
 - I have no idea what the code sample is doing. The code sample 
is not for me or anyone that already knows D, but for newcomer 
that wonder what the hell D is about. If I can't understand it at 
first glance, then it is missing it's goal BY FAR.
 - Learn barely make the cut on my 15' monitor. That's way too 
low. If one doesn't know D, one doesn't care about news, 
community or whatever.

 - Widget are still broken on https.
 - The download button is small while surrounded by wasted grey 
area. BIG FAT DOWNLOAD WANTED, DEAD OR ALIVE.
 - Please don't make me click on the menus. You can also make 
them work with pure CSS using :hover
 - A light touch of green would make the page much nicer 
(complementary color, all that good fun).

 - Look and feel of packages and forum need to follow.

While I complains like a grumpy old man, I'd like to congrats 
people that makes this happen. This is very good for D. Good job.