Re: [theory] What is a type?
On Monday, 15 January 2018 at 20:46:19 UTC, Ali wrote: If you want to learns the ins and outs of types, this books comes highly recommended https://www.cis.upenn.edu/~bcpierce/tapl/ +1, TAPL is a must read for anyone in CS, I believe. Also recommended: "Type Theory & Functional Programming" by Simon Thompson, "Practical Foundations for Programming Languages" by Robert Harper and his and his colleagues lectures here: https://www.cs.uoregon.edu/research/summerschool/archives.html Many programmers remain unaware that there is a discipline called Type Theory, as part of math in general, it predates all electronic computers and it's still very relevant today. Anyone dabbling into compilers and programming language theory should learn the basics of type theory, proof theory and some category theory, these three are very much connected and talk about basically the same constructions from different angles (see Curry-Howard correspondence and "computational trinitarianism"). It's ridiculous how many programmers only learn about types from books on C++ or MSDN, get very vague ideas about them and never learn any actual PLT. Of course type is not a set of values, or any other set, not at all.
Re: Phobos bindings
On 1/14/18 1:17 PM, Temtaime wrote: 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 ? The inclusion of etc in general has been considered a mistake. Since they were added, dub has obviated any need to include such things in Phobos. In fact there have been efforts to remove them from Phobos (https://github.com/dlang/phobos/pull/4283). That being said, zlib is quite a static library. The others are actively developed, and we shouldn't need to keep updating all our sources when the external dependencies change. -Steve
Re: Proposed Phobos equivalent of wcswidth()
On Monday, 15 January 2018 at 13:34:09 UTC, Jack Stouffer wrote: On Saturday, 13 January 2018 at 17:26:52 UTC, H. S. Teoh wrote: ... Thanks for taking the time to do this. And now the obligatory bikeshed: what should the Phobos equivalent of wcswidth be called? std.utf.displayWidth std.utf.bikeshed Never heard that phrase before. Nice one :)
Re: How to run vibe.d web app in XAMPP server ?
On Monday, 15 January 2018 at 06:22:13 UTC, Jayam wrote: 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 ? To use Apache to proxy requests to your D app do something along these lines: Configure a Virtual Host for use with the application: sudo vim /etc/apache2/sites-available/yoursite.conf using the following content: ServerAdmin webmas...@example.com ServerName example.com ServerAlias www.example.com ErrorLog /var/log/apache2/yoursite-error.log CustomLog /var/log/apache2/yoursite-access.log common ProxyRequests off ProxyPreserveHost off ProxyPass / http://127.0.0.1:8080 ProxyPassReverse / http://127.0.0.1:8080 Then make sure to enable the relevant mods and your site sudo a2enmod proxy proxy_http sudo a2ensite yoursite Verfiy the Apache config with apachectl configtest then restart: sudo systemctl restart apache2
Re: Tuple DIP - tuple unification with arrays and structs
On 1/14/2018 6:55 AM, Q. Schroll wrote:
How is (1, 2) different from [1, 2] (static array)?
It's a very good question. It's corollary is how is (1, 2) different from
struct S { int a, b; }
It does turn out that int[2] is structurally (!) the same as struct S. This is a
property I've taken some pains to ensure stays valid, and it has turned out to
be nicely useful.
But consider:
S foo(char a, char b);
t = ('a', 'b');
foo(t); // equivalent to foo('a', 'b')
That works. But:
S s = {'a', 'b' };
foo(s); // Does not work
It does not work is because s as a parameter has a distinctly different ABI than
(char, char). The former consumes an int sized parameter, the latter two int
sized parameters. A similar issue exists with the return value.
So far, the issue of unification of tuples with arrays (and structs) has
defeated me because of the fundamental structural differences in the ABI which
we are stuck with.
Re: Tuple DIP
On 1/14/2018 10:17 AM, Timon Gehr wrote: It's inherited from C, where all struct instances have size at least 1. (Such that each of them has a distinct address.) There are some peculiarities with that, like with multiple inheritance sometimes the size really is zero :-)
Re: [theory] What is a type?
On Monday, 15 January 2018 at 19:25:16 UTC, H. S. Teoh wrote:
At the most abstract level, a type is just a set. The members
of the set represent what values that type can have.
Hm, yes, like representing an ordered pair (a,b) as {{a},{a,b}}.
But I think typing is more commonly viewed as a filter. So if you
represent all values as sets, then the type would be a filter
preventing certain combinations.
It is a matter of perspective, constructive or not constructive.
Kinda like synthesis, additive (combine sines) or subtractive
(filter noise).
Re: [theory] What is a type?
On Sunday, 10 October 2010 at 12:28:32 UTC, Justin Johansson wrote: Now having hopefully described that a type is something that might well have multiple orthogonal aspects to its identity, how would one go about implementing a dynamic language with such a complex type system in D? I realize that this is a complex topic and that it might require better articulation than so far I have given. Nevertheless, thanks for all replies, Justin Johansson If you want to learns the ins and outs of types, this books comes highly recommended https://www.cis.upenn.edu/~bcpierce/tapl/
Re: [theory] What is a type?
On Sunday, 10 October 2010 at 12:28:32 UTC, Justin Johansson
wrote:
Specifically I have a problem in trying to implement
a functional language translator in D. My target language
has a rather non-conventional type system, in which,
superficially at least, types can be described as being
Cartesian in nature. That is,
types in this system have two orthogonal dimensions:
(1) classical data-type (e.g. boolean, number, string,
object) and
(2) Kleene cardinality (occurrences) with respect to (1).
The axial origin of this Cartesian type-system correlates well
with the concept of the "top" type (AKA "Unit" in Scala)
and as the rather adhoc "void" type in many Algol-derived
languages such as C/C++/Java/D.
So along axis 1 we might broadly describe the classical
data types as item, boolean, number, string, object where
item is effectively either a superclass or variant of the
other mentioned types.
Along axis 2 we describe Kleene occurrences of 1 as may be
passed contractually to a receiving function. These
occurrences may be enumerated six-fold as:
zeroOrMore
zeroOrOne
oneOrMore
exactlyZero
exactlyOne
none
Readers may see that, for example, zeroOrOne is a special
case (perhaps a subclass?) of zeroOrMore. exactlyOne is
a special case of both zeroOrOne and oneOrMore (sounds like
multiple inheritance?). OTOH, exactlyZero is a special
case of zeroOrOne, which, in turn, is a special case of
zeroOrmore.
none is a special case of all of the above and reflects
the cardinality facet of the return type of a function
that never returns (say as by throwing an exception).
To make this type system even more enigmatic lets add a
third dimension, taking the 2-D Cartesian type system
model to a 3-D Spatial model, by imagining a further
degree of freedom with respect to laziness of evaluation
(AKA closure of arguments).
Now having hopefully described that a type is something
that might well have multiple orthogonal aspects to its
identity, how would one go about implementing a dynamic
language with such a complex type system in D?
I realize that this is a complex topic and that it might
require better articulation than so far I have given.
Nevertheless, thanks for all replies,
Justin Johansson
Well, in D-speak you could imagine taking (perhaps arbitrarily)
the first axis (basic data type) as the "skeleton" and attach
various properties to it. For example:
Int!(exactlyOne, eager) x = 42;
Int!(zeroOrMore, lazy) y;
readf("%d", &y);
auto foo = x+y; // What does this mean? What type is foo?
You seem to have in mind a syntax for your type system but I'm
not sure how you intend for the semantics to work. D's templates
are really nice in that they allow you to express many properties
of a term that are not "hard coded" into its type. So you can do
stuff like:
enum MinimizationTarget { programThroughput, GCThroughput,
heapOverhead, pauseTimes, pauseFrequency, heapFragmentation,
warmupTime }
auto GarbageCollector(MinimizationTarget[] priorities = [])()
{
static if (priorities == []) return
StopTheWorldMarkAndSweepGC();
else static if (priorities[0] == heapFragmentation) return
copyingGC();
else static if (/* some boolean algebra condition on
$priorities */) return GenerationalMarkAndSweepGC();
else /* etc. */
}
auto myGC = GarbageCollector![pauseTimes, heapOverHead,
programThroughput];
auto myGraph = Graph!(myGC, directed);
which is pretty cool. :)
Re: Proposed Phobos equivalent of wcswidth()
On Sat, Jan 13, 2018 at 09:26:52AM -0800, H. S. Teoh via Digitalmars-d wrote: [...] > https://github.com/quickfur/strwidth [...] One thing I'm seeking help with, and this is mainly directed at Dmitry Olshansky but can be anyone here who knows the internal workings of std.uni well enough, is how to transform the Trie generated by the static ctor into compile-time TrieNode declarations. This is one blocker for my turning this code into a Phobos PR, because I don't want to incur the cost of initializing this trie at runtime. Also, on a related note, there exist nicer interfaces in std.uni for constructing Tries that map ranges of codepoints to non-boolean values, but none of these are available publicly. The current implementation in strwidth only uses the public API of std.uni, so the construction of the trie is pretty horrendous (looping over individual codepoints and creating an AA of individual codepoints -- including very large ranges like the entire Unicode plane 2). I wonder if some of these facilities should be made public so that user code that needs to construct codepoint tries that include large ranges of codepoints can do so more efficiently. T -- This sentence is false.
Re: [theory] What is a type?
On Monday, 15 January 2018 at 19:34:23 UTC, Ali Çehreli wrote: On 01/15/2018 10:58 AM, Jonathan Marler wrote: > On Sunday, 10 October 2010 at 12:28:32 UTC, Justin Johansson wrote: > I'm getting "nostalgia" from all the math terminology :) Just the date of the post you're responding to is sufficient for "nostalgia". ;) Ali Oh wow! I don't know why the form post was on the first page of my form thread. You think he still checks his thread every day to see if someone has responded? :)
Re: [theory] What is a type?
On Mon, Jan 15, 2018 at 06:58:37PM +, Jonathan Marler via Digitalmars-d
wrote:
[...]
> That being said, I don't think this model really get much closer to
> answering the original question, "what is a type?".
[...]
At the most abstract level, a type is just a set. The members of the set
represent what values that type can have. Operations on types are
therefore simply operations on sets, which lets us bring in the entire
mechanism of mathematical sets to elaborate upon the theory of types.
A boolean, for example, is simply a 2-membered set B = {true, false}. A
struct of two booleans is just the Cartesian product B x B. An array of
booleans is simply the Kleene closure of B, i.e., the union of all
Cartesian powers of B, usually denoted as B*.
This abstract view disregards how a type is actually implemented, and
merely considers its set of possible values. Under this model, you
begin by describing the sets of possible values your program will work
with. Then when you're ready to implement it, you decide on some kind of
mapping to map the abstract sets to the physical types provided by the
hardware.
On a more practical level, the way I see a type is an *interpretation*
imposed upon a series of zero or more bytes (or, if you want to drill
down even deeper, bits). The same binary values can represent different
types, depending on how you interpret them. Under this model, you
proceed in the opposite direction: starting with an arbitrary sequence
of bytes, you recursively build up interpretations of it until you
arrive at the data structures that your program will operate on.
The abstract view is useful when you're working within your problem
domain: it allows you to phrase your algorithms and transformations
directly in terms of the objects and operations you wish to work on. But
it's not always so easy to map this abstract model onto the quirks of
the hardware you have to work with. It's easy to think of trivial
mappings, of course, but generally they will have pretty poor
performance because they don't take advantage of the properties of the
underlying hardware. Finding an *efficient* mapping that doesn't also
break correctness can be quite challenging.
The practical view is useful when you're building things from ground up,
e.g., when you're building a compiler. It lets you build up types that
can take advantage of the underlying hardware's properties, and also
avoid or work around hardware quirks or weaknesses. It also allows you
to reinterpret types creatively, that may allow you to achieve
interesting effects (e.g., the data bytes output by the compiler can be
reinterpreted as executable code by the CPU). However, types built up
this way may not map nicely into your problem domain, and that forces
your code to become convoluted in order to compensate for the impedance
mismatch between the two. Correctness may also be compromised if the
objects in your problem domain don't have a 1-to-1 fit with the hardware
types (e.g., your calculator program might operate on integers in the
mathematical sense of numbers that can be arbitrarily large, but the int
type provided by the hardware is modulo some power of 2; so when values
get too large, what your program thinks of as an integer no longer
matches what the hardware implements, resulting in overflow/underflow
bugs).
Finding the sweet spot that balances the two is non-trivial, and is the
subject of entire fields of research. :-D
T
--
The trouble with TCP jokes is that it's like hearing the same joke over and
over.
Re: [theory] What is a type?
On 01/15/2018 10:58 AM, Jonathan Marler wrote: > On Sunday, 10 October 2010 at 12:28:32 UTC, Justin Johansson wrote: > I'm getting "nostalgia" from all the math terminology :) Just the date of the post you're responding to is sufficient for "nostalgia". ;) Ali
gRPC in D good idea for GSOC 2018?
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
Re: [theory] What is a type?
On Sunday, 10 October 2010 at 12:28:32 UTC, Justin Johansson wrote: Specifically I have a problem in trying to implement a functional language translator in D. My target language has a rather non-conventional type system, in which, superficially at least, types can be described as being Cartesian in nature. That is, types in this system have two orthogonal dimensions: (1) classical data-type (e.g. boolean, number, string, object) and (2) Kleene cardinality (occurrences) with respect to (1). The axial origin of this Cartesian type-system correlates well with the concept of the "top" type (AKA "Unit" in Scala) and as the rather adhoc "void" type in many Algol-derived languages such as C/C++/Java/D. So along axis 1 we might broadly describe the classical data types as item, boolean, number, string, object where item is effectively either a superclass or variant of the other mentioned types. Along axis 2 we describe Kleene occurrences of 1 as may be passed contractually to a receiving function. These occurrences may be enumerated six-fold as: zeroOrMore zeroOrOne oneOrMore exactlyZero exactlyOne none Readers may see that, for example, zeroOrOne is a special case (perhaps a subclass?) of zeroOrMore. exactlyOne is a special case of both zeroOrOne and oneOrMore (sounds like multiple inheritance?). OTOH, exactlyZero is a special case of zeroOrOne, which, in turn, is a special case of zeroOrmore. none is a special case of all of the above and reflects the cardinality facet of the return type of a function that never returns (say as by throwing an exception). To make this type system even more enigmatic lets add a third dimension, taking the 2-D Cartesian type system model to a 3-D Spatial model, by imagining a further degree of freedom with respect to laziness of evaluation (AKA closure of arguments). Now having hopefully described that a type is something that might well have multiple orthogonal aspects to its identity, how would one go about implementing a dynamic language with such a complex type system in D? I realize that this is a complex topic and that it might require better articulation than so far I have given. Nevertheless, thanks for all replies, Justin Johansson I'm getting "nostalgia" from all the math terminology :) Here are some of my thoughts: You've taken one property, cardinality, and put that on one axis and then declared all other properties in your system should be orthogonal to cardinality. But then you said that "string" was on the other axis, which itself is of type zeroOrMore(char), violating your own system. You also need to take into account that cardinality is multi-dimensional. i.e. you could have zeroOrMore(char) or zeroOrMore(zeroOrMore(char)). That being said, I don't think this model really get much closer to answering the original question, "what is a type?". A while back I watched a cppcon talk from Dan Saks who defined what a data type was in C++: https://www.youtube.com/watch?v=D7Sd8A6_fYU#t=58m59s Note that the whole video also contains alot of good information. It explores the social aspects being a programmer and is definitely worth watching. In his video he declares a data type as a "bundle of compile-time properties for an object", namely 1. size/alignment 2. set of values 3. set of permitted operations This model is a very good breakdown of what a type is in C++. D's a bit more complex. When you say "type" in D, there's alot more things you could be talking about so you either need to expand your definition of what a type is, or restrict the entities you consider to be types. But these 3 properties are a good start :) A bit off topic. I find it frustrating that types always need to have these 3 properties. Most of the time a programmer doesn't care about size/alignment, they just want the set of values and operations. D can allow a programmer to do this using templates, but that "throws the baby out with the bath water". You almost always require subset of properties. Because template don't define any of the properties, you end up with cryptic template error messages. D's tried to make the problem better by using conditional templates and C++ is trying to solve this with "Concepts". I've explored these ideas for a long time and am still currently developing my own methods for solving these problems. My latest idea is that you can create different "type interfaces". At a minimum, I've defined a type to be a "pure function" that takes any value and maps it to a boolean indicating whether or not that value is a member of that type. That's the "minimum interface", but you could also have a type that declares other properties, such as, a set of "values", or size/alignment. However, it's important to allow a developer to work with types that don't necessarily define all these properties for every time. Anyway, I'm mostly just sharing some of my thoughts. I have alot to say on this subject bu
Re: Proposed Phobos equivalent of wcswidth()
On Monday, January 15, 2018 10:37:14 H. S. Teoh via Digitalmars-d wrote: > On Mon, Jan 15, 2018 at 06:20:16PM +, Jack Stouffer via Digitalmars-d wrote: > > On Monday, 15 January 2018 at 17:32:40 UTC, H. S. Teoh wrote: > > > On Mon, Jan 15, 2018 at 02:14:56PM +, Simen Kjærås via > > > Digitalmars-d > > > > > > wrote: > > > > On Monday, 15 January 2018 at 13:34:09 UTC, Jack Stouffer wrote: > > > > > std.utf.displayWidth > > > > > > > > +1 > > > > > > [...] > > > > > > Why std.utf rather than std.uni, though? > > > > The way I understand it is that std.uni is (supposed to be) for > > functions on individual unicode units (be they code units/points or > > graphemes) and std.utf is for functions which handle operating on > > unicode strings. > > Are you sure? I thought std.utf was specifically dealing with UTF-* > encodings, i.e., code units and conversions to/from code points, and > std.uni was supposed to be for implementing Unicode algorithms and > Unicode compliance in general, i.e., stuff that works at the code point > level. Your understanding of the division more or less matches mine, though I'm not sure that the line is entirely clearcut. I would definitely think that std.uni was the more appropriate place for such a function. - Jonathan M Davis
Re: Proposed Phobos equivalent of wcswidth()
On Mon, Jan 15, 2018 at 06:20:16PM +, Jack Stouffer via Digitalmars-d wrote: > On Monday, 15 January 2018 at 17:32:40 UTC, H. S. Teoh wrote: > > On Mon, Jan 15, 2018 at 02:14:56PM +, Simen Kjærås via Digitalmars-d > > wrote: > > > On Monday, 15 January 2018 at 13:34:09 UTC, Jack Stouffer wrote: > > > > std.utf.displayWidth > > > > > > +1 > > [...] > > > > Why std.utf rather than std.uni, though? > > The way I understand it is that std.uni is (supposed to be) for > functions on individual unicode units (be they code units/points or > graphemes) and std.utf is for functions which handle operating on > unicode strings. Are you sure? I thought std.utf was specifically dealing with UTF-* encodings, i.e., code units and conversions to/from code points, and std.uni was supposed to be for implementing Unicode algorithms and Unicode compliance in general, i.e., stuff that works at the code point level. > Obviously there are exceptions. I think "they" put graphemeStride in > std.uni because Grapheme was defined there and it seemed reasonable at > the time. But, generally I think utf stuff should go into std.utf. But displayWidth isn't really directly related to UTF (i.e., the encoding of Unicode code points). It seems to me to be more to do with processing Unicode in general, though, granted, the optimizations I implemented are kinda in a grey zone between dealing with Unicode proper (i.e., with code points) vs. working with code units. T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney
Re: Proposed Phobos equivalent of wcswidth()
On Monday, 15 January 2018 at 17:32:40 UTC, H. S. Teoh wrote: On Mon, Jan 15, 2018 at 02:14:56PM +, Simen Kjærås via Digitalmars-d wrote: On Monday, 15 January 2018 at 13:34:09 UTC, Jack Stouffer wrote: > std.utf.displayWidth +1 [...] Why std.utf rather than std.uni, though? The way I understand it is that std.uni is (supposed to be) for functions on individual unicode units (be they code units/points or graphemes) and std.utf is for functions which handle operating on unicode strings. Obviously there are exceptions. I think "they" put graphemeStride in std.uni because Grapheme was defined there and it seemed reasonable at the time. But, generally I think utf stuff should go into std.utf.
Re: How to run vibe.d web app in XAMPP server ?
On Monday, 15 January 2018 at 06:22:13 UTC, Jayam wrote: Is there any way how to deploy the vibe.d web app into XAMPP ? No you cant deploy vibe.d web app into XAMPP. What you can do is to install vibe.d to the same server and tell apache to proxy all requests to vibe.d. I dont know enough about servers to tell you exactly how to do it but it should be the same as setting up node.js. https://stackoverflow.com/questions/9831594/apache-and-node-js-on-the-same-server I hope this helps
Re: Proposed Phobos equivalent of wcswidth()
On Mon, Jan 15, 2018 at 02:14:56PM +, Simen Kjærås via Digitalmars-d wrote: > On Monday, 15 January 2018 at 13:34:09 UTC, Jack Stouffer wrote: > > std.utf.displayWidth > > +1 [...] Why std.utf rather than std.uni, though? T -- ASCII stupid question, getty stupid ANSI.
Re: Proposed Phobos equivalent of wcswidth()
On Monday, 15 January 2018 at 15:08:24 UTC, Kagamin wrote: columnWidth as it only makes sense for column-oriented text display. I think displayWidth is better, because "width" is directly linked to hozizontal direction (else it would be called hight), and setting text in colums would still take additional steps to be set correct. Also "display" indicates that it has nothing to do with the string length, which is good to avoid confusion.
Web Application Development
We create web applications from the ground up, tailored to your specific needs and that of your business. Weather you need to digitise an existing paper-based form or you want to build a ground-breaking social network. We've got it covered. We use the latest languages, frameworks and development techniques available to ensure your application is future proofed with the most reliable and secure of technology. https://viewport-tech.com/web-application-development
Re: Proposed Phobos equivalent of wcswidth()
columnWidth as it only makes sense for column-oriented text display.
Re: Proposed Phobos equivalent of wcswidth()
On Monday, 15 January 2018 at 13:34:09 UTC, Jack Stouffer wrote: std.utf.displayWidth +1 -- Simen
Re: Bump the minimal version required to compile DMD to 2.076.1
Btw, ther is a gdc which stil uses c++ version of dfrontend, so on DragonFlyBSD you can build dmd using gdc. On Mon, Jan 15, 2018 at 2:25 PM, Daniel Kozak wrote: > So why not to use cross compilation? > > On Mon, Jan 15, 2018 at 2:10 PM, Joakim via Digitalmars-d < > digitalmars-d@puremagic.com> wrote: > >> On Monday, 15 January 2018 at 12:15:27 UTC, Temtaime wrote: >> >>> And what builds C++ compiler from source ? :) >>> >> >> The system C/C++ compiler is already built and there, obviously. Since >> nobody ships a D compiler with their OS, I'm not sure how you think that's >> relevant. >> >> On Monday, 15 January 2018 at 12:36:04 UTC, Daniel Kozak wrote: >> >>> Exactly, there is no reason to build 2.067, 2.076, and 2.078, just build >>> the latest one with the previos one. It is common (in case you do not have >>> dlang compiler in your distribution) to start with downloading existing >>> binary and compile lastest version as a package, then you can use this >>> package as a dependency for building new versions. >>> >> >> There is no existing binary for an OS that doesn't have a port yet! >> >> Take the current DragonFlyBSD port that's being done: he had to port both >> dmd 2.067, which is written in C++, and the latest dmd master to DragonFly, >> in order to have source packages for their ports repository: >> >> https://github.com/dlang/dmd/pull/7463 >> >> If you bump the D compiler required for latest master, he'll have to port >> every bumped D compiler too, ie 2.067, 2.076, and 2.078, in order to have a >> source package. That's going to be a huge pain that will stop many from >> doing the initial port. >> > >
Re: Proposed Phobos equivalent of wcswidth()
On Saturday, 13 January 2018 at 17:26:52 UTC, H. S. Teoh wrote: ... Thanks for taking the time to do this. And now the obligatory bikeshed: what should the Phobos equivalent of wcswidth be called? std.utf.displayWidth
Re: Bump the minimal version required to compile DMD to 2.076.1
So why not to use cross compilation? On Mon, Jan 15, 2018 at 2:10 PM, Joakim via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Monday, 15 January 2018 at 12:15:27 UTC, Temtaime wrote: > >> And what builds C++ compiler from source ? :) >> > > The system C/C++ compiler is already built and there, obviously. Since > nobody ships a D compiler with their OS, I'm not sure how you think that's > relevant. > > On Monday, 15 January 2018 at 12:36:04 UTC, Daniel Kozak wrote: > >> Exactly, there is no reason to build 2.067, 2.076, and 2.078, just build >> the latest one with the previos one. It is common (in case you do not have >> dlang compiler in your distribution) to start with downloading existing >> binary and compile lastest version as a package, then you can use this >> package as a dependency for building new versions. >> > > There is no existing binary for an OS that doesn't have a port yet! > > Take the current DragonFlyBSD port that's being done: he had to port both > dmd 2.067, which is written in C++, and the latest dmd master to DragonFly, > in order to have source packages for their ports repository: > > https://github.com/dlang/dmd/pull/7463 > > If you bump the D compiler required for latest master, he'll have to port > every bumped D compiler too, ie 2.067, 2.076, and 2.078, in order to have a > source package. That's going to be a huge pain that will stop many from > doing the initial port. >
Re: Bump the minimal version required to compile DMD to 2.076.1
On Monday, 15 January 2018 at 12:15:27 UTC, Temtaime wrote: And what builds C++ compiler from source ? :) The system C/C++ compiler is already built and there, obviously. Since nobody ships a D compiler with their OS, I'm not sure how you think that's relevant. On Monday, 15 January 2018 at 12:36:04 UTC, Daniel Kozak wrote: Exactly, there is no reason to build 2.067, 2.076, and 2.078, just build the latest one with the previos one. It is common (in case you do not have dlang compiler in your distribution) to start with downloading existing binary and compile lastest version as a package, then you can use this package as a dependency for building new versions. There is no existing binary for an OS that doesn't have a port yet! Take the current DragonFlyBSD port that's being done: he had to port both dmd 2.067, which is written in C++, and the latest dmd master to DragonFly, in order to have source packages for their ports repository: https://github.com/dlang/dmd/pull/7463 If you bump the D compiler required for latest master, he'll have to port every bumped D compiler too, ie 2.067, 2.076, and 2.078, in order to have a source package. That's going to be a huge pain that will stop many from doing the initial port.
Re: Bump the minimal version required to compile DMD to 2.076.1
Exactly, there is no reason to build 2.067, 2.076, and 2.078, just build the latest one with the previos one. It is common (in case you do not have dlang compiler in your distribution) to start with downloading existing binary and compile lastest version as a package, then you can use this package as a dependency for building new versions. On Mon, Jan 15, 2018 at 1:15 PM, Temtaime via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > And what builds C++ compiler from source ? :) >
Re: Bump the minimal version required to compile DMD to 2.076.1
And what builds C++ compiler from source ? :)
I didn't succeed in creating an empty project for a long time
zoujiaqing@Brian-XPS MINGW64 /d/Projects $ dub init serializable -v Using dub registry url 'https://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at C:\ProgramData\dub\packages\local-packages.json Looking for local package map at C:\Users\Brian\AppData\Roaming\dub\packages\local-packages.json No package found in current working directory.
Re: How to run vibe.d web app in XAMPP server ?
On Monday, 15 January 2018 at 06:22:13 UTC, Jayam wrote: 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 ? You can use hunt framework, it's an full-stack web framework. Create project: ```D git clone https://github.com/huntlabs/hunt-skeleton.git myproject cd myproject dub run -v ``` Open the URL with the browser: ```bash http://localhost:8080/ ``` Github repo: https://github.com/huntlabs/hunt
Re: Bump the minimal version required to compile DMD to 2.076.1
On Sunday, 14 January 2018 at 19:22:11 UTC, Martin Nowak wrote: 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. Realistically, I'm not sure how this is supposed to work beyond the initial port. As Thomas Mader pointed out earlier, most packaging systems expect to build from source, which right now means starting with the 2.067/2.068 C++ frontend and then porting every version needed up till the latest. So under Seb's proposed scenario, 2.067, 2.076, and 2.078 would all need to be ported and integrated into their packaging system. If we bump it to 2.082 later, that becomes, 2.067, 2.076, 2.082, and the latest at the time, 2.085 or whatever. This makes it more and more difficult for ports. - 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. Yet the dmd and ldc CI, not sure about gdc, explicitly build with 2.068 to make sure it's still working. Maybe that's because gdc is still on 2.068, but it wasn't clear that that's the reason. - No other guarantees were negotiated. Sticking to an ancient compiler defeats the eat your own dogfood goal underlying the C++ -> D transition. Realistically this isn't happening, since the compiler doesn't use the stdlib or gc anyway. 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 I hope that happens, but 18.0 would be better, so it matches the year.
