Re: How to compile against GitHub fork of Phobos?
On Tuesday, 7 March 2017 at 02:30:21 UTC, ketmar wrote: Q. Schroll wrote: On Tuesday, 7 March 2017 at 01:45:48 UTC, Adam D. Ruppe wrote: You pass your modified file to the compiler: dmd yourfile.d format.d The format.d there can be a copy of the one from phobos (or a fork or whatever) and since you passed it explicitly on the command line, it takes precedence over the one in the library. You still import it as std.format. You can do that with as many modules as you like. I just tried it out. dmd myfile.d phobos/std/format.d worked fine, but interestingly, rdmd myfile.d phobos/std/format.d did not. The latter definitely takes format from the library. I have no idea why. rdmd doesn't work like dmd. here, it just passing "phobos/std/format.d" as command line argument to "myfile.d". You're right. I should've known that. By bad ... Thanks for your replies. They were very helpful.
Re: How to compile against GitHub fork of Phobos?
Q. Schroll wrote: On Tuesday, 7 March 2017 at 01:45:48 UTC, Adam D. Ruppe wrote: You pass your modified file to the compiler: dmd yourfile.d format.d The format.d there can be a copy of the one from phobos (or a fork or whatever) and since you passed it explicitly on the command line, it takes precedence over the one in the library. You still import it as std.format. You can do that with as many modules as you like. I just tried it out. dmd myfile.d phobos/std/format.d worked fine, but interestingly, rdmd myfile.d phobos/std/format.d did not. The latter definitely takes format from the library. I have no idea why. rdmd doesn't work like dmd. here, it just passing "phobos/std/format.d" as command line argument to "myfile.d".
Re: How to compile against GitHub fork of Phobos?
On Tuesday, 7 March 2017 at 01:45:48 UTC, Adam D. Ruppe wrote: You pass your modified file to the compiler: dmd yourfile.d format.d The format.d there can be a copy of the one from phobos (or a fork or whatever) and since you passed it explicitly on the command line, it takes precedence over the one in the library. You still import it as std.format. You can do that with as many modules as you like. I just tried it out. dmd myfile.d phobos/std/format.d worked fine, but interestingly, rdmd myfile.d phobos/std/format.d did not. The latter definitely takes format from the library. I have no idea why.
Re: How to compile against GitHub fork of Phobos?
On Tuesday, 7 March 2017 at 01:14:28 UTC, Q. Schroll wrote:
I have a fork of the standard-library in the folder "phobos".
In version 2.072.1 of the compiler, I could use code like
void main()
{
import phobos.std.format;
That should never have worked unless you changed the module
declaration in the format file too...
But if I do so, it imports the one from the standard library
attached to the compiler. Is it a regression? Should the old
version have rejected my code? I don't see any possibility to
test specific changes in modules of my fork.
You pass your modified file to the compiler:
dmd yourfile.d format.d
The format.d there can be a copy of the one from phobos (or a
fork or whatever) and since you passed it explicitly on the
command line, it takes precedence over the one in the library.
You still import it as std.format. You can do that with as many
modules as you like.
How to compile against GitHub fork of Phobos?
I have a fork of the standard-library in the folder "phobos". In
version 2.072.1 of the compiler, I could use code like
void main()
{
import phobos.std.format;
/* code for checking my changes to format */
}
compiled with
$ dmd -I"phobos" test_format.d
in the parent folder of phobos. It worked fine.
I've updated the compiler today and get an error message:
module std.typecons from file phobos\std\typecons.d must be
imported with 'import std.typecons;'
But if I do so, it imports the one from the standard library
attached to the compiler. Is it a regression? Should the old
version have rejected my code? I don't see any possibility to
test specific changes in modules of my fork.
I've just read
https://wiki.dlang.org/Starting_as_a_Contributor#Building_D, but
it didn't help me out.
Re: Writing pattern matching macros in D.
On 2017-03-06 17:27, Deech wrote:
I was thinking something on the order of Scala's pattern matching using
apply/unapply methods. http://www.artima.com/pins1ed/extractors.html.
That should be possible. Although not as a macro and not with the same
nice syntax. Something like this should be possible:
1.match(
3, e => writeln("value is 3"),
(int e) => writeln("value is an integer"),
() => writeln("fallback")
);
--
/Jacob Carlborg
Re: Writing pattern matching macros in D.
On Monday, 6 March 2017 at 08:27:13 UTC, David Nadlinger wrote: On Monday, 6 March 2017 at 02:20:02 UTC, Deech wrote: […] add pattern matching to the language as a macro. D doesn't have macros per se. However, template metaprogramming and mixins can replace them in many cases. Which particular form of pattern matching do you have in mind? You won't get all the way to Haskell (or even Prolog) levels of functionality in a generic way, but for limited use cases, it is definitely possible. — David I was thinking something on the order of Scala's pattern matching using apply/unapply methods. http://www.artima.com/pins1ed/extractors.html.
Re: Why doesn't this chain of ndslices work?
On Sunday, 15 May 2016 at 12:30:03 UTC, Stiff wrote: On Sunday, 15 May 2016 at 08:31:17 UTC, 9il wrote: On Saturday, 14 May 2016 at 21:59:48 UTC, Stiff wrote: Here's the code that doesn't compile: import std.stdio, std.experimental.ndslice, std.range, std.algorithm; [...] Coming soon https://github.com/libmir/mir/issues/213#issuecomment-219271447 --Ilya Awesome, thanks to both of you. I think I can get what I want from mir.sparse. I was aware of it, but hadn't made the connection to what I'm trying to do for some reason. More generally, I'm eagerly looking forward to a more complete Mir. I've been using bindings to GSL for non-uniform (and quasi-) random number generation, and a cleaner interface would be great. I'll be watching on github. Done: http://docs.algorithm.dlang.io/latest/mir_ndslice_stack.html#.stack Sorry for the huge delay!
Re: index of ddocs
On 06/03/2017 11:29, rikki cattermole wrote: > On 06/03/2017 11:25 PM, Christian Köstlin wrote: >> Hi, >> >> I have a small dub-based application project with several modules (it's >> not a vibe.d project). I can easily create ddocs for the modules by >> running dub build --build=docs. >> >> I am missing at the moment a page, that shows the contents of the whole >> package. Did I miss something here? >> >> Best regards, >> Christian > > Nope, DDOC doesn't do that for you[0]. > > [0] https://github.com/dlang/phobos/blob/master/index.d > thanks ... will do accordingly :)
Re: Best memory management D idioms
On Monday, 6 March 2017 at 08:26:53 UTC, Eugene Wissner wrote: The memory management in D is becoming a mess. I am aware this is a hot topic, hence the opening joke. But I just want to learn what toolboxes are currently available, not really discuss how adequate they are, or how often GC is adequate enough. Neither how much % GC-haram Phobos or other libraries are internally atm. There are several threads already discussing this, which I've browsed. My impression so far is that dlib's New/Delete is the most straightforward or efficient tool, and it can kind of cover all the bases (and is GC-halal), as far as I can tell in advance. Plus it has printMemoryLog() as a bonus, which is already better than C++ new/delete. Just an observation that it doesn't provide an option to allocate an uninitialized array, considering that this module is already targeting performance applications. Not sure if I would use any other tool (besides GC itself). I'm curious about Unique but it's not fully clear to me what happens (regarding lifetime, deterministic destruction, GC monitoring) when you need to call "new" to use it.
Re: index of ddocs
On 06/03/2017 11:25 PM, Christian Köstlin wrote: Hi, I have a small dub-based application project with several modules (it's not a vibe.d project). I can easily create ddocs for the modules by running dub build --build=docs. I am missing at the moment a page, that shows the contents of the whole package. Did I miss something here? Best regards, Christian Nope, DDOC doesn't do that for you[0]. [0] https://github.com/dlang/phobos/blob/master/index.d
index of ddocs
Hi, I have a small dub-based application project with several modules (it's not a vibe.d project). I can easily create ddocs for the modules by running dub build --build=docs. I am missing at the moment a page, that shows the contents of the whole package. Did I miss something here? Best regards, Christian
Re: Writing pattern matching macros in D.
On Monday, 6 March 2017 at 02:20:02 UTC, Deech wrote: […] add pattern matching to the language as a macro. D doesn't have macros per se. However, template metaprogramming and mixins can replace them in many cases. Which particular form of pattern matching do you have in mind? You won't get all the way to Haskell (or even Prolog) levels of functionality in a generic way, but for limited use cases, it is definitely possible. — David
Re: Best memory management D idioms
On Sunday, 5 March 2017 at 20:54:06 UTC, XavierAP wrote: I was going to name this thread "SEX!!" but then I thought "best memory management" would get me more reads ;) Anyway now that I have your attention... What I want to learn (not debate) is the currently available types, idioms etc. whenever one wants deterministic memory management. Please do not derail it debating how often deterministic should be preferred to GC or not. Just, whenever one should happen to require it, what are the available means? And how do they compare in your daily use, if any? If you want to post your code samples using special types for manual memory management, that would be great. AFAIK (from here on please correct me wherever I'm wrong) the original D design was, if you don't want to use GC, then malloc() and free() are available from std.c. Pretty solid. I guess the downside is less nice syntax than new/delete, and having to check the returned value instead of exceptions. I guess these were the original reasons why C++ introduced new/delete but I've never been sure. Then from this nice summary [1] I've learned about the existence of new libraries and Phobos modules: std.typecons, Dlib, and std.experimental.allocator. Sadly in this department D starts to look a bit like C++ in that there are too many possible ways to do one certain thing, and what's worse none of them is the "standard" way, and none of them is deprecated atm either. I've just taken a quick look at them, and I was wondering how many people prefer either, and what are their reasons and their experience. dlib.core.memory and dlib.memory lack documentation, but according to this wiki page [2] I found, dlib defines New/Delete substitutes without GC a-la-C++, with the nice addition of a "memoryDebug" version (how ironclad is this to debug every memory leak?) From std.typecons what caught my eye first is scoped() and Unique. std.experimental.allocator sounded quite, well, experimental or advanced, so I stopped reading before trying to wrap my head around all of it. Should I take another look? scoped() seems to work nicely for auto variables, and if I understood it right, not only it provides deterministic management, but allocates statically/in the stack, so it is like C++ without pointers right? Looking into the implementation, I just hope most of that horribly unsafe casting can be taken care of at compile time. The whole thing looks a bit obscure under the hood and in its usage: auto is mandatory or else allocation doesn't hold, but even reflection cannot tell the different at runtime between T and typeof(scoped!T) //eew. Unfortunately this also makes scoped() extremely unwieldy for member variables: their type has to be explicitly declared as typeof(scoped!T), and they cannot be initialized at the declaration. To me this looks like scoped() could be useful in some cases but it looks hardly recommendable to the same extent as the analogous C++ idiom. Then Unique seems to be analogous to C++ unique_ptr, fair enough... Or are there significant differences? Your experience? And am I right in assuming that scoped() and Unique (and dlib.core.memory) prevent the GC from monitoring the memory they manage (just like malloc?), thus also saving those few cycles? This I haven't seen clearly stated in the documentation. [1] http://forum.dlang.org/post/stohzfatiwjzemqoj...@forum.dlang.org [2] https://github.com/gecko0307/dlib/wiki/Manual-Memory-Management The memory management in D is becoming a mess. Yes, D was developed with the GC in mind and the attempts to make it usable without GC came later. Now std has functions that allocate with GC, there're containers that use malloc/free directly or reference counting for the internal storage, and there is std.experimental.allocator. And it doesn't really get better. There is also some effort to add reference counting directly into the language. I really fear we will have soon signatures like "void myfunc() @safe @nogc @norc..". Stuff like RefCounted or Unique are similar to C++ analogues, but not the same. They throw exceptions allocated with GC, factory methods (like Unique.create) use GC to create the object. Also dlib's memory management is a nightmare: some stuff uses "new" and GC, some "New" and "Delete". Some functions allocate memory and returns it and you never know if it will be collected or you should free it, you have to look into the source code each time to see what the function does internally, otherwise you will end up with memory leaks or segmentation faults. dlib has a lot of outdated code that isn't easy to update.
Re: Split Real / Float into Mantissa, Exponent, and Base
On Friday, 3 March 2017 at 18:09:02 UTC, Jonathan M. Wilbur wrote: I have tried to come up with a good way to get the mantissa, exponent, and base from a real number, and I just can't come up with a good cross-platform way of doing it. I know about std.math.frexp(), but that function only gives you another real as the mantissa. I need an integral mantissa, exponent, and base. Is there either (1) a crafty, cross-platform way of doing this or (2) a function in a standard library that does this that I somehow missed? If there is no such function, what are your thoughts on me implementing such a thing and submitting it to Phobos, probably similar to how frexp is implemented (elseifs for each FP format)? See std.bitmanip.FloatRep and std.bitmanip.DoubleRep: https://dlang.org/phobos/std_bitmanip.html#.FloatRep https://dlang.org/phobos/std_bitmanip.html#.DoubleRep
