Re: how to determine of a module or any other symbol is visible?
On Monday, 18 June 2018 at 09:28:00 UTC, rikki cattermole wrote:
On 18/06/2018 9:24 PM, Mr.Bingo wrote:
On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole
wrote:
This doesn't work with depreciation warnings.
There won't be a way to check for those (I think).
Easier to not worry about them until it turns into errors.
you can try the -de flag:
// foo.d:
deprecated void foo() {}
pragma(msg, __traits(compiles, foo()));
---
dmd foo.d
-> true
dmd -de foo.d
-> false
---
couldn't think of any examples of deprecated visibility to try
though
Re: scope(success) lowered to try-catch ?
On Monday, 18 June 2018 at 03:58:47 UTC, Neia Neutuladh wrote:
...
yeah, at an AST level it makes sense why it was implemented like
this.
it's unfortunate that there's no straightforward way to express
'finally(success) {'.
Re: scope(success) lowered to try-catch ?
On Sunday, 17 June 2018 at 12:10:33 UTC, Nicholas Wilson wrote: I suspect scope(success) is lowered because scope(exit) and scope(failure) are, and that would result in a simpler (compiler) implementation of it. does adding nothrow to main fix it? For dcompute I specifically allow scope(exit|success) because there will never be any exceptions _at all_. If not, please do submit an issue. Also a better error message should be given. nothrow unfortunately doesn't help; i guess I'll file an issue. thanks for your input
scope(success) lowered to try-catch ?
Hello,
I'm not sure whether I'm missing something obvious here, but is
there a reason for scope(success) being lowered to a try-catch
statement?
I would have expected only scope(exit) and scope(failure) to
actually interact with exception handling, while scope(success)
simply places code on the path of normal control flow.
Example (windows x32):
---
// main.d
void main() {
scope(success) {}
}
dmd -betterC main.d
Error: Cannot use try-catch statements with -betterC
---
Regardless of whether -betterC is used, you can see in the
disassembly that having a scope(success) anywhere in the function
causes the SEH prologue to be emitted in the code.
Is there a reason scope(success) needs to set up for exception
handling?
Or is this a bug / potential enhancement ?
Re: immutable postblit unusable?
issue opened here: https://issues.dlang.org/show_bug.cgi?id=18417 thanks Jon
Re: Debugging on Windows
On Thursday, 8 February 2018 at 21:09:33 UTC, JN wrote: Hi, is there any way to debug binaries on Windows? I'd at least like to know which line of code made it crash. If it's D code, I get a call trace usually, but if it's a call to a C library, I get a crash and that's it. I am using VSCode and I'd prefer to debug in it if possible, but using other IDEs is a possibility for me if that will help. Other options: I use x64dbg, x32dbg and ollydbg with D. When PDB files are loaded you should get symbol names and line-by-line source file mapping. Currently they don't do much memory analysis though — like getting names of variables on the stack or fields of objects on the heap. With -m64 the linker should already be emitting PDB files that x64dbg will find automatically. With 32-bit OPTLINKed code you need to use cv2pdb on the .exe/.dll to get the PDB file, then olly/x32dbg should find it. WinDBG should work too — which is probably your only choice if you're writing a driver.
Re: immutable postblit unusable?
On Sunday, 11 February 2018 at 08:25:41 UTC, Jonathan M Davis wrote: … Thanks, I couldn't have asked for a more thorough explanation. Especially that __xpostblit detail, which I now vaguely recall seeing in the runtime code. Sounds like making `this(this) immutable` illegal is the way to go. I don't have anything to add about the `const` problem though.
immutable postblit unusable?
https://dpaste.dzfl.pl/80d2a208519c
struct A {
this(this) immutable {}
}
struct B {
A a;
}
// Error: immutable method f18.A.__postblit is not callable using
a mutable object
-
I honestly don't know what to make of this.
I guess the auto-generated postblit of B is throwing this?
Does it even make sense to have an immutable postblit?
Should such code be explicitly rejected?
Re: DIP1001: DoExpression
On Saturday, 3 September 2016 at 16:03:39 UTC, Jonathan M Davis wrote: So, instead of having the return statement which everyone knows to look for and is easy to grep for, you want to add a way to return _without_ a return statement? I think you've misunderstood. Even with DoExpressions, the only way to return from a function without a return statement is in a lambda '=>' function.
Re: DIP1001: DoExpression
On Saturday, 3 September 2016 at 16:28:15 UTC, Andrei Alexandrescu wrote: This is a terrible argument. It has "why not" all over it. -- Andrei Sorry, it's my first time proposing a language feature.
Re: DIP1001: DoExpression
On Saturday, 3 September 2016 at 16:10:16 UTC, Jonathan M Davis
wrote:
.. and from what I've seen, it seems to be the case that just
about only the only folks who read it correctly are the ones
who use it frequently ..
You know what else is easy to misread?
{
x;
y;
return z;
}();
Because until you reach the () at the end you have no idea
whether this is supposed to be an anonymous function to be called
elsewhere or a series of statements to be executed right now.
Sure, the comma expression isn't used very often, but when I do
need to use it I don't want to have to put garbage syntax like
that in my code. When you're reading code and you see `do(` you
know straight away what's going on.
Re: DIP1001: DoExpression
On Saturday, 3 September 2016 at 15:28:36 UTC, Andrei
Alexandrescu wrote:
What's wrong with:
auto seq(T...)(auto ref T vals) { return vals[$ - 1]; }
Well there's nothing *wrong* with that, but I really think that
'do' is the perfect word for this purpose, and the fact that it's
already a keyword is real convenient. For just 10 lines in
parse.d we get this great syntax, no code breakage, no need to
copy-paste a little template around.
Re: DIP1001: DoExpression
On Saturday, 3 September 2016 at 14:47:50 UTC, rikki cattermole wrote: I may dislike not using return but please consider at the very least using ; instead of , for the last element do(x, y ; z). Just something to hint that the last one is special. Not a bad idea, actually. I feel like the semicolon should be allowed, but not enforced. If another two or three people also like this idea I'll go ahead and implement it, and adjust the DIP.
Re: DIP1001: DoExpression
On Saturday, 3 September 2016 at 14:26:30 UTC, Stefan Koch wrote:
Introducing an expression for this seems overkill.
The same could be said for the '=>' lambda syntax. Doesn't do
anything that {return x;} can't do.
Re: DIP1001: DoExpression
On Saturday, 3 September 2016 at 14:25:49 UTC, rikki cattermole wrote: I propose a slight change: do(x, y, return z) Hmm, I suppose I should mention one other motivation behind this DIP: I really like to avoid using the 'return' keyword inside expressions, because I find it visually confusing - hear me out here - When you're reading a function and trying to understand its control flow, one of the main elements you're searching for is all the places the function can return from. If the code has a lot of anonymous functions with return statements this can really slow down the process as you have to more carefully inspect every return to see if it's a 'real' return or inside an anonymous function. Also, in case it wasn't obvious, the do() syntax was inspired by Clojure: http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/do
Re: Hash table element existence check
On Saturday, 3 September 2016 at 12:33:26 UTC, Illuminati wrote:
On Saturday, 3 September 2016 at 07:44:28 UTC, Cauterite wrote:
On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote:
I am trying to create a hash table and would like an
efficient way to be able to know if an element exists to test
for collisions.
Just do a regular lookup on the hash? It's an O(1) operation,
like 4 instructions.
Huh? One can look up fine, but how does one know if the result
is valid or not?
Okay I think I misinterpreted the question. I believe when I did
this my solution was to have an additional template parameter
specifying null key values, so the template was like this:
struct HashTbl(
K, /* key type */
V, /* value type */
K NullKey, /* key placeholder value */
alias hash_key, /* hash function */
alias keys_eq /* equality function */
) {...
I guess this doesn't really solve the problem, but makes it the
user's problem.
I could keep a bitarray, but wasting around 12% space.
That assumes your (K,V) tuples are 1 byte total, right?
Re: Hash table element existence check
On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. Just do a regular lookup on the hash? It's an O(1) operation, like 4 instructions.
Re: ADL
On Friday, 2 September 2016 at 12:15:25 UTC, Manu wrote: The only problem I have with this feature is that it would lead to implicit-importation, which is a totally foreign concept in D, and I would assume a design choice to not support it. import bob : S; S s; // implicit `import bob : f;` for this statement: f(s); Is this an acceptable feature? Perhaps; my main concern is that it can be very difficult to work out where this `f` symbol is coming from. If you see the only import statement is `import bob : S;` then you'd naturally assume that the `f` being called here is not `bob.f`. It's nice to learn this term "argument dependent lookup" though. I've spent a lot of time thinking about this feature, but never realised it had a name (and I never realised any languages supported it).
Re: Equivalent of FirstOrDefault with ranges
On Friday, 2 September 2016 at 06:56:07 UTC, Lutger wrote:
You could do:
names.find("bob").chain(only(``)).front;
It's not very expressive though.
Re: Fallback 'catch-all' template functions
On Thursday, 1 September 2016 at 17:21:02 UTC, Meta wrote:
I just thought of this, but cannot test if it works. If it
does, maybe it would be a suitable solution?
void f(T)(T t) if(isSomething!T) {}
void f(T)(T t) if(isSomethingElse!T) {}
//Taken if no other "overload" of f will intantiate with the
given T
void f(T)(T t) if(!__traits(compiles, alias _ = .f!T)) {}
That's so dirty, I love it. I imagine if __traits(getOverloads
worked for templates we could actually use this pretty reliably
(by excluding the fallback template from the search).
Re: DMD front-end can be used as a library with Dub
On Monday, 29 August 2016 at 10:42:23 UTC, Alexander Breckel wrote: Because of the poor memory management in the compiler, I included a modified GC-stub when I compiled the frontend as a library, so that it can be used in long-running processes: https://gist.github.com/Cauterite/4eb74347aea040f5d371fb49054e1819 You can call gc_annihilate(true) to delete the entire heap. Obviously you need to keep the library in a separate DLL with its own runtime, and carefully avoid holding references to GC memory across annihilations. This technique is working pretty smoothly for me so far. Also to compile it as a DLL you either have to remove main() from mars.d or play games with the C runtime: https://gist.github.com/Cauterite/b190e62891c773703d0de3a1d99df362
Re: Fallback 'catch-all' template functions
On Thursday, 1 September 2016 at 10:50:18 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 1 September 2016 at 10:43:50 UTC, Dominikus Dittes
Scherkl wrote:
I have never seen what benefit could be gained from having
overloads. I think they are a relict from languages without
static if.
I mean, overloads with same function signature except for the
condition. Of course if the overloads have different parameters
or return type, they may make sense. But they still uglyfy the
API, so I try to avoid them - instead I use default parameters
and template parameters what pretty much always works.
When you're specialising on type classes rather than concrete
types, you have no choice:
auto f(T)(T source) if (is(ElementType!T : int)) {...};
auto f(T)(T source) if (is(ElementType!T : Object)) {...};
There is nothing you can write in the template parameters list to
enable the same kind of specialisation.
testing for deprecation
How does one test whether a symbol is deprecated? I would have
expected something like: __traits(isDeprecated, foo).
In the compiler we have Dsymbol.isDeprecated, is that not
accessible in any way from code?
The only solution I can think of is compiling with -de and using
__traits(compiles, {alias x = foo;})
which actually does seem to work. Pretty lousy though.
You can call Fiber.yield() inside a vectored exception handler (win32)
In case anyone was wondering, in 32-bit Windows you can call
Fiber.yield() from inside a vectored exception handler, and
subsequently resume the fibre again.
As far as I can tell it works flawlessly.
Here's a little example:
---
extern(Windows) int on_exception_global(EXCEPTION_POINTERS* X)
nothrow {
/* once installed, this function will be called for every
exception raised in the current process */
if (X.ExceptionRecord.ExceptionCode == STATUS_ACCESS_VIOLATION) {
Fibre.yield(); // can do!
// retry the instruction that raised the exception
return EXCEPTION_CONTINUE_EXECUTION;
};
// call next exception handler
return EXCEPTION_CONTINUE_SEARCH;
};
auto Hdl = enforce(AddVectoredExceptionHandler(
1, /* insert at front of exception-handler chain */
_exception_global
));
---
Careful about throwing from inside your exception handler (any
kind of software or hardware exception, not limited to
'Throwable'). Don't want to end up in an infinite loop.
Re: Debug prints in @nogc
On Wednesday, 31 August 2016 at 16:17:51 UTC, Yuxuan Shui wrote: No. When you use assumeUnique, you know something the compiler does know, and have to use assumeUnique to tell the compiler that (at least when you use it correctly). But when you use assumeNogc, it's always because you want to bypass compiler checks. assumeNogc works the same way, you're telling the compiler something it doesn't know — that the function should be treated as @nogc. Using assumeNogc on a function that calls the GC is as unsafe as using assumeUnique on a reference that is not unique.
Re: Multi-threading how-to
On Wednesday, 31 August 2016 at 17:37:25 UTC, solidstate1991 wrote: I decided to add a functionality that if multiple programs use the same instance of the library on the same computer, the messages will be passed directly instead of via networking. What you're describing here is not actually multi-threading, it's multi-process…ing. The keyword you're looking for is "inter-process communication". You have a huge range of possible options for implementing this. Your decision would depend on your operating system, your existing implementation with sockets, and desired performance. My suggestion: try just using sockets between processes on the same PC. You might not even need to add any new code to support this method, and it might be faster than you'd expect.
Re: Debug prints in @nogc
On Wednesday, 31 August 2016 at 15:10:11 UTC, Seb wrote: AssumeNogc is potentially dangerous, so I don't know whether it can make it directly, but only if you try you know ;-) So is assumeUnique
Re: D to C++
On Wednesday, 31 August 2016 at 11:43:12 UTC, Nick wrote: That's quite nice, but not what I'm looking for. What Calypso does, as far as I can see, is to make it possible to compile C++ and D together. I'm looking for a compiler that takes in D code and spits out either C or C++ code. Your best option would be to use LDC with a C backend: https://www.google.com/search?q=llvm++c+backend No idea how well supported this is, I've never used LLVM myself.
Re: Debug prints in @nogc
On Tuesday, 30 August 2016 at 14:38:47 UTC, Nordlöw wrote: Just being able to print a string is not good enough. I want the variadic part writeln so I can debug-print values in my buggy code. Do you have a similar solution? Take a look at the example here: http://dlang.org/phobos/std_traits#SetFunctionAttributes You could make a `assumeNogc` template similar to the example `assumePure`. Oh yeah, here's one I prepared earlier: https://dpaste.dzfl.pl/254a5c2697a7
Re: if-expressions
On Tuesday, 30 August 2016 at 07:41:35 UTC, w0rp wrote:
I don't think this particular syntax is desirable. We already
have ternary expressions, and anything more complicated than a
regular ternary should probably be written with a regular
series of if statements.
The problem is when you're in the middle of a large expression
which you don't want to break apart into statements (it might be
the body of a '=>' lambda), your options are ternary conditionals
(horrid syntax), or something like `{if (x) {return y;} else
{return z;};}()` which is just as bad.
Re: Does D have anything like the generators of Python and some other languages?
On Monday, 29 August 2016 at 21:24:52 UTC, A D dev wrote: Hi group, Does D have anything like the generators of Python and some other languages? Thanks. Ranges serve some of the purposes that generators are often used for: http://dlang.org/phobos/std_range.html But you can of course make true coroutine-based generators with fibres: http://dlang.org/phobos/core_thread.html#.Fiber "fibre" is basically a synonym of "coroutine".
Re: Do we need a FAQ page?
On Monday, 29 August 2016 at 13:50:07 UTC, Andrea Fontana wrote: It's very deep inside menu. Anyway this FAQ sections sounds not right for a newcomer that never seen D IMO. You can actually fork the website ( https://github.com/dlang/dlang.org/blob/master/faq.dd ) and improve it yourself if you feel so inclined. I'm sure many of us will be happy to help you smooth it over once you get the ball rolling. I agree that the FAQ page is far from ideal, and horribly out of date in many places.
Re: Unicode function name? ∩
On Monday, 29 August 2016 at 12:53:26 UTC, Jesper Tholstrup wrote:
Personally, I would prefer 'intersect' as a function name over
'∩' anytime.
Which benifits does the symbols add?
Sounds like you'd love Java.
x = new BigDecimal("0.1")
x.negate().divide(y).compareTo(z)
who needs symbols? >_>
Re: if-expressions
On Sunday, 28 August 2016 at 13:48:43 UTC, Tomer Filiba wrote:
Python uses `x = 5 if cond else 6`, which is by far more
readable
-tomer
conseq1 if cond1 else conseq2 if cond2 else conseq3 if cond3 else
conseq4
I dunno man, it seems all backwards to me. If you're gonna do it
this way, then you'd also want your if-statements like this:
{
foo();
bar();
} if (cond);
Could you imagine trying to read a function you didn't write
yourself if branches were written like that?
But more importantly IMO the order of execution should be
reflected in the syntax. Even if you put the condition in the
middle, it still gets executed first.
Re: Allows the use of part of the language keywords?
On Sunday, 28 August 2016 at 08:25:38 UTC, Basile B. wrote: to think that it can be detected with a simple lookup backward (or forward from the KW) is too simplistic. I'm not saying it'd necessarily be easy to distinguish keyword 'body' from identifier 'body' in the lexer, I'm just saying a 'look-behind' feature in a lexer would be trivial to implement.
Re: if-expressions
On Sunday, 28 August 2016 at 10:08:09 UTC, vladdeSV wrote: Nice work! However, don't you think it's a bit odd that `if(asdf : <-- colon 5 else 6)` equals `asdf ? <-- questionmark 5 : <-- colon 6;` Mm you're right, I had the same concern. The ':' or '?' could both be just as easily used here, but I figured since IfExpressions kind of make ternary conditionals obsolete, it'd be better to 'free-up' the '?' token for other purposes. Maybe you have some other ideas?
Re: Allows the use of part of the language keywords?
On Sunday, 28 August 2016 at 04:32:46 UTC, Basile B. wrote: You must keep track of the previous token, which is not usually done in a scanner. That sounds like a pretty trivial feature to me. There's no way that's a legitimate obstacle.
Re: Unicode function name? ∩
On Sunday, 28 August 2016 at 05:21:03 UTC, Tofu Ninja wrote: Are unicode function names not supported in dmd? Here's a few ANSI characters you can use (and can type with alt-codes): ª º · Ø ø µ ƒ I use º pretty often, it makes a nice sigil.
Re: if-expressions
On Saturday, 27 August 2016 at 01:45:58 UTC, Bill Hicks wrote: Yes, fully implementing new language syntax is how I troll on the internet.
Re: Proper concurrent nearly lock free efficient nogc storage structures?
On Saturday, 27 August 2016 at 01:06:53 UTC, Illuminati wrote: Surely one of the many intelligent people on this forum should be able to implement some of the basic structures fairly quickly? Most of these people are happy to use the GC, so @nogc structures are not a priority.
Re: Proper concurrent nearly lock free efficient nogc storage structures?
On Friday, 26 August 2016 at 23:38:02 UTC, Illuminati wrote: Does D have any such thing? I'm having to recreate the wheel here and it isn't fun ;/ Getting in the way of real work ;/ @nogc is such a new language feature that you can't expect a lot of support yet from e.g. the standard library. But in any case, Phobos is a very minimal library when it comes to data structures, for better or for worse. I personally hate to say it. However if you don't have your eye on Phobos, disregard my response, it was hard to tell from your question.
Re: Does D have any construct like Python's with keyword?
On Friday, 26 August 2016 at 23:28:27 UTC, pineapple wrote:
I've grown to very much appreciate how context initialization
and teardown can be very conveniently handled using `with` in
Python. Is there any clean way to imitate this syntax in D?
Yep, scope guards.
auto p = OpenProcess(...);
scope(exit) {CloseHandle(p);};
Re: GC Inspiration
On Friday, 26 August 2016 at 21:41:04 UTC, Robert M. Münch wrote: I'm just digging into LuaJIT and found this interesting GC concept page: http://wiki.luajit.org/New-Garbage-Collector Not sure if this is widly known but I like it, it shows a lot of different approaches with rational etc. Maybe it's of use to some of you thinking about the GC. I don't know how much of this is applicable to D, but this looks like it has some really valuable insights. I will definitely read it for the sake of a GC I've been planning on writing for a different language. Thanks for pointing this out.
Re: if-expressions
On Friday, 26 August 2016 at 18:25:00 UTC, Cauterite wrote: // any number of condition/predicate pairs ehem... "any number of predicate:consequent pairs"
if-expressions
Here's a little patch you guys might enjoy: https://github.com/dlang/dmd/compare/master...Cauterite:ifExpr0 It enables this syntax: int foo = if(asdf: 5 else 6); equivalent to int foo = asdf ? 5 : 6; Here's some other examples which work: // any number of condition/predicate pairs foo = if( asdf : 5, doZxcv(bar) : 90 else 6 ); // redundant commas and colons permitted foo = if( a : 5, b : 90, else : 6, ); // roughly equivalent to // foo = asdf ? 5 : doZxcv(bar) ? 90 : assert(0); foo = if( asdf : 5, doZxcv(bar) : 90 ); Also it doesn't conflict with if-statement syntax, as far as I'm aware. Just a little experiment to learn my way around the parser.
Re: Allows the use of part of the language keywords?
On Friday, 26 August 2016 at 14:16:27 UTC, Brian wrote: package application.module.user.model; I get "Error: identifier expected following '.' instead of 'module'" So I'm not sure how that compiles for you.
Re: C# 7 Features - Tuples
On Thursday, 25 August 2016 at 14:43:35 UTC, Dominikus Dittes
Scherkl wrote:
But I dislike the named tuple members.
Why not declare them at the calling site?
(int, int, int, string) fn()
{
return (3, 2, 1, "meins");
}
Because how are you supposed to know what each member of the
tuple represents? If you read the function signature all you see
is "int, int, int, string".
Re: using .init reliably
On Friday, 26 August 2016 at 15:14:42 UTC, Steven Schveighoffer wrote: FYI, you cannot make this patch until we fully deprecate the use of TypeInfo.init: https://github.com/dlang/druntime/blob/master/src/object.d#L294 So at least until 2.075. -Steve Ah yes, good thinking. I'll keep that in mind.
Re: using .init reliably
On Friday, 26 August 2016 at 09:48:00 UTC, Jonathan M Davis wrote: And I expect that it will become an error at some point in the future to define an init member for a user-defined type, at which point, there won't be any choice about fixing it. I might take a crack at this patch. Sounds pretty trivial.
using .init reliably
How can I get the initial value of an arbitrary type? Since any
struct can override it, .init is not reliable:
struct Z {
enum init = 6;
string val = `asdf`;
};
assert(Z.init == 6);
assert(typeof(Z()).init == 6);
I know I could use
*(cast(Z*) typeid(Z).initializer.ptr)
but that doesn't work in CTFE (because the typeinfo doesn't exist
yet).
Z() is obviously not reliable either since it can override static
opCall.
Re: Optimisation possibilities: current, future and enhancements
On Thursday, 25 August 2016 at 12:27:20 UTC, Cecil Ward wrote: When I said GCC/LLVM I meant GDC(GNU D Compiler)/LDC(LLVM D Compiler). I might have caused some confusion there.
Re: Optimisation possibilities: current, future and enhancements
On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote: * the GCC "__builtin_expect()" Instead of adding individual micro-optimisation features like this, I'd be more interested in the potential for profile-guided optimisation (which *ideally* can make these micro-optimisation decisions automatically). Since DMD already has some framework in place to support code profiling, I suspect this is at least a feasible enhancement. On the other hand, it might not be worth trying to play catch-up with existing PGO features in GCC/LLVM. If you're using PGO, you're probably already using these other backends for their more advanced static optimisers.
Re: Optimisation possibilities: current, future and enhancements
On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote: I long for the day we ditch signalling NaNs — they would surely prevent `-ffast-math` from being effective. I have a couple more ideas, here's one of them: - if a function is pure and called with constexpr parameters, the compiler could potentially execute that call in the CTFE engine (automatically), as part of the constant-folding phase I guess. Such a technique will hopefully one day be practical, once the CTFE engine's performance improves.
Re: nested enum
On Thursday, 25 August 2016 at 10:36:21 UTC, Daniel Kozak wrote: Btw, tehre is no need for extra semicolon (`;`) after enum and struct definition Thanks. This forum insists on reminding me every time I write code here.
Re: nested enum
On Wednesday, 24 August 2016 at 23:04:25 UTC, Illuminati wrote:
Well those other answers aren't wrong, but I envisioned that
you'd have multiple categories within your sub-enums and whatnot,
so you'd need something more like this:
struct A {
enum X {
one,
two,
three,
};
enum Y {
four = X.max + 1,
five,
six,
};
enum Z {
seven = Y.max + 1,
eight,
nine,
};
};
Continuing each enumeration from the end of the previous ensures
you won't get any fields with the same values.
Re: pull requ. 6068 (issue 15257) -- need advice
On Wednesday, 24 August 2016 at 20:42:36 UTC, Cauterite wrote: _> now it appears. Sorry guys, feel free to delete this thread.
pull requ. 6068 (issue 15257) -- need advice
NOTE: I tried to post this on the DMD sub-board, but it gave me and error and my post never appeared, so I'm putting it here instead. I've been working on this patch: https://github.com/dlang/dmd/pull/6068 which fixes up some severe flaws in the inline assembler. But I've hit a roadblock. The patch is almost correct, everything *appears* to be working as intended, except for this obscure bug that has somehow been introduced as a side effect of the patch: Makefile:205: recipe for target 'test_results/d_do_test.exe' failed gmake: *** [test_results/d_do_test.exe] Error 127 See my latest comment for details: https://github.com/dlang/dmd/pull/6068#issuecomment-242147910 The problem is, I don't know where to start with debugging this. I'm really struggling to envision how my patch could've caused it. Even some basic suggestions or speculation would be much appreciated. This is my first time working on the DMD codebase, so I've been discovering the details of its componentry along the way as I diagnosed the bugs I encountered. Because this bug is manifesting outside the compiler, I can't think of how I can trace it back to its source. Thanks for any help you can provide. I've been working hard on this patch, so I really want to see it completed.
Re: Usability of D on windows?
On Tuesday, 23 August 2016 at 21:37:57 UTC, John Burton wrote: Although they have windows as a host it says that the target is arm-linux-gnueabi so I assumed they were cross compilers? I heard that GDC worked with MinGW at some point in the past, so it may still be feasible without cross-compilation. You'll have to ask someone else about this though.
Re: Usability of D on windows?
On Tuesday, 23 August 2016 at 21:36:12 UTC, John Burton wrote: It might be fast enough though so I could try it. Remember, if you don't like the compiler's output, you can always substitute it with your own (inline assembly!). Incidentally I'm in the process of fixing a number of IASM bugs in the frontend right now.
Re: Usability of D on windows?
On Tuesday, 23 August 2016 at 21:15:40 UTC, John Burton wrote: Well, you're fighting a losing battle by trying to use GDC/LDC on Windows, since Windows is priority #2 for D, and GDC/LDC are still struggling with priority #1 (Linux). You make the Digital Mars backend sound unusable, but I think you should give it another chance. I personally find most bugs originating from the backend are triggered by corner-cases which can be easily avoided until the bug is fixed.
Re: Do you like bounded integrals?
On Tuesday, 23 August 2016 at 20:40:06 UTC, Andrei Alexandrescu
wrote:
I think all of these questions have answers, but I wanted to
gauge the interest in bounded checked integrals. Would the need
for them justify additional complications in the definition?
Well, this occurs very frequently in my code:
struct S {
int foo;
invariant {
assert(ordered_(MIN, foo, MAX));
};
};
If bounded integers can handle this for me then you've got my
support. Assuming the checks disappear in -release.
Re: Phobos uni methods
On Monday, 22 August 2016 at 07:58:50 UTC, Andrew wrote: Note that changing isAlpha() can potentially break any D code with unicode in its identifiers, because the DMD frontend uses isAlpha() to determine which characters are allowed in identifiers.
Re: Float values are wrong in union
On Monday, 22 August 2016 at 04:37:50 UTC, stunaep wrote: I made a union to convert between int bits and floats, but the values are coming out wrong sometimes. I can already tell what this is going to be... The problem is almost certainly nothing to do with your union, it's this line: float t2 = t.f; This will load 0x7fb0 into ST(0), which instantly converts it to 7FF0 because it's a signalling NaN, then store ST(0) in your float `t2`. Signalling NaNs are an ongoing problem in D's codegen. See Don's remarks at this page: https://issues.dlang.org/show_bug.cgi?id=16105#c2 The reason it works in other languages is because they don't place floats in the floating point registers for non-arithmetic operations. I've been trying to patch DMD's backend to behave this way too, but it's much harder than I expected (difficult codebase to understand/navigate).
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 18:31:26 UTC, Zane wrote: I see - That makes sense, but is there no way to "pause/stop" the GC, but still be able to use the 'new' syntax? Oh you can use `new` when the GC is disabled, no problem. All the GC's functionality is still available. But be careful about what I said with `new` not returning the base of the allocation. It might not be safe to explicitly `free()` memory allocated by `new` if there could be multiple objects in the same memory block. I honestly don't know the facts about this. You can always `GC.free()` memory you've allocated yourself with `GC.malloc()`, so malloc+emplace is an option. You could define a template to give more convenient syntax. Also I think you can overload the `new` operator. I've never tried it. Regarding the marking, I guess my question is: what must be done to ensure something allocated with 'new' will be a candidate for auto-collection later (when GC is enabled)? I don't think it's possible with a conservative garbage collector, because anything that looks like a pointer to your object can prevent it from being collected. However, if there are no actual live pointers to it, the chances that it will be collected are very high, especially on 64-bit systems. So for now, your best bet is to make sure your object is not accessible (set all live pointers to it to null). It will only stay in memory if you're very unlucky. Once we have a precise garbage collector (should be soon) you can be sure an object will get collected if it is not accessible from any live pointers. -- By the way, when I say "live pointer", I mean a pointer which is accessible (through any number of indirections) from the memory roots. e.g. If you have a linked list on the heap, with each node pointing to the next, but no other pointers to any of the nodes (e.g. from the stack) those pointers are not live. The list as a whole is not accessible.
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 16:14:53 UTC, Zane wrote: 1) If using the GC, but for whatever reason, I need to free something _right now_, is core.GC.free() the proper way to do this? The main problem is that `new` does not necessarily give you a pointer to the start of an allocation, and `GC.free()` does not work if you give it a pointer to the interior of an allocated block. You could use `GC.addrOf()` to get the base address from an interior pointer, but I don't know whether there could be other objects/arrays sharing the same memory block. If you explicitly allocated the memory block yourself with `GC.malloc()` then you have full control over what is placed in it and can safely `GC.free()` the memory using the base address. Keep in mind, `GC.free()` does not call finalisers.
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 16:14:53 UTC, Zane wrote: 5) Is there a way to do simple heap allocation with 'new' while ensuring the GC doesn't deallocate until I want it to? While my earlier suggestion of using malloc/emplace is one option, another is to use `GC.addRoot(objPtr)`. It ensures the object is never deallocated until you call `GC.removeRoot(objPtr)`.
Re: Compiling DMD on Windows: A journey of mystery and madness
On Sunday, 21 August 2016 at 16:41:27 UTC, NX wrote: [warning: rant ahead] Consider using Digger ( https://github.com/CyberShadow/Digger ) in your future attempts to build DMD, to save yourself some trouble. I've had a great experience using it, apart from the dependency on visual studio.
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 16:14:53 UTC, Zane wrote: 2) Does calling object.destroy() mean that the object is marked for future collection? If not, how can I ensure it is properly marked. Because the GC is not of the incremental type, it can't perform any marking outside of a stop-the-world mark/sweep cycle. Instead, what `destroy()` does is finalise an object: that is, runs any destructors and puts it in an invalid state — in particular, all pointers contained within the object are nullified, so it doesn't reference any other objects. When I say 'object' I mean anything; class instance, structure, array, primitive, whatever.
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 16:14:53 UTC, Zane wrote: 6) If the GC is off, how is allocation/deallocation handled? Can I still use new for example (and how do I dealloc)? All the allocation/deallocation functionality is the same as normal, except the GC won't start a collection cycle unless it's out of memory. You can still use `free()` to deallocate, and it will free memory straight away.
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 16:14:53 UTC, Zane wrote: 5) Is there a way to do simple heap allocation with 'new' while ensuring the GC doesn't deallocate until I want it to? I can answer this at least, If you don't want the GC to ever collect the object itself, here's the best way: Allocate the object with a non-GC allocator (such as std.c.malloc ), then use `emplace` to construct the object in that memory ( http://dlang.org/phobos/std_conv.html#.emplace ).
Re: MurmurHash3 behaviour
On Friday, 19 August 2016 at 21:03:22 UTC, Seb wrote: http://dlang.org/phobos-prerelease/std_digest_murmurhash.html Ah great, I just finished writing my own murmurhash digest module ( https://github.com/Cauterite/phobos/blob/murmur/std/digest/murmur.d ), and now I discover someone's already done it. Glad I wasted the last 3 hours of my life ;_;
MurmurHash3 behaviour
Regarding the MurmurHash3 implementation in core.internal.hash, it is my understanding that: // assuming a and b are uints bytesHash([a, b], 0) == bytesHash([b], bytesHash([a], 0)) Is this correct? I'm just not quite certain of this property when I try to read the code myself, and I don't know much about hash algorithms.
Re: having a trivial anonymous function call in template prevents compilation?
On Wednesday, 17 August 2016 at 13:33:26 UTC, Steven Schveighoffer wrote: I think the OP's case is a bug. Please file. Thanks, I've filed it. Just wanted to get a second opinion before concluding that it's a bug.
Re: having a trivial anonymous function call in template prevents compilation?
On Wednesday, 17 August 2016 at 13:18:06 UTC, Adam D. Ruppe wrote:
Best you can do is use them in an alias argument directly, but
you cannot use them in an enum argument.
I think you missed the point; it works perfectly fine without
having this `({return 0;})()` in the template body (which, as far
as I can see, doesn't appear to interact at all with the template
argument).
having a trivial anonymous function call in template prevents compilation?
// -- Example: --
template A(alias Arg) {
enum A = Arg;
enum Unrelated = ({return 0;})(); // this line prevent
compilation
};
void main() {
enum FnPtr =
enum _ = A!FnPtr;
};
void asdf() {};
// ( https://dpaste.dzfl.pl/79301f12e5fc )
Just by having a random `({return 0;})()` in the template body,
suddenly the template rejects its arguments. I'm so confused, is
this a bug? Or am I missing something?
Re: When does take modify the underlying iterator?
On Tuesday, 16 August 2016 at 21:01:14 UTC, cy wrote: This has also been annoying me lately, so I came up with this workaround: InputRange!T X = inputRangeObject(Src); X.take(6); // remove+return items 0 to 5 X.take(3); // remove+return items 6 to 8
Re: Passing Structs to function like in C
On Sunday, 14 August 2016 at 16:21:58 UTC, D.Rex wrote: so '();' works the same as 'foo.bar();'? with pointers, D automatically rewrites expressions like this: f.fooMethod() to this: (*f).fooMethod() which is why you're able to index an object-pointer-pointer (Foo*) the same way as an object-pointer (Foo). Most built-in D types have value semantics, so it's understandable that you wouldn't expect classes to be reference types. Associative arrays are also reference types, FYI. Structs on the other hand are value types; if you're new to the language make sure you familiarise yourself with the differences between structs and classes.
Re: if static member then call
On Saturday, 13 August 2016 at 18:34:43 UTC, Engine Machine wrote: static if (hasStaticMember!(T, "foo")) Here I suspect you're looking for this: __traits(isStaticFunction, __traits(getMember, T, "foo"))
Re: if static member then call
On Saturday, 13 August 2016 at 18:34:43 UTC, Engine Machine wrote:
auto ref foo(T, Args...)(args)
{
static if (hasStaticMember!(T, "foo"))
return T.foo!(T)(args);
}
Basically I want to forward the *static* call to T if
possible(if foo exists in T). The main problem is actually
calling T.foo as the syntax here doesn't work. I also need to
be able to check to see if a method is static, since I have no
object.
you're probably gonna want something like, if i understand your
question correctly:
return __traits(getMember, T, "foo")(args);
Re: Passing Structs to function like in C
On Saturday, 13 August 2016 at 15:47:51 UTC, D.Rex wrote:
/* memory.d file */
module memory;
import include.linux.sched;/* contains task_struct
definition */
void free_page_tables(task_struct* tsk) {
/* do something with */
}
And to use the method from somewhere else
/* use method.d */
module usemethod;
import include.linux.sched;
import mm.memory;
void some method() {
free_page_tables(*pointer to task_struct*);
}
I hope my explanation is not rambling nonsense.
Cheers.
Yes, you're right. Passing structure pointers to functions is an
extremely common practice in C, because there aren't really any
other compelling options. In D we have things like methods,
classes, 'const ref' params, return-type inference, etc., so
there's usually a better way to achieve the same result.
Re: 'importing' threads — i.e. thread_attachThis()
On Friday, 12 August 2016 at 18:59:35 UTC, Guillaume Piolat wrote: On Friday, 12 August 2016 at 10:45:22 UTC, Cauterite wrote: Thanks, this is very helpful. I already feel much more confident about the idea. My use is definitely the 'whole-lifetime' case, so I might be able to get away with ignoring the `_beginthreadex` business since at this stage I won't be using CRT functions anyway. The only reason I can't run through _beginthreadex normally is because I'm allocating the thread stack myself, which requires use of NtCreateThread.
Re: Passing Structs to function like in C
Thanks colon-nazis, I'll take that into consideration ¬_¬
Re: Passing Structs to function like in C
On Friday, 12 August 2016 at 16:50:43 UTC, ag0aep6g wrote: On 08/12/2016 05:23 PM, Cauterite wrote: No semicolon there, please. Why would I not terminate a declaration with a semi-colon? Why should a declaration not end in a semi-colon just because the last token is a brace? Why should I not tell the lexer precisely where my declaration ends instead of relying on whatever other tokens floating around it not interfering? Why must every thread in this forum contain more posts regarding some irrelevant tangent than posts responding to the original topic?
Re: Passing Structs to function like in C
On Friday, 12 August 2016 at 15:21:22 UTC, D.Rex wrote:
extern unsigned long free_page_tables(struct task_struct * tsk);
extern(C) ulong free_page_tables(task_struct* tsk);
void main() {
task_struct tsk = …… ;
free_page_tables();
};
That should be what you're after?
'importing' threads — i.e. thread_attachThis()
I'm planning on 'importing' a thread into the D runtime using thread_attachThis(), and was just wondering about the potential pitfalls of this process. For example: - Would having an entry function other than core.thread.thread_entryPoint() pose problems? What about during stack unwinding? Should I try to replicate the exception handling code of thread_entryPoint() in my own entry function? - I'm aware of having to invoke rt_moduleTlsCtor() explicitly, but what about rt_moduleTlsDtor() ? Should I again follow thread_entryPoint()'s behaviour here? - How important is it to run the thread though _beginthreadex() ? I know the Microsoft CRT uses _beginthreadex()/_threadstartex() to set up the thread's '_tiddata' object, but since D uses the Digital Mars _beginthreadex (which I don't have source for) I'm not entirely sure what goes on in there. It *appears* to be messing around with a global '__thdtbl' object. - Do I need to call thread_detachThis() when the thread terminates, or can I just wait until the corresponding Thread object gets destroyed by the GC? I'm using DMD on Windows x32 by the way. Thanks for your help.
Re: method static-ness has no effect on the type?
On Monday, 8 August 2016 at 10:21:47 UTC, ag0aep6g wrote: Also thanks for submitting the bug for me.
Re: method static-ness has no effect on the type?
On Monday, 8 August 2016 at 10:05:58 UTC, ag0aep6g wrote:
The first assert compares the return types of f1 and f2. They
both return `void`, so everything's fine there.
I think you're mistaken about this. typeof(S.f1) definitely gives
the type of the function, not of the return. Try it out:
struct S {
void f1(int, string, float) {};
};
static assert(typeof(S.f1).stringof == "void(int, string,
float)");
( https://dpaste.dzfl.pl/cda66002120a )
Re: [DIP] In-place struct initialization
On Friday, 5 August 2016 at 07:04:55 UTC, deadalnix wrote: Also, there are nice library solution for named argument already. Which ones do you have in mind?
Re: Tracking memory usage
On Sunday, 7 August 2016 at 00:28:40 UTC, Alfred Pincher wrote:
this is a very nice feature. I hope D has something similar?
If you want to implement that kind of allocation tracking you'll
probably want to use gc_getProxy()+gc_setProxy(). They're global
C functions you can access by declaring:
extern(C) gc.gcinterface.GC gc_getProxy() nothrow;
extern(C) void gc_setProxy(gc.gcinterface.GC);
First call gc_getProxy() to get the real GC instance and save it
somewhere.
Then call gc_setProxy() with your object implementing the GC
interface functions, and in each function forward to the
corresponding function of the real GC instance, after any
statistic-gathering code you want run.
Something like this:
__gshared GC RealGcInstance = gc_getProxy();
__gshared GC MyProxy = new class GC {
// ...
extern(C) void gc_free(void* Ptr) nothrow {
printf("freeing pointer %x\n", Ptr); // or whatever
return RealGcInstance.free(Ptr);
};
// ... etc.
};
gc_setProxy(MyProxy);
I haven't tested this method myself, but it will probably work.
Refer to
https://github.com/dlang/druntime/blob/master/src/gc/proxy.d and
https://github.com/dlang/druntime/blob/master/src/gc/gcinterface.d
Also remember that you can't invoke the GC from inside the proxy
functions. Using helper functions marked @nogc might make it
easier to avoid.
method static-ness has no effect on the type?
See: https://dpaste.dzfl.pl/2ec6780d4b25 We have two methods defined, f1 and f2, where f2 is static but they have otherwise identical signatures. We can see from the disassembly that f1 receives a `this` pointer while f2 does not. Yet, typeof() == typeof(). This makes no sense, how can the compiler even know whether to pass a `this` pointer when both methods have same type?
Re: Cannot distinguish between template function wtih 0 args and 1 arg
On Monday, 8 August 2016 at 02:36:24 UTC, Engine Machine wrote: Error: template Mem cannot deduce function from argument types !(cast(eException)1280L, "main.d", 38u, "main.WinMain")(int), candidates are: Mem(T, B = eX, string file = __FILE__, uint line = __LINE__, string func = __FUNCTION__)(size_t bytes) Mem(T, B = eX, string file = __FILE__, uint line = __LINE__, string func = __FUNCTION__)() From this error message it looks like the `B = eX` parameter is not getting matched up against the value `cast(eException)1280L` as you are hoping for. Probably because `1280L` is a value and it's expecting a type. Try replacing it with something like `alias B = eX` or `enum B = eX`.
Re: assert or throw in range members?
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote: Should range members front() and back() assert() or throw() on emptyness? I'm pretty sure it's assert() here. The contract is that the caller is responsible for checking emptiness beforehand, and the whole of Phobos is coded around that contract. I think. If it should assert() doesn't that lead to unsafer code in release mode? That's the point of release mode. Omitting superfluous checks based on the assumption that your code is correct (e.g. assumption that the emptiness contract is respected).
Re: Overflows in Phobos
On Saturday, 30 July 2016 at 00:55:11 UTC, Charles Hixson wrote: FWIW, in that case I always use assert (false, "..."); I try to never use integers for booleans. But this may well be a common usage. I suspect `assert(0)` is really `assert(constexpr>)`, so you should be fine. Both styles are used in Phobos.
Re: [DIP] In-place struct initialization
On Saturday, 30 July 2016 at 22:05:29 UTC, cym13 wrote:
On Saturday, 30 July 2016 at 21:45:31 UTC, Cauterite wrote:
On Saturday, 30 July 2016 at 21:42:42 UTC, cym13 wrote:
...
Here's something you might enjoy in the meantime:
https://github.com/Cauterite/dlang-pod-literals/blob/master/podliterals.d
Thanks, I'm aware of this work but some points just aren't good
enough IMHO. We can do better than that. First of all the
syntax is too far appart from traditional field assignment
which is always done using ':' . I understand why it is so but
still it makes one more thing to remember. Calling lambdas all
the time isn't free while the change I propose is static. Those
lambdas aren't optimized away by DMD and while that might
change I just don't feel like trusting it. And more importantly
it doesn't work with common structs, you have to pass it to
your template first and then it isn't the struct anymore. There
are just too many ways for this to get wrong in my opinion.
Note that I find the idea ingenious and interesting, I just
think we can do better than that.
It does work with common structs:
struct Xyzº {
int X;
wstring Y;
Object Z;
};
auto Thing = pod!(Xyzº,
Y => `asdf`w,
X => 3,
Z => null,
);
assert(is(typeof(Thing) == Xyzº));
But anyway, you don't need to convince me that having a native
language feature would be superior to this template nonsense :P
It's just a workaround for the moment (albeit a bloody powerful
workaround!)
Although I do like being able to both define and instanciate a
structure in the same expression (especially with unions). Maybe
that could be a future extension to your DIP.
Re: [DIP] In-place struct initialization
On Saturday, 30 July 2016 at 21:42:42 UTC, cym13 wrote: ... Here's something you might enjoy in the meantime: https://github.com/Cauterite/dlang-pod-literals/blob/master/podliterals.d
Re: Does D have object wrappers for primitives?
On Saturday, 30 July 2016 at 04:12:45 UTC, stunaep wrote: Thank you. This is just what I needed. I am curious though as to why this doesn't work with strings. It would work if I removed immutable from the Boxed constructor but I thought strings were immutable. I get a compiler error 'not callable using a mutable object'. Even marking a string with the immutable keyword has the same result. auto s = new immutable(Boxed!string)(`foo`); what it's saying is that the box itself needs to be immutable. Honestly I don't know why it was even possible to make a mutable box in the first place, when the only constructor is marked `immutable`.
Re: [OT] Music to Program Compilers To
On Friday, 29 July 2016 at 22:44:04 UTC, Walter Bright wrote: http://70sdisconights.com/ Yes, I listen to it while I work. that webpage design though >_<
Re: Does D have object wrappers for primitives?
On Friday, 29 July 2016 at 20:26:47 UTC, Ali Çehreli wrote: I was going to suggest Algebraic because it allows arrays of mixed primitive types (wrapped in Algebraic): https://dlang.org/phobos/std_variant.html#.Algebraic Ali It could work, but keep in mind Algebraic is a structure, not an object.
Re: Does D have object wrappers for primitives?
On Friday, 29 July 2016 at 20:13:34 UTC, stunaep wrote:
I have some java code I need to convert and at one point it
uses an Object[] array to store various ints, longs, and
strings. Java has built in Integer and Long classes that wrap
the primitives in an object and strings are already objects.
No, but with a template you could easily make your own:
class Boxed(T) {
T _v;
alias _v this;
this(in T v) immutable {_v = v;};
};
auto i = new Boxed!int(6);
Re: When I should to call destroy?
On Friday, 29 July 2016 at 13:18:00 UTC, Suliman wrote: But I can't understand if D have GC it should remove objects when their life is finished. When I should to call `destroy`? What would be if I will not call it? `destroy` is mainly about running destructors deterministically. From the source comments: "It's used to destroy an object so that any cleanup which its destructor or finalizer does is done and so that it no longer references any other objects." For example, your object might allocate a large amount of manually-managed memory, and you don't want that allocation laying around until the next GC cycle, so you can use `destroy` to finalise your object as early as possible to release that manually-managed allocation. If you really want to deallocate the object's own memory, you can check out core.memory.GC.query() / core.memory.GC.free().
