Re: dbuilder, pakage manager, dget
On Saturday, 26 May 2012 at 15:33:27 UTC, Jacob Carlborg wrote: On 2012-05-26 13:34, bioinfornatics wrote: Dear, dbuilder: https://github.com/dbuilder-developers/dbuilder currently dbuilder works on Linux, Apple, Windows platform (at least) this tool allow to us to build easily lib, or desktop application It support // build, // install i think i will improve this tool to be use as a package manager, for this add to supported config file a new section --- [[dependenies]] [[[xxx] version_type=[version, tag, revision] repo_url=https://github ...https://bitbucket ... tool=[git, hg, svn] version=xx tag=xx revision=xx --- put the config file at root of repo for detect this file and use it if this config is not enough for to be used as config said to me what need to be added anyone is welcome I don't think a built tool and package manager should be in the same tool. A built tool works with individual files. A package manager works with package, i.e. complete libraries/tools/applications. I also think that in the long run both a build tool and a package manager needs to use a full programming language as their config files. Yes they should be separate tools but that's doesn't mean they can't work together. Let's say you have a build configuration file and an package manager configuration file in the same folder. When you call the build process, if the dependencies aren't there, it calls the package manager to fetch all your dependencies and then it adds the required include and lib path in your build configuration. Adding an dependency to your project is now easier and doesn't require manual management.
Re: Pointer semantics in CTFE
On 5/26/2012 3:59 AM, Don wrote: Yes, that's what happens now. But that doesn't help the programmer. If it is inside, no problem, the expression is true. But if it is not inside, the expression is not false -- it's a compile-time error. Ok, I understand now what you meant. So you can't use it as a test for if it is inside the same object. I was confused about how memmove can work in C without relying on undefined behaviour. But I just read http://www.cplusplus.com/reference/clibrary/cstring/memcpy/ which defines it in terms of an intermediate buffer. So maybe, the current CTFE implementation is _exactly_ consistent with the C spec. If that's true, though, I find it pretty incredible that there is no way to find out if a pointers points a particular array, even if you have pointers to both the start and end of that array. (OK, I guess you can iterate from start to end, checking for equality, but .. bleah .. it's a terrible abstraction inversion). You could implement it as simply comparing the addresses - you'd be no worse off than C is, and you would get the correct answer for pointers both in and out of the array without needing special cases.
Re: dget - getting code from github
On 5/26/2012 3:04 PM, Martin Nowak wrote: On Sat, 26 May 2012 03:35:13 +0200, Walter Bright wrote: On 5/25/2012 1:32 AM, Martin Nowak wrote: Anyone want to implement such? It ought to be fairly straightforward, and will be a nice timesaver for a lot of people. https://gist.github.com/2786276 usage: rdmd dget dsimcha/TempAlloc libevent How about slapping a Boost license on it and creating a pull request for: https://github.com/D-Programming-Language/tools ? I will do that after some cleanup. Great!
Re: dget - getting code from github
On Sat, 26 May 2012 03:35:13 +0200, Walter Bright wrote: On 5/25/2012 1:32 AM, Martin Nowak wrote: Anyone want to implement such? It ought to be fairly straightforward, and will be a nice timesaver for a lot of people. https://gist.github.com/2786276 usage: rdmd dget dsimcha/TempAlloc libevent How about slapping a Boost license on it and creating a pull request for: https://github.com/D-Programming-Language/tools ? I will do that after some cleanup.
Re: Pointer semantics in CTFE
Le 25/05/2012 17:38, Steven Schveighoffer a écrit : On Fri, 25 May 2012 11:08:52 -0400, David Nadlinger wrote: On Friday, 25 May 2012 at 14:06:55 UTC, Steven Schveighoffer wrote: Remove the restriction. The code is unpredictable, but not invalid. It just means you need to take more care when writing such code. The question is whether we want to allow unpredictable behavior at compile time. Given the alternative, yes I think we do. -Steve What ? We absolutely don't whant that, and teh alternative is pretty simple : using slices.
Re: clear() and UFCS
On Saturday, 26 May 2012 at 08:38:10 UTC, RivenTheMage wrote: On Saturday, 26 May 2012 at 06:06:08 UTC, sclytrack wrote: On 05/26/2012 06:58 AM, jerro wrote: On Saturday, 26 May 2012 at 03:21:31 UTC, Mehrdad wrote: Why not just call it 'destroy()'? +1 +1 +1 +1 I'll agree, destroy has no hidden meanings and is easy to remember. If 'clear' becomes free, it can be used in other things, say a graphics program that clears a editing window. I also liked recycle and zero. Dump should probably not be used, as having used linux dump to me means you'd want to dump the object's data out to the screen or to a file for analysis.
Re: Nimrod language
Chad J wrote: I think my only complaints were the bus-factor and the apparent lack of array slices (the kind that doesn't cause copying). Still, very promising. It actually does have slices as a construct in the system lib (included by default). http://force7.de/nimrod/system.html#139 http://force7.de/nimrod/system.html#606 but I'm not sure how they stack up against D's in practice.
Compiling Data into a D Executable
http://www.gamedev.net/blog/1140/entry-2254294-compiling-data-into-a-d-executable/ and on Reddit: http://www.reddit.com/r/programming/comments/u5sgs/compiling_data_into_a_d_executable/
Re: Destructor nonsense on dlang.org
Le 25/05/2012 16:35, Andrei Alexandrescu a écrit :
On 5/25/12 12:07 AM, Mehrdad wrote:
Now, there are two ways a FileStream can get destroyed:
1. Through a manual call to FileStream.Dispose(). In this case, all
embedded objects (e.g. SafeFileHandle) are *guaranteed* to be valid, so
we simply flush the file and call SafeFileHandle.Dispose() to dispose of
the managed resources, and then dispose of all the unmanaged resources
(which are primitive fields, guaranteed to be accessible). Furthermore,
the object suppresses its own finalizer.
2. Through a garbage-collected call to ~FileStream(). In this case, the
managed resources such as SafeFileHandle will be (or is already)
destroyed SEPARATELY, and so we do _NOT_ access them. We ONLY dispose of
the unmanaged resources, if any, and let the managed resources take care
of themselves.
What happens in C# if an object A that has a field referring to object
B, and the object B has in turn a field referring to object A? That is:
class C { C another; ~this() { writeln(another.another); } }
void main() {
auto a = new C;
auto b = new C;
a.another = b;
b.another = a;
}
What happens then? Will the GC nullify references to destroyed objects,
or will it put them in a zombie state?
Thanks,
Andrei
Here is what I suggest :
1/ what is in ~this stay in ~this. You cannot escape a reference to this
or anything reached throw this of ~this. In other terms, the hidden this
parameter get scope storage class. This avoid resurrection (something we
really want, it have caused much trouble in java).
2/ The GC will call all finalizers on objects (here a and b) when they
are garbage. Finalizers are called in undefined order.
3/ The GC will recycle the memory after all finalizers ran.
In the example above, both writeln will executed and then, both object's
memory will be recycled.
Re: clear() and UFCS
On Saturday, May 26, 2012 14:00:15 Jacob Carlborg wrote: > On 2012-05-26 03:38, Jonathan M Davis wrote: > > clear and delete are very different things. It was definitely decided that > > we'd be better off without delete. It's going for good. Renaming clear to > > something that doesn't conflict so easily with more benign functions is > > completely different from bringing back delete. Bringing back delete > > isn't even on the table at this point. > > > > - Jonathan M Davis > > Why can't "delete" do what "clear" does. Backwards compatibility? I would think that that would be a bad idea, because it wouldn't be doing what delete does in C++ at all and would be really confusing to a lot of people. It would probably work without them realizing what was going on (since it's stupid to do anything with a deleted object other than assign it a new value, which would work with clear), but it would end up with very different behavior memory-wise, causing unexpected behavior. Another problem is that we're trying to discourage using stuff like clear unless you actually need to and know what you're doing, whereas delete is used all the time in C++, because it doesn't _have_ a GC built in. So, having clear as a language construct rather than a function is arguably a bad idea, because it elevates it to something more normal. If it's delete, a lot of people will just use it without learning what's really going on, whereas they'll have to actually learn about clear to use it. Also, it would have a negative effect on ported code to change clear to delete. If delete is illegal, then the compiler will catch it when you forget to remove it from ported code, whereas if it just does what clear does, you could end up with deletes left in when you didn't intend to, but now they have different semantics. - Jonathan M Davis
Re: dbuilder, pakage manager, dget
Fix link: http://pypi.python.org/pypi that is pypi and not pypy
Re: dbuilder, pakage manager, dget
Le samedi 26 mai 2012 à 17:33 +0200, Jacob Carlborg a écrit : > On 2012-05-26 13:34, bioinfornatics wrote: > > Dear, > > > > dbuilder: https://github.com/dbuilder-developers/dbuilder > > > > currently dbuilder works on Linux, Apple, Windows platform (at least) > > this tool allow to us to build easily lib, or desktop application > > It support // build, // install > > i think i will improve this tool to be use as a package manager, for > > this add to supported config file a new section > > --- > > [[dependenies]] > > [[[xxx] > > version_type=[version, tag, revision] > > repo_url=https://github ...https://bitbucket ... > > tool=[git, hg, svn] > > version=xx > > tag=xx > > revision=xx > > --- > > > > put the config file at root of repo for detect this file and use it > > > > if this config is not enough for to be used as config said to me what > > need to be added > > > > anyone is welcome > > I don't think a built tool and package manager should be in the same > tool. A built tool works with individual files. A package manager works > with package, i.e. complete libraries/tools/applications. > > I also think that in the long run both a build tool and a package > manager needs to use a full programming language as their config files. > pypy from python do both http://pypy.org/ get dependencies, build from setup script
Re: Nimrod language
On Saturday, 26 May 2012 at 16:01:25 UTC, Jacob Carlborg wrote: I had a look at the Nimrod language, the template and macro features look really cool. I would love to have those in D. I would be great to see such a mechanism employed to increase the power-to-weight ratio of the D language (e.g. relegate a construct like "scope" to the standard library).
Re: UFCS on forward reference
Status update: I created a pull request for the trivial change required to allow UFCS on opaque structs. Kenji Hara balked at the change however, on the grounds that it opens up function hijacking. I argued why that is not true-- at least using Walter's original definition of hijacking. No response from Kenji, and things have been at a standstill for a week now. Really this comes down to how we want to define opaque struct in the language specification. The current definition from (http://dlang.org/struct.html): "The members are completely hidden to the user, and so the only operations on those types are ones that do not require any knowledge of the contents of those types." That definition is a bit vague. Do methods count as "contents" of a struct? I propose distinguishing between structural content (fields, types, and sizes) and non-structural content (methods): "Members are completely hidden to the user. Operations which require knowledge of the struct layout are not allowed and yield a compile error. As far as methods, an opaque struct has none-- a property which can be relied on when employing uniform function call syntax." http://d.puremagic.com/issues/show_bug.cgi?id=8104
Re: Nimrod language
On 2011-01-02 07:46, bearophile wrote: Andrei: My fantasy: bearophile goes to the Nimrod forum and says "Hey, how about this D language, seems interesting..." :o) That fantasy of yours means that I am interested in using my time to explain to Nimrod developers what's good in D, what may be modified or improved, to steal some of the good ideas of the D language for the development and spreading of Nimrod :-) Bye, bearophile I had a look at the Nimrod language, the template and macro features look really cool. I would love to have those in D. -- /Jacob Carlborg
Add CTFE execute function
CTFE execute will be very useful on web develop, for example It is very hard to create a CTFE version template engine with rich feature. But we can use execute call to transe template file to d code string, then mixed it to application. The vibed project is very cool and I want to add my Jade template to this, but I can't find other way to do it. Maybe we also need a compiler option to enable this CTFE io operate because security.
Re: Destructor nonsense on dlang.org
On 2012-05-26 14:28, foobar wrote: Huh? In my model FooA has no destructor. Hm, right. But if a destructor of a class isn't guaranteed to be called, how can it guarantee that the struct's destructor will be called? I indeed propose that structs allocated with "new" will be put in region of the heap *not* managed by the GC. It's a tiny price to pay to get more orthogonal semantics which are easier to reason about. Please note that this only affects code that directly uses pointers which is not common in D and is geared towards more advanced use cases where the programmer will likely want to manage the memory explicitly anyway. I see. -- /Jacob Carlborg
Re: dbuilder, pakage manager, dget
On 2012-05-26 13:34, bioinfornatics wrote: Dear, dbuilder: https://github.com/dbuilder-developers/dbuilder currently dbuilder works on Linux, Apple, Windows platform (at least) this tool allow to us to build easily lib, or desktop application It support // build, // install i think i will improve this tool to be use as a package manager, for this add to supported config file a new section --- [[dependenies]] [[[xxx] version_type=[version, tag, revision] repo_url=https://github ...https://bitbucket ... tool=[git, hg, svn] version=xx tag=xx revision=xx --- put the config file at root of repo for detect this file and use it if this config is not enough for to be used as config said to me what need to be added anyone is welcome I don't think a built tool and package manager should be in the same tool. A built tool works with individual files. A package manager works with package, i.e. complete libraries/tools/applications. I also think that in the long run both a build tool and a package manager needs to use a full programming language as their config files. -- /Jacob Carlborg
Re: Nimrod language
On 5/26/12, Marco Leise wrote: > It looks like "ventor3000" mentioned D there just yesterday on those forums. > Here is an excerpt: > "I really like D but i think its totally overkill for > real world applications. And I say this of long experience: Keep it simple. > [...]" You can always keep the D code simple, it's totally up to the programmer. I really don't understand what is "overkill" about D, nobody is forced to use every single feature in the language. And on the plus side, as you write more D code you come to realize its various features come in really handy.
Re: ColorD
mine code for ansi terminal
==
enum Attributes : size_t{
RESET,
BOLD,
NORMAL,
UNDERLINE,
BLINK,
INVERSE,
HIDE
}
size_t getBackgroundColor( string color ){
size_t result;
switch(color){
case("black"):
result = 30;
break;
case("red"):
result = 31;
break;
case("green"):
result = 32;
break;
case("yellow"):
result = 33;
break;
case("blue"):
result = 34;
break;
case("violet"):
result = 35;
break;
case("cyan"):
result = 36;
break;
case("white"):
result = 37;
break;
case("default"):
result = 0;
break;
default:
throw new Exception( "Unknow color: %d".format(color) );
}
return result;
}
size_t getUndergroundColor( string color ){
size_t result;
switch(color){
case("black"):
result = 40;
break;
case("red"):
result = 41;
break;
case("green"):
result = 42;
break;
case("yellow"):
result = 43;
break;
case("blue"):
result = 44;
break;
case("violet"):
result = 45;
break;
case("cyan"):
result = 46;
break;
case("white"):
result = 47;
break;
case("default"):
result = 0;
break;
default:
throw new Exception( "Unknow color: %d".format(color) );
}
return result;
}
string colorString( string backgroundColor, string undergroundColor,
string content, Attributes[] attributes...){
size_t bg = getBackgroundColor( backgroundColor );
size_t fg = getUndergroundColor( undergroundColor );
string result = "\033[";
foreach(attribute; attributes){
result = result ~ "%d;".format(attribute);
}
result = result ~ "%d;%dm%s\033[0;0m".format(fg, bg, content);
return result;
}
void clean(){
write("\033[H\033[2J");
}
Re: clear() and UFCS
On 2012-05-26 12:00:15 +, Jacob Carlborg said: On 2012-05-26 03:38, Jonathan M Davis wrote: clear and delete are very different things. It was definitely decided that we'd be better off without delete. It's going for good. Renaming clear to something that doesn't conflict so easily with more benign functions is completely different from bringing back delete. Bringing back delete isn't even on the table at this point. - Jonathan M Davis Why can't "delete" do what "clear" does. Backwards compatibility? That'd be my preferred solution too. I think it makes a lot of sense. Clear does almost the same thing as delete, except that currently delete means memory can be reused immediately, which is not safe. If the only difference is that one is safe and the other is not, and if we're going to deprecate and then remove delete because it's not safe, wouldn't it make more sense to simply make 'delete' memory-safe by giving it the semantics of clear()? By the way, clear() as "clear" would have made more sense if it was effectively destructing then reconstructing the object in place, making it a suitable default implementation of the container-kind clear(). But for what it does right now, it's *clearly* misleading. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
ColorD
I would like to share with my new library written in D. As name may suggest (or not) it adds color to your console output, it works on both Linux and Windows platforms. I haven't seen any similar library for D language, so I decided to create this one. Source and examples(included in Readme file) can be found on GitHub repo: https://github.com/robik/ColorD Regards, Robik.
Re: Destructor nonsense on dlang.org
On 05/26/12 13:35, Jacob Carlborg wrote:
> On 2012-05-25 14:05, foobar wrote:
>
>>> If you have a pointer to a struct you don't know how it was created.
>>> It's possible it's been created with "new", which means the garbage
>>> collector needs to delete it.
>>
>> let's say we add two classes:
>> class FooA {
>> A a;
>> }
>> class FooPA {
>> A* pa;
>> }
>>
>> For the first case, both the class and the struct share the same
>> lifetime thus when an instance of FooA is GC-ed, the GC would call A's
>> d-tor and allow it to do what-ever (self) cleaning it requires. This
>> means the d-tor will always be called.
>
> Is that the cases even if the destructor of FooA isn't called?
>
>> For the second case, The GC will only scan "pa" to find inner class
>> instances but will *not* handle the struct value itself.
>> In order to clean what "pa" points to, you need to explicitly call the
>> destructor yourself.
>
> Are you saying that the GC won't collect a struct allocated with "new"?
>
> http://dlang.org/expression.html#NewExpression
>
> "NewExpressions are used to allocate memory on the garbage collected
> heap...". I though that everything allocated via the GC was also collected by
> the GC.
Everything allocated is collected, though not necessarily destructed. In case
of structs, the GC currently doesn't know about the dtors, so those are never
called.
import std.stdio;
struct S { ~this() { writeln("never called"); } }
void main() { S* sp; while (1) sp = new S(); }
Right now you have to use a class if you need dtors for heap allocated
objects.
artur
Re: clear() and UFCS
On Saturday, 26 May 2012 at 08:52:06 UTC, Alex Rønne Petersen wrote: On 26-05-2012 10:48, Francisco Almeida wrote: I vote for destroy(). It seems to be a popular choice, and it isn't ambiguous in any way. Are there any classes/structs using destroy() methods in Phobos? Francisco It doesn't actually matter. It wouldn't be ambiguous. UFCS prefers the method on a class/struct over a free function. It wouldn't break existing types, yes, but would probably cause confusion similar to clear() right now if the name was already in (widespread) use. David
Re: Destructor nonsense on dlang.org
On Saturday, 26 May 2012 at 11:35:29 UTC, Jacob Carlborg wrote:
On 2012-05-25 14:05, foobar wrote:
If you have a pointer to a struct you don't know how it was
created.
It's possible it's been created with "new", which means the
garbage
collector needs to delete it.
let's say we add two classes:
class FooA {
A a;
}
class FooPA {
A* pa;
}
For the first case, both the class and the struct share the
same
lifetime thus when an instance of FooA is GC-ed, the GC would
call A's
d-tor and allow it to do what-ever (self) cleaning it
requires. This
means the d-tor will always be called.
Is that the cases even if the destructor of FooA isn't called?
Huh? In my model FooA has no destructor.
For the second case, The GC will only scan "pa" to find inner
class
instances but will *not* handle the struct value itself.
In order to clean what "pa" points to, you need to explicitly
call the
destructor yourself.
Are you saying that the GC won't collect a struct allocated
with "new"?
http://dlang.org/expression.html#NewExpression
"NewExpressions are used to allocate memory on the garbage
collected heap...". I though that everything allocated via the
GC was also collected by the GC.
I indeed propose that structs allocated with "new" will be put in
region of the heap *not* managed by the GC. It's a tiny price to
pay to get more orthogonal semantics which are easier to reason
about.
Please note that this only affects code that directly uses
pointers which is not common in D and is geared towards more
advanced use cases where the programmer will likely want to
manage the memory explicitly anyway.
One way to do this would be to register a callback
with the GC to get notified when an instance of FooPA is
collected and
inside the callback function maintain a reference-counter.
This also means that if you allocate a struct value on the
heap via
"new" you are responsible to call delete _yourself_ and the gc
will not
call it for you.
I think that loosing this small convenience is worth it - we
gay more
orthogonal semantics that are easier to reason about.
Re: clear() and UFCS
On 2012-05-26 03:38, Jonathan M Davis wrote: clear and delete are very different things. It was definitely decided that we'd be better off without delete. It's going for good. Renaming clear to something that doesn't conflict so easily with more benign functions is completely different from bringing back delete. Bringing back delete isn't even on the table at this point. - Jonathan M Davis Why can't "delete" do what "clear" does. Backwards compatibility? -- /Jacob Carlborg
Re: Nimrod language
On 05/24/2012 07:21 PM, Araq wrote: On Thursday, 24 May 2012 at 22:56:52 UTC, Kevin Cox wrote: On May 24, 2012 6:53 PM, "Froglegs" wrote: Like the design, syntax is way better than D But half of what makes a language are the compilers/debuggers/tool I like many ideas of the language but there are some show-stoppers for me. For example the fact that you have to define things in order. I shouldn't have to deal with that in this day and age. Nimrod is full of constructs that have inlining semantics and as such declaration order matters quite a bit. The D compiler has/had bugs with this feature for a reason. ;-) OK, now I'm curious. Why? I'm considering to weaken the requirement but I don't mind this feature: Having the order reflect the call graph has its advantages too. Many consider the resulting order *backwards*, but at least there is *an* order. Wouldn't it be good enough to define the order arbitrarily when building your symbol table? What kind of information is this allowing the programmer to convey to the compiler? I'm already skeptical because I have no intuition for how this allows me to better optimize my code ;) Btw, I've looked at Nimrod a while ago (year+) and found it very elegant. I love good metaprogramming. I think my only complaints were the bus-factor and the apparent lack of array slices (the kind that doesn't cause copying). Still, very promising.
Re: Nimrod language
On 2012-05-25 14:04, dom96 wrote: You will, you can compile an empty .nim file and you still get an executable. BTW http://nimrod-code.org/ is the new Nimrod website, the one you linked to is long outdated. Ah, thanks. I though that the address didn't look quite right. -- /Jacob Carlborg
dbuilder, pakage manager, dget
Dear, dbuilder: https://github.com/dbuilder-developers/dbuilder currently dbuilder works on Linux, Apple, Windows platform (at least) this tool allow to us to build easily lib, or desktop application It support // build, // install i think i will improve this tool to be use as a package manager, for this add to supported config file a new section --- [[dependenies]] [[[xxx] version_type=[version, tag, revision] repo_url=https://github ...https://bitbucket ... tool=[git, hg, svn] version=xx tag=xx revision=xx --- put the config file at root of repo for detect this file and use it if this config is not enough for to be used as config said to me what need to be added anyone is welcome
Re: Destructor nonsense on dlang.org
On 2012-05-25 14:05, foobar wrote:
If you have a pointer to a struct you don't know how it was created.
It's possible it's been created with "new", which means the garbage
collector needs to delete it.
let's say we add two classes:
class FooA {
A a;
}
class FooPA {
A* pa;
}
For the first case, both the class and the struct share the same
lifetime thus when an instance of FooA is GC-ed, the GC would call A's
d-tor and allow it to do what-ever (self) cleaning it requires. This
means the d-tor will always be called.
Is that the cases even if the destructor of FooA isn't called?
For the second case, The GC will only scan "pa" to find inner class
instances but will *not* handle the struct value itself.
In order to clean what "pa" points to, you need to explicitly call the
destructor yourself.
Are you saying that the GC won't collect a struct allocated with "new"?
http://dlang.org/expression.html#NewExpression
"NewExpressions are used to allocate memory on the garbage collected
heap...". I though that everything allocated via the GC was also
collected by the GC.
One way to do this would be to register a callback
with the GC to get notified when an instance of FooPA is collected and
inside the callback function maintain a reference-counter.
This also means that if you allocate a struct value on the heap via
"new" you are responsible to call delete _yourself_ and the gc will not
call it for you.
I think that loosing this small convenience is worth it - we gay more
orthogonal semantics that are easier to reason about.
--
/Jacob Carlborg
Re: Is the D community lacking development tools?
On 2012-05-25 16:07, Dejan Lekic wrote: Well, the OT was about lacking of development tools. The author did not specify the level of proficiency. Sure many things are missing from current tools, but come on, the fact is that one can do a serious D project with Mono-D. Well, at least I think without a second thought that it is possible. I do all my D coding with TextMate with a customized D bundle and the command line. -- /Jacob Carlborg
Re: Pointer semantics in CTFE
On 26.05.2012 05:35, Walter Bright wrote: On 5/25/2012 8:24 PM, Don wrote: The problem is, if pstart and pend point to the beginning and end of an array, then given another pointer q, there is AFAIK no defined way in C for checking if q is between pstart and pend, even though I'm sure everyone does it. (eg, I don't know how to implement memcpy otherwise). If q is part of that array, (q >= pstart && q <= pend) is well-defined, and returns true. But if it isn't part of that array, q >= pstart is undefined. In reality of course, if q is unrelated to the array then EITHER q < pstart, OR q > pend. So (q >= pstart && q <= pend) is ALWAYS false, and the result is completely predictable. If q is unrelated to the array, which you can tell because q, pstart, and pend must all refer to the same object that CTFE knows about, then you can have CTFE refuse to execute it. Yes, that's what happens now. But that doesn't help the programmer. If it is inside, no problem, the expression is true. But if it is not inside, the expression is not false -- it's a compile-time error. So you can't use it as a test for if it is inside the same object. I was confused about how memmove can work in C without relying on undefined behaviour. But I just read http://www.cplusplus.com/reference/clibrary/cstring/memcpy/ which defines it in terms of an intermediate buffer. So maybe, the current CTFE implementation is _exactly_ consistent with the C spec. If that's true, though, I find it pretty incredible that there is no way to find out if a pointers points a particular array, even if you have pointers to both the start and end of that array. (OK, I guess you can iterate from start to end, checking for equality, but .. bleah .. it's a terrible abstraction inversion). ie, the full expression can be well-defined even though its two subexpressions are not. This can be implemented. Given an expression like q >= pstart, where p and q are unrelated, it's possible to make it have the value 'false_or_undefined'. If it is anded with another expression that is also false_or_undefined, and goes the other direction ( q <= pend) , then the whole thing is false. Otherwise, it generates an error. The reason it would have to be a special case is because of things like: bool b = false; q >= start && ( b = true, true) && q <= end which is undefined because the result of the first comparison has been stored. So it would only be valid for one-comparison-in-each-direction-anded-together (and the equivalent for ||). I still don't think you need to make a special case for it. If upon initialization of q, pstart, and pend, CTFE makes a note of what memory object they are initialized from, then you can unambiguously tell if they still point within the same object or not.
Re: dget - getting code from github
Le mercredi 23 mai 2012 à 16:14 -0700, Walter Bright a écrit : > Currently, getting D code from github is a multistep process, that isn't > always > obvious. I propose the creation of a dget program, which will: > > dget https://github.com/D-Programming-Deimos/libevent > > download the libevent code and install it in a subdirectory named libevent. > Of > course, the url could also be: > > dget github.com/D-Programming-Deimos/libevent > > since https is assumed, or: > > dget D-Programming-Deimos/libevent > > since github is assumed. And since Deimos is a known library, > > dget libevent > > can also be hardwired into dget. > > Anyone want to implement such? It ought to be fairly straightforward, and > will > be a nice timesaver for a lot of people. yes it is a feature i wish to add but the repository should be always the same or by a config file understand where is the source code (root of dir in src dir ...), if it is a lib, a desktop application, a web application (which vied, serenity ..), detect dependencies i have start a little project for build common D project (80% of use case) https://github.com/organizations/dbuilder-developers this tool could in more download and build/install easilly if you put at root of the github repo a config file (example of config file supported https://github.com/dbuilder-developers/dbuilder/blob/master/examples/dbuilder.cfg ) Any help are welcome, this tool goal to be easy to use $ dbuilder get xxx // not implemented $ dbuilder build $ dbuilder install in more from command line you can override value in config file Sorry for my english )
Re: clear() and UFCS
On 26-05-2012 10:48, Francisco Almeida wrote: On Friday, 25 May 2012 at 18:22:08 UTC, Andrei Alexandrescu wrote: On 5/25/12 12:37 PM, Mirko Pilger wrote: Now I don't have a good name. Finalize isn't right, and neither is dispose... what about "invalidate"? Whatever it is, I should say I'll be very strongly opposed to any proposal if it is about as controversial as "clear". Andrei I vote for destroy(). It seems to be a popular choice, and it isn't ambiguous in any way. Are there any classes/structs using destroy() methods in Phobos? Francisco It doesn't actually matter. It wouldn't be ambiguous. UFCS prefers the method on a class/struct over a free function. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: clear() and UFCS
On Friday, 25 May 2012 at 18:22:08 UTC, Andrei Alexandrescu wrote: On 5/25/12 12:37 PM, Mirko Pilger wrote: Now I don't have a good name. Finalize isn't right, and neither is dispose... what about "invalidate"? Whatever it is, I should say I'll be very strongly opposed to any proposal if it is about as controversial as "clear". Andrei I vote for destroy(). It seems to be a popular choice, and it isn't ambiguous in any way. Are there any classes/structs using destroy() methods in Phobos? Francisco
Re: clear() and UFCS
On Saturday, 26 May 2012 at 06:06:08 UTC, sclytrack wrote: On 05/26/2012 06:58 AM, jerro wrote: On Saturday, 26 May 2012 at 03:21:31 UTC, Mehrdad wrote: Why not just call it 'destroy()'? +1 +1 +1
