On Saturday, 14 November 2015 at 06:16:15 UTC, Walter Bright
wrote:
True, but that doesn't support your assertion that transpiling
to C produces better C interop.
Setting aside compatibility with the C preprocessor, I've asked
for a single instance where a language that transpiles to C has
be
On 11/14/2015 12:06 AM, Ola Fosheim Grøstad wrote:
I'm not sure if it reasonable to set aside the preprocessor,
If your new language doesn't have the C preprocessor in it, then you must set it
aside. If it does have a C preprocessor in it, then it really isn't a new
language at all, it's just
On 14-Nov-2015 02:10, Andrei Alexandrescu wrote:
I created a simple persistent list with reference counting and custom
allocation at http://dpaste.dzfl.pl/0981640c2835. It's a good
illustration of a number of issues. In particular, each cast must be
properly explained.
Here's my exegesis:
[snip
On Saturday, 14 November 2015 at 08:28:08 UTC, Walter Bright
wrote:
If your new language doesn't have the C preprocessor in it,
then you must set it aside. If it does have a C preprocessor in
it, then it really isn't a new language at all, it's just a C
permutation.
But you can do code gen wi
On Saturday, 14 November 2015 at 09:58:19 UTC, Ola Fosheim
Grøstad wrote:
http://www.mercurylang.org/backends.html
Btw, didn't Ali convert his book on D using princeXML?
princeXML is written in Mercury:
https://en.wikipedia.org/wiki/Prince_(software)
Hi,
I'm currently making changes to cgdb, and would like to have
someone give a quick view over the lexer rules.
https://github.com/cgdb/cgdb/blob/master/lib/tokenizer/dlexer.l
Having a skim over myself, I see @nogc needs adding, and probably
c_long, cpp_long and other ABI compatibility type
On 11/14/2015 1:58 AM, Ola Fosheim Grøstad wrote:
[...]
Like I said, you think the points I raised are all non-issues. You'll change
your mind once you try to implement one, and then try to support it with a
diverse group of customers.
> C99 defines [...]
I just have to laugh. You even ad
On Saturday, 14 November 2015 at 11:30:04 UTC, Walter Bright
wrote:
Like I said, you think the points I raised are all non-issues.
Please don't make assumptions about what I think. What I think is
that for a language that is aligned with C semantics, you can
with reasonable effort generate go
On Saturday, 14 November 2015 at 10:44:53 UTC, Iain Buclaw wrote:
Hi,
I'm currently making changes to cgdb, and would like to have
someone give a quick view over the lexer rules.
https://github.com/cgdb/cgdb/blob/master/lib/tokenizer/dlexer.l
Having a skim over myself, I see @nogc needs addi
On 11/11/2015 4:19 AM, Walter Bright wrote:
I've looked into generating C code as an output format. I found the problems to
be endemic and working around them was harder than just generating native code:
1. You're at the mercy of bugs in the C compiler you cannot fix.
2. C leaves quite a lot as
On Saturday, 14 November 2015 at 11:30:04 UTC, Walter Bright
wrote:
Guess what happened when I found out that people were relying
on bugs in gcc's preprocessor, not to mention all of its
non-standard behavior.
Off-topic, but I'd like to know more about that. Did you by any
chance ever wrote a
On Saturday, 14 November 2015 at 00:37:51 UTC, Manu wrote:
In the meantime, there probably needs to be strong warnings
about violating attributes, and if patterns have emerged that
rely on violating such attributes, we should publish a
recommended alternative.
One pattern that comes to mind i
This is a classic topic in .learn when someone tries to declare a
static array over 10 MB. Are there other limits ? Are they worth
a new documentation page ?
For example, FPC has
http://www.freepascal.org/docs-html/3.0.0/prog/progap3.html
On Sat, 2015-11-14 at 10:47 +1000, Manu via Digitalmars-d wrote:
> […]
> I'd love to read a revised edition of that page! :)
So write it, and do the pull request. It doesn't matter if it is any
good or not, what matters is activity. All the waffling and wailing on
the mailing list results in f###
On Fri, 2015-11-13 at 19:40 -0800, Walter Bright via Digitalmars-d
wrote:
> […]
>
> that would be most appreciated!
Or you could do it based on your material, no?
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200
http://wiki.dlang.org/DIP85
This DIP proposes an officially sanctioned way to initialize
const members (or mutable members of const structs) lazily by
allowing limited mutation of const objects.
Destroy!
Dan Olson writes:
> Johannes Pfau writes:
>
>> Am Thu, 12 Nov 2015 09:59:14 -0800
>> schrieb Dan Olson :
>>
>>> Johannes Pfau writes:
>>> > To expand on this: I think we'd prefer one __d_personality_v0 which
>>> > is implemented in upstream druntime and identical for all
>>> > compilers.
>>>
http://dlang.org/phobos/std_experimental_allocator.html
I am not sure what the plan is but it seems to me that the
standard library could make use of the "theAllocator" for
allocation and also allow you to swap in different allocators.
So could it then be possible to completely bypass the GC
On Saturday, 14 November 2015 at 14:30:33 UTC, Marc Schütz wrote:
http://wiki.dlang.org/DIP85
This DIP proposes an officially sanctioned way to initialize
const members (or mutable members of const structs) lazily by
allowing limited mutation of const objects.
Destroy!
I'm just right now r
On Saturday, 14 November 2015 at 11:39:12 UTC, Brian Schott wrote:
On Saturday, 14 November 2015 at 10:44:53 UTC, Iain Buclaw
wrote:
Hi,
I'm currently making changes to cgdb, and would like to have
someone give a quick view over the lexer rules.
https://github.com/cgdb/cgdb/blob/master/lib/t
On Friday, 13 November 2015 at 18:40:06 UTC, Iain Buclaw wrote:
There may be a few other holes between how Fibers and EH
interact.
https://github.com/D-Programming-Language/druntime/commit/f6633abb43ea1f2464d3a772b8f8fe78216ffd8e
The SJLJ stack switching should probably be added to this
mech
On 11/13/2015 06:36 PM, Steven Schveighoffer wrote:
On 11/13/15 6:10 PM, Andrei Alexandrescu wrote:
I created a simple persistent list with reference counting and custom
allocation at http://dpaste.dzfl.pl/0981640c2835. It's a good
illustration of a number of issues. In particular, each cast mus
On 11/13/2015 06:26 PM, Ali Çehreli wrote:
On 11/13/2015 03:10 PM, Andrei Alexandrescu wrote:
> at http://dpaste.dzfl.pl/0981640c2835
> * Lines 11-12: I came to terms with the notion that some types cannot be
> made immutable.
Could constructor qualifiers help in such cases? I would like to
On 11/13/2015 06:41 PM, Timon Gehr wrote:
On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote:
* Lines 6: By construction the list doesn't work with mutable objects.
=(
I've decided persistent lists with mutable elements just too weird to
endorse. Lisp allows them but every time it mentions
On 11/13/2015 07:28 PM, Jakob Ovrum wrote:
On Friday, 13 November 2015 at 23:10:04 UTC, Andrei Alexandrescu wrote:
* Lines 11-12: I came to terms with the notion that some types cannot
be made immutable. We've been trying to do reference counting on
immutable objects for a long time. It's time t
On 11/14/2015 4:35 AM, cym13 wrote:
Off-topic, but I'd like to know more about that. Did you by any chance ever
wrote a blog post of some sort describing thoses issues?
Sorry, it was a couple years ago, I don't recall the specifics.
On 11/14/2015 3:39 AM, Ola Fosheim Grøstad wrote:
What I think is that for a
language that is aligned with C semantics, you can with reasonable effort
generate good quality C99 code.
https://www.youtube.com/watch?v=YlVDGmjz7eM
:-)
P.S. another problem with `RC!(immutable T)` is that it actually
must be `shared(RC!(immutable T)` to be provide @safe API.
I don't think immutable should be something casual and widespread
in most designs at all. It is a very restrictive qualifier with
an extremely narrow use case, trying to retro-fit it to be easy
to use and compose tends to do more harm than actually going with
mutable instead.
All trouble come
On 11/14/2015 08:47 AM, Russel Winder via Digitalmars-d wrote:
On Fri, 2015-11-13 at 19:40 -0800, Walter Bright via Digitalmars-d
wrote:
[…]
that would be most appreciated!
Or you could do it based on your material, no?
I take it there's a bit of sarcasm there, so probably it's worth trying
On Saturday, 14 November 2015 at 17:01:53 UTC, Loretta wrote:
On Saturday, 14 November 2015 at 13:46:32 UTC, Russel Winder
wrote:
On Sat, 2015-11-14 at 10:47 +1000, Manu via Digitalmars-d
wrote:
[…]
I'd love to read a revised edition of that page! :)
So write it, and do the pull request. It d
On Saturday, 14 November 2015 at 17:03:21 UTC, Reg wrote:
On Saturday, 14 November 2015 at 17:01:53 UTC, Loretta wrote:
On Saturday, 14 November 2015 at 13:46:32 UTC, Russel Winder
wrote:
On Sat, 2015-11-14 at 10:47 +1000, Manu via Digitalmars-d
wrote:
[...]
So write it, and do the pull requ
On Saturday, 14 November 2015 at 13:46:32 UTC, Russel Winder
wrote:
On Sat, 2015-11-14 at 10:47 +1000, Manu via Digitalmars-d wrote:
[…]
I'd love to read a revised edition of that page! :)
So write it, and do the pull request. It doesn't matter if it
is any good or not, what matters is activi
On Friday, 13 November 2015 at 21:30:35 UTC, Rory McGuire wrote:
On Tue, Nov 10, 2015 at 6:56 PM, Steven Schveighoffer via
Digitalmars-d < digitalmars-d@puremagic.com> wrote:
To install a new compiler I just download the latest .tar.xz
and place in /usr/local/dmd/; and then rename "dmd2" direc
On Saturday, 14 November 2015 at 16:19:13 UTC, Walter Bright
wrote:
On 11/14/2015 3:39 AM, Ola Fosheim Grøstad wrote:
What I think is that for a
language that is aligned with C semantics, you can with
reasonable effort
generate good quality C99 code.
https://www.youtube.com/watch?v=YlVDGmjz7
On 11/14/2015 04:45 PM, Andrei Alexandrescu wrote:
On 11/13/2015 06:41 PM, Timon Gehr wrote:
On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote:
* Lines 6: By construction the list doesn't work with mutable objects.
=(
I've decided persistent lists with mutable elements just too weird to
en
On 11/14/2015 05:05 PM, Andrei Alexandrescu wrote:
Technically, that clearly works. There's a problem with scaling it up:
COMPOSITION
...
Composition matters.
Disallowing immutable(RC!T) in favor of RC!(immutable T) effectively
disables composition of larger immutable objects from smaller o
On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote:
...
* Lines 11-12: I came to terms with the notion that some types cannot be
made immutable. We've been trying to do reference counting on immutable
objects for a long time. It's time to acknowledge that true immutability
(which the immutable key
On Saturday, 14 November 2015 at 16:27:17 UTC, Dicebot wrote:
All trouble comes from trying to use physical immutable as
logical one while still pretending it gives physical
guarantees. Even if existing immutability is not widely
applicable, I'd prefer to have narrow applicability over wide
fa
On 11/14/2015 03:36 PM, Timon Gehr wrote:
Right, because e.g. whether the elements are reference counted or traced
should totally completely change the required container semantics for
the problem at hand! This does not make any sense, unless you are saying
that nobody should actually use the per
On 11/14/2015 03:55 PM, Timon Gehr wrote:
On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote:
...
* Lines 11-12: I came to terms with the notion that some types cannot be
made immutable. We've been trying to do reference counting on immutable
objects for a long time. It's time to acknowledge that
On 11/14/2015 09:42 PM, Andrei Alexandrescu wrote:
On 11/14/2015 03:36 PM, Timon Gehr wrote:
Right, because e.g. whether the elements are reference counted or traced
should totally completely change the required container semantics for
the problem at hand! This does not make any sense, unless yo
On 11/13/2015 07:51 AM, Stefan wrote:
On Thursday, 12 November 2015 at 23:08:57 UTC, Jakob Ovrum wrote:
> [...dependency check...]
It can be implemented as an external tool with the -deps compiler switch.
there is depend [1].
It warns about cycles and unintended dependencies if you specif
On 11/14/2015 05:04 PM, Timon Gehr wrote:
We have had the discussion you are asking for before, and you have
decided to ignore it, with the justification that this was how you
decided and a vague appeal to emotion. I usually don't operate under
the assumption that identical experiments lead to di
On 11/14/2015 10:59 PM, Andrei Alexandrescu wrote:
On 11/14/2015 03:55 PM, Timon Gehr wrote:
On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote:
...
* Lines 11-12: I came to terms with the notion that some types cannot be
made immutable. We've been trying to do reference counting on immutable
ob
On 11/14/15 5:49 PM, Timon Gehr wrote:
It's supposed to guarantee that the given reference is not used to
transitively mutate the object. The casts violate this.
I think that semantics needs to change. Specifically, either we add a
@mutable attribute (which means const doesn't apply to fields
On 11/14/2015 11:37 PM, Andrei Alexandrescu wrote:
On 11/14/2015 05:04 PM, Timon Gehr wrote:
We have had the discussion you are asking for before, and you have
decided to ignore it, with the justification that this was how you
decided and a vague appeal to emotion. I usually don't operate under
On 11/15/2015 12:20 AM, Andrei Alexandrescu wrote:
On 11/14/15 5:49 PM, Timon Gehr wrote:
It's supposed to guarantee that the given reference is not used to
transitively mutate the object. The casts violate this.
I think that semantics needs to change. Specifically, either we add a
@mutable at
Sorry for the delay, here's the initial commit for C++ exception
catching in Calypso:
https://github.com/Syniurge/Calypso/commit/8b55ec1f013c29df86455ab055fbba91a72d92af
https://github.com/Syniurge/druntime/commit/d33d8bf32c739bf9a30705dfc764718c817f16b1
The main files of interest are:
https:/
This code fails on 32 bit Linux / FreeBSD.
It is very dangerous bug.
Please pay attention to it!
```
unittest {
double a, b;
a = -5.50533e+307;
b = 4.49423e+307;
writefln("a = %a, b = %a, (a+b)/2.0 = %a", a, b, (a+b)/2.0);
assert((a+b)/2.0 > a);
}
```
issue: https://is
On Sunday, 3 November 2013 at 01:45:23 UTC, Timothee Cour wrote:
1)
The main issue I see with pegged is PEG grammars don't support
left
recursion, so for example will fail on foo[1].bar(2).fun().
Unless there's a plan to accomodate those, I sense a dead end.
One can eliminate left recursion but
On Saturday, 14 November 2015 at 23:20:08 UTC, Andrei
Alexandrescu wrote:
On 11/14/15 5:49 PM, Timon Gehr wrote:
It's supposed to guarantee that the given reference is not
used to
transitively mutate the object. The casts violate this.
I think that semantics needs to change. Specifically, eit
Hi everyone,
Just looked at the vision for this half, and I had an idea pop in
my head. Before I get to that idea, let me explain what I think
might be an issue with it as-is.
I've consistently seen D's participation metrics marked by the
number of pull requests created and closed, which is
On Saturday, 14 November 2015 at 16:05:10 UTC, Andrei
Alexandrescu wrote:
Technically, that clearly works. There's a problem with scaling
it up:
COMPOSITION
Disallowing immutable(RC!T) in favor of RC!(immutable T)
effectively disables composition of larger immutable objects
from smaller ones
On Saturday, 14 November 2015 at 14:56:57 UTC, maik klein wrote:
http://dlang.org/phobos/std_experimental_allocator.html
I am not sure what the plan is but it seems to me that the
standard library could make use of the "theAllocator" for
allocation and also allow you to swap in different alloc
On 09/11/15 04:38, Richard Davies wrote:
On Friday, 18 September 2015 at 03:19:26 UTC, Nick B wrote:
On Thursday, 17 September 2015 at 23:53:30 UTC, Anthony Di Franco wrote:
I read the whole book and did not regret it at all, but I was already
looking for good interval arithmetic implementati
David Nadlinger writes:
> On Friday, 13 November 2015 at 18:40:06 UTC, Iain Buclaw wrote:
>> There may be a few other holes between how Fibers and EH interact.
>>
>> https://github.com/D-Programming-Language/druntime/commit/f6633abb43ea1f2464d3a772b8f8fe78216ffd8e
>
> The SJLJ stack switching sho
On Saturday, 14 November 2015 at 13:46:32 UTC, Russel Winder
wrote:
On Sat, 2015-11-14 at 10:47 +1000, Manu via Digitalmars-d wrote:
[…]
I'd love to read a revised edition of that page! :)
So write it, and do the pull request. It doesn't matter if it
is any good or not, what matters is activi
On Saturday, 14 November 2015 at 03:40:08 UTC, Walter Bright
wrote:
The current state can be found here:
https://www.youtube.com/watch?v=IkwaV6k6BmM
slides:
http://www.walterbright.com/cppint.pdf
If someone would care to turn that into a pull request for
http://dlang.org/cpp_interface.
59 matches
Mail list logo
