On Friday, 30 June 2017 at 20:13:37 UTC, H. S. Teoh wrote:
On Fri, Jun 30, 2017 at 07:57:22PM +, FoxyBrown via
Digitalmars-d-learn wrote: [...]
[...]
Um... the docs explicit say that dirEntries is lazy, did you
not see that?
[...]
It is possible that dmd has the same problem but I
On Fri, Jun 30, 2017 at 07:57:22PM +, FoxyBrown via Digitalmars-d-learn
wrote:
[...]
> The only way this can happen is if the rename command is somehow
> feeding back in to the algorithm. Since the problem goes away when I
> pre-compute dirEntries, it suggests that dirEntries is being lazily
On Friday, 30 June 2017 at 17:32:33 UTC, H. S. Teoh wrote:
On Fri, Jun 30, 2017 at 12:50:24PM +, FoxyBrown via
Digitalmars-d-learn wrote:
I am using dirEntries to iterate over files to rename them.
I am renaming them in a loop(will change but added code for
testing).
In DMD the
On Fri, Jun 30, 2017 at 12:50:24PM +, FoxyBrown via Digitalmars-d-learn
wrote:
> I am using dirEntries to iterate over files to rename them.
>
> I am renaming them in a loop(will change but added code for testing).
>
>
> In DMD the renaming works but in LDC the renaming fails. It fails in
On Friday, 30 June 2017 at 15:07:29 UTC, Murzistor wrote:
On Friday, 30 June 2017 at 12:50:24 UTC, FoxyBrown wrote:
The funny thing is, newName is printed wrong so Recompute is
effected by the rename.
Does LDC use Unicode?
Or, maybe, standard library under LDC does not support Unicode
- then
On Friday, 30 June 2017 at 12:50:24 UTC, FoxyBrown wrote:
The funny thing is, newName is printed wrong so Recompute is
effected by the rename.
Does LDC use Unicode?
Or, maybe, standard library under LDC does not support Unicode -
then it is a serious bug.
Do you use any non-ASCII symbols?
I am using dirEntries to iterate over files to rename them.
I am renaming them in a loop(will change but added code for
testing).
In DMD the renaming works but in LDC the renaming fails. It fails
in a way that I can't quite tell and I cannot debug because
visual D is not working properly
On Friday, 20 January 2017 at 11:58:39 UTC, Rene Zwanenburg wrote:
On Friday, 20 January 2017 at 08:19:57 UTC, Chris M. wrote:
[...]
My guess:
The encrypted output will be a bit longer than your input.
You're not getting an out of bounds exception during encryption
since OpenSSL only has
me a very
strange bug.
[...]
auto encOut = new ubyte[inputStr.length];
// Encrypt and convert to base64
AES_set_encrypt_key(aesKey.ptr, aesKey.sizeof * 8, );
AES_ecb_encrypt(inputStr.ptr, encOut.ptr, ,
AES_ENCRYPT);
Here's the problem. I tried running this without
s-d-learn@puremagic.com> wrote:
> I have no idea if this is an issue with D, or OpenSSL, or if I'm just
> doing something completely wrong. I'm writing a program that will either
> encrypt or decrypt a string using AES in ECB mode (for a school assignment)
> and it's giving me
I have no idea if this is an issue with D, or OpenSSL, or if I'm
just doing something completely wrong. I'm writing a program that
will either encrypt or decrypt a string using AES in ECB mode
(for a school assignment) and it's giving me a very strange bug.
encrypt and decrypt are both bools
On Tuesday, 19 July 2016 at 15:18:20 UTC, Steven Schveighoffer
wrote:
Please add what you can to the report.
ok, i found why it doesn't work with static libs. not sure what
to do next, though... added the info to bugzilla.
On Tuesday, 19 July 2016 at 15:18:20 UTC, Steven Schveighoffer
wrote:
It's affecting phobos devs too, we are aware of the issue:
https://issues.dlang.org/show_bug.cgi?id=16291
i see, thank you. my searching foo failed to find that issue.
i guess i have to use digger to find the commit that
On 7/19/16 11:08 AM, ketmar wrote:
i'm using git master (updated daily), and recently found very strange
thing.
when i'm linking my programs with libphobos2.a, module ctor from
"std.internal.phobosinit" is not called, but when i'm linking with .so,
everything is ok.
it is easy to check:
i'm using git master (updated daily), and recently found very
strange thing.
when i'm linking my programs with libphobos2.a, module ctor from
"std.internal.phobosinit" is not called, but when i'm linking
with .so, everything is ok.
it is easy to check: `EncodingScheme.create("utf-8")` will
bug.d
88
@trusted:
import std.datetime : benchmark;
import std.stdio: writefln, writeln;
alias double Real;
void ben(alias fun)(string msg, uint n = 1_000_000) {
auto b = benchmark!fun(n);
writefln( %s %s ms, msg, b[0].to!(msecs, int));
}
On 02/26/2012 09:06 PM, Caligo wrote:
Once you have those two files, compile with this:
dmd -unittest t1.d bug.d
and then run t1:
./t1
The output you get should look like this:
...
[0, 4, 0, 0, 0, 0, 0, 2, 0, 0, 1, 2, 0, 1, 0, 0]
I get:
...
[0, 4, 0, 0, 0, 0, 0, 2, 0, 0, 1, 2, 0, 1, 0,
Thanks. I have reported the bug:
http://d.puremagic.com/issues/show_bug.cgi?id=7595
This is a DMD bug, and fixed in the pending pull request 91:
https://github.com/D-Programming-Language/dmd/pull/91
David
On 4/5/11 6:19 AM, Jose Armando Garcia wrote:
dmd can compile and run to follow the code:
unittest
{
spawn(fun);
}
void fun(int i) { writeln(i); }
Which if you are
On Tue, 05 Apr 2011 01:19:08 -0300, Jose Armando Garcia wrote:
dmd can compile and run to follow the code:
unittest
{
spawn(fun);
}
void fun(int i) { writeln(i); }
Which if you are lucky segfaults and if you are unlucky prints garbage!
The problem is that spawn doesn't checks
20 matches
Mail list logo
