On 02/02/2013 10:48 PM, Chris Cain wrote:
> Okay, I've got a question for you Ali... why is it that sometimes as
> Elements increased, there were a _drop_ of allocations?
>
> So, these in particular:
>
> On Sunday, 3 February 2013 at 06:02:04 UTC, Ali Çehreli wrote:
>> Elements: 65536, Allocations
On 03.02.2013 06:09, Ali Çehreli wrote:
> You need 'static this()':
>
> import std.stdio;
>
> string[string] ch_Description;
>
> static this()
> {
> ch_Description = [ "kill" : "kills a process",
>"pause" : "pauses a process" ];
> }
>
> void main() {
> // ...
>
Okay, I've got a question for you Ali... why is it that sometimes
as Elements increased, there were a _drop_ of allocations?
So, these in particular:
On Sunday, 3 February 2013 at 06:02:04 UTC, Ali Çehreli wrote:
Elements: 65536, Allocations: 9, Moved: 1012
Elements: 131072, Allocations: 10, M
On 02/02/2013 02:23 AM, dennis luehring wrote:
i've got something like an streaming/converter system
and parts of the specialised converters are stateless other statefull
is there any way to force pureness/stateless-ness through the base
class or an interface in D?
That seems to be the case:
On 02/02/2013 08:37 PM, Ali Çehreli wrote:
> On 02/02/2013 06:22 PM, timotheecour wrote:
> > What's the rationale behind array appending adding a page size to
> > capacity
>
> It is not always the case. The page is added only if the next page
> conveniently free. There is no cost for that "alloc
On 02/02/2013 08:00 AM, timewulf wrote:
> After searching for the differences to my code, I found my fault:
It is not your fault. :)
> Now I've just to look, how to declare this array in the way of public
> constants.
You need 'static this()':
import std.stdio;
string[string] ch_Description;
On Sunday, 3 February 2013 at 02:28:26 UTC, timotheecour wrote:
here goes:
http://d.puremagic.com/issues/show_bug.cgi?id=9444
please see my added comment in 9444 regarding capturing std err
instead of displaying it.
actually the new std.process pull request
(http://forum.dlang.org/thread/k5u
On Sunday, 3 February 2013 at 00:34:48 UTC, Namespace wrote:
C have also runtime fixed size arrays.
They were added in C99 (variable length arrays, they're called).
C++, on the other hand, still doesn't have them.
here goes:
http://d.puremagic.com/issues/show_bug.cgi?id=9444
please see my added comment in 9444 regarding capturing std err
instead of displaying it.
What's the rationale behind array appending adding a page size to
capacity instead of doubling, after the size of the array reaches
a certain size (cf what std::vector does) ? That seems like an
example of (evil?) early optimization.
T[]a;
int n=some big value;
foreach(i;0..n)
a~=T.in
On 2/3/13, timotheecour wrote:
> Isn't there a unittest to test this?
The only unittest is unfortunately pretty bad:
unittest
{
auto x = shell("echo wyda");
}
Please feel free to file a bug:
http://d.puremagic.com/issues/enter_bug.cgi?product=D
The doc for std.process.shell says "If the process could not be
started or exits with an error code, throws an exception."
However on OSX I'm having a different kind of behavior.
Isn't there a unittest to test this?
---
import std.process;
import std.stdio;
void main(){
shell("asfasfas
On Sunday, 3 February 2013 at 01:41:26 UTC, Jonathan M Davis
wrote:
reserve should guarantee that you have at least the requested
amount of memory already allocated, or it's broken. Its whole
purpose is to guarantee that capacity is at least as large as
the amount being reserved so that you can
On Sunday, February 03, 2013 02:27:16 Era Scarecrow wrote:
> On Saturday, 2 February 2013 at 15:47:37 UTC, FG wrote:
> > Yeah but let us move reallocation out of the equation.
> > Reserving space limits the amount of RAM used and can avoid
> > reallocations all together but in a little test it came
On Saturday, 2 February 2013 at 15:47:37 UTC, FG wrote:
Yeah but let us move reallocation out of the equation.
Reserving space limits the amount of RAM used and can avoid
reallocations all together but in a little test it came out
that still appender is 2.5-4 times faster than tab ~= str,
wher
But as far as I can see all your are fine with the wrapped
struct solution.
->
But as far as I can see, all of you are happy with the current
wrapped struct solution.
We need an 'edit' button.
On Saturday, 2 February 2013 at 22:39:58 UTC, monarch_dodra wrote:
On Saturday, 2 February 2013 at 22:15:56 UTC, Namespace wrote:
My real question was: will we ever have fixed size arrays at
runtime?
I see no reason why we couldn't, the only problem is a syntax
one. If you beat the syntax (by
On 2013-02-02 22:47, monarch_dodra wrote:
I suggest you read this:
http://dlang.org/d-array-article.html
It is a very interesting read, especially for those of us with C++ background.
Thank you for pointing me to that article.
I have read it months ago and forgotten the important parts.
Now it
On Saturday, 2 February 2013 at 22:15:56 UTC, Namespace wrote:
My real question was: will we ever have fixed size arrays at
runtime?
I see no reason why we couldn't, the only problem is a syntax
one. If you beat the syntax (by wrapping it in a struct) then you
can do it no problem:
//
T
On 2013-02-02 22:57, FG wrote:
On 2013-02-02 22:33, Steven Schveighoffer wrote:
Heap block sizes start at 16. One byte overhead is used to store the array
length, so the minimum size of ANY array allocation is 15 bytes.
How is the length stored because I see only strange numbers in that byte.
My real question was: will we ever have fixed size arrays at
runtime?
On 2013-02-02 22:33, Steven Schveighoffer wrote:
Heap block sizes start at 16. One byte overhead is used to store the array
length, so the minimum size of ANY array allocation is 15 bytes.
How is the length stored because I see only strange numbers in that byte.
foreach (end; 2..31) {
On Saturday, 2 February 2013 at 19:49:39 UTC, FG wrote:
On 2013-02-02 19:53, Namespace wrote:
Are you uncomfortable, because it may allocate twice as much
space
as you need (for bigger color_data)?
Yes, that's the point.
Sorry, I cannot express myself very well in English.
You're right. It'
On Sat, 02 Feb 2013 11:36:28 -0500, Namespace
wrote:
Currently something like new ubyte[4]; reserves space for _at least_ 4
items.
But if I want to store now something, the index isn't 0, it's 4.
Let me explain that on a brief example:
[code]
import std.stdio;
void main() {
ubyte[
On Sat, 02 Feb 2013 10:47:39 -0500, FG wrote:
On 2013-02-02 13:50, Era Scarecrow wrote:
On Saturday, 2 February 2013 at 11:33:07 UTC, Namespace wrote:
I'm was quite surprised as I had heard the first time of these
'appender'.
Therefore I'm asking me:
Why is the 'appender' method so much mor
On 2013-02-02 19:53, Namespace wrote:
Are you uncomfortable, because it may allocate twice as much space
as you need (for bigger color_data)?
Yes, that's the point.
Sorry, I cannot express myself very well in English.
You're right. It's surprising for anyone used to dealing with std::vector,
Are you uncomfortable, because it may allocate twice as much
space
as you need (for bigger color_data)?
Yes, that's the point.
Sorry, I cannot express myself very well in English.
On 2013-02-02 19:01, Namespace wrote:
Example:
struct Color {
public:
ubyte[4] colors;
}
ubyte[] data = new ubyte[color_data.length * 4]; // enough storage
foreach (ref const Color col; color_data) {
data ~= col.colors;
}
Sorry, but what is the point of data having only 4 bytes rese
On Saturday, 2 February 2013 at 17:48:14 UTC, FG wrote:
On 2013-02-02 17:36, Namespace wrote:
ubyte[] arr = new ubyte[4];
arr ~= 4; // desirable: [4, 0, 0, 0];
Why not arr[0] = 4? What is so special about having 4 elements?
Example:
struct Color {
public:
ubyte[4] colors;
}
uby
02-Feb-2013 18:55, Rainer Schuetze пишет:
On 02.02.2013 14:16, Michael wrote:
Hi,
diff versions of Visual Studio may have diff installation path.
So here mine in proper order:
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\
LINKCMD64=%VCINSTALLDIR%\bin\x86_amd64\link.exe
02-Feb-2013 00:39, FG пишет:
On 2013-02-01 20:33, Dmitry Olshansky wrote:
Mine reiteration on it, with a bit of help from std.parallelism.
std.parallelism uses thread pool thus it's somewhat faster then
creating threads
anew.
Interestingly, threads+barrier here wasn't much slower than tasks:
1
On 2013-02-02 17:36, Namespace wrote:
ubyte[] arr = new ubyte[4];
arr ~= 4; // desirable: [4, 0, 0, 0];
Why not arr[0] = 4? What is so special about having 4 elements?
As I looked at arr.length and arr.capacity for the first time I was schocked: I
want only space for 4 items, but I
No one said that this is a problem, or? (;
But why should I generate an array with size 4 if an append of me
resize it to 5?
I'm asking because we have currently nothing (nice) for _fixed_
size arrays at runtime. That should be change. Therefore new
T[size] would be a good.
On Saturday, 2 February 2013 at 16:36:29 UTC, Namespace wrote:
Currently something like new ubyte[4]; reserves space for _at
least_ 4 items.
But if I want to store now something, the index isn't 0, it's 4.
Let me explain that on a brief example:
[code]
import std.stdio;
void main() {
u
Currently something like new ubyte[4]; reserves space for _at
least_ 4 items.
But if I want to store now something, the index isn't 0, it's 4.
Let me explain that on a brief example:
[code]
import std.stdio;
void main() {
ubyte[] arr = new ubyte[4];
arr ~= 4; // desirable: [4, 0
Works now.
On 02.02.2013 17:06, FG wrote:
> On 2013-02-02 16:06, Namespace wrote:
>> string[string] ch_Description = [
>> "kill" : "kills a process",
>> "pause" : "pauses a process"
>> ];
>>
>> writeln(ch_Description); // does not work, but it should
>
> Doesn't work in the c
Yes! very good idea!
I also added something like static assert(staticIndexOf!(T, Children) !=
-1); to get a compile time error when someone wants to get something
which is not there.
thanks
christian
On 2/2/13 14:13 , Philippe Sigaud wrote:
On Fri, Feb 1, 2013 at 11:04 PM, Christian Köstli
On Saturday, 2 February 2013 at 16:06:09 UTC, FG wrote:
On 2013-02-02 16:06, Namespace wrote:
string[string] ch_Description = [
"kill" : "kills a process",
"pause" : "pauses a process"
];
writeln(ch_Description); // does not work, but it should
Doesn't work in the
On 2013-02-02 16:06, Namespace wrote:
string[string] ch_Description = [
"kill" : "kills a process",
"pause" : "pauses a process"
];
writeln(ch_Description); // does not work, but it should
Doesn't work in the current version? In DMD 2.060 it works.
On 02.02.2013 16:06, Namespace wrote:
> import std.stdio;
>
> void main() {
> string[string] ch_Description = [
> "kill" : "kills a process",
> "pause" : "pauses a process"
> ];
>
> // writeln(ch_Description); // does not work, but it should
> foreach (string k
On 2013-02-02 16:22, Josh wrote:
Maybe because of output buffering and you need to add flush?
How do I do that? I've never heard of flush before.
writeln("..."); stdout.flush();
C also has flush, in the form of fflush(stdout);
I've never come across Appenders before. Could you please e
On 2013-02-02 13:50, Era Scarecrow wrote:
On Saturday, 2 February 2013 at 11:33:07 UTC, Namespace wrote:
I'm was quite surprised as I had heard the first time of these 'appender'.
Therefore I'm asking me:
Why is the 'appender' method so much more efficient?
Because concatenation likely will
I've never come across Appenders before. Could you please
explain them a little bit, and what each call in your modified
code does?
Thanks,
Josh
http://dlang.org/phobos/std_array.html#.Appender
And read Era's post.
On Saturday, 2 February 2013 at 11:16:50 UTC, FG wrote:
On 2013-02-02 07:49, Josh wrote:
But main's first writeln actually outputs after f.close().
Maybe because of output buffering and you need to add flush?
How do I do that? I've never heard of flush before.
The program uses ~1GB of RAM o
It seems you are right. I get the same error. You should open a
bug report for this.
But as long as it isn't fixed you can use an output via foreach.
import std.stdio;
void main() {
string[string] ch_Description = [
"kill" : "kills a process",
"pause" : "
On 02.02.2013 14:16, Michael wrote:
Hi,
diff versions of Visual Studio may have diff installation path.
So here mine in proper order:
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\
LINKCMD64=%VCINSTALLDIR%\bin\x86_amd64\link.exe
WindowsSdkDir=C:\Program Files (x86)\Micr
Hi all,
in the moment I'm running against a wall:
I want to put some strings together into an ass. array:
For example a command with it's description like the following.
char[char[]] ch_Description = [ 'kill' : 'kills a process',
'pause' : 'pauses a process' ]
I
On 02.02.2013 12:41, Gor Gyolchanyan wrote:
Good day,
I'm trying to write a script in D for building D projects. I want to set
the environment variable LIB for optlink to be able to pick up library
files from where I put them after compiling dependencies.
The problem is, that the std.process.
Hi,
diff versions of Visual Studio may have diff installation path.
So here mine in proper order:
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\
LINKCMD64=%VCINSTALLDIR%\bin\x86_amd64\link.exe
WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\
P.S.: I
On Fri, Feb 1, 2013 at 11:04 PM, Christian Köstlin
wrote:
> Hi Philippe,
>
> wonderful solution. I also added
> T get(T)() {
> return components[staticIndexOf!(T, Children)];
> }
> to the class to get the Children out by type (works as long as there is only
> one child of each type in the tuple)
On Saturday, 2 February 2013 at 11:33:07 UTC, Namespace wrote:
I'm was quite surprised as I had heard the first time of these
'appender'.
Therefore I'm asking me:
Why is the 'appender' method so much more efficient?
Because concatenation likely will end up relocating the memory
over and over
Good day,
I remember hearing something about separating 32-bit and 64-bit
environment configuration in sc.ini, but I don't seem to see any
changes. I really don't get why is sc.ini so messed up and not
working? Is it so very hard to make a configuration file? I can't
get 64-bit version to wor
Good day,
I'm trying to write a script in D for building D projects. I want
to set the environment variable LIB for optlink to be able to
pick up library files from where I put them after compiling
dependencies.
The problem is, that the std.process.setenv is only available
under Linux and s
I'm was quite surprised as I had heard the first time of these
'appender'.
Therefore I'm asking me:
Why is the 'appender' method so much more efficient?
On 2013-02-02 07:49, Josh wrote:
But main's first writeln actually outputs after f.close().
Maybe because of output buffering and you need to add flush?
The program uses ~1GB of RAM overall, even though main.results is ~50MB
according to memSize.
Wrong comparison. You should have compared t
i've got something like an streaming/converter system
and parts of the specialised converters are stateless other statefull
is there any way to force pureness/stateless-ness through the base
class or an interface in D?
On Saturday, 2 February 2013 at 09:59:07 UTC, bearophile wrote:
SaltySugar:
My code:
In Phobos there isn't something like random.choice() of Python.
This code doesn't work with truly Unicode strings (better to
use a dstring or dchar[] for that, unless you want to walk the
string every time
SaltySugar:
My code:
In Phobos there isn't something like random.choice() of Python.
This code doesn't work with truly Unicode strings (better to use
a dstring or dchar[] for that, unless you want to walk the string
every time you want to extract a random item):
import std.stdio, std.ran
Hi
Thank you for your help.
I wrapped some functions of Qt.
After updating to Qt5.0.1 it suddenly worked.
The lib is c++. Its probably a bit simple. but good to know that
there is no problem with clang and dmd interop so far.
thx
60 matches
Mail list logo
