I did it again, pressed answer instead of answer to Newsgroup...
От: David
Отправлено: 11 декабря 2012 г. 18:43
Кому: evilrat
Тема: Re: Awesomium D wrappers/bindings
Wow! I was thinking of doing that. I made CEF instead...
https://github.com/Dav1dde/cef
So Awesomium supports Linux? I
On Tuesday, 11 December 2012 at 15:28:08 UTC, Moritz Maxeiner
wrote:
One more thing: It's been asked before in this thread, but I
haven't seen a reply by Walter yet: Is it viable to add the
option of using the VC linker for 32bit, e.g. as something like
-linkvc. And I don't mean to remove
11.12.2012 3:01, Walter Bright пишет:
On 12/10/2012 8:28 AM, Denis Shelomovskij wrote:
This was the result of DustMite-ing my sources:
http://d.puremagic.com/issues/show_bug.cgi?id=6296
Currently the bug state is a bit confusing. It is a regression (but I
didn't
mark it that way, only write in
On 12/11/2012 12:08 AM, Denis Shelomovskij wrote:
How can I suppress DMD abnormal program termination pop-up when launched with
dmd ... 21?
DustMite's code:
https://github.com/CyberShadow/DustMite/wiki/Suppressing-DMD-crashes
fails in this call: FindWindowExA(h, null, Button, OK);
dmd never
11.12.2012 12:25, Walter Bright пишет:
On 12/11/2012 12:08 AM, Denis Shelomovskij wrote:
How can I suppress DMD abnormal program termination pop-up when
launched with
dmd ... 21?
DustMite's code:
https://github.com/CyberShadow/DustMite/wiki/Suppressing-DMD-crashes
fails in this call:
On 2012-12-10 23:15, Walter Bright wrote:
The syntax will be:
@(attributes)
and:
@identifier
although the latter isn't implemented yet.
Pull 1395.
struct Foo1 {}
@Foo int x1;
struct Foo2 (string bar) {}
@Foo!asd int x2;
@Foo!(asd) int x22;
struct Foo3 (string bar) { int a; }
On 2012-12-11 00:19, Max Samukha wrote:
Probably it should. Single parametrized attributes (in the form of
templates or CTFE constructors) are very likely to occur as often (if
not more often) as parameterless (as they do in C#, for example).
I've just made a pull request, see:
Am 11.12.2012 09:25, schrieb Walter Bright:
On 12/11/2012 12:08 AM, Denis Shelomovskij wrote:
How can I suppress DMD abnormal program termination pop-up when launched with
dmd ... 21?
DustMite's code:
https://github.com/CyberShadow/DustMite/wiki/Suppressing-DMD-crashes
fails in this call:
On 12/11/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
P.S. And also, http://wiki.dlang.org/Pull_Requests
I never needed to use pull --ff-only, all I do to rebase is git
pull --rebase upstream master, it never messed with my history as far
as I'm aware.
On Tuesday, 11 December 2012 at 09:10:30 UTC, Jacob Carlborg
wrote:
On 2012-12-11 00:19, Max Samukha wrote:
Probably it should. Single parametrized attributes (in the
form of
templates or CTFE constructors) are very likely to occur as
often (if
not more often) as parameterless (as they do in
On Tuesday, 11 December 2012 at 00:04:57 UTC, Alex Rønne Petersen
wrote:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
Destroy.
Instead of changing slices, shouldn't all pointers be modified if
you want to do this kind of things (a pointer would have two
On Tuesday, 11 December 2012 at 00:32:23 UTC, H. S. Teoh wrote:
P.S. And also, http://wiki.dlang.org/Pull_Requests and
http://wiki.dlang.org/Building_DMD, which needs some
Windows-specific
instructions.
T
I got some windows instructions done quick and dirty. The page
still needs some
On Friday, December 07, 2012 15:23:36 monarch_dodra wrote:
In particular, when compiling -unittest std\algorithm.d, dmd
uses *nearly* 1 GB (it uses about 1,051,176K on my machine).
Problem is that when it reaches 1GB, it crashes. I have a pull
request which adds a few unittests to algorithm,
Am 11.12.2012 03:02, schrieb Andrei Alexandrescu:
On 12/10/12 7:19 PM, H. S. Teoh wrote:
Sounds OK to me, though it seems unnecessarily complicated.
FWIW there's also this:
http://drewfradette.ca/a-simpler-successful-git-branching-model/
Andrei
Just throwing this in:
Greetings
The following code prints . Similar thing happens when a and b are
bytes.
Is this intended?
Regards
- Puneet
void main()
{
import std.stdio;
ushort a = 0x55AA;
ushort b = 0xAA55;
writefln(%X, ~(a | b));
}
For some more clarity, when I compile the following code:
void main() {
import std.stdio;
byte a;
byte b;
byte c = a + b;
}
I get error:
test.d(6): Error: cannot implicitly convert expression (cast(int)a +
cast(int)b) of type int to byte
Why is D trying to convert bytes and shorts to
On Tuesday, 11 December 2012 at 07:19:07 UTC, monarch_dodra wrote:
Here is a example of using COW for a simple object that wraps
nothing more than an int:
[snip]
This means you only pay for the copy when you *actually* need
it.
Drawbaks from this approach include:
1. Needs actual code.
2.
On Tuesday, 11 December 2012 at 12:24:14 UTC, d coder wrote:
Greetings
The following code prints . Similar thing happens when
a and b are
bytes.
Is this intended?
Regards
- Puneet
void main()
{
import std.stdio;
ushort a = 0x55AA;
ushort b = 0xAA55;
writefln(%X, ~(a | b));
}
On Tuesday, 11 December 2012 at 12:30:35 UTC, d coder wrote:
For some more clarity, when I compile the following code:
void main() {
import std.stdio;
byte a;
byte b;
byte c = a + b;
}
I get error:
test.d(6): Error: cannot implicitly convert expression
(cast(int)a +
cast(int)b) of
On Tue, Dec 11, 2012 at 6:23 PM, monarch_dodra monarchdo...@gmail.comwrote:
D's stance regarding integer operations is if it compiles, it creates the
same output as in C.
Thanks Monarch. So it is a gotcha we inherit from C. :-)
Regards
- Puneet
On 12/11/12 2:19 AM, monarch_dodra wrote:
On Tuesday, 11 December 2012 at 03:09:53 UTC, Dan wrote:
On Tuesday, 11 December 2012 at 01:47:38 UTC, Walter Bright wrote:
On 12/10/2012 10:40 AM, Dan wrote:
For something as simple as this would you introduce COW?
Yes.
Any D examples showing the
On 12/11/12 8:03 AM, d coder wrote:
On Tue, Dec 11, 2012 at 6:23 PM, monarch_dodra monarchdo...@gmail.com
mailto:monarchdo...@gmail.com wrote:
D's stance regarding integer operations is if it compiles, it
creates the same output as in C.
Thanks Monarch. So it is a gotcha we inherit
On Tuesday, 11 December 2012 at 02:02:54 UTC, Andrei Alexandrescu
wrote:
On 12/10/12 7:19 PM, H. S. Teoh wrote:
Sounds OK to me, though it seems unnecessarily complicated.
FWIW there's also this:
http://drewfradette.ca/a-simpler-successful-git-branching-model/
Andrei
First of all - Yay!
On Tuesday, 11 December 2012 at 11:36:16 UTC, Andrej Mitrovic
wrote:
Note that these can no longer be used on win32 because the
entire
There's a version on my github that works on dmd 2.060
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
The newer version
On Tuesday, 11 December 2012 at 12:52:03 UTC, Dan wrote:
For me it did not compile (No constructor for payload), maybe
you had a ctor for Payload? I think opAssign is not necessary -
if I remove it it still seems to work since default opAssign
calls postblit. I added the ctor, removed
On 10 December 2012 00:33, Walter Bright newshou...@digitalmars.com wrote:
It's time to do a release; to that end we should be working on tidying up
the regressions.
This will be the last official D1 release.
I foresee that this release will be the biggest pain in the ass to
merge downstream
On Tuesday, 11 December 2012 at 13:24:59 UTC, d coder wrote:
But it does not look clean if you have to write:
byte a, b, c;
a = cast(byte) (b + c);
That's the whole point. What you are doing is dangerous, so it
requires the cast.
Adding a compiler flag to change the semantics of the
On Tuesday, 11 December 2012 at 13:22:42 UTC, monarch_dodra wrote:
Anyways, opAssign is *definitely* necessary. Without it,
assignment would be equivalent to aliasing, and you wouldn't
have actual COW (both instances would end up modified). What's
more, if the current object had a handle on
On Tuesday, 11 December 2012 at 13:39:22 UTC, Dan wrote:
Can you confirm this with an example? Again, I think default
opAssign calls postblit. postblit increments. In this example
everything looks fine without opAssign (except for the bug you
point out regarding S()).
On Tue, Dec 11, 2012 at 7:05 PM, Peter Alexander
peter.alexander...@gmail.com wrote:
That's the whole point. What you are doing is dangerous, so it requires
the cast.
What I am doing is not dangerous. I am operating at byte/short level.
Tell me, if what I am doing is dangerous, how come
On 12/11/12, Adam D. Ruppe destructiona...@gmail.com wrote:
There's a version on my github that works on dmd 2.060
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
Cool! Thanks.
d coder:
Tell me, if what I am doing is dangerous, how come doing the
following is not dangerous. It is allowed by D.
int a, b, c;
a = b + c;
I think this dis-uniformity was added because:
- Statistically it's more common to have an overflow when you sum
two bytes compared to summing two
On Tuesday, 11 December 2012 at 13:01:44 UTC, Andrei Alexandrescu
wrote:
Walter and I discussed that it should be possible to automate
the dupIfNeeded() (I call it ensureUnique()) calls like this:
* If a method is const or immutable, leave as is
* For all other methods, insert a ensureUnique()
On Tuesday, 11 December 2012 at 13:24:59 UTC, d coder wrote:
No, it's a fix of a gotcha from C. The C code would just allow
the
assignment.
Yes Andrei.
But it does not look clean if you have to write:
byte a, b, c;
a = cast(byte) (b + c);
Well I know the advantages (safety). But imagine
Hello,
The previous thread, about the int resulting from operations on
bytes, rised me a question, that is somewhat linked to a
difference between Pascal/Delphi/FPC (please, no flame here) and
C/D.
Basically, as far as i get it, both FPC and C use Integer (name
it int, if you like), as a
Now, the off-topic question: the loss in unsigned-range aside
(that I find it to be a small price for the earned clarity), is
that any other reason (except C-compatibility) that D would not
implement that model (this is not a suggestion to do it now, I
know D is almost ready for prime-time,
On 12/11/12 8:24 AM, d coder wrote:
No, it's a fix of a gotcha from C. The C code would just allow the
assignment.
Yes Andrei.
But it does not look clean if you have to write:
byte a, b, c;
a = cast(byte) (b + c);
Well I know the advantages (safety). But imagine having to write all
On 12/11/12 9:37 AM, Dan wrote:
On Tuesday, 11 December 2012 at 13:01:44 UTC, Andrei Alexandrescu wrote:
Walter and I discussed that it should be possible to automate the
dupIfNeeded() (I call it ensureUnique()) calls like this:
* If a method is const or immutable, leave as is
* For all other
On 12/11/12 10:20 AM, eles wrote:
Hello,
The previous thread, about the int resulting from operations on bytes,
rised me a question, that is somewhat linked to a difference between
Pascal/Delphi/FPC (please, no flame here) and C/D.
[snip]
There's a lot to be discussed on the issue. A few
There's a lot to be discussed on the issue. A few quick
thoughts:
* 32-bit integers are a sweet spot for CPU architectures.
There's rarely a provision for 16- or 8-bit operations; the
action is at 32- or 64-bit.
Speed can be still optimized by the compiler, behind the scenes.
The approach
Thanks Everybody for responding. I have another query which is off-topic
but related.
Why is the following allowed in D?
long a;
int b;
b += a; // Allowed -- no explicit cast
b = a + b; // Not allowed
b = a; // Not allowed
On 12/11/12 11:29 AM, eles wrote:
There's a lot to be discussed on the issue. A few quick thoughts:
* 32-bit integers are a sweet spot for CPU architectures. There's
rarely a provision for 16- or 8-bit operations; the action is at 32-
or 64-bit.
Speed can be still optimized by the compiler,
d coder:
Why is the following allowed in D?
long a;
int b;
b += a; // Allowed -- no explicit cast
b = a + b; // Not allowed
b = a; // Not allowed
Seems a bug of range analysis.
Bye,
bearophile
On 12/11/12 11:36 AM, d coder wrote:
Thanks Everybody for responding. I have another query which is off-topic
but related.
Why is the following allowed in D?
long a;
int b;
b += a; // Allowed -- no explicit cast
RMW operations are allowed without a cast.
Andrei
On 11-12-2012 11:36, renoX wrote:
On Tuesday, 11 December 2012 at 00:04:57 UTC, Alex Rønne Petersen wrote:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
Destroy.
Instead of changing slices, shouldn't all pointers be modified if you
want to do this kind of
On 11-12-2012 08:29, Rainer Schuetze wrote:
On 11.12.2012 01:04, Alex Rønne Petersen wrote:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
Destroy.
I don't think there is a noticeable difference in detecting whether a
pointer is pointing to the beginning of
On 12/11/2012 5:37 AM, Iain Buclaw wrote:
I foresee that this release will be the biggest pain in the ass to
merge downstream into GDC. I wonder if David on LDC's side shares the
same concern...
Why?
On 12/11/2012 5:24 AM, d coder wrote:
Would I be asking for too much if I ask DMD to provide a compiler
flag that makes it return bytes and shorts for operations on them? So the deal
would be, if you use this compiler flag, code behavior would be different from
that of C/C++.
Having compiler
On Tue, Dec 11, 2012 at 11:35:39AM -0500, Andrei Alexandrescu wrote:
On 12/11/12 11:29 AM, eles wrote:
There's a lot to be discussed on the issue. A few quick thoughts:
* 32-bit integers are a sweet spot for CPU architectures. There's
rarely a provision for 16- or 8-bit operations; the
On Tue, 11 Dec 2012 11:25:44 -0600, Alex Rønne Petersen a...@lycus.org
wrote:
On 11-12-2012 08:29, Rainer Schuetze wrote:
On 11.12.2012 01:04, Alex Rønne Petersen wrote:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
Destroy.
Done.
[snip]
From what I could
On Tue, 11 Dec 2012 09:47:33 -0800
Walter Bright newshou...@digitalmars.com wrote:
On 12/11/2012 5:24 AM, d coder wrote:
Would I be asking for too much if I ask DMD to provide a compiler
flag that makes it return bytes and shorts for operations on them?
So the deal would be, if you use
On 12/11/2012 8:22 AM, Andrei Alexandrescu wrote:
* 32-bit integers are a sweet spot for CPU architectures. There's rarely a
provision for 16- or 8-bit operations; the action is at 32- or 64-bit.
Requiring integer operations to all be 64 bits would be a heavy burden on 32 bit
CPUs.
On 12/11/2012 8:35 AM, Andrei Alexandrescu wrote:
Besides, at the end of the day, a half-approach would be to have a
widest-signed-integral and a widest-unsigned-integral type and only play
with those two.
Why stop at 64 bits? Why not make there only be one integral type, and it is of
Why stop at 64 bits? Why not make there only be one integral
type, and it is of whatever precision is necessary to hold the
value? This is quite doable, and has been done.
You really miss the point here. Nobody will ask you to promote
those numbers to 64-bit or whatever *unless necessary*. It
On Tuesday, 11 December 2012 at 16:35:39 UTC, Andrei Alexandrescu
wrote:
On 12/11/12 11:29 AM, eles wrote:
There's a lot to be discussed on the issue. A few quick
thoughts:
* 32-bit integers are a sweet spot for CPU architectures.
There's
rarely a provision for 16- or 8-bit operations; the
Walter Bright:
Why stop at 64 bits? Why not make there only be one integral
type, and it is of whatever precision is necessary to hold the
value? This is quite doable, and has been done.
I think no one has asked for *bignums on default* in this thread.
But at a terrible performance cost.
On 11-12-2012 19:11, Robert Jacques wrote:
On Tue, 11 Dec 2012 11:25:44 -0600, Alex Rønne Petersen a...@lycus.org
wrote:
On 11-12-2012 08:29, Rainer Schuetze wrote:
On 11.12.2012 01:04, Alex Rønne Petersen wrote:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
Besides, at the end of the day, a half-approach would be to
have a widest-signed-integral and a widest-unsigned-integral
type and only play with those two.
Clarification: to have those two types as fundamental (ie:
promotion-favourite) types, not the sole types in the language.
12/11/2012 4:04 AM, Alex Rønne Petersen пишет:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
Destroy.
Aside from the fact that I can use slices without GC just fine? :)
The base pointers would then be either counted, released manually or
implicitly as part
On 11-12-2012 20:09, Dmitry Olshansky wrote:
12/11/2012 4:04 AM, Alex Rønne Petersen пишет:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
Destroy.
Aside from the fact that I can use slices without GC just fine? :)
The base pointers would then be either
On Tuesday, 11 December 2012 at 16:09:14 UTC, Andrei Alexandrescu
wrote:
On 12/11/12 8:24 AM, d coder wrote:
No, it's a fix of a gotcha from C. The C code would just
allow the
assignment.
Yes Andrei.
But it does not look clean if you have to write:
byte a, b, c;
a = cast(byte) (b +
On Tuesday, 11 December 2012 at 13:19:56 UTC, foobar wrote:
First of all - Yay!
There are still a few open questions that need to be decided
before a suitable process can be defined.
I'd say we should _at most_
support _one_ previous stable version with critical bug fixes
only.
I agree with
On Tuesday, 11 December 2012 at 04:30:38 UTC, evansl wrote:
On 12/10/12 06:45, Walter Bright wrote:
On 12/7/2012 2:51 PM, deadalnix wrote:
I'm working on a program that now require more than 2.5Gb of
RAM to
compile,
where separate compilation is not possible due to bug 8997
and that
On Mon, Dec 10, 2012 at 04:54:43PM -0500, Nick Sabalausky wrote:
On Mon, 10 Dec 2012 12:57:43 -0800
H. S. Teoh hst...@quickfur.ath.cx wrote:
[...]
Heh. I used to browse with no JS. But due to the annoying bandwagon
jumping trend that is a common pathology in people involved with
computers,
12/11/2012 11:23 PM, Alex Rønne Petersen пишет:
On 11-12-2012 20:09, Dmitry Olshansky wrote:
12/11/2012 4:04 AM, Alex Rønne Petersen пишет:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
Destroy.
Aside from the fact that I can use slices without GC just
On 11.12.2012 18:25, Alex Rønne Petersen wrote:
On 11-12-2012 08:29, Rainer Schuetze wrote:
On 11.12.2012 01:04, Alex Rønne Petersen wrote:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
This is clearly a huge problem for type-precise garbage collection.
On Monday, 10 December 2012 at 22:33:49 UTC, 1100110 wrote:
On 12/10/2012 05:16 AM, Mr. Anonymous wrote:
On Monday, 10 December 2012 at 02:10:43 UTC, Ellery Newcomer
wrote:
Is anyone else noticing e.g. std.datetime taking upwards of
30 seconds
to render the blob of links at the top? It's
On 11-12-2012 21:24, Dmitry Olshansky wrote:
12/11/2012 11:23 PM, Alex Rønne Petersen пишет:
On 11-12-2012 20:09, Dmitry Olshansky wrote:
12/11/2012 4:04 AM, Alex Rønne Petersen пишет:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
Destroy.
Aside from
On 11-12-2012 21:24, Rainer Schuetze wrote:
On 11.12.2012 18:25, Alex Rønne Petersen wrote:
On 11-12-2012 08:29, Rainer Schuetze wrote:
On 11.12.2012 01:04, Alex Rønne Petersen wrote:
http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
This is clearly a huge
On 12/11/12 3:54 PM, Rob T wrote:
On Monday, 10 December 2012 at 22:33:49 UTC, 1100110 wrote:
On 12/10/2012 05:16 AM, Mr. Anonymous wrote:
On Monday, 10 December 2012 at 02:10:43 UTC, Ellery Newcomer wrote:
Is anyone else noticing e.g. std.datetime taking upwards of 30 seconds
to render the
On 11.12.2012 22:08, Alex Rønne Petersen wrote:
On 11-12-2012 21:24, Rainer Schuetze wrote:
This stores the type info with the reference, not with the memory block,
but it does not make a big difference. (Actually it does: if the
reference only is a reference a base class of the actual
On Tuesday, 11 December 2012 at 21:13:25 UTC, Andrei Alexandrescu
wrote:
On 12/11/12 3:54 PM, Rob T wrote:
On Monday, 10 December 2012 at 22:33:49 UTC, 1100110 wrote:
On 12/10/2012 05:16 AM, Mr. Anonymous wrote:
On Monday, 10 December 2012 at 02:10:43 UTC, Ellery Newcomer
wrote:
Is anyone
On 12/11/2012 10:36 AM, eles wrote:
You really miss the point here. Nobody will ask you to promote those numbers to
64-bit or whatever *unless necessary*.
No, I don't miss the point. There are very few cases where the compiler could
statically prove that something will fit in less than 32
On 12/11/12 1:36 PM, eles wrote:
Until now the question received many backfights, but no answer.
A bit shameful.
I thought my answer wasn't all that shoddy and not defensive at all.
Andrei
On Tuesday, 11 December 2012 at 18:11:32 UTC, Robert Jacques
wrote:
On Tue, 11 Dec 2012 11:25:44 -0600, Alex Rønne Petersen wrote:
Interior pointers are OK in the stack and registers, so taking
pointers to fields inside aggregates should be fine so long as
they are not stored in the heap.
So
On 12/11/2012 10:45 AM, bearophile wrote:
Walter Bright:
Why stop at 64 bits? Why not make there only be one integral type, and it
is of whatever precision is necessary to hold the value? This is quite
doable, and has been done.
I think no one has asked for *bignums on default* in this
I thought my answer wasn't all that shoddy and not defensive at
all.
I step back. I agree. Thank you.
On 12/11/2012 10:44 AM, foobar wrote:
All of the above relies on the assumption that the safety problem is due to the
memory layout. There are many other programming languages that solve this by
using a different point of view - the problem lies in the implicit casts and not
the memory layout.
On 12/11/2012 10:12 AM, Nick Sabalausky wrote:
Let's not entertain any thoughts of allowing D to venture down that
path.
No worries there :-) I feel pretty dang strongly about this issue, from bad
experience.
Even if a language behaves wrong, it is still usable if it is predictable.
On 12/7/2012 6:23 AM, monarch_dodra wrote:
Also, I'm no expert, but why is my dmd limited to 1 GB memory on my 64 bit
machine...?
The latest beta I uploaded increases the limit to 2 GB (thanks to a patch by
Rainer Schuetze).
On 11 December 2012 17:44, Walter Bright newshou...@digitalmars.com wrote:
On 12/11/2012 5:37 AM, Iain Buclaw wrote:
I foresee that this release will be the biggest pain in the ass to
merge downstream into GDC. I wonder if David on LDC's side shares the
same concern...
Why?
If the last
On 12/11/12 5:07 PM, eles wrote:
I thought my answer wasn't all that shoddy and not defensive at all.
I step back. I agree. Thank you.
Somebody convinced somebody else of something on the Net. This has good
day written all over it. Time to open that champagne. Cheers!
Andrei
On Tuesday, 11 December 2012 at 14:02:52 UTC, d coder wrote:
On Tue, Dec 11, 2012 at 7:05 PM, Peter Alexander
peter.alexander...@gmail.com wrote:
That's the whole point. What you are doing is dangerous, so it
requires
the cast.
What I am doing is not dangerous. I am operating at
On Tuesday, 11 December 2012 at 21:57:38 UTC, Walter Bright wrote:
On 12/11/2012 10:45 AM, bearophile wrote:
Walter Bright:
Why stop at 64 bits? Why not make there only be one integral
type, and it
is of whatever precision is necessary to hold the value? This
is quite
doable, and has been
On Tuesday, 11 December 2012 at 19:57:55 UTC, Rob T wrote:
On Tuesday, 11 December 2012 at 13:19:56 UTC, foobar wrote:
First of all - Yay!
There are still a few open questions that need to be decided
before a suitable process can be defined.
I'd say we should _at most_
support _one_ previous
Somebody convinced somebody else of something on the Net.
About the non-defensiveness. As for the int's, I tend to consider
that the matter is controversial, but the balance is more
equilibrated than it seems (between drawbacks and advantages) of
either choice.
On Tuesday, 11 December 2012 at 22:08:15 UTC, Walter Bright wrote:
On 12/11/2012 10:44 AM, foobar wrote:
All of the above relies on the assumption that the safety
problem is due to the
memory layout. There are many other programming languages that
solve this by
using a different point of view
Walter Bright:
I don't notice anyone reaching for Lisp or Ocaml for high
performance applications.
Nowadays CommonLisp is not used much for anything (people at ITA
use it to plan flights, their code is efficient, algorithmically
complex, and used for heavy loads).
OCaML on the other hand
foobar:
I would enforce overflow and underflow checking semantics.
Plus one or two switches to disable such checking, if/when
someone wants it, to regain the C performance. (Plus some syntax
way to disable/enable such checking in a small piece of code).
Maybe someday Walter will change
On Wednesday, 12 December 2012 at 00:06:53 UTC, bearophile wrote:
foobar:
I would enforce overflow and underflow checking semantics.
Plus one or two switches to disable such checking, if/when
someone wants it, to regain the C performance. (Plus some
syntax way to disable/enable such
On 12/11/2012 3:15 PM, deadalnix wrote:
That's irrelevant to this discussion. It is not a problem with the language.
Anyone can improve the library one if they desire, or do their own.
The library is part of the language. What is a language with no vocabulary ?
I think it is useful to draw a
On Wed, Dec 12, 2012 at 01:26:08AM +0100, foobar wrote:
On Wednesday, 12 December 2012 at 00:06:53 UTC, bearophile wrote:
foobar:
I would enforce overflow and underflow checking semantics.
Plus one or two switches to disable such checking, if/when someone
wants it, to regain the C
On 12/11/2012 3:44 PM, foobar wrote:
Thanks for proving my point. after all , you are a C++ developer, aren't you? :)
No, I'm an assembler programmer. I know how the machine works, and C, C++, and D
map onto that, quite deliberately. It's one reason why D supports the vector
types directly.
On 12/11/2012 4:06 PM, bearophile wrote:
Plus one or two switches to disable such checking, if/when someone wants it, to
regain the C performance. (Plus some syntax way to disable/enable such checking
in a small piece of code).
I.e. the C# solution.
1. The global switch solution: What I hate
On Tuesday, 11 December 2012 at 23:15:27 UTC, foobar wrote:
By support I meant specifically _bug fixes_. You can already
download all previous released versions from the website and in
no way am I arguing to change that policy.
Even if we ever get to a point where we don't want to keep
older
Walter Bright:
ML has been around for 30-40 years, and has failed to catch on.
OcaML, Haskell, F#, and so on are all languages derived more or
less directly from ML, that share many of its ideas. Has Haskell
caught on? :-)
Bye,
bearophile
H. S. Teoh:
Just because you specify a certain compiler switch, it can cause
unrelated breakage in some obscure library somewhere, that
assumes modular arithmetic with C/C++ semantics.
The idea was about two switches, one for signed integrals, and
the other for both signed and unsigned. But
On Monday, 10 December 2012 at 00:47:09 UTC, Andrei Alexandrescu
wrote:
It's official - http://wiki.dlang.org is our new wiki home.
Would anybody mind if I move the official LDC installation
instructions there? We currently have a few pages at the GitHub
wiki for this, but are not really
On Wed, Dec 12, 2012 at 02:03:56AM +0100, Rob T wrote:
[...]
OK, but who has already tested it and how many people have been able
to test it and comment on it? I was thinking more along the lines of
how Debian does it, with a 4 staged release process: experimental =
unstable = testing
On Tuesday, 11 December 2012 at 03:28:00 UTC, d coder wrote:
Greetings
I too find this very useful. I am also having this situation
often when
there is an array of nested struct instances inside a class
environment.
This is a common scenario and deserves attention. Also I
believe (looking
at
1 - 100 of 173 matches
Mail list logo
