Re: Copy constructors for lazy initialization
On Fri, 28 May 2010 20:26:50 -0500, Andrei Alexandrescu wrote: > Walter has had a great idea last night: allow classes to define > > this(ref S src); > > where S is the name of the struct being defined, as an alternative for > > this(this); > > The result would be a function similar with a C++ copy constructor. > > S. > > What do you think? > > > Andrei Thats great. Yet another way to initialize an AA, without having to insert and then remove a value. I just have to make a dummy function and pass the AA to it. Maybe a setup property / function would be easier.
Re: Memory Mapped File Access
On 29/05/2010 21:52, Robert wrote: Ok, that makes sense. On the other hand I will use a very simple rule-of-thumb: As long as the app runs the file is open. Only if the app terminates the file gets closed. Which implies that the reference to the MMF is a global but this shouldn't be a problem. From the docs.. --- File is closed when the object instance is deleted. --- Maybe we can have a more precise doc. please.
Re: std.mmfile doc.
On 29/05/2010 21:53, Robert wrote: On 2010-05-29 18:01:13 +0200, BLS said: seems that the std.mmfile documentation is not up to date. Unfortunately I haven't D2 on this machine. But afaik UnMap was part of std.mmfile. I wrote this 'cause Robert plans to write a memory mapped database, and I've recommended him to use Phobos2 instead of Tango. Thanks for the hint. I already took a look at the code and IIRC I saw UnMap in there. -- Robert M. Münch http://www.robertmuench.de I was involved (a little bit) in the Suneido DB dev. Since Andrew, the Author of Suneido, is going to port the core database from C++ to Java, he immediately has to find out that the memory mapped file implementation of SDK 1.5 is..erm...shi* 'cause of non existing UnMap, slicing, et al... D shines here. Also build in GC, std.algo. all in all a good starting point. IO Streaming, well, guess Andrei should say something about it. In case that you need some help in designing your DB, do not hesitate to ask Andrew. He's a nice guy and always willing to help. Bjoern
Re: Copy constructors for lazy initialization
On Fri, 28 May 2010 20:26:50 -0500, Andrei Alexandrescu wrote:
> Walter has had a great idea last night: allow classes to define
>
> this(ref S src);
>
> where S is the name of the struct being defined, as an alternative for
>
> this(this);
>
> The result would be a function similar with a C++ copy constructor.
>
> Such an abstraction allows us to perform lazy initialization in a way
> that allows the kind of problems associated with non-shared hash tables:
>
> void foo(int[int] x)
> {
> x[5] = 5;
> }
>
> void main()
> {
> int[int] x;
> foo(x);
> assert(x[5] == 5); // fails
> }
>
> If you change the first line of main() with
>
> int[int] x = [ 42:42 ];
>
> the assert passes.
>
> The idea of the copy constructor is to lazy initialize the source and
> the target if the source has null state. That would take care of this
> problem and the similar problems for shared state.
>
> There is still a possibility to call a method against an object with
> null state. I think that's acceptable, particularly because lazy
> initialization saves some state allocation.
>
> What do you think?
>
>
> Andrei
Nothing wrong with yet another widely available constructor tool if the
user optionally wants to have it available and use it that way, and its
usage is well defined.
Good if no cost if the programmer does not use the facility.
What seems to be missing, in this example of the unintentional creation
of 2 AAs because initially a null AA is passed, if there was a way of
explicitly initialising the AA first without having to insert something
into it. That subject seems to be taboo. Of course, an empty but setup
AA can be kludged by adding an arbitrary value and then removing it, and
as such begs the need for a setup property / function.
\\
Re: Memory Mapped File Access
On 2010-05-29 23:23:06 +0200, Andrei Alexandrescu said: There's nothing to sketch, really. The runtime tracks the opened memory-mapped files and the memory ranges associated with them. Upon a collections, if a file's memory has been successfully freed, the file can be safely closed. Is this something that needs to be integrated into the deeper D levels or is this something I could plug on-top if it? I'm not yet that familiar with the GC internals. -- Robert M. Münch http://www.robertmuench.de
Re: The last changes to range
On 05/29/2010 03:05 PM, Philippe Sigaud wrote:
On Sat, May 29, 2010 at 18:45, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:
I plan to make two more (hopefully the last two) changes to the
range abstraction this morning.
Does that mean that you changed some other parts recently?
Not recently, I think I made the last changes before you joined the gang.
1. First, I want to define this:
// inside range type SomeRange
@property SomeRange save();
vote++
That should make it clear you need a forward range for an algorithm.
Yah.
The idea is that save() provides a guaranteed means to take a
snapshot in a range's state. The notable absents are input ranges -
they are unable to define save(), and therefore some algorithms
won't apply to them.
I think many ranges and algorithm that you put in std have a constraint
on InputRange that should be changed to ForwardRange. Most (all?) of the
lazy ones should probably ask for a ForwardRange. Don't forget to update
that part.
I'm not sure about that. Could you give an example? Why would map() not
work with an input range?
2. swapFront, swapBack, and swapAt methods
// inside range type SomeRange
void swapFront(ref ElementType!SomeRange obj);
void swapBack(ref ElementType!SomeRange obj);
void swapAt(size_t i, ref ElementType!SomeRange obj);
All functions are optional and are needed if and only if front(),
back(), and opIndex() return rvalues. The idea is to provide a cheap
means to move elements in and out of ranges without creating extra
copies. There's more detail about this of increased subtlety, please
ask.
Will that be associated with a constraint template? And why methods
instead of free functions?
They will be methods because they must be primitive operations of the
respective ranges. However, there will be wrappers like this:
// at module scope
void swapFront(Range)(Range r1, Range r2)
{
static if (is(typeof(&(r1.front)) == ElementType!(Range)*)) {
swap(r1.front, r2.front);
} else {
static assert(is(typeof(&(r1.swapFront)), "Cannot swap ranges");
r1.swapFront(r2);
}
}
3. sameFront()
The gnarly bringToFront() algorithm needs the primitive:
// inside range type SomeRange
bool sameFront(SomeRange another);
I think it's necessary for future algorithms as well. It's an
optional primitive. In particular, if front() returns by reference
it's easy to infer that two ranges have the same front by comparing
the addresses of their front()s.
And if front does not return by ref? Do you then define the fronts to be
different or compare the values?
If front() does not return by ref, the range should define sameFront()
as a member. If it doesn't, it won't have access to a number of algorithms.
About returning by ref, did you try to use 'auto ref'? I think I tried
the day the feature appeared, without success, IIRC. Many ranges in
Phobos return by ref and won't compose with other ranges because of that.
Yah, auto ref was meant for that kind of work. But generally note that
certain ranges actively refuse to return by ref in order to not expose
addresses of their elements. Such ranges are fit for perfectly
encapsulated containers.
Andrei
Re: Memory Mapped File Access
On 05/29/2010 02:52 PM, Robert wrote: On 2010-05-29 18:30:13 +0200, Andrei Alexandrescu said: Andrei and I had talked a while back about adding memory-mapped file support to the GC and then it fell off the radar while we worked on other things. I'll see if I can remember how it was to work. The basic idea is that the only way to handle memory-mapped files safely is to let the garbage collector close them. This is because in any other case you'd have dangling pointers. Ok, that makes sense. On the other hand I will use a very simple rule-of-thumb: As long as the app runs the file is open. Only if the app terminates the file gets closed. That might be the case if no collection ensues, but if a collection does, the runtime should attempt to reclaim available resources. Which implies that the reference to the MMF is a global but this shouldn't be a problem. So the idea is that druntime should provide a safe means for mapping a file to memory and an unsafe means of closing a file. Why should it provide an unsafe way of closing a MMF file? For applications concerned with deterministic closing of a file (e.g. following writing) and that are willing to take the unsafety risk. Safe code should be able to count on the garbage collector to close memory-mapped files that have no pointers referring to them. Have you sketched any ideas how to use the GC for MMF? There's nothing to sketch, really. The runtime tracks the opened memory-mapped files and the memory ranges associated with them. Upon a collections, if a file's memory has been successfully freed, the file can be safely closed. Andrei Andrei
Re: The last changes to range
On Sun, 30 May 2010 01:45:54 +0900, Andrei Alexandrescu
wrote:
I plan to make two more (hopefully the last two) changes to the range
abstraction this morning.
1. First, I want to define this:
// inside range type SomeRange
@property SomeRange save();
That simply returns a copy of the range. Most implementations look like
this:
// inside range type SomeRange
@property SomeRange save() { return this; }
If SomeRange is a class or interface, you'd write:
// inside range type SomeRange
@property SomeRange save() { return this->clone(); }
The idea is that save() provides a guaranteed means to take a snapshot
in a range's state. The notable absents are input ranges - they are
unable to define save(), and therefore some algorithms won't apply to
them.
I also want save.
It allows you to treat some ranges in a unified way.
Masahiro
Re: The last changes to range
On Sat, May 29, 2010 at 18:45, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > I plan to make two more (hopefully the last two) changes to the range > abstraction this morning. > Does that mean that you changed some other parts recently? > 1. First, I want to define this: > > // inside range type SomeRange > @property SomeRange save(); > vote++ That should make it clear you need a forward range for an algorithm. > The idea is that save() provides a guaranteed means to take a snapshot in a > range's state. The notable absents are input ranges - they are unable to > define save(), and therefore some algorithms won't apply to them. > I think many ranges and algorithm that you put in std have a constraint on InputRange that should be changed to ForwardRange. Most (all?) of the lazy ones should probably ask for a ForwardRange. Don't forget to update that part. > 2. swapFront, swapBack, and swapAt methods > > // inside range type SomeRange > void swapFront(ref ElementType!SomeRange obj); > void swapBack(ref ElementType!SomeRange obj); > void swapAt(size_t i, ref ElementType!SomeRange obj); > > All functions are optional and are needed if and only if front(), back(), > and opIndex() return rvalues. The idea is to provide a cheap means to move > elements in and out of ranges without creating extra copies. There's more > detail about this of increased subtlety, please ask. > Will that be associated with a constraint template? And why methods instead of free functions? > 3. sameFront() > > The gnarly bringToFront() algorithm needs the primitive: > > // inside range type SomeRange > bool sameFront(SomeRange another); > > I think it's necessary for future algorithms as well. It's an optional > primitive. In particular, if front() returns by reference it's easy to infer > that two ranges have the same front by comparing the addresses of their > front()s. > > And if front does not return by ref? Do you then define the fronts to be different or compare the values? About returning by ref, did you try to use 'auto ref'? I think I tried the day the feature appeared, without success, IIRC. Many ranges in Phobos return by ref and won't compose with other ranges because of that. Philippe
Re: Memory Mapped File Access
On 2010-05-29 10:17:34 +0200, Robert said: Replying to myself: Simple, close the file, and re-open with new size. Old content is kept. This should be added to the docs, as it's not totally clear. This could become problematic if the app holds some slices to the MMF and the 2nd open maps to a different memory address. In this case all references to the MMF are invalid. I saw that it's possible to specify an explicit address but it seems not to be ensured that this address is used by the OS. Going to do some tests to see if this holds or not. Returned values from the MMF (even index offsets) of course stay the same and are valid. -- Robert M. Münch http://www.robertmuench.de
Re: Huffman coding comparison
On Sat, May 29, 2010 at 03:27, bearophile wrote:
>Now and then it's very useful to compare how to write in D2 a small
interesting program
>written in another language, the comparison can help find problems,
possible improvements,
>performance problems, and so on.
>
>Time ago I have tried to convert to D2 a small Python program that finds
the Huffman encoding
> of a given string, but Phobos2 was not mature enough, and I didn't produce
a good enough D2 program.
>I have tried again and this time things are good enough.
(snip)
Hey, cool. And you made it generic to boot. I'd vote that to be put in
std.algorithm.
Simen kjaeraas:
>
> > I'm now so tired of hearing this, I started writing something that
> > does it:
>
>Now, granted, I have little to no experience with list comprehension,
>and as such this might not be what is needed. Still, it was fun to
>play around with, and I kinda like what it turned out as.
That's fun to see, the syntax is cool. I never thought of using operator
overloading for this.
I did a range comprehension also, a few months ago. It's called comp in
http://svn.dsource.org/projects/dranges/trunk/dranges/docs/algorithm2.html
Like yours, it takes any range and is lazy, the main difference it that it's
multirange: you can give it any number of range as input, it will create the
combinations of elements (aka product of ranges), filter it with the
predicate and map the generative function on it.
Syntax is comp!(mappingFunction, predicate)(ranges...)
The classical example for Haskell list comprehension is generating the
pythagorean triplets:
pyth n = [ ( a, b, c ) | a <- [1..n], -- Pythagorean Triples
b <- [1..n],
c <- [1..n],
a + b + c <= n,
a^2 + b^2 == c^2 ]
In my case, it would be:
auto pyth(int n)
{
return comp ! ("tuple(a,b,c)", "a*a+b*b==c*c && a (3,4,5), (6,8,10)
Philippe
Re: Memory Mapped File Access
On 2010-05-29 18:30:13 +0200, Andrei Alexandrescu said: Andrei and I had talked a while back about adding memory-mapped file support to the GC and then it fell off the radar while we worked on other things. I'll see if I can remember how it was to work. The basic idea is that the only way to handle memory-mapped files safely is to let the garbage collector close them. This is because in any other case you'd have dangling pointers. Ok, that makes sense. On the other hand I will use a very simple rule-of-thumb: As long as the app runs the file is open. Only if the app terminates the file gets closed. Which implies that the reference to the MMF is a global but this shouldn't be a problem. So the idea is that druntime should provide a safe means for mapping a file to memory and an unsafe means of closing a file. Why should it provide an unsafe way of closing a MMF file? Safe code should be able to count on the garbage collector to close memory-mapped files that have no pointers referring to them. Have you sketched any ideas how to use the GC for MMF? -- Robert M. Münch http://www.robertmuench.de
Re: std.mmfile doc.
On 2010-05-29 18:01:13 +0200, BLS said: seems that the std.mmfile documentation is not up to date. Unfortunately I haven't D2 on this machine. But afaik UnMap was part of std.mmfile. I wrote this 'cause Robert plans to write a memory mapped database, and I've recommended him to use Phobos2 instead of Tango. Thanks for the hint. I already took a look at the code and IIRC I saw UnMap in there. -- Robert M. Münch http://www.robertmuench.de
Re: Memory Mapped File Access
On 2010-05-29 17:21:18 +0200, BLS said: in opposite to Bane I think this Job is doable and makes perfectly sense. Hi Bjoern, thanks to support this idea. IMO used in a smart way MMF make a lot of things simpler. Especially with D's array slices I see a perfect match. In fact the Suneido programming system is using a memory mapped file to create a modern (and used in practice) database. Database lines of code are remarkable less.. See yourself.. Thanks for the link. Just this. I would choose Phobos MMAP over Tango MMAP. compare it by yourself. I'm currently using D2 with Phobos. So far it works very well. -- Robert M. Münch http://www.robertmuench.de
Re: Memory Mapped File Access
> Ok, I need to be fair. We are quite good at these things. Anyone > remembering Adimens from the Atari (later for Windows as well)? It > was/is a ACID compliant SQL database with row-level locking etc. > > And, it was written by my friend and sold more than 500.000 times. > > Yes, we are crazy... but chances are high we will get something done. I > need to get some practice with D but shouldn't be that hard. Then this is a whole new ball game. I did that scare-to-double-think-it so you wouldn't start too ambitiously, but it seems you have enough experience to know exactly what you are getting into. I think D is perfect for the job. Much less lines of code than C family, same or more power. I hope your project will make you famous, along with D :)
Re: C#5 desiderata
Don, el 29 de mayo a las 17:59 me escribiste: > >>It's cute. But Don hates attributes :-) Recently I have created > >>a thread about this, and some one has written a good enough > >>implementation in normal D code, that can be "good enough". > > > >Screw Don. :p > > . I just think that @ shouldn't be an excuse to be careless -- > anything with an @ in front is still part of the language. That's > all. It shouldn't, that's (was?) the point of @. If the point of @ was to create a namespace for keywords, it sucks... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Bald men with no jobs and no money who live with their parents don't approach strange women. -- George Constanza
The last changes to range
I plan to make two more (hopefully the last two) changes to the range
abstraction this morning.
1. First, I want to define this:
// inside range type SomeRange
@property SomeRange save();
That simply returns a copy of the range. Most implementations look like
this:
// inside range type SomeRange
@property SomeRange save() { return this; }
If SomeRange is a class or interface, you'd write:
// inside range type SomeRange
@property SomeRange save() { return this->clone(); }
The idea is that save() provides a guaranteed means to take a snapshot
in a range's state. The notable absents are input ranges - they are
unable to define save(), and therefore some algorithms won't apply to them.
2. swapFront, swapBack, and swapAt methods
// inside range type SomeRange
void swapFront(ref ElementType!SomeRange obj);
void swapBack(ref ElementType!SomeRange obj);
void swapAt(size_t i, ref ElementType!SomeRange obj);
All functions are optional and are needed if and only if front(),
back(), and opIndex() return rvalues. The idea is to provide a cheap
means to move elements in and out of ranges without creating extra
copies. There's more detail about this of increased subtlety, please ask.
Of course, swapBack() only makes sense if back() exists and swapAt()
only makes sense if opIndex exists.
3. sameFront()
The gnarly bringToFront() algorithm needs the primitive:
// inside range type SomeRange
bool sameFront(SomeRange another);
I think it's necessary for future algorithms as well. It's an optional
primitive. In particular, if front() returns by reference it's easy to
infer that two ranges have the same front by comparing the addresses of
their front()s.
I've posted this to the phobos list as well.
Andrei
Re: Memory Mapped File Access
On 05/29/2010 10:40 AM, Sean Kelly wrote: Robert Wrote: Hi, has anyone played around with D and memory mapped files on Windows / Linux? A friend of mine and I want to use D to develop a D native database-system. Yes, sounds crazy and it will take long and we haven't done a lot yet. So don't expect anything to look at soon :-) Andrei and I had talked a while back about adding memory-mapped file support to the GC and then it fell off the radar while we worked on other things. I'll see if I can remember how it was to work. The basic idea is that the only way to handle memory-mapped files safely is to let the garbage collector close them. This is because in any other case you'd have dangling pointers. So the idea is that druntime should provide a safe means for mapping a file to memory and an unsafe means of closing a file. Safe code should be able to count on the garbage collector to close memory-mapped files that have no pointers referring to them. Andrei
Re: Memory Mapped File Access
On 05/29/2010 10:40 AM, Sean Kelly wrote: Robert Wrote: Hi, has anyone played around with D and memory mapped files on Windows / Linux? A friend of mine and I want to use D to develop a D native database-system. Yes, sounds crazy and it will take long and we haven't done a lot yet. So don't expect anything to look at soon :-) Andrei and I had talked a while back about adding memory-mapped file support to the GC and then it fell off the radar while we worked on other things. I'll see if I can remember how it was to work. The basic idea is that the only way to handle memory-mapped files safely is to let the garbage collector close them. This is because in any other case you'd have dangling pointers. So the idea is that druntime should provide a safe means for mapping a file to memory and an unsafe means of closing a file. Safe code should be able to count on the garbage collector to close memory-mapped files that have no pointers referring to them. Andrei
Re: Go has contempt for generics
On 05/29/2010 10:52 AM, Don wrote: bearophile wrote: Jonathan M Davis: Yes, you _can_ add things like generics into the language later, but it can be quite disruptive to do so, and the result could be subpar due to constraints such as backwards compatability. D didn't have templates for some time. Maybe compile-time function execution plus a type type can replace the need for C++/D/Java style generics :-) I agree with that. Over time, D has moved very strongly in that direction. I wonder how far that approach could ultimately be taken. Clearly we're still exploring what the best way to carve the territory is, but one trend is clear: * Type-parameterized types and functions for generic programming * Compile-time function evaluation for generative programming Andrei
Re: Go has contempt for generics
On 05/29/2010 10:43 AM, Sean Kelly wrote: Andrei Alexandrescu Wrote: http://www.reddit.com/r/programming/comments/c93iy/go_at_io_frequently_asked_questions/ "Do you have plans to implement generics? Many proposals for generics-like features have been mooted both publicly and internally, but as yet we haven't found a proposal that is consistent with the rest of the language. We think that one of Go's key strengths is its simplicity, so we are wary of introducing new features that might make the language more difficult to understand. Additionally, the more Go code we write (and thus the better we learn how to write Go code ourselves), the less we feel the need for such a language feature." So they've simplified the language at the cost of more complex user code. They should have just said that they haven't found a proposal they like yet and left it at that. Exactly. This "the more code we write the less we felt a need for genericity" reflects very poorly - just not on genericity. Andrei
Re: Memory Mapped File Access
On 29/05/2010 10:17, Robert wrote: On 2010-05-28 23:41:46 +0200, Robert said: 1. How can I expand the size of a MMF after it was created? Replying to myself: Simple, close the file, and re-open with new size. Old content is kept. This should be added to the docs, as it's not totally clear. 2. If I specify 100GB file-size will it always be written once to disk even if there is nothing in it? Or does the OS use sparse-files as well? Current things I found out: Filesize is used as soon as things are flushed to disk. So MMF need to grow in chunks to be real useful. -- Robert M. Münch http://www.robertmuench.de Hi Robert, I think the std.mmfile documentation in Phobos is not up to date.. AFAIK there is a unMap method. Have posted a new msg regarding this topic. Regarding chunks.. please see prev. msg. Bjoern
std.mmfile doc.
Hi, seems that the std.mmfile documentation is not up to date. Unfortunately I haven't D2 on this machine. But afaik UnMap was part of std.mmfile. I wrote this 'cause Robert plans to write a memory mapped database, and I've recommended him to use Phobos2 instead of Tango. Bjoern
Re: C#5 desiderata
Simen kjaeraas wrote:
bearophile wrote:
Simen kjaeraas:
I think you have missed one important point: that was not my list of
things I'd like in D2/D3. It contains some cute things, but it's first
of all a summary of the linked stackoverflow thread. My personal list
of desiderata for D3 is different.
You are right indeed. I misread that first sentence to its exact
opposite. :p
I think Walter said this can't be implemented :)
I think Walter just doesn't want to implement it. :p
The items alignment of function arguments used by D tuples is not
fitting to return a struct.
Yeah. So, either we need thunks for this, or tuples need to carry
alignment information.
Neat. Worthy an @keyword, I think. "@flag enum foo {...}"
It's cute. But Don hates attributes :-) Recently I have created a
thread about this, and some one has written a good enough
implementation in normal D code, that can be "good enough".
Screw Don. :p
. I just think that @ shouldn't be an excuse to be careless --
anything with an @ in front is still part of the language. That's all.
Re: Go has contempt for generics
bearophile wrote: Jonathan M Davis: Yes, you _can_ add things like generics into the language later, but it can be quite disruptive to do so, and the result could be subpar due to constraints such as backwards compatability. D didn't have templates for some time. Maybe compile-time function execution plus a type type can replace the need for C++/D/Java style generics :-) I agree with that. Over time, D has moved very strongly in that direction. I wonder how far that approach could ultimately be taken.
Re: Go has contempt for generics
Andrei Alexandrescu Wrote: > http://www.reddit.com/r/programming/comments/c93iy/go_at_io_frequently_asked_questions/ > > "Do you have plans to implement generics? > Many proposals for generics-like features have been mooted both publicly > and internally, but as yet we haven't found a proposal that is > consistent with the rest of the language. We think that one of Go's key > strengths is its simplicity, so we are wary of introducing new features > that might make the language more difficult to understand. Additionally, > the more Go code we write (and thus the better we learn how to write Go > code ourselves), the less we feel the need for such a language feature." So they've simplified the language at the cost of more complex user code. They should have just said that they haven't found a proposal they like yet and left it at that.
Re: Memory Mapped File Access
Robert Wrote: > Hi, has anyone played around with D and memory mapped files on Windows / > Linux? > > A friend of mine and I want to use D to develop a D native > database-system. Yes, sounds crazy and it will take long and we haven't > done a lot yet. So don't expect anything to look at soon :-) Andrei and I had talked a while back about adding memory-mapped file support to the GC and then it fell off the radar while we worked on other things. I'll see if I can remember how it was to work.
Re: Memory Mapped File Access
On 28/05/2010 09:28, Robert wrote: Hi, has anyone played around with D and memory mapped files on Windows / Linux? A friend of mine and I want to use D to develop a D native database-system. Yes, sounds crazy and it will take long and we haven't done a lot yet. So don't expect anything to look at soon :-) Thanks Robert. Hi Robert, in opposite to Bane I think this Job is doable and makes perfectly sense. In fact the Suneido programming system is using a memory mapped file to create a modern (and used in practice) database. Database lines of code are remarkable less.. See yourself.. I would also say that D is the perfect language to implement such a system.. Cookbook for the Suneido DB C++, MMAP file, slightly modified BTree indexing system( IMHO Skiplists are preferable) Boehm GC in SVN (regular download uses home brewed GC), Memory chunk support) Features: C/S database, ATOMIC, RAL (relational algebra... following C.J.Date... set theories) instead of SQL Link > http://www.suneido.com/index.php?option=com_content&task=view&id=49&Itemid=1 Limits : Database size, but I think the size-limit is acceptable on 64 bit engines. Number of concurrent access without hassle. 35-50 users HTH Bjoern Just this. I would choose Phobos MMAP over Tango MMAP. compare it by yourself.
Re: Go has contempt for generics
Hello bearophile, Jonathan M Davis: Yes, you _can_ add things like generics into the language later, but it can be quite disruptive to do so, and the result could be subpar due to constraints such as backwards compatability. D didn't have templates for some time. They showed up much closer to v0.01 than v1.00 Maybe compile-time function execution plus a type type can replace the need for C++/D/Java style generics :-) Bye, bearophile -- ... <
Re: Go has contempt for generics
On 05/29/2010 04:42 AM, Jonathan M Davis wrote: In any case, while I would agree with you that it generally works better for a language to have generics of some kind, there are plenty of languages which get by just fine without them. Yah, it's not the generics per se. That's why I mentioned "response to problems usually tackled by generics in contemporary languages". More dynamic languages achieve things in different ways. But Go seems to claim that built-in arrays, hashes, and channels are all you'll ever need that's generic. I believe that's a mistake. Andrei
Re: Go has contempt for generics
On 05/29/2010 01:38 AM, Alex Makhotin wrote: Andrei Alexandrescu wrote: That has Java 1994 written all over it. (This happened with early Java as well; one hallmark of Java is that it talked out of existence all necessities of modern languages until it adopted them, invariably too late to be properly integrated.) And what happened to Java? Looking at the popularity of Java: http://www.devtopics.com/most-popular-programming-languages/ http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://langpop.com/ Not because of that! Andrei
Re: Static constructors in circularly imported modules - again
Max Samukha Wrote:
> On 27.05.2010 13:37, Max Samukha wrote:
> > There was a discussion about those a while ago that terminated with
> > Andrei's authoritative "it would be a step backward".
> >
> > I am not entirely convinced that there had been a step forward in the
> > first place. Defining static construction order to be determined by the
> > module import graph had been a half step forward. Completely disallowing
> > static construction of circularly imported modules - a half step
> > backward. The result is std.stdiobase and impossibility to initialize
> > static data in mixins without resorting to lazy initialization.
> >
> > I can live with hacks like std.stdiobase when such are possible. What is
> > more critical is initialization of mixins. Restating the problem:
> >
> > module a;
> > mixin template Foo()
> > {
> > static immutable Object foo;
> > shared static this()
> > {
> > foo = cast(immutable)new Object;
> > }
> > }
> >
> >
> > module b;
> > import a;
> > import c;
> >
> > mixin Foo;
> >
> >
> > module c;
> > import a;
> > import b;
> >
> > mixin Foo;
> >
> > In this scenario one is forced to avoid static constructors by lazily
> > initializing foo and using some kind of synchronization, which should be
> > absolutely unnecessary and sometimes is not tolerable.
> >
> > So which of the following is going to happen?
> >
> > 1. The current blinkered design will stay.
> > 2. A solution will be provided before D2 is feature-freezed.
>
> Feature-frozen. Sorry.
>
> >
> > Note that I am well aware of
> > http://yosefk.com/c++fqa/ctors.html#fqa-10.12 etc, but simply
> > disallowing static construction is not a good solution for static
> > construction problems.
>
> I'd really appreciate a reply from the language designers. What are the
> plans?
>
> 1. Static constructor semantics won't change.
> 2. We've worked out a solution and it will be implemented in a future
> compiler release.
>
> Please care to type 1 or 2. Thank you!
Why has it become a tradition to ignore uncomfortable questions in these
newsgroups?
Re: Memory Mapped File Access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert wrote: > On 2010-05-28 23:41:46 +0200, Robert said: > >> 1. How can I expand the size of a MMF after it was created? > > Replying to myself: Simple, close the file, and re-open with new size. > Old content is kept. This should be added to the docs, as it's not > totally clear. > >> 2. If I specify 100GB file-size will it always be written once to disk >> even if there is nothing in it? Or does the OS use sparse-files as well? > > Current things I found out: Filesize is used as soon as things are > flushed to disk. So MMF need to grow in chunks to be real useful. > > -- > Robert M. Münch > http://www.robertmuench.de > NTFS supports sparse files: http://msdn.microsoft.com/en-us/library/aa365566(v=VS.85).aspx Not sure how you're going to get that to play with phobos memory mapped file. I'm guessing you'd be better off writing your own accessor so you can explicitly support each target platform. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMAQpLT9LetA9XoXwRAlD/AKDLkw+FHiLCaTGz8oSBzgTKCZFf4ACg0Uyg CHTCPA6RL4vGMq3JVJad/Hk= =Lz1M -END PGP SIGNATURE-
Re: Copy constructors for lazy initialization
On 2010-05-28 21:26:50 -0400, Andrei Alexandrescu said: Walter has had a great idea last night: allow classes to define this(ref S src); where S is the name of the struct being defined, as an alternative for this(this); The result would be a function similar with a C++ copy constructor. Such an abstraction allows us to perform lazy initialization in a way that allows the kind of problems associated with non-shared hash tables: At this point I'll put the lazy initialization into question. If as soon as you make a copy of the struct you must allocate, it means that the container will be initialized as soon as you pass it to some function (unless the argument is passed by 'ref', but you want reference semantics precisely to avoid that, am I right?). If the container is to be initialized as soon as you make a copy, the lazy initialization becomes of limited utility; it'll only be useful when you have a container you don't pass to another function *and* you never put anything in it. This makes the tradeoff of lazy initialization less worth it, as the extra logic checking every time if the container is already initialized will rarely serve a purpose. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Go has contempt for generics
Jonathan M Davis: > Yes, you _can_ add things like generics into the language later, > but it can be quite disruptive to do so, and the result could be subpar due > to constraints such as backwards compatability. D didn't have templates for some time. Maybe compile-time function execution plus a type type can replace the need for C++/D/Java style generics :-) Bye, bearophile
Re: Go has contempt for generics
Andrei Alexandrescu wrote: > On 05/28/2010 08:39 PM, Jonathan M Davis wrote: > [snip some good points] >> So, while >> some folks seem to want to draw comparisons between Go and D, it sounds >> like there are definitely things about them which are drastically >> different, not only in the design, but in the philosophy behind the >> design. > > If Go has only a black stare as a response to problems usually tackled > by generics in contemporary language, I wouldn't call that a different > philosophy, I'd call that a lacuna therein. > > Andrei Curse you for making me increase my vocabulary! ;) Nice word, lacuna... In any case, while I would agree with you that it generally works better for a language to have generics of some kind, there are plenty of languages which get by just fine without them. I haven't looked into Go at all, so I don't know how they would affect it if you added them or what frustrations currently exist without them. But you can have perfectly good languages without generics, and there probably are languages where it would be a bit awkward or needless to have them (probably primary in functional and/or dynamically-typed languages). It could be that Go works great without them, so I'm not sure that it's necessarily a lacuna, but certainly my first reaction without looking more closely into the matter would be that it probably is a lacuna. But whether it really is a lacuna or not would really depend on what they have and how the lack of generics affects them. Certainly, on Java's and C#'s parts, it was a lacuna until they added them. So, I guess that I'm agreeing with you on the condition that Go really is the kind of language that should have generics, but not being familiar with the language, I can't really say. Regardless, I'm very glad that D has powerful generics in its templates. And they retain and improve on some of the more powerful aspects of C++'s templates rather than being used pretty much purely for container types like in C# and Java. But given your involvement in the project and how big you are on templates and template metaprogramming, that should come as no surprise. That would also be suggestive of why you'd find a language without them to be lacking. - Jonathan M Davis
Re: Copy constructors for lazy initialization
Actually, I have to ask what the purpose behind this delayed initialization is in the first place. The following works just fine as things are: int[] a; assert(!a); a ~= 42; assert(a); If a were an object, this wouldn't work at all - even if it implemented the concatenation assignment operator. It would be null until you actually assigned it an object. Arrays - both normal and associative - don't seem to operate this way at all. This has the advantage that it's a bit hard to get the program to blow up on a null array, but it's not like that would generally be hard to find and fix. It makes it bit hard to have actual null array which stays that way. It would be easy to make an array null and accidentally add something to it, resulting in a bug which would have been found if the array didn't create itself upon concatenation. Also, you get the problem which started this thread - that of it getting created in a function that it's passed to and not ending up in the function that did the passing. Other than having to update existing code, it doesn't seem that onerous to me to require int[] = new int[](0); to have an empty array if you want one (though it is a little weird to create an array of length 0). Are there bugs that I'm not thinking of which the current behavior of creating the array for you avoids? Or am I just missing something here? It really seems to me like you're creating a workaround for a problem in the language. And while that workaround may be great for other stuff too, just making arrays stay null until the programmer assigns them another value fixes the bug that you're trying to fix - at least as far as I can tell. I don't understand why the current behavior was chosen. It does simplify array creation somewhat, but it seems to me that it's more likely to cause bugs than avoid them. - Jonathan M Davis
Re: Memory Mapped File Access
On 2010-05-28 23:41:46 +0200, Robert said: 1. How can I expand the size of a MMF after it was created? Replying to myself: Simple, close the file, and re-open with new size. Old content is kept. This should be added to the docs, as it's not totally clear. 2. If I specify 100GB file-size will it always be written once to disk even if there is nothing in it? Or does the OS use sparse-files as well? Current things I found out: Filesize is used as soon as things are flushed to disk. So MMF need to grow in chunks to be real useful. -- Robert M. Münch http://www.robertmuench.de
