Re: How do I the temlate parameter name as string?
On Tue, 27 Nov 2018 02:00:44 +, PacMan wrote:
> f is defined as:
>
>> void f(T)(T t, string p)
>> if(is(T == A) || is(T == B))
>>{
>> // ...
>>}
>
> my goal is get "p" as string.
`f` is a template that generates functions. Before you instantiate that
template, the function doesn't exist, so there's no function to get
parameters from.
You can get the parameter names of any instantiation of that template,
such as:
assert(ParameterIdentifierTuple!(f!A)[1] == "p");
Re: How do I the temlate parameter name as string?
On Tuesday, 27 November 2018 at 02:00:44 UTC, PacMan wrote:
ParameterIdentifierTuple from std.traits did work fine for
regular functions but not for template functions:
Error: template instance
`std.traits.ParameterIdentifierTuple!(f)` does not match
template declaration `ParameterIdentifierTuple(func...) if
(func.length == 1 && isCallable!func)` (foo)
f is defined as:
void f(T)(T t, string p)
if(is(T == A) || is(T == B))
{
// ...
}
my goal is get "p" as string.
If I'm understanding right I need this quite frequently so I
wrote this:
template nameOf(alias nameType)
{
enum string nameOf = __traits(identifier, nameType);
}
unittest
{
immutable int name;
assert(nameOf!name == "name");
}
How do I the temlate parameter name as string?
ParameterIdentifierTuple from std.traits did work fine for
regular functions but not for template functions:
Error: template instance
`std.traits.ParameterIdentifierTuple!(f)` does not match
template declaration `ParameterIdentifierTuple(func...) if
(func.length == 1 && isCallable!func)` (foo)
f is defined as:
void f(T)(T t, string p)
if(is(T == A) || is(T == B))
{
// ...
}
my goal is get "p" as string.
Re: D is supposed to compile fast.
On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote: Any time I see people mention the benefits of D, I see "compile times" "compile times" "compile times" over and over. I'm using very modest amounts of templates, for a fairly small sized program (very early work toward a game), and I'm hitting ~15 seconds compile time in LDC and ~7 seconds in DMD. And I'm not even compiling with optimizations! ldc2 -w -ofextra extra.d molto.d helper.d editor.d common.d map.d object_t.d animation.d ini.d -L-L. $@-gc -d-debug=3 -de -fdmd-trace-functions dmd -w -ofextra extra.d molto.d helper.d editor.d common.d map.d object_t.d animation.d ini.d -profile=gc -profile -g -debug -color -L-L. I keep putting stuff into new files, but it feels like it's compiling everything from scratch / not getting faster the way C++ does. And I'm not even bringing up the 800MB of RAM required because I dared to import std.regex. (On a laptop with 2 GB of RAM. RIP. If I dare to have tabs open, the compile time goes into the minutes thanks to swapping.) I've profiled your example, unsurprisingly allmost all of the compiletime is eaten by regex, which is executed at compile-time. Most of the time there is actually taken by the template-instantiation and the templates which are involved in building the IR and such. newCTFE helps out a little, but for this to be fast, std.regex would have to be rewritten with CTFE in mind. Maybe you can generate a finite automaton for your regex offline using some other engine like which supports D or C. That alone should cut a few seconds of your compile-times and prevent out-of-memory errors, I hope this helps. Cheers, Stefan
Re: interrupting a function
On Saturday, 17 November 2018 at 08:17:36 UTC, Paul Backus wrote:
You could run the calculation in another thread and use
std.concurrency.receiveTimeout [1] to stop waiting for the
result after a certain amount of time.
Ok... would you say the following is a feasible alternative?
´´´
import std.experimental.all;
import core.thread;
auto assumeNoGC(T) (T t) if (isFunctionPointer!T || isDelegate!T)
{
enum attrs = functionAttributes!T | FunctionAttribute.nogc;
return cast(SetFunctionAttributes!(T, functionLinkage!T,
attrs)) t;
}
struct D
{
size_t d;
static S s;
}
struct S
{
size_t dummy;
D[] data;
}
struct Model
{
auto ref s()
{
return D.s;
}
size_t counter;
void run() @nogc
{
do
{
debug
{
"I'm running".writeln;
writeln(s.data.length);
writeln(s.dummy);
}
// some heavy work, which is nogc
Thread.sleep(1.seconds);
assumeNoGC((){
yield(); // is stack change a nogc action?
})();
counter++;
}while(counter < 10);
}
}
Fiber composed;
auto myCall()
{
return composed.call;
}
void main()
{
Model m;
composed = new Fiber( );
D.s.data.length = 4;
D.s.dummy = 42;
import std.datetime.stopwatch : Duration, benchmark;
Duration res;
bool abort;
while(composed.state != Fiber.State.TERM)
{
writeln(res == Duration.zero);
res += benchmark!(((myCall)))(1).front;
writeln(m.counter);
writeln(composed.state);
writeln(res);
writeln(res > 5.seconds);
if(res > 5.seconds)
{
abort = true;
break;
}
}
assert(abort);
}
´´´
Re: version(StdDoc)
On Sun, Nov 25, 2018 at 09:53:50PM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
> On Sunday, 25 November 2018 at 21:38:43 UTC, H. S. Teoh wrote:
>
> > Actually, I just thought of a way to do this with the existing language:
> > use a struct to simulate an enum:
> >
> > struct E {
> > alias Basetype = int;
> > Basetype impl;
> > alias impl this;
> >
> > enum a = E(1);
> > enum b = E(2);
> > version(Windows) {
> > enum c = E(3);
> > }
> > version(Posix) {
> > enum c = E(4);
> > enum d = E(100);
> > }
> > }
>
> Heh, that can work in a pinch. Disgusting though :D
I dunno, given that D structs are supposed to be "glorified ints"
according to TDPL, I see enum declarations more-or-less as a shorthand
for structs of the above sort. :-D Much like template functions / enums
/ etc. are shorthands for eponymous templates.
> > It's not 100% the same thing, but gets pretty close, e.g., you can
> > reference enum values as E.a, E.b, you can declare variables of type
> > E and pass it to functions and it implicitly converts to the base
> > type, etc..
> >
> > There are some differences, like cast(E) won't work like an enum...
>
> It should, you can cast values of same sizeof to a struct.
[...]
Haha, didn't know that.
T
--
Dogs have owners ... cats have staff. -- Krista Casada
Re: handling shared objects
On Monday, 26 November 2018 at 16:27:23 UTC, Steven Schveighoffer wrote: On 11/26/18 10:37 AM, Alex wrote: On Monday, 26 November 2018 at 15:26:43 UTC, Steven Schveighoffer wrote: Well, if you want to run calculations in another thread, then send the result back to the original, you may be better off sending the state needed for the calculation to the worker thread, and receiving the result back via the messaging system. How to do this, if parts of the state are statically saved in a type? For instance, with your toy example, instead of saving the D[] as a static instance to share with all threads, use idup to make a complete copy, and then send that array directly to the new thread via spawn. When the result is done, instead of sending a bool to say it's complete, send the answer. Sending an immutable copy is the easiest way to ensure you have no races. It may be more expensive than you want to make a deep copy of something, but probably less expensive than the headache of creating a non-debuggable monster race condition. Yeah... the problem is: the D[] array is stored statically not because of threads, but because every element of it has to have an access to it. So not to store it statically is the very point I want to avoid. But the idea is clear now, I think: I should delay the array expansion until the object is transferred to the other thread. Then, I expand the whole thing, (statically, as I would like to) do my calculations there and send back results, as you proposed. In this way, the object to copy will be a simple copy, because everything that would need a deep copy will be created in the proper thread, after the transfer. Thanks :)
Re: How to iterate getSymbolsByUDA
On 11/26/18 8:59 AM, Adam D. Ruppe wrote: On Monday, 26 November 2018 at 13:50:13 UTC, Eko Wahyudin wrote: seems my problem is i use GDC, i got this error error: basic type expected, not foreach. The common versions of gdc don't support static foreach, but plain foreach should work there the same way in this context. So just remove the word "static" and try it then. Yeah, the original code used for, not foreach. for does not work on compile-time alias sequences (which is what getSymbolsByUDA evaluates to). Using foreach should work with most flavors of the compiler. static foreach was a recent addition to D, so I expect GDC will be getting support for it eventually. -Steve
Re: handling shared objects
On 11/26/18 10:37 AM, Alex wrote: On Monday, 26 November 2018 at 15:26:43 UTC, Steven Schveighoffer wrote: Well, if you want to run calculations in another thread, then send the result back to the original, you may be better off sending the state needed for the calculation to the worker thread, and receiving the result back via the messaging system. How to do this, if parts of the state are statically saved in a type? For instance, with your toy example, instead of saving the D[] as a static instance to share with all threads, use idup to make a complete copy, and then send that array directly to the new thread via spawn. When the result is done, instead of sending a bool to say it's complete, send the answer. Sending an immutable copy is the easiest way to ensure you have no races. It may be more expensive than you want to make a deep copy of something, but probably less expensive than the headache of creating a non-debuggable monster race condition. Note that if you want to do it without safety in place, you can use the Thread class in core.thread which has no requirements for data to be immutable or shared. But you have to be even more careful about how you access the data. Ah... ok. But then, I will prefer to mark the appropriate parts as shared, I think... Right :) Threading is always very difficult to get right, and usually very difficult to find errors when you get it wrong. I remember working with pthreads about 20 years ago in a C++ project, and having a data race that caused a hang once every *2 weeks*. It took insane amounts of printouts and logging to figure out exactly why it happened (and the cycle was 2 weeks roughly), and the cause was (I think, not 100% sure) a place where a lock should have been but wasn't used. -Steve
derelict-sdl2 automatically stripping the SDL_ prefix from names
Hi,
I attempted to use a combination of traits and mixins to
automatically create aliases of names in SDL2 without the SDL_
prefix for convenience. However, I was only able to achieve this
for functions in the module, and not for types nor enum values.
How could I go about achieving the desired result? Here is the
code I'm using in an intermediate "sdl_stripped" module:
import std.regex;
import std.array;
public import derelict.sdl2.sdl;
string StripSDLPrefix() {
auto members = [__traits(allMembers, derelict.sdl2.internal)];
foreach(ref member; members) {
if (member.length > 4 && member[0..4] == "SDL_") {
member = "alias " ~ member[4..$] ~ " = " ~ member ~
";\n";
}
else {
member = "";
}
}
return members.join();
}
mixin(StripSDLPrefix());
// I added this to print the list of generated names for
debugging purposes.
static if (false) {
pragma(msg, StripSDLPrefix());
}
Re: handling shared objects
On Monday, 26 November 2018 at 15:26:43 UTC, Steven Schveighoffer wrote: Well, if you want to run calculations in another thread, then send the result back to the original, you may be better off sending the state needed for the calculation to the worker thread, and receiving the result back via the messaging system. How to do this, if parts of the state are statically saved in a type? Note that if you want to do it without safety in place, you can use the Thread class in core.thread which has no requirements for data to be immutable or shared. But you have to be even more careful about how you access the data. Ah... ok. But then, I will prefer to mark the appropriate parts as shared, I think...
Re: handling shared objects
On 11/26/18 10:16 AM, Alex wrote: On Monday, 26 November 2018 at 14:28:33 UTC, Steven Schveighoffer wrote: A static member is stored per thread. If you want a global that's shared between all threads, you need to make it shared. But the result may not be what you are looking for, shared can cause difficulty if your code wasn't written to deal with it (and a lot of code isn't). Well, the only reason I use multithreading is this: https://forum.dlang.org/thread/cfrtilrtbahollmaz...@forum.dlang.org So, even if my code is not really shared designed, this doesn't matter, as I wait for "the other" thread to end (or interrupt it). So, marking the model as shared is already a workaround, for being able to pass it to another thread, which I don't really need. However, now, if also all components of the model have to be marked shared, the workaround has to grow and expands over all components (?). This is the reason for this question... Well, if you want to run calculations in another thread, then send the result back to the original, you may be better off sending the state needed for the calculation to the worker thread, and receiving the result back via the messaging system. It's really hard to know the requirements with such toy examples, so maybe that's not workable for you. What it seems like you need is a way to run the calculations in a separate thread. But with multiple threads comes all the dangers of concurrency and races. So you have to be very careful about how you design this. At this point, std.concurrency does not have the ability to safely pass mutable data to another thread without it being shared. Note that if you want to do it without safety in place, you can use the Thread class in core.thread which has no requirements for data to be immutable or shared. But you have to be even more careful about how you access the data. -Steve
Re: D is supposed to compile fast.
On Sunday, 25 November 2018 at 22:00:21 UTC, Chris Katko wrote:. So 1) I have to compile manually, then link. Except that also runs the files every time even if they're up-to-date. Is that normal behavior for C/C++? Well you dont have to use separate commands but yes compiling and linking are two steps and its normal behavior for all native languages. Each OS have their own linker and we dont control that. Two questions/topics/issues: --- #1 How to I only build files that are dirty? Do I actually need a build program like DUB, MAKE, or CMAKE to do that? (Can make, cmake be used?) How do they recognize files are out-dated if DMD can't? Is that just an industry-standard specialization/separation-of-responsibilities to not have the compiler auto-detect up-to-date builds? Yes its separation of responsibilities and there are many tools to automate that. Take a look at rdmd "rdmd recompiles files only on a needed basis, e.g. two invocations of rdmd in sequence without an intervening change to any relevant source file does not produce the executable again." https://dlang.org/rdmd.html If dub or rdmd doesnt satisfy your needs then you will need to learn other build system. I have to tell you that, as an outsider (who is VERY interested in D), this is very frustrating. "Compile times are fast" != "build times" is a huge misconception that borders on being a clever lie or twisting of words. When people hear "compile times", they think "time to compile the whole project" not "time to compile a simple test case that doesn't use any typical D features--also, it's not linking." Second, as shown here, it's not fast even for compiling! Because the second you touch std.regex (which has NO WARNINGS in the documentation), you're greeted with another clever lie-by-omission: a 10x explosion of build time over some modules. Yes D have some rough spots thats for sure. For compile times these include std.regex, std.format and heavy CTFE use. There is newCTFE engine that is faster but its not ready yet. That said D code compiles faster than C++ and Rust. To really put fast into perspective read this https://news.ycombinator.com/item?id=18442941 So my point is, I keep running into either misconceptions that conveniently make D look good, and other gotchas with NO DOCUMENTATION that make the language much slower to work with than expected. People who advertise languages talk about positives and leave out negatives. One thing you need to know - D doesnt have huge sponsor and some places might be rough because of it. Currently core dev team focus more on stability and bug fixes than build speeds. I think you rather have compiler that works than compiler that crashes 1 sec faster. Its not all negatives with regex. Current regex implementation is one of the fastest in the world. Thats classic D trade of - you spend compile time for better runtime. I mean, can you think of any module in the Python/Javascript/C# standard library that simply including it will swell your program to the point it can't compile? Have you tried C++ boost?
Re: handling shared objects
On Monday, 26 November 2018 at 14:28:33 UTC, Steven Schveighoffer wrote: Some problems arose: 1. Obviously, this is not the case, as the output is different, depending on the thread I start the model function. Yes, unless you declare the model to be shared, there is a copy made for each thread, independently managed. 2. If I declare the model object inside the main, the compiler aborts with the message "Aliases to mutable thread-local data not allowed." Right, because you are not allowed to pass unshared data between threads. 3. If I mark the S instance as shared, it works. But I didn't intend to do this... Is this really how it meant to be? Let's go over how the data is actually laid out: Model has NO data in it, so it doesn't really matter if it's shared or not. S has a single array of element type D's. There is no static data in S, so it has no static state (only instance state). D has a single size_t, which is thread-local, especially, the size_t is local to an instance of D. but has a static instance of S in the TYPE. Right, because to work properly a D instance has to know about the D's in the array of S There is not a copy of an S for each D, just a single copy for each THREAD. If you make this shared, it's a shared copy for all threads. This means the array inside the shared S will be shared between all threads too. This is the point where my headaches begin: I do not need this level of sharedness, but I don't really care. What happens when you spawn a new thread is that the thread-local copy of m is created with Model.init (but it has no data, so it's not important). A thread-local copy of D.s is created with S.init (so an empty array). The reason your assignment of length in main doesn't work is because the init value is used, not the current value from the main thread. So yes, you need to make it shared to have the sub-thread see the changes, if that's what you are after. As I'm writing the model object as well as all of its compartments, I can do almost everything... but what I to avoid is to declare the instances of compartments inside the model: They are stored locally to their modules and the single elements of them have to know about the compound objects, like with the D and S structs shown. A static member is stored per thread. If you want a global that's shared between all threads, you need to make it shared. But the result may not be what you are looking for, shared can cause difficulty if your code wasn't written to deal with it (and a lot of code isn't). Well, the only reason I use multithreading is this: https://forum.dlang.org/thread/cfrtilrtbahollmaz...@forum.dlang.org So, even if my code is not really shared designed, this doesn't matter, as I wait for "the other" thread to end (or interrupt it). So, marking the model as shared is already a workaround, for being able to pass it to another thread, which I don't really need. However, now, if also all components of the model have to be marked shared, the workaround has to grow and expands over all components (?). This is the reason for this question... -Steve
Re: handling shared objects
On 11/26/18 9:00 AM, Alex wrote:
Hi all!
Can somebody explain to me, why the example below is not working in a
way I'm expecting it to work?
My example is a little bit longer this time, however the half of it is
taken from
https://dlang.org/library/std/concurrency/receive_only.html
´´´
import std.experimental.all;
struct D
{
size_t d;
static S s;
}
struct S
{
D[] data;
}
struct Model
{
auto ref s()
{
return D.s;
}
void run()
{
"I'm running".writeln;
writeln(s.data.length);
}
}
Model m;
void main()
{
D.s.data.length = 4;
m.run; //4
auto childTid = spawn(, thisTid);
send(childTid, 0);
receiveOnly!bool;
}
static void runner(Tid ownerTid)
{
receive((size_t dummy){
import core.thread : Thread;
m.run;
// Send a message back to the owner thread
// indicating success.
send(ownerTid, true);
});
}
´´´
The idea is:
the model is something that I can declare deliberately in the
application. And, I assumed that if it is (globally) shared, then so are
all compartments of it, even if they are not explicitly part of the model.
Some problems arose:
1. Obviously, this is not the case, as the output is different,
depending on the thread I start the model function.
Yes, unless you declare the model to be shared, there is a copy made for
each thread, independently managed.
2. If I declare the model object inside the main, the compiler aborts
with the message "Aliases to mutable thread-local data not allowed."
Right, because you are not allowed to pass unshared data between threads.
3. If I mark the S instance as shared, it works. But I didn't intend to
do this... Is this really how it meant to be?
Let's go over how the data is actually laid out:
Model has NO data in it, so it doesn't really matter if it's shared or not.
S has a single array of element type D's. There is no static data in S,
so it has no static state (only instance state).
D has a single size_t, which is thread-local, but has a static instance
of S in the TYPE. There is not a copy of an S for each D, just a single
copy for each THREAD. If you make this shared, it's a shared copy for
all threads. This means the array inside the shared S will be shared
between all threads too.
What happens when you spawn a new thread is that the thread-local copy
of m is created with Model.init (but it has no data, so it's not
important). A thread-local copy of D.s is created with S.init (so an
empty array). The reason your assignment of length in main doesn't work
is because the init value is used, not the current value from the main
thread.
So yes, you need to make it shared to have the sub-thread see the
changes, if that's what you are after.
As I'm writing the model object as well as all of its compartments, I
can do almost everything... but what I to avoid is to declare the
instances of compartments inside the model:
They are stored locally to their modules and the single elements of them
have to know about the compound objects, like with the D and S structs
shown.
A static member is stored per thread. If you want a global that's shared
between all threads, you need to make it shared. But the result may not
be what you are looking for, shared can cause difficulty if your code
wasn't written to deal with it (and a lot of code isn't).
-Steve
handling shared objects
Hi all!
Can somebody explain to me, why the example below is not working
in a way I'm expecting it to work?
My example is a little bit longer this time, however the half of
it is taken from
https://dlang.org/library/std/concurrency/receive_only.html
´´´
import std.experimental.all;
struct D
{
size_t d;
static S s;
}
struct S
{
D[] data;
}
struct Model
{
auto ref s()
{
return D.s;
}
void run()
{
"I'm running".writeln;
writeln(s.data.length);
}
}
Model m;
void main()
{
D.s.data.length = 4;
m.run; //4
auto childTid = spawn(, thisTid);
send(childTid, 0);
receiveOnly!bool;
}
static void runner(Tid ownerTid)
{
receive((size_t dummy){
import core.thread : Thread;
m.run;
// Send a message back to the owner thread
// indicating success.
send(ownerTid, true);
});
}
´´´
The idea is:
the model is something that I can declare deliberately in the
application. And, I assumed that if it is (globally) shared, then
so are all compartments of it, even if they are not explicitly
part of the model.
Some problems arose:
1. Obviously, this is not the case, as the output is different,
depending on the thread I start the model function.
2. If I declare the model object inside the main, the compiler
aborts with the message "Aliases to mutable thread-local data not
allowed."
3. If I mark the S instance as shared, it works. But I didn't
intend to do this... Is this really how it meant to be?
As I'm writing the model object as well as all of its
compartments, I can do almost everything... but what I to avoid
is to declare the instances of compartments inside the model:
They are stored locally to their modules and the single elements
of them have to know about the compound objects, like with the D
and S structs shown.
Re: __traits for checking if a type is dynamic array (slice)
On 11/26/18 4:04 AM, Per Nordlöw wrote: Why is there no - __traits(isArray, T) alongside - __traits(isStaticArray, T) and - __traits(isAssociativeArray, T) Thanks for bringing this to my attention, Per. The core idea is to have __traits "primitive and ugly" and std.traits "convenient and nice". From that viewpoint, if isArray can be implemented as a library feature using primitives provided by traits, there is no need for making it. when dmd already has `ENUMTY.Tarray` alongside - ENUMTY.Tsarray and - ENUMTY.Taarray Justifying the feature by means of a detail in the compiler implementation is definitely undesirable. and std.traits already has a wrapper for this at https://dlang.org/phobos/std_traits.html#isDynamicArray ? If the wrapper works well, use it and move on. Thanks, Andrei
Re: How to iterate getSymbolsByUDA
On Monday, 26 November 2018 at 13:50:13 UTC, Eko Wahyudin wrote: seems my problem is i use GDC, i got this error error: basic type expected, not foreach. The common versions of gdc don't support static foreach, but plain foreach should work there the same way in this context. So just remove the word "static" and try it then.
Re: How to iterate getSymbolsByUDA
On Sunday, 25 November 2018 at 01:01:30 UTC, bauss wrote:
On Saturday, 24 November 2018 at 08:50:59 UTC, Eko Wahyudin
wrote:
On Saturday, 24 November 2018 at 08:09:38 UTC, Stanislav
Blinov wrote:
[...]
aah ya,, this statement is work
static foreach (i; 0 .. symbols.length)
thank you.
It should work with just:
static foreach(sym; getSymbolsByUDA!(A, Attr)){
...
}
or
alias symbols = getSymbolsByUDA!(A, Attr);
static foreach(sym; symbols){
...
}
---
What you were missing was just making it a static foreach.
seems my problem is i use GDC, i got this error
error: basic type expected, not foreach.
Re: Cannot build project due to Derelict package
On Monday, 26 November 2018 at 12:11:03 UTC, Alex wrote:
On Monday, 26 November 2018 at 11:57:40 UTC, Andrey wrote:
Hello,
I try to build my project using command "dub build" but I
can\t because there is an error:
Fetching derelict-util 3.0.0-beta.2 (getting selected
version)...
SSL connect error on handle 1F19AC0
And this happens every time... As I understand dub can't find
package.
In dub.json I have this:
"dependencies": {
"derelict-glfw3": "~master"
}
I manually downloaded derelict-glfw3 and derelict-util from
GitHub (master branch). What should I do to dub knew about
these local packages?
There are some ways to let dub know about them:
https://forum.dlang.org/thread/fgpmytpzoifpdrhzk...@forum.dlang.org
Thanks!
Re: D is supposed to compile fast.
On Monday, 26 November 2018 at 03:09:03 UTC, Mike Parker wrote: I mean, can you think of any module in the Python/Javascript/C# standard library that simply including it will swell your program to the point it can't compile? I'm not an omnipotent master programmer, but as a professional, I can't recall ever having this situation in another library or language. Have you reached the point in D where you can't compile? I thought people had reached that point already: https://forum.dlang.org/post/mailman.3134.1517944133.9493.digitalmar...@puremagic.com I remember reading about a never ending for loop as well. Because of the way ctfe has to be handled "purely" without mutations, every change is a new allocation (but i could be remembering wrong). So just a large enough for loop because "uncompliable". And this is just time, the memory consumption is also quite large no? I think there are some caveats which are not mentioned when it comes to the fastness of the compiler. I remember last year's advent of code, I wanted to do everything at compile time, but at some point I thought, no, this small piece of code is taking way too long. Not worth it. And me mate's Go code was "consistently" fast.
Re: Cannot build project due to Derelict package
On Monday, 26 November 2018 at 11:57:40 UTC, Andrey wrote:
Hello,
I try to build my project using command "dub build" but I can\t
because there is an error:
Fetching derelict-util 3.0.0-beta.2 (getting selected
version)...
SSL connect error on handle 1F19AC0
And this happens every time... As I understand dub can't find
package.
In dub.json I have this:
"dependencies": {
"derelict-glfw3": "~master"
}
I manually downloaded derelict-glfw3 and derelict-util from
GitHub (master branch). What should I do to dub knew about
these local packages?
There are some ways to let dub know about them:
https://forum.dlang.org/thread/fgpmytpzoifpdrhzk...@forum.dlang.org
Cannot build project due to Derelict package
Hello,
I try to build my project using command "dub build" but I can\t
because there is an error:
Fetching derelict-util 3.0.0-beta.2 (getting selected
version)...
SSL connect error on handle 1F19AC0
And this happens every time... As I understand dub can't find
package.
In dub.json I have this:
"dependencies": {
"derelict-glfw3": "~master"
}
I manually downloaded derelict-glfw3 and derelict-util from
GitHub (master branch). What should I do to dub knew about these
local packages?
Re: __traits for checking if a type is dynamic array (slice)
On Monday, 26 November 2018 at 10:53:25 UTC, Eduard Staniloiu wrote: I would like to see this in the compiler traits :D https://github.com/dlang/dmd/pull/9014
Re: __traits for checking if a type is dynamic array (slice)
On Monday, 26 November 2018 at 09:28:37 UTC, Basile B. wrote: On Monday, 26 November 2018 at 09:04:25 UTC, Per Nordlöw wrote: Why is there no - __traits(isArray, T) alongside - __traits(isStaticArray, T) and - __traits(isAssociativeArray, T) when dmd already has `ENUMTY.Tarray` alongside - ENUMTY.Tsarray and - ENUMTY.Taarray and std.traits already has a wrapper for this at https://dlang.org/phobos/std_traits.html#isDynamicArray ? Should we add this new builtin trait and use it in std.traits.isDynamicArray? If so, should we call it - __traits(isDynamicArray) or - __traits(isArray) or - __traits(isArraySlice) or - __traits(isSlice) or something else? Yeah maybe just try, although i see some alias this implication in the current std.traits implementation. Adding a new trait is rarely a big deal as far as i could see in the past (i.e no big never endings discussions). This would be a nice addition, imho. As Basile B is saying, there is quite a bit of work done for the `isDynamicArray` implementation. If you have the time to drill down from https://github.com/dlang/phobos/blob/master/std/traits.d#L6618 I was expecting the `isArray` check to be something like `enum isArray(T) = is(T == U[], U)` I would like to see this in the compiler traits :D
Re: __traits for checking if a type is dynamic array (slice)
On Monday, 26 November 2018 at 09:04:25 UTC, Per Nordlöw wrote: Why is there no - __traits(isArray, T) alongside - __traits(isStaticArray, T) and - __traits(isAssociativeArray, T) when dmd already has `ENUMTY.Tarray` alongside - ENUMTY.Tsarray and - ENUMTY.Taarray and std.traits already has a wrapper for this at https://dlang.org/phobos/std_traits.html#isDynamicArray ? Should we add this new builtin trait and use it in std.traits.isDynamicArray? If so, should we call it - __traits(isDynamicArray) or - __traits(isArray) or - __traits(isArraySlice) or - __traits(isSlice) or something else? Yeah maybe just try, although i see some alias this implication in the current std.traits implementation. Adding a new trait is rarely a big deal as far as i could see in the past (i.e no big never endings discussions).
Re: dip1000 rule 5
On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
There are 4 rules listed.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
What is rule 5?
int* global_ptr;
void abc() {
scope int* a;
int* b;
scope int* c = a; // Error, rule 5
scope int* d = b; // Ok
int* i = a;// Ok, scope is inferred for i
global_ptr = d;// Error, lifetime(d) <
lifetime(global_ptr)
global_ptr = i;// Error, lifetime(i) <
lifetime(global_ptr)
int* j;
global_ptr = j;// Ok, j is not scope
}
---
Are the following assumptions correct?
lifetime(a) < lifetime(b)
Means that b is older and lives longer than a. Or better, the
data that b is pointing
to is older and lives longer than the one that a is pointing too.
With the exception
of the null pointer which gets unlimited lifetime because it does
not corrupt memory.
---
scope int * a;
The variable gets unlimited lifetime because the value it is
pointing is assigned
null. And that throws exception when trying to access the memory
and because
it does not corrupt memory it is assigned unlimited lifetime.
Also once a variable
is assigned unlimited lifetime, then it retains that unlimited
lifetime during
the entire reachability of the variable.
scope int * c = a;
The above is allowed. You are assigning a variable that according
to the compiler
has unlimited lifetime. Therefore the variable c will be handled
like it has
unlimited lifetime by the compiler.
lifetime(c) <= lifetime(a)
The dip talks about longer and shorter, but is equal okay too?
int * c = a;
The above can not be inferred because scope is only inferred when
it is assigned
a limited lifetime. So it is an error.
---
How is a person able to understand this DIP?
---
How many DIP manager are there?
When is a DIP assigned a number?
---
__traits for checking if a type is dynamic array (slice)
Why is there no - __traits(isArray, T) alongside - __traits(isStaticArray, T) and - __traits(isAssociativeArray, T) when dmd already has `ENUMTY.Tarray` alongside - ENUMTY.Tsarray and - ENUMTY.Taarray and std.traits already has a wrapper for this at https://dlang.org/phobos/std_traits.html#isDynamicArray ? Should we add this new builtin trait and use it in std.traits.isDynamicArray? If so, should we call it - __traits(isDynamicArray) or - __traits(isArray) or - __traits(isArraySlice) or - __traits(isSlice) or something else?
