Re: How to assign and compare arrays to SumType?
On Tuesday, 11 June 2024 at 16:41:46 UTC, confuzzled wrote:
Comparison between a Variant and an array is straightforward.
How does one accomplish the same between a SumType and an array?
Okay, this is what I came up with. Just a sanity check please.
Did I do this correctly? Is there something I'm overlooking?
```d
import std.variant;
import std.sumtype;
import std.traits: isArray;
struct S
{
SumType!(double[]) data;
bool opEquals(T)(auto ref const T s) const
if (isArray!T)
{
return data == typeof(data)(s);
}
void opAssign(T)(T value)
if (isArray!T)
{
data = typeof(data)(value);
}
this(T)(T value)
if (isArray!T)
{
opAssign(value);
}
}
void main()
{
Variant v = [1.7, 2.7, 3.7, 4.7, 5.7];
assert(v == [1.7, 2.7, 3.7, 4.7, 5.7]);
S s = [1.7, 2.7, 3.7, 4.7, 5.7];
assert(s == [1.7, 2.7, 3.7, 4.7, 5.7]);
}
```
Thanks,
--confuzzled
Re: How to assign and compare arrays to SumType?
On Tuesday, 11 June 2024 at 16:41:46 UTC, confuzzled wrote:
Also, assuming that {1} read "SumType!(double)[] data;", what
would be the proper way to accomplish the assignment at {2} and
the subsequent comparison.
Not sure how to do solve the fist part of the question yet but I
was able to get this part done.
s.data = [SumType!double(1.7), SumType!double(2.7),
SumType!double(3.7), SumType!double(4.7), SumType!double(5.7)];
assert(s.data == [SumType!double(1.7), SumType!double(2.7),
SumType!double(3.7), SumType!double(4.7), SumType!double(5.7)]);
Wander if there is a more succinct way to do this?
P.S. Is news.digitalmars.com still operational? I'm unable to
access it through Thunderbird.
How to assign and compare arrays to SumType?
Comparison between a Variant and an array is straightforward. How
does one accomplish the same between a SumType and an array?
```d
import std.variant;
import std.sumtype;
import std.stdio;
struct S
{
SumType!(double[]) data; // {1}
}
void main()
{
Variant v = [1.7, 2.7, 3.7, 4.7, 5.7];
assert(v == [1.7, 2.7, 3.7, 4.7, 5.7]);
S s;
s.data = [1.7, 2.7, 3.7, 4.7, 5.7]; // {2}
assert(s.data == [1.7, 2.7, 3.7, 4.7, 5.7]);
}
```
Resulting Error:
var.d(17): Error: template \`opEquals\` is not callable using
argument types `!()(double[])`
/Users/anju/dlang/dmd-2.109.0-beta.1/osx/bin/../../src/phobos/std/sumtype.d(712):
Candidate is: `opEquals(this This, Rhs)(auto ref Rhs rhs)`
with `This = SumType!(double[]),
Rhs = double[]`
must satisfy the following constraint:
` !is(CommonType!(This, Rhs) == void)`
Also, assuming that {1} read "SumType!(double)[] data;", what
would be the proper way to accomplish the assignment at {2} and
the subsequent comparison.
Thanks,
--confuzzled
P.S. Is news.digitalmars.com still operational? I'm unable to
access it through Thunderbird.
Re: request assistance resolving curl error
On 3/26/24 8:44 PM, Andrea Fontana wrote: On Tuesday, 26 March 2024 at 07:13:24 UTC, confuzzled wrote: I think you should use the HTTP interface, did you check this docs? https://dlang.org/phobos/std_net_curl.html#.HTTP https://dlang.org/phobos/std_net_curl.html#.HTTP.addRequestHeader Andrea Thanks Andrea. I noticed it and even tried HTTP before but could not find a means for setting CurlOptions. As a result, I chose to stick with Curl. Following your comment, however, I went back and combed the source and found it buried in HTTP.handle. Thanks again. --confuzzled
request assistance resolving curl error
Hello all,
I have two scripts. I copied the first directly from the alpaca
website and massaged it with etc.c.curl until it compiled in D.
The result is that it creates the order and returns the result to
stdout. In the second script, I tried to use std.net.curl but
cannot get it to work.
The only difference I can recognize between the two is that in
the direct C version, CurlOption.writedata accepts a file handle
and is passed stdout as in the example presented on alpaca's
website while the wrapper accepts three different types (i.e.,
const(char)[], long, void*) and regardless of what I pass to it,
nothing works. I tried to not setting it but that didn't work
either. Don't know if that is even an option since alpaca_c did
not work without it and resulted in the same error
`{"code":4001,"message":"request body format is invalid"}`.
**1. alpaca_c**
```d
module alpaca_c;
import etc.c.curl;
import core.stdc.stdio: stdout;
import std.conv: text;
import config;
pragma(lib, "curl");
int main()
{
CURL *hnd = curl_easy_init();
curl_easy_setopt(hnd, CurlOption.customrequest, "POST".ptr);
curl_easy_setopt(hnd, CurlOption.writedata, stdout);
curl_easy_setopt(hnd, CurlOption.url,
"https://paper-api.alpaca.markets/v2/orders".ptr);
curl_slist *headers = null;
headers = curl_slist_append(headers, "accept:
application/json");
headers = curl_slist_append(headers, "content-type:
application/json");
headers = curl_slist_append(headers, i"APCA-API-KEY-ID:
$(config.api_key)".text.ptr);
headers = curl_slist_append(headers, i"APCA-API-SECRET-KEY:
$(config.secret_key)".text.ptr);
curl_easy_setopt(hnd, CurlOption.httpheader, headers);
curl_easy_setopt(hnd, CurlOption.postfields,
`{"side":"buy","type":"market","time_in_force":"day","qty":"1","symbol":"LCID"}`.ptr);
CURLcode ret = curl_easy_perform(hnd);
return 0;
}
```
**2. alpaca_d**
```d
import std.net.curl: Curl;
import etc.c.curl: curl_slist, curl_slist_append, CurlOption;
import core.stdc.stdio: stdout;
import std.stdio: writeln;
import std.conv: text;
import config;
pragma(lib, "curl");
void main()
{
string result;
Curl c;
c.initialize();
c.set(CurlOption.customrequest, "POST");
c.set(CurlOption.writedata, cast(void*) stdout);
c.set(CurlOption.url,
"https://paper-api.alpaca.markets/v2/orders;);
string key = i"APCA-API-KEY-ID: $(config.api_key)".text;
string secret = i"APCA-API-SECRET-KEY:
$(config.secret_key)".text;
curl_slist* headers;
headers = curl_slist_append(headers, "accept:
application/json");
headers = curl_slist_append(headers, "content-type:
application/json");
headers = curl_slist_append(headers, [0]);
headers = curl_slist_append(headers, [0]);
c.set(CurlOption.httpheader, headers);
c.set(CurlOption.postfields,
`{"side":"buy","type":"market","time_in_force":"day","symbol":"LCID","qty":"1"}`);
c.onReceive = (ubyte[] data) { result ~= data; return
data.length; };
auto ret = c.perform();
writeln(result);
}
```
Thanks for your assistance.
--confuzzled
Re: union default initialization values
On 12/6/23 4:47 AM, H. S. Teoh wrote: On Wed, Dec 06, 2023 at 04:24:51AM +0900, confuzzled via Digitalmars-d-learn wrote: [...] Also, if you don't understand how floating-point in computers work, I highly recommend reading this: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html It's a bit long, but well worth the time to read to understand why floating-point behaves the way it does. T Thank you for the explanation. Heading to the link to glean more. --confuzzled
Re: union default initialization values
On 12/6/23 4:28 AM, Adam D Ruppe wrote:
On Tuesday, 5 December 2023 at 19:24:51 UTC, confuzzled wrote:
Given the following union
union F
{
double x;
struct {
ulong lo;
ulong hi;
}
}
The default value of this would be `double.init`, since the first member
of the union is a `double`, which is a kind of NaN. This is non-zero.
Correct. So I expected a NaN output for x. However, I wasn't expecting
lo == 13835058055282163712 and hi == 32767 where x is of type real, or
lo == 9221120237041090560 and hi = 0 where x is of type double. Based on
the default initialization rules, I expected both lo and hi to have a
value of zero regardless if x is of type double or real. This is what
I'm trying to understand, how are these values derived?
Thanks again,
--confuzzled
union default initialization values
Given the following union
union F
{
double x;
struct {
ulong lo;
ulong hi;
}
}
I do not understand the output below. Please clarify.
import std.stdio;
void main()
{
F fp;
fp.lo.writeln; // Why is this not zero? How is this value derived?
fp.hi.writeln; // expected
fp.x.writeln; // expected
fp.x =
19716939937510315926535.148979323846264338327950288458209749445923078164062862089986280348253421170679;
fp.lo.writeln;
fp.hi.writeln;
fp.x.writefln!"%20.98f"; // Also, why is precision completely lost
after 16 digits (18 if I change the type of x to real)?
}
Sorry if this seem like noise but I genuinely do not understand. What
changes would I need to make to retain the precision of the value
provided in the assignment above?
Thanks,
--confuzzled
Re: What are the best available D (not C) File input/output options?
On 11/3/23 2:30 AM, Steven Schveighoffer wrote: On Thursday, 2 November 2023 at 15:46:23 UTC, confuzzled wrote: You should use a buffering library like iopipe to write properly here (it handles the encoding of text for you). Thanks Steve, I will try that.
Re: What are the best available D (not C) File input/output options?
Good morning, First, thanks to you, Steve, and Julian for responding to my inquiry. On 11/3/23 4:59 AM, Sergey wrote: On Thursday, 2 November 2023 at 15:46:23 UTC, confuzzled wrote: I've ported a small script from C to D. The original C version takes roughly 6.5 minutes to parse a 12G file while the port originally took about 48 minutes. In my experience I/O in D is quite slow. But you can try to improve it: Try to use std.outbuffer instead of writeln. And flush the result only in the end. Unless I did it incorrectly, this did nothing for me. My understanding is that I should first prepare an OutBuffer to which I write all my output. Once complete, I then write the OutBuffer to file; which still requires the use of writeln, albeit not as often. First I tried buffering the entire thing, but that turned out to be a big mistake. Next I tried writing and clearing the buffer every 100_000 records (about 3000 writeln calls). Not as bad as the first attempt but significantly worse than what I obtained with the fopen/fprintf combo. I even tried writing the buffer to disk with fprintf but jumped ship because it took far longer than fopen/fprintf. Can't say how much longer because I terminated execution at 14 minutes. Also check this article. It is showing how manual buffers in D could speed up the processing of files significantly: https://tech.nextroll.com/blog/data/2014/11/17/d-is-for-data-science.html The link above was quite helpful. Thanks. I am a bit slow on the uptake so it took a while to figure out how to apply the idea to my own use case. However, once I figured it out, the result was 2 minutes faster than the original C implementation and 3 minutes faster than the fopen/printf port. Whether it did anything for the writeln implementation or not, I don't know. Wasn't will to wait 45+ minutes for something that can feasibly be done in 6 minutes. I gave up at 12. Haven't played with std.string.representation as suggested by Julian as yet but I plan to. Thank again. --Confuzzled
What are the best available D (not C) File input/output options?
I've ported a small script from C to D. The original C version takes
roughly 6.5 minutes to parse a 12G file while the port originally took
about 48 minutes. My naïve attempt to improve the situation pushed it
over an hour and 15 minutes. However, replacing std.stdio:File with
core.stdc.stdio:FILE* and changing my output code in this latest version
from:
outputFile.writefln("%c\t%u\t%u\t%d.%09u\t%c", ...)
to
fprintf(outputFile, "%c,%u,%u,%llu.%09llu,%c\n", ...)
reduced the processing time to roughly 7.5 minutes. Why is
File.writefln() so appallingly slow? Is there a better D alternative?
I tried std.io but write() only outputs ubyte[] while I'm trying to
output text so I abandoned idea early. Now that I've got the program
execution time within an acceptable range, I tried replacing
core.stdc.fread() with std.io.read() but that increased the time to 24
minutes. Now I'm starting to think there is something seriously wrong
with my understanding of how to use D correctly because there's no way
D's input/output capabilities can suck so bad in comparison to C's.
Re: macOS Sonoma Linker Issue
On Wednesday, 4 October 2023 at 11:01:08 UTC, Johan wrote: Try passing `-ld_classic` to the linker. (`dmd -L-ld_classic`) https://github.com/ldc-developers/ldc/issues/4501#issuecomment-1738295459 -Johan Thanks. This did the trick.
macOS Sonoma Linker Issue
Any known workaround for this most recent issue on macOS Sonoma? The file I'm compiling contains a blank main() without any imports but this error shows up on everything I've attempted to compile since upgrading to Sonoma. (dmd-2.105.2) confuzzled@test ~ % dmd add ld: multiple errors: symbol count from symbol table and dynamic symbol table differ in '/Users/confuzzled/add.o' in '/Users/confuzzled/add.o'; address=0x0 points to section(2) with no content in '/Users/confuzzled/dlang/dmd-2.105.2/osx/lib/libphobos2.a[3177](config_a68_4c3.o)' clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: linker exited with status 1
Re: ImportC linking issue
On Saturday, 12 November 2022 at 12:48:40 UTC, confuzzled wrote: Right, so I figured that the dependencies for for libxlsxio_read would be resolved when it was being compiled/linked. Therefore, when I used it later, I would just need to import its and include it on the command line. I didn't **import its header and provide the library on the command line***
Re: ImportC linking issue
On Saturday, 12 November 2022 at 11:44:06 UTC, Mike Parker wrote: On Saturday, 12 November 2022 at 10:02:12 UTC, confuzzled wrote: On Saturday, 12 November 2022 at 08:43:13 UTC, Mike Parker wrote: On Saturday, 12 November 2022 at 02:45:52 UTC, confuzzled wrote: The linker doesn't care if the libraries are C or D, and the compiler is only involved in that you can pass flags to the linker via the compiler command line. Mike, first of all, thanks for the in depth response. That all makes sense. The issue I'm having is this: having made sure the two dependencies are available and building the libxlsxio_reader.a from the source without errors, why would I need to hunt down all the dependencies from that library to include them in my program? I figured that importing the header and passing libxlsxio_read.a on the command line would be enough? Why would I have to search for libcrypto, libminizip, libexpat, and more that I haven't even figured out what library they are? I thought those dependencies would already be linked into libxlsxio_read.a which is a statically linked library. Static library dependencies are resolved at link time. Anything they need to link with, your binary must link with. It's shared libraries that have their static dependencies all baked in. Right, so I figured that the dependencies for for libxlsxio_read would be resolved when it was being compiled/linked. Therefore, when I used it later, I would just need to import its and include it on the command line. I didn't realize I would have to hunt down those libraries again and link them to my program, especially since I don't know what most of them are. I didn't have to provide them to the linker when I compiled libxlsxio_read. Anyway, thanks for the explanation. I was definitely thinking and going about this all wrong. Appreciate the clarification. confuzzled!!!
Re: ImportC linking issue
On Saturday, 12 November 2022 at 08:43:13 UTC, Mike Parker wrote: On Saturday, 12 November 2022 at 02:45:52 UTC, confuzzled wrote: The linker doesn't care if the libraries are C or D, and the compiler is only involved in that you can pass flags to the linker via the compiler command line. Mike, first of all, thanks for the in depth response. That all makes sense. The issue I'm having is this: having made sure the two dependencies are available and building the libxlsxio_reader.a from the source without errors, why would I need to hunt down all the dependencies from that library to include them in my program? I figured that importing the header and passing libxlsxio_read.a on the command line would be enough? Why would I have to search for libcrypto, libminizip, libexpat, and more that I haven't even figured out what library they are? I thought those dependencies would already be linked into libxlsxio_read.a which is a statically linked library. I guess my noob is showing a lot. Again, thanks for your assistance. confuzzled!!!
Re: ImportC linking issue
On Friday, 11 November 2022 at 03:15:17 UTC, confuzzled wrote: When I try to compile it, I get a slew of errors about undefined symbols. It wasn't finding libexpat and libminizip so I copied those to my work directory and tried again. With that, most of the errors disappeared. The remaining ones are: It seems that every time I resolve one of these undefined symbols issues, the compiler finds more. So I keep copying lib files from locations that are a path, to my working directory and linking them to my script. Is that the norm? Do I need to configure DMD somehow to recognize C libraries that are already in the path? Thanks, confuzzled!!!
ImportC linking issue
Wondering if someone can help me with this. Mr. Adam D. Ruppe got
me 90% there, but I'm a little lost after reaching the 99% mark.
I want to use XLSX I/O to manipulate excel spreadsheets.
I've cloned, built, and installed the library. And with the help
of Adam, I am now able to import it and link to D program (as
long as I'm not using anything from the lib). Wanted to continue
the discussion with Adam, but I realize the announce forum isn't
the place to ask for help.
Anyway, the library has two dependencies:
- [expat](http://www.libexpat.org/) (only for libxlsxio_read)
- [minizip](http://www.winimage.com/zLibDll/minizip.html) or
libzip (libxlsxio_read and libxlsxio_write)
Since I'm on a Mac, I installed them using homebrew. In a demo.d
file I have the following:
```d
import xlsxio_read;
import std.stdio;
pragma(lib, "libxlsxio_read.a");
pragma(lib, "libexpat.a");
pragma(lib, "libminizip.a");
string filename = "logistic_regression.xlsx";
void main (string[] args)
{
if (args.length > 1)
filename = args[1];
xlsxioreader xlsxioread;
writef("XLSX I/O library version %s\n",
xlsxioread_get_version_string());
}
```
And in xlsxio_read.c (probably should call it something else), I
simply import the library header:
```c
#include
```
When I try to compile it, I get a slew of errors about undefined
symbols. It wasn't finding libexpat and libminizip so I copied
those to my work directory and tried again. With that, most of
the errors disappeared. The remaining ones are:
```
dmd demo.d xlsxio_read.c
ld: warning: ignoring file libminizip.a, building for
macOS-x86_64 but attempting to link with file built for
macOS-x86_64
Undefined symbols for architecture x86_64:
"_unzClose", referenced from:
_xlsxioread_close in libxlsxio_read.a(xlsxio_read.c.o)
"_unzCloseCurrentFile", referenced from:
_expat_process_zip_file in libxlsxio_read.a(xlsxio_read.c.o)
_xlsxioread_sheetlist_close in
libxlsxio_read.a(xlsxio_read.c.o)
_xlsxioread_sheet_close in libxlsxio_read.a(xlsxio_read.c.o)
"_unzGetCurrentFileInfo", referenced from:
_iterate_files_by_contenttype_expat_callback_element_start
in libxlsxio_read.a(xlsxio_read.c.o)
"_unzGetGlobalInfo", referenced from:
_iterate_files_by_contenttype_expat_callback_element_start
in libxlsxio_read.a(xlsxio_read.c.o)
"_unzGoToFirstFile", referenced from:
_iterate_files_by_contenttype_expat_callback_element_start
in libxlsxio_read.a(xlsxio_read.c.o)
"_unzGoToNextFile", referenced from:
_iterate_files_by_contenttype_expat_callback_element_start
in libxlsxio_read.a(xlsxio_read.c.o)
"_unzLocateFile", referenced from:
_XML_Char_openzip in libxlsxio_read.a(xlsxio_read.c.o)
"_unzOpen", referenced from:
_xlsxioread_open in libxlsxio_read.a(xlsxio_read.c.o)
"_unzOpen2", referenced from:
_xlsxioread_open_filehandle in
libxlsxio_read.a(xlsxio_read.c.o)
_xlsxioread_open_memory in libxlsxio_read.a(xlsxio_read.c.o)
"_unzOpenCurrentFile", referenced from:
_XML_Char_openzip in libxlsxio_read.a(xlsxio_read.c.o)
"_unzReadCurrentFile", referenced from:
_expat_process_zip_file in libxlsxio_read.a(xlsxio_read.c.o)
_expat_process_zip_file_resume in
libxlsxio_read.a(xlsxio_read.c.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to
see invocation)
Error: linker exited with status 1
```
From the first line of the error message, I gather I'm using the
wrong minizip but I'm not sure how or why. What does **"building
for macOS-x86_64 but attempting to link with file built for
macOS-x86_64"** even mean?
Thanks,
confuzzled!!!
