Re: Comparison : mysql-native + asdf and hunt-database + asdf
On Friday, 6 November 2020 at 04:58:05 UTC, Vino wrote: Component : mysql-native + asdf Executable size : 17 MB Execution time : 10 secs, 189 ms, 919 μs, and 3 hnsecs Component : hunt-database + asdf Executable size : 81 MB Execution time : 5 secs, 916 ms, 418 μs, and 3 hnsecs Interesting but I think you should provide the test code for representative results?
Re: Return values from auto function
On Friday, 6 November 2020 at 15:06:18 UTC, Andrey Zherikov wrote: On Friday, 6 November 2020 at 14:58:40 UTC, Jesse Phillips wrote: On Friday, 6 November 2020 at 14:20:40 UTC, Andrey Zherikov wrote: This issue seems hit the inability to implicitly convert custom types. May be it makes more sense to ask in a separate thread. The return type must be the same for all execution paths. Result!void is a different type from Result!int. You aren't passing a 'Result' because that doesn't exist as a type. To clarify my statement: Yes, Result!void and Result!int are different types but I couldn't find a way to implicitly convert one to another. Putting aside D not providing implicit conversion to custom types. I'm curious what your semantics would be. # Result!void => Result!int How does the type know it can convert to int, or string, or Foo? What does it mean for a void to be an int? # Result!int => Result!void If you have something, what does it mean to go to not having that something. Would you really want to implicitly lose that something?
Re: Return values from auto function
On Friday, 6 November 2020 at 20:05:36 UTC, Ferhat Kurtulmuş wrote: On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote: I have auto function 'f' that might return either an error (with some text) or a result (with some value). The problem is that the type of the error is not the same as the type of result so compilation fails. [...] Sounds like Andrei's "Expected". Here is an implementation for d. https://github.com/tchaloupka/expected Hmmm, I wonder how that is different from the idea of 'option'
Re: Return values from auto function
On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote: I have auto function 'f' that might return either an error (with some text) or a result (with some value). The problem is that the type of the error is not the same as the type of result so compilation fails. [...] Sounds like Andrei's "Expected". Here is an implementation for d. https://github.com/tchaloupka/expected
Re: Switch between two structs with csvreader
On Fri, Nov 06, 2020 at 07:17:53PM +, Selim Ozel via Digitalmars-d-learn
wrote:
> On Thursday, 5 November 2020 at 22:36:36 UTC, Anonymouse wrote:
> > If I'm not mistaken the `csvReader` function returns a range struct,
> > and the full type is something long and unwieldy like
> > `CsvReader!(struct_type1, cast(Malformed)1, string, dchar,
> > string[])`. So just think of `records` as being that.
>
> I actually first going this route but couldn't figure out the correct
> name for that data type. It is quite long.
[...]
You can use the typeof() operator to capture the type of a long,
unwieldy type in an alias. This is useful if you ever need to store such
a return type somewhere, e.g.:
alias T = typeof(csvReader(...));
struct MyStorage {
T result;
}
MyStorage s;
s.result = csvReader(...);
Let the compiler figure out the type for you. :-)
T
--
Guns don't kill people. Bullets do.
How to load a dll which is written by dlang with a c interface from a c program static/dynamic link on windows?
e.g.
mydll.d:
import core.sys.windows.windows;
import core.sys.windows.dll;
extern (C) export int foo(ref int a[10],ref int b[10],ref int
c[10])
{
for(int i=0;i<10;i++)
{
c[10]=a[10]-b[10];
}
return 0;
}
mixin SimpleDllMain;
test.c:
How to write in both static and dynamic mode?
Re: Switch between two structs with csvreader
On Thursday, 5 November 2020 at 22:36:36 UTC, Anonymouse wrote: If I'm not mistaken the `csvReader` function returns a range struct, and the full type is something long and unwieldy like `CsvReader!(struct_type1, cast(Malformed)1, string, dchar, string[])`. So just think of `records` as being that. I actually first going this route but couldn't figure out the correct name for that data type. It is quite long. You need two different variables and two different `foreach`es. For the same code to work on both types, the easy solution is templates. Perhaps make the `foreach` part after the reads a templated function that accepts any type passed to it? Embedding the foreach loop inside a template function and deciding on the data type at the higher level function solved my issue. Thanks for the pointer! Best, Selim
Re: Return values from auto function
On Friday, 6 November 2020 at 15:06:18 UTC, Andrey Zherikov wrote: To clarify my statement: Yes, Result!void and Result!int are different types but I couldn't find a way to implicitly convert one to another. You can't. Structs do not implicitly convert to each other, templated or otherwise.
Re: Implicit conversion to templatized type
On Fri, Nov 06, 2020 at 03:36:46PM +, Paul Backus via Digitalmars-d-learn wrote: [...] > User-defined implicit conversions are one of the most error-prone > features of C++, and have been deliberately excluded from D, with the > exception of `alias this`. And Walter is already expressing regret at allowing `alias this`. I used to love `alias this`, and still use it in many of my projects, but over time, I'm also starting to agree with Walter that it was a mistake. Implicit conversions are generally not a good idea, except in very narrow, well-defined cases. They are convenient, but lead to problems in long-term maintenance. T -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth
Re: Implicit conversion to templatized type
On Friday, 6 November 2020 at 15:01:21 UTC, Andrey Zherikov wrote:
But how can I achieve the same result if S1 is a template
"struct S1(T) {}" and S2 should be convertible to S1!T with any
T?
Also why neither "opCast"
struct S2 { S1 opCast(T)() const if(is(T == S1)) { return
S1(); } }
nor suitable ctor
struct S1 { this(const S2 s){} }
are used for implicit conversion?
This is impossible by design. User-defined implicit conversions
are one of the most error-prone features of C++, and have been
deliberately excluded from D, with the exception of `alias this`.
Re: Vibe.d build on LDC error
On Friday, 6 November 2020 at 10:30:03 UTC, Mathias LANG wrote:
On Friday, 6 November 2020 at 05:52:56 UTC, Vino wrote:
[...]
Which Linux distribution ? Which version of Vibe.d ?
A recent enough Vibe.d should detect OpenSSL based on 1)
pkg-config 2) the openssl binary. Make sure you have the
development version of OpenSSL installed.
Additionally, v1.0.2 is quite old (and subject to security
issues), so you might want consider upgrading. But even with
that version, it should work.
You can force the usage of a certain configuration using:
```
"dependencies": {
"vibe-d": "~>0.9",
"vibe-d:tls": "*"
},
"subConfigurations": {
"vibe-d:tls": "openssl-1.0"
},
```
See:
https://github.com/vibe-d/vibe.d/blob/70b50fdb9cd4144f1a5007b36e6ac39d4731c140/tls/dub.sdl#L99-L103
Hi Mathias,
Thank you very much, it resolved the issue.
From,
Vino.B
Re: Return values from auto function
On Friday, 6 November 2020 at 14:58:40 UTC, Jesse Phillips wrote: On Friday, 6 November 2020 at 14:20:40 UTC, Andrey Zherikov wrote: This issue seems hit the inability to implicitly convert custom types. May be it makes more sense to ask in a separate thread. The return type must be the same for all execution paths. Result!void is a different type from Result!int. You aren't passing a 'Result' because that doesn't exist as a type. To clarify my statement: Yes, Result!void and Result!int are different types but I couldn't find a way to implicitly convert one to another.
Re: Return values from auto function
On Friday, 6 November 2020 at 14:20:40 UTC, Andrey Zherikov wrote: On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote: You can't. Both return values have to have the same type, which means the failure function has to be able to return more than one type, which means it has to be a template. This issue seems hit the inability to implicitly convert custom types. May be it makes more sense to ask in a separate thread. The return type must be the same for all execution paths. Result!void is a different type from Result!int. You aren't passing a 'Result' because that doesn't exist as a type. Hopefully one of these captures a misunderstanding.
Re: Return values from auto function
On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote: You can't. Both return values have to have the same type, which means the failure function has to be able to return more than one type, which means it has to be a template. This issue seems hit the inability to implicitly convert custom types. May be it makes more sense to ask in a separate thread.
Re: Return values from auto function
On Friday, 6 November 2020 at 13:59:58 UTC, gbram wrote: On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote: On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote: How can I make the original code compilable without templatizing `failure` function? You can't. Both return values have to have the same type, which means the failure function has to be able to return more than one type, which means it has to be a template. Being pedantic, he can, by templatising 'f' instead. Could you share how?
Re: Return values from auto function
On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote: On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote: How can I make the original code compilable without templatizing `failure` function? You can't. Both return values have to have the same type, which means the failure function has to be able to return more than one type, which means it has to be a template. Being pedantic, he can, by templatising 'f' instead.
Re: Return values from auto function
On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote:
I can make it work if I add a type to `failure` function but
this remove brevity in usage:
-
auto failure(T)(string error)
{
return Result!T(Result!T.Failure(error));
}
auto f(int i)
{
return i > 0 ? success(i) : failure!int("err text"); //
no error
}
-
How can I make the original code compilable without
templatizing `failure` function?
You can't. Both return values have to have the same type, which
means the failure function has to be able to return more than one
type, which means it has to be a template.
Return values from auto function
I have auto function 'f' that might return either an error (with
some text) or a result (with some value). The problem is that the
type of the error is not the same as the type of result so
compilation fails.
Here is my code:
--
struct Result(T)
{
struct Success
{
static if(!is(T == void))
{
T value;
}
}
struct Failure
{
string error;
}
Algebraic!(Success, Failure) result;
this(Success value)
{
result = value;
}
this(Failure value)
{
result = value;
}
}
auto success(T)(T value)
{
return Result!T(Result!T.Success(value));
}
auto failure(string error)
{
return Result!void(Result!void.Failure(error));
}
auto f(int i)
{
return i > 0 ? success(i) : failure("err text"); // Error:
incompatible types for (success(i)) : (failure("err text")):
Result!int and Result!void
}
-
I can make it work if I add a type to `failure` function but this
remove brevity in usage:
-
auto failure(T)(string error)
{
return Result!T(Result!T.Failure(error));
}
auto f(int i)
{
return i > 0 ? success(i) : failure!int("err text"); //
no error
}
-
How can I make the original code compilable without templatizing
`failure` function?
Re: Vibe.d build on LDC error
On Friday, 6 November 2020 at 05:52:56 UTC, Vino wrote:
Hi All,
When we try to build vide.d using ldc (dub build) we are
getting the below error, openssl is already been installed
(OpenSSL 1.0.2j-fips 26 Sep 2016), hence request your help on
the same.
openssl.d:84: error: undefined reference to 'OPENSSL_init_ssl'
openssl.d:121: error: undefined reference to 'OPENSSL_sk_num'
openssl.d:128: error: undefined reference to 'OPENSSL_sk_value'
openssl.d:243: error: undefined reference to 'BIO_set_init'
openssl.d:244: error: undefined reference to 'BIO_set_data'
openssl.d:245: error: undefined reference to 'BIO_set_shutdown'
openssl.d:1382: error: undefined reference to
'BIO_get_new_index'
openssl.d:1382: error: undefined reference to 'BIO_meth_new'
openssl.d:1384: error: undefined reference to
'BIO_meth_set_write'
openssl.d:1385: error: undefined reference to
'BIO_meth_set_read'
openssl.d:1386: error: undefined reference to
'BIO_meth_set_ctrl'
openssl.d:1387: error: undefined reference to
'BIO_meth_set_create'
openssl.d:1388: error: undefined reference to
'BIO_meth_set_destroy'
openssl.d:899: error: undefined reference to
'BN_get_rfc3526_prime_2048'
openssl.d:1288: error: undefined reference to 'BIO_set_init'
openssl.d:1290: error: undefined reference to 'BIO_set_data'
openssl.d:1298: error: undefined reference to 'BIO_get_shutdown'
openssl.d:1300: error: undefined reference to 'BIO_set_init'
openssl.d:1302: error: undefined reference to 'BIO_set_data'
openssl.d:1309: error: undefined reference to 'BIO_get_data'
openssl.d:1323: error: undefined reference to 'BIO_get_data'
openssl.d:1339: error: undefined reference to 'BIO_get_shutdown'
openssl.d:1342: error: undefined reference to 'BIO_set_shutdown'
openssl.d:1335: error: undefined reference to 'BIO_get_data'
collect2: error: ld returned 1 exit status
Error: /usr/bin/cc failed with status: 1
/Project/dlang/ldc-1.24.0/bin/ldc2 failed with exit code 1.
From,
Vino.B
Which Linux distribution ? Which version of Vibe.d ?
A recent enough Vibe.d should detect OpenSSL based on 1)
pkg-config 2) the openssl binary. Make sure you have the
development version of OpenSSL installed.
Additionally, v1.0.2 is quite old (and subject to security
issues), so you might want consider upgrading. But even with that
version, it should work.
You can force the usage of a certain configuration using:
```
"dependencies": {
"vibe-d": "~>0.9",
"vibe-d:tls": "*"
},
"subConfigurations": {
"vibe-d:tls": "openssl-1.0"
},
```
See:
https://github.com/vibe-d/vibe.d/blob/70b50fdb9cd4144f1a5007b36e6ac39d4731c140/tls/dub.sdl#L99-L103
Re: why `top` report is not consistent with the memory freed by core.stdc.stdlib : free?
On Friday, 6 November 2020 at 06:17:42 UTC, mw wrote: https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation using core.stdc.stdlib : malloc and free to manually manage memory, I tested two scenarios: -- malloc & free -- malloc only and I use Linux command `top` to check the memory used by the program, there is no difference in this two scenarios. I also tried to use `new` to allocate the objects, and GC.free(). The memory number reported by `top` is much less than those reported by using core.stdc.stdlib : malloc and free. I'm wondering why? shouldn't core.stdc.stdlib : malloc and free be more raw (low-level) than new & GC.free()? why `top` shows stdlib free() is not quite working? In general, any GC (not just the one in D) are not likely to give back memory to the OS. Because it's less overhead for the GC to keep the memory and reuse it. But I'm guessing `GC.free()` is supposed to give back memory to the OS, which leads into the other scenario. When it comes to maclloc/free. I would guess it's doing something similar. It probably splitting up the memory in blocks and/or pools. It might keep the memory just as the GC does for efficiency, even if `free` is called. Otherwise it would be not much point in using over the syscalls like `mmap` or `sbrk` (and whatever the corresponding calls are on Windows). -- /Jacob Carlborg
Re: why `top` report is not consistent with the memory freed by core.stdc.stdlib : free?
On Friday, 6 November 2020 at 06:17:42 UTC, mw wrote: Hi, I'm trying this: https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation using core.stdc.stdlib : malloc and free to manually manage memory, I tested two scenarios: -- malloc & free -- malloc only and I use Linux command `top` to check the memory used by the program, there is no difference in this two scenarios. I also tried to use `new` to allocate the objects, and GC.free(). The memory number reported by `top` is much less than those reported by using core.stdc.stdlib : malloc and free. I'm wondering why? shouldn't core.stdc.stdlib : malloc and free be more raw (low-level) than new & GC.free()? why `top` shows stdlib free() is not quite working? stdlib free does not give memory back to the system in a process normally on Linux. top only shows the virtual memory granted to that process. When you malloc, the VIRT goes up, the RES might go up also but they only go down if explicitly requested.
A GtkD question: Is there an explicit public function to get D Classes from StructCtype*?
For instance,
I have extern (C) int sortList1(GtkListBoxRow* _row1,
GtkListBoxRow* _row2, void* userData)
I pass it as listbox.setSortFunc(, cast(void*)this,
&_destroy2);
In the sortList1 function I want to access derived members of my
ListBoxRowWithData such as:
auto row1 =
cast(ListBoxRowWithData)getMyDObject!ListBoxRow(_row1);
auto row2 =
cast(ListBoxRowWithData)getMyDObject!ListBoxRow(_row2);
if(row1.id < row2.id) return 1;
A regular type cast returns null. T opCast(T)() in ObjectG.d
returns null in this case. I dug into the sources a little, and
my working solution is like:
template getCType(T)
{
static if ( is(T == class) )
alias getCType = typeof(T.tupleof[0]);
else
alias getCType = void*;
}
T getMyDObject(T, TC = getCType!T)(void* data){
T ret = ObjectG.getDObject!(T)(cast(TC)data);
return ret;
}
Is there an existing implementation for T getMyDObject(T, TC =
getCType!T)(void* data)?
