auto vectorization notes
When speeds are equivalent, or very close, I usually prefer auto vectorized code to explicit SIMD/__vector code as it's easier to read. (on the downside you have to guard against compiler code-gen performance regressions) One oddity I've noticed is that I sometimes need to use pragma(inline, *false*) in order to get ldc to "do the right thing". Apparently the compiler sees the costs/benefits differently in the standalone context. More widely known techniques that have gotten people over the serial/SIMD hump include: 1) simplified indexing relationships 2) known count inner loops (chunkify) 3) static foreach blocks (manual inlining that the compiler "gathers") I'd be interested to hear from others regarding their auto vectorization and __vector experiences. What has worked and what hasn't worked in your performance sensitive dlang code?
Re: Where is the latest android dev info?
My thingy can help https://github.com/adamdruppe/d_android a lot is built into ldc now too which is really nice as well. i need to update my repo to use the new ldc features, hoping to tomorrow. i'm just behind on a lot of things lol
Re: Swedish letters fuck up parsing into SQL querry
On Monday, 23 March 2020 at 15:07:31 UTC, Adam D. Ruppe wrote:
On Monday, 23 March 2020 at 14:26:46 UTC, Anders S wrote:
do you mean I should loop through each pos till
strlen(cellTab[CellIndex].name) to find "\0"?
strlen is ok, that gives the answer itself. Just slice to that.
cellTab[CellIndex].name[0 ..
strlen(cellTab[CellIndex].name.ptr)]
could do it. or
size_t end = 0;
foreach(idx, ch; cellTab[CellIndex].name)
if(ch == 0) {
end = idx;
break;
}
auto name = cellTab[CellIndex].name[0 .. end];
anything like that
How do you suggest I do the querry build then?
how are you running it? using a lib or just generating a .sql
file?
Hi,
I'm creating a connection to the db and conn.exec(sql)
I think I'll try the foreach to find out if it works (
tomorrow )
Re: Swedish letters fuck up parsing into SQL querry
On Monday, 23 March 2020 at 14:58:03 UTC, bauss wrote:
On Monday, 23 March 2020 at 14:26:46 UTC, Anders S wrote:
On Monday, 23 March 2020 at 13:53:50 UTC, Adam D. Ruppe wrote:
My first thought is to!string(cellTab[CellIndex].name) is
wrong, if it is a char[20] you should be scanning it to find
the length and slicing. Maybe [0 .. name.indexOf("\0")] or
whatever.
You also shouldn't be building a query by concatenation.
Hi, thks
do you mean I should loop through each pos till
strlen(cellTab[CellIndex].name) to find "\0"?
How do you suggest I do the querry build then?
This is open to sql injection.
I thought we were rid of this in this day and age.
Use prepared statements.
Yes true however I'm in early development and want to get a red
line working, then take care of the issues ;)
Re: Swedish letters fuck up parsing into SQL querry
On Monday, 23 March 2020 at 14:26:46 UTC, Anders S wrote:
do you mean I should loop through each pos till
strlen(cellTab[CellIndex].name) to find "\0"?
strlen is ok, that gives the answer itself. Just slice to that.
cellTab[CellIndex].name[0 .. strlen(cellTab[CellIndex].name.ptr)]
could do it. or
size_t end = 0;
foreach(idx, ch; cellTab[CellIndex].name)
if(ch == 0) {
end = idx;
break;
}
auto name = cellTab[CellIndex].name[0 .. end];
anything like that
How do you suggest I do the querry build then?
how are you running it? using a lib or just generating a .sql
file?
Re: Swedish letters fuck up parsing into SQL querry
On Monday, 23 March 2020 at 14:26:46 UTC, Anders S wrote:
On Monday, 23 March 2020 at 13:53:50 UTC, Adam D. Ruppe wrote:
My first thought is to!string(cellTab[CellIndex].name) is
wrong, if it is a char[20] you should be scanning it to find
the length and slicing. Maybe [0 .. name.indexOf("\0")] or
whatever.
You also shouldn't be building a query by concatenation.
Hi, thks
do you mean I should loop through each pos till
strlen(cellTab[CellIndex].name) to find "\0"?
How do you suggest I do the querry build then?
This is open to sql injection.
I thought we were rid of this in this day and age.
Use prepared statements.
Re: Swedish letters fuck up parsing into SQL querry
On Monday, 23 March 2020 at 13:53:50 UTC, Adam D. Ruppe wrote:
My first thought is to!string(cellTab[CellIndex].name) is
wrong, if it is a char[20] you should be scanning it to find
the length and slicing. Maybe [0 .. name.indexOf("\0")] or
whatever.
You also shouldn't be building a query by concatenation.
Hi, thks
do you mean I should loop through each pos till
strlen(cellTab[CellIndex].name) to find "\0"?
How do you suggest I do the querry build then?
Re: Swedish letters fuck up parsing into SQL querry
My first thought is to!string(cellTab[CellIndex].name) is wrong,
if it is a char[20] you should be scanning it to find the length
and slicing. Maybe [0 .. name.indexOf("\0")] or whatever.
You also shouldn't be building a query by concatenation.
Swedish letters fuck up parsing into SQL querry
Hi guys,
I'm trying to read a name from a struct iorequest where the name
is char name[20]
The struct is received through a FIFO pipe and message is going
into a mysql database to update specific post there.
Now my problem is that all works fine to read and stop with '\0'
termination till I receive a Swedish character, ie åäö. Then the
string gets crazy and reads all 20 chars no matter what.
Any ideas how to read all chars including åäö?
Using "~ to!string(name) ~" to build the SQL querry string as
below
int extract_Cell_From_IOREQ(int CellIndex){
auto sql ="UPDATE celldata set
name='"~ to!string(cellTab[CellIndex].name) ~"',
...
Re: linking obj files compiled with LDC2 1.20.0 on Win64
On Sunday, 22 March 2020 at 20:20:17 UTC, Steven Schveighoffer wrote: Make sure you don't have any stale objects left over in your project from the older build. Build everything clean from scratch. -Steve Thx, I double checked this. Then I attempted to link from the commandline and it worked. o.O So there must be some weirdness in my build tool which is fine with LDC2 1.6.0 but fails with 1.20.0 :S
Re: Wired question related with Chinese characters
On Monday, 23 March 2020 at 01:40:16 UTC, Adam D. Ruppe wrote: Terminal.getline *might* work in my lib, but if there's combining codepoints I'm not sure. You can try it though and let me know if you are already using the lib. I have done a small test and It works. Thank you!
Where is the latest android dev info?
See Title!
Re: assert expression in release mode
On 3/23/20 2:14 PM, Steven Schveighoffer wrote: E.g. https://dlang.org/dmd-osx.html#switch-release There are also other switches like -boundscheck and -check. It’s possible you have some library or project that is causing the behavior. -Steve Thank you, Steve. In my case I guess it was my mistake because now I returned to the problem to fix it and I can not reproduce that behavior locally.
Re: assert expression in release mode
On Monday, 23 March 2020 at 10:08:58 UTC, drug wrote: Before I lived in assurance that asserts are actual only in debug mode and in release mode they are nothing (except `assert(0)`). But today my whole life is going sour because I stumbled upon assert in release mode and of course that assert is failing. This doc https://dlang.org/spec/expression.html#assert_expressions say nothing about debug mode vs release mode. So the question is when and why assert expression is enabled in release mode (besides assert(0)) E.g. https://dlang.org/dmd-osx.html#switch-release There are also other switches like -boundscheck and -check. It’s possible you have some library or project that is causing the behavior. -Steve
assert expression in release mode
Before I lived in assurance that asserts are actual only in debug mode and in release mode they are nothing (except `assert(0)`). But today my whole life is going sour because I stumbled upon assert in release mode and of course that assert is failing. This doc https://dlang.org/spec/expression.html#assert_expressions say nothing about debug mode vs release mode. So the question is when and why assert expression is enabled in release mode (besides assert(0))
