Re: More radical ideas about gc and reference counting
On Sunday, 4 May 2014 at 22:56:41 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, May 03, 2014 at 10:48:47PM -0500, Caligo via Digitalmars-d wrote: [...] Last but not least, currently there are two main ways for new features to make it into D/Phobos: you either have to belong to the inner circle, or have to represent some corporation that's doing something with D. I'm sorry, but this is patently false. I am neither in the inner circle, nor do I represent any corporation, yet I've had many changes pulled into Phobos (including brand new code). I can't say I'm perfectly happy with the D development process either, but this kind of accusation is bordering on slander, and isn't helping anything. T There is a lot of truth in what Caligo has said, but I would word that part of it differently. A couple years ago I submitted std.rational, but it didn't go anywhere. About a year later I discovered that someone else had done a similar thing, but it never made it into Phobos either. Of course, it's not because we didn't belong to some inner circle, but I think it has to do with the fact that D has a very poor development process. The point being, something as simple as a Rational library shouldn't take years for it to become part of Phobos, specially when people are taking the time to do the work. --Arlen
Re: std.rational?
FWIW, about a year ago I submitted rational module. Here are the links: source: https://github.com/Arlen/phobos/blob/units/std/rational.d docs: http://arlen.github.com/phobos/std_rational.html discussion: http://forum.dlang.org/thread/mailman.579.1349545483.5162.digitalmar...@puremagic.com I think we discussed the issue of BigInt and BigFloat. Personally, I'm not a big fan of BigInt, and rational supporting it. Anyway, I hope you find it useful. Arlen On Wed, Sep 25, 2013 at 11:57 AM, H. S. Teoh hst...@quickfur.ath.cx wrote: Does anybody happen to have a working rational number library in D? Any plans to add that to Phobos at some point? Just wondering, because I'm working on some numerical code that would benefit from a custom number type that could be implemented in terms of rational numbers. I just don't feel like reinventing a rational library if one already exists. :) T -- GEEK = Gatherer of Extremely Enlightening Knowledge
Re: Today's github tip - fixing local master
On Tue, Jun 18, 2013 at 2:41 PM, Walter Bright newshou...@digitalmars.comwrote: I often struggle with understanding how github works. github or git? In any case, have you tried setting up a local and a remote on your local system to try out the commands without the fear of ruining your working repo? You can set up a local and remote on your local computer, and push and pull from them in the same way you do with your local repo and github. Example: mkdir test cd test git init local_repo cd local_repo ... add files, commit, etc. cd ../test git clone --bare local_repo/ remote_repo cd ../local_repo git remote add origin ../remote_repo ... add more changes and commit git push origin master Note, to be able to push, that repo needs to be bare. You can also add a dummy linux user to your local system to play the role of a contributor. Using this kind of setup really helped me understand git better. Alren
Re: DConf 2013 last talk
On Thu, May 2, 2013 at 6:59 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I'll answer community questions in my last talk at DConf 2013, which is about 24 hours from now. Please send yours here or on Twitter #dconf. Andrei 1. How many years must pass before GCC includes a front end for D? 2. Are we going to spend the next 10-20 years writing garbage collectors for D? Arlen
Dfix
Gofix, a tool to mechanically update code to accommodate language and library changes. Mr. Pike talks more about it starting at 8:26 http://www.youtube.com/watch?v=bj9T2c2Xk_sfeature=player_embedded I wish D had such a tool. Any chance?
Re: Migrating dmd to D?
On Wed, Feb 27, 2013 at 6:37 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Hello, Walter and I have had a long conversation about the next radical thing to do to improve D's standing. Like others in this community, we believe it's a good time to consider bootstrapping the compiler. Having the D compiler written in D has quite a few advantages, among which taking advantages of D's features and having a large codebase that would be its own test harness. By this we'd like to initiate a dialog about how this large project can be initiated and driven through completion. Our initial basic ideas are: 1. Implement the dtoh standalone program that takes a D module and generates its corresponding C++ header. 2. Use dtoh to initiate and conduct an incremental port of the compiler. At given points throughout the code D code will coexist and link with C++ code. 3. At a point in the future the last C++ module will be replaced with a D module. Going forward there will be no more need for a C++ compiler to build the compiler (except as a bootstrapping test). It is essential that we get support from the larger community for this. This is a large project that should enjoy strong leadership apart from Walter himself (as he is busy with dynamic library support which is strategic) and robust participation from many of us. Please chime in with ideas on how to make this happen. Thanks, Andrei Having ported Boost.units to D, I can attest to this being a lot of work. I did try translating first and then refactoring the code, but that did not go well, mainly because of all the tricks and hacks employed when doing template meta-programming in C++ that did not translate well at all to D. With my first attempt I pretty much ended up with C++ code that was written in D, and that's not what I wanted. So I had to start over, refactoring and writing D code in D as I went. The problem with refactoring is that once you refactor a piece, chances are that you will need to refactor everything that depends on the code that was refactored, and that starts a domino effect. Of course, things are different with DMD, so translating first and then refactoring is probably the right way to do it. But, I don't see how we could use D's nice features without refactoring. So, I presume this is going to be done in two phases: Phase 1: direct translation to make sure everything works. Phase 2: refactoring to use D's nice features. And your three steps would be describing Phase 1. Arlen
Re: My codebase have reached the critical size
I have the same issue with my Boost.units port: https://github.com/Arlen/phobos/blob/std_units/std/units.d DMD runs out of memory and that's why I've had to comment out most of the definitions. I haven't tried separate compilation, yet. Arlen On Sat, Feb 16, 2013 at 3:37 AM, deadalnix deadal...@gmail.com wrote: And that critical size isn't very large. I cannot compile anymore : Unable to fork: Cannot allocate memory I cannot use separate compilation to mitigate the problem as some symbol are not emitted properly (so I get linker errors). Hopefully, dmd is fast because it doesn't use any GC.
Re: Preliminary submission - std.rational and std.typelist
On Mon, Feb 11, 2013 at 1:05 PM, bearophile bearophileh...@lycos.comwrote: And isn't it better for the Rational constructor to simplify the arguments (calling an optimized GCD)? See this implementation (that doesn't use an optimized GCD): http://rosettacode.org/wiki/**Arithmetic/Rational#Dhttp://rosettacode.org/wiki/Arithmetic/Rational#D Bye, bearophile I ran some benchmarks, and I don't see how the rosetta version is more optimized: https://gist.github.com/Arlen/4947368 And the results on my 64-bit system, compiled with '-O -inline -release': Rosettarational + rational: ms Rosetta immutable rational + rational: 3358 ms stdrational + rational: 2348 ms std immutable rational + rational: 2197 ms Rosettarational - rational: 2822 ms Rosetta immutable rational - rational: 2720 ms stdrational - rational: 1668 ms std immutable rational - rational: 1583 ms Rosettarational * rational: 1628 ms Rosetta immutable rational * rational: 1579 ms stdrational * rational: 1603 ms std immutable rational * rational: 1500 ms Rosettarational / rational: 1636 ms Rosetta immutable rational / rational: 1614 ms stdrational / rational: 1664 ms std immutable rational / rational: 1534 ms Rosettarational == rational: 180 ms Rosetta immutable rational == rational: 176 ms stdrational == rational: 90 ms std immutable rational == rational: 80 ms Arlen
Re: Preliminary submission - std.rational and std.typelist
On Wed, Feb 13, 2013 at 3:48 PM, bearophile bearophileh...@lycos.comwrote: Arlen: I ran some benchmarks, and I don't see how the rosetta version is more optimized: My message says See this implementation (that doesn't use an optimized GCD):. I have never said that code is more optimized. What I have said is that your version probably should simplify its arguments inside the constructor, possibly with an optimized GCD. Bye, bearophile Sorry, I misread what you said. Maybe you mean something different by simplify its arguments, but my version _does_ simplify its arguments inside the constructor. As for an optimized GCD, are you talking about binary GCD? Arlen
Re: Preliminary submission - std.rational and std.typelist
Just a quick update: I have made Rational nothrow, fixed toString, and some other minor changes. For the past several months I've used Rational extensively in units (see my other thread), and it works great. source: https://github.com/Arlen/phobos/blob/std_rational/std/rational.d docs: http://arlen.github.com/phobos/std_rational.html What would be the next step, a formal review? Arlen
Boost.units ported to D
Greetings, source: https://github.com/Arlen/phobos/blob/std_units/std/units.d docs: http://arlen.github.com/phobos/std_units.html you will also need the rational module, source: https://github.com/Arlen/phobos/blob/std_rational/std/rational.d docs: http://arlen.github.com/phobos/std_rational.html There is still some work to be done, so I'm calling it an alpha release. I don't know if it belongs in Phobos or not, but I hope others will find it useful as I have. External Issues: 1. Many of the definitions of the systems have been commented out (starting line 3217) because during compilation DMD runs out of memory. As it is, on my system DMD consume nearly 2GB of ram. As a side note, the definitions should be in their own separate modules, but for now they are placed in structs. 2. Very long and not so helpful error messages. When I say long I'm talking hundreds and sometimes thousands of lines of error messages produced by DMD. Bugs in D: If you grep for D_BUG_ you will find several potential bugs that I've marked. I would appreciate it if someone could take a look. FIXMEs: There are a number of FIXMEs, and at the moment I don't have the best solution for them. You will find them if you grep for FIXME_, with FIXME_6 being the most important one. And then there are the potential bugs in Boost.units, which you will find in the very last part of the units.d module. I have posted several of them on stackoverflow. I have also emailed the original authors and waiting to hear from them. #4 is holding back the completion of Absolute, which also affect Quantity. I'm considering removing Absolute altogether. And finally, there is the function convert (line 3666). It needs some cleanup, but this is the function used to explicitly convert from a quantity to another. I haven't decided on the actual syntax yet, but in Boost.units casting is used (e.g., quantitycgs::length L1 = static_castquantitycgs::length (L2)). Any ideas? Arlen
Re: Boost.units ported to D
On Mon, Feb 11, 2013 at 1:19 PM, Michael p...@m1xa.com wrote: It is possible write something like? auto force = 2.0 * SI.Newton; auto energy = force * 2.0 * SI.Meter; Yes because typeof(2.0 * si.newton) is Quantity!(si.Force) and typeof(force * 2.0 * si.meter) is Quantity!(si.Energy). In the future when the unit systems are placed in their own modules, you could alias away and say: auto force = 2.0 * newton; auto energy = force * 2.0 * meters; Also note, 'newton' and 'meter' are instances of Unit. You could define your own and give whatever name you like. For example: si.Length myMeter; auto x = 3.0 * myMeter; writeln(x); // prints '3 m' In std.units I had to make the instances manifest constants (using instanceOf mixin) because they are in structs. That will probably change in the future if each system is placed in its own module. In that case std.unit will have to become a package, and I'm not sure if packages are allowed in Phobos. Anyone know?
Re: Preliminary submission - std.rational and std.typelist
On Mon, Feb 11, 2013 at 1:05 PM, bearophile bearophileh...@lycos.comwrote: A Rational should accept T as BigInt too. Bye, bearophile Rational doesn't support BigInt because the necessary math functions do not support BigInt. And if you are going to have Rational support BigInt, you are most likely going to need BigFloat, which is something we don't have. I personally do not like BigInt because it is incomplete, and because it is reinventing the wheel. I much rather see Phobos provide an interface to GMP, MPFR, or some other arbitrary precision arithmetic library, similar to what you see with Haskell and Python. Arlen
Re: Boost.units ported to D
On Mon, Feb 11, 2013 at 4:18 PM, develop32 develo...@gmail.com wrote: How about something like meters!15 or newtons!30? For me it is more pleasing and shorter than multiplication. 'meters!15' is supposed to be '15 * meters', right? Then how would you express '15 / meters' ? You cannot; therefore, 'meters!15' doesn't make sense. 15 * meters, has an outupt '15 m' which is short for '15 m^1'. The exponent is not shown when it's 1. 15 / meters, has an output '15 m^-1'
Re: Preliminary submission - std.rational and std.typelist
On Mon, Oct 8, 2012 at 2:08 AM, Simen Kjaeraas simen.kja...@gmail.com wrote: On 2012-44-08 06:10, Arlen arlen...@gmx.com wrote: 1. To convert a BigInt to floating-point one needs to convert it to the built-in integer types first. If you go beyond the limits of the built-in types (long), then what's the point? You might as well be using int or long. I thought (part of) the point of Rational was to use it when it would be more fitting than floating-point. If it's only there to be converted to floating-point, I don't know what it's there for. Some computations with rational numbers produce irrational numbers, and to store irrational numbers you need real numbers. What do we do in those cases? As for a workaround, right-shift num and den to reasonable values (which fit in a long), divide to get a float, and multiply by 2.0^^(log2(num)-log2(den)). Oughta work. 2. The functions in std.math don't support BigInt, and most likely never will. Even if they did, you would still need multi-precision floating point to store the irrational numbers. If you decided to use the built-in types, then again what's the point? You might as well go with int or long. The only function you use from std.math is abs, right? That should be fairly easy to implement for BigInt. It'd mean you'd have to specialize a bit for BigInt, though (just create your own abs function that calls the correct one). Yes, std.math.abs and std.numeric.gcd are very easy to implement for BigInt, but I'm not talking about those. I'm talking about things like std.math.pow(), and std.math.log().
Re: Preliminary submission - std.rational and std.typelist
On Mon, Oct 8, 2012 at 4:37 PM, bearophile bearophileh...@lycos.com wrote:
Arlen:
Yes, std.math.abs and std.numeric.gcd are very easy to implement for
BigInt,
Don doesn't agree regarding the gcd. To compute the gcd efficiently on large
numbers you need not easy algorithms.
See:
http://d.puremagic.com/issues/show_bug.cgi?id=7102
Bye,
bearophile
gcd() is very easy to implement:
BigInt _gcd(BigInt a, BigInt b)
{
enforce(a = 0 b =0);
while (b != 0) {
auto t = b;
b = a % b;
a = t;
}
return a;
}
It's not going to be the fastest or the most efficient, but it does
produce correct results, and that's the most important thing when
implementing mathematical functions IMO. You can always improve the
performance later. Implementing pow(), on the other hand, is very
difficult and complex.
Re: Preliminary submission - std.rational and std.typelist
On Sun, Oct 7, 2012 at 2:23 AM, Philippe Sigaud
philippe.sig...@gmail.com wrote:
Double-stage templates (which reminds me of rocket science :) )
template Merge(A...)
{
template With(B...)
{ }
}
Usage:
Merge!(int,double,string).With!(double,byte)
I can live with that, but, as I explained before, TypeTuples cause
code duplication in certain cases because they force 'alias' to be
used in the signature of the metafunctions.
And how would you return a multi-dimensional TypeTuple? The result of
certain metafunctions are multi-dimensional. For example,
Permutations and Combinations will return multi-dimensional
containers.
http://arlen.github.com/phobos/std_typelist2.html#Permutations
Re: Preliminary submission - std.rational and std.typelist
On Sat, Oct 6, 2012 at 1:32 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote: Cool, does it work with BigInt? No it doesn't work with BigInt, but I did look into it today briefly. There are issues with BigInt that I'm not sure what to do about: 1. To convert a BigInt to floating-point one needs to convert it to the built-in integer types first. If you go beyond the limits of the built-in types (long), then what's the point? You might as well be using int or long. 2. The functions in std.math don't support BigInt, and most likely never will. Even if they did, you would still need multi-precision floating point to store the irrational numbers. If you decided to use the built-in types, then again what's the point? You might as well go with int or long. Also I think there is better version of toString that has signature: void toString(scope void delegate(const(char)[]) sink) this toString just use functions like formattedWrite to write chars to sink. It thus totally avoids overhead of allocating strings. Your current code may have some bad impact on performance: return ( ~ to!string(res.numerator) ~ / ~ to!string(res.denominator) ~ ); Allocates 4 times. ~ operator is convenient shortcut to get job done but it's unsuitable for building strings and formatted output. Thanks, I'll fix it.
Re: Preliminary submission - std.rational and std.typelist
On Sun, Oct 7, 2012 at 11:16 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: While this sort of function might be useful from time to time, how often is it actually, realistically needed? Certainly, I'd argue that it's rare enough that having a slightly more complicated solution specifically for it makes more sense than adding a whole new abstraction to the standard library. That particular metafunction may not have a lot of usage, I agree, but I was trying to make the point that TypeTuples do not support multi-dimensions. For example, in the Boost.units library that I'm porting to D, multi-dimensional typelist are common. To solve algebraic equations of types can require matrices, and to implement a matrix you'll need a typelist of typelist. So, we're not adding TypeList. Oh, I was aware that a decision had already been made. I thought it was an open issue. While I sympathize with your desire to get some of the functionality that TypeList provides and TypeTuple doesn't, please work with us to improve upon TypeTuple rather than trying to add something to Phobos that does almost the same thing as TypeTuple. In most cases, it's simply a matter of adding the appropriate templates to gain TypeList-like functionality on top of TypeTuple rather than adding TypeList, and we've even recently added (post-2.060) some of those templates to std.typetuple, thereby improving what can be done with std.typetuple. - Jonathan M Davis Since TypeList is out of the question, I need to figure out what to do with the units library first.
Preliminary submission - std.rational and std.typelist
Greetings, In one of my D projects a units library was needed, so I decided to port Boost.Units to D. I've been working on it for the past month or so (mostly on the weekends), and It's about 90% done. The work has also produced additional functionality not yet available in Phobos, so I've decided to separate them into their own modules and present them here as my preliminary submission. At the time I wasn't aware of the Boost submission process, otherwise I would have done Determine Interest first. Hopefully nobody has ported Boost.Units to D. So far the completion of the units library is contingent on the finalization of the design and implementation of the following two modules: std.rational, which is a small module for rational numbers. Source: https://github.com/Arlen/phobos/blob/units/std/rational.d Docs: http://arlen.github.com/phobos/std_rational.html std.typelist, which provides the TypeList type and several metafunctions. The metafunctions are pretty much stolen from Haskell. Source: https://github.com/Arlen/phobos/blob/units/std/typelist2.d Docs: http://arlen.github.com/phobos/std_typelist2.html I wasn't aware that we already had std.typelist module in Phobos until I was ready to submit my work. I suppose the work was abandoned or it was never finalized? There are differences in typelist2.d and typelist.d, though. I would be interested to know if there is any interest in a units library. I certainly need it in my project, and I will make my preliminary submission available to the community once it's complete. Thanks, Arlen
Re: Preliminary submission - std.rational and std.typelist
I'm not sure if TypeTuples work well when doing things like dimensional
analysis. For example, if you have two TypeTuples, A and B, what would the
signature of the metafunction to merge the two look like?
template Merge(A, B) { }
won't work, and neither will
template Merge(alias A, alias B) { }
and you certainly can't do something like
template Merge(AB...) { }
Arlen
- Original Message -
From: Jonathan M Davis
Sent: 10/06/12 12:52 PM
To: digitalmars.D
Subject: Re: Preliminary submission - std.rational and std.typelist
On Saturday, October 06, 2012 19:03:39 Arlen wrote:
I wasn't aware that we already had std.typelist module in Phobos until I was
ready to submit my work. I suppose the work was abandoned or it was never
finalized? There are differences in typelist2.d and typelist.d, though.
It needs to be removed. It's not even compiled in. std.typetuple is what we
use. I would suggest looking at adding further functionality to it rather than
trying to create anything based on type lists. TypeTuples can do the same
things and are actually more flexible.
- Jonathan M Davis
Re: Preliminary submission - std.rational and std.typelist
There are many unittests, but std.rational doesn't work with BigInts. It only works with signed integrals because I wasn't sure how to deal with the overflow problem. - Original Message - From: bearophile Sent: 10/06/12 12:54 PM To: digitalmars-d@puremagic.com Subject: Re: Preliminary submission - std.rational and std.typelist I'd like a Rational in Phobos. Have you tested it (in unittests) widely with Bigints? Bye, bearophile
Re: Preliminary submission - std.rational and std.typelist
I'll have more to say about the design in the future. At the moment for me porting Boost.Units to D is the fastest and the safest path to take. Besides, the math behind it is sound and and many years of hard work has gone into it. The problem with it, in my opionion, is that it's implemented in C++, :-). I do want to mention that the distinction between dimension and unit is important. I rather see this: Quantity!(length, float) a = 2 * metre; than this: Quantity!(metre, float) a = 2 * metre; I'll spend more time going over you library once I have some free time. Thanks, Arlen - Original Message - From: David Nadlinger Sent: 10/06/12 12:58 PM To: digitalmars-d@puremagic.com Subject: Re: Preliminary submission - std.rational and std.typelist I wrote a units library in D last year: http://klickverbot.at/code/units/. Before setting out, I extensively researched existing solutions in other languages, Boost.Units being on of them, and I believe that I managed to come up with a design which takes advantage of D's advanced metaprogramming capabilities, and as such is more powerful while being much less clunky. For example, in comparison to Boost.Units, I didn't introduce a notion of dimension separate from the concept of units, which seemed to ultimately serve no purpose besides making valid conversions easier to determine given the limitations of C++. I'd love to hear your comments on the design! David
Re: Preliminary submission - std.rational and std.typelist
- Original Message -
From: David Nadlinger
Sent: 10/06/12 01:08 PM
To: digitalmars-d@puremagic.com
Subject: Re: Preliminary submission - std.rational and std.typelist
In my experience, these cases occur a lot less frequently than
one might think when first encountering the problem. The solution
I usually go for is to just define a ConfinedTuple (or something
like that) template:
---
template ConfinedTuple(T...) {
alias T Tuple;
}
template SomeAlgorithm(alias A, alias B) {}
---
Then, call that one algorithm using
SomeAlgorithm!(ConfinedTuple!A, ConfinedTuple!B). At least to me,
it seems to be the better tradeoff compared to re-implementing
all the TypeTuple functionality for another compile-time tuple
type.
David
That does solve the initial problem, but it creates problems of its own.
The initial implementation of TypeList looked like this, which is same as your
ConfinedTuple:
template TypeList(T...)
{
alias T items;
}
but the problem with this is that it forces you to use 'alias' in the
signature, which in turn causes code duplication later on. You need both of
these if you want, for example, fold to work with n-dimensional typelists:
template Foldl(alias Fun, Z, alias TL) { }
template Foldl(alias Fun, alias Z, alias TL) { } // when Z is a TypeList
Thanks,
Arlen
Re: Preliminary submission - std.rational and std.typelist
Testing...
Re: Preliminary submission - std.rational and std.typelist
On Sat, Oct 6, 2012 at 3:53 PM, David Nadlinger s...@klickverbot.at wrote:
On Saturday, 6 October 2012 at 20:00:47 UTC, Arlen wrote:
You need both of these if you want, for example, fold to work with
n-dimensional typelists:
template Foldl(alias Fun, Z, alias TL) { }
template Foldl(alias Fun, alias Z, alias TL) { } // when Z is a TypeList
I'm not quite sure what you mean, as the parameter names are not quite
telling. When would the first overload be needed? Actually, I'm reasonably
sure that there is a solution to whatever problem you might be encountering –
if maybe not obvious unless you have already learned the ins and outs of D
metaprogramming the hard way. ;)
#1
template Foldl(alias Fun, Z, alias TL) { }
This is called when dealing with 1-dimensional typelists. For example:
alias Foldl!(MyFun, char, TL) R1; // where TL is, e.g.,
TypeList!(int, char, double)
#2
template Foldl(alias Fun, alias Z, alias TL) { }
This is called when dealing with 2-dimensions or higher. For example:
alias Foldl!(MyFun, TL1, TL2) R2; // where TL1 is 1-dimensional,
e.g., TypeList!(int, char), and TL2 is 2-dimensional, e.g.,
TypeList!(TypeList!(int, char), TypeList!(float, double)).
I hope that's clear.
Another problem with this is that, when the time comes to implement
MyFun, chances are you will need to implement two versions of it, just
like the Foldl example above. Making TypeList a struct instead of a
template fixed all these problem. Maybe there another solution, but
that's what I could come up with.
By the way, could you please fix the threading behavior of your mail client?
At the moment, all of your replies create a new topic on the NG web interface
(forum.dlang.org), which makes the conversation somewhat hard to follow.
Sorry about that. I think it's fixed now.
David
