Re: why won't byPair work with a const AA?

[Ali Çehreli via Digitalmars-d-learn]

On 07/29/2017 10:15 PM, Matthew Gamble wrote:

>> I think it should work. I think a cast to unqualified is a safe
>> workaround in this case:
>>
>> auto pairs() @property const { return
>> (cast(int[string])aa).byPair.array.sort().release; }

As your question reveals, casting away const is not safe in general and 
not for this code. :-/


> That works to solve the compile problem. Seems the data in aa was safe
> from modification without the const or casting, even if the values are
> reference types (i.e. ClassB[string]). Is that expected?

No, they are not safe as you can mutate values in the AA:

import std.stdio;
import std.array;
import std.algorithm;

class B {
int i;
void mutate() {
++i;
}
}

class A
{
this() { aa = ["a" : new B(), "b" : new B(), "c" : new B()]; }
auto pairs() @property const { return 
(cast(B[string])aa).byPair.array.sort().release; }

private:
B[string] aa;
}

void main() {
auto a = new A();
auto p = a.pairs();
p.front[1].mutate();
assert(p.front[1].i == 1);// <-- Mutated :(
}

Of course, the problem is the same without const and the cast.

Ali

Re: why won't byPair work with a const AA?

[Matthew Gamble via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 04:36:19 UTC, Ali Çehreli wrote:

On 07/29/2017 09:19 PM, Matthew Gamble wrote:
I have a class member function from which I'm trying to return 
a sorted
array of key, value tuples stored in an associative array as a 
private
member. The member function should be able to be marked const 
to prevent
the AA from being modified. I have reduced the problem to the 
simple

case below which won't compile with DMD v2.072.2.

import std.array;
import std.algorithm;

class A
{
this() { aa = ["a":1, "b" : 2, "c" : 3]; }
auto pairs() @property const { return 
aa.byPair.array.sort().release; }

private:
int[string] aa;
}

If I remove const from the pairs function it compiles fine. 
I'm just not
sure this is a behavior I want. Any help/recommendation would 
be

appreciated.


I think it should work. I think a cast to unqualified is a safe 
workaround in this case:


auto pairs() @property const { return 
(cast(int[string])aa).byPair.array.sort().release; }


Ali


Thanks Ali,

That works to solve the compile problem. Seems the data in aa was 
safe from modification without the const or casting, even if the 
values are reference types (i.e. ClassB[string]). Is that 
expected?


Best,
Matt

Re: why won't byPair work with a const AA?

[Ali Çehreli via Digitalmars-d-learn]

On 07/29/2017 09:19 PM, Matthew Gamble wrote:

I have a class member function from which I'm trying to return a sorted
array of key, value tuples stored in an associative array as a private
member. The member function should be able to be marked const to prevent
the AA from being modified. I have reduced the problem to the simple
case below which won't compile with DMD v2.072.2.

import std.array;
import std.algorithm;

class A
{
this() { aa = ["a":1, "b" : 2, "c" : 3]; }
auto pairs() @property const { return aa.byPair.array.sort().release; }
private:
int[string] aa;
}

If I remove const from the pairs function it compiles fine. I'm just not
sure this is a behavior I want. Any help/recommendation would be
appreciated.


I think it should work. I think a cast to unqualified is a safe 
workaround in this case:


auto pairs() @property const { return 
(cast(int[string])aa).byPair.array.sort().release; }


Ali

why won't byPair work with a const AA?

[Matthew Gamble via Digitalmars-d-learn]

I have a class member function from which I'm trying to return a 
sorted array of key, value tuples stored in an associative array 
as a private member. The member function should be able to be 
marked const to prevent the AA from being modified. I have 
reduced the problem to the simple case below which won't compile 
with DMD v2.072.2.


import std.array;
import std.algorithm;

class A
{
this() { aa = ["a":1, "b" : 2, "c" : 3]; }
	auto pairs() @property const { return 
aa.byPair.array.sort().release; }

private:
int[string] aa;
}

If I remove const from the pairs function it compiles fine. I'm 
just not sure this is a behavior I want. Any help/recommendation 
would be appreciated.

Re: Is std.xml seriously broken, or is it me?

[Mike via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 02:58:09 UTC, Mike wrote:


import std.xml;
import std.stdio;

void main()
{
	auto parser = new DocumentParser("encoding=\"utf-8\"?>");

parser.onStartTag["device"] = (ElementParser parser)
{
writeln("device");
};
parser.parse(); 
}

https://dpaste.dzfl.pl/262597d2fda6

I used it before without any trouble.  Is it somehow seriously 
broken?  If not, what am I doing wrong?


It appears `onStartTag` does not handle the root element.  For 
example, this code seems to work:


import std.xml;
import std.stdio;

void main()
{
	auto parser = new DocumentParser("encoding=\"utf-8\"?>");

parser.onStartTag["peripheral"] = (ElementParser parser)
{
writeln("peripheral");
};
parser.parse(); 
}

Mike

Is std.xml seriously broken, or is it me?

[Mike via Digitalmars-d-learn]

I'm trying to use std.xml, and I can't get it to work.

I tried the simplest program I could think of:

import std.xml;
import std.stdio;

void main()
{
	auto parser = new DocumentParser("encoding=\"utf-8\"?>");

parser.onStartTag["device"] = (ElementParser parser)
{
writeln("device");
};
parser.parse(); 
}

https://dpaste.dzfl.pl/262597d2fda6

I used it before without any trouble.  Is it somehow seriously 
broken?  If not, what am I doing wrong?


Thanks,
Mike

Re: Question on SSE intrinsics

[Nicholas Wilson via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 02:05:32 UTC, Nicholas Wilson wrote:

On Saturday, 29 July 2017 at 22:45:12 UTC, piotrekg2 wrote:

What about __builtin_ctz?


https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/intrinsics.di#L325


you can also make it out of bsf or bsr (i can't remember which) 
from `core.bitop`

Re: Question on SSE intrinsics

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 29 July 2017 at 22:45:12 UTC, piotrekg2 wrote:

On Saturday, 29 July 2017 at 18:19:47 UTC, Johan Engelen wrote:

On Saturday, 29 July 2017 at 16:01:07 UTC, piotrekg2 wrote:

Hi,
I'm trying to port some of my c++ code which uses sse2 
instructions into D. The code calls the following intrinsics:


- _mm256_loadu_si256
- _mm256_movemask_epi8

Do they have any equivalent intrinsics in D?


Yes, with LDC (probably GDC too).
But unfortunately we don't have the "_mm256" functions (yet?), 
instead we have GCC's "__builtin_ia32..." functions.


The first one you mention I think is just an unaligned load? 
That can be done with the template `loadUnaligned` from module 
ldc.simd.


The second one has a synonym, "__builtin_ia32_pmovmskb256".

-Johan


What about __builtin_ctz?


https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/intrinsics.di#L325

Re: Error 1: Previous Definition Different : _D3gtk3All12__ModuleInfoZ (gtk.All.__ModuleInfo)

[Marco Leise via Digitalmars-d-learn]

Am Fri, 28 Jul 2017 22:53:52 +
schrieb FoxyBrown :

> After upgrading to latest dmd and having to rebuild gtk, I now 
> get the following error
> 
>   Error 1: Previous Definition Different : 
> _D3gtk3All12__ModuleInfoZ (gtk.All.__ModuleInfo)
>
>
> in my apps that were previously working(no changes, opened up old 
> app and tried to build it and it didn't work). All I did was 
> upgrade dmd2.

Expect potential changes to the ABI in every Dlang version.
After a compiler upgrade you have to rebuild all libraries.
That's why for the Gentoo Linux packages I maintain, there is
a separate library path for each Dlang version, compiler
vendor and architecture (i.e. 32-bit/64-bit). That way an
upgrade doesn't affect existing apps at the cost of manually
maintaining the list of compilers (and versions) you want to
install GtkD for.

> So tired of D and it's crap ;/ So unstable in so many ways. About 
> 10% as productive overall than other languages I've used.  It's 
> error messages are about as helpful as a rock.

Error messages did get better, but generic functions will
always end up looking more verbose than e.g. errors for C
function calls.

-- 
Marco

Re: Question on SSE intrinsics

[piotrekg2 via Digitalmars-d-learn]

On Saturday, 29 July 2017 at 18:19:47 UTC, Johan Engelen wrote:

On Saturday, 29 July 2017 at 16:01:07 UTC, piotrekg2 wrote:

Hi,
I'm trying to port some of my c++ code which uses sse2 
instructions into D. The code calls the following intrinsics:


- _mm256_loadu_si256
- _mm256_movemask_epi8

Do they have any equivalent intrinsics in D?


Yes, with LDC (probably GDC too).
But unfortunately we don't have the "_mm256" functions (yet?), 
instead we have GCC's "__builtin_ia32..." functions.


The first one you mention I think is just an unaligned load? 
That can be done with the template `loadUnaligned` from module 
ldc.simd.


The second one has a synonym, "__builtin_ia32_pmovmskb256".

-Johan


What about __builtin_ctz?

Re: It makes me sick!

[Timon Gehr via Digitalmars-d-learn]

On 29.07.2017 23:52, FoxyBrown wrote:

On Saturday, 29 July 2017 at 21:48:09 UTC, Timon Gehr wrote:

On 28.07.2017 23:30, FoxyBrown wrote:


because you didn't want to spend 10 minutes to fix a program.


You need to realize that the same thing applies to you. There is no 
"us" vs "you". I.e. if you know it to only be 10 minutes of work, why 
don't you just fix it yourself? Mike currently has as many commits in 
DMD as you do, and he is already busy contributing in other ways.




EXACTLY! Your problem is that you are taking the you vs me too literal. 
I am talking about a mentality people have that think that them saving 
10 minutes by not implementing something that will save 10 hours(low 
estimate) for everyone else is a good thing and criticize people when 
they say there is a better and try to condemn them and continue the 
status quo that wastes more time.




Personally, I expect a minimal amount of consistency. I.e. when someone 
criticizes something, I only take them seriously when they don't go on 
to indulge in the very behavior they criticize.


Also, Mike was not showing this mindset. Mike was saying it is not 
reasonable to expect being able to manually and somewhat carelessly 
juggle around the files of the installation on the file system and only 
get expected behaviour. Everything else is your own interpretation.


Note that there are a lot of things that anyone could work on that saves 
them or someone else a lot of time, and not everyone agrees on 
priorities. I think it is safe to assume that it was not laziness that 
led to the current behaviour, but that it was just an oversight.

Re: It makes me sick!

[FoxyBrown via Digitalmars-d-learn]

On Saturday, 29 July 2017 at 21:48:09 UTC, Timon Gehr wrote:

On 28.07.2017 23:30, FoxyBrown wrote:


because you didn't want to spend 10 minutes to fix a program.


You need to realize that the same thing applies to you. There 
is no "us" vs "you". I.e. if you know it to only be 10 minutes 
of work, why don't you just fix it yourself? Mike currently has 
as many commits in DMD as you do, and he is already busy 
contributing in other ways.




EXACTLY! Your problem is that you are taking the you vs me too 
literal. I am talking about a mentality people have that think 
that them saving 10 minutes by not implementing something that 
will save 10 hours(low estimate) for everyone else is a good 
thing and criticize people when they say there is a better and 
try to condemn them and continue the status quo that wastes more 
time.

Re: It makes me sick!

[Timon Gehr via Digitalmars-d-learn]

On 28.07.2017 23:30, FoxyBrown wrote:


because you didn't want to spend 10 minutes to fix a program.


You need to realize that the same thing applies to you. There is no "us" 
vs "you". I.e. if you know it to only be 10 minutes of work, why don't 
you just fix it yourself? Mike currently has as many commits in DMD as 
you do, and he is already busy contributing in other ways.


The compiler is here: https://github.com/dlang/dmd

Just implement the check, and commit it with commit message "fix Issue 
17699 - Importing a module that has both modulename.d and 
modulename/package.d should be an error", then create a pull request.


It is very easy to figure out where to add the check:

$ git clone g...@github.com:dlang/dmd
$ cd dmd/src/ddmd$
$ grep "package.d" * # the obvious string to search for
access.d:printf("\ts is in same package.d module as sc\n");
astbase.d:PKGunknown, // not yet determined whether it's a 
package.d or not
astbase.d:PKGmodule,  // already determined that's an actual 
package.d

grep: backend: Is a directory
dimport.d:// mod is a package.d, or a normal 
module which conflicts with the package name.

dmodule.d: * Therefore, the result should be: filename/package.d
dmodule.d: * iff filename/package.d is a file
dmodule.d:const(char)* ni = FileName.combine(filename, 
"package.di");

dmodule.d:const(char)* n = FileName.combine(filename, "package.d");
dmodule.d:const(char)* n2i = FileName.combine(n, "package.di");
dmodule.d:const(char)* n2 = FileName.combine(n, "package.d");
dmodule.d:PKGunknown, // not yet determined whether it's a 
package.d or not
dmodule.d:PKGmodule,  // already determined that's an actual 
package.d

dmodule.d:bool isPackageFile; // if it is a package.d
dmodule.d:// if module is not named 'package' but we're 
trying to read 'package.d', we're looking for a package module
dmodule.d:bool isPackageMod = (strcmp(toChars(), 
"package") != 0) && (strcmp(srcfile.name.name(), "package.d") == 0 || 
(strcmp(srcfile.name.name(), "package.di") == 0));
dmodule.d:.error(loc, "importing package '%s' 
requires a 'package.d' file which cannot be found in '%s'", toChars(), 
srcfile.toChars());
dmodule.d:isPackageFile = (strcmp(srcfile.name.name(), 
"package.d") == 0 ||
dmodule.d: strcmp(srcfile.name.name(), 
"package.di") == 0);
dmodule.d:if (m && (strcmp(m.srcfile.name.name(), 
"package.d") != 0 &&
dmodule.d:  strcmp(m.srcfile.name.name(), 
"package.di") != 0))

dmodule.d: * +- package.d
dmodule.d: * If both are used in one compilation, 'pkg' as a 
module (== pkg/package.d)
dmodule.d: *later package.d loading will change 
Package::isPkgMod to PKGmodule and set Package::mod.
dmodule.d: * 2. Otherwise, 'package.d' wrapped by 'Package' 
is inserted to the internal tree in here.
dmodule.d:/* If the previous inserted Package is not 
yet determined as package.d,
module.h:PKGunknown, // not yet determined whether it's a package.d 
or not

module.h:PKGmodule,  // already determined that's an actual package.d
module.h:bool isPackageFile; // if it is a package.d


I.e., let's check out dmodule.d. We immediately find the following code:

extern (C++) const(char)* lookForSourceFile(const(char)** path, 
const(char)* filename)

{
*path = null;
/* Search along global.path for .di file, then .d file.
 */
const(char)* sdi = FileName.forceExt(filename, global.hdr_ext);
if (FileName.exists(sdi) == 1)
return sdi;
const(char)* sd = FileName.forceExt(filename, global.mars_ext);
if (FileName.exists(sd) == 1)
return sd;
if (FileName.exists(filename) == 2)
{
/* The filename exists and it's a directory.
 * Therefore, the result should be: filename/package.d
 * iff filename/package.d is a file
 */
const(char)* ni = FileName.combine(filename, "package.di");
if (FileName.exists(ni) == 1)
return ni;
FileName.free(ni);
const(char)* n = FileName.combine(filename, "package.d");
if (FileName.exists(n) == 1)
return n;
FileName.free(n);
}
...


I'll let you (or anyone else who would like to) take it from here.

Re: It makes me sick!

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, July 29, 2017 21:17:23 Joakim via Digitalmars-d-learn wrote:
> On Saturday, 29 July 2017 at 19:26:03 UTC, FoxyBrown wrote:
> > Also, equating dmd to an audio program or a clip art program
> > that is designed to load any and all files in it's install dir
> > is moronic too.
>
> It is not moronic, it's a simple example that illustrates the
> larger principle, which is much more relevant for a compiler and
> its source.  The fact that you rail on the example rather than
> understanding the principle shows how much of an idiot you are.
>
> I'm tired of your constant complaints in this forum, which
> reflect your own stupidity and ignorance more than anything else.
>   I'm amazed people have treated you this nicely in this thread,
> and yet you keep ranting about how the D devs should account for
> the most idiotic things you do.
>
> GTFO, nobody wants you around.

While I agree that he's not being reasonable, let's please try to keep this
civil.

We answered his question. He didn't like the answer. I think that at this
point, we can just let him be unhappy about it rather than needing to
continue to argue with him about it and being rude in return.

- Jonathan M Davis

Re: It makes me sick!

[Joakim via Digitalmars-d-learn]

On Saturday, 29 July 2017 at 19:26:03 UTC, FoxyBrown wrote:

On Saturday, 29 July 2017 at 19:17:08 UTC, Joakim wrote:

On Friday, 28 July 2017 at 22:32:27 UTC, FoxyBrown wrote:

[...]


What you are suggesting is blatantly idiotic.  No software 
ever made supports simply installing on top of an old 
installation from a compressed zip or tar file.  If you need 
hand-holding, the installer will wipe the old install before 
unpacking the new install for you.  The zip file is for people 
who know what they are doing, such as not unpacking on top of 
the old install.  You should just use the installer from now 
on, not the zip file, if you can't be bothered to remove the 
old install first.


bullshit. Are you a moron? You really think your absolute "No 
software ever" is logical?


The only moron here is the one who simply uncompresses zip files 
on top of old software.  That either shows blatant ignorance of 
what uncompressing does, or sheer stupidity that it would work 
well for a compiler install.  Of course there is trivial software 
that consists of a single binary, for which you could do this.  
But there is nothing "logical" about that, just an exception for 
extremely simple software, which a compiler and its stdlib 
clearly isn't.


I can name many off the top of my head. Have you ever heard the 
fucking word "portable"? I guess not, go look it up.


You can name so many, yet you did not name a single one. I guess 
it's not so easy.


Yes, that's hilarious, "portable" has essentially nothing to do 
with this.



Please take your jack ass arrogant self somewhere else.


The only jackass is the one constantly braying about doing stupid 
things and how we should account for every dumb thing you do.  If 
you want to blame us for your not knowing how to deal with zip 
files, sounds like you're the one who should leave.


Also, equating dmd to an audio program or a clip art program 
that is designed to load any and all files in it's install dir 
is moronic too.


It is not moronic, it's a simple example that illustrates the 
larger principle, which is much more relevant for a compiler and 
its source.  The fact that you rail on the example rather than 
understanding the principle shows how much of an idiot you are.


I'm tired of your constant complaints in this forum, which 
reflect your own stupidity and ignorance more than anything else. 
 I'm amazed people have treated you this nicely in this thread, 
and yet you keep ranting about how the D devs should account for 
the most idiotic things you do.


GTFO, nobody wants you around.

Re: It makes me sick!

[FoxyBrown via Digitalmars-d-learn]

On Saturday, 29 July 2017 at 19:51:30 UTC, Adam D. Ruppe wrote:

On Saturday, 29 July 2017 at 19:26:03 UTC, FoxyBrown wrote:
Also, equating dmd to an audio program or a clip art program 
that is designed to load any and all files in it's install dir 
is moronic too.


I like to add files to the dmd install directory to expand its 
"just works" library.


I was bitten by this change too. I'm of the opinion that 
splitting std.datetime was a waste of time and also that the 
package.d feature is misdesigned. It should ALSO allow any 
other file to be passed with the module declaration that 
matches... you know, like every other module in the language. 
Why it got this bizarre special requirement is beyond me.


If it did, then we could easily enough just leave the old file. 
But no, it requires the new one, but then prolly on efficiency 
grounds, doesn't check it first meaning the old one can 
silently conflict. Ugh.


But the fix here is to fix the bizarre package.d design. Don't 
break the zip for cases like mine where adding files is a key 
feature of it.


I don't mind the issue as long as it is stated clearly what must 
be done(e.g., simply add "requires cleaned installed directory"). 
What pisses me off more more than anything is the asinine people 
defending the behavior as if it is acceptable and that it is the 
users fault to know that the behavior.


Many programs I use can be upgraded without issue by copying over 
the data files. Dmd did not have this program until recently and 
so, because it isn't stated it is a problem, how the hell is the 
user suppose to know that? Specially when it worked correct the 
first time, the second time, the third time, etc.

Re: It makes me sick!

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

On Saturday, 29 July 2017 at 19:26:03 UTC, FoxyBrown wrote:
Also, equating dmd to an audio program or a clip art program 
that is designed to load any and all files in it's install dir 
is moronic too.


I like to add files to the dmd install directory to expand its 
"just works" library.


I was bitten by this change too. I'm of the opinion that 
splitting std.datetime was a waste of time and also that the 
package.d feature is misdesigned. It should ALSO allow any other 
file to be passed with the module declaration that matches... you 
know, like every other module in the language. Why it got this 
bizarre special requirement is beyond me.


If it did, then we could easily enough just leave the old file. 
But no, it requires the new one, but then prolly on efficiency 
grounds, doesn't check it first meaning the old one can silently 
conflict. Ugh.


But the fix here is to fix the bizarre package.d design. Don't 
break the zip for cases like mine where adding files is a key 
feature of it.

Re: It makes me sick!

[FoxyBrown via Digitalmars-d-learn]

On Saturday, 29 July 2017 at 19:17:08 UTC, Joakim wrote:

On Friday, 28 July 2017 at 22:32:27 UTC, FoxyBrown wrote:

[...]


What you are suggesting is blatantly idiotic.  No software ever 
made supports simply installing on top of an old installation 
from a compressed zip or tar file.  If you need hand-holding, 
the installer will wipe the old install before unpacking the 
new install for you.  The zip file is for people who know what 
they are doing, such as not unpacking on top of the old 
install.  You should just use the installer from now on, not 
the zip file, if you can't be bothered to remove the old 
install first.


bullshit. Are you a moron? You really think your absolute "No 
software ever" is logical?


I can name many off the top of my head. Have you ever heard the 
fucking word "portable"? I guess not, go look it up.


Please take your jack ass arrogant self somewhere else.

Also, equating dmd to an audio program or a clip art program that 
is designed to load any and all files in it's install dir is 
moronic too.

Re: It makes me sick!

[Joakim via Digitalmars-d-learn]

On Friday, 28 July 2017 at 22:32:27 UTC, FoxyBrown wrote:

On Friday, 28 July 2017 at 21:35:01 UTC, Anonymouse wrote:

On Friday, 28 July 2017 at 21:23:22 UTC, FoxyBrown wrote:

[...]


I'm sorry if I'm not expressing it in a way that agrees with 
you but you're looking at the wrong side of the example. 
You're pasting one set of files onto another and expect the 
software to somehow know to ignore some of them.


YES! EXACTLY! I AM EXPECTING THE SOFTWARE, WHICH IS WHAT THE 
PROGRAMMER CREATED AND HANDLES THE FILES TO ACTUALLY KNOW WHAT 
THE HELL IT IS DOING!


I'm sorry if that is too complex to understand.

If the software has some build in design that makes it use 
arbitrary files in a specific way like it does with 
std.datetime, then it should have sanity checks.


After all, who the hell knows more about dmd using std.datetime 
and how it uses it and such, the end user or the programmer of 
dmd?


You are expecting the end user, who generally knows very little 
to do the dirty work instead of having the programmer who is 
suppose to know what the fuck is going on to add sanity checks, 
useful error messages, etc.


Ali suggested a very reasonable solution that would have solved 
this problem and you guys are against it and offer no solution 
to the issue.


It all boils down to laziness. Too lazy to spend the time to 
add code that makes dmd more robust. Simple as that.


It's not that it can't be done, like you bone-heads are 
claiming, but that you simply don't want to do it.


Another very simple solution:

Before the zip file is generated, a listing of all the files in 
the dmd installation that are used(which should be all of them) 
is taken. This file then is parsed by dmd and only those files 
in the dmd dir that are in the list are used. This would also 
have avoided the issue and future issues. Any stale files in 
the dir would simply be ignored.


But, again, too much work. Keep making the end users deal with 
these problems instead of doing your due diligence. That we, we 
have something to waste our time with in these forums instead 
of real problems.


What you are suggesting is blatantly idiotic.  No software ever 
made supports simply installing on top of an old installation 
from a compressed zip or tar file.  If you need hand-holding, the 
installer will wipe the old install before unpacking the new 
install for you.  The zip file is for people who know what they 
are doing, such as not unpacking on top of the old install.  You 
should just use the installer from now on, not the zip file, if 
you can't be bothered to remove the old install first.

Re: Question on SSE intrinsics

[Johan Engelen via Digitalmars-d-learn]

On Saturday, 29 July 2017 at 16:01:07 UTC, piotrekg2 wrote:

Hi,
I'm trying to port some of my c++ code which uses sse2 
instructions into D. The code calls the following intrinsics:


- _mm256_loadu_si256
- _mm256_movemask_epi8

Do they have any equivalent intrinsics in D?


Yes, with LDC (probably GDC too).
But unfortunately we don't have the "_mm256" functions (yet?), 
instead we have GCC's "__builtin_ia32..." functions.


The first one you mention I think is just an unaligned load? That 
can be done with the template `loadUnaligned` from module 
ldc.simd.


The second one has a synonym, "__builtin_ia32_pmovmskb256".

-Johan

Re: It makes me sick!

[Grander via Digitalmars-d-learn]

On Friday, 28 July 2017 at 22:32:27 UTC, FoxyBrown wrote:

On Friday, 28 July 2017 at 21:35:01 UTC, Anonymouse wrote:

[...]


YES! EXACTLY! I AM EXPECTING THE SOFTWARE, WHICH IS WHAT THE 
PROGRAMMER CREATED AND HANDLES THE FILES TO ACTUALLY KNOW WHAT 
THE HELL IT IS DOING!


[...]



The software actually knows what it does: loading/including all 
files from its library directory.


If you place your own pictures into a text processing program's 
clipart directory, you shouldn't complain about finding them 
listed as cliparts either.




I'm sorry if that is too complex to understand.

If the software has some build in design that makes it use 
arbitrary files in a specific way like it does with 
std.datetime, then it should have sanity checks.


[...]



Seems like the DMD zip should contain a notice like this: 
"Extract into an empty directory."

Re: Question on SSE intrinsics

[Eugene Wissner via Digitalmars-d-learn]

On Saturday, 29 July 2017 at 16:01:07 UTC, piotrekg2 wrote:

Hi,
I'm trying to port some of my c++ code which uses sse2 
instructions into D. The code calls the following intrinsics:


- _mm256_loadu_si256
- _mm256_movemask_epi8

Do they have any equivalent intrinsics in D?

I'm compiling my c++ code using gcc.

Thanks,
Piotr


https://stackoverflow.com/questions/14002946/explicit-simd-code-in-d

I don't think something has changed since then.

Question on SSE intrinsics

[piotrekg2 via Digitalmars-d-learn]

Hi,
I'm trying to port some of my c++ code which uses sse2 
instructions into D. The code calls the following intrinsics:


- _mm256_loadu_si256
- _mm256_movemask_epi8

Do they have any equivalent intrinsics in D?

I'm compiling my c++ code using gcc.

Thanks,
Piotr

Re: D Debug101

[Eugene Wissner via Digitalmars-d-learn]

On Saturday, 29 July 2017 at 14:41:32 UTC, Kagamin wrote:

People who don't use IDE, use printf debugging.


or gdb which has several GUI-frontends if needed.

Re: D Debug101

[Kagamin via Digitalmars-d-learn]

People who don't use IDE, use printf debugging.

Re: dmd can't build gtk x64

[Mike Wey via Digitalmars-d-learn]

On 29-07-17 01:57, FoxyBrown wrote:

On Friday, 28 July 2017 at 22:45:58 UTC, FoxyBrown wrote:
Error: can't run 'C:\VS\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64', 
check PATH


It is trying to run some x64.exe/com/bat file... why? What is this file?

simply doing dmd -m64 build.d

Works fine for x86.



I was able to get this to work by copying all the required lib's to the 
lib dir from the windows sdk(liburct.lib, shell32.lib) and copying 
link.exe to x64.


The program compiles, but when ran, I get the error

object.Exception@generated\gtkd\gtkd\Loader.d(125): Library load failed 
(libgdk-3-0.dll):  is not a valid Win32 application.


which I assume is due to the fact that I have x86 gtk installed(I think, 
as I thought I installed the dual package... can't seem to find x64 
gtk3+ standalone).


Yes, that error is probably because you only have the 32bit version of 
the GTK runtime installed.


On gtkd.org installers for both 32bit and 64bit are available, they can 
be installed side by side without any issues.


--
Mike Wey