On Sunday, 4 May 2014 at 19:19:57 UTC, Nick Sabalausky wrote:
-Jsource/example/media: Use stringImportPaths to specify
import paths in a compiler independent way
Error: multiple definition of tcl_38_307: _Tcl_Main and
Tcl_Main: _Tcl_Main
These errors should now be fixed in Tkd v1.0.1-beta.
On Monday, 5 May 2014 at 08:58:34 UTC, Gary Willoughby wrote:
On Sunday, 4 May 2014 at 19:19:57 UTC, Nick Sabalausky wrote:
-Jsource/example/media: Use stringImportPaths to specify
import paths in a compiler independent way
Error: multiple definition of tcl_38_307: _Tcl_Main and
Tcl_Main:
Hi,
I don't think I told anyone, but I recall that it got a few
smiles off people, and others expressed wishes to get something
similar.
If you recall the Stand Back! shirt I was wearing last year at
DConf 2013, it was designed by myself, and made by CafePress. I
need to find a way to
On Monday, 3 March 2014 at 16:37:49 UTC, Adam D. Ruppe wrote:
As some of you might know, I've been working on a D book over
the last few months. It is now available as coming soon on
the publisher's website:
http://www.packtpub.com/discover-advantages-of-programming-in-d-cookbook/book
We're publishing in about two weeks now so it won't be long until
the real thing is out anyway!
On 5/5/2014 4:58 AM, Gary Willoughby wrote:
On Sunday, 4 May 2014 at 19:19:57 UTC, Nick Sabalausky wrote:
-Jsource/example/media: Use stringImportPaths to specify
import paths in a compiler independent way
Error: multiple definition of tcl_38_307: _Tcl_Main and Tcl_Main:
_Tcl_Main
These
On Monday, 5 May 2014 at 16:17:34 UTC, Nick Sabalausky wrote:
Excellent. I just grabbed the latest, copied the dlls and setup
scripts, and it works now.
I did find file a couple issues though:
https://github.com/nomad-software/tcltk/issues/4
https://github.com/nomad-software/tkd/issues/11
On Monday, 5 May 2014 at 11:49:23 UTC, Iain Buclaw wrote:
Hi,
I don't think I told anyone, but I recall that it got a few
smiles off people, and others expressed wishes to get something
similar.
If you recall the Stand Back! shirt I was wearing last year at
DConf 2013, it was designed by
On Sunday, 4 May 2014 at 22:56:41 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sat, May 03, 2014 at 10:48:47PM -0500, Caligo via
Digitalmars-d wrote:
[...]
Last but not least, currently there are two main ways for new
features
to make it into D/Phobos: you either have to belong to the
inner
On Sun, 04 May 2014 21:18:22 +
Daniele M. via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Sunday, 4 May 2014 at 10:23:38 UTC, Jonathan M Davis via
Digitalmars-d wrote:
And then comes my next question: except for that malloc-hack,
would it have been possible to write it in @safe
On 04/05/14 20:26, Jonas Drewsen wrote:
Just had a quick look at the source code.
If this is to be something like the official gfx library wouldn't it
make sense to follow the phobos coding style?
For example struct Size instead of struct SIZE
To me, most code there looks like bindings.
--
On 04/05/14 23:20, Daniele M. wrote:
You are right, devs would eventually abuse everything possible, although
it would make it for sure more visible: you cannot advertize an un-@safe
library as @safe, although I agree that a lot depends from devs/users
culture.
In D, you can at least
On Sun, 04 May 2014 13:29:33 +
Meta via Digitalmars-d digitalmars-d@puremagic.com wrote:
The only language I would
really trust is one in which it is impossible to write unsafe
code, because you can then know that the developers can't use
such unsafe hacks, even if they wanted to.
On 05/05/14 00:55, H. S. Teoh via Digitalmars-d wrote:
I'm sorry, but this is patently false. I am neither in the inner circle,
nor do I represent any corporation, yet I've had many changes pulled
into Phobos (including brand new code).
I think he's referring to language changes. Things that
On Monday, 28 April 2014 at 16:03:33 UTC, Andrei Alexandrescu
wrote:
Fair enough, I'll remove that part of the spec. Thanks! --
Andrei
According to the docs, the multiple of sizeof(void*)
restriction only applies to posix_memalign (and not to
_aligned_malloc and aligned_alloc.)
On
On Monday, 5 May 2014 at 06:35:07 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Sun, 04 May 2014 13:29:33 +
Meta via Digitalmars-d digitalmars-d@puremagic.com wrote:
The only language I would
really trust is one in which it is impossible to write unsafe
code, because you can then know
Importing both core.thread and std.regex results in a conflict as
both define a Thread type.
Perhaps the regex module's author assumed there'd be no clash
since it's a template - Thread(DataIndex). Should I file a bug
suggesting a name change? Or maybe D ought to allow both
parameterised and
On Mon, 05 May 2014 07:39:13 +
Paulo Pinto via Digitalmars-d digitalmars-d@puremagic.com wrote:
Sometimes I wonder how much money have C design decisions cost
the industry in terms of anti-virus, static and dynamic analyzers
tools, operating systems security enforcements, security research
On Monday, 5 May 2014 at 08:04:24 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Mon, 05 May 2014 07:39:13 +
Paulo Pinto via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Sometimes I wonder how much money have C design decisions cost
the industry in terms of anti-virus, static and
On 1 May 2014 18:40, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/1/14, 10:32 AM, Brad Anderson wrote:
It hasn't been C:\TEMP for almost 13 years
About the time when I switched :o). -- Andrei
Amen to that! (Me too)
On Sunday, 4 May 2014 at 21:18:24 UTC, Daniele M. wrote:
And then comes my next question: except for that malloc-hack,
would it have been possible to write it in @safe D? I guess
that if not, module(s) could have been made un-@safe. Not
saying that a similar separation of concerns was not
On Monday, 5 May 2014 at 00:40:41 UTC, Walter Bright wrote:
D has so many language features, we need a higher bar for
adding new ones, especially ones that can be done
straightforwardly with existing features.
Sure, but you'll have to agree that there comes a point where
library solutions
Walter Bright:
D has so many language features, we need a higher bar for
adding new ones, especially ones that can be done
straightforwardly with existing features.
If I am not wrong, all this is needed here is a boolean
compile-time flag, like __is_main_module. I think this is a
small
On Sunday, 4 May 2014 at 16:13:23 UTC, Andrei Alexandrescu wrote:
On 5/4/14, 4:42 AM, Marc Schütz schue...@gmx.net wrote:
But I'm afraid your suggestion is unsafe: There also needs to
be a way
to guarantee that no references to the scoped object exist
when it is
destroyed.
Actually, it
On Monday, 5 May 2014 at 09:32:40 UTC, JR wrote:
On Sunday, 4 May 2014 at 21:18:24 UTC, Daniele M. wrote:
And then comes my next question: except for that malloc-hack,
would it have been possible to write it in @safe D? I guess
that if not, module(s) could have been made un-@safe. Not
saying
On Mon, 05 May 2014 10:00:54 +
bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote:
Walter Bright:
D has so many language features, we need a higher bar for
adding new ones, especially ones that can be done
straightforwardly with existing features.
If I am not wrong, all
On Mon, 05 May 2014 10:24:27 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 5 May 2014 at 09:32:40 UTC, JR wrote:
On Sunday, 4 May 2014 at 21:18:24 UTC, Daniele M. wrote:
And then comes my next question: except for that malloc-hack,
would it have been possible to
Jonathan M Davis:
Just because something is done in
python does not mean that it is appropriate for D or that it
requires adding features to D in order to support it.
I agree. On the other hand now I have years of experience in both
language and I still have this need in D.
It makes no
05-May-2014 12:03, John Chapman пишет:
Importing both core.thread and std.regex results in a conflict as both
define a Thread type.
Perhaps the regex module's author assumed there'd be no clash since it's
a template - Thread(DataIndex). Should I file a bug suggesting a name
change? Or maybe D
On Mon, 05 May 2014 15:55:13 +0400
Dmitry Olshansky via Digitalmars-d digitalmars-d@puremagic.com wrote:
Why the heck should internal symbols conflict with public from other
modules? No idea.
Because no one has been able to convince Walter that it's a bad idea for
private symbols to be visible.
On Monday, 5 May 2014 at 12:48:11 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Mon, 05 May 2014 15:55:13 +0400
Dmitry Olshansky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Why the heck should internal symbols conflict with public from
other
modules? No idea.
Because no one has
On Mon, 05 May 2014 11:26:29 +
bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote:
Jonathan M Davis:
Such code should be kept separate IMHO.
This means that you now have two modules, so to download them
atomically you need some kind of packaging, like a zip. If your
project
On Wednesday, 30 April 2014 at 19:28:24 UTC, Ola Fosheim Grøstad
wrote:
Restricting dicts and arrays to a single element type requires
more complicated logic in some cases.
How you would handle elements of unexpected type in those arrays?
What if mishandling is silent and causes a heisenbug?
On Mon, 05 May 2014 13:11:29 +
Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 5 May 2014 at 12:48:11 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Mon, 05 May 2014 15:55:13 +0400
Dmitry Olshansky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Why
On Monday, 5 May 2014 at 13:33:13 UTC, Jonathan M Davis via
Digitalmars-d wrote:
IIRC, it had something to do with member functions, but I'd
have to go digging
through the newsgroup archives for the details. In general
though, I think
that private symbols should be ignored by everything outside
Jonathan M Davis:
Honestly, I wouldn't even consider distributing something that
was only a
single module in size unless it were on the scale of
std.datetime, which we've
generally agreed is too large for a single module.
So, a single module
wouldn't have enough functionality to be worth
On Sunday, 4 May 2014 at 20:49:57 UTC, bearophile wrote:
If we keep class destructors in D, is it a good idea to require
them to be @nogc?
This post comes after this thread in D.learn:
http://forum.dlang.org/thread/vlnjgtdmyolgoiofn...@forum.dlang.org
Bye,
bearophile
Not sure that would be
Also, the @nogc for destructors is specific to the current GC, and is
a limitation that isn't really needed were destructors implemented
properly in the current GC.
On 5/5/14, monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Sunday, 4 May 2014 at 20:49:57 UTC, bearophile
On Mon, May 05, 2014 at 06:16:34AM +, Arlen via Digitalmars-d wrote:
On Sunday, 4 May 2014 at 22:56:41 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sat, May 03, 2014 at 10:48:47PM -0500, Caligo via Digitalmars-d wrote:
[...]
Last but not least, currently there are two main ways for new
Initial post in this thread makes focus on a change that does not
fix anything and implies silent semantical breakage. I am glad
Andrei has reconsidered it but feels like key problem is not that
proposal itself was bad but that it does not even try to solve.
Real issue being deterministic
The only thing I could see being an issue is the size of resulting
scanning code, which could probably be mitigated by using a
`bitmap`-ish representation as a key, so that types that have the same
bitmap use the same scanning function. Also, I see a *very* large
number of indirect branching
On 5/4/14, Marco Leise via Digitalmars-d digitalmars-d@puremagic.com wrote:
Would that affect all arrays, only arrays containing structs
or only affect arrays containing structs with dtors?
printf(hello\n.ptr);
should still work after all.
That should work independent of what the GC
05-May-2014 10:16, Arlen пишет:
On Sunday, 4 May 2014 at 22:56:41 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sat, May 03, 2014 at 10:48:47PM -0500, Caligo via Digitalmars-d wrote:
[...]
Last but not least, currently there are two main ways for new features
to make it into D/Phobos: you either
Very short feedback about original proposal:
1) managing local objects is not really a problem, we already
have `scoped` in Phobos for that (and unimplemented scope
qualifier as possible more reliable approach)
2) real problem is managing global objects without clear
destruction point while
However, the community is starting to standardize around Dub as
the standard package manager. Dub makes downloading a package as
easy as editing a JSON file (and it scales such that you can
download a project of any size this way). Did Python have a
proper package manager before this idiom
On 5/5/14, 12:13 AM, safety0ff wrote:
On Monday, 28 April 2014 at 16:03:33 UTC, Andrei Alexandrescu wrote:
Fair enough, I'll remove that part of the spec. Thanks! -- Andrei
According to the docs, the multiple of sizeof(void*) restriction only
applies to posix_memalign (and not to
On 2014-05-04 4:34 AM, Daniele M. wrote:
I have read this excellent article by David A. Wheeler:
http://www.dwheeler.com/essays/heartbleed.html
And since D language was not there, I mentioned it to him as a possible
good candidate due to its static typing and related features.
However, now I
On 5/5/14, 2:32 AM, JR wrote:
On Sunday, 4 May 2014 at 21:18:24 UTC, Daniele M. wrote:
And then comes my next question: except for that malloc-hack, would it
have been possible to write it in @safe D? I guess that if not,
module(s) could have been made un-@safe. Not saying that a similar
On 5/5/14, 3:18 AM, Marc Schütz schue...@gmx.net wrote:
On Sunday, 4 May 2014 at 16:13:23 UTC, Andrei Alexandrescu wrote:
On 5/4/14, 4:42 AM, Marc Schütz schue...@gmx.net wrote:
But I'm afraid your suggestion is unsafe: There also needs to be a way
to guarantee that no references to the scoped
On Thursday, 1 May 2014 at 16:08:23 UTC, Andrei Alexandrescu
wrote:
It got full because of tests (surprise!). Your actions?
Fix the machine and reduce the output created by the unittests.
It's a simple engineering problem. -- Andrei
You can't. You have not control over that machine you
On Thursday, 1 May 2014 at 19:22:36 UTC, Andrei Alexandrescu
wrote:
On 5/1/14, 11:49 AM, Jacob Carlborg wrote:
On 2014-05-01 17:15, Andrei Alexandrescu wrote:
That's all nice, but I feel we're going gung ho with
overengineering
already. If we give unittests names and then offer people a
On 5/4/14, 11:16 PM, Arlen wrote:
A couple years ago I submitted std.rational, but it didn't go
anywhere. About a year later I discovered that someone else had
done a similar thing, but it never made it into Phobos either.
Of course, it's not because we didn't belong to some inner
circle, but I
On 5/5/14, 8:11 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 16:08:23 UTC, Andrei Alexandrescu wrote:
It got full because of tests (surprise!). Your actions?
Fix the machine and reduce the output created by the unittests. It's a
simple engineering problem. -- Andrei
You can't. You have not
On 5/5/14, 8:16 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 19:22:36 UTC, Andrei Alexandrescu wrote:
On 5/1/14, 11:49 AM, Jacob Carlborg wrote:
On 2014-05-01 17:15, Andrei Alexandrescu wrote:
That's all nice, but I feel we're going gung ho with overengineering
already. If we give unittests
Meta:
However, the community is starting to standardize around Dub as
the standard package manager. Dub makes downloading a package
as easy as editing a JSON file (and it scales such that you can
download a project of any size this way).
Having package manager(s) in Python doesn't make
On Monday, 5 May 2014 at 15:36:19 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 8:11 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 16:08:23 UTC, Andrei Alexandrescu
wrote:
It got full because of tests (surprise!). Your actions?
Fix the machine and reduce the output created by the
unittests.
Andrei Alexandrescu:
I think the needs to support BigInt argument is not a blocker
- we can release std.rational to only support built-in
integers, and then adjust things later to expand support while
keeping backward compatibility. I do think it's important that
BigInt supports appropriate
05-May-2014 18:59, Etienne пишет:
On 2014-05-04 4:34 AM, Daniele M. wrote:
I have read this excellent article by David A. Wheeler:
http://www.dwheeler.com/essays/heartbleed.html
And since D language was not there, I mentioned it to him as a possible
good candidate due to its static typing and
How to get and address of newly created object and put it in
pointer array?
int maxNeurons = 100;
Neuron*[] neurons = new Neuron*[](maxNeurons);
Neuron n;
for(int i = 0; i maxNeurons; i++)
{
n = new Neuron();
neurons[] = n; // here n always returns same adress
}
On Monday, 5 May 2014 at 16:15:43 UTC, hardcoremore wrote:
neurons[] = n; // here n always returns same adress
You're taking the address of the pointer, which isn't changing.
Just use plain n - when you new it, it is already a pointer so
just add that value to your array.
On Monday, 5 May 2014 at 14:17:04 UTC, Orvid King via
Digitalmars-d wrote:
Also, the @nogc for destructors is specific to the current GC,
and is a limitation that isn't really needed were destructors
implemented properly in the current GC.
How does one implement destructors (described below)
On 5/5/2014 12:15 PM, hardcoremore wrote:
How to get and address of newly created object and put it in pointer array?
int maxNeurons = 100;
Neuron*[] neurons = new Neuron*[](maxNeurons);
Neuron n;
for(int i = 0; i maxNeurons; i++)
{
n = new Neuron();
neurons[] = n; // here n
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should do no I/O because
any sort of I/O can fail because of reasons you don't control from the
test suite is an appropriate generalization of my statement.
Full /tmp is not a problem, there is nothing broken about
On Mon, May 05, 2014 at 03:55:12PM +, bearophile via Digitalmars-d wrote:
Andrei Alexandrescu:
I think the needs to support BigInt argument is not a blocker - we
can release std.rational to only support built-in integers, and then
adjust things later to expand support while keeping
Am Sun, 04 May 2014 21:05:01 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
I've decided that runtime-chosen page sizes are too much of a
complication for the benefits.
Alright. Note however, that on Windows the allocation
granularity is larger than the page size (64 KiB).
Hi Guys,
Thanks so much for your reply. This fixes my problem like Adam D.
Ruppe suggested:
int maxNeurons = 100;
Neuron[] neurons = new Neuron[](maxNeurons);
Neuron n;
for(int i = 0; i maxNeurons; i++)
{
n = new Neuron();
neurons[] = n;
}
But can you give me a more details
On Monday, 5 May 2014 at 16:33:42 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should do no I/O
because
any sort of I/O can fail because of reasons you don't control
from the
test suite is an appropriate generalization of my
05-May-2014 20:57, Marco Leise пишет:
That sounds like a more complicated topic than anything I had
in mind. I think a »std.virtualmemory« module should already
implement all the primitives in a portable form, so we don't
have to do that again for the next use case. Since
cross-platform code is
On Sunday, 4 May 2014 at 17:01:23 UTC, safety0ff wrote:
On Saturday, 3 May 2014 at 22:46:03 UTC, Andrei Alexandrescu
wrote:
On 5/3/14, 2:42 PM, Atila Neves wrote:
gdc gave _very_ different results. I had to use different
modules
because at some point tests started failing, but with gdc the
Am Mon, 5 May 2014 09:39:30 -0700
schrieb H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com:
On Mon, May 05, 2014 at 03:55:12PM +, bearophile via Digitalmars-d wrote:
Andrei Alexandrescu:
I think the needs to support BigInt argument is not a blocker - we
can release
On Monday, 5 May 2014 at 17:22:58 UTC, Marco Leise wrote:
Am Mon, 5 May 2014 09:39:30 -0700
schrieb H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com:
On Mon, May 05, 2014 at 03:55:12PM +, bearophile via
Digitalmars-d wrote:
Andrei Alexandrescu:
I think the needs to support
On Mon, 05 May 2014 16:15:42 +
hardcoremore via Digitalmars-d digitalmars-d@puremagic.com wrote:
How to get and address of newly created object and put it in
pointer array?
int maxNeurons = 100;
Neuron*[] neurons = new Neuron*[](maxNeurons);
Neuron n;
for(int i = 0; i maxNeurons;
The current GC cannot allocate within a destructor because of the fact
that it has to acquire a global lock on the GC before calling the
actual destructor, meaning that attempting to allocate or do anything
that requires a global lock on the GC is impossible, because the lock
has already been
On Saturday, 3 May 2014 at 12:26:13 UTC, Rikki Cattermole wrote:
On Saturday, 3 May 2014 at 12:24:59 UTC, Atila Neves wrote:
Out of curiosity are you on Windows?
No, Arch Linux 64-bit. I also just noticed a glaring threading
bug in my code as well that somehow's never turned up. This is
not
Going to take a wild guess, but as core.atomic.casImpl will never be
inlined anywhere with DMD, due to it's inline assembly, you have the
cost of building and destroying a stack frame, the cost of passing the
args in, moving them into registers, saving potentially trashed
registers, etc. every
I never got the real issue with destructors(I haven't seen the
issue explained, just a lot of talk about it being a problem and
how to fix it) but I think doing away with them would be a very
bad idea. Assuming the only/main issue is with the GC not
guaranteeing to call them then that is
On 5/5/14, 9:57 AM, Marco Leise wrote:
That sounds like a more complicated topic than anything I had
in mind. I think a »std.virtualmemory« module should already
implement all the primitives in a portable form, so we don't
have to do that again for the next use case. Since
cross-platform code is
On 5/5/14, 10:08 AM, Dicebot wrote:
On Monday, 5 May 2014 at 16:33:42 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should do no I/O because
any sort of I/O can fail because of reasons you don't control from the
test suite is
On Monday, 5 May 2014 at 18:24:43 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 10:08 AM, Dicebot wrote:
On Monday, 5 May 2014 at 16:33:42 UTC, Andrei Alexandrescu
wrote:
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should do no
I/O because
any sort of I/O
On 5/5/14, 11:25 AM, Dicebot wrote:
On Monday, 5 May 2014 at 18:24:43 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 10:08 AM, Dicebot wrote:
On Monday, 5 May 2014 at 16:33:42 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should
On Monday, 5 May 2014 at 17:46:35 UTC, Orvid King via
Digitalmars-d wrote:
Destructors and finalizers are the same thing.
That is exactly the point that I am arguing against. That they
are confused in D (or 'unified', if you think is a good thing) I
accept, but I think it's a language design
On Monday, 5 May 2014 at 18:29:40 UTC, Andrei Alexandrescu wrote:
My understanding here is you're trying to make dogma out of
engineering choices that may vary widely across projects and
organizations. No thanks.
Andrei
I am asking to either suggest an alternative solution or to
clarify
On Monday, 5 May 2014 at 14:59:13 UTC, Etienne wrote:
On 2014-05-04 4:34 AM, Daniele M. wrote:
I have read this excellent article by David A. Wheeler:
http://www.dwheeler.com/essays/heartbleed.html
And since D language was not there, I mentioned it to him as a
possible
good candidate due to
On Monday, 5 May 2014 at 10:41:41 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Mon, 05 May 2014 10:24:27 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 5 May 2014 at 09:32:40 UTC, JR wrote:
On Sunday, 4 May 2014 at 21:18:24 UTC, Daniele M. wrote:
And then comes my
On 5/5/14, 11:47 AM, Dicebot wrote:
On Monday, 5 May 2014 at 18:29:40 UTC, Andrei Alexandrescu wrote:
My understanding here is you're trying to make dogma out of
engineering choices that may vary widely across projects and
organizations. No thanks.
Andrei
I am asking to either suggest an
On 2014-05-05 15:32, Jonathan M Davis via Digitalmars-d wrote:
Maybe they should still be
visible for the purposes of reflection or some other case where seeing the
symbols would be useful
Yes, it's useful for .tupleof to access private members.
--
/Jacob Carlborg
Am 05.05.2014 19:46, schrieb Orvid King via Digitalmars-d:
The current GC cannot allocate within a destructor because of the fact
that it has to acquire a global lock on the GC before calling the
actual destructor, meaning that attempting to allocate or do anything
that requires a global lock on
17-Mar-2014 02:13, Martin Nowak пишет:
On 02/22/2014 09:31 PM, Marc Schütz schue...@gmx.net wrote:
But that still doesn't explain why a custom hash table implementation is
necessary. Maybe a lightweight wrapper around built-in AAs is sufficient?
I'm also wondering what benefit this hash table
On Monday, 5 May 2014 at 00:44:43 UTC, Caligo via Digitalmars-d
wrote:
On Sun, May 4, 2014 at 12:22 AM, Andrei Alexandrescu via
Digitalmars-d
digitalmars-d@puremagic.com wrote:
The on/off switch may be a nice idea in the abstract but is
hardly the
perfect recipe to good language feature
On 2014-05-05 2:54 PM, Daniele M. wrote:
Have you thought about creating an SSL/TLS implementations tester instead?
You mean testing existing TLS libraries using this information?
The advantages of using all-D is having zero-copy buffers that inline
with the other layers of streams when
Are we allowed to put a DMD installer on http://chocolatey.org as a
package? I'd be interested in building a bulk installer for DMD + dub +
Mono-D but I'm not sure about the licensing terms b/c the dmd back-end
is supposedly proprietary.
On 5 May 2014 19:07, Orvid King via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Going to take a wild guess, but as core.atomic.casImpl will never be
inlined anywhere with DMD, due to it's inline assembly, you have the
cost of building and destroying a stack frame, the cost of passing the
On 5/5/2014 4:05 PM, Etienne wrote:
Are we allowed to put a DMD installer on http://chocolatey.org as a
package? I'd be interested in building a bulk installer for DMD + dub +
Mono-D but I'm not sure about the licensing terms b/c the dmd back-end
is supposedly proprietary.
Go here (with JS
On 5/5/2014 4:26 PM, Nick Sabalausky wrote:
Use the Send email to Walter Bright and request permission. He's known
to be cool about this sort of thing. IIUC, the whole permission thing
is just a formality necessitated by the backend's former life as part of
various companies's commercial
Hi Jonathan,
Thanks for your reply. So actually I was getting the pointer of n
itself.
I understand now what was my problem. The problem was that I did
not know that array support references of objects, so I thought
that I must fill it with pointers of objects.
But its great that I do
On Monday, 5 May 2014 at 17:56:11 UTC, Dicebot wrote:
On Saturday, 3 May 2014 at 12:26:13 UTC, Rikki Cattermole wrote:
On Saturday, 3 May 2014 at 12:24:59 UTC, Atila Neves wrote:
Out of curiosity are you on Windows?
No, Arch Linux 64-bit. I also just noticed a glaring
threading bug in my
On Monday, 5 May 2014 at 20:05:09 UTC, Etienne wrote:
Are we allowed to put a DMD installer on http://chocolatey.org
as a package? I'd be interested in building a bulk installer
for DMD + dub + Mono-D but I'm not sure about the licensing
terms b/c the dmd back-end is supposedly proprietary.
On 2014-05-05 18:21, Vladimir Panteleev wrote:
On Monday, 5 May 2014 at 20:05:09 UTC, Etienne wrote:
Are we allowed to put a DMD installer on http://chocolatey.org as a
package? I'd be interested in building a bulk installer for DMD + dub
+ Mono-D but I'm not sure about the licensing terms b/c
http://forum.dlang.org/thread/wdddgiowaidcojbrk...@forum.dlang.org
Worth a reddit announcement tomorrow morning? -- Andrei
TkD is nice,but the exe's Memory usage is 6.8~7M,but DFL's only
2.8~3M,and only a single file on windows 7.
https://github.com/Rayerd/dfl,
On 2014-05-04 09:26, w0rp wrote:
Qt 4 support basically arises from what is easy to do right now.
Supporting Qt 5 doesn't seem that far off. I went with Qt 4 for now
because it's easier, and at this stage it's more important to work with
something that can actually work and learn from that,
1 - 100 of 195 matches
Mail list logo
