How to run vibe.d web app in XAMPP server ?
In our production server, we have only XAMPP for use to deploy web app and mysql combinedly? Is there any way how to deploy the vibe.d web app into XAMPP ?
Re: Developing blockchain software with D, not C++
On Sunday, 14 January 2018 at 23:03:27 UTC, Andrei Alexandrescu wrote: Thanks for these thoughts! * (u)cent support * fixes for the shared qualifier * ownership mechanism These took less than 1h to add support for? That would be awesome... but realistically only the (u)cent sounds like that size of effort. I've always wondered why we can't implement struct LargeInt(uint bytes) as a library mechanism for larged fixed-size integers, with asm specialization for LargeInt!8. Is adding the type to the compiler necessary, and if so, why? Andrei That is the proposed path for bootstrapping the compiler. See https://github.com/d-gamedev-team/gfm/blob/master/integers/gfm/integers/wideint.d https://github.com/dlang/dmd/pull/7699 and recent effort to have struct as the main integral type in the compiler.
Re: Compiler bug or incorrect usage for pointer of Struct?
On Sunday, 14 January 2018 at 14:12:55 UTC, Temtaime wrote:
On Sunday, 14 January 2018 at 13:24:14 UTC, Heromyth wrote:
On Sunday, 14 January 2018 at 08:05:34 UTC, Temtaime wrote:
On Sunday, 14 January 2018 at 04:02:09 UTC, Heromyth wrote:
On Saturday, 13 January 2018 at 14:11:23 UTC, H. S. Teoh
wrote:
On Sat, Jan 13, 2018 at 12:22:17PM +, Heromyth via
Digitalmars-d wrote: [...]
https://run.dlang.io/is/RUHtqK
It's not ok dude
It runs because you don't use any variable inside the struct
and because struct members are simple functions with hidden
parameter
Thanks. It's really dangerous to use a pointer to struct!
I have created another test based on your code. See here
https://run.dlang.io/is/LOeMKG
I add *ref* in the constructor and add a new template fucntion
writerFor. So, it goes back the scenario in my first post.
Tester tester = new Tester(buildWriter()); // can't compile.
The compiler does the right thing.
Tester tester = writerFor(buildWriter()); // Here is a bug,
because the compiler takes this!
Am I right?
There's no bug in compiler.
"auto ref" can be NOT a reference. It depends on its parameter.
RValues are passed by value.
given
writerFor(buildWriter());
it becomes
auto writerFor(OutRange)(OutRange outRange) // NO REF,
parameter is on the stack
{
auto res = new Tester(outRange);
return res;
}
and after writerFor the returned object points on a variable
inside writerFor which already died
I see. Thanks!
Re: Developing blockchain software with D, not C++
On Sun, 14 Jan 2018 18:03:27 -0500, Andrei Alexandrescu wrote: > On 1/4/18 8:42 AM, deadalnix wrote: >> I would *LOVE* to be able to use more D on a day to day basis, but >> these 2 problems make it very hard. It is especially sad considering 1/ >> could be solved very easily. It literally took me less than 1h to add >> support for it in SDC. > > Thanks for these thoughts! > > * (u)cent support * fixes for the shared qualifier * ownership mechanism > > These took less than 1h to add support for? That would be awesome... but > realistically only the (u)cent sounds like that size of effort. > That's what he said: "... considering 1/ could be solved very easily. It literally took me less than 1h to add support for it in SDC."
Re: Developing blockchain software with D, not C++
On 1/4/18 8:42 AM, deadalnix wrote: On Saturday, 30 December 2017 at 16:59:41 UTC, aberba wrote: In this video[1] from 2016, developer talks about C++ memory safety features, meta-programming, maturity and few others as main reasons they choose it for developing their blockchain software (the way I got it from a quick view). Besides, D maturity (which I can't confirm or deny), what else does D miss to be considered a better alternative for blockchain in 2018? D is also more productive, has safety and unittest built-in. 1. https://www.youtube.com/watch?v=w4jq4frE5v4 I can talk about this first hand as I have a project running in D. However, I would sadly not recommend D ATM for such a project for 2 reasons: 1/ It is practically not possible to write efficient crypto routines without cent/ucent, short of writing them in asm. 2/ The network layer become very tedious very quick because of how broken shared is and because there is no ownership mechanism. While none of this is present in C++ it doesn't get in your way either. I would *LOVE* to be able to use more D on a day to day basis, but these 2 problems make it very hard. It is especially sad considering 1/ could be solved very easily. It literally took me less than 1h to add support for it in SDC. Thanks for these thoughts! * (u)cent support * fixes for the shared qualifier * ownership mechanism These took less than 1h to add support for? That would be awesome... but realistically only the (u)cent sounds like that size of effort. I've always wondered why we can't implement struct LargeInt(uint bytes) as a library mechanism for larged fixed-size integers, with asm specialization for LargeInt!8. Is adding the type to the compiler necessary, and if so, why? Andrei
Re: Bump the minimal version required to compile DMD to 2.076.1
On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote: Motivation -- 1) It's required for Walter's work on using -betterC for the backend conversion: https://github.com/dlang/dmd/pull/6907 That is only a putative dependency. Indeed the -mv== feature is useful. If it's just about the backend though, there is a straightforward solution. If we insist on having a backend package (not under dmd) ``` module backend.cod1; ``` then we can simply move the package to the right place ``` mv src/dmd/backend src/backend ``` . Imports of dmd from backend obviously forbidden (should be enforced by separate compilation). 2) We start to run into random failures lately, e.g. https://github.com/braddr/d-tester/issues/63 https://github.com/dlang/dmd/pull/7569#issuecomment-356992048 3) There's also WIP to move dmd-cxx to 2.076.1: https://github.com/dlang/dmd/pull/7595 We've been through bootstrapping discussions a couple of times, so let me repeat what was decided when we made the frontend switch from C++ to D. - Other platforms are bootstrapped by cross-compilation. - DMD must be compilable with the latest stable/major release of dmd, ldc, and gdc. To enforce this policy the Travis-CI test was set up. Hopefully this original purpose of the Travis-CI hasn't been forgotten in the meantime. - No other guarantees were negotiated. Sticking to an ancient compiler defeats the eat your own dogfood goal underlying the C++ -> D transition. The latest released frontend versions are at the moment: 2.078 - dmd (2.078.1) 2.077 - ldc (1.7.0) 2.068 - gdc (6.3.0+2.068.2) So technically we could only upgrade to 2.068 atm. Would be good to hear some release plans from the GDC team for this year. == Just in case this is what dmd's schedule looks like for 2018. 2.078.0 - 2018-01-01 2.079.0 - 2018-03-01 2.080.0 - 2018-05-01 2.081.0 - 2018-07-01 2.082.0 - 2018-09-01 2.083.0 - 2018-11-01 2.084.0 - 2019-01-01 I wished the semver discussion¹ would have been a bit more decisive and we'd started out the year with 8.0.0 (majors every 6 months, minors every 2 months). Hopefully we take the chance of relabeling 2.080.0 to 8.0.0. [¹]: http://forum.dlang.org/post/eghpfllbnvvlskbdp...@forum.dlang.org
Re: Tuple DIP
On Sun, Jan 14, 2018 at 10:17 AM, Timon Gehr via Digitalmars-d wrote: > On 14.01.2018 19:14, Timothee Cour wrote: >> >> actually I just learned that indeed sizeof(typeof(tuple()))=1, but why >> is that? (at least for std.typecons.tuple) >> maybe worth mentioning that in the DIP (with rationale) > > > It's inherited from C, where all struct instances have size at least 1. > (Such that each of them has a distinct address.) Should definitely be mentioned in the DIP to open that up for discussion; it breaks assumptions like sizeof(Tuple)=sum_i : tuple (sizeof(Ti)); even if that were the case in std.typecons.tuple, having it as builtin could behave differently.
Re: Tuple DIP
On 14.01.2018 19:14, Timothee Cour wrote: actually I just learned that indeed sizeof(typeof(tuple()))=1, but why is that? (at least for std.typecons.tuple) maybe worth mentioning that in the DIP (with rationale) It's inherited from C, where all struct instances have size at least 1. (Such that each of them has a distinct address.)
Phobos bindings
Phobos comes with zlib, curl and sqlite bindings. Zlib sources come with phobos, so there's no need to build and link with it separately. Why there's no curl and sqlite sources ? For example sqlite comes as 1 file. I think we can add it too, isn't it ?
Re: Tuple DIP
actually I just learned that indeed sizeof(typeof(tuple()))=1, but why is that? (at least for std.typecons.tuple) maybe worth mentioning that in the DIP (with rationale) On Sun, Jan 14, 2018 at 8:18 AM, Timon Gehr via Digitalmars-d wrote: > On 14.01.2018 15:55, Q. Schroll wrote: >> >> On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote: >>> >>> [...] >>> This DIP aims to make code like the following valid D: >>> >>> --- >>> auto (a, b) = (1, 2); >>> (int a, int b) = (1, 2); >>> --- >>> [...] >> >> >> How is (1, 2) different from [1, 2] (static array)? > > > The first is a tuple, the second is a static array. This distinction exists > already, it is not proposed in this DIP. > > I.e., you could just as well ask "How is tuple(1, 2) different from [1, 2] > (static array)?". A (probably non-exhaustive) answer is that dynamic arrays > have a 'ptr' property; slicing a static array will produce a dynamic array; > tuples alias this to an 'expand' property that gives the components as an > AliasSeq; an empty tuple will take up 1 byte of space in a struct/class, but > an empty static array will not; empty static arrays have an element type, > 'void' is allowed as the element type of an empty static array; array > literals are _dynamic_ arrays by default, enforcing homogeneous element > types, while tuple literals give you heterogeneous _tuples_, ... > > None of this has much to do with the DIP though. > >> It makes no sense to me to have both and probably a bunch of conversion >> rules/functions. >> ... > > > The DIP proposes no new conversion rules, nor does it _introduce_ tuples. > You'll need to complain about the status quo elsewhere; blaming the DIP for > it makes no sense. > >> Why don't you consider extending (type-homogeneous) static arrays to >> (finite type enumerated) tuples? > > > Because tuples and arrays have significant differences as outlined above and > tuple literal syntax is essentially useless if it needs to be accompanied by > explicit type casts or annotations on every use. It's better to not add > tuple syntax at all than to overload square brackets in this ad-hoc manner. > Calling 'tuple(1, 2.0)' is less of a hassle than writing cast([int, > double])[1, 2.0]. This is just not good language design. > >> It solves >> - 1-tuples > > > There is already a solution. > >> - comma operator vs. tuple literal > > > The comma operator is gone. > >> instantly. > > > I think it introduces more problems than it solves. > >> You'd have T[n] as an alias for the tuple type consisting of n objects of >> type T. >> ... > > > So whether or not a tuple is instead a static array (according to the > differences above) depends on whether or not the types happen to be > homogeneous? > > I do understand very well the superficial aesthetic appeal, but this is > unfortunately just not a workable approach. > >> I've written something about that here: >> https://forum.dlang.org/post/wwgwwepihklttnqgh...@forum.dlang.org > > > (The DIP links to that thread.) > >> (sorry for my bad English in that post) >> ... > > > The English is fine. > >> The main reason I'd vote against the DIP: Parenthesis should only be used >> for operator precedence and function calls. > > > You do realize that this translates to "just because"? > (That, and you forgot about template instantiation, type constructor/typeof > application, if/for/while/switch/scope/... statements, type casts, basic > type constructor/new calls, ... (list wildly non-exhaustive).)
Re: Tuple DIP
On 14.01.2018 15:55, Q. Schroll wrote: On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote: [...] This DIP aims to make code like the following valid D: --- auto (a, b) = (1, 2); (int a, int b) = (1, 2); --- [...] How is (1, 2) different from [1, 2] (static array)? The first is a tuple, the second is a static array. This distinction exists already, it is not proposed in this DIP. I.e., you could just as well ask "How is tuple(1, 2) different from [1, 2] (static array)?". A (probably non-exhaustive) answer is that dynamic arrays have a 'ptr' property; slicing a static array will produce a dynamic array; tuples alias this to an 'expand' property that gives the components as an AliasSeq; an empty tuple will take up 1 byte of space in a struct/class, but an empty static array will not; empty static arrays have an element type, 'void' is allowed as the element type of an empty static array; array literals are _dynamic_ arrays by default, enforcing homogeneous element types, while tuple literals give you heterogeneous _tuples_, ... None of this has much to do with the DIP though. It makes no sense to me to have both and probably a bunch of conversion rules/functions. ... The DIP proposes no new conversion rules, nor does it _introduce_ tuples. You'll need to complain about the status quo elsewhere; blaming the DIP for it makes no sense. Why don't you consider extending (type-homogeneous) static arrays to (finite type enumerated) tuples? Because tuples and arrays have significant differences as outlined above and tuple literal syntax is essentially useless if it needs to be accompanied by explicit type casts or annotations on every use. It's better to not add tuple syntax at all than to overload square brackets in this ad-hoc manner. Calling 'tuple(1, 2.0)' is less of a hassle than writing cast([int, double])[1, 2.0]. This is just not good language design. It solves - 1-tuples There is already a solution. - comma operator vs. tuple literal The comma operator is gone. instantly. I think it introduces more problems than it solves. You'd have T[n] as an alias for the tuple type consisting of n objects of type T. ... So whether or not a tuple is instead a static array (according to the differences above) depends on whether or not the types happen to be homogeneous? I do understand very well the superficial aesthetic appeal, but this is unfortunately just not a workable approach. I've written something about that here: https://forum.dlang.org/post/wwgwwepihklttnqgh...@forum.dlang.org (The DIP links to that thread.) (sorry for my bad English in that post) ... The English is fine. The main reason I'd vote against the DIP: Parenthesis should only be used for operator precedence and function calls. You do realize that this translates to "just because"? (That, and you forgot about template instantiation, type constructor/typeof application, if/for/while/switch/scope/... statements, type casts, basic type constructor/new calls, ... (list wildly non-exhaustive).)
Re: Tuple DIP
On Sunday, 14 January 2018 at 00:01:15 UTC, rikki cattermole
wrote:
On 13/01/2018 11:45 PM, Timothee Cour wrote:
some people have suggested using `{a, b}` instead of `(a,b)` ;
this
would not work because of ambiguity, eg:
`auto fun(){ return {}; }`
already has a meaning, so the empty tuple would not work.
so `()` is indeed better.
Easy fix, tuples must have a length greater than 0.
A tuple with length 0 is by definition void.
Zero tuples exist and don't have type void as their type has an
object: the empty tuple. It's similar to the empty word, the
empty array, etc.
They naturally arise in corner cases of templates. You have to
support them like static arrays of length 0.
Effectively forbidding them would be an unreasonable limitation.
Re: Tuple DIP
On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote: [...] This DIP aims to make code like the following valid D: --- auto (a, b) = (1, 2); (int a, int b) = (1, 2); --- [...] How is (1, 2) different from [1, 2] (static array)? It makes no sense to me to have both and probably a bunch of conversion rules/functions. Why don't you consider extending (type-homogeneous) static arrays to (finite type enumerated) tuples? It solves - 1-tuples - comma operator vs. tuple literal instantly. You'd have T[n] as an alias for the tuple type consisting of n objects of type T. I've written something about that here: https://forum.dlang.org/post/wwgwwepihklttnqgh...@forum.dlang.org (sorry for my bad English in that post) The main reason I'd vote against the DIP: Parenthesis should only be used for operator precedence and function calls.
Re: Compiler bug or incorrect usage for pointer of Struct?
On Sunday, 14 January 2018 at 13:24:14 UTC, Heromyth wrote:
On Sunday, 14 January 2018 at 08:05:34 UTC, Temtaime wrote:
On Sunday, 14 January 2018 at 04:02:09 UTC, Heromyth wrote:
On Saturday, 13 January 2018 at 14:11:23 UTC, H. S. Teoh
wrote:
On Sat, Jan 13, 2018 at 12:22:17PM +, Heromyth via
Digitalmars-d wrote: [...]
https://run.dlang.io/is/RUHtqK
It's not ok dude
It runs because you don't use any variable inside the struct
and because struct members are simple functions with hidden
parameter
Thanks. It's really dangerous to use a pointer to struct!
I have created another test based on your code. See here
https://run.dlang.io/is/LOeMKG
I add *ref* in the constructor and add a new template fucntion
writerFor. So, it goes back the scenario in my first post.
Tester tester = new Tester(buildWriter()); // can't compile.
The compiler does the right thing.
Tester tester = writerFor(buildWriter()); // Here is a bug,
because the compiler takes this!
Am I right?
There's no bug in compiler.
"auto ref" can be NOT a reference. It depends on its parameter.
RValues are passed by value.
given
writerFor(buildWriter());
it becomes
auto writerFor(OutRange)(OutRange outRange) // NO REF, parameter
is on the stack
{
auto res = new Tester(outRange);
return res;
}
and after writerFor the returned object points on a variable
inside writerFor which already died
Re: Compiler bug or incorrect usage for pointer of Struct?
On Sunday, 14 January 2018 at 08:05:34 UTC, Temtaime wrote: On Sunday, 14 January 2018 at 04:02:09 UTC, Heromyth wrote: On Saturday, 13 January 2018 at 14:11:23 UTC, H. S. Teoh wrote: On Sat, Jan 13, 2018 at 12:22:17PM +, Heromyth via Digitalmars-d wrote: [...] https://run.dlang.io/is/RUHtqK It's not ok dude It runs because you don't use any variable inside the struct and because struct members are simple functions with hidden parameter Thanks. It's really dangerous to use a pointer to struct! I have created another test based on your code. See here https://run.dlang.io/is/LOeMKG I add *ref* in the constructor and add a new template fucntion writerFor. So, it goes back the scenario in my first post. Tester tester = new Tester(buildWriter()); // can't compile. The compiler does the right thing. Tester tester = writerFor(buildWriter()); // Here is a bug, because the compiler takes this! Am I right?
Re: Compiler bug: Incorrect line in error message
Reported as issue #18236
It is possible this is a duplicate of issue #3773, from 8 years ago
(opened on D1).
On 14/01/18 14:24, Shachar Shemesh wrote:
Please consider the following program:
struct V {
int a;
}
struct S {
enum A = V(12); // Line 6
}
void main() {
int b = cast(int)S.A; // Line 10
}
It fails to compile:
test2.d(6): Error: cannot cast expression V(12) of type V to int
Everything about this error message is correct except the line number.
It should be line 10, not line 6. The problem is where the incorrect
cast is performed, not where the enum is defined.
I just spent three hours on this problem (thanks to Idan. Otherwise I'd
spend much much more).
Shachar
Compiler bug: Incorrect line in error message
Please consider the following program:
struct V {
int a;
}
struct S {
enum A = V(12); // Line 6
}
void main() {
int b = cast(int)S.A; // Line 10
}
It fails to compile:
test2.d(6): Error: cannot cast expression V(12) of type V to int
Everything about this error message is correct except the line number.
It should be line 10, not line 6. The problem is where the incorrect
cast is performed, not where the enum is defined.
I just spent three hours on this problem (thanks to Idan. Otherwise I'd
spend much much more).
Shachar
Re: Compiler bug or incorrect usage for pointer of Struct?
On Sunday, 14 January 2018 at 04:02:09 UTC, Heromyth wrote:
On Saturday, 13 January 2018 at 14:11:23 UTC, H. S. Teoh wrote:
On Sat, Jan 13, 2018 at 12:22:17PM +, Heromyth via
Digitalmars-d wrote: [...]
auto writerFor(OutRange)(auto ref OutRange outRange)
{
auto res = Writer!(OutRange)();
res.setSink(outRange);
return res;
}
struct Writer(OutRange)
{
private OutRange* output;
void setSink(ref OutRange output)
{
this.output = &output;
[...]
Here's the bug. `output` refers to a local variable
(parameter) in
writerFor(), which goes out of scope after writerFor() exits,
so
this.output becomes a dangling pointer.
T
I have another test. It runs whithout any error. Here it is:
import std.stdio;
void main()
{
Tester tester = new Tester(buildWriter());
tester.run("It's OK");
}
struct StringWriter
{
void put(string s)
{
writeln(s);
}
}
StringWriter buildWriter()
{
return StringWriter();
}
class Tester
{
private StringWriter* writer;
this(StringWriter w)
{
writer = &w;
writer.put("ok");
}
void run(string m)
{
writer.put(m);
}
}
https://run.dlang.io/is/RUHtqK
It's not ok dude
It runs because you don't use any variable inside the struct and
because struct members are simple functions with hidden parameter
