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 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 us
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
str
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 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; // e
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
h
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 a
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;
pragma(mangle
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 unsafe
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
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 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 tru
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 u
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 f
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
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 e
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 : wr
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
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 'fu
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 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
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 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 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 protect
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 symb
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 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 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 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
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 );
}
}
---
Tobias Pankrath wrote:
> writefln("stack: %s", stack[]); //fine
This call consumes all ranges stored in stack, so they're empty afterwards.
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: %
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
forea
41 matches
Mail list logo
