Re: Is the use of .di depreceated ?
On Tuesday, 24 April 2012 at 01:51:54 UTC, Adam Wilson wrote: On Wed, 18 Apr 2012 03:02:49 -0700, Robert Clipsham wrote: On 18/04/2012 09:18, "Erèbe" wrote: Hi, I recently discovered that D support file interface .di, but through my past reads I never seen someone using it. The std don't do usage of it (compile time issue maybe ?) and most of D project are in the same case. Is this feature depreceated ? I'm from a C++ background, I agree on the fact that keeping declarations and implementaions sync across two files is tedious, but when I have to read code, I like a clean interface to summarize the thing. Dmd doc is there to replace the need of an clean interface ? You can find a list of deprecated features here: http://dlang.org/deprecate .di files are not deprecated, just rarely used. This is for a few reasons: * There is no requirement to use them * They severely limit the capabilities of CTFE (http://dlang.org/function#interpretation) * DMD is really fast - the speed gain from using .di files isn't noticeable for a lot of projects * If you want them, they're very easy to generate yourself (use the -Dd and -Df compiler switches) * For the purposes of reading APIs, DDoc is normally used - alternatively, all good editors and IDEs provide code folding to hide implementations Where DI files come in handy is for commercial libraries that don't want to hand out their source, without DI's that's impossible, therefore for D to be a commercially acceptable language, DI's must work, unfortunately, DI's do not auto-generate to the this requirement right now, I have a patch to fix that. But if you are OSS, you don't really care, just deliver the source as the "library". D could see use an approach similar to what Delphi does, where the tooling is able to extract the information from the .tpu files (delphi libraries), as far as I can remember. Go has a similar approach where the package information is stored in a special section in the library/object files. But I guess di files are anyway easier to maintain.
Re: comma operator causes hard to spot bugs
On 04/24/2012 03:21 AM, Martin Nowak wrote:
if(r.front == 'a' && (r.popFront(), r.front) == 'b') { ... }
There are a few similar usages in Phobos. If comma was to be used as a
tuple constructor instead, those could be replaced by ( , )[$-1].
Tuples with void elements?
Yes. They behave similar to void.
And if the first exp had a value one wouldn't like to pay for the copying.
How would this require copying? D language tuples already work in a way
that would make (,)[$-1] completely equivalent to what (,) does now.
Re: [off-topic] Sony releases PS Vita SDK
On 04/22/2012 03:43 PM, Victor Vicente de Carvalho wrote: Another option that crossed my mind was to do something like a kickstarter funding to pay someone to do that fulltime. What you guys think? I think "FUCK YES". I would dump money on that. ;)
Re: Escaping control in formatting
2012年4月24日2:49 Denis Shelomovskij :
> 23.04.2012 21:15, kenji hara написал:
>>
>> 2012年4月24日1:14 Denis Shelomovskij:
>>>
>>> 23.04.2012 18:54, kenji hara написал:
>>>
>>>
Please give us use cases. I cannot imagine why you want to
change/remove quotations but keep escaped contents.
>>>
>>>
>>>
>>> Sorry, I should mention that !' and !" are optional and aren't commonly
>>> used, and all !?* are very optional and are here just for completeness
>>> (IMHO).
>>>
>>> An example is generating a complicated string for C/C++:
>>> ---
>>> myCppFile.writefln(`tmp = "%!?"s, and %!?"s, and even %!?"s";`,
>>> str1, str2, str3)
>>> ---
>>>
>>>
>>> --
>>> Денис В. Шеломовский
>>> Denis V. Shelomovskij
>>
>>
>> During my improvements of std.format module, I have decided a design.
>> If you format some values with a format specifier, you should unformat
>> the output with same format specifier.
>>
>> Example:
>> import std.format, std.array;
>>
>> auto aa = [1:"hello", 2:"world"];
>> auto writer = appender!string();
>> formattedWrite(writer, "%s", aa);
>>
>> aa = null;
>>
>> auto output = writer.data;
>> formattedRead(output, "%s",&aa); // same format specifier
>>
>> assert(aa == [1:"hello", 2:"world"]);
>>
>> More details:
>>
>> https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L3264
>>
>> I call this "reflective formatting", and it supports simple text based
>> serialization and de-serialization.
>> Automatic quotation/escaping for nested elements is necessary for the
>> feature.
>>
>> But your proposal will break this design very easy, and it is
>> impossible to unformat the outputs reflectively.
>>
>> For these reasons, your suggestion is hard to accept.
>>
>> Kenji Hara
>
>
> Is there sum misunderstanding?
>
> Reflective formatting is good! But it isn't what you always want. It is
> needed mostly for debug purposes. But debugging is one of two usings of
> formatting, the second one is just writing something somewhere.
>
> There are already some non-reflective constructs (like "%(%(%c%), %)" for a
> range and "X%sY%sZ" for strings) and I just propose adding more comfortable
> ones because every second time I use formatting I use it for writing (I mean
> not for debugging).
>
>
> --
> Денис В. Шеломовский
> Denis V. Shelomovskij
My concern is that the proposal is much complicated and less useful
for general use cases.
You can emulate such formatting like follows:
import std.array, std.format, std.stdio;
import std.range, std.uni;
void main()
{
auto strs = ["It's", "\"world\""];
{
// emulation of !?"
auto w = appender!string();
foreach (s; strs)
formatStrWithEscape(w, s, '"');
writeln(w.data);
}
{
// emulation of !?'
auto w = appender!string();
foreach (s; strs)
formatStrWithEscape(w, s, '\'');
writeln(w.data);
}
}
void formatStrWithEscape(W)(W writer, string str, char quote)
{
writer.put(quote);
foreach (dchar c; str)
formatChar(writer, c, quote);
writer.put(quote);
}
// copy from std.format
void formatChar(Writer)(Writer w, in dchar c, in char quote)
{
if (std.uni.isGraphical(c))
{
if (c == quote || c == '\\')
put(w, '\\'), put(w, c);
else
put(w, c);
}
else if (c <= 0xFF)
{
put(w, '\\');
switch (c)
{
case '\a': put(w, 'a'); break;
case '\b': put(w, 'b'); break;
case '\f': put(w, 'f'); break;
case '\n': put(w, 'n'); break;
case '\r': put(w, 'r'); break;
case '\t': put(w, 't'); break;
case '\v': put(w, 'v'); break;
default:
formattedWrite(w, "x%02X", cast(uint)c);
}
}
else if (c <= 0x)
formattedWrite(w, "\\u%04X", cast(uint)c);
else
formattedWrite(w, "\\U%08X", cast(uint)c);
}
I can agree changing private functions in std.format, e.g. formatChar,
to public undocumented, but cannot agree adding such complicated rule
into supported format specifier.
Kenji Hara
Re: Is the use of .di depreceated ?
On Tuesday, 24 April 2012 at 01:51:54 UTC, Adam Wilson wrote: Where DI files come in handy is for commercial libraries that don't want to hand out their source, without DI's that's impossible, therefore for D to be a commercially acceptable language, DI's must work, unfortunately, DI's do not auto-generate to the this requirement right now, I have a patch to fix that. But if you are OSS, you don't really care, just deliver the source as the "library". DI files are sufficiently auto generated now. Templated functions have to be part of the source code because, well, *they're templates* the compiler needs the source code. Otherwise .di files are just .d files with a different name, you can do forward declarations for defining the interface with a library, I've used it several times. There is a build tool that will generate the interface files and use those when actually compiling in order to speed up compilation times when doing incremental compilation (don't have to parse as much code). -- James Miller
Re: Notice/Warning on narrowStrings .length
On Tuesday, April 24, 2012 01:01:57 James Miller wrote: > I'm writing an introduction/tutorial to using strings in D, > paying particular attention to the complexities of UTF-8 and 16. > I realised that when you want the number of characters, you > normally actually want to use walkLength, not length. Is is > reasonable for the compiler to pick this up during semantic > analysis and point out this situation? > > It's just a thought because a lot of the time, using length will > get the right answer, but for the wrong reasons, resulting in > lurking bugs. You can always cast to immutable(ubyte)[] or > immutable(short)[] if you want to work with the actual bytes > anyway. At this point, I don't think that it makes any sense to give a warning for this. The compiler can't possibly know whether using length is a good idea or correct in any particular set of code. If we really want to do something to tackle the problem, then we should create a new string type which better solves the issues. There's a _lot_ more to be worried about due to the fact that strings are variable length encoded than just their length. There has been talk of creating a new string type, and there has been talk of creating the concept of a variable length encoded range which better handles all of this stuff, but no proposal thus far has gotten anywhere. As for walkLength being O(n) in many cases (as discussed elsewhere in this thread), I don't think that it's that big a deal. If you know what it's doing, you know that it's O(n), and it's simple enough to simply save the result if you need to call it multiple times. - Jonathan M Davis
Re: Is the use of .di depreceated ?
On Wed, 18 Apr 2012 03:02:49 -0700, Robert Clipsham wrote: On 18/04/2012 09:18, "Erèbe" wrote: Hi, I recently discovered that D support file interface .di, but through my past reads I never seen someone using it. The std don't do usage of it (compile time issue maybe ?) and most of D project are in the same case. Is this feature depreceated ? I'm from a C++ background, I agree on the fact that keeping declarations and implementaions sync across two files is tedious, but when I have to read code, I like a clean interface to summarize the thing. Dmd doc is there to replace the need of an clean interface ? You can find a list of deprecated features here: http://dlang.org/deprecate .di files are not deprecated, just rarely used. This is for a few reasons: * There is no requirement to use them * They severely limit the capabilities of CTFE (http://dlang.org/function#interpretation) * DMD is really fast - the speed gain from using .di files isn't noticeable for a lot of projects * If you want them, they're very easy to generate yourself (use the -Dd and -Df compiler switches) * For the purposes of reading APIs, DDoc is normally used - alternatively, all good editors and IDEs provide code folding to hide implementations Where DI files come in handy is for commercial libraries that don't want to hand out their source, without DI's that's impossible, therefore for D to be a commercially acceptable language, DI's must work, unfortunately, DI's do not auto-generate to the this requirement right now, I have a patch to fix that. But if you are OSS, you don't really care, just deliver the source as the "library". -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Notice/Warning on narrowStrings .length
James Miller: Another option would be to have some sort of general lint tool that picks up on these kinds of potential errors, though that is a lot bigger scope... Lot of people in D.learn don't even use "-wi -property" so go figure how many will use a lint :-) In first approximation you can rely only on what people see compiling with "dmd foo.d", that is the most basic compilation use only. More serious programmers thankfully activate warnings. Bye, bearophile
Re: Notice/Warning on narrowStrings .length
On Monday, 23 April 2012 at 23:52:41 UTC, bearophile wrote: James Miller: I realised that when you want the number of characters, you normally actually want to use walkLength, not length. As with strlen() in C, unfortunately the result of walkLength(somestring) is computed every time you call it... because it's doesn't get cached. A partial improvement for this situation is to assure walkLength(somestring) to be strongly pure, and to assure the D compiler is able to move this invariant pure computation out of loops. Is is reasonable for the compiler to pick this up during semantic analysis and point out this situation? This is not easy to do, because sometimes you want to know the number of code points, and sometimes of code units. I remember even a proposal to rename the "length" field to another name for narrow strings, to avoid such bugs. I was thinking about that. This is quite a vague suggestion, more just throwing the idea out there and seeing what people think. I am aware of the issue of walkLength being computed every time, rather than being a constant lookup. One option would be to make it only a warning in @safe code, so worst case scenario is that you mark the function as @trusted. I feel this fits in with the idea of @safe quite well, since you have to explicitly tell the compiler that you know what you're doing. Another option would be to have some sort of general lint tool that picks up on these kinds of potential errors, though that is a lot bigger scope... -- James Miller
About Blender bugs
Notes on bugs found by PVS-Studio in the Blender source code:
http://www.gamasutra.com/blogs/AndreyKarpov/20120423/169021/Analyzing_the_Blender_project_with_PVSStudio.php
#define DEFAULT_STREAM \
m[dC] = RAC(ccel,dC); \
\
if((!nbored & CFBnd)) { \
\
No one has implemented this yet :-(
http://d.puremagic.com/issues/show_bug.cgi?id=5409
---
void tcd_malloc_decode() {
...
x0 = j == 0 ? tilec->x0 :
int_min(x0, (unsigned int) tilec->x0);
y0 = j == 0 ? tilec->y0 :
int_min(y0, (unsigned int) tilec->x0);
x1 = j == 0 ? tilec->x1 :
int_max(x1, (unsigned int) tilec->x1);
y1 = j == 0 ? tilec->y1 :
int_max(y1, (unsigned int) tilec->y1);
...
}
This code was most likely created through the Copy-Paste
technology
and the programmer forgot to change the name of one variable
during
editing. This is the correct code:
y0 = j == 0 ? tilec->y0 :
int_min(y0, (unsigned int) tilec->y0);
To avoid such mistakes maybe the IDE has to offer a way to create
such nearly-repeated lines of code, maybe writing a pattern like
this:
$ = j == 0 ? tilec->$ :
int_min($, (unsigned int) tilec->$);
And then giving a list like [x0, y0, x1, y1] to fill it four
times.
Dynamic languages are maybe able to do the same.
Or in D with something like:
foreach (s; TypeTuple!("x0", "y0", "x1", "y1")) {
mixin(" $ = j == 0 ? tilec->$ :
int_min($, (unsigned int) tilec->$);".replace("$",
s));
But it's not very readable, and replace() doesn't care if $ is
present inside strings, where it must not be replaced.
---
#define cpack(x) \
glColor3ub( ((x)&0xFF), (((x)>>8)&0xFF), (((x)>>16)&0xFF) )
static void star_stuff_init_func(void)
{
cpack(-1);
glPointSize(1.0);
glBegin(GL_POINTS);
}
PVS-Studio's warning: V610 Unspecified behavior.
Check the shift operator '>>. The left operand '(- 1)' is
negative. bf_editor_space_view3d view3d_draw.c 101
According to the C++ language standard, right shift of
a negative value leads to unspecified behavior. In practice
this method is often used but you shouldn't do that: it
cannot be guaranteed that the code will always work as
intended.
I suggest rewriting this code in the following way:
cpack(UINT_MAX);
Assigning -1 to an unsigned integer is a garbage way to code,
expecially in D where uint.max/typeof(T).max are available with
no need for imports.
---
This kind of error is common:
static bool pi_next_rpcl(opj_pi_iterator_t * pi) {
...
if ((res->pw==0)||(res->pw==0)) continue;
...
}
PVS-Studio's warning: V501 There are identical
sub-expressions to the left and to the right of
the '||' operator: (res->pw == 0) || (res->pw == 0)
extern_openjpeg pi.c 219
{
...
if ((size_t(lhs0+alignedStart)%sizeof(LhsPacket))==0)
for (Index i = alignedStart;i(&lhs0[i]),
ptmp0, pload(&res[i])));
else
for (Index i = alignedStart;i(&lhs0[i]),
ptmp0, pload(&res[i])));
...
}
PVS-Studio's warning: V523 The 'then' statement
is equivalent to the 'else' statement.
---
I have also seen code that is essentially:
size_t x = ...;
if (x < 0) { ... }
It was not a way to disable code. And in D you have /+...+/ and
version(none){...}.
Bye,
bearophile
Re: comma operator causes hard to spot bugs
if(r.front == 'a' && (r.popFront(), r.front) == 'b') { ... }
There are a few similar usages in Phobos. If comma was to be used as a
tuple constructor instead, those could be replaced by ( , )[$-1].
Tuples with void elements?
And if the first exp had a value one
wouldn't like to pay for the copying.
Re: Notice/Warning on narrowStrings .length
James Miller: I realised that when you want the number of characters, you normally actually want to use walkLength, not length. As with strlen() in C, unfortunately the result of walkLength(somestring) is computed every time you call it... because it's doesn't get cached. A partial improvement for this situation is to assure walkLength(somestring) to be strongly pure, and to assure the D compiler is able to move this invariant pure computation out of loops. Is is reasonable for the compiler to pick this up during semantic analysis and point out this situation? This is not easy to do, because sometimes you want to know the number of code points, and sometimes of code units. I remember even a proposal to rename the "length" field to another name for narrow strings, to avoid such bugs. --- Adam D. Ruppe: Maybe... but it is important that this works: string s; if(s.length) do_something(s); since that's always right and quite common. Better: if (!s.empty) do_something(s); (or even better, built-in non-ulls, usable for strings too). Bye, bearophile
Re: Notice/Warning on narrowStrings .length
On Monday, 23 April 2012 at 23:01:59 UTC, James Miller wrote: Is is reasonable for the compiler to pick this up during semantic analysis and point out this situation? Maybe... but it is important that this works: string s; if(s.length) do_something(s); since that's always right and quite common.
Notice/Warning on narrowStrings .length
I'm writing an introduction/tutorial to using strings in D, paying particular attention to the complexities of UTF-8 and 16. I realised that when you want the number of characters, you normally actually want to use walkLength, not length. Is is reasonable for the compiler to pick this up during semantic analysis and point out this situation? It's just a thought because a lot of the time, using length will get the right answer, but for the wrong reasons, resulting in lurking bugs. You can always cast to immutable(ubyte)[] or immutable(short)[] if you want to work with the actual bytes anyway.
Re: Voldemort command structures
On 4/22/12 11:42 AM, Brad Anderson wrote: That's really neat. We need to start making a catalog of interesting stuff you can do in D. We need descriptions in article or blog entry form, and then we collect (links to) them on the website. Andrei
Re: GTK and D
BTW, More info for d-apt server at: https://code.google.com/p/d-apt/wiki/APT_Repository#APT_Repository_for_D
Re: GTK and D
On Sunday, 22 April 2012 at 18:32:09 UTC, Russel Winder wrote: Mike, On Sun, 2012-04-22 at 20:07 +0200, Mike Wey wrote: [...] Odd trying to download http://d-apt.googlecode.com/files/./Packages with a browser or wget completes without any errors. http://d-apt.googlecode.com/files/./Packages in unix-like system is same than: http://d-apt.googlecode.com/files/Packages Hummm... here too. Perhaps browser and wget look for Packages and then Packages.txt whereas aptitude/apt-get do not? I note that the Debian repositories have Package.gz not Package.txt, might this be indicative that plain text should be Packages? This is certainly the filename I use on my personal deb repository. On d-apt server there are 4 control files: Packages (text plain file containing data about all deb packages) Packages.gz (Packages file compressed) Release (contains several checksums of Packages and Packages.gz files) Release.gpg (Release signed with d-apt key. verifiable with public key on d-apt-keyring) In an standard apt server there are more control files, but these four are the basic to make the d-apt server to work. Best regards,
Re: GSoC 2012 Proposal: Continued Work on a D Linear Algebra library (SciD - std.linalg)
Unfortunately, my proposal was not picked up this year. I might try to work
on these ideas this summer anyway so I would still be very much interested
in ideas and feedback, but I will probably have much less time if I'll be
working somewhere else.
---
Cristi Cobzarenco
BSc in Artificial Intelligence and Computer Science
University of Edinburgh
Profile: http://www.google.com/profiles/cristi.cobzarenco
On 10 April 2012 12:31, Cristi Cobzarenco wrote:
> Timon is, of course, right. I got a bit confused when trying to simplify
> in a hurry. What I meant was actually something like this:
>
> ops.d:
> import std.stdio;
>
> int sum( T )( T mat ){
> writeln("ops.sum");
> // return reduce!"a+b"( 0, mat );
> return 1;
> }
>
> int numelems( T )( T mat ) {
> // return mat.rows * mat.columns;
> return 1;
> }
>
> int mean( T )( T mat ) {
> return sum( mat ) / numelems( mat );
> }
>
> diagonal.d:
> import ops;
> import std.stdio;
>
> struct DiagonalMatrix {
> }
>
> int sum( T : DiagonalMatrix )( T mat ) {
> writeln( "diagonal.sum" );
> // return reduce!"a+b"( 0, mat.diagonal() );
> return 1;
> }
>
> main.d:
> import ops;
> import diagonal;
>
> void main() {
> DiagonalMatrix mat;
> sum( mat ); // this will not compile, but if removed mean
> mean( mat ); // will use ops.sum, not diagonal.sum anyway
> }
>
> The first problem could, in theory, be fixed using a member flag,
> something like enum specializedSum = true; and ops.sum could be redefined
> as: int sum( T )( T mat ) if( !T.specializedSum ) {}. But in this case
> mean() would still try to use ops.sum which will fail. All of this can be
> easily fixed by providing member functions, and having the free functions
> call the member ones when they exist.
>
> ---
> Cristi Cobzarenco
> BSc in Artificial Intelligence and Computer Science
> University of Edinburgh
> Profile: http://www.google.com/profiles/cristi.cobzarenco
>
>
>
> On 10 April 2012 10:35, Timon Gehr wrote:
>
>> On 04/10/2012 03:24 AM, Cristi Cobzarenco wrote:
>>
>>> Thanks for the suggestions!
>>>
>>> I don't think UFCS would help us. Our problem is that we can't do this:
>>> triangular.d:
>>> struct TriangularMatrix {
>>>
>>> }
>>>
>>> void sum( T )( T x ) if( is( T : TriangularMatrix ) ) {
>>>
>>> }
>>>
>>> diagonal.d:
>>> struct DiagonalMatrix {
>>>
>>> }
>>>
>>> void sum( T )( T x ) if( is( T : DiagonalMatrix ) ) {
>>> }
>>>
>>> main.d:
>>> import diagonal;
>>> import triangular;
>>>
>>> void bar() {
>>>TriangularMatrix a;
>>>Diagonal b;
>>>sum( a ); // this does not compile because sum() is ambiguous
>>>sum( b ); // nor does this
>>> }
>>>
>>
>> There are no ambiguities in that example, and if ambiguities occur, they
>> can always be fixed manually.
>>
>>
>>> This, AFAIK, is deliberate to avoid name hijacking - ADL in C++ had its
>>> share of criticism. I doubt we will ever get this behaviour in D and
>>> that is perhaps a good thing. I may have misunderstood UFCS though - or
>>> what you meant by making non-member function calls look nicer - please
>>> correct me if that's the case.
>>>
>>> Don't worry about long names, t() is already the way transposition is
>>> defined SciD. Moreover, it's a property so you can actually do "a.t * a"
>>> - convenience galore. I'm also considering of creating a submodule like
>>> std.linalg.short which defines aliases with short names for types and
>>> free functions - this will allow particularly numerics-heavy functions
>>> to be written more compactly. I'm not entirely sure it would be a good
>>> idea though as it may sacrifice readability where it's most needed.
>>>
>>> ---
>>> Cristi Cobzarenco
>>> BSc in Artificial Intelligence and Computer Science
>>> University of Edinburgh
>>> Profile:
>>> http://www.google.com/**profiles/cristi.cobzarenco
>>>
>>>
>> If you change 'Diagonal' to 'DiagonalMatrix', this compiles fine.
>>
>>
>
Re: Escaping control in formatting
23.04.2012 21:49, Denis Shelomovskij написал: 23.04.2012 21:15, kenji hara написал: 2012年4月24日1:14 Denis Shelomovskij: 23.04.2012 18:54, kenji hara написал: Please give us use cases. I cannot imagine why you want to change/remove quotations but keep escaped contents. Sorry, I should mention that !' and !" are optional and aren't commonly used, and all !?* are very optional and are here just for completeness (IMHO). An example is generating a complicated string for C/C++: --- myCppFile.writefln(`tmp = "%!?"s, and %!?"s, and even %!?"s";`, str1, str2, str3) --- -- Денис В. Шеломовский Denis V. Shelomovskij During my improvements of std.format module, I have decided a design. If you format some values with a format specifier, you should unformat the output with same format specifier. Example: import std.format, std.array; auto aa = [1:"hello", 2:"world"]; auto writer = appender!string(); formattedWrite(writer, "%s", aa); aa = null; auto output = writer.data; formattedRead(output, "%s",&aa); // same format specifier assert(aa == [1:"hello", 2:"world"]); More details: https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L3264 I call this "reflective formatting", and it supports simple text based serialization and de-serialization. Automatic quotation/escaping for nested elements is necessary for the feature. But your proposal will break this design very easy, and it is impossible to unformat the outputs reflectively. For these reasons, your suggestion is hard to accept. Kenji Hara Is there sum misunderstanding? Reflective formatting is good! But it isn't what you always want. It is needed mostly for debug purposes. But debugging is one of two usings of formatting, the second one is just writing something somewhere. There are already some non-reflective constructs (like "%(%(%c%), %)" for a range and "X%sY%sZ" for strings) and I just propose adding more comfortable ones because every second time I use formatting I use it for writing (I mean not for debugging). Completely forgot. %!+s in my proposal is exactly for reflective formatting (e.g. "X%!+sY%!+sZ" in reflective for strings). -- Денис В. Шеломовский Denis V. Shelomovskij
Re: GTK and D
On Sunday, 22 April 2012 at 02:51:29 UTC, Russel Winder wrote:
Being a Debian user I was interested in
https://code.google.com/p/d-apt/
but it seems the instructions for using this break since
http://d-apt.googlecode.com/files results in a 404.
This is a correct behaviour. If you want to list all files in
d-apt use this link:
https://code.google.com/p/d-apt/downloads/list
Otherwise, if you want to include d-apt as an apt server, just
add the line (without additional dots):
deb http://d-apt.googlecode.com/files /
at the file:
/etc/apt/sources.list
Also I am assuming it is an oversight that Tango-D2 is
packaged but Phobos is not?
This is not correct. As phobos is the standard d library, it's
included into the dmd package, so there are both phobos and tango
libraries available on d-apt server.
If you install tango package, you'll able to compile this code:
file: test.d
---
import tango.io.Stdout;
import std.stdio;
void main()
{
Stdout("hello with tango!").newline;
writeln("hello with phobos!");
}
---
$ dmd `pkg-config --cflags --libs tango` -run test.d
About packages on d-apt. I understand that dmd package can be
split into two or more packages (compiler, druntime, phobos
library with headers, help, etc.).
This is the initial apt version, and there is a long way to walk.
Best regards,
Re: Recursive aliases?
On 04/23/2012 01:44 PM, Steven Schveighoffer wrote: On Sat, 21 Apr 2012 15:46:29 -0400, Mehrdad wrote: alias int delegate(out ItemGetter next) ItemGetter; We currently can't do the above^ in D, but what do people think about allowing it? i.e. More specifically, I think an alias expression should be able to refer to the identifier (unless it doesn't make sense, like including a struct inside itself). (It would require a look-ahead.) It doesn't work. If I do this: alias int delegate() dtype; alias int delegate(dtype d) ddtype; pragma(msg, ddtype.stringof); I get: int delegate(int delegate() d) Note how it's not: int delegate(dtype d) Why? Because alias does not create a new type. It's a new symbol that *links* to the defined type. How shall the compiler expand your example so it can know the type? Basically the same way it detects recursive aliases. It is not really an implementation problem, but it would add a special case (don't expand recursive aliases). In general, it would get a little bit challenging to resolve recursive types in a reliable way: typeof(dg) delegate(typeof(dg(dg)(dg)), typeof(dg(dg)) = typeof(dg(dg(dg))).init) dg; // type safe! Implementing those infinite types would be a fun exercise though :o) It works for classes because classes are a new type which do not need to have another type backing it. The solution? Well, there are two possible ones. One is you create a ficticious type (or use void *) and cast when inside the delegate. The other is to not use delegates, but use types instead. Either a struct or a class/interface will do, something for the compiler to anchor on. -Steve Sure, but it shouldn't be necessary. There is no reason why it could not work except for the added complexity.
Re: Alias Expressions
On 04/23/2012 05:17 AM, Xinok wrote: I know this has probably been asked for a hundred times before, but I don't understand why D doesn't support this. Template alias parameters can accept nearly anything as an argument that standard aliases don't. I think standard aliases should be equally as powerful as their template counterpart. Note that standard aliases and template aliases have an overlapping set of features but both support some aliasees that the other one does not. (So no one is strictly more powerful than the other.) I really think this should be fixed, but Walter has never discussed the point when this issue was brought up in the past.
Re: Escaping control in formatting
23.04.2012 21:15, kenji hara написал: 2012年4月24日1:14 Denis Shelomovskij: 23.04.2012 18:54, kenji hara написал: Please give us use cases. I cannot imagine why you want to change/remove quotations but keep escaped contents. Sorry, I should mention that !' and !" are optional and aren't commonly used, and all !?* are very optional and are here just for completeness (IMHO). An example is generating a complicated string for C/C++: --- myCppFile.writefln(`tmp = "%!?"s, and %!?"s, and even %!?"s";`, str1, str2, str3) --- -- Денис В. Шеломовский Denis V. Shelomovskij During my improvements of std.format module, I have decided a design. If you format some values with a format specifier, you should unformat the output with same format specifier. Example: import std.format, std.array; auto aa = [1:"hello", 2:"world"]; auto writer = appender!string(); formattedWrite(writer, "%s", aa); aa = null; auto output = writer.data; formattedRead(output, "%s",&aa); // same format specifier assert(aa == [1:"hello", 2:"world"]); More details: https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L3264 I call this "reflective formatting", and it supports simple text based serialization and de-serialization. Automatic quotation/escaping for nested elements is necessary for the feature. But your proposal will break this design very easy, and it is impossible to unformat the outputs reflectively. For these reasons, your suggestion is hard to accept. Kenji Hara Is there sum misunderstanding? Reflective formatting is good! But it isn't what you always want. It is needed mostly for debug purposes. But debugging is one of two usings of formatting, the second one is just writing something somewhere. There are already some non-reflective constructs (like "%(%(%c%), %)" for a range and "X%sY%sZ" for strings) and I just propose adding more comfortable ones because every second time I use formatting I use it for writing (I mean not for debugging). -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Alias Expressions
A couple of examples of earlier discussions: http://www.digitalmars.com/d/archives/digitalmars/D/Non-enum_manifest_constants_Pie_in_the_sky_102248.html http://www.digitalmars.com/d/archives/digitalmars/D/Manifest_constants_why_enum_instead_of_invariant_70595.html
Re: Escaping control in formatting
2012年4月24日1:14 Denis Shelomovskij : > 23.04.2012 18:54, kenji hara написал: > >> Please give us use cases. I cannot imagine why you want to >> change/remove quotations but keep escaped contents. > > > Sorry, I should mention that !' and !" are optional and aren't commonly > used, and all !?* are very optional and are here just for completeness > (IMHO). > > An example is generating a complicated string for C/C++: > --- > myCppFile.writefln(`tmp = "%!?"s, and %!?"s, and even %!?"s";`, > str1, str2, str3) > --- > > > -- > Денис В. Шеломовский > Denis V. Shelomovskij During my improvements of std.format module, I have decided a design. If you format some values with a format specifier, you should unformat the output with same format specifier. Example: import std.format, std.array; auto aa = [1:"hello", 2:"world"]; auto writer = appender!string(); formattedWrite(writer, "%s", aa); aa = null; auto output = writer.data; formattedRead(output, "%s", &aa); // same format specifier assert(aa == [1:"hello", 2:"world"]); More details: https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L3264 I call this "reflective formatting", and it supports simple text based serialization and de-serialization. Automatic quotation/escaping for nested elements is necessary for the feature. But your proposal will break this design very easy, and it is impossible to unformat the outputs reflectively. For these reasons, your suggestion is hard to accept. Kenji Hara
Re: Alias Expressions
On Monday, 23 April 2012 at 14:53:38 UTC, Eldar Insafutdinov wrote: Which brings us to an interesting point that alias and enum should be brought together: alias x = 1; alias y = int; should replace current enum x = 1; alias int y; respectively. This is makes it a consistent syntax and behavior for alias declarations(no reverse order compared to normal assignments which is a legacy of C's typedef) and also fixes enum storage class which name is not relevant anymore. +1, but I know this has been brought up before. And there's zero chance it will happen if it doesn't also allow earlier (C/C++/D) usage. IMHO, using "enum" as a keyword for declaring constants is confusing and is a wart on an otherwise elegant* language. I know that the reason it is used is because under the covers constant declarations and enums are the same thing. But this is a classic case of leaving the human interface up to the engineers. Not everyone (and, in this case, hardly anyone) has the background to see that. *Elegance is, of course, highly subjective. And I know that there are other cases of problematic syntax. It just seems to me that replacing "enum" is almost painless. (Not replacing, exactly -- "enum" should still work. But there should be an alternative keyword. Way back when this was first brought up there were several keywords proposed but none were entirely satisfactory, so we kind of settled for "enum".) It makes me want to use: alias enum constant; Paul
Re: Escaping control in formatting
23.04.2012 18:54, kenji hara написал: Please give us use cases. I cannot imagine why you want to change/remove quotations but keep escaped contents. Sorry, I should mention that !' and !" are optional and aren't commonly used, and all !?* are very optional and are here just for completeness (IMHO). An example is generating a complicated string for C/C++: --- myCppFile.writefln(`tmp = "%!?"s, and %!?"s, and even %!?"s";`, str1, str2, str3) --- -- Денис В. Шеломовский Denis V. Shelomovskij
Re: GC + malloc/free = deadlock
On Apr 23, 2012, at 5:11 AM, Benjamin Thaut wrote: > Am 23.04.2012 13:57, schrieb Steven Schveighoffer: >> On Mon, 23 Apr 2012 02:41:21 -0400, Benjamin Thaut >> wrote: >> >>> I wrote a small "bad example" program for a presentation. It calls >>> malloc/free very frequently and I wanted to profile the impact of this >>> compared to a pool allocator solution. Unfortunately I had to notice >>> that the program only runs for a fraction of a second before >>> deadlocking. As it seems the following situation accurs: >>> >>> 1) Thread 1 calls malloc(), and locks the internal malloc mutex >>> 2) Thread 2 triggers garbage collection and stops thread 1 >>> 3) Thread 2 is done collecting garbage and calls all destructors. One >>> of these calls free(), as the malloc mutex is still locked by Thread 1 >>> and Thread 1 will never release the mutex, as it is stoped, Thread 2 >>> deadlocks. >> >> This shouldn't happen. The collection routine is specifically designed >> to avoid this. I remember when Sean put it into Tango after an IRC >> conversation. >> >> The correct sequence is: >> >> 1. stop the world >> 2. Perform mark on all data (identifying which blocks should be freed) >> 3. resume the world >> 4. Call dtors on unreferenced data and deallocate. >> >> This was to fix the exact problem you are having, albeit the malloc/free >> were indirect by calls to C-libs. >> >> Please file a bug. >> >> -Steve > > If what you are saying is true, the deadlock must happen somewhere else. This > was kind of a assumption because the deadlock happend after I added all the > malloc / free calls. Because all the threads are stopped when this happens I > can't really debug this, because the Visual Studio debugger tells me that it > can not debug any thread but the one that is currently running the GC. > > Kind Regards > Ingrater You should be able to get stack traces for all threads, even the suspended ones.
Re: Alias Expressions
On Monday, 23 April 2012 at 12:25:21 UTC, Peter Alexander wrote:
On Monday, 23 April 2012 at 03:17:49 UTC, Xinok wrote:
I know this has probably been asked for a hundred times
before, but I don't understand why D doesn't support this.
Template alias parameters can accept nearly anything as an
argument that standard aliases don't. I think standard aliases
should be equally as powerful as their template counterpart.
If you can write this:
template Eval(alias arg){ alias arg Eval; }
alias Eval!(cond ? a : b) al;
Why not simply allow this?
alias (cond ? a : b) al;
Or perhaps this:
alias al = cond ? a : b;
Do equivalent expressions instantiate the same template?
class Foo(alias E) {}
int x, y;
alias (x + y) A;
alias (x + y) B;
alias (y + x) C;
Are Foo!A and Foo!B the same type? What about Foo!C?
Either way, it will require name-mangling of arbitrary
expressions, which is just plain nasty.
I think you've misunderstood the poster as "cond ? a : b" must
fold and Eval(alias arg) receives a compile time value. That
makes it no different from doing just enum al = cond ? a: b;
Which brings us to an interesting point that alias and enum
should be brought together:
alias x = 1;
alias y = int;
should replace current
enum x = 1;
alias int y;
respectively. This is makes it a consistent syntax and behavior
for alias declarations(no reverse order compared to normal
assignments which is a legacy of C's typedef) and also fixes enum
storage class which name is not relevant anymore.
Re: Escaping control in formatting
2012年4月23日21:36 Denis Shelomovskij :
> I've never used new excellent range formatting syntax by Kenji Hara until
> now. And I've met with difficulties, because "%(%(%c%), %)" is the most
> common format for string array for me and it neither obvious nor elegant. It
> occurs that "%c" disables character escaping. What the hell? Why? Not
> obvious at all.
>
> So I think it will be good to add 'Escaping' part after 'Precision' in
> format specifications:
>
> Escaping:
> empty
> !-
> !+
> !'
> !"
> !?'
> !?"
> !?!
>
> Escaping affect formatting depending on the specifier as follows.
>
> EscapingSemantics
> !- disable escaping, for a range it also disables [,]
> !+ enable escaping using single quotes for chars and double quotes for
> strings
> !' enable escaping using single quotes
> !" enable escaping using double quotes
> !?' like !' but without adding the quotes and [,] for a range
> !?" like !" but without adding the quotes and [,] for a range
> !?! enable escaping, both single and double quotes will be escaped
> without adding any quotes and [,] for a range
>
> Escaping is enabled by default only for associative arrays, ranges (not
> strings), user-defined types, and all its sub-elements.
>
> I'd like to remove "%c"'s ability to magically disable escaping and it looks
> possible until it is documented.
>
> Look at the example:
> ---
> import std.stdio;
>
> void main() {
>writeln("char");
>char c = '\'';
>writefln("unescaped: %s." , c );
>writefln(`escaped+': %(%).`, [ c ]); // proposal: %!+s or %!'s
>writefln(`escaped+": %(%).`, [[c]]); // proposal: %!"s
>writeln (` escaped: \t.`); // proposal: %!?'s
>writeln();
>writeln("string");
>string s = "a\tb";
>writefln("unescaped: %s." , s );
>writefln(`escaped+": %(%).`, [s]); // proposal: %!+s or %!"s
>writeln (` escaped: a\tb.`); // proposal: %!?"s
>writeln();
>writeln("strings");
>string[] ss = ["a\tb", "cd"];
>writefln("unescaped: %(%(%c%)%).", ss); // proposal: %!-s
>writefln(`escaped+": %(%).` , ss);
>writeln (` escaped: a\tbcd.`, ss); // proposal: %!?"s
> }
> ---
>
> If it will be accepted, I can volunteer to try to implement it. If not,
> escaping should be at least documented (and do not forget about "%c"'s
> magic!).
>
> Any thoughts?
Please give us use cases.
I cannot imagine why you want to change/remove quotations but keep
escaped contents.
> P.S.
> If it has already been discussed, please give me a link.
As far as I know, there is not yet discussions.
Kenji Hara
Re: GC + malloc/free = deadlock
On Mon, 23 Apr 2012 15:44:01 +0200, Benjamin Thaut wrote: Am 23.04.2012 14:36, schrieb Kapps: On Monday, 23 April 2012 at 12:11:19 UTC, Benjamin Thaut wrote: If what you are saying is true, the deadlock must happen somewhere else. This was kind of a assumption because the deadlock happend after I added all the malloc / free calls. Because all the threads are stopped when this happens I can't really debug this, because the Visual Studio debugger tells me that it can not debug any thread but the one that is currently running the GC. Kind Regards Ingrater Are these threads created by core.thread.Thread, or are they created through different means such as native OS calls or a C api? If the latter, you have to register them with the runtime (I think it was something like Thread.attachThis), otherwise issues like this will happen. No all threads are created via core.thread.Thread. There are however some threads (OpenGL / OpenAL) that I do not create. I've had problems using attachThis() on threads created in C. Look at http://www.digitalmars.com/d/archives/digitalmars/D/learn/GC_collecting_too_much_.._33934.html No one has answered though..
Re: GC + malloc/free = deadlock
Am 23.04.2012 14:36, schrieb Kapps: On Monday, 23 April 2012 at 12:11:19 UTC, Benjamin Thaut wrote: If what you are saying is true, the deadlock must happen somewhere else. This was kind of a assumption because the deadlock happend after I added all the malloc / free calls. Because all the threads are stopped when this happens I can't really debug this, because the Visual Studio debugger tells me that it can not debug any thread but the one that is currently running the GC. Kind Regards Ingrater Are these threads created by core.thread.Thread, or are they created through different means such as native OS calls or a C api? If the latter, you have to register them with the runtime (I think it was something like Thread.attachThis), otherwise issues like this will happen. No all threads are created via core.thread.Thread. There are however some threads (OpenGL / OpenAL) that I do not create.
Re: comma operator causes hard to spot bugs
On 23-04-2012 11:38, CTFE-4-the-win wrote:
On Monday, 23 April 2012 at 08:08:52 UTC, Timon Gehr wrote:
On 04/23/2012 01:56 AM, deadalnix wrote:
Le 21/04/2012 18:54, bearophile a écrit :
Jonathan M Davis:
There have been discussions about the comma operator before. I don't
expect that it's going anywhere,
Maybe there are intermediate solutions between keeping wild commas in D
and disallowing them fully. I think most of my bugs caused by commas
are
similar to the one shown by the OP. This means this is not a common
source of bugs:
foo(), bar();
This is completely redundant with foo(); bar();
Not completely, you also need { }
if(qux()) foo(), bar();
I see no benefit from being able to do this.
I think the most common use-case for the , operator is in the "increment
part" of for loops... but this could of course be special-cased to still
be allowed...
Which is what the rest of the world's programming languages (other than
C and C++) do.
--
- Alex
Re: GC + malloc/free = deadlock
On Mon, 23 Apr 2012 08:36:59 -0400, Kapps wrote: On Monday, 23 April 2012 at 12:11:19 UTC, Benjamin Thaut wrote: If what you are saying is true, the deadlock must happen somewhere else. This was kind of a assumption because the deadlock happend after I added all the malloc / free calls. Because all the threads are stopped when this happens I can't really debug this, because the Visual Studio debugger tells me that it can not debug any thread but the one that is currently running the GC. Kind Regards Ingrater Are these threads created by core.thread.Thread, or are they created through different means such as native OS calls or a C api? If the latter, you have to register them with the runtime (I think it was something like Thread.attachThis), otherwise issues like this will happen. No. Dtor calls should all be done while all threads are running. The portion of the GC collection cycle which requires the world to be stopped should not be doing any locking/unlocking in arbitrary C libs. If it is, it's a bug. -Steve
Re: Escaping control in formatting
On 23.04.2012 16:36, Denis Shelomovskij wrote: I've never used new excellent range formatting syntax by Kenji Hara until now. And I've met with difficulties, because "%(%(%c%), %)" is the most common format for string array for me and it neither obvious nor elegant. It occurs that "%c" disables character escaping. What the hell? Why? Not obvious at all. Does %(%s, %) not work? [snip] -- Dmitry Olshansky
Re: Deterministic life-time storage type
Michel Fortin , dans le message (digitalmars.D:164837), a écrit : > newsgroup. There were two problems for adoption: it makes writing > functions difficult (because you have to add all that scoping thing to > your mental model) and implementing new type modifiers is a major > undertaking that didn't fit with the schedule. While the second problem > might disappear given enough time, the first one is a hurdle. If we choose the following defaults, the hurdle may not be that high: -1: function *parameters* and return value are scope by default (scope(in) and scope(out) in my terminology, although it is enough to say scope in that case), -2: *variable* are dynamic (= noscope = escape) when it is necessary, and scope when the compiler can find that they do not escape the scope. This way, programmers don't have to worry about variable's scope, since they are dynamic by default. But the performance cost may not be too high, because most of the times the variable will be treated like scope since the functions that use them will be scope by defaults. Lazy programmers only have to say when they let an argument escape the scope of a function. This is a good thing, because this scheme should be avoided, and in any case, this information should be documented. When a scope as to be shared between parameters/return value, stating "inout" would adequately solve 90% of the cases or more. For the less than 10% left, "dynamic" and/or deep copies allows to get rid of the problem, if the programmer is too lazy to use scope(label) or has no choice. Finally, programmers requiring efficiency can control the scope of a variable by declaring them explicitely scope. This way, the compiler will check they are not dynamic. This is obviously non-backward-compatible. However, most of the errors will occur in function's signature, where the compiler can be made to provide adequate error messages to correct the signature quickly. I reckon backward-compatibility issue and implementation time makes it very difficult to considers this before D 3.0, which is not tomorrow. I would really like this sort of system to be implemented in a medium-term, even if I think it's just dream. -- Christophe Travert, 4 years too late to discuss the issue.
Escaping control in formatting
I've never used new excellent range formatting syntax by Kenji Hara
until now. And I've met with difficulties, because "%(%(%c%), %)" is the
most common format for string array for me and it neither obvious nor
elegant. It occurs that "%c" disables character escaping. What the hell?
Why? Not obvious at all.
So I think it will be good to add 'Escaping' part after 'Precision' in
format specifications:
Escaping:
empty
!-
!+
!'
!"
!?'
!?"
!?!
Escaping affect formatting depending on the specifier as follows.
EscapingSemantics
!- disable escaping, for a range it also disables [,]
!+ enable escaping using single quotes for chars and double
quotes for strings
!' enable escaping using single quotes
!" enable escaping using double quotes
!?' like !' but without adding the quotes and [,] for a range
!?" like !" but without adding the quotes and [,] for a range
!?! enable escaping, both single and double quotes will be
escaped without adding any quotes and [,] for a range
Escaping is enabled by default only for associative arrays, ranges (not
strings), user-defined types, and all its sub-elements.
I'd like to remove "%c"'s ability to magically disable escaping and it
looks possible until it is documented.
Look at the example:
---
import std.stdio;
void main() {
writeln("char");
char c = '\'';
writefln("unescaped: %s." , c );
writefln(`escaped+': %(%).`, [ c ]); // proposal: %!+s or %!'s
writefln(`escaped+": %(%).`, [[c]]); // proposal: %!"s
writeln (` escaped: \t.`); // proposal: %!?'s
writeln();
writeln("string");
string s = "a\tb";
writefln("unescaped: %s." , s );
writefln(`escaped+": %(%).`, [s]); // proposal: %!+s or %!"s
writeln (` escaped: a\tb.`); // proposal: %!?"s
writeln();
writeln("strings");
string[] ss = ["a\tb", "cd"];
writefln("unescaped: %(%(%c%)%).", ss); // proposal: %!-s
writefln(`escaped+": %(%).` , ss);
writeln (` escaped: a\tbcd.`, ss); // proposal: %!?"s
}
---
If it will be accepted, I can volunteer to try to implement it. If not,
escaping should be at least documented (and do not forget about "%c"'s
magic!).
Any thoughts?
P.S.
If it has already been discussed, please give me a link.
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: GC + malloc/free = deadlock
On Monday, 23 April 2012 at 12:11:19 UTC, Benjamin Thaut wrote: If what you are saying is true, the deadlock must happen somewhere else. This was kind of a assumption because the deadlock happend after I added all the malloc / free calls. Because all the threads are stopped when this happens I can't really debug this, because the Visual Studio debugger tells me that it can not debug any thread but the one that is currently running the GC. Kind Regards Ingrater Are these threads created by core.thread.Thread, or are they created through different means such as native OS calls or a C api? If the latter, you have to register them with the runtime (I think it was something like Thread.attachThis), otherwise issues like this will happen.
Re: Alias Expressions
On Monday, 23 April 2012 at 03:17:49 UTC, Xinok wrote:
I know this has probably been asked for a hundred times before,
but I don't understand why D doesn't support this. Template
alias parameters can accept nearly anything as an argument that
standard aliases don't. I think standard aliases should be
equally as powerful as their template counterpart.
If you can write this:
template Eval(alias arg){ alias arg Eval; }
alias Eval!(cond ? a : b) al;
Why not simply allow this?
alias (cond ? a : b) al;
Or perhaps this:
alias al = cond ? a : b;
Do equivalent expressions instantiate the same template?
class Foo(alias E) {}
int x, y;
alias (x + y) A;
alias (x + y) B;
alias (y + x) C;
Are Foo!A and Foo!B the same type? What about Foo!C?
Either way, it will require name-mangling of arbitrary
expressions, which is just plain nasty.
Re: GC + malloc/free = deadlock
Am 23.04.2012 13:57, schrieb Steven Schveighoffer: On Mon, 23 Apr 2012 02:41:21 -0400, Benjamin Thaut wrote: I wrote a small "bad example" program for a presentation. It calls malloc/free very frequently and I wanted to profile the impact of this compared to a pool allocator solution. Unfortunately I had to notice that the program only runs for a fraction of a second before deadlocking. As it seems the following situation accurs: 1) Thread 1 calls malloc(), and locks the internal malloc mutex 2) Thread 2 triggers garbage collection and stops thread 1 3) Thread 2 is done collecting garbage and calls all destructors. One of these calls free(), as the malloc mutex is still locked by Thread 1 and Thread 1 will never release the mutex, as it is stoped, Thread 2 deadlocks. This shouldn't happen. The collection routine is specifically designed to avoid this. I remember when Sean put it into Tango after an IRC conversation. The correct sequence is: 1. stop the world 2. Perform mark on all data (identifying which blocks should be freed) 3. resume the world 4. Call dtors on unreferenced data and deallocate. This was to fix the exact problem you are having, albeit the malloc/free were indirect by calls to C-libs. Please file a bug. -Steve If what you are saying is true, the deadlock must happen somewhere else. This was kind of a assumption because the deadlock happend after I added all the malloc / free calls. Because all the threads are stopped when this happens I can't really debug this, because the Visual Studio debugger tells me that it can not debug any thread but the one that is currently running the GC. Kind Regards Ingrater
Re: GC + malloc/free = deadlock
On Mon, 23 Apr 2012 02:41:21 -0400, Benjamin Thaut wrote: I wrote a small "bad example" program for a presentation. It calls malloc/free very frequently and I wanted to profile the impact of this compared to a pool allocator solution. Unfortunately I had to notice that the program only runs for a fraction of a second before deadlocking. As it seems the following situation accurs: 1) Thread 1 calls malloc(), and locks the internal malloc mutex 2) Thread 2 triggers garbage collection and stops thread 1 3) Thread 2 is done collecting garbage and calls all destructors. One of these calls free(), as the malloc mutex is still locked by Thread 1 and Thread 1 will never release the mutex, as it is stoped, Thread 2 deadlocks. This shouldn't happen. The collection routine is specifically designed to avoid this. I remember when Sean put it into Tango after an IRC conversation. The correct sequence is: 1. stop the world 2. Perform mark on all data (identifying which blocks should be freed) 3. resume the world 4. Call dtors on unreferenced data and deallocate. This was to fix the exact problem you are having, albeit the malloc/free were indirect by calls to C-libs. Please file a bug. -Steve
Re: Recursive aliases?
On Sat, 21 Apr 2012 15:46:29 -0400, Mehrdad wrote: alias int delegate(out ItemGetter next) ItemGetter; We currently can't do the above^ in D, but what do people think about allowing it? i.e. More specifically, I think an alias expression should be able to refer to the identifier (unless it doesn't make sense, like including a struct inside itself). (It would require a look-ahead.) It doesn't work. If I do this: alias int delegate() dtype; alias int delegate(dtype d) ddtype; pragma(msg, ddtype.stringof); I get: int delegate(int delegate() d) Note how it's not: int delegate(dtype d) Why? Because alias does not create a new type. It's a new symbol that *links* to the defined type. How shall the compiler expand your example so it can know the type? It works for classes because classes are a new type which do not need to have another type backing it. The solution? Well, there are two possible ones. One is you create a ficticious type (or use void *) and cast when inside the delegate. The other is to not use delegates, but use types instead. Either a struct or a class/interface will do, something for the compiler to anchor on. -Steve
Re: GC + malloc/free = deadlock
Am 23.04.2012 08:52, schrieb David: Am 23.04.2012 08:41, schrieb Benjamin Thaut: I wrote a small "bad example" program for a presentation. It calls malloc/free very frequently and I wanted to profile the impact of this compared to a pool allocator solution. Unfortunately I had to notice that the program only runs for a fraction of a second before deadlocking. As it seems the following situation accurs: 1) Thread 1 calls malloc(), and locks the internal malloc mutex 2) Thread 2 triggers garbage collection and stops thread 1 3) Thread 2 is done collecting garbage and calls all destructors. One of these calls free(), as the malloc mutex is still locked by Thread 1 and Thread 1 will never release the mutex, as it is stoped, Thread 2 deadlocks. Now this is not limited to malloc / free, it can happen with any kind of locking that is done within a destructor. Currently I can only think of two ways to fix this: 1) Don't use free inside a destructor (goodbye manual memory management) 2) A callback triggered by the GC before it starts stopping any threads, and after it is done destructing all objects to manually lock / unlock necessary synchronization primitives to prevent this kind of deadlocking. The default implementation of this callback should lock / unlock the malloc mutex. That's nearly the same with OpenGL, never, really never put a glDelete*-Call in a Dtor, I had this for a few commits in glamour (a OpenGL wrapper) and it kept raining Segfaults. The bigger problem was, that was only caused by the GC, I didn't tell him to collect garbage from another Thread, it happend when it jumped in, and called dtors. The way I have fixed it was with "scope" and an additional .remove method. Maybe this is the way you can solve your problem. Well the issue with OpenGL is that you can only make OpenGL calls from the thread that actually owns the OpenGL context, so this is not quite the same. Because I'm perfectly allowed to call free from a different thread then where I called malloc. Also this is not only my problem, std.container.Array uses malloc & free so it can happen there too.
Re: comma operator causes hard to spot bugs
On Monday, 23 April 2012 at 08:08:52 UTC, Timon Gehr wrote:
On 04/23/2012 01:56 AM, deadalnix wrote:
Le 21/04/2012 18:54, bearophile a écrit :
Jonathan M Davis:
There have been discussions about the comma operator before.
I don't
expect that it's going anywhere,
Maybe there are intermediate solutions between keeping wild
commas in D
and disallowing them fully. I think most of my bugs caused by
commas are
similar to the one shown by the OP. This means this is not a
common
source of bugs:
foo(), bar();
This is completely redundant with foo(); bar();
Not completely, you also need { }
if(qux()) foo(), bar();
I see no benefit from being able to do this.
I think the most common use-case for the , operator is in the
"increment part" of for loops... but this could of course be
special-cased to still be allowed...
Re: comma operator causes hard to spot bugs
On 04/23/2012 01:56 AM, deadalnix wrote:
Le 21/04/2012 18:54, bearophile a écrit :
Jonathan M Davis:
There have been discussions about the comma operator before. I don't
expect that it's going anywhere,
Maybe there are intermediate solutions between keeping wild commas in D
and disallowing them fully. I think most of my bugs caused by commas are
similar to the one shown by the OP. This means this is not a common
source of bugs:
foo(), bar();
This is completely redundant with foo(); bar();
Not completely, you also need { }
if(qux()) foo(), bar();
I see no benefit from being able to do this.
