Re: bigfloat II
Paul D. Anderson wrote: > Multiplying two floats produces a number whose potential precision is the sum > of the operands' precision. We need a method to determine what the precision > of the product should be. Not that it's difficult to come up with an answer > -- but we have to agree on something. Not more precision than the input data deserve. The decimal floating-point numbers of the new IEEE 754-2008 carry with them a notion of “how precise is this result?”; this might be a good starting point for discussion. —Joel Salomon
Re: The new, new phobos sneak preview
Bill Baxter wrote: On Sun, Apr 12, 2009 at 5:50 AM, Andrei Alexandrescu wrote: Lars Kyllingstad wrote: I think isInfinite!() should be called isInfiniteRange!(). The current name is, in my opinion, too general. I'm undecided about this (and similar cases). isInfinite sits inside std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange feels redundant. On the other hand, I don't want to use too common symbols because then the user will be forced to prefix them whenever they clash. This is one of the big reasons why "static import" by default would have been better than pull-everything-in by default. But since pull-everything-in *is* the default. I agree with Lars. Symbols supplied by modules should look unambiguous even when undecorated by their module name. Or you could use the trick that Tango often uses -- make a static struct with a few members. It's pretty ugly though, if you ask me. Introducing a static struct just to get a namespace to replace the namespace that is already there but gets stripped as the default action upon 'import'. Ick. This could be easily fixed by changing the import statement such, that the module name is used as namespace: import some.mypackage.mymodule; mymodule.somefunctionfrommymodule(); This is a bit different from static imports, that require the full package path, and it's exactly like you use Tango modules. --bb
Re: The new, new phobos sneak preview
Bill Baxter Wrote: > On Sun, Apr 12, 2009 at 5:50 AM, Andrei Alexandrescu > wrote: > > Lars Kyllingstad wrote: > >> I think isInfinite!() should be called isInfiniteRange!(). The current > >> name is, in my opinion, too general. > > > > I'm undecided about this (and similar cases). isInfinite sits inside > > std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange > > feels redundant. On the other hand, I don't want to use too common symbols > > because then the user will be forced to prefix them whenever they clash. > > This is one of the big reasons why "static import" by default would > have been better than pull-everything-in by default. > > But since pull-everything-in *is* the default. I agree with Lars. > Symbols supplied by modules should look unambiguous even when > undecorated by their module name. Or you could use the trick that > Tango often uses -- make a static struct with a few members. It's > pretty ugly though, if you ask me. Introducing a static struct just > to get a namespace to replace the namespace that is already there but > gets stripped as the default action upon 'import'. Ick. > > --bb There's no need for imported names to be unambiguous. Users can give aliases to imports or import specific members. I hate how Tango puts stuff in structs for no good reason
Re: The new, new phobos sneak preview
On Sun, Apr 12, 2009 at 5:50 AM, Andrei Alexandrescu wrote: > Lars Kyllingstad wrote: >> I think isInfinite!() should be called isInfiniteRange!(). The current >> name is, in my opinion, too general. > > I'm undecided about this (and similar cases). isInfinite sits inside > std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange > feels redundant. On the other hand, I don't want to use too common symbols > because then the user will be forced to prefix them whenever they clash. This is one of the big reasons why "static import" by default would have been better than pull-everything-in by default. But since pull-everything-in *is* the default. I agree with Lars. Symbols supplied by modules should look unambiguous even when undecorated by their module name. Or you could use the trick that Tango often uses -- make a static struct with a few members. It's pretty ugly though, if you ask me. Introducing a static struct just to get a namespace to replace the namespace that is already there but gets stripped as the default action upon 'import'. Ick. --bb
Re: The new, new phobos sneak preview
Michel Fortin wrote: On 2009-04-11 20:33:15 -0400, Michel Fortin said: Compile time expressions, just like in a static assert and a static if? StaticTuple, obviously. I would add that StaticTuple justifies perfectly the use of "Tuple" as a name for runtime expression tuples (because non-static ifs and asserts take runtime expressions). That sounds good to me. If nobody opposes it, I'll make the change. I also made a lot of breaking changes (capitalization) in std.date. The idea is to take the hit once (with the next release) and then have improved overall stability. Andrei
Re: The new, new phobos sneak preview
Jarrett Billingsley wrote: On Sat, Apr 11, 2009 at 7:36 PM, Andrei Alexandrescu wrote: I wonder what a good name would be. How about... umm... oh I don't know. "Tuple"? Tuple is taken by tuples. Andrei
Re: The new, new phobos sneak preview
On 2009-04-11 20:33:15 -0400, Michel Fortin said: Compile time expressions, just like in a static assert and a static if? StaticTuple, obviously. I would add that StaticTuple justifies perfectly the use of "Tuple" as a name for runtime expression tuples (because non-static ifs and asserts take runtime expressions). -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: The new, new phobos sneak preview
On 2009-04-11 19:36:36 -0400, Andrei Alexandrescu said: Frits van Bommel wrote: Andrei Alexandrescu wrote: Frits van Bommel wrote: Andrei Alexandrescu wrote: alias TypeTuple!(GENERIC_READ, FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN, HANDLE.init) defaults; How is that a type-tuple? (As far as I can see, none of those are types...) TypeTuple is a misnomer. A TypeTuple can contain not only types, but also compile-time expressions. I know, that's what I was pointing out :). I figure, you've got commit access to Phobos... I wonder what a good name would be. Compile time expressions, just like in a static assert and a static if? StaticTuple, obviously. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: The new, new phobos sneak preview
Jarrett Billingsley wrote: On Sat, Apr 11, 2009 at 7:36 PM, Andrei Alexandrescu wrote: I wonder what a good name would be. How about... umm... oh I don't know. "Tuple"? That name is already taken. http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/typecons.d#L337
Re: The new, new phobos sneak preview
On Sat, Apr 11, 2009 at 7:36 PM, Andrei Alexandrescu wrote: > > I wonder what a good name would be. How about... umm... oh I don't know. "Tuple"?
Re: The new, new phobos sneak preview
Frits van Bommel wrote: Andrei Alexandrescu wrote: Frits van Bommel wrote: Andrei Alexandrescu wrote: alias TypeTuple!(GENERIC_READ, FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN, HANDLE.init) defaults; How is that a type-tuple? (As far as I can see, none of those are types...) TypeTuple is a misnomer. A TypeTuple can contain not only types, but also compile-time expressions. I know, that's what I was pointing out :). I figure, you've got commit access to Phobos... I wonder what a good name would be. Andrei
Re: The new, new phobos sneak preview
Andrei Alexandrescu wrote: Frits van Bommel wrote: Andrei Alexandrescu wrote: alias TypeTuple!(GENERIC_READ, FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN, HANDLE.init) defaults; How is that a type-tuple? (As far as I can see, none of those are types...) TypeTuple is a misnomer. A TypeTuple can contain not only types, but also compile-time expressions. I know, that's what I was pointing out :). I figure, you've got commit access to Phobos...
Re: Linux Shared Library Fun
jeff wrote: So, I've been messing around with creating shared libraries in D and then dynamically loading them into another D program and calling the functions. Thus far this is very simple: just using a function that prints "hello" in the library and then the main program loads it. This whole thing works perfectly if the library is created in C and compiled into a .so with gcc. Fun problems arise when I try to compile the library in D with gdc (since dmd does not support creation of libraries under Linux... which makes me sad). The compilation and creation of the library itself is fine... However, when I try to load the library in the main program it comes up with this fun error: ./testlib.so: undefined symbol: __data_start I'm using dlopen, dlsym, etc to pull stuff from the library. I also tried std.loader but since it's basically a front-end to dlopen the same error occurs. nm indeed shows that __data_start is undefined in the compiled D library. I've tried lazy binding and that does not solve the problem either. Any ideas would be appreciated. And also I apologize profusely in advance if this isn't the proper newsgroup to put this in...
Linux Shared Library Fun
So, I've been messing around with creating shared libraries in D and then dynamically loading them into another D program and calling the functions. Thus far this is very simple: just using a function that prints "hello" in the library and then the main program loads it. This whole thing works perfectly if the library is created in C and compiled into a .so with gcc. Fun problems arise when I try to compile the library in D with gdc (since dmd does not support creation of libraries under Linux... which makes me sad). The compilation and creation of the library itself is fine... However, when I try to load the library in the main program it comes up with this fun error: ./testlib.so: undefined symbol: __data_start I'm using dlopen, dlsym, etc to pull stuff from the library. I also tried std.loader but since it's basically a front-end to dlopen the same error occurs. nm indeed shows that __data_start is undefined in the compiled D library. I've tried lazy binding and that does not solve the problem either. Any ideas would be appreciated.
Re: The new, new phobos sneak preview
Frits van Bommel wrote: Andrei Alexandrescu wrote: alias TypeTuple!(GENERIC_READ, FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN, HANDLE.init) defaults; How is that a type-tuple? (As far as I can see, none of those are types...) TypeTuple is a misnomer. A TypeTuple can contain not only types, but also compile-time expressions. Andrei
Re: The new, new phobos sneak preview
Andrei Alexandrescu wrote: alias TypeTuple!(GENERIC_READ, FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN, HANDLE.init) defaults; How is that a type-tuple? (As far as I can see, none of those are types...)
Re: The new, new phobos sneak preview
Lars Kyllingstad wrote:
Andrei Alexandrescu wrote:
Hi everybody,
I just committed all of Phobos into svn on dsource.org. That is not an
official release and has known and unknown bugs, limitations, and
rhinodemons. I expect some ripples before we stabilize, but when we will
we'll stabilize at a higher potential.
Some corrections/suggestions to std.range, if you are ready for such yet:
Thanks!
From the documentation it seems that the function series() is meant to
be called recurrence(). (Personally I think recursiveSequence() is more
fitting.)
Fixed. (I'm trying to stay with one-word names when possible.)
The function sequence() is missing from the documentation, only struct
Sequence is listed. Guess there should be a ///ditto in there.
Oops... fixed.
I think isInfinite!() should be called isInfiniteRange!(). The current
name is, in my opinion, too general.
I'm undecided about this (and similar cases). isInfinite sits inside
std.range, so std.range.isInfinite is clear and
std.range.isInfiniteRange feels redundant. On the other hand, I don't
want to use too common symbols because then the user will be forced to
prefix them whenever they clash.
I fixed everything and checked in. Speaking of which, I'd be glad if
interested people could take a look at std.file and compare it against
the old:
http://dsource.org/projects/phobos/browser/trunk/phobos/std/file.d
Previously many phobos modules, e.g. std.file, looked like this:
version(Windows)
{
... big chunk ...
}
version(Posix)
{
... big chunk ...
}
The advantage of this approach is that it keeps platform-specific code
together. The disadvantage is that it encourages code duplication. I
found that about 25% of the functions inside std.file actually were not
platform dependent; they essentially were duplicated verbatim.
So I suggest we change this to per-declaration granularity where it
makes sense:
/**
Doc for read...
*/
version(Windows) void[] read(in char[] filename, void[] data) { ... }
version(Posix) void[] read(in char[] filename, void[] data) { ... }
The current std.file implements this alternative factoring and initial
experience seems to suggest it works fine. Also, the code got smaller by
18%. This must also because I got rid of all goto's :o).
By the way, here's a neat trick I think may be used in other situations
as well: factoring some constant function arguments together.
version(Windows) void[] read(in char[] name)
{
alias TypeTuple!(GENERIC_READ,
FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,
HANDLE.init)
defaults;
auto h = useWfuncs
? CreateFileW(std.utf.toUTF16z(name), defaults)
: CreateFileA(toMBSz(name), defaults);
...
}
The previous code duplicated all those arguments.
Andrei
Re: The new, new phobos sneak preview
Andrei Alexandrescu wrote: Hi everybody, I just committed all of Phobos into svn on dsource.org. That is not an official release and has known and unknown bugs, limitations, and rhinodemons. I expect some ripples before we stabilize, but when we will we'll stabilize at a higher potential. Some corrections/suggestions to std.range, if you are ready for such yet: From the documentation it seems that the function series() is meant to be called recurrence(). (Personally I think recursiveSequence() is more fitting.) The function sequence() is missing from the documentation, only struct Sequence is listed. Guess there should be a ///ditto in there. I think isInfinite!() should be called isInfiniteRange!(). The current name is, in my opinion, too general. -Lars
Re: Std Phobos 2 and logging library?
On Sat, 11 Apr 2009 12:12:07 -0400, Sean Kelly wrote: Robert Jacques wrote: On that note, support for per thread GCs in general is another major change. i.e.: GC.malloc!(T)(); to Thread.getThis.gc.malloc!(T)(); // Alternatively use thread local storage. It can remain as GC.malloc(). Exposing a GC handle via thread would allow one thread to use another thread's GC. Yeah, after a night's sleep I realized that GC.malloc() could just wrap the underlying implementation. P.S. The post was meant to illustrate the under-the-hood changes (i.e. not public), but didn't come out that way.
Re: weird behavior for machine epsilon in float, double and real
Andrew Spott wrote: So, for the following code, I get something I think is a little off. I get the same value for all three variable types. I'm kind of new to this, but I would think that a 32 bit would give me a different "smallest value" than a 64 bit or 80 bit (if real even evaluates to 80 bit on my machine). What am I doing wrong, or is this a bug? The expression: (ep + n != n) is evaluated at 80 bit precision, regardless of the size of its operands. The idea is that the floating point sizes only specify a minimum precision, and the compiler (where it makes sense) can use a larger precision to do constant folding and/or for intermediate values. If you need the epsilon values, use float.epsilon, double.epsilon, and real.epsilon.
Re: Std Phobos 2 and logging library?
Zz wrote: Andrei Alexandrescu Wrote: Frank Benoit wrote: Andrei Alexandrescu schrieb: Zz wrote: Hi, Are there any plans for a logging library in Std Phobos 2.0? Zz I wanted to add logging support for a while now but am undecided about the API to use. Log4J is quite popular but quite complicated. There are a number of simpler APIs out there but I couldn't figure out which is the best. If anyone has ideas and/or code to contribute, that would be great. Andrei Why not start with the one from tango? Because it's not my code and every discussion on licensing ends up confused. What we can do in Phobos is following e.g. the Log4J API, which as far as I understand Tango implements or at least draws inspiration from. But then by browsing this group a while ago I figured that Tango added a Trace module because some people deemed the logging API too complicated. Why has everything to be different? Nobody said it has to be different. If it really is not important, why do you have to make it different than tango? Every code that uses tango and phobos, or wants to support both has to reimplemnent an intermediate abstraction layer. Again, I don't *have* to make it different, but I can't *copy* it either. There are two other things to consider: (a) Phobos' logging can take advantage of D2 features; (b) Phobos' logging should be well integrated with the rest of itself, e.g. it may be odd to have one way to format things in stdio and an entirely different way in the log, or to have the logging infrastructure incompatible with the stream infrastructure. That all being said, I don't see a lot of point in making Phobos' logging 100% identical with Tango's. Phobos2 and Tango2 will be usable together, so there's no point in the duplication - if you want Tango's logging mechanism, you just use it. So there will be no point in "supporting both" because both can coexist. Andrei It would be good to have one that makes use of D2's features have you looked at "simple-log", I'm not a java programmer but I do know some people who seem to like it more than Log4J. here is the link https://simple-log.dev.java.net/ Anyway whatever the API looks like one would be welcome. Zz That looks interesting, thanks for the pointer. Andrei
Re: Std Phobos 2 and logging library?
Andrei Alexandrescu Wrote: > Frank Benoit wrote: > > Andrei Alexandrescu schrieb: > >> Zz wrote: > >>> Hi, > >>> > >>> Are there any plans for a logging library in Std Phobos 2.0? > >>> > >>> Zz > >> I wanted to add logging support for a while now but am undecided about > >> the API to use. Log4J is quite popular but quite complicated. There are > >> a number of simpler APIs out there but I couldn't figure out which is > >> the best. > >> > >> If anyone has ideas and/or code to contribute, that would be great. > >> > >> > >> Andrei > > > > Why not start with the one from tango? > > Because it's not my code and every discussion on licensing ends up > confused. What we can do in Phobos is following e.g. the Log4J API, > which as far as I understand Tango implements or at least draws > inspiration from. But then by browsing this group a while ago I figured > that Tango added a Trace module because some people deemed the logging > API too complicated. > > > Why has everything to be > > different? > > Nobody said it has to be different. > > > If it really is not important, why do you have to make it > > different than tango? Every code that uses tango and phobos, or wants to > > support both has to reimplemnent an intermediate abstraction layer. > > Again, I don't *have* to make it different, but I can't *copy* it > either. There are two other things to consider: (a) Phobos' logging can > take advantage of D2 features; (b) Phobos' logging should be well > integrated with the rest of itself, e.g. it may be odd to have one way > to format things in stdio and an entirely different way in the log, or > to have the logging infrastructure incompatible with the stream > infrastructure. > > That all being said, I don't see a lot of point in making Phobos' > logging 100% identical with Tango's. Phobos2 and Tango2 will be usable > together, so there's no point in the duplication - if you want Tango's > logging mechanism, you just use it. So there will be no point in > "supporting both" because both can coexist. > > > Andrei It would be good to have one that makes use of D2's features have you looked at "simple-log", I'm not a java programmer but I do know some people who seem to like it more than Log4J. here is the link https://simple-log.dev.java.net/ Anyway whatever the API looks like one would be welcome. Zz
Re: The new, new phobos sneak preview
Lars Kyllingstad wrote: Andrei Alexandrescu wrote: bearophile wrote: For even bigger data you may use muds: "On the Complexity of Processing Massive, Unordered, Distributed Data", by Jon Feldman, S. Muthukrishnan, Anastasios Sidiropoulos, Cliff Stein, Zoya Svitkina: http://arxiv.org/abs/cs.CC/0611108 I've developed a skepticism towards arxiv.org. My understanding is that it's not high-quality so a paper that only appears of it is highly questionable. Andrei I'm not sure how it is in CS, but at least in physics, *everything* is posted on arXiv -- papers, talks, lectures, etc. Since it (usually) takes quite a while to get a paper published in a peer-reviewed journal, it allows for rapid communication of research results. For each paper on arXiv there is a "journal-ref" field that can be filled in when the paper is quality-assured and published. Another nice thing about arXiv is that it's free. Scientific journals usually require subscriptions -- expensive ones, at that, normally paid for by university libraries. Therefore, when I want to send someone a link to a paper of mine, I usually direct them to the arXiv version, since then I'm sure they can actually read it. So I guess my point is: don't diss arXiv. :) Thank you, this is very useful information. Andrei
Re: weird behavior for machine epsilon in float, double and real
Hello Andrew,
So, for the following code, I get something I think is a little off.
I get the same value for all three variable types. I'm kind of new to
this, but I would think that a 32 bit would give me a different
"smallest value" than a 64 bit or 80 bit (if real even evaluates to 80
bit on my machine).
What am I doing wrong, or is this a bug?
This is a classic case of the optimizer getting in your way by doing all
the math in the FPU (the other classic cases is it noting that as long as
ep!=0, ep+n "can't" equal n). If you are on x86 than the only type the FPU
uses inside is 80bit-real.
import std.stdio;
void main() {
//Find Machine Epsilon:
double ep = 1.0;
double n = 1.0;
while (ep + n != n) {
ep = ep / 2;
}
writefln(ep);
real epr = 1.0;
real nr = 1.0;
while (epr + nr != nr)
epr = epr / 2;
writefln(epr);
float epf = 1.0;
float nf = 1.0;
while (epf + nf != nf)
epf = epf / 2;
writefln(epr);
}
Re: Std Phobos 2 and logging library?
Robert Jacques wrote: On that note, support for per thread GCs in general is another major change. i.e.: GC.malloc!(T)(); to Thread.getThis.gc.malloc!(T)(); // Alternatively use thread local storage. It can remain as GC.malloc(). Exposing a GC handle via thread would allow one thread to use another thread's GC.
Re: Std Phobos 2 and logging library?
dsimcha wrote: > Absolutely. When writing parallel code to do large scale data mining in D, the lack of precision and multithreaded allocation are real killers. My interests are, in order of importance: 1. Being able to allocate at least small chunks of memory without locking. My next big project for Druntime will be to write a GC with per-thread heaps, but I don't know when that will be. I've been pretty busy lately.
Re: Std Phobos 2 and logging library?
On Sat, 11 Apr 2009 01:21:04 -0400, dsimcha wrote: == Quote from Leandro Lucarella (llu...@gmail.com)'s article Andrei Alexandrescu, el 10 de abril a las 16:49 me escribiste: > >And Braddr just made a documentation fix, and Walter only commits > >portability stuff and an occasional bug fix now and then, so... > >Yes, it really looks like a five-person show =) > >I think most work in Phobos now it's done by Andrei, there are other > >*collaborators* (the four other you named plus people sending patches), but > >it looks like Andrei's show to me. This is not necessarily bad, it's > >definitely better than before, when it was Walter's show, now at least he > >can dedicate his efforts in the compiler and language and Phobos is having > >a lot more attention. > > We'll be very happy to integrate credited contributions from anyone, and > to give dsource.org write access to serious participants. What I think > right now stands in the way of large participation to Phobos is that we > all still learn the ropes of D2; the possibilities are dizzying and we > haven't quite zeroed in on a particular style. Nonetheless, as it's been > noticed I'm always summoning help from this group. So again, if you feel > you want to contribute with ideas and/or code, don't hesitate. I hope I can come up with something useful with my thesis (improving D's GC) and I can contribute that. Right now all my energies are focused on that, and I'm very close to the point to finally start playing with alternate implementations. BTW, is there any real interest in adding some more power to the GC implementator to allow some kind of moving or generational collector? Absolutely. When writing parallel code to do large scale data mining in D, the lack of precision and multithreaded allocation are real killers. My interests are, in order of importance: 1. Being able to allocate at least small chunks of memory without locking. After reading Leandro's blog about the current GC, converting the free-lists to a lock-free data-structure would be a simple (i.e. library only) way to provide this. Another is to provide per thread heaps, which I realized this morning can also be done without changing the complier. 2. Precise scanning of at least the heap. 3. Collection w/o stopping the world. *Sigh*. A concurrent GCs (which is what is generally meant by Collection w/o stopping the world) is actually the wrong choice for you. In data-mining you're generally concerned with throughput. A concurrent collector is used solely for gaining latency back, and does so by sacrificing throughput. i.e. the total time your program spends collecting is increased. A parallel collector is probably what you're looking for, since it decreases the total collection time (i.e. increases your throughput) (It also reduces the latency on multi-core systems, which is why you often see synergistic parallel-concurrent collectors) And if you really want to have your cake (low latency) and eat it too (high throughput) there are thread-local heaps. 4. Moving GC so that allocations can be pointer bumps.
Re: Std Phobos 2 and logging library?
dsimcha wrote: == Quote from grauzone (n...@example.net)'s article Rioshin an'Harthen wrote: "Leandro Lucarella" kirjoitti viestissä news:20090411030416.ga22...@homero.springfield.home... BTW, is there any real interest in adding some more power to the GC implementator to allow some kind of moving or generational collector? What I mostly want/need from the GC would be determinism. I want to be able to call delete on a subobject in the destructor of the object being deleted. How many times have I stumbled on this already? Actually, this isn't needed: - if you want to manually free an object, you can add an extra destroy() method - when the object is garbage collected, there's no point in deleting referenced objects, because these are either still alive, or get collected as well In theory true, but in practice false. If you have a huge array owned by a small class, the huge array can be retained due to false pointers. Before I realized that it's illegal, I used to put delete statements in destructors in these kinds of situations and it seemed to work in practice even though it's illegal according to the spec, although I never tested it rigorously or really thought about how it could break. Then you should simply use malloc.
Re: Std Phobos 2 and logging library?
== Quote from grauzone (n...@example.net)'s article > Rioshin an'Harthen wrote: > > "Leandro Lucarella" kirjoitti viestissä > > news:20090411030416.ga22...@homero.springfield.home... > >> BTW, is there any real interest in adding some more power to the GC > >> implementator to allow some kind of moving or generational collector? > > > > What I mostly want/need from the GC would be determinism. I want to be > > able to call delete on a subobject in the destructor of the object being > > deleted. > > > > How many times have I stumbled on this already? > Actually, this isn't needed: > - if you want to manually free an object, you can add an extra destroy() > method > - when the object is garbage collected, there's no point in deleting > referenced objects, because these are either still alive, or get > collected as well In theory true, but in practice false. If you have a huge array owned by a small class, the huge array can be retained due to false pointers. Before I realized that it's illegal, I used to put delete statements in destructors in these kinds of situations and it seemed to work in practice even though it's illegal according to the spec, although I never tested it rigorously or really thought about how it could break.
Re: The new, new phobos sneak preview
Andrei Alexandrescu wrote: bearophile wrote: For even bigger data you may use muds: "On the Complexity of Processing Massive, Unordered, Distributed Data", by Jon Feldman, S. Muthukrishnan, Anastasios Sidiropoulos, Cliff Stein, Zoya Svitkina: http://arxiv.org/abs/cs.CC/0611108 I've developed a skepticism towards arxiv.org. My understanding is that it's not high-quality so a paper that only appears of it is highly questionable. Andrei I'm not sure how it is in CS, but at least in physics, *everything* is posted on arXiv -- papers, talks, lectures, etc. Since it (usually) takes quite a while to get a paper published in a peer-reviewed journal, it allows for rapid communication of research results. For each paper on arXiv there is a "journal-ref" field that can be filled in when the paper is quality-assured and published. Another nice thing about arXiv is that it's free. Scientific journals usually require subscriptions -- expensive ones, at that, normally paid for by university libraries. Therefore, when I want to send someone a link to a paper of mine, I usually direct them to the arXiv version, since then I'm sure they can actually read it. So I guess my point is: don't diss arXiv. :) -Lars
Re: Std Phobos 2 and logging library?
grauzone wrote: You make no sense. You can look at the Log4J API, but not at Tango's, because Phobos should take advantage of D2.0 features? Yeah, I know, that's not exactly what you said, but come on. "Shut that cigarette!" "I'm not smoking and am not a smoker." "Yeah, I know, but come on." Andrei
Re: Std Phobos 2 and logging library?
You make no sense. You can look at the Log4J API, but not at Tango's, because Phobos should take advantage of D2.0 features? Yeah, I know, that's not exactly what you said, but come on.
Re: Std Phobos 2 and logging library?
Frank Benoit wrote: Andrei Alexandrescu schrieb: Zz wrote: Hi, Are there any plans for a logging library in Std Phobos 2.0? Zz I wanted to add logging support for a while now but am undecided about the API to use. Log4J is quite popular but quite complicated. There are a number of simpler APIs out there but I couldn't figure out which is the best. If anyone has ideas and/or code to contribute, that would be great. Andrei Why not start with the one from tango? Because it's not my code and every discussion on licensing ends up confused. What we can do in Phobos is following e.g. the Log4J API, which as far as I understand Tango implements or at least draws inspiration from. But then by browsing this group a while ago I figured that Tango added a Trace module because some people deemed the logging API too complicated. Why has everything to be different? Nobody said it has to be different. If it really is not important, why do you have to make it different than tango? Every code that uses tango and phobos, or wants to support both has to reimplemnent an intermediate abstraction layer. Again, I don't *have* to make it different, but I can't *copy* it either. There are two other things to consider: (a) Phobos' logging can take advantage of D2 features; (b) Phobos' logging should be well integrated with the rest of itself, e.g. it may be odd to have one way to format things in stdio and an entirely different way in the log, or to have the logging infrastructure incompatible with the stream infrastructure. That all being said, I don't see a lot of point in making Phobos' logging 100% identical with Tango's. Phobos2 and Tango2 will be usable together, so there's no point in the duplication - if you want Tango's logging mechanism, you just use it. So there will be no point in "supporting both" because both can coexist. Andrei
Re: demangle tool
Michel Fortin wrote: On 2009-04-11 00:00:08 -0400, Andrei Alexandrescu said: Thanks. Arrays aren't a problem, but non-random-access ranges are problematic. (For arrays a slice could also be taken.) That's why I've been reluctant - if I make before and after primitives, then anyone defining a range needs to worry about implementing them. Then could it be limited to random-access ranges? Other ranges could provide their own implementation, if it makes sense for them. That'd make another category of ranges: "intersectable ranges". We could just provide primitives for consuming a range and returning the consumed data (as my read function does above). This could be supported by all ranges. Which makes me think: how does the new regex library handle consuming and backtracking with ranges? For now regex only supports random-access ranges. Andrei
Re: demangle tool
On 2009-04-11 00:00:08 -0400, Andrei Alexandrescu said: Thanks. Arrays aren't a problem, but non-random-access ranges are problematic. (For arrays a slice could also be taken.) That's why I've been reluctant - if I make before and after primitives, then anyone defining a range needs to worry about implementing them. Then could it be limited to random-access ranges? Other ranges could provide their own implementation, if it makes sense for them. That'd make another category of ranges: "intersectable ranges". We could just provide primitives for consuming a range and returning the consumed data (as my read function does above). This could be supported by all ranges. Which makes me think: how does the new regex library handle consuming and backtracking with ranges? -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: weird behavior for machine epsilon in float, double and real
Andrew Spott:
> import std.stdio;
> [...]
This is the same code of yours, a bit refactored:
import std.stdio: writefln;
template Tuple(T...) { alias T Tuple; }
void computeEpsilon(T)() {
T ep = 1;
T n = 1;
while ((ep + n) != n)
ep /= 2;
writefln("%.30f type: %s", ep, typeid(T));
}
void main() {
foreach (T; Tuple!(float, double, real))
computeEpsilon!(T)();
}
Bye,
bearophile
Re: Std Phobos 2 and logging library?
Rioshin an'Harthen wrote: "Leandro Lucarella" kirjoitti viestissä news:20090411030416.ga22...@homero.springfield.home... BTW, is there any real interest in adding some more power to the GC implementator to allow some kind of moving or generational collector? What I mostly want/need from the GC would be determinism. I want to be able to call delete on a subobject in the destructor of the object being deleted. How many times have I stumbled on this already? Actually, this isn't needed: - if you want to manually free an object, you can add an extra destroy() method - when the object is garbage collected, there's no point in deleting referenced objects, because these are either still alive, or get collected as well
