On 11/01/2014 11:13 PM, Sean Kelly wrote:
> Note that thread_joinAll is called automatically when main exits
Has that always been the case? I remember having to inject
thread_joinAll() calls at the ends of the main()s of a couple of
examples because of having trouble otherwise.
Can I safely
Note that thread_joinAll is called automatically when main exits,
so if you just want to be sure that your spawned thread completes
you don't have to do anything at all.
The decision to obscure the Thread object in std.concurrency was
deliberate, as it allows us to use more than just kernel threa
Note that thread_joinAll is called automatically when main exits,
so if you just want to be sure that your spawned thread completes
you don't have to do anything at all.
The decision to obscure the Thread object in std.concurrency was
deliberate, as it allows us to use more than just kernel th
On 11/01/2014 04:32 PM, Neven wrote:
Ok, a newbie question ahead. I want to create new thread which calls
given function with some parameters. Thus, I think spawn is the right
function for me. However that functions returns Tid and not a Thread
object.
So I want to know how can I make a Thread o
Is there a way to spawn a process that won't be a child process,
because I can't seem to kill any processes created with
spawnProcess() It keeps giving me access denied for the processes
and it's necessary for me to kill a process, compile it and then
spawn it again.
Currently what I do is sa
On Saturday, November 01, 2014 10:30:05 anonymous via Digitalmars-d-learn
wrote:
> On Saturday, 1 November 2014 at 00:08:23 UTC, Jonathan M Davis
>
> via Digitalmars-d-learn wrote:
> > So, by shallow copy, you mean that you want an array that
> > contains the same
> > elements but is a new array?
On Saturday, 1 November 2014 at 21:12:58 UTC, Kagamin wrote:
Oops, this:
http://forum.dlang.org/post/vybptydvdxultfnfq...@forum.dlang.org
Ok. I see. Each static library used by the source must be build
manually with ms32coff, and even in the final version those lib
wont be included because it
Ok, a newbie question ahead. I want to create new thread which
calls given function with some parameters. Thus, I think spawn is
the right function for me. However that functions returns Tid and
not a Thread object.
So I want to know how can I make a Thread object out of it. What
I would like
On Saturday, 1 November 2014 at 23:18:35 UTC, John Colvin wrote:
Doesn't support "is" keyword.
Another good use-case for allowing a user-defined operator for is.
What are the known pitfalls of std.typecons.Typedef as of now?
Things I know:
Have to use a cookie string to get a proper unique type.
Have to explicitly specify an init in order to specify a cookie.
Doesn't support "is" keyword.
Isn't nice to look at in error messages.
Relies on optimisatio
On 11/01/2014 01:34 PM, Suliman wrote:
> Or auto mean structure of data, that have not standard type
> like (int or string)?
D is a strongly typed language, so every variable has its specific type.
D also has type inference, meaning that we don't need to specify types
explicitly. In theory, ev
On Saturday, 1 November 2014 at 20:48:45 UTC, Nordlöw wrote:
Is there a suitable trait we can use to detect this and in turn
use to disallow stealFront() and stealBack() in these cases?
Made it a separate new question at
http://forum.dlang.org/thread/onibkzepudfisxtri...@forum.dlang.org#post-o
You can see http://wiki.dlang.org/DIP61 and linked discussions.
Static and virtual functions probably work. Constructors and
destructors probably don't. What's difficult is multiple
inheritance. The information on C++ support is largely considered
private to the compiler team.
As a follow-up question to
http://forum.dlang.org/thread/jkbhlezbcrufowxtt...@forum.dlang.org?page=3#post-zyuqclyjitbhavemmwto:40forum.dlang.org
discussing the motivation for a new range primitive stealFront
that combines moveFront and popFront implemented at
https://github.com/nordlow/justd/
Oops, this:
http://forum.dlang.org/post/vybptydvdxultfnfq...@forum.dlang.org
http://forum.dlang.org/post/xqjosrzoswakjcdgq...@forum.dlang.org
D claims compatibility with system C compiler, which usually have
32-bit int.
> I thought you were expanding it
Drat. *You* thought you were expanding it.
On Sat, Nov 1, 2014 at 9:34 PM, Suliman via Digitalmars-d-learn
wrote:
> Few questions.
>
> 1. In examples tuples are created with keyword auto. Can I create them with
> another keyword. Or auto mean structure of data, that have not standard type
> like (int or string)?
`tuple' is a function defi
On Saturday, 1 November 2014 at 16:10:17 UTC, Jakob Ovrum wrote:
problematic.
What about turning stealFront and stealBack at
https://github.com/nordlow/justd/blob/master/range_ex.d
into mixins?
On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum wrote:
Sometimes after popping, the previous `front` is no longer
valid, such as in the case of a buffer being reused.
Is there a suitable trait we can use to detect this and in turn
use to disallow stealFront() and stealBack() in the
Few questions.
1. In examples tuples are created with keyword auto. Can I create
them with another keyword. Or auto mean structure of data, that
have not standard type like (int or string)?
2. How ti expend tuple? I tried to do:
auto imglist = tuple("aaa");
imglist.expand["sss"];
wr
On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum wrote:
Sometimes after popping, the previous `front` is no longer
valid, such as in the case of a buffer being reused. We should
This seems like a error-prone design to me.
I guess performance is the motivation right?
Maybe a future
On Saturday, 1 November 2014 at 16:10:17 UTC, Jakob Ovrum wrote:
The other half of my post explained why such a `stealFront` is
problematic.
Got it. Thanks!
Is it supposed to ? Is this feature planned for 2.067 ?
error messages:
...\windows\bin\..\..\src\phobos\std\stdio.d(35): Error: module
std.c.stdio import 'FHND_WCHAR' not found
...\windows\bin\..\..\src\phobos\std\stdio.d(35): Error: module
std.c.stdio import 'FHND_TEXT' not found
On Saturday, 1 November 2014 at 11:43:28 UTC, Nordlöw wrote:
On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum
wrote:
If you want move semantics, use `moveFront`.
But x.moveFront doesn't modify x.
It does modify `x` as it leaves `front` in a destroyed and
default-initialized state
On Saturday, 1 November 2014 at 15:48:27 UTC, Shriramana Sharma
via Digitalmars-d-learn wrote:
Thank you very much. But this is curious -- isn't Andrei
himself able
to directly commit or answer that pull request?!!
All pull requests need to be peer reviewed, even those submitted
by committers
On Sat, Nov 01, 2014 at 09:18:19PM +0530, Shriramana Sharma via
Digitalmars-d-learn wrote:
> Thank you very much. But this is curious -- isn't Andrei himself able
> to directly commit or answer that pull request?!!
[...]
Andrei appears to be very busy these days and rarely responds to PRs
unless
Thank you very much. But this is curious -- isn't Andrei himself able
to directly commit or answer that pull request?!!
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
On Saturday, 1 November 2014 at 15:02:44 UTC, Shriramana Sharma
via Digitalmars-d-learn wrote:
Hello. I already posted this via the forum interface:
http://forum.dlang.org/thread/yqhwwpskwmkdefarj...@forum.dlang.org
But for whatever reason I didn't get any replies so I worry if
it
actually rea
Hello. I already posted this via the forum interface:
http://forum.dlang.org/thread/yqhwwpskwmkdefarj...@forum.dlang.org
But for whatever reason I didn't get any replies so I worry if it
actually reached people or not...
-- Original message --
At http://dlang.org/spec.html I read: "This is also
In the following pages:
http://dlang.org/interfaceToC.html
http://dlang.org/cpp_interface
the "Data Type Compatibility" section says D int is compatible with
C/C++ int. Isn't this actually false because D's integer types are
fixed-size whereas C/C++'s are variable? So D int is only compatible
wit
On Saturday, 1 November 2014 at 14:01:42 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 13:36:05 UTC, anonymous wrote:
I don't see what you'd need inout for here.
stealFront/stealBack are not methods.
inout can be used on free functions aswell. See for example
https://github.com/nordlow/
In the following pages (which have differing file naming patterns for
whatever reason!):
http://dlang.org/interfaceToC.html
http://dlang.org/cpp_interface
I would suggest to add the info that wchar is compatible with the
char16_t and dchar with char32_t of C11. See:
http://en.wikipedia.org/wiki/
Hello. I really really need to be able to interface well with a C++
library which contains lots of classes if I am going to further invest
time into D.
Now from the http://dlang.org/cpp_interface I find out the current
status of built-in C++ interfacing support. I'm working on Linux so
using the C
On Saturday, 1 November 2014 at 13:54:31 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 13:38:22 UTC, Marc Schütz wrote:
If you want to avoid the temporary variable, you could write:
scope(success) r.popFront;
return r.moveFront;
Does this solution cost performance?
I guess we ha
On Saturday, 1 November 2014 at 13:38:22 UTC, Marc Schütz wrote:
If you want to avoid the temporary variable, you could write:
scope(success) r.popFront;
return r.moveFront;
Nice solution anyhow! Thanks!
On Saturday, 1 November 2014 at 13:36:05 UTC, anonymous wrote:
I don't see what you'd need inout for here.
stealFront/stealBack are not methods.
inout can be used on free functions aswell. See for example
https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L674
On Saturday, 1 November 2014 at 13:30:16 UTC, anonymous wrote:
`auto ref` is nonsense here. You can't return a reference to `e`
as
it's a local variable.
My mistake. Thanks.
On Saturday, 1 November 2014 at 13:38:22 UTC, Marc Schütz wrote:
If you want to avoid the temporary variable, you could write:
scope(success) r.popFront;
return r.moveFront;
Does this solution cost performance?
On Saturday, 1 November 2014 at 13:25:03 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
What's the recommended way of making stealFront and stealBack
inout here? Can I somehow use au
On Saturday, 1 November 2014 at 13:30:16 UTC, anonymous wrote:
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 11:45:25 UTC, Nordlöw wrote:
So why isn't something like x.stealFront already in Phobos?
First try here:
https://github.com/nordlow/just
On Saturday, 1 November 2014 at 13:36:05 UTC, Marc Schütz wrote:
On Saturday, 1 November 2014 at 13:30:16 UTC, anonymous wrote:
[...]
auto ref stealFront(R)(ref R r)
{
import std.range: moveFront, popFront;
auto e = r.moveFront;
r.popFront;
return e;
}
[...]
It's probably intended to mean `aut
On Saturday, 1 November 2014 at 13:25:03 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
What's the recommended way of making stealFront and stealBack
inout here? Can I somehow use au
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 11:45:25 UTC, Nordlöw wrote:
So why isn't something like x.stealFront already in Phobos?
First try here:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
That is:
auto
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
What's the recommended way of making stealFront and stealBack
inout here? Can I somehow use auto ref together with inout?
On Saturday, 1 November 2014 at 11:45:25 UTC, Nordlöw wrote:
So why isn't something like x.stealFront already in Phobos?
First try here:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
On Friday, 31 October 2014 at 23:59:54 UTC, dajones wrote:
is there a better way than doing...
cast(string)(buf~"hoo")
to get it to pick the correct overload?
text(buf,"hoo")
On Saturday, 20 September 2014 at 19:40:02 UTC, AsmMan wrote:
Is this function part of phobos library? if so, where?
It's in std.range.
On Saturday, 1 November 2014 at 11:43:28 UTC, Nordlöw wrote:
if (!x.empty)
if (auto front = x.stealFront)
{
front.doStuff;
}
This is more functional/atomic, that is it reduces the risk of
accidentally forgetting to call popFront at the end.
Forgot my explicit question:
So
On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum wrote:
If you want move semantics, use `moveFront`.
But x.moveFront doesn't modify x.
What I want is to transform my uses of std.range from
if (!x.empty)
{
x.front.doStuff;
x.popFront;
}
into
if (!x.empty)
if (auto fron
On Saturday, 1 November 2014 at 00:08:23 UTC, Jonathan M Davis
via Digitalmars-d-learn wrote:
So, by shallow copy, you mean that you want an array that
contains the same
elements but is a new array?
yes
If that's what you want, just slice the array.
auto b = a[];
This is the same as `auto
On Sat, 01 Nov 2014 08:36:40 +
via Digitalmars-d-learn wrote:
> No, it's `~=` that may or may not allocate, but `~` always does.
you a right. sorry, i was wrong here.
signature.asc
Description: PGP signature
On Saturday, 1 November 2014 at 03:28:36 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sat, 01 Nov 2014 00:05:19 +
"Adam D. Ruppe via Digitalmars-d-learn"
wrote:
BTW one could argue that char[] ~ operator should yield
something that's implicitly convertable, since it allocates a
new memor
54 matches
Mail list logo
