Re: __traits for checking if a type is dynamic array (slice)
On 11/26/18 4:04 AM, Per Nordlöw wrote: Why is there no - __traits(isArray, T) alongside - __traits(isStaticArray, T) and - __traits(isAssociativeArray, T) Thanks for bringing this to my attention, Per. The core idea is to have __traits "primitive and ugly" and std.traits "convenient and nice". From that viewpoint, if isArray can be implemented as a library feature using primitives provided by traits, there is no need for making it. when dmd already has `ENUMTY.Tarray` alongside - ENUMTY.Tsarray and - ENUMTY.Taarray Justifying the feature by means of a detail in the compiler implementation is definitely undesirable. and std.traits already has a wrapper for this at https://dlang.org/phobos/std_traits.html#isDynamicArray ? If the wrapper works well, use it and move on. Thanks, Andrei
Re: Forwarding arguments through a std.algorithm.map
On 03/16/2018 03:52 PM, Nordlöw wrote:
On Saturday, 10 March 2018 at 21:31:41 UTC, ag0aep6g wrote:
auto forwardMap(alias fun, Ts ...)(Ts things)
{
import std.meta: aliasSeqOf, staticMap;
import std.range: iota;
import std.typecons: Tuple;
alias NewType(size_t i) = typeof(fun(things[i]));
alias NewTypes = staticMap!(NewType,
aliasSeqOf!(iota(things.length)));
Tuple!NewTypes results;
static foreach (i, thing; things) results[i] = fun(thing);
return results;
}
Found a slightly compacter way without `iota` and `aliasSeqOf` and with
(deprecated) string-lambda support and single-pass initialization using
`= void` and `emplace`:
/** Returns: `xs` forwarded through calls to `fun`.
*
* See also:
https://forum.dlang.org/post/zjxmreegqkxgdzvih...@forum.dlang.org
*/
auto forwardMap(alias fun, Ts...)(Ts xs)
{
import std.meta : staticMap;
alias MappedTypeOf(T) = typeof(fun(T.init));
alias NewTypes = staticMap!(MappedTypeOf, Ts);
import std.typecons : Tuple;
Tuple!NewTypes ys = void;
import std.conv : emplace;
import std.functional : unaryFun;
alias fun_ = unaryFun!(fun);
static foreach (immutable i, x; xs)
{
emplace([i], fun_(x));
}
return ys;
}
I believe this should go into Phobos somewhere. Into std.typecons,
std.meta or std.algorithm?
My knee-jerk reaction is that's a rather peculiar primitive to add to
the standard library. -- Andrei
Re: Range over a container r-value with disabled postblit
On 1/14/18 4:59 PM, Nordlöw wrote: On Sunday, 14 January 2018 at 21:57:37 UTC, Nordlöw wrote: Note that __trait(isLvalue, this) cannot be used to detect whether `this` is an l-value or an r-value, which I find strange. Shall be __traits(isRef, this) That would be difficult because lval/rval is known on he callee side. -- Andrei
Re: std.range.interfaces : InputRange moveFront
On 12/03/2017 12:42 AM, Johan Engelen wrote: On Friday, 1 December 2017 at 18:33:09 UTC, Ali Çehreli wrote: On 12/01/2017 07:21 AM, Steven Schveighoffer wrote: > On 12/1/17 4:29 AM, Johan Engelen wrote: >> (Also, I would expect "popFront" to return the element popped, but it >> doesn't, OK... > > pop removes the front element, but if getting the front element is > expensive (say if it's a map with a complex lambda function), you don't > want to execute that just so you can return it to someone who doesn't > care. This is why front and popFront are separate. Yet, we're told that compilers are pretty good at eliminating that unused copy especially for function templates where all code is visible. I assume that Steven means "copying the front element" when he wrote "getting the front element"? There is no need for a copy, because the element will be removed from the range, so we can move (whose cost only depends on the size of the element, internal pointers being disallowed by the language). If it is expensive to actually get _to_ the front/back element (i.e. find its memory location), then having to do the operation twice is a disadvantage. Ali: the compiler can only elide copying/moving of an unused return value when inlining the function. (the duty of making the return value move/copy is on the callee, not the caller) Note that because front/back() and popFront/Back() are separate, a copy *is* needed when one wants to "pop an element off". Thus moveFront/Back() and popFront/Back() should be used. OK. The fact that "pop" does something different from other programming languages is something important to remember when teaching people about D. And I think should be made clear in the documentation; let's add an example of how one is supposed to use all this in an efficient manner? Back on topic: let's change the documentation of moveFront such that it is clear that it does _not_ reduce the number of elements in the range? So, even though exception safety is not a common topic of D community, the real reason for why popFront() does not return the element is for strong exception safety guarantee. Interesting point. Argh why do we allow the user to throw in move? Regardless, separating front() from popFront() is preferable due to cohesion: fewer responsibilities per function, especially such low level ones. This doesn't make much sense ;-) popFrontN has more responsibility, and one gains better performance than simply calling popFront N times. It's similar here. Thanks Ali for asking me to comment in this thread. The matter of fact is moveFront was needed for different purposes. First off, moving in D cannot throw; all objects are moveable by means of bitwise move. The main reason for moveFront's existence is supporting ranges that have front() return an rvalue. For those, there would otherwise be no efficient means to move data out of the range to its user. Now, why does popFront return void instead of the popped element? We need front() anyway as a non-destructive way to look at the current element of the range, so having popFront return that element is redundant. Plus, it's difficult to optimize away particularly in separately compiled code. Andrei
Re: How to avoid throwing an exceptions for a built-in function?
On 5/10/17 3:40 PM, k-five wrote:
I have a line of code that uses "to" function in std.conv for a purpose
like:
int index = to!int( user_apply[ 4 ] ); // string to int
When the user_apply[ 4 ] has value, there is no problem; but when it is
empty: ""
it throws an ConvException exception and I want to avoid this exception.
currently I have to use a dummy catch:
try{
index = to!int( user_apply[ 4 ] );
} catch( ConvException conv_error ){
// nothing
}
I no need to handle that, so is there any way to prevent this exception?
Use the "parse" family: https://dlang.org/phobos/std_conv.html#parse --
Andrei
Re: [Semi-OT] I don't want to leave this language!
On 12/5/16 3:49 PM, e-y-e wrote: If you don't mind me saying, I think Mir could be one of the best things for the future of D (along with LDC) and I'd be glad to help it on its way. Yes, Mir is awesome! I keep on thinking of ways to make it better supported by the language and infra. -- Andrei
Re: [Semi-OT] I don't want to leave this language!
On 12/6/16 3:28 AM, Ilya Yaroshenko wrote: On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana wrote: On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko Phobos/Druntime are pretty good for a lot of projects. In theory And what seem to be the issues in practice with code that is not highly specialized? -- Andrei
Re: Set Operations on Set-like Containers
On 11/02/2016 11:07 AM, Nordlöw wrote: On Wednesday, 2 November 2016 at 13:45:41 UTC, Nordlöw wrote: Typically set- and map-like containers with O(1) key membership checking. A typical use case is intersection of the two sets `x` and `y`. When `x` and `y` both support O(1)-`contains(e)` the preferred algorithm is to interate over all elements in the shorter (smallest .length) of `x` and `y` (called `s`), and return only those elements of type E in `s` than can be looked up in `l` via `l.contains(E)`. Currently we don't have a good framework for associative ranges yet. We should define what the associative operations are, and then we can proceed to see where they'd make sense. -- Andrei
Re: Rust-like collect in D
On 10/06/2016 10:32 AM, Nordlöw wrote: Is there a concept in D similar to Rust's `collect`: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.collect That's "make" in std.container. Is that what you're looking for? As an aside, "collect" is an awful abbreviation of "collection". -- Andrei
Re: Allocating Heap/GC Storage upon Default Construction of RC Containers
On 9/21/16 8:49 AM, Nordlöw wrote:
Is there any way to make a default constructor of a struct container
allocate/initialize an internal pointer?
I need this in a container with RC behaviour similar to
struct Container
{
this()// this is currently forbidden:
{
_rcStore = emplace(cast(RCStore*)malloc(RCStore.size), null, 0);
}
private:
static struct RCStore
{
T* store;
size_t refCount;
}
RCStore* _rcStore;
}
If I can't modify default construction in containers such as `Container`
it is gonna behave in the same confusing way as empty AA's do for
(novel) D developers. Namely that the assignment of uninitialized AA's
has copy semantics and non-empty AA's have reference semantics.
I believe Andralex has spoken about this being a problem that should be
fixed if possible.
Sadly, not currently. I realize this makes certain designs more
difficult. -- Andrei
Re: Dual conditions in D and Python
On 5/21/15 2:35 PM, Ali Çehreli wrote:
On 05/21/2015 12:44 PM, Meta wrote:
All we need is user-defined opIs and then we're really cooking with gas.
if (5 is between(4, 6))
{
//...
}
We're almost there. :)
bool is_between(T0, T1, T2)(T0 what, T1 min, T2 max)
{
return (what = min) (what = max);
}
void main()
{
if (5.is_between(4, 6)) {
// ...
}
}
In fact we'll be there with 2.068:
http://dlang.org/phobos-prerelease/std_algorithm_sorting.html#.ordered
if (ordered(4, 5, 6)) { ... }
if (strictlyOrdered(4, 5, 6)) { ... }
Andrei
Re: druntime build failing because of masm386 problems
On 1/18/15 10:19 PM, Jonathan M Davis via Digitalmars-d-learn wrote: On Sunday, January 18, 2015 23:21:43 jollie via Digitalmars-d-learn wrote: Jonathan M Davis via Digitalmars-d-learn digita lmars-d-le...@puremagic.com Wrote in message: It's been a while since I did anything in Windows with D, and unfortunately, I need to again, and now I can't get druntime to build. I'm getting this lovely error: dmc -c src\rt\minit.asm masm386 -DM_I386=1 -D_WIN32 -Mx src\rt\minit.asm; Can't run 'masm386', check PATH Error: 'dmc' not found I know that I've seen this before, but I can't remember how to fix the problem. dmc is definitely on my PATH (I successfully built dmd prior to trying to build druntime), so the error seems to be wrong, for whatever good that does me. I don't see a masm386 with dmc, so I don't know where that comes from. Maybe that's part of the problem. Has anyone seen this problem and figured out how to get around it or fix it? - Jonathan M Davis It's been some months since I had this problem pop up, but I just ran touch on the minit.obj file so make thought it was up to date and used it. That did the trick. Thanks. It looks like that has to be done after every time I run clean. That definitely sucks. - Jonathan M Davis Can't we just change win32.mak to consider minit.obj part of the distribution? -- Andrei
Re: druntime build failing because of masm386 problems
On 1/18/15 11:22 PM, Jonathan M Davis via Digitalmars-d-learn wrote: It suggests creating an empty masm386.bat file in a directory which is in your path (e.g. C:\dm\bin), and then it'll just work, since masm386 will do nothing. Still, I'm inclined to think that the makefile should be fixed so that it just uses the provided object file if can't be rebuilt on the system anyway. Yah, that's a pretty poor suggestion. -- Andrei
Re: For those ready to take the challenge
On 1/9/15 6:10 PM, Jesse Phillips wrote: On Friday, 9 January 2015 at 13:50:29 UTC, eles wrote: https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro Link to answer in D: http://codegolf.stackexchange.com/a/44417/13362 Nailed it. -- Andrei
Re: Getting libcurl for 64 bit Windows
On 6/26/14, 11:11 AM, Mark Isaacson wrote:
Managed to build it successfully I think, but have actually
returned to the problem that initially caused me to want to try
and build the library in the first place:
If I try to build a simple program:
import std.stdio;
import std.net.curl;
void main() {
writeln(Hello world);
}
The program compiles, but does not print Hello World at
runtime... it just stops, and seemingly does nothing.
Trying to determine the root cause of that now.
Mark is my intern, and we're currently blocked by this in creating an
important demo for tomorrow.
Does anyone have good instructions for building libcurl on Win64, or
prebuild .lib and .dll files?
Thanks very much,
Andrei
