understanding std.algorithm.mutation.fill behaivor.
Perhaps this is a stupid question, and I apologize if it is, but
why doesn't this compile:
import std.algorithm;
import std.stdio;
void main()
{
char[] array = [1, 2, 3, 4];
char value = 2;
fill(array, value);
}
if this does:
import std.algorithm;
import std.stdio;
void main()
{
int[] array = [1, 2, 3, 4];
int value = 2;
fill(array, value);
}
when the only difference is the type, and the 'fill' method is
meant to be generic?
Thanks for your time.
Re: Working with Modules
On Wednesday, 28 December 2016 at 02:12:32 UTC, pineapple wrote: On Wednesday, 28 December 2016 at 02:08:44 UTC, Guy Asking a Question wrote: import test; <---dmd choking here. You will need to use the -I option of dmd/rdmd to inform the compiler of where your `HopefullySomeDLibrary` directory is located, as well as any other places you will want to import modules from. If you're using another compiler, it should have a similar option. (Though I can't speak from experience.) Thanks. That did the trick.
Re: Working with Modules
On Wednesday, 28 December 2016 at 02:08:44 UTC, Guy Asking a Question wrote: import test; <---dmd choking here. You will need to use the -I option of dmd/rdmd to inform the compiler of where your `HopefullySomeDLibrary` directory is located, as well as any other places you will want to import modules from. If you're using another compiler, it should have a similar option. (Though I can't speak from experience.)
Re: Working with Modules
The code...
tester.d
module main;
import std.stdio;
import test; <---dmd choking here.
int main(string[] args)
{
writefln("Hello World\n");
writefln(add(a, b));
return 0;
}
test.d
module test;
int add(int a, int b)
{
return a + b;
}
Working with Modules
I am just starting up with dmd and code::blocks. Generally I have as my project structure something like this (sorry if your forum doesn't format this nicely, use the '-'es for directory nesting): ProjectA -SubProject1 -SubProject2 ProjectB -SubProject1 -SubProjectB HopefullySomeDProject -main.d Libraries -C --CLibrary1 -CPP --CPPLibrary1 -CSharp --CSharpLibrary1 -D --HopefullySomeDLibrary ---test.d Workspaces -csharp.sln -mydproject.workspace But it seems the D module system isn't playing nice with this setup. I keep getting this error: ||=== Build: Debug in tester (compiler: Digital Mars D Compiler) ===| tester.d|4|Error: module test is in file 'test.d' which cannot be read| ||=== Build failed: 1 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===| Unfortunately, neither code::blocks nor D's resources are really giving me any insight how I can make such a file structure work for me. Does D prefer more of a hierarchical structure where all libraries have to be in subdirectories? If so, how do people usually disembody the libraries from the actual projects?
Re: DMD specify VS version in sc.ini
On Tue, 27 Dec 2016 22:09:49 +, Ryan wrote: > I have a C library I want to link against that was compiled with VS > 2013. I have VS2013 and VS2015 installed. I want DMD to use the 2013 > version, since the C-runtime in 2015 is not backwards compatible. > > Looking at sc.ini I see several entries that relate to the linker, CRT, > and SDK. How do I edit these to force the use of VS 2013? > > I think I can figure out most of them except for UCRTVersion. > > Thanks, You want either LINKCMD or LINKCMD64. VS 2013 is what, 11.0? So you'd add something like: LINKCMD64=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin \x86_amd64\link.exe --Ryan
Re: CTFE difference between dmd and ldc2
On Tuesday, 27 December 2016 at 17:56:07 UTC, Stefan Koch wrote: On Tuesday, 27 December 2016 at 17:50:15 UTC, Joseph Rushton Wakeling wrote: Hello all, [ ... ] Can anyone advise what could be going wrong here? This looks like a nasty CTFE bug to me :-( Thanks & best wishes, -- Joe I doubt that this is a CTFE bug since there should be little difference in the ctfe code between ldc and dmd. That said, it is of course a possibility. Do you see the same with dmd 2.071? (that's the same front-end code as the LDC version tested) -Johan
DMD specify VS version in sc.ini
I have a C library I want to link against that was compiled with VS 2013. I have VS2013 and VS2015 installed. I want DMD to use the 2013 version, since the C-runtime in 2015 is not backwards compatible. Looking at sc.ini I see several entries that relate to the linker, CRT, and SDK. How do I edit these to force the use of VS 2013? I think I can figure out most of them except for UCRTVersion. Thanks,
Re: [question] Access from UDA constructor to parent symbol
On Monday, 26 December 2016 at 21:15:03 UTC, Adam D. Ruppe wrote:
On Monday, 26 December 2016 at 20:07:56 UTC, crimaniak wrote:
// I want to see Foo here and use it's reflection to
iterate fields and methods.
then pass foo to it
What do you mean parent symbol? I assumed you mean subclass but
your example shows one class and one struct. So is it the
structure containing the class? Or what?
But, the answer of just passing the argument is probably the
best one anyway. You can use a factory function, or pass the
type from a constructor to a super method, or something like
that.
I think he wants the symbol that the UDA is attached to.
So instead of doing:
struct attribN(I, T) { }
@attrib1!(Implement1, MyStructName)
@attrib2!(Implement2, MyStructName)
struct MyStructName
{
}
you could instead possibly add a feature to do this:
struct attribN(I, T = __UDA__)
{
}
// or possibly
class attribN(I) : Attribute // Attribute then contains the
symbol its connected to
{
}
@attrib1!Implement1
@attrib2!Implement2
struct MyStructName
{
}
Not likely a feature to be added though.
Re: Build your own Trie entry table
On Monday, 26 December 2016 at 10:12:20 UTC, Remi Thebault wrote: Hello I want to map a dchar to its Bidi_Class. I've built an utility that reads UnicodeData.txt into an AA and builds a trie with std.uni.codepointTrie from it. I use Trie.store() to export the trie entry table into a D module. (I believe in a similar manner than phobos' unicode_tables.d) Now I want to use this table to efficiently create a Trie in my code, the same way std.uni does, but found out that Trie constructor is private. I've copy-pasted the asTrie function (and also TrieEntry struct) in my code and it works well (which I don't understand because my code still ends up calling the private ctor). This must be an oversight on my part. Indeed it should be possible to store/load your own trie. Can you give indication on the workflow one should follow for this use case? Please file a bug report for Phobos basically stating your use case and the visibility problem. Thanks Rémi Dmitry Olshansky
Re: Gui programing in D
On 12/27/2016 01:47 PM, Samson Akomire wrote: I am working with GTKD for GUI Application in D programing language. D programing Language is truly wholesome in all definitions.I have a great difficulty in setting widgets width and height. I will also appreciate any direction to resources to learn GTKD. These might be use full: https://sites.google.com/site/gtkdtutorial/ http://gexperts.com/wp/category/gtk/ http://www.britseyeview.com/software/articles/gsgtkd101.html -- Mike Wey
Re: CTFE difference between dmd and ldc2
On Tuesday, 27 December 2016 at 17:56:07 UTC, Stefan Koch wrote: I doubt that this is a CTFE bug since there should be little difference in the ctfe code between ldc and dmd. That said, it is of course a possibility. I'll have a look. Thanks! It's very weird how, of the values in the `state` variable, one winds up being set correctly and the others are all zero. That might suggest that the `state` variable _is_ being set correctly and then something else is happening that zeroes out most of the values ... ?
Re: CTFE difference between dmd and ldc2
On Tuesday, 27 December 2016 at 17:50:15 UTC, Joseph Rushton Wakeling wrote: Hello all, [ ... ] Can anyone advise what could be going wrong here? This looks like a nasty CTFE bug to me :-( Thanks & best wishes, -- Joe I doubt that this is a CTFE bug since there should be little difference in the ctfe code between ldc and dmd. That said, it is of course a possibility. I'll have a look.
CTFE difference between dmd and ldc2
Hello all, I've recently been working on a port of the mir.random Mersenne Twister implementation to Phobos, and I've run into a bit of weirdness with CTFE. Specifically, I use some CTFE functionality to generate a default starting state for the generator: https://github.com/WebDrake/mersenne-twister-range/blob/dda0bb006ee4633ae4fa227f9bad1453ba0e9885/src/mersenne_twister_range.d#L126 https://github.com/WebDrake/mersenne-twister-range/blob/dda0bb006ee4633ae4fa227f9bad1453ba0e9885/src/mersenne_twister_range.d#L166 However, it turns out that while this works while compiling with the latest ldc2 beta (v1.1.0-beta6, which uses the dmd 2.071.2 frontend), it doesn't when compiled with the latest dmd master or with dmd 2.072.1 (as installed from the deb package downloaded from dlang.org). Specifically, if we look at the unittests where the generator is initialized with implicit construction, versus where the default seed is explicitly supplied: https://github.com/WebDrake/mersenne-twister-range/blob/dda0bb006ee4633ae4fa227f9bad1453ba0e9885/src/mersenne_twister_range.d#L399-L407 ... different results emerge when compiled with dmd; it turns out that in the implicit-construction case, only the `state.z` variable is set (the rest are all zeroes), whereas with the explicit seeding, all elements of the `state` variable are set correctly. When ldc2 is used, this doesn't happen and in both cases the `state` variable is set correctly. Can anyone advise what could be going wrong here? This looks like a nasty CTFE bug to me :-( Thanks & best wishes, -- Joe
Gui programing in D
I am working with GTKD for GUI Application in D programing language. D programing Language is truly wholesome in all definitions.I have a great difficulty in setting widgets width and height. I will also appreciate any direction to resources to learn GTKD.
Re: [question] Access from UDA constructor to parent symbol
On Tuesday, 27 December 2016 at 02:05:27 UTC, Ali Çehreli wrote:
On 12/26/2016 02:04 PM, crimaniak wrote:
So my main question: how it is possible to do such thing?
Just to make sure we're on the same page: :)
* There is 'interface' in addition to 'class'
Yes. I want it for structs exactly.
* If all you want is to check, then you can write template
constraints by following the example of std.range.isInputRange.
Interface implementation has a significant advantage over
template constraints for implementation break case. With
interface I have one relevant error on the implementation stage.
With template constraints I have many less relevant errors on the
usage stage. It's just different types of contract.
With that aside, what you need is generally achieved by a mixin:
@implements!I1
struct S1
{
// ...
}
template ValidateInterfaces() {
// Go through all members of the module here
// Identify the ones having the 'implements' UDA
// The useful tools here are
// __traits(getAttributes)
// __traits(allMembers)
// __traits(getMember)
}
mixin ValidateInterfaces;
Thanks, this is a way. The only problem user can forget to call
this mixin. It would be useful to have module-wide compile-time
variables, in this case it's possible to call ValidateInterfaces
one time from first @implements instance and user don't have to
write it at every module.
