Re: version and configuration
On Saturday, 12 September 2015 at 14:41:45 UTC, Spacen Jasset It appears that I can't put this in a module and import it elsewhere to test the version specifications as they are all in their own namespaces. Is this then a dead end for having a feature configuration file? Correct, version doesn't get imported. You're better off using enums or ordinary variables.
Re: Mixin templates accessing mixed out scope
On Saturday, 12 September 2015 at 17:11:04 UTC, anonymous wrote: On Saturday 12 September 2015 16:30, Ali Çehreli wrote: Reduced: [...] Error: type SingleStore is not an expression Reduced further: class MyStore { class SingleStore { static void New() // Removing 'static' compiles { new SingleStore(); } } } And now the problem can be spotted: SingleStore is a nested class. That means, instances of it are bound to MyStore instances. But New is static, so it doesn't have a MyStore to which it could attach the `new SingleStore`. That error message is pretty awful. I filed an issue: https://issues.dlang.org/show_bug.cgi?id=15049 like most D errors ;/ it's the #1 problem I'm struggling with in D. Remember there's another error with remove, that isn't releated to SingleStore. As for a fix: I guess SingleStore isn't supposed to be a nested class. Mark it static then. NO! That is the whole point! SingleStore is a momento that wraps the key value pair, e.g., auto t = DeleteStore.New("mycooldelegate", (int x) { return true; }); t is suppose to be a single store. then t.Remove(); removes the delegate from the store. Note I don't have to know the actual key or delegate!! Which is the whole point! Else it would lool like this: store[][string] mydelegatestore; auto dg = (int x) { return true; }; mydelegatestore["mycooldelegate"] ~= dg; then mydelegatestore["mycooldelegate"].remove(d => dg == d); which requires remembering both the key and the delegate, which makes using inline lambdas infeasible(because you'll never be able to remove them). I see no reason why SingleStore has to be static. The mixin template should insert all that stuff into the class, which, by the way, works... I've also used that New pattern all that time and it works, maybe not for nested classes. Moving SingleStore outside the template works. I've fixed the issue with that, it's not as pretty but works. Still have the remove error: import std.stdio; import std.concurrency; extern (C) int getch(); import std.string; import std.concurrency; import core.time; import core.thread; import std.container.array; import std.typecons; public class SingleStore(TKey, TValue) { public TValue Value; public TKey Key; public TValue[][TKey] Store; public auto Remove() { import std.algorithm; remove!(c => Value == c")(Store[this.Key], SwapStrategy.unstable); // Not working, can't disambiguate } public static auto New(TKey k, TValue v, ref TValue[][TKey] s) { auto o = new SingleStore!(TKey, TValue)(k, v); o.Store = s; return o; } private this(TKey k, TValue v) { Key = k; Value = v; } } public mixin template ObjectStore(TKey, TValue) { public static TValue[][TKey] store; public static auto New(TKey k, TValue v) { (store[k]) ~= v; auto o = SingleStore!(TKey, TValue).New(k, v, store); o.store = store; return o; } } class MyStore { mixin ObjectStore!(string, bool delegate(int)); } void main() { auto s = MyStore.New("x", (int x) { return true; }); // works, stores delegate in MyStore s.Remove(); // Doesn't work because std.algorithm's remove isn't working getch(); } (The whole point of nesting was so I wouldn't have to explicitly create a pointer to the store in SingleStore. Should have worked, probably another one of D's bugs)
Re: Floating point in the type system
On Saturday, 12 September 2015 at 19:02:16 UTC, Robert wrote: For what it's worth, I was investigating this initially as a discussion about adding type-level values in Rust, and how to handle unusual cases like this. C++ does not allow it. And frankly, having more than a single integer value type as a value parameter in C++ templates is a pointless PITA. I think Go got literal constant values right: make them untyped until bound.
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:54:09 UTC, Enamex wrote: On Saturday, 12 September 2015 at 20:40:35 UTC, Adam D. Ruppe wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: - code completion in IDE. It'will never work. Why not? I haven't actually tried it, but it seems like a pretty easy problem, except perhaps with complex templates. - noobs, code is unreadable. meh [...] With a dedicated syntax, specific functions/groups-of-functions could be easily recognized as extensions of a type and could even be made to be recognized by templates You've got the idea. IDE plugins can not decently provide completion based on the UFCS possibilities. With something like a type helper, it's more likely to work.
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On Saturday, 12 September 2015 at 14:26:10 UTC, Jacob Carlborg wrote: On 2015-09-12 03:23, Jonathan M Davis wrote: Though, now that I think about it, we should probably also put it in undead now. I think it can be put in undead as soon as something is deprecated or to-be-deprecated in the documentation. That's probably a good policy, but it hadn't occurred to me until we were discussing it here. - Jonathan M Davis
Re: Calling D from C, C++, Python…
On Saturday, 12 September 2015 at 09:47:55 UTC, Jacob Carlborg wrote: Well, if your D function doesn't use anything of the runtime I guess it's not necessary. Right. If you don't call into the threading system in the druntime, you should be ok. Keep in mind though that the GC uses the threads and the new expression, array literals, array append, and others use the GC. Runtime.initialize is also what calls static and module constructors... and might have responsibility for fixing up dynamic casting of class objects in a shared lib too, I'm not sure about that. But if you avoid the bulk of the runtime functions, indeed you can get away without initializing it. Just that null thread handle is likely to cause segfaults in places where you might not expect if you don't. It is best to initialize it. Lots of C libraries need an init an teardown call, so surely the Python interop provides some solution for it. idk what it would be though.
[Issue 12210] dlang.org home page example - Run button does not work
https://issues.dlang.org/show_bug.cgi?id=12210 Vladimir Panteleevchanged: What|Removed |Added Depends on||15051 --
[Issue 15051] New: Code that runs fine on dpaste.dzfl.pl refuses to run on dlang.org
https://issues.dlang.org/show_bug.cgi?id=15051 Issue ID: 15051 Summary: Code that runs fine on dpaste.dzfl.pl refuses to run on dlang.org Product: D Version: D2 Hardware: All URL: http://dpaste.dzfl.pl/81b0c9d09e3f OS: All Status: NEW Severity: normal Priority: P1 Component: dlang.org Assignee: nazriel6...@gmail.com Reporter: thecybersha...@gmail.com Blocks: 12210 E.g.: import std.regex; static reFloatingPoint = ctRegex!`[0-9]+\.[0-9]+`; void main() {} When run from dlang.org (click "Edit" under any example, paste code, click "Run"), it results in: Compilation output (255: Unknown signal 255) unable to fork: Cannot allocate memory However, it runs fine on dpaste.dzfl.pl. This is blocking e.g. the floating-point example on dlang.org. --
Re: Reasons to use D
On Saturday, 12 September 2015 at 18:48:52 UTC, Adam D. Ruppe wrote: On Saturday, 12 September 2015 at 18:44:44 UTC, Ola Fosheim Grøstad wrote: Arrayviews ("slices") are available as a type so you can do it like this: Yeah, there's also the Array.slice and String.substring that work kinda similarly in old standard javascript. Array.slice create value copies, not reference views. I don't think there is a "slice" for Array. :-/ But there's still a lot of type-specific verbiage in there, whereas with D, it is always the same [a .. $] for almost anything so it is one thing to remember instead of three or more. Yes. So, let's create a TypeScript like subset of:D. Compile GC-based D-JS -> JavaScript + TypeScript definitions. The problem is that you might need a little bit of Dependent Typing in order to provide types for the browser API. I.e. return type depending on parameter values? Not sure.
Rust style memory management
So I saw this video: https://air.mozilla.org/guaranteeing-memory-safety-in-rust/ and was amazed. Is there any way we can implement this in D? What language extensions would be required? My idea on implement this would be to add 3 new pointer (and array) types : [owned,shared immutable,borrow mutable] and depend on casting raw pointers to the new types. Thoughts?
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: - code completion in IDE. It'will never work. Why not? I haven't actually tried it, but it seems like a pretty easy problem, except perhaps with complex templates. - noobs, code is unreadable. meh
Re: shared array?
On Saturday, 12 September 2015 at 22:36:00 UTC, Laeeth Isharc wrote: Thank you for this. How large is the allocation for closure for a delegate? Just a pair of pointers? It depends on what the delegate needs to capture. It makes a copy of the local variables the function is referencing. (Usually pretty small I'd gamble; how big are your typical function's arguments and local vars?)
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: That's why I propose the new keywords 'helper' and 'subject' that will allow to extend the properties pre-defined for a type, as long as the helper is imported: --- module myhelper; helper for subject : string Do we really need a 3-keyword chain? What's wrong with a simple `helper : string` or `helper(string)`? { void writeln() { import std.stdio; writeln(subject); } } --- Why `subject` to refer to the string the function gets called on? What's wrong with good old `this`, which is used for this purpose everywhere else?
Re: shared array?
On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote: Using it at all is a problem because one doesn't know when and where. It is called when the collect function is called and where it was called from. D's garbage collector isn't magic, it is just a function that frees memory when the pool runs low. It's like playing Russian roulette. It doesn't matter if only 1/6 times will kill you. It's totally different than 0/6. The big difference is the garbage collector doesn't actually kill you. Memory corruption, use-after-free, and double-free bugs on the other hand often do terminate your process.
Re: Moving forward with work on the D language and foundation
On Friday, 28 August 2015 at 12:28:43 UTC, Russel Winder wrote: On Thu, 2015-08-27 at 16:01 +, BBasile via Digitalmars-d-announce wrote: […] That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome. I say "bollocks" to your accusation that Europeans post 50 are a bunch of useless idiots. I call double "bollocks" on the claim that only in the USA do people do anything. https://www.google.fr/maps/@51.4602279,-0.1695423,3a,68.5y,2.82h,52.97t/data=!3m6!1e1!3m4!1shQpIZlKwZL_k_IzgQSA-aw!2e0!7i13312!8i6656!6m1!1e1 I say that you could still sort your waste. Never mind the Bollocks.
Re: Reasons to use D
On Saturday, 12 September 2015 at 16:34:42 UTC, Meta wrote: Maybe because the static type system allows for overloading and so all of these utility functions don't have to do a million different things depending on what you pass to them. Yea. Another huge thing to me is the slice operator. I use it for a lot of stuff and it is consistent for strings and other arrays. (well, utf issues aside, but D's rule there is simple enough to remember too)
Re: Calling D from C, C++, Python…
On Saturday, 12 September 2015 at 18:20:37 UTC, Brad Roberts wrote: You can get away with it in some circumstances, but it's at your own risk. Yeah, I agree.
Re: I guess this is a bug?
On Saturday 12 September 2015 20:28, Random D user wrote: > prints (with option B): > bar: 0.00, 0.00 // BUG?? > baz: 1.00, 2.00 Looks like a bug to me. Please file an issue at https://issues.dlang.org/
Re: Reasons to use D
On Saturday, 12 September 2015 at 18:23:55 UTC, Adam D. Ruppe wrote: On Saturday, 12 September 2015 at 16:34:42 UTC, Meta wrote: Maybe because the static type system allows for overloading and so all of these utility functions don't have to do a million different things depending on what you pass to them. Yea. Another huge thing to me is the slice operator. I use it for a lot of stuff and it is consistent for strings and other arrays. (well, utf issues aside, but D's rule there is simple enough to remember too) Arrayviews ("slices") are available as a type so you can do it like this: a = new Uint32Array([7,2,3,6]) // a is [7, 2, 3, 6] b = a.subarray(1,3) // b reference [2, 3] b[0] = 8 // now a is [7, 8, 3, 6] a.set([5,9], 2) // now a is [7,8,5,9] Destructuring is coming too. So you can destructure arrays as if they are tuples. E.g.: var a,b; [a,b] = [2,4] [a,b] = [b,a] I think it might work in TypeScript or some of the other compilers already.
[Issue 15036] SimpleDllMain assumes various symbols are available unqualified
https://issues.dlang.org/show_bug.cgi?id=15036 Vladimir Panteleevchanged: What|Removed |Added Keywords||pull CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev --- https://github.com/D-Programming-Language/druntime/pull/1385 --
[Issue 15043] [e2ir] dmd still crashes when trying to set a delegate from __traits(getOverloads)
https://issues.dlang.org/show_bug.cgi?id=15043 bb.t...@gmx.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|nob...@puremagic.com|k.hara...@gmail.com --- Comment #2 from bb.t...@gmx.com --- he knows the topic. --
Re: Moving forward with work on the D language and foundation
On Saturday, 12 September 2015 at 22:28:49 UTC, BBasile wrote: On Friday, 28 August 2015 at 12:28:43 UTC, Russel Winder wrote: On Thu, 2015-08-27 at 16:01 +, BBasile via Digitalmars-d-announce wrote: […] That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome. I say "bollocks" to your accusation that Europeans post 50 are a bunch of useless idiots. I call double "bollocks" on the claim that only in the USA do people do anything. Never mind the bollocks. :handshake: https://www.youtube.com/watch?v=aKLpeNJ9zZo don't let your dishes just in front of your house.
Re: Rust style memory management
Try using the -dip25 switch to dmd, it does one more step in D toward making a borrow thingy. Nowhere near the level Rust does it, but combined with other library things like destructors, prohibiting copying, etc., it can kinda make a owned thing with borrowed bits.
[Issue 15049] New: bad error message when trying to instantiate a nested class in a static method
https://issues.dlang.org/show_bug.cgi?id=15049 Issue ID: 15049 Summary: bad error message when trying to instantiate a nested class in a static method Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: diagnostic Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: ag0ae...@gmail.com Found by Prudence, reduced by Ali Çehreli and myself: http://forum.dlang.org/post/sggmxddjpqpaookmw...@forum.dlang.org The following code is invalid, but the error message should be improved: class MyStore { class SingleStore { static void New() { new SingleStore(); /* line 7 */ } } } test.d(7): Error: type SingleStore is not an expression SingleStore is a nested class. That means, instances of it are bound to MyStore instances. But New is static, so it doesn't have a MyStore to which it could attach the `new SingleStore`. When moving New to MyStore the error gets better: class MyStore { class SingleStore { } static void New() { new SingleStore(); /* line 8 */ } } test.d(8): Error: 'this' is only defined in non-static member functions, not New test.d(8): Error: 'this' for nested class must be a class type, not _error_ That's still a bit stilted, but a lot better than the other one. --
Re: I guess this is a bug?
On Saturday, 12 September 2015 at 18:28:02 UTC, Random D user wrote: or is it some obscure feature conflict? [...] Oh... and I'm using win 64-bit and dmd 2.068.1, but this behavior was present earlier than that...
Re: Reasons to use D
On Saturday, 12 September 2015 at 18:59:11 UTC, Ola Fosheim Grøstad wrote: Array.slice create value copies, not reference views. I don't think there is a "slice" for Array. :-/ Right, that's why I said "kinda similarly"... the copy is really important if you want to mutate it, but it is good enough for viewing (tho poorly performing by comparsion). Compile GC-based D-JS -> JavaScript + TypeScript definitions. That's basically what my D->JS thing did back in 2011. The problem is that you might need a little bit of Dependent Typing in order to provide types for the browser API. I.e. return type depending on parameter values? Not sure. That doesn't actually happen very often, and when it does, you can do a function overload like string foo(string s) { return s;} vs int foo(int i) { return i; } and it works in D land pretty well. Then use a pragma(mangle) to make both refer to the same browser function. That actually worked somewhat well in my dtojs but it was a mild hassle too once function callbacks got more involved. You can template them in D but then it bloats the generated JS for no real reason since they all have identical dynamically typed code! I suppose that is solvable too but i never got around to it and just went back to writing normal javascript. (I write small JS files anyway, it is an ok language for small scripts.)
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:40:35 UTC, Adam D. Ruppe wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: - code completion in IDE. It'will never work. Why not? I haven't actually tried it, but it seems like a pretty easy problem, except perhaps with complex templates. - noobs, code is unreadable. meh meh too.
Re: Moving forward with work on the D language and foundation
On Friday, 28 August 2015 at 12:28:43 UTC, Russel Winder wrote: On Thu, 2015-08-27 at 16:01 +, BBasile via Digitalmars-d-announce wrote: […] That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome. I say "bollocks" to your accusation that Europeans post 50 are a bunch of useless idiots. I call double "bollocks" on the claim that only in the USA do people do anything. Never mind the bollocks. :handshake:
Re: Rust style memory management
On Saturday, 12 September 2015 at 23:21:48 UTC, welkam wrote: On Saturday, 12 September 2015 at 20:17:04 UTC, Freddy wrote: So I saw this video: https://air.mozilla.org/guaranteeing-memory-safety-in-rust/ and was amazed. Is there any way we can implement this in D? What language extensions would be required? My idea on implement this would be to add 3 new pointer (and array) types : [owned,shared immutable,borrow mutable] and depend on casting raw pointers to the new types. Thoughts? There is something in std.typecons http://dlang.org/phobos/std_typecons.html Never tried and didnt get into details, but sounds something like rust No that's can't provide the guarantee that are wanted here. You can't provides these guarantee without language support.
Re: Rust style memory management
On Saturday, 12 September 2015 at 20:33:39 UTC, Adam D. Ruppe wrote: Try using the -dip25 switch to dmd, it does one more step in D toward making a borrow thingy. Nowhere near the level Rust does it, but combined with other library things like destructors, prohibiting copying, etc., it can kinda make a owned thing with borrowed bits. I really wish we don't move that way. dip25 is at best a glorious hack and the kind of things that incrase language complexity without giving much in return.
Re: Mixin templates accessing mixed out scope
On Saturday, 12 September 2015 at 14:30:16 UTC, Ali Çehreli wrote: On 09/12/2015 06:37 AM, Prudence wrote: Says the creating new SingleStore is not an expression Reduced: mixin template ObjectStore(TKey) { class SingleStore { static void New()// Removing 'static' compiles { new SingleStore(); } } } class MyStore { mixin ObjectStore!(int); } void main() { auto s = new MyStore(); } Error: type SingleStore is not an expression Ali Are you saying this is a bug or something else? The only alternative I can think of is to use string mixins but this method should work?
I guess this is a bug?
or is it some obscure feature conflict? struct Foo { this( float x_, float y_ ) { // option A //x = x_; //y = y_; // option B v[0] = x_; v[1] = y_; } union { struct { float x = 0; float y = 0; } float[2] v; } } struct Bar { Foo foo = Foo( 1, 2 ); } Bar bar; Bar baz = bar.init; printf( "bar: %f, %f\n", bar.foo.x, bar.foo.y ); printf( "baz: %f, %f\n", baz.foo.x, baz.foo.y ); - prints (with option B): bar: 0.00, 0.00 // BUG?? baz: 1.00, 2.00 prints (with option A): bar: 1.00, 2.00 baz: 1.00, 2.00 - Luckily the option A works as I expected and is good enough for me...
Massive linker error after upgrade to DMD 2.068.1-1
After upgrading from DMD 2.068.0-1 to DMD 2.068.1-1, my project began producing a large linker error (when built using dub). I was able to trace it down to a single line: target = target.adjacent(Diagonals.yes).randomSample(1).front; target is of type RowCol (https://github.com/rcorre/dtiled/blob/master/src/dtiled/coords.d#L36), which has an `adjacent` property that leverages chain, only, and take. When I comment this line out (or build on a system with DMD 2.068.0-1), I can build fine. When uncommented, I see (post ddemangle): http://dpaste.com/1PJB35V I've tried to break this down into a reduced example to prove that I can call randomSample on the range returned by RowCol.adjacent (http://dpaste.com/13G9WDE). This runs fine, so it seems to be a deeper issue with my build environment (full project at https://github.com/rcorre/damage_control if you're curious). I don't want to turn this into "please debug my project for me", but do people have general hints on how to track down issues like this? Thanks! Side note: I see src/transition.d in the output, but I don't see how it is relevant to the error (it isn't even imported by the file causing the error).
Re: Operator overloading or alternatives to expression templates
On Fri, 11 Sep 2015 21:40:58 +0200, Martin Nowakwrote: Does anyone have a different idea how to make a nice query language? db.get!Person.where!(p => p.age > 21 && p.name == "Peter") Django's approach is, IMO, the cleverest and least magical one while keeping it expressive and efficient: Person.objects.filter(age__gt=21, name__eq='peter') The input of `filter` is keyword argument style. So, filter can access the dynamic argument names, in addition to their values. This makes it easy to understand user's intent without the need to overloaded operators or black magic (like repeated reflections Hibernate uses) and the syntax stays clean from user's perspective as well. -- -- Bahman Movaqar
Re: shared array?
On Saturday, 12 September 2015 at 06:23:12 UTC, Jonathan M Davis wrote: Aside from the few classes in Phobos, its GC usage is almost entirely restricted to when it allocates arrays or when it has to allocate a closure for a delegate, which can happen in some cases when passing predicates to range-based algorithms. Avoiding functions that need to allocate arrays avoids that source of allocation, and using functors or function pointers as predicates avoids having to allocate closures. So, you _can_ end up with GC allocations accidentally in Phobos if you're not careful, but on the whole, the assertion that Phobos uses the GC heavily is FUD - or at least a misunderstanding. But as we make more of the functions use lazy ranges rather than arrays (particularly with regards to strings), and we make more of the code @nogc, it becomes even clearer that the GC isn't involved. Also, improvements to how lambdas are handled should reduce how often closures have to be allocated for them. Thank you for this. How large is the allocation for closure for a delegate? Just a pair of pointers? On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote: I don't think it's that simple. Saying that it doesn't use it most of the time is not an answer/solution. Using it at all is a problem because one doesn't know when and where. I realize there is a switch now(-vgc), and maybe that is the solution, but you say "well, phobos only uses 0.01% on the GC", yet since you either don't, can't, or won't know where that is, then it might as well be 100% if you would like to potentially get off the GC one day. It's like playing Russian roulette. It doesn't matter if only 1/6 times will kill you. It's totally different than 0/6. But if you hardly use the GC, how long is it really going to take to run?
Re: Rust style memory management
On Saturday, 12 September 2015 at 20:17:04 UTC, Freddy wrote: So I saw this video: https://air.mozilla.org/guaranteeing-memory-safety-in-rust/ and was amazed. Is there any way we can implement this in D? What language extensions would be required? My idea on implement this would be to add 3 new pointer (and array) types : [owned,shared immutable,borrow mutable] and depend on casting raw pointers to the new types. Thoughts? There is something in std.typecons http://dlang.org/phobos/std_typecons.html Never tried and didnt get into details, but sounds something like rust
Re: Floating point in the type system
On Saturday, 12 September 2015 at 15:13:27 UTC, Robert wrote: Hi all, I came across this example, and wondered what your thoughts on it are: It seems a little unusual to me. Robert For what it's worth, I was investigating this initially as a discussion about adding type-level values in Rust, and how to handle unusual cases like this. In the process we've managed to break the Idris type system: https://github.com/idris-lang/Idris-dev/issues/2609. There's been quite a lot of interesting discussion about it on the IRC channels for all three languages :) I'd be interested to know how other languages handle this, if anyone knows.
Re: Operator overloading or alternatives to expression templates
On Friday, 11 September 2015 at 23:47:42 UTC, Andrei Alexandrescu wrote: 1. Use lambdas, which seem to already do what you want: db.get!Person.filter!(p => p.age > 21 && p.name == "Peter") The way this'd go, the db.get!Person() call returns an input range of Person. Presumably introspection is being used to bind fields in the query such as "age" and "name" to static field names in struct Person. Then good old std.algorithm.filter takes care of the rest. I'm instantiating the lambda with a fake p to capture the expression so I can translate it to whatever SQL, MongoDB, columnar db is used. 2. If you want to embed real SQL into D, use string-based DSLs. Strings don't capture context, aren't typechecked, and require a complex CTFE parser. db.get!Person.where!"age > 21 & name = ?"(name);
Re: Rust style memory management
On Saturday, 12 September 2015 at 20:17:04 UTC, Freddy wrote: So I saw this video: https://air.mozilla.org/guaranteeing-memory-safety-in-rust/ and was amazed. Is there any way we can implement this in D? What language extensions would be required? My idea on implement this would be to add 3 new pointer (and array) types : [owned,shared immutable,borrow mutable] and depend on casting raw pointers to the new types. Thoughts? There's been: http://wiki.dlang.org/User:Schuetzm/scope1 http://wiki.dlang.org/User:Schuetzm/scope2 http://wiki.dlang.org/User:Schuetzm/scope3 And at least one earlier proposal that's been accepted already. It requires the '@safe' annotation to work and is quite limited to anything more general. Although the basic opinion was that it covered a large proportion of the inherently unsafe cases that Rust aims to cover compared to C++ or unsafe D (but Rust's approach is more 'safe by proof' vs D's 'safe by prohibiting known unsafe').
Type helpers instead of UFCS
UFCS is good but there are two huge problems: - code completion in IDE. It'will never work. - noobs, code is unreadable. That's why I propose the new keywords 'helper' and 'subject' that will allow to extend the properties pre-defined for a type, as long as the helper is imported: --- module myhelper; helper for subject : string { void writeln() { import std.stdio; writeln(subject); } } --- this will allow IDE plugins to provide better completion. for example if 'Peter' types --- void foo() { import myhelper; "foobarbaz". } --- after the dot, 'Peter' can get ".writeln". Why ? because a clear grammatical construction will allow an IDE plugin to work on a type and provides additional helpers that would be hard to put in the list without any specific grammatical construction. ...
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On Saturday, 12 September 2015 at 14:24:21 UTC, Jacob Carlborg wrote: The problem with adding notifications in the documentation is that if a user already has implemented code that uses the particular model and have no need to change the code. Or the user already is familiar with the module there's no reason to read the documentation to see the notification or to notice the documentation is gone. It only (hopefully) prevents new users to use the module. Would it be better to add the deprecation immediately and let be deprecated for a longer period? Or use something like 'pragam(msg, "WARNING: deprecated ...")' if someone is using the "-de" flag. std.stream got a note in its documentation (something like 3 years ago) rather than being deprecated, because we didn't have a replacement yet. We just knew that we definitely wanted to replace it. But we have yet to actually come up with a replacement, and when it was brought up at dconf that the note had been on std.stream for years and yet the module was still there, Andrei said that we should just kill it and that maybe this was a sign that streams weren't all that important. So, we're now actually deprecating it even though we don't have a replacement yet. It used to be that marking something as deprecated immediately made that code fail to compile, which is why we used to mark stuff as "scheduled for deprecation" in its documentation for a while before actually deprecating it, but deprecated was fixed a while ago so that it doesn't result in a compilation error by default (hence the -de flag that you mentioned), and when that change was made, we stopped marking stuff as "scheduled for deprecation." Normally, what we've been doing for a while now is to just immediately deprecate a symbol (or module) and then wait about a year before removing it from the docs, and then wait about another year before removing it from the code. So, the result is that existing code has about two years to be changed before it'll stop compiling due to the symbol going away. It's just that anyone compiling it will be bugged by deprecation messages unless they use a flag to shut them off (which they shouldn't, because then they'll miss all deprecation messages, but folks are free to shoot themselves in the foot if they really want to). So, at this point, there really isn't much point in general in saying anything in the documentation before deprecating a symbol, and we haven't been doing that. The one exception that's come up is that deprecating a symbol and introducing its replacement in the same release causes problems for folks who need their code to build with both the current release and master (as is the case with Vladimir). So, in a few cases, we've marked a symbol as scheduled for deprecation when we add its replacement and then have deprecated it in the next release and continued the deprecation cycle as normal. But most of the time, we've just gone straight to deprecated, and we aren't doing a lot of deprecating these days, so it's nowhere near the issue it was when we were doing mass renamings and whatnot several years ago. - Jonathan M Davis
Re: Why does reverse also flips my other dynamic array?
On 09/12/2015 02:29 PM, Marco Leise wrote: > Note that often the original dynamic array has additional > capacity beyond its length. This can be used to ~= additional > items without causing a reallocation, but is lost when you > do the assignment "b = a". Actually, the capacity is still there, useful to the runtime. Interestingly, the first dynamic array that is appended the new element becomes the owner of that capacity. The capacity of the other dynamic array becomes 0. import std.stdio; void main(){ int [] a = [1,2,3,4,5]; int [] b = a; writeln(a.ptr, " ", b.ptr); writeln(a.capacity, " ", b.capacity); a ~= 42;// <-- change to b, now b owns the capacity writeln(a.ptr, " ", b.ptr); writeln(a.capacity, " ", b.capacity); } Ali
Re: Hello World Example with Glade?
On Saturday, 12 September 2015 at 09:03:53 UTC, Russel Winder wrote: Once you get to a GtkD application bigger than "Hello World" create a project and use Dub. Oh yes, Dub. That's the ticket. Thanks, mate.
Re: Reasons to use D
On Saturday, 12 September 2015 at 11:36:47 UTC, Sebastiaan Koppe wrote: I suppose you mean changing the contents of an existing script element. I was talking about inserting a new inline-script via html(). oh yeah, you are right. That's one thing I do like about D though: I find it so much easier to remember (perhaps because I wrote most the libs I use myself). I forget the difference between stuff like substr and substring in Javascript or chop and chomp in Ruby and so on. I have to refer to the docs to remember this stuff, even when I write it all the time. I find D's ways to be much easier to store in the brain, despite D arguably being a bigger, more complex language.
Re: Floating point in the type system
On Saturday, 12 September 2015 at 16:08:31 UTC, Robert wrote: assert and runtime assert failing. I'm just curious to understand the reasoning behind this, whether it's intentional, and whether it matters at all. Types need to mangle to the same name, but using floats in a type name is usually not a good idea. Try pi... How many decimals? A roundoff error and you get a new type.
Re: Better lambdas!!!!!!!!!!
On Saturday, 12 September 2015 at 10:44:05 UTC, Pierre Krafft wrote: On Saturday, 12 September 2015 at 03:32:51 UTC, Prudence wrote: On Saturday, 12 September 2015 at 02:13:11 UTC, Pierre Krafft wrote: On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence wrote: On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli wrote: On 09/10/2015 10:55 AM, Prudence wrote: > How bout this: > > void myfunc(double delegate(int i, int z, float f)) {} > > > myfunc((int i, int z, float f) { return i*z*f; } } > > vs > > myfunc({ return i*z*f; }) // Names of parameters are inferred from > signature. Considering other features of the language, that's pretty much impossible in D. What if there is another i in scope: int i; myfunc({ return i*z*f; }); Now, should it call another overload of myfunc that takes (int z, int f) because i is something else? Should the compiler analyze the body of the code and decide which symbols could be parameters? And then go through all overloads of myfunc? etc.? Ali As I said, it could throw a warning or error. It, in some sense, is already a a problem with nested blocks that hide outside variables, is it not? The compiler doesn't need to scan anything. It knows the which parameters from the definition! -> void myfunc(double delegate(int i, int z, float f)) <- Compiler knows to use the names here as the default names in for the parameters when. when used: myfunc({ return i*z*f; }); <- Oh, there are the names, we know what they are because the signature is tells us. The compiler does the following: 1. Sees we have a block without any parameters defined. i.e., a lambda. 2. It looks up the signature of myfunc to find out what the names are 3. It sees that they are i z and f 4. Now it knows and it effectively rewrites the code as myfunc((i,z,f) { return i*z*f; }); Surely this is not difficult, 4 steps? You're making your code more brittle for a small gain. The suggestion makes parameter usage order important and the compiler can't warn about my typos. Consider: myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return "y:"~y~"x:"~x;}); Or the typo in myfunc({return i*z+f*j;}); Lambdas are already very concise. This proposal doesn't give any benefits outside of very simple lambdas. Such lambdas are already so simple that they could use some standard functions instead (like sum, to!T, and bind). What does this have to do with my proposal? Those issues exist regardless of the simplification. myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return "y:"~y~"x:"~x;}); huh? What do you mean the suggestion makes parameter usage order important? They are important, it has nothing to do with the suggestion? Are you saying that you want to reserve the right to do something like myfunc(string delegate(string x, string y)); and myfunc((y,x){ "y:"~y~"x:"~x; }) ? If so, or unless I'm missing something, that's bad no matter what. Changing the order and reversing the names is more than just confusing, it's hard to read and most people will gloss over that fact. Be consistent with your parameters and maybe you'll have less bugs? Or the typo in myfunc({return i*z+f*j;}); Again, what does this have to do with anything? A typo is a typo and is always a mistake. The above example has the same effect regardless if the parameters are explicit or deduced. myfunc((i,z,f) {return i*z+f*j;}); j is still a problem. If j is defined outside the lambda then regardless of specific or implicit parameter names, it will not cause any problems. In either case, the compiler can see that j is either referenced outside the scope or undefined. It has nothing to do with the parameters used. Of course maybe I'm missing something, but essentially are not almost all uses of lambda's simply copying the parameter signature of the delegate. It already infers types... you could say that leads to typo's too... myfunc({return "x:"~x~"y:"-y;}); is infered to mean myfunc((x,y){return "x:"~x~"y:"-y;}); while myfunc({return "y:"~y~"x:"~x;}); is infered to mean myfunc((y,x){return "y:"~y~"x:"~x;}); which is not what I expect since the lambda I want is myfunc((x,y){return "y:"~y~"x:"~x;}); This can lead to subtle bugs which are very hard to see. In the typo example there could be two overloaded functions differing only in that one takes a delegate having 3 parameters and one taking a delegate having 4 parameters. If we explicitly write the lambda parameters the typo will be found since j is undefined. But when parameters are inferred the compiler will see that {return i*z + f*j;} matches the function taking a lambda with 4 parameters. Inferred parameter types are on the brink of what I can allow. They can risk typos, but not as easily since you write the parameters twice (declaration and usage). They can also silently change if the function taking the delegate has the parameter type changed. I don't want
Re: Mixin templates accessing mixed out scope
On Saturday 12 September 2015 16:30, Ali Çehreli wrote: > Reduced: [...] > Error: type SingleStore is not an expression Reduced further: class MyStore { class SingleStore { static void New() // Removing 'static' compiles { new SingleStore(); } } } And now the problem can be spotted: SingleStore is a nested class. That means, instances of it are bound to MyStore instances. But New is static, so it doesn't have a MyStore to which it could attach the `new SingleStore`. That error message is pretty awful. I filed an issue: https://issues.dlang.org/show_bug.cgi?id=15049 As for a fix: I guess SingleStore isn't supposed to be a nested class. Mark it static then.
[Issue 15050] DPaste is always passing an empty second argument to programs
https://issues.dlang.org/show_bug.cgi?id=15050 Vladimir Panteleevchanged: What|Removed |Added Blocks||12210 --
[Issue 12210] dlang.org home page example - Run button does not work
https://issues.dlang.org/show_bug.cgi?id=12210 Vladimir Panteleevchanged: What|Removed |Added Depends on||15050 --
[Issue 15050] New: DPaste is always passing an empty second argument to programs
https://issues.dlang.org/show_bug.cgi?id=15050 Issue ID: 15050 Summary: DPaste is always passing an empty second argument to programs Product: D Version: D2 Hardware: All URL: http://dpaste.dzfl.pl/32757e6f96b0 OS: All Status: NEW Severity: normal Priority: P1 Component: dlang.org Assignee: nazriel6...@gmail.com Reporter: thecybersha...@gmail.com import std.stdio; void main(string[] args) { writeln(args); } This will print e.g.: ["./f342", ""] This is blocking e.g. the float-rounding example on dlang.org. --
Re: Mixin templates accessing mixed out scope
On Saturday 12 September 2015 19:36, Prudence wrote: > On Saturday, 12 September 2015 at 17:11:04 UTC, anonymous wrote: [...] >> class MyStore >> { >> class SingleStore >> { >> static void New() // Removing 'static' compiles >> { >> new SingleStore(); >> } >> } >> } [...] >> As for a fix: I guess SingleStore isn't supposed to be a nested >> class. Mark it static then. > > NO! That is the whole point! So New is supposed to create a SingleStore that's associated with a MyStore? That static can't work like that then. It doesn't escape just the first level (SingleStore), but all levels (SingleStore and MyStore). That is, a static method isn't bound to any object. But you need a MyStore to construct a (nested) SingleStore. You have to pass a MyStore somehow. It can come via `this.outer`: class MyStore { class SingleStore { SingleStore New() { return new SingleStore; } } } void main() { auto ms = new MyStore; auto ss1 = ms.new SingleStore; auto ss2 = ss1.New(); } But here you need a SingleStore object to call New on. Not what you want, I think. Or the MyStore can come via parameter: class MyStore { class SingleStore { static SingleStore New(MyStore ms) { return ms.new SingleStore; } } } void main() { auto ms = new MyStore; auto ss = MyStore.SingleStore.New(ms); } Or you can move New a level up, into MyStore, and then plain `this` is the needed MyStore: class MyStore { class SingleStore { } SingleStore NewSingleStore() { return new SingleStore; } } void main() { auto ms = new MyStore; auto ss = ms.NewSingleStore(); }
Re: Calling D from C, C++, Python…
On 9/12/15 9:20 AM, Adam D. Ruppe via Digitalmars-d-learn wrote: On Saturday, 12 September 2015 at 09:47:55 UTC, Jacob Carlborg wrote: Well, if your D function doesn't use anything of the runtime I guess it's not necessary. Right. If you don't call into the threading system in the druntime, you should be ok. Keep in mind though that the GC uses the threads and the new expression, array literals, array append, and others use the GC. Runtime.initialize is also what calls static and module constructors... and might have responsibility for fixing up dynamic casting of class objects in a shared lib too, I'm not sure about that. But if you avoid the bulk of the runtime functions, indeed you can get away without initializing it. Just that null thread handle is likely to cause segfaults in places where you might not expect if you don't. It is best to initialize it. Lots of C libraries need an init an teardown call, so surely the Python interop provides some solution for it. idk what it would be though. I think it's safest to say (and it belongs in the spec somewhere) that executing D code before initializing the runtime results in undefined behavior, or something along those lines. You can get away with it in some circumstances, but it's at your own risk.
[Issue 12210] dlang.org home page example - Run button does not work
https://issues.dlang.org/show_bug.cgi?id=12210 Vladimir Panteleevchanged: What|Removed |Added Assignee|thecybersha...@gmail.com|nazriel6...@gmail.com --- Comment #10 from Vladimir Panteleev --- Some fixes: https://github.com/D-Programming-Language/dlang.org/pull/1098 Some issues are still blocked on some DPaste-specific problems. (In reply to Gerald Jansen from comment #9) > Perhaps this is a slightly different issue but it is related so I'll just > mention it here. The example in the section "Convenience" under the > paragraph starting with "Automatic memory management makes for safe, simple, > and robust code.", crashes with message: > > Application output: (1 Hangup) > Exiting main. > std.exception.ErrnoException@std/stdio.d(385): Cannot open file `text.txt' > in mode `rb' (No such file or directory) > > ... and a bunch of incomprehensible junk (for a casual visitor) > > Having examples that don't run is probably worse than no examples. Perhaps > the priority of this issue should be increased. Perhaps the more general > issue is how to continuously test and ensure that all example code > highlighted on dlang.org runs correctly. The example is correct, and works as expected in the absence of a text.txt file. It is meant to illustrate RAII, there isn't much value in including it in Edit-and-Run, so I added support for excluding examples and excluded it. --
Re: Reasons to use D
On Saturday, 12 September 2015 at 18:44:44 UTC, Ola Fosheim Grøstad wrote: Arrayviews ("slices") are available as a type so you can do it like this: Yeah, there's also the Array.slice and String.substring that work kinda similarly in old standard javascript. But there's still a lot of type-specific verbiage in there, whereas with D, it is always the same [a .. $] for almost anything so it is one thing to remember instead of three or more.
[Issue 15036] SimpleDllMain assumes various symbols are available unqualified
https://issues.dlang.org/show_bug.cgi?id=15036 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15036] SimpleDllMain assumes various symbols are available unqualified
https://issues.dlang.org/show_bug.cgi?id=15036 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/957d83f1c342e44229d148027a449c956a42c122 fix Issue 15036 - SimpleDllMain assumes various symbols are available unqualified https://github.com/D-Programming-Language/druntime/commit/15cde5050c8341fec3c8b5f5ad83eac2a92fe6f3 Merge pull request #1385 from CyberShadow/pull-20150912-184323 fix Issue 15036 - SimpleDllMain assumes various symbols are available… --
Re: Operator overloading or alternatives to expression templates
On 12-Sep-2015 23:08, Martin Nowak wrote: On Friday, 11 September 2015 at 23:47:42 UTC, Andrei Alexandrescu wrote: 1. Use lambdas, which seem to already do what you want: db.get!Person.filter!(p => p.age > 21 && p.name == "Peter") The way this'd go, the db.get!Person() call returns an input range of Person. Presumably introspection is being used to bind fields in the query such as "age" and "name" to static field names in struct Person. Then good old std.algorithm.filter takes care of the rest. I'm instantiating the lambda with a fake p to capture the expression so I can translate it to whatever SQL, MongoDB, columnar db is used. 2. If you want to embed real SQL into D, use string-based DSLs. Strings don't capture context, aren't typechecked, and require a complex CTFE parser. db.get!Person.where!"age > 21 & name = ?"(name); What if we add generic string interpolation a-la: s"$age > 21 && name = ${someobj.field}" would translate to: AliasSeq!("",age," > 21 && name = ", someobj.field, ""); Thoughts? I think it was proposed before by Timothy Cour. -- Dmitry Olshansky
Re: Operator overloading or alternatives to expression templates
On Friday, 11 September 2015 at 23:19:54 UTC, Timon Gehr wrote: Does anyone have a different idea how to make a nice query language? db.get!Person.where!(p => p.age > 21 && p.name == "Peter") You could give up on operator syntax. That's what I did in the prototype, p.age.gt(21), but it's somewhat ugly.
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:40:35 UTC, Adam D. Ruppe wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: - code completion in IDE. It'will never work. Why not? I haven't actually tried it, but it seems like a pretty easy problem, except perhaps with complex templates. - noobs, code is unreadable. meh There's the bigger problem that extending a type via UFCS is 'open'; there can always be more functions where the first parameter accepts that type you're using. With a dedicated syntax, specific functions/groups-of-functions could be easily recognized as extensions of a type and could even be made to be recognized by templates (when the type is passed as type parameter or alias param) even though they're not in its definition. Kinda like type classes. But, anyway...
Re: Reasons to use D
On Saturday, 12 September 2015 at 20:03:09 UTC, Adam D. Ruppe wrote: That's basically what my D->JS thing did back in 2011. Nice, so now you will do it again in 2016 ? ;) That actually worked somewhat well in my dtojs but it was a mild hassle too once function callbacks got more involved. You can template them in D but then it bloats the generated JS for no real reason since they all have identical dynamically typed code! Yes, you need to convert the D into a JS-specific IR and then fix it in an optimization step before code gen. But function overloading isn't enough, unless you accept casting, since javascript can return anything. I guess you can use template parameters when you request literal strings like «document.createElement("div")», but in other situations it might be more tricky. I don't think function overloading is enough if you want to avoid casting. But the TypeScript definition files might make it somewhat easier, and might be a good starting point as they expose typing issues. I don't think they are too hard to parse partially: https://github.com/Microsoft/TypeScript/blob/master/lib/lib.core.es6.d.ts https://github.com/Microsoft/TypeScript/blob/master/lib/lib.es6.d.ts https://github.com/Microsoft/TypeScript/blob/master/lib/lib.dom.d.ts etc Although I think one should only include what browsers have in common. So it is a tedious job that probably involves writing a test program that test what different browsers support and upload results to a web server... I suppose that is solvable too but i never got around to it and just went back to writing normal javascript. (I write small JS files anyway, it is an ok language for small scripts.) It's ok if you only write a few hundred lines of javascript, but the IDE code completion you get with typing really makes a difference.
Re: Floating point in the type system
On Saturday, 12 September 2015 at 19:02:16 UTC, Robert wrote: handle unusual cases like this. In the process we've managed to break the Idris type system: https://github.com/idris-lang/Idris-dev/issues/2609. I don't know Idris, but you can't easily unify over floats, because they are samples on an interval, and don't behave like real numbers, but more like underspecified intervals from interval arithmetics. If you want to unify over reals, you probably should do it symbolically. Or just treat float values as literal symbols in the type system. It is useful for configuration: Frequency!342.234 Sometimes it is worthwhile to have an unsound type system. Both D and Dart have somewhat unsound type systems. It puts a burden on the programmer, but can be useful.
Re: Floating point in the type system
On Saturday, 12 September 2015 at 16:08:31 UTC, Robert wrote: On Saturday, 12 September 2015 at 15:49:23 UTC, Atila Neves wrote: What do think is unusual? Atila It's unusual, because `float.nan != float.nan`, so one might expect that `typeof(Foo!(float.nan) != Foo!(float.nan))`, whereas this is clearly not the case, even with both the static assert and runtime assert failing. I'm just curious to understand the reasoning behind this, whether it's intentional, and whether it matters at all. (1) f = f2; // This is assignment, not comparison (2) alias VAL = f; // This is not a data member so is not involved in comparisons or assignments change "alias VAL" to "float VAL" and then you might see the behavior you expect.
Re: A collection of DIPs
On Saturday, 12 September 2015 at 15:54:53 UTC, Adam D. Ruppe wrote: D programs *never* have a GC thread. Remember, the D GC isn't magic and isn't actually even that complicated, it is just an ordinary function call. That's what I was afraid of :'(
Re: Reasons to use D
On Saturday, 12 September 2015 at 16:32:52 UTC, Adam D. Ruppe wrote: oh yeah, you are right. That's one thing I do like about D though: I find it so much easier to remember (perhaps because I wrote most the libs I use myself). I forget the difference between stuff like substr and substring in Javascript or chop and chomp in Ruby and so on. I have to refer to the docs to remember this stuff, even when I write it all the time. I find D's ways to be much easier to store in the brain, despite D arguably being a bigger, more complex language. Maybe because the static type system allows for overloading and so all of these utility functions don't have to do a million different things depending on what you pass to them.
Re: Floating point in the type system
On Saturday 12 September 2015 18:08, Robert wrote: > It's unusual, because `float.nan != float.nan`, so one might > expect that `typeof(Foo!(float.nan) != Foo!(float.nan))`, whereas > this is clearly not the case, even with both the static assert > and runtime assert failing. I'm just curious to understand the > reasoning behind this, whether it's intentional, and whether it > matters at all. I don't know what the compiler actually does, but it looks like the comparison of template value arguments doesn't use equality, but something more akin to `is` instead (bitwise equality). If that's right, then `is(Foo!(float.nan) == Foo!(float.nan))` holds because `float.nan is float.nan` holds. Same behavior with a struct instead of float: struct S { bool opEquals(S other) {return false;} } struct Foo(S s) { } static assert(S.init != S.init); /* not equal */ static assert(S.init is S.init); /* but bit for bit identical */ static assert(is(Foo!(S.init) == Foo!(S.init)));
Re: Why does reverse also flips my other dynamic array?
Am Sat, 12 Sep 2015 10:55:50 + schrieb "Namal": > > Why is also b flipped here? This doesn't happen if I use static > > arrays. > > nvm. I need to .dup that. Correct, static arrays are value types and copied on assignment. Dynamic arrays on the other hand are generally slices of memory on the garbage collected heap represented by just a pointer to the first element and a length. When you assign those you only get a second reference to the same data. Note that often the original dynamic array has additional capacity beyond its length. This can be used to ~= additional items without causing a reallocation, but is lost when you do the assignment "b = a". (This is so you can't accidentally append different items to both a and b and have them overwrite each other.) You can query the actual capacity with a.capacity. Just felt like writing down some knowledge you might need along the way. :) -- Marco
Re: shared array?
On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote: Saying that it doesn't use it most of the time is not an answer/solution. Using it at all is a problem because one doesn't know when and where. I realize there is a switch now(-vgc), and maybe that is the solution, but you say "well, phobos only uses 0.01% on the GC", yet since you either don't, can't, or won't know where that is, then it might as well be 100% if you would like to potentially get off the GC one day. "you either don't, can't, or won't know where that is" just check the signature, no ? eg http://dlang.org/phobos/std_string.html pure nothrow @nogc @system inout(char)[] fromStringz(inout(char)* cString); ^
[Issue 15052] New: dmd/std/utf.d error on variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r
https://issues.dlang.org/show_bug.cgi?id=15052 Issue ID: 15052 Summary: dmd/std/utf.d error on variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUn itImpl.r Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: blocker Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: pedrolo...@gmx.com Created attachment 1550 --> https://issues.dlang.org/attachment.cgi?id=1550=edit the utf.d file dmd 2.068.1-1 it fails when using dub to compile a file. /usr/include/dlang/dmd/std/utf.d(3128): Error: variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r only parameters or stack based variables can be inout /usr/include/dlang/dmd/std/utf.d(3278): Error: template instance std.utf.byCodeUnit!(inout(char)[]) error instantiating /usr/include/dlang/dmd/std/string.d(386):instantiated from here: byDchar!(inout(char)[]) actually this is not just one error it is a load of them, --
Re: Massive linker error after upgrade to DMD 2.068.1-1
On Saturday, 12 September 2015 at 20:05:28 UTC, rcorre wrote: After upgrading from DMD 2.068.0-1 to DMD 2.068.1-1, my project began producing a large linker error (when built using dub). I was able to trace it down to a single line: target = target.adjacent(Diagonals.yes).randomSample(1).front; target is of type RowCol (https://github.com/rcorre/dtiled/blob/master/src/dtiled/coords.d#L36), which has an `adjacent` property that leverages chain, only, and take. When I comment this line out (or build on a system with DMD 2.068.0-1), I can build fine. When uncommented, I see (post ddemangle): http://dpaste.com/1PJB35V I've tried to break this down into a reduced example to prove that I can call randomSample on the range returned by RowCol.adjacent (http://dpaste.com/13G9WDE). This runs fine, so it seems to be a deeper issue with my build environment (full project at https://github.com/rcorre/damage_control if you're curious). I don't want to turn this into "please debug my project for me", but do people have general hints on how to track down issues like this? Thanks! Side note: I see src/transition.d in the output, but I don't see how it is relevant to the error (it isn't even imported by the file causing the error). there was talk of adding symbol name compression some time ago ( to reduce lib size ( and maybe make ddemangle not fail on long syms?). This might be the cause of your problems i.e. the new compiler emitting references to compressed names but built with the old compiler using the not compressed ones. Try rebuilding everything and see if that fixes it.
[Issue 15052] dmd/std/utf.d error on variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r
https://issues.dlang.org/show_bug.cgi?id=15052 pedrolopeschanged: What|Removed |Added CC||pedrolo...@gmx.com Severity|blocker |critical --
[Issue 15052] dmd/std/utf.d error on variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r
https://issues.dlang.org/show_bug.cgi?id=15052 pedrolopeschanged: What|Removed |Added Component|dmd |phobos --
Re: Looking for someone that could work on 32 bits support for SDC
On Sunday, 13 September 2015 at 01:17:17 UTC, Brandon Ragland wrote: x86 would be easiest to target. I've checked out the repo, built it so far, and indeed some failures but no big deals. Currently paging through to get a hold on what's in there. (I'll be the first to admit I don't know squat about the LLVM compiler). A good place to start is : http://llvm.org/docs/LangRef.html You can uncomment things here : https://github.com/SDC-Developers/SDC/blob/master/libd-llvm/src/d/llvm/backend.d#L115 and see what kind of IR is outputed. Frankly you don't need to know much more than this to get started. Don't go paralyzed because you don't know everything. Start doing something and see what is actually blocking you.
Re: Does a synchronization yield on waiting thread?
On 9/12/15 10:48 PM, Prudence wrote: It would seem to be the logical thing to do? That is, suppose two threads are sharing a resource. Thread A has it locked. B is "waiting". Is B in a loop burning cycles running in the background(regardless of thread.sleep, which only alleviates the problem) or does it yield completely and somehow inform the lock to resume it when A has unlocked the resources? If you are using D mutexes or synchronized statements, it uses the OS' mechanisms (e.g. pthreads). For all supported OSes, this means it is asleep and waiting for the OS to awaken it when it has locked the resource. The first one burns cycles and can have timing problems. I.e., What if A locks and unlocks at the same rate that B checks? (I suppose a random sleep time would help with this) ( You don't have to worry about this. If A unlocks a resource that B is waiting for the lock, it cannot lock it again before B gets it. -Steve
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 22:44:41 UTC, Idan Arye wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: That's why I propose the new keywords 'helper' and 'subject' that will allow to extend the properties pre-defined for a type, as long as the helper is imported: --- module myhelper; helper for subject : string Do we really need a 3-keyword chain? What's wrong with a simple `helper : string` or `helper(string)`? { void writeln() { import std.stdio; writeln(subject); } } --- Why `subject` to refer to the string the function gets called on? What's wrong with good old `this`, which is used for this purpose everywhere else? no 'helper' is enough: http://www.israpresse.net/wp-content/uploads/2015/05/625088-34.jpg
Re: Looking for someone that could work on 32 bits support for SDC
On Wednesday, 9 September 2015 at 20:33:43 UTC, deadalnix wrote: All is in the title. ARM/Mips/pNaCl/WebAssembly require 32bits to work. These are valuable targets IMO. I can provide support, but I just don't have the bandwidth to pull it by myself. If someone could step up, that'd be great. Do you think that libd is 32bit ready ? https://github.com/SDC-Developers/SDC/pull/141
Re: reading file byLine
On Saturday, 12 September 2015 at 12:51:04 UTC, Namal wrote: Anyway, there is no .reverse for strings I guess, what is the way to completely reverse a string in D? What do you want to do? Do you want to keep your data in original order, but get a reversed view of it for something, or do you actually want to reverse your original array? You can use `retro` to simply read your array backwards, i.e.: string s = "Some text"; s.retro.writeln; // `txet emoS` s.writeln; // `Some text` s.retro.find("e"); // `Some te` (Surprising to me. Error? 2.067.1) s.retro.until("e").writeln;// `tx` s.find("e"); // `Some` The string is still kept in original order, but `retro` returns a range reading the array backwards. If you want to store a reversed string in memory, that's possible too, of course. One way of doing it, is to convert your retro range to a string: s = s.retro.to!string; s.writeln; // `txet emoS` This will allocate new memory for the reversed copy and assign it to `s`. Reverse is an algorithm that swaps values at different indices and since `string` is an alias for `const(char)[]`, it's not allowed. It means that each element of the array is const, so you cannot mutate any elements, but you can append or remove elements or assign the slice to view another part of the string or some other string. Hence, a `s.reverse` will give you an error. If you use `char[]` instead of `const(char)[]` you can use reverse and reuse the same memory for the reversed `char[]`. To illustrate: char[] t = ['a', 'b', 'c']; std.algorithm.reverse(t); t.writeln; // `cba` // s[0] = s[$-1]; // Error, cannot mutate const elements auto r = s.retro; s.length = 0; r.each!(e => s ~= e); s.writeln; // s has the reversed string, obtained through // a temporary range object, setting length to // zero and appending the elements from the // range, which is allowed for const(char)[]
[Issue 15019] [ICE] Heisencrash on OS X 32-bit with non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #13 from Vladimir Panteleev--- I think I found the cause of the memory corruption, but not the root cause of the bug. If you apply these patches: https://github.com/CyberShadow/dmd/commit/2d424ac899535d975a6265b094c7f3fec217f4c5 https://github.com/CyberShadow/dmd/commit/0ea57be391b0a8307c1b5bf907506f74892ffe1d you will see that the assert fails with the given test case, although the DMD test suite passes with these asserts. It looks like DMD is trying to create a relocation outside of the data segment? Here's the backtrace: * frame #0: 0x0001001d9a66 dmd`util_assert(file=0x000100322900, line=278) + 22 at util2.c:55 frame #1: 0x0001001d072d dmd`local_assert(line=278) + 29 at tassert.h:29 frame #2: 0x0001001d00d7 dmd`Outbuffer::setsize(this=0x000121e7d320, size=4100) + 55 at outbuf.c:278 frame #3: 0x00010022e767 dmd`Obj::bytes(seg=2, offset=4100, nbytes=4, p=0x000100344f98) + 167 at machobj.c:2288 frame #4: 0x0001001b93c6 dmd`addtofixlist(s=0x000100cf9b40, soffset=4100, seg=2, val=0, flags=16) + 374 at cgen.c:594 frame #5: 0x0001002325b6 dmd`Obj::reftoident(seg=2, offset=4100, s=0x000100cf9b40, val=0, flags=16) + 150 at machobj.c:2469 frame #6: 0x00010019c9c5 dmd`el_ptr(s=0x000100cf9b40) + 261 at el.c:1710 frame #7: 0x0001001606ca dmd`toElem(this=0x7fff5fbfd108, fe=0x000121120be0)::ToElemVisitor::visit(FuncExp*) + 138 at e2ir.c:1154 frame #8: 0x00010008e986 dmd`FuncExp::accept(Visitor*) + 34 at expression.d:6324 frame #9: 0x00010015a332 dmd`toElem(e=0x000121120be0, irs=0x7fff5fbfd970) + 66 at e2ir.c:5485 frame #10: 0x00010016254c dmd`toElem(this=0x7fff5fbfd198, pe=0x00012131e4d0)::ToElemVisitor::visit(PtrExp*) + 44 at e2ir.c:3690 frame #11: 0x00010009ad0e dmd`PtrExp::accept(Visitor*) + 34 at expression.d:9738 frame #12: 0x00010015a332 dmd`toElem(e=0x00012131e4d0, irs=0x7fff5fbfd970) + 66 at e2ir.c:5485 frame #13: 0x00010016204b dmd`toElem(this=0x7fff5fbfd328, ce=0x000121120b90)::ToElemVisitor::visit(CallExp*) + 1179 at e2ir.c:3605 frame #14: 0x000100099f16 dmd`CallExp::accept(Visitor*) + 34 at expression.d:9464 frame #15: 0x00010015a332 dmd`toElem(e=0x000121120b90, irs=0x7fff5fbfd970) + 66 at e2ir.c:5485 frame #16: 0x000100166625 dmd`toElem(this=0x7fff5fbfd788, ae=0x0001205dc9d0)::ToElemVisitor::visit(AssignExp*) + 8453 at e2ir.c:2949 frame #17: 0x0001000a3476 dmd`AssignExp::accept(Visitor*) + 34 at expression.d:12155 frame #18: 0x00010015a332 dmd`toElem(e=0x0001205dc9d0, irs=0x7fff5fbfd970) + 66 at e2ir.c:5485 frame #19: 0x00010015b8a8 dmd`toElemDtor(e=0x0001205dc9d0, irs=0x7fff5fbfd970) + 88 at e2ir.c:5578 frame #20: 0x00010014f3a2 dmd`S2irVisitor::visit(this=0x7fff5fbfd890, s=0x000121120b00) + 130 at s2ir.c:846 frame #21: 0x00010011aa73 dmd`ExpStatement::accept(Visitor*) + 31 at statement.d:1247 frame #22: 0x00010014f242 dmd`Statement_toIR(s=0x000121120b00, irs=0x7fff5fbfd970) + 66 at s2ir.c:1283 frame #23: 0x00010014f446 dmd`S2irVisitor::visit(this=0x7fff5fbfd930, s=0x000121121f10) + 134 at s2ir.c:862 frame #24: 0x00010011bd83 dmd`CompoundStatement::accept(Visitor*) + 31 at statement.d:1587 frame #25: 0x00010014f242 dmd`Statement_toIR(s=0x000121121f10, irs=0x7fff5fbfd970) + 66 at s2ir.c:1283 frame #26: 0x00010014f6b5 dmd`S2irVisitor::visit(this=0x7fff5fbfda60, s=0x000121121e40) + 149 at s2ir.c:922 frame #27: 0x00010011c4d3 dmd`ScopeStatement::accept(Visitor*) + 31 at statement.d:1763 frame #28: 0x00010014f242 dmd`Statement_toIR(s=0x000121121e40, irs=0x7fff5fbfdad0) + 66 at s2ir.c:1283 frame #29: 0x00010014f588 dmd`S2irVisitor::visit(this=0x7fff5fbfdbc0, s=0x000121121e60) + 280 at s2ir.c:895 frame #30: 0x00010011c173 dmd`UnrolledLoopStatement::accept(Visitor*) + 31 at statement.d:1677 frame #31: 0x00010014f242 dmd`Statement_toIR(s=0x000121121e60, irs=0x7fff5fbfdc00) + 66 at s2ir.c:1283 frame #32: 0x00010014f6b5 dmd`S2irVisitor::visit(this=0x7fff5fbfdcf0, s=0x000121118060) + 149 at s2ir.c:922 frame #33: 0x00010011c4d3 dmd`ScopeStatement::accept(Visitor*) + 31 at statement.d:1763 frame #34: 0x00010014f242 dmd`Statement_toIR(s=0x000121118060, irs=0x7fff5fbfdd58) + 66 at s2ir.c:1283 frame #35: 0x00010014fd9b dmd`S2irVisitor::visit(this=0x7fff5fbfde50, s=0x000121118020) + 331 at s2ir.c:198 frame #36: 0x000100123e23 dmd`IfStatement::accept(Visitor*) + 31 at statement.d:3287 frame #37: 0x00010014f242 dmd`Statement_toIR(s=0x000121118020, irs=0x7fff5fbfe328) + 66 at s2ir.c:1283 frame #38: 0x00010014f446
[Issue 15053] New: Runtime.cArgs not @nogc
https://issues.dlang.org/show_bug.cgi?id=15053 Issue ID: 15053 Summary: Runtime.cArgs not @nogc Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: m...@philpax.me When using @nogc code and/or C standard library functions, accessing the standard C main arguments is useful. Unfortunately, cArgs is not @nogc: --- import core.stdc.stdio; import core.runtime; @nogc: void main() { // NG printf("%s\n", Runtime.cArgs.argv[0]); } --- --
Re: Enumap -- a lightweight AA alternative when your keys are enums
On Friday, 11 September 2015 at 03:25:58 UTC, SimonN wrote: It doesn't seem to matter whether I put const int, or int, in the foreach statement. What's the idiomatic way to loop over a const Enumap? :-) -- Simon I've released v0.4.0, which implements foreach with ref, and (hopefully) atones for my crimes against const-correctness. You should be able to modify values in a loop and work with const/immutable Enumaps. Thanks for the feedback!
[Issue 15052] dmd/std/utf.d error on variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r
https://issues.dlang.org/show_bug.cgi?id=15052 pedrolopeschanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from pedrolopes --- Solves! clean all phobos files and reinstalled DMD. old files from phobos had not been replaced during some DMD update installation. --
Re: Looking for someone that could work on 32 bits support for SDC
On Friday, 11 September 2015 at 01:35:09 UTC, deadalnix wrote: On Friday, 11 September 2015 at 01:12:21 UTC, Brandon Ragland wrote: [...] Sure. First thing first, try to checkout the project and get it to build and pass the tests (well, some tests will fail, but you should get 0 regressions). Step 2 would be to modify the test runner to be able to run in 64 or 32 bits. Some tests will have a different result in 32 bits, notably the ones that use the pointer size somewhere. (tests/runner.d) Step 3 add a m32/m64 flags to SDC. It is using the getopt from phobos and that should be fairly straightforward. (sdc/src/main.d) Step 4 go through the codegen (libd-llvm) and update it to take the flag into account. (that's the big chunk). There may be some places in the frontend that assume 64 bits pointers, but if so, not many. Step 5 go through the runtime and do the same. There shouldn't be many here as well, but I'm not sure. In a first instance, I guess the right move is to target x86 because it is fairly close to x64 so it should work with minimal changes in the runtime. You can jump in IRC if you want to talk more about the details. x86 would be easiest to target. I've checked out the repo, built it so far, and indeed some failures but no big deals. Currently paging through to get a hold on what's in there. (I'll be the first to admit I don't know squat about the LLVM compiler).
Re: Adjacent Pairs Range
On Saturday, 12 September 2015 at 10:17:19 UTC, Nordlöw wrote: How do I most elegantly iterate all the adjacent pairs in an `InputRange` using Phobos? Something like [1,2,3,4] => [(1,2), (2,3), (3,4)] Why not just: zip(arr[0 .. $-1], arr[1 .. $]) ?
Re: Operator overloading or alternatives to expression templates
On 09/12/2015 04:08 PM, Martin Nowak wrote: On Friday, 11 September 2015 at 23:47:42 UTC, Andrei Alexandrescu wrote: 1. Use lambdas, which seem to already do what you want: db.get!Person.filter!(p => p.age > 21 && p.name == "Peter") The way this'd go, the db.get!Person() call returns an input range of Person. Presumably introspection is being used to bind fields in the query such as "age" and "name" to static field names in struct Person. Then good old std.algorithm.filter takes care of the rest. I'm instantiating the lambda with a fake p to capture the expression so I can translate it to whatever SQL, MongoDB, columnar db is used. Yah, understood. Problem here is the approach is bound to run into walls at every few steps. Say you fix the comparisons to work. Then you have operators such as LIKE that are necessary yet not representable in D. So more tricks are in order. This is what I've seen with ET in C++ - an endless collection of tricks to achieve modest outcomes at enormous costs. 2. If you want to embed real SQL into D, use string-based DSLs. Strings don't capture context, aren't typechecked, and require a complex CTFE parser. db.get!Person.where!"age > 21 & name = ?"(name); Understood as well. I figure from the example you have binding in mind, which is good. At some point you need to bite the bullet and write a parser for the relational query language you want there. Andrei
Re: Build It And They Will Not Come
On 09/13/2015 08:51 AM, Meta wrote: > It's funny, people are willing to suspend their disbelief for demons > from hell, but not for the lack of a flashlight and duct tape. It's > probably because it was an annoying game mechanic, and taping a > flashlight to a gun is something so simple and mundane that you *can't* > suspend your disbelief at Doom Guy being unable to find a way to use > both at once somehow. Have you ever tried taping 8 different flashlights to 8 different weapons ranging from a pistol to a badass BFG while carrying a light-tank-load of ammunition? I'm not even talking about finding tapes in that demon-infested compound with those jammed office doors that once you open them an imp (in the best case) tries to plasma-whack you! Cut the doom guy some slack! We owe him our very existence! :-) -- Bahman Movaqar signature.asc Description: OpenPGP digital signature
Does a synchronization yield on waiting thread?
It would seem to be the logical thing to do? That is, suppose two threads are sharing a resource. Thread A has it locked. B is "waiting". Is B in a loop burning cycles running in the background(regardless of thread.sleep, which only alleviates the problem) or does it yield completely and somehow inform the lock to resume it when A has unlocked the resources? The first one burns cycles and can have timing problems. I.e., What if A locks and unlocks at the same rate that B checks? (I suppose a random sleep time would help with this) ( "Yielding", OTOH, has B burn no cycles waiting in a loop. This can lead to optimization and prioritization and all that(after an unlock, all the threads waiting can be called, but in what order). Obviously yielding is more complex and requires the threads kept track of(an array for each lock/unlock pair) but far more efficient. I'm hoping D does this, but not holding my breath.
Re: Build It And They Will Not Come
On Saturday, 12 September 2015 at 14:25:46 UTC, Nick Sabalausky wrote: That's pretty similar to how I felt about Doom3: People complained how "unrealistic" it was to not be able to duct tape the flashlight to the gun, but...For crap's sake, it's a game about a demon invasion from hell and one guy single-handedly holding them all off. Realism and believability were obviously never the point. :) 'Course, that game had other issues, but realism (or lack of) was never one of them. But maybe I'm misremembering. Saw it a long time ago. Never saw it myself, but that's what I'd heard it was about. It's funny, people are willing to suspend their disbelief for demons from hell, but not for the lack of a flashlight and duct tape. It's probably because it was an annoying game mechanic, and taping a flashlight to a gun is something so simple and mundane that you *can't* suspend your disbelief at Doom Guy being unable to find a way to use both at once somehow.
Re: Looking for someone that could work on 32 bits support for SDC
On Sunday, 13 September 2015 at 02:19:27 UTC, BBasile wrote: On Wednesday, 9 September 2015 at 20:33:43 UTC, deadalnix wrote: All is in the title. ARM/Mips/pNaCl/WebAssembly require 32bits to work. These are valuable targets IMO. I can provide support, but I just don't have the bandwidth to pull it by myself. If someone could step up, that'd be great. Do you think that libd is 32bit ready ? https://github.com/SDC-Developers/SDC/pull/141 Building on 32 bits and generating 32 bit code are 2 different things. No I don't think libd can compile on a 32 bits system ATM, but I do not expect it to be that far away from being able to do so.
Re: A collection of DIPs
On Friday, 11 September 2015 at 19:30:56 UTC, ponce wrote: Some of us use and need @nogc all the time. The other parts of an application can use the GC: best of both worlds. Is there even a compiler switch to disable GC altogether so the program doesn't have a GC thread? No, I can't see it...
Re: std.allocator ready for some abuse
On Saturday, 12 September 2015 at 06:30:42 UTC, bitwise wrote: On Saturday, 12 September 2015 at 00:31:27 UTC, Andrei Alexandrescu wrote: [...] This sounds like the default setup I'll be using. The containers will use a Mallocator by default, so I will have to add the ranges when the contained type is found to have indirections. [...] Alternatively, GC.addRange() could return a value indicating whether or not the range had actually been added(for the first time) and should be removed. Bit
Difference between back (`) and double (") quoted strings
Is there any or they are just simply syntactically equivalent? Are there any official docs on this? -- Bahman Movaqar http://BahmanM.com - https://twitter.com/bahman__m https://github.com/bahmanm - https://gist.github.com/bahmanm PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) signature.asc Description: OpenPGP digital signature
Re: Multidimension AA's and remove
On Saturday, 12 September 2015 at 05:54:13 UTC, NX wrote: import std.stdio : writeln, std.algorithm.mutation : remove; Ooops, this is so wrong! Corrected version: void main() { import std.stdio : writeln; import std.algorithm.mutation : remove; int[][string] heh = [ "heh":[ 0, 10, 15, 20 ] ]; heh["heh"][0] = 5; writeln(heh); // ["heh":[5, 10, 15, 20]] heh["heh"] = remove!(c => (c == 15))(heh["heh"]); writeln(heh); // ["heh":[5, 10, 20]] }
Re: Better lambdas!!!!!!!!!!
On Friday, 11 September 2015 at 23:15:58 UTC, Jonathan M Davis wrote: style lambdas in D. However, given the complexity of C++ templates, as I understand it, there are no plans to ever support them in C++ interop (since it would pretty much mean putting a C++ compiler in the D compiler), in which case, there's no need to worry about C++ lambdas anyway, because they all involve templates. No, you have to generate c++ sourcecode. No need to build in the compiler.
Re: shared array?
On Friday, September 11, 2015 23:29:05 Laeeth Isharc via Digitalmars-d-learn wrote: > On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe wrote: > > On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote: > >> Oh really?!?! I thought slicing used the GC? Is this a recent > >> development or always been that way? > > > > Always been that way. A D slice is just a C pointer + length > > packed together. A slice simply increments the pointer and/or > > decrements the length - no allocation needed. > > (btw the garbage collector is actually pretty nice, why are you > > avoiding it anyway?) > > Seems to be quite a lot of FUD wrt use of standard library and > GC, which means also perhaps we don't communicate this point very > well as a community. Making Phobos GC-optional perhaps is an > ultimate answer. But people seem to think that you're back to C > without the GC. Aside from the few classes in Phobos, its GC usage is almost entirely restricted to when it allocates arrays or when it has to allocate a closure for a delegate, which can happen in some cases when passing predicates to range-based algorithms. Avoiding functions that need to allocate arrays avoids that source of allocation, and using functors or function pointers as predicates avoids having to allocate closures. So, you _can_ end up with GC allocations accidentally in Phobos if you're not careful, but on the whole, the assertion that Phobos uses the GC heavily is FUD - or at least a misunderstanding. But as we make more of the functions use lazy ranges rather than arrays (particularly with regards to strings), and we make more of the code @nogc, it becomes even clearer that the GC isn't involved. Also, improvements to how lambdas are handled should reduce how often closures have to be allocated for them. Probably the may issue that actually requires a language change is that exceptions currently pretty much have to be GC-allocated whereas they really should be reference-counted (though possibly still GC-allocated, just not left for a garbage collection cycle), but exceptions are thrown rarely, meaning that the fact that they're GC allocated is really only a problem if you're trying to avoid the GC completely rather than just minimize its use, so it's rarely a problem. And there are plans to support reference-counted types in the language, in which case, the exception types would be change to use that Object hierarchy rather than the normal one. So, we have improvements to make, but for the most part, I think that the idea that Phobos requires a GC is FUD. It's not completely false, but folks seem to think using Phobos means heavy GC usage, and for the most part, that's not true at all. - Jonathan M Davis
Re: std.allocator ready for some abuse
On Saturday, 12 September 2015 at 00:31:27 UTC, Andrei Alexandrescu wrote: On 09/11/2015 07:46 PM, bitwise wrote: [...] Say you have a container that uses its own allocator inside, yet offers the user to store objects with indirections that use the GC. Then indeed the container would need to call addRange and removeRange on its own internal structures. This sounds like the default setup I'll be using. The containers will use a Mallocator by default, so I will have to add the ranges when the contained type is found to have indirections. If, on the contrary, the container imposes that its own held objects use the container's allocator as well (a rare but not implausible design), it wouldn't need to do that. I don't understand exactly what you mean, but here is a more verbose version of my concern: Lets say someone's allocator calls GC.addRange on the memory it allocates before a container gets it. The container would call GC.addRange when it gets it, but then call GC.removeRange before calling allocator.deallocate(). The allocator which think's the block has already been registered with the GC could possibly reuse it, thinking it's registered with the GC alreadybut that allocator may pass the memory to a container which chooses not to call GC.addRange, because it thinks it's using an allocator that does that for it. That second container may now store types with indirections, which would be unreachable, and get freed, and..chaos. I suppose that as a general rule, a container could always add ranges it gets from an allocator to the GC, which would prevent the above problem...but only for containers that abide by the rule. It sounds like you're saying that although it may not be needed sometimes, that no harm would be done. I think a better solution though would be for the GC to have something like GC.hasRange(). The container could check the state of the memory it receives and take appropriate action. I don't see anything in the current GC docs which would allow you to tell if a range had already been added to the GC. Bit
[Issue 15026] cannot array assign to a slice return value
https://issues.dlang.org/show_bug.cgi?id=15026 anoneu...@gmail.com changed: What|Removed |Added CC||anoneu...@gmail.com --- Comment #2 from anoneu...@gmail.com --- The first example doesn't look to me like it should compile. Is it not equivalent to this? void test() { (cast(int[]) null) = 2; } The second example works if you use opIndexAssign instead of opSlice: struct Foo { int[] opIndexAssign(int v) { return null; } } void test() { Foo foo; foo[] = 2; } --
Re: How To: Passing curried functions around
On Friday, 11 September 2015 at 21:06:32 UTC, Ali Çehreli wrote: On 09/11/2015 02:04 PM, Ali Çehreli wrote: The same keyword has a different use with templates: And the official documentation: http://dlang.org/template.html#TemplateAliasParameter Thanks again!
Re: Reasons to use D
On Friday, 11 September 2015 at 17:58:49 UTC, bachmeier wrote: On Friday, 11 September 2015 at 14:17:03 UTC, Bahman Movaqar wrote: On Friday, 11 September 2015 at 13:15:03 UTC, Adam D. Ruppe wrote: "3. The documentation poor." I agree but so is the documentation for virtually everything else I've ever used too. I'd take D's over Ruby's for example. Couldn't help but to drop in and count two exceptions: Racket's docs[1] and Java API docs[2]. [1] http://docs.racket-lang.org/ [2] http://docs.oracle.com/javase/7/docs/api/ I'd add Guile. It's fun to read the manual. /me nods Another fun manual is Gforth's.
Re: Difference between back (`) and double (") quoted strings
On Saturday, 12 September 2015 at 08:13:33 UTC, Bahman Movaqar wrote: Is there any or they are just simply syntactically equivalent? Are there any official docs on this? What if I told you, you should search the official reference before asking such things in the forum? http://dlang.org/lex.html#WysiwygString Wysiwyg: What you see is what you get writeln(`\asd"fg"hj hmph'`); \asd"fg"hj haha'
Re: Hello World Example with Glade?
On Friday, 11 September 2015 at 20:29:05 UTC, Mike Wey wrote: You should be able to drop the -L-ldl and -I/usr/ flags, as they are included in the pkg-config output. I just tested and you are correct. Now, is there a way that I can edit /etc/dmd.conf and make it so that I don't need to do this pkg-config stuff all the time?
[Issue 12210] dlang.org home page example - Run button does not work
https://issues.dlang.org/show_bug.cgi?id=12210 --- Comment #9 from Gerald Jansen--- Perhaps this is a slightly different issue but it is related so I'll just mention it here. The example in the section "Convenience" under the paragraph starting with "Automatic memory management makes for safe, simple, and robust code.", crashes with message: Application output: (1 Hangup) Exiting main. std.exception.ErrnoException@std/stdio.d(385): Cannot open file `text.txt' in mode `rb' (No such file or directory) ... and a bunch of incomprehensible junk (for a casual visitor) Having examples that don't run is probably worse than no examples. Perhaps the priority of this issue should be increased. Perhaps the more general issue is how to continuously test and ensure that all example code highlighted on dlang.org runs correctly. --