Re: What's up with GDC?
On Saturday, 11 June 2016 at 04:20:38 UTC, Joerg Joergonson wrote: On Saturday, 11 June 2016 at 01:43:21 UTC, Adam D. Ruppe wrote: What's the exact message and what did you do? The opengl32.lib I have on my github is for dmd 32 bit, ldc uses the Microsoft one I think so you shouldn't need anything else. It just says the format is invalid. I used the one you supplied in the package and never worried about it. I'll try some other libs when I get a chance. OpenGL32.lib and glu32.lib are part of the Windows SDK. Assuming you've got VS 2015 installed, they should be part of the installation and should be available out of the box. Adam's lib is solely for use with OPTLINK when compiling with DMD using the default -m32 on Windows, since DMD does not ship with the opengl lib. When compiling with -m32mscoff or -m64, it will use Visual Studios libraries.
Re: What's up with GDC?
On Saturday, 11 June 2016 at 01:43:21 UTC, Adam D. Ruppe wrote: On Friday, 10 June 2016 at 22:01:15 UTC, Joerg Joergonson wrote: The problem I'm getting with ldc, using your simpledisplay, is that the libs aren't loading due to the wrong format. What's the exact message and what did you do? The opengl32.lib I have on my github is for dmd 32 bit, ldc uses the Microsoft one I think so you shouldn't need anything else. It just says the format is invalid. I used the one you supplied in the package and never worried about it. I'll try some other libs when I get a chance. BTW I make your code a bit better with resizing case WM_SIZING: goto size_changed; break; case WM_ERASEBKGND: break; Handling the erase background prevents windows from clearing the window, even with open GL. This allows resizing the window to still show the content. The only problem with it is that it seems the opengl code shifts up and down as the resize happens... It is probably an issue with the size change updates. It's pretty minor though and better than what it was(when I'd resize the window would go white and stay white as long as mouse was moving) The specific errors are opengl32.lib : warning LNK4003: invalid library format; library ignored glu32.lib : warning LNK4003: invalid library format; library ignored
Re: Asio Bindings?
On Friday, 10 June 2016 at 20:52:46 UTC, Andrej Mitrovic wrote: On 6/9/16, Joerg Joergonson via Digitalmars-d-learnwrote: [...] Just to show that I'm not full of shit, here's the e-mail chain: On 6/3/11, Andrej Mitrovic wrote: [...] On 6/7/11, Yvan Grabit wrote: [...] On 6/23/11, Andrej Mitrovic wrote: [...] On 6/23/11, Yvan Grabit wrote: [...] On 6/23/11, Andrej Mitrovic wrote: [...] Unfortunately this is the last I've heard from them at the time.. Well, I definitely didn't think you were full of shit! But I see no negative statements against doing what you did. They simply said that you can't include their code directly... they want people who download your code to have to download the sdk from Steinberg. You own your code, no one else, not even Steinberg... but you don't own or have the right, as they mention, to publish their code with yours. Creating bindings is not a license infraction. [...] Are you using any of their source code from the vst sdk? If you hand re-write any of their source code, it is yours. You say that the only two files from the sdk are aeffect.h and aeffectx.h, right? Is it these: https://github.com/falkTX/dssi-vst/blob/master/vestige/aeffectx.h https://sourceforge.net/u/geyan123d/freepiano/ci/54f876d52c6f49925495f7ed880bd2434bda0504/tree/src/vst/aeffect.h?format=raw http://www.dith.it/listing/vst_stuff/vstsdk2.4/doc/html/aeffect_8h.html https://source.openmpt.org/svn/openmpt/branches/devBranch_1_17_03/include/AEffect.h etc... If so, as you can see, people already do what your wanting to do and their is probably a reason they stopped responding, and it's because they can't do much as long as you don't include anything from them. Of course, don't take my word... maybe ask on stack overflow or something? If you are simply worried about being sued then that problem is relatively easily fixed! Just ask Walter or Andrei to fund your defense ;) Don't let your hard work go to waste! ;) I think you should be more afraid of all the questions I'll be asking you on how to use it rather than being sued by Steinberg! ;)
Re: Why can't I assign a mixin to an alias?
On Saturday, 11 June 2016 at 02:46:00 UTC, Adam D. Ruppe wrote: On Saturday, 11 June 2016 at 02:33:46 UTC, Alex Parrill wrote: Mixins are statements. No, they're not. Well, yes they are [1], but there are also mixin expressions [2]. Not to be confused with the TemplateMixin[3], which is indeed always a statement. 1: http://dlang.org/spec/grammar.html#MixinExpression 2: http://dlang.org/spec/grammar.html#MixinStatement 3: http://dlang.org/spec/grammar.html#TemplateMixin Huh, every time I've used mixins, I've always run into the issue in the OP, so I assumed they were statements. It definitely seems like a bug then.
Re: Why can't I assign a mixin to an alias?
On Saturday, 11 June 2016 at 02:33:46 UTC, Alex Parrill wrote: Mixins are statements. No, they're not. Well, yes they are [1], but there are also mixin expressions [2]. Not to be confused with the TemplateMixin[3], which is indeed always a statement. 1: http://dlang.org/spec/grammar.html#MixinExpression 2: http://dlang.org/spec/grammar.html#MixinStatement 3: http://dlang.org/spec/grammar.html#TemplateMixin
Re: Why can't I assign a mixin to an alias?
On Friday, 10 June 2016 at 22:38:29 UTC, Dechcaudron wrote: I have the following code: private string getVariableSignalWrappersName(VarType)() { return VarType.stringof ~ "SignalWrappers"; } void addVariableListener(VarType)(int variableIndex, void delegate(int, VarType)) { alias typeSignalWrappers = mixin(getVariableSignalWrappersName!VarType); } On compilation, the following error is issued: Error: basic type expected, not mixin Why should it be like that? I believe the compiler should not impose restrictions on what mixins can or cannot do :/ Mixins are statements. They cannot be a part of an expression. The other two posts have demonstrated how to get around this.
Re: Why can't I assign a mixin to an alias?
On Friday, 10 June 2016 at 22:38:29 UTC, Dechcaudron wrote: Error: basic type expected, not mixin Why should it be like that? I believe the compiler should not impose restrictions on what mixins can or cannot do :/ This might be a gratuitous grammar restriction. There are a few of those surrounding alias "targets". A template that simply returns its parameter might work, though, such as std.meta.Alias (alias foo = Alias!(mixin(…));). — David
Re: What's up with GDC?
On Friday, 10 June 2016 at 22:01:15 UTC, Joerg Joergonson wrote: The problem I'm getting with ldc, using your simpledisplay, is that the libs aren't loading due to the wrong format. What's the exact message and what did you do? The opengl32.lib I have on my github is for dmd 32 bit, ldc uses the Microsoft one I think so you shouldn't need anything else.
Re: What's up with GDC?
On Saturday, 11 June 2016 at 01:04:28 UTC, David Nadlinger wrote: Knowing Adam, though, simpledisplay probably only depends on the Win32 API, so I'm not sure where the issue would be in the first place. It also uses opengl32.lib that could be a problem. I offer the .omf file on my github for people to download... but with ldc you'd want to use whatever is packaged there (the Microsoft ones?). Or compile with -version=without_opengl and that might work too (or the LDC translation of that). Grab the newest version btw because I just noticed a bug in that version.
Re: What's up with GDC?
On Friday, 10 June 2016 at 22:01:15 UTC, Joerg Joergonson wrote: The problem I'm getting with ldc, using your simpledisplay, is that the libs aren't loading due to the wrong format. It's the omf vs coff thing or whatever, I guess... How do you mean that? LDC/MSVC uses COFF, and there should be no issues with linking against any external libraries you might need. Knowing Adam, though, simpledisplay probably only depends on the Win32 API, so I'm not sure where the issue would be in the first place. Unless, of course, you are referring to linking an LDC executable against a simpledisplay library built with DMD – the different D compilers are not ABI-compatible, and will not be for the foreseeable future. — David
Re: Why can't I assign a mixin to an alias?
On Friday, 10 June 2016 at 22:38:29 UTC, Dechcaudron wrote: I have the following code: private string getVariableSignalWrappersName(VarType)() { return VarType.stringof ~ "SignalWrappers"; } void addVariableListener(VarType)(int variableIndex, void delegate(int, VarType)) { alias typeSignalWrappers = mixin(getVariableSignalWrappersName!VarType); } On compilation, the following error is issued: Error: basic type expected, not mixin Why should it be like that? I believe the compiler should not impose restrictions on what mixins can or cannot do :/ I'm no expert, but this looks like a grammar issue more than anything else. You can work around it by moving the alias declaration into the mixin. mixin("alias typeSignalWrappers = " ~ getVariableSignalWrappersName!VarType ~ ";");
Why can't I assign a mixin to an alias?
I have the following code: private string getVariableSignalWrappersName(VarType)() { return VarType.stringof ~ "SignalWrappers"; } void addVariableListener(VarType)(int variableIndex, void delegate(int, VarType)) { alias typeSignalWrappers = mixin(getVariableSignalWrappersName!VarType); } On compilation, the following error is issued: Error: basic type expected, not mixin Why should it be like that? I believe the compiler should not impose restrictions on what mixins can or cannot do :/
Re: Parse File at compile time, but not embedded
On Tuesday, 7 June 2016 at 22:09:58 UTC, Alex Parrill wrote: Not necessarily, You chased that rabbit quite far! The data your reading could contain sensitive information only used at compile time and not meant to embed. For example, the file could contain login and password to an SQL database that you then connect, at compile time and retrieve that information the disregard the password(it is not needed at run time). Accessing a SQL server at compile time seems like a huge abuse of CTFE (and I'm pretty sure it's impossible at the moment). Why do I need to install and set up a MySQL database in order to build your software? Just mount a filesystem that uses an SQL database as storage (query can be encoded in file path) and you have it. Whether it's a good idea is another story.
Re: What's up with GDC?
On Friday, 10 June 2016 at 21:33:58 UTC, Adam D. Ruppe wrote: On Friday, 10 June 2016 at 20:30:36 UTC, Joerg Joergonson wrote: Why isn't there a proper binaries for ldc and gdc that work out of the box like dmd? There used to be. What's up with all this arm-linux-genuabi crap? Those are proper binaries that work out of the box on different platforms. Alas Windows doesn't have prebuilt binaries for gdc targeting Windows. Weird, the Windows binaries there generate ARM binaries (for phones and stuff). LDC has Win32 builds though: https://github.com/ldc-developers/ldc/releases/download/v1.0.0/ldc2-1.0.0-win32-msvc.zip The problem I'm getting with ldc, using your simpledisplay, is that the libs aren't loading due to the wrong format. It's the omf vs coff thing or whatever, I guess... I didn't feel like messing with it right now(later I'll need both x86 and x64 libs that work with dmd, ldc, and gdc). But yea, ldc basically worked similar to dmd, but not gdc.
Re: What's up with GDC?
On Friday, 10 June 2016 at 20:30:36 UTC, Joerg Joergonson wrote: Why isn't there a proper binaries for ldc and gdc that work out of the box like dmd? There used to be. What's up with all this arm-linux-genuabi crap? Those are proper binaries that work out of the box on different platforms. Alas Windows doesn't have prebuilt binaries for gdc targeting Windows. Weird, the Windows binaries there generate ARM binaries (for phones and stuff). LDC has Win32 builds though: https://github.com/ldc-developers/ldc/releases/download/v1.0.0/ldc2-1.0.0-win32-msvc.zip
Re: What's up with GDC?
On Friday, 10 June 2016 at 20:30:36 UTC, Joerg Joergonson wrote: Well, the post was a bit incoherent because getting all this stuff working is. I was searching for ldc and ran across some web site that had only the sources(same for gdc). […] Why isn't there a proper binaries for ldc and gdc that work out of the box like dmd? LDC binaries exist and work out of the box – just extract them anywhere and you are set. Have a look at the official release list: https://github.com/ldc-developers/ldc/releases I'm not sure what other website you came across; maybe there are some links that need fixing? — David
Re: What's up with GDC?
On Friday, 10 June 2016 at 20:30:36 UTC, Joerg Joergonson wrote: On Friday, 10 June 2016 at 19:51:19 UTC, Johan Engelen wrote: [...] Well, the post was a bit incoherent because getting all this stuff working is. I was searching for ldc and ran across some web site that had only the sources(same for gdc). The point of it all is that things seem to be a bit discombobulated and make D look bad. Professions won't use D if it can't be used professionally(not that I'm a pro, just saying). Why isn't there a proper binaries for ldc and gdc that work out of the box like dmd? There used to be. What's up with all this arm-linux-genuabi crap? When one opens up the archive all the files are named that way too. There is no explanation of what that means. Did some kid write this stuff in his basement or is this suppose to be serious? Do people think about the end user when creating this stuff or is it just a eureka moment "Lightbulb: Lets create some spaghetti!". I would have thought things would have gotten easier and more logical but that doesn't seem to be the case. The official download page is http://dlang.org/download.html (ldc download can be found from there) - please let us know if you find other outdated pages. You can even use the official install script for ldc and gdc too :)
Re: Asio Bindings?
On 6/9/16, Joerg Joergonson via Digitalmars-d-learnwrote: > Why would bindings have any issues with licensing? Just to show that I'm not full of shit, here's the e-mail chain: On 6/3/11, Andrej Mitrovic wrote: > Hello, > > I'm currently porting the Steinberg VST and ASIO SDKs for use with the > D programming language. I would like to know if there are any special > licensing requirements before I can publish the source code to a > public repository. > > Specifically, do I need to print out the licensing agreement PDF > document, sign it, and send it via snail-mail to Steinberg? I'm > currently unemployed, so there shouldn't be any issues from my part > with regards to signing any licensing agreements, if that's required. > > The bindings themselves won't distribute any C/C++ header or > implementation files from the SDK, as the D language can't use C > header files directly. > > > Kind regards, > Andrej Mitrovic > On 6/7/11, Yvan Grabit wrote: > Hi Andrej > > i will speak with our internal Product planning people about your > concern... > I will keep you inform about our decision as soon as we have a decision... > > Cheers > > Yvan > > Yvan Grabit mailto:y.gra...@steinberg.de > Technical Manager - Technology Group Phone: +49-40-21035125 > Steinberg Media Technologies GmbHFax : +49-40-21035300 > Neuer Hoeltigbaum 22-32, D-22143 Hamburg/Germany > http://www.steinberg.net > On 6/23/11, Andrej Mitrovic wrote: > Hello Yvan, > > I apologize if this e-mail is unnecessary and a decision is yet to be > made. If you are too busy should I try to contact one of Steinberg's > official representatives? > > I am willing to provide the source code for examination to Steinberg > if this could help verify that I'm not breaking any licensing > requirements. > > Have a nice day, > Andrej Mitrovic > On 6/23/11, Yvan Grabit wrote: > Hi > > we have examine your request, and decide due to our current VST/ASIO > license that you are not allowed to deploy/distribute a copy of the > VST/ASIO SDK (partially or full). > We will investigate a way to change our licensing for research or > educational use. > > In your concrete case, could it be not possible to ask the people you give > your source using the VST SDK (or ASIO) to download the VST-SDK (or ASIO) > (and agree the agreement) and provide a compiler macro (or something > different) which will convert the VST /ASIO interface to something D > compatible ? > > By the way how can we guaranty that the VST plugin or ASIO component > developed in D could be load by a host developed in C ? > > Cheers > > Yvan > > > Yvan Grabit mailto:y.gra...@steinberg.de > Technical Manager - Technology Group Phone: +49-40-21035125 > Steinberg Media Technologies GmbHFax : +49-40-21035300 > Neuer Hoeltigbaum 22-32, D-22143 Hamburg/Germany > http://www.steinberg.net > On 6/23/11, Andrej Mitrovic wrote: > On 6/23/11, Yvan Grabit wrote: >> In your concrete case, could it be not possible to ask the people you >> give >> your source using the VST SDK (or ASIO) to download the VST-SDK (or >> ASIO) >> (and agree the agreement) and provide a compiler macro (or something >> different) which will convert the VST /ASIO interface to something D >> compatible ? > > Yes, I believe I can do that. For ASIO, I have the following: > > - A "Loader", which is a source file made from scratch which searches > for ASIO entries in the Windows Registry and provides a class which > can load and initialize any found ASIO drivers. Through this class > user code calls functions like "canSampleRate", "outputReady", etc. > > The Loader only requires the type definitions found in the > asiosdk\common\asio.h header file. This header file can be > automatically converted to D via an existing tool, and the Loader > would then import the newly converted header file and use the type > definitions. > > The Loader requires the OpenAsio DLL that can be found here: > http://www.martinfay.com/openasio.htm > > The reason OpenAsio is required is because the ASIO COM class has the > "thiscall" calling convention which is not directly supported by the D > language. It might be possible to use inline assembler to simulate the > "thiscall" calling convention, but this would require some work on my > part to get it working. > > No other ASIO SDK file is required. > > From my current understanding, you would require me that
Re: What's up with GDC?
On Friday, 10 June 2016 at 19:51:19 UTC, Johan Engelen wrote: On Friday, 10 June 2016 at 19:37:13 UTC, Joerg Joergonson wrote: arm-linux-genuabi? arm-linux-gnueableihfqueridsofeyfh? aifh-fkeif-f-fdsskjhfkjfafaa? Rofl! and ldc requires building from sources(actually I didn't have too much trouble with installing it but it doesn't work with my libs because of the crappy coff issues that D has had since birth(it's like a tumor)). Why do you have to build from sources? Any details about the problems you see? Thanks, Johan Well, the post was a bit incoherent because getting all this stuff working is. I was searching for ldc and ran across some web site that had only the sources(same for gdc). The point of it all is that things seem to be a bit discombobulated and make D look bad. Professions won't use D if it can't be used professionally(not that I'm a pro, just saying). Why isn't there a proper binaries for ldc and gdc that work out of the box like dmd? There used to be. What's up with all this arm-linux-genuabi crap? When one opens up the archive all the files are named that way too. There is no explanation of what that means. Did some kid write this stuff in his basement or is this suppose to be serious? Do people think about the end user when creating this stuff or is it just a eureka moment "Lightbulb: Lets create some spaghetti!". I would have thought things would have gotten easier and more logical but that doesn't seem to be the case.
Re: What's up with GDC?
On Friday, 10 June 2016 at 19:37:13 UTC, Joerg Joergonson wrote: arm-linux-genuabi? arm-linux-gnueableihfqueridsofeyfh? aifh-fkeif-f-fdsskjhfkjfafaa? Rofl! and ldc requires building from sources(actually I didn't have too much trouble with installing it but it doesn't work with my libs because of the crappy coff issues that D has had since birth(it's like a tumor)). Why do you have to build from sources? Any details about the problems you see? Thanks, Johan
What's up with GDC?
version 2.062? 2.066.1? arm-linux-gnueabi arm-linux-gnueabihf ? I remember a year ago when I tried D for the first time I downloaded both gdc and ldc and everything just worked and each install was just like dmd! Now it seems like a step backwards and I'm not sure what is going on. arm-linux-genuabi? arm-linux-gnueableihfqueridsofeyfh? aifh-fkeif-f-fdsskjhfkjfafaa? Is D dead? If DMD is the reference compiler and can't be used for production code... and gdc is about 1000 versions out of date... and ldc requires building from sources(actually I didn't have too much trouble with installing it but it doesn't work with my libs because of the crappy coff issues that D has had since birth(it's like a tumor)). `Windows users should replace arm-gdcproject-linux-gnueabi-gdc with arm-gdcproject-linux-gnueabi-gdc.exe.` Why so many hoops to jump through? D is making me feel like a poodle!
Re: Parse File at compile time, but not embedded
On Friday, 10 June 2016 at 12:48:43 UTC, Alex Parrill wrote: On Thursday, 9 June 2016 at 22:02:44 UTC, Joerg Joergonson wrote: On Tuesday, 7 June 2016 at 22:09:58 UTC, Alex Parrill wrote: Accessing a SQL server at compile time seems like a huge abuse of CTFE (and I'm pretty sure it's impossible at the moment). Why do I need to install and set up a MySQL database in order to build your software? Lol, who says you have access to my software? You know, the problem with assumptions is that they generally make no sense when you actually think about them. By "I" I meant "someone new coming into the project", such as a new hire or someone that will be maintaining your program while you work on other things. In any case, this is impossible. D has no such concept as "compile-time-only" values, so any usage of a value risks embedding it into the binary. It seems that dmd does not remove the data if it is used in any way. When I started using the code, the data then appeared in the binary. The access to the code is through the following auto SetupData(string filename) { enum d = ParseData!(filename); //pragma(msg, d); mixin(d); return data; } The enum d does not have the data in it as showing by the pragma. ParseData simply determines how to build data depending on external state and uses import(filename) to get data. Since the code compiles, obviously d is a CT constant. But after actually using "data" and doing some work with it, the imported file showed up in the binary. Of course, if I just copy the pragma output and paste it in place of the first 3 lines, the external file it isn't added to the binary(since there are obviously then no references to it). So, at least for DMD, it doesn't do a good job at removing "dangling" references. I haven't tried GDC or LDC. You could probably use somethign like string ParseData(string filename)() { auto lines[] = import(splitLines(import(filename))); if (lines[0] == "XXXyyyZZZ33322211") return "int data = 3"; return "int data = 4"; } So the idea is if the external file contains XXXyyyZZZ33322211 we create an int with value 3 and if not then with 4. The point is, though, that `XXXyyyZZZ33322211` should never be in the binary since ParseData is never called at run-time. At compile time, the compiler executes ParseData as CTFE and is able to generate the mixin string as if directly typed "int data = 3;" or "int data = 4;" instead. The only difference between my code and the above is the generated string that is returned. I'm going to assume it's a dmd thing for now until I'm able check it out with another compiler.
Re: Cannot find module during separate compilation
On Friday, 10 June 2016 at 15:20:21 UTC, Satoshi wrote: Hello, I have 2 files: source/test.d: module foo.test; and source/bar.d module foo.bar; import foo.test; When I am compiling this 2 files together there is no problem. But when I compile it with -c flag (LDC) compiler thrown an error (cannot find foo/test.d) Why isn't import path resolved from module declaration when it is possible? module foo.bar; import foo.test; Compiler should know foo is the same directory in which bar is. For any module foo, the compiler will look for foo.d in the current directory or on the import path. For any module foo.bar, the compiler will look for foo/bar.d relative to the current directory or on the import path. So if you compile outside of the source directory, this breaks and you must specify an import path for the files to be found. In your case, you have the file source/bar but have named the module foo.bar. Even if you cd source before compiling, the compiler will be looking for foo/bar.d because that's what you have named the module. If you want to use separate compilation, you need to make your module names have the same name as your file names. If you do this: source/foo/bar.d source/foo/test.d Then one option is: dmd -Isource -c source/foo/bar.d And another is: cd source dmd -c foo/bar.d Assuming, of course, that bar.d imports foo.test.
isCallable and templates
Consider: import std.traits; class Foo { void bar() {} void baz()() {} } This works: static assert(isCallable!(Foo.bar)); This does not: static assert(isCallable!(Foo.baz)); However, clearly I can call baz due to IFTI (with the equivalent syntax, someFoo.baz() or someFoo.baz). Is there a way to fix this? -Steve
Cannot find module during separate compilation
Hello, I have 2 files: source/test.d: module foo.test; and source/bar.d module foo.bar; import foo.test; When I am compiling this 2 files together there is no problem. But when I compile it with -c flag (LDC) compiler thrown an error (cannot find foo/test.d) Why isn't import path resolved from module declaration when it is possible? module foo.bar; import foo.test; Compiler should know foo is the same directory in which bar is.
Re: How to cast ASCII value to char?
On Friday, 10 June 2016 at 14:27:41 UTC, Seb wrote: On Friday, 10 June 2016 at 14:20:16 UTC, TheDGuy wrote: Is it possible to cast an ascii value to char? Sure! char A = cast(char) 65; // A char a = cast(char) 97; // a and back again: ubyte b = cast(ubyte) a; // 65 In general there's also an entire module (https://dlang.org/phobos/std_ascii.html) that might help you for ASCII operations ;-) Thanks a lot!
Re: How to cast ASCII value to char?
On Friday, 10 June 2016 at 14:20:16 UTC, TheDGuy wrote: Is it possible to cast an ascii value to char? Sure! char A = cast(char) 65; // A char a = cast(char) 97; // a and back again: ubyte b = cast(ubyte) a; // 65 In general there's also an entire module (https://dlang.org/phobos/std_ascii.html) that might help you for ASCII operations ;-)
Re: How to cast ASCII value to char?
On Friday, 10 June 2016 at 14:20:16 UTC, TheDGuy wrote: Is it possible to cast an ascii value to char? Yea, basically just like that: cast(char) *sorry*
How to cast ASCII value to char?
Is it possible to cast an ascii value to char?
Re: Where are the solutions for the exercises of the dlang tour???
On Friday, 10 June 2016 at 05:31:18 UTC, Richter wrote: I've been trying to solve the exercise of the caesar encryption for practicing with arrays with no luck. I'm new to D Thanks for your help. :D 1) First of all - sorry that you couldn't find the solution. The tour is still heavily worked on, hence I opened an issue for you https://github.com/stonemaster/dlang-tour/issues/226 2) The example isn't that good, because neither loops nor ranges have been exampled before. However that being said, here's my solution to the task. It's a bit more advanced as it uses `map`, but it also shows the power of D: ``` import std.array: array; import std.algorithm: map; return input.map!((x) => cast(char) (((x - 97) + shift) % 26 + 97)).array; ``` For more info, see: https://dlang.org/phobos/std_algorithm_iteration.html#.map (I opened another issue for this - https://github.com/stonemaster/dlang-tour/issues/227) => continue to rock with D and let us know all the rough corners that you encounter. Thanks again!
Re: Mono-D for the new Xamarin Studio
On Friday, 10 June 2016 at 12:51:34 UTC, Saurabh Das wrote: I have foolishly updated my Xamarin Studio and now the D Language Binding no longer works. Is there an update to fix this? Or should I downgrade? Thanks, Saurabh Hi there, please uninstall XS and reinstall the older release http://www.monodevelop.com/download/
Re: Mono-D for the new Xamarin Studio
On Friday, 10 June 2016 at 13:36:43 UTC, Alex Bothe wrote: On Friday, 10 June 2016 at 12:51:34 UTC, Saurabh Das wrote: I have foolishly updated my Xamarin Studio and now the D Language Binding no longer works. Is there an update to fix this? Or should I downgrade? Thanks, Saurabh Hi there, please uninstall XS and reinstall the older release http://www.monodevelop.com/download/ Thanks Alex. I shall do that. Will you release an update that works on the new XS soon? Saurabh
Re: Linker error
On Friday, 10 June 2016 at 13:17:32 UTC, Steven Schveighoffer wrote: On 6/10/16 8:04 AM, Chris wrote: I get the error below with code like this: auto res = ['1', '2'].map!(a => a.to!string); dmd 2.071.0 What's wrong here? I import std.algorithm, std.range, std.array, std.conv in the module. (.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10): undefined reference to `_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ' collect2: error: ld returned 1 exit status This linker error is saying it can't find a required typeinfo initializer for std.range.interfaces.InputRange (of some type, not an expert in demangling D symbols). Generally this happens when you compile against a third-party library file but don't link to it (I think that type of symbol is stored in the module info). Your posted code has nothing to do with this, so I'm not sure this is the exact line you are having trouble with. Your posted map line should not be invoking this error at all. Have you tried Vladimir's DustMite tool? It can automatically whittle down your code into a minimal test case. https://github.com/CyberShadow/DustMite/wiki -Steve I've got it now. I remembered that it is to do with passing -allinst to the compiler. You're right, it's not `map!` as such. It's the template instantiation. However, the problem only appeared when I started to use `map!`
Re: Linker error
On 6/10/16 8:04 AM, Chris wrote: I get the error below with code like this: auto res = ['1', '2'].map!(a => a.to!string); dmd 2.071.0 What's wrong here? I import std.algorithm, std.range, std.array, std.conv in the module. (.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10): undefined reference to `_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ' collect2: error: ld returned 1 exit status This linker error is saying it can't find a required typeinfo initializer for std.range.interfaces.InputRange (of some type, not an expert in demangling D symbols). Generally this happens when you compile against a third-party library file but don't link to it (I think that type of symbol is stored in the module info). Your posted code has nothing to do with this, so I'm not sure this is the exact line you are having trouble with. Your posted map line should not be invoking this error at all. Have you tried Vladimir's DustMite tool? It can automatically whittle down your code into a minimal test case. https://github.com/CyberShadow/DustMite/wiki -Steve
Re: Linker error
On Friday, 10 June 2016 at 13:04:32 UTC, Chris wrote: It doesn't compile with `dmd file1.d file2.d` either. I'll have to look into this. Weird. looks like a clear sign of dmd versions conflict. most of the time things like that caused by some leftover from previous dmd — like old libphobos.a lying somewhere in link path, or alike. try to get link command from "dmd -v", and supply it with explicit path to correct libphobos to check if there is really something interferring.
Re: Linker error
On Friday, 10 June 2016 at 12:52:05 UTC, Chris wrote: I use dub and `dvm use 2.071.0`. hm. sorry, i can't help you with this. straight "dmd test.d" is ok, so it's probably something with dub/dvm interaction...
Re: Linker error
On Friday, 10 June 2016 at 12:12:17 UTC, ketmar wrote: On Friday, 10 June 2016 at 12:04:50 UTC, Chris wrote: I get the error below with code like this: auto res = ['1', '2'].map!(a => a.to!string); dmd 2.071.0 What's wrong here? I import std.algorithm, std.range, std.array, std.conv in the module. (.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10): undefined reference to `_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ' collect2: error: ld returned 1 exit status post the whole code and command line, please. it looks like you doing separate compilation, and forgot to put something to command line, or there is some conflict between installed compiler versions (for example, dmd and ldc, and one somehow is trying to use libphobos from another). The whole code would be too much. This, however compiles and links perfectly well: ` import std.algorithm; import std.conv : to; void main() { auto res = [1, 2, 3].map!(a => a.to!string); } ` I use dub and `dvm use 2.071.0`. The code compiled perfectly well until I used `map!` I have no clue what causes it. I even used `dub clean`
Mono-D for the new Xamarin Studio
I have foolishly updated my Xamarin Studio and now the D Language Binding no longer works. Is there an update to fix this? Or should I downgrade? Thanks, Saurabh
Re: Parse File at compile time, but not embedded
On Thursday, 9 June 2016 at 22:02:44 UTC, Joerg Joergonson wrote: On Tuesday, 7 June 2016 at 22:09:58 UTC, Alex Parrill wrote: Accessing a SQL server at compile time seems like a huge abuse of CTFE (and I'm pretty sure it's impossible at the moment). Why do I need to install and set up a MySQL database in order to build your software? Lol, who says you have access to my software? You know, the problem with assumptions is that they generally make no sense when you actually think about them. By "I" I meant "someone new coming into the project", such as a new hire or someone that will be maintaining your program while you work on other things. In any case, this is impossible. D has no such concept as "compile-time-only" values, so any usage of a value risks embedding it into the binary.
Re: Linker error
On Friday, 10 June 2016 at 12:04:50 UTC, Chris wrote: I get the error below with code like this: auto res = ['1', '2'].map!(a => a.to!string); dmd 2.071.0 What's wrong here? I import std.algorithm, std.range, std.array, std.conv in the module. (.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10): undefined reference to `_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ' collect2: error: ld returned 1 exit status post the whole code and command line, please. it looks like you doing separate compilation, and forgot to put something to command line, or there is some conflict between installed compiler versions (for example, dmd and ldc, and one somehow is trying to use libphobos from another).
Re: shared Mutex?
On 6/9/16 9:19 PM, cy wrote: On Thursday, 9 June 2016 at 20:53:38 UTC, tcak wrote: (cast()mx).lock(); I was told casting away shared when there are still references to it is a bad idea. Like, the Mutex object might get corrupted if the garbage collector tries to move it while another thread is using it. No, the GC doesn't care about shared in almost all circumstances, and certainly will not do anything different based on a cast. https://dlang.org/faq.html#casting_from_shared That is if you are going to keep it unshared. Casting away shared temporarily is almost a requirement, as nobody writes shared-aware functions for types. -Steve
Linker error
I get the error below with code like this: auto res = ['1', '2'].map!(a => a.to!string); dmd 2.071.0 What's wrong here? I import std.algorithm, std.range, std.array, std.conv in the module. (.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10): undefined reference to `_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ' collect2: error: ld returned 1 exit status
Re: operator overload for enum
On 10.06.2016 13:02, Satoshi wrote: Hello, why operator overloading is not working as a static methods through the UFCS? ... It's an arbitrary limitation. https://issues.dlang.org/show_bug.cgi?id=8062 (The specification has been updated in the meantime, it now documents the limitation explicitly. https://dlang.org/spec/operatoroverloading.html) I need overload a << operator in this way: enum PlatformID { None, Trinix, Unix, MacOS, Windows } PlatformID toPlatformID(string platform) { switch (platform.toLower()) { case "trinix": return PlatformID.Trinix; case "unix":return PlatformID.Unix; case "macos": return PlatformID.MacOS; case "windows": return PlatformID.Windows; default:return PlatformID.None; } } void opBinary(string op)(ref PlatformID plat, auto ref const string str) if (op == "<<") { plat = toPlatformID(str); } void thisIsTest() { PlatformID id; id << "x86_64"; // this is not working id.opBinary!("<<")("test"); // but this works O.K. } Yuck. This should at the very least be opAssign instead.
operator overload for enum
Hello, why operator overloading is not working as a static methods through the UFCS? I need overload a << operator in this way: enum PlatformID { None, Trinix, Unix, MacOS, Windows } PlatformID toPlatformID(string platform) { switch (platform.toLower()) { case "trinix": return PlatformID.Trinix; case "unix":return PlatformID.Unix; case "macos": return PlatformID.MacOS; case "windows": return PlatformID.Windows; default:return PlatformID.None; } } void opBinary(string op)(ref PlatformID plat, auto ref const string str) if (op == "<<") { plat = toPlatformID(str); } void thisIsTest() { PlatformID id; id << "x86_64"; // this is not working id.opBinary!("<<")("test"); // but this works O.K. }
Re: Pointer problems, changing for no reasons
ooops. that solution is provided in Ali's book. sorry for the noise.
Re: Pointer problems, changing for no reasons
On Friday, 10 June 2016 at 08:32:40 UTC, Begah wrote: In the constructor, i copied the textures to the model's inner texture array, and for some reason this caused the problem. So i needed to change to something like : this.textures.length = textures.length; foreach(i; 0..textures.length) { this.textures[i] = textures[i]; } the easier one-line solution: this.textures = textures.dup;
Re: Pointer problems, changing for no reasons
On 06/10/2016 01:32 AM, Begah wrote: > I have found the problem and i still don't understand why i was a problem : > struct Model > { > TextureType[] textures; > > this(TextureType[] textures...) { > this.textures = textures[]; > } > } Yeah, that's a bug because the argument array is on the stack and has a short lifetime. (I wish the compiler would warn about that.) As a result, this.textures is now a reference to elements that are destroyed upon constructor exit. I have some more explanation of it under the "Variadic function arguments have a short lifetime" section here: http://ddili.org/ders/d.en/parameter_flexibility.html Ali
Re: Pointer problems, changing for no reasons
On Friday, 10 June 2016 at 07:28:44 UTC, Begah wrote: On Thursday, 9 June 2016 at 19:00:42 UTC, cy wrote: I can't help but notice that loadModel is not a static member function, yet you don't seem to call it with a Model object in your "get" function. Also have a look at std.typecons.RefCounted if you want reference counted data.. loadModel is not a method, it is a function. Being a function it doesn't have a 'this' so doesn't need to be called with an object. Also, i tried using std.typecons.RefCounted but i didn't like the lack of control i had over it ( refCount is private and only has a getter method ). I have found the problem and i still don't understand why i was a problem : struct Model { TextureType[] textures; this(TextureType[] textures...) { this.textures = textures[]; } } In the constructor, i copied the textures to the model's inner texture array, and for some reason this caused the problem. So i needed to change to something like : this.textures.length = textures.length; foreach(i; 0..textures.length) { this.textures[i] = textures[i]; }
Re: Pointer problems, changing for no reasons
On Thursday, 9 June 2016 at 19:00:42 UTC, cy wrote: I can't help but notice that loadModel is not a static member function, yet you don't seem to call it with a Model object in your "get" function. Also have a look at std.typecons.RefCounted if you want reference counted data.. loadModel is not a method, it is a function. Being a function it doesn't have a 'this' so doesn't need to be called with an object. Also, i tried using std.typecons.RefCounted but i didn't like the lack of control i had over it ( refCount is private and only has a getter method ).
Re: Parse File at compile time, but not embedded
On Thursday, 9 June 2016 at 22:02:44 UTC, Joerg Joergonson wrote: Lol, who says you have access to my software? You know, the problem with assumptions is that they generally make no sense when you actually think about them. oh, yeah. it suddenly reminds me about some obscure thing. other people told me that they were able to solve the same problems with something they called "build system"...