On Wednesday, 25 February 2015 at 13:56:06 UTC, wobbles wrote:
Hi,
Any reason why the following wont work?
void main(string[] args)
{
auto pidIn = File.tmpfile();
auto pidOut = File.tmpfile();
auto pid = spawnProcess([ls, ./], pidIn, pidOut,
std.stdio.stdout, null, Config.newEnv);
Hi,
Any reason why the following wont work?
void main(string[] args)
{
auto pidIn = File.tmpfile();
auto pidOut = File.tmpfile();
auto pid = spawnProcess([ls, ./], pidIn, pidOut,
std.stdio.stdout, null, Config.newEnv);
if(wait(pid) == 0)
writefln(%s, pidOut.readln());
It improves things without tools. Tools are always welcome, e.g.
dfix already does something.
On Tuesday, 24 February 2015 at 10:15:29 UTC, FrankLike wrote:
There is a int[] ,how to use the Fiber execute it ?
Such as :
import std.stdio;
import core.thread;
class DerivedFiber : Fiber
{
this()
{
super( run );
}
private :
void run()
{
printf( Derived
On Wednesday, 25 February 2015 at 16:04:54 UTC, Adam D. Ruppe
wrote:
No, D's variable scoping is always lexical.
Thanks.
No, D's variable scoping is always lexical.
Good time of day.
Tell me, please, does D dynamic scope? If there is, prevalite,
please, an example of it's use, or give a link where you can read
about dynamic scope.
On 2015-02-24 18:55, Jonathan M Davis via Digitalmars-d-learn wrote:
Normally, the symbol is deprecated right away, because using a deprecated
symbol just results in a message being printing, but if a new symbol is
being introduced to replace the deprecated one at the same time that the
old
On Wed, Feb 25, 2015 at 07:32:48PM +, Namespace wrote:
void glCheck(lazy void func, string file = __FILE__, uint line =
__LINE__) {
func();
glCheckError(file, line);
}
How can I specify that 'func' is @nogc? Or can define the
function otherwise?
Try
void
On Wednesday, 25 February 2015 at 07:07:00 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 25 February 2015 at 00:12:41 UTC, anonymous wrote:
[...]
That sounds more attractive than the provided example, but the
right thing to do is to establish proper encapsulation. That
means you need a
void glCheck(lazy void func, string file = __FILE__, uint line =
__LINE__) {
func();
glCheckError(file, line);
}
How can I specify that 'func' is @nogc? Or can define the
function otherwise?
On 02/25/2015 05:56 AM, wobbles wrote:
Hi,
Any reason why the following wont work?
void main(string[] args)
{
auto pidIn = File.tmpfile();
auto pidOut = File.tmpfile();
auto pid = spawnProcess([ls, ./], pidIn, pidOut,
std.stdio.stdout, null, Config.newEnv);
On Wednesday, 25 February 2015 at 19:53:16 UTC, Ivan Timokhin
wrote:
On Wed, Feb 25, 2015 at 07:32:48PM +, Namespace wrote:
void glCheck(lazy void func, string file = __FILE__, uint line
= __LINE__) {
func();
glCheckError(file, line);
}
How can I specify that
On Wednesday, 25 February 2015 at 20:15:10 UTC, anonymous wrote:
On Wednesday, 25 February 2015 at 19:32:50 UTC, Namespace wrote:
void glCheck(lazy void func, string file = __FILE__, uint line
= __LINE__) {
func();
glCheckError(file, line);
}
How can I specify that
On Wed, 25 Feb 2015 20:36:32 +, Namespace wrote:
That last thing works. But I have no clue why. o.O Anyway, thanks a lot!
this is a smart hack. that should be NEVER used in production code.
anyway, it's good that you don't understand it. your code will crash
sooner or later, and you will
Hello,
I have a main.d file which looks like this;
import somepackage.somemodule;
void main()
{
printSomething();
}
Next to maind.d I have a directory 'somepackage' with a file
inside called 'somemodule.d' which looks like this;
void printSomething()
{
import std.stdio :
On Wednesday, 25 February 2015 at 19:32:50 UTC, Namespace wrote:
void glCheck(lazy void func, string file = __FILE__, uint line
= __LINE__) {
func();
glCheckError(file, line);
}
How can I specify that 'func' is @nogc? Or can define the
function otherwise?
First of
The module declaration at the top of the file is needed and must
match the import.
So in somepackage/somemodule.d, add at the top
module somepackage.somemodule;
and then it will all work. While the module declaration is
technically optional, any file that is imported really should
have it
Thanks Adam for the prompt response;
I was following the process of importing modules as described in
TDPL and Ali's book and they both claim that By default, the
name of a module is the same as its filename without the .d and
continue on to describe how the compiler searches for modules. So
I see, that makes sense! thanks
On Wednesday, 25 February 2015 at 21:14:17 UTC, module wrote:
I was following the process of importing modules as described
in TDPL and Ali's book and they both claim that By default,
the name of a module is the same as its filename without the .d
That's true but the key thing is it is the
On Wednesday, 25 February 2015 at 20:46:32 UTC, ketmar wrote:
On Wed, 25 Feb 2015 20:36:32 +, Namespace wrote:
That last thing works. But I have no clue why. o.O Anyway,
thanks a lot!
this is a smart hack. that should be NEVER used in production
code.
anyway, it's good that you don't
On Wednesday, 25 February 2015 at 18:58:13 UTC, anonymous wrote:
We can't make malloc and free actually memory-safe, can we? We
must not mark public unsafe functions @safe/@trusted.
My point was that there is no conceptual difference between
having a named function trusted_malloc!int() and
On Wed, Feb 25, 2015 at 08:20:37PM -0600, captaindet via Digitalmars-d-learn
wrote:
[...]
struct Stuff2Do{
static ubyte[1024*1024] buffer4speed = void; // even if untyped at this
point
// more
}
[...]
Tangential note: be careful with putting a large static array inside a
struct.
On Wednesday, 25 February 2015 at 14:47:37 UTC, Dejan Lekic wrote:
On the Articles page on D Wiki (
http://wiki.dlang.org/Articles ) you have this link:
http://octarineparrot.com/article/view/getting-more-fiber-in-your-diet
It is probably the best article about using fibers in D that I
On Wed, 25 Feb 2015 20:20:37 -0600, captaindet wrote:
On 2015-02-25 19:24, Adam D. Ruppe wrote:
does this warning only apply to dynamic void[] arrays but not to
static void[CTconstant] arrays?
Both of those will be scanned for pointers.
thanks, adam,
so i should always use
struct
On 2015-02-25 20:45, H. S. Teoh via Digitalmars-d-learn wrote:
On Wed, Feb 25, 2015 at 08:20:37PM -0600, captaindet via Digitalmars-d-learn
wrote:
[...]
struct Stuff2Do{
static ubyte[1024*1024] buffer4speed = void; // even if untyped at this
point
// more
}
[...]
Tangential note:
On 2015-02-25 19:24, Adam D. Ruppe wrote:
does this warning only apply to dynamic void[] arrays but not to static
void[CTconstant] arrays?
Both of those will be scanned for pointers.
thanks, adam,
so i should always use
struct Stuff2Do{
static ubyte[1024*1024] buffer4speed = void; //
You don't have to do all that, if it is typed ubyte[] instead of
void[], it shouldn't be scanned at all anyway.
On Wednesday, 25 February 2015 at 19:32:50 UTC, Namespace wrote:
How can I specify that 'func' is @nogc? Or can define the
function otherwise?
An alternative solution would be to use function
templated on an alias.
import std.traits;
void glCheck(alias func)(string file = __FILE__,
On Wed, 25 Feb 2015 21:32:02 +, Namespace wrote:
Instead of some wise talk, you could simply explain it. ;)
i can, but i certainly don't want to. many people are reading this forum,
and i don't want to teach 'em something like this.
signature.asc
Description: PGP signature
On Wed, 25 Feb 2015 21:32:02 +, Namespace wrote:
The code is only used for debugging purposes.
the best way to make your program undebugable is to use debugging code
that will be turned off in production. this way you aren't debugging the
code that will go into production, you debugging
if i understand correctly, static arrays are exempt from GC scanning for memory
pointers
http://dlang.org/garbage.html : Pointers in D can be broadly divided into two categories: Those that point to garbage collected memory, and those that do not. Examples of the latter are pointers created by
On Wednesday, 25 February 2015 at 20:36:33 UTC, Namespace wrote:
On Wednesday, 25 February 2015 at 20:15:10 UTC, anonymous wrote:
[...]
It may be possible to hack through this limitation - NOT
THOUGHT-OUT, NOT TESTED, NOT RECOMMENDED:
---
void glCheck(scope lazy int thing) @nogc;
On Wednesday, 25 February 2015 at 22:16:14 UTC, Ola Fosheim
Grøstad wrote:
My point was that there is no conceptual difference between
having a named function trusted_malloc!int() and trusted_free()
and wrapping them up individually unnamed.
An ad-hoc declared @trusted malloc is just as
On Thursday, 26 February 2015 at 01:15:37 UTC, captaindet wrote:
pointers to static data.
Keep in mind that this is pointers TO static data - that is, if
the object itself is static, it is not to be collected.
static int[5] foo = [1,2,3,4,5]; // foo will never be collected,
even if there
Huh? If you wanted to print an array, then
---
void main()
{
int n=1;
while(n=10_001)
{
v~=n;
n+=5000;
}
foreach(c;v)
{
writeln( current n is ,c );
}
}
---
On Wednesday, 25 February 2015 at 09:49:41 UTC, Kagamin wrote:
It's not only code itself to manage here, but also its
evolution:
http://forum.dlang.org/post/mbaksa$1ers$1...@digitalmars.com
That's why it was proposed to change trusted so that it won't
allow implicit usage of system code.
But
On Wednesday, 25 February 2015 at 09:07:17 UTC, Tobias Pankrath
wrote:
import std.container;
import std.stdio;
void main()
{
DList!int list;
Array!(DList!int.Range) stack;
foreach(i; 0 .. 4)
{
list.stableInsertBack(i);
stack.insertBack(list[]);
}
writefln(list:
Tobias Pankrath wrote:
writefln(stack: %s, stack[]); //fine
This call consumes all ranges stored in stack, so they're empty afterwards.
import std.container;
import std.stdio;
void main()
{
DList!int list;
Array!(DList!int.Range) stack;
foreach(i; 0 .. 4)
{
list.stableInsertBack(i);
stack.insertBack(list[]);
}
writefln(list: %s, list[]); // fine
writefln(stack: %s, stack[]); //fine
41 matches
Mail list logo
