After again a longer-than-anticipated wait, the next release of the DUB
package and build manager is finally ready. This is a major milestone
with some important changes in the way dependency versions are handled,
making it more robust for a rapidly growing ecosystem. The number of
available
https://github.com/Hackerpilot/DCD/releases/tag/v0.4.0-beta1
Changelog at the above link. Let me know if and how you manage to
break it by filing an issue on Github.
Awesome :)
Thanks for the time you put in dub, it has become a vital part in D now.
2014-09-22 11:33 GMT+02:00 Sönke Ludwig
digitalmars-d-announce@puremagic.com:
If you can think of any potentially important and especially
backwards-incompatible changes/additions, please mention them
I thought that new version of DUB will bring SDL instead json ...
Am 22.09.2014 12:26, schrieb Suliman:
I thought that new version of DUB will bring SDL instead json ...
That's planned for 1.0.0 (or a possible intermediate release). The major
reason for this release is to get the new version management out as soon
as possible, because it is a breaking
On Monday, 22 September 2014 at 10:34:29 UTC, Sönke Ludwig wrote:
Am 22.09.2014 12:26, schrieb Suliman:
I thought that new version of DUB will bring SDL instead json
...
That's planned for 1.0.0 (or a possible intermediate release).
The major reason for this release is to get the new version
On 21/09/2014 18:43, Rainer Schuetze wrote:
I tried it on Windows and Digger does an amazing job at installing
dependencies. I think we should recommend it as the first thing to run
when trying to get your hands on building dmd/phobos.
+1
In case someone starts creating patches: Would it be
On 22/09/2014 10:35, Brian Schott wrote:
https://github.com/Hackerpilot/DCD/releases/tag/v0.4.0-beta1
Changelog at the above link. Let me know if and how you manage to break
it by filing an issue on Github.
I found this link to explain what DCD is ;-)
Am 22.09.2014 12:24, schrieb Mathias Lang via Digitalmars-d-announce:
Awesome :)
Thanks for the time you put in dub, it has become a vital part in D now.
2014-09-22 11:33 GMT+02:00 Sönke Ludwig
digitalmars-d-announce@puremagic.com
mailto:digitalmars-d-announce@puremagic.com:
If you can
Am 22.09.2014 12:43, schrieb Suliman:
On Monday, 22 September 2014 at 10:34:29 UTC, Sönke Ludwig wrote:
Am 22.09.2014 12:26, schrieb Suliman:
I thought that new version of DUB will bring SDL instead json ...
That's planned for 1.0.0 (or a possible intermediate release). The
major reason for
Now also on reddit:
http://www.reddit.com/r/programming/comments/2h492i/as_of_0922_dub_is_now_ds_official_package_manager/
Great news !
I have a suggestion, not so important: add the subConfigurations
field in the complex variant of dependencies.If you have an issue
with a package, you will have to look in one place instead of two.
See the github issue for details:
On 22/09/14 13:26, Sönke Ludwig wrote:
That would be a good thing - with more tests (and that is definitely
something that needs to be worked on, especially high level tests) it
will be more important to have a Windows tester, too, but so far
Travis/Linux has generally been sufficient, so there
On 22/09/14 11:33, Sönke Ludwig wrote:
- Improved dependency version handling scheme. Version upgrades are
now explicit, with the current snapshot being stored in the
dub.selections.json file. This is similar to how other popular
systems, such as Bundler [3], work, but built into
On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote:
But even more important, I'm pleased to announce that DUB is
now officially developed as part of the D language ecosystem!
Based on the decision back during this year's DConf, the
repository has been migrated to the
On 09/22/2014 12:50 PM, Nick Treleaven wrote:
(...)
Sometimes my Windows machine with 2 GB RAM gets OOM when trying to link
phobos.lib (I have to close most programs and start again), it would be
nice if there was a way to continue a failed build without starting from
scratch.
My guess is the
On 22 September 2014 10:33, Sönke Ludwig
digitalmars-d-announce@puremagic.com wrote:
- Added general support for single-file compilation mode, as well as
separate compile/link mode for GDC.
N.B:
All-at-once compilation has improved with GDC. But you still have to
wait minutes rather
On Mon, Sep 22, 2014 at 16:00:40 +0200, Mathias Lang via Digitalmars-d-announce
wrote:
The focus was on allowing one to compile on a limited platform (compiled
vibe.d
on a Raspberry Pi B, 512 Mos or RAM, no swap).
In order to be fast, we will have to implement proper dependency analysis
On Monday, 22 September 2014 at 11:26:58 UTC, Sönke Ludwig wrote:
That would be a good thing - with more tests (and that is
definitely something that needs to be worked on, especially
high level tests) it will be more important to have a Windows
tester, too, but so far Travis/Linux has
Am 22.09.2014 11:33, schrieb Sönke Ludwig:
After again a longer-than-anticipated wait, the next release of the DUB
package and build manager is finally ready. This is a major milestone
with some important changes in the way dependency versions are handled,
making it more robust for a rapidly
On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote:
Great thanks Sönke!
Is it's proper name DUB analog of CMake and other build tools
from C world?
On Mon, 22 Sep 2014 15:24:55 +0200
simendsjo via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
My guess is the average for developers is ~8GB. 2GB RAM is really not
enough for pretty much anything these days - the browser alone easily
chews 3-4GB on moderate use. I
FoundationDB is a modern NoSQL database which utilizes a key
value store model and purely ACID transactions.
https://foundationdb.com/
I've made D bindings available here:
https://github.com/shrub77/DerelictFDB
On Monday, 22 September 2014 at 10:50:51 UTC, Nick Treleaven
wrote:
AFAICT the test suite needs a separate MSYS install from the
one Git uses, e.g. for a newer version of 'diff'. Not sure if
that makes it harder for Digger to support.
It shouldn't be too hard. The difficult part is getting
On 09/22/2014 07:28 PM, ketmar via Digitalmars-d-announce wrote:
On Mon, 22 Sep 2014 15:24:55 +0200
simendsjo via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
My guess is the average for developers is ~8GB. 2GB RAM is really not
enough for pretty much anything these
Good stuff! But why the derelict namespace? Looks like your bindings are to
the C FoundationDB drivers. In which case i suggest splitting that up and
submitting it to the Deimos project (https://github.com/D-Programming-Deimos
).
The higher level stuff, like class DerelictFDBLoader, can be a
Am 22.09.2014 17:59, schrieb Poyeyo:
On Monday, 22 September 2014 at 11:26:58 UTC, Sönke Ludwig wrote:
That would be a good thing - with more tests (and that is definitely
something that needs to be worked on, especially high level tests) it
will be more important to have a Windows tester, too,
On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote:
If you can think of any potentially important and especially
backwards-incompatible changes/additions, please mention them
(ideally as GitHub tickets), so that we can include them before
the 1.0.0 release.
What is the
This inclusion into the DMD install, is just that DMD comes with
the dub.exe and .dll's (and ofcourse the linux mac equivalents)
in it's folders, correct?
On 9/21/2014 2:11 AM, Marc Schütz schue...@gmx.net wrote:
On Sunday, 21 September 2014 at 03:39:24 UTC, Walter Bright wrote:
I think it's a well thought out proposal. Thanks for doing this!
A couple thoughts:
1. const can be both a storage class and a type constructor. Scope is only a
storage
On 9/21/2014 4:37 PM, deadalnix wrote:
On Sunday, 21 September 2014 at 20:05:57 UTC, Walter Bright wrote:
On 9/20/2014 10:29 PM, deadalnix wrote:
DMD does very bizarre things. I think I should write a DIP, but time is always
running low...
Free goodie: when you import, all symbol are resolved
On 9/21/2014 2:17 PM, ketmar via Digitalmars-d wrote:
On Sun, 21 Sep 2014 13:04:49 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
I don't know what mental model people have for how lookups work, but
the above algorithm is how it actually works.
i believe that people
On 9/21/2014 2:33 PM, Timon Gehr wrote:
On 09/21/2014 10:08 PM, Walter Bright wrote:
Parameters are not in the same scope as local variables.
I know, and you will know that it makes no practical difference since identifier
shadowing is disallowed (deprecated) within a function.
The
On Monday, 22 September 2014 at 06:05:42 UTC, Walter Bright wrote:
On 9/21/2014 2:17 PM, ketmar via Digitalmars-d wrote:
On Sun, 21 Sep 2014 13:04:49 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com
wrote:
I don't know what mental model people have for how lookups
work, but
Am Sun, 21 Sep 2014 23:07:26 -0700
schrieb Walter Bright newshou...@digitalmars.com:
Your misunderstanding appears to be that:
foo(int a) { int b; }
'a' and 'b' are in the same scope. They are NOT in the same scope.
But quite understandable that people expect them to be in the
same
On 21/09/14 22:04, Walter Bright wrote:
Lookup rules are straightforward:
scope is current scope
do {
look up name in scope
if name is found, done!
look up name in imports imported into scope
if name is found, done!
set scope to enclosing scope
}
On 9/21/2014 11:09 PM, deadalnix wrote:
We should simply do a lookup for local symbol, and if that fail, imported
symbols.
That's what it does now, i.e. lookup in the current scope, and if that fails,
look in imports, if that fails, go to the enclosing scope.
In that case, a should
On Monday, 22 September 2014 at 06:59:14 UTC, Walter Bright wrote:
On 9/21/2014 11:09 PM, deadalnix wrote:
We should simply do a lookup for local symbol, and if that
fail, imported symbols.
That's what it does now, i.e. lookup in the current scope, and
if that fails, look in imports, if that
On 9/21/2014 11:44 PM, Marco Leise wrote:
But quite understandable that people expect them to be in the
same scope, seeing as there is only one set of {}.
{ } introduce a new nested scope, they do not extend an existing one.
Adding some
shadowing warnings should deal with that, so that the
On 9/21/2014 11:36 PM, Jacob Carlborg wrote:
You better write down the scope rules as well. It gets complicated with base
classes, template mixins and all features available in D.
Sure, I had thought they were.
BTW, template mixins work exactly like imports. See Mixin Scope here:
On 19 August 2014 19:22, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/19/14, 9:25 AM, Kai Nacke wrote:
On Tuesday, 19 August 2014 at 14:08:30 UTC, Andrei Alexandrescu wrote:
On 8/18/14, 11:18 PM, Kai Nacke wrote:
I think we should propose a D dev room for
On 9/22/14, 12:09 AM, Walter Bright wrote:
On 9/21/2014 11:36 PM, Jacob Carlborg wrote:
You better write down the scope rules as well. It gets complicated
with base
classes, template mixins and all features available in D.
Sure, I had thought they were.
BTW, template mixins work exactly like
On Monday, 22 September 2014 at 08:06:11 UTC, Andrei Alexandrescu
wrote:
D lookup rules are logical and relatively simple.
If you look at my first post, you'll notice that the discussion
so far touched only a fraction of the issue (and I forgot to
mention opDispatch in there).
That being
On Sunday, 21 September 2014 at 23:00:09 UTC, ketmar via
Digitalmars-d wrote:
On Sun, 21 Sep 2014 22:07:21 +
Ola Fosheim Grostad via Digitalmars-d
digitalmars-d@puremagic.com
wrote:
I am waiting for a patch...
i believe that we should revive 'typedef' keyword, but i'm not
fully
On 21 September 2014 15:54, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/21/14, 1:27 AM, ponce wrote:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
What do you think are the worst parts of D?
Proper D code is supposed to have lots of
Fasten your seatbelt, it's gonna be a bumpy ride! :o)
Andrei
The fundamentalness of the changes seem to be sufficient that one
could argue it's D3. If you're going to make major changes
wouldn't it be worth a fuller break to address some of the other
unresolved and seemingly pretty major
ixid:
The fundamentalness of the changes seem to be sufficient that
one could argue it's D3.
This seems a good idea.
If you're going to make major changes wouldn't it be worth a
fuller break to address some of the other unresolved and
seemingly pretty major issues such as const/immutable
On 9/22/2014 12:02 AM, deadalnix wrote:
On Monday, 22 September 2014 at 06:59:14 UTC, Walter Bright wrote:
On 9/21/2014 11:09 PM, deadalnix wrote:
We should simply do a lookup for local symbol, and if that fail, imported
symbols.
That's what it does now, i.e. lookup in the current scope, and
On Sunday, 21 September 2014 at 11:37:19 UTC, Manu via
Digitalmars-d wrote:
On 21 September 2014 16:02, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sunday, 21 September 2014 at 03:48:36 UTC, Walter Bright
wrote:
On 9/12/2014 6:48 PM, Manu via Digitalmars-d wrote:
On Sunday, 21 September 2014 at 18:09:26 UTC, Andrei Alexandrescu
wrote:
On 9/21/14, 8:29 AM, ketmar via Digitalmars-d wrote:
On Sun, 21 Sep 2014 08:15:29 -0700
Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com
wrote:
alias Int1 = Typedef!(int, a.Int1);
alias Int2 =
On Monday, 22 September 2014 at 02:34:00 UTC, Googler Lurker
wrote:
Go fizzled inside google but granted has traction outside of
google. Paulo stop feeding the troll for Petes sake.
Don't be such a coward, show your face and publish you real name.
Your style and choice of words reminds me of
On Monday, 22 September 2014 at 08:01:43 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 19 August 2014 19:22, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/19/14, 9:25 AM, Kai Nacke wrote:
On Tuesday, 19 August 2014 at 14:08:30 UTC, Andrei
Alexandrescu wrote:
On 22 September 2014 01:10, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/21/14, 4:27 AM, Manu via Digitalmars-d wrote:
On 21 September 2014 16:02, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On
On 9/21/2014 3:12 PM, Andrei Alexandrescu via Digitalmars-d wrote:
On 9/21/14, 12:35 PM, Nordlöw wrote:
On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote:
Please chime in with thoughts.
Why don't we all focus our efforts on upgrading the current GC to a
state-of-the GC
On 22 September 2014 13:19, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/21/2014 4:27 AM, Manu via Digitalmars-d wrote:
It's also extremely hard to unittest; explodes the number of static if
paths
exponentially. I'm constantly finding bugs appear a year after
On 21/09/2014 03:35, deadalnix wrote:
- It is slow to compile.
Surely that's not an inherent property of Rust?
- Constraints too much the dev in some paradigms, which obviously
won't fit all area of programming.
Absolutely. The unique mutable borrow rule too often prevents even
On 22 September 2014 19:22, via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Sunday, 21 September 2014 at 11:37:19 UTC, Manu via Digitalmars-d wrote:
On 21 September 2014 16:02, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sunday, 21 September 2014 at 03:48:36
Nick Treleaven:
- It is slow to compile.
Surely that's not an inherent property of Rust?
We don't know yet. Perhaps Rust type inference needs lot of
computations.
Bye,
bearophile
On Monday, 22 September 2014 at 11:45:39 UTC, Manu via
Digitalmars-d wrote:
Application to scope will be identical to ref. A function that
returns or
receives scope that is inserted into generic code must have
that property
cascaded outwards appropriately. If typeof() or alias loses
'scope',
On 22 September 2014 22:14, via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Monday, 22 September 2014 at 11:45:39 UTC, Manu via Digitalmars-d wrote:
Application to scope will be identical to ref. A function that returns or
receives scope that is inserted into generic code must have
On Monday, 22 September 2014 at 09:39:29 UTC, Don wrote:
My feeling is that almost every time when you want to create a
new type from an existing one, you actually want to restrict
the operations which can be performed on it. (Eg if you have
typedef money = double; then money*money doesn't
On Sunday, 21 September 2014 at 21:42:03 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 21 September 2014 at 19:28:13 UTC, Kagamin wrote:
Only isolated cluster can safely migrate between threads. D
has no means to check isolation, you should check it manually,
and in addition check if the logic
Rainer Schuetze wrote in message news:lvmjqr$h13$1...@digitalmars.com...
The branch is still in the doIt function:
Yes.
dmd didn't do any inlining at all. It is very restrained with inlining,
you'll get much better results with GDC or LDC.
Check again, it inlined doIt into main. It
Timon Gehr wrote in message news:lvmh5b$eo9$1...@digitalmars.com...
When was int x(T)=2; introduced?
At the same time as enum x(T) = 2; I think.
Also, C-style array syntax would actually be string results(T)[] = ;.
Nah, array type suffix goes before the template argument list.
On Monday, 22 September 2014 at 11:20:57 UTC, Manu via
Digitalmars-d wrote:
It is a useful tool, but you can see how going to great lengths
to write
this explosion of paths is a massive pain in the first place,
let alone
additional overhead to comprehensively test that it works... it
should
On 09/22/2014 03:26 PM, Daniel Murphy wrote:
Timon Gehr wrote in message news:lvmh5b$eo9$1...@digitalmars.com...
When was int x(T)=2; introduced?
At the same time as enum x(T) = 2; I think.
...
Is this documented?
Also, C-style array syntax would actually be string results(T)[] = ;.
On Saturday, 20 September 2014 at 14:22:32 UTC, Tofu Ninja wrote:
On Saturday, 20 September 2014 at 13:30:24 UTC, Ola Fosheim
Grostad wrote:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja
wrote:
What do you think are the worst parts of D?
1. The whining in the forums.
2. Lacks
On 9/22/14, 1:56 AM, ixid wrote:
Fasten your seatbelt, it's gonna be a bumpy ride! :o)
Andrei
The fundamentalness of the changes seem to be sufficient that one could
argue it's D3.
Let's aim for not.
If you're going to make major changes wouldn't it be
worth a fuller break to address some
On 9/22/14, 2:39 AM, Don wrote:
On Sunday, 21 September 2014 at 18:09:26 UTC, Andrei Alexandrescu wrote:
On 9/21/14, 8:29 AM, ketmar via Digitalmars-d wrote:
On Sun, 21 Sep 2014 08:15:29 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
alias Int1 = Typedef!(int,
On Monday, 22 September 2014 at 12:37:47 UTC, Manu via
Digitalmars-d wrote:
On 22 September 2014 22:14, via Digitalmars-d
digitalmars-d@puremagic.com
wrote:
On Monday, 22 September 2014 at 11:45:39 UTC, Manu via
Digitalmars-d wrote:
Application to scope will be identical to ref. A function
On Monday, 22 September 2014 at 09:13:49 UTC, bearophile wrote:
ixid:
The fundamentalness of the changes seem to be sufficient that
one could argue it's D3.
This seems a good idea.
No, it's not a good idea. Tweaking memory management shouldn't
require the language branching. IMHO, this
On 22 September 2014 23:38, Kagamin via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 22 September 2014 at 11:20:57 UTC, Manu via Digitalmars-d wrote:
It is a useful tool, but you can see how going to great lengths to write
this explosion of paths is a massive pain in the first
Piotrek:
No, it's not a good idea. Tweaking memory management shouldn't
require the language branching. IMHO, this would be a suicide.
I didn't meant the advancement as a language branching, but as a
successive version that is (mostly) backwards compatible.
Likewise C#6.0 is not a branching
On 23 September 2014 01:00, via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Monday, 22 September 2014 at 12:37:47 UTC, Manu via Digitalmars-d wrote:
On 22 September 2014 22:14, via Digitalmars-d
digitalmars-d@puremagic.com
wrote:
On Monday, 22 September 2014 at 11:45:39 UTC, Manu
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei
Alexandrescu wrote:
alias A = Typedef!float;
alias B = Typedef!float;
By basic language rules, A and B are identical. Making them
magically distinct would be surprising...
Hold up. See, Making them magically distinct would be
On Monday, 22 September 2014 at 16:21:43 UTC, Wyatt wrote:
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei
Alexandrescu wrote:
alias A = Typedef!float;
alias B = Typedef!float;
By basic language rules, A and B are identical. Making them
magically distinct would be surprising...
Hold
On Sunday, 21 September 2014 at 22:17:59 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sun, Sep 21, 2014 at 08:49:38AM +, via Digitalmars-d
wrote:
On Sunday, 21 September 2014 at 00:07:36 UTC, Vladimir
Panteleev wrote:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja
wrote:
What
On 9/22/14, 9:21 AM, Wyatt wrote:
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei Alexandrescu wrote:
alias A = Typedef!float;
alias B = Typedef!float;
By basic language rules, A and B are identical. Making them magically
distinct would be surprising...
Hold up. See, Making them
What are the major issues with const/immutable and ref?
Const and immutable seem to be difficult to work with, Maxime
wrote a piece about how difficult to use they were in practice.
Ref is difficult to combine properly with generic templates, Manu
covers that in another thread here.
Andrei Alexandrescu:
I find the requirement for the cookie perfect.
So far you're the only one, it seems. And you have admitted you
have not tried to use them significantly in your code.
Bye,
bearophile
On Monday, 22 September 2014 at 17:21:50 UTC, Andrei Alexandrescu
wrote:
I find the requirement for the cookie perfect.
There is one thing I like about it and wish was available
elsewhere: two modules can define the same type for
interoperability without needing to import each other.
My
On Mon, 22 Sep 2014 16:21:42 +
Wyatt via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei
Alexandrescu wrote:
alias A = Typedef!float;
alias B = Typedef!float;
By basic language rules, A and B are identical. Making them
Vladimir Panteleev wrote in message
news:oadjpzibjneyfutoy...@forum.dlang.org...
What if you *want* a Typedef instantiation to be the same for all
instantiations of a parent template?
Declare it outside the template and provide an alias inside. Like you would
with any other declaration
On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu
wrote:
http://dpaste.dzfl.pl/817283c163f5
You implementation seems to hold water at least in my tests and
save memory at
https://github.com/nordlow/justd/blob/master/conceptnet5.d
Thanks :)
I'm however struggling with fast
On 21.9.2014. 22:57, Peter Alexander wrote:
On Sunday, 21 September 2014 at 19:36:01 UTC, Nordlöw wrote:
On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote:
Please chime in with thoughts.
Why don't we all focus our efforts on upgrading the current GC to a
state-of-the GC
22-Sep-2014 01:45, Ola Fosheim Grostad пишет:
On Sunday, 21 September 2014 at 17:52:42 UTC, Dmitry Olshansky wrote:
to use non-atomic ref-counting and have far less cache pollution (the
set of fibers to switch over is consistent).
Caches are not a big deal when you wait for io.
Go also
On Monday, 22 September 2014 at 15:18:00 UTC, bearophile wrote:
Piotrek:
No, it's not a good idea. Tweaking memory management shouldn't
require the language branching. IMHO, this would be a suicide.
I didn't meant the advancement as a language branching, but as
a successive version that is
22-Sep-2014 13:45, Ola Fosheim Grostad пишет:
Locking fibers to threads will cost you more than using threadsafe
features. One 300ms request can then starve waiting fibers even if you
have 7 free threads.
This statement doesn't make any sense taken in isolation. It lacks way
too much context
On 22.09.2014 15:24, Daniel Murphy wrote:
Rainer Schuetze wrote in message news:lvmjqr$h13$1...@digitalmars.com...
The branch is still in the doIt function:
Yes.
dmd didn't do any inlining at all. It is very restrained with
inlining, you'll get much better results with GDC or LDC.
On Monday, 22 September 2014 at 09:17:16 UTC, Walter Bright wrote:
It is depth first. It starts at the innermost scope, which is
the current scope. Somehow, we don't seem to be talking the
same language :-(
Depth first in the sense, go from the inner to the outer scope
and look for local
On Mon, 22 Sep 2014 14:28:47 +
AsmMan via Digitalmars-d digitalmars-d@puremagic.com wrote:
It's really needed to keep C++-compatible as possible otherwise
too few people are going to use it. If C++ wasn't C-compatible do
you think it would be a successfully language it is today? I
On 09/22/2014 10:27 PM, deadalnix wrote:
On Monday, 22 September 2014 at 09:17:16 UTC, Walter Bright wrote:
It is depth first. It starts at the innermost scope, which is the
current scope. Somehow, we don't seem to be talking the same language :-(
Depth first in the sense, go from the inner
On 9/22/2014 1:27 PM, deadalnix wrote:
On Monday, 22 September 2014 at 09:17:16 UTC, Walter Bright wrote:
It is depth first. It starts at the innermost scope, which is the current
scope. Somehow, we don't seem to be talking the same language :-(
Depth first in the sense, go from the inner to
On Mon, Sep 22, 2014 at 02:58:33PM -0700, Walter Bright via Digitalmars-d wrote:
On 9/22/2014 1:27 PM, deadalnix wrote:
On Monday, 22 September 2014 at 09:17:16 UTC, Walter Bright wrote:
It is depth first. It starts at the innermost scope, which is the
current scope. Somehow, we don't seem to
On 9/22/14, 11:35 AM, bearophile wrote:
Andrei Alexandrescu:
I find the requirement for the cookie perfect.
So far you're the only one, it seems. And you have admitted you have not
tried to use them significantly in your code.
Well there seem to be a sore need of arguments to convince me
On 9/22/14, 11:52 AM, ketmar via Digitalmars-d wrote:
seems that Andrei talking about 'idiomatic D' and we are talking about
'hacky typedef replacement'. that's why we can't settle the issue: we
are both right! ;-)
That I'd agree with.
and that's why we need 'typedef' revived, methinks.
On 9/22/14, 12:18 PM, Nordlöw wrote:
On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu wrote:
http://dpaste.dzfl.pl/817283c163f5
You implementation seems to hold water at least in my tests and save
memory at
https://github.com/nordlow/justd/blob/master/conceptnet5.d
On 9/22/14, 11:56 AM, Daniel Murphy wrote:
Vladimir Panteleev wrote in message
news:oadjpzibjneyfutoy...@forum.dlang.org...
What if you *want* a Typedef instantiation to be the same for all
instantiations of a parent template?
Declare it outside the template and provide an alias inside.
On 9/22/14, 1:44 PM, ketmar via Digitalmars-d wrote:
On Mon, 22 Sep 2014 14:28:47 +
AsmMan via Digitalmars-d digitalmars-d@puremagic.com wrote:
It's really needed to keep C++-compatible as possible otherwise
too few people are going to use it. If C++ wasn't C-compatible do
you think it
1 - 100 of 201 matches
Mail list logo
