Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis
wrote:
Of course, ultimately, different programmers have different
preferences, and none of us are going to be happy about
everything in any language.
It's not only about preferences. The feature is inconsistent with
how 'invariant' and 'synchronized' are specified. They imply
class-instance-level private, while the language dictates
module-level. Consider:
```
synchronized class C
{
private int x;
private int y;
invariant () { assert (x == y); }
}
void foo(C c)
{
// mutate c
}
```
With module-level private, 'foo' is part of C's public interface,
but it neither locks on c, nor runs the invariant checks. I
personally have no idea how to fix that sensibly except by
ditching class invariant/synchronized entirely.
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 19:03:00 UTC, Walter Bright wrote: $0. true
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote:
https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/
'enum { Yes, No }; is just an automatic “no hire” decision'
'No hire' for language designers who design sum types to be
implicitly enumerated and convertible to integers and booleans?
Re: implicit-context v0.0.1
On Saturday, 30 September 2023 at 12:40:29 UTC, Guillaume Piolat wrote: When is it useful? You can use it to troll Jonathan Blow.
Re: Evolving the D Language
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:
I don't remember people from outside the community being
impressed by alias this.
We have the right to backtrack on bad ideas instead of keeping
them forever.
I don't know why anybody should be impressed, but Zig and Jai,
the two closest competitors of D, both have a generalized version
of 'alias this' ('usingnamespace' and 'using', respectively).
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Monday, 1 May 2023 at 14:03:51 UTC, bachmeier wrote: ``` value.type = STRING; ``` IRL people would use namespacing prefixes or actual namespaces anyway, so your example would look more like ``` value.type = VALUE_TYPE_STRING; ```
Re: Release D 2.102.0
On Thursday, 2 February 2023 at 22:46:51 UTC, Ali Çehreli wrote:
https://forum.dlang.org/thread/qwixdanceeupdefyq...@forum.dlang.org
I still agree with myself :) in that discussion here:
https://forum.dlang.org/post/tlqcjq$usk$1...@digitalmars.com
BTW, check out another case of D violating the "if in an invalid
state, die" precept. The following code not only runs the
upstream destructor (which depends on successful completion of
the downstream one), but does that in an infinite loop:
struct TransactionFactory
{
Transaction spawnTransaction()
{
return Transaction(0);
}
// depends on all Transactions having been destroyed
~this()
{
assert(Transaction.count == 0);
}
}
struct Transaction
{
static int count;
// the usual "fake nullary constructor" fiddlesticks
this() @disable;
this(int dummy)
{
count++;
}
~this()
{
assert(false); // a failure that leaves the system in an
invalid state
count--;
}
}
void main()
{
TransactionFactory tf;
Transaction t = tf.spawnTransaction;
}
Re: Binary Literals Not Going Anywhere
On Monday, 26 September 2022 at 04:40:02 UTC, Mike Parker wrote: You may have seen [the long discussion about the deprecation of binary literals(https://forum.dlang.org/thread/vphguaninxedxopjk...@forum.dlang.org). A few hours ago, Walter and I recorded a second conversation for our YouTube channel. Before we got started, I asked him about the binary literal situation. He confirmed that they will not be deprecated. If you're using them today, you can keep using them tomorrow. Please do not take the backlash against the removal of binary literals as general aversion to breaking changes/deprecations. D has plenty to remove/deprecate (and it is NOT `alias this`, unless that is replaced with a more general mechanism, such as `using` in Jai).
Re: Giving up
On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote: On 8/5/2022 9:43 AM, Max Samukha wrote: Both "123." and "123.E123" is valid C. For some reason, D only copied the former. It's to support UFCS (Universal Function Call Syntax). UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.) nd, the truth comes out. It is not representable, it is truncated to 0. Technically, ImportC should accept it. But if it does, doesn't it mislead users into thinking it is non-zero? We've got the right choice here, but it's definitely a judgement call. No objections to this.
Re: Giving up
On Friday, 5 August 2022 at 15:44:10 UTC, Steven Schveighoffer wrote: On 8/5/22 11:36 AM, Rumbu wrote: float z = 85886696878585969769557975866955695.E0; //integer overflow, I don't see any int That's an integer, which is trying to call a UFCS function named `E0`. Did you mean to include the `.`? -Steve Both "123." and "123.E123" is valid C. For some reason, D only copied the former.
Re: From the D Blog: Driving with D
On Tuesday, 8 June 2021 at 11:35:39 UTC, Iain Buclaw wrote: Testing backports of both now ([here](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935) and [here](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964)). Thanks!
Re: From the D Blog: Driving with D
On Monday, 7 June 2021 at 10:38:08 UTC, Max Samukha wrote:
Would be great if you did. Not a blocker, though.
However, this is a major pain:
```d
struct FP {
}
alias parse = () {
FP[] parts;
parts ~= FP();
return parts;
};
immutable s = parse();
extern(C) int main() {
return 0;
}
```
avr-gdc -fno-druntime ctfe.d
ctfe.d:3:1: error: 'object.TypeInfo' cannot be used with
'-fno-rtti'
3 | struct FP {
| ^
ctfe.d:3:1: error: 'object.TypeInfo' could not be found, but is
implicitly used
3 | struct FP {
| ^
d21: internal compiler error: Segmentation fault
0x178ae29 internal_error(char const*, ...)
Re: From the D Blog: Driving with D
On Sunday, 6 June 2021 at 22:39:34 UTC, Johan Engelen wrote: it's fun Hell Yeah! )
Re: From the D Blog: Driving with D
On Sunday, 6 June 2021 at 21:18:01 UTC, Iain Buclaw wrote: That sounds a lot like this issue: https://issues.dlang.org/show_bug.cgi?id=17857 Most certainly. Can backport that for GCC-11. Would be great if you did. Not a blocker, though.
Re: From the D Blog: Driving with D
On Sunday, 6 June 2021 at 18:57:06 UTC, Max Samukha wrote:
2) 'align' is mishandled
GCC's bugzilla won't let me register.
align(4)
struct S {
ubyte[4] bytes;
}
static assert (S.alignof == 4); // fail, S.alignof == 1
It's not specific to AVR. Worked around by placing 'align' inside
the struct.
Re: From the D Blog: Driving with D
On Friday, 4 June 2021 at 21:47:21 UTC, Iain Buclaw wrote: You should have better luck using gdc on avr. https://explore.dgnu.org/z/bos5ee Trying that, thank you. For now, two issues with GDC 11, which I hope to work around: 1) compiler complains about typeinfos of structs used in CTFE only, 2) 'align' is mishandled
Re: From the D Blog: Driving with D
On Friday, 4 June 2021 at 15:48:50 UTC, rikki cattermole wrote:
Does this form of foreach work?
foreach(i; 0 .. 10)
That does work.
This doesn't:
ubyte[] slice;
foreach (ubyte i; slice) {
}
Invalid bitcast
%17 = bitcast i16 %15 to i32
I guess the cause is the same - slice.length.sizeof == 4, while
slice.sizeof == 4, slice.ptr.sizeof == 2, and size_t.sizeof == 2.
Re: From the D Blog: Driving with D
On Tuesday, 1 June 2021 at 11:57:34 UTC, Mike Parker wrote: Dylan Graham writes about his experience using D in a microcontroller project and why he chose it. Does anyone know of any similar projects using D? I don't. This may well be the first time it's been employed in this specific manner. The blog: https://dlang.org/blog/2021/06/01/driving-with-d/ Reddit: https://www.reddit.com/r/programming/comments/nps6k5/driving_with_dlang/ FWIW, I tried D in a simple project using an atmega32a. It almost worked (thanks to Webfreak and LDC people), but there were a couple of issues: 1. No support for ISRs. I had to implement thunks in C calling D. 2. No slices, because 'length' is typed as 32-bit. Worked around by accessing the array's elements via .ptr. 3. No foreach (as a consequence of 2, I guess) 4. Integer promotion errors/warnings are very annoying when the primary integer type is byte. 5. A memory corruption bug (probably due to clobbered registers/corrupted stack/a stupid mistake of mine), which made me switch back to C++ for now.
Re: On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
On Thursday, 4 March 2021 at 13:54:48 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ "The destructors of all stack-allocated structs in a given scope are invoked when the scope exits." Please add a note that temporaries are scoped to the full expression, not the block.
Re: Interesting work on packing tuple layout
On Monday, 15 June 2020 at 14:55:37 UTC, Andrej Mitrovic wrote: On Monday, 15 June 2020 at 14:18:38 UTC, Timon Gehr wrote: Apparently, it has been fixed in 2.092. Nice! Oh wow that's fantastic. Does anyone know which changeset / PR fixed it? The person who fixed that must be commended.
Re: Interesting work on packing tuple layout
On Monday, 15 June 2020 at 13:57:01 UTC, Max Samukha wrote:
void main() {
Tuple!(byte, int, short) t;
writeln(t[0]);
}
test.d(57,23): Error: need `this` for `__value_field_2` of
type `byte`
It should work. This works:
void main() {
Tuple!(byte, int, short) t;
t[0] = 0;
t[1] = 2;
t[2] = 3;
auto a0 = t[0];
auto a1 = t[1];
}
}
I cannot reproduce the error. writeln(t[0]) works here:
https://run.dlang.io/is/kz6lFc
Re: Interesting work on packing tuple layout
On Monday, 15 June 2020 at 13:50:07 UTC, Andrej Mitrovic wrote:
typeof(t[0]) works fine, but reading or assigning to such a
field will not work. For example:
void main() {
Tuple!(byte, int, short) t;
writeln(t[0]);
}
test.d(57,23): Error: need `this` for `__value_field_2` of
type `byte`
It should work. This works:
void main() {
Tuple!(byte, int, short) t;
t[0] = 0;
t[1] = 2;
t[2] = 3;
auto a0 = t[0];
auto a1 = t[1];
}
}
Re: Interesting work on packing tuple layout
On Sunday, 14 June 2020 at 23:30:03 UTC, Andrei Alexandrescu
wrote:
It's really easy if members in the layout are given internal
names that include information about the original index.
You can construct a list of member aliases in the original order
and then 'alias this' that:
import std.meta;
struct Tuple(A...) {
alias Reordered = AliasSeq!(A[1], A[2], A[0]);
Reordered value;
alias reordered = AliasSeq!(typeof(this).tupleof);
alias original = AliasSeq!(reordered[2], reordered[0],
reordered[1]);
alias original this;
}
void main() {
Tuple!(byte, int, short) t;
static assert(is(typeof(t.tupleof) == AliasSeq!(int, short,
byte)));
static assert(is(typeof(t[0]) == byte));
static assert(is(typeof(t[1]) == int));
static assert(is(typeof(t[2]) == short));
}
Re: Facebook is using D in production starting today
On Friday, 11 October 2013 at 00:36:12 UTC, Andrei Alexandrescu wrote: Today I committed the first 5112 lines of D code to Facebook's repository. The project is in heavy daily use at Facebook. Compared to the original version (written in C++) we've measured massive wins in all of source code size, build speed, and running speed. In all likelihood we'll follow up with a blog post describing the process. Andrei Nice! No more Go (Rust, C#...) gets any attention only because it is backed by a big name.
Re: Facebook is using D in production starting today
On Friday, 11 October 2013 at 13:03:00 UTC, Nick Sabalausky wrote: That would rock my world. Facebook is written in PHP! seems to be the biggest, most common argument made in favor of PHP (despite only being a partial-truth). I'd love to see D kill that rediculous appeal-to-authority fallacy once and for all. ...and replace it with another appeal to authority? :)
Re: Facebook is using D in production starting today
On Friday, 11 October 2013 at 12:44:04 UTC, Adam D. Ruppe wrote: Worth remembering that being use on a small, easily replaceable, scale is a far cry from backing. They've just dipped their toes in the water. I think people started bashing Go for its association with Google long before it got to production.
Re: DConf 2013 Day 1 Talk 5: Using D Alongside a Game Engine by Manu Evans
On Thursday, 23 May 2013 at 20:19:28 UTC, Nick Sabalausky wrote:
On Thu, 23 May 2013 23:09:54 +1000
Manu turkey...@gmail.com wrote:
On 23 May 2013 22:56, Max Samukha maxsamu...@gmail.com wrote:
You have module constructors in mixins. How did you solve the
circular imports problem? Banned circular imports?
Pretty much.
I anticipate the problem arising, but it hasn't come up.
The codebase is fairly hierarchical it seems...
I'd really rather not do it with module constructors though.
There
might be other solutions, like module locals executing
constructors
or something.
I don't know whether there might be a problem with this
approach in
your particular situation, but I always try to avoid module
ctors by
using lazy-inited module-level properties:
// From:
Foo foo;
static this {
foo = ...etc...;
}
// To:
private Foo _foo;
private bool fooInited;
@property Foo foo() {
if(!fooInited) {
foo = ...etc...;
fooInited = true;
}
return _foo;
}
A little more boiler-platey, but that be cleaned up with
mixins. And
then if I need to force init to happen right at start-up, then
I can
just make sure to touch each of the properties at startup.
Problems start when the state needs to be thread-shared.
Re: DConf 2013 Day 1 Talk 5: Using D Alongside a Game Engine by Manu Evans
On Thursday, 23 May 2013 at 16:30:28 UTC, Manu wrote: Pretty much. I anticipate the problem arising, but it hasn't come up. The codebase is fairly hierarchical it seems... I'd really rather not do it with module constructors though. There might be other solutions, like module locals executing constructors or something. I see. Ok.
Re: DConf 2013 Day 1 Talk 5: Using D Alongside a Game Engine by Manu Evans
On Friday, 17 May 2013 at 13:28:20 UTC, Andrei Alexandrescu wrote: Great talk. Vote up! http://www.reddit.com/r/programming/comments/1eiku4/dconf_2013_day_1_talk_5_using_d_alongside_a_game/ Andrei Nice talk, Manu! You You have module constructors in mixins. How did you solve the circular imports problem? Banned circular imports?
Re: [OT] Three Optimization Tips for C++
On Thursday, 20 December 2012 at 05:29:46 UTC, Andrei Alexandrescu wrote: Vote up! http://www.reddit.com/r/programming/comments/155ivw/three_optimization_tips_for_c_video/ Andrei Nice talk. For anybody interested, PIC was made a bit faster by x64 due to introduction of RIP-relative addressing. Here is a concise and well-written article describing an x64 PIC implementation http://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64/.
Re: User Defined Attributes
On Thursday, 8 November 2012 at 09:08:23 UTC, Max Samukha wrote: alias getAttribute!(b, foo) t; Ignore that line.
Re: User Defined Attributes
On Thursday, 8 November 2012 at 12:42:38 UTC, Jacob Carlborg wrote: On 2012-11-08 10:08, Max Samukha wrote: Could you explain why it is impossible without complicating the current state of things? I gave it a quick try and it seems to work reasonably well (a proper implementation will be more involved due to compiler bugs and language issues irrelevant to this discussion): I just see no point in allowing random structs and classes acting like attributes. Suddenly someone starts to use your struct as an attribute without you having any intention of it acting like an attribute and you don't know about it. The problem is where to draw the line. There is nothing to stop an idiot programmer from applying your attributes to a wrong target, so we'd better take care of that by introducing those target-restricting attributes specially treated by the compiler. Instead of throwing attributes on attributes, I'd rather have decorators based on templates as someone proposed. Those would allow the programmer to implement arbitrary restrictions on their usage.
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 08:20:42 UTC, Walter Bright wrote: On 11/6/2012 12:15 AM, Tove wrote: [*drool*, totally perfect awesomeness] Thanks! The neato thing is I realized I could just connect the dots on what D already does well - CTFE, tuples, and templates. The actual features can now be added by library routines. Thank you. Now we can stop connecting the dots with hidden declaration hacks. Yay!
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote:
=
User Defined Attributes
---
Attributes on overloads are critical. Currently fails:
module test;
[1] void foo();
[2] void foo(int x);
template Tuple(A...)
{
alias A Tuple;
}
void main()
{
foreach (o; __traits(getOverloads, test, foo))
{
alias Tuple!(__traits(getAttributes, o)) attrs;
pragma(msg, attrs.stringof);
}
}
Compiler outputs:
()
()
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 17:17:50 UTC, Walter Bright wrote: On 11/6/2012 9:06 AM, deadalnix wrote: Le 06/11/2012 16:15, Walter Bright a écrit : On 11/6/2012 5:14 AM, Adam D. Ruppe wrote: Hmmm, it didn't work on the most important place for my use case, function parameters: It didn't occur to me to enable that. It should work everywhere or not work at all. You can't have @pure attributes on function parameters, either. Parameters don't work like regular declarations, never have, and I don't know of a language where they do. They even have a different grammar. C# allows custom attributes on function parameters, including the return value. Actually, it allows custom meta-data everywhere. See a use case here http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshalasattribute.aspx. I believe Java does the same.
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 19:12:54 UTC, Walter Bright wrote: As for the return value attributes, I think that can be handled by attributing the function symbol itself, as it can only have one return type. Theoretically there might be cases requiring an attribute of the same class both on the function and on the return value. Then differentiation of function and return value attributes would be necessary. Anybody has an example?
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 19:43:54 UTC, Jacob Carlborg wrote:
You need to specify the target tough, like declaration of an
annotation:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Test { }
Yep, C# attributes can be restricted to specific targets as well.
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 20:14:56 UTC, Walter Bright wrote:
On 11/6/2012 11:42 AM, Max Samukha wrote: Theoretically there
might be cases requiring an attribute of the same class both
on the function and on the return value. Then differentiation
of function and
return value attributes would be necessary. Anybody has an
example?
Not a problem, as you'd search the tuple for the attribute that
matters anyway.
By the same class I meant:
template SomeFunkyID(string id)
{
}
[SomeFunkyID!boo]
[return: SomeFunkyID!bar]
void foo();
In C#, I can distinguish, which of SomeFunkyID instances is
intended for the return value and which for the function itself.
How would I do that if both attributes were piled together in the
same tuple?
Re: dmd 1.070 and 2.055 release
On 09/08/2011 08:21 AM, Walter Bright wrote:
By far, the most number of bug fixes ever!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.070.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.055.zip
This test case
struct S
{
@disable this();
this(int x)
{
}
}
class C
{
S s;
this()
{
s = S(42);
}
}
void main()
{
auto c = new C;
}
yields Error: default construction is disabled for type C
Is it a bug?
Re: TDPL in Russian
On 11/10/2010 12:22 AM, Andrei Alexandrescu wrote: Just got word from my editor that TDPL has been approved for translation in Russian. Andrei Поздравляю! Надеюсь, что перевод будут делать долго, дорого и о..енно.
Re: TDPL in Russian
On 11/10/2010 08:25 PM, Dmitry Olshansky wrote: On 10.11.2010 1:22, Andrei Alexandrescu wrote: Just got word from my editor that TDPL has been approved for translation in Russian. Andrei Awesome! P.S. God, if you hear me, please, send us some _adequate_ Russian translators/reviewers. It seems I am not alone in my disliking of recent Russian translations. Nostalgic digression: when the USSR was keen on copying American microchip design, IT-related technical translations were much better.
Re: QtD is resumed
On 10/12/2010 09:49 PM, Andrei Alexandrescu wrote: On 10/12/10 13:20 CDT, Max Samukha wrote: As there is interest in the project, we have decided to proceed. Stay tuned. Awesome news! I think we need to take the hiccup as a warning to be more mindful of compilers and library bugs reported on behalf of QtD. Andrei Thanks! I find it reasonable to lower our expectations of the language/tools for a while. I've decided to go on without const and other goodies like the scarcely implemented alias this. For now, the most important for me are the issues with struct lifetime management. For example, destructors should be called on global struct instances. And this one is critical: http://d.puremagic.com/issues/show_bug.cgi?id=3516 It would be great if we soon had a complete and debugged implementation of the struct semantics described in TDPL.
QtD is resumed
As there is interest in the project, we have decided to proceed. Stay tuned.
Re: QtD is suspended
On 09/27/2010 09:15 AM, Emil Madsen wrote: Is there a partly complete release? - that just basic stuff available? Latest trunk: http://bitbucket.org/qtd/repo Wiki: http://www.dsource.org/projects/qtd I have a local branch that should fix a couple of major problems but it is not ready for a commit. Among other things, it supports generating struct wrappers for Qt value types, making it obvious that the lack of default struct constructors is a disaster.
Re: QtD is suspended
On 09/26/2010 05:36 PM, Emil Madsen wrote: Just curious about QtD, how far did the design process go in terms of % before it got suspended? 10% - 25% - 50%? - and what would the time approximations be to finish it? On 16 September 2010 16:22, Max Samukha spam...@d-coding.com mailto:spam...@d-coding.com wrote: After a good amount of hesitation, we have decided to put the QtD project on hold. QtD has a potential to become a complete and effective development platform for D but it is not going to happen soon (unless people with harder hearts take it over). We have spent half of the day hunting yet another dmd bug-o-feature and that is the last straw. We offer our apologies to people who put their hope upon the project. Please come back in a year or two when the language has a stable compiler with the features fully specified, implemented and debugged. -- // Yours sincerely // Emil 'Skeen' Madsen I guess it is about 67%. Basic stuff is in place, including cross-language virtual dispatch, partially meta-object system, signals/slots etc, but more advanced features like Q_PROPERTY are to be implemented. A couple of months (very roughly) before we have a stable and feature-compete version.
Re: QtD is suspended
On 09/17/2010 07:37 PM, Lutger wrote: Georg Wrede wrote: I take it this is directed at me. Look, it was a gut reaction. I don't understand why, but if anyone takes offense I'm sorry, I didn't want to provoke that. I don't see why anybody should take offense from what you said. Quite the opposite - thanks for being around. I think Georg directed those words to somebody else.
Re: QtD is suspended
On 09/17/2010 11:15 AM, Andrei Alexandrescu wrote:
Thanks for replying. This is very helpful. I'll make some points below,
definitely not as an attempt to revisit the decision you've already made.
The recent big one is the unspecified behavior of
postblit on const/immutable structs and overloading by rvalue/lvalue.
Specifically, we were bending the generator into generating Qt value
types as structs and hit two problems:
1. The generated __cpctor (which does the blit and calls the postblit)
is always non-const and takes a non-const reference to the original.
That means copy-construction of const objects is impossible without
casts.
To proceed, we had to hack the compiler so that __cpctor took a const
original reference and was called on a mutable target reference. That
seemed to work but left us in uncertainty: how it actually should and
will work?
Walter and I discussed a fair amount about copying objects with
different qualifiers. The syntax we discussed was
this(this) const { ... }
which would be called after you copy a const or non-const object into a
const object. Certain special typechecking applies inside that
constructor, but nothing really difficult; it does entail a fair amount
of work in the front end, which Walter hasn't find the time to put in.
Nice to hear that the problem is being worked on. What kind of
typechecking will be performed in const/immutable postblit?
On a funny note, we figured that for a number of reasons it would help
to allow C++-style constructors that offer access to the source; it just
turns out some idioms need to modify the source as well as the destination.
Funny. We seem to be in the opposite situation. We originally thought
that postblit won't be enough for QtD but it looks like copying most (or
all, not sure) value types in Qt do not need access to the source object.
One obvious example is the built-in hashtable that is not shared
properly when it's null. Making the copy constructor spring the
hashtable to life would make it more uniform in behavior.
The situation is a bit ironic - we worked on improving upon C++
constructors but it turns out something similar is still needed in
certain situations.
Anyway, regardless of whether C++-style constructors will be supported
(as an alternative to postblit), the issue you mention is serious. But
by and large I think the matter could gave have be settled in a
different manner: by not catering for const in the first release. D has
a lot to offer besides const, and its const subsystem is a good bit more
restrictive than e.g. C++'s, mainly to help with concurrency. So until
the typical D idioms for using const become established, it's not a
crime to have QtD work without const.
The thing is that D's const looked well suited for our purpose. Postblit
and const were discussed in TDPL so we concluded that their design and
implementation were more or less complete and harmonized. We took the
effort to change the generator to properly generate const qualifiers and
only after that discovered the postblit issues.
I wouldn't go back from a Lexus to
a Yugo because the Lexus doesn't have a butt warmer :o).
:) The Lexus doesn't start and has an obscenity scratched on its hood. A
butt warmer would double its resale price.
2. A bug in the compiler doesn't allow us to overload struct parameters
by ref-ness. So we had to generate by-value parameters where Qt has them
by reference.
And today we've encountered two other bugs in sequence. One was about
the impossibility to access a template instance member from within a
struct nested in another struct and the second didn't give any line/file
information.
We could probably work around or ignore all these problems but I think
it is starting to take more time and nerve than we can afford.
I understand. Let me ask you this - if your bugs had #1 priority, would
that have helped? I mean, is the slow response time to bug submissions a
large annoyance factor?
Definitely. The notorious one
(http://d.puremagic.com/issues/show_bug.cgi?id=424), which hindered QtD
development on Windows, drove a couple of good users away from D and
became a powerful FUD generator, was submitted 4 years ago.
Thanks,
Andrei
I think one of the big factors causing annoyances is miscommunication.
While you have immediate access to Walter, most of us have to settle for
this NG and #d IRC channel (the latter has become a source of nothing
but discouragement).
We carefully follow discussions (at least we try to) in the mail-lists
and NG but often do not know what is the final decision on a problem
having been discussed.
One example is the semantics of clear() and scoped(). As I understood
from one of your posts, you agree that resurrecting the destroyed object
by calling its default constructor is objectionable. However, no further
action followed. So we are at a loss whether you have a better solution,
are still thinking about one, don't have time to change
Re: QtD is suspended
On 09/17/2010 06:48 PM, Michel Fortin wrote:
On 2010-09-17 11:14:21 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Now that I think of it, you don't need a fancy struct to make this
problem appear, you just need two layers of functions:
void fun(const(int[int]) hash) {
fun(hash); // calling ourself, how can we copy hash?
}
Although in this case we could probably assert() that hash is already
initialized.
In my mind it's simpler to just explain the notion that an uninitialized
hash is null and detached from anything else until initialized. Objects
works like this (minus the implicit initialization part), so it
shouldn't be too hard to understand. Better have pragmatic semantics
that work rather than idealistic semantics that fail at a number of cases.
Another difference between object and AA - if one wants to initialize a
class object reference, he does it with a sane syntax. To eagerly
initialize an empty AA, woodoo is needed.
QtD is suspended
After a good amount of hesitation, we have decided to put the QtD project on hold. QtD has a potential to become a complete and effective development platform for D but it is not going to happen soon (unless people with harder hearts take it over). We have spent half of the day hunting yet another dmd bug-o-feature and that is the last straw. We offer our apologies to people who put their hope upon the project. Please come back in a year or two when the language has a stable compiler with the features fully specified, implemented and debugged.
Re: QtD is suspended
On 09/16/2010 06:44 PM, Andrei Alexandrescu wrote: On 9/16/10 9:22 CDT, Max Samukha wrote: After a good amount of hesitation, we have decided to put the QtD project on hold. QtD has a potential to become a complete and effective development platform for D but it is not going to happen soon (unless people with harder hearts take it over). We have spent half of the day hunting yet another dmd bug-o-feature and that is the last straw. We offer our apologies to people who put their hope upon the project. Please come back in a year or two when the language has a stable compiler with the features fully specified, implemented and debugged. Hi Max, Sorry to hear that. Was this an issue of many small annoyances or a few big ones? Thanks, Andrei Hi Andrei, Both, I guess. The recent big one is the unspecified behavior of postblit on const/immutable structs and overloading by rvalue/lvalue. Specifically, we were bending the generator into generating Qt value types as structs and hit two problems: 1. The generated __cpctor (which does the blit and calls the postblit) is always non-const and takes a non-const reference to the original. That means copy-construction of const objects is impossible without casts. To proceed, we had to hack the compiler so that __cpctor took a const original reference and was called on a mutable target reference. That seemed to work but left us in uncertainty: how it actually should and will work? 2. A bug in the compiler doesn't allow us to overload struct parameters by ref-ness. So we had to generate by-value parameters where Qt has them by reference. And today we've encountered two other bugs in sequence. One was about the impossibility to access a template instance member from within a struct nested in another struct and the second didn't give any line/file information. We could probably work around or ignore all these problems but I think it is starting to take more time and nerve than we can afford.
Re: dmd 1.053 and 2.037 release
On Sun, 06 Dec 2009 23:43:16 -0600, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Not wanting to start a language war, but to just say C has plenty of
design holes and then patronize it with the comment that designing
languages is hard - well, you better have a hell of an argument up
your sleeve.
C really has only one major design flaw - the conflation of arrays and
pointers.
Great insight.
Andrei
I think the following real-world code is a good argument against comma
operators:
template typename T
Q_INLINE_TEMPLATE void QListT::node_destruct(Node *from, Node *to)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
while(from != to) --to, delete reinterpret_castT*(to-v);
else if (QTypeInfoT::isComplex)
while (from != to) --to, reinterpret_castT*(to)-~T();
}
Re: dmd 1.053 and 2.037 release
On Sat, 5 Dec 2009 10:59:12 -0500, Nick Sabalausky a...@a.a wrote: Max Samukha spam...@d-coding.com wrote in message news:pkvkh5tvvhie0ga61lrpp5qmt53h5ju...@4ax.com... On Sat, 5 Dec 2009 10:19:23 -0500, Nick Sabalausky a...@a.a wrote: bearophile bearophileh...@lycos.com wrote in message news:hfdt87$1nu...@digitalmars.com... There's a large number of changes! I don't understand what No more comma operators allowed between [ ]. means. I assume that means: int[1,2,3] foo; // - formerly created an int[3], now (presumably) disallowed Was this feature documented anywhere? I don't think it was ever really a feature, it was just a consequence of the next-to-useless expression x,y evaluating to y and int[...] foo; taking a single value for Ah, it is simply the unfortunate comma expression evaluated to 3. Comma expressions need to go. Thanks.
Re: dmd 1.053 and 2.037 release
On Fri, 04 Dec 2009 20:05:13 -0800, Walter Bright newshou...@digitalmars.com wrote: Probably the biggest thing is opDispatch! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.053.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.037.zip Many thanks to the numerous people who contributed to this update. This code: int[3] a = [1, 2, 3]; allocates the literal on heap and then copies it to 'a'. A call to a library function has to be made to avoid the allocation. Can we have such allocations optimized out?
Re: On Iteration By Andrei Alexandrescu
On Mon, 9 Nov 2009 15:24:48 + (UTC), Jesse Phillips jessekphill...@gmail.com wrote: This has a strange hick-up in the intro, Andrei Alexandrescu, author of The D Programming Language I sent them a message, so it should get fixed but :D http://www.reddit.com/r/programming/comments/a2hv3/ on_iteration_by_andrei_alexandrescu/ Good stuff! Just feels right.
Re: dmd 2.029 release
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright newshou...@digitalmars.com wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip Wicked awesome! file:///C:/dmd/html/d/phobos/std_range.html#cons Looks like bug 2676 was fixed in 2.027
Re: dmd 2.029 release
On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha samu...@voliacable.com.removethis wrote: On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright newshou...@digitalmars.com wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip Wicked awesome! file:///C:/dmd/html/d/phobos/std_range.html#cons http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons Looks like bug 2676 was fixed in 2.027
Re: Just one more thing...
On Tue, 03 Mar 2009 20:05:28 +1100, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Bill Baxter wrote:
On Mon, Mar 2, 2009 at 11:55 AM, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Frits van Bommel wrote:
Sean Kelly wrote:
Daniel Keep wrote:
extern(C) void __identifier(blah$UNIX2003)(int);
That would be awesome.
A beneficial side-effect is that I can finally get rid of all those
mixins that are just doing this:
mixin(`void `~name_of_fn~`(int a)
{
// ... rest of function ...
}`);
I'm sure you've thought of this, so why can you not do
mixin(`void `~name_of_fn~`(int a) { implementation_of_function(a); }`);
or
mixin(`alias implementation_of_function `~name_of_fn~`);
Simple enough to break:
mixin(Property(foo, int));
mixin(Property(bar, float));
You can't use alias. You have to have some way of generating unique
symbol names in a context you don't have any control over.
As of 1.039, it seems to be possible to generate unique symbols in a
reasonable way (not well tested):
template UniqueAlias(string member, string idName, int id = 0)
{
static if (is(typeof(mixin(this. ~ idName ~ ToString!(id)
mixin UniqueAlias!(member, idName, id + 1);
else
mixin(alias ~ member ~ ~ idName ~ ToString!(id) ~ ;);
}
unittest
{
class A
{
int x;
}
class B : A
{
int y;
void foo() {}
template Bar() {}
mixin UniqueAlias!(x, m);
mixin UniqueAlias!(y, m);
mixin UniqueAlias!(x, m);
mixin UniqueAlias!(foo, m);
mixin UniqueAlias!(Bar, m);
}
auto s = new B;
s.m0 = 1;
s.m1 = 2;
assert(s.x == 1);
assert(s.y == 2);
assert(s.m2 == 1);
s.m3();
alias B.m4!() bar;
}
There are also little issues with this like how the name of the function, when
debugging, won't be what you expect it to be.
No, you can't use templates because you can't mixin functions with
non-public protection with templates.
-- Daniel
Re: Just one more thing...
On Tue, 03 Mar 2009 21:34:51 +1100, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Max Samukha wrote:
On Tue, 03 Mar 2009 20:05:28 +1100, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Bill Baxter wrote:
On Mon, Mar 2, 2009 at 11:55 AM, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Frits van Bommel wrote:
Sean Kelly wrote:
Daniel Keep wrote:
extern(C) void __identifier(blah$UNIX2003)(int);
That would be awesome.
A beneficial side-effect is that I can finally get rid of all those
mixins that are just doing this:
mixin(`void `~name_of_fn~`(int a)
{
// ... rest of function ...
}`);
I'm sure you've thought of this, so why can you not do
mixin(`void `~name_of_fn~`(int a) { implementation_of_function(a); }`);
or
mixin(`alias implementation_of_function `~name_of_fn~`);
Simple enough to break:
mixin(Property(foo, int));
mixin(Property(bar, float));
You can't use alias. You have to have some way of generating unique
symbol names in a context you don't have any control over.
As of 1.039, it seems to be possible to generate unique symbols in a
reasonable way (not well tested):
template UniqueAlias(string member, string idName, int id = 0)
{
static if (is(typeof(mixin(this. ~ idName ~ ToString!(id)
mixin UniqueAlias!(member, idName, id + 1);
else
mixin(alias ~ member ~ ~ idName ~ ToString!(id) ~ ;);
}
unittest
{
class A
{
int x;
}
class B : A
{
int y;
void foo() {}
template Bar() {}
mixin UniqueAlias!(x, m);
mixin UniqueAlias!(y, m);
mixin UniqueAlias!(x, m);
mixin UniqueAlias!(foo, m);
mixin UniqueAlias!(Bar, m);
}
auto s = new B;
s.m0 = 1;
s.m1 = 2;
assert(s.x == 1);
assert(s.y == 2);
assert(s.m2 == 1);
s.m3();
alias B.m4!() bar;
}
There are also little issues with this like how the name of the function,
when
debugging, won't be what you expect it to be.
No, you can't use templates because you can't mixin functions with
non-public protection with templates.
-- Daniel
Yes, this is definitely an improvement...
char[] Foo(char[] name)
{
const char[] uid = createUniqueAlias(name);
return
`private void `~uid~`() { blah; }`
~ `private alias `~uid~` `~name~`;`;
}
class Bar
{
mixin(Foo(baz));
}
Wait, no; that won't work.
Yes, the mixin that checks for uniqueness needs to have access to the
scope where it is instantiated. So it has to be mixed in directly or
as part of another template mixin
createUniqueAlias won't have access to the
enclosing scope. I'll have to do this:
char[] Foo(char[] name)
{
return `
mixin CreateUniqueAlias!(uid);
mixin(private void ~uid~() { blah; });
mixin(private alias ~uid~ `~name`;);
`;
}
class Bar
{
mixin(Foo(baz));
}
Now I get TWO string-escaped mixins AND a meaninglessly named function
mixed into my instantiating code's scope! Plus, since I need to refer
to the unique name, I have to store it somewhere... and now THAT can
collide with other symbols!
I'm not saying it's not a neat trick; I've used the exact same thing a
few times. But it's not a solution to *this* problem.
-- Daniel
I didn't say it's a solution to this problem. I was saying it is
possible to generate unique symbol names. Your problem could be solved
like this:
template Property(string name, T)
{
private T _prop;
private T prop()
{
return _prop;
}
private T prop(T v)
{
_prop = v;
return v;
}
mixin (alias prop ~ name ~ ;);
}
class A
{
mixin Property!(foo, int);
}
class B : A
{
mixin Property!(bar, float);
mixin Property!(baz, int);
}
void main()
{
auto b = new B;
b.foo = 1;
b.bar = 2.0;
b.baz = 3;
assert (b.foo == 1);
assert (b.bar == 2.0);
assert (b.baz == 3);
}
But such properties cannot implement interfaces. The spec says nothing
about whether aliases should be able to implement interface functions,
so I'm not sure if it's a compiler bug.
Ok, I'm all for the ident() thing. Or probably 'mixin' can be reused?
What ambiguities may arise?
void mixin(foo)() {}
Re: QtD 0.1 is out!
On Sun, 15 Feb 2009 21:27:35 -0500, Eldar Insafutdinov
e.insafutdi...@gmail.com wrote:
Eldar Insafutdinov Wrote:
Max Samukha Wrote:
On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter wbax...@gmail.com
wrote:
On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
samu...@voliacable.com.removethis wrote:
On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
e.insafutdi...@gmail.com wrote:
Finally we managed to compile qtd for Windows. But at the very last
step when compiling example, optlink crashed with a messagebox
containing X86 registers content. This seems to be a blocker for qtd
working on windows..
This may be related to the famous
http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't
make extensive use of templates.
It can also happen because of a single very large file. Perhaps one
created by some sort of automatic code generation. Anything like that
in qtd?
--bb
Yes, all modules are autogenerated. You are right, we probably should
think about splitting up that big file. For example, by placing enum
definitions into a separate module. It is still a less preferred
solution because it requires more tweaking of the original code
generator, which is already messy.
The reason why is this file is big is in this bug
http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that
placing enums outside the class is a good idea, because enums will be
exposed to global namespace unlike original Qt version. I have just checked,
if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which
means that we have to keep that file big until this bug is fixed.
You can still alias global enums into the class scope if you want Qt.A
Anyway, I tried to place enums outside the classes, and I got:
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
Circular import is present.
Taking them outside the class doesn't help. I proposed to put them in
a separate module. That would require renaming them to include class
names. Yes, that sucks but it seems there's not much choice.
module QFooEnums;
enum QFooState {}
module QBarEnums;
enum QBarState {}
module QFoo;
import QBar;
import QFooEnums;
import QBarEnums;
class QFoo
{
alias QFooState State; // if you really want to
void bar(QBarState e) {}
}
---
module QBar;
import QFooEnums;
import QBarEnums;
QBar
{
alias QBarState State;
void foo(QFooState e) {}
}
Or put all the enums in a single module (which will result in a big
file but more digestable for optlink)
Btw, circular imports magically erase static constructors from the
menu.
Re: QtD 0.1 is out!
On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. This may be related to the famous http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't make extensive use of templates.
Re: QtD 0.1 is out!
On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter wbax...@gmail.com wrote: On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha samu...@voliacable.com.removethis wrote: On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. This may be related to the famous http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't make extensive use of templates. It can also happen because of a single very large file. Perhaps one created by some sort of automatic code generation. Anything like that in qtd? --bb Yes, all modules are autogenerated. You are right, we probably should think about splitting up that big file. For example, by placing enum definitions into a separate module. It is still a less preferred solution because it requires more tweaking of the original code generator, which is already messy.
Re: QtD 0.1 is out!
On Thu, 12 Feb 2009 15:48:07 -0500, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Fri, Feb 13, 2009 at 5:00 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Can somebody help me with exporting functions from a DLL? I am defining functions in C++ like extern C __declspec(dllexport) void* __qtd_QObject_QObject_QObject(args) After compiling a DLL with MINGW and producing a lib file for it with implib I am trying to use them from D. In D I declare them as extern (C) void* __qtd_QObject_QObject_QObject(args); And then compile it and link it to the .lib file made by implib for that DLL, but optlink complains that symbol is undefined. I tried to use that Cfunction from C++ and it worked. What I can do? What's the implib command you're using? Often you need to use the /system flag. --bb okay, second problem then - I need to be able to call extern (C) functions defined in D code from DLL. I tried to do getProcAddress(NULL, __some_D_func); but this doesn't work. I think you may have to write some code to explicitly register your D functions with the DLL. You could write a mini getDCodeProcAddress kind of thing in your D code. Then give a pointer to that function to the C code in the DLL at startup. Then C code uses getDCodeProcAddress from there. Maybe there's an easier way, but that's what I'd try. --bb This way won't really work because there are dozens of such a functions - that's for virtual dispatch. I have just solved it by declaring functions export extern (C) and adding _ prefix to function name when calling GetProcAddress. So technically there are no issues to make qtd working on windows! You are a genius! ;)
Re: rdmd and popen
On Sat, 17 Jan 2009 12:57:24 -0800, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Max Samukha wrote: On Sat, 17 Jan 2009 09:19:38 -0800, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Max Samukha wrote: On Sat, 17 Jan 2009 16:09:43 +0200, Max Samukha samu...@voliacable.com.removethis wrote: rebuild is pretty unusable with dmd 2.023, so I've taken the liberty to port a popen implementation to D for Windows and modify rdmd to use that. The handle returned by the popen st ..ill fails at the end of stream (maybe due to this issue http://www.digitalmars.com/d/archives/c++/windows/32-bits/274.html), so the exception is simply ignored for now. The rdmd.d patch and popen are here http://d-coding.com/download/rdmd.zip That's great! Is it ok with you if I take the popen implementation and do the rdmd integration by hand? I made a couple of other changes to rdmd and I'm not sure how patch would cope with that. Also, please let me know if you allow me to change popen a bit to e.g make symbols more local and add documentation. Finally, please let me know if I can publish your implementation in Phobos and use it in other functions such as shell(). Thanks, Andrei Yep. But there are numerous issues with this implementation 1. The bad descriptor error. 2. pclose is not implemented accoring to the standard. There is a way to partially fix this by storing the process ID in the descriptor. 3. 0 is passed to the mode parameter of _open_osfhandle. It should probably be _O_BINARY if the runtime cares at all. 4. This implementaion is based on a number of existing ones so the owners of original versions may be bad enough to claim their rights. So it's far from being a perfect popen :) If your implementation relies heavily on others I think there is no question that you need to ask them for permission and also credit them in your implementation (whether they ask for that or not). Until then I can't do much. Andrei I wouldn't say it relies on them heavily. It uses the same pretty obvious concept: create a pipe and pass its handles to the child process. I don't think it makes much sense to ask permission from developers of MSVC, cygwin and a dozen more, who came up with similar implementations (imperfect in their own ways). Either I credit them all or nobody. I choose the latter for the sake of brevity and put the code in public domain. Meanwhile, I've updated the implementation to use array slices and a different way of getting to the command interpreter. I tried to use __tmpnum field of _iobuf to store the process handle and it seemed to work but then, having no idea of the field's exact purpose, I simply introduced a global vector that maps file descriptors to process handles, meaning popen is now not thread-safe, which is ok. _open_osfhandle doesn't accept the write end of the pipe, so the function will always fail for w mode. As I don't have the sources for digitalmars C runtime I cannot tell what's going on. And it would be really nice if Walter implemented a popen in the C runtime where it belongs. Thanks! The updated version is here http://d-coding.com/download/rdmd.zip. cpopen is for ANSI and UTF-16 versions with C linkage and dpopen contains a wrapper taking UTF-8 strings.
rdmd and popen
rebuild is pretty unusable with dmd 2.023, so I've taken the liberty to port a popen implementation to D for Windows and modify rdmd to use that. The handle returned by the popen st
Re: rdmd and popen
On Sat, 17 Jan 2009 16:09:43 +0200, Max Samukha samu...@voliacable.com.removethis wrote: rebuild is pretty unusable with dmd 2.023, so I've taken the liberty to port a popen implementation to D for Windows and modify rdmd to use that. The handle returned by the popen st ..ill fails at the end of stream (maybe due to this issue http://www.digitalmars.com/d/archives/c++/windows/32-bits/274.html), so the exception is simply ignored for now. The rdmd.d patch and popen are here http://d-coding.com/download/rdmd.zip
Re: Adding Unicode operators to D
On Wed, 22 Oct 2008 17:27:58 -0500, Andrei Alexandrescu [EMAIL PROTECTED] wrote: Please vote up before the haters take it down, and discuss: http://www.reddit.com/r/programming/comments/78rjk/allowing_unicode_operators_in_d_similarly_to/ Andrei I'm already having problems with unicode: the news reader I'm using doesn't display the characters correctly (maybe it's time to update). If unicode can be avoided, please avoid it.
Re: Adding Unicode operators to D
On Thu, 23 Oct 2008 08:33:16 -0400, bearophile [EMAIL PROTECTED] wrote: I always use English for variable names, instead of my language, because I've had my share of debugging code with variables in other languages and it's not a nice thing to do. Regarding Python code, its std libs keeps identifiers in English only, but when they have invented the OneLaptopForChild that uses Python a lot, they have decided that 'kids' may enjoy using variable names in their language... Bye, bearophile Keep children away from Python. Let them have happy lives :)
Re: DMD 1.036 and 2.020 releases
On Mon, 20 Oct 2008 16:29:36 -0700, Walter Bright [EMAIL PROTECTED] wrote: http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.036.zip The 2.0 version splits phobos into druntime and phobos libraries (thanks to Sean Kelly). This will enable both Tango and Phobos to share a common core library. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.020.zip There are a lot of structural changes that go along with this, so expect some rough patches with this release. It may take a followup release to file them down. There's also some renaming of imports and function names, as a compromise with Tango names. Thank you!
