Is there any easy way to convert a string to uppercase? I tried
s.asUpperCase, but it returns a ToCaserImpl, not a string, and it
cant be cast to string. I also tried toUpper but it wasnt working
with strings
On Sunday, 3 April 2016 at 03:05:08 UTC, stunaep wrote:
Is there any easy way to convert a string to uppercase? I tried
s.asUpperCase, but it returns a ToCaserImpl, not a string, and
it cant be cast to string. I also tried toUpper but it wasnt
working with strings
asUpperCase returns a range
I am trying to use the bzip2 bindings that are available on
code.dlang.org/packages, but I am having a really hard time using
it due to the pointers. It needs to be an array once it's
decompressed.
Here is what I have:
import std.stdio;
import bzlib;
void main(string[] args)
{
File f =
Let's say I have a ubyte[256]. I want to test all the possible
values this array can have on a function.
Currently I fill it for each new test with std.random.uniform but
I'm sure that I loose some time with randomizing and with the
tests that are repeated. Is there a simple way to do this ?
On Saturday, 2 April 2016 at 08:27:07 UTC, rikki cattermole wrote:
On 02/04/2016 9:20 PM, jkpl wrote:
Let's say I have a ubyte[256]. I want to test all the possible
values
this array can have on a function.
Actually I'd use a hex string.
So:
static ubyte[256] DATA = cast(ubyte[256])x"00 01
On Saturday, 2 April 2016 at 09:11:34 UTC, jkpl wrote:
On Saturday, 2 April 2016 at 08:48:10 UTC, rikki cattermole
wrote:
On 02/04/2016 9:36 PM, jkpl wrote:
On Saturday, 2 April 2016 at 08:27:07 UTC, rikki cattermole
wrote:
Okay that is a problem then.
Yes clearly!
Maybe this, a bit
gives: core.exception.OutOfMemoryError@src/core/exception.d(693):
Memory allocation failed
On 02/04/2016 9:36 PM, jkpl wrote:
On Saturday, 2 April 2016 at 08:27:07 UTC, rikki cattermole wrote:
On 02/04/2016 9:20 PM, jkpl wrote:
Let's say I have a ubyte[256]. I want to test all the possible values
this array can have on a function.
Actually I'd use a hex string.
So:
static
On Saturday, 2 April 2016 at 08:48:10 UTC, rikki cattermole wrote:
On 02/04/2016 9:36 PM, jkpl wrote:
On Saturday, 2 April 2016 at 08:27:07 UTC, rikki cattermole
wrote:
Okay that is a problem then.
Yes clearly!
Maybe this, a bit better:
foreach (b0; randomCover(iota(0,256)))
On Saturday, 2 April 2016 at 09:28:58 UTC, ZombineDev wrote:
On Wednesday, 23 March 2016 at 19:39:49 UTC, kinke wrote:
On Tuesday, 22 March 2016 at 07:35:49 UTC, ZombineDev wrote:
If the object is larger than the size of a register on the
target machine, it is implicitly passed by ref
That's
On Friday, 1 April 2016 at 02:05:23 UTC, Taylor Hillegeist wrote:
Even though i just checked for a valid path.
[...]
if(!args[1].buildNormalizedPath.isValidPath){writeln("Path is
invalid! "); return;}
From https://dlang.org/library/std/path/is_valid_path.html :
It does *not* check
On 02/04/2016 9:20 PM, jkpl wrote:
Let's say I have a ubyte[256]. I want to test all the possible values
this array can have on a function.
Currently I fill it for each new test with std.random.uniform but I'm
sure that I loose some time with randomizing and with the tests that are
repeated. Is
On Wednesday, 23 March 2016 at 19:39:49 UTC, kinke wrote:
On Tuesday, 22 March 2016 at 07:35:49 UTC, ZombineDev wrote:
If the object is larger than the size of a register on the
target machine, it is implicitly passed by ref
That's incorrect. As Johan pointed out, this is somewhat true
for
Hi !
I can't find this in specs.
If i add an element to AA:
aa[10] = 123;
Will [10] be always the same (of course i don't remove that
key) ?
Thanks for a reply.
I think specs should be enhanced.
[Probably a repost.]
On 04/02/2016 01:20 AM, jkpl wrote:
Let's say I have a ubyte[256]. I want to test all the possible values
this array can have on a function.
nextPermutation():
https://dlang.org/phobos/std_algorithm_sorting.html#nextPermutation
Ali
On Saturday, April 02, 2016 15:38:30 Ozan via Digitalmars-d-learn wrote:
> On Friday, 1 April 2016 at 20:50:32 UTC, Yuxuan Shui wrote:
> > Why?
> >
> > This is annoying when I need to feed it into a function that
> > requires hasLength.
>
> aa.keys.length
That allocates an array. Doing that would
On 04/02/2016 07:22 AM, Temtaime wrote:
Hi !
I can't find this in specs.
If i add an element to AA:
aa[10] = 123;
Will [10] be always the same (of course i don't remove that key) ?
Thanks for a reply.
I think specs should be enhanced.
No, the underlying buffer can be relocated when the hash
On Saturday, 2 April 2016 at 14:22:01 UTC, Temtaime wrote:
Hi !
I can't find this in specs.
If i add an element to AA:
aa[10] = 123;
Will [10] be always the same (of course i don't remove that
key) ?
Thanks for a reply.
I think specs should be enhanced.
Running following
int
On Friday, 1 April 2016 at 20:50:32 UTC, Yuxuan Shui wrote:
Why?
This is annoying when I need to feed it into a function that
requires hasLength.
aa.keys.length
On Saturday, 2 April 2016 at 18:32:03 UTC, Steven Schveighoffer
wrote:
I honestly think you are better off just generating random
arrays, even if it results in some overlap (unlikely to be
relevant).
-Steve
Yes I know, I've realized how it's silly. just foreach(xn; 0 ..
range) foreach(xn;
On 4/2/16 5:47 AM, jkpl wrote:
gives: core.exception.OutOfMemoryError@src/core/exception.d(693): Memory
allocation failed
Probably because randomCover needs to allocate a bool for all the
elements it has already covered, so you are allocating 32 * 4G bools.
How much RAM do you have? Note
On 4/2/16 10:22 AM, Temtaime wrote:
Hi !
I can't find this in specs.
If i add an element to AA:
aa[10] = 123;
Will [10] be always the same (of course i don't remove that key) ?
Thanks for a reply.
I think specs should be enhanced.
Depends on your definition of "always". As long as you don't
22 matches
Mail list logo
