Re: HibernateD and DDBC - ORM and DB abstraction layer for D
Am 29.04.2013 11:25, schrieb Kagamin:
On Friday, 5 April 2013 at 07:32:55 UTC, Vadim Lopatin wrote:
@Embeddable // required for Embeddable
class Address {
String zip; // @Null
String state; // @Null
string streetAddress; // @NotNull
}
Is it good to assume string is not null? For most scenarios there's
little difference between null and empty string.
Null blows up your code, doesn't. Also it's a SQL thing, NotNull
must be initialized, when the row is filled.
Crowdfunding article features DConf 2013
http://workbar.com/tips-tales-of-effective-crowdfunding/ Andrei
Re: Crowdfunding article features DConf 2013
On 4/29/13 10:49 AM, Andrei Alexandrescu wrote: http://workbar.com/tips-tales-of-effective-crowdfunding/ Andrei On reddit technology: http://www.reddit.com/r/technology/comments/1dcmzd/tips_tales_of_effective_crowdfunding/ Vote up! Andrei
DConf 2013 on twitter
Use hashtag #dconf to stay up to date during the conference, even if you can't attend. I'll see y'all Wed morning!
Re: DConf 2013 on twitter
On 4/29/2013 11:47 AM, Walter Bright wrote: Use hashtag #dconf to stay up to date during the conference, even if you can't attend. I'll see y'all Wed morning! https://twitter.com/search?q=%23dconf
Re: DUB 0.9.13 released
On 4/16/13 5:49 PM, Sönke Ludwig wrote: Changes: - Support for a new buildRequirements field to be able to specify things like Don't treat warnings as errors or Allow use of deprecated features - A lot of improvements to the VisualD project generator - Some important bug fixes Change log: https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md Download: http://registry.vibed.org/download Probably a stupid question but can DUB be used to install DMD? Instructions please. Thanks
Re: DConf 2013 on twitter
Just curious if there were any plans to put videos/slideshows from the presentations online after the conference?
Re: DConf 2013 on twitter
On 04/29/2013 06:44 PM, Diggory wrote: Just curious if there were any plans to put videos/slideshows from the presentations online after the conference? Yes, that's the plan. Ali
Re: DUB 0.9.13 released
On Monday, April 29, 2013 21:27:48 Tyro[17] wrote: On 4/16/13 5:49 PM, Sönke Ludwig wrote: Changes: - Support for a new buildRequirements field to be able to specify things like Don't treat warnings as errors or Allow use of deprecated features - A lot of improvements to the VisualD project generator - Some important bug fixes Change log: https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md Download: http://registry.vibed.org/download Probably a stupid question but can DUB be used to install DMD? Instructions please. There is no dub build for dmd. dmd is built using makefiles, and it really needs the druntime, Phobos, and tools projects as well (all of which build with makefiles) - especially if you're going to install it - and dub does not currently support building with makefiles or including other projects like that. It also doesn't support installing anything AFAIK. It just builds stuff with the bonus that it'll download and build the dependencies for you first. It may be possible for dub to do all of that in the future, but not now. - Jonathan M Davis
Re: Stable D version?
On 2013-04-29 01:11, Mehrdad wrote: Curious, which ones are you referring to? Windows uses C for the kernel, for many reasons, one of which is that C (unlike C++) discourages storing large objects on the stack. Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers). Which vendors have switched to C++ for systems programming? The kernel in Mac OS X is written in a subset of C++. -- /Jacob Carlborg
Re: 1 matches bool, 2 matches long
On 4/28/2013 2:05 AM, deadalnix wrote: On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote: On 4/27/2013 2:29 PM, Rob T wrote: If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords? Because writing cast(bool)0 and cast(bool)1 is unappealing. VRP say you don't need to. You're implying there is no need for 1L or 1U either, but there is. The other reason, mentioned before, is that without making them a keyword or standard type, people will inevitably create their own in one of many different, incompatible, ways.
Re: Formal Review of std.uni
On 2013-04-28 18:56, Jesse Phillips wrote: First off, Dconf is this next weekend and effects the schedule of this review. Review will be held for 3 weeks, instead of holding off a week I'm extending the period and starting the review now. (Dmitry may be unable to respond due to his being a speaker) This is a replacement module for the current std.uni by Dmitry Olshansky. The std.uni module provides an implementation of fundamental Unicode algorithms and data structures. Two minor things: * The docs for decomposeHangul contains a ddoc macro * toLower and toUpper mention overloads which take strings instead of a dchar. I cannot find those overloads in the std.uni module. If they refer to another module it should say so -- /Jacob Carlborg
Re: Stable D version?
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote: Am 28.04.2013 12:03, schrieb Dicebot: On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote: I also think when modules are integrated into the C++ True, but only now the major OS vendors are switching from C to C++ as their main systems programming language. I think that exactly because it is a switch *in the happening*, it is the moment for D to be involve in that switch. Because project managers are considering switching and they look for alternatives. Maybe some of them will tell themselves: well, if we switch, why do not take that D in consideration? at least, for experimenting and see what it gives. It is useless to be a good alternative if nobody wants to switch. If they go down on the C++ path, then two things will happen: -they will be even more reluctant to do another switch, while their code base matures (and, do not forget, interoperability or portability from C to D is one thing; form C++ to D is a different, huge, beast). -C++ will get more traction and more pressure to improve itself, from vendors and community at large. it will advance faster. In the end, we should not be sorry, as programmers we will win better language, better tools. But I am afraid that D will not win as much.
Re: 1 matches bool, 2 matches long
On Friday, 26 April 2013 at 14:28:59 UTC, Rob T wrote: On Friday, 26 April 2013 at 08:03:14 UTC, Walter Bright wrote: On 4/25/2013 11:16 PM, deadalnix wrote: This feature never has been useful to me. It has been useful to me. So there! Come on, characters are not an integral type, they are just an ordered and, for that reason, an indexed type. All the usual operations on characters apply to the index behnid (which is given by the ASCII/Unicode representation). You are not adding characters, you are adding indices of those characters and so on. And you make a simple convention to always thing character for a givent (integer) index, since the index per se is of no much use without its equivalent representation from the ASCII table. On the same grounds, one could index the values of bool form 4 to 5 and assimilate false for 4 and true for 5, then go with the above convention. There is a difference, however, between the bool and the char here: for the bool you want to go straight from the logical value to a conventional integral value, do not even think about some kind of tabular representation, while for the ASCII representation of char you seem to forget that such kind of a table exists in the first place.
Re: Stable D version?
On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote: ... D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view.
Re: Stable D version?
On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote: On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote: D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view. Well, then a list of what's still missing should be compiled (in terms of features and language changes, not in terms of bugs). An rush to complete it. Some of the issues were discussed since many months, and no definitive decision has been taken (see the @property). I am rather in favor of taking a decision, good or bad, than to prolonge ambiguity. Also for several minor issues (ie: double[$] static arrays and __MODULE__ identifier and so on). For those, I would like to see a more accelerated pace. I even start thinking that is better to release a new feature after a relative short, preliminary discussion, and be prepared to change it during a time frame, if it is not as practical as desired, instead of prolonging a discussion for centuries in the search of the perfect implementation.
Re: Stable D version?
On Monday, 29 April 2013 at 08:07:05 UTC, eles wrote: I even start thinking that is better to release a new feature after a relative short, preliminary discussion, and be prepared to change it during a time frame, if it is not as practical as desired, instead of prolonging a discussion for centuries in the search of the perfect implementation. That brings us back to the Stable D subject, and the separation between stable and unstable. Those preliminary features should be included in the unstable releases, where changes can be made without the fear of breaking things. Then, after some actual usage, they would be merged to the stable branch.
Re: Stable D version?
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote: On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote: True, but only now the major OS vendors are switching from C to C++ as their main systems programming language. Curious, which ones are you referring to? Windows uses C for the kernel, for many reasons, one of which is that C (unlike C++) discourages storing large objects on the stack. Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers). Which vendors have switched to C++ for systems programming? BeOS/Haiku - C++ Symbian - C++ MacOS X - Device Drivers are written in a C++ subset (IOKit) z/OS - Original code was Modula-2/Assembly, with new code being C++ Windows - WinRT is C++, C is considered legacy, Herb Sutter stated at BUILD 2012 that Windows team is making kernel code C++ compatible. I can search for the exact minute in the videos if you wish.
Re: Stable D version?
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote: On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote: Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers). err, Linus
Re: 1 matches bool, 2 matches long
On Monday, 29 April 2013 at 06:26:44 UTC, Walter Bright wrote: On 4/28/2013 2:05 AM, deadalnix wrote: On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote: On 4/27/2013 2:29 PM, Rob T wrote: If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords? Because writing cast(bool)0 and cast(bool)1 is unappealing. VRP say you don't need to. You're implying there is no need for 1L or 1U either, but there is. The other reason, mentioned before, is that without making them a keyword or standard type, people will inevitably create their own in one of many different, incompatible, ways. The same could be said of booleans. If D does not have a proper logical boolean type rather than a bit then people will simply write their own (conflicting and likely inefficient) boolean types which work the way they expect. I've actually used a language where boolean is effectively a 1-bit integer, and I can safely say that I have never found a single advantage over a language with more strongly type booleans which can implicitly be cast to int, but not the other way around. On the other hand the disadvantages are quite extensive: confusion for anyone who has ever used any other high level language, confusing overload resolution as shown in this thread, special cases (booleans convert by comparison rather than truncation, obviously truncation would be stupid but I think this is more of a reason to ditch integer booleans rather than to introduce a special case), different meaning (an integer is a number, a boolean is more like a yes/no enum and that is how it will be used in almost all code regardless of how it is defined in the language), etc.
Re: Stable D version?
On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote: On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote: ... D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view. This guys don't have any issues selling Oberon compilers for embedded use. http://www.oberonday2011.ethz.ch/talks/armembedded.pdf http://www.astrobe.com/default.htm A GC enabled systems programming language. Oracle with their Spots and the new Keil board support (Java) http://www.sunspotworld.com/ http://docs.oracle.com/javame/config/cldc/rel/3.3/keil/gs/html/getstart_rtx/running.htm Or the Netduino guys (C#) http://netduino.com/ Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards.
Re: 1 matches bool, 2 matches long
On Monday, 29 April 2013 at 09:49:59 UTC, Diggory wrote: On Monday, 29 April 2013 at 06:26:44 UTC, Walter Bright wrote: On 4/28/2013 2:05 AM, deadalnix wrote: On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote: On 4/27/2013 2:29 PM, Rob T wrote: this thread, special cases (booleans convert by comparison rather than truncation, obviously truncation would be stupid but I think this is more of a reason to ditch integer booleans rather than to introduce a special case), different meaning (an integer is a number, a boolean is more like a yes/no enum and that is how it will be used in almost all code regardless of how it is defined in the language), etc. gdc: bool x = false; x++; main.d:50: Error: operation not allowed on bool 'x' why not? is just an integer after all. another special case? this works: int x = false; x++;
Re: Stable D version?
On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote: This guys don't have any issues selling Oberon compilers for embedded use. ... That is simple, embedded is a buzzword often understood as something like PC but small. Such definition is quite useless because it implies no specific requirements. Like, calling modern ARM smartphone an embedded system? No way. You can even afford to have something as inefficient as kernel in Java on those machines, why not. Much more practical definition of embedded is all about specific requirements. Real-time systems, systems with hard memory restrictions (imagine coding in environment where malloc is prohibited because every single byte of physical memory is pre-allocated). Those can vary from microchips to monstrous servers and I don't see anything but C or C++ with lot of custom policies used there.
trusted purity?
Is there *any* way to make a call to a non-pure function in a pure context, if you know you won't violate your own purity? This is something you can do with @safe (@trusted), but what about pure? For example, free is not pure, because you can't call it twice on the same pointer. But if you manage the pointer yourself inside a struct, you can guarantee the purity of your own functions. But the language won't allow you to do that. Related question: Can a function that sometimes throws be considered as pure?
Re: Stable D version?
On Monday, 29 April 2013 at 10:38:32 UTC, Dicebot wrote: On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote: This guys don't have any issues selling Oberon compilers for embedded use. ... That is simple, embedded is a buzzword often understood as something like PC but small. Such definition is quite useless because it implies no specific requirements. Like, calling modern ARM smartphone an embedded system? No way. You can even afford to have something as inefficient as kernel in Java on those machines, why not. Much more practical definition of embedded is all about specific requirements. Real-time systems, systems with hard memory restrictions (imagine coding in environment where malloc is prohibited because every single byte of physical memory is pre-allocated). Those can vary from microchips to monstrous servers and I don't see anything but C or C++ with lot of custom policies used there. Quoting myself Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards.
Re: trusted purity?
I've been working on a pull request and came up with something
like this:
private void initialize(A...)(auto ref A args)
{
auto m = cast(void* function(size_t size) pure)malloc;
_store = cast(Impl*) enforce(m(Impl.sizeof));
auto r = cast(void function(in void* p, size_t sz) nothrow
pure)GC.addRange;
static if (hasIndirections!T)
r(_store._payload, T.sizeof);
emplace(_store._payload, args);
_store._count = 1;
}
The purity of emplace depends on the purity of the ctor called.
I'm not sure how to fix that.
Re: trusted purity?
By the way, my post is related to the impurity of RefCounted: http://d.puremagic.com/issues/show_bug.cgi?id=9998
Re: Stable D version?
On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote: Quoting myself Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards. Okay, pardon me, may be I have not highlighted my point clear enough: there is no real market for D in that limited subset because it has to compete with Java, C# or any modern language based on their virtual machines. And, similar to desktop usage, lot of selling points for D are lost then, because, well, why bother? Contrary to this, any language who can make it into real embedded domain will be almost uncontested, because this industry is still stuck with 40-year obsolete tools. But that is not something that may happen on its own.
Re: trusted purity?
On Monday, 29 April 2013 at 11:15:20 UTC, Henning Pohl wrote:
I've been working on a pull request and came up with something
like this:
private void initialize(A...)(auto ref A args)
{
auto m = cast(void* function(size_t size) pure)malloc;
_store = cast(Impl*) enforce(m(Impl.sizeof));
auto r = cast(void function(in void* p, size_t sz) nothrow
pure)GC.addRange;
static if (hasIndirections!T)
r(_store._payload, T.sizeof);
emplace(_store._payload, args);
_store._count = 1;
}
I always forget you can cast the type of a function...
The purity of emplace depends on the purity of the ctor
called. I'm not sure how to fix that.
I'm not sure there's anything to fix there: If the CTor is not
pure, then how could emplace be pure?
I did some work on emplace that is awaiting to be pulled, which
should improve its purity.
On Monday, 29 April 2013 at 11:19:33 UTC, Henning Pohl wrote:
By the way, my post is related to the impurity of RefCounted:
http://d.puremagic.com/issues/show_bug.cgi?id=9998
Yes, that is also what I am investigating. The cast is would
indeed be a fix for malloc/free. RefCounted's
isInitialized/refCount still need to be marked as pure though.
I'm still worried about what it means for a pure function to
throw... (I'm thinking about the enforce(malloc) scheme)
Re: trusted purity?
On Monday, 29 April 2013 at 11:32:33 UTC, monarch_dodra wrote: I'm still worried about what it means for a pure function to throw... (I'm thinking about the enforce(malloc) scheme) If malloc returns null, we are out of memory. In D this is not an exception, it is an error. So I guess we just need to check the pointer returned by malloc and throw an OutOfMemoryError on failure. Thus if the ctor called is nothrow, it can be marked as nothrow, too. So in this case, there should be no problem making it pure.
Re: trusted purity?
On Monday, 29 April 2013 at 11:50:11 UTC, Henning Pohl wrote: On Monday, 29 April 2013 at 11:32:33 UTC, monarch_dodra wrote: I'm still worried about what it means for a pure function to throw... (I'm thinking about the enforce(malloc) scheme) If malloc returns null, we are out of memory. In D this is not an exception, it is an error. So I guess we just need to check the pointer returned by malloc and throw an OutOfMemoryError on failure. Thus if the ctor called is nothrow, it can be marked as nothrow, too. So in this case, there should be no problem making it pure. I've hit this issue before: In D, if the *managed* memory runs out, then it is an error (since then *everything* crumbles: arrays, GC. etc). The reason it is an error is that since the memory is managed by the language, there is nothing the user can do anyway, so throwing is pointless. for unmanaged memory, on the otherhand, the user *can* do something about it, so throwing is better. I myself am not sure I 100% agree with this, but that was the conclusion last time I tried to transform an malloc=Exception into a malloc=Error+Nothrow
Re: trusted purity?
On Monday, 29 April 2013 at 12:08:58 UTC, monarch_dodra wrote: I've hit this issue before: In D, if the *managed* memory runs out, then it is an error (since then *everything* crumbles: arrays, GC. etc). The reason it is an error is that since the memory is managed by the language, there is nothing the user can do anyway, so throwing is pointless. for unmanaged memory, on the otherhand, the user *can* do something about it, so throwing is better. I myself am not sure I 100% agree with this, but that was the conclusion last time I tried to transform an malloc=Exception into a malloc=Error+Nothrow What about using allocators the user can specify? The default one would be malloc + Error + nothrow. All the signatures of RefCounted have to change depending on the allocator's ones, though. This is where attribute inference is rather needed.
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On Sunday, 28 April 2013 at 16:33:19 UTC, Idan Arye wrote: When you use `std.typecons.Nullable` with a type that already accept `null` values, you get two types of nulls - the `Nullable`'s null state the the regular type's `null`: Nullable!string a; writeln(a.isNull()); //prints true a = null; writeln(a.isNull()); //prints false a.nullify(); writeln(a.isNull()); //prints true All types should be non nullable. Problem solved.
Re: DConf 2013 official car/room sharing thread
On Sunday, 24 March 2013 at 21:32:12 UTC, Andrei Alexandrescu wrote: Hello to all prospective DConf 2013 attendees! A few of you are interested in sharing options for rental cars, or to share hotel rooms and split the cost in half. Let this thread be the official tracker for such requests and offers. I'll also post a link to this thread on http://dconf.org/venue.html. If necessary, we'll also post important related notices there. So, just reply to this with your offers and requests! Thanks, Andrei Due to last minute issue, I find myself in an hotel in mountain view. 3km/2miles away from the caltrain, so I'll need someone to grab me if that is possible. I promise to be good company on the road :D
Re: 1 matches bool, 2 matches long
On Sunday, 28 April 2013 at 19:38:26 UTC, eles wrote: On Sunday, 28 April 2013 at 19:19:53 UTC, Walter Bright wrote: On 4/27/2013 2:58 PM, jerro wrote: On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright To reiterate, history amply shows that if 'true' and 'false' are not there, then people will define them themselves, inconsistently, and the end result is not helpful to anybody. So basically, those are to be seen as simple #defines for 0 and 1 and nothing more than that? I am for a boolean type that is only true and false. And, if so much needed conversion from int 0 and int non0 to boolean is needed in if() and while(), then simply add ifz(), ifnz(), whilez() and whilenz() to the language. (that is: ifzero(), infnonzero(), whilezero(), whilenonzero()). This is plain useless as a cast is already inserted here.
Re: 1 matches bool, 2 matches long
On Sunday, 28 April 2013 at 22:40:33 UTC, Andrei Alexandrescu
wrote:
On 4/28/13 5:41 PM, kenji hara wrote:
Yes, as Andrei mentioned, it is sometimes useful. But, at
least during
overload resolution, it must not occur.
Kenji Hara
Well the problem has other ramifications beyond bool. Consider:
import std.stdio;
int fun(short v1) { return 1; }
int fun(long v1) { return 2; }
void main(string[] args)
{
writeln(fun(10_000));
writeln(fun(100_000));
}
This prints 1 2. So the behavior of bool in this case is
consistent with the behavior of other integral types.
For the same reason, both should call the long overload.
Re: 1 matches bool, 2 matches long
On Monday, 29 April 2013 at 12:30:06 UTC, deadalnix wrote: On Sunday, 28 April 2013 at 19:38:26 UTC, eles wrote: On Sunday, 28 April 2013 at 19:19:53 UTC, Walter Bright wrote: On 4/27/2013 2:58 PM, jerro wrote: On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright This is plain useless as a cast is already inserted here. so, only allow explict casting then.
Re: 1 matches bool, 2 matches long
On Monday, 29 April 2013 at 00:45:47 UTC, Mehrdad wrote: On Monday, 29 April 2013 at 00:40:08 UTC, Andrei Alexandrescu wrote: 2. Stop allowing implicit bool-int conversions (explicit conversions like in if/while/etc. are of course not included here) Unlikely to ever happen. What's the use case against it? This is useful, and do not cause problem by itself. The reverse conversion is problematic.
Re: Stable D version?
On Monday, 29 April 2013 at 11:24:02 UTC, Dicebot wrote: On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote: Quoting myself Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards. Okay, pardon me, may be I have not highlighted my point clear enough: there is no real market for D in that limited subset because it has to compete with Java, C# or any modern language based on their virtual machines. And, similar to desktop usage, lot of selling points for D are lost then, because, well, why bother? Contrary to this, any language who can make it into real embedded domain will be almost uncontested, because this industry is still stuck with 40-year obsolete tools. But that is not something that may happen on its own. Fair enough, I agree with you there.
GDB support for multithreaded D application debugging
Greetings I just wanted to find out how good is the GDB support for debugging multithreaded code written in D language. I remember trying it sometimes back, but could not get it to work. Any suggestions? Regards - Puneet
Re: 1 matches bool, 2 matches long
gdc: bool x = false; x++; main.d:50: Error: operation not allowed on bool 'x' why not? is just an integer after all. another special case? If you are going to create a boolean then use it as a boolean - it's not an integer any more. Don't mix and match - there's nothing worse than trying to follow some code that uses a variable in one way then, out of lazyness, uses it in a different way. this works: int x = false; x++;
Re: 1 matches bool, 2 matches long
On Monday, 29 April 2013 at 14:08:20 UTC, Mike James wrote: gdc: bool x = false; x++; main.d:50: Error: operation not allowed on bool 'x' why not? is just an integer after all. another special case? If you are going to create a boolean then use it as a boolean - it's not an integer any more. Don't mix and match - there's nothing worse than trying to follow some code that uses a variable in one way then, out of lazyness, uses it in a different way. that was exactly my point. that a boolean *should not* be an integer. and the case that I presented shows just another inconsistency of the relationship between booleans and integers in D. it works one way when it comes to function overloading, and another way when it comes to, let's say, ++ operator.
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On Monday, 29 April 2013 at 12:23:04 UTC, deadalnix wrote: On Sunday, 28 April 2013 at 16:33:19 UTC, Idan Arye wrote: When you use `std.typecons.Nullable` with a type that already accept `null` values, you get two types of nulls - the `Nullable`'s null state the the regular type's `null`: Nullable!string a; writeln(a.isNull()); //prints true a = null; writeln(a.isNull()); //prints false a.nullify(); writeln(a.isNull()); //prints true All types should be non nullable. Problem solved. *All* types? Even object references and pointers?
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On 2013-04-29, 17:34, Idan Arye wrote: On Monday, 29 April 2013 at 12:23:04 UTC, deadalnix wrote: On Sunday, 28 April 2013 at 16:33:19 UTC, Idan Arye wrote: When you use `std.typecons.Nullable` with a type that already accept `null` values, you get two types of nulls - the `Nullable`'s null state the the regular type's `null`: Nullable!string a; writeln(a.isNull()); //prints true a = null; writeln(a.isNull()); //prints false a.nullify(); writeln(a.isNull()); //prints true All types should be non nullable. Problem solved. *All* types? Even object references and pointers? That would be nice, yes. -- Simen
Re: DConf 2013 official car/room sharing thread
I'll be in SFO at midday if anyone is heading down from up that way? Otherwise, can anyone suggest the best way to get there from the airport? On 29 Apr 2013 05:30, deadalnix deadal...@gmail.com wrote: On Sunday, 24 March 2013 at 21:32:12 UTC, Andrei Alexandrescu wrote: Hello to all prospective DConf 2013 attendees! A few of you are interested in sharing options for rental cars, or to share hotel rooms and split the cost in half. Let this thread be the official tracker for such requests and offers. I'll also post a link to this thread on http://dconf.org/venue.html. If necessary, we'll also post important related notices there. So, just reply to this with your offers and requests! Thanks, Andrei Due to last minute issue, I find myself in an hotel in mountain view. 3km/2miles away from the caltrain, so I'll need someone to grab me if that is possible. I promise to be good company on the road :D
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On Monday, 29 April 2013 at 15:39:47 UTC, Simen Kjaeraas wrote: On 2013-04-29, 17:34, Idan Arye wrote: On Monday, 29 April 2013 at 12:23:04 UTC, deadalnix wrote: On Sunday, 28 April 2013 at 16:33:19 UTC, Idan Arye wrote: When you use `std.typecons.Nullable` with a type that already accept `null` values, you get two types of nulls - the `Nullable`'s null state the the regular type's `null`: Nullable!string a; writeln(a.isNull()); //prints true a = null; writeln(a.isNull()); //prints false a.nullify(); writeln(a.isNull()); //prints true All types should be non nullable. Problem solved. *All* types? Even object references and pointers? That would be nice, yes. And what would they be initialized to? When you write: Object obj; what will `obj` refer to? Also, what about the CC++ interface? Without null values, how can you use an extern function that accepts or returns pointers?
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On Monday, 29 April 2013 at 15:34:30 UTC, Idan Arye wrote: On Monday, 29 April 2013 at 12:23:04 UTC, deadalnix wrote: On Sunday, 28 April 2013 at 16:33:19 UTC, Idan Arye wrote: When you use `std.typecons.Nullable` with a type that already accept `null` values, you get two types of nulls - the `Nullable`'s null state the the regular type's `null`: Nullable!string a; writeln(a.isNull()); //prints true a = null; writeln(a.isNull()); //prints false a.nullify(); writeln(a.isNull()); //prints true All types should be non nullable. Problem solved. *All* types? Even object references and pointers? Especially object references and pointers.
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On Monday, 29 April 2013 at 16:02:11 UTC, Idan Arye wrote: On Monday, 29 April 2013 at 15:39:47 UTC, Simen Kjaeraas wrote: On 2013-04-29, 17:34, Idan Arye wrote: On Monday, 29 April 2013 at 12:23:04 UTC, deadalnix wrote: On Sunday, 28 April 2013 at 16:33:19 UTC, Idan Arye wrote: When you use `std.typecons.Nullable` with a type that already accept `null` values, you get two types of nulls - the `Nullable`'s null state the the regular type's `null`: Nullable!string a; writeln(a.isNull()); //prints true a = null; writeln(a.isNull()); //prints false a.nullify(); writeln(a.isNull()); //prints true All types should be non nullable. Problem solved. *All* types? Even object references and pointers? That would be nice, yes. And what would they be initialized to? When you write: Object obj; what will `obj` refer to? Also, what about the CC++ interface? Without null values, how can you use an extern function that accepts or returns pointers? Data flow analysis can smash your face if you try to use that before initializing it. In fact, this is already done in many languages.
Re: 1 matches bool, 2 matches long
On Sat, 27 Apr 2013 12:51:48 -0700, Walter Bright newshou...@digitalmars.com wrote: On 4/26/2013 7:36 PM, Mehrdad wrote: Walter, you're completely missing the point. I completely understand it is a perception problem. Some people see bool as a 1 bit integer (including me). Some see bool as something very distinct from integers (including you). short x = cast(short)0x1; assert(x == 0); bool b = cast(bool)2; assert(b == 1); // NOT 2s complement bool is not an integer. It doesn't behave like any other integer type. Because it has some power to implicitly cast to int, this does not make it an integer. -Steve
Re: 1 matches bool, 2 matches long
On Monday, 29 April 2013 at 14:08:20 UTC, Mike James wrote: gdc: bool x = false; x++; main.d:50: Error: operation not allowed on bool 'x' why not? is just an integer after all. another special case? If you are going to create a boolean then use it as a boolean - it's not an integer any more. Don't mix and match - there's nothing worse than trying to follow some code that uses a variable in one way then, out of lazyness, uses it in a different way. this works: int x = false; x++; The main point made in this thread is that because bool is not really an integral type, you cannot use it as one, but D overloads integral types with bool which is clearly wrong. You also cannot in general interchange ints and bools inside a template without special conditions to differentiate between them the two (eg ++bool fails), therefore bool should not overload on ints or implicitly cast to/from ints and bools under most situations. --rt
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On 2013-04-29, 18:02, Idan Arye wrote: On Monday, 29 April 2013 at 15:39:47 UTC, Simen Kjaeraas wrote: On 2013-04-29, 17:34, Idan Arye wrote: On Monday, 29 April 2013 at 12:23:04 UTC, deadalnix wrote: On Sunday, 28 April 2013 at 16:33:19 UTC, Idan Arye wrote: When you use `std.typecons.Nullable` with a type that already accept `null` values, you get two types of nulls - the `Nullable`'s null state the the regular type's `null`: Nullable!string a; writeln(a.isNull()); //prints true a = null; writeln(a.isNull()); //prints false a.nullify(); writeln(a.isNull()); //prints true All types should be non nullable. Problem solved. *All* types? Even object references and pointers? That would be nice, yes. And what would they be initialized to? When you write: Object obj; what will `obj` refer to? It won't. That would be a compile-time error: 'Variable obj needs an initializer'. We have some of this already in @disable this(). However, a true non-nullable reference is, I believe, not possible in D today. -- Simen
Re: 1 matches bool, 2 matches long
On Sat, 27 Apr 2013 13:27:39 -0700, Walter Bright newshou...@digitalmars.com wrote: On 4/26/2013 11:04 PM, Steven Schveighoffer wrote: I think the issue (and I am firmly in the foo(1) = long camp) is that bools are considered better integers than actual integer types (or even floating point types for that matter). I agree that bools can be implicitly cast to and from integers, as a last resort. The overload system in D is explicitly not based on better. (The C++ better overloading system is for functions, but not for templates.) The D overload system is based on partial ordering, which is the same as what C++ uses for templates. I don't know for a fact, but I'm pretty sure the partial ordering scheme that C++ selected for templates, which came along many years later, was picked because people realized it was better (and more mathematically robust and defensible). One of the problems with a better matching system is handling functions with multiple parameters, each with their own better match. (The C++ Standard devotes a great deal of complex text to this, it boils down to a bunch of rather arbitrary decisions.) Partial ordering solves this neatly and consistently. As one who implemented C++'s better matching system, I can confidently state that the partial ordering scheme is FAR better overall. I think you are inventing a strawman problem that this bug solves. There is no need for a Better scheme, partial ordering works great, and so do true and false. bool isn't an integer. It can implicitly cast to an integer, but that's it. Once we implement that rule, everything falls into place. If you want to pass a true boolean literal, use true. If you want to pass a false boolean literal use false. Using 1 and 0 may be convenient, and may also be valid, but when it matches an integral type as well as bool, then it's ambiguous. -Steve
Re: trusted purity?
I'm getting strange behavior trying to cast to pure. This is my
test program:
//
import std.stdio;
import core.stdc.stdlib;
void main()
{
auto p1 = core.stdc.stdlib.free;
auto p2 = cast(void function(void*))core.stdc.stdlib.free;
auto p3 = cast(void function(void*)
pure)core.stdc.stdlib.free;
auto pp1 = core.stdc.stdlib.malloc(5);
auto pp2 = core.stdc.stdlib.malloc(5);
auto pp3 = core.stdc.stdlib.malloc(5);
writeln(p1);
p1(pp1);
writeln(p2);
p2(pp2); //This hangs
writeln(p3); //Never reaches here
p3(pp3);
}
//
Am I doing something wrong? Could somebody else test this? I'm on
win32.
I've also been getting some object violations trying to use this
cast...
Re: DConf 2013 official car/room sharing thread
On 04/29/2013 09:03 AM, Manu wrote: can anyone suggest the best way to get there from the airport? We have used door-to-door airport shuttles many times in the past. The cost should be around $35-45 to most places around Menlo Park. When you arrive, just walk out of the international terminal; you can't miss the door-to-door shuttles. Ask their prices and pick the cheaper one. Unfortunately, I work today. Otherwise, I would have picked you up like I will tomorrow, to take you to the ACCU talk. :) (Thanks again!) Ali
Re: trusted purity?
On Monday, 29 April 2013 at 10:58:45 UTC, monarch_dodra wrote: Is there *any* way to make a call to a non-pure function in a pure context, if you know you won't violate your own purity? This is something you can do with @safe (@trusted), but what about pure? This raise the case once again for trusted as a statement and not as a qualifier. Tis would solve the purity issue. Related question: Can a function that sometimes throws be considered as pure? Yes as long at its behavior depends only on parameters.
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On Monday, 29 April 2013 at 16:14:02 UTC, deadalnix wrote:
On Monday, 29 April 2013 at 16:02:11 UTC, Idan Arye wrote:
On Monday, 29 April 2013 at 15:39:47 UTC, Simen Kjaeraas wrote:
On 2013-04-29, 17:34, Idan Arye wrote:
On Monday, 29 April 2013 at 12:23:04 UTC, deadalnix wrote:
On Sunday, 28 April 2013 at 16:33:19 UTC, Idan Arye wrote:
When you use `std.typecons.Nullable` with a type that
already accept `null` values, you get two types of nulls -
the `Nullable`'s null state the the regular type's `null`:
Nullable!string a;
writeln(a.isNull()); //prints true
a = null;
writeln(a.isNull()); //prints false
a.nullify();
writeln(a.isNull()); //prints true
All types should be non nullable. Problem solved.
*All* types? Even object references and pointers?
That would be nice, yes.
And what would they be initialized to? When you write:
Object obj;
what will `obj` refer to?
Also, what about the CC++ interface? Without null values, how
can you use an extern function that accepts or returns
pointers?
Data flow analysis can smash your face if you try to use that
before initializing it. In fact, this is already done in many
languages.
The point is that you are forcing ref variables to point to data,
even in paths where there is no data for them to point to.
Let's say we have something like:
MyClass myObject;
auto myVar1=DEFAULT_VALUE_FOR_MY_VAR_1;
bool objectCreated=false;
if(myCondition()){
myObject=new MyClass(/*some arguments*/);
objectCreated=true;
myVar1=myObject.calculateSomething();
}
auto myVar2=calculateSomethingElse(myVar1);
if(objectCreated){
myObject.doSomething(myVar2);
}
doSomethingElse(myVar2);
It would be nice to create `myObject` in the second `if`, right
before we use it, but this is not possible, since if
`myCondition` is `true` and we do allocate `myObject`, we need to
use it to calculate `myVar2`. And we can't pull the call for
`myObject.doSomething` to the first `if` either - because we need
to calculate `myVar2` before we use it. So, why not bring the
calculation of `myVar2` into the first `if` as well? Because we
need it for `doSomethingElse`, which should be invoked whether or
not we allocate `myObject`!
As humans, we can easily see that if we didn't allocate
`myObject` that will also mean that `objectCreated` remains
false, and therefore the program will not enter the second `if`.
I would like to see a data flow analysis mechanism that figures
that out - and that's a simple case!
If `myObject` was `int` it would be easy - we could initialize it
to `0` at declaration. But object references are not that simple
- if you take away `null`, what will you init `myObject` to?
Remember - it needs to be an instance of `MyClass` or of a
subclass of `MyClass`. That means that:
a) You have to allocate memory for an object you will not use.
b) You need to call a constructor, that might have side-effects.
c) You end up with an object that has a meaningless state.
Now, let's look at that meaningless object we created. What if
`MyClass` has fields which are object references themselves? They
can't be in the uninitialized state - I would like to see the
data flow analysis mechanism that can follow that! So, that means
we need to set them to meaningless objects as well.
Now, consider implementing a linked list.
Re: 1 matches bool, 2 matches long
On Monday, April 29, 2013 09:54:40 Steven Schveighoffer wrote: On Sat, 27 Apr 2013 12:51:48 -0700, Walter Bright newshou...@digitalmars.com wrote: On 4/26/2013 7:36 PM, Mehrdad wrote: Walter, you're completely missing the point. I completely understand it is a perception problem. Some people see bool as a 1 bit integer (including me). Some see bool as something very distinct from integers (including you). short x = cast(short)0x1; assert(x == 0); bool b = cast(bool)2; assert(b == 1); // NOT 2s complement bool is not an integer. It doesn't behave like any other integer type. Because it has some power to implicitly cast to int, this does not make it an integer. It also isn't considered to be an integral type per std.traits.isIntegral. isIntegral only considers byte, ubyte, short, ushort, int, uint, long, and ulong to be integral types. - Jonathan M Davis
Re: Formal Review of std.uni
29-Apr-2013 10:45, Jacob Carlborg пишет: On 2013-04-28 18:56, Jesse Phillips wrote: First off, Dconf is this next weekend and effects the schedule of this review. Review will be held for 3 weeks, instead of holding off a week I'm extending the period and starting the review now. (Dmitry may be unable to respond due to his being a speaker) This is a replacement module for the current std.uni by Dmitry Olshansky. The std.uni module provides an implementation of fundamental Unicode algorithms and data structures. Two minor things: * The docs for decomposeHangul contains a ddoc macro Thanks, fixed that and the same typo elsewhere. * toLower and toUpper mention overloads which take strings instead of a dchar. I cannot find those overloads in the std.uni module. If they refer to another module it should say so Technically these should be in std.string and are there but incorrect. Plus the impossible to implement toLowerInPlace/toUpperInPlace since length may change during case-conversion. Darn... I got to implement them in std.uni then. Not much work given that all of pieces are already here. -- Dmitry Olshansky
Re: 1 matches bool, 2 matches long
Am 29.04.2013 19:10, schrieb Steven Schveighoffer: On Sat, 27 Apr 2013 13:27:39 -0700, Walter Bright newshou...@digitalmars.com wrote: On 4/26/2013 11:04 PM, Steven Schveighoffer wrote: I think the issue (and I am firmly in the foo(1) = long camp) is that bools are considered better integers than actual integer types (or even floating point types for that matter). I agree that bools can be implicitly cast to and from integers, as a last resort. The overload system in D is explicitly not based on better. (The C++ better overloading system is for functions, but not for templates.) The D overload system is based on partial ordering, which is the same as what C++ uses for templates. I don't know for a fact, but I'm pretty sure the partial ordering scheme that C++ selected for templates, which came along many years later, was picked because people realized it was better (and more mathematically robust and defensible). One of the problems with a better matching system is handling functions with multiple parameters, each with their own better match. (The C++ Standard devotes a great deal of complex text to this, it boils down to a bunch of rather arbitrary decisions.) Partial ordering solves this neatly and consistently. As one who implemented C++'s better matching system, I can confidently state that the partial ordering scheme is FAR better overall. I think you are inventing a strawman problem that this bug solves. There is no need for a Better scheme, partial ordering works great, and so do true and false. bool isn't an integer. It can implicitly cast to an integer, but that's it. Once we implement that rule, everything falls into place. If you want to pass a true boolean literal, use true. If you want to pass a false boolean literal use false. Using 1 and 0 may be convenient, and may also be valid, but when it matches an integral type as well as bool, then it's ambiguous. -Steve Fully agree, I still not understand what is the issue to support the boolean strong typing other languages do offer. -- Paulo
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On 2013-04-29, 19:57, Idan Arye wrote:
On Monday, 29 April 2013 at 16:14:02 UTC, deadalnix wrote:
On Monday, 29 April 2013 at 16:02:11 UTC, Idan Arye wrote:
On Monday, 29 April 2013 at 15:39:47 UTC, Simen Kjaeraas wrote:
On 2013-04-29, 17:34, Idan Arye wrote:
On Monday, 29 April 2013 at 12:23:04 UTC, deadalnix wrote:
On Sunday, 28 April 2013 at 16:33:19 UTC, Idan Arye wrote:
When you use `std.typecons.Nullable` with a type that already
accept `null` values, you get two types of nulls - the
`Nullable`'s null state the the regular type's `null`:
Nullable!string a;
writeln(a.isNull()); //prints true
a = null;
writeln(a.isNull()); //prints false
a.nullify();
writeln(a.isNull()); //prints true
All types should be non nullable. Problem solved.
*All* types? Even object references and pointers?
That would be nice, yes.
And what would they be initialized to? When you write:
Object obj;
what will `obj` refer to?
Also, what about the CC++ interface? Without null values, how can you
use an extern function that accepts or returns pointers?
Data flow analysis can smash your face if you try to use that before
initializing it. In fact, this is already done in many languages.
The point is that you are forcing ref variables to point to data, even
in paths where there is no data for them to point to.
Let's say we have something like:
MyClass myObject;
auto myVar1=DEFAULT_VALUE_FOR_MY_VAR_1;
bool objectCreated=false;
if(myCondition()){
myObject=new MyClass(/*some arguments*/);
objectCreated=true;
myVar1=myObject.calculateSomething();
}
auto myVar2=calculateSomethingElse(myVar1);
if(objectCreated){
myObject.doSomething(myVar2);
}
doSomethingElse(myVar2);
It would be nice to create `myObject` in the second `if`, right before
we use it, but this is not possible, since if `myCondition` is `true`
and we do allocate `myObject`, we need to use it to calculate `myVar2`.
And we can't pull the call for `myObject.doSomething` to the first `if`
either - because we need to calculate `myVar2` before we use it. So, why
not bring the calculation of `myVar2` into the first `if` as well?
Because we need it for `doSomethingElse`, which should be invoked
whether or not we allocate `myObject`!
As humans, we can easily see that if we didn't allocate `myObject` that
will also mean that `objectCreated` remains false, and therefore the
program will not enter the second `if`. I would like to see a data flow
analysis mechanism that figures that out - and that's a simple case!
If `myObject` was `int` it would be easy - we could initialize it to `0`
at declaration. But object references are not that simple - if you take
away `null`, what will you init `myObject` to? Remember - it needs to be
an instance of `MyClass` or of a subclass of `MyClass`. That means that:
a) You have to allocate memory for an object you will not use.
b) You need to call a constructor, that might have side-effects.
c) You end up with an object that has a meaningless state.
Now, let's look at that meaningless object we created. What if `MyClass`
has fields which are object references themselves? They can't be in the
uninitialized state - I would like to see the data flow analysis
mechanism that can follow that! So, that means we need to set them to
meaningless objects as well.
Now, consider implementing a linked list.
Now, consider the fact we have Nullable in Phobos.
--
Simen
Re: trusted purity?
On 4/29/2013 3:58 AM, monarch_dodra wrote: Is there *any* way to make a call to a non-pure function in a pure context, if you know you won't violate your own purity? Vee haf veys: 1. put debug before the impure code (but you'll have to compile with -debug) 2. put the impure code in a separate function, take its address, and cast its address to being a pointer to a pure function. (Of course, such a cast should be rejected by @safe code.) 3. Put the code in an extern(C) function, compiled separately as impure, but declared as pure in the client. C functions don't get name mangling, so the compiler won't know it's impure. I feel it's a good thing that you'll need to jump through some hoops to do this, otherwise 'pure' would not be very useful. Related question: Can a function that sometimes throws be considered as pure? deadalnix's answer is correct.
Re: trusted purity?
On 4/29/2013 5:08 AM, monarch_dodra wrote: I've hit this issue before: In D, if the *managed* memory runs out, then it is an error (since then *everything* crumbles: arrays, GC. etc). The reason it is an error is that since the memory is managed by the language, there is nothing the user can do anyway, so throwing is pointless. for unmanaged memory, on the otherhand, the user *can* do something about it, so throwing is better. You cannot call a function pure if it sometimes throws a recoverable exception and sometimes does not, and this is not based on the supplied arguments.
Re: DConf 2013 official car/room sharing thread
On Monday, 29 April 2013 at 16:04:00 UTC, Manu wrote: I'll be in SFO at midday if anyone is heading down from up that way? Otherwise, can anyone suggest the best way to get there from the airport? Where is there? I just used BART/Caltrain – not very fancy and takes a while to get there, but since my hotel is near the Palo Alto stop, it was ideal for me. David
Re: trusted purity?
On 4/29/2013 10:19 AM, monarch_dodra wrote: I'm getting strange behavior trying to cast to pure. This is my test program: You're casting a C function to a D function. This will cause crashes.
Re: 1 matches bool, 2 matches long
On 4/29/2013 10:10 AM, Steven Schveighoffer wrote: On Sat, 27 Apr 2013 13:27:39 -0700, Walter Bright newshou...@digitalmars.com wrote: On 4/26/2013 11:04 PM, Steven Schveighoffer wrote: I think the issue (and I am firmly in the foo(1) = long camp) is that bools are considered better integers than actual integer types (or even floating point types for that matter). I agree that bools can be implicitly cast to and from integers, as a last resort. The overload system in D is explicitly not based on better. (The C++ better overloading system is for functions, but not for templates.) The D overload system is based on partial ordering, which is the same as what C++ uses for templates. I don't know for a fact, but I'm pretty sure the partial ordering scheme that C++ selected for templates, which came along many years later, was picked because people realized it was better (and more mathematically robust and defensible). One of the problems with a better matching system is handling functions with multiple parameters, each with their own better match. (The C++ Standard devotes a great deal of complex text to this, it boils down to a bunch of rather arbitrary decisions.) Partial ordering solves this neatly and consistently. As one who implemented C++'s better matching system, I can confidently state that the partial ordering scheme is FAR better overall. I think you are inventing a strawman problem that this bug solves. There is no need for a Better scheme, partial ordering works great, and so do true and false. bool isn't an integer. It can implicitly cast to an integer, but that's it. Once we implement that rule, everything falls into place. If you want to pass a true boolean literal, use true. If you want to pass a false boolean literal use false. Using 1 and 0 may be convenient, and may also be valid, but when it matches an integral type as well as bool, then it's ambiguous. Carefully reading your statement, you are still arguing that matching 1 to long should be better than matching it to bool.
Re: trusted purity?
On Monday, April 29, 2013 12:58:44 monarch_dodra wrote: Is there *any* way to make a call to a non-pure function in a pure context, if you know you won't violate your own purity? This is something you can do with @safe (@trusted), but what about pure? For example, free is not pure, because you can't call it twice on the same pointer. But if you manage the pointer yourself inside a struct, you can guarantee the purity of your own functions. But the language won't allow you to do that. You can cast a pointer to the function. std.datetime does that for the LocalTime and UTC singletons. Take a look at the semi-recently added std.traits.SetFunctionAttributes. Related question: Can a function that sometimes throws be considered as pure? Throwing has nothing to do with purity. pure is purely a question of whether the function accesses module-level or static variables which can possibly be mutated after they're initialized. Strong purity (which is required for most/all optimizations) is then places additional requirements on the function parameters, but purity itself is simply a question of whether the function accesses module-level or static variables. So, throwing has nothing to do with it. - Jonathan M Davis
Re: Formal Review of std.uni
On Monday, April 29, 2013 22:13:09 Dmitry Olshansky wrote: Technically these should be in std.string and are there but incorrect. Then fix them there. - Jonathan M Davis
Re: 1 matches bool, 2 matches long
On Sunday, 28 April 2013 at 13:38:53 UTC, Andrei Alexandrescu wrote: [...] If enough differences accumulate to make bool quite a different type from a regular integral, then the matter of overloading with long, conversion from literals 1 and 0 etc. may be reopened. Even then, it would be a difficult decision. I agree with most of what you said in your full post, except that in the quote above you are suggesting that there's a difficult decision to be made in the case of bool being it's own type rather than an integral type. The opposite should be the case, where the decision to keep it as an integral is a difficult to defend. I don't see where the difficulty is, because unless bool can exactly be treated as an integral, then it simply is not an integral, and unless it is an integral, it cannot be freely interchanged with the integrals. The arguments in defense if bool as an integral are IMO weak. For example, Walter mentioned the case of char successfully being treated as an integral type rather than a special case char' type. However, are there any differences between what char does and what byte does that interfere with each other? If char performs exactly like a integral type, then you can convincingly argue that it is an integral type. Can the same thing with char be said about bool? No. You can only say that bool does share some, but not all the characteristics if an integral. The other argument in favor boils down to a matter of convenience under some circumstances. Yes, there are a few cases where it is advantageous to interchange boolean 'true' and 'false' with integral 1 and 0, however the vast majority of uses do not rely on such an interchange, and even if such interchanges are used often, bool still has significant differences of behavior that exclude it from being considered as a fully interchangeable integral type (eg truncation behavior and differences with operators). The best you can argue for, is that under some situations, bool should be freely interchanged with regular integrals, however that's not going to be true for all cases. The conclusion ought to be that unless bool can be adjusted into behaving exactly like all the other integrals, then it simply cannot be freely interchanged as an integral in all cases, i.e., maybe OK in some cases, but certainly not all. --rt
Re: 1 matches bool, 2 matches long
On 4/29/2013 7:30 AM, deadalnix wrote:
(that is: ifzero(), infnonzero(), whilezero(), whilenonzero()).
int x = 3;
if (!!x)
{
// do something
}
Its not official but this already works in the C like langauges, as a
way to 'promote to bool'
Re: 1 matches bool, 2 matches long
On Monday, 29 April 2013 at 18:53:22 UTC, Sean Cavanaugh wrote: On 4/29/2013 7:30 AM, deadalnix wrote: Its not official but this already works in the C like langauges, as a way to 'promote to bool' I know, but I still think that ifz() and ifnz() convey better (more, they are easier to debug, but that's subjective). However, is not a big deal.
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On Monday, 29 April 2013 at 18:20:35 UTC, Simen Kjaeraas wrote:
On 2013-04-29, 19:57, Idan Arye wrote:
Now, consider the fact we have Nullable in Phobos.
Yes, we have `Nullable` in Phobos. It works by having two member
fields - `_value`, which stores the value, and `_isNull`, which
specifies if the `Nullable` is null or not. Let's implement a
bare bones Linked List:
class Node(T){
T value;
Nullable!(Node!T) next;
this(){}
this(T value){
this.value=value;
}
this(T value,Node!T next){
this.value=value;
this.next=next;
}
}
Now lets create an instance:
auto myList=new Node(Hello);
What will happen?
We create a new `Node!string`. it's `value` will be set to
hello, and since the one-argument constructor does not modify
`next`, it will it will remain as the init value of
`Nullable!(Node!string)`. What is the init value of
`Nullable!(Node!string)`?
The init value of `Nullable!(Node!string)` is an object with two
member fields - `value` of type `string` and `next` of type
`Nullable!(Node!string)`. The default constructor modifies
neither, so they will both remain with their initial values. The
init value of `string` is an empty string. What is the init value
of `Nullable!(Node!string)`? To find the answer, return to the
beginning of this paragraph and read it again.
You are not supposed to be reading this paragraph. You are
supposed to be stuck in an infinite recursion in the previous
paragraph. As a human, you can cheat and escape it, but the
computer is not so lucky - it'll allocate more and more objects
until it'll crash with a stack overflow.
Actually - that won't happen, since the compiler is smart enough
to detect type recursion and emit e compile time error. But the
problem remains - we are left unable to implement any type of
recursive structure.
Re: trusted purity?
On Monday, 29 April 2013 at 18:34:46 UTC, Walter Bright wrote: On 4/29/2013 10:19 AM, monarch_dodra wrote: I'm getting strange behavior trying to cast to pure. This is my test program: You're casting a C function to a D function. This will cause crashes. OK, so say I have a documented pure C function, how do I call it from a pure scope? You say, take the address and cast it, but not if it's C...
Re: Is the other-kind-of-null really necessary in Nullable and Variant?
On Monday, 29 April 2013 at 20:00:32 UTC, Idan Arye wrote: The init value of `Nullable!(Node!string)` is an object with two member fields - `value` of type `string` and `next` of type `Nullable!(Node!string)`. The default constructor modifies neither, so they will both remain with their initial values. The init value of `string` is an empty string. What is the init value of `Nullable!(Node!string)`? To find the answer, return to the beginning of this paragraph and read it again. I made a mistake here - `Nullable!(Node!string)` is a struct with a boolean member `_isNull` and a `Node!string` member named `_value` which is an object as described in this paragraph. Still, the point remains - even if `_isNull` is true, `_value` still need to refer to a `Node!string` object.
Re: trusted purity?
On 4/29/2013 1:03 PM, monarch_dodra wrote:
On Monday, 29 April 2013 at 18:34:46 UTC, Walter Bright wrote:
On 4/29/2013 10:19 AM, monarch_dodra wrote:
I'm getting strange behavior trying to cast to pure. This is my
test program:
You're casting a C function to a D function. This will cause crashes.
OK, so say I have a documented pure C function, how do I call it from a pure
scope? You say, take the address and cast it, but not if it's C...
extern (C) {
int foo(int);
}
extern (C) {
pure int function(int) fp_pure_t;
}
...
cast(fp_pure_t)(foo)
clear() causes crash?
This crashes in the last line of main:
class A
{
void foo() {}
}
void main()
{
A a = new A();
a.foo();
clear(a);
assert(a !is null);
a.foo(); // crashes
}
As far as I understand from TDPL book, this should not crash, but
it does (DMD64 v2.062, OS X). Am I misunderstanding clear()?
BTW, why not make clear also change 'a' to null?
Re: DConf 2013 official car/room sharing thread
All good, I took the shuttle on Ali's advice. Cost $55. Much better than a taxi. By 'there' I was thinking anywhere in the area I guess (I presumed it would all be walking distance). Turns out the aloft is on the other side of the bay, and google maps was lying to me ;) Who else is staying at the aloft? On 30 April 2013 04:32, David Nadlinger s...@klickverbot.at wrote: On Monday, 29 April 2013 at 16:04:00 UTC, Manu wrote: I'll be in SFO at midday if anyone is heading down from up that way? Otherwise, can anyone suggest the best way to get there from the airport? Where is there? I just used BART/Caltrain – not very fancy and takes a while to get there, but since my hotel is near the Palo Alto stop, it was ideal for me. David
Re: How to deal with systems where real == double
real is defined to be the largest floating point type supported on the target machine, so if that's the same as double, then it's double (though still a distinct type to the D typing system).
Re: clear() causes crash?
On Monday, April 29, 2013 23:04:29 =?UTF-8?B?Ikx1w61z?=.Marques
luismarq...@gmail.com@puremagic.com wrote:
This crashes in the last line of main:
class A
{
void foo() {}
}
void main()
{
A a = new A();
a.foo();
clear(a);
assert(a !is null);
a.foo(); // crashes
}
As far as I understand from TDPL book, this should not crash, but
it does (DMD64 v2.062, OS X). Am I misunderstanding clear()?
BTW, why not make clear also change 'a' to null?
I think that what TDPL says about clear may be outdated (I don't recall
exactly what it said). But clear destroys the class object and zeroes out the
vtbl, and it's invalid to do anything with the object after that. It's purely
for cases where you want to destroy the object without waiting for the GC to
do it (but it doesn't free any memory, so it's pretty much only of use for
making sure that the destructor/finalizer gets run). It's very much on purpose
that the app crashes when you use an object which you called clear on.
Also, clear has been renamed to destroy (leaving clear as an alias to
destroy), so new code should be using destroy.
- Jonathan M Davis
Re: Formal Review of std.uni
I was working on a list of suggestions, but turned it into a pull request instead, as the list had gotten big enough to be inconvenient to go through manually. The pull focuses on improving some of the phrasing in the DDoc comments. https://github.com/blackwhale/gsoc-bench-2012/pull/2
Re: DConf 2013 official car/room sharing thread
On 4/29/2013 2:31 PM, Manu wrote: All good, I took the shuttle on Ali's advice. Cost $55. Much better than a taxi. By 'there' I was thinking anywhere in the area I guess (I presumed it would all be walking distance). Turns out the aloft is on the other side of the bay, and google maps was lying to me ;) Who else is staying at the aloft? I'll be there late tonight.
Re: Formal Review of std.uni
Looks nice. The glossary should be alphabetized. combining class is defined under combiningClass - should it be in the glossary instead?
Re: DConf 2013 official car/room sharing thread
On 3/24/13 5:32 PM, Andrei Alexandrescu wrote: Hello to all prospective DConf 2013 attendees! A few of you are interested in sharing options for rental cars, or to share hotel rooms and split the cost in half. Let this thread be the official tracker for such requests and offers. I'll also post a link to this thread on http://dconf.org/venue.html. If necessary, we'll also post important related notices there. So, just reply to this with your offers and requests! Thanks, Andrei Hi all, I'll be arriving tomorrow night. Will be in commuting from Redwood City if anyone needs a ride. Andrew
Re: DConf 2013 official car/room sharing thread
On Monday, 29 April 2013 at 22:20:26 UTC, Walter Bright wrote: On 4/29/2013 2:31 PM, Manu wrote: Who else is staying at the aloft? I'll be there late tonight. I'm starting to feel like am the only one _not_ staying there… ;) David
Re: DConf 2013 official car/room sharing thread
On 4/29/2013 3:47 PM, David Nadlinger wrote: On Monday, 29 April 2013 at 22:20:26 UTC, Walter Bright wrote: On 4/29/2013 2:31 PM, Manu wrote: Who else is staying at the aloft? I'll be there late tonight. I'm starting to feel like am the only one _not_ staying there… ;) You can still hang out with us :-)
Re: Formal Review of std.uni
29-Apr-2013 22:50, Jonathan M Davis пишет: On Monday, April 29, 2013 22:13:09 Dmitry Olshansky wrote: Technically these should be in std.string and are there but incorrect. Then fix them there. I think it will take a certain amount of leaked implementation details to get it done at least half-decently. In particular to re-use the same case-folding table as for case-insensitive matching. Would be a strategic mistake IMHO to spread the internals across 2 modules. Then std.string could provide a public alias(es) as it imports std.uni anyway? Going further if we are to preserve the status quo then std.uni will declare them as package to not advertise their new location. - Jonathan M Davis -- Dmitry Olshansky
Re: DConf 2013 official car/room sharing thread
On Mon, 29 Apr 2013 15:47:46 -0700, David Nadlinger s...@klickverbot.at wrote: On Monday, 29 April 2013 at 22:20:26 UTC, Walter Bright wrote: On 4/29/2013 2:31 PM, Manu wrote: Who else is staying at the aloft? I'll be there late tonight. I'm starting to feel like am the only one _not_ staying there… ;) David *sigh* I'm not staying there either, but it does seem like all the cool kids are. Well, we'll just have to start our own Not Staying at Aloft Club for the cooler kids. :-D -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: DConf 2013 official car/room sharing thread
On Monday, 29 April 2013 at 23:00:48 UTC, Walter Bright wrote: On 4/29/2013 3:47 PM, David Nadlinger wrote: On Monday, 29 April 2013 at 22:20:26 UTC, Walter Bright wrote: On 4/29/2013 2:31 PM, Manu wrote: Who else is staying at the aloft? I'll be there late tonight. I'm starting to feel like am the only one _not_ staying there… ;) You can still hang out with us :-) So would anybody be interested in meeting up today in the evening? I've been in touch with Ali, but nobody else responded so far – I guess you are just arrived today? David
Re: DConf 2013 official car/room sharing thread
Sigh, careless typing on a mobile phone… Make that »I'm in touch with Ali, but nobody else responded so far – I guess you all just arrived today?« David
Re: Formal Review of std.uni
30-Apr-2013 02:40, Walter Bright пишет: Looks nice. Cool, this means we are getting there ;) The glossary should be alphabetized. combining class is defined under combiningClass - should it be in the glossary instead? Good ideas. Linked combining class as everything else. -- Dmitry Olshansky
Re: DConf 2013 official car/room sharing thread
On 04/29/2013 04:10 PM, Adam Wilson wrote: *sigh* I'm not staying there either, but it does seem like all the cool kids are. Well, we'll just have to start our own Not Staying at Aloft Club for the cooler kids. :-D We can start the coolness by going to Manu's ACCU talk tomorrow in Mountain View: :) http://www.meetup.com/SFBay-Association-of-C-C-Users/events/115855342/ Ali
Re: std.variant holding bigger structs and std.concurrency message limitation
On Saturday, 27 April 2013 at 17:42:54 UTC, Idan Arye wrote: The way it works now, is that if the size is too big they use a reference instead: https://github.com/D-Programming-Language/phobos/blob/master/std/variant.d#L544#L555 So is the bug in std.concurrency and they way it uses Variant or is the bug in Variant?
Re: Formal Review of std.uni
On Tuesday, April 30, 2013 03:02:17 Dmitry Olshansky wrote: 29-Apr-2013 22:50, Jonathan M Davis пишет: On Monday, April 29, 2013 22:13:09 Dmitry Olshansky wrote: Technically these should be in std.string and are there but incorrect. Then fix them there. I think it will take a certain amount of leaked implementation details to get it done at least half-decently. In particular to re-use the same case-folding table as for case-insensitive matching. Would be a strategic mistake IMHO to spread the internals across 2 modules. Then std.string could provide a public alias(es) as it imports std.uni anyway? Going further if we are to preserve the status quo then std.uni will declare them as package to not advertise their new location. An alias would be one option. The primary issue I see is that the general design of the modules has been that std.ascii and std.uni operate on individual characters and not strings, whereas std.string operates on strings (generally going with the unicode versions of things when there's a choice rather than the ASCII ones). And having overloads in std.uni which operate on strings doesn't follow that organizational model. Usually, std.string has called the std.uni functions to do what it's needed, and no implementation details have been leaked. I haven't looked at what you've done with std.uni yet, so I don't know how well that would work. But toLower and toUpper are far from them only functions which would be affected by something like this (icmp would be another obvious one). But even if we decided to reorganize where some functionality or functions live, we shouldn't have std.uni replacing std.string functions while leaving the old functions in std.string. So, worst case, aliases should be used, but if at all reasonable, I'd prefer to keep the module organizational structure that we've had with regards to how characters and string functionality is organized. - Jonathan M Davis
Re: DConf 2013 official car/room sharing thread
On Monday, 29 April 2013 at 22:42:09 UTC, Tyro[17] wrote: Hi all, I'll be arriving tomorrow night. Will be in commuting from Redwood City if anyone needs a ride. Andrew Hi! I'm also staying in Redwood City. Mike Parker is too, and I'm in touch with him already. But my phone is five-one-oh three-seven-four oh-eight six three, if you want to call or text when you get in.
Re: DConf 2013 official car/room sharing thread
On Monday, 29 April 2013 at 12:28:33 UTC, deadalnix wrote: Due to last minute issue, I find myself in an hotel in mountain view. 3km/2miles away from the caltrain, so I'll need someone to grab me if that is possible. I promise to be good company on the road :D deadalnix, I can pick you up, because I'll be in Mountain View, too.
Re: DConf 2013 official car/room sharing thread
On Tuesday, 30 April 2013 at 00:50:43 UTC, Aldo Nunez wrote: On Monday, 29 April 2013 at 12:28:33 UTC, deadalnix wrote: Due to last minute issue, I find myself in an hotel in mountain view. 3km/2miles away from the caltrain, so I'll need someone to grab me if that is possible. I promise to be good company on the road :D deadalnix, I can pick you up, because I'll be in Mountain View, too. Awesome ! Can we exchange contact infos via some more private canal in order to set that up ? You have my email on every posts in that newgroup.
Re: DConf 2013 official car/room sharing thread
On Mon, 29 Apr 2013 16:31:03 -0700, Ali Çehreli acehr...@yahoo.com wrote: On 04/29/2013 04:10 PM, Adam Wilson wrote: *sigh* I'm not staying there either, but it does seem like all the cool kids are. Well, we'll just have to start our own Not Staying at Aloft Club for the cooler kids. :-D We can start the coolness by going to Manu's ACCU talk tomorrow in Mountain View: :) http://www.meetup.com/SFBay-Association-of-C-C-Users/events/115855342/ Ali ARG! My flight doesn't land until 11PM! -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: DConf 2013 official car/room sharing thread
On Monday, 29 April 2013 at 23:31:06 UTC, Ali Çehreli wrote: We can start the coolness by going to Manu's ACCU talk tomorrow in Mountain View: :) http://www.meetup.com/SFBay-Association-of-C-C-Users/events/115855342/ Sound like a plan – probably will be there, too. How many people usually attend those meetings? David
Re: DConf 2013 official car/room sharing thread
On 4/29/13 8:37 PM, Zach the Mystic wrote: On Monday, 29 April 2013 at 22:42:09 UTC, Tyro[17] wrote: Hi all, I'll be arriving tomorrow night. Will be in commuting from Redwood City if anyone needs a ride. Andrew Hi! I'm also staying in Redwood City. Mike Parker is too, and I'm in touch with him already. But my phone is five-one-oh three-seven-four oh-eight six three, if you want to call or text when you get in. GTG. Will link you when I arrive.
Re: DConf 2013 official car/room sharing thread
On 30 April 2013 00:13, David Nadlinger s...@klickverbot.at wrote: On Monday, 29 April 2013 at 23:00:48 UTC, Walter Bright wrote: On 4/29/2013 3:47 PM, David Nadlinger wrote: On Monday, 29 April 2013 at 22:20:26 UTC, Walter Bright wrote: On 4/29/2013 2:31 PM, Manu wrote: Who else is staying at the aloft? I'll be there late tonight. I'm starting to feel like am the only one _not_ staying there… ;) You can still hang out with us :-) So would anybody be interested in meeting up today in the evening? I've been in touch with Ali, but nobody else responded so far – I guess you are just arrived today? David Where do you want to meet up? -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: DConf 2013 official car/room sharing thread
On Tuesday, 30 April 2013 at 01:29:55 UTC, Iain Buclaw wrote: Where do you want to meet up? I'm probably the wrong person to make a suggestion. My hotel is a few blocks from the Palo Alto Caltrain station, and everything reachable by bike/public transport (in a reasonable amount of time) would be fine for me. David
