Re: BitArray shift left/right confusion.
On Wednesday, 27 December 2017 at 20:45:49 UTC, Biotronic wrote: BitArray is apparently a mess. Thanks for your confirmation, digging and reporting issues https://issues.dlang.org/show_bug.cgi?id=18133 and https://issues.dlang.org/show_bug.cgi?id=18134 (Turns out we both live in the same country).
Re: how to localize console and GUI apps in Windows
you can just set console CP to UTF-8: https://github.com/CyberShadow/ae/blob/master/sys/console.d
Re: Don't expect class destructors to be called at all by the GC
On Thursday, December 28, 2017 10:37:09 H. S. Teoh via Digitalmars-d-learn wrote: > On Sun, Dec 24, 2017 at 02:07:26PM -0700, Jonathan M Davis via > Digitalmars-d-learn wrote: [...] > > > Regardless, even if it were the case that it were guaranteed that all > > finalizers were run when the program exited, it would still be > > terrible practice to rely on it. It's trivial to end up in a situation > > where no collection is run for quite some time (e.g. just don't do > > much memory allocation for a while), which would leave any resources > > that needed to be freed by a finalizer unfreed for quite a while even > > though they weren't needed anymore. So practically speaking, it > > doesn't really matter where the finalizers are guaranteed to run. > > Relying on them to be run rather than forcing them to be run via > > destroy or using some other helper function is just going to cause > > problems, so it's just plain bad practice to rely on finalizers to be > > run to release resources. That's just life with GC's in general, not > > just D's. It's why C# has the while dispose/IDisposable thing, and why > > D code should either be using destroy to deal with freeing resources > > for a class or using structs on the stack for resources that need to > > be freed. Or alternate memory strategies can be used via > > std.experimental.allocator. The GC works great for lots of stuff but > > not for system resources. Honestly, in some ways, we'd be better off > > if D didn't even have finalizers. > > [...] > > This makes me wonder if a better approach to memory management is to use > refcounting by default, and fallback to the GC to collect cycles. > > In my current project, I'll probably end up having to use > RefCounted!Database just so I can have deterministic releasing of > database handles without needing to worry about dangling references that > may still be lingering around. (Currently, I'm just calling .destroy > directly on the handle when I'm done with it, but there's a slim > possibility that there might be dangling references left somewhere. So > that needs to be addressed at some point.) The GC works perfectly well for most things. You just have to be aware of its downsides - and that includes being aware of what's going to happen if you try and use it to manage system resources. For that, ref-counting is almost certainly going to be better (though there are probably cases where it doesn't matter, because it's not really a problem if the resources aren't freed before the program exits). In any case, for a lot of the cases where dispose/IDisposable would be used in C#, ref-counting is almost certainly what the code should be doing (either that or scope statements if what's being done is localized and not common enough to create a type to use with RAII). That's probably on the list of things that needs to be written up somewhere as being among best practices for D. There are probably too many things like that that are sitting in the heads of a lot of folks but not necessarily well communicated to others - though this particular issue may have been discussed in the recent GC articles. I don't know. I still need to read them. - Jonathan M Davis
Re: how to localize console and GUI apps in Windows
On Thu, Dec 28, 2017 at 05:56:32PM +, Andrei via Digitalmars-d-learn wrote:
> There is one everlasting problem writing Cyrillic programs in Windows:
> Microsoft consequently invented two much different code pages for
> Russia and other Cyrillic-alphabet countries: first was MSDOS-866 (and
> alike), second Windows-1251. Nowadays MS Windows uses first code page
> for console programs, second for GUI applications, and there always
> are many workarounds to get proper translation between them. Mostly a
> programmer should write program sources either in one code page for
> console and other for GUI, or use .NET, which basically uses UTF8 in
> sources and makes seamless translation depending on back end.
>
> In D language which uses only UTF8 for string encoding I cannot write
> neither MS866 code page program texts, nor Windows-1251 - both cases
> end in a compiler error like "Invalid trailing code unit" or "Outside
> Unicode code space". And writing Cyrillic strings in UTF8 format is
> fatal for both console and GUI Windows targets.
>
> My question is: is there any standard means to translate Cyrillic or
> any other localized UTF8 strings for console and GUI output in D
> libraries. If so - where I can get more information and good example.
> Google would not help.
[...]
The string / wstring / dstring types in D are intended to be Unicode
strings. If you need to use other encodings, you really should be using
ubyte[] or const(ubyte)[] or immutable(ubyte)[], instead of string.
One approach is to use UTF-8 in your code, and only translate to one of
the code pages when you need to produce output. I wrote a small module
for translating to/from KOI8-R when dealing with Russian text; you might
find it helpful:
---
/**
* Module to convert between UTF and KOI8-R
*/
module koi8r;
import std.string;
import std.range;
static immutable ubyte[0x450 - 0x410] utf2koi8r = [
225, 226, 247, 231, 228, 229, 246, 250, // АБВГДЕЖЗ
233, 234, 235, 236, 237, 238, 239, 240, // ИЙКЛМНОП
242, 243, 244, 245, 230, 232, 227, 254, // РСТУФХЦЧ
251, 253, 255, 249, 248, 252, 224, 241, // ШЩЪЫЬЭЮЯ
193, 194, 215, 199, 196, 197, 214, 218, // абвгдежз
201, 202, 203, 204, 205, 206, 207, 208, // ийклмноп
210, 211, 212, 213, 198, 200, 195, 222, // рстуфхцч
219, 221, 223, 217, 216, 220, 192, 209 // шщъыьэюя
];
/**
* Translates a range of UTF characters into KOI8-R characters.
* Returns: Range of KOI8-R characters (as ubyte).
*/
auto toKOI8r(R)(R range)
if (isInputRange!R && is(ElementType!R : dchar))
{
static struct Result
{
R _range;
@property bool empty() { return _range.empty; }
@property ubyte front()
{
dchar ch = _range.front;
// ASCII
if (ch < 128)
return cast(ubyte)ch;
// Primary alphabetic range
if (ch >= 0x410 && ch < 0x450)
return utf2koi8r[ch - 0x410];
// Special case: Ё and ё are outside the usual range.
if (ch == 0x401) return 179;
if (ch == 0x451) return 163;
throw new Exception(
"Encoding error: unable to convert '%c' to KOI8-R".format(ch));
}
void popFront() { _range.popFront(); }
static if (isForwardRange!R)
{
@property Result save()
{
Result copy;
copy._range = _range.save;
return copy;
}
}
}
return Result(range);
}
unittest
{
import std.string;
import std.algorithm : equal;
assert("юабцдефгхийклмнопярстужвьызшэщчъ".toKOI8r.equal(iota(192, 224)));
assert("ЮАБЦДЕФГХИЙКЛМНОПЯРСТУЖВЬЫЗШЭЩЧЪ".toKOI8r.equal(iota(224, 256)));
}
unittest
{
auto r = "abc абв".toKOI8r;
static assert(isForwardRange!(typeof(r)));
import std.algorithm.comparison : equal;
assert(r.equal(['a', 'b', 'c', ' ', 193, 194, 215]));
}
static dchar[0x100 - 0xC0] koi8r2utf = [
'ю', 'а', 'б', 'ц', 'д', 'е', 'ф', 'г', // 192-199
'х', 'и', 'й', 'к', 'л', 'м', 'н', 'о', // 200-207
'п', 'я', 'р', 'с', 'т', 'у', 'ж', 'в', // 208-215
'ь', 'ы', 'з', 'ш', 'э', 'щ', 'ч', 'ъ', // 216-223
'Ю', 'А', 'Б', 'Ц', 'Д', 'Е', 'Ф', 'Г', // 224-231
'Х', 'И', 'Й', 'К', 'Л', 'М', 'Н', 'О', // 232-239
'П', 'Я', 'Р', 'С', 'Т', 'У', 'Ж', 'В', // 240-247
'Ь', 'Ы', 'З', 'Ш', 'Э', 'Щ', 'Ч', 'Ъ' // 248-255
];
/**
* Translates a range of KOI8-R characters to UTF.
* Returns: Range of UTF characters (as dchar).
*/
auto fromKOI8r(R)(R range)
if (isInputRange!R && is(ElementType!R : ubyte))
{
static struct Result
{
R _range;
@property bool empty() { return _range.empty; }
@property dchar front()
{
ubyte b = _range.front;
if (b < 128) return b;
if (b >= 192)
return koi8r2utf[b -
Re: Don't expect class destructors to be called at all by the GC
On Sun, Dec 24, 2017 at 02:07:26PM -0700, Jonathan M Davis via Digitalmars-d-learn wrote: [...] > Regardless, even if it were the case that it were guaranteed that all > finalizers were run when the program exited, it would still be > terrible practice to rely on it. It's trivial to end up in a situation > where no collection is run for quite some time (e.g. just don't do > much memory allocation for a while), which would leave any resources > that needed to be freed by a finalizer unfreed for quite a while even > though they weren't needed anymore. So practically speaking, it > doesn't really matter where the finalizers are guaranteed to run. > Relying on them to be run rather than forcing them to be run via > destroy or using some other helper function is just going to cause > problems, so it's just plain bad practice to rely on finalizers to be > run to release resources. That's just life with GC's in general, not > just D's. It's why C# has the while dispose/IDisposable thing, and why > D code should either be using destroy to deal with freeing resources > for a class or using structs on the stack for resources that need to > be freed. Or alternate memory strategies can be used via > std.experimental.allocator. The GC works great for lots of stuff but > not for system resources. Honestly, in some ways, we'd be better off > if D didn't even have finalizers. [...] This makes me wonder if a better approach to memory management is to use refcounting by default, and fallback to the GC to collect cycles. In my current project, I'll probably end up having to use RefCounted!Database just so I can have deterministic releasing of database handles without needing to worry about dangling references that may still be lingering around. (Currently, I'm just calling .destroy directly on the handle when I'm done with it, but there's a slim possibility that there might be dangling references left somewhere. So that needs to be addressed at some point.) T -- "I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr
how to localize console and GUI apps in Windows
There is one everlasting problem writing Cyrillic programs in Windows: Microsoft consequently invented two much different code pages for Russia and other Cyrillic-alphabet countries: first was MSDOS-866 (and alike), second Windows-1251. Nowadays MS Windows uses first code page for console programs, second for GUI applications, and there always are many workarounds to get proper translation between them. Mostly a programmer should write program sources either in one code page for console and other for GUI, or use .NET, which basically uses UTF8 in sources and makes seamless translation depending on back end. In D language which uses only UTF8 for string encoding I cannot write neither MS866 code page program texts, nor Windows-1251 - both cases end in a compiler error like "Invalid trailing code unit" or "Outside Unicode code space". And writing Cyrillic strings in UTF8 format is fatal for both console and GUI Windows targets. My question is: is there any standard means to translate Cyrillic or any other localized UTF8 strings for console and GUI output in D libraries. If so - where I can get more information and good example. Google would not help. Thanks.
Re: How do I set a class member value by its name in a string?
Always helpful. Thank you very much guys.
Re: Getting error in dmd testsuite
On Sunday, 27 August 2017 at 14:04:18 UTC, Joakim wrote: That module tests linking with C++ files, looks like you have some symbols that don't match up. That's weird, because those normally work with gcc. For each of them, use the readelf command from binutils to compare the symbols generated and see how they differ. For example, readelf -sW /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppb.cpp.o |grep foo15372 Then run the same command on the D side, ie for cppa_0.o, and compare the symbols. File a bug on the ldc github if you can't figure it out: https://github.com/ldc-developers/ldc/issues gcc does not create the symbol at all on NixOS. I already created an issue for NixOS: https://github.com/NixOS/nixpkgs/issues/28896 I am not supposed to ask here but maybe someone knows about problems with gcc?
Re: druntime memory unittest fails
On Thursday, 28 December 2017 at 10:25:01 UTC, Seb wrote: On Thursday, 28 December 2017 at 10:23:38 UTC, Thomas Mader wrote: Hello, on NixOS the druntime memory unittest fails at 'assert(z is null);' (https://github.com/dlang/druntime/blob/v2.075.1/src/core/memory.d#L899) Does anyone have a clue how that can happen? Thomas Use master: https://github.com/dlang/druntime/pull/1991 Perfect, thanks. I already tested building with 2.078.0-beta1 but don't remember if I reactivated the test or not. Nevertheless I will just wait for the final release.
Re: How do I set a class member value by its name in a string?
On Wednesday, 27 December 2017 at 23:47:14 UTC, Biotronic wrote: [...] much, much better. thanks biotronic.
Re: float.max + 1.0 does not overflow
On Wednesday, 27 December 2017 at 14:14:42 UTC, Benjamin Thaut wrote: On Wednesday, 27 December 2017 at 13:40:28 UTC, rumbu wrote: Is that normal? It computes the difference between float.max and the next smaller reprensentable number in floating point. The difference printed by the program is: 20282409603651670423947251286016.0 As you might notice this is siginificantly bigger then 1.0. Floating point operations work like this: They perform the operation and then round to the nearest representable number in floating point. So adding 1.0 to float.max and then rounding to the nearest representable number will just give you back float.max. If you however add float.max and float.max the next nearest reprensentable number is float.inf. The float with the lower exponent would have to be shifted to match the higher which means 1.0 would be shifted something like 156 bits to the right before the addition can be done. If you shift right more bits than are in the mantissa then it get rounded to zero. Hence once the two values are lined up to do the actual op it becomes float.max + 0.0. That said i suspect the OP was expecting the FPU unit to catch that in theory it should overflow. Not that the actual op would overflow but that the FPU would be checking the values on input. Maybe.
Re: DLang Tour : Functions as arguments
On Thursday, 28 December 2017 at 10:20:59 UTC, Basile B. wrote:
On Thursday, 28 December 2017 at 01:37:16 UTC, Tony wrote:
On this page:
https://tour.dlang.org/tour/en/basics/delegates
there is:
void doSomething(int function(int, int) doer) {
// call passed function
doer(5,5);
}
doSomething(add); // use global function `add` here
// add must have 2 int parameters
I can't get it to compile unless it is:
doSomething();
Thanks for reporting this. This will be corrected soon:
https://github.com/dlang-tour/english/pull/220
If you find more issues, please rather use this bug dedicated
tracker
https://github.com/dlang-tour/english/issues.
Or simply click on the edit button yourself. Thanks for reporting
and thanks @Basile for fixing it!
druntime memory unittest fails
Hello, on NixOS the druntime memory unittest fails at 'assert(z is null);' (https://github.com/dlang/druntime/blob/v2.075.1/src/core/memory.d#L899) Does anyone have a clue how that can happen? Thomas
Re: druntime memory unittest fails
On Thursday, 28 December 2017 at 10:23:38 UTC, Thomas Mader wrote: Hello, on NixOS the druntime memory unittest fails at 'assert(z is null);' (https://github.com/dlang/druntime/blob/v2.075.1/src/core/memory.d#L899) Does anyone have a clue how that can happen? Thomas Use master: https://github.com/dlang/druntime/pull/1991
Re: DLang Tour : Functions as arguments
On Thursday, 28 December 2017 at 01:37:16 UTC, Tony wrote:
On this page:
https://tour.dlang.org/tour/en/basics/delegates
there is:
void doSomething(int function(int, int) doer) {
// call passed function
doer(5,5);
}
doSomething(add); // use global function `add` here
// add must have 2 int parameters
I can't get it to compile unless it is:
doSomething();
Thanks for reporting this. This will be corrected soon:
https://github.com/dlang-tour/english/pull/220
If you find more issues, please rather use this bug dedicated
tracker
https://github.com/dlang-tour/english/issues.
Re: Is this an okay representation of a dynamically sized Matrix, to be used for HMM matrices m = (A,B)
On Thursday, 28 December 2017 at 01:34:10 UTC, Enjoys Math wrote:
Code:
module matrix;
import std.array;
struct Matrix(E)
{
private:
E[][];
this() {
}
void deleteRow(int i)
{
E = E[0..i] ~ E[i..$];
}
void deleteColumn(int j)
{
for (int i=0; i < E.length; i++)
{
E[i] = E[i][0..j] ~ E[i][j..$];
}
}
void insertRow(int i, E[] row)
{
if (E.length != 0)
assert(E[0].length == row.length);
E.insertInPlace(i, row);
}
void insertColumn(int j, E[] col)
{
for (int i=0; i < E.length; i++)
{
E[i].insertInPlace(j, col[i]);
}
}
int numRows() { return E.length; }
int numColumns() {
if (E.length == 0)
return 0;
return E[0].length;
}
}
Is there a more efficient way of doing this, knowing that I'll
be inserting columns / rows every time we need to create a new
hidden state so this matrix will be huge, for a good model. By
huge we'll probably use the full capacity of a long[] in D.
I've already tried doing this in MQL5 and we exceeded easily
the max array capacity.
Full capacity of a long[] (or any array) is the entire
addressable memory, which is 4GB for 32bit. You will not exceed
the 64bit address space.
Do you know the width of the matrix ahead of time? I assume they
are all the same given the implementation of numColumns.
Have you looked at mir (https://github.com/libmir/mir-algorithm)
for ndslice?
by deleting rows, can you get away with just zeroing them?
