Re: dub optional dependency
On Sunday, 29 October 2017 at 01:55:22 UTC, evilrat wrote: This is dub design choice, optional requires manual fetching(dub fetch 'package'). I don't see other options, but you can try hack this using 'preBuildCommands' by adding dub fetch. Of course this defeats the purpose. No, they don't need to be manually fetched. Optional packages are downloaded when they are specified in the dub.selections.json file. Isn't it possible to put dependencies in specific configuration? What the OP wants is to have dependencies in a configuration be downloaded only when the configuration is specified. Currently, dependencies are always downloaded unless they are optional, no matter where they're listed in the file. And optional dependencies are only downloaded when they are specified in dub.selections.json. It would be a nice feature to have.
Re: Removing some of the elements from vibe.core.concurrency.Future[] futurelist
On Sunday, 29 October 2017 at 01:44:37 UTC, Nicholas Wilson wrote: Alternatively you could use a singly linked list and splice out elements that pass the filter predicate. I think you'd have to roll your own though. Something like https://github.com/dlang/phobos/pull/5821
Re: dub optional dependency
On Saturday, 28 October 2017 at 19:23:42 UTC, ikod wrote: So default version is "std", I can build it w/o vibe-d, but dub anyway fetch vibe-d. I'd like dub fetch vibe-d only when I build with --config vibed. As far as I know, that isn't possible. A package is either optional, or it isn't. It certainly would be a useful feature to have. Perhaps create an enhancement request for it if there isn't one already. https://github.com/dlang/dub/issues
Re: dub optional dependency
On Saturday, 28 October 2017 at 19:23:42 UTC, ikod wrote: So default version is "std", I can build it w/o vibe-d, but dub anyway fetch vibe-d. I'd like dub fetch vibe-d only when I build with --config vibed. I know about "optional": true, it prevent dub to fetch vibe-d for "std" config, but it also prevent it from fetching for --config vibed. This is dub design choice, optional requires manual fetching(dub fetch 'package'). I don't see other options, but you can try hack this using 'preBuildCommands' by adding dub fetch. Of course this defeats the purpose. Isn't it possible to put dependencies in specific configuration?
Re: Removing some of the elements from vibe.core.concurrency.Future[] futurelist
On Saturday, 28 October 2017 at 13:51:42 UTC, kerdemdemir wrote:
I am trying to make non blocking web requests to a web service.
vibe.core.concurrency.Future!(UserData)[] futurelist;
// I will make http requests in for loop and push them to
futureList
foreach( elem; elemList )
{
// In makeWebRequest I make the httprequest, parse json
and push to my UserData
auto future = vibe.core.concurrency.async(
&elem.makeWebRequest );
futurelist ~= future;
}
// I want to do call ProcessResponceData for each future which
is ready.
while ( futurelist.length > 0 )
{
futurelist.filter!(a => a.ready()).each!(a=>
ProcessResponceData(a.getResult()));
//! Here is my problem
//! I want to remove the futures which are already
processed.
futurelist = futurelist.filter!(a => !a.ready()).array;
sleep(10.msecs);
}
I am having troubles while trying to remove the future which I
already processed.
futurelist = futurelist.filter!(a => !a.ready()).array;
results with:
/usr/local/bin/../import/std/array.d(2716,20): Error: can't
have array of nothrow @safe void()
/usr/local/bin/../import/std/array.d(2782,46): Error: can't
have array of inout nothrow @safe void()
/usr/local/bin/../import/std/array.d(3158,1): Error: template
instance std.array.Appender!(Future!(UserData)[]) error
instantiating
/usr/local/bin/../import/std/array.d(133,32):
instantiated from here: appender!(Future!(UserData)[])
futurelist = futurelist.filter!(a => !a.ready()); results with:
Error: cannot implicitly convert expression
(filter(futurelist)) of type FilterResult!(__lambda5,
Future!(UserData)[]) to Future!(AnalyzeData)[]
Do you have any suggestion or workaround for my case?
What lesson I should learn from this case? Do you guys have any
idea why I am getting those compile errors?
Thanks
Erdem
I'd take a look at why the error message says
`Future!(UserData)[]) to Future!(AnalyzeData)[]`
is AnalyzeData the type returned by ProcessResponceData?
Alternatively you could use a singly linked list and splice out
elements that pass the filter predicate. I think you'd have to
roll your own though.
CSV with empty values for integer fields
CSV with empty values for integer fields throws
(Row: 1, Col: 3) Unexpected end of input when converting from
type string to type int
Code that parses the CSV:
```
import std.algorithm;
import std.array;
import std.csv;
import std.stdio;
import std.conv;
import std.range;
private struct IdentifyResult
{
string probe;
string target;
int rank;
int score;
bool vendorMatch;
}
void main(string[] args)
{
if (args.length < 2)
{
writeln("Usage: ", args[0], " ...
");
return;
}
foreach (i; 1 .. args.length)
{
try
{
auto arr = File(args[i],
"r").byLine.joiner("\n").csvReader!IdentifyResult.array;
writeln(args[i], "\tValid");
}
catch (std.csv.CSVException e)
{
writeln(e);
writeln(args[i], "\tInvalid");
}
}
}
```
Input CSV file below
CSV header (just for reference, but not part of the CSV)
Probe,Target,rank,score,match/nomatch,datetime,position,score
```
LIP_0905_1230.nistFALSE,2017-09-05 23:24:37,,
LIP_0905_1230.nistFALSE,2017-10-12 11:37:29,,
LIP_0905_1230.nistFALSE,2017-10-12 11:51:03,,
LIP_0905_1230.nistFALSE,2017-10-12 12:07:21,,
LIP_0905_1230.nist,CRM_1012_1920.nist,1,,true,2017-10-12
19:56:00,25,
LIP_0905_1230.nist,CRM_1012_1920.nist,1,,true,2017-10-13
00:55:00,25,
LIP_0905_1230.nist,CRM_1013_0005.nist,2,,true,2017-10-13
00:55:00,25,
LIP_0905_1230.nist,CRM_1012_1920.nist,1,,true,2017-10-18
18:27:22,25,
LIP_0905_1230.nist,CRM_1013_0005.nist,2,,true,2017-10-18
18:27:22,25,
LIP_0905_1230.nist,CRM_1013_0005.nist,1,,true,2017-10-20
11:04:31,25,
```
Is there anyway to overcome this without modifying the original
CSV?
Cheers,
Arun
Re: What is the best way to use requests and iopipe on gzipped JSON file
On 10/13/17 6:18 PM, Steven Schveighoffer wrote: On 10/13/17 6:07 PM, Steven Schveighoffer wrote: I reproduced, and it comes down to some sort of bug when size_t.max is passed to ensureElems. I will find and eradicate it. I think I know, the buffered input source is attempting to allocate a size_t.max size buffer to hold the expected new data, and cannot do so (obviously). I need to figure out how to handle this properly. I shouldn't be prematurely extending the buffer to read all that data. The while loop does work, I may change ensureElems(size_t.max) to do this. But I'm concerned about accidentally allocating huge buffers. For example ensureElems(1_000_000_000) works, but probably allocates a GB of space in order to "work"! This is now fixed. https://github.com/schveiguy/iopipe/pull/12 -Steve
dub optional dependency
Hello,
I have dub.json with two configurations:
"configurations": [
{
"name": "std",
"targetType": "library"
},
{
"name": "vibed",
"dependencies": {
"vibe-d": {"version": "~>0.7"}
},
"targetType": "library",
"versions": [
"vibeD"
]
}
],
So default version is "std", I can build it w/o vibe-d, but dub
anyway fetch vibe-d.
I'd like dub fetch vibe-d only when I build with --config vibed.
I know about "optional": true, it prevent dub to fetch vibe-d for
"std" config, but it also prevent it from fetching for --config
vibed.
Thanks for any help.
Re: opCast fails when this is null.
On 28-10-17 16:22, Nicholas Wilson wrote: On Saturday, 28 October 2017 at 14:19:01 UTC, Nicholas Wilson wrote: As Basile mentioned, this is compiler sticking checks in behind your back. The reason it works on new LDC is because #6982 was cherry picked to LDC (1.3?) before it was merged into dmd (not sure what version, I though it was 2.076, but it might have been one of the betas of 2.077) because I needed it for DCompute to build without -release. The only course is to use recent compilers. Erm, 2.077 is not a thing yet. Does it work with 2.076.1? No, it does work with the 2.077 beta tough. -- Mike Wey
Re: opCast fails when this is null.
On Saturday, 28 October 2017 at 14:19:01 UTC, Nicholas Wilson wrote: As Basile mentioned, this is compiler sticking checks in behind your back. The reason it works on new LDC is because #6982 was cherry picked to LDC (1.3?) before it was merged into dmd (not sure what version, I though it was 2.076, but it might have been one of the betas of 2.077) because I needed it for DCompute to build without -release. The only course is to use recent compilers. Erm, 2.077 is not a thing yet. Does it work with 2.076.1?
Re: opCast fails when this is null.
On Saturday, 28 October 2017 at 13:24:49 UTC, Mike Wey wrote:
The following code runs correctly when compiled with ldc
(1.4.0) but fails with an assert error when compiled with dmd
(2.076 and ldc 1.2.0)
```
class A
{
}
class B
{
T opCast(T)()
{
return this;
}
}
void main()
{
A a = null;
B b = null;
auto c = cast(Object)a;
auto d = cast(Object)b; // Fails with:
core.exception.AssertError@test.d(8): null this
}
```
How would you write an opCast that would handle this case
correctly?
Testing if this is null at the start of the opCast doesn't help
since the assert is thrown before that happens.
Making the opCast static leaves us without access to this,
which would be needed in my use case.
We can't relay on ufcs since the rewrite to opCast doesn't
happen when it's not a member function.
As Basile mentioned, this is compiler sticking checks in behind
your back.
The reason it works on new LDC is because #6982 was cherry picked
to LDC (1.3?) before it was merged into dmd (not sure what
version, I though it was 2.076, but it might have been one of the
betas of 2.077) because I needed it for DCompute to build without
-release.
The only course is to use recent compilers.
Re: Just starting with D (linking with C++)
On Saturday, 28 October 2017 at 02:20:42 UTC, codephantom wrote: On Friday, 27 October 2017 at 17:14:20 UTC, sivakon wrote: I want to use C++ libraries for machine learning and deep learning. How do I add C++ libraries to my d code. on FreeBSD, I use: for C static binding: -- clang -c sample.c dmd -L-lc foo.d sample.o or ldc -L-lc foo.d sample.o for c++ static binding: --- clang++ -c sample.cpp dmd -L-lc++ foo.d sample.o or ldc -L-lc++ foo.d sample.o There is nice article here that was pretty interesting too: https://www.gamedev.net/blogs/entry/2254003-binding-d-to-c/ Thanks! That worked like a charm. Now I can use dlang confidently. Any tips to make it faster cflags etc.
Removing some of the elements from vibe.core.concurrency.Future[] futurelist
I am trying to make non blocking web requests to a web service.
vibe.core.concurrency.Future!(UserData)[] futurelist;
// I will make http requests in for loop and push them to
futureList
foreach( elem; elemList )
{
// In makeWebRequest I make the httprequest, parse json
and push to my UserData
auto future = vibe.core.concurrency.async(
&elem.makeWebRequest );
futurelist ~= future;
}
// I want to do call ProcessResponceData for each future which is
ready.
while ( futurelist.length > 0 )
{
futurelist.filter!(a => a.ready()).each!(a=>
ProcessResponceData(a.getResult()));
//! Here is my problem
//! I want to remove the futures which are already
processed.
futurelist = futurelist.filter!(a => !a.ready()).array;
sleep(10.msecs);
}
I am having troubles while trying to remove the future which I
already processed.
futurelist = futurelist.filter!(a => !a.ready()).array; results
with:
/usr/local/bin/../import/std/array.d(2716,20): Error: can't have
array of nothrow @safe void()
/usr/local/bin/../import/std/array.d(2782,46): Error: can't have
array of inout nothrow @safe void()
/usr/local/bin/../import/std/array.d(3158,1): Error: template
instance std.array.Appender!(Future!(UserData)[]) error
instantiating
/usr/local/bin/../import/std/array.d(133,32):instantiated
from here: appender!(Future!(UserData)[])
futurelist = futurelist.filter!(a => !a.ready()); results with:
Error: cannot implicitly convert expression (filter(futurelist))
of type FilterResult!(__lambda5, Future!(UserData)[]) to
Future!(AnalyzeData)[]
Do you have any suggestion or workaround for my case?
What lesson I should learn from this case? Do you guys have any
idea why I am getting those compile errors?
Thanks
Erdem
Re: opCast fails when this is null.
On Saturday, 28 October 2017 at 13:24:49 UTC, Mike Wey wrote:
The following code runs correctly when compiled with ldc
(1.4.0) but fails with an assert error when compiled with dmd
(2.076 and ldc 1.2.0)
```
class A
{
}
class B
{
T opCast(T)()
{
return this;
}
}
void main()
{
A a = null;
B b = null;
auto c = cast(Object)a;
auto d = cast(Object)b; // Fails with:
core.exception.AssertError@test.d(8): null this
}
```
How would you write an opCast that would handle this case
correctly?
Compiler change is required.
This doesn't happen in -release mode. The assert is automatically
generated by the compiler. It could be disabled, as done here for
ctors and dtors
https://github.com/dlang/dmd/pull/6982
opCast fails when this is null.
The following code runs correctly when compiled with ldc (1.4.0) but
fails with an assert error when compiled with dmd (2.076 and ldc 1.2.0)
```
class A
{
}
class B
{
T opCast(T)()
{
return this;
}
}
void main()
{
A a = null;
B b = null;
auto c = cast(Object)a;
auto d = cast(Object)b; // Fails with:
core.exception.AssertError@test.d(8): null this
}
```
How would you write an opCast that would handle this case correctly?
Testing if this is null at the start of the opCast doesn't help since
the assert is thrown before that happens.
Making the opCast static leaves us without access to this, which would
be needed in my use case.
We can't relay on ufcs since the rewrite to opCast doesn't happen when
it's not a member function.
--
Mike Wey
Re: How to find the content of core.sys.* ?
On 2017-10-28 13:48, user1234 wrote: It's not documented because everything is already well documented either at microsoft, posix reference, c reference etc. It would be copy and paste monkey work to do that. I would be nice to have empty Ddoc comments so the symbols show up in the generated documentation. That way you'll know which symbols are available without having to read the source code. -- /Jacob Carlborg
Re: How to find the content of core.sys.* ?
On Saturday, 28 October 2017 at 11:41:16 UTC, Ryan Frame wrote: On Tuesday, 17 May 2016 at 06:56:36 UTC, rikki cattermole wrote: On 17/05/2016 6:55 PM, chmike wrote: Hello, The nice and handy documentation of dlang doesn't provide any info on the core.sys. How can I find out all the things that are in there ? https://github.com/dlang/druntime/tree/master/src/core/sys So is there a reason it's not being documented? I've got a deprecation message saying to switch from std.c.linux.linux to core.sys.posix.* Generally I'd assume undocumented features mean "don't use this", or at least "use at your own risk" (I believe that's why deprecated features are removed from the docs before they're pulled from the code). It looks like doc comments are pretty sparse in core/sys - is that the only reason docs aren't being generated? It's not documented because everything is already well documented either at microsoft, posix reference, c reference etc. It would be copy and paste monkey work to do that.
Re: How to find the content of core.sys.* ?
On Tuesday, 17 May 2016 at 06:56:36 UTC, rikki cattermole wrote: On 17/05/2016 6:55 PM, chmike wrote: Hello, The nice and handy documentation of dlang doesn't provide any info on the core.sys. How can I find out all the things that are in there ? https://github.com/dlang/druntime/tree/master/src/core/sys So is there a reason it's not being documented? I've got a deprecation message saying to switch from std.c.linux.linux to core.sys.posix.* Generally I'd assume undocumented features mean "don't use this", or at least "use at your own risk" (I believe that's why deprecated features are removed from the docs before they're pulled from the code). It looks like doc comments are pretty sparse in core/sys - is that the only reason docs aren't being generated?
