On Friday, 17 October 2014 at 05:38:05 UTC, thedeemon wrote:
Gentlemen, do I understand correctly that you're trying to find
a Windows-friendly switch to something that will never see the
light on Windows (because of being based on fork)?
No we want general runtime configuration, not only for
On Fri, 17 Oct 2014 00:01:39 +0100, Leandro Lucarella l...@llucax.com.ar
wrote:
Regan Heath, el 14 de October a las 11:11 me escribiste:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
As mentioned this is not a very
New backend why ?
Regan Heath, el 17 de October a las 10:55 me escribiste:
Regan Heath, el 14 de October a las 11:11 me escribiste:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
As mentioned this is not a very windows friendly/like
Marginally related: Page fault handling in user space.
http://lwn.net/Articles/615086/
Maybe this can be used as an alternative to forking.
On Thursday, 16 October 2014 at 23:32:22 UTC, Alexander Bothe
wrote:
Hi everyone,
just gave the second drop down box in Xamarin Studio a use:
Selection of build types for dub projects.
Furthermore, please don't rage silently somewhere - tell me
about issues with Mono-D on github or in
On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote:
More APIs could be implemented if the interest happens to be
non-null.
Interest non-null, this is awesome.
On Thursday, 16 October 2014 at 23:32:22 UTC, Alexander Bothe
wrote:
Cheers thanks to everyone,
Alex
What a hardwork are you doing, Alex! Kudos!
On 10/17/14, 7:58 AM, Tofu Ninja wrote:
On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote:
More APIs could be implemented if the interest happens to be non-null.
Interest non-null, this is awesome.
Let it ride!
Regan Heath, el 17 de October a las 15:43 me escribiste:
You've got it backwards. I'm looking for a *better* solution than
environment variables, which are a truly horrid way to control
runtime behaviour IMHO.
OK, then this is now a holly war. So I'll drop it here.
I think you've mistook
On 10/17/14, Leandro Lucarella via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
In all the years I've been working in Linux I never, EVER came across
problems with environment variables being accidentally set. I find it
very hard to believe this is a real problem. On the
On Friday, 17 October 2014 at 10:39:15 UTC, Temtaime wrote:
New backend why ?
Because I want to code a backend.
I want output C or maybe even Cool ...
generating UML via a backend would also be nice.
Hi all,
I'd like to announce the initial version of endovena, a
dependency injection
framework.
It's based on dejector, a great work by Jakub Stasiak, with some
new features borrowed from dryioc (C# IoC)
I would be glad to see any feedback,
Thank you.
* [endovena]
Any help?
On 16 Oct 2014 23:01, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thu, 16 Oct 2014 21:53:40 +
Chris via Digitalmars-d digitalmars-d@puremagic.com wrote:
I had planned to use GDC/LDC too, but GDC is 2.064
GDC is 2.065.
And soon to be 2.066 as soon as I apply the
Sorry, everything turned out simply, I'm very inattentive ...
No, right now one can affect the way tests are run by simply
replacing the runner to a custom one and it will work for any
amount of modules compiled in. Beauty of `unittest` block
approach is that it is simply a bunch of functions that are
somewhat easy to discover from the combined sources
On Thursday, 16 October 2014 at 21:00:18 UTC, bearophile wrote:
Just found with Reddit. C seems one step ahead of D with this:
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
Bye,
bearophile
The sad thing about this tools is that they are all about fixing
On Thursday, 16 October 2014 at 22:01:37 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 16 Oct 2014 21:53:40 +
Chris via Digitalmars-d digitalmars-d@puremagic.com wrote:
I had planned to use GDC/LDC too, but GDC is 2.064
GDC is 2.065.
But why does it say 2.064 here
On Friday, 17 October 2014 at 07:02:53 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 16 Oct 2014 23:01, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thu, 16 Oct 2014 21:53:40 +
Chris via Digitalmars-d digitalmars-d@puremagic.com wrote:
I had planned to use GDC/LDC too,
On 17 October 2014 09:53, Chris via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 16 October 2014 at 22:01:37 UTC, ketmar via Digitalmars-d
wrote:
On Thu, 16 Oct 2014 21:53:40 +
Chris via Digitalmars-d digitalmars-d@puremagic.com wrote:
I had planned to use GDC/LDC too,
When I read that error I wondered why anyone would define a
function for threads with the same name as a well established
C function. On a closer look it revealed to be just another
name for the same extern(C) memcpy to avoid the import of
core.stdc.string in core.thread:
private
{
import
I saw [this][0] proposal for adding ranges to C++'s standard
library. The [paper][1] looks at D style ranges, but concludes:
Since iterators can implement D ranges, but D ranges cannot be
used to implement iterators, we conclude that iterators form a
more powerful and foundational basis.
Am Fri, 17 Oct 2014 08:38:11 +
schrieb Paulo Pinto pj...@progtools.org:
On Thursday, 16 October 2014 at 21:00:18 UTC, bearophile wrote:
Just found with Reddit. C seems one step ahead of D with this:
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
On Thursday, 16 October 2014 at 05:45:00 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 16 October 2014 at 03:53:53 UTC, Daniel N wrote:
There's no impact, we already support it since the template is
instantiated from C++ side.
But you don't know the return type of the templated function
until
On Friday, 17 October 2014 at 09:15:37 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 17 October 2014 09:53, Chris via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 16 October 2014 at 22:01:37 UTC, ketmar via
Digitalmars-d
wrote:
On Thu, 16 Oct 2014 21:53:40 +
Chris via
On Friday, 17 October 2014 at 08:38:12 UTC, Paulo Pinto wrote:
As an outsider, I think D would be better by having only
defined behaviors.
Actually, this is the first thing I would change about D and make
it less dependent on x86. I think a system level language should
enable max
On 16 October 2014 22:00, bearophile via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Just found with Reddit. C seems one step ahead of D with this:
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
*cough* GDC *cough* :o)
Am Fri, 17 Oct 2014 09:17:51 +
schrieb ZombineDev valid_em...@he.re:
I saw [this][0] proposal for adding ranges to C++'s standard
library. The [paper][1] looks at D style ranges, but concludes:
Since iterators can implement D ranges, but D ranges cannot be
used to implement
On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote:
Am Fri, 17 Oct 2014 09:17:51 +
schrieb ZombineDev valid_em...@he.re:
I saw [this][0] proposal for adding ranges to C++'s standard
library. The [paper][1] looks at D style ranges, but concludes:
Since iterators can implement D
On Friday, 17 October 2014 at 10:10:23 UTC, Olivier Grant wrote:
On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote:
Am Fri, 17 Oct 2014 09:17:51 +
schrieb ZombineDev valid_em...@he.re:
No, the equivalent implementation in C++ is this:
double mittelwert_accumulate(const
On Friday, 17 October 2014 at 09:46:49 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 17 October 2014 at 08:38:12 UTC, Paulo Pinto wrote:
The second thing I would change is to make whole program
analysis mandatory so that you can deduce and constrain value
ranges.
Nice idea, but how to
On Friday, 17 October 2014 at 10:30:14 UTC, eles wrote:
On Friday, 17 October 2014 at 09:46:49 UTC, Ola Fosheim Grøstad
wrote:
The second thing I would change is to make whole program
analysis mandatory so that you can deduce and constrain value
ranges.
Nice idea, but how to persuade
On Thursday, 16 October 2014 at 21:00:18 UTC, bearophile wrote:
Just found with Reddit. C seems one step ahead of D with this:
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
Bye,
bearophile
Not every software bug has as serious consequences as seen in
the
LDC is 2.065
Already 2.066 in the repo.
On Friday, 17 October 2014 at 09:39:27 UTC, Daniel N wrote:
On Thursday, 16 October 2014 at 05:45:00 UTC, Ola Fosheim
Grøstad wrote:
But you don't know the return type of the templated function
until you know which combination of templates it instantiated?
Yes, but this is true already today
On Friday, 17 October 2014 at 10:17:38 UTC, eles wrote:
double mittelwert_accumulate(const vectordouble vektor)
{
return accumulate(vektor.begin(), vektor.end(), 0.0) /
vektor.size();
}
templatetypename T
auto mittelwert_accumulate(const T vektor){
return accumulate(cbegin(vektor),
Am Fri, 17 Oct 2014 00:42:24 +
schrieb IgorStepanov wa...@mail.ru:
OK, I've run into the same problem and there is no line
number, just:
Error: immutable method Lib.Sys.File.File.~this is not callable using a mutable
object
Error: mutable method Lib.Sys.File.File.~this is not callable using
On Fri, 17 Oct 2014 08:00:03 +0200
Marco Leise via Digitalmars-d digitalmars-d@puremagic.com wrote:
ketmar gtfo ... oh wait, that's a great idea actually!
;-)
signature.asc
Description: PGP signature
On Friday, 17 October 2014 at 11:44:29 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 17 October 2014 at 10:17:38 UTC, eles wrote:
(not tested :^)
templatetypename T
auto mittelwert_accumulate2(const T vektor) -typename
T::value_type
{
return accumulate(vektor.cbegin(), vektor.cend(),
Am Fri, 17 Oct 2014 14:42:53 +0200
schrieb Marco Leise marco.le...@gmx.de:
Am Fri, 17 Oct 2014 00:42:24 +
schrieb IgorStepanov wa...@mail.ru:
OK, I've run into the same problem and there is no line
number, just:
Error: immutable method Lib.Sys.File.File.~this is not callable using a
On Fri, 17 Oct 2014 09:46:48 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
It is just plain wrong to let integers wrap by default in an
accessible result. That is not integer behaviour.
do you know any widespread hardware with doesn't work this way?
yet i know very widespread
On Fri, 17 Oct 2014 08:02:42 +0100
Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com wrote:
GDC is 2.065.
And soon to be 2.066 as soon as I apply the last 244 patches between
May and the final release date.
yay! you're my hero, do you know that? ;-)
signature.asc
Description: PGP
On Friday, 17 October 2014 at 13:27:37 UTC, eles wrote:
(gcc does not yet support std::cbegin() and std::cend()).
(tested :^)
Thanks ;)
Like your new version, but I don't think it will work with
regular arrays and maybe the accumulator will overflow if you sum
a large number of ubytes? I
On Friday, 17 October 2014 at 09:17:52 UTC, ZombineDev wrote:
I saw [this][0] proposal for adding ranges to C++'s standard
library. The [paper][1] looks at D style ranges, but concludes:
Since iterators can implement D ranges, but D ranges cannot be
used to implement iterators, we conclude
On Friday, 17 October 2014 at 00:55:25 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 00:42:24 +
IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Can someone comment this code? Should I think that it's a bug.
it's just an anomaly. const postblit can do alot of
On Friday, 17 October 2014 at 01:09:00 UTC, John McFarlane wrote:
On Friday, 3 January 2014 at 07:22:32 UTC, monarch_dodra wrote:
On Thursday, 2 January 2014 at 14:59:55 UTC, Adam D. Ruppe
wrote:
On Thursday, 2 January 2014 at 13:30:06 UTC, monarch_dodra
wrote:
Currently, this is not possible.
They are discussing about named arguments for C++:
http://www.reddit.com/r/cpp/comments/2jiai2/n4172_named_arguments/
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm
Bye,
bearophile
On Fri, 17 Oct 2014 14:18:30 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
To be honest, I think people use const way too much in D. It's
*not* the C++ head const you can use anywhere. It's really just
the base attribute between mutable and immutable data. In
On Friday, 17 October 2014 at 13:44:24 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 09:46:48 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
It is just plain wrong to let integers wrap by default in an
accessible result. That is not integer behaviour.
do you know any
On Friday, 17 October 2014 at 14:18:31 UTC, monarch_dodra wrote:
On Friday, 17 October 2014 at 00:55:25 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 00:42:24 +
IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Can someone comment this code? Should I think
On Friday, 17 October 2014 at 13:22:26 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 08:00:03 +0200
Marco Leise via Digitalmars-d digitalmars-d@puremagic.com
wrote:
ketmar gtfo ... oh wait, that's a great idea actually!
;-)
it is! ketmar ctfb
On 10/17/14, 2:17 AM, ZombineDev wrote:
I saw [this][0] proposal for adding ranges to C++'s standard
library. The [paper][1] looks at D style ranges, but concludes:
Since iterators can implement D ranges, but D ranges cannot be used to
implement iterators, we conclude that iterators form a
On Thursday, 16 October 2014 at 19:53:42 UTC, Walter Bright wrote:
On 10/15/2014 12:19 AM, Kagamin wrote:
Sure, software is one part of an airplane, like a thread is a
part of a process.
When the part fails, you discard it and continue operation. In
software it works
by rolling back a failed
On 10/17/14, 2:53 AM, Iain Buclaw via Digitalmars-d wrote:
On 16 October 2014 22:00, bearophile via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Just found with Reddit. C seems one step ahead of D with this:
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
On 10/17/14 10:13 AM, monarch_dodra wrote:
My personal feeling (IMO):
- Consuming, adapting, producing data: Ranges win hands down.
- Managing, shuffling or inserting elements in a container: To be
honest, I prefer iterators.
Dcollections solves this.
-Steve
On 10/17/14, 3:51 AM, eles wrote:
On Thursday, 16 October 2014 at 21:00:18 UTC, bearophile wrote:
Just found with Reddit. C seems one step ahead of D with this:
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
Bye,
bearophile
Not every software bug has as
On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote:
True. Iterators are more foundational, ranges are more
neat-o. ;)
Python is more accurate, succinct and generic :-)
Fraction(Fraction(sum(a)),len(a))
or
Fraction(sum([Fraction(n) for n in a]),len(a))
On Fri, 17 Oct 2014 14:38:29 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
It is just plain wrong to let integers wrap by default in an
accessible result. That is not integer behaviour.
do you know any widespread hardware with doesn't work this way?
Yes, the carry flag is
On Fri, 17 Oct 2014 08:08:34 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Do you mean ubsan will work with gdc? -- Andrei
as far as i can understand, ubsan is GCC feature. not GCC C compiler,
but GNU Compiler Collection. it works on IR representations, so GDC
On Fri, 17 Oct 2014 14:41:36 +
IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote:
What happends if we will ignore const/immutable modifier for
postblits? Is it create any holes?
it will break const promise. i.e. const/immutable data is not really
immutable now, it can be
On Friday, 17 October 2014 at 15:10:33 UTC, Andrei Alexandrescu
wrote:
On 10/17/14, 3:51 AM, eles wrote:
On Thursday, 16 October 2014 at 21:00:18 UTC, bearophile wrote:
Just found with Reddit. C seems one step ahead of D with this:
Still a step forward. -- Andrei
While I agree, IIRC,
Its a holdover from when we were trying to eliminate imports in
druntime because of the associated overhead. I'd submit a
bugzilla about it.
On 2014-10-17 07:24, Sergey wrote:
Or if I already have a byte string in cp1251 how to translate it into a
normal string?
Doesn't Sql Server uses UC2?
--
/Jacob Carlborg
On 2014-10-16 17:21, Dan Olson wrote:
Specifically here I mean LDC targeted to arm-ios. The linker complains
about the generated debug info and I end up stepping through D in arm
assembly.
Oh, right. I was mostly thinking about OS X applications.
--
/Jacob Carlborg
On Friday, 17 October 2014 at 15:17:12 UTC, ketmar via
Digitalmars-d wrote:
it's good. but this not justifies the decision to make 2's
complement
overflow undefined.
If you want a circular type, then call it something to that
effect. Not uint or int. Call it bits or wrapint.
yes. what's
On 17 October 2014 16:08, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 10/17/14, 2:53 AM, Iain Buclaw via Digitalmars-d wrote:
On 16 October 2014 22:00, bearophile via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Just found with Reddit. C seems one step
On 2014-10-16 21:35, Walter Bright wrote:
Ok, but why would 3rd party library unittests be a concern? They
shouldn't have shipped it if their own unittests fail - that's the whole
point of having unittests.
They will have asserts in contracts and other parts of that code that is
not unit
On 2014-10-17 10:26, Atila Neves wrote:
Is cleaning up in a unittest build a problem? I'd say no, if it the
tests fail it doesn't make much sense to clean up unless it affects the
reporting of tests failing.
I have used files in some of my unit tests. I would certainly like those
to be
On 2014-10-16 20:50, Walter Bright wrote:
I don't understand why unittests in druntime/phobos are an issue for
users. We don't release a DMD unless they all pass - it should be moot
for users.
There are asserts elsewhere in the code.
--
/Jacob Carlborg
On 2014-10-16 21:31, Walter Bright wrote:
Contract errors in Phobos/Druntime should be limited to having passed it
invalid arguments, which should be documented
That doesn't mean it won't happen.
--
/Jacob Carlborg
On Friday, 17 October 2014 at 15:20:50 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 14:41:36 +
IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com
wrote:
What happends if we will ignore const/immutable modifier for
postblits? Is it create any holes?
it will break const
On Fri, 17 Oct 2014 15:58:02 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Friday, 17 October 2014 at 15:17:12 UTC, ketmar via
Digitalmars-d wrote:
it's good. but this not justifies the decision to make 2's
complement
overflow undefined.
If you want a circular type,
On Friday, 17 October 2014 at 16:26:08 UTC, ketmar via
Digitalmars-d wrote:
i have nothing against this either. but i have alot against
integral with arbitrary size type.
Actually it makes a lot of sense to be able to reuse 16-bit
library code on a 24-bit ALU. Like for loading a sound at
Am 17.10.2014 um 17:14 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com:
On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote:
True. Iterators are more foundational, ranges are more
neat-o. ;)
Python is more accurate, succinct and generic :-)
On Friday, 17 October 2014 at 17:14:24 UTC, Paulo Pinto wrote:
And slrrr
Accurate is slower, but not this:
sum(a)/len(a)
On Fri, 17 Oct 2014 16:49:10 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
i have nothing against this either. but i have alot against
integral with arbitrary size type.
Actually it makes a lot of sense to be able to reuse 16-bit
library code on a 24-bit ALU. Like for
On Friday, 17 October 2014 at 16:19:47 UTC, IgorStepanov wrote:
It's just common words=)
I meant that when postblit is called when new object is being
creating and doesn't exists for user code.
E.g.
const S v1 = v2;
Ok, v1 _will_ be const when it will be _created_.
However postblit can think
On Fri, 17 Oct 2014 16:19:46 +
IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Friday, 17 October 2014 at 15:20:50 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 14:41:36 +
IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com
wrote:
What
On Friday, 17 October 2014 at 17:16:29 UTC, Ola Fosheim Grøstad
wrote:
Accurate is slower, but not this:
sum(a)/len(a)
Forgot to point out that the original point with mentioning
Python in the thread is:
1. Compiled static languages still have a long way to go with
expressiveness.
2.
I made some research, though couldn't have found any article
about it. Is there any work that has been/is being done for
Parallax Propeller Microcontroller with D Language? Any library,
linker etc.
As far as I see on wikipedia
(http://en.wikipedia.org/wiki/Parallax_Propeller), there are
On 8/21/14, 7:35 PM, Sönke Ludwig wrote:
Following up on the recent std.jgrandson thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose blend of said std.jgrandson, vibe.data.json and some changes
that I had planned for vibe.data.json for a
Hi all,
Following up on the very fun work of Adam Ruppe, Mike (JinShil)'s
Cortex M howto, XomB, and of course the D Bare Bones tutorial
on wiki.osdev.org, I have started a brand-new kernel in D over
at: https://github.com/klamonte/cycle
At the moment I am running on i386 (qemu), but aiming
Am 17.10.2014 um 19:46 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com:
On Friday, 17 October 2014 at 17:16:29 UTC, Ola Fosheim Grøstad wrote:
Accurate is slower, but not this:
sum(a)/len(a)
Forgot to point out that the original point with mentioning Python
On Friday, 17 October 2014 at 14:01:46 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 17 October 2014 at 13:27:37 UTC, eles wrote:
(gcc does not yet support std::cbegin() and std::cend()).
(tested :^)
Thanks ;)
Like your new version, but I don't think it will work with
regular arrays and maybe
Am 17.10.2014 um 20:06 schrieb tcak:
I made some research, though couldn't have found any article about it.
Is there any work that has been/is being done for Parallax Propeller
Microcontroller with D Language? Any library, linker etc.
As far as I see on wikipedia
On Friday, 17 October 2014 at 17:14:24 UTC, Paulo Pinto wrote:
Am 17.10.2014 um 17:14 schrieb Ola Fosheim
=?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com:
On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote:
And slrrr
And it has
On Friday, 17 October 2014 at 19:07:26 UTC, Paulo Pinto wrote:
I don't think I would have those issues with ML languages.
That's probably true, ML has had some generic support for 40+
years?
On Friday, 17 October 2014 at 17:25:47 UTC, monarch_dodra wrote:
On Friday, 17 October 2014 at 16:19:47 UTC, IgorStepanov wrote:
It's just common words=)
I meant that when postblit is called when new object is being
creating and doesn't exists for user code.
E.g.
const S v1 = v2;
Ok, v1
On Fri, 17 Oct 2014 19:39:39 +
IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote:
Thus I suggest another solution:
Do not generate helper functions like __fieldPostBlit, if struct
has a @disabled this(this);
Destroy it.
`@disable this (this);` means that struct can't be
On Friday, 17 October 2014 at 19:11:48 UTC, eles wrote:
On Friday, 17 October 2014 at 17:14:24 UTC, Paulo Pinto wrote:
Am 17.10.2014 um 17:14 schrieb Ola Fosheim
=?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com:
On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote:
And
On Fri, 17 Oct 2014 19:49:06 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
I just read this though:
Python 3 disallows mixing the use of tabs and spaces for
indentation.
Fucking WIN. A compiler that will *refuse* to compile your code
because it is too ugly? Mind
On Friday, 17 October 2014 at 19:45:43 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 19:39:39 +
IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Thus I suggest another solution:
Do not generate helper functions like __fieldPostBlit, if
struct has a @disabled
On Friday, 17 October 2014 at 04:23:40 UTC, Ola Fosheim Grøstad
wrote:
They don't have much of a choice since AMD64 does not provide a
segmented memory model.
Ack, I misinterpreted. The OP probably talks about
split-stacks, stacks a linked list of memory segments. I
thought it was about
and vibed.org and forum.rejectedsoftware.com
what up with your servers Sönke?
On Friday, 17 October 2014 at 21:15:47 UTC, John Colvin wrote:
and vibed.org and forum.rejectedsoftware.com
what up with your servers Sönke?
and the dub repository itself...
On Friday, 17 October 2014 at 19:12:52 UTC, Paulo Pinto wrote:
You forgot to provide the link for the best use case that
Parallax Propeller is being used for. :)
http://www.xgamestation.com/view_product.php?id=33
--
Paulo
Wow! I didn't know that really. Checking the games now.
On Thursday, 16 October 2014 at 19:46:42 UTC, Shucai wrote:
I am doing research on segmented stack mechanisms, and in
addition to academic papers, I am surveying whether segmented
stack mechanism is still useful on 64-bit machines. On 64 bit
machines, why they don’t just use a big enough
On Friday, 17 October 2014 at 18:06:26 UTC, tcak wrote:
I made some research, though couldn't have found any article
about it. Is there any work that has been/is being done for
Parallax Propeller Microcontroller with D Language? Any
library, linker etc.
As far as I see on wikipedia
On Saturday, 18 October 2014 at 01:42:38 UTC, Mike wrote:
2. Clone the GDC repository for the specific GCC version that
best matches the GCC version of the PropellerGCC
Forgot the most important link, the GDC source code:
https://github.com/D-Programming-GDC/GDC
Mike
1 - 100 of 184 matches
Mail list logo
