Re: text based file formats
On Sunday, 18 December 2022 at 16:12:35 UTC, rikki cattermole wrote: > * make it @safe and pure if possible (and its likely possible) pure is always a worry for me, but yeah @safe and ideally nothrow (if they are forgiving which they absolutely should be, there is no reason to throw an exception until its time to inspect it). I frequently find it useful for a text data file parser to call a diagnostic callback instead of assuming some default behavior (whether that's forgiving, printing warnings, throwing or something else). With template callback parameters the parser can throw if the user wants it or stay pure nothrow if no action is required.
Re: GCC 12.1 Released (D v2.100-rc.1)
On Friday, 6 May 2022 at 11:57:47 UTC, Iain Buclaw wrote: Hi, I am proud to announce another major GCC release, 12.1. [...] Thank you for all the great work!
Re: dxml 0.2.0 released
On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole
wrote:
See lines:
- Input!IR temp = input;
- input = temp;
bool commentLine() {
Input!IR temp = input;
(...)
if (!temp.empty) {
(...)
input = temp;
return true;
} else
return false;
}
`temp = input.save` is exactly what you want here, which means
forward range is required. Your example won't work for range
objects with reference semantics.
Re: gRPC in D good idea for GSOC 2018?
On Monday, 15 January 2018 at 19:28:08 UTC, Ali Çehreli wrote: I know a project where D could benefit from gRPC in D, which is not among the supported languages: https://grpc.io/docs/ Do you think gRPC support is worth adding to GSOC 2018 ideas? https://wiki.dlang.org/GSOC_2018_Ideas Ali I can share a fresh experience from mentoring a student in a similar (also RPC) project last summer. We built native D-Bus bindings in D based on libasync. The student had had no previous experience with D or RPC, and within ~2.5 months of focused work she implemented the following: 1. (de)serialization of all D-Bus data types, including the use of compile-time reflection to recursively marshall structs, arrays, and variants. Except Variant, for which we decided to make our own D-Bus-specific tagged union type, all other D-Bus types are mapped to built-in D types. 2. A class to connect to the bus via libasync sockets, read the incoming messages and dispatch them to the registered handlers, and send messages to the bus. 3. Proxy (client) and server class templates that generate all the code necessary to make the remote calls look almost like local ones (the return value/out arguments are passed to a delegate that handles the output instead of being returned synchronously). So, more or less an equivalent of vibe.d's REST interface generator, only with fewer customization points. There were still some opportunities for refactorings and optimizations, so I wouldn't consider it production ready. Also, some planned features weren't implemented, such as a more convenient way for handling signals or allowing transports other than unix sockets on libasync. On the other hand, what we have is almost 100% covered with unit tests. This not only made adding successive layers quite pleasant, as little (if any) debugging of previously written stuff was ever necessary, but also helps to keep the stuff working as we modify it. Based on my experience, I'd say that implementing gRPC may be of a right size for a GSoC project, as long as you split it into smaller components/layers, prioritize them, and focus on having at least the basic stuff usable and tested, instead of expecting it to cover all usage cases and be heavily optimized.
Re: Adding Markdown to Ddoc
On Wednesday, 6 December 2017 at 12:13:56 UTC, Walter Bright wrote: On 12/5/2017 8:11 PM, Walter Bright wrote: (I know this has come up before, and I've been opposed to it, but I've changed my mind.) Part of this change of mind was driven by the bit of markdown that Ddoc already supports - the backticks to quote code and auto detection of URLs - and how nice that has turned out. This is going to be the right time to deprecate the automatic change of some words that happen to be parameter names into code. :)
Re: String import an entire directory
On Monday, 13 November 2017 at 16:18:06 UTC, Andre Pany wrote: Three is a use case. (...) Yeah, I could probably find more use cases, but from the OP's question it's not clear what would be the benefit of doing it at compile time in OP's case.
Re: mir-linux-kernel 1.0.0: Linux system call numbers for different architectures
On Saturday, 11 November 2017 at 08:54:54 UTC, Nicholas Wilson wrote: On Saturday, 11 November 2017 at 08:43:32 UTC, Adrian Matoga wrote: On Friday, 10 November 2017 at 18:27:36 UTC, Nathan S. wrote: About package -- Linux system call numbers for different architectures. That's all. [...] Was there anything wrong with https://code.dlang.org/packages/syscall-d ? From it's readme: Supported Platforms: Linux-x86_64 Linux-x86 OSX-x86_64 FreeBSD-x86_64 i.e. x86[_64] only. mir-linux-kernel has all the supported archs. Still, I would first try to submit a PR to syscall-d, and only go for a new package if syscall-d owners refuse to extend the list of platforms. Now we have two different packages that are supposed to do the same but have different arbitrary limitations.
Re: String import an entire directory
On Saturday, 11 November 2017 at 14:11:50 UTC, Neia Neutuladh wrote: At my job, I put together a database migration tool for our services. It scans for resources in your JAR file with an appropriate path, interprets them as SQL scripts, and applies them to the database if it hasn't been done yet. I want to implement this in D. However, while D allows you to import individual files, it doesn't let you import an entire directory. I can make a prebuild script to generate code for this, but I'm wondering: do other people find themselves needing this periodically? If so, I can write a DIP for it, or at least publish a codegen tool that other people can use. Why do you want to import files at compile time? Why can't it be done in run time, by simply reading directory with dirEntries and opening std.stdio.File for each one?
Re: mir-linux-kernel 1.0.0: Linux system call numbers for different architectures
On Friday, 10 November 2017 at 18:27:36 UTC, Nathan S. wrote: About package -- Linux system call numbers for different architectures. That's all. [...] Was there anything wrong with https://code.dlang.org/packages/syscall-d ?
Re: Is it possible to avoid call to destructor for structs?
On Sunday, 24 September 2017 at 19:52:52 UTC, bitwise wrote:
On Sunday, 24 September 2017 at 17:11:26 UTC, Haridas wrote:
In the following code, Bar is an element of struct Foo. Is
there a way to avoid a call to ~Bar when ~Foo is getting
executed?
Don't construct it to begin with.
struct Bar {
import std.stdio : writeln;
int a = 123;
void boink() { writeln(a); }
~this(){ writeln("bar dtor"); }
}
struct Foo
{
ubyte[Bar.sizeof] barBuffer;
Bar* _bar = null;
ref Bar bar()
{
import std.conv : emplace;
if(!_bar) {
_bar = cast(Bar*)barBuffer.ptr;
emplace(_bar);
}
return *_bar;
}
}
You shouldn't store the pointer to barBuffer inside Foo. The
language allows moving the structure around with a simple memcpy,
so _bar is likely to point into garbage soon after it's assigned.
Why don't you just return *cast(Bar*)barBuffer.ptr in bar()? You
could still emplace a Bar inside barBuffer in Foo's constructor,
if needed.
Static initialization of pointers
The D language specification under "Global and static initializers" [1], says the following: The Initializer for a global or static variable must be evaluatable at compile time. Whether some pointers can be initialized with the addresses of other functions or data is implementation defined. Runtime initialization can be done with static constructors. What is the rationale of making this implementation defined? What's the range of possible behaviors? Are there any circumstances in which a pointer can't be initialized with an address of a function or data? If so, couldn't a subset of cases have an explicitly defined, portable behavior? As far as I've tested this, DMD, GDC and LDC can handle static initialization of pointers to functions or data (except that LDC fails if function pointer(s) are obtained via __traits(getUnitTests, module_name)), even across separately compiled modules, which is consistent with a similar feature of C and C++. IIUC, the C standard always allows such initialization. In 6.6 Constant expressions, N1570 [2] says: 7 More latitude is permitted for constant expressions in initializers. Such a constant expression shall be, or evaluate to, one of the following: — an arithmetic constant expression, — a null pointer constant, — an address constant, or — an address constant for a complete object type plus or minus an integer constant expression. and 9 An address constant is a null pointer, a pointer to an lvalue designating an object of static storage duration, or a pointer to a function designator; it shall be created explicitly using the unary & operator or an integer constant cast to pointer type, or implicitly by the use of an expression of array or function type. The array-subscript [] and member-access . and -> operators, the address & and indirection * unary operators, and pointer casts may be used in the creation of an address constant, but the value of an object shall not be accessed by use of these operators. [1] https://dlang.org/spec/declaration.html#global_static_init [2] http://iso-9899.info/n1570.html
Re: @safe and null dereferencing
On Thursday, 27 July 2017 at 17:43:17 UTC, H. S. Teoh wrote: On Thu, Jul 27, 2017 at 05:33:22PM +, Adrian Matoga via Digitalmars-d wrote: [...] Why can't we just make the compiler insert null checks in @safe code? Because not inserting null checks is a sacred cow we inherited from the C/C++ days of POOP (premature optimization oriented programming), and we are loathe to slaughter it. :-P We should seriously take some measurements of this in a large D project to determine whether or not inserting null checks actually makes a significant difference in performance. That's exactly what I thought.
Re: DIP 1012--Attributes--Preliminary Review Round 1
On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 10 (3:59 AM GMT August 11), or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors. Thanks in advance to all who participate. Destroy! I don't want to see monsters like "@core.attribute.GarbageCollectedness.inferred" as part of any declaration, ever. I agree that the problem is valid, but I don't think adding the complexity and verboseness presented in the DIP can solve it.
Re: @safe and null dereferencing
On Thursday, 27 July 2017 at 15:03:02 UTC, Steven Schveighoffer
wrote:
Inside the thread for adding @safe/@trusted attributes to OS
functions, it has come to light that @safe has conflicting
rules.
For the definition of safe, it says:
"Safe functions are functions that are statically checked to
exhibit no possibility of undefined behavior."
In the definition of @trusted, it says:
"Trusted functions are guaranteed by the programmer to not
exhibit any undefined behavior if called by a safe function."
Yet, safe functions allow dereferencing of null pointers.
Example:
void foo() @safe
{
int *x;
*x = 5;
}
There are various places on the forum where Walter argues that
null pointer dereferencing should cause a segmentation fault
(or crash) and is checked by the hardware/OS. Therefore,
checking for null pointers before any dereferencing would be a
waste of cycles.
However, there do exist places where dereferencing null may NOT
cause a segmentation fault. For example, see this post by
Moritz Maxeiner:
https://forum.dlang.org/post/udkdqogtrvanhbotd...@forum.dlang.org
In such cases, the compiled program can have no knowledge that
the zero page is mapped somehow. There is no way to prevent it,
or guarantee it during compilation.
It's also worth noting that C/C++ identifies null dereferencing
as undefined behavior. So if we are being completely pedantic,
we could say that no C/C++ code could be marked safe if there
is a possibility that a null pointer would be dereferenced.
The way I see it, we have 2 options. First, we can disallow
null pointer dereferencing in @safe code. This would be hugely
disruptive. We may not have to instrument all @safe code with
null checks, we could do it with flow analysis, and assuming
that all pointers passed into a @safe function are not null.
But it would likely disallow a lot of existing @safe code.
The other option is to explicitly state what happens in such
cases. I would opt for this second option, as the likelihood of
these situations is very low.
If we were to update the spec to take this into account, how
would it look?
A possibility:
"@safe D does not support platforms or processes where
dereferencing a null pointer does not crash the program. In
such situations, dereferencing null is not defined, and @safe
code will not prevent this from happening."
In terms of not marking C/C++ code safe, I am not convinced we
need to go that far, but it's not as horrible a prospect as
having to unmark D @safe code that might dereference null.
Thoughts?
-Steve
Why can't we just make the compiler insert null checks in @safe
code? We can afford bounds checking even in @system -O -release.
C++ can afford null check upon executing an std::function. The
pointer would most likely be in a register anyway, and the
conditional branch would almost always not be taken, so the cost
of that check would be barely measurable. Moreover, the compiler
can elide the check e.g. if the access via pointer is made in a
loop in which the pointer doesn't change. And if you prove that
this tiny little check ruins performance of your code, there's
@trusted to help you.
Re: D easily overlooked?
On Friday, 14 July 2017 at 13:29:30 UTC, Joakim wrote: Yes, D's compile-time regex are still the fastest in the world. I've been benching it recently for a marketing-oriented blog post I'm preparing for the official D blog, std.regex beats out the top C and Rust entries from the benchmarks game on linux/x64 with a single core: http://benchmarksgame.alioth.debian.org/u64q/regexredux.html https://github.com/joakim-noah/regex-bench D comes in third on Android/ARM, but not far behind, suggesting it would still be third on that list if run with a bunch of other languages on mobile. Dmitry thinks it might be alignment issues, the bane of cross-platform, high-performance code on ARM, as he hasn't optimized his regex code for ARM. Interesting. A few months ago I wanted to sell ctRegex as the fastest one in a presentation, but in my benchmarks (based on [1]) I found it to be of equal speed or slower than boost::regex (LDC vs Clang). I've got to take a look at your benchmarks, and repeat mine to check again if I didn't mess something up. [1] http://lh3lh3.users.sourceforge.net/reb.shtml
Re: Release D 2.075.0
On Thursday, 20 July 2017 at 07:19:03 UTC, Patrick Schluter wrote: version 2.067 that still had the C++ frontend took more than 100 seconds. I can hardly believe it. I remember versions 2.05x building in about 11 seconds.
Re: DIP 1010--Static foreach--Formal Review
On Wednesday, 12 July 2017 at 10:57:37 UTC, Steven Schveighoffer wrote: Perhaps the deprecation path should include a removal of straight foreach over a tuple working (use static foreach explicitly). This would make the distinction even more obvious. I'd also vote for gradual removal of foreach over a tuple. It would be one less awkward moment when teaching D.
Re: version=D_16
On Monday, 10 July 2017 at 21:30:44 UTC, Walter Bright wrote: On 7/10/2017 1:52 PM, Luís Marques wrote: On Monday, 10 July 2017 at 20:19:46 UTC, Walter Bright wrote: On 7/10/2017 12:46 PM, Luís Marques wrote: I'm curious how that implementation addresses the issues I brought up: I'm not really sure how to respond, you mostly just made statements about your worldview. For instance: "C++ on a 64K machine is like using a tank to get to the grocery store". If you mean using all of C++ features, sure, that's inappropriate. If you mean that there are no C++ features that you could use in a microcontroller, there are non-trivial amounts of people the disagree with you. You can't use RTTI or Exceptions, for example. Those generate bloat even if they are not used - a compiler switch is typical to disable them. It's not true that C++ is "pay only for what you use". If the C++ usage is "C with member functions", then yes, it'll work and be useful. There's more to that. Since these chips have limited computational capabilities, you really want to move as much computation as possible into compile time. And this is what makes C++ a better choice than C, and D a better choice than C++. It's also the safer and more expressive type system that saves you the time you would spent on debugging every kind of bug resulting from casting everything to void* and back.
Re: Analysis of D GC
On Tuesday, 20 June 2017 at 11:49:49 UTC, Jacob Carlborg wrote: You need to move to 64bit. Apple is already deprecating support for 32bit apps and after the next version of macOS (High Sierra) they're going to remove the support for 32bit apps. There are other 32-bit platforms that are going to stay on the market for a while. 32-bit ARMs won't disappear anytime soon.
Re: atomic operations compared to c++
On Tuesday, 13 June 2017 at 06:12:46 UTC, gzp wrote: (...) There is no consume in D. What do you currently use for in C++? It is temporarily deprecated in C++17.
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer wrote: On 6/7/17 5:47 PM, John Carter wrote: On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html That is kind of neat. While I can say that D can perform technically the same feat via pragma(msg, ...) and importing a file directly (would leave a comment on the blog, but there isn't a spot for it), the fact that you can execute arbitrary code in a block at compile time that can use the *actual* i/o routines you would use at runtime is pretty impressive. Stefan would have a field day with this power :) Yeah, it feels C++'y when you need to leave CTFE if you want to print some value computed in CTFE or use it as a name of file to load. :/
Re: DIP 1003 Formal Review
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote: ... 3. deprecate, remove, forget. During the deprecation period, it could live as "contextual keyword", or actually with grammar modified to expect an identifier "body" instead of keyword. That would allow using "body" as identifier immediately.
Re: Fantastic exchange from DConf
On Wednesday, 10 May 2017 at 12:18:40 UTC, Patrick Schluter wrote: On Wednesday, 10 May 2017 at 11:16:57 UTC, Atila Neves wrote: [...] The likelihood of a randomly picked C/C++ programmer not even knowing what a profiler is, much less having used one, is extremely high in my experience. I worked with a lot of embedded C programmers with several years of experience who knew nothing but embedded C. We're talking dozens of people here. Not one of them had ever used a profiler. I've worked 10 years in embedded (industry, time acquisition and network gears) and I can say that there is a good reason to that. It's nearly impossible to profile in an embedded system (nowadays it's often possible because of the generalization of Linux and gnu tools but at that time it wasn't). The tools don't exist or if they do, the instrumentation breaks the constraints of the controller. This was also one of the reason we chose our embedded CPU's very carefully. We always chose processors for which there existed mainstream desktop versions so that we could at least use the confortable tooling to test some parts of the code on a nice environment. We used Z80 (CP/M), 80186 (MS-C on DOS) and then 68030 (Pure-C on Atari TT). TL;DR profiling for embedded is order of magnitudes harder than for nice OS environments. IMO it's just different. The thing is, the tools you can use don't need to be marketed as "profilers". People will always find excuses if they lack time, will or knowledge. In practice, there's always a way to profile and debug, even if you don't have dedicated tools for it. It's also a lot easier to reason about performance on small chips with no caches, ILP, etc. and with fixed instruction timing, than it is on modern complex CPUs with hundreds of tasks competing for resources. One universal tool is oscilloscope, for sure you have one on your colleague's desk if you really do embedded stuff. A common way to profile on home computers from the '80s such as Atari XE (6502), was simply to change screen colors. That way you always knew the time taken by the measured code with 1-cycle precision. 13.5 scanlines are white? That's 1539 cycles! The time it took to execute a tight loop could even be computed accurately with pen and paper by just looking at the assembly. It's also a lot easier to implement a cycle-exact emulator for such simple chips, and then you can measure everything without observer effect.
Re: DConf 2017 Hackathon report
On Tuesday, 9 May 2017 at 13:19:12 UTC, Steven Schveighoffer wrote: But it was very awesome to be able to go around and find the people to discuss a PR/idea without going through a forum thread. I think there's a psychological barrier that happens when you post a complete argument, and then your counterpart forms an interpretation in their mind of what the argument means, forms their complete counter argument, and neither side really understands what the other is saying or willing to do. Doing it in person allows so much more interaction -- you can cut off early any misinterpretations. It's also harder to be nasty in person :) +1! For the same reasons, it's also a lot easier for people who don't use English as their 1st language to express their ideas as one doesn't need to spend time carefully looking up the meaning of words to make sure the "complete argument" will be understood as intended. :)
Re: DConf 2017 Hackathon report
On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote: Please list what we've achieved during the hackathon, including what is started but is likely to be finished in the coming days or months. For me: - Finished updating "Programming in D" to 2.074.0 (the HTML is now up to date but I could not get to the still manual work of preparing the ebooks) - Contributed to the logo and branding discussions - Opened two bugs - Ate German cookies :) Ali I: 1. Started a PR adding -Xcc switch to LDC [1]. 2. Discussed a solution to [2] and [3] with Sönke, implementation is in progress. 3. Briefly went through sources of Stefan's CTFE implementation. To me it was also a good quick lesson about part of DMD internals I didn't know yet, and I hope I'll be able to review his code from time to time and motivate him. 4. Got a ton of inspiration and motivation. [1] https://github.com/ldc-developers/ldc/pull/2104 [2] https://github.com/dlang/dub/issues/628 [3] https://github.com/dlang/dub/issues/228
Re: "I made a game using Rust"
On Wednesday, 10 May 2017 at 15:03:19 UTC, Adam D. Ruppe wrote: On Wednesday, 10 May 2017 at 14:02:38 UTC, Adrian Matoga wrote: Would you mind giving some examples? What bothers me on a regular basis is overloading. Basic case: $ dmd lll lll.d(6): Error: none of the overloads of 'foo' are callable using argument types (int, double), candidates are: lll.d(1):lll.foo(int a, int a) lll.d(2):lll.foo(int a, string s) Contrast that to g++: $ g++ lll.cpp lll.cpp: In function ‘int main()’: lll.cpp:7:14: error: no matching function for call to ‘foo(int, Foo)’ foo(0, Foo()); ^ lll.cpp:7:14: note: candidates are: lll.cpp:1:6: note: void foo(int, char*) void foo(int a, char* b); ^ lll.cpp:1:6: note: no known conversion for argument 2 from ‘Foo’ to ‘char*’ lll.cpp:2:6: note: void foo(int, float) void foo(int a, float b); ^ lll.cpp:2:6: note: no known conversion for argument 2 from ‘Foo’ to ‘float’ The g++ example isn't great either... but is better because of this: "no known conversion for argument 2 from ‘Foo’ to ‘float’" It actually told me which argument didn't match! clang is similar: $ clang lll.cpp lll.cpp:7:2: error: no matching function for call to 'foo' foo(0, Foo()); ^~~ lll.cpp:1:6: note: candidate function not viable: no known conversion from 'Foo' to 'char *' for 2nd argument void foo(int a, char* b); ^ lll.cpp:2:6: note: candidate function not viable: no known conversion from 'Foo' to 'float' for 2nd argument void foo(int a, float b); With the dmd one, especially on a long function, it is hard to tell just which argument is giving trouble. The C++ errors just flat out tell me which argument didn't match for each candidate. In this simple case above, I actually prefer DMD's messages, as there's simply less text for my eyes to read and brain to parse, so I can quickly spot where the problem is. I agree, though, that with longer argument lists, especially with const vs. non-const or template constraints, trying to figure out what's wrong could be at least frustrating. Templates with constraints are even worse. lll.d(3): Error: template std.algorithm.sorting.sort cannot deduce function from argument types !()(int), candidates are: /home/me/d/dmd2/linux/bin32/../../src/phobos/std/algorithm/sorting.d(1830):std.algorithm.sorting.sort(alias less = "a < b", SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range || hasAssignableElements!Range) || ss != SwapStrategy.unstable && hasAssignableElements!Range) && isRandomAccessRange!Range && hasSlicing!Range && hasLength!Range) What a mess! Just formatting that output might help, but I'd especially love it if it told me which individual boolean elements failed, passed, and were short-circuited. The compiler knows this, it had to evaluate that to figure out it didn't match, but it doesn't tell me. At a glance, can you even tell what I passed to the function? Bonus points would be it telling me why, for example, `isInputRange` failed, but I understand that is an even bigger problem to solve. It's indeed painful, but I found UDAs to be useful in dealing with it. First, I'm sure you know Atila's concepts [1]. I also use UDAs in flod [2], so instead of checking whether the implementation satisfies a constraint, I only check if it's explicitly tagged with a specific UDA. Now, I immediately see whether it's a method that I forgot to implement or just a typo, instead of being forced to guess by a "missing overload" message. Of course, C++ doesn't have constraints so there's no comparison there. Lastly, check this out: lll.d(5): Error: function lll.foo (Color c) is not callable using argument types (Color) WTF, right? Well, I have a locally defined `struct Color` and an imported one. Same name, but different type. The error message doesn't tell me which one is which. Yeah, that one was funny. :) These are the top 3 dmd error messages that bother me regularly. At runtime, little drives me more nuts than RangeError not telling me the index and the length. Again, it knows, the code checked it, but it didn't report it. Same with assertions. I usually end up adding wrappers like assertEqual, and the more I use them, the more I feel like switching to something like [3] or [4], as much as I normally prefer to keep the number of dependencies low. I think RangeError could be solved without much effort by changing the compiler/runtime interface at _d_arraybounds*. Assertions are probably harder. [1] http://forum.dlang.org/post/eoxerbkaowxpgjubh...@forum.dlang.org [2] https://github.com/epi/flod/blob/develop/source/flod/package.d [3] https://code.dlang.org/packages/fluent-asserts [4] http://code.dlang.org/packages/unit-threaded
Re: "I made a game using Rust"
On Wednesday, 10 May 2017 at 14:00:08 UTC, Ethan Watson wrote: On Wednesday, 10 May 2017 at 13:22:22 UTC, Adam D. Ruppe wrote: Those of you on IRC know that I've been pushing hard for better error messages. I think that is *the* killer feature clang offered and I see it brought up again and again. D used to do well. Now we're lagging behind. No language change needed to vastly improve error messages. I find it a very curious state of affairs myself that Microsoft's C++ compiler has significantly better error messages than DMD. Would you mind giving some examples?
Re: Fantastic exchange from DConf
On Tuesday, 9 May 2017 at 09:22:13 UTC, Joakim wrote: On Tuesday, 9 May 2017 at 06:15:12 UTC, H. S. Teoh wrote: On Mon, May 08, 2017 at 06:33:08PM +, Jerry via Digitalmars-d wrote: [...] Is that a subtle joke, or are you being serious? [...] Heh, I saw you wrote the post and knew it would be long, then I kept scrolling and scrolling... :) Please, please, please submit this as a post on the D blog, perhaps prefaced by the Walter/Scott exchange and with some links to the issues you mention and the relevant portions of the D reference. I think it would do well. +1
Re: DLang quarterly EU?
On Sunday, 7 May 2017 at 16:37:02 UTC, Ethan Watson wrote: On Sunday, 7 May 2017 at 11:32:53 UTC, Adam Wilson wrote: On 5/7/17 12:57, Seb wrote: +1 - maybe its worth considering to make it for two days (=one weekend) That can work. It would be two or three days vacation depending on flight schedules. ... Not to mention a cool way to see new cities if it moves around. Yes, that was the intention on both counts. There's no point to flying somewhere just for the day. Especially since there will doubtless be Micro BeerConfs in the evening ;-) Andrei suggested that Bucharest be the first city we hold this in. Sounds like a great plan to me. Count me in!
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 07:42:51 UTC, Luís Marques wrote: On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote: Hi, I am very happy to see you soon at dconf. And I apologize in advance for my nearly slideless talk. Hope this time there is dmd on the machine! Cheers Stefan Well, I have too many. Want some? Can anyone get me a phillips screwdriver? Seriously. I'll be at the official hotel or you can lend me one tomorrow morning at the conference. I've got one with me. I'm not staying in Ibis, but it's close to my hotel. I shall get there at about 9pm. See you!
Re: CTFE Status 2
On Sunday, 30 April 2017 at 19:52:27 UTC, H. S. Teoh wrote: On Sun, Apr 30, 2017 at 01:26:09PM +, Stefan Koch via Digitalmars-d wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: > [ ... ] Big news! The first step to include debug info has been done. Yes this means you will be able to step through ctfe code while the compiler executes it. Wow! Will that be accessible to users in the end? That could be a totally awesome way of debugging CTFE code! I used to think the same, but with each new line of code I write that is to be executed in CT, I become more convinced that there's no need to expose such debugging interface to the end user. Why? Because the end user expects that CTFE either gives exactly the same results as run-time execution or that it stops with an explicit error message on something that is not designed to be executed in CT. Any other problem found during CTFE execution must be 100% reproducible in run time or it's an ICE. Any CTFE debugging should be only for compiler maintainers, and the user shouldn't worry that CTFE could mess up something.
Re: CTFE Status 2
On Wednesday, 3 May 2017 at 04:22:00 UTC, Stefan Koch wrote: On Tuesday, 2 May 2017 at 22:08:31 UTC, Moritz Maxeiner wrote: [...] Using TCP would just remove any potential future headache from the equation. I think any ordering should be done explicitly at the debugging protocol level. for example when sending sourceline messages the order is given by the line number and ordering can be done by the application. It's the same for breakpoint setting or for breakpoint trigger notification. As for lost packages, we want to respond intelligently as well. And maybe reduce the amount of data in the package, to make arrival of future packages more likely. So you're going to reinvent TCP in your debugging protocol?
Re: DConf Hackathon Ideas
On Thursday, 27 April 2017 at 14:53:02 UTC, Mike Parker wrote: This year, DConf has an extra day tacked on for problem solving in the form of a hackathon. The intent is to work on issues people find frustrating in the D ecosystem. While there will be time given at the event for proposals, and those involving third-party projects are welcome, it will help speed things along for the organizers to come in with a list of big issues to get the ball rolling. To help in compiling the list, what are some major issues from the ecosystem that you'd like to see fixed? It's probably not a "major issue", but I'd be interested in joining any efforts towards making dub more cross-compilation-friendly. "--compiler=" and "--arch=" aren't quite useful in any serious scenario with multiple target platforms that use different compiler settings and sysroots.
Re: Compare boost::hana to D
On Saturday, 22 April 2017 at 07:53:49 UTC, Johannes Pfau wrote: OT but is there any benefit to identify events with strings? As long as you use compile time only events I'd prefer a syntax as in https://github.com/WebFreak001/EventSystem (one benefit is that it's 100% IDE autocomplete compatible) I guess if you want runtime registration of events identifying by name is useful. But then you also somehow have to encode the parameter types to make the whole thing safe... I agree. Personally, I'd probably also start with something like WebFreak001's ES and only think about how to add run-time dispatch later if I absolutely need it.
Re: DConf 2017 Berlin - bicycles
On Friday, 21 April 2017 at 13:37:17 UTC, Steven Schveighoffer wrote: After the bike tour I had last year, I can 100% agree that having a bike is a fabulous way to get around the city quickly. You can ride the subway with your bike (although IIRC, you need to buy a ticket for it), but the thing that makes Berlin so accessible via bike is that it's totally flat. Those 10 minute walks become 1 minute rides, and it's a very bike-friendly city. I mused while riding around that the tour would be nearly impossible, or at least a huge workout if we did something like that in Boston :) I don't know about Boston, but I've heard many times that Lisbon was too hilly to ride a bike there, but in reality it wasn't all that bad (well, maybe on the hottest summer days), and in recent years the city council has been investing in dedicated infrastructure to improve it. I guess people will always find excuses. :) Warsaw, where I live now, is almost just as flat as Berlin and quite pleasant to ride around, especially in spring and summer (I rarely choose the shortest way home), but it's not as bike-friendly yet for other reasons. Cities like Berlin are a live explanation of the term "critical mass" – there's just enough people on bikes so they're treated as normal and respected in the streets, unlike in Polish cities where riding to work is still considered eccentric and casual cyclists are thought of as traffic obstacles, members of leftist sects, or just too poor to own a car. Glad you are coming, Adrian, looking forward to seeing you again! Yeah, can't wait to hear your talk on iopipe! :)
Re: DConf 2017 Berlin - bicycles
On Friday, 21 April 2017 at 16:49:36 UTC, Iain Buclaw wrote: On 19 April 2017 at 20:22, Adrian Matoga via Digitalmars-d <digitalmars-d@puremagic.com> wrote: I'm arriving at Berlin Ostbahnhof on Wednesday evening and will be heading to Britz Hotel, but last year I learnt that the best way to get around the city is on a bicycle. Can you recommend a place (preferably near the station) where I could rent a not-so-small bike for 4 days for a reasonable price? Thanks! Almost every single bike shop you stumble across in Berlin offers rentals, all pretty much at the same price of around 10€ a day. If you have a native german to help you, maybe you'll even get a swindled deal. However, the one notable thing that has changed from last year is that there's a new competitor in the form of a Lidl bike. I've seen literally hundreds of them inside the Berlin S-bahn ring, one major advantage of using them is that they don't need a dedicated docking station for you to park them in. I'll just refer to this blog on the more fine grain details. https://schnaeppchenfuchs.com/news/lidl-bike-berlin Looks like they even come with a GPS locator, which probably is used for DB's smartphone app. https://www.lidl-bike.de/de/rad-finden Good idea, I'll try to find one before I look for some "traditional" rental. I'm only afraid that as a sort of public bikes they're all in a "normalized" size which probably won't be safe for me – I sometimes ride nextbike bikes here in Warsaw (this year they look exactly the same as in Berlin) and they kill my knees very quickly. I really wanted to take my own bike but the train operator sucks – there's only one train in the timetable that allows bicycles and it's at 6am and costs twice as much as the one in the afternoon.
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? The question occurred to me somehow while browsing some D posts on the forums just now. DLanger? DLangist? D'er? Doer? :) I tend to favor DLanger, FWIW. In just 2 weeks we'll get a chance to be called Drunkards.
Re: Compare boost::hana to D
On Friday, 21 April 2017 at 13:10:43 UTC, Adam D. Ruppe wrote:
On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga
wrote:
[2] https://epi.github.io/2017/03/18/less_fun.html
BTW in your D foreach, you could also have done `switch`
void trigger(string event) {
switch(event) {
foreach (i, e; events) {
case e:
foreach (c; callbacks_[i])
c();
return;
}
default:
assert(false, "trying to trigger an unknown event: "
~ event);
}
}
And the compiler+runtime can optimize that into a binary search
when it gets larger automatically.
Thanks, I completely forgot about it. I should update the article
soon.
Re: Compare boost::hana to D
On Friday, 21 April 2017 at 12:37:03 UTC, Mike Parker wrote: On Friday, 21 April 2017 at 12:34:53 UTC, Mike Parker wrote: On Thursday, 20 April 2017 at 07:37:17 UTC, Mike Parker wrote: On Thursday, 20 April 2017 at 05:01:17 UTC, Adrian Matoga wrote: On Wednesday, 19 April 2017 at 19:22:11 UTC, Ali Çehreli wrote: Thank you. Has this been on Reddit yet? I haven't posted it there, I don't have an account. I'll post it, but not today. It will get more attention if I wait until Friday afternoon GMT. https://www.reddit.com/r/programming/comments/66ovil/metaprogramming_is_less_fun_in_d/ And I should add (for anyone paying attention), this is exactly the sort of thing I'm looking for more of on the D Blog. Submissions welcome :-) This, and the generally positive feedback on r and HN are quite motivating. :) I have some ideas for more articles but being a non-native English speaker I need a lot of time to make the text look at least understandable, so I usually give up quickly and move on to play with code instead. :)
Re: Compare boost::hana to D
On Friday, 21 April 2017 at 12:34:53 UTC, Mike Parker wrote:
On Thursday, 20 April 2017 at 07:37:17 UTC, Mike Parker wrote:
On Thursday, 20 April 2017 at 05:01:17 UTC, Adrian Matoga
wrote:
On Wednesday, 19 April 2017 at 19:22:11 UTC, Ali Çehreli
wrote:
Thank you. Has this been on Reddit yet?
I haven't posted it there, I don't have an account.
I'll post it, but not today. It will get more attention if I
wait until Friday afternoon GMT.
https://www.reddit.com/r/programming/comments/66ovil/metaprogramming_is_less_fun_in_d/
Thanks!
Maaan, reddit takes ages to load on mobile and doesn't let me
read anything until I close all these annoying popups. Yet the
comments are mostly in the same tone I saw a few times in the
past when links were posted here ("D sucks" and so on) and made
me think of reddit as a complete waste of time. It looks like
it's all the time the same topic – bad, bad GC, D1 vs. D2, oh,
and Rust and Go are better.
OTOH, I saw it posted also on HN
(https://news.ycombinator.com/item?id=14165198)
and there, the discussion seems to be slightly more interesting.
Re: DConf 2017 Berlin - bicycles
On Wednesday, 19 April 2017 at 20:13:52 UTC, Walter Bright wrote: On 4/19/2017 11:22 AM, Adrian Matoga wrote: I'm arriving at Berlin Ostbahnhof on Wednesday evening and will be heading to Britz Hotel, but last year I learnt that the best way to get around the city is on a bicycle. Can you recommend a place (preferably near the station) where I could rent a not-so-small bike for 4 days for a reasonable price? Thanks! I personally found that the transit system in Berlin was excellent. You can buy a 3 day pass from the ticket machines, it's under "Tourist Fahrkarte" if I remember correctly. It is! In many discussions about public transport, Berlin is mentioned as an example that should be followed, and I must agree with that after a few rides I had.
Re: DConf 2017 Berlin - bicycles
On Wednesday, 19 April 2017 at 19:03:40 UTC, Fool wrote: No personal experience, but http://www.yaambike.de/ sounds like an option. Looks good, thanks.
Re: Compare boost::hana to D
On Wednesday, 19 April 2017 at 19:22:11 UTC, Ali Çehreli wrote:
Thank you. Has this been on Reddit yet?
I haven't posted it there, I don't have an account.
Two typos:
1) A missing underscore made me believe C++ gained a new
keyword (make). :)
auto events = make event_system("foo"_s, "bar"_s, "baz"_s});
Uhh, that underscore isn't the only problem in this line. ;)
Fixed both, thank you!
Re: Compare boost::hana to D
On Wednesday, 19 April 2017 at 18:57:19 UTC, David Gileadi wrote: On 4/19/17 11:30 AM, Adrian Matoga wrote: On Wednesday, 19 April 2017 at 18:26:20 UTC, Sebastiaan Koppe wrote: On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote: [2] https://epi.github.io/2017/03/18/less_fun.html Minor nit in the article--in the following paragraph "runtime" should probably be replaced with "compile time": "Note the enum in place where C++ version used auto. The type is also inferred automatically, but using enum forces index to be computed at runtime and only then it can be used in static assert." Fixed, thanks a lot! It seems impossible to spot all mistakes without someone else's eyes even if I read it a thousand times... :|
Re: Compare boost::hana to D
On Wednesday, 19 April 2017 at 18:26:20 UTC, Sebastiaan Koppe wrote: On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote: [2] https://epi.github.io/2017/03/18/less_fun.html Great article! Thanks! I should mention I've also got somewhat positive feedback from Louis [1]. [1] https://twitter.com/LouisDionne/status/843227582803849216
DConf 2017 Berlin - bicycles
I'm arriving at Berlin Ostbahnhof on Wednesday evening and will be heading to Britz Hotel, but last year I learnt that the best way to get around the city is on a bicycle. Can you recommend a place (preferably near the station) where I could rent a not-so-small bike for 4 days for a reasonable price? Thanks!
Re: Compare boost::hana to D
On Wednesday, 19 April 2017 at 08:19:52 UTC, Ali Çehreli wrote: I'm brushing up on my C++ to prepare for my C++Now 2017 presentation[1]. boost::hana is an impressive library that overlaps with many D features: http://www.boost.org/doc/libs/1_64_0_b2/libs/hana/doc/html/index.html Have you used boost::hana? What are your thoughts on it? And please share your ideas for the presentation. There has been threads here about C++ closing the gap. Does D still bring competitive advantage or is it becoming irrelevant? (Obviously, some think its irrelevant already.) I'm trying to collect opinions... :) Thank you, Ali [1] http://cppnow.org/2017-conference/announcements/2017/04/09/d-keynote.html I was at C++ Meeting 2016 in Berlin, where Louis Dionne talked about hana in his keynote [1]. I've summarized my feelings in a blog post [2]. In short, you can do the same tricks in D, but frequently there's an idiomatic way to express the same thing just as concisely without them. And of course, feel free to use any part of my post in your talk. :) [1] https://www.youtube.com/watch?v=X_p9X5RzBJE [2] https://epi.github.io/2017/03/18/less_fun.html
Re: DConf 2017 Schedule
On Monday, 20 March 2017 at 13:57:19 UTC, Dukc wrote: If I remember correctly, last year it took perhaps two months or so for the talks to be published on YouTube. Would it be much extra effort to publish unedited versions of them asap, for us who can't wait for the edited versions? Yes, they are that interesting. AFAIR unedited recordings were immediately available on ustream.tv
Re: RAII
On Thursday, 23 February 2017 at 09:52:26 UTC, Arun
Chandrasekaran wrote:
I'm trying to write an RAII wrapper on Linux.
I understand struct in D doesn't have default constructor (for
.init reasons).
I don't want to use `scope`.
Is there an elegant way to achieve this in D?
static opCall() is the way to emulate an argumentless struct
constructor. You still need to call it explicitly, though:
```
import std.stdio : writefln;
struct Foo {
int a;
static Foo opCall() {
Foo foo;
foo.a = 42;
return foo;
}
~this() {
writefln("destroyed with a=%d", a);
}
@disable this(this);
@disable void opAssign(Foo);
}
void main()
{
auto foo1 = Foo(); // ok
Foo foo2; // == Foo.init
}
```
Re: Mir Random announce - Professional RNGs
On Friday, 25 November 2016 at 23:14:06 UTC, Ilya Yaroshenko wrote: https://github.com/libmir/mir-random http://docs.random.dlang.io/latest/index.html Cool! I'd only suggest renaming "algorithm" to "range", to better reflect what's inside the module.
Re: PDF generation in D?
On Wednesday, 16 November 2016 at 01:22:33 UTC, Jot wrote: What's your point? My point is that PS as a textual format can be easily generated without external libraries or tools, and then converted to an identically looking PDF.
Re: PDF generation in D?
On Tuesday, 15 November 2016 at 11:13:54 UTC, Jot wrote: On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga wrote: On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner Schadek wrote: I used text files and LaTeX in the past, it works with everything textfile -> process -> LaTeX -> pdf This. Another (a bit lower-level) option would be to produce a PostScript file and pass it to (e)ps2pdf. Then that begs the question about how to generate ps in D and just kicks the can down the road. PostScript is a programming language and PS files are plain text files with programs written in it, so formatted file output is your friend here. "Lower-level" means that you need to take care of the layout of items on a page manually, using physical positions. It's quite straightforward for simple vector graphics, but not so much for multi-page text documents with figures and tables.
Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open
On Monday, 14 November 2016 at 19:49:26 UTC, Andrei Alexandrescu wrote: We're happy to announce that the D Language Foundation is cooperating again with Sociomantic to organize DConf 2017 in Berlin for the second time. Same location, same dates, but of course a whole new experience! (...) http://dconf.org/2017/index.html It would be less confusing if the dates were updated with more attention than just s/2016/2017/g, as there's no February 29 in 2017, and all others dates are on different days of week than in 2016. Otherwise, excellent news.
Re: PDF generation in D?
On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner Schadek wrote: I used text files and LaTeX in the past, it works with everything textfile -> process -> LaTeX -> pdf This. Another (a bit lower-level) option would be to produce a PostScript file and pass it to (e)ps2pdf.
Re: If Statement with Declaration
On Friday, 4 November 2016 at 15:34:00 UTC, Jerry wrote:
On Friday, 4 November 2016 at 14:16:44 UTC, Matthias Bentrup
wrote:
On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:
if(int i = someFunc(); i >= 0)
{
// use i
}
Thoughts on this sort of feature?
I would prefer the syntax
if( (int i = someFunc()) >= 0 )
{
// use i
}
as this matches the already existing assignment expression
syntax if you pull the declaration out of the if expression.
Well you can argue the "if( init ; condition )" syntax matches
"for( init ; condition ; update)", minus the "update" section.
You've just answered your own question:
for (int i = someFunc(); i >= 0; )
{
// use i
break;
}
Re: Why can't static arrays be sorted?
On Thursday, 6 October 2016 at 09:17:08 UTC, pineapple wrote: On Wednesday, 5 October 2016 at 19:30:01 UTC, Jonathan M Davis wrote: Would just like to point out that this is design weirdness on Phobos' part - the library I've been writing does not have this problem. It doesn't even make conceptual sense for a static array to be a range, because you can't remove elements from it. - Jonathan M Davis Just because the static array itself isn't a range doesn't mean that it should be necessary to do unintuitive gymnastics with it just to pass it to functions like `sort`. `sort` takes a range. [] gets a range from anything. It's a convention, not gymnastics.
Re: Why can't static arrays be sorted?
On Tuesday, 4 October 2016 at 20:05:15 UTC, TheGag96 wrote: I was writing some code today and ran into this oddity that I'd never come across before: import std.algorithm : sort; int[10] arr = [0, 3, 4, 6, 2, 1, 1, 4, 6, 9]; thing.sort(); This doesn't compile. Obviously the .sort property works, but what about static arrays makes them unable to be sorted by std.algorithm.sort? Thanks. Try: arr[].sort();
Re: Is dmd fast?
On Wednesday, 22 June 2016 at 14:28:19 UTC, Adam D. Ruppe wrote: BTW this more measures linker speed than compiler. dmd -c -o- just runs the compiler and skips filesystem output... it'd be pretty fast and if there's similar options for other compilers (gcc has -c too at least) it might be better for small programs. Larger programs I think is fair to include the link step, since it should be less a percentage there and you do need to run it anyway. Yeah, you do need to run it anyway, even if you build incrementally. It'd be a lie to omit the link time when the compiler actively works to make linker's job harder by inflating the symbol table to tens or hundreds of megabytes.
Re: Non movable structs
On Sunday, 19 June 2016 at 02:06:59 UTC, deadalnix wrote: Long story short, I need structs that do not move. I'm sure there are many other use cases. I needed that for a struct member function to be passed as delegate for a fiber. The easiest way I found was to malloc the struct.
Re: Allowing DConf presentations to be spoken in other languages
On Friday, 10 June 2016 at 21:31:36 UTC, Jesse Phillips wrote: After this year's DConf I started to wonder if it could be beneficial to provide a slot during the conference where the speaker would do his presentation in a language other than English. I realize that many are like me and would not be able to consume such information, which is why the suggestion is to limit talks from other languages. My hope would be that it would help produce more language information content outside of English and strengthen those communities. Possibly uniting communities we don't see, but still center around D. This isn't for me, such an idea is not helpful for me. Is there anyone in a position who could speak to this being a reasonable thing to try? That's what local or national conferences are for. Still, even in such ones people often prefer to use English (I've seen it in Portugal and Poland), as CS vocabulary for other languages is usually awkward, non-consistent or non-existent, and it feels even more awkward to use English verbs and nouns interspersed with your native prepositions.
Re: Parse File at compile time, but not embedded
On Tuesday, 7 June 2016 at 22:09:58 UTC, Alex Parrill wrote: Not necessarily, You chased that rabbit quite far! The data your reading could contain sensitive information only used at compile time and not meant to embed. For example, the file could contain login and password to an SQL database that you then connect, at compile time and retrieve that information the disregard the password(it is not needed at run time). Accessing a SQL server at compile time seems like a huge abuse of CTFE (and I'm pretty sure it's impossible at the moment). Why do I need to install and set up a MySQL database in order to build your software? Just mount a filesystem that uses an SQL database as storage (query can be encoded in file path) and you have it. Whether it's a good idea is another story.
Re: Release DUB 0.9.25, new logo and updated website design
On Tuesday, 24 May 2016 at 22:59:24 UTC, Adrian Matoga wrote: (...) 1. The font is much thinner than on dlang.org main site PR: https://github.com/dlang/dub-registry/pull/156 3. Clicking the top-left dub logo directs to "http://code.dlang.org/packages/; which is 404. PR: https://github.com/dlang/dub-registry/pull/157
Re: Release DUB 0.9.25, new logo and updated website design
On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote: (...) The new site is cool, except a few annoyances: 1. The font is much thinner than on dlang.org main site (font-weight set to 300 for no good reason), and thus much harder to read. Using #333 for text color instead of pure black makes it even harder. Come on, perhaps most of us already have some sort of vision defects, please do not make it worse. 2. Project READMEs now render with different font which looks weird. (OTOH, the README alone looks nicer and easier on eyes, because plain Helvetica or Arial are just better suited for on-screen reading than clumsy serif fonts like roboto slab). 3. Clicking the top-left dub logo directs to "http://code.dlang.org/packages/; which is 404. 4. List of available versions for a package is broken: the most recent version is repeated multiple times and is not a hyperlink. Also, some parts of READMEs are not rendered the way they are on github, like: nested lists, [ ]/[x] progress ticks, syntax highlighting in code snippets.
Re: Idea: swap with multiple arguments
On Tuesday, 24 May 2016 at 02:40:24 UTC, Observer wrote: As for utility, if you're a PostScript programmer, where keeping track of data is done via a stack-oriented model, this capability gets used all the time, to bring relevant arguments to the top of the stack to be operated upon, or to shove arguments deeper into the stack for later use. Forth also has "swap" and "rot". The former moves 2nd value to the top of the stack (i.e. a, b becomes b, a). The latter moves 3rd value to the top (i.e. a, b, c becomes b, c, a).
Re: To all DConf speakers: please upload slides!
On Wednesday, 11 May 2016 at 17:31:32 UTC, dilkROM wrote: And also, if anyone can identify all lightning speakers, that would be terrific. We do need their slides and their names / desired nicknames / contact info as well. :) I didn't use slides, but only a few code examples, collected in a text file that Andrei pasted here: http://dpaste.dzfl.pl/36e4c089d0d6
Re: DustMite now has -j
On Wednesday, 11 May 2016 at 19:53:54 UTC, Vladimir Panteleev wrote: By popular demand. https://github.com/CyberShadow/DustMite/compare/e175b95da070d84029f75ba8a15f5d900fb90704...15693cbd5a5c0f47ee9cc68be9dada39b99c3836 Dreams come true. Thank you!
Re: So, About That Official Blog...
On Friday, 6 May 2016 at 13:47:48 UTC, Adam D. Ruppe wrote: On Friday, 6 May 2016 at 13:34:02 UTC, Jack Stouffer wrote: Using JS for an eye candy feature on the internet is not "outrageous". It's not like with JS turned off the code would be displayed with no formatting and in sans-serif. Those JS things have a habit of lagging my laptop to a crawl, whereas a server side highlighter works beautifully without slowdown. When your site works better without JS than with, you've made a mistake somewhere, especially when what the JS is doing could be free! I totally agree. This tumblr site easily lagged a bored i7. A big NO from me.
Re: Post-DConf brunch?
On Saturday, 7 May 2016 at 08:55:50 UTC, Joseph Rushton Wakeling wrote: Hello all, For anyone who's still in town and fancies grabbing a nice late breakfast/early lunch in a nice Berlin food place, I'll be doing my usual Saturday morning thing of dropping by this cafe/restaurant Cool! I'll be there in ca. 20 minutes.
Re: How are you enjoying DConf? And where to go next?
On Friday, 6 May 2016 at 20:59:29 UTC, John Colvin wrote: On Friday, 6 May 2016 at 14:57:59 UTC, Chris wrote: On Friday, 6 May 2016 at 14:53:15 UTC, Jonathan M Davis wrote: [...] Facebook have their European headquarters in Dublin. Maybe they'd be willing to sponsor DConf2017 (there are loads of other tech companies in Dublin). Flights from the U.S. to Ireland and back are very frequent. Dublin has cheap direct flights from quite a few places in the US, as well as pretty much everywhere in europe. Yup, +1 for Dublin.
Re: With statement extension
On Wednesday, 27 April 2016 at 18:34:18 UTC, Artur Skawina wrote:
[...]
void foo (Matrix matrix, SameType e1, SameType e2)
{
ref M() { return matrix.rawArr; }
ref Ex1() { return e1.someProperties.someModulusX; }
ref Ey1() { return e1.someProperties.someModulusY; }
ref Ex2() { return e2.someProperties.someModulusX; }
ref Ey2() { return e2.someProperties.someModulusY; }
ref v() { return e1.someProperties.aRatio; }
foreach (i; ...) foreach (j; ...) {
M[...] = Ex1 > Ex2 ?
1/v^^2 * sqrt(v * (Ex1 + Ex2)^^2 + v^^2 * (Ey1 -
Ey2)^^2) :
1/v^^2 * sqrt(v * (Ex1 + Ex2)^^2 + v^^2 * (Ey1 +
Ey2)^^2) ;
}
}
artur
Unless any of the properties is an enum or, well, a @property,
and I'd expect both in such case.
Re: Anonymous structure
On Monday, 18 April 2016 at 15:59:11 UTC, Steven Schveighoffer
wrote:
I wonder if it makes a difference for layout. So for example:
struct T
{
struct
{
int x;
ubyte y;
}
ubyte z;
}
If there is padding inserted between y and z.
There isn't. T.init.z.offsetof - T.init.y.offsetof == 1.
Re: The day before DConf 2016
On Thursday, 7 April 2016 at 18:13:16 UTC, Mike Parker wrote: I'm flying in to Berlin late on May 2nd. I'll be staying at the Hotel Ibis, slated to be the "unofficial hangout place" according to the DConf site. I'm curious who else will be in the area on the 3rd. I'm usually an explorer when I visit a city for the first time, but on this trip I'd be more interested in hanging out with others from DLand, conversing about our favorite language, if anyone's up for it. I'm arriving at Ostbahnhof on May 3rd at about 7:30pm. It doesn't leave much time for sightseeing, but it would be cool to join you for a dinner or a few pints. :)
Re: Joining AliasSeq/TypeTuple s
On Tuesday, 29 March 2016 at 10:06:43 UTC, Adrian Matoga wrote:
(...)
Another version that doesn't misbehave if first and second are of
different lengths:
import std.meta : AliasSeq;
template RR(A...) {
template With(B...) {
static if (A.length == 0 || B.length == 0)
alias With = AliasSeq!(A, B); // or static assert(0) if you
require equal lengths
else
alias With = AliasSeq!(A[0], B[0], RR!(A[1 .. $]).With!(B[1 ..
$]));
}
}
struct S(A...) {} // needed to reliably compare AliasSeq's for
equality
unittest {
alias first = AliasSeq!(int, string, bool);
alias second = AliasSeq!("abc", "def", "ghi");
alias third = RR!first.With!second;
static assert(is(S!third == S!(int, "abc", string, "def", bool,
"ghi")));
alias fourth = RR!(first[0 .. 2]).With!second;
static assert(is(S!fourth == S!(int, "abc", string, "def",
"ghi")));
}
Re: Joining AliasSeq/TypeTuple s
On Tuesday, 29 March 2016 at 09:33:40 UTC, Voitech wrote:
Hi, i want to join two or more tupples in to one, with mixing
the indexes like roundRobin but in compile time.
unittest{
import std.meta;
alias first=AliasSeq!(int, string,bool);
alias second=AliasSeq!("abc","def","ghi");
alias third=...
static assert(third==AliasSeq!(int, "abc", string, "def", bool,
"ghi"));
}
How to obtain this kind of functionality ? Is there maybe some
builin template for this in phobos ? I couldn't find this.
Thank you
Voitech.
import std.meta : AliasSeq;
template RR(A...)
if (!(A.length & 1))
{
static if (A.length == 0)
alias RR = AliasSeq!();
else {
alias Left = A[0 .. $ / 2];
alias Right = A[$ / 2 .. $];
alias RR = AliasSeq!(Left[0], Right[0], RR!(Left[1 .. $],
Right[1 .. $]));
}
}
struct S(A...) {} // needed to reliably compare AliasSeq's for
equality
unittest {
alias first = AliasSeq!(int, string, bool);
alias second = AliasSeq!("abc", "def", "ghi");
alias third = RR!(first, second);
static assert(is(S!third == S!(int, "abc", string, "def", bool,
"ghi")));
}
Re: Template mixins and struct constructors
On Wednesday, 2 March 2016 at 20:39:57 UTC, Adam D. Ruppe wrote: On Wednesday, 2 March 2016 at 12:27:04 UTC, Adrian Matoga wrote: Is it by design or is it a bug? And, if it is by design, what is the reason for that? That's by design. It allows you to override names from a template mixin like inheritance but no runtime cost. Read my tip of the week here to see how it works and how you can combine ctors from a mixin: http://arsdnet.net/this-week-in-d/2016-feb-07.html Ah, I was on vacation at that time so that's why I don't remember reading it. :) Thanks! It's a nice workaround but it's, well, a workaround. It leaks the internals of the template mixin and a potential API user would have to remember two additional quirks when using it. I guess I'll try a different approach, initializing the mixed in members later with a function.
Re: Template mixins and struct constructors
On Wednesday, 2 March 2016 at 14:36:59 UTC, Daniel Kozak wrote:
OK maybe this one:
template AddField(T) {
T b;
this(Args...)(T b, auto ref Args args)
{
this.b = b;
this(args);
}
this(int a) {
this.a = a;
}
}
struct Bar {
int a;
mixin AddField!(string);
}
unittest {
auto bar1 = Bar(5);
auto bar2 = Bar("bar", 15);
}
Then it's limited to structs in which only "int a" is to be
initialized. Not very useful and the templated ctor is not needed
now.
struct Baz {
mixin AddField!string; // fail, no "int a" in Baz.
ulong d;
double x;
string foo;
}
Re: Template mixins and struct constructors
On Wednesday, 2 March 2016 at 12:48:47 UTC, Daniel Kozak wrote:
On Wednesday, 2 March 2016 at 12:27:04 UTC, Adrian Matoga wrote:
(...)
You can use string mixins:
template AddField(T) {
enum AddField = T.stringof ~ ` b;
this(Args...)(` ~ T.stringof ~ ` b, auto ref Args args)
{
this.b = b;
this(args);
}`;
}
struct Bar {
mixin(AddField!string);
int a;
this(int a) { this.a = a; }
}
unittest {
auto bar1 = Bar(5);
auto bar2 = Bar("bar", 15); // line 31
}
What if T is private type in some other module or, even worse, a
Voldemort type?
Re: Dconf gets a new logo
On Wednesday, 2 March 2016 at 03:37:48 UTC, Andrei Alexandrescu wrote: Many thanks to https://github.com/aG0aep6G who contributed the DConf 2016 logo (the Berlin tower https://github.com/D-Programming-Language/dconf.org/pull/95). After discussing it with Sociomantic, they proposed a new one that is not Berlin-specific and also looks terrific on T-shirts. Take a look: http://dconf.org The "Register" link is now missing, but when I click "Venue", I can see "Register" and the old logo. Btw, how about making the entire top bar purple to match the logo (maybe the menu bar could be turned D-red instead)?
Template mixins and struct constructors
I can do this:
struct Foo {
int a;
string b;
this(int a) { this.a = a; }
this(Args...)(string b, auto ref Args args) { this.b = b;
this(args); }
}
unittest {
auto foo1 = Foo(5);
auto foo2 = Foo("foo", 15);
}
However, the following code is invalid:
mixin template AddField(T) {
T b;
this(Args...)(T b, auto ref Args args)
{
this.b = b;
this(args);
}
}
struct Bar {
mixin AddField!string;
int a;
this(int a) { this.a = a; }
}
unittest {
auto bar1 = Bar(5);
auto bar2 = Bar("bar", 15); // line 31
}
sctor.d(31): Error: constructor sctor.Bar.this (int a) is not
callable using argument types (string, int)
Is it by design or is it a bug?
And, if it is by design, what is the reason for that?
Re: Member Access Based On A Runtime String
On Tuesday, 1 March 2016 at 08:53:20 UTC, Adrian Matoga wrote:
static if (is(Q : T)) {
Oops, should be T : Q
Re: Member Access Based On A Runtime String
On Tuesday, 1 March 2016 at 05:05:40 UTC, Jack Stouffer wrote:
In Python, I can do this:
my_obj = Obj()
string_from_func = func()
setattr(my_obj, string_from_func, 100)
Say func() returns "member1" or "member2", the setattr would
then set either one of those to 100.
Is there any equivalent in D?
struct Foo
{
string foo = "dog";
int bar = 42;
int baz = 31337;
}
void set(P, T)(ref P p, string name, auto ref T value)
{
foreach (mem; __traits(allMembers, P)) {
static if (is(typeof(__traits(getMember, p, mem)) Q)) {
static if (is(Q : T)) {
if (mem == name) {
__traits(getMember, p, mem) = value;
return;
}
}
}
}
assert(0, P.stringof ~ " has no member " ~ name);
}
unittest
{
Foo foo;
foo.set("bar", 15);
assert(foo.bar == 15);
foo.set("foo", "cat");
assert(foo.foo == "cat");
}
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 20:25:05 UTC, anonymous wrote: On 10.02.2016 17:49, Ola Fosheim Grøstad wrote: If you guys are going to create a new logo based on the old one, you probably should clear it with the original creator. On his website he has give us use rights for non-commercial use, but not rights to create derivative works... The new logo is not part of the pull request. It's already on the site. If there's a legal problem, we should probably revert that. The exact text on the site of the original author [1] is COPYRIGHT © SUKIMASHITA 2006 ALL FREE TO USE. ONLY SELLING THESE IMAGES IS PROHIBITED. I'd understand that to allow derivative works, but disallow selling them. I'm not a lawyer, though. If those terms don't allow us to mess with the logo, what kind of statement or license do we need from the author? [1] http://media.sukimashita.com/d/ The same site also says, under "Guide": "Ease creation of derivative art (icons, banners etc.)", which is certainly not an explicit legal statement, but gives an idea of the author's intention.
Re: is(some template instantiation) is true, but the actual instantiation fails
On Friday, 29 January 2016 at 23:44:56 UTC, Basile B. wrote: Haven't you seen my answer about constraint ? If you put a constraint on your function template then invalid instantiations are rejected. I mean... this language feature is not just ornamental... What do you think constraints are used for otherwise ^^ Yes, I've seen it, thanks. Requiring the user to write the constraint might indeed enforce a better style, but I want to be able to test it even if the user forgets the constraint. Otherwise she'll get cryptic error messages from some other code assuming that CallsFoo!NoFoo is a valid type.
Re: is(some template instantiation) is true, but the actual instantiation fails
On Saturday, 30 January 2016 at 00:16:21 UTC, Ali Çehreli wrote: > https://issues.dlang.org/show_bug.cgi?id=15623 As I noted on the bug report, they are work when moved from module scope to inside a function (e.g. main()). At least there's that workaround... Ali Thanks a lot! Now I can continue my work. :)
Re: reduce -> fold?
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders. So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Thoughts? YES! There was a topic on this [1] and some implementation proposed. I'm not sure if it was the only one. [1] http://forum.dlang.org/post/sqbizjwcyavbrxwag...@forum.dlang.org
is(some template instantiation) is true, but the actual instantiation fails
Code:
struct HasFoo { void foo() {} }
struct NoFoo {}
struct CallsFoo(T) {
T t;
void bar() { t.foo(); }
}
static assert(is(CallsFoo!HasFoo));
alias Bar = CallsFoo!HasFoo;
static assert(is(CallsFoo!NoFoo)); // (1)
//alias Baz = CallsFoo!NoFoo; // (2)
This compiles, although I expected that (1) should fail.
Now try uncommenting (2) and it can't be compiled.
Why does `is(CallsFoo!NoFoo)` evaluate to true if
`is(CallsFoo!NoFoo)` can't be instantiated?
Am I missing something about `is(T)` or is it a bug?
How can I reliably test if CallsFoo can be instantiated?
Re: is(some template instantiation) is true, but the actual instantiation fails
On Friday, 29 January 2016 at 16:36:01 UTC, Steven Schveighoffer
wrote:
On 1/29/16 10:28 AM, Adrian Matoga wrote:
Code:
struct HasFoo { void foo() {} }
struct NoFoo {}
struct CallsFoo(T) {
T t;
void bar() { t.foo(); }
}
static assert(is(CallsFoo!HasFoo));
alias Bar = CallsFoo!HasFoo;
static assert(is(CallsFoo!NoFoo)); // (1)
//alias Baz = CallsFoo!NoFoo; // (2)
This compiles, although I expected that (1) should fail.
Now try uncommenting (2) and it can't be compiled.
Why does `is(CallsFoo!NoFoo)` evaluate to true if
`is(CallsFoo!NoFoo)`
can't be instantiated?
Am I missing something about `is(T)` or is it a bug?
How can I reliably test if CallsFoo can be instantiated?
is(T) is supposed to be false if T is not a valid type.
I would agree with you that the static assert should fail.
-Steve
Oh, there's more:
// this should fail:
static assert(is(CallsFoo!NoFoo));
// this should fail too:
static assert(is(typeof({ alias Baz = CallsFoo!NoFoo; return
Baz.init; }(;
// and this:
static assert(__traits(compiles, { alias Baz = CallsFoo!NoFoo;
return Baz.init; }()));
// but only this fails:
alias Baz = CallsFoo!NoFoo;
https://issues.dlang.org/show_bug.cgi?id=15623
Re: GDC Explorer Site Update
On Monday, 25 January 2016 at 23:08:32 UTC, Iain Buclaw wrote: http://explore.dgnu.org/ Nice! Is there a way to override the default '-Og'? It seems that now Currently I cannot see any difference Now supports 12 different architectures from ARM to SystemZ! (not including -m32 or any -march options) BTW, dunno how it's now, but about a year ago GDC was able to compile for AVR after removing two asserts in the frontend (checking if the pointer size is at least 32 bits or the like).
Re: GDC Explorer Site Update
On Tuesday, 26 January 2016 at 10:17:37 UTC, Adrian Matoga wrote: Nice! Is there a way to override the default '-Og'? It seems that now Currently I cannot see any difference Oops, pressed "Send" too quickly. Should be: I cannot see any difference in the output when I enter various optimization options.
Re: how to allocate class without gc?
On Tuesday, 26 January 2016 at 01:09:50 UTC, Igor wrote:
Is there any examples that shows how to properly allocate an
object of a class type with the new allocators and then release
it when desired?
There's an example of class object allocation in the
std.experimental.allocator docs:
// Dynamically allocate a class object
static class Customer
{
uint id = uint.max;
this() {}
this(uint id) { this.id = id; }
// ...
}
Customer cust = theAllocator.make!Customer;
assert(cust.id == uint.max); // default initialized
cust = theAllocator.make!Customer(42);
assert(cust.id == 42);
To release the object (call the destructor and free the memory),
call dispose():
theAllocator.dispose(cust);
You'll need to replace "theAllocator" with the allocator you want.
Re: LDC 0.17.0-beta1 has been released!
On Thursday, 14 January 2016 at 20:33:30 UTC, Kai Nacke wrote: LDC 0.17.0-beta1, the LLVM-based D compiler, is available for download! This release is based on the 2.068.2 frontend and standard library and supports LLVM 3.5-3.7. Excellent! Works great so far (Linux x86_64). Any chance of having pre-built binaries for cross-compiling to arm-linux-gnueabihf, like in GDC distributions?
Re: Logo for D
On Monday, 18 January 2016 at 10:28:48 UTC, Guillaume Piolat wrote: On Saturday, 16 January 2016 at 17:55:13 UTC, karabuta wrote: How do you see it? http://amazingws.0fees.us/wp-content/uploads/2016/01/dlang2.png Many variants are on the way. The current logo is very good and there is value in keeping it. Now if it didn't have this extremely 90s-looking borders, it would be even better. +1 Also, change just for the sake of change is just bad strategy.
Re: Distributed Memory implementation
On Monday, 18 January 2016 at 05:59:15 UTC, tcak wrote: I, due to a need, will start implementation of distributed memory system. Idea is that: Let's say you have allocated 1 GiB space in memory. This memory is blocked into 4 KiB. After some reservation, and free operations, now only the blocks 0, 12, and 13 are free to be allocated. Problem is that those memory blocks are not consecutive. With the implementation of distributed memory, those blocks will be appended into a struct or object (however it is implemented), and that struct or object will allow access to that 12 KiB of space (3 x 4 KiB blocks) like it is allocated in memory consecutively. Is there anything like this in Phobos, or shall I start my own implementation? Just a note about terminology: I'd rather call it "fragmented memory" or something alike. The term "distributed memory" usually refers to something really different [1]. Your idea seems interesting, but IMHO a compacting GC should be the preferred solution for heap fragmentation. [1] https://en.wikipedia.org/wiki/Distributed_memory
Re: Hash Tables in D
On Sunday, 3 January 2016 at 19:29:05 UTC, Martin Nowak wrote: There is a bug. You should never do this b/c of iterator/range invalidation. foreach (key; aa.keys) aa.remove(key); I've recently hit this when trying to remove some of the elements from an AA while iterating over it. It's easy to forget that it is not allowed, especially when working on more complex algorithms. Accidentally, it worked all fine even with large data sets with DMD 2.069, but with GDC mysterious segfaults appeared - the first thought in such case was obviously a bug in GDC or in the older front-end. However, this is a very convenient, natural and intuitive syntax for something that is needed quite frequently, yet this code breaks silently in non-predictable ways. There are already registered issues concerning this (or similar with insertion) problem, including: https://issues.dlang.org/show_bug.cgi?id=4179 https://issues.dlang.org/show_bug.cgi?id=2255 https://issues.dlang.org/show_bug.cgi?id=10821 https://issues.dlang.org/show_bug.cgi?id=10876 https://issues.dlang.org/show_bug.cgi?id=13903 I've personally encountered segfaults, infinite loops, programs producing incorrect results. Some solutions to this were proposed in the bug reports - either: a) explicitly allow removing during iteration, and make sure it always works, or b) explicitly disallow removing during iteration, and always throw an Error whenever it is attempted. In some cases it could even be detectable in compile time. And I don't mean including a single sentence about this somewhere in the docs. I mean an error reported by the compiler and/or runtime. The runtime checks could be disabled for -release, but there should be at least an option to detect such errors. Probably the worst part of it is that you're free to wrap it in @safe, while it's not safe at all.
Re: Socket - handling large numbers of incoming connections
On Monday, 21 December 2015 at 21:32:55 UTC, Jakob Jenkov wrote: My server uses "poll" for that. Okay, how does that work? How do I use "poll" in D? Link? Code example? The same as in C [1]. Just change #include to import core.sys.posix.poll; [1] http://linux.die.net/man/2/poll
Re: We need a good code font for the function signatures on dlang.org
On Wednesday, 16 December 2015 at 21:05:27 UTC, Andrei Alexandrescu wrote: I was looking at https://github.com/D-Programming-Language/dlang.org/pull/1169 and that bold sans serif proportional text for the code is just... well let's say it's time to replace it. What would be a good code font to use for those? My favourites would be: Menlo, DejaVu Sans Mono, Ubuntu Mono. But don't embed them, just provide a safe fallback, like monospace.
Re: Redesign of dlang.org
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg wrote: Thoughts? Excellent, both for increasing the apparent brand value for newcomers and for reducing frustration of existing users. Minimalistic, modern, professional and consistent look & feel, easy to read and navigate - even at the very first sight at the main site one can instantly find what they're looking for.
Re: We need better documentation for functions with ranges and templates
On Tuesday, 15 December 2015 at 01:10:01 UTC, Chris Wright wrote:
This reminds me of the Tango strategy for this kind of thing.
tango.core.Array was arranged like this:
version(TangoDoc) {
/** Documentation comment. */
bool isSameLangth(Range1, Range2)(Range1 r1, Range2 r2) {
return true;
}
} else {
bool isSameLength(Range1, Range2)(Range1 r1, Range2 r2)
if (
isInputRange!Range1 &&
isInputRange!Range2 &&
!isInfinite!Range1 &&
!isInfinite!Range2) {
// actual implementation
}
}
Fantastic example of why this strategy should be just banned. You
need to duplicate the signature in the source, and you are free
to make any mistake that won't be caught by the compiler, such as
the typo in the word 'Length' here. A beginner then copies the
signature and fills in the argument part, and then spends minutes
decrypting error messages or even grepping Phobos source to find
out that the name of the function should be spelled
'isSameLength', as it's quite easy to overlook, especially when
you copy-paste from the official documentation, which you expect
to be correct.
Re: We need better documentation for functions with ranges and templates
On Tuesday, 15 December 2015 at 16:12:18 UTC, Chris Wright wrote: On Tue, 15 Dec 2015 09:09:43 +, Adrian Matoga wrote: Fantastic example of why this strategy should be just banned. Just as well I wasn't recommending it as a long-term solution. I was more offering it as additional evidence that template definitions can get a bit large and people have known that this is a problem for documentation for eight years now. "Banned" is a strong term. Perhaps you simply meant it should not be recommended and should not be used in Phobos? Yes, perhaps "strongly discouraged" would be a more appropriate wording. version(StdDdoc) already appears about 40 times in Phobos, sometimes wrapping quite large blocks of declarations. I doubt the maintainability of such setup in the long term.
Re: How to return user name from vibed session?
On Thursday, 10 December 2015 at 11:36:20 UTC, Suliman wrote:
Vibed have method get for user session
http://vibed.org/api/vibe.http.session/SessionStore
I set user name for session like this:
req.session.set("username", "admin");
But I can't understand how to get user name from it:
abstract std.variant.VariantN!(20) get(
string id,
string name,
lazy std.variant.VariantN!(20) defaultVal
);
What does every string here mean? Could anybody to show example
of usage?
I think what you need is Session.get, not SessionStore.get:
http://vibed.org/api/vibe.http.session/Session.get
