Re: Simple casting?
On Wednesday, 27 November 2019 at 14:40:56 UTC, Timon Gehr wrote:
On 27.11.19 11:43, ixid wrote:
On Tuesday, 26 November 2019 at 16:33:06 UTC, Timon Gehr wrote:
import std;
void main(){
int[] x=[1,1,2,3,4,4];
int[][] y=x.chunkBy!((a,b)=>a==b).map!array.array;
writeln(y);
}
This stuff is a nightmare for less experienced users like
myself, I wish there were a single function that would make
any data obkect eager, no matter how convoluted its arrays of
arrays of arrays.
import std;
auto eager(T)(T r){
static if(isInputRange!T) return r.map!eager.array;
else return r;
}
void main(){
int[] x=[1,1,2,3,4,4];
int[][] y=x.chunkBy!((a,b)=>a==b).eager;
writeln(y);
}
Thank you, this is great but it should be in Phobos!
Re: Simple casting?
On Tuesday, 26 November 2019 at 16:33:06 UTC, Timon Gehr wrote:
import std;
void main(){
int[] x=[1,1,2,3,4,4];
int[][] y=x.chunkBy!((a,b)=>a==b).map!array.array;
writeln(y);
}
This stuff is a nightmare for less experienced users like myself,
I wish there were a single function that would make any data
obkect eager, no matter how convoluted its arrays of arrays of
arrays.
Re: No UFCS with nested functions?
On Monday, 4 November 2019 at 20:46:41 UTC, H. S. Teoh wrote:
On Mon, Nov 04, 2019 at 07:51:26PM +, Tobias Pankrath via
Digitalmars-d-learn wrote:
Why does the following not work? It works, if I move the
'prop' out of 'foo'.
UFCS is only supported for module-level functions, as far as I
know.
---
struct S {
ubyte[12] bar;
}
bool foo (ref S s)
{
static bool prop(const(ubyte)[] f) {
return f.length > 1;
}
return s.bar[].prop;
}
---
[...]
T
Is this a necessary limitation? It feels inconsistent and clunky.
Re: Accuracy of floating point calculations
On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote:
On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak
wrote:
If you use gdc or ldc you will get same results as c++, or you
can use C log directly:
import std.stdio;
import std.math : pow;
import core.stdc.math;
void main()
{
writefln("%12.3F",log(1-0.)/log(1-(1-0.6)^^20));
}
AFAIK dmd use real for floating point operations instead of
double
Given x87 is deprecated and has been recommended against since
2003 at the latest it's hard to understand why this could be seen
as a good idea.
Re: Enum and CTFE function call
On Tuesday, 14 August 2018 at 13:38:16 UTC, Everlast wrote: etc Thanks all for the comprehensive responses. I was not clearly separating CTFE and the compilation of the function in thinking about it. Much clearer now.
Re: Enum and CTFE function call
On Tuesday, 14 August 2018 at 09:12:30 UTC, ixid wrote: This will not compile as it says n is not known at compile time... This does work if 'value' is changed to immutable and fun to accept it. So it still seems like a missed opportunity as enum shouldn't be able to change either.
Enum and CTFE function call
This will not compile as it says n is not known at compile time:
auto fun(int n) {
static foreach(i;0..n)
mixin(i.to!string ~ ".writeln;");
return;
}
enum value = 2;
void main() {
fun(value);
}
But making it a template parameter fun(int n)() and fun!value
will obviously work as will replacing n in the foreach statement
with the enum 'value'. It seems like a missed opportunity that
the enum nature of 'value' does not propagate through the
function call letting the compiler know that 'value'and therefore
n are known at compile time.
Re: Infer return type from assignment
On Wednesday, 11 April 2018 at 14:33:06 UTC, Adam D. Ruppe wrote: On Wednesday, 11 April 2018 at 14:26:53 UTC, ixid wrote: Is it possible to infer a template's return type from what it's assigned to? If not is this a difficult or worthless feature to add? Not really. The function call needs to make sense by itself: fun(a) needs to be a complete thing for a lot of things in the language to work. Type checking assumes it is there, inference assumes it is there, overloading assumes it s there, etc. void foo(int); void foo(float); foo(fun(a)); // what happens? So I don't say anything is impossible that isn't a paradox... but the effort level to solve all these problems would be really high for D. I am sure there are all sorts of thorns involved but for your example a somewhat arbitrarily defined fallback hierarchy of types from most complex to most simple, with it matching the most 'simple' that it can.
Infer return type from assignment
Is it possible to infer a template's return type from what it's
assigned to? If not is this a difficult or worthless feature to
add?
OUT fun(IN, OUT)(IN value) {
return value.to!OUT;
}
void main() {
float a = 5.0;
int b = fun(a);
}
Re: See docs compiler message
On Tuesday, 6 March 2018 at 14:50:05 UTC, ixid wrote: On Tuesday, 6 March 2018 at 14:37:27 UTC, Steven Schveighoffer wrote: Now, there aren't actually docs for Transposed, but you can find it if you look at std.range.transposed: https://dlang.org/phobos/std_range.html#transposed -Steve Thanks, I had found that but that is not an explanation unless you have a lot of prior technical understanding of what save is and why it's not working. I guess it's a general doc quality issue - unless you're already very knowledgeable it's pretty much useless to understand the problem you have. I transposed a range of ranges to pass to a function to get the distance between characters in strings. That works fine, as does printing the result. But it then complains if I try to do anything like fold with the result. What is the correct way to iterate a range of ranges as transposed does?
Re: See docs compiler message
On Tuesday, 6 March 2018 at 14:37:27 UTC, Steven Schveighoffer wrote: Now, there aren't actually docs for Transposed, but you can find it if you look at std.range.transposed: https://dlang.org/phobos/std_range.html#transposed -Steve Thanks, I had found that but that is not an explanation unless you have a lot of prior technical understanding of what save is and why it's not working. I guess it's a general doc quality issue - unless you're already very knowledgeable it's pretty much useless to understand the problem you have. I transposed a range of ranges to pass to a function to get the distance between characters in strings. That works fine, as does printing the result. But it then complains if I try to do anything like fold with the result.
See docs compiler message
/opt/compilers/dmd2/include/std/algorithm/iteration.d(663): Deprecation: function `std.range.Transposed!(string[], cast(TransverseOptions)0).Transposed.save` is deprecated - This function is incorrect and will be removed November 2018. See the docs for more details. If it's going to say 'See the docs' how about linking the docs or even just specifying which docs it's referring to?
Re: short s, t; t = -s: no (longer) works: Deprecation: integral promotion not done for -s, use
On Saturday, 24 February 2018 at 20:07:04 UTC, kdevel wrote:
I don't get the point of the deprecation message:
--- intprom.d
import std.stdio;
void main ()
{
short s, t;
t = -s;
}
---
$ dmd intprom.d
intprom.d(6): Deprecation: integral promotion not done for -s,
use '-transition=intpromote' switch or -cast(int)(s)
What shall I do in order to get my template code
void mymain (T) ()
{
:
b[i] = -b [i];
:
}
compiled for any type for which negation is defined?
It's ridiculous and is going to cause endless pain and spammed or
forgotten casts in generic code. It will turn off newbies to D.
Re: How to instantiate a template struct with a template constructor without relying on auto deduction?
On Wednesday, 21 February 2018 at 14:42:56 UTC, Simen Kjærås
wrote:
On Wednesday, 21 February 2018 at 14:29:38 UTC, ixid wrote:
I do not understand what is happening here, I tried to wrote
what I thought would be the answer. If someone could explain
that would be great. I wrote this code:
struct Foo2(T, S) {
T bar;
this(S s) {
bar = s.to!T;
}
}
void main() {
float some_float = 0.5f;
int some_int = 1;
auto foo1 = Foo2!(int, float)(some_float);// Compiles, OK!
auto foo2 = Foo2!(int, float)(some_int); // Compiles,
wat?
}
int n = 1;
float f = n; // Basically this.
Foo2!(int, float) expects a float, and ints are implicitly
convertible to float.
--
Simen
Ah yes, that was silly of me to forget. Thanks!
Re: How to instantiate a template struct with a template constructor without relying on auto deduction?
On Wednesday, 21 February 2018 at 14:11:10 UTC, ParticlePeter
wrote:
struct Foo(T) {
T bar;
this(S)(S s) {
bar = convert(s);
}
}
auto foo = Foo!int(some_float);
this works because S is deduced as typeof(some_float), but how
would I instantiate the struct without relying on auto
deduction?
Suppose we would have this kind of constructor where auto
deduction is not possible:
this(int n)(float f) {
static foreach( i; 0..n) { do_some_ctfe_magic;}
}
How to instantiate Foo then?
I do not understand what is happening here, I tried to wrote what
I thought would be the answer. If someone could explain that
would be great. I wrote this code:
struct Foo2(T, S) {
T bar;
this(S s) {
bar = s.to!T;
}
}
void main() {
float some_float = 0.5f;
int some_int = 1;
auto foo1 = Foo2!(int, float)(some_float);// Compiles, OK!
auto foo2 = Foo2!(int, float)(some_int); // Compiles, wat?
}
Re: import strangeness with std.stdio.write
On Tuesday, 13 February 2018 at 13:52:37 UTC, rikki cattermole wrote: write exists in both, writeln exists only in std.stdio. Use named imports to pick which write you want. It does seem a little silly to have a name clash with such a commonly used function. Would it not be better to rename std.file.write to something like writeFile and deprecate the current name?
Re: alias and UFCS
On Tuesday, 24 January 2017 at 20:51:49 UTC, Stefan Koch wrote: On Tuesday, 24 January 2017 at 16:41:12 UTC, ixid wrote: On Tuesday, 24 January 2017 at 16:27:50 UTC, ixid wrote: On Tuesday, 24 January 2017 at 15:57:48 UTC, Las wrote: On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote: [...] Submit a bug report then. I will if it turns out the behaviour is wrong, that's what I'm checking at this stage. =) Apologies for the extra post - does the alias function count as declared in the same scope as the content of the function? That would be plausible as UFCS refuses to work on functions declared in the same scope. Is this something that could be changed? UFCS is only applied if the function if defined at module scope. This to to prevent the meaning of a ufcs function from changing. Does alias of an existing function count as a new function definition in that case?
Re: alias and UFCS
On Tuesday, 24 January 2017 at 16:27:50 UTC, ixid wrote:
On Tuesday, 24 January 2017 at 15:57:48 UTC, Las wrote:
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
This code:
T tFunc(alias F, T)(T n) {
n.F;
return n;
}
Produces this error:
Error: no property 'F' for type 'int[]' (or whatever type I
use).
The alias rules for functions seem to be incompatible with
UFCS, F(n) works fine. What are the rewrite steps here? Is
this necessary or an oversight? Not very uniform function
call syntax.
Submit a bug report then.
I will if it turns out the behaviour is wrong, that's what I'm
checking at this stage. =)
Apologies for the extra post - does the alias function count as
declared in the same scope as the content of the function? That
would be plausible as UFCS refuses to work on functions declared
in the same scope. Is this something that could be changed?
Re: alias and UFCS
On Tuesday, 24 January 2017 at 15:57:48 UTC, Las wrote:
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
This code:
T tFunc(alias F, T)(T n) {
n.F;
return n;
}
Produces this error:
Error: no property 'F' for type 'int[]' (or whatever type I
use).
The alias rules for functions seem to be incompatible with
UFCS, F(n) works fine. What are the rewrite steps here? Is
this necessary or an oversight? Not very uniform function call
syntax.
Submit a bug report then.
I will if it turns out the behaviour is wrong, that's what I'm
checking at this stage. =)
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 00:52:30 UTC, Gorge Jingale wrote: So, you can see D as a sort of dried up waste land desert with a few nice palm trees growing here and there and a few scorpions. C++, say, is a very lush forest with many tree dwelling monkeys. Which environment would you rather use? You're forgetting the spiked stick pits that the lush forest is full of, and also the monkeys are rabid. =)
Re: Operator overloading through UFCS doesn't work
On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote: And the fact that allowing free functions to overload operators via UFCS sends us into that territory just highlights the fact that they're a horrible idea. - Jonathan M Davis Do you have any examples of UFCS doing bad things? Most people seem to very much like it yet you argue against any change that would benefit UFCS. You seem to prefer: read(to(easier(much(i over i.much.easier.to.read
Re: OpenGL with D tutorials
On Sunday, 22 May 2016 at 12:55:47 UTC, Guillaume Piolat wrote: On Sunday, 22 May 2016 at 12:13:07 UTC, ixid wrote: What is the best OpenGL tutorial with D to use? I've tried to use d-gamedev-intro and opengl-tutorials and seem to get errors, files that are no longer included are needed (dgl)? and deprecation messages. Not a tutorial by any means but this example program can get you started with the annoying "Modern" OpenGL: https://github.com/d-gamedev-team/gfm/blob/master/examples/simpleshader/simpleshader.d Thanks, I have tried to get all the libraries and link them and now get a huge number of error messages (I am almost certainly missing or have mis-installed something, it doesn't complain about failing to import anything though. SeverityCodeDescription Project FileLineSuppression State Error Error 42: Symbol Undefined _D3gfm4sdl26window10SDL2Window11swapBuffersMFZv (void gfm.sdl2.window.SDL2Window.swapBuffers()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict7opengl39functions7glClearPWNbNikZv C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl23sdl4SDL213processEventsMFZv (void gfm.sdl2.sdl.SDL2.processEvents()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram3useMFZv (void gfm.opengl.program.GLProgram.use()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl3vao5GLVAO6unbindMFZv (void gfm.opengl.vao.GLVAO.unbind()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram5unuseMFZv (void gfm.opengl.program.GLProgram.unuse()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict7opengl39functions10glViewportPWNbNiZv C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl28keyboard12SDL2Keyboard9isPressedMFiZb (bool gfm.sdl2.keyboard.SDL2Keyboard.isPressed(int)) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl26window10SDL2Window8setTitleMFAyaZv (void gfm.sdl2.window.SDL2Window.setTitle(immutable(char)[])) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram7uniformMFAyaZC3gfm6opengl7uniform9GLUniform (gfm.opengl.uniform.GLUniform gfm.opengl.program.GLProgram.uniform(immutable(char)[])) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl23sdl4SDL28keyboardMFZC3gfm4sdl28keyboard12SDL2Keyboard (gfm.sdl2.keyboard.SDL2Keyboard gfm.sdl2.sdl.SDL2.keyboard()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4math6matrix21__T6MatrixTfVii4Vii4Z6Matrix8identityFNaNbNiNfZS3gfm4math6matrix21__T6MatrixTfVii4Vii4Z6Matrix C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict4sdl29functions12SDL_GetTicksPUNbNiZk C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\
OpenGL with D tutorials
What is the best OpenGL tutorial with D to use? I've tried to use d-gamedev-intro and opengl-tutorials and seem to get errors, files that are no longer included are needed (dgl)? and deprecation messages.
Re: foreach UFCS
On Thursday, 31 March 2016 at 13:48:27 UTC, Adam D. Ruppe wrote: It is trying to look up a name i in global scope, and calling writeln on it. This is why the .name syntax exists: so you can bypass local variables with the same name when trying to access a global. It would compile if you put an `int i;` at the top of your module... try it! Thanks, that makes sense! I had forgotten the global dot syntax. That seems like a somewhat sketchy syntax given how little one would use it, wouldn't something like: writeln(i).global; be much clearer for globals?
foreach UFCS
What is going on with UFCS and foreach? foreach(i;0..5).writeln; This prints five line breaks. foreach(i;0..5).i.writeln; This will not compile. foreach(i;0..5).writeln(i); This writes out 1 to 4 on separate lines. Is this supposed to work? I thought a.b would be rewritten to b(a) with UFCS but writeln(foreach(i;0..5)) is nonsensical and does not compile and should be the same as foreach(i;0..5).writeln;
Re: Simple performance question from a newcomer
On Tuesday, 23 February 2016 at 14:07:22 UTC, Marc Schütz wrote: On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote: We really need to standard algorithms to be fast and perhaps have separate ones for perfect technical accuracy. While I agree with most of what you're saying, I don't think we should prioritize performance over accuracy or correctness. Especially for numerics people, precision is very important, and it can make a just as bad first impression if we don't get this right. We can however make the note in the documentation (which already talks about performance) a bit more prominent: http://dlang.org/phobos/std_algorithm_iteration.html#sum Wouldn't it be better to have technically perfect implementations for those numerics people? Sum is a basic function that almost everyone may want to use, this is a factor of four slowdown for the sake of one user group who could be perfectly well served by a sub-library that contains high-accuracy versions. It might make sense if the speed difference were only a few percent.
Re: Simple performance question from a newcomer
On Monday, 22 February 2016 at 15:43:23 UTC, dextorious wrote: I do have to wonder, however, about the default settings of dub in this case. Having gone through its documentation, I might still not have guessed to try the compiler options you provided, thereby losing out on a 2-3x performance improvement. What build options did you use in your dub.json that it managed to translate to the correct compiler switches? Your experience is exactly what the D community needs to get right. You've come in as an interested user with patience and initially D has offered slightly disappointing performance for both technical reasons and because of the different compilers. You've gotten to the right place in the end but we need point A to point B to be a lot smoother and more obvious so more people get a good initial impression of D. Every D user thread seems to go like this- someone starts with DMD, they then struggle a little and hopefully get LDC working with a list of slightly obscure compiler switches offered. A standard algorithm performs disappointingly for somewhat valid technical reasons and more clunky alternatives are then deployed. We really need to standard algorithms to be fast and perhaps have separate ones for perfect technical accuracy. What are your thoughts on D now? What would have helped you get to the right place much faster?
Re: print function
On Thursday, 4 February 2016 at 22:13:36 UTC, Ola Fosheim Grøstad wrote: Well, it is probably not the best point in time to have absolute beginners use D anyway. That is a ridiculous thing to say and a great way of ensuring a language dies. Good starting resources help everyone.
Re: print function
On Thursday, 4 February 2016 at 11:04:23 UTC, cym13 wrote: On Thursday, 4 February 2016 at 10:18:35 UTC, ixid wrote: Do you think your knowledge and experience is a good model for how a new user who hasn't done much if any programming before would approach this? A design choice had to be made and made it was. Adding another function now (or worse, changing the existing ones) would only bring more confusion for beginners and unconsistency to the language. I firmly believe that no matter what your experience you have having one and preferably only one way to do things is more important to ease the learning process than having spaces or not. That's a nonsensical argument given the number of printing and writing functions that exist.
Re: print function
On Thursday, 4 February 2016 at 10:05:15 UTC, Jonathan M Davis
wrote:
I would normally expect someone to do that with writefln, which
would be cleaner. e.g.
writefln("%s %s %s %s", a, b, c, d);
Personally, I've never felt the need for a function like you're
describing.
- Jonathan M Davis
Do you think your knowledge and experience is a good model for
how a new user who hasn't done much if any programming before
would approach this?
Re: print function
On Thursday, 4 February 2016 at 13:46:46 UTC, Dejan Lekic wrote:
On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote:
It would be nice to have a simple writeln that adds spaces
automatically like Python's 'print' in std.stdio, perhaps
called print.
There are many implementations of string interpolation in D
(that is what you want, basically). One of them is given in
Phillipe's excellent book about templates:
https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/D-templates-tutorial.md#simple-string-interpolation .
I have written an attempt at it but my point was that a print
function would be a good addition to the standard library rather
than asking someone to write an implementation for me.
string makePrintString(T)(T length) {
import std.conv : to;
string s = "writeln(";
foreach( i; 0 .. length) {
s ~= "a[" ~ i.to!string ~ "]";
if(i != length - 1)
s ~= ",\" \",";
else s ~= ");";
}
return s;
}
void print(A...)(A a) {
static if(a.length) {
mixin(makePrintString(a.length));
} else writeln;
}
Re: print function
On Thursday, 4 February 2016 at 17:34:33 UTC, Artur Skawina wrote: On 02/04/16 16:32, Artur Skawina wrote: but that seems too expensive, when the use is just in toy programs and debugging. I hadn't really considered the relative cost-benefit, it's just a habit to try to hardcode things at compile time. =) It certainly seems to make sense to do it that way.
print function
It would be nice to have a simple writeln that adds spaces automatically like Python's 'print' in std.stdio, perhaps called print.
Re: print function
On Thursday, 4 February 2016 at 00:30:03 UTC, cym13 wrote: On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote: It would be nice to have a simple writeln that adds spaces automatically like Python's 'print' in std.stdio, perhaps called print. Sounds way too redundant to me. Normally you'd be right but printing out data is such a common thing, especially for beginners. It's the kind of thing that can make their early experience of a language a lot more positive. writeln(a, " ", b, " ", c, " ", d); Is very clunky. Programming languages are like cereal, you need sugar to get the kids hooked.
foreach change for multi-dimensional data
This is an idle thought hence putting it on the Learn-level forum. An idea struck me for foreach to make working with more complicated data types or heavily nested data easier. uint[][] a = [[1,2,3],[4,5,6]]; foreach(uint[] b; a) b.writeln; At present you can specify the type of 'b' in this example. If you want to iterate over each uint you have to write (and obviously you can omit the type for 'b' and 'c'): foreach(uint[] b; a) foreach(uint c; b) c.writeln; It would be nice if you could do something like this: foreach(uint c; a) c.writeln; Where it will take the ForeachType of 'a' until it finds a match to the type of 'c' and iterate over all that data. It would make it much less messy to apply a function that takes uint to all the data rather than having to nest loops or map maps.
Re: foreach change for multi-dimensional data
On Thursday, 28 January 2016 at 15:38:20 UTC, Ali Çehreli wrote: On 01/28/2016 05:33 AM, ixid wrote: > This is an idle thought hence putting it on the Learn-level forum. An > idea struck me for foreach to make working with more complicated data > types or heavily nested data easier. > > > uint[][] a = [[1,2,3],[4,5,6]]; [...] > It would be nice if you could do something like this: > > foreach(uint c; a) > c.writeln; It looks like Solomon E's recent collapse() is what we need here: http://forum.dlang.org/post/xihlsfgfpykdvmvrg...@forum.dlang.org foreach(c; a.collapse) // ... Ali That's a much more limited version of what I'm suggesting in that it just collapses until something isn't an array any more, sometimes you might only want to collapse two levels and get up with something that's still an array type or you will be getting members in struct that's in an array. I've written something similar for myself that will collapse until a provided type is matched or the first argument type of a provided function is matched and apply the function.
Re: Collapsing n-dimensional array to linear (1 dimensional)
On Monday, 25 January 2016 at 08:31:14 UTC, abad wrote: On Monday, 25 January 2016 at 02:27:57 UTC, Solomon E wrote: On Saturday, 23 January 2016 at 07:57:55 UTC, Ali Çehreli Ruby's Array class includes this sort method for flattening and for me it was surprisingly useful, for instance when it was necessary to write the array to file. D could certainly add a few more helper functions to work on multidimensional data or perhaps an article, I admit I was unaware joiner could be chained without mapping like that. One that regularly irritates me is arrays of results that you want to make eager such that you can map a lazy function to a 2D array and then store the result in a 2D array again. This seems messy and I'd like a function that will take absolutely anything and force eager assessment. auto a = res.map!array.array; // De-lazying 2D result Would like: auto a = res.eager;
Re: Preventing implicit conversion
On Thursday, 5 November 2015 at 05:41:46 UTC, Jonathan M Davis wrote: On Wednesday, November 04, 2015 21:22:02 ixid via Digitalmars-d-learn wrote: On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin wrote: > On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: >> Is there an elegant way of avoiding implicit conversion to >> int when you're using shorter types? > > Only with library solution. Implicit conversions are built > into language. Doesn't that seem rather limiting and unnecessary? Why? You can't affect what conversions do and don't work for the built-in types in _any_ language that I've ever used, and I've never heard of a language that allowed anything like that. If you want different conversion rules, you need to create a user-defined type that defines the conversions you want. That's pretty normal. And AFAIK, there aren't very many folks trying to avoid the built-in implicit conversions in D, particularly since D eliminated the various implicit narrowing conversions that you get in C/C++. - Jonathan M Davis In C++ I can add two shorts together without having to use a cast to assign the result to one of the two shorts. It just seems super clunky not to be able to do basic operations on basic types without casts everywhere.
Operator implicit conversion difference
This may have been overlooked in my other thread so I wanted to ask again: This seems very inconsistent, does a += b not lower to a = a + b? I guess not based on the below: ushort a = ushort.max, b = ushort.max; a += b; // Compiles fine a = a + b; // Error: cannot implicitly convert expression (cast(int)a + cast(int)b) of type int to ushort
Re: Preventing implicit conversion
On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin wrote: On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? Only with library solution. Implicit conversions are built into language. Doesn't that seem rather limiting and unnecessary?
Re: Preventing implicit conversion
On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? Also does this not seem inconsistent: ushort a = ushort.max, b = ushort.max; a += b; // Compiles fine a = a + b; // Error: cannot implicitly convert expression (cast(int)a + cast(int)b) of type int to ushort
Preventing implicit conversion
Is there an elegant way of avoiding implicit conversion to int when you're using shorter types?
Re: foreach loop
On Tuesday, 3 November 2015 at 15:06:00 UTC, Namal wrote: Can you help me out please. Thx. reduce!((x, y) => x + !y)(0, arr).writeln; This would probably be the preferred way, that uses a lambda function (x, y) => x + !y which adds the inverse of the next array value (y) to the total so far (x). You have to provide 0 as the first argument to reduce as it is the seed, otherwise it will use the first value in the array as the seed and convert it to an int, making the total 1 too high as the first value is 'true'. You can also use a string but this is frowned on style-wise though in this case it is clearer: reduce!"a + !b"(0, arr).writeln;
Re: Preventing implicit conversion
On Wednesday, 4 November 2015 at 17:26:04 UTC, Daniel Kozak wrote: V Wed, 04 Nov 2015 14:27:45 + ixid via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> napsáno: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? http://dlang.org/phobos/std_typecons.html#.Typedef That doesn't appear to prevent implicit conversion. Making two bools (or ubytes etc) that are Typedef and adding them together still results in an int.
Re: Hash-Table-Based Multiple Arguments Replacement
On Saturday, 10 October 2015 at 16:19:53 UTC, Nordlöw wrote:
Is there an algorithm somewhere in Phobos which performs when
possible a replacement/substitution based on a variadic
definition of replacements using hash-table search similar to
string replaceWhole(string a)
{
switch (x)
{
case "a": return "1";
case "b": return "2";
default: return x;
}
}
?
Desired interface
y = x.replaceWhole!("a","x",
"b","y",
"c","z")
or perhaps
y = x.replaceWhole!(tuple("a","x"),
tuple("b","y"),
tuple("c","z"))
kind of like
"a".among!("a", "b", "c")
but for replacements.
It would also be nice to have a splitter that can split on any of
a number of conditions being fulfilled in a similar vein.
Lazy sort
Does sort have to be eager or would it be possible to have a lazy version? It's messy to always have to use array and leap in and out of lazy operations within a UFCS chain. Surely as many functions as possible should be optionally lazy.
Re: Lazy sort
On Friday, 11 September 2015 at 11:08:29 UTC, Ola Fosheim Grøstad wrote: On Friday, 11 September 2015 at 10:41:16 UTC, ixid wrote: Does sort have to be eager or would it be possible to have a lazy version? It's messy to always have to use array and leap in and out of lazy operations within a UFCS chain. Surely as many functions as possible should be optionally lazy. https://en.wikipedia.org/wiki/Priority_queue Yes, I was reading about heapsort. I was only thinking about the usability POV (I mean isn't reduced pretty much an eager operation that accepts a lazy input? Why can't sort do that?) but it could also offer some performance improvement if you only use a part of the sorted array.
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 16:02:42 UTC, cym13 wrote:
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought
I'd suggest this- having seen the cartesianProduct function
from std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an earth
shattering change but it makes something very common more
elegant and reduces indentation significantly for multiple
nested loops. Braces make nested loops very messy and any
significant quantity of code in the loop body benefits from
not being in a messy nesting.
...
What would you do with associative arrays?
void main() {
auto aa = [1:1, 2:2];
foreach (a, b ; aa, 1..10)
foo(a, b);
}
Prevent both iterator count and associative value variables for
foreach loops with nested loops. This behaviour of associative
arrays is already an odd case as it clashes with the iterator
behaviour for other arrays.
foreach multiple loop sugar
Though sugar seems to be somewhat looked down upon I thought I'd
suggest this- having seen the cartesianProduct function from
std.algorithm in another thread I thought it would be an
excellent piece of sugar in the language. It's not an earth
shattering change but it makes something very common more elegant
and reduces indentation significantly for multiple nested loops.
Braces make nested loops very messy and any significant quantity
of code in the loop body benefits from not being in a messy
nesting.
import std.algorithm, std.range, std.stdio;
void main() {
// Standard
foreach(i; 0..10)
foreach(j; 0..10)
foreach(k; 0..10)
writeln(i, j, k);
// Better
foreach(k, j, i; cartesianProduct(10.iota, 10.iota, 10.iota))
writeln(i, j, k);
// Sugar
foreach(k, j, i; 0..10, 0..10, 0..10)
writeln(i, j, k);
//Following brace rules
// Standard
foreach(i; 0..10)
{
foreach(j; 0..10)
{
foreach(k; 0..10)
{
writeln(i, j, k);
}
}
}
// Sugar
foreach(k, j, i; 0..10, 0..10, 0..10)
{
writeln(i, j, k);
}
}
std.array: array, ulong and Win32
This seems like a reasonable use but errors, obviously I can do it in many other ways: ulong[] result = iota(1UL, 10UL).array; Error: static assert Argument types in (ulong) are not all convertible to size_t: (ulong) C:\D\dmd2\src\phobos\std\array.d 516 And while I'm here why do arrays not implicitly cast? ulong is happy to accept uint values but ulong[] will not accept uint[].
Re: std.array: array, ulong and Win32
On Sunday, 9 August 2015 at 20:33:10 UTC, anonymous wrote: On Sunday, 9 August 2015 at 20:13:38 UTC, ixid wrote: Yup, bug. Please file an issue at http://issues.dlang.org/. It seems like bearophile beat me to it. Good to see he's still alive. https://issues.dlang.org/show_bug.cgi?id=14832
Array operations, dynamic arrays and length
int[] a = [1,1,1,1]; int[] b = [1,1,1,1]; int[] c; c[] = a[] - b[]; c.writeln; This outputs []. This feels wrong, it feels like something that should have exploded or set the length to 4. If the lengths of a and b are mismatched it throws an exception. It also throws an exception if a dynamic array is longer or a static array is not the same length but is happy when a dynamic array is shorter. Is this intended behaviour and if so why?
Re: for ranges
On Thursday, 22 January 2015 at 16:41:49 UTC, Russel Winder wrote: Playing with factorial implementations, as you do. I had a D implementation using ulong. Not sensible obviously since overflow is a bit of a problem. But the code worked, as did the tests. Now converting to BigInt and… The standard explicit iteration form uses a loop: for(i; 2..n+1) for n = 0 or 1 this loop doesn't loop since the range is [,). However for BigInt: for(i; two..n + one) the loop starts at 0 and just keeps on going. This is clearly not good. Am I having a mental breakdown or is this a real bug? In general it feels as if BigInt needs more work as it doesn't work with simple generic code in too many cases. Templates get confused by invocation with a literal and a BigInt for example when it should have a single type. Literals feel too strongly typed or too weakly implicitly convertible.
Re: import std.random fails
On Tuesday, 6 January 2015 at 20:49:34 UTC, Rene Zwanenburg wrote: On Tuesday, 6 January 2015 at 20:26:25 UTC, ixid wrote: Dmd latest non-beta, with the latest VisualD. Debug build. Debug build and no additional or non default settings. Hmm.. Did you verify that the D installation directory was completely empty after uninstalling? Does VisualD have some kind of verbose mode to show the exact command used to invoke DMD? What happens if you run rdmd on your main file? It seems to work fine with RDMD. I don't know if VisualD has a verbose mode. Would this suggest the issue is with VisualD or with DMD settings in some way?
Re: import std.random fails
On Tuesday, 6 January 2015 at 18:37:25 UTC, Rene Zwanenburg wrote:
On Monday, 5 January 2015 at 15:59:17 UTC, ixid wrote:
On Friday, 31 August 2012 at 22:52:13 UTC, Jonathan M Davis
wrote:
On Saturday, September 01, 2012 00:40:25 deed wrote:
import std.random
void main() {}
---
results in:
Error 42: Symbol Undefined
_D4core6memory2GC6qallocFkkZS4core6memory8BLkInfo_
Error 42: Symbol Undefined _D4core6memory2GC6extendFPvkkZk
Error 42: Symbol Undefined _D4core5bitop3bsrFNaNbkZi
--- errorlevel 3
What is wrong?
You druntime installation is bad due to some cruft left from
a previous
install (the installer obviously needs some work). If you
used an installer,
then uninstall dmd, make sure that it's completely removed,
and then reinstall
it.
If you installed it manually, then make sure that you blow
away druntime's
import directory and then restore it with the current version
of those files.
- Jonathan M Davis
I am having this issue now. What else would I need to do other
than uninstall and reinstall D on Windows to get it working? I
tried that and it's not fixed it. Importing std.random in my
own module which is in the project directory fails to find the
symbol while importing std.algorithm works fine. Importing
std.random in main.d works fine as well.
Error 1 Error 42: Symbol Undefined _D7objects12__ModuleInfoZ
How do you build your program? Dmd, rdmd, Dub, etc.?
Dmd latest non-beta, with the latest VisualD. Debug build. Debug
build and no additional or non default settings.
Re: import std.random fails
On Friday, 31 August 2012 at 22:52:13 UTC, Jonathan M Davis wrote:
On Saturday, September 01, 2012 00:40:25 deed wrote:
import std.random
void main() {}
---
results in:
Error 42: Symbol Undefined
_D4core6memory2GC6qallocFkkZS4core6memory8BLkInfo_
Error 42: Symbol Undefined _D4core6memory2GC6extendFPvkkZk
Error 42: Symbol Undefined _D4core5bitop3bsrFNaNbkZi
--- errorlevel 3
What is wrong?
You druntime installation is bad due to some cruft left from a
previous
install (the installer obviously needs some work). If you used
an installer,
then uninstall dmd, make sure that it's completely removed, and
then reinstall
it.
If you installed it manually, then make sure that you blow away
druntime's
import directory and then restore it with the current version
of those files.
- Jonathan M Davis
I am having this issue now. What else would I need to do other
than uninstall and reinstall D on Windows to get it working? I
tried that and it's not fixed it. Importing std.random in my own
module which is in the project directory fails to find the symbol
while importing std.algorithm works fine. Importing std.random in
main.d works fine as well.
Error 1 Error 42: Symbol Undefined _D7objects12__ModuleInfoZ
Template function type inference with default arguments
Why don't templates take a type from the default argument if
nothing else is supplied? It would be useful to be able to use an
enum to set a default.
enum MAX = 1_000;
auto sieve(T)(T max = MAX) {
import std.bitmanip : BitArray;
BitArray n;
n.length = max;
T[] primes = [2];
for(T i = 3; i max; i += 2)
if(n[i] == 0) {
primes ~= i;
for(T j = i + i; j max; j += i)
n[j] = 1;
}
return primes;
}
Changing the type to T = typeof(MAX) works but feels
unnecessarily clunky and out of step with how templates normally
operate when supplied with an argument.
Type name shadowing
T shadow(T = int)(T a) {
alias T = string;
T b = hi;
T c = 1; // Error
writeln(typeof(a).stringof); // int
writeln(typeof(b).stringof); // string
return a;
}
Are there uses for this shadowing of type names? It seems a
little dangerous, for example ulong T could be shadowed by uint
T. Is there a reason to allow it?
