Re: Is string.ptr a part of the language?
On Apr 1, 10 13:20, Ali Çehreli wrote: I've seen people access string.ptr in code examples. Does that member exist and publicly accessible? How about the internals of slices, associative arrays, and others? I am not planning or need to use them. I am just trying to determine how much of the internals are a part of the D language. Thank you, Ali string is just an alias of invariant(char)[], and dynamic arrays do have the .ptr property (http://www.digitalmars.com/d/2.0/arrays.html).
Re: Feature suggestion: in-place append to array
Steven Schveighoffer wrote: > What do you mean by nondeterministic? It's very deterministic, just not always easy to determine ;) However, given enough context, it's really easy to determine. When I say deterministic, I'm referring to determinism from the user's point of view, where the allocation behavior is affected solely by the parameter (the size request, e.g. 1 objects) and not by some kind of internal state, hidden context, or arcane black magic. :p > The amount of memory given is determined by the GC, and ultimately by the OS. The currently supported OSes allocate in Page-sized chunks, so when you allocate any memory from the OS, you are allocating a page (4k). Most likely, you may not need a whole page for the data you are allocating, so the GC gives you more finely sized chunks by breaking up a page into smaller pieces. This strategy works well in some cases, and can be wasteful in others. The goal is to strike a balance that is "good enough" for everyday programming, but can be specialized when you need it. That's understandable, and it makes sense that the actual memory being allocated would correspond to some chunk size. It's really just opaque black box behavior that poses a problem; if users are given well-defined guidelines and chunk sizes, that would work just fine. For instance, a spec like, "reserve a multiple of 512 bytes and that's exactly what you will be given," would allow users to minimize wastefulness and know precisely how much memory they're allocating. If you want to control memory allocation yourself, you can always do that by allocating page-sized chunks and doing the memory management on those chunks yourself. I do something very similar in dcollections to speed up allocation/destruction. I think D has deterministic allocation, and better ability than C++ to make custom types that look and act like builtins. Therefore, you can make an array type that suits your needs and is almost exactly the same syntax as a builtin array (except for some things reserved for builtins, like literals). Such a thing is certainly possible, even with using the GC for your allocation. That parallels what game devs do in C++: They tend to use custom allocators a lot, and they're likely to follow the same basic strategy in D too, if/when it becomes a suitable replacement. I'm still just browsing though, and I'm not all that familiar with D. If you can't actually use the built-in dynamic arrays for this purpose, how difficult would it be to reimplement a contiguously stored dynamic container using custom allocation? I suppose you'd have to build it from the ground up using a void pointer to a custom allocated block of memory, right? Do user-defined types in D have any/many performance disadvantages compared to built-ins? BTW, I made the change to the runtime renaming the function previously known as setCapacity to reserve. It won't be a property, even if that bug is fixed. -Steve That's a bit of a downer, since a capacity property would have nice symmetry with the length property. I suppose there were good reasons though. Considering the name change, does that mean reserve can only reserve new space, i.e. it can't free any that's already been allocated? (That makes me wonder: Out of curiosity, how does the garbage collector know how much space is allocated to a dynamic array or especially to a void pointer? I suppose it's registered somewhere?)
Is string.ptr a part of the language?
I've seen people access string.ptr in code examples. Does that member exist and publicly accessible? How about the internals of slices, associative arrays, and others? I am not planning or need to use them. I am just trying to determine how much of the internals are a part of the D language. Thank you, Ali
Re: Feature suggestion: in-place append to array
On Wed, 31 Mar 2010 17:57:07 -0400, Mike S wrote: Steven Schveighoffer wrote: You are correct, setCapacity ensures that *at least* the given number of elements will be available for appending. I planned on making the function a property (but a bug would not allow that), the original intended usage was: a.capacity = 1; Reserve doesn't work in this context. Can you come up with a name that does? I'll bring up reserve (as a function) as an alternative on the phobos mailing list, and see what people say. I kind of liked the setter/getter idea, but you make a good point. -Steve Sorry if resurrecting this thread is against netiquette, but it caught my eye, and this is my first newsgroup post in years. ;) Anyway, is there any compelling reason why setCapacity or modifying a.capacity should allocate a nondeterministic amount of storage? What do you mean by nondeterministic? It's very deterministic, just not always easy to determine ;) However, given enough context, it's really easy to determine. Depending on the application, programmers might require strict control over memory allocation patterns and strict accounting for allocated memory. Game programmers, especially console game programmers, tend to strongly prefer deterministic allocation patterns, and nondeterminism is one of the [several] common complaints about the C++ STL (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html is a good resource on these kind of issues). In the case of D (which I'm considering learning), this is especially important for dynamic arrays, partly because they're so useful by themselves, and partly because they may form the backbone of custom containers. The amount of memory given is determined by the GC, and ultimately by the OS. The currently supported OSes allocate in Page-sized chunks, so when you allocate any memory from the OS, you are allocating a page (4k). Most likely, you may not need a whole page for the data you are allocating, so the GC gives you more finely sized chunks by breaking up a page into smaller pieces. This strategy works well in some cases, and can be wasteful in others. The goal is to strike a balance that is "good enough" for everyday programming, but can be specialized when you need it. If you want to control memory allocation yourself, you can always do that by allocating page-sized chunks and doing the memory management on those chunks yourself. I do something very similar in dcollections to speed up allocation/destruction. Whereas it's easy to add "smart nondeterministic" behavior to a deterministic setCapacity function by providing a wrapper, ordinary language users can't do the opposite. Because of this, and because dynamic arrays are so central to the D language, a nondeterministic setCapacity function may deter game programmers, especially console programmers, from adopting D. Assuming you see this post, what are your thoughts here? I think D has deterministic allocation, and better ability than C++ to make custom types that look and act like builtins. Therefore, you can make an array type that suits your needs and is almost exactly the same syntax as a builtin array (except for some things reserved for builtins, like literals). Such a thing is certainly possible, even with using the GC for your allocation. BTW, I made the change to the runtime renaming the function previously known as setCapacity to reserve. It won't be a property, even if that bug is fixed. -Steve
Re: @pinned classes
On Wed, 31 Mar 2010 22:59:08 -0400, bearophile
wrote:
>
> Thinking more about some of the things I've recently written to Mike S, I
> think the situation of the D GC can be improved not teaching the D type
> system how to tell apart three types of pointers, but introducing the @pinned
> for classes:
>
> @pinned class Foo {}
>
> Unpinned memory can be moved, allowing a generational moving GC, that's
> efficient.
>
> All objects instantiated from a unpinned class are unpinned. This is a little
> limiting (you can think of allowing both pinned and unpinned instances) but
> this keeps the situation simpler for the compiler and the programmer.
>
> With unpinned classed Java/C# programmers can program in D in a style similar
> to the one they are used too in their languages. This is good.
>
> Classes are unpinned on default (the opposite of the current situation) to
> maximize the amount of unpinned objects.
>
> The @pinned attribute can't be used with structs and enums, they are always
> pinned becasue Java programmers don't use them, they are usually used for
> performance in a lower level way, and because they don't have a virtual table
> pointer that the GC can use, etc.
>
> Normal unpinned classes can't contain pointers to their fields or to unpinned
> memory, in a transitive way. They can contain pointers to pinned memory.
>
> In system (unsafe) modules you can of course cast a unpinned class referent
> to a pointer, but this is nearly, because the GC can move the class in memory
> in any moment. It can be useful for a short time if you disable the GC.
>
> Pinned classes act as now, they can contain pointers to their fields too.
>
> The GC can move around unpinned objects and must keep in place the pineed
> ones, the GC has to modify the references to unpinned classes (references on
> the stack, inside other objects, etc), to update them to their new positions.
>
> Probably enums can't contain references to unpinned memory, to keep things
> tidy.
>
> This can be a compile error, prbably Bar too has to be unpinned:
> class Foo {}
> @pinned class Bar: Foo {}
>
> I'm sure I'm forgetting several things :-)
>
> Bye,
> bearophile
I think the D2 spec puts restrictions on what you can do with GC-
allocated pointers (can't convert them to integers, can't perform
arithmetic on them outside of their bounds, etc.), and I think they're
restrictive enough that a copying garbage collector could work with no
changes to compliant code.
- Justin Spahr-Summers
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
On Wed, 31 Mar 2010 21:10:22 -0600, Phil Deets wrote: On Wed, 31 Mar 2010 11:49:31 -0600, Nick Sabalausky wrote: Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. Crimson Editor (my preferred D text editor) has menu options to convert tabs to spaces, convert leading tabs to spaces, convert spaces to tabs, and remove trailing spaces. Correction: It has leading spaces to tabs, not leading tabs to spaces.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
On Wed, 31 Mar 2010 11:49:31 -0600, Nick Sabalausky wrote: Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. Crimson Editor (my preferred D text editor) has menu options to convert tabs to spaces, convert leading tabs to spaces, convert spaces to tabs, and remove trailing spaces.
Re: Feature suggestion: in-place append to array
bearophile wrote: The short D1 history shows that designers of small games are willing to use D. Some game designers seem almost desperate to find an usable language simpler than C++. So I agree with you that D2 can be designed keeping an eye at game designers too. But that's very demanding people, it's not easy to satisfy them even with a mature language + compiler + std lib + dev tools. And currently nothing in D2 is mature. For them maybe not even the most mature thing you can find in D world, the back-end of ldc (llvm), is mature enough :-) Yeah, you're right about the demanding tool and maturity requirements that game studios have, but assuming people continue working on D and other people adopt it and enhance the tools, those things will flesh out over time. I'm young enough that I look forward to seeing it overtake C++ in the game world someday. I am not able to tell the future. Some parts of D design are already old-style: - Some early design decisions make hard to inline D virtual functions (so if you write D code in Java style, you see a significant slow down compared to similar Java code running with HotSpot). So far no one seems to care of this, we'll see if I am right to see a problem here; Well, writing code Java-style is certainly no problem for game devs, considering they already minimize virtual function usage, at least in lower code layers. ;) A system language is something that you can use to write very small binaries, that can be used to write a kernel like Linux, device drivers for a smaller computer+CPU, etc. Such things are hard to do in D2, I don't see Linus using D2 to write his kernel, he even thinks C++ is unfit. So I see D2 more like a "low-level application language", on a level located somewhere between C and C#. It can also become a numerics language (see below). This is true, but I do recall seeing an executable size comparison somewhere, and the D version of a program (hello world?) beat out the C++ version by about a factor of two. The C version killed both, but still, perhaps D might not be eternally unfit even if C++ is. ;) Then again, maybe the C++ program was just including a superfluous amount of library code, and maybe D programs are generally larger than their C++ equivalents. Plus, if it was hello world, it obviously wasn't using a lot of higher-level features. Either way though, even if D does become fit for kernel/driver code someday, it'll still be a long time before someone actually starts from scratch to write a new kernel using it anyway. As it stands, I believe there are only two major kinds of programmers who still use C++, and those are game programmers and masochists. ;)< There's also an army of legacy programmers that have to update and debug tons of C++ code. Part of the human society works thanks to a mountain of C++ code. Online programming competitions are usually won by C++ code. People will find ways to use C++ for many more years, it will probably outlast us all. You're right, and I actually realized I misspoke here a little bit ago while I was eating. The legacy code just might keep people using C++ until the sun dies. Still, I maintain that game developers and masochists probably comprise a large portion of programmers starting completely new projects in C++. :D It's too low-level for scripting tasks,< I have asked several times to have Python-style array/lazy comprehensions in D :-) They help. I think their introduction can reduce by 10-30% the length of D2 programs. How difficult do you think that would be for the compiler devs to implement in the semantic sense? Assuming it can be done without major hardship or compromising the design of the language, that would be really cool. Syntactically speaking, Python list comprehensions make the source so much more compact, expressive, and clean that a statically compiled language using them would really stand out. If they're implemented correctly, I can't see any reasons why the syntactic sugar would be any slower than spelling everything out explicitly, either. The syntax would have to be a bit different to feel at home in D, but the idea itself probably isn't too foreign. I also noticed a discussion about Python tuples from October 2009 I think, and native tuples in D would also be useful...more useful than in Python, in fact. After all, Python lists can contain mixed types (unlike arrays in D), so they make tuples largely redundant except for their different conventional meanings (and except for the ability to used named tuples). In comparison, built-in tuples in D with similarly elegant syntax would fill in a much larger gap. I suppose they'd work something like implicitly generated struct types, which could be hastily constructed as lvalues or rvalues, returned from functions, packed/unpacked and passed to functions, etc. Honestly, I think there's a lot to be learned from the expressiven
@pinned classes
Thinking more about some of the things I've recently written to Mike S, I think
the situation of the D GC can be improved not teaching the D type system how to
tell apart three types of pointers, but introducing the @pinned for classes:
@pinned class Foo {}
Unpinned memory can be moved, allowing a generational moving GC, that's
efficient.
All objects instantiated from a unpinned class are unpinned. This is a little
limiting (you can think of allowing both pinned and unpinned instances) but
this keeps the situation simpler for the compiler and the programmer.
With unpinned classed Java/C# programmers can program in D in a style similar
to the one they are used too in their languages. This is good.
Classes are unpinned on default (the opposite of the current situation) to
maximize the amount of unpinned objects.
The @pinned attribute can't be used with structs and enums, they are always
pinned becasue Java programmers don't use them, they are usually used for
performance in a lower level way, and because they don't have a virtual table
pointer that the GC can use, etc.
Normal unpinned classes can't contain pointers to their fields or to unpinned
memory, in a transitive way. They can contain pointers to pinned memory.
In system (unsafe) modules you can of course cast a unpinned class referent to
a pointer, but this is nearly, because the GC can move the class in memory in
any moment. It can be useful for a short time if you disable the GC.
Pinned classes act as now, they can contain pointers to their fields too.
The GC can move around unpinned objects and must keep in place the pineed ones,
the GC has to modify the references to unpinned classes (references on the
stack, inside other objects, etc), to update them to their new positions.
Probably enums can't contain references to unpinned memory, to keep things tidy.
This can be a compile error, prbably Bar too has to be unpinned:
class Foo {}
@pinned class Bar: Foo {}
I'm sure I'm forgetting several things :-)
Bye,
bearophile
Re: Feature suggestion: in-place append to array
Mike S: >the needs of game programmers should be taken seriously while considering D's >evolution:< The short D1 history shows that designers of small games are willing to use D. Some game designers seem almost desperate to find an usable language simpler than C++. So I agree with you that D2 can be designed keeping an eye at game designers too. But that's very demanding people, it's not easy to satisfy them even with a mature language + compiler + std lib + dev tools. And currently nothing in D2 is mature. For them maybe not even the most mature thing you can find in D world, the back-end of ldc (llvm), is mature enough :-) >Right now, D hasn't completely found its niche, but it seems to position >itself as a sane successor to C++ for systems-level programming.< I am not able to tell the future. Some parts of D design are already old-style: - Some early design decisions make hard to inline D virtual functions (so if you write D code in Java style, you see a significant slow down compared to similar Java code running with HotSpot). So far no one seems to care of this, we'll see if I am right to see a problem here; - Some of D unsafe characteristics are worked on to improve their safety, but there's lot of road to travel still, for example null-safety and integers-overflow-safety are far away still. People are trying to explain Walter still why null-safety has some importance. - D2 defaults to mutables. This can be acceptable, I don't know; - Currently D2 is not designed from the start to work with an IDE (but I think this problem can be fixed with not too much work); - The built-in unit testing and documentation are not fit for professional usage (but the documentation is easy to extend because they are just comments, so it's a smaller problem). - etc. A system language is something that you can use to write very small binaries, that can be used to write a kernel like Linux, device drivers for a smaller computer+CPU, etc. Such things are hard to do in D2, I don't see Linus using D2 to write his kernel, he even thinks C++ is unfit. So I see D2 more like a "low-level application language", on a level located somewhere between C and C#. It can also become a numerics language (see below). >As it stands, I believe there are only two major kinds of programmers who >still use C++, and those are game programmers and masochists. ;)< There's also an army of legacy programmers that have to update and debug tons of C++ code. Part of the human society works thanks to a mountain of C++ code. Online programming competitions are usually won by C++ code. People will find ways to use C++ for many more years, it will probably outlast us all. >It's too low-level for scripting tasks,< I have asked several times to have Python-style array/lazy comprehensions in D :-) They help. I think their introduction can reduce by 10-30% the length of D2 programs. >I think D will eventually be used for writing other heavy-duty non-OS >frameworks and software systems,< >From what I've seen so far I think D2 will appeal to some numerics folks too, >so it can eat a bit of Fortran pie too. Some improvements can make D2 more >appealing to them, Don is working on this too. (Some ideas from Chapel >language can help here, but I think no one here has taken a serious look at it >so far). >You're right that the garbage collector is a major issue - probably the >biggest one inherent to the language design - but I haven't determined it's a >dealbreaker, at least not yet.< The situation with the D GC is interesting. First of all D GC is not refined, Java VM GCs are way more advanced. So D GC will need a much more modern GC. Another problem is that the current D GC is quite imprecise, this causes leaks when you use it in real programs that have to run for more than few minutes. Part of this problem can be solved using a better GC that's more precise (this can slow it down a bit, but avoids a good amount of memory leaks). The other problem is intrinsic of the language, that makes it hard or impossible to invent a fully precise GC for D. And D makes it hard to use a modern generational moving GC with D. You can't just adopt a JavaVM GC with D. Even the Mono GC (that knows the notion of pinned/unpinned memory) can be unfit (because it's designed for mostly unpinned memory). This is partially caused by D being a low level language with pointers, and it's partially caused by D2 type system unable to tell apart: 1) hand-managed pointers, to GC memory or C heap memory; 2) GC-managed pointers to pinned memory; 3) GC-managed pointers to unpinned memory. I think Walter think that telling them apart in the language makes D too much complex, and he can be right. But the current situation makes it hard to design a very efficient GC for D. So I don't think high-performance game designers will use D GC for the next few years, they will manage most or all the memory manually. I am ignorant, but I think
Re: Solution for Fatal flaw in D design which is holding back widespread
> I have tried that "Universal Indent GUI" with Uncrustify. It seems nice but > it has so many options that finding the correct ones is lot of work, even if > you use that GUI: > http://uncrustify.sourceforge.net/config.txt > It seems unable to recognize foreach and foreach_reverse. > > Bye, > bearophile In my case it breaks class indentation. I guess template syntax is a bit tricky for it too.
Re: Feature suggestion: in-place append to array
bearophile wrote: Mike S: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html It's a nice read. I don't see them switching to D soon. If you whisper them that D is based on a GC they will run away screaming :-) Bye, bearophile Hah...well, there's a reason I'm still just looking into D rather than diving in headfirst! :p Actually though, I do believe the needs of game programmers should be taken seriously while considering D's evolution: Right now, D hasn't completely found its niche, but it seems to position itself as a sane successor to C++ for systems-level programming. As it stands, I believe there are only two major kinds of programmers who still use C++, and those are game programmers and masochists. ;) Odds are, D won't be replacing C anytime soon for operating system kernels and such. It's too low-level for scripting tasks, and most website designers and non-real-time applications programmers use higher-level languages already (C#, Python, PHP...shudder...etc.), and they're unlikely to go back. I think D will eventually be used for writing other heavy-duty non-OS frameworks and software systems, but if it's really going to become the successor to C++, it's going to have to absorb most of C++'s user base...and that includes game programmers. You're right that the garbage collector is a major issue - probably the biggest one inherent to the language design - but I haven't determined it's a dealbreaker, at least not yet. After all, D also allows manual memory management, and freeing memory early apparently helps speed things up anyway (http://stackoverflow.com/questions/472133/turning-off-the-d-garbage-collector). That part helps ensure control over how much memory is used/available, and the only other issue with the garbage collector is reconciling its running time with the soft real-time constraint that games have to satisfy. I can think of a few tactics which should help here: 1.) In addition to permitting better reasoning about memory allocations, freeing most memory manually should reduce the load on the garbage collector and reduce its runtime, right? 2.) On the simulation side of the game engine, I believe a constant timestep promotes a more robust design, and that means some frames (relatively idle ones) will have plenty of CPU time left over. If you can explicitly call the garbage collector to make it run during those times instead of at nondeterministic times (can you?), you can maintain a smooth framerate without any GC-induced spikes. 3.) Can user code execute simultaneously with the GC in other threads (on other cores), or does the GC halt the entire program for safety reasons? Assuming simultaneous threaded execution is permitted, it would also dramatically reduce the GC's impact on multi-core systems. Assuming these strategies work, the garbage collector by itself shouldn't be a showstopper. In the case of dynamic arrays, resizing capacity deterministically is one of those small things that would be really helpful to anal game programmers, and it probably wouldn't hurt anyone else, either. Plus, it's easier to implement than "smart nondeterministic" resizing anyway. :)
Unofficial wish list status.(Apr 2010)
Hi
This is the monthly status for the unofficial d wish list:
http://all-technology.com/eigenpolls/dwishlist/
I am closing this wish list.
New requests should be posted to bugzilla on http://d.puremagic.com/issues/
It would be a great help,
if you could help move some of the wish list items to bugzilla.
But please use the same title, so it is easy to avoid duplication.
Right now the wish list looks like this:
214 Stack tracing (#26)
204 Reflection API (#6)
136 vectorization (#10)
115 Multiple return values (tuples (#28)
105 Multiple opCast per class (#24)
98 Debug check for null reference (#52)
91 Native AMD64 codegen (#36)
82 !in (#44)
80 Short syntax for new (#18)
77 unit test after compilation (#1)
74 extra compiler values (#19)
69 Return-type overloading (#49)
59 Explicit out/inout (#38)
57 Foreach on first/on last (#42)
55 Unit test isolation (#2)
52 Posix threads support native (#3)
50 Array pushback/popback (#51)
49 Variadic arguments re-passing (#102)
47 better syntax for cast (#23)
46 Array masking (#11)
45 Consistent struct/class sizeof (#40)
44 Explicit type initializers (#35)
43 L-Value return (#73)
43 struct constructor (#97)
41 Named keyword arguments (#87)
37 black box unit testing (#8)
36 Non-Static isExpression (#37)
35 unit test & code separation (#7)
35 associative arrays by index (#16)
35 coherent assoc. array syntax (#20)
34 Conditional syncronized (#30)
34 Explicit module `friendship` (#43)
33 Pass value params byref (#34)
33 auto-member objects (#45)
30 Unit test measurements (#9)
30 Explicit property keyword (#83)
27 Renaming ctor/dtor (#17)
27 Inline enum declaration (#76)
26 interface to C++ (#71)
26 Small Exectables (#88)
25 User-defined sync function (#31)
23 Pascal like sets (#61)
23 if, while, true, false, int (#86)
22 proper cast operators (#21)
22 Iterators and Generators (#58)
21 Built-in variant type (#56)
20 Precise names for floats (#62)
19 D library contest (#59)
18 No Postfix Array Declarations (#85)
18 range type (#106)
18 Real C bitfields (#145)
17 Full lexical closures (#140)
16 conv() and opConv (#66)
16 modules must not rely on files (#84)
15 Call log (#47)
15 Improve module architecture (#64)
15 Finite sets (#72)
15 opCast overloading (#81)
15 garbage collection switch (#96)
15 Multi-Dimensional Allocation (#109)
14 copy operator (#95)
13 Meta Information (#69)
12 Parallel Scavenging GC (#80)
11 Against class instance sizeof (#48)
11 inout variable and return (#60)
11 imag and comp FP types. (#63)
11 inline expansion (#67)
11 in for arrays (#161)
11 Tango to work with D2 (#179)
10 function inheritance (#92)
10 Statically check for == null (#98)
10 In flight exception detection (#101)
10 static foreach(scope/unscope) (#152)
9 Relational class/array algebra (#65)
9 support struct&array in switch (#99)
9 in for arrays (#160)
9 Get rid of const (#165)
9 throws keyword (#173)
7 array in template arguments (#91)
7 date/time/datetime literal (#105)
7 void Class.Method() {} syntax (#146)
6 Declaration in function calls (#74)
6 Better UTF32 Support (#113)
6 Implicit New (#143)
6 Efficient array opCatAssign (#148)
5 named tuple (#103)
5 Reallocation Keyword (#108)
5 Explicit out/inout/lazy (#110)
5 First-class continuations (#141)
5 tuple literal and append-op (#151)
5 ext property for basic types (#154)
5 {Cleaner Operator Overloading} (#166)
5 suffix identifiers. (#168)
5 Property declarator (#174)
5 Voting in bugzilla for D. (#176)
5 Power operator (#177)
4 System.Windows.Forms (#93)
4 function call over network (#111)
4 templated constructors (#164)
4 New Switch Case Design (#170)
4 Easy threading a la OpenMP (#189)
3 Property shortcut (#144)
3 variable template(short syntax (#149)
3 template literal (#150)
3 Custom Attributes (#159)
3 C++ Member Pointers (#167)
3 Remove const (#171)
3 Remove const (#172)
3 Enum string cast (#178)
3 Template inst. syntax: <> (#182)
3 classes on stack (or ROM) (#188)
2 Manage .resources files (#70)
2 Multistep return (#75)
2 constant operater overloading (#100)
2 solve interdepend static this (#107)
2 temp alias param specialize (#112)
2 Quick For Syntax (#142)
2 invariant function (#156)
2 constant member functions (#158)
2 Keyword Pow Operator (#162)
2 Custom Syntax (#163)
2 Overlapping array copy (#181)
2 Invariant => invar (#185)
2 Output C Code (#194)
1 consistant new (#77)
1 remove initializers (#147)
1 __traits (#153)
1 temporary variable (#155)
1 Dynamic Conditional (#157)
1 Better Array Function Template (#169)
1 Remove SFINAE (#175)
1 Auto const member funcs (#180)
1 Template inst. syntax: <> (#183)
1 Template inst. syntax: <> (#184)
1 similar templt/function syntax (#186)
1 other systems (#195)
1 other archs (#196)
0 -nogc option (#187)
0 link exchange request (#190)
0 link exchange request (#191)
0 switch case accept range and (#192)
0 switch case accept range and (#193
Re: Feature suggestion: in-place append to array
Mike S: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html It's a nice read. I don't see them switching to D soon. If you whisper them that D is based on a GC they will run away screaming :-) Bye, bearophile
Re: Solution for Fatal flaw in D design which is holding back widespread
Jérôme M. Berger: > Uncrustify already claims to support D: > http://uncrustify.sourceforge.net/ I have tried that "Universal Indent GUI" with Uncrustify. It seems nice but it has so many options that finding the correct ones is lot of work, even if you use that GUI: http://uncrustify.sourceforge.net/config.txt It seems unable to recognize foreach and foreach_reverse. Bye, bearophile
Re: It is impossible to debug code compiled with dmd
Robert Clipsham wrote: On 31/03/10 21:58, Walter Bright wrote: Robert Clipsham wrote: The first one is in bugzilla, Do you mean http://d.puremagic.com/issues/show_bug.cgi?id=1079 or another? http://d.puremagic.com/issues/show_bug.cgi?id=3987 Please ignore the attached patch file, it's the incorrect fix (although it does work). I haven't written a formal patch, I didn't see a need with it only being 2 lines needing removing (which are mentioned in my last post, and a comment on that bug). As an update to the case it doesn't fix, it seems the second DW_TAG_formal_param is causing the debug info for something else to be written half way between the debug info for something else, so when it's read it's read incorrectly. Still working on this, I'm hoping to have a patch for it tonight, I've already put days into this, I'd rather not spend too much more ;) I and I'm sure many others appreciate your efforts.
Re: console output in dll doesn't work OT a bit
I'm not sure what you mean by "de-alloc". The dll_helper functions in DllMain take care of initializing and deinitializing the tls-data (running static ctors and dtors) when new threads are created or terminated. Sorry, my question was not very exact. Nevertheless you've answered my question :) With the current version you cannot share gc-allocated memory between DLLs. When the DLL is unloaded the complete heap used by the DLL is destroyed. Not sure about the impact. Bjoern
Re: Feature suggestion: in-place append to array
Steven Schveighoffer wrote: You are correct, setCapacity ensures that *at least* the given number of elements will be available for appending. I planned on making the function a property (but a bug would not allow that), the original intended usage was: a.capacity = 1; Reserve doesn't work in this context. Can you come up with a name that does? I'll bring up reserve (as a function) as an alternative on the phobos mailing list, and see what people say. I kind of liked the setter/getter idea, but you make a good point. -Steve Sorry if resurrecting this thread is against netiquette, but it caught my eye, and this is my first newsgroup post in years. ;) Anyway, is there any compelling reason why setCapacity or modifying a.capacity should allocate a nondeterministic amount of storage? Depending on the application, programmers might require strict control over memory allocation patterns and strict accounting for allocated memory. Game programmers, especially console game programmers, tend to strongly prefer deterministic allocation patterns, and nondeterminism is one of the [several] common complaints about the C++ STL (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html is a good resource on these kind of issues). In the case of D (which I'm considering learning), this is especially important for dynamic arrays, partly because they're so useful by themselves, and partly because they may form the backbone of custom containers. Whereas it's easy to add "smart nondeterministic" behavior to a deterministic setCapacity function by providing a wrapper, ordinary language users can't do the opposite. Because of this, and because dynamic arrays are so central to the D language, a nondeterministic setCapacity function may deter game programmers, especially console programmers, from adopting D. Assuming you see this post, what are your thoughts here?
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky Wrote: > I was thinking of it as whole-programming-world kind of thing not specific > to any langauge, kind of like how UTF has been replacing ASCII and code > pages (although this would use UTF). Basically kind of like a programmer's > RTF (although it obviously wouldn't involve setting fonts and colors, but > rather things like tab settings). You mean something like PTSC - http://www.synchro.net/ptsc_hdr.html
Re: It is impossible to debug code compiled with dmd
On 31/03/10 21:58, Walter Bright wrote: Robert Clipsham wrote: The first one is in bugzilla, Do you mean http://d.puremagic.com/issues/show_bug.cgi?id=1079 or another? http://d.puremagic.com/issues/show_bug.cgi?id=3987 Please ignore the attached patch file, it's the incorrect fix (although it does work). I haven't written a formal patch, I didn't see a need with it only being 2 lines needing removing (which are mentioned in my last post, and a comment on that bug). As an update to the case it doesn't fix, it seems the second DW_TAG_formal_param is causing the debug info for something else to be written half way between the debug info for something else, so when it's read it's read incorrectly. Still working on this, I'm hoping to have a patch for it tonight, I've already put days into this, I'd rather not spend too much more ;)
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky wrote: > And here's an even crazier idea: Some sort of well-thought-out UCF format > (Unicode Code Format) that is like plain-text, but includes a standard > metadata header (typically hidden while editing) that can help sort all this > stuff out, and maybe other things as well. Obviously it would require > special support from compilers and editors, but if it was well-designed > (including discouragement of proprietary extensions - don't want a repeat of > HTML) then I think it would be worth trying to push. > You mean like the Emacs/vim headers which allow to specify everything in special comments near the top or bottom of the file and Emacs/vim sets the appropriate options automatically upon loading the file? http://www.gnu.org/software/emacs/manual/html_node/emacs/File-Variables.html Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: It is impossible to debug code compiled with dmd
Robert Clipsham wrote: The first one is in bugzilla, Do you mean http://d.puremagic.com/issues/show_bug.cgi?id=1079 or another?
Re: It is impossible to debug code compiled with dmd
On 31/03/10 21:37, Walter Bright wrote: Please let me know when you have dwarf.c patches ready, and thank you for trying to figure this out. The first one is in bugzilla, you just need to comment out/remove the lines: abuf.writeByte(DW_AT_type); abuf.writeByte(DW_FORM_ref4); (at about line 1447, in the TYjfunc case of the switch statement in dwarf_typidx()). And: infobuf->write32(nextidx); // DW_AT_type At about line 1469 of dwarf.c. This fixes debug info for druntime, phobos, and a couple of test projects (the debug info looks identical to the equivalent output from clang too). There is one case which this patch doesn't solve, and that's for function pointers in the form: T function(U function(V)) foobar; Where T, U and V are any type. If you look at the .debug_info produced by dmd (either before or after the above patch, use objdump --dwarf=info testFile), you will see that it ends up writing what is parsed as a DW_TAG_compile_unit after the second DW_TAG_formal_parameter, so it seems some stray bytes are getting written causing the 0x1 to be detected as the abbrev rather than what ever it was intended to be (I'm still looking into this).
Re: console output in dll doesn't work OT a bit
BLS wrote: a bit OT sorry.. Rainer, did you give D2 static variables inside an DLL a try ? Are they thread local ? it looks like but I am not sure. static variables that are neither const/immutable nor shared are in thread local storage. > In case that they are > another question is coming up > who cares about de- alloc. Guess I have to. You see me clueless. I'm not sure what you mean by "de-alloc". The dll_helper functions in DllMain take care of initializing and deinitializing the tls-data (running static ctors and dtors) when new threads are created or terminated. With the current version you cannot share gc-allocated memory between DLLs. When the DLL is unloaded the complete heap used by the DLL is destroyed.
Re: It is impossible to debug code compiled with dmd
Robert Clipsham wrote: On 31/03/10 10:41, Eldar Insafutdinov wrote: On Linux dmd outputs faulty debug info. There are several bugs in the debug info on linux, one of them I've fixed (for most cases ie. anything that requires phobos, I'm working on the other cases ie. anything that needs funky libraries that use a lot of complicated function pointers), and another one you've sent me a massive test case for which I'm working down to a manageable size for a bug report now (I'd have done it by now, your make file doesn't play nicely with my multilib system though ;)). Other than those 2 bugs I don't know what else is blocking debug info on linux... I'm becoming quite familiar with DWARF/dmd's backend code for DWARF through all this debugging, so if I can get these bugs fixed I'd be happy to work on any others while I have time. Please let me know when you have dwarf.c patches ready, and thank you for trying to figure this out.
Re: It is impossible to debug code compiled with dmd
Eldar Insafutdinov wrote: On Linux dmd outputs faulty debug info. On Windows optlink crashes when building code in debug. Is there a bugzilla for this? For example, I compile the entire test suite on Windows with debugging on, and no optlink crashes.
Re: console output in dll doesn't work OT a bit
On 31/03/2010 21:21, Rainer Schuetze wrote: Trass3r wrote: What was the fix? The example in samples/d/mydll compiles fine and looks very much the same. Note that I'm talking about D2. 1. The path in build.bat is incorrect: is ..\..\..\bin\dmd instead of ...\..\..\windows\bin\dmd 2. printf isn't defined by default anymore. 3. The gc code etc in DllMain is for D1 I guess. I used code from http://www.digitalmars.com/d/2.0/dll.html instead. 4. HINSTANCE g_hInst; wasn't (__g)shared These were fixed in dmd-2.042. I guess you are using an earlier version of the example. a bit OT sorry.. Rainer, did you give D2 static variables inside an DLL a try ? Are they thread local ? it looks like but I am not sure. In case that they are > another question is coming up > who cares about de- alloc. Guess I have to. You see me clueless.
Re: console output in dll doesn't work
These were fixed in dmd-2.042. I guess you are using an earlier version of the example. Indeed. Seems like I was still using dmd2.042beta or some mixture.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky Wrote: > "Walter Bright" wrote in message > news:hp087r$19l...@digitalmars.com... > > Nick Sabalausky wrote: > >> Alhough it wouldn't necessarily even need to be a full-fledged source > >> formatter. Just something to sanitize the whitespace between > >> start-of-line and anything non-whitespace would be a huge improvement > >> *and* be cross-language. > > > > I think that's a great idea. Yesterday, I wrote the following program and > > added it to the dmd makefile so that all checkins and installs run the > > source code through it first. I welcome improvements. The current version > > replaces tabs with spaces, and removes trailing whitespace. > > > > Sounds great. > > > If someone is ambitious, a full fletched D source code pretty printer > > would be valuable that anyone could use, and which all Phobos source code > > could be run through in order to enforce a common style. > > For bonus points, they could expose it as a library so editors and other > tools can make use of it without shuffling everything through command-line > params, stdout and the filesystem. > > Will it work with multiline strings? char[] s = r""" I am very wide string""";
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
"Walter Bright" wrote in message news:hp087r$19l...@digitalmars.com... > Nick Sabalausky wrote: >> Alhough it wouldn't necessarily even need to be a full-fledged source >> formatter. Just something to sanitize the whitespace between >> start-of-line and anything non-whitespace would be a huge improvement >> *and* be cross-language. > > I think that's a great idea. Yesterday, I wrote the following program and > added it to the dmd makefile so that all checkins and installs run the > source code through it first. I welcome improvements. The current version > replaces tabs with spaces, and removes trailing whitespace. > Sounds great. > If someone is ambitious, a full fletched D source code pretty printer > would be valuable that anyone could use, and which all Phobos source code > could be run through in order to enforce a common style. For bonus points, they could expose it as a library so editors and other tools can make use of it without shuffling everything through command-line params, stdout and the filesystem.
Re: It is impossible to debug code compiled with dmd
On 31/03/10 19:31, Matthias Pleh wrote: Having played with the testcase you sent me, it isn't another bug. You were using -g instead of -gc, which won't work until debuggers support the D extensions to debug info. When using -gc it gives the error as reported in bug #3987, so it should work when that is fixed. Does this mean, the -g option only works in compination with the ddbg debugger and all other debugger need the -gc option? I need this to set a defaultsetting in codeblocks! Having never used ddbg I can't say if it supports -g or not (although it looks like it should). But yes, as far as I'm aware, all other debuggers need -gc to be used, unless they have had D support written for them (even gdb with the D patches doesn't support -g).
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
"Walter Bright" wrote in message news:hp08a9$19l...@digitalmars.com... > Nick Sabalausky wrote: >> And here's an even crazier idea: Some sort of well-thought-out UCF format >> (Unicode Code Format) that is like plain-text, but includes a standard >> metadata header (typically hidden while editing) that can help sort all >> this stuff out, and maybe other things as well. Obviously it would >> require special support from compilers and editors, but if it was >> well-designed (including discouragement of proprietary extensions - don't >> want a repeat of HTML) then I think it would be worth trying to push. > > Sorry, but anything that requires D users to use a custom editor for a > special source code file format is doomed to failure. I was thinking of it as whole-programming-world kind of thing not specific to any langauge, kind of like how UTF has been replacing ASCII and code pages (although this would use UTF). Basically kind of like a programmer's RTF (although it obviously wouldn't involve setting fonts and colors, but rather things like tab settings). I agree that getting it to actually happen would be an uphill battle (especially if there's no large organization backing it :( ), but it could be worth the potential benefits if it were to happen.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky wrote: And here's an even crazier idea: Some sort of well-thought-out UCF format (Unicode Code Format) that is like plain-text, but includes a standard metadata header (typically hidden while editing) that can help sort all this stuff out, and maybe other things as well. Obviously it would require special support from compilers and editors, but if it was well-designed (including discouragement of proprietary extensions - don't want a repeat of HTML) then I think it would be worth trying to push. Sorry, but anything that requires D users to use a custom editor for a special source code file format is doomed to failure.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky wrote:
Alhough it wouldn't necessarily even need to be a full-fledged source
formatter. Just something to sanitize the whitespace between start-of-line
and anything non-whitespace would be a huge improvement *and* be
cross-language.
I think that's a great idea. Yesterday, I wrote the following program and added
it to the dmd makefile so that all checkins and installs run the source code
through it first. I welcome improvements. The current version replaces tabs with
spaces, and removes trailing whitespace.
If someone is ambitious, a full fletched D source code pretty printer would be
valuable that anyone could use, and which all Phobos source code could be run
through in order to enforce a common style.
/* Replace tabs with spaces, and remove trailing whitespace from lines.
*/
import std.file;
import std.path;
int main(string[] args)
{
foreach (f; args[1 .. $])
{
auto input = cast(char[]) std.file.read(f);
auto output = filter(input);
if (output != input)
std.file.write(f, output);
}
return 0;
}
char[] filter(char[] input)
{
char[] output;
size_t j;
int column;
for (size_t i = 0; i < input.length; i++)
{
auto c = input[i];
switch (c)
{
case '\t':
while ((column & 7) != 7)
{ output ~= ' ';
j++;
column++;
}
c = ' ';
column++;
break;
case '\r':
case '\n':
while (j && output[j - 1] == ' ')
j--;
output = output[0 .. j];
column = 0;
break;
default:
column++;
break;
}
output ~= c;
j++;
}
while (j && output[j - 1] == ' ')
j--;
return output[0 .. j];
}
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Bane wrote: > Would something like tidyMyHorribleDcode be a solution? > Put a conf file in source somewhere which states how many > tabs/spaces/whatever. > Before you comit code back to shared repository you run tidy to convert code > to D spe format. > > When you checkout code from repo you run tidy with your custom settings. > > A great & simple solution for trivial problem not worth talking about it. > Uncrustify already claims to support D: http://uncrustify.sourceforge.net/ Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: console output in dll doesn't work
Trass3r wrote: What was the fix? The example in samples/d/mydll compiles fine and looks very much the same. Note that I'm talking about D2. 1. The path in build.bat is incorrect: is ..\..\..\bin\dmd instead of ...\..\..\windows\bin\dmd 2. printf isn't defined by default anymore. 3. The gc code etc in DllMain is for D1 I guess. I used code from http://www.digitalmars.com/d/2.0/dll.html instead. 4. HINSTANCE g_hInst; wasn't (__g)shared These were fixed in dmd-2.042. I guess you are using an earlier version of the example.
Re: console output in dll doesn't work
What was the fix? The example in samples/d/mydll compiles fine and looks very much the same. Note that I'm talking about D2. 1. The path in build.bat is incorrect: is ..\..\..\bin\dmd instead of ..\..\..\windows\bin\dmd 2. printf isn't defined by default anymore. 3. The gc code etc in DllMain is for D1 I guess. I used code from http://www.digitalmars.com/d/2.0/dll.html instead. 4. HINSTANCE g_hInst; wasn't (__g)shared In contrast to printf the std.stdio.write functions seem to buffer the output. When the DLL is unloaded, console output is already closed by the application. Two possible solutions: 1. call stdout.flush() after writing doesn't fix it. 2. set std.c.stdio._fcloseallp = null; before terminating the exe, but expect scrumbled output from the DLL and the exe fixes it. need to find out why.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
> And here's an even crazier idea: Some sort of well-thought-out UCF format > (Unicode Code Format) that is like plain-text, but includes a standard > metadata header (typically hidden while editing) that can help sort all this > stuff out, and maybe other things as well. Obviously it would require > special support from compilers and editors, but if it was well-designed > (including discouragement of proprietary extensions - don't want a repeat of > HTML) then I think it would be worth trying to push. Sounds complicated and error prone. I still have problems with notepad and his habit of killing utf-8 files and inserting bunch of where all the nice chars were. Makes me want to kill somebody.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
> It would be a start. Used by itself it would be a bit of a hassle, but > having it hooked up to auto-run upon checkout/commit or upon save/load in > the editor (this would ideally be better since you can double-check the > reults before committing) would be pretty much what I already had in mind as > a solution. My thinking the same. > > Alhough it wouldn't necessarily even need to be a full-fledged source > formatter. Just something to sanitize the whitespace between start-of-line > and anything non-whitespace would be a huge improvement *and* be > cross-language. > Only thing to be taken into special consideration are multi line strings. Sanitizing them would produce errors. Some kind of lexer or advanced regexpr match might be required. >
Re: console output in dll doesn't work
Trass3r wrote:
I tried the simple(st) official dll example (which I fixed slightly to
compile; using the dll_helper module etc)
What was the fix? The example in samples/d/mydll compiles fine and looks
very much the same.
export void dllprint() { write("hello dll world\n"); }
The code is executed (I checked with a debugger) but nothing is printed
in the console window.
In contrast to printf the std.stdio.write functions seem to buffer the
output. When the DLL is unloaded, console output is already closed by
the application.
Two possible solutions:
1. call stdout.flush() after writing
2. set std.c.stdio._fcloseallp = null; before terminating the exe, but
expect scrumbled output from the DLL and the exe
Re: It is impossible to debug code compiled with dmd
Am 31.03.2010 20:16, schrieb Robert Clipsham: On 31/03/10 16:09, Robert Clipsham wrote: On 31/03/10 10:41, Eldar Insafutdinov wrote: On Linux dmd outputs faulty debug info. There are several bugs in the debug info on linux, one of them I've fixed (for most cases ie. anything that requires phobos, I'm working on the other cases ie. anything that needs funky libraries that use a lot of complicated function pointers), and another one you've sent me a massive test case for which I'm working down to a manageable size for a bug report now (I'd have done it by now, your make file doesn't play nicely with my multilib system though ;)). Other than those 2 bugs I don't know what else is blocking debug info on linux... I'm becoming quite familiar with DWARF/dmd's backend code for DWARF through all this debugging, so if I can get these bugs fixed I'd be happy to work on any others while I have time. Having played with the testcase you sent me, it isn't another bug. You were using -g instead of -gc, which won't work until debuggers support the D extensions to debug info. When using -gc it gives the error as reported in bug #3987, so it should work when that is fixed. Does this mean, the -g option only works in compination with the ddbg debugger and all other debugger need the -gc option? I need this to set a defaultsetting in codeblocks!
Re: It is impossible to debug code compiled with dmd
On 31/03/10 16:09, Robert Clipsham wrote: On 31/03/10 10:41, Eldar Insafutdinov wrote: On Linux dmd outputs faulty debug info. There are several bugs in the debug info on linux, one of them I've fixed (for most cases ie. anything that requires phobos, I'm working on the other cases ie. anything that needs funky libraries that use a lot of complicated function pointers), and another one you've sent me a massive test case for which I'm working down to a manageable size for a bug report now (I'd have done it by now, your make file doesn't play nicely with my multilib system though ;)). Other than those 2 bugs I don't know what else is blocking debug info on linux... I'm becoming quite familiar with DWARF/dmd's backend code for DWARF through all this debugging, so if I can get these bugs fixed I'd be happy to work on any others while I have time. Having played with the testcase you sent me, it isn't another bug. You were using -g instead of -gc, which won't work until debuggers support the D extensions to debug info. When using -gc it gives the error as reported in bug #3987, so it should work when that is fixed.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
"Nick Sabalausky" wrote in message news:hp022i$t1...@digitalmars.com... > "Bane" wrote in message > news:hovb6n$13s...@digitalmars.com... >> Would something like tidyMyHorribleDcode be a solution? >> Put a conf file in source somewhere which states how many >> tabs/spaces/whatever. >> Before you comit code back to shared repository you run tidy to convert >> code to D spe format. >> >> When you checkout code from repo you run tidy with your custom settings. >> >> A great & simple solution for trivial problem not worth talking about it. >> > > It would be a start. Used by itself it would be a bit of a hassle, but > having it hooked up to auto-run upon checkout/commit or upon save/load in > the editor (this would ideally be better since you can double-check the > reults before committing) would be pretty much what I already had in mind > as a solution. > > Alhough it wouldn't necessarily even need to be a full-fledged source > formatter. Just something to sanitize the whitespace between start-of-line > and anything non-whitespace would be a huge improvement *and* be > cross-language. And here's an even crazier idea: Some sort of well-thought-out UCF format (Unicode Code Format) that is like plain-text, but includes a standard metadata header (typically hidden while editing) that can help sort all this stuff out, and maybe other things as well. Obviously it would require special support from compilers and editors, but if it was well-designed (including discouragement of proprietary extensions - don't want a repeat of HTML) then I think it would be worth trying to push.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
"Bane" wrote in message news:hovb6n$13s...@digitalmars.com... > Would something like tidyMyHorribleDcode be a solution? > Put a conf file in source somewhere which states how many > tabs/spaces/whatever. > Before you comit code back to shared repository you run tidy to convert > code to D spe format. > > When you checkout code from repo you run tidy with your custom settings. > > A great & simple solution for trivial problem not worth talking about it. > It would be a start. Used by itself it would be a bit of a hassle, but having it hooked up to auto-run upon checkout/commit or upon save/load in the editor (this would ideally be better since you can double-check the reults before committing) would be pretty much what I already had in mind as a solution. Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language.
Re: Fatal flaw in D design which is holding back widespread adoption
Jacob Carlborg wrote: > On 3/31/10 03:53, Nick Sabalausky wrote: >> "Steven Schveighoffer" wrote in message >> news:op.vaefb7p3eav...@localhost.localdomain... >>> On Tue, 30 Mar 2010 16:56:32 -0400, Walter Bright >>> wrote: >>> BTW, type a file to a console window. Tabs come out as 8 characters, on Windows, Linux, and OSX. >>> >>> So do 8 spaces. This is the surest way to make code easily >>> viewable/editable anywhere. Just set the "expand tabs" option on your >>> favorite editor. >>> >>> My recommendation is to say indentations are 4 spaces and tabs should not >>> be used for indentation. >>> >> >> I've always found using spaces for indentation to make editing a real >> PITA. (Why woudn't I rather be able to move in/out one level of >> indentation with one arrow-key press instead of 4 (or so) ?) >> >> But really, I don't see why the whole issue hasn't already been made 100% >> personal style by a VCS that handles it the same way SVN handles EOLs. If >> one person has problems involving another person using a different >> indentation system, then at least one of them is doing something very >> wrong. Seriously, how is it that this is 2010, we have things like syntax >> highlighting as standard featutres in every editor that anyone ever >> actually uses...and yet the whole world of programmers still can't >> abstract away something as simple as f*cking tab sizes? Bah! > > Eclipse with descent can reformat the files to your own personal > preferences. vote++ The descent reformatter is crazy, no matter how funky your style is the chances are pretty good you can autoformat all that pesky code written by others :) Not to mention you can use it as a tool to save time formatting yourself. I would perhaps even pay for it as a standalone utility /salestalk>
Re: Fatal flaw in D design which is holding back widespread adoption
Nick Sabalausky wrote: "Walter Bright" wrote in message news:houh5g$29c...@digitalmars.com... Nick Sabalausky wrote: But really, I don't see why the whole issue hasn't already been made 100% personal style by a VCS that handles it the same way SVN handles EOLs. If one person has problems involving another person using a different indentation system, then at least one of them is doing something very wrong. Seriously, how is it that this is 2010, we have things like syntax highlighting as standard featutres in every editor that anyone ever actually uses...and yet the whole world of programmers still can't abstract away something as simple as f*cking tab sizes? Bah! It all started in the 80's when someone wrote a text editor that had customizable tab lengths (before then, tabs were 8. End of story.). Things went downhill from there. Since there's no way for an editor to figure out what the tab setting might be for any particular file, the only solution that works is to not use tabs. Thanks to some nameless programmer who ruined it for everyone . See, I think this is looking at things completely backwards: "...there's no way for an editor to figure out what the tab setting might be for any particular file...". My strategy for saving time: stop reading a post as soon as I detect it's even remotely pro-tabs. Andrei
console output in dll doesn't work
I tried the simple(st) official dll example (which I fixed slightly to
compile; using the dll_helper module etc)
export void dllprint() { write("hello dll world\n"); }
The code is executed (I checked with a debugger) but nothing is printed in
the console window.
Re: It is impossible to debug code compiled with dmd
On 31-mar-10, at 17:09, Robert Clipsham wrote: On 31/03/10 10:41, Eldar Insafutdinov wrote: On Linux dmd outputs faulty debug info. There are several bugs in the debug info on linux, one of them I've fixed (for most cases ie. anything that requires phobos, I'm working on the other cases ie. anything that needs funky libraries that use a lot of complicated function pointers), and another one you've sent me a massive test case for which I'm working down to a manageable size for a bug report now (I'd have done it by now, your make file doesn't play nicely with my multilib system though ;)). Other than those 2 bugs I don't know what else is blocking debug info on linux... I'm becoming quite familiar with DWARF/dmd's backend code for DWARF through all this debugging, so if I can get these bugs fixed I'd be happy to work on any others while I have time. On Windows optlink crashes when building code in debug. Current situation is a complete disaster. OPTLINK still has problems, hopefully this situation will improve as it gradually gets ported to C and eventually open sourced (or at least we can hope that happens ;)). If not I guess we need to either write a new linker, or a new backend for dmd so it can output COFF and use another linker. a new backend like gcc (of gdc) or even better llvm (ldc)? for linux that was already done, and for D 1.0 it works well (I am using linux x86_64). and debugging normally works, even tango's stacktrace... windows is indeed a different story (but I know some people use gdc). Hopefully we can sort this situation out and get debug info for D on a par with C/C++ :)
Re: It is impossible to debug code compiled with dmd
On 31/03/10 10:41, Eldar Insafutdinov wrote: On Linux dmd outputs faulty debug info. There are several bugs in the debug info on linux, one of them I've fixed (for most cases ie. anything that requires phobos, I'm working on the other cases ie. anything that needs funky libraries that use a lot of complicated function pointers), and another one you've sent me a massive test case for which I'm working down to a manageable size for a bug report now (I'd have done it by now, your make file doesn't play nicely with my multilib system though ;)). Other than those 2 bugs I don't know what else is blocking debug info on linux... I'm becoming quite familiar with DWARF/dmd's backend code for DWARF through all this debugging, so if I can get these bugs fixed I'd be happy to work on any others while I have time. On Windows optlink crashes when building code in debug. Current situation is a complete disaster. OPTLINK still has problems, hopefully this situation will improve as it gradually gets ported to C and eventually open sourced (or at least we can hope that happens ;)). If not I guess we need to either write a new linker, or a new backend for dmd so it can output COFF and use another linker. Hopefully we can sort this situation out and get debug info for D on a par with C/C++ :)
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Jesse Phillips Wrote: > Bane wrote: > > > Would something like tidyMyHorribleDcode be a solution? > > Put a conf file in source somewhere which states how many > > tabs/spaces/whatever. > > Before you comit code back to shared repository you run tidy to convert > > code to D spe format. > > > > When you checkout code from repo you run tidy with your custom settings. > > > > A great & simple solution for trivial problem not worth talking about it. > > So, something like indent or bcpp for Linux? > > http://indent.isidore-it.eu/beautify.html > > http://www.faqs.org/docs/Linux-HOWTO/C-C++Beautifier-HOWTO.html Nah, they are unworthy. Not written in D.
Re: DSpec / Templates + Delegates
On 31-mar-10, at 16:33, bearophile wrote: Fawzi Mohamed: It is a randomized unittest framework. It seems similar to the famous: http://en.wikipedia.org/wiki/QuickCheck indeed (as I say in the doc) it was inspired by it, it is a bit different as it supports also non random (i.e. combinatorial) tests (which makes it possible to integrate "normal" tests more easily), and one can also use mixins to change the generators (but I found mixins unnecessary in retrospect). I liked it much when programming in haskell... Later people have built similar automatic testing systems for Python, Java, etc. The idea is nice, but they get created and used in OO languages only when a traditional unit test system is already in place. So maybe this is why it has had no success so far in D. Well I use it, and am happy with it (I suppose because I prefer writing functions than testcases), but it seems that it is not something other D programmer know/enjoy/want much :).
go and defer implementation in Go
Found through Reddit, maybe this is interesting for Walter, the implementation of "go" and "defer" () in Go language: http://research.swtch.com/2010/03/broken-abstractions-in-go.html A comment by jerf on Reddit: >It isn't "breaking" function calling abstractions, it's using different ones.< Bye, bearophile
Re: Enum arguments?
well you can always use Varargs...
void convolve(int n,mask...)(...)
Fawzi
On 31-mar-10, at 13:28, bearophile wrote:
Max Samukha:
Actually, they are allowed via an additional alias:<
This doesn't compile:
void convolve(float[N][M] mask, N, M)(float[][] a, float[][] b) {
//...
}
void main() {
float[][] outmat = [[0.0]];
enum float[1][2] mask = [[1.0],[1.0]];
convolve!mask([[1.0, 1.0]], outmat);
}
You have to use an alias plus static asserts:
void convolve(alias mask)(float[][] a, float[][] b) {
static assert(__traits(isStaticArray, typeof(mask)));
static assert(__traits(isStaticArray, typeof(mask[0])));
//...
}
void main() {
float[][] outmat = [[0.0]];
enum float[1][2] mask = [[1.0],[1.0]];
convolve!mask([[1.0, 1.0]], outmat);
}
While with an array of dchar (4 bytes each) compiles:
void foo(immutable(dchar)[] s)() {}
void main() {
immutable(dchar)[] s1 = "Hello"d;
foo!(s1)();
}
So I'd like arrays too to be allowd as template parameters.
(The other thing I've asked in that post (the enum argument type for
functions) I've seen is similar to the "static" arguments in the
"The future of D", that I think was tried and abandoned because too
much hard to implement. So it's probably an useless request, sorry.)
Bye,
bearophile
Re: DSpec / Templates + Delegates
Fawzi Mohamed: > It is a randomized unittest framework. It seems similar to the famous: http://en.wikipedia.org/wiki/QuickCheck Later people have built similar automatic testing systems for Python, Java, etc. The idea is nice, but they get created and used in OO languages only when a traditional unit test system is already in place. So maybe this is why it has had no success so far in D. Bye, bearophile
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Bane wrote: > Would something like tidyMyHorribleDcode be a solution? > Put a conf file in source somewhere which states how many > tabs/spaces/whatever. > Before you comit code back to shared repository you run tidy to convert code > to D spe format. > > When you checkout code from repo you run tidy with your custom settings. > > A great & simple solution for trivial problem not worth talking about it. So, something like indent or bcpp for Linux? http://indent.isidore-it.eu/beautify.html http://www.faqs.org/docs/Linux-HOWTO/C-C++Beautifier-HOWTO.html
Re: DSpec / Templates + Delegates
As unittesting came up again I will use the occasion to pump up again
blip.rtest ;).
It is a randomized unittest framework.
see
http://petermodzelewski.blogspot.com/2009/02/tango-conference-2008-rolling-dice.html
The basic idea is to make writing testing functions easy: you write
things that generate inputs for your testing functions (for example
file path, random strings, matrix/vector,...)
To add a structure or a class it is enough to implement
static MyType randomGenerate(Rand r)
or
static MyType randomGenerate(Rand r,ref bool acceptable)
or (if you have also a combinatorial, non random part)
static MyType randomGenerate(Rand r,int idx, ref int nEl, ref
bool acceptable)
For many types you already have predefined generators.
Then you write testing functions that use these arguments:
void myTestFunction(MyType arg1,int arg2,...){ ...}
and create test collections using autoInitTst.testNoFail,
autoInitTst.testFail, autoInitTst.testTrue, autoInitTst.testFalse (if
you have delegates, or the version with F at the end if you have
functions).
TestCollection myTests(TestCollection superColl=null){
TestCollection coll=new TestCollection("myCollection",
__LINE__,__FILE__,superColl);
autoInitTst.testNoFailF("myTest",
&myTestFunction,__LINE__,__FILE__,coll);
...
return coll;
}
and finally small tests can be run in a unittest setup, but for
something more serious run them with something like
import blip.rtest.RTest;
import dchem.test.AllTests: allTests;
import tango.math.random.Random;
import blip.io.Console;
version(NoTrace){} else { import
tango.core.stacktrace.TraceExceptions; import blip.util.TraceAll; }
void main(char[][] args){
serr(rand.toString());
serr("\n");
mainTestFun(args,allTests!()());
}
and this will call the function several times with automatically
generated inputs.
If a function has no arguments it is called just once, if it has only
combinatorial arguments then it is not called more often than it should.
Different tests run in parallel taking advantage of all the cpus you
have,and clearly you can write templatized testing functions.
Blip by default wants blas, lapack and hwlock libraries, but you can
compile it without using
-version=noHwlock -version=noBlas -version=noLapack
The parallel version stresses a little the thread/fibers and needs a
patched version of tango (with the latest reorganizations some bugs
crept back, so I use an old version by default, but I hope to submit
the patches for trunk soon). Sequential execution can be forced with -
version=SequentialWorkManager
Personally for serious tests I like to recreate the same structure as
the module structure, so that x.y.Z has its tests in x.test.y.ZTests ,
y will contain a collection called YTests that collects all the tests
of the modules in the package Y and finally all tests are collected in
the AllTests module.
These functions can even be templates, so that the compilation of the
library without tests is fast (my NArray tests are quite extensive and
need a bit to compile.
Then outside the library you have a test runner.
The test runner has command flags to initialize it with special values
(to reproduce a failure), or to ask the execution of a single test or
subsets.
Fawzi
Re: Enum arguments?
> void convolve(float[N][M] mask, N, M)(float[][] a, float[][] b) {
That's quite wrong anyway. This looks a bit better:
void convolve(float[N][M] mask)(float[][] a, float[][] b) {
> You have to use an alias plus static asserts:
Or better a template constraint:
void convolve(alias mask)(float[][] a, float[][] b) if
(__traits(isStaticArray, typeof(mask)) && __traits(isStaticArray,
typeof(mask[0]))) {
//...
}
Bye,
bearophile
Re: Enum arguments?
Max Samukha:
>Actually, they are allowed via an additional alias:<
This doesn't compile:
void convolve(float[N][M] mask, N, M)(float[][] a, float[][] b) {
//...
}
void main() {
float[][] outmat = [[0.0]];
enum float[1][2] mask = [[1.0],[1.0]];
convolve!mask([[1.0, 1.0]], outmat);
}
You have to use an alias plus static asserts:
void convolve(alias mask)(float[][] a, float[][] b) {
static assert(__traits(isStaticArray, typeof(mask)));
static assert(__traits(isStaticArray, typeof(mask[0])));
//...
}
void main() {
float[][] outmat = [[0.0]];
enum float[1][2] mask = [[1.0],[1.0]];
convolve!mask([[1.0, 1.0]], outmat);
}
While with an array of dchar (4 bytes each) compiles:
void foo(immutable(dchar)[] s)() {}
void main() {
immutable(dchar)[] s1 = "Hello"d;
foo!(s1)();
}
So I'd like arrays too to be allowd as template parameters.
(The other thing I've asked in that post (the enum argument type for functions)
I've seen is similar to the "static" arguments in the "The future of D", that I
think was tried and abandoned because too much hard to implement. So it's
probably an useless request, sorry.)
Bye,
bearophile
Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Would something like tidyMyHorribleDcode be a solution? Put a conf file in source somewhere which states how many tabs/spaces/whatever. Before you comit code back to shared repository you run tidy to convert code to D spe format. When you checkout code from repo you run tidy with your custom settings. A great & simple solution for trivial problem not worth talking about it.
Re: Fatal flaw in D design which is holding back widespread adoption
"Walter Bright" wrote in message news:houstg$44...@digitalmars.com... > Nick Sabalausky wrote: >> There's absolutely no need whatsoever for any kind of magical "figure out >> the tab-size for a file". Everyone can have everything the way *they* >> want it without screwing up anything for anyone else all by the >> convention of treating tab as *the* "indent" symbol. (Note that this *is* >> very different from the "everyone will get along if they just think like >> I do" argument pattern.) > > That would work for indent, but nothing else (such as tabbing over to the > comment column). I was only talking about indent. The rest should just be spaces.
dmd changesets: 422, 427, 428
I don't know if there is a better place to comment or ask questions about dmd/Phobos changesets. If I don't find a better place I will post here my future comments about the changesets. dmd changeset 422: http://dsource.org/projects/dmd/changeset/422 Very good, I think I have asked for this change in one of my first posts in this newsgroup :-) -- dmd changeset 427: Is this error given in the case of a single-module program that has file name different from its module statement? -- dmd changeset 428: It fixes half of this (not mine) bug report (sorry for being unpolite: Walter has balls): http://d.puremagic.com/issues/show_bug.cgi?id=4008 The other half too of that bug report can be followed, renaming file suffixes to something better for C++ code, like "cpp". Bye, bearophile
Re: Enum arguments?
On 31.03.2010 3:04, bearophile wrote:
as compile-time arguments both floating point values and strings of 8,16,32
bit chars, but I don't know why arrays are not allowed
Actually, they are allowed via an additional alias:
void main() {
float[][] outmat = [[0.0]];
enum float[][] mask = [[0.0]];
convolve!mask([[1.0, 1.0]], outmat);
}
Re: DSpec / Templates + Delegates
bearophile:
I think that follows the type-II solution (the worst one) I have explained here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=107997
(Thank you for your code and work, the worst solution is often better than no
solution.)
I enjoyed reading your article and i agree with you about the current
Unittest-situation. If i remember my time working with other Unittesting
Frameworks in other languages, i was always annoyed in the beginning to
find out how to setup the tests and especially it's test execution.
Often it was more comfortable to rely on some buildsystems, which
already configured an automatic way. Though i doesn't like it to be
depending on a specific buildsystem.
Walters approach to implement unittests into the compiler, is also in my
opinion the most user-friendly way for developers to run unittest and
avoids the annoying and time-consuming configuration management. (Though
the D language give a great help to locate specific classes thanks to
ModuleInfo struct and makes it eas implementing a testrunner in compare
of other programming languages)
Thanks to the article i decided to move the dspec execution into the
unittest environment (it's also already working now) in hope to make the
configuration and test execution more simpler. I also agree that
developers shouldn't waste much time in the setup and API of a
unittesting framework, because it's only a tool for development.
Unfortanetly, i don't know a way to get commandline arguments which
would offers to configure a unittest framework. I can indeed catch the
arguments in the main function, but the unittest code is already
executed before the main function will be invoked. A trivial workaround
could be probably using a configuration file, which can be located and
accessed by dspec framework.
Masahiro Nakagawa:
I read sources. I have something on my chest.
- ruun package
Umm...need?
It's surely not needed :) I already moved all modules to a simple dspec
package.
- import ruun.dspec.Spec; import ruun.dspec.Should;
I think ruun.dspec.Spec should uses "public import" for Should module.
Is there a case that spec empties in it! ?
I know other unittest frameworks, that offers different implementation
for assertions / expectations and the developer can chose one.
But setting Should.d to a public import would offer a standard
implementation that is always accessible. Of course, this is a good idea.
- Spec methods
Why final? How can I create custom Spec?
Is not needed anymore, because the Spec class is removed and the spec
methods are moved to a single module now in order to get executed in a
dmd unittest environment. (Though it won't also offer creating custom
Specs).
Thank you very much for your code review.
If someone want to test dspec, be warned the buildscript (Rakefile) can
maybe fail on Linux or Mac. I haven't test it yet on that
plattforms.
Jacob Carlborg:
int[] array = [1, 2, 3, 4];
int b = 10;
array.each in (int item) {
writefln("%d", item + b);
};
You are right :) I like it very much.
Chris Mueller
--
ruu...@googlemail.com
http://ruuns.de/blog/
Re: Fatal flaw in D design which is holding back widespread adoption
"bearophile" schrieb im Newsbeitrag news:hov7j7$sv...@digitalmars.com... > Bane: >> I wonder do Python folks have same problems. > > In Python3+ if you mix tabs and spaces to indent code, the "interpreter" > raises a parsing error. So you are forced to use only tabs or only spaces > to indent code. Only really newbies mix tabs and spaces in Python 2.x > code. > > And the Python coding standards (PEP8, > http://www.python.org/dev/peps/pep-0008/ ) says: > "Use 4 spaces per indentation level." > And all a little serious Python programmers follow it. > > Bye, > bearophile And the D dstyle doc (http://www.digitalmars.com/d/2.0/dstyle.html) says: "Each indentation level will be four columns" and "Using spaces instead of tabs is preferred" And all a little serious D programmers follow it. Bye, nocide
Re: Fatal flaw in D design which is holding back widespread adoption
Bane: > I wonder do Python folks have same problems. In Python3+ if you mix tabs and spaces to indent code, the "interpreter" raises a parsing error. So you are forced to use only tabs or only spaces to indent code. Only really newbies mix tabs and spaces in Python 2.x code. And the Python coding standards (PEP8, http://www.python.org/dev/peps/pep-0008/ ) says: "Use 4 spaces per indentation level." And all a little serious Python programmers follow it. Bye, bearophile
It is impossible to debug code compiled with dmd
On Linux dmd outputs faulty debug info. On Windows optlink crashes when building code in debug. Current situation is a complete disaster.
Re: Fatal flaw in D design which is holding back widespread adoption
On 3/31/10 03:53, Nick Sabalausky wrote: "Steven Schveighoffer" wrote in message news:op.vaefb7p3eav...@localhost.localdomain... On Tue, 30 Mar 2010 16:56:32 -0400, Walter Bright wrote: BTW, type a file to a console window. Tabs come out as 8 characters, on Windows, Linux, and OSX. So do 8 spaces. This is the surest way to make code easily viewable/editable anywhere. Just set the "expand tabs" option on your favorite editor. My recommendation is to say indentations are 4 spaces and tabs should not be used for indentation. I've always found using spaces for indentation to make editing a real PITA. (Why woudn't I rather be able to move in/out one level of indentation with one arrow-key press instead of 4 (or so) ?) But really, I don't see why the whole issue hasn't already been made 100% personal style by a VCS that handles it the same way SVN handles EOLs. If one person has problems involving another person using a different indentation system, then at least one of them is doing something very wrong. Seriously, how is it that this is 2010, we have things like syntax highlighting as standard featutres in every editor that anyone ever actually uses...and yet the whole world of programmers still can't abstract away something as simple as f*cking tab sizes? Bah! Eclipse with descent can reformat the files to your own personal preferences.
Re: Fatal flaw in D design which is holding back widespread adoption
Tabs versus Spaces: An Eternal Holy War. http://www.jwz.org/doc/tabs-vs-spaces.html :)
Re: Fatal flaw in D design which is holding back widespread adoption
I wonder do Python folks have same problems.
Re: Fatal flaw in D design which is holding back widespread adoption
Nick Sabalausky wrote: There's absolutely no need whatsoever for any kind of magical "figure out the tab-size for a file". Everyone can have everything the way *they* want it without screwing up anything for anyone else all by the convention of treating tab as *the* "indent" symbol. (Note that this *is* very different from the "everyone will get along if they just think like I do" argument pattern.) That would work for indent, but nothing else (such as tabbing over to the comment column).
