Re: DIP81: Writing files at compile time
On 2015-08-13 01:27, Tofu Ninja wrote: A simple alternative to this would be a flag to the compiler to expand mixins and output the new files. This would also be great for tooling, an IDE could use this and allow you to expand a mixin in place to see what it looks like. And currently all the auto complete engines I have seen for D don't handle mixins very well. Expanding them would make autocompletion a simpler job. I agree, this is much better. I remember the old Eclipse plugin, Descent. It had a compile time view which showed how mixins where expanded and how some language features where lowered, i.e. scope to try-catch-finally. -- /Jacob Carlborg
Re: Indivisual Incremental Compalation with dub
On Thursday, 13 August 2015 at 05:42:38 UTC, Freddy wrote: I have a file that takes a while to compile with a static interface. Is there any way i can make dub keep the object file of only that file(for faster compilation)? I don't think dub itself can do this, but https://github.com/atilaneves/reggae should be able to do it. And it will parse/understand your dub configuration file.
[Issue 13567] Attribute inference for private functions
https://issues.dlang.org/show_bug.cgi?id=13567 --- Comment #5 from ZombineDev petar.p.ki...@gmail.com --- Yes, it would definitely be a step in the right direction. A lot more code will benefit from this because private functions are more common than auto-returning and also people tend to neglect putting attributes on private functions more than on public ones. --
Re: DIP81: Writing files at compile time
On Thursday, 13 August 2015 at 00:54:37 UTC, JDemler wrote: I am not sure if I understand your idea correctly: The compiler would in case of an export(name, content) write the content both to a internal database and the filesystem and then only use the internal one? Or could the content of the internal database be copied to the file system at the end of the compilation process? Or is only the output bundle written to the file system? The filesystem is a compiler issue and not a language issue, so sure, the compiler could do whatever it wants, flush everything to disk or into a SQL database or… Keep in mind that someone might want to compile on a diskless computer from an in-memory zip-file or similar. I think the important file generation that are relevant to the language would be for the output bundle, so that you e.g. can have a config file in D and generate platform specific files (.ini, .xml etc).
Re: SList container problem
On Thursday, 13 August 2015 at 08:40:13 UTC, ted wrote:
have upgraded from 2.066.1 to 2.068.0, and have a change in
behaviour:
import std.container: SList;
void main()
{
SList!int tmp;
tmp.insertAfter( tmp[], 3 );
}
used to work happily with dmd2.066.1, causes assert
(core.exception.AssertError@std/container/slist.d(57):
Assertion failure) in 2.068.0 (also 2.067.1).
There was a change in slist.d in 2.067. Am I no longer able to
start from an empty list?
--ted
tmp ~= 3; ?
[Issue 14911] Compiler found indexing in code new MyStruct[2].ptr
https://issues.dlang.org/show_bug.cgi?id=14911 --- Comment #1 from Sobirari Muhomori dfj1es...@sneakemail.com --- Oh, did it work? AFAIK, D grammar never allowed to parse (new A.B) as (new A).B, that would require semantic analysis before parsing. --
Re: D for Game Development
On Wednesday, 12 August 2015 at 14:57:17 UTC, jmh530 wrote: Regardless, my point is more about the importance of a seamless installation on Windows than necessarily about what is required or not. This isn't unique to D. I just tried to install the Clang Windows binary and I got a message about MSVC integration failing. I have Visual Express 2008, The express versions of Visual Studio do not include everything needed to do Windows development. You also need download a version of the Windows SDK. My recommendation is that you just uninstall the Express version and install Visual Studio Community 2013. Then go ahead and remove every trace of DMD from your system. Make sure it's not in your system PATH. After that, download the latest installer and run it. It will find your VS installation automatically and will configure sc.ini appropriately. It has worked for me every time I've tried it. I don't think DMD is able to work with 2015 just yet, because of the C Runtime changes. I had trouble with it when VS 2015 was first released, so I deleted it and reverted to 2013.
Re: DIP81: Writing files at compile time
On Thursday, 13 August 2015 at 04:58:06 UTC, Rikki Cattermole wrote: [...] So in the vibe.d example we would generate a file diet.di which would include all the generated diet templates of the whole project? Maybe 100 * 50 extra lines of code for a medium sized project? This is not debuggable, understandable or transparent. Especially because the generated code lies inside a file of a library which I should not need to know about. Also I do not understand how we could expand template instatiations. Maybe it would be possible for basic templates that only take types but imagine a template that takes a parse tree as a value. How would an expanded version of that look like?
Re: D for Game Development
On Wednesday, 12 August 2015 at 13:32:10 UTC, kink wrote: Afaik DMD for Win64 requires the MS linker, so good luck without Visual Studio then. Same goes for LDC on Win64, although an LLVM COFF linker is under development. Serious system programming on Windows without MSVC and its C runtime? Not really an option; MinGW appears to be a dead end and never really fitted the Windows eco-system. MSVC toolchain is required to link 3rd-party C++ code compiled with MSVC, mingw links c runtime just fine.
Re: DIP81: Writing files at compile time
On 13/08/2015 7:57 p.m., JDemler wrote: On Thursday, 13 August 2015 at 04:58:06 UTC, Rikki Cattermole wrote: [...] So in the vibe.d example we would generate a file diet.di which would include all the generated diet templates of the whole project? Maybe 100 * 50 extra lines of code for a medium sized project? This is not debuggable, understandable or transparent. Especially because the generated code lies inside a file of a library which I should not need to know about. If it is done via D interface files, you would be in control of where it lands. It would not go into a dub package directory that you do not control for your project. You want it to be debuggable, this is. Is it nice and pretty? No. If you are interested in only one code path i.e. specific template arguments to outputted and not the others, then perhaps a pragma can be used to limit it. Also I do not understand how we could expand template instatiations. Maybe it would be possible for basic templates that only take types but imagine a template that takes a parse tree as a value. How would an expanded version of that look like? Template if statement. Also argument overloads. Also remember, the information must exist to expand it. If it didn't, we sure couldn't generate assembly.
SList container problem
have upgraded from 2.066.1 to 2.068.0, and have a change in behaviour:
import std.container: SList;
void main()
{
SList!int tmp;
tmp.insertAfter( tmp[], 3 );
}
used to work happily with dmd2.066.1, causes assert
(core.exception.AssertError@std/container/slist.d(57): Assertion failure)
in 2.068.0 (also 2.067.1).
There was a change in slist.d in 2.067. Am I no longer able to start from
an empty list?
--ted
Re: Where will D sit in the web service space?
On Wednesday, 12 August 2015 at 22:17:11 UTC, rsw0x wrote: Rust is also backed by a major organization. I(and others from what it seemed) was hoping Facebook using D internally and hiring major D developers would have Facebook promote/champion D a bit, but this did not happen. D needs a major corporation to champion it. Yes, well. Java caught on because it was heavily marketed as THE web-programming language by SUN. That might not be how it is used today, but that is what got it attention and traction. C++ was essentially a cost-free upgrade for existing C-code bases that provided more scalable abstraction mechanisms. So C++/OO was heavily pushed by magazines as the next big thing (this was before templates). Maybe you need an organization, not sure. If it is commercial then people might not want to contribute so it can work both ways. I think people have been quite reluctant to jump in on Google-owned open source projects. Mozilla is perceived as a non-profit, so it's good. So, I think being the best tool in your domain makes people more inclined to contribute. It makes business sense to improve the tooling you use in production. Most languages that are recognized as serious had a domain where they were perceived as the only good option when they got picked up: - C++ had existing C code bases as their domain. - Java had the web as their domain. - Ada had government contractors as their domain. - Javascript had browsers as their domain. - Lua had game scripting as the domain. - Delphi had rapid prototyping/development as a domain. - Haskell had language research as the domain. etc.
Re: DIP81: Writing files at compile time
On Thursday, 13 August 2015 at 09:52:02 UTC, JDemler wrote: This solves the concurrency problem. But what about non concurrent compiler runs? A block there would never be resolved. I do not know enough about compilers to judge this problem. Can a sane way of compiling the files be found easily? Can the compiler switch to compile something else when it is blocked on an import? You need a highly concurrent compiler. If you import in one definition and export in the next definition, then the first one would block and be queued, and the compiler would move on to the next definition. In the actor-model (co-routines/fibers) each definition will spawn a new actor. And I do not understand why you differentiate between generated source files and generated non source files (.xml, .ini). As both types can be imported (or read at compile time) I do not think we should treat them differently. Also we would need a way to tell the one from the other (file extension? different parameter in the export syntax?). In my understanding storage area 2 and 3 should be merged. Area 2 is pre-populated with area 1, so they are the same. You need to be able to tell the compiler what files should be included in the output bundle. Actually, I think the file-model is too simple. I think you need a more advanced key-value database so that you can update different fields in the same .ini file from different source files.
[Issue 14911] Compiler found indexing in code new MyStruct[2].ptr
https://issues.dlang.org/show_bug.cgi?id=14911 --- Comment #4 from Kenji Hara k.hara...@gmail.com --- (In reply to kdmult from comment #3) (In reply to Sobirari Muhomori from comment #1) Oh, did it work? AFAIK, D grammar never allowed to parse (new A.B) as (new A).B, that would require semantic analysis before parsing. http://dlang.org/changelog.html#postfix-new Until 2.067, compiler parser had recognized `MyStruct[2].` for the new-ed type, and `.ptr` was parsed as dot-identifier expression. In 2.068, the issue 1215 fix had (accidentally) changed parser behavior, to make the whole part of `MyStruct[2].ptr` as the new-ed type. Then semantic analysis is failing to find such the type. --
[Issue 14911] Compiler found indexing in code new MyStruct[2].ptr
https://issues.dlang.org/show_bug.cgi?id=14911 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86_64 |All OS|Windows |All --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4876 --
[Issue 14911] Compiler found indexing in code new MyStruct[2].ptr
https://issues.dlang.org/show_bug.cgi?id=14911 --- Comment #3 from kdmult kdm...@ya.ru --- (In reply to Sobirari Muhomori from comment #1) Oh, did it work? AFAIK, D grammar never allowed to parse (new A.B) as (new A).B, that would require semantic analysis before parsing. http://dlang.org/changelog.html#postfix-new --
new release doesn't work as advertised
trying to compile the minimal console application generated by visuald: Building Debug\ConsoleApp1.exe... LINK : fatal error LNK1104: cannot open file 'libucrtd.lib' Building Debug\ConsoleApp1.exe failed! win10 - vs2015
Re: new release doesn't work as advertised
On Thursday, 13 August 2015 at 10:40:08 UTC, learn wrote: trying to compile the minimal console application generated by visuald: Building Debug\ConsoleApp1.exe... LINK : fatal error LNK1104: cannot open file 'libucrtd.lib' Building Debug\ConsoleApp1.exe failed! win10 - vs2015 This error has nothing to do with the new D release. For help with visuald please try the learn section here: http://forum.dlang.org/group/learn
[Issue 14901] [reg 2.067/2.068] template static shared this() run multiple times with separate compilation
https://issues.dlang.org/show_bug.cgi?id=14901 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, wrong-code Hardware|x86 |All OS|Mac OS X|All --
vs2015 linker error
trying to comile the minimal console application generated by visuald: Building Debug\ConsoleApp1.exe... LINK : fatal error LNK1104: cannot open file 'libucrtd.lib' Building Debug\ConsoleApp1.exe failed!
Re: DIP81: Writing files at compile time
On Thursday, 13 August 2015 at 06:53:14 UTC, Jacob Carlborg wrote: On 2015-08-13 01:27, Tofu Ninja wrote: A simple alternative to this would be a flag to the compiler to expand mixins and output the new files. This would also be great for tooling, an IDE could use this and allow you to expand a mixin in place to see what it looks like. And currently all the auto complete engines I have seen for D don't handle mixins very well. Expanding them would make autocompletion a simpler job. I agree, this is much better. I remember the old Eclipse plugin, Descent. It had a compile time view which showed how mixins where expanded and how some language features where lowered, i.e. scope to try-catch-finally. This would be great but we would need some support for the formatting I think, mixin code tends to be a mess, it would be nice to have some basic auto indent or general FMT style support.
[Issue 14914] New: Inconsistent alias declaration could be detected
https://issues.dlang.org/show_bug.cgi?id=14914
Issue ID: 14914
Summary: Inconsistent alias declaration could be detected
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bb.t...@gmx.com
It's possible to alias a method from one class instance in another one but the
declaration is actually unusable. Example:
---
class Foo
{
void something(size_t param){}
}
class Bar
{
private Foo foo;
this(){foo = new Foo;}
alias somethingelse0 = foo.something;
//alias somethingelse1 = typeof(foo).something;// equivalent
}
void main(string[] args)
{
auto bar = new Bar;
bar.somethingelse0(0);
}
---
'Bar.somethingelse0' or 'Bar.somethingelse1' are indeed methods but they are
not callable.
To be more clear, the problem is that the alias declaration is legal but it
cannot be used.
--
Re: std.data.json formal review
Am 11.08.2015 um 19:08 schrieb Atila Neves: On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote: Start of the two week process, folks. Code: https://github.com/s-ludwig/std_data_json Docs: http://s-ludwig.github.io/std_data_json/ Atila I forgot to give warnings that the two week period was about to be up, and was unsure from comments if this would be ready for voting, so let's give it another two days unless there are objections. Atila I think we really need to have an informal pre-vote about the BigInt and DOM efficiency vs. functionality issues. Basically there are three options for each: 1. Keep them: May have an impact on compile time for big DOMs (run time/memory consumption wouldn't be affected if a pointer to BigInt is stored). But provides an out-of-the-box experience for a broad set of applications. 2. Remove them: Results in a slim and clean API that is fast (to run/compile), but also one that will be less useful for certain applications. 3. Make them CT configurable: Best of both worlds in terms of speed, at the cost of a more complex API. 4. Use a string representation instead of BigInt: This has it's own set of issues, but would also enable some special use cases [1] [2] ([2] is also solved by BigInt/Decimal support, though). I'd also like to postpone the main vote, if there are no objections, until the question of using a general enum based alternative to Algebraic is answered. I've published an initial candidate for this now [3]. These were, AFAICS, the only major open issues (a decision for an opt() variant would be nice, but fortunately that's not a fundamental decision in any way). There is also the topic of avoiding any redundancy in symbol names, which I don't agree with, but I would of course change it if the inclusion depends on that. [1]: https://github.com/rejectedsoftware/vibe.d/issues/431 [2]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/10098/ [3]: http://code.dlang.org/packages/taggedalgebraic
Re: Code Reviewer
On Wednesday, 12 August 2015 at 13:14:04 UTC, sigod wrote: On Tuesday, 11 August 2015 at 22:50:52 UTC, Clayton wrote: Hello everyone, Am looking for someone who could help review my code . As an entry exercise to D am converting 3 C implementations of popular pattern matching algorithms. The idea is to have 6 final implementations ( 3 compile-time and 3 runtime) . I think am basically done with the coding, but being a beginner myself, I feel I need some do some critics so I can improve (especially on the compiletime ones). I could have uploaded direct but I think the code may be way too long. Help will be dearly appreciated. Use this site: http://codereview.stackexchange.com/ Thanks sigod, I have also put the compiletime code here : http://dpaste.dzfl.pl/f0bec44f859e
Re: Code Reviewer
On Wednesday, 12 August 2015 at 12:14:20 UTC, Rikki Cattermole wrote: On 13/08/2015 12:09 a.m., Clayton wrote: On Wednesday, 12 August 2015 at 02:49:59 UTC, Rikki Cattermole wrote: On 12/08/2015 10:50 a.m., Clayton wrote: [...] Upload to e.g. Github/gist/pastebin. Hi Rikki, can I have your email so I add you to my repository on BitBucket? No need, as long as it is not propriety code feel free to post the links :) That way anybody who is willing to comment can. Thanks , I have put the compiletime code here : http://dpaste.dzfl.pl/f0bec44f859e
[Issue 14915] New: can't build phobos-release
https://issues.dlang.org/show_bug.cgi?id=14915 Issue ID: 14915 Summary: can't build phobos-release Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: regression Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: ag0ae...@gmail.com $ make -f posix.mak phobos-release From https://github.com/D-Programming-Language/dmd * branchHEAD - FETCH_HEAD LATEST=2.068.0 -- place in the command line to skip network traffic. make --directory=../dmd-2.068.0/src -f posix.mak -j 4 make[1]: *** ../dmd-2.068.0/src: No such file or directory. Stop. posix.mak:338: recipe for target '../dmd-2.068.0/src/dmd' failed make: *** [../dmd-2.068.0/src/dmd] Error 2 Introduced by https://github.com/D-Programming-Language/dlang.org/pull/1050 --
Re: DIP81: Writing files at compile time
On Thursday, 13 August 2015 at 08:19:15 UTC, Ola Fosheim Grøstad wrote: On Thursday, 13 August 2015 at 00:54:37 UTC, JDemler wrote: I am not sure if I understand your idea correctly: The compiler would in case of an export(name, content) write the content both to a internal database and the filesystem and then only use the internal one? Or could the content of the internal database be copied to the file system at the end of the compilation process? Or is only the output bundle written to the file system? The filesystem is a compiler issue and not a language issue, so sure, the compiler could do whatever it wants, flush everything to disk or into a SQL database or… Keep in mind that someone might want to compile on a diskless computer from an in-memory zip-file or similar. I think the important file generation that are relevant to the language would be for the output bundle, so that you e.g. can have a config file in D and generate platform specific files (.ini, .xml etc). To summarize: We would have a central registry handling all the generated and non generated files. If an import is triggered, this registry is then searched for the imported file. If this file does not already exist, the import blocks. Writing these generated files to the file system would be optional, triggered by a compiler switch and happen after the compilation process is complete. This solves the concurrency problem. But what about non concurrent compiler runs? A block there would never be resolved. I do not know enough about compilers to judge this problem. Can a sane way of compiling the files be found easily? Can the compiler switch to compile something else when it is blocked on an import? And I do not understand why you differentiate between generated source files and generated non source files (.xml, .ini). As both types can be imported (or read at compile time) I do not think we should treat them differently. Also we would need a way to tell the one from the other (file extension? different parameter in the export syntax?). In my understanding storage area 2 and 3 should be merged.
[Issue 14904] bad error message in reduce: 'Incompatible function/seed/element'
https://issues.dlang.org/show_bug.cgi?id=14904 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||diagnostic Component|dmd |phobos Hardware|x86 |All --- Comment #1 from Kenji Hara k.hara...@gmail.com --- This is a diagnostic regression introduced in Phobos change: https://github.com/D-Programming-Language/phobos/pull/2060 --
[Issue 14904] [REG2.067.0] bad error message in reduce: 'Incompatible function/seed/element'
https://issues.dlang.org/show_bug.cgi?id=14904 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Summary|bad error message in|[REG2.067.0] bad error |reduce: 'Incompatible |message in reduce: |function/seed/element' |'Incompatible ||function/seed/element' --
Re: new release doesn't work as advertised
On 13/08/2015 10:44 p.m., Gary Willoughby wrote: On Thursday, 13 August 2015 at 10:40:08 UTC, learn wrote: trying to compile the minimal console application generated by visuald: Building Debug\ConsoleApp1.exe... LINK : fatal error LNK1104: cannot open file 'libucrtd.lib' Building Debug\ConsoleApp1.exe failed! win10 - vs2015 This error has nothing to do with the new D release. For help with visuald please try the learn section here: http://forum.dlang.org/group/learn It was posted there. It's a known issue. Currently no fix for VS2015. However it is being worked upon. Use 2013 instead.
Re: Code Reviewer
On 12/08/2015 10:50 a.m., Clayton wrote:
Hello everyone,
Am looking for someone who could help review my code . As an entry
exercise to D am converting 3 C implementations of popular pattern
matching algorithms. The idea is to have 6 final implementations ( 3
compile-time and 3 runtime) . I think am basically done with the coding,
but being a beginner myself, I feel I need some do some critics so I can
improve (especially on the compiletime ones).
I could have uploaded direct but I think the code may be way too long.
Help will be dearly appreciated.
http://dpaste.dzfl.pl/f0bec44f859e
- COMPILETIME_BM_PRE does it really need to be all caps?
- initialisebmBc interesting naming convention that
- Could do with a format (Mono-D supports this)
- ~~
void suffixes(S, I, int i:-1)(S pattern, ref int[size] suff, I size,
ref I f, ref int g){
}
void main() {
int a;
suffixes(, null, 0, a, a);
}
~
/d481/f560.d(1): Error: undefined identifier size, did you mean alias
size_t?
/d481/f560.d(5): Error: template f560.suffixes cannot deduce function
from argument types !()(string, typeof(null), int, int, int), candidates
are:
/d481/f560.d(1):f560.suffixes(S, I, int i : -1)(S pattern, ref
int[size] suff, I size, ref I f, ref int g)
Final dummy code I could get working:
~~
void suffixes(S, I, int i:-1)(S pattern, ref int[] suff, I size, ref I
f, ref int g){
}
void main() {
int a, c;
int[] b;
suffixes!(string, int, -1)(, b, 0, a, c);
}
~~
Irk, that -1 should be inside a template if condition no there and
certainly not using the colon.
Also size must be passed in at compile time if being used in the static
array like that. Otherwise pass it via a dynamic array like that.
Currently it is really ugly. Format it. Mono-D can do this.
Fix up those template arguments and function arguments. They are all wrong.
There is no way that should compile.
Re: DIP81: Writing files at compile time
On 13-Aug-2015 02:27, Tofu Ninja wrote: On Wednesday, 12 August 2015 at 18:37:40 UTC, JDemler wrote: Triggered by the original forum thread I wrote a DIP to further explain the idea of the writing files at compile time feature and its implications. http://wiki.dlang.org/DIP81 Please discuss! The benefits of this I see are debugging, actually having the generated files makes it much simpler to see what is going wrong. Otherwise the utility of this can be achieved with string mixins. pragma(msg, your_mixin); A simple alternative to this would be a flag to the compiler to expand mixins and output the new files. This would also be great for tooling, an IDE could use this and allow you to expand a mixin in place to see what it looks like. And currently all the auto complete engines I have seen for D don't handle mixins very well. Expanding them would make autocompletion a simpler job. I agree with Ola, something more restricted then filesystem is required. -- Dmitry Olshansky
[Issue 14903] Destructors for arguments completely broken
https://issues.dlang.org/show_bug.cgi?id=14903 David Nadlinger c...@klickverbot.at changed: What|Removed |Added Severity|major |critical --
[Issue 14903] Destructors for arguments completely broken
https://issues.dlang.org/show_bug.cgi?id=14903
--- Comment #7 from David Nadlinger c...@klickverbot.at ---
This patch should fix the issue where no dtors are run at all:
—
--- a/dmd2/expression.c
+++ b/dmd2/expression.c
@@ -1889,10 +1889,7 @@ bool functionParameters(Loc loc, Scope *sc, TypeFunction
*tf,
}
}
}
-if (anythrow i == lastthrow)
-{
-appendToPrefix = false;
-}
+
if (appendToPrefix) // don't need to add to prefix until there's
something to destruct
{
Identifier *idtmp = Identifier::generateId(__pfx);
@@ -1901,8 +1898,14 @@ bool functionParameters(Loc loc, Scope *sc, TypeFunction
*tf,
tmp-semantic(sc);
/* Modify the destructor so it only runs if gate==false
+ * We immediately set the gate to true after the last throwing
argument
+ * has been constructed, so we can directly fold away the
check.
*/
-if (tmp-edtor)
+if (i == lastthrow)
+{
+tmp-edtor = NULL;
+}
+else if(tmp-edtor)
{
Expression *e = tmp-edtor;
e = new OrOrExp(e-loc, new VarExp(e-loc, gate), e);
// (gate || destructor)
—
Previously, the gate was set to true before the last throwing argument, which
is obviously wrong if it indeed throws.
Don't have time to turn this into a proper DMD PR myself at the moment, though.
--
Re: Structs and compiletime evaluation
On Thursday, 13 August 2015 at 12:21:44 UTC, Rikki Cattermole
wrote:
On Thursday, 13 August 2015 at 12:07:48 UTC, D_Learner wrote:
I am having this struct :-
struct COMPILETIME_BM_PRE
{
void initialisebmBc(S,C,I,int k)( const S pattern ,ref
I[C] bmBc){
static if ( k ASIZE ){
bmBc[ALPHABET[k]] = size;
initialisebmBc!(S,C,I,k+1)( pattern ,bmBc);
}
}
void initialisebmBc(S,C,I,int k : ASIZE)( const S
pattern ,ref I[C] bmBc){}
[...]
No it wouldn't be. It's declared for runtime usage. Not compile
time.
Also bmBc isn't declared as an enum (can't be in fact, bug with
AA's). So even if bmh was accessible, bmBc isn't.
Thanks Rikki, but what do you mean by AA's ?
The Bug Tracker is a community tool
A little bit of bikeshedding, which irritates me every time I go file a bug: IMHO, the bugzilla link (Bug Tracker) should be under the Community section and not under the Resources section. Note that, for instance, the review queue is in the community section, and both have similar functions, compared with something like the glossary, which does make sense to be in the resources section.
Re: Structs and compiletime evaluation
On Thursday, 13 August 2015 at 12:07:48 UTC, D_Learner wrote:
I am having this struct :-
struct COMPILETIME_BM_PRE
{
void initialisebmBc(S,C,I,int k)( const S pattern ,ref
I[C] bmBc){
static if ( k ASIZE ){
bmBc[ALPHABET[k]] = size;
initialisebmBc!(S,C,I,k+1)( pattern ,bmBc);
}
}
void initialisebmBc(S,C,I,int k : ASIZE)( const S pattern
,ref I[C] bmBc){}
[...]
No it wouldn't be. It's declared for runtime usage. Not compile
time.
Also bmBc isn't declared as an enum (can't be in fact, bug with
AA's). So even if bmh was accessible, bmBc isn't.
Structs and compiletime evaluation
I am having this struct :-
struct COMPILETIME_BM_PRE
{
void initialisebmBc(S,C,I,int k)( const S pattern ,ref I[C]
bmBc){
static if ( k ASIZE ){
bmBc[ALPHABET[k]] = size;
initialisebmBc!(S,C,I,k+1)( pattern ,bmBc);
}
}
void initialisebmBc(S,C,I,int k : ASIZE)( const S pattern
,ref I[C] bmBc){}
void calculatebmBc(S,C,I,int i)( const S pattern ,ref I[C]
bmBc)
{
static if ( i size -1 )
bmBc[pattern[i]] = size -i-1;
calculatebmBc!(S,C,I,i+1)(pattern ,bmBc);
}
I[C] preBmBc(S ,C,I)( const S pattern ,ref I[C] bmBc){
this.initialisebmBc!(S,C,I,0)( pattern ,bmBc);
this.calculatebmBc!(S,C,I,0)(pattern ,bmBc);
return bmBc;
}
}
In another module I use the struct as below :-
int[char] bmBc;
COMPILETIME_BM_PRE bmh ;
enum bmBc1 = bmh.preBmBc!(string ,char,int)( pattern , bmBc);
On last line , I get the error message : `Error: variable bmh
cannot be read at compile time` , yet I thought this value would
be evaluated at compiletime.
Re: DDT 0.13.0 released - DUB configurations support.
On 11/08/2015 19:06, Colin wrote: On Tuesday, 11 August 2015 at 17:03:35 UTC, Bruno Medeiros wrote: A new DDT release (nicknamed Candy Kingdom ) is out, please read the changelog: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.13.0 This is Release Candidate quality, there might be a few undiscovered bugs with the recently introduced functionality. Great work! Thanks. Is the next one going to be Ice Kingdom? Ha, I think I'll stick with one fandom at a time :) TBH, with short release iterations, it very rarely feels right to give a nickname to a release, since now they usually have only a few changes. (This has even prompted me to blog about it here: http://www.pureconcepture.blogspot.co.uk/2015/08/for-me-one-disadvantage-of-short.html :p ) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: std.data.json formal review
On Thursday, 13 August 2015 at 03:44:14 UTC, Walter Bright wrote: On 8/12/2015 10:10 AM, deadalnix wrote: Thing is, the schema is not always known perfectly? Typical case is JSON used for configuration, and diverse version of the software adding new configurations capabilities, or ignoring old ones. Hah, I'd like to replace dmd.conf with a .json file. Not .json! No configuration file should be in a format that doesn't support comments.
[Issue 14879] tuple documentation broken link
https://issues.dlang.org/show_bug.cgi?id=14879 --- Comment #2 from ag0ae...@gmail.com --- (In reply to ag0aep6g from comment #1) https://github.com/D-Programming-Language/dlang.org/pull/1052 Superseded by https://github.com/D-Programming-Language/dlang.org/pull/1064 --
[Issue 14916] New: opDispatch: no property error for parameter type mismatch
https://issues.dlang.org/show_bug.cgi?id=14916
Issue ID: 14916
Summary: opDispatch: no property error for parameter type
mismatch
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: l...@luismarques.eu
unittest // getter is fine
{
struct S
{
auto opDispatch(string name)()
{
return 42;
}
}
S s;
s.foo;
}
unittest // setter is fine
{
struct S
{
void opDispatch(string name)(ushort value)
{
}
}
S s;
s.foo = 42; // fine
long x = 42;
s.foo = x; // correct error: not callable using argument types (long)
}
unittest // getter and setter... bug: misleading error
{
struct S
{
auto opDispatch(string name)()
{
return 42;
}
void opDispatch(string name)(ushort value)
{
}
}
S s;
s.foo = 42; // fine
long x = 42;
s.foo = x; // *wrong* error: no property 'foo' for type 'S'
}
--
Re: Structs and compiletime evaluation
On 14/08/2015 12:48 a.m., D_Learner wrote:
On Thursday, 13 August 2015 at 12:21:44 UTC, Rikki Cattermole wrote:
On Thursday, 13 August 2015 at 12:07:48 UTC, D_Learner wrote:
I am having this struct :-
struct COMPILETIME_BM_PRE
{
void initialisebmBc(S,C,I,int k)( const S pattern ,ref I[C]
bmBc){
static if ( k ASIZE ){
bmBc[ALPHABET[k]] = size;
initialisebmBc!(S,C,I,k+1)( pattern ,bmBc);
}
}
void initialisebmBc(S,C,I,int k : ASIZE)( const S pattern
,ref I[C] bmBc){}
[...]
No it wouldn't be. It's declared for runtime usage. Not compile time.
Also bmBc isn't declared as an enum (can't be in fact, bug with AA's).
So even if bmh was accessible, bmBc isn't.
Thanks Rikki, but what do you mean by AA's ?
Associative Array.
Other names e.g. map.
Nested public imports - bug or feature?
Right now this works:
``D
struct Std
{
public import std.stdio;
}
void main()
{
Std.writeln(Nice!);
}
```
I want to use it as an import hygiene idiom but not entirely sure
if this behavior can be relied upon (or it is just a side effect
of imports being implemented as aliases currently).
Re: Where will D sit in the web service space?
On Tuesday, 14 July 2015 at 15:17:13 UTC, Sebastiaan Koppe wrote: On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad wrote: What do you think about the future for D in the web service space? What about this question: in 5 years from now what would be the reason D failed? These come to my mind: Tooling Marketing Talent Pool (companies not willing to adopt) That is not going to happen. Maturity is the priority here. After that, boom!
Re: Where will D sit in the web service space?
On Wednesday, 15 July 2015 at 06:57:36 UTC, Sebastiaan Koppe wrote: When I think about Web services and D, I don't think about just repeating what people do in other languages, but more about anticipating the future in web services. With my humble knowledge of the field that would be something with micro services and containers. If D can do something cool with that, e.g. a web application framework where services sit behind a vibe-d web server, and where they can be easily developed, tested, deployed and upgraded - with 0 downtime - that would be great. Combine it with a knowledgeable community and some good practices (e.g. 12factor apps) and you can have a honey-pot. I don't think people care as much about the other stuff (gc, etc). Yeah, no one cares about GC considering the benefits and uplifted burden :)
Re: Attributes not propagating to objects via typeinfo?
On Thursday, 13 August 2015 at 03:46:19 UTC, rsw0x wrote:
Sample code:
class C{}
struct S{}
void main(){
import std.stdio;
auto c = new shared C();
auto s = new shared S();
writeln(typeid(c)); //modulename.C
writeln(typeid(s)); //shared(modulename.S)*
writeln(typeid(c).next); //null
writeln(typeid(s).next); //shared(modulename.S)
writeln(typeid(typeid(s).next) is typeid(TypeInfo_Shared));
//true
writeln(typeid(typeid(c)) is typeid(TypeInfo_Shared));
//false
}
What's the reason that the shared propagates to the typeinfo
for the struct, but not for the class declaration?
bump, is this working as intended?
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 13:12:44 UTC, Dicebot wrote:
Right now this works:
``D
struct Std
{
public import std.stdio;
}
void main()
{
Std.writeln(Nice!);
}
```
I want to use it as an import hygiene idiom but not entirely
sure if this behavior can be relied upon (or it is just a side
effect of imports being implemented as aliases currently).
Well, that's pretty much why splitting up a module and putting
public imports in its package.d file doesn't break any of the
cases where someone types out the full import path when referring
to something from that module/package. But I doubt that anyone
considered that that would have this effect when you have a
scoped import. In fact, to be honest, it never occurred to me
that it would be legal to have a scoped, public import. I think
that you just hit a weird result of how allowing imports to be
put everywhere ended up working.
I confess that I don't particularly like that this is legal (and
I think that public imports tend to get a bit hinky because of
the fact that they create aliases), and I'm not quite sure how
you could use it form import hygiene, but I also don't see how
this could work any other way if scoped, public imports are
allowed.
- Jonathan M Davis
Re: Where will D sit in the web service space?
On Tuesday, 14 July 2015 at 16:25:29 UTC, Ola Fosheim Grøstad wrote: I think neither, but what I have alluded to in this thread. A lack of decision making regarding picking an application domain that is large enough to sustain an ecosystem of libraries, and going 100% for honing the feature set towards that domain. Possible is not good enough. I think the rest comes when you have the best feature set for a particular domain and a polished compiler/runtime. So yeah, maybe Game clients is the best bet, since you don't have to change the semantics too much (low latency GC and linear typing would take time to work in) and games benefits from C++/iOS interop. Indie games have low adoption threshold and could work as marketing. The Gaming industry is quiet a path to go on. Expecially since no language actually focus on that area. For now, I see some new projects making good moves to writing gaming tools (I dislike bindings to C++).
[Issue 14917] New: typeid(x) is typeid(y) returns different results during ctfe
https://issues.dlang.org/show_bug.cgi?id=14917
Issue ID: 14917
Summary: typeid(x) is typeid(y) returns different results
during ctfe
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: joeyemm...@yahoo.com
void main()
{
class A{}
class B:A {}
bool test(A a)
{
if(typeid(a) is typeid(B)) return true;
return false;
}
bool rt = test(new B()); // TRUE
enum ct = test(new B()); // FALSE
assert(rt == ct); // FAILS
}
--
Re: Where will D sit in the web service space?
On Thursday, 13 August 2015 at 14:31:10 UTC, karabuta wrote: Oh! someone thinks typescript is a programming language. Typescript runs in which browser? :) (Because when I use typescript, I worry about two things in my development process, .js and .ts) How is that different from D/asm?
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 13:12:44 UTC, Dicebot wrote:
Right now this works:
``D
struct Std
{
public import std.stdio;
}
void main()
{
Std.writeln(Nice!);
}
```
I want to use it as an import hygiene idiom but not entirely
sure if this behavior can be relied upon (or it is just a side
effect of imports being implemented as aliases currently).
And we're back to namespaces : )
Re: Nested public imports - bug or feature?
On 08/13/2015 03:42 PM, Jonathan M Davis wrote:
On Thursday, 13 August 2015 at 13:12:44 UTC, Dicebot wrote:
Right now this works:
``D
struct Std
{
public import std.stdio;
}
void main()
{
Std.writeln(Nice!);
}
```
I want to use it as an import hygiene idiom but not entirely sure if
this behavior can be relied upon (or it is just a side effect of
imports being implemented as aliases currently).
Well, that's pretty much why splitting up a module and putting public
imports in its package.d file doesn't break any of the cases where
someone types out the full import path when referring to something from
that module/package. But I doubt that anyone considered that that would
have this effect when you have a scoped import. In fact, to be honest,
it never occurred to me that it would be legal to have a scoped, public
import. I think that you just hit a weird result of how allowing imports
to be put everywhere ended up working.
I confess that I don't particularly like that this is legal (and I think
that public imports tend to get a bit hinky because of the fact that
they create aliases), and I'm not quite sure how you could use it form
import hygiene,
It has nothing to do with the import being public. This works:
---
struct Std{
import std.stdio;
}
void main(){
Std.writeln(Nice!);
}
---
(It also works if main and Std are defined in different modules.)
but I also don't see how this could work any other way
if scoped, public imports are allowed.
...
Easy. Just treat aggregate scopes and module scopes differently. (They
are treated differently even now: all imports are 'public' in aggregate
scopes, but not at module scope.) I think this shouldn't be done though.
In any case, I guess we agree that this idiom should work for public
imports, but not for non-public ones (so the current behaviour with
non-public imports is accepts-invalid, but Dicebot's code should be fine)?
Re: Nested public imports - bug or feature?
On 13-Aug-2015 16:56, Timon Gehr wrote:
[snip]
It has nothing to do with the import being public. This works:
---
struct Std{
import std.stdio;
}
void main(){
Std.writeln(Nice!);
}
---
(It also works if main and Std are defined in different modules.)
but I also don't see how this could work any other way
if scoped, public imports are allowed.
...
Easy. Just treat aggregate scopes and module scopes differently. (They
are treated differently even now: all imports are 'public' in aggregate
scopes, but not at module scope.) I think this shouldn't be done though.
In any case, I guess we agree that this idiom should work for public
imports, but not for non-public ones (so the current behaviour with
non-public imports is accepts-invalid, but Dicebot's code should be fine)?
Agreed, public import case looks legitimate.
--
Dmitry Olshansky
Re: The Bug Tracker is a community tool
On Thu, Aug 13, 2015 at 01:23:25PM +, via Digitalmars-d wrote: A little bit of bikeshedding, which irritates me every time I go file a bug: IMHO, the bugzilla link (Bug Tracker) should be under the Community section and not under the Resources section. Note that, for instance, the review queue is in the community section, and both have similar functions, compared with something like the glossary, which does make sense to be in the resources section. PR to fix this? T -- He who laughs last thinks slowest.
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 13:34:32 UTC, Ola Fosheim Grøstad wrote: If you go node.js, you get static typing with typescript if you want + same language on the browser, debuggable. If you go Dart you get static typing if you want + same language the browser, debuggable. Oh! someone thinks typescript is a programming language. Typescript runs in which browser? :) (Because when I use typescript, I worry about two things in my development process, .js and .ts)
Re: The Bug Tracker is a community tool
On Thursday, 13 August 2015 at 13:53:30 UTC, H. S. Teoh wrote: PR to fix this? Sure. If the top men (who?) agree with it, I'll do it. I mean, now that I fixed a wrong link and minor documentation bug this week I can ask where the D community would be without me. More seriously, please take a look at my findSplit post please; if you agree that there is a bug there I can try to fix it too when I look into this. Less context switches.
[Issue 14912] Move initialisation of GC'd struct and class data from the callee to the caller
https://issues.dlang.org/show_bug.cgi?id=14912 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com --- Wouldn't it be enough to simply change the call to the opaque function _d_newitemT(TypeInfo ti) to a template _d_newitem!(T)() ? I don't want to put more special code in the compiler if possible. --
Re: Nested public imports - bug or feature?
As long as imports are not hygienic, this trick is useful. I didn't find it useful in a language with hygienic imports (C#).
Re: new release doesn't work as advertised
On Thursday, 13 August 2015 at 16:30:59 UTC, learn wrote: On Thursday, 13 August 2015 at 11:04:21 UTC, Rikki Cattermole wrote: It was posted there. It's a known issue. Currently no fix for VS2015. However it is being worked upon. Use 2013 instead. thank you for your answer and suggestion, but it is not possible for me to uninstall vs 2015 because of D alone. You can install VS 2013 alongside VS 2015 just fine. — David
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 16:37:00 UTC, Jonathan M Davis wrote: Well, that's better than requiring the full import path, but requiring _any_ module name is just plain annoying IMHO. If I were okay with that I wouldn't be doing stuff like using namespace std; in all of my .cpp files - and that's a really common thing to do. Matter of scale. At some point of application size maintenance cost become much higher than development costs - and problems of name clashes become more important than any extra typing annoyance. In my C++ projects such using abuse was normally banned.
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 16:40:31 UTC, Dicebot wrote: On Thursday, 13 August 2015 at 16:37:00 UTC, Jonathan M Davis wrote: Well, that's better than requiring the full import path, but requiring _any_ module name is just plain annoying IMHO. If I were okay with that I wouldn't be doing stuff like using namespace std; in all of my .cpp files - and that's a really common thing to do. Matter of scale. At some point of application size maintenance cost become much higher than development costs - and problems of name clashes become more important than any extra typing annoyance. Well, if name clashes become that high in a .cpp file, odds are that it's pulling in too much stuff. In my C++ projects such using abuse was normally banned. I've never worked on a team that banned them. Every C++ project that I've ever worked on has used them heavily. It's common practice for every namespace that's being used in a .cpp file to having a corresponding using directive. On the rare cases where there's a collision, you then have to be more explicit, but I've never seen it be much of a problem - and definitely nowhere near enough of a problem to consider banning using directives. I'd _hate_ to be writing code that required being that explicit. - Jonathan M Davis
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis wrote: Matter of scale. At some point of application size maintenance cost become much higher than development costs - and problems of name clashes become more important than any extra typing annoyance. Well, if name clashes become that high in a .cpp file, odds are that it's pulling in too much stuff. My projects have been broken twice by adding new functions to druntime (and one was symbol added to object.di :)). Forgive me if I discard that argument as nonsense. If short names are allowed and project is big enough, clashes are simply inevitable. With D module system even medium size will do.
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 17:32:33 UTC, Dmitry Olshansky wrote: On 13-Aug-2015 20:17, Jonathan M Davis wrote: On Thursday, 13 August 2015 at 17:09:11 UTC, Dicebot wrote: On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis wrote: Matter of scale. At some point of application size maintenance cost become much higher than development costs - and problems of name clashes become more important than any extra typing annoyance. Well, if name clashes become that high in a .cpp file, odds are that it's pulling in too much stuff. My projects have been broken twice by adding new functions to druntime (and one was symbol added to object.di :)). Forgive me if I discard that argument as nonsense. If short names are allowed and project is big enough, clashes are simply inevitable. With D module system even medium size will do. Yes. Clashes are going to happen, especially if you're using short names heavily, but in C++, I've rarely had problems with it. D is potentially worse, Because private symbols from imported modules *do* clash with public ones even though not accessible. THAT is the problem and header/source is not the reason of D doing worse here. Oh. That makes the problem even worse, and it definitely needs to be fixed, but the fact that you're essentially forced to use fully qualified names in C++ for header files means that you're not going to run into name clashes in the public declarations - only in the function bodies in the .cpp file - whereas all of that is out in the open with .d files. So, the header/source separation does reduce the problem in C++, and even if we do fix the private symbol mess in D, D will still have more name clashing problems because it doesn't normally have that separation. But the private symbols affecting the public API is just plain embarrassing and definitely makes the problem _far_ worse. - Jonathan M Davis
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 17:51:06 UTC, Jonathan M Davis wrote: But the private symbols affecting the public API is just plain embarrassing and definitely makes the problem _far_ worse. - Jonathan M Davis It's worse than embarassing. Every symbol added, public or private, must be considered a breaking change.
complete win headers for 32/64 bit
unfortunately i can't find a complete set of windows header files. maybe one should add a link for those headers if they exist - life is not linux or osx only.
Re: Nested public imports - bug or feature?
On 08/13/2015 06:22 PM, Dicebot wrote: On Thursday, 13 August 2015 at 16:19:29 UTC, Jonathan M Davis wrote: You can get that behavior with static imports in D, but having to use the whole import path while referencing symbols gets ugly fast. Check example again, you are only required to use the plain module name, not fully qualified one. With D syntax: import std.stdio; writeln(); // not good stdio.writeln(); // good std.stdio.writeln(); // also good, but not required static import std.stdio; private alias stdio=std.stdio;
Re: new release doesn't work as advertised
On Thursday, 13 August 2015 at 10:44:06 UTC, Gary Willoughby wrote: On Thursday, 13 August 2015 at 10:40:08 UTC, learn wrote: trying to compile the minimal console application generated by visuald: Building Debug\ConsoleApp1.exe... LINK : fatal error LNK1104: cannot open file 'libucrtd.lib' Building Debug\ConsoleApp1.exe failed! win10 - vs2015 This error has nothing to do with the new D release. For help with visuald please try the learn section here: http://forum.dlang.org/group/learn wow you are a real polite cookie. if you guys want to be with VS by MS you should have the complete headers and working releases or ABANON the voting at MS. the linker bug alone it is disgusting for a new release and it renders the compiler unuasable - what an advertisement for the compiler. you don't even have a fast fix, so that the compiler becomes and that should make any prospective new and old user think twice about using D.
Re: complete win headers for 32/64 bit
On Thursday, 13 August 2015 at 16:28:15 UTC, learn wrote: unfortunately i can't find a complete set of windows header files. maybe one should add a link for those headers if they exist - life is not linux or osx only. I'm slowly working on getting them into the standard library. I'm probably one or two more weekends away from getting it to work (it is harder than I thought because the stdlib's build system sucks and there's an incomplete patchwork in there that needs to be cleaned up first too). In the mean time... there is a port of the mingw headers somewhere, but I don't know where anymore. maybe try searching dlang win32... Or you can just declare functions and structs as needed. I did that in simpledisplay.d for Win32, opengl, and X11 bindings: https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d#L3596
Re: complete win headers for 32/64 bit
On Thursday, 13 August 2015 at 17:04:54 UTC, Adam D. Ruppe wrote: On Thursday, 13 August 2015 at 16:28:15 UTC, learn wrote: I'm slowly working on getting them into the standard library. I'm probably one or two more weekends away from getting it to work (it is harder than I thought because the stdlib's build system sucks and there's an incomplete patchwork in there that needs to be cleaned up first too). In the mean time... there is a port of the mingw headers somewhere, but I don't know where anymore. maybe try searching dlang win32... Or you can just declare functions and structs as needed. I did that in simpledisplay.d for Win32, opengl, and X11 bindings: https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d#L3596 thank you for the information - and please announce it when you are finished.
[Issue 14912] Move initialisation of GC'd struct and class data from the callee to the caller
https://issues.dlang.org/show_bug.cgi?id=14912 rsw0x rs...@rsw0x.me changed: What|Removed |Added CC||rs...@rsw0x.me --- Comment #4 from rsw0x rs...@rsw0x.me --- @Steven Schveighoffer Unrelated, but this would help a lot in making a precise GC which is a reason to prefer going that route. --
Re: [Optimization] Speculatively not calling invariant on class objects
On 8/13/15 1:39 PM, Iain Buclaw via Digitalmars-d wrote: On 13 August 2015 at 19:12, Steven Schveighoffer via Digitalmars-d You could probably get rid of calls to _d_invariant by just calling the invariant directly, no? Not with classes, because you need to walk over all interfaces in the vtable, which more likely than not is unknown at compile-time. I guess my understanding of the vtable population isn't very good. I thought there was one invariant entry, period. I don't understand why you'd have multiple invariants in an object that you have to cycle through, why wouldn't the fully derived object know how to call them (from one entry point)? Surely, it knows the interfaces it uses. I thought invariant was like ctor/dtor, the most derived automatically calls the base version. -Steve
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 16:40:31 UTC, Dicebot wrote:
Matter of scale. At some point of application size maintenance
cost become much higher than development costs - and problems
of name clashes become more important than any extra typing
annoyance.
In my C++ projects such using abuse was normally banned.
I would add that it's not just C++. It is also common in Python
to use the full name, albeit typically with an alias, e.g. import
numpy as np. One benefit of this approach is that you can easily
find every function using numpy in a file.
So, while I'm sympathetic with Jonathan's point about requiring
the module being a little annoying if you're doing something
small, I think you raise a good point about large projects.
Nevertheless, others have already pointed out options for
allowing the control that you need.
If you think that you should be able to re-define imports, then
submit an enhancement request. I looked for any suggesting it,
but didn't see anything.
I did see a few others related to imports that were interesting
like allowing something like
import std {
array, range;
}
Re: [Optimization] Speculatively not calling invariant on class objects
On 13 August 2015 at 19:12, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/12/15 8:22 AM, Iain Buclaw wrote:
This post got me thinking:
http://forum.dlang.org/post/mpo71n$22ma$1...@digitalmars.com
We know at compile time for a given object whether or not there are any
invariants, lack of any polymorphism, along with disallowing invariants
in interfaces means that for the given:
class NoInvariants { }
NoInvariants obj;
assert(obj);
It's only a case of checking each base class for any invariant
functions, and if none are found, then we can make an (almost)
reasonable assumption that calling _d_invariant will result in nothing
but wasted cycles.
However, these can't be omitted completely at compile-time given that we
can't guarantee if there are any up-cast classes that have an invariant.
But we should be able to speculatively test at runtime whether or not a
call to _d_invariant may be required by doing a simple pointer test on
the classinfo.
My thought was that you could just set the default invariant pointer to
null. Then when you load the invariant function to call, if it's null,
don't call it.
That is what's done at compile time with structs.
You could probably get rid of calls to _d_invariant by just calling the
invariant directly, no?
-Steve
Not with classes, because you need to walk over all interfaces in the
vtable, which more likely than not is unknown at compile-time.
Regards
Iain.
Re: new release doesn't work as advertised
On Thursday, 13 August 2015 at 16:44:09 UTC, David Nadlinger wrote: On Thursday, 13 August 2015 at 16:30:59 UTC, learn wrote: On Thursday, 13 August 2015 at 11:04:21 UTC, Rikki Cattermole wrote: It was posted there. It's a known issue. Currently no fix for VS2015. However it is being worked upon. Use 2013 instead. thank you for your answer and suggestion, but it is not possible for me to uninstall vs 2015 because of D alone. You can install VS 2013 alongside VS 2015 just fine. — David thank you for the info, but i don't want/need two VS's; this might just wreck the registry and it is a pain to uninstall. i rather be interested in the working working thingy - and so i wait a week or two to try or have lost out on d. thank you again
Re: new release doesn't work as advertised
On Thursday, 13 August 2015 at 17:56:06 UTC, tcak wrote: On Thursday, 13 August 2015 at 16:44:09 UTC, David Nadlinger wrote: On Thursday, 13 August 2015 at 16:30:59 UTC, learn wrote: On Thursday, 13 August 2015 at 11:04:21 UTC, Rikki Cattermole wrote: It was posted there. It's a known issue. Currently no fix for VS2015. However it is being worked upon. Use 2013 instead. thank you for your answer and suggestion, but it is not possible for me to uninstall vs 2015 because of D alone. You can install VS 2013 alongside VS 2015 just fine. — David I think, first of all, the reason why it doesn't compile with VS 2015 should be explained. By leaving the reason, and saying to just install VS 2013 is too ignorant for this community. What is the problem about VS 2015? and how can it be solved? First of all, the RTM has been released about 3 weeks ago, so how come you expect an entirely community-driven compiler to support it within such a short time frame? Especially as Win64 is not considered a primary target. Secondly, there's been breaking changes in the C runtime, as MS finally almost caught up with all other C runtimes in terms of C99 standard conformance. So D's druntime layer on top of the C runtime is being adapted. LDC is already compatible with VS 2015 (http://forum.dlang.org/thread/sgdyguqpuydnkwtmn...@forum.dlang.org) and the next release will greatly improve its Win64 support. And then there's VisualD apparently missing to detect VS 2015. I know that CTPs have been out for quite some time, I've used one for quite some time myself. But the Windows faction in this community isn't strong, the DMD CI slaves use VS 2010, LDC only has CI tests on Linux etc. @learn: if you guys want to be with VS by MS you should have the complete headers and working releases or ABANON the voting at MS. Wow, what arrogance. Nothing prevents MS from taking their first steps towards D, why must we do it all ourselves in our spare time for a proprietary and commercial OS?
Re: Nested public imports - bug or feature?
On 13-Aug-2015 20:17, Jonathan M Davis wrote: On Thursday, 13 August 2015 at 17:09:11 UTC, Dicebot wrote: On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis wrote: Matter of scale. At some point of application size maintenance cost become much higher than development costs - and problems of name clashes become more important than any extra typing annoyance. Well, if name clashes become that high in a .cpp file, odds are that it's pulling in too much stuff. My projects have been broken twice by adding new functions to druntime (and one was symbol added to object.di :)). Forgive me if I discard that argument as nonsense. If short names are allowed and project is big enough, clashes are simply inevitable. With D module system even medium size will do. Yes. Clashes are going to happen, especially if you're using short names heavily, but in C++, I've rarely had problems with it. D is potentially worse, Because private symbols from imported modules *do* clash with public ones even though not accessible. THAT is the problem and header/source is not the reason of D doing worse here. because we don't have the equivalent separation of header and source files where it's only the source files that risk breakage. But still, I'd _much_ rather just deal with the occasional breakage than have to qualify everything. - Jonathan M Davis -- Dmitry Olshansky
Re: [Optimization] Speculatively not calling invariant on class objects
On 13 August 2015 at 20:03, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/13/15 1:39 PM, Iain Buclaw via Digitalmars-d wrote:
On 13 August 2015 at 19:12, Steven Schveighoffer via Digitalmars-d
You could probably get rid of calls to _d_invariant by just calling
the invariant directly, no?
Not with classes, because you need to walk over all interfaces in the
vtable, which more likely than not is unknown at compile-time.
I guess my understanding of the vtable population isn't very good.
I thought there was one invariant entry, period. I don't understand why
you'd have multiple invariants in an object that you have to cycle through,
why wouldn't the fully derived object know how to call them (from one entry
point)? Surely, it knows the interfaces it uses.
class A { invariant { } }
class B : A { }
class C : B { invariant { } }
B b = new C(); // We can only discover that 'b' is a C object at runtime.
I thought invariant was like ctor/dtor, the most derived automatically
calls the base version.
Nope, it only calls it's own invariants. Calling all derived invariants is
what _d_invariant is for.
Re: new release doesn't work as advertised
On Thursday, 13 August 2015 at 11:04:21 UTC, Rikki Cattermole wrote: On 13/08/2015 10:44 p.m., Gary Willoughby wrote: On Thursday, 13 August 2015 at 10:40:08 UTC, learn wrote: trying to compile the minimal console application generated by visuald: Building Debug\ConsoleApp1.exe... LINK : fatal error LNK1104: cannot open file 'libucrtd.lib' Building Debug\ConsoleApp1.exe failed! win10 - vs2015 This error has nothing to do with the new D release. For help with visuald please try the learn section here: http://forum.dlang.org/group/learn It was posted there. It's a known issue. Currently no fix for VS2015. However it is being worked upon. Use 2013 instead. thank you for your answer and suggestion, but it is not possible for me to uninstall vs 2015 because of D alone.
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 16:24:56 UTC, Timon Gehr wrote: static import greetings=phrases.english.greetings; ? http://forum.dlang.org/post/szaaakmavraxatkrf...@forum.dlang.org How is this relevant? Does Rust support it? Relevant as explanation why I don't consider aliased imports a solution. Rust does exactly that and I feel that bottom-qualification is inferior approach to top-qualification in general for deeply nested package hierarchies. Of course, both are much more hygienic than semantics D uses by default - yet if I am forced to resort to idioms, I want to get most out of it :)
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 16:22:04 UTC, Dicebot wrote: On Thursday, 13 August 2015 at 16:19:29 UTC, Jonathan M Davis wrote: You can get that behavior with static imports in D, but having to use the whole import path while referencing symbols gets ugly fast. Check example again, you are only required to use the plain module name, not fully qualified one. With D syntax: import std.stdio; writeln(); // not good stdio.writeln(); // good std.stdio.writeln(); // also good, but not required Well, that's better than requiring the full import path, but requiring _any_ module name is just plain annoying IMHO. If I were okay with that I wouldn't be doing stuff like using namespace std; in all of my .cpp files - and that's a really common thing to do. - Jonathan M Davis
Re: [Optimization] Speculatively not calling invariant on class objects
On 8/13/15 2:25 PM, Iain Buclaw via Digitalmars-d wrote:
class A { invariant { } }
class B : A { }
class C : B { invariant { } }
B b = new C(); // We can only discover that 'b' is a C object at runtime.
I thought invariant was like ctor/dtor, the most derived
automatically calls the base version.
Nope, it only calls it's own invariants. Calling all derived invariants
is what _d_invariant is for.
I envisioned C.invariant would inject a call to A.invariant, and that
invariant would occupy a vtable slot.
-Steve
Re: [Optimization] Speculatively not calling invariant on class objects
On 8/12/15 8:22 AM, Iain Buclaw wrote:
This post got me thinking:
http://forum.dlang.org/post/mpo71n$22ma$1...@digitalmars.com
We know at compile time for a given object whether or not there are any
invariants, lack of any polymorphism, along with disallowing invariants
in interfaces means that for the given:
class NoInvariants { }
NoInvariants obj;
assert(obj);
It's only a case of checking each base class for any invariant
functions, and if none are found, then we can make an (almost)
reasonable assumption that calling _d_invariant will result in nothing
but wasted cycles.
However, these can't be omitted completely at compile-time given that we
can't guarantee if there are any up-cast classes that have an invariant.
But we should be able to speculatively test at runtime whether or not a
call to _d_invariant may be required by doing a simple pointer test on
the classinfo.
My thought was that you could just set the default invariant pointer to
null. Then when you load the invariant function to call, if it's null,
don't call it.
You could probably get rid of calls to _d_invariant by just calling the
invariant directly, no?
-Steve
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 17:09:11 UTC, Dicebot wrote: On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis wrote: Matter of scale. At some point of application size maintenance cost become much higher than development costs - and problems of name clashes become more important than any extra typing annoyance. Well, if name clashes become that high in a .cpp file, odds are that it's pulling in too much stuff. My projects have been broken twice by adding new functions to druntime (and one was symbol added to object.di :)). Forgive me if I discard that argument as nonsense. If short names are allowed and project is big enough, clashes are simply inevitable. With D module system even medium size will do. Yes. Clashes are going to happen, especially if you're using short names heavily, but in C++, I've rarely had problems with it. D is potentially worse, because we don't have the equivalent separation of header and source files where it's only the source files that risk breakage. But still, I'd _much_ rather just deal with the occasional breakage than have to qualify everything. - Jonathan M Davis
Re: new release doesn't work as advertised
On Thursday, 13 August 2015 at 16:44:09 UTC, David Nadlinger wrote: On Thursday, 13 August 2015 at 16:30:59 UTC, learn wrote: On Thursday, 13 August 2015 at 11:04:21 UTC, Rikki Cattermole wrote: It was posted there. It's a known issue. Currently no fix for VS2015. However it is being worked upon. Use 2013 instead. thank you for your answer and suggestion, but it is not possible for me to uninstall vs 2015 because of D alone. You can install VS 2013 alongside VS 2015 just fine. — David I think, first of all, the reason why it doesn't compile with VS 2015 should be explained. By leaving the reason, and saying to just install VS 2013 is too ignorant for this community. What is the problem about VS 2015? and how can it be solved?
Re: How do I find the actual types of the elements in a list of classes?
On Thursday, 13 August 2015 at 20:28:33 UTC, Adam D. Ruppe wrote:
On Thursday, 13 August 2015 at 20:23:56 UTC, Jack Stouffer
wrote:
As far as I can tell, there is no way to know the actual type
of each of the objects in the list to be able to print:
Cast it to Object first, then do the typeid and it will get the
dynamic class type. Since Parent is an interface, typeid works
differently.
I wrote about this in more detail recently here:
http://stackoverflow.com/questions/31563999/how-to-get-classinfo-of-object-declared-as-an-interface-type/31564253#31564253
Thanks, that worked, and based on your answer, I was able to fix
my real problem: dynamically calling different methods on each
object in the list based on its type. So, using the above code as
an example, I am able to call method if the object is of type A
and method2 if the object is of type B:
interface Parent {
void method();
}
class A : Parent {
void method() {}
this() {}
}
class B : Parent {
void method() {}
void method2() {}
this() {}
}
void main() {
import std.stdio;
import std.string;
Parent[] parent_list = [];
parent_list ~= new A();
parent_list ~= new B();
foreach (item; parent_list) {
string class_name = (cast(Object)
item).classinfo.name;
if (class_name == test.A) {
(cast(A) item).method();
} else if (class_name == test.B) {
(cast(B) item).method2();
}
}
}
This is a dirty hack, but I don't care, it works :)
Re: How do I find the actual types of the elements in a list of classes?
On Thursday, 13 August 2015 at 22:20:35 UTC, Justin Whear wrote:
foreach (item; parent_list) {
if (auto asA = cast(A)item) {
asA.method();
} else if (auto asB = cast(B)item) {
asB.method2();
}
}
On Thursday, 13 August 2015 at 22:20:35 UTC, Justin Whear wrote:
Thanks Justin and rumbu, that makes the code a lot more readable.
Re: std.data.json formal review
On 8/13/2015 3:51 AM, Sönke Ludwig wrote: These were, AFAICS, the only major open issues (a decision for an opt() variant would be nice, but fortunately that's not a fundamental decision in any way). 1. What about the issue of having the API be a composable range interface? http://s-ludwig.github.io/std_data_json/stdx/data/json/lexer/lexJSON.html I.e. the input range should be the FIRST argument, not the last. 2. Why are integers acceptable as lexer input? The spec specifies Unicode. 3. Why are there 4 functions that do the same thing? http://s-ludwig.github.io/std_data_json/stdx/data/json/generator.html After all, there already is a http://s-ludwig.github.io/std_data_json/stdx/data/json/generator/GeneratorOptions.html
Re: new release doesn't work as advertised
On Thursday, 13 August 2015 at 18:32:31 UTC, kinke wrote: First of all, the RTM has been released about 3 weeks ago, so how come you expect an entirely community-driven compiler to support it within such a short time frame? Especially as Win64 is not considered a primary target. Secondly, there's been breaking changes in the C runtime, as MS finally almost caught up with all other C runtimes in terms of C99 standard conformance. So D's druntime layer on top of the C runtime is being adapted. LDC is already compatible with VS 2015 (http://forum.dlang.org/thread/sgdyguqpuydnkwtmn...@forum.dlang.org) and the next release will greatly improve its Win64 support. And then there's VisualD apparently missing to detect VS 2015. I know that CTPs have been out for quite some time, I've used one for quite some time myself. But the Windows faction in this community isn't strong, the DMD CI slaves use VS 2010, LDC only has CI tests on Linux etc. @learn: if you guys want to be with VS by MS you should have the complete headers and working releases or ABANON the voting at MS. Wow, what arrogance. Nothing prevents MS from taking their first steps towards D, why must we do it all ourselves in our spare time for a proprietary and commercial OS? don't cry around. i don't care how it's done - i want to use it. maybe you should consider to advertise it differently - by truthfully explaining what works and what not. maybe you should think a little about that your prios are not necessarily the prios of other possible users.
[Issue 14918] New: Undefined reference when using a static array of pollfd's
https://issues.dlang.org/show_bug.cgi?id=14918
Issue ID: 14918
Summary: Undefined reference when using a static array of
pollfd's
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: initrd...@gmail.com
This code:
import core.sys.posix.poll;
void main() {
pollfd[5] entry;
}
Produces the following error when compiling:
rdmd ~/test.d
/tmp/.rdmd-1000/rdmd-test.d-F32582916A80A29195884B844D6EB219/objs/test.o:
In function `_Dmain':
/home/col/test.d:(.text._Dmain+0x10): undefined reference to
`_D4core3sys5posix4poll6pollfd6__initZ'
collect2: error: ld returned 1 exit status
--- errorlevel 1
--
Re: Where are the semantics of shared defined?
On Thursday, 13 August 2015 at 21:29:42 UTC, rsw0x wrote: The only mention of them in the spec is: shared Attribute The shared attribute modifies the type from T to shared(T), the same way as const does. Am I missing something obvious? There is this http://dlang.org/migrate-to-shared.html But you are right, the spec is seriously lacking in details.
Re: new release doesn't work as advertised
On Thursday, 13 August 2015 at 21:04:53 UTC, bachmeier wrote: My comment was about the limited resources of this community. If there are false statements about VS 2015 support, then they should be corrected. And if you feel that VS 2015 support is a must, then it is entirely reasonable to not use D. I was responding to what I felt was a harsh response by Tofu Ninja. IMO it is not realistic to think that any developer can sit down and use his preferred setup without any rough edges. It comes with writing D code. Others have told you that the problem is being fixed, told you how you can still use VS, and I don't see what more they should have done. i am sorry if have been to harsh and - i have no problems with rough edges - but that also means, that the overall thingy IS working. BUT IT DOESN'T. running on windows, i need the headers and is not only a VS issue - and then - i will have also the painful task to connect to my old code or be willing to port old code and that with seemingly (unknown to me yet) bad (multi D) dll support on windows. i know about rough edges - i used assembler half my life, i wrote the programs for my dissertation with walter's zortech c++ compiler (it had just came out - rough edges at the time) and having said that, i kind of feel old (walter is surely alot younger - but then the hair??). never the less, if you promise something - do at least the QS necessary to keep the overall promise, with, may be the rough edges included. But that does not include that it doesn't work, - that it doesn't have the needed headers and donn’t suggest that others (developers on D) care more for just one OS which isn’t necessarily windows. BOLD don't knowingly steel the time of people (bad QS is knowing/intent), just tell them what is and what is not - rough edges included. they might still go for D - just for that reason and that is an opportunity. BOLD OFF one last remark: a lot of times the old(er) people are the ones who decide about using the rough edges or not. they take a risks that might be the situation D needs. but D is missing QS? lost of it? give your thoughts.
Re: How do I find the actual types of the elements in a list of classes?
On Thursday, 13 August 2015 at 21:42:54 UTC, Jack Stouffer wrote:
Thanks, that worked, and based on your answer, I was able to
fix my real problem: dynamically calling different methods on
each object in the list based on its type. So, using the above
code as an example, I am able to call method if the object is
of type A and method2 if the object is of type B:
interface Parent {
void method();
}
class A : Parent {
void method() {}
this() {}
}
class B : Parent {
void method() {}
void method2() {}
this() {}
}
void main() {
import std.stdio;
import std.string;
Parent[] parent_list = [];
parent_list ~= new A();
parent_list ~= new B();
foreach (item; parent_list) {
string class_name = (cast(Object)
item).classinfo.name;
if (class_name == test.A) {
(cast(A) item).method();
} else if (class_name == test.B) {
(cast(B) item).method2();
}
}
}
This is a dirty hack, but I don't care, it works :)
It works as long as your module is called test.
I think this is a better approach:
foreach (item; parent_list) {
if (auto a = cast(A)item)
a.method();
else if (auto b = cast(B)item)
b.method2();
}
Yieldable function?
Is there any way to have a yieldable function that can be resumed
at a later time in D?
Some thing like:
void test()
{
writeln(A);
yeild();
writeln(B);
}
...
auto x = yieldable!test();
x.resume(); // prints A
x.resume(); // prints B
x.resume(); // throws an error or something, i dont know..
Also how portable is the built in asm support, was thinking about
implementing this if it's not already available. Also is there a
way to define naked functions in D? I think not but they might
make implementing this a little more simple.
Re: Yieldable function?
http://dlang.org/phobos/core_thread.html#.Fiber
Re: std.data.json formal review
On 8/13/2015 5:18 PM, Adam D. Ruppe wrote: On Thursday, 13 August 2015 at 03:44:14 UTC, Walter Bright wrote: Hah, I'd like to replace dmd.conf with a .json file. There's an awful lot of people out there replacing json with more ini-like files We've currently invented our own, rather stupid and limited, format. There's no point to it over .json.
Re: How do I find the actual types of the elements in a list of classes?
On Friday, 14 August 2015 at 00:06:33 UTC, Adam D. Ruppe wrote:
On Thursday, 13 August 2015 at 23:48:08 UTC, Jack Stouffer
wrote:
In my code, the list can have 20-30 different types of classes
in it all inheriting from the same interface, and it doesn't
make sense for all of those classes to implement a method that
is very specific to one of the classes.
I don't want to get too far into this since I haven't seen your
code, but the function that uses this list might itself be a
candidate for addition to the interface, or a second interface
with that method that all the classes also inherit from
(remember you can only inherit from one class in D, but you can
implement as many interfaces as you want).
The code in question is a collision resolver in a 2D game that I
am making. The list is a list of all of the drawable objects that
the object could be colliding with. After collision is checked on
each of the possible collisions, the object is placed at the last
position where it was not colliding. I am using the cast in the
enemy resolver where each collision is then checked to see if the
collision was with the player, and if it was, the player is then
given damage.
-
class Blob : Enemy {
...
final override void resolveCollisions() {
import player : Player;
//check for collision
Entity[] possible_collisions =
this.state_object.getPossibleCollisions(this);
Entity[] collisions = [];
foreach (ref entity; possible_collisions) {
// discount any Rect that is equal to the player's,
as it's probably
// the players bounding box
if (this.boundingBox != entity.boundingBox
this.boundingBox.intersects(entity.boundingBox)) {
collisions ~= entity;
}
}
if (collisions.length 0) {
// If we collided with something, then put position
back to its
// original spot
this.position = this.previous_position;
// If we collided with the player, give the player
damage
foreach (collision; collisions) {
// Check to see if the object collided was a
player by testing the
// result of the cast, which will return null if
unsuccessful
if (auto player = cast(Player) collision) {
player.damagePlayer(5, this.position,
this.mass);
}
}
}
}
}
[Issue 14873] Build fails with message 'cannot create PDB file'
https://issues.dlang.org/show_bug.cgi?id=14873 --- Comment #6 from Derik Palacino de...@palacino.net --- Sorry for the delay. I've tried this with the latest version (0.3.42 from a4db8f4) and got the same results. -- Rebuild All started: Project: Library, Configuration: Debug Win32 -- Building Debug\Library.dll... Converting debug information... C:\Users\Derik\Projects\TagIO\Projects\Library\Debug\Library.pdb: cannot create PDB file Building Debug\Library.dll failed! Details saved as file://C:\Users\Derik\Projects\TagIO\Projects\Library\Debug\Library.buildlog.html == Rebuild All: 0 succeeded, 1 failed, 0 skipped == The build log reveals... Command Line set PATH=C:\D\dmd2\windows\bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\\Common7\IDE;C:\Program Files (x86)\Windows Kits\8.1\\bin;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE;%PATH% dmd -g -debug -X -XfDebug\Library.json -deps=Debug\Library.dep -c -ofDebug\Library.obj dll.def dllmain.d Objects.d TagIO.d if errorlevel 1 goto reportError set LIB=C:\D\dmd2\windows\bin\..\lib echo. C:\Users\Derik\Projects\TagIO\Projects\Library\Debug\Library.build.lnkarg echo Debug\Library.obj,Debug\Library.dll_cv,Debug\Library.map,user32.lib+ C:\Users\Derik\Projects\TagIO\Projects\Library\Debug\Library.build.lnkarg echo kernel32.lib,dll.def/MAP:FULL/CO/NOI/DELEXE C:\Users\Derik\Projects\TagIO\Projects\Library\Debug\Library.build.lnkarg C:\Program Files (x86)\VisualD\pipedmd.exe -deps Debug\Library.lnkdep C:\D\dmd2\windows\bin\link.exe @C:\Users\Derik\Projects\TagIO\Projects\Library\Debug\Library.build.lnkarg if errorlevel 1 goto reportError if not exist Debug\Library.dll_cv (echo Debug\Library.dll_cv not created! goto reportError) echo Converting debug information... C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe Debug\Library.dll_cv Debug\Library.dll if errorlevel 1 goto reportError if not exist Debug\Library.dll (echo Debug\Library.dll not created! goto reportError) goto noError :reportError echo Building Debug\Library.dll failed! Output onverting debug information... C:\Users\Derik\Projects\TagIO\Projects\Library\Debug\Library.pdb: cannot create PDB file Building Debug\Library.dll failed! --
Re: Yieldable function?
On Thursday, 13 August 2015 at 22:29:17 UTC, MrSmith wrote: http://dlang.org/phobos/core_thread.html#.Fiber Man I feel like I saw that before but when I went looking for it I couldn't find it. Didn't think to check in core. :/ Welp that solves my question, thanks :D
Re: Yieldable function?
On Thursday, 13 August 2015 at 22:27:31 UTC, Tofu Ninja wrote: Also how portable is the built in asm support it varies a bit across compilers (gdc does it differently), and obviously across processors. Also is there a way to define naked functions in D? Put the `naked;` pseudo-instruction at the top of a function in an asm block. http://dlang.org/iasm.html
