string to uppercase
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
Re: string to uppercase
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 that you can iterate over like
auto upper = someString.asUpperCase;
foreach(c; upper)
{
//do stuff
}
toUpper works with both characters (standard, w and d) as well as
(w|d| )strings, please post the use case that doesn't work.
There is also toUpperInPlace that will modify the string.
Nic
Decompressing bzip2
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 = File("./test.bz2");
ubyte[] data = new ubyte[f.size];
f.rawRead(data);
writeln(data);
ubyte* output;
uint avail_out;
bz_stream* stream = new bz_stream();
stream.avail_out = avail_out;
stream.next_out = output;
int init_error = BZ2_bzDecompressInit(stream, 0, 0);
int bzipresult = BZ2_bzDecompress(stream);
stream.avail_in = cast(uint) data.length;
stream.next_in = cast(ubyte*) data;
bzipresult = BZ2_bzDecompress(stream);
int read = stream.total_out_lo32;
BZ2_bzDecompressEnd(stream);
delete stream;
writeln(output);
}
It's not working at all so any help would be very much
appreciated.
Idiomatic way to generate all possible values a static array of ubyte can have
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 ? Without thinking much, it seems that the loops to generate this would be seriously awefull. By thinking a bit more maybe with a fixed-size big integer it would work, since the value could be casted as the right array type (as long as its length is power of 2) ?
Re: Idiomatic way to generate all possible values a static array of ubyte can have
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 02 03"; I'm sure you get the idea. That can be created easily enough. No I don't get the idea. I think that I haven't well explained. By static array I meant "not dynamic". The 256^256 combinations must be generated on the same ubyte[256], which is a variable, during the program execution.
Re: Idiomatic way to generate all possible values a static array of ubyte can have
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 better:
foreach (b0; randomCover(iota(0,256)))
foreach (b1; randomCover(iota(0,256)))
...
foreach (b255; randomCover(iota(0,256)))
{
...
}
Still not the right approach,
import std.stdio;
import std.random;
import std.range;
void testRunner(bool function(ubyte[128]) test)
{
uint[32] arr;
foreach (v0; randomCover(iota(0U,uint.max)))
foreach (v1; randomCover(iota(0U,uint.max)))
foreach (v2; randomCover(iota(0U,uint.max)))
foreach (v3; randomCover(iota(0U,uint.max)))
foreach (v4; randomCover(iota(0U,uint.max)))
foreach (v5; randomCover(iota(0U,uint.max)))
foreach (v6; randomCover(iota(0U,uint.max)))
foreach (v7; randomCover(iota(0U,uint.max)))
foreach (v8; randomCover(iota(0U,uint.max)))
foreach (v9; randomCover(iota(0U,uint.max)))
foreach (v10; randomCover(iota(0U,uint.max)))
foreach (v11; randomCover(iota(0U,uint.max)))
foreach (v12; randomCover(iota(0U,uint.max)))
foreach (v13; randomCover(iota(0U,uint.max)))
foreach (v14; randomCover(iota(0U,uint.max)))
foreach (v15; randomCover(iota(0U,uint.max)))
foreach (v16; randomCover(iota(0U,uint.max)))
foreach (v17; randomCover(iota(0U,uint.max)))
foreach (v18; randomCover(iota(0U,uint.max)))
foreach (v19; randomCover(iota(0U,uint.max)))
foreach (v20; randomCover(iota(0U,uint.max)))
foreach (v21; randomCover(iota(0U,uint.max)))
foreach (v22; randomCover(iota(0U,uint.max)))
foreach (v23; randomCover(iota(0U,uint.max)))
foreach (v24; randomCover(iota(0U,uint.max)))
foreach (v25; randomCover(iota(0U,uint.max)))
foreach (v26; randomCover(iota(0U,uint.max)))
foreach (v27; randomCover(iota(0U,uint.max)))
foreach (v28; randomCover(iota(0U,uint.max)))
foreach (v29; randomCover(iota(0U,uint.max)))
foreach (v30; randomCover(iota(0U,uint.max)))
foreach (v31; randomCover(iota(0U,uint.max)))
{
arr = [v0,v1,v2,v3,v4,v5,v6,v7,v8,v9,
v10,v11,v12,v13,v14,v15,v16,v17,v18,v19,
v20,v21,v22,v23,v24,v25,v26,v27,v28,v29,
v30, v31
];
writeln(arr);
//if (test(cast(ubyte[128]) arr))
return;
}
}
bool test(ubyte[128] arr)
{
if (arr[0] == 0U)
return true;
else
return false;
}
void main()
{
testRunner();
}
Re: Idiomatic way to generate all possible values a static array of ubyte can have
gives: core.exception.OutOfMemoryError@src/core/exception.d(693): Memory allocation failed
Re: Idiomatic way to generate all possible values a static array of ubyte can have
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 ubyte[256] DATA = cast(ubyte[256])x"00 01 02 03"; I'm sure you get the idea. That can be created easily enough. No I don't get the idea. I think that I haven't well explained. By static array I meant "not dynamic". The 256^256 combinations must be generated on the same ubyte[256], which is a variable, during the program execution. Okay that is a problem then. Stick with generating it I think, can't hard code that number of combinations.
Re: Idiomatic way to generate all possible values a static array of ubyte can have
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)))
foreach (b1; randomCover(iota(0,256)))
...
foreach (b255; randomCover(iota(0,256)))
{
...
}
Re: pass a struct by value/ref and size of the struct
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 incorrect. As Johan pointed out, this is somewhat true for the Win64 ABI (but it firstly copies the argument before passing a pointer to it!), but it's not for the 32-bit x86 and x86_64 System V (used on all non-Windows platforms) ABIs. System V is especially elaborate and may pass structs up to twice the size of a register in 2 registers. Bigger structs passed by value are blitted into the function arguments stack in memory. They are then accessed by the callee via a stack offset, that's correct, but I wouldn't call that implicit-by-ref-passing, as copying does take place, unless the optimizer decides it's unnecessary. So passing structs > 64-bit by value on Win64 never pays off (there's always an indirection); using `const ref(T)` where possible makes sure you at least elide the copy. But then again, you'll very soon find out that it's not really an option as rvalues cannot be passed byref in D, something a lot of people [including myself if not already obvious :)] hate about D. Thank you and Johan for the detailed explanation. You're efforts on improving LDC are much appreciated. My intentions were to say that taking structs by value shouldn't be as expensive as in C++, because of the way D handles copy construction, especially if there is no user-defined postblit (which is quite common), and also because separate compilation is used more rarely. But probably I shouldn't have said that about the size of registers as it depends very much on the ABI and it's not true in general (as you pointed out). BTW, how does LDC handle the `auto ref` and `in` parameter attributes for templated functions (that obviously have their source code available)? Can they be used to prevent indirection when the structure can be passed in registers and to prevent copying when passing by registers is not possible? I find that (at least from a usability standpoint) auto ref works quite well: // UniqueRef has disabled this(this) UniqueRef!Resource r; void use()(auto ref UniqueRef!Resource r); // borrows use(r); // passes ownership of rvalues use(UniqueRef!Resource()) // transfers ownership use(move(r)); // r == UniqueRef.init here //= auto ref add(V)(auto ref V v1, auto ref V v2); // default this(this) Vec3f vec1; // accepts both lvalues and rvalues auto res = add(vec1, Vec3f(1, 2, 3.14));
Re: Direntries seems to on other drives. (windows)
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 whether the path points to an existing file
or directory; use std.file.exists for this purpose.
You are using the wrong function for the job.
The simple explanation is that the path you specified doesn't
actually exist.
Re: Idiomatic way to generate all possible values a static array of ubyte can have
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 there a simple way to do this ? Without thinking much, it seems that the loops to generate this would be seriously awefull. By thinking a bit more maybe with a fixed-size big integer it would work, since the value could be casted as the right array type (as long as its length is power of 2) ? Actually I'd use a hex string. So: static ubyte[256] DATA = cast(ubyte[256])x"00 01 02 03"; I'm sure you get the idea. That can be created easily enough.
Re: pass a struct by value/ref and size of the struct
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 the Win64 ABI (but it firstly copies the argument before passing a pointer to it!), but it's not for the 32-bit x86 and x86_64 System V (used on all non-Windows platforms) ABIs. System V is especially elaborate and may pass structs up to twice the size of a register in 2 registers. Bigger structs passed by value are blitted into the function arguments stack in memory. They are then accessed by the callee via a stack offset, that's correct, but I wouldn't call that implicit-by-ref-passing, as copying does take place, unless the optimizer decides it's unnecessary. So passing structs > 64-bit by value on Win64 never pays off (there's always an indirection); using `const ref(T)` where possible makes sure you at least elide the copy. But then again, you'll very soon find out that it's not really an option as rvalues cannot be passed byref in D, something a lot of people [including myself if not already obvious :)] hate about D. Thank you and Johan for the detailed explanation. You're efforts on improving LDC are much appreciated. My intentions were to say that taking structs by value shouldn't be as expensive as in C++, because of the way D handles copy construction, especially if there is no user-defined postblit (which is quite common), and also because separate compilation is used more rarely. But probably I shouldn't have said that about the size of registers as it depends very much on the ABI and it's not true in general (as you pointed out). BTW, how does LDC handle the `auto ref` and `in` parameter attributes for templated functions (that obviously have their source code available)? Can they be used to prevent indirection when the structure can be passed in registers and to prevent copying when passing by registers is not possible?
Address of an element of AA
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.
Re: Idiomatic way to generate all possible values a static array of ubyte can have
[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
Re: No aa.byKey.length?
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 be like doing aa.byKeys().array().length. And associate arrays already have length. You can do auto len = aa.length; The problem is when you want to operate on a range, and the function that you want to pass it to wants length on the range. If byKeys returned a range with length, then that would work, but since it doesn't, it doesn't. Having other ways to get the length doesn't help. - Jonathan M Davis
Re: Address of an element of AA
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 table is reconstructed e.g. when there are sufficiently many elements in the array. Ali
Re: Address of an element of AA
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 aa[int]; aa[10] = 123; auto p = [10]; writeln(*p); aa[11] = 121; // add Element writeln(*p); aa[10] = 1; // change Element writeln(*p); aa.rehash; // reorganize writeln(*p); aa.remove(10); aa[10] = 3; // remove & add Element writeln(*p); results in 123 // correct 123 // correct 1 // correct 1 // correct because I'm lucky 1 // wrong What Alis said is "rehash", a combination of remove/add or any other reorganisation, which could change memory usage and data locations. By the way...why do you need a pointer to an AA-Element? Regards, Ozan
Re: No aa.byKey.length?
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
Re: Idiomatic way to generate all possible values a static array of ubyte can have
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; 0 .. range) foreach(xn; 0 .. range) foreach(xn; 0 .. range) is enough. But still silly in term of complexity. I have to go for a heuristic approach. UNtil that I still use a prng.
Re: Idiomatic way to generate all possible values a static array of ubyte can have
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 that D's GC is conservative, so false pointers, especially for large arrays also can cause problems. I'll note that even if it worked, this code will never complete in your lifetime, or even your great great grandchild's lifetime. I don't understand the point of doing this. I'll also note that if you just want to test a *subset* of all the possible inputs (given the length of time taken to test all these), you probably want to change different elements each time through the loop. Your code spends a long time testing the same elements in the first slots. Given your test code is just looking at the first element, this isn't very good test coverage. I honestly think you are better off just generating random arrays, even if it results in some overlap (unlikely to be relevant). -Steve
Re: Address of an element of AA
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 add or remove keys, it will remain at the same place. Adding other keys can cause a rehash, and removing keys (even if it isn't that one) can cause a rehash. Note: in the current implementation, it WILL remain in the same location, even on a rehash. This is because the AA is implemented as an array of pointers to elements. A rehash does not reallocate the elements. But this is NOT guaranteed to stay this way in the future. Note: reason the spec does not say this is because we don't want to constrain the implementation to behave a certain way. -Steve
