Re: Rust updates
On 12 July 2012 18:42, Marco Leise wrote: > Am Wed, 11 Jul 2012 22:58:07 +0200 > schrieb "bearophile" : > >> > => a = 5s; >> >> I read that as "5 seconds" :-( > > Me too, but then again "5l" could be read as 5 liters. I guess that is why > the move is towards uppercase suffixes. 5S and 5L are not likely misread. "L" is also an internationally-recognised symbol for litres. http://physics.nist.gov/cuu/Units/outside.html Personally, I think that if I need to care about the data size/maximum range of a value, I should be using a fixed-size data type rather than specifying it in the value. The language typically supports me in doing so without the need for prefixes except on rare occasions. Geoff
Re: Congratulations to the D Team!
On 10 July 2012 01:02, Timon Gehr wrote:
> 1.
>
> Most code that gives amortized complexity guarantees, eg:
>
> interface Map(K, V){
> V opIndex(K k) const;
> // ...
> }
>
> class SplayTree(K, V) : Map!(K, V) {
> // ???
> }
>
> 2.
>
> - hash table
> - opApply compacts the table if it is occupied too sparsely, in order
> to speed up further iteration.
> - toString iterates over all key/value pairs by the means of opApply.
>
> Clearly, toString cannot be const in this setup.
>
> 3.
>
> Often, objects can cache derived properties to speed up the code. With
> 'const-correctness' in place, such an optimization is not transparent
> nor doable in a modular way.
>
>
>
>> IME, it rather helps code quality than harm it.
>
>
> I am not talking about code quality. I am talking about code
> maintainability, extensibility and performance.
Although I don't know what D's goals with const are, in C++,
const-correctness is often considered from the perspective of outside
the interface. A const member function guarantees that, from the point
of view of an entity using the object, its state will not change. This
does not guarantee that data stored in the object is not changing.
This allows for things like storing cached values. Unfortunately,
implementing this is more difficult than it might sound, e.g. in cases
such as #2 above, particularly if you also want the compiler checking
that the const keyword can allow (which you should).
See here for more information:
http://www.parashift.com/c++-faq-lite/mutable-data-members.html
Geoff
Re: Is dsource .org completely deserted?
On May 16, 2012, at 9:38 PM, Steven Schveighoffer wrote: > On Tue, 15 May 2012 11:43:42 -0400, Nick Sabalausky > wrote: > >> I'm well aware that it's deliberate, but it's still anti-competetive, >> asinine and anachronistic. And it's not as if the whole hosting thing isn't >> worth anything. That is, after all, what they *do*. > > Wait, can't you just git clone the data into whatever "github-like" service > you wish? I mean, yeah, you cannot do pull requests to Phobos unless you > have your code in github, but that could just be a simple intermediate step. This is not entirely correct. You can do pull requests. You just can't do them through the github interface, which aims to make them easier and smoother. A pull request is nothing more than a request to execute a common git command with a URL pointing to a git repository (which can be hosted anywhere). The github interface just wraps this command and directs it to the repository stored on the server rather than one on your computer (as well as adding things like tracker integration, etc). From the git documentation: Often, "please pull" messages on the mailing list just provide two pieces of information: a repo URL and a branch name; this is designed to be easily cut&pasted at the end of a git fetch command line: Linus, please pull from git://git/proj.git master to get the following updates... becomes: $ git pull git://git/proj.git master (See http://git-scm.com/docs/git-tag) Projects that don't operate around sites like github rely on messages to a mailing list asking the integrator to pull from some branch of some repository. Although I'm sure the Linux kernel works like this, I haven't seen it, but I have seen the same process used effectively by Erlang - and they even use github for their repositories. If Phobos is *requiring* pull requests to be done through the github interface, well, I think that's pretty silly and a good way to discourage some contributions, but it's not my project and perhaps they like the interface too much to work any other way. Geoff
Re: Three Unlikely Successful Features of D
On Mar 21, 2012, at 6:43 AM, Walter Bright wrote: > On 3/20/2012 12:02 PM, Andrei Alexandrescu wrote: >> What are your faves? I have a few in mind, but wouldn't want to influence >> answers. > > Although array slices have been in D nearly since the beginning, I had little > idea they would become so darn useful and foundational. They originated from > an idea by Jan Knepper. > > The unexpected utility of them explains why they haven't appeared in other > languages (yet). Python has had slices since at least 2000. I can't imagine using Python without them, and I always miss them when using languages such as C++. D providing slices in a compiled, system programming language is a massive advantage over other such languages. Geoff
Re: Review of Jose Armando Garcia Sancio's std.log
On Mar 12, 2012, at 7:28 AM, Andrei Alexandrescu wrote: > On 3/11/12 4:49 PM, David Nadlinger wrote: >> Unfortunately, the discussion has ground to a halt again, so consider >> this a friendly reminder that there is still one day left until the end >> of the review period. >> >> David > > I thought more about the point made about mixing throwing and logging levels. > I agree that it's awkward to e.g. log to critical without throwing etc. I > personally think in that case you really want the error log, but hey, point > taken. > > Here's a suggestion: > > * Don't throw from the critical log and don't abort from the fatal log. > > * Define the logging functions such that logging an exception will log its > toString() and then throw the exception. > > * Regarding static import log = std.log, I suggest we keep course. > > Works? +1 (I particularly like the idea of logging an exception rather than logging a message and a separate exception to throw, which may contain a different message.) Geoff
Re: Review of Jose Armando Garcia Sancio's std.log
On 07/03/12 11:12, Jose Armando Garcia wrote:
On Tue, Mar 6, 2012 at 6:05 PM, Geoffrey Biggs
wrote:
That approach means that if I actually do have a fatal error, I can't mark
it as such. It gets conflated with the non-fatal errors, both in the source
and in the logging output (which may, for example, be filtering for fatal
errors to phone someone in the middle of the night while errors just send an
email). Another point worth considering is that I cannot use the fatal level
and be able to re-compile my software with logging disabled, because that
will change the program flow.
Fatal and Critical severity cannot be disabled either at runtime or at
compile. In other words fatal log messages will always assert(true)
and critical log messages will always throw.
Forcing the two semantic concepts (logging and error handling) together
needlessly restricts the ways the library can be used. It is nice to
encapsulate frequent patterns, but providing a convenience function that
throws an error, or a new level ("terminate" or something) is a better
approach than forcing that pattern on everyone. Based on the name, it's a
*logging* library, not an error handling library.
Fatal and critical are these convenience functions.
OK, I took another look at the docs. I see your point now. Sorry for
making a fuss.
However, I think that in this case, the log levels usable without
killing the program are too coarse. This may be a matter of taste, though.
Geoff
Re: Review of Jose Armando Garcia Sancio's std.log
On 07/03/12 09:59, Andrei Alexandrescu wrote:
I don't see why the agitation around this particular matter. It's a
matter of convenience, much like writeln (as opposed to just write).
Let's admit that it often happens that you want to log some troublesome
stuff just before throwing an exception with essentially the same
message, so the thing is shown on the screen and also persisted in the
log. Without a critical level, the pattern would be:
string message = stuff() + ": " + moreStuff();
log.error(message);
throw new Exception(message);
It's nice to encapsulate this frequent pattern, hence:
log.critical(stuff() + ": " + moreStuff());
If you want to log but not throw, use log.error. I don't think the
response "dont use those libraries either" is meaningful.
That approach means that if I actually do have a fatal error, I can't
mark it as such. It gets conflated with the non-fatal errors, both in
the source and in the logging output (which may, for example, be
filtering for fatal errors to phone someone in the middle of the night
while errors just send an email). Another point worth considering is
that I cannot use the fatal level and be able to re-compile my software
with logging disabled, because that will change the program flow.
Forcing the two semantic concepts (logging and error handling) together
needlessly restricts the ways the library can be used. It is nice to
encapsulate frequent patterns, but providing a convenience function that
throws an error, or a new level ("terminate" or something) is a better
approach than forcing that pattern on everyone. Based on the name, it's
a *logging* library, not an error handling library.
Geoff
Re: Review of Jose Armando Garcia Sancio's std.log
On 07/03/12 09:25, Jonathan M Davis wrote: On Tuesday, March 06, 2012 13:08:42 Brad Roberts wrote: On Tue, 6 Mar 2012, Jose Armando Garcia wrote: Fix now: 1. Add thread name attribute to the default logger 2. Check that the example compile 3. Come up with a better name for Rich and rich template 4. Add @safe pure nothrow const to as many methods as possible 5. Remove check when setting Configuration.logger I still believe pretty strongly that the logger must not affect application flow, ie, not throw or exit the app. From the feed back, I am not alone in thinking that. I don't believe that "well, don't use those log levels" is a workaround if for no other reason that there will be libraries that contain them and that becomes a "dont use those libraries either" response. Agreed. The logging functions should _not_ throw. +1. Is std.log a logging library or a complete error management library? If it's a logging library, the last thing it should be doing is affecting program flow. In the case of fatal, in particular, the program may need to do something else after logging the fatal error before terminating. You could argue that the program should do that before logging the fatal error, but I don't think that's nice semantics. On the other hand, if it's a complete error management library, it probably shouldn't be called std.log. That's my opinion as an uninformed user. Geoff
Re: CORBA in D
On 02/03/12 21:43, Martin Nowak wrote: On Fri, 02 Mar 2012 01:43:17 +0100, Geoffrey Biggs wrote: Morning all, In a project just starting, we want to use D (for its safety, amongst other things). However, we also need to connect to distributed objects that have CORBA interfaces. I did a search, and the most recent mention of CORBA and D that I could find is a post to this list nearly 5 years ago: http://www.digitalmars.com/d/archives/digitalmars/D/Using_CORBA_with_D_55285.html The linked project is still just as empty now as it was then. Does anyone know of any existing approaches to using CORBA from D that have perhaps appeared since then? If there isn't a direct implementation, what are the chances of using a C++ library such as omniORB from D? Thanks, Geoff There was some Thrift support in the workings if that might help you. Thanks for the pointer. Unfortunately, CORBA and Thrift are not compatible. Geoff
Re: CORBA in D
On 02/03/12 13:28, Sean Kelly wrote: On Mar 1, 2012, at 6:42 PM, Geoffrey Biggs wrote: On 02/03/12 10:54, Walter Bright wrote: On 3/1/2012 4:43 PM, Geoffrey Biggs wrote: Morning all, In a project just starting, we want to use D (for its safety, amongst other things). However, we also need to connect to distributed objects that have CORBA interfaces. I did a search, and the most recent mention of CORBA and D that I could find is a post to this list nearly 5 years ago: http://www.digitalmars.com/d/archives/digitalmars/D/Using_CORBA_with_D_55285.html The linked project is still just as empty now as it was then. Does anyone know of any existing approaches to using CORBA from D that have perhaps appeared since then? If there isn't a direct implementation, what are the chances of using a C++ library such as omniORB from D? Isn't CORBA based on COM? D supports COM interfaces. Are you referring to Microsoft's COM? If so, then I don't *think* there's any connection. CORBA and Microsoft's COM/DCOM are not compatible. CORBA uses a different (standardised, for what that's worth) distribution protocol to DCOM. I haven't heard of one. Does omniORB use a pre-compiler? This would be a great use of CTFE in a native D implementation. Yes, there's the omniidl IDL compiler, to go from OMG IDL to C++ objects (or Python objects, if you're using omniORB-py). Unfortunately, the code it produces is enough to make you go blind, so it's not something I would want to write D bindings for manually. Geoff
Re: CORBA in D
On 02/03/12 10:54, Walter Bright wrote: On 3/1/2012 4:43 PM, Geoffrey Biggs wrote: Morning all, In a project just starting, we want to use D (for its safety, amongst other things). However, we also need to connect to distributed objects that have CORBA interfaces. I did a search, and the most recent mention of CORBA and D that I could find is a post to this list nearly 5 years ago: http://www.digitalmars.com/d/archives/digitalmars/D/Using_CORBA_with_D_55285.html The linked project is still just as empty now as it was then. Does anyone know of any existing approaches to using CORBA from D that have perhaps appeared since then? If there isn't a direct implementation, what are the chances of using a C++ library such as omniORB from D? Isn't CORBA based on COM? D supports COM interfaces. Are you referring to Microsoft's COM? If so, then I don't *think* there's any connection. CORBA and Microsoft's COM/DCOM are not compatible. CORBA uses a different (standardised, for what that's worth) distribution protocol to DCOM. Geoff
CORBA in D
Morning all, In a project just starting, we want to use D (for its safety, amongst other things). However, we also need to connect to distributed objects that have CORBA interfaces. I did a search, and the most recent mention of CORBA and D that I could find is a post to this list nearly 5 years ago: http://www.digitalmars.com/d/archives/digitalmars/D/Using_CORBA_with_D_55285.html The linked project is still just as empty now as it was then. Does anyone know of any existing approaches to using CORBA from D that have perhaps appeared since then? If there isn't a direct implementation, what are the chances of using a C++ library such as omniORB from D? Thanks, Geoff
