Re: N-dimensional slices is ready for comments!
15.06.2015 11:40, Ilya Yaroshenko пишет: Hi All, PR and Examples: https://github.com/D-Programming-Language/phobos/pull/3397 DUB http://code.dlang.org/packages/dip80-ndslice N-dimensional slices is real world example where `static foreach` would be useful. Corresponding lines was marked with //TODO: static foreach Best regards, Ilya http://forum.dlang.org/post/l315jb$avg$1...@digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Re: N-dimensional slices is ready for comments!
16.06.2015 1:11, Denis Shelomovskij пишет: 15.06.2015 11:40, Ilya Yaroshenko пишет: Hi All, PR and Examples: https://github.com/D-Programming-Language/phobos/pull/3397 DUB http://code.dlang.org/packages/dip80-ndslice N-dimensional slices is real world example where `static foreach` would be useful. Corresponding lines was marked with //TODO: static foreach Best regards, Ilya http://forum.dlang.org/post/l315jb$avg$1...@digitalmars.com Sorry, this was the last one: Finally full multidimensional arrays support in D http://forum.dlang.org/thread/lg7c0t$jmg$1...@digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Encapsulating trust
31.08.2014 17:47, Dmitry Olshansky пишет:
Quite recently a lot of work has been done to make most of Phobos usable
in @safe code.
While a very welcome effort, it caused a number of doubts in particular
due to the boilerplate required to isolate a small amount of unsafe
operations and slap @trusted over it.
See e.g. Denis argument:
https://github.com/D-Programming-Language/phobos/pull/2465
There were proposals for language changes along the lines of having
@trusted block alike to debug/version blocks, but nothing ever came out
of them.
Without language support I decided it worth a shot to create a universal
wrappers to establish a consistent convention. A use of such wrapper
should indicate that a @system function call or language feature was
hand-verified.
Names and complete set of primitives are up for debate, but here is the
start:
https://gist.github.com/DmitryOlshansky/bc02f369c8a63818bd07
A bit of usage:
import core.stdc.string;
import trusted;
void main() @safe
{
char[] msg = Hello!.dup;
char[] msg2 = msg;
import trusted; // may also use static import for absolute clarity
assert(call!memcmp(addrOf(msg[0]), addrOf(msg2[0]), msg.length) == 0);
}
What do you guys think?
The language works fine for me as it is in this aspect. E.g. functions
from `std.file` like `read` should be marked as `@trusted` because this
is what `@trusted` is for, a function operating unsafe stuff and
providing a safe interface to it.
Currently the only problem is with templates like `std.array.Appender`
when we want the compiler to infer attributes from user type and have to
carefully wrap our code in `@trusted` blocks leaving calls to user code
unwrapped.
Yes, my opinion here is the same as Daniel's one.
About related `std.file` pulls:
I wrote my original comment [1] to the pull because it blows the code
size and reduce its readability by using `@trusted` nested functions
(lambdas not used just because they currently can't be inlined, but it's
silly as these functions work with disk and thus slow anyway).
This introduces a bad anti-pattern in the library and should be
reverted. Just imagine a D newbie who just started leaning the language
and is reading `std.file` module to see how easy can he use native API
in D (e.g. I was such newbie). With all these pulls merged (current
HEAD) he will be terrified of the code ugliness and either decide this
is the only way to use native API in D (wrap every native function in
`@trusted` nested function in `@safe` function) or will spend
significant time discovering the history of this module and who is
guilty in such bad design (e.g. I spend a lot of time when learned D
because of `TypeTuple` used with expressions which completely confused me).
[1]
https://github.com/D-Programming-Language/phobos/pull/2465#issuecomment-53950146
--
Денис В. Шеломовский
Denis V. Shelomovskij
Just curious: who do know current purity rules?
As Kenji Hara just created purity fixing pull [1] we will probably soon
have more intuitive rules so it's interesting who do understand current
purity rules. The following code is proposed to check your understanding:
---
alias F = bool function(int) pure;
alias D = bool delegate(int) pure;
D foo1(immutable F f) pure { return x = (*f)(x); } // ok or error?
D foo2(const F f) pure { return x = (*f)(x); } // ok or error?
D foo1(immutable F* f) pure { return x = (*f)(x); } // ok or error?
D foo2(const F* f) pure { return x = (*f)(x); } // ok or error?
---
Who passes this test? By pass I mean completely understand what the
compiler do and why.
By the way, personally I would fail the test. )
[1] [spoiler!] https://github.com/D-Programming-Language/dmd/pull/3626
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: Just curious: who do know current purity rules?
06.06.2014 13:05, Kagamin пишет: Do you mean true purity rules or whatever is implemented in the compiler? whatever is implemented. ) -- Денис В. Шеломовский Denis V. Shelomovskij
Re: DGui is alive
26.05.2014 23:08, Andre пишет: On Saturday, 24 May 2014 at 07:20:49 UTC, Denis Shelomovskij wrote: 20.05.2014 17:46, FrankLike пишет: DGui need some other controls,such as imageButton,DataView,GridViewe.t.c. There is no plan to add new controls and I don't see any lacking ones. One can use `paint` event to draw image on button and there is `GridPanel` (with usage example `grid.d`) so I don't understand why `GridView` is needed and what is its purpose. Also I don't know what is `DataView` for. DGui is really fantastic, it is easy to use and without a big overhead. What I experienced, developers coming from other frameworks might miss a horizontal/vertical layout. This would be much easier than using a grid for this purpose. Also some more examples could boost the popularity of DGui. Especially, how can I create create my own controls? Horizontal/vertical layout can be achieved using `Control.dock` property. I will think about examples and documentation improvements. What would be really nice for business developer would be a specific Stringgrid control (like delphi/lazarus has). Here an example http://i.stack.imgur.com/FJFiN.gif Use `ListView` and `TreeView` classes. Do you accept pull requests if developers provide you new stuff for DGui? Yes, but I strongly recommend to contact me first to plan and synchronize activities to prevent useless time wasting. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: DGui is alive
20.05.2014 17:46, FrankLike пишет: DGui need some other controls,such as imageButton,DataView,GridViewe.t.c. There is no plan to add new controls and I don't see any lacking ones. One can use `paint` event to draw image on button and there is `GridPanel` (with usage example `grid.d`) so I don't understand why `GridView` is needed and what is its purpose. Also I don't know what is `DataView` for. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Thank you Kenji
23.05.2014 8:11, Martin Nowak пишет: Today at DConf we learned, once again, that people are doing and starting amazing projects using D. A lot of which wouldn't have been possible without your contribution. So I just wanted to say thank you. -Martin Finally a thread to thank the man who fights all these corner cases and bugs. ) Thank you Kenji very much! -- Денис В. Шеломовский Denis V. Shelomovskij
Re: DGui is alive
20.05.2014 22:46, Suliman пишет: DGui need some other controls,such as imageButton,DataView,GridViewe.t.c. Thank you. Frank Yes, I very need imageButton. Is there any chance that they will be developed in nearest time? No, not in near future. General usage of buttons with images is a `ToolBar` so there is a `ToolButton` with image. As for other controls, e.g. a regular `Button`, one can draw everything in `paint` event. I need example how to draw line (small Paint) with this lib. Does DGUI can do it? If not I would need to look for alternative... Here is an example of button with image and lines drawn on it: https://gist.github.com/denis-sh/56e2104dba7d9793f68d -- Денис В. Шеломовский Denis V. Shelomovskij
Re: DGui is alive
21.05.2014 15:05, Suliman пишет: On Wednesday, 21 May 2014 at 08:25:20 UTC, Denis Shelomovskij wrote: 20.05.2014 22:46, Suliman пишет: DGui need some other controls,such as imageButton,DataView,GridViewe.t.c. Thank you. Frank Yes, I very need imageButton. Is there any chance that they will be developed in nearest time? No, not in near future. General usage of buttons with images is a `ToolBar` so there is a `ToolButton` with image. As for other controls, e.g. a regular `Button`, one can draw everything in `paint` event. What is the difference between imageButton and ToolButton? There is no `imageButton` objects in DGui. `ToolButton` is a button placed in `ToolBar` and it can have an image. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: DGui is alive
20.05.2014 18:11, FrankLike пишет: Can you put DGui into github.com and code.dlang.org ? Let all d's coders build on it! Thank you. Frank It is already in code.dlang.org. As for Github I have already answered here [1]. [1] http://forum.dlang.org/post/llf00b$2pl5$1...@digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
18.05.2014 14:52, FrankLike пишет: On Sunday, 18 May 2014 at 09:22:53 UTC, FrankLike wrote: DFL isn't boost licensed, that's the problem for me. And Christopher didn't answered anything on my proposal to change the license. I'd suggest to put the effort in DGui [1] instead because its author, Antonio Davide Trogu, kindly changed the license to Boost as he want the library to be used. By the way, see DGui examples at Downloads page [2], they are smaller, than DFL ones. Also one of DGui goals was a source code simplicity. ) [1] https://bitbucket.org/dgui/dgui [2] https://bitbucket.org/dgui/dgui/downloads Why not put it in github.com? Because personally I like Bitbucket (it has side-by-side diff and Github some time ago switched to completely unusable fonts for source code making it unreadable for Windows XP users like me). Thank you. And put it in code.dlang.org. Will do as soon as its Bitbucket support will be restored. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
18.05.2014 18:25, FrankLike пишет: *http://denis-sh.bitbucket.org/ Where is the DGui? This dgui is very cool. The link is to my personal page. DGui isn't my library, I only manage it so it can't be listened in my open-source projects page. As for x64 support, yes is isn't ready. If it is needed just like any other feature feel free to open an issue. [1] https://bitbucket.org/dgui/dgui/issues -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
18.05.2014 19:14, FrankLike пишет: On Sunday, 18 May 2014 at 14:54:44 UTC, FrankLike wrote: 1.DFL's Memory Usage is the least than other. winsamp.exe is 2.1M,DFL's example's exe is 2.7M. DGui's Memory Usage is 3.2M. [1] https://bitbucket.org/dgui/dgui [2] https://bitbucket.org/dgui/dgui/downloads You will put it in code.dlang.org and github.com? DGui is very cool,the exe's size is a half of DFL's,and it's easy to learn. If It will be used on Linux ,Mac Os X,it will be the coolist of all gui libs. Thank you. Frank And there are some controls are not implement,such as imageButton,GridView,DateTimePick,Socket,DataControl. Thank you. There is no plans for cross-platform porting or adding new controls in near future. Probably the situation may be improved in case developers of DFL unofficial fork [1] will join DGui development. [1] https://github.com/Rayerd/dfl -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
15.05.2014 7:58, FrankLike пишет: 1.DFL's Memory Usage is the least than other. winsamp.exe is 2.1M,DFL's example's exe is 2.7M. 2.The size of DFL's example's exe files is the least than other, and only a single file. 3.DFL's source code is the most easy to understand. D need Christopher E. Miller. DFL isn't boost licensed, that's the problem for me. And Christopher didn't answered anything on my proposal to change the license. I'd suggest to put the effort in DGui [1] instead because its author, Antonio Davide Trogu, kindly changed the license to Boost as he want the library to be used. By the way, see DGui examples at Downloads page [2], they are smaller, than DFL ones. Also one of DGui goals was a source code simplicity. ) [1] https://bitbucket.org/dgui/dgui [2] https://bitbucket.org/dgui/dgui/downloads -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Allocating a wstring on the stack (no GC)?
07.05.2014 22:26, Maxime Chevalier-Boisvert пишет: I have a very specific use case (JIT compiler) in which I have a pre-allocated array of wchar string data stored somewhere in memory. I'd like to be able to create a temporary D wstring object to pass this as a regular string to other functions. For performance reasons, it would be preferable not to dynamically allocate or copy any data. Dynamically allocating the strings tends to trigger the D GC which severely impacts the performance. So, my question is, would it be possible for me to allocate a wstring object on the stack, and manually set its string data pointer and length? If so, how? Your wizardly help is much appreciated. If you have a preallocated data, just using slicing will be enough. A result will be `wstring` for immutable data or `const(wchar)[]` for non-immutable, if you respect a typesystem. If a new data is generated but you want it to be put on stack if it's small enough (you can't put big data on stack anyway) you need some allocation facility. E.g. `unstd.memory.allocation.tempAlloc` [1] will do the work. [1] http://denis-sh.bitbucket.org/unstandard/unstd.memory.allocation.html#tempAlloc -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Table lookups - this is pretty definitive
01.04.2014 22:35, Walter Bright пишет:
Try this benchmark comparing various classification schemes:
-
import core.stdc.stdlib;
import core.stdc.string;
import std.algorithm;
import std.array;
import std.ascii;
import std.datetime;
import std.range;
import std.stdio;
import std.traits;
bool isIdentifierChar0(ubyte c)
{
return isAlphaNum(c) || c == '_' || c == '$';
}
bool isIdentifierChar1(ubyte c)
{
return ((c = '0' || c == '$')
(c = '9' || c = 'A')
(c = 'Z' || c = 'a' || c == '_')
(c = 'z'));
}
immutable bool[256] tab2;
static this()
{
for (size_t u = 0; u 0x100; ++u)
{
tab2[u] = isIdentifierChar0(cast(ubyte)u);
}
}
bool isIdentifierChar2(ubyte c)
{
return tab2[c];
}
/*/
int f0()
{
int x;
for (uint u = 0; u 0x100; ++u)
{
x += isIdentifierChar0(cast(ubyte)u);
}
return x;
}
int f1()
{
int x;
for (uint u = 0; u 0x100; ++u)
{
x += isIdentifierChar1(cast(ubyte)u);
}
return x;
}
int f2()
{
int x;
for (uint u = 0; u 0x100; ++u)
{
x += isIdentifierChar2(cast(ubyte)u);
}
return x;
}
void main()
{
auto r = benchmark!(f0, f1, f2)(10_000);
writefln(Milliseconds %s %s %s, r[0].msecs, r[1].msecs, r[2].msecs);
}
Some regular benchmark notes:
1. The first one passed to `benchmark` is always slower (e.g. pass `f2`
and see).
2. Unexpected program behaviour changes:
Let's use `benchmark!(f1, f1, f1)(1_000_000)`:
Milliseconds 928 889 888
Then copy `isAlphaNum` in file (benchmark still shows same results) and
change `dchar c` to `ubyte c`, result changes:
Milliseconds 849 815 827
The difference is sufficient but `isAlphaNum` not called in benchmark.
Also `f0` is faster than `f1`, benchmark!(f0, f0, f0)(1_000_000):
Milliseconds 731 694 702
And `f2` wins, it's the only obvious thing, benchmark!(f2, f2,
f2)(1_000_000):
Milliseconds 227 184 184
Compiler used: dmd -O -inline -release
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: Table lookups - this is pretty definitive
01.04.2014 23:22, Denis Shelomovskij пишет:
01.04.2014 22:35, Walter Bright пишет:
Try this benchmark comparing various classification schemes:
-
import core.stdc.stdlib;
import core.stdc.string;
import std.algorithm;
import std.array;
import std.ascii;
import std.datetime;
import std.range;
import std.stdio;
import std.traits;
bool isIdentifierChar0(ubyte c)
{
return isAlphaNum(c) || c == '_' || c == '$';
}
bool isIdentifierChar1(ubyte c)
{
return ((c = '0' || c == '$')
(c = '9' || c = 'A')
(c = 'Z' || c = 'a' || c == '_')
(c = 'z'));
}
immutable bool[256] tab2;
static this()
{
for (size_t u = 0; u 0x100; ++u)
{
tab2[u] = isIdentifierChar0(cast(ubyte)u);
}
}
bool isIdentifierChar2(ubyte c)
{
return tab2[c];
}
/*/
int f0()
{
int x;
for (uint u = 0; u 0x100; ++u)
{
x += isIdentifierChar0(cast(ubyte)u);
}
return x;
}
int f1()
{
int x;
for (uint u = 0; u 0x100; ++u)
{
x += isIdentifierChar1(cast(ubyte)u);
}
return x;
}
int f2()
{
int x;
for (uint u = 0; u 0x100; ++u)
{
x += isIdentifierChar2(cast(ubyte)u);
}
return x;
}
void main()
{
auto r = benchmark!(f0, f1, f2)(10_000);
writefln(Milliseconds %s %s %s, r[0].msecs, r[1].msecs,
r[2].msecs);
}
Some regular benchmark notes:
1. The first one passed to `benchmark` is always slower (e.g. pass `f2`
and see).
2. Unexpected program behaviour changes:
Let's use `benchmark!(f1, f1, f1)(1_000_000)`:
Milliseconds 928 889 888
Then copy `isAlphaNum` in file (benchmark still shows same results) and
change `dchar c` to `ubyte c`, result changes:
Milliseconds 849 815 827
The difference is sufficient but `isAlphaNum` not called in benchmark.
Also `f0` is faster than `f1`, benchmark!(f0, f0, f0)(1_000_000):
Milliseconds 731 694 702
And `f2` wins, it's the only obvious thing, benchmark!(f2, f2,
f2)(1_000_000):
Milliseconds 227 184 184
Compiler used: dmd -O -inline -release
Few more words about `dmd`:
Hey, silly, you still use `== x` to compare with `x`? Use table
lookups! And never cast `size_t` to `ubyte`! See:
---
import std.datetime;
import std.stdio;
immutable bool[256] tab2;
static this()
{
foreach(size_t u; 0 .. 0x100)
tab2[u] = u == '_';
}
/*/
int f0()
{
int x;
foreach(uint u; 0 .. 0x100)
x += u == '_';
return x;
}
int f2()
{
int x;
foreach(uint u; 0 .. 0x100)
x += tab2[cast(ubyte)u];
return x;
}
int f2plus()
{
int x;
foreach(size_t u; 0 .. 0x100)
x += tab2[u];
return x;
}
void main()
{
auto r = benchmark!(f0, f0, f0)(1_000_000);
writefln(Milliseconds %s %s %s (f0), r[0].msecs, r[1].msecs,
r[2].msecs);
r = benchmark!(f2, f2, f2)(1_000_000);
writefln(Milliseconds %s %s %s (f2), r[0].msecs, r[1].msecs,
r[2].msecs);
r = benchmark!(f2plus, f2plus, f2plus)(1_000_000);
writefln(Milliseconds %s %s %s (f2plus), r[0].msecs, r[1].msecs,
r[2].msecs);
}
---
Milliseconds 323 274 281 (f0)
Milliseconds 185 185 185 (f2)
Milliseconds 105 97 105 (f2plus)
---
P.S.
I don't want to say anything with these results. I just have no idea
what happens here and I don't want to investigate dmd's way of
optimizing things now.
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: Cross Platform GUI Development
24.03.2014 13:04, Gary Willoughby пишет: On Sunday, 23 March 2014 at 20:04:00 UTC, Jeroen Bollen wrote: The main problem I have with GTK is that it's a mess to setup on Windows for the end user. The only real problem is the actual installation of GTK onto the Windows user's machine as some people ask why do i need to install this weird GTK thing for this app to work?. But... you can 'hide' the installation of GTK on Windows as part of the main application's installer because the Windows version of GTK has a silent install options. http://gtk-win.sourceforge.net/home/index.php/Main/EmbeddingGTK Note different programs may require different GTK versions and GTK isn't backward compatible on Windows because of some bugs (e.g. 2.16 is the last one with working OpenGL using GtkGLExt from 2.x), so it's usually just copied in application's folder. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Cross Platform GUI Development
23.03.2014 16:34, Jeroen Bollen пишет: Are there any tools to do this at all in Digitalmars D? All current libraries seem to be outdated, but GTKD. GTK on it's end is a pain to bundle which is enough to not consider it cross platform at all. First, I don't understand what is the problem with GTK? Also there is DWT, but I already have spent some time on it and I'd like to suggest to not use it as its sources is a mess. As for cross-platform GUI app, I'd suggest to use own native GUI library for every platform as it looks like an easiest and the most convenient for the user of your program approach. The problem is it's too common to connect application login and GUI, so for my personal purposes I created MetaUI [1] which allow such intermediate layer and you only create native GUI elements, place it somewhere and connect with logic elements from MetaUI, see examples. As a native GUI I use GTK (mainly my own fast, correct and very usable bindings [2]) over MetaUI for now, but when I will have more time I will use DGui on Windows just to decrease program installation size. The only problem is a Mac OS X for which I don't know working GUI library (I don't target it for now, GTK may work but with PITA), but with MetaUI it shouldn't be a problem to use some C one as the only thing you need is a way to connect C widgets to D logic controls. [1] https://bitbucket.org/denis-sh/metaui [2] https://bitbucket.org/denis-sh/gtkd [3] https://bitbucket.org/dgui/dgui -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Cross Platform GUI Development
24.03.2014 0:03, Jeroen Bollen пишет: On Sunday, 23 March 2014 at 19:56:47 UTC, Denis Shelomovskij wrote: 23.03.2014 16:34, Jeroen Bollen пишет: Are there any tools to do this at all in Digitalmars D? All current libraries seem to be outdated, but GTKD. GTK on it's end is a pain to bundle which is enough to not consider it cross platform at all. First, I don't understand what is the problem with GTK? ... The main problem I have with GTK is that it's a mess to setup on Windows for the end user. And you shouldn't ever do it. Just bundle GTK with your program and be happy. Here is what I use (~4 MiB): http://deoma-cmd.ru/files/other/GTK-3-redist.7z (if you are OK with third GTK version) These files just should be in your target installation directory. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Handling invalid UTF sequences
21.03.2014 12:25, monarch_dodra пишет: On Thursday, 20 March 2014 at 23:34:02 UTC, Brad Anderson wrote: I'm a fan of this approach but Timon pointed out when I wrote about it once that it's rather trivial to get an invalid string through slicing mid-code point so now I'm not so sure. It's just as easy to slice mid-codepoint as it is to access a range out of bounds. In both cases, it's a programming error. The only excuse I see for throwing an exception for slicing mid-codepoint, is that 1. programmers are less aware of the issue, so it's more forgiving in a released program (nobody likes a crash). 2. arguably, it's not the *program* state that's bad. It's the *data*. Well, in regards to 2, you could argue that program state and data state is one and the same. I think I'm still in favor of it because you've obviously got a logic error if that happens so your program isn't correct anyway (it's not a matter of bad user input). If I remember correctly, with a specially written UTF string, it *was* possible to corrupt program state. I think. I need to double check. I didn't give it much thought then (it should virtually never happen), but it could be used as deliberate security vulnerability. Almost nothing to add here. We already have `-noboundscheck` which can dramatically increase performance, throwing `UTFError` should either use same mechanics (`-noutfcheck`?) or just be stripped in release. Personally I'd choose the latter as there are lots of (sometimes very slow) assertions stripped with `-release` in real programs, which indicates same critical data corruption. -- Денис В. Шеломовский Denis V. Shelomovskij
[Proposal] Add module for C-strings support in Phobos
It's filed as enhancement 12418 [2]: C-strings processing is a special and common case so: 1. C-strings should be supported with both performance and usability. 2. There should be a dedicated module for C-strings (instead of adding such functions here and there in other modules). Current state: there is no good support for C-strings in Phobos, there is slow and broken `toStringz` (Issue 12417 [3]), and no standard way to make many common operations, like converting returned C-string to string and releasing its memory or creating a C-string from string using an allocation function. So I propose to add `unstd.c.string` [1] module to Phobos which include all use-cases I have seen implementing (correct and fast in contrast to existing ones like GtkD (yes, it's both incorrect and slow because of tons of GC allocations)) C library wrappers. [1] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html [2] https://d.puremagic.com/issues/show_bug.cgi?id=12418 [3] https://d.puremagic.com/issues/show_bug.cgi?id=12417 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Add module for C-strings support in Phobos
20.03.2014 13:20, Rikki Cattermole пишет: On Thursday, 20 March 2014 at 08:24:30 UTC, Denis Shelomovskij wrote: It's filed as enhancement 12418 [2]: C-strings processing is a special and common case so: 1. C-strings should be supported with both performance and usability. 2. There should be a dedicated module for C-strings (instead of adding such functions here and there in other modules). Current state: there is no good support for C-strings in Phobos, there is slow and broken `toStringz` (Issue 12417 [3]), and no standard way to make many common operations, like converting returned C-string to string and releasing its memory or creating a C-string from string using an allocation function. So I propose to add `unstd.c.string` [1] module to Phobos which include all use-cases I have seen implementing (correct and fast in contrast to existing ones like GtkD (yes, it's both incorrect and slow because of tons of GC allocations)) C library wrappers. [1] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html [2] https://d.puremagic.com/issues/show_bug.cgi?id=12418 [3] https://d.puremagic.com/issues/show_bug.cgi?id=12417 Looks like it wouldn't be really useful with Windows API. Given that wstrings are more common there. You misunderstand the terminology. C string is a zero-terminated string. Also looks like you didn't even go to docs page as the second example is WinAPI one. Another thing that would be nice to have is a wrapper struct for the pointer that allows accessing via e.g. opIndex and opSlice. Ext. Use case: Store the struct on D side to make sure GC doesn't clean it up and still be able to access and modify it like a normal string easily. I don't understand the use-case. If you did implemented some C library wrappers and have a personal experience, I'd like to hear your opinion on C functions calling problem and your proposal to solve it, if you dislike mine. Also with examples, please, where my solution fails and your one rocks. ) -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Finally full multidimensional arrays support in D
18.03.2014 1:35, Christof Schardt пишет: I looked to the doku-page and expected to see, how some basic matrix-operations could be performed. Like e.g. (basic syntax) this: Dim a(10,12) a(3,4) = 7 a(i,j) = a(j,i) * 12 Instead I found exotic assignments and calculations. Did I expect the wrong thing? Sorry for that. Do you mead there is a lack of simple indexing examples or lack of some matrix functionality? The latter case is if you meant transpose and multiply by 12 with `a(i,j) = a(j,i) * 12`. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Add module for C-strings support in Phobos
20.03.2014 13:52, Rikki Cattermole пишет: On Thursday, 20 March 2014 at 09:32:33 UTC, Denis Shelomovskij wrote: 20.03.2014 13:20, Rikki Cattermole пишет: On Thursday, 20 March 2014 at 08:24:30 UTC, Denis Shelomovskij wrote: It's filed as enhancement 12418 [2]: C-strings processing is a special and common case so: 1. C-strings should be supported with both performance and usability. 2. There should be a dedicated module for C-strings (instead of adding such functions here and there in other modules). Current state: there is no good support for C-strings in Phobos, there is slow and broken `toStringz` (Issue 12417 [3]), and no standard way to make many common operations, like converting returned C-string to string and releasing its memory or creating a C-string from string using an allocation function. So I propose to add `unstd.c.string` [1] module to Phobos which include all use-cases I have seen implementing (correct and fast in contrast to existing ones like GtkD (yes, it's both incorrect and slow because of tons of GC allocations)) C library wrappers. [1] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html [2] https://d.puremagic.com/issues/show_bug.cgi?id=12418 [3] https://d.puremagic.com/issues/show_bug.cgi?id=12417 Looks like it wouldn't be really useful with Windows API. Given that wstrings are more common there. You misunderstand the terminology. C string is a zero-terminated string. Also looks like you didn't even go to docs page as the second example is WinAPI one. I understand how c strings work. It would be nice to have more unittests for dstring/wstring, because it looks more geared towards char/string. Which is why it looks on the offset that it is less going to work. I'd say must unittests do test UTF-16 UTF-32 versions. As for documentation, function signatures contain template parameter for character but probably there is a lack of ddoc unittests and/or documentation. Another thing that would be nice to have is a wrapper struct for the pointer that allows accessing via e.g. opIndex and opSlice. Ext. Use case: Store the struct on D side to make sure GC doesn't clean it up and still be able to access and modify it like a normal string easily. I don't understand the use-case. If you did implemented some C library wrappers and have a personal experience, I'd like to hear your opinion on C functions calling problem and your proposal to solve it, if you dislike mine. Also with examples, please, where my solution fails and your one rocks. ) I don't dislike your approach at all. I just feel that it needs to allow for a little more use cases. Given the proposal is for phobos. What you have done looks fine for most cases to c libraries. I'm just worried that it has less use cases then it could have. I'm just nitpicking so don't mind me too much :) Thanks. So the algorithm is like this: find C library which needs more love and file me an issue [1]. As I just added all common use-cases I have seen. [1] https://bitbucket.org/denis-sh/unstandard/issues -- Денис В. Шеломовский Denis V. Shelomovskij
Finally full multidimensional arrays support in D
Multidimensional arrays indexing and slicing syntax is finally added [1] (thanks to Kenji Hara). So it was a good cause to update my multidimensional arrays library implementation and add support for the new syntax. So here we are: [2]. Also should we add it to the standard library? [1] https://github.com/D-Programming-Language/dmd/pull/443 [2] http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Finally full multidimensional arrays support in D
17.03.2014 21:39, Denis Shelomovskij пишет: Multidimensional arrays indexing and slicing syntax is finally added [1] (thanks to Kenji Hara). So it was a good cause to update my multidimensional arrays library implementation and add support for the new syntax. So here we are: [2]. Also should we add it to the standard library? [1] https://github.com/D-Programming-Language/dmd/pull/443 [2] http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html An important note: My proposal is just a sliceable multidimensional array implementation, a try to provide the same effort we have for simple arrays for multidimensional ones. It isn't aimed to be a dedicated matrix / linear algebra module. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Facebook open sources flint, a C++ linter written in D
25.02.2014 16:48, Dicebot пишет: On Tuesday, 25 February 2014 at 11:20:37 UTC, bearophile wrote: Currently the D compiler catches several bugs that are caught only by C lints. Clang shows that you can add lot of lint-like tests to the compiler. I'd like some more tests in the D compiler. Full stop. It should be other way around - remove all such arguable warnings from compiler to dedicated lint tool and never add any single one to compiler. I'd say a good static code analysis require a full compiler frontend and I see no reasons why there can't be such thing in dmd as it is just as required as profiler, unittesting or documentation generation which are already in. Of course it has nothing to do with compiler warnings and is a separate thing. But looks like people aren't interested in it as enhancement request 9811 [1] still has no votes or discussion. [1] https://d.puremagic.com/issues/show_bug.cgi?id=9811 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: std.signal : voting has begun
06.01.2014 13:11, Dicebot пишет:
Some time ago there have been a review for `std.signal` Phobos proposal
(http://forum.dlang.org/thread/ujlhznaphepibgtpc...@forum.dlang.org#post-ujlhznaphepibgtpcoqz:40forum.dlang.org).
It have not received much feedback and I was a it too busy to proceed
with final voting at that moment but with no outstanding issues to
address nothing prevents that final step.
Let's put 2 week deadline to refresh memories about the proposal and
make some decision. Voting closes at January 20th 23:59 GMT 0
Please take some time and help make Phobos better ;)
No.
Any signals implementation is at least blocked by the fact closure
delegates lifetime can't be determined (see issues [2] and [3]).
Requirement to explicitly pass owning object is redundant and
unacceptable, such code must work:
---
/// Usage: don't pass struct member function delegates as `del`.
void f(void delegate() del)
{
obj.event.connect(del);
}
---
Yes, I still don't see an elegant way to fix the language for struct
member function delegates, but for closures there is issue [1].
Another way to make things work is a runtime support for weak
references, see druntime pull 639 discussion [4].
Also see this thread for more discussion about signals problems: [5].
[1] https://d.puremagic.com/issues/show_bug.cgi?id=9601
[2] https://d.puremagic.com/issues/show_bug.cgi?id=9602
[3] https://d.puremagic.com/issues/show_bug.cgi?id=9603
[4] https://github.com/D-Programming-Language/druntime/pull/639
[5] http://forum.dlang.org/thread/kkdkh3$sft$1...@digitalmars.com
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: How do you deal with scoped allocations?
08.12.2013 2:32, Namespace пишет: Since my last thread doesn't get much attention I like to ask here: How did you deal with temporary memory? The algorithm is always this: 1. Use function stack frame for small allocations. 2. Use thread local stack allocator if temporary allocations corresponds LIFO principle and use thread local heap otherwise. As for usability it must be a single function call and D type system have to rest. And what do you use? As I answered in previous thread: http://forum.dlang.org/thread/nxrxojbzbrfwv...@forum.dlang.org#post-l77th1:24icc:241:40digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Re: scoped allocations
27.11.2013 3:33, Namespace пишет: First of all: I apologize for my bad english. In the last few weeks I searched for a way to allocate nicely temporary buffer of unknown lengths. You can use `unstd.memory.allocation.tempAlloc` [1]. Also there is `unstd.c.string.tempCString` [2] for common case of temporary C strings. [1] http://denis-sh.bitbucket.org/unstandard/unstd.memory.allocation.html#tempAlloc [2] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html#tempCString -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Duplicate keys in array literals?
28.11.2013 15:23, bearophile пишет:
Is it a good idea to silently statically accept duplicated keys in both
dynamic array literals and in associative array literals?
void main() {
int[] a = [0:10, 0:20];
int[int] aa = [0:10, 0:20];
}
I don't remember having ever had the need for this, and on the other
hand I have had some mistakes like this in my D code not caught
statically by the compiler.
---
Note that in this post I am not discussing about inserting multiple
times a key-pair in an associative array, this is normal and useful:
void main() {
int[int] aa;
aa[0] = 10;
aa[0] = 20;
}
Bye,
bearophile
File the issue please.
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: std.templatecons ready for comments
12.11.2013 2:19, John Colvin пишет: On Monday, 11 November 2013 at 22:18:27 UTC, John Colvin wrote: On Monday, 11 November 2013 at 20:33:37 UTC, Denis Shelomovskij wrote: 10.11.2013 19:30, Ilya Yaroshenko пишет: Hello, All! std.templatecons: Functional style template constructors. Documentation: http://9il.github.io/phobosx/std.templatecons.html Source: https://github.com/9il/phobosx/blob/master/std/templatecons.d Note: dmd = 2.64 required Please destroy! I am sorry for my English in sources/docs. Best Regards, Ilya No more plain modules, please. Call it `std.meta.something`. I'm against of including a few range-like (i.e. like `std.range` and `std.algorithm` stuff) templates like `RepeatExactly`, `templateStaticMap`, and `templateFilter`. First these are generic tuple manipulation templates belong to `std.meta.generictuple` (or how it's called now). Second I'd like to see one-to-one analog of all (most) applicable range operation functions for generic tuples in Phobos by merging in e.g. [1] As for `std.functional`-like template I can't tell much as the only ones http://denis-sh.bitbucket.org/unstandard/unstd.templates.html [1] http://denis-sh.bitbucket.org/unstandard/unstd.generictuple.html How would you feel about me cannibalising parts of that for my attempt at making a proper std.meta module? Conveniently it seems that we use similar core ideas, but have implemented disjoint sets of functionality. *somewhat disjoint Use it as you wish. Also feel free to e-mail me with questions/functionality requests (or open issues for Unstandard project). Just in case you want we also could make `unstd.meta` and then push to Phobos. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Expanding the horizons of D purity
07.11.2013 21:41, H. S. Teoh пишет:
On Thu, Nov 07, 2013 at 09:22:47PM +0400, Denis Shelomovskij wrote:
01.11.2013 0:05, H. S. Teoh пишет:
I'd like to propose extending the scope of weak purity one step
further: allow weakly-pure functions to call (not necessarily pure)
delegates passed as a parameter.
Unacceptable. It will break strongly purity. Your mistake is
strongly pure function can easily get an impure delegate:
[...]
It will not. My proposal only applies to weakly pure functions. Strongly
pure functions cannot call impure delegates because you cannot guarantee
anything about what the delegate will do.
So basically, once a pure function takes a non-pure delegate parameter,
it is no longer strongly pure, only weakly pure. (I stated this at the
end of my post where strongly pure functions are not allowed to call
impure delegates.)
T
Let me repeat my code again:
---
int i;
struct S
{ void g() { ++i; } }
void impureCaller(scope void delegate() del) pure
{ del(); }
void f() pure // strongly pure, will modify `i`
{
S s;
impureCaller(s.g);
}
---
Currently the only error is in `impureCaller` body. You propose to make
`impureCaller`'s body valid thus making the code compilable. Do you also
propose some breaking changes to make `f` body invalid? I see no
breaking changes notes in you nutshell at the end. Looks like you
either didn't think enough about such cases or you propose to make it
impossible to detect whether the function is strongly pure by it's
signature.
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: std.templatecons ready for comments
10.11.2013 19:30, Ilya Yaroshenko пишет: Hello, All! std.templatecons: Functional style template constructors. Documentation: http://9il.github.io/phobosx/std.templatecons.html Source: https://github.com/9il/phobosx/blob/master/std/templatecons.d Note: dmd = 2.64 required Please destroy! I am sorry for my English in sources/docs. Best Regards, Ilya No more plain modules, please. Call it `std.meta.something`. I'm against of including a few range-like (i.e. like `std.range` and `std.algorithm` stuff) templates like `RepeatExactly`, `templateStaticMap`, and `templateFilter`. First these are generic tuple manipulation templates belong to `std.meta.generictuple` (or how it's called now). Second I'd like to see one-to-one analog of all (most) applicable range operation functions for generic tuples in Phobos by merging in e.g. [1] As for `std.functional`-like template I can't tell much as the only ones http://denis-sh.bitbucket.org/unstandard/unstd.templates.html [1] http://denis-sh.bitbucket.org/unstandard/unstd.generictuple.html -- Денис В. Шеломовский Denis V. Shelomovskij
Re: std.templatecons ready for comments
12.11.2013 0:33, Denis Shelomovskij пишет: 10.11.2013 19:30, Ilya Yaroshenko пишет: Hello, All! std.templatecons: Functional style template constructors. Documentation: http://9il.github.io/phobosx/std.templatecons.html Source: https://github.com/9il/phobosx/blob/master/std/templatecons.d Note: dmd = 2.64 required Please destroy! I am sorry for my English in sources/docs. Best Regards, Ilya No more plain modules, please. Call it `std.meta.something`. I'm against of including a few range-like (i.e. like `std.range` and `std.algorithm` stuff) templates like `RepeatExactly`, `templateStaticMap`, and `templateFilter`. First these are generic tuple manipulation templates belong to `std.meta.generictuple` (or how it's called now). Second I'd like to see one-to-one analog of all (most) applicable range operation functions for generic tuples in Phobos by merging in e.g. [1] As for `std.functional`-like template I can't tell much as the only ones http://denis-sh.bitbucket.org/unstandard/unstd.templates.html [1] http://denis-sh.bitbucket.org/unstandard/unstd.generictuple.html Sorry, accidental Ctrl+Enter. So let me continue: As for `std.functional`-like template I can't tell much as the only ones I really use are `unaryFun`/`binaryFun` and its string-to-function abilities which I also need for templates and which I also want to have in Phobos (see [2]). [2] http://denis-sh.bitbucket.org/unstandard/unstd.templates.html -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Expanding the horizons of D purity
01.11.2013 0:05, H. S. Teoh пишет:
I'd like to propose extending the scope of weak purity one step further:
allow weakly-pure functions to call (not necessarily pure) delegates
passed as a parameter.
Unacceptable. It will break strongly purity. Your mistake is strongly
pure function can easily get an impure delegate:
---
int i;
struct S
{ void g() { ++i; } }
void impureCaller(scope void delegate() del) pure
{ del(); }
void f() pure // strongly pure, will modify `i`
{
S s;
impureCaller(s.g);
}
---
So issues 11469 [1] 11412 [2] are the only way I see to solve our
problems.
[1] http://d.puremagic.com/issues/show_bug.cgi?id=11469
[2] http://d.puremagic.com/issues/show_bug.cgi?id=11412
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: Copy elision by spec
04.11.2013 11:02, Lars T. Kyllingstad пишет: My question is therefore, is this by design? Can I rely on this to work in the future, and on all compilers? If this is the case, it really should be added to the spec. This is Issue 10372 [1]. [1] https://d.puremagic.com/issues/show_bug.cgi?id=10372 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Expanding the horizons of D purity
01.11.2013 21:12, H. S. Teoh пишет: On Fri, Nov 01, 2013 at 08:59:29PM +0400, Denis Shelomovskij wrote: 01.11.2013 0:05, H. S. Teoh пишет: [...] So, in a nutshell, my proposal is: - Functions that, besides invoking a delegate parameter, are pure, should be allowed to be marked as pure. - Template functions that, besides invoking a delegate parameter, perform no impure operations should be inferred as pure. - A function that takes a delegate parameter cannot be strongly pure (but can be weakly pure), unless the delegate itself is pure. (Rationale: the delegate parameter potentially involves arbitrary references to the outside world, and thus cannot be strongly pure.) T The code you like to make working looks good but I'm against the language change. I'd say the issue is nested pure functions aren't allowed to access outer function variables. Filed as Issue 11412. [...] No, that's not good enough. What if you need to pass an impure delegate to toString()? Sure, std.format can be made to use only pure delegates, but you can't predict other code that needs to use toString. Forcing toString to take only pure delegates makes it unusable with output ranges that need to perform impure operations. With my proposal, toString will work with *both* pure and impure delegates -- basically, the pure qualifier becomes a dependent purity (purity of this function depends on the delegate parameter, body of function is pure besides the invocation of the delegate). T I'd say `@safe`, `pure`, and `nothrow` are in the same boat here and the solution should work for them all. Probably we will need a delegate attributes wildcard. Something like this: --- // a single wildcard for all: void f(void delegate() @attr_wildcard del) @attr_wildcard; --- or better: --- // `f` is `@safe`, it also `pure` and `nothrow` if `del` is: void f(void delegate() @safe pure? nothrow? del) @safe pure? nothrow?; --- Also, do you disagree with the proposal in Issue 11412 [1]? [1] http://d.puremagic.com/issues/show_bug.cgi?id=11412 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Expanding the horizons of D purity
01.11.2013 0:05, H. S. Teoh пишет:
[I actually came up with this idea last week, but decided to postpone
bringing it up until all the furor about Andrei's new allocator design
has settled a little. ;-)]
One of the neatest things about purity in D is that traditionally impure
operations like mutation and assignment can be allowed inside a pure
function, as long as the effect is invisible to the outside world. This,
of course, describes strong purity. Weak purity takes it one step
further, by allowing mutation of outside state via references to mutable
data passed in as function arguments.
I'd like to propose extending the scope of weak purity one step further:
allow weakly-pure functions to call (not necessarily pure) delegates
passed as a parameter. That is, the following code should work:
// N.B. This is a (weakly) pure function.
void func(scope void delegate(int) dg) pure
{
// N.B. This calls an *impure* delegate.
dg(1);
}
Before you break out the pitchforks, please allow me to rationalize this
situation.
The above code is essentially equivalent to:
void func(void *context, scope void function(void*,int) dg) pure
{
dg(context, 1);
}
That is to say, passing in a delegate is essentially equivalent to
passing in a mutable reference to some outside state (the delegate's
context), and a pointer to a function that possibly mutates the outside
world through that context pointer. In a sense, this is not that much
different from a weakly pure function that directly modifies the outside
world via the context pointer.
But, I hear you cry, if func calls an *impure function* via a function
pointer, doesn't that already violate purity??!
Well, it certainly violates *strong* purity, no question about that. But
consider this code:
int stronglyPure(int x) pure
{
int[] scratchpad;
scratchpad.length = 2;
// This is an impure delegate because it closes over
// scratchpad.
auto dg = (int x) { scratchpad[x]++; };
// Should this work?
func(dg);
return scratchpad[1];
}
Think about it. What func does via dg can only ever affect a variable
local to stronglyPure(). It's actually impossible for stronglyPure() to
construct a delegate that modifies a global variable, because the
compiler will complain that referencing a global is not allowed inside a
pure function (verified on git HEAD). Any delegate that stronglyPure()
can construct, can only ever affect its local state. The only way you
could sneak an impure delegate into func() is if stronglyPure() itself
takes an impure delegate as parameter -- but if it does so, then it is
no longer strongly pure.
IOW, if stronglyPure() is truly strongly pure, then it is actually
impossible for the call to func() to have any effect outside of
stronglyPure()'s local scope, no matter what kind of delegate
stronglyPure() passes to func(). So such a call should be permitted!
Now let's consider the case where we pass a delegate to func() that
*does* modify global state:
int global_state;
void main() {
func((int x) { global_state = x; });
}
In this case, func being marked pure doesn't really cause any issues:
main() itself is already impure because it is constructing a delegate
that closes over a global variable, so the fact that the actual change
comes from calling func no longer matters. It's always OK for impure
code to call pure code, after all. It's no different from this:
void weaklyPure(int* x) pure {
*x = 1; // OK
}
int global_state;
void main() {
weaklyPure(global_state);
}
That is to say, as long as the code that calls func() is marked pure,
then the behaviour of func() is guaranteed never to affect anything
outside the local scope of the caller (and whatever the caller can reach
via mutable reference parameters). That is, it is (at least) weakly
pure. If the caller is strongly pure (no mutable indirections in
parameters -- and this includes delegates), then func() is guaranteed to
never cause side-effects outside its caller. Therefore, it should be
permissible to mark func() as pure.
//
Why is this important? Well, ultimately the motivation for pushing the
envelope in this direction is due to functions of this sort:
void toString(scope void delegate(const(char)[]) dg) {
dg(...);
}
By allowing this function to be marked pure, we permit it to be called
from pure code (which I proved in the above discussion as actually
pure). Or, put another way, we permit template functions that call
toString with a delegate that updates a local variable to be inferred as
pure. This allows more parts of std.format to be pure, which in turn
expands the usability of things like std.conv.to
Re: Tristate - wanna?
27.10.2013 4:08, Timon Gehr пишет: On 10/26/2013 05:42 PM, Andrei Alexandrescu wrote: While messing with std.allocator I explored the type below. I ended up not using it, but was surprised that implementing it was quite nontrivial. Should we add it to stdlib? Theory: http://en.wikipedia.org/wiki/Three-state_logic The term tri-state[1] should not be confused with ternary logic (3-value logic). So this thread is about a three-valued logic with same truth tables as in Kleene's and Priest's logics. See: * http://en.wikipedia.org/wiki/Many-valued_logic * http://en.wikipedia.org/wiki/Three-valued_logic -- Денис В. Шеломовский Denis V. Shelomovskij
Re: More on C++ stack arrays
23.10.2013 1:05, Lionello Lunesu пишет: Careful! Alloca doesn't get cleaned up when used in loops! And I don't use `alloca`. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: More on C++ stack arrays
21.10.2013 14:30, Manu пишет: System interface functions that pass zero-terminated strings through to the OS are the primary offender, needless garbage, those should be on the stack. I like to use alloca too where it's appropriate. I'd definitely like if D had a variable-sized static array syntax for pretty-ing alloca. I thought about something similar using alloca via a mixin template, but that feels really hackey! No hacks needed. See `unstd.c.string` module from previous post: http://forum.dlang.org/thread/lqdktyndevxfcewgt...@forum.dlang.org?page=2#post-l42evp:241ok7:241:40digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Re: More on C++ stack arrays
21.10.2013 18:04, dennis luehring пишет: ...Implementation note: For small strings tempCString will use stack allocated buffer, for large strings (approximately 1000 characters and more) it will allocate temporary one from unstd.memory.allocation.threadHeap... does that mean that tempCString reserves minimum 1000 bytes on stack else using heap? if so i would prefer a template based version where i can put in the size Yes, `tempCString` allocates `1024 * To.sizeof` bytes on the stack. Note that it doesn't initialize the data so it is O(1) operation which will just do ~1 KiB move of stack pointer. As function stack frame can easily eat 50-100 bytes it is like 10-20 function calls. IIRC typical stack size is ~1 MiB and `tempCString` isn't expected to be used in some deep recursion or be ~1000 times used in one function. So I'd prefer to change default stack allocation size if needed and not confuse user with manual choice. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: add -allinst compiler switch
18.10.2013 11:17, Walter Bright пишет: Explained here: http://d.puremagic.com/issues/show_bug.cgi?id=11284 It's a bit complicated, and important. BTW, I hate the name of the switch, but haven't thought of anything better. Links to user complains are needed or the issue sounds not evident. E.g. the only issues with dmd object generation change after dmd pull #2550 [1] I have seen are compiler bugs when it incorrectly detects instantiating module (e.g. issues 11069 [2] and 4 [3]). Also personally I against supporting incorrect user actions just because it was supported before just like we do every release with fixing accept-invalid bugs. [1] https://github.com/D-Programming-Language/dmd/pull/2550 [2] http://d.puremagic.com/issues/show_bug.cgi?id=11069 [3] http://d.puremagic.com/issues/show_bug.cgi?id=4 -- Денис В. Шеломовский Denis V. Shelomovskij
Petition to chime in Issue 1553 - foreach_reverse is allowed for delegates
`foreach_reverse` is allowed for delegates and do what `foreach` do thus causing dangerous confusion. Walter Bright is the only one for some obscure reason definitely for not deprecating this feature and WONTFIX-ed the issue. And yes, no big red note in docs about it. As always, this is even more error-prone for highly templated language like D (i.e. one can expect in template `foreach_reverse` will not compile if reverse iteration isn't supported). Petition for all not indifferent to language misfeatures to chime in and show in this thread we all are for deprecating it (if we really are). Issue URL: http://d.puremagic.com/issues/show_bug.cgi?id=1553 Thanks. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Petition to chime in Issue 1553 - foreach_reverse is allowed for delegates
20.10.2013 15:29, Denis Shelomovskij пишет: `foreach_reverse` is allowed for delegates and do what `foreach` do thus causing dangerous confusion. Walter Bright is the only one for some obscure reason definitely for not deprecating this feature and WONTFIX-ed the issue. And yes, no big red note in docs about it. As always, this is even more error-prone for highly templated language like D (i.e. one can expect in template `foreach_reverse` will not compile if reverse iteration isn't supported). Petition for all not indifferent to language misfeatures to chime in and show in this thread we all are for deprecating it (if we really are). Issue URL: http://d.puremagic.com/issues/show_bug.cgi?id=1553 Thanks. Also the funny thing is according to Andrei [1] about `foreach_reverse` over ranges from February 2010: Gone, that is. Walter agreed to remove it. [1] http://forum.dlang.org/post/hl8345$2b1q$1...@digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Re: More on C++ stack arrays
20.10.2013 18:25, bearophile пишет: More discussions about variable-sized stack-allocated arrays in C++, it seems there is no yet a consensus: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf I'd like variable-sized stack-allocated arrays in D. I'd say the most common case one need a stack-allocated array is a temporary allocation which isn't going to survive end of scope. Even more in such cases for too large for stack data one want to allocate from thread local heap instead of shared one to prevent needless locking. `unstd.memory.allocation.tempAlloc` [1] will do the job. As the one of the most common subcases is a temporary C string creation `unstd.c.string.tempCString` will help here. [1] http://denis-sh.bitbucket.org/unstandard/unstd.memory.allocation.html#tempAlloc [2] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html#tempCString -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
17.10.2013 12:09, Martin Nowak пишет: On 10/13/2013 09:47 AM, Denis Shelomovskij wrote: * Alex's one from MCI: https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d I remember talking about this with Alex. He wanted to add some functions to the GC and this is what I came up with based on the current implementation. It uses the synchronized GC.addrOf to check whether the loaded pointer is still valid. Still looks correctly synchronized to me. https://gist.github.com/dawgfoto/2852438 In fact the load!(msync.acq) could be made load!(msync.raw) too. The only thing we need from `GC.addrOf` here is a GC barrier i.e. `lock`/`unlock` pair so runtime changes are necessary for performance. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
16.10.2013 3:20, Sean Kelly пишет: On Tuesday, 15 October 2013 at 22:09:17 UTC, Robert wrote: The problem is that destructors and thus the registered hooks for the dispose events are called when threads are already resumed. If this wasn't the case there would actually be no problems. Gotcha. Looking at the code... I think you'll get this to work, but manipulating such user-mode weak references seems really expensive. Why not work on a DIP to get them built in? For example, one option might be to have the GC perform certain types of finalization while the world is stopped. This would have to be limited to very rudimentary stuff, and the easiest way to guarantee that would be to have everything live in Druntime. But someone have to do it. And I can only see it will save one of two GC lock/unlock pairs. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
16.10.2013 3:20, Sean Kelly пишет: On Tuesday, 15 October 2013 at 22:09:17 UTC, Robert wrote: The problem is that destructors and thus the registered hooks for the dispose events are called when threads are already resumed. If this wasn't the case there would actually be no problems. Gotcha. Looking at the code... I think you'll get this to work, but manipulating such user-mode weak references seems really expensive. Why not work on a DIP to get them built in? For example, one option might be to have the GC perform certain types of finalization while the world is stopped. This would have to be limited to very rudimentary stuff, and the easiest way to guarantee that would be to have everything live in Druntime. What about this: https://github.com/D-Programming-Language/druntime/pull/639 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
14.10.2013 17:42, robert пишет: Damn it, you are right I did not think this through, somehow thought the use in addrOf is enough, which is of course crap. Thank's a lot for your time, I'll fix this ASAP. So, here are your revised version: https://github.com/phobos-x/phobosx/blob/1f0016c84c2043da0b9d2dafe65f54fcf6b6b8fa/source/phobosx/signal.d Sorry, but you are making the same mistake again. Lets start from the hardware. Just like a compiler CPU is free to do whatever it wants with passed instructions but guarantee result state will be the same as if it is executed sequentially. And it doesn't assume access from other threads by default (see e.g. out-of-order execution). So memory barriers (memory fences) are needed to ensure loads/stores before the barrier are performed and no loads/stores after the barrier are executing. This is what `core.atomic.atomicFence` does and it can be used in e.g. in mutex implementations. As your operations with `_obj` are already atomic no `atomicFence` call is needed. Now let's assume without loss of generality `InvisibleAddress.address` returns `cast(void*) ~_addr`, inline the `address` call, and remove redundant `atomicFence` call: ``` auto tmp = atomicLoad(_obj); auto o = cast(void*) ~tmp._addr; if(o is null) return null; GC.addrOf(o); auto tmp1 = atomicLoad(_obj); if(o is cast(void*) ~tmp1._addr) return cast(Object) o; assert(cast(void*) ~tmp1._addr is null); return null; ``` As I mentioned above you are making the same incorrect assumption that you know what machine instructions a compiler will generate. Never make such assumptions. Here is an example of how your code can be rewritten by a compiler: ``` auto tmp = atomicLoad(_obj); if(tmp._addr == -1) return null; GC.addrOf(cast(void*) ~tmp._addr); auto tmp1 = atomicLoad(_obj); if(tmp._addr == tmp1._addr) return cast(Object) cast(void*) ~tmp._addr; assert(tmp1._addr == -1); return null; ``` -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
13.10.2013 22:19, Walter Bright пишет: On 10/13/2013 12:47 AM, Denis Shelomovskij wrote: --- Proposal --- Please post as a DIP: http://wiki.dlang.org/DIPs The trouble with it as a n.g. posting is they tend to scroll off and be forgotten. Why? There is already enhancement request 4151 to no forget and review queue to add it into. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
13.10.2013 21:36, Robert пишет: * Robert's one from his new `std.signals` implementation proposal: https://github.com/phobos-x/phobosx/blob/d0cc6b45511465ef1d493b0d7226ccb990ae84e8/source/phobosx/signal.d Obviously I don't see it, otherwise I would have fixed it. Maybe you could elaborate a bit on your claim? Your implementation uses an entirely different technique for hiding the reference so a direct comparison is quite hard. 1. Have you read `gc.gc.fullcollect`, I mean a general function structure, not every line? If not, read it or you have no idea how collection performs. 2. I'm surprised you do think your implementation is correct as calling code twice (`foreach(i; 0..2)`) is an obvious hack to decrease a variety of undesired threads execution order (as it have to execute in this order twice). - Explanation - 1. Race condition In every moment GC thread can be paused in state it already marked all dead blocks and ready to collect. So before `GC.addrOf` (which will have to wait for the end of the collection as it uses same mutex) call it can collect your object (the object can be on stack or whatever, doesn't matter). Also an new object can be created occupying the same memory and `GC.addrOf` will return non-null. 2. Incorrect assumption `o = GC.addrOf(tmp.address)` is just incorrect as you assume the object is placed at the base address of its memory block which is not guaranteed. Yes, it may be true for now (I haven't read GC sources enough to be definite here) in general case but what about some e.g. tricky user defined class instance sequences which user may create? Yes, never heard about it and just invented it, but it doesn't make this or similar case impossible. Also it's rather bad to do any needless assumption about internal stuff. - P.S. - I have to say you have a big problem especially for a programmer: you think you are competent in area you aren't and it can play a trick on you later. Please don't be angry with me, we all like to think so but we all have to look at ourselves as critically as possible to prevent problems in future. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
14.10.2013 13:04, robert пишет: Why would I be angry with a stranger who insults me in public? I don't understand your concerns. No insults assumed! Just ugly truth about all of us. ) If you are more experienced in this area I am glad if you share your insights and Walter and Andrei often do silly mistakes. Can we suppose we are more experienced than they? Of course no, they just don't have enough time to think and check. Here the situation can be the same. I probably just have enough time to investigate the problem and solve it. if you think something is wrong, I am glad to discuss it and fix it if you are right, but just saying your implementation is wrong, does not really help. It implies that you are obviously right and everyone who does not see this is obviously a moron, if someone has a bit of a problem with his ego, I don't think it is me. Easy, man. I have never met morons here, except, probably, myself. Concurrent programming is fun so I just don't want to spoil the pleasure of investigation. And yes, I'm also lazy. ) Now about your code. First, I was completely incorrect about it, sorry for that. My mistake. I didn't even think the code containing such loop can be so much correct. But, and this is the second, the code can't be more or less correct. It is either correct or not correct. It remembers me our (Russian) recent Moscow mayoral elections when we tried to change something in our country (we failed, yes) and after government won officials said: It was the most honest elections of all preceding. ) So you code is incorrect and lets show it. When you give your code for eating to the compiler, it can does whatever it want but guarantee your program will work as you have written it (except special cases like copy construction elimination) and it doesn't assume every variable can be accessed from other threads. E.g. here is you code with unwinded loop in SSA (static single assignment) form: ``` auto tmp1 = atomicLoad(_obj); void* o1 = tmp1.address; if(o1 is null) return null; void* o2 = GC.addrOf(tmp1.address); auto tmp2 = atomicLoad(_obj); void* o3 = tmp2.address; if(o3 is null) return null; void* o4 = GC.addrOf(tmp2.address); if(o4) return cast(Object) o4; return null; ``` `o1` is only used once and `o2` is never used so the compiler is free to discard the former and ignore the latter. So your code equals to this code: ``` auto tmp1 = atomicLoad(_obj); if(tmp1.address is null) return null; GC.addrOf(tmp1.address); auto tmp2 = atomicLoad(_obj); if(tmp2.address is null) return null; void* o4 = GC.addrOf(tmp2.address); if(o4) return cast(Object) o4; return null; ``` So the second iteration gives nothing except decreasing (squaring to be precise) a variety of undesired threads execution order. -- Денис В. Шеломовский Denis V. Shelomovskij
[Proposal] Weak reference implementation for D
--- Proposal --- The proposal is to add weak reference functionality based on `unstd.memory.weakref`. It can be placed e.g. in `core.memory`. Source code: https://bitbucket.org/denis-sh/unstandard/src/HEAD/unstd/memory/weakref.d Documentation: http://denis-sh.bitbucket.org/unstandard/unstd.memory.weakref.html Enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=4151 --- Reasons --- Reasons, why we do need weak reference functionality in D (Issue 4151 [1]): 1. It has a general use. I suppose no question here. 2. It's hard to implement correctly. As a proof here are incorrect implementations written by experienced developers: * Weak reference functionality in `std.signal` implementation: https://github.com/D-Programming-Language/phobos/blob/7134b603f8c9a2e9124247ff250c9b48ea697998/std/signals.d * Alex's one from MCI: https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d * Robert's one from his new `std.signals` implementation proposal: https://github.com/phobos-x/phobosx/blob/d0cc6b45511465ef1d493b0d7226ccb990ae84e8/source/phobosx/signal.d * My implementation (fixed now, I hope): https://bitbucket.org/denis-sh/unstandard/src/cb9a835a9ff5/unstd/memory/weakref.d Everybody can check his knowledge of concurrent programming and D GC by trying to understand what exactly every implementation does and where are race conditions. It's recommended to read implementations in the order provided here going to the next one as soon as you see why previous one is incorrect. For now the only [probably] fixed implementation is mine so one can see spoiler here: https://bitbucket.org/denis-sh/unstandard/history-node/HEAD/unstd/memory/weakref.d (the first and the most fixing (spoiling you joy to understand everything yourself) commit is 6f59b33) 3. It's hard to create a good API design for it. No jokes. E.g. there are two different behaviours of .NET weak references and even more in Java library. 4. It is needed for correct signals implementation in D. The lack of correct signals implementation is one of [major?] disadvantages of D. Bug report: http://d.puremagic.com/issues/show_bug.cgi?id=9606 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
13.10.2013 12:55, Sönke Ludwig пишет: Am 13.10.2013 09:47, schrieb Denis Shelomovskij: Just to reassure, the following race-condition doesn't exist, right? It looks like GC.addRoot() makes guarantees by taking the GC lock or something similar? time - thread1: GC collection | | run finalizer | thread2: paused| lock weak ref | | access object All public GC API uses same mutex. So right, no races here. ) -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
13.10.2013 12:36, Benjamin Thaut пишет: Will rt_attachDisposeEvent also work with std.allocator? Or does it rely on the GC running? What exactly do you mean? `rt_attachDisposeEvent` adds delegate to `object.__monitor.devt` array which is called from `rt_finalize2 - _d_monitordelete - _d_monitor_devt`. -- Денис В. Шеломовский Denis V. Shelomovskij
Unstandard, a general purpose library
*Unstandard* is a library for general purpose usage aimed to be an addition to the *D* standard runtime library *Phobos*. The author would like to pull as much functionality as possible to Phobos but it's a rather difficult and slow work. NOTE: It's a personal one-man library, not some experimental stuff for *Phobos*. There is nothing official in it. Project page: https://bitbucket.org/denis-sh/unstandard Documentation: http://denis-sh.bitbucket.org/unstandard/ Partial Unstandard brief content description --- * For string manipulation functions see unstd.c.string and unstd.utf. * For user-defined lifetime implementation see unstd.lifetime. * For various metaprogramming stuff see unstd.generictuple, unstd.templates, and unstd.traits. * For various GC and non-GC memory manipulation stuff see unstd.memory.allocation, unstd.memory.misc, unstd.memory.weakref, and unstd.windows.heap. * For functions to manipulate with multidimensional rectangular arrays see unstd.multidimarray. Also see for other useful stuff unstd.array, unstd.casts, unstd.math, and unstd.typecons. Read documentation for more information. P.S. --- The library is about one year old. It has been mentioned few times in digitalmars.D NG as phobos-additions library. The name was changed to prevent thinking it has a relation to the official library. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Rectangular multidimensional arrays for D
09.10.2013 7:55, Nick B пишет: On Tuesday, 8 October 2013 at 17:26:46 UTC, Stefan Frijters wrote: andrei wrote: I too are interesteed in this area as well. Dennis do you only plan to focus on multidimensional arrays only, or will you incorporate the above matrices as well ?? What features are you proposing ? I propose stuff for multidimensional arrays only as you noted. And I plan just to revise my existing API [1] without cardinal changes. I.e. all I propose is rectangular multidimensional arrays slicing and iterating. For matrix and math specific tasks see DScience [2] and SciD [3]. The latter started as a fork of DScience but became a separate project and is in development. See its wiki [4]. Also such math oriented libraries have to be partially (and the are) wrapper around LAPACK. Also it will be interest to see features you (Stefan and Nick) need e.g. as examples of code you want to compile with comments if needed. Write down at least basic features for now. [1] http://denis-sh.bitbucket.org/unstandard/unstd.multidimensionalarray.html [2] https://github.com/dscience-developers/dscience [3] https://github.com/kyllingstad/scid [4] https://github.com/kyllingstad/scid/wiki -- Денис В. Шеломовский Denis V. Shelomovskij
Re: My thoughts experiences with D so far, as a novice D coder
28.03.2013 0:28, Andrei Alexandrescu пишет: On 3/27/13 3:18 PM, H. S. Teoh wrote: Which is what Denis' multidimensional array implementation does. As does my implementation as well. This seems to be quite a common use-case; we should put this into Phobos IMO. Agree. Do you (or Denis) have something in reviewable form? Andrei No. The module is 2 years old and I only made changes on dmd requests. But if such functionality is really needed I will be happy to revise API and prepare my implementation for review. P.S. It's an accident I have seen this post. I think in the case of such questions it is obligatory to e-mail the author or there is a big risk the question will bot be delivered. -- Денис В. Шеломовский Denis V. Shelomovskij
Rectangular multidimensional arrays for D
I accidentally discovered Andrei wrote [1] multidimensional array implementation is needed. If it really is, I will work to revise the API and prepare my implementation [2] for review if nobody is doing it already. Also as Kenji's multidimensional indexing and slicing pull [3] still not merged the only way is to use hacks like this: --- // first two rows and three columns of the second matrix array2d = matrices[1, R[0 .. 2], R[0 .. 3]]; --- [1] http://forum.dlang.org/post/kivkp0$csp$1...@digitalmars.com [2] http://denis-sh.bitbucket.org/unstandard/unstd.multidimensionalarray.html [3] https://github.com/D-Programming-Language/dmd/pull/443 --- Previous related topics --- At least the ones I participated in: * October 09, 2011: Kenji Hara proposes Matrix-type-friendly syntax and more. His dmd pull #443 still isn't merged. http://forum.dlang.org/thread/j6sp68$2a7k$1...@digitalmars.com https://github.com/D-Programming-Language/dmd/pull/443 * October 25, 2011: Original Multidimensional arrays for D post. No response from Phobos developers. http://forum.dlang.org/thread/j864es$2gi0$1...@digitalmars.com * June 17, 2012: A request for template that can simulate a rectangular array. http://forum.dlang.org/thread * June 30, 2012: A request for fixed size multidimensional array at runtime. http://forum.dlang.org/thread/ldjzfqvnjltbbiovq...@forum.dlang.org -- Денис В. Шеломовский Denis V. Shelomovskij
What endiannesses do D support?
Some of druntime/phobos code assumes it is one of little/big endianness others have `static assert(0)` for third case. Lets clear the situation and make a decision. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What endiannesses do D support?
04.10.2013 15:00, Alex Rønne Petersen пишет: On Friday, 4 October 2013 at 10:59:05 UTC, Denis Shelomovskij wrote: Some of druntime/phobos code assumes it is one of little/big endianness others have `static assert(0)` for third case. Lets clear the situation and make a decision. Little endian and big endian must be supported. Little endian PowerPC, for example, is extremely rare (if not entirely extinct), so just supporting little endian is not enough. Of course. The question is about a third case. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Bug 6186
02.10.2013 23:03, Benjamin Thaut пишет: Am 02.10.2013 20:56, schrieb H. S. Teoh: On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote: Well thats the problem with volenteer work. People usually pick something they interrested in. (Kenji beeing an exception to this rule) The most annoying struct lifetime bug for me is the following: http://d.puremagic.com/issues/show_bug.cgi?id=8360 So Kenji rapidly (as often) did https://github.com/D-Programming-Language/dmd/pull/2620 Let's be astonished by his response time! -- Денис В. Шеломовский Denis V. Shelomovskij
Re: D2 is really that stable as it is claimed to be?
21.09.2013 21:41, Zhouxuan пишет: http://d.puremagic.com/issues/show_bug.cgi?id=11086 http://d.puremagic.com/issues/show_bug.cgi?id=11010 http://d.puremagic.com/issues/show_bug.cgi?id=10970 I've found and reported these bugs after about merely 100 LOCs written down. Should I continue? Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all. A year or two ago it was a lot of wrong-code bugs with lambdas and nested functions making e.g. `std.algorithm` almost unusable. But it's only the beginning. OPTLINK bug causing random linking failures thus making the whole language unusable for real projects was fixed only about half a year ago. And all this time I liked D except the language is stable words. And when half a year ago D become fully usable I become happy. For me enough stability is an ability to grab my copy of tool-chain and work with it without random failures. Since then I had not any real problems with breaking changes or regressions. Generally regressions are fixed quickly and as for me the more breaking changes the better language we get. ) -- Денис В. Шеломовский Denis V. Shelomovskij
[Remove SPAM] Re: Last day! 30% OFF Rip Blu-ray to M2TS with original quality
Remove the spam please!
Re: D-thrift package detects regressions since 2.061, where is the regression suite located?
13.08.2013 21:49, glycerine пишет: Grrr... Apparently nobody has been testing the D - Apache Thrift bindings since 2.061, and dmd has since accumulated multiple regressions that affect the correctness of the Thrift implementation. I emailed with David N. and he said that this was quite common for each release of dmd, and that while he used to religously evaluate each new dmd release on the Thrift bindings, he had simply not had the time for more recent recents to test each thoroughly. Serialization: this is fundamental. This really isn't the kind of thing that should ever be allowed to break. Hence it really isn't something that should be tested manually. It should be an automatic part of the automatic regression detection test suite. Where is the regression suite for D located, and how can I add to it? There used to be github issue tracking, but I don't see it any more... is it hiding under their new interface perhaps...? Thanks. - glycerine By the way, the ability to add costume projects to D autotester is already proposed without any response: http://forum.dlang.org/thread/kqm4ta$m7f$1...@digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
04.08.2013 11:53, dennis luehring пишет: Am 04.08.2013 09:35, schrieb Walter Bright: On 8/4/2013 12:19 AM, Joseph Rushton Wakeling wrote: On Sunday, 4 August 2013 at 06:07:54 UTC, dennis luehring wrote: ever tested nedmalloc (http://www.nedprod.com/programs/portable/nedmalloc/) or other malloc allocators? Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 all contain state-of-the-art allocators and no third party allocator is likely to significantly improve on them in real world results. So there may be minimal returns from incorporating nedmalloc on modern OS's ... ? As I wrote earlier, Microsoft has enormous incentive to make Heap as fast as possible, as it will pay dividends for every Microsoft software product and software designed for Windows. I'm sure the engineers there know all about the various strategies available on the intarnets. Why not take advantage of their work? HeapAlloc is a forwarder to RtlHeapAlloc and C++ new does call RtlHeapAlloc directly - would it be better to use this kernel32 api directly? (maybe if used in druntime to reduce dll dependencies) Up to Windows XP (at least) KERNEL32's HeapAlloc function is forwarded to RtlAllocateHeap [1] function exported by NTDLL so there is no runtime performance overhead. There is no RtlHeapAlloc function on my Windows XP and I can't find any information about it on the web. Looks like a Windows 6.x stuff or a mistake in name. Also note there are tons of errors because of such slightly different names. If we are talking about Heap* functions: 1. Incorrect RtlAllocHeap name here [2]. 2. Incorrect HeapFree function signature (4-byte BOOL is returned but it is just a wrapper of RtlFreeHeap which returns 1-byte BOOLEAN) (fixed in Windows 6.x). [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff552108(v=vs.85).aspx [2] http://msdn.microsoft.com/ru-ru/magazine/cc301808(en-us).aspx -- Денис В. Шеломовский Denis V. Shelomovskij
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
04.08.2013 1:55, Walter Bright пишет: The execrable existing implementation was scrapped, and the new one uses Windows HeapAlloc(). http://ftp.digitalmars.com/snn.lib This is for testing porpoises, and of course for those that Feel Da Need For Speed. So I suppose you use `HeapFree` too? Please, be sure you use this Windows API BOOL/BOOLEAN bug workaround: https://github.com/denis-sh/phobos-additions/blob/e061d1ad282b4793d1c75dfcc20962b99ec842df/unstd/windows/heap.d#L178 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Strict aliasing in D
27.07.2013 12:59, Walter Bright пишет: On 7/27/2013 1:57 AM, David Nadlinger wrote: On Saturday, 27 July 2013 at 06:58:04 UTC, Walter Bright wrote: Although it isn't in the spec, D should be strict aliasing. This is because: 1. it enables better code generation 2. there are ways, such as unions, to get the other aliasing that doesn't break strict aliasing We need to carefully formalize this then, and quickly. The problem GCC, Clang and others are facing is that (as you are probably aware) 2. isn't guaranteed to work for type-casting pointers either by the specs, but people want to be able to do this nonetheless. Thus, they both accept pointer aliasing through union types, trying to optimize as much as possible while avoiding to break people's expectations and existing code. This is a very unfortunate situation for both compiler developers and users; just search for something like gcc strict aliasing on StackOverflow for examples. There is already quite a lot of D code out there that violates the C-style strict aliasing rules. I agree. Want to do an enhancement request on bugzilla for it? So is enhancement request filed? -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Feature request: assert expressions should live inside version(assert)
07.07.2013 17:12, Tommi пишет: On Sunday, 7 July 2013 at 12:30:28 UTC, Andrej Mitrovic wrote: On 7/7/13, Tommi tommitiss...@hotmail.com wrote: Sometimes you need to have some extra data to check against in the assert expression. That data isn't needed in release mode when assertions are ignored. Therefore, you put that extra data inside a version(assert). But then those assertions fail to compile in release mode because the symbol lookup for that extra data fails. For this reason, assert statements should live inside version(assert) blocks by default. I've ran into an issue when implementing this feature back in February (see the pull request): http://d.puremagic.com/issues/show_bug.cgi?id=9450 https://github.com/D-Programming-Language/dmd/pull/1614 Oh, should have searched bugzilla before posting this. But would it be possible to implement it something like: During a release build, even though version(assert) blocks are compiled out of existence, the compiler would keep a separate list of symbols (and other info) of the things declared inside those version(assert) blocks. Then, when parsing assert expressions, if an undefined symbol is found, the compiler would check that separate list of symbols that it has been keeping, and if the symbol is found there and use of the symbol is syntactically correct, the compiler would just keep on going instead of spewing an unidentified identifier error. That way we'd make sure that things like: assert(this_identifier_doesnt_exist 12); ...wouldn't compile. It's always a bad idea to add special cases like this one for `version(assert)`. Anyway one will get into huge troubles trying to implement such stuff as I even can't imagine how it can be implemented consistently. -- Денис В. Шеломовский Denis V. Shelomovskij
What about to add costume projects to D autotester?
As dmd is actively developed approximately every 2 weeks (since May) I have to find a cause for a regression which takes few hours and is a bit annoying as it looks like a needless job. What about to introduce some benefit criteria (regressions discovered by the project e.g.) relying on which a project is considered to be useful and can is added to autotester? This will help dmd developers to see bugs in their pulls immediately and will save D users time. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: DIP42 - Add enum E(T) = expression; eponymous template support
26.06.2013 20:35, Andrej Mitrovic пишет: On 6/26/13, Denis Shelomovskij verylonglogin@gmail.com wrote: which will look better this way: --- static if (...) enum template = ...; else static if (...) enum template = ...; else ... --- Yeah I agree, this is more important than DIP42's shortened syntax for simple templates. It's the more complicated templates that are the problem. It's rather strange that enhancement 7364 isn't implemented yet (and even not discussed) as it's an easy-to-implement change with big pros and no cons. -- Денис В. Шеломовский Denis V. Shelomovskij
Add static code analyzing to dmd
IMHO it's an important enhancement as I see no reasons for the compiler to not inform about may-be-an-error situations if the user asks as it will save a lot people time. Original issue: http://d.puremagic.com/issues/show_bug.cgi?id=9811 Description: There are things which may or may not indicate and error. Current compiler behavior is: I'm a compiler, I can't even give a warning if there is a chance for false positive, there are only warnings and errors. But it looks inconsistent with the fact a compiler tries to help the developer by doing code coverage, documentation etc. Static code analyzing is an essential task a compiler could also do and do good. Also, IMHO, compilers should do static analyzing instead of external tools. So I propose to add -diagnostic flag to the compiler for things Walter is a bit uncomfortable in declaring it as always wrong and also for things that are definitely not always wrong. There also could be different levels of such analyzing and ability to treat diagnostic warnings as errors. See also: [1] Interview of Walter Bright by Andrey Karpov http://www.viva64.com/en/b/0182/ [2] NG thread about the interview http://forum.dlang.org/thread/nnzzbsafuwwzuotvl...@forum.dlang.org -- Денис В. Шеломовский Denis V. Shelomovskij
Re: DIP42 - Add enum E(T) = expression; eponymous template support
26.06.2013 1:31, Walter Bright пишет: http://wiki.dlang.org/DIP42 What about enhancement 7364 [1] (from [2] discussion)? As we still have such cases: --- static if (...) enum fullyQualifiedNameImplForTypes = ...; else static if (...) enum fullyQualifiedNameImplForTypes = ...; else static if (...) ... --- which will look better this way: --- static if (...) enum template = ...; else static if (...) enum template = ...; else ... --- Also note current syntax is error-prone as one can easily make a typo or copy paste mistake which will lead to cryptic template errors. [1] http://d.puremagic.com/issues/show_bug.cgi?id=7364 [2] http://forum.dlang.org/thread/jfh7po$3b$1...@digitalmars.com?page=1 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: std.signals regressions
14.06.2013 18:31, David пишет:
This code currently fails with a RangeError (used to work in 2.062)
// http://dpaste.dzfl.pl/332a71ec
import std.stdio;
import std.signals;
struct X {
mixin Signal!();
}
class O {
void m() {}
}
void main() {
O o = new O();
X[string] aa;
aa[o] = X.init;
aa[o].connect(o.m);
/*{ // 20
X x = aa[o];
}*/
}
If you take the uncomment the block at line 20 you end up with a
segmentation fault, also worked in 2.062. Both times the problem is in
the __dtor (segfault happens in the call to _d_toObject(stor.ptr).
Changing struct to class and X.init to new X() it seems to work
as it should.
Is this worth a bugreport or was the old behaviour never intended?
This bug (I consider it one) broke quite a few lines of code... If the
old behaviour was never intended, why wasn't it documentated then... oh
well I am drifting into another D rant here...
http://dlang.org/phobos/std_signals.html#Signal
Mixin to create a signal within a class object.
So your `X` must be a class.
Also don't use std.signals - it's an incorrect and dangerous mess (see
bug tracker).
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: about with statement
09.06.2013 14:11, khurshid пишет: D language have like Pascal/Delphi with statement, which very useful for writing readable code. http://dlang.org/statement.html#WithStatement Maybe I'm wrong, but, I never saw where using this statement in phobos source codes, what problem using this statement? Note, that for now you can't instantiate templates in with statement, see Issue 6196 [1]. [1] http://d.puremagic.com/issues/show_bug.cgi?id=6196 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Any plans to fix Issue 9044? aka Language stability question again
25.05.2013 14:07, Denis Shelomovskij пишет: As those of you who do write some non-toy projects in D know, from time to time you projects become unbuildable because of Issue 9044 [1] an you have to juggle with files and randomly copy/move functions from one library to another to detrigger the issue creating mess marked Issue 9044 workaround. It become really annoying when your one-file project using an external library fails as it forcing you to juggle with that library files (e.g. VisualD's `cpp2d` project which triggers the issue randomly). I'd never complain about such things but the language is tend to be self-called stable by main maintainers and I'd like to finally see an official definition of this stability as it obviously contradicts my personal very loyal definition (e.g. I have noting against breaking changes if they are in good direction). [1] http://d.puremagic.com/issues/show_bug.cgi?id=9044 So now the issue is marked as duplicate of Issue 6461 [1]. The issue have no votes. There is no official answers about when it will be fixed. Am I the only one who meet it in almost every project at least at age about dozen days of development? [1] http://d.puremagic.com/issues/show_bug.cgi?id=6461 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Need some opinions for a GUI editor
29.05.2013 1:25, Flamaros пишет: Hi, I and a friend are developing a GUI library, and now our script engine is ready to start a prototype (but far to be finished). We think to try to create a GUI editor based on our library. In this way, we'll see which features are need. My concern is about how the editor have to works, we see two different ways to do it : 1) Classic editor external to the user applications a) Good : - Lightweight (easy to deploy and test) - No need to modify application code - Stable due to isolation of application - Real-time edition but limited on one view (bad to preview menus transitions) b) Bad : - Limited, plugins needed to extend editor components and his knowledge of application (can't predict size of unknown application specific items) 2) Integrated editor (launch with the user application in a second Window) a) Good : - Preview is the final result with real data - All application components accessible to the editor without complex plugin system (in this way all editors components will be well placed in the preview) - Full real-time edition (can preview menus transitions,...) - User can customize the editor b) Bad : - Intrusive in the application code - Force the user to port application on a desktop OS (Linux, Mac or Windows), not friendly if he target only embedded devices (can be bypassed with a remote system) - Less stable editor? The second solution is commonly used in the video game industry, but is the best choice for a larger usage? What do you think about? As for me, a GUI editor is completely unneeded. Currently I'm using GTK+ for my apps so I tried to use Glade a long time ago but finished manually writing all the code as it: 1. It is not complicated and not time-wasted at all. 2. It gives you more control on the application. 3. It saves you time (!) as you can use you own functions for common widgets creation/location patterns. So if your library isn't that silly one where you have to manually specify widget location/size in parent don't waste your time on GUI editor. -- Денис В. Шеломовский Denis V. Shelomovskij
Any plans to fix Issue 9044? aka Language stability question again
As those of you who do write some non-toy projects in D know, from time to time you projects become unbuildable because of Issue 9044 [1] an you have to juggle with files and randomly copy/move functions from one library to another to detrigger the issue creating mess marked Issue 9044 workaround. It become really annoying when your one-file project using an external library fails as it forcing you to juggle with that library files (e.g. VisualD's `cpp2d` project which triggers the issue randomly). I'd never complain about such things but the language is tend to be self-called stable by main maintainers and I'd like to finally see an official definition of this stability as it obviously contradicts my personal very loyal definition (e.g. I have noting against breaking changes if they are in good direction). [1] http://d.puremagic.com/issues/show_bug.cgi?id=9044 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: clear() causes crash?
30.04.2013 1:04, Luís Marques luismarq...@gmail.com пишет:
This crashes in the last line of main:
class A
{
void foo() {}
}
void main()
{
A a = new A();
a.foo();
clear(a);
assert(a !is null);
a.foo(); // crashes
}
As far as I understand from TDPL book, this should not crash, but it
does (DMD64 v2.062, OS X). Am I misunderstanding clear()?
BTW, why not make clear also change 'a' to null?
Ideally is should throw with pretty message but it isn't implemented.
See Issue 8139 - Make objects really disposable by addition of Object
finalized assertion [1].
IMO, also `destroy` (renamed `clear`) looks like the worst mistake in D
runtime and I'd recommend to not use it (or better recompile
druntime+phobos without it for your own use). See Issue 9139 - `destroy`
is dangerous and inconsistent [2]. Use
`unstd.lifetime.finalizeClassInstance` [3] and friends for user-defined
lifetime implementation to avoid serious problems.
[1] http://d.puremagic.com/issues/show_bug.cgi?id=8139
[2] http://d.puremagic.com/issues/show_bug.cgi?id=9139
[3]
http://denis-sh.github.io/phobos-additions/unstd.lifetime.html#finalizeClassInstance
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: I wrote a JSON library
07.05.2013 11:29, w0rp пишет: I wasn't quite satisfied with std.json or the JSON libraries in frameworks. The standard library doesn't make it easy enough to create JSON objects, and my primary objection for the framework solutions is that they seem to depend on other parts of the frameworks. (I'd rather not depend on a host of libraries I won't be using just to use one I will.) So, desiring an easy-to-use and atomic library, I took to writing my own from scratch. https://github.com/w0rp/dson/blob/master/json.d I would love to hear some comments on my implementation. Criticism is mostly what I am after. It's hard for me to self-criticise. Perhaps the most obvious criticism to me is that I seem to write too damn many unit tests. Good luck as my personal attempt to improve std.json to at least this: https://github.com/D-Programming-Language/phobos/pull/1206#issuecomment-14826562 got stuck on even this simple pull: https://github.com/D-Programming-Language/phobos/pull/1263 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Could anybody remove SPAM from this thread?!
30.03.2013 13:56, Denis Shelomovskij пишет: For SPAM, see previous posts. Same request. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
24.04.2013 12:47, deadalnix пишет: On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij wrote: 19.04.2013 11:45, deadalnix пишет: On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote: Another try to describe the problem: When I get a delegate, I'd like to use it unless it become invalid. How does using an object solve that ? Unless this is a struct-member delegate (which is not often used anyway and can be marked as dangerous e.g.): --- T delegate(A) del = ...; rt_attachDisposeEvent(_d_toObject(del.ptr), onDelegateDisposed); --- I still see many possibilities without changing the language. For instance, allowing to attach dispose event to something else than an object. Thus making that something else almost class but not class and I don't see why not just use class instead of creating a new entity. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
19.04.2013 11:45, deadalnix пишет: On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote: Another try to describe the problem: When I get a delegate, I'd like to use it unless it become invalid. How does using an object solve that ? Unless this is a struct-member delegate (which is not often used anyway and can be marked as dangerous e.g.): --- T delegate(A) del = ...; rt_attachDisposeEvent(_d_toObject(del.ptr), onDelegateDisposed); --- -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
18.04.2013 18:21, deadalnix пишет: On Thursday, 18 April 2013 at 13:25:32 UTC, Denis Shelomovskij wrote: - What is the fundamental problem. When a delegate is created information about it's outer scope is lost instead of being stored in it's ptr. That doesn't mean anything. No information is stored into a ptr except an address in memory. A joke? Of course I mean stored into a memory ptr point to. - Why this fundamental problem is a language issue and not a lib one. ... I don't care about the cost. You have made no point in 3 pages in favor of the change you propose. Not even an invalid point I can disagree on. As everything I have written above is known, I still don't understand why you are telling about signal fixing as a main problem as it is just an example of problems that occurs when we throw away outer scope information without any practical reason, IMO. It is an example of a library interface issue (very real). To propose a language change, you must show that this limitation is in fact a symptom of a deeper cause, which it at language level (so that must be fixed at language level). Another try to describe the problem: When I get a delegate, I'd like to use it unless it become invalid. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
17.04.2013 15:26, Timon Gehr пишет: On 04/17/2013 12:35 PM, Denis Shelomovskij wrote: ... It will make code in Issue 9603 work. You have to argue why this is the correct way to fix it. Why would lifetime control necessarily be linked to implicit object field overhead? 0. I do like this approach, it looks straight and consistent IMO. 1. I see no other ways to fix the issue. 2. I see no important overhead in my proposal as wasting a few bytes is nothing in contrast with GC allocation process/memory overhead. 3. I think added functionality is very usable and even already required. Everyone is free to propose a better approach. By the way, almost every technical idea we know is incorrect and will be likely superceeded in the future with a better one as history shows. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
17.04.2013 19:47, deadalnix пишет: On Wednesday, 17 April 2013 at 10:35:08 UTC, Denis Shelomovskij wrote: Can you explain what is the problem ? Code in Issue 9603 doesn't work. That is not explaining what is the problem. This should contains at least : - Why it doesn't work. No ability to tell when a delegate will be destroyed (currently it isn't even destroyed when it should, see Issue 9602). http://d.puremagic.com/issues/show_bug.cgi?id=9602 - What is the fundamental problem. When a delegate is created information about it's outer scope is lost instead of being stored in it's ptr. - Why this fundamental problem is a language issue and not a lib one. Looks self-evident. - How does you proposition solve it. It stores the information about delegate's outer scope wasting (oh God, how many, especially in contrast to GC allocation) a few bytes. Right now, the only element you have been able to provide are : - signal accept delegate from object. - So we must make all delegate object. This is a very poor argumentation as the only reasonable answer to 1 without more input is go fix signal or raise a bug about signal. As everything I have written above is known, I still don't understand why you are telling about signal fixing as a main problem as it is just an example of problems that occurs when we throw away outer scope information without any practical reason, IMO. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
16.04.2013 13:17, deadalnix пишет: On Tuesday, 16 April 2013 at 07:55:51 UTC, Denis Shelomovskij wrote: Sorry, I really don't understand what you don't understand. Let's consider example from Issue 9603 Comment 2 [1]. Do you think such code must not work? Also you can look through Issue 9601 discussion. [1] http://d.puremagic.com/issues/show_bug.cgi?id=9603#c2 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9601 The code in 9603 is completely broken. It should compile and run, but what it does is undefined as o is finalized when delegates have reference to it. I don't see how changing delegate into object would change anything, as the code would be broken in the same way for the same reason. Current behaviour when delegates stays alive when its outer scope is destroyed is just a bad language design. Let's assume there is a magic way to make code in Issue 9603 work. Do you think this is usable? So, the magic: I propose to make an object on closure creation (i.e. just prepend allocated closure with few hidden fields) and add finalize the closure to outer scope dispose event. And I already described it in Issue 9601 and its comments. What is non-obvious here? Note: This can work just the same way if there is no GC-allocated closure. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
17.04.2013 10:43, deadalnix пишет: On Wednesday, 17 April 2013 at 06:15:43 UTC, Denis Shelomovskij wrote: Current behaviour when delegates stays alive when its outer scope is destroyed is just a bad language design. No, destroying is unsafe by definition, and this is why GC solve a lot of problems. I mead destroying by GC. Can you explain what is the problem ? Code in Issue 9603 doesn't work. What does creating an object change except adding 2 pointers into the frame pointer ? It will make code in Issue 9603 work. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
16.04.2013 10:10, deadalnix пишет: On Tuesday, 16 April 2013 at 05:39:32 UTC, Denis Shelomovskij wrote: Do you mean that tracking an object with a delegate whenever it goes to just know where it's outer scope is destroyed is not a problem? Delegate context is allocated on the heap, unless compiler can prove it can do it on stack. context is destroyed when no live pointer point to it. You still didn't explain why an object is better than the actual delegate mecanism. Sorry, I really don't understand what you don't understand. Let's consider example from Issue 9603 Comment 2 [1]. Do you think such code must not work? Also you can look through Issue 9601 discussion. [1] http://d.puremagic.com/issues/show_bug.cgi?id=9603#c2 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9601 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
15.04.2013 7:46, deadalnix пишет: On Sunday, 14 April 2013 at 07:06:12 UTC, Denis Shelomovskij wrote: For working signals I suppose will be enough fixing of both Issue 9606 [1] and Issue 9603 [2]. IMO, for the first issue we need weak references [3]. IMO, for the second issue we need to make regular D objects on closures [4] and fix Issue 9602 [5]. Any thoughts about my proposal to make signals working in D? Other proposals? Any (approximate) period for [proposal parts] to be implemented? Also, does anybody think currently D has working signals and I'm just slander in the title? P.S. Also there is a proposal for new signals implementation without compiler changes [6]. [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603 [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151 [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601 [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602 [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347 Can you expand yourself on the subject ? I did followed discussion on the topic, and so this thread is quite hard to follow. My points was: 1. Implement a weak reference (and, better, a weak references array) as a general utility [3] and don't implement it in every case we need it (this will make `std.signals` fixing [1] trivial, one will just supersede incorrect internal weak ref implementation with standard one). 2. Make regular D objects on closures [4] to be able to know when delegate's outer scope is destroyed (this will auto-fix both [5] and [2], see Comment 2 of [2] for code example) I think both points are relatively easy to implement and will improve things a lot. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
14.04.2013 21:07, Robert пишет: Does it mean you disagree with proposed compiler changes and with the idea we have to create weak reference functionality instead of recreating it every time it is needed (beside of theoretical danger such approach already showed it as a bad thing with `std.stdio.File` as I wrote)? A weak reference could actually be implemented in the library relatively easy. ( I basically did it for std.signals2 ) But for std.signals a weak ref is not really enough, because ideally the slot gets removed if the target gets destroyed, not only set to null. Updating a collection on destruction of an object is not that easy as you pointed out (thank you for that), but I don't see how weak references would help there. Array of weak references is what is needed. But you just made me think: If it is ok that a signal does not release the memory for the slot immediately when the object gets destroyed but only on the next call to emit(), then the implementation would be much simpler ... Yes, this is how array of weak references will work because this is how weak references work. And this shows one mustn't implement general facilities in every case they are needed as he will do mistakes and will complicate thinks for himself. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
15.04.2013 13:07, Robert пишет:
2. Make regular D objects on closures [4] to be able to know when
delegate's outer scope is destroyed (this will auto-fix both [5] and
[2], see Comment 2 of [2] for code example)
I still don't understand what that buys us. Having a closure being an
object would make it possible to use a weak reference, but why would you
want that? The signal would be the only one to hold a reference to the
lamdas context, if this reference was a weak one, then the memory would
be claimed immediately. This is why std.signals2 holds a strong ref to
the delegate context of a wrapping closure and a weak ref to the target
object.
With your `std.signals2` one can't e.g. forward delegate connection like
this:
---
/// Usage: don't pass struct pointer delegates as `del`.
void f(void delegate() del)
{
obj.event.connect(del);
}
---
as you require explicit passing an object owning a delegate.
But it is completely unnecessary as delegate do know where it was born
from and the fact this information isn't tracked when a closure is
created is a language design issue. One of those fixing which is easy,
will not break any code and will improve things a lot.
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
15.04.2013 20:15, deadalnix пишет:
On Monday, 15 April 2013 at 12:07:19 UTC, Denis Shelomovskij wrote:
15.04.2013 13:07, Robert пишет:
2. Make regular D objects on closures [4] to be able to know when
delegate's outer scope is destroyed (this will auto-fix both [5] and
[2], see Comment 2 of [2] for code example)
I still don't understand what that buys us. Having a closure being an
object would make it possible to use a weak reference, but why would you
want that? The signal would be the only one to hold a reference to the
lamdas context, if this reference was a weak one, then the memory would
be claimed immediately. This is why std.signals2 holds a strong ref to
the delegate context of a wrapping closure and a weak ref to the target
object.
With your `std.signals2` one can't e.g. forward delegate connection
like this:
---
/// Usage: don't pass struct pointer delegates as `del`.
void f(void delegate() del)
{
obj.event.connect(del);
}
---
as you require explicit passing an object owning a delegate.
But it is completely unnecessary as delegate do know where it was born
from and the fact this information isn't tracked when a closure is
created is a language design issue. One of those fixing which is easy,
will not break any code and will improve things a lot.
Even with that explanation, I still don't see the problem.
Do you mean that tracking an object with a delegate whenever it goes to
just know where it's outer scope is destroyed is not a problem?
--
Денис В. Шеломовский
Denis V. Shelomovskij
Is there any plans to make working signals in D?
For working signals I suppose will be enough fixing of both Issue 9606 [1] and Issue 9603 [2]. IMO, for the first issue we need weak references [3]. IMO, for the second issue we need to make regular D objects on closures [4] and fix Issue 9602 [5]. Any thoughts about my proposal to make signals working in D? Other proposals? Any (approximate) period for [proposal parts] to be implemented? Also, does anybody think currently D has working signals and I'm just slander in the title? P.S. Also there is a proposal for new signals implementation without compiler changes [6]. [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603 [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151 [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601 [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602 [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
14.04.2013 15:22, Robert пишет: There is: http://wiki.dlang.org/Review_Queue It is currently blocked by: http://d.puremagic.com/issues/show_bug.cgi?id=8441 There is already a pull request for 8441, but it was not merged yet. As soon as 8441 gets fixed, I am going to finish up the implementation to make it ready for review. For an overview of fixes and improvements over the current implementation, simply search the forums for std.signals2. Does it mean you disagree with proposed compiler changes and with the idea we have to create weak reference functionality instead of recreating it every time it is needed (beside of theoretical danger such approach already showed it as a bad thing with `std.stdio.File` as I wrote)? -- Денис В. Шеломовский Denis V. Shelomovskij
Re: PHP extension in D
11.04.2013 15:28, gedaiu пишет: Hi, I want to extend Php with an extension written in D, and wrap some D classes in php. My questions are: 1. How I can build a static library(I am using eclipse with ddt) 2. How I can create methods and create objects in c++ from the D library. Post such questions to digitalmars.D.learn, please. -- Денис В. Шеломовский Denis V. Shelomovskij
