Re: against enforce
Jonathan M Davis wrote: On 2011-03-26 08:55, Don wrote: spir wrote: On 03/25/2011 11:20 PM, Jonathan M Davis wrote: In the case of something like dividing by 0 or other math functions that could be given bad values, the typical solution is to either use an assertion (or check nothing) and then let the caller worry about it. It would be extremely wasteful to have to constantly check whether the arguments to typical math functions are valid. They almost always are, and those types of functions needto be really efficient. But catching wrong arguments to math functions at *runtime* is precisely what D itself does (as well as all languages I know): auto a = 1, b = 0; auto c = a/b; ==> Floating point exception There is no way out, or do I miss a point? Denis That one is done by the CPU, as mentioned in another post. But it does illustrate something interesting: the contract programming makes you think there is a symmetry between in and out contracts, whereas in fact they have very little in common. If an out contract fails, it ALWAYS indicates a bug in the function. So it should ALWAYS be an assert. But 'in' contracts are completely different, since they indicate a problem in the calling code. (Personally I cannot see the value of 'out' contracts, except as information for verifying later 'in' contracts). Whereas I _rarely_ use in contracts. In most cases, I favor exceptions, treating my functions as API functions pretty much as long as they're public. That's not always the best approach, but it's generally what I end up using. invariants, I use fairly frequently (and in fact have run into trouble due to issues with them - e.g. http://d.puremagic.com/issues/show_bug.cgi?id=5058 ). out, on the other hand, I don't use as much. It's not terribly common that there's a good test to run on the return value of a function in my experience. Upon occasion, it's useful, but rarely. Unit tests generally solve the problem better with regards to testing output. They're still useful though - just not commonly so. So, honestly, other than invariants, I don't use D's DbC much. in contracts get used upon occasion, but I tend to favor exceptions over assertions in most cases, so I don't use in all that often, and while out is occasionally useful, unit tests generally do a better job of verifying that a function's return value is correct. I'm _very_ glad to have invariants though. - Jonathan M Davis If you only have standalone functions, at the moment there's not really any benefit to in and out contracts. You can equally well put the asserts at the start and end of the function. I totally agree with you about invariants. I've been amazed at how many bugs can be caught by even a very trivial invariant.
Re: against enforce
On 2011-03-28 00:53, Don wrote: > Jonathan M Davis wrote: > > On 2011-03-26 08:55, Don wrote: > >> spir wrote: > >>> On 03/25/2011 11:20 PM, Jonathan M Davis wrote: > In the case of something like dividing by 0 or other math functions > that could > be given bad values, the typical solution is to either use an > assertion (or > check nothing) and then let the caller worry about it. It would be > extremely > wasteful to have to constantly check whether the arguments to typical > math > functions are valid. They almost always are, and those types of > functions needto be really efficient. > >>> > >>> But catching wrong arguments to math functions at *runtime* is > >>> precisely > >>> > >>> what D itself does (as well as all languages I know): > >>> auto a = 1, b = 0; > >>> auto c = a/b; > >>> > >>> ==> > >>> > >>> Floating point exception > >>> > >>> There is no way out, or do I miss a point? > >>> > >>> Denis > >> > >> That one is done by the CPU, as mentioned in another post. But it does > >> illustrate something interesting: the contract programming makes you > >> think there is a symmetry between in and out contracts, whereas in fact > >> they have very little in common. If an out contract fails, it ALWAYS > >> indicates a bug in the function. So it should ALWAYS be an assert. > >> But 'in' contracts are completely different, since they indicate a > >> problem in the calling code. (Personally I cannot see the value of 'out' > >> contracts, except as information for verifying later 'in' contracts). > > > > Whereas I _rarely_ use in contracts. In most cases, I favor exceptions, > > treating my functions as API functions pretty much as long as they're > > public. That's not always the best approach, but it's generally what I > > end up using. > > > > invariants, I use fairly frequently (and in fact have run into trouble > > due to issues with them - e.g. > > http://d.puremagic.com/issues/show_bug.cgi?id=5058 ). > > > > out, on the other hand, I don't use as much. It's not terribly common > > that there's a good test to run on the return value of a function in my > > experience. Upon occasion, it's useful, but rarely. Unit tests generally > > solve the problem better with regards to testing output. They're still > > useful though - just not commonly so. > > > > So, honestly, other than invariants, I don't use D's DbC much. in > > contracts get used upon occasion, but I tend to favor exceptions over > > assertions in most cases, so I don't use in all that often, and while > > out is occasionally useful, unit tests generally do a better job of > > verifying that a function's return value is correct. I'm _very_ glad to > > have invariants though. > > > > - Jonathan M Davis > > If you only have standalone functions, at the moment there's not really > any benefit to in and out contracts. You can equally well put the > asserts at the start and end of the function. > > I totally agree with you about invariants. I've been amazed at how many > bugs can be caught by even a very trivial invariant. What's even more surprising is how invariants sometimes find bugs in _other_ code (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=5500 ) instead of just the member functions of the type with the invariant. - Jonathan M Davis
Re: i like cakes
try this? Dealing with Internet Trolls - the Cognitive Therapy Approach http://unarmed.shlomifish.org/909.html A... On 28/03/2011 02:57, Andrew Wiley wrote: On Sun, Mar 27, 2011 at 8:45 PM, Gary Whatmore wrote: Hello again I've stayed quiet for a long time because people started accusing me of trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY TROLL! :-( The problem with trolls is that when you do this, they win. No one likes them, but you've just got to learn to ignore them or you just make things worse.
Re: i like cakes
== Quote from Alix Pexton (alix.dot.pex...@gmail.dot.com)'s article > try this? > Dealing with Internet Trolls - the Cognitive Therapy Approach > http://unarmed.shlomifish.org/909.html > A... > On 28/03/2011 02:57, Andrew Wiley wrote: > > On Sun, Mar 27, 2011 at 8:45 PM, Gary Whatmore wrote: > >> Hello again > >> > >> I've stayed quiet for a long time because people started accusing me of trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY TROLL! :-( > > > > > > The problem with trolls is that when you do this, they win. No one > > likes them, but you've just got to learn to ignore them or you just > > make things worse. It broke the flow of reading. Why is top posting bad? --- http://flamewarriors.com
Re: against enforce
On 3/28/2011 12:53 AM, Don wrote: If you only have standalone functions, at the moment there's not really any benefit to in and out contracts. You can equally well put the asserts at the start and end of the function. In and out contracts come into their own when you're using inheritance. The in contract is an OR of all the overridden function in's, and the out is the AND of all the overridden out's. It's pretty clunky to do this manually. They also have a possible future use as input to a static program analyzer.
Re: i like cakes
On 28/03/2011 10:36, Iain Buclaw wrote: == Quote from Alix Pexton (alix.dot.pex...@gmail.dot.com)'s article try this? Dealing with Internet Trolls - the Cognitive Therapy Approach http://unarmed.shlomifish.org/909.html A... On 28/03/2011 02:57, Andrew Wiley wrote: On Sun, Mar 27, 2011 at 8:45 PM, Gary Whatmore wrote: Hello again I've stayed quiet for a long time because people started accusing me of trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY TROLL! :-( The problem with trolls is that when you do this, they win. No one likes them, but you've just got to learn to ignore them or you just make things worse. It broke the flow of reading. Why is top posting bad? --- http://flamewarriors.com oops, rush >< A...
Re: i like cakes
On 28.03.2011 03:45, Gary Whatmore wrote: > Hello again > > I've stayed quiet for a long time because people started accusing me of > trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME > CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE > HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE > BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY > TROLL! :-( > > - G.W. Are you the idiot with the sockpuppets? Good job giving all of us a bad name.
Re: against enforce
Jonathan M Davis Wrote: > Whereas I _rarely_ use in contracts. In most cases, I favor exceptions, > treating my functions as API functions pretty much as long as they're public. > That's not always the best approach, but it's generally what I end up using. So why do you need a feature, which you don't use? Also if a feature isn't used, doesn't it mean it's useless? > out, on the other hand, I don't use as much. It's not terribly common that > there's a good test to run on the return value of a function in my > experience. > Upon occasion, it's useful, but rarely. Unit tests generally solve the > problem > better with regards to testing output. They're still useful though - just not > commonly so. If you don't prohibit contracts to check external data, you can enforce the check at design time with out contract. How would you check that caller checks received data?
Re: GSoC-2011 project:: Containers
On Fri, 25 Mar 2011 18:37:26 -0400, Jonathan M Davis wrote: On 2011-03-25 05:41, spir wrote: About D collections: aside std.container in Phobos, Steven Schweighoffer has a fairly advanced project called dcollections: http://www.dsource.org/projects/dcollections. As I understand it, it is a bit of a concurrent for std.container, but there seems to be a possibility for them to converge in the future. In any case, you should definitely study it, if only to take inspiration and avoid double work. dcollections is Steven Schweighoffer's project which has existed since D1. std.container is the container module for Phobos. So, they aren't, strictly speaking related. When designing std.container and planning out how containers should be done in Phobos, Andrei took a different approach than Steve did. So, nothing can be taken from dcollections and simply plopped into std.container. However, dcollections 2.0 does use the Boost license, so the code from there can be refactored to work in std.container. Steve already did that with RedBlackTree. He ported std.RedBlackTree from whatever his red-black tree implementation is in dcollections. So, if it makes sense, code can be taken from dcollections and ported to Phobos (and Steve would obviously be a good guy to talk to about that). However, anyone doing that needs to be aware of the differences in how dcollections works vs how std.container works (e.g. dcollections has cursors whereas std.container uses ranges exclusively). Any of the private implementations inside dcollections are usable in std.container, because they do not expose any public interface. In fact, dcollections' types can be separated into two categories -- interfaces and implementations. The implementations have a very raw, unsafe, simple API (no range or cursor support there). The interface types (which BTW are implemented via final classes) expose the common public interface that all dcollections classes have, including ranges and cursors. It is this separation which allowed me to port red black tree to std.container by changing nothing in the red black node implementation. If you compare RBNode in std.container and RBNode in dcollections, you'll find them virtually identical (little cleanup here and there). In fact, I plan to have dcollections' RBTree use std.container's RBNode to avoid code duplication. Unfortunately, red black tree is the most complex part of dcollections, so there is not much else to gain by porting to std.container. I think Deque would be a good one, even though it's implementation is not separate (the implementation is based on builtin arrays), so the port would be more involved. You could also take the Link implementation (dual-linked list), but that is simple enough to write from scratch ;) The Hash is extremely naive and basic, so I'm not sure it's worth copying. I'm not an algorithms expert. Aside from porting dcollections/implementing equivalent types, I think there are some things that would be good to have in phobos: * Conceptual types that use the implementations, such as a map type. These *should* be implementation agnostic as long as you use template constraints to identify the appropriate functions required. Doing this should test the completeness of the functions that the containers define. * Custom allocation. This has increased dcollections' performance significantly. If you have any questions, do not hesitate to email me at this address. I would be a mentor for this, but 1) I don't have much time (not sure what is required) and 2) I have a severe difference of opinion from Andrei on what is good in collections, I don't want to guide someone to designs/code that won't be accepted. -Steve
Re: i like cakes
On Mar 28, 11 17:36, Iain Buclaw wrote: == Quote from Alix Pexton (alix.dot.pex...@gmail.dot.com)'s article try this? Dealing with Internet Trolls - the Cognitive Therapy Approach http://unarmed.shlomifish.org/909.html A... On 28/03/2011 02:57, Andrew Wiley wrote: On Sun, Mar 27, 2011 at 8:45 PM, Gary Whatmore wrote: Hello again I've stayed quiet for a long time because people started accusing me of trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY TROLL! :-( The problem with trolls is that when you do this, they win. No one likes them, but you've just got to learn to ignore them or you just make things worse. It broke the flow of reading. > Only matters if you need to read all quotes in one message. If you read those in DFS order the flow isn't really broken since you already know what the quoted text is. Why is top posting bad? --- http://flamewarriors.com
Re: against enforce
On Fri, 25 Mar 2011 23:17:53 -0400, spir wrote:
On 03/25/2011 09:49 PM, Steven Schveighoffer wrote:
On Fri, 25 Mar 2011 16:23:08 -0400, spir wrote:
This logic certainly looks sensible, but I cannot understand how it
should
work in practice. Say I'm implementing a little set of operations on
decimals. Among those, some (division, square root...) will
necessarily have
to check their input.
You can look at it in a simple way: If this branch of code will always
run the
same way every time (i.e. is deterministic), then using assert is
desired. Why?
Because the assumption is that you test that code via unit tests. Once
you test
it, and it works, there is no reason to test it again.
For example, if I do:
sqrt(1);
There is never ever a need to test this in production code. sqrt(1) is
always
1, and will always work.
If I do:
sqrt(-1);
There is never ever a need to test this in production code. sqrt(-1) is
always
a failure, and will always fail. Unit tests should catch this code
before it is
released.
But if I do something like:
auto file = File.open("/tmp/xyz.txt"); // did not look up usage for
File, may
be wrong
I agree with all of this. But here you're the client of sqrt. What if
you implement it (or for a new numeric type)? You'll need to catch param
errors for /input/ to your func (not for args you /provide/ to a third
party func). That was my case.
The issue isn't so much that you should or should not catch errors, the
issue is, can the error catching be *optimized out* at production time.
The answer to that question is impossible for a compiler to answer,
because figuring out where a parameter came from I believe is the halting
problem, and impossible (currently) for a developer who can figure out the
answer to handle.
This is really a question of optimization, not error catching. If
something will always be the same, and it has already been tested, there
is no reason to test it again.
-Steve
Re: against enforce
On Mon, 28 Mar 2011 03:53:56 -0400, Don wrote: If you only have standalone functions, at the moment there's not really any benefit to in and out contracts. You can equally well put the asserts at the start and end of the function. Well, if you have code in your in/out contracts that is not an assert call, it will also be compiled out (not true if the in check is inside the body). -Steve
Re: Determine the "type" of a delegate
On Sat, 26 Mar 2011 06:46:22 -0400, teo wrote: Having a delegate d, I can use d.ptr to get a void* pointer to the environment used to construct the delegate. How can I determine from that pointer whether that is a class object? AFAIK, you can't. -Steve
Re: against enforce
On Sat, 26 Mar 2011 08:14:19 -0400, Kagamin wrote: Steven Schveighoffer Wrote: For example, if I do: sqrt(1); There is never ever a need to test this in production code. sqrt(1) is always 1, and will always work. If I do: sqrt(-1); pure function called on literals is evaluatable at compile time together with checks, so if sqrt run at runtime, this means input couldn't be validated that easily, so checks should be run too. This means that it's unnecessary to ever remove checks from sqrt. It's not that simple. for example: sqrt(uniform(1.0, 2000.0)); This is completely safe, and needs no runtime error checks. It's easier to explain with simple examples, knowing that you can extrapolate more complex ones that the compiler can't "prove". -Steve
Re: i like cakes
FeepingCreature Wrote: > On 28.03.2011 03:45, Gary Whatmore wrote: > > Hello again > > > > I've stayed quiet for a long time because people started accusing me of > > trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME > > CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE > > HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE > > BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY > > TROLL! :-( > > > > - G.W. > > Are you the idiot with the sockpuppets? Good job giving all of us a bad name. Gary Whatmore's message looks like a troll post to me. Could even be iLiekCaeks himself.
Re: i like cakes
I do to. Why do you like cakes? Really I think IlikeCakes has been fairly healthy criticism. For the most part he sounds like a Tango user who is pissed because D2 no longer supports it. But he generally does bring true issues forth. He is also fairly informed on the current status of D, but isn't actually using it to have accurate count of real issues. Leave him alone, he may have a vendetta against D, but at least he hasn't been petty, at least I don't think he is down voting all posts about D.
Re: against enforce
Steven Schveighoffer Wrote: > This is really a question of optimization, not error catching. If > something will always be the same, and it has already been tested, there > is no reason to test it again. Optimization is not a question of error catching, only if it's smart enough to not interfere with error catching, but we have only blunt method of -release switch. Thus optimization becomes question of error catching.
Complete D grammar
Didn't someone here have a complete D grammar? I vaguely remember that there is at least a D1 one buried somewhere.
Re: i like cakes
On 28.03.2011 15:19, random lurker wrote: > FeepingCreature Wrote: > >> On 28.03.2011 03:45, Gary Whatmore wrote: >>> Hello again >>> >>> I've stayed quiet for a long time because people started accusing me of >>> trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME >>> CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE >>> HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE >>> BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY >>> TROLL! :-( >>> >>> - G.W. >> >> Are you the idiot with the sockpuppets? Good job giving all of us a bad name. > > Gary Whatmore's message looks like a troll post to me. Could even be > iLiekCaeks himself. ILiekCakes actually has some good points once you get past the instinctive fanboy's revulsion for people who are not in awe of D. ;)
Re: Complete D grammar
Trass3r Wrote: > Didn't someone here have a complete D grammar? I vaguely remember that there > is at least a D1 one buried somewhere. huh? http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=20299
Re: Complete D grammar
On 3/28/11 5:17 PM, Kagamin wrote: Trass3r Wrote: Didn't someone here have a complete D grammar? I vaguely remember that there is at least a D1 one buried somewhere. huh? http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=20299 Nope, Trass3r is talking about a grammar for the D language itself, whereas Goldie is a parser generator for D (which generates parsers for a given grammar). Unfortunately, I only remember someone working on one (and filing some related bugs), I lost the details as well… David
Re: against enforce
On Mon, 28 Mar 2011 10:28:04 -0400, Kagamin wrote: Steven Schveighoffer Wrote: This is really a question of optimization, not error catching. If something will always be the same, and it has already been tested, there is no reason to test it again. Optimization is not a question of error catching, only if it's smart enough to not interfere with error catching, but we have only blunt method of -release switch. Thus optimization becomes question of error catching. Yes, the instrument is too blunt, which is why we are having this discussion ;) But the question is still not *whether* to test for errors but *when*. The ideal is to avoid testing for them when they could not possibly occur (i.e. after testing during development proves there is no error). The whole point of using assert and contracts only in development code is so you can instrument all your code with comprehensive, possibly slow performing, tests while testing, and take them all out for shipping. But the mechanisms provided do not allow expression of when an error can occur (during testing or during production) *per call*, only per function. We need it per call to be correct. Made even more difficult is that we are discussing library functions, which can't possibly know whether to test the inputs they get unless the functions are private. You can take the "better safe than fast" approach, but it leaves no room for performance upgrades (as shown by the poor performance of phobos in comparison tests by the likes of bearophile and others). You can take the "not my problem" approach and leave it up to the caller to test inputs, but we don't provide an easy way for a user to test inputs in production code for when its needed at production time. My opinion is that Phobos should opt for "not my problem" because 90% of the time, the input comes from deterministic sources that only need be tested during development. All we need for that is a phobos compiled in non-release mode to test against. It's always possible to add more tests *outside* the phobos call for when they are needed. Then we should look into adding ways to have functions specify how to test their inputs during production in a DRY way. But of course, this path makes code that uses Phobos more prone to errors. It may be worth having all the enforce checks if we can do something like prevent all buffer overflow attacks. I'm not sure of the right answer. -Steve
Re: Complete D grammar
A complete D grammar is one of the objectives of my GSOC 2011 ANTLR proposal, if I got accepted you will have one :) On 3/28/11, David Nadlinger wrote: > On 3/28/11 5:17 PM, Kagamin wrote: >> Trass3r Wrote: >> >>> Didn't someone here have a complete D grammar? I vaguely remember that >>> there is at least a D1 one buried somewhere. >> >> huh? >> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=20299 > > Nope, Trass3r is talking about a grammar for the D language itself, > whereas Goldie is a parser generator for D (which generates parsers for > a given grammar). > > Unfortunately, I only remember someone working on one (and filing some > related bugs), I lost the details as well… > > David >
[GSoC Proposal] Statically Checked Measurement Units
First, let me apologize for this very late entry, it's the end of university
and it's been a very busy period, I hope you will still consider it.
Note this email is best read using a fixed font.
PS: I'm really sorry if this is the wrong mailing list to post and I hope
you'll forgive me if that's the case.
=== Google Summer of Code Proposal: Statically Checked Units ===
Abstract
-
Measurement units allow to statically check the correctness of assignments
and expressions at virtually no performance cost and very little extra
effort. When it comes to physics the advantages are obvious – if you try to
assign a force a variable measuring distance, you've most certainly got a
formula wrong somewhere along the way. Also, showing a sensor measurement in
gallons on a litre display that keeps track of the remaining fuel of a plane
(a big no-no) is easily avoidable with this technique. What this translates
is that one more of the many hidden assumptions in source code is made
visible: units naturally complement other contract checking techniques, like
assertions, invariants and the like. After all the unit that a value is
measured in is part of the contract.
The scope of measurement units is not limited to physics calculations
however and if the feature is properly implemented and is very easy to use,
creating a very domain-specific units helps a great deal with checking
correct code at compile time. Static typing doesn't cut it sometimes:
imaginetwo variables counting different things – Gadgets and Widgets.
While both values should be ints, one of them should probably not be
assignable to the other. Or imagine a website calculating the number of
downloads per second, but uses a timer that counts milliseconds. When one
thinks about it this way, there are a great many cases where units can help
prevent common errors.
Given D's focus on contract based design and language features supporting
it, I think statically checked measurement units fit very naturally into the
standard library, and the language's metaprogramming features would make it
very clean to implement (as opposed to a similar effort in C++). I think a
system that is closer to the one in F# would be a better idea than the one
provided by Boost.Units:
1. Defining unit systems, like Boost.Units requires is extra effort, so
units for counting Widgets or Gadgets would be awkward to use and we would
lose the safety checks there.
2. Defining dimensions is not strictly necessary, and F# does well without
them.
3. The sort of silent conversion that Boost.Units performs is undesirable in
many cases since it is a recipe for precision disasters, imagine sometimes
accidentally assigning a variable measured in billions of years to a one
measured in picoseconds. Boost.Units would silently convert one to another,
since they measure the same dimension. This probably results into the value
being set to +INF and even if it doesn't, very rarely one actually intends
to perform this conversion.
4. Setting numerical ids to units and dimensions is cumbersome. S
Thus, the requirements for the unit system would be:
1. One line definition of new units.
2. Simple, yet safe and explicit conversion between units.
3. Zero runtime overhead.
4. Minimal extra coding effort to use units.
Interface Overview
---
A Boost type approach to the library interface would be:
struct Metre : SomeUnitBaseType!(...) {}
struct Second: SomeUnitBaseType!(...) {}
typedef DerivedUnit!(MetreType,1,Second,-1) MetresPerSecond;
typedef DerivedUnit!(MetreType,2) MetersSquared;
Meter metre, metres;
Second second, seconds;
MetersPerSecond metersPerSecond;
MetersSquared meterSquared, metersSquared;
void f() {
Quantity!(metre) dist1 = 3.0 * metres;
Quantity!(meterSquared)area = dist1 * dist1;
Quantity!(metresPerSecond) speed = distance / (2.0*seconds);
}
This is very cumbersome and fails on the one line requirement. I propose
using types for base units and mixins to define derived units. One can use
the typenames of the units in arithmetic operations this way:
struct metre {}
struct second {}
void f() {
Quantity!("metre")dist1 = quantity!(3.0, "metre");
Quantity!("metre^2") area = dist1 * dist1;
Quantity!("metre/second") speed = dist1 / quantity!(2.0, "second");
}
Conversion between units can be done specifying a single factor with a
proper unit:
template conversion( alias unit : "kilometer/meter" ) {
immutable Quantity!(unit) conversion = quantity!(123.0,unit);
}
void f() {
Quantity!("metre") d1 = quantity!(123.0,"metre");
// convert calls conversion! with the right argument
Quantity!("kilometre") d2 = convert!(d1,"kilometre");
}
Also, notice this approach imposes no restriction to the types that define
units, therefore our Widget/Gadget counters could be defined without any
extra work:
class Widget { /* complicated class definition */ }
class Gadget { /* complicated cla
Re: GCC 4.6
I've been doing a lot of coding in D in the past few weeks, and one thing I've noticed is that performance is not great. Surprisingly, DMD generated binaries perform worse than GDC's, but even GDC is lagging behind equivalent code written in C++ and compiled with G++. Are we to expect performance to improve as more work is done on GDC? Another thing that's bothering me is that there is currently only one active developer working on GDC.
Re: GCC 4.6
== Quote from Caligo (iteronve...@gmail.com)'s article > I've been doing a lot of coding in D in the past few weeks, and one > thing I've noticed is that performance is not great. Surprisingly, > DMD generated binaries perform worse than GDC's, but even GDC is > lagging behind equivalent code written in C++ and compiled with G++. > Are we to expect performance to improve as more work is done on GDC? There's a lot going on behind the scenes, so that's hard to say that your code is 'genuinely equivalent'. > Another thing that's bothering me is that there is currently only one > active developer working on GDC. :'(
Re: Complete D grammar
> huh? > http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=20299 The grammar offered there is lexing-only.
Re: Complete D grammar
David Nadlinger Wrote: > Nope, Trass3r is talking about a grammar for the D language itself, Exactly, I'm pretty sure that some guy once stated on IRC or somewhere he had a complete D1 grammar.
Re: [GSoC Proposal] Statically Checked Measurement Units
On 03/28/2011 05:43 PM, Cristi Cobzarenco wrote:
Thus, the requirements for the unit system would be:
1. One line definition of new units.
2. Simple, yet safe and explicit conversion between units.
3. Zero runtime overhead.
4. Minimal extra coding effort to use units.
I like your study very much. Measurement units are, for me, kinds of conceptual
types --as opposed to primitive types. I think they would be welcome, possibly
for Phobos.
[...]
I propose using types for base units and mixins to define derived units.
One can use the typenames of the units in arithmetic operations this way:
struct metre {}
struct second {}
void f() {
Quantity!("metre")dist1 = quantity!(3.0, "metre");
Quantity!("metre^2") area = dist1 * dist1;
Quantity!("metre/second") speed = dist1 / quantity!(2.0, "second");
}
I think (not sure) this could be even simpler:
1. Thank to D's very used auto feature, avoiding double specification of the
type; you could get rif of quantity, if it's only a convenience factory func.
2. I guess it's not needed for the user to give a quantity type to
/constants/ (here 2.0). It is /meant/ to be a a number of seconds. This, as
opposed to measure /variables/.
Thus, we possibly could have:
auto dist1 = Quantity!("meter")(3.0);
auto area = Quantity!("metre^2")(dist1 * dist1);
auto speed = Quantity!("metre/second")(dist1 / 2.0);
(Unsure whether your system could automagically infer the unit of area. ?)
I'm not fan of using strings as unit identifiers. Why don't you want to use use
the corresponding types (structs or classes) themselves?
auto dist1 = Quantity!Meter(3.0);
Thus requiring each unit to be identified by a (possibly empty) struct or
class. This also gives the opportunity for the user to actually implement some
useful stuff in there; or to *reuse* existing types for things-to-be-counted
(in the latter case, measures would actually be integer /counts/); see your
Widget vs Gadget example below).
Conversion between units can be done specifying a single factor with a
proper unit:
template conversion( alias unit : "kilometer/meter" ) {
immutable Quantity!(unit) conversion = quantity!(123.0,unit);
}
Unsure of the right approch here. All we need is a registered conversion factor
for every needed (U1,U2) pair. It could be a kind of 2D associative array with
unit keys and float values. Then, would it be possible to have a single convert
template, like:
Quantity!U2 convert (string U1, string U2) (Quantity!U1 measure) {
auto factor = conversionFactors[U1][U2]; // throws if undefined
return Quantity!U2(measure * factor);
}
?
void f() {
Quantity!("metre") d1 = quantity!(123.0,"metre");
// convert calls conversion! with the right argument
Quantity!("kilometre") d2 = convert!(d1,"kilometre");
}
auto d1 = Quantity!("metre")(123.0);
auto d2 = convert!(d1,"kilometre");
or using my approach:
auto d2 = convert!("metre","kilometre")(d1);
Here the type for d2 is really unnecessary.
Also, notice this approach imposes no restriction to the types that define
units, therefore our Widget/Gadget counters could be defined without any
extra work:
class Widget { /* complicated class definition */ }
class Gadget { /* complicated class definition */ }
Quantity!("Widget",int) nWidgets;
Quantity!("Gadget",int) nGadgets;
See note about identifying units above.
Denis
--
_
vita es estrany
spir.wikidot.com
Eitan Frachtenberg has been accepted as a GSoC 2011 mentor for Digital Mars
My coworker Eitan Frachtenberg has joined the ranks of our GSoC 2011 mentors. Eitan brings tremendous value to our ranks. He is a very strong, creative scientist with broad interests and achievements, a prolific author (see http://frachtenberg.com/eitan/pubs/index.php for his impressive publication track record), not to mention a great speaker, communicator, and fellow all around. Last but not least, Eitan has a strong interest in D and has already worked in it a fair amount. Please join me in congratulating and wishing the best to Eitan. We have four mentors and one pending application. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Registration for students opens later today. Andrei
Re: Eitan Frachtenberg has been accepted as a GSoC 2011 mentor for Digital Mars
Congratulations Eitan Frachtenberg! On 3/28/11, Andrei Alexandrescu wrote: > My coworker Eitan Frachtenberg has joined the ranks of our GSoC 2011 > mentors. > > Eitan brings tremendous value to our ranks. He is a very strong, > creative scientist with broad interests and achievements, a prolific > author (see http://frachtenberg.com/eitan/pubs/index.php for his > impressive publication track record), not to mention a great speaker, > communicator, and fellow all around. Last but not least, Eitan has a > strong interest in D and has already worked in it a fair amount. > > Please join me in congratulating and wishing the best to Eitan. > > We have four mentors and one pending application. We are always looking > for mentor and student applications. Please refer to this page for how > to apply: > > http://d-programming-language.org/gsoc2011.html > > Registration for students opens later today. > > > Andrei >
Re: how to use a lib in d
Thanks to everyone, I got it to compile :D Still don't get the point of a lib file. I'm used to program java and there you can compile to a jar-libary, a lib in d is obviously not the same.
Re: Complete D grammar
You can find an ANTLR grammar for D v1 at http://www.dsource.org/projects/antlrd/browser/toys/v3d/parsed.g (by Ellery Newcomer) The syntax is similar to EBNF, check the ANTLR documentation for details. I hope this might help you. Luca Boasso On 3/28/11, Trass3r wrote: > David Nadlinger Wrote: >> Nope, Trass3r is talking about a grammar for the D language itself, > > Exactly, I'm pretty sure that some guy once stated on IRC or somewhere he > had a complete D1 grammar. >
Re: how to use a lib in d
On Mon, Mar 28, 2011 at 12:34 PM, maarten van damme wrote: > Thanks to everyone, I got it to compile :D > > Still don't get the point of a lib file. I'm used to program java and there > you can compile to a jar-libary, a lib in d is obviously not the same. > In a machine-compiled language, a library just contains straight binary, and you need a header or an import file (di) to tell the compiler exactly what code is in that library. This is because unlike Java, where type information is preserved in bytecode, machine-compiled code loses a lot of type information during the transition from code to binary. For example, if I have void add(int a, uint b) and I compile it, I can no longer tell you that a and b have different types. At least, this is how I understand it.
Re: against enforce
On 2011-03-28 04:56, Kagamin wrote: > Jonathan M Davis Wrote: > > Whereas I _rarely_ use in contracts. In most cases, I favor exceptions, > > treating my functions as API functions pretty much as long as they're > > public. That's not always the best approach, but it's generally what I > > end up using. > > So why do you need a feature, which you don't use? > Also if a feature isn't used, doesn't it mean it's useless? 1. I do use it sometimes, just not often. 2. Just because I don't personally use it much doesn't mean that it's useless. 3. The main place that in is supposed to shine is with inheritance trees. It handles contract inheritance. > > out, on the other hand, I don't use as much. It's not terribly common > > that there's a good test to run on the return value of a function in my > > experience. Upon occasion, it's useful, but rarely. Unit tests generally > > solve the problem better with regards to testing output. They're still > > useful though - just not commonly so. > > If you don't prohibit contracts to check external data, you can enforce the > check at design time with out contract. How would you check that caller > checks received data? I'm afraid that I don't understand the question. out contracts are intended to verify that the result(s) of the function are correct (return value, the state of the object if it's a member variable, etc.). That's not generally very flexible in that it implies that there is a test that you can run on the result of a function to determine that the result is correct _regardless_ of the input. I don't find that to be useful very often, but sometimes it is. More often what I need is to check that given a particular input, the function gives you a particular output. And that's a job for unit tests. - Jonathan M Davis
Re: how to use a lib in d
Am 28.03.2011 19:48, schrieb Andrew Wiley: On Mon, Mar 28, 2011 at 12:34 PM, maarten van damme wrote: Thanks to everyone, I got it to compile :D Still don't get the point of a lib file. I'm used to program java and there you can compile to a jar-libary, a lib in d is obviously not the same. In a machine-compiled language, a library just contains straight binary, and you need a header or an import file (di) to tell the compiler exactly what code is in that library. This is because unlike Java, where type information is preserved in bytecode, machine-compiled code loses a lot of type information during the transition from code to binary. For example, if I have void add(int a, uint b) and I compile it, I can no longer tell you that a and b have different types. At least, this is how I understand it. AFAIK you can't get any parameter type from just-binary. The code in there just expects the stack to have a certain structure and fullfil certain consitions. If these conditions are not fullfilled it'll probaly segfault. Because D (like C++ and unlike C) allows overloading the same name on different parameter types, this information has to be put into the name (mangling) to avoid name clashes for the linker. Mafi PS: Just a thought of mine: You should be theoretically be able regenereate function signatures from mangled names. Maybe someone could such a tool.
Re: Eitan Frachtenberg has been accepted as a GSoC 2011 mentor for Digital Mars
On 3/28/2011 10:24 AM, Andrei Alexandrescu wrote: My coworker Eitan Frachtenberg has joined the ranks of our GSoC 2011 mentors. Welcome and congrats!
Re: how to use a lib in d
Mafi wrote: > PS: Just a thought of mine: You should be theoretically be able > regenereate function signatures from mangled names. Maybe someone > could such a tool. import core.demangle; http://digitalmars.com/d/2.0/phobos/std_demangle.html If you did a mixin(demangle(fname)) you actually should be able to make it work from a lib in most cases. There's a lot of mangled names that can't be unmangled though, so it won't be perfect.
Re: GCC 4.6
On 3/28/2011 9:09 AM, Caligo wrote: I've been doing a lot of coding in D in the past few weeks, and one thing I've noticed is that performance is not great. Surprisingly, DMD generated binaries perform worse than GDC's, but even GDC is lagging behind equivalent code written in C++ and compiled with G++. Are we to expect performance to improve as more work is done on GDC? There is no technical reason why performance should be worse. It's a matter of investing the time and effort into the code generation.
Re: GCC 4.6
== Quote from Walter Bright (newshou...@digitalmars.com)'s article > On 3/28/2011 9:09 AM, Caligo wrote: > > I've been doing a lot of coding in D in the past few weeks, and one > > thing I've noticed is that performance is not great. Surprisingly, > > DMD generated binaries perform worse than GDC's, but even GDC is > > lagging behind equivalent code written in C++ and compiled with G++. > > Are we to expect performance to improve as more work is done on GDC? > There is no technical reason why performance should be worse. It's a matter of > investing the time and effort into the code generation. Correct me if I'm wrong, but I think some important optimizations (like inlining) are performed in the front end. It's pretty obvious that DMD's inliner needs improvement, though I agree with Walter's decision to prioritize this below fixing major bugs, 64 support and (before that) finalizing the spec. Therefore, the performance of GDC is still a quality of implementation issue rather than a fundamental technical issue.
Re: [GSoC Proposal] Statically Checked Measurement Units
Thanks a lot for your quick response, I'm glad somebody actually read
through the whole thing and that I got some feedback. I'll try and do my
best to answer your questions.
On 28 March 2011 19:15, spir wrote:
> On 03/28/2011 05:43 PM, Cristi Cobzarenco wrote:
>
>> Thus, the requirements for the unit system would be:
>> 1. One line definition of new units.
>> 2. Simple, yet safe and explicit conversion between units.
>> 3. Zero runtime overhead.
>> 4. Minimal extra coding effort to use units.
>>
>
> I like your study very much. Measurement units are, for me, kinds of
> conceptual types --as opposed to primitive types. I think they would be
> welcome, possibly for Phobos.
>
> [...]
>>
>> I propose using types for base units and mixins to define derived units.
>> One can use the typenames of the units in arithmetic operations this way:
>>
>> struct metre {}
>> struct second {}
>>
>> void f() {
>> Quantity!("metre")dist1 = quantity!(3.0, "metre");
>> Quantity!("metre^2") area = dist1 * dist1;
>> Quantity!("metre/second") speed = dist1 / quantity!(2.0, "second");
>> }
>>
>
> I think (not sure) this could be even simpler:
> 1. Thank to D's very used auto feature, avoiding double specification of
> the type; you could get rif of quantity, if it's only a convenience factory
> func.
> 2. I guess it's not needed for the user to give a quantity type to
> /constants/ (here 2.0). It is /meant/ to be a a number of seconds. This, as
> opposed to measure /variables/.
> Thus, we possibly could have:
>
I know about the 'auto' feature, and you're right, it would make more sense
use it in this situation, I just wanted to make the type of the variables
clearer. If one wants to have a data member with a measurement unit, one
needs to know the type of the object. But, you're right, that is definitely
how you would do it.
Regarding, the factory function, I was thinking that for convenience (not
write two pairs of parenthesis) we could have the function. Maybe using the
constructor is a better idea, we could provide both.
The system should definitely be able to figure out the type of dist1 /
Quantity!("second")(2.0) or dist1*dist1 automatically, you're right.
About constants. How would the system know that 2.0 is supposed to be
seconds? Imagine the following situation:
auto distance = Quantity!("metre")(3.0);
auto mass = Quantity!("kilogram")(2.0);
auto speed = Quantity!("metres/second")(mass/2.0); // oops, the programmer
meant distance/2.0
Now the system would automatically infer that the unit for 2.0 is
"metre/(second*kilogram)" to get metres/second and the whole point of units
would be defeated. My idea is to only allow adimensional initializers
(floats, doubles etc.) for the quantites, and specify the unit for the
constants. So there would be no need to do Quantity!("meters/second"). One
could simply say:
auto speed= distance / Quantity!("second")(2.0);
One final note about 'auto'. If a programmer abuses auto, then the part of
the reason to have units is lost. In the above example, if one simply used:
auto speed = mass / Quantity!("second")(2.0);
Then this would not fail here (it might fail later, or not at all), since
there is no unit checking performed. I think that ideally one should avoid
using auto when initializing from a result of an operation between two other
variables.
>auto dist1 = Quantity!("meter")(3.0);
>auto area = Quantity!("metre^2")(dist1 * dist1);
>auto speed = Quantity!("metre/second")(dist1 / 2.0);
>
> (Unsure whether your system could automagically infer the unit of area. ?)
>
> I'm not fan of using strings as unit identifiers. Why don't you want to use
> use the corresponding types (structs or classes) themselves?
>
> auto dist1 = Quantity!Meter(3.0);
>
> Thus requiring each unit to be identified by a (possibly empty) struct or
> class. This also gives the opportunity for the user to actually implement
> some useful stuff in there; or to *reuse* existing types for
> things-to-be-counted (in the latter case, measures would actually be integer
> /counts/); see your Widget vs Gadget example below).
>
>
I agree that using strings as unit identifiers is a bad idea. I'm not sure
if I was clear when I said I wanted to use mixins for the units. The strings
would be converted (using string mixins) to actual type names, therefore you
wouldn't be able to use any string for a unit - it has to be the name of a
type. The reason to use strings is to be able to write derived units easily.
"Quantity!(Meter/Second)(3.0)" is not valid D if Meter and Second are types,
right? So, if you wanted to use the type names you would have to do
"Quantity!( UnitDivison!(Meter,Second) )(3.0)". An idea would be to allow
both. When there is a single type involved, you could write
Quantity!Meter(3), but when one wants to get a derived unit, one could use a
string "Meter*Second^-1" - this would behind the scenes call a function like
UnitDivision, of course. What do you think?
>
> Con
Re: i like cakes
On 3/28/2011 7:31 AM, FeepingCreature wrote: ILiekCakes actually has some good points once you get past the instinctive fanboy's revulsion for people who are not in awe of D. ;) Trying to give the impression that I'm responsible for Tango's choice of license isn't one of them. To reiterate: 1. None of Phobos is or ever was BSD licensed. 2. I never suggested to the Tango devs that they use BSD. 3. The Tango devs never asked me what license to use and never included me in any discussion about it. 4. I have offered to them the ability to adapt any Phobos module to Tango and relicense it as necessary for anything I have the right to do so.
Re: "body" keyword is unnecessary
On 3/27/2011 10:35 PM, Jonathan M Davis wrote: I'll be _very_ excited to have both the destructor issues and the const issues sorted out. They are some of the more annoying quality of implementation issues at the moment. Yes, I agree those are the top priority at the moment, now that we have the 64 bit compiler online and the worst of the optlink issues resolved.
Re: [GSoC Proposal] Statically Checked Measurement Units
On 3/28/11 5:43 PM, Cristi Cobzarenco wrote: First, let me apologize for this very late entry, it's the end of university and it's been a very busy period, I hope you will still consider it. This is by no means a late proposal – the application period has not even formally opened yet. I was somewhat surprised to see your post, because I had been playing around with a dimensional algebra/unit system implementation for a while before the whole GSoC thing started. I even have an unfinished project proposal for it lying around, but as I thought that I was rather alone with my fascination for unit systems, I decided to finish the Thrift one first. Well, seems like I was wrong… :) A few things that came to my mind while reading your proposal: - The need for numerical ids is not inherent to a dimension-aware model like Boost.Units – it's just needed because there is no way to get a strict total order of types in C++. You will need to find a solution for this in D as well, because you want to make sure that »1.0 * second * metre« is of the same type as »1.0 * metre * second«. - I think that whether disallowing implicit conversion of e.g. millimeters to meters is a good idea has to be decided once the rest of the API has been implemented and one can actually test how the API »feels« – although I'd probably disallow them in my design by default as well, I'm not too sure if this actually works out in practice, or if it just cumbersome to use. Also, I'd like to note that whether to allow this kind of implicit conversions doesn't necessarily depend on whether a system has the notion of dimensions. - Not that I would be too fond of the Boost.Units design, but »convenience« functions for constructing units from strings like in your second example could be implemented for it just as well. - You have probably already thought of this and omitted it for the sake of brevity, but I don't quite see how your current, entirely string-based proposal would work when units and/or conversion factors are defined in a module different from the one the implementations of Quantity/convert/… are in. Contrary to C++, D doesn't have ADL, so I am not sure how a custom base unit would be in scope for Quantity to find, or how a custom conversion template could be found from convert(). Anyway, I am not sure whether I should submit my own units proposal as well, but if you should end up working on this project, I'd be happy to discuss any design or implementation issue you'd like to. David
Re: Managing the review queue
On 3/27/2011 8:53 PM, dsimcha wrote: From observing the review processes for std.parallelism and std.net.isemail, I think our review process needs some tweaking. There are two key issues: 1. The pace of reviews is glacial unless there's a vote date near. Only 4 people have reviewed std.net.isemail, and that's counting any participation in the discussion as "review". This module doesn't have a vote date yet. IIRC only two people reviewed std.parallelism during its first two weeks of review. Furthermore, it took some time after I requested review for the "official" review period to start. As a solution all requests for review should come with a tentative vote date to prevent the module from being held in limbo indefinitely and move the review queue along. I know that reviews can be frustratingly slow. It's mainly because we have a smallish community. 2. Reviews that prompt major changes right before the vote date are stressful. A looming deadline is not conducive to careful discussion and consideration of suggestions, especially those that are non-trivial to understand and/or implement. I propose that all review periods last one week for small modules or two weeks for large modules, subject to extension if the review process is still yielding good discussion near the vote date or "stashing" if the author needs time to discuss specific issues that were raised and/or design and implement changes. When a module is stashed, it is no longer officially in review and the next item in the review queue, if any, can begin the process. As soon as this item is done, review of the stashed item is resumed. Right now, std.parallelism is stashed until std.net.isemail is finished. To prevent the community from being overwhelmed, multiple reviews may not take place concurrently but a review may take place concurrently with a vote. Contention for the review queue is an issue in theory, but that's a problem we'd like to have and can work out on an ad-hoc basis should it arise. More specifically, the pace of reviews for std.net.isemail has been glacial. If everyone who intends to review it has done so, we should move on to a vote. If anyone intends to review this module but hasn't yet, please do so or at least state your intention to do so. Different people have interests in different things. I don't think a person interested in std.parallelism would necessarily have any interest in std.net.isemail, and vice versa, so those can be done in parallel (!). A further issue with the review process is that the bulk of people won't look at something until it is actually released. I think the only way to deal with this is to be willing to correct deficiencies found after release.
Re: Managing the review queue
== Quote from Walter Bright (newshou...@digitalmars.com)'s article > A further issue with the review process is that the bulk of people won't look > at > something until it is actually released. I think the only way to deal with > this > is to be willing to correct deficiencies found after release. Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements.
Re: Managing the review queue
On 3/28/2011 12:18 PM, dsimcha wrote: == Quote from Walter Bright (newshou...@digitalmars.com)'s article A further issue with the review process is that the bulk of people won't look at something until it is actually released. I think the only way to deal with this is to be willing to correct deficiencies found after release. Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements. I have thought in the past about putting such modules into another package, call it "foo" for lack of a better name, and put it in the dmd distribution. If the package pans out in real life, then move it to std. So, yes, I think your idea is a good one.
Re: GCC 4.6
On 3/28/2011 11:49 AM, dsimcha wrote: Correct me if I'm wrong, but I think some important optimizations (like inlining) are performed in the front end. It's pretty obvious that DMD's inliner needs improvement, though I agree with Walter's decision to prioritize this below fixing major bugs, 64 support and (before that) finalizing the spec. Therefore, the performance of GDC is still a quality of implementation issue rather than a fundamental technical issue. By fundamental technical issue, I mean things like Python's numeric types which require runtime testing for every operation, and are very resistant to known techniques of optimization. D's perf problems have known causes that are not faults in the language, but are fixable in the compiler using known techniques. It's just a matter of priorities and manpower. In fact, D has many attributes that offer the potential for significantly better code generation than C/C++. They've just not been exploited yet.
Re: Complete D grammar
On 3/28/2011 9:02 AM, Luca Boasso wrote: A complete D grammar is one of the objectives of my GSOC 2011 ANTLR proposal, if I got accepted you will have one :) The complete grammar should be part of the D spec. Please post any errors/fixes to the existing one to bugzilla!
Re: Managing the review queue
Walter: > I have thought in the past about putting such modules into another package, > call > it "foo" for lack of a better name, and put it in the dmd distribution. If > the > package pans out in real life, then move it to std. So, yes, I think your > idea > is a good one. It's a nice idea. Possible names: "std.experimental", "std.unstable" or "std.minefield" :-) In Python there is kind of built-in namespace named "future" that you import as module, it contains even new basic language features in testing (like integer division!). I'd like the same in D2 too, for experimental features. Bye, bearophile
Re: i like cakes
On 3/28/11 9:31 AM, FeepingCreature wrote: On 28.03.2011 15:19, random lurker wrote: FeepingCreature Wrote: On 28.03.2011 03:45, Gary Whatmore wrote: Hello again I've stayed quiet for a long time because people started accusing me of trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY TROLL! :-( - G.W. Are you the idiot with the sockpuppets? Good job giving all of us a bad name. Gary Whatmore's message looks like a troll post to me. Could even be iLiekCaeks himself. ILiekCakes actually has some good points once you get past the instinctive fanboy's revulsion for people who are not in awe of D. ;) I've never had an emotional response to such posts but I'd be hard pressed to gather insight tidbits from them. He has technical knowledge and follows developments in D with a zeal worth of a nobler cause, but all he tries is to manipulate everything and everyone to make D look bad and to derail any constructive discussion. I'm surprised you are falling for that. His recent longer rants reveal some quite interesting personality issues and give insights into his ulterior motives and their origins. Probably an interesting case for a social psychologist. Anyway, just like in the case of 'retard', the main annoyance to me is wasted time on such a low signal/noise ratio. Reddit is difficult to browse as is. One of these days I'll spend 15 minutes finding and installing a good killfile-like reddit browser extension. (Does anyone know of one?) Andrei
Re: [GSoC Proposal] Statically Checked Measurement Units
- I too was playing around with a units project before GSoC, that is why I
thought doing this project was a good idea. The way I was doing it without
numerical IDs was simply by having more complicated algorithms for equality,
multiplications etc. For example, equality would be implemented as:
template UnitTuple(P...) {
alias P Units;
}
template contains( Unit, UT ) {
/* do a linear search for Unit in UT.Units (since UT is a UnitTuple) -
O(n)*/
}
template includes( UT1, UT2 ) {
/* check for each Unit in UT1 that it is also in UT2 (using contains) -
O(n^2) */
}
template equals( UT1, UT2 ) {
immutable bool equals = includes!(UT1,UT2) && includes!(UT2, UT1);
}
Granted this means that each check takes O(n^2) where n is the number of
different units, but it might be worth it - or not. On the small tests I've
done it didn't seem to increase compile time significantly, but more
research needs to be done. I think that as long as there aren't values with
_a lot_ of units (like ten), the extra compile time shouldn't be noticeable.
The biggest problem I have with adding IDs is that one will have to manage
systems afterwards or have to deal with collisions. Neither one is very
nice.
- You're right, you don't need dimensions for implicit conversions, of
course. And you're also right about possibly making the decision later about
implicit conversions. The thing is F#, where units are very popular, only
has explicit conversions, and I was trying to steer more towards that model.
- I seem not to have been to clear about the way I would like to use
strings. The names of the units in the strings have to be the type names
that determine the units. Then one needs a function that would convert a
string like "Meter/Second" to Division!(Meter, Second), I'm not sure how you
would do that in C++. Maybe I'm wrong, but I can't see it.
- I hope it is by now clear that my proposal is not, in fact, string based
at all. The strings are just there to be able to write derived units in
infix notation, something boost solves by using dummy objects with
overloaded operators. The lack of ADL is a problem which I completely
missed; I have immersed myself in C++ completely lately and I've gotten used
to specializing templates in different scopes. These are the solutions I can
come up with, but I will have to think some more:
1. There is an intrusive way of solving this, by making the conversion
factors static members of the unit types, but this would not allow, for
example, having a Widget/Gadget counter the way I intended.
2. The way they get away with it in F# is to use global conversion factors,
that one manually uses. That actually is not bad at all. The only problem
was that I was hoping that conversion between derived units could
automatically be done using the conversion factors of the fundamental units:
(meter/second) -> (kilometer/hour) knowing meter->kilometer and
second->hour.
Again I will have to think some more about the latter point. And I'll do
some more tests on the performance of doing linear searches. Is there way to
get the name of a type (as a string) at compile time (not the mangled name
you get at runtime)? I wasn't able to find any way to do this. My original
idea was actually to use the fully qualified typenames to create the
ordering.
Thanks a lot for your feedback, it's been very helpful, especially in
pointing out the lack of ADL. Hope to hear from you again.
On 28 March 2011 20:57, David Nadlinger wrote:
> On 3/28/11 5:43 PM, Cristi Cobzarenco wrote:
>
>> First, let me apologize for this very late entry, it's the end
>> of university and it's been a very busy period, I hope you will still
>> consider it.
>>
>
> This is by no means a late proposal – the application period has not even
> formally opened yet.
>
> I was somewhat surprised to see your post, because I had been playing
> around with a dimensional algebra/unit system implementation for a while
> before the whole GSoC thing started. I even have an unfinished project
> proposal for it lying around, but as I thought that I was rather alone with
> my fascination for unit systems, I decided to finish the Thrift one first.
> Well, seems like I was wrong… :)
>
> A few things that came to my mind while reading your proposal:
> - The need for numerical ids is not inherent to a dimension-aware model
> like Boost.Units – it's just needed because there is no way to get a strict
> total order of types in C++. You will need to find a solution for this in D
> as well, because you want to make sure that »1.0 * second * metre« is of the
> same type as »1.0 * metre * second«.
>
> - I think that whether disallowing implicit conversion of e.g. millimeters
> to meters is a good idea has to be decided once the rest of the API has been
> implemented and one can actually test how the API »feels« – although I'd
> probably disallow them in my design by default as well, I'm not too sure if
> this actually works out in practice, or if it just cumbersome to use. Als
Re: Determine the "type" of a delegate
On Mon, 28 Mar 2011 08:48:18 -0400, Steven Schveighoffer wrote:
> On Sat, 26 Mar 2011 06:46:22 -0400, teo wrote:
>
>> Having a delegate d, I can use d.ptr to get a void* pointer to the
>> environment used to construct the delegate. How can I determine from
>> that pointer whether that is a class object?
>
> AFAIK, you can't.
>
> -Steve
I tried to find a solution, but since I don't exactly know the anatomy of
the class object it is not an easy task. Is there any info on how the
class object is laid out in memory? Basically I casted the pointer to an
Object and then dumped the first 64 bytes looking for hints.
Here is the code:
import std.stdio;
struct S
{
void t() { writeln("S"); }
}
class C
{
void t() { writeln("C"); }
}
void main()
{
auto c = new C();
S s;
auto t1 = &c.t;
auto t2 = &s.t;
writeln("the class:");
dump(t1.ptr);
writeln("the struct:");
dump(t2.ptr);
}
void dump(void* p)
{
dump(cast(Object)p);
}
void dump(Object o)
{
auto size = size_t.sizeof * 8;
writeln("object:");
auto b1 = (cast(ubyte*)(cast(size_t*)o))[0 .. size];
dump(b1);
writeln("classinfo:");
auto b2 = (cast(ubyte*)(cast(size_t*)o.classinfo))[0 .. size];
dump(b2);
}
void dump(ubyte[] buffer)
{
auto l = 16;
auto n = buffer.length / l + (buffer.length % l > 0 ? 1 : 0);
for (int i = 0; i < n; i++)
{
auto s = i * l;
auto e = s + l;
writefln(" %02x", buffer[s .. (e > $) ? $ : e]);
}
}
BTW: I am getting strange results from writefln - the format is not obeyed
the class:
object:
[f0, e4, 49, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[75, 74, 66, 2d, 33, 32, 6c, 65, 0, 0, 0, 0, 0, 0, 0, 8]
[a0, 1b, 4a, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[75, 74, 66, 2d, 31, 36, 6c, 65, 0, 0, 0, 0, 0, 0, 0, 8]
classinfo:
[b0, f9, 49, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[10, 0, 0, 0, 0, 0, 0, 0, d0, e4, 49, 0, 0, 0, 0, 0]
[06, 00, 00, 00, 00, 00, 00, 00, e0, e4, 49, 00, 00, 00, 00, 00]
[07, 00, 00, 00, 00, 00, 00, 00, f0, e4, 49, 00, 00, 00, 00, 00]
the struct:
object:
[00, 21, 0e, 7b, 57, 7f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
[80, be, fc, 7a, 57, 7f, 0, 0, 78, c1, 45, 0, 0, 0, 0, 0]
[40, 72, a6, 10, ff, 7f, 0, 0, 2c, c1, 45, 0, 0, 0, 0, 0]
[a0, 72, a6, 10, ff, 7f, 0, 0, 45, 3b, 46, 0, 0, 0, 0, 0]
classinfo:
Segmentation fault
Re: Managing the review queue
On Mon, 28 Mar 2011 15:32:44 -0400, bearophile wrote: > Walter: > >> I have thought in the past about putting such modules into another >> package, call it "foo" for lack of a better name, and put it in the dmd >> distribution. If the package pans out in real life, then move it to >> std. So, yes, I think your idea is a good one. > > It's a nice idea. Possible names: "std.experimental", "std.unstable" or > "std.minefield" :-) Personally I like the experimental/incubator idea (though it had better not get a 'std' prefix!). I'm not sure the D community is large enough to support a more formal review process (yet). > In Python there is kind of built-in namespace named "future" that you > import as module, it contains even new basic language features in > testing (like integer division!). I'd like the same in D2 too, for > experimental features. I don't see the connection. '__future__' in Python isn't for experimental features, nor is it for introducing stdlib changes. It's a way to 'import' language features which become standard in later releases. For example, as you know, the 'print' statement becomes a function in Python 3.0, but you can disable the print statement in Python 2.6+ via 'from __future__ import print_function'. Graham
Re: i like cakes
killfile-like? You mean with an option to ignore posts from certain users? This should do the trick: http://reddit.honestbleeps.com/ ```User Tagger - now with ignore! Allows you to set a tag and highlight color for any user on reddit that is applied whenever you see their name. New in v1.1 - also *allows you to ignore comments/posts from users you don't like*! ```
Re: [GSoC Proposal] Statically Checked Measurement Units
On 3/28/11 10:43 AM, Cristi Cobzarenco wrote: First, let me apologize for this very late entry, it's the end of university and it's been a very busy period, I hope you will still consider it. Note this email is best read using a fixed font. PS: I'm really sorry if this is the wrong mailing list to post and I hope you'll forgive me if that's the case. === Google Summer of Code Proposal: Statically Checked Units === [snip] This is a good place to discuss pre-submission proposals. To submit, go to http://d-programming-language.org/gsoc2011.html later today. This is a strong draft proposal that I am likely to back up when complete. A few notes: * There is a good overview of existing work, which puts the proponent in the right position to make the best choices for an implementation in D. * Human-readable strings as means to generate types is a fertile direction. One issue is canonicalization, e.g. "meters^2" would be a different type from "meters ^ 2" (and btw that should mimic D's operators, so it should use "^^"), and both are different from the semantically equivalent "meters*meters". I think this is avoidable by a function that brings all strings to a canonical form. This needs to be discussed in the proposal. * The approach to quantities of discrete objects (widgets, gadgets and I hope to see examples with degrees, radians etc.) is very promising. I'm also looking forward to a "Categorical" type - an integer-based quantity that describes a bounded enumeration of objects, for example "CityID". Categorical measures are not supposed to support arithmetic; they simply identify distinct objects in an unrelated space. * In the final proposal the scope of the library should be clarified (e.g. what kinds of units and related idioms will be supported, and what kinds you chose not to support and why). * At best the proposal could define and project a relationship with std.datetime, which defines a few units itself. Wonder whether it's possible to simplify std.datetime by using the future units library. Thanks for your interest, and good luck! Andrei
Re: Managing the review queue
Graham Fawcett: > I don't see the connection. '__future__' in Python isn't for experimental > features, nor is it for introducing stdlib changes. It's a way to 'import' > language features which become standard in later releases. But the end result is the same: if they find troubles in a feature present just in __future__, then I am sure they fix them before the feature becomes standard. Bye, bearophile
Re: GCC 4.6
Walter: > By fundamental technical issue, I mean things like Python's numeric types > which > require runtime testing for every operation, and are very resistant to known > techniques of optimization. Life is a bit more complex than that: - The Lua JIT has shown once and for all that dynamic typing is not as bad (performance-wise) as you think. I have floating-point heavy benchmarks that run faster in jitted Lua than in D compiled with DMD. - Python is a language, and there are many ways to run a language. You are able to interpret D code and to compile Python code. Since several years I am helping the develpment of ShedSkin, a Python->C++ compiler, that uses powerful type inferencing to infer all the static types of an implicitly static Python program. The results are sometimes faster than D programs compiled with DMD, because they are essentially pretty clean C++ programs compiled by G++. - Today GPUs are used more and more where the max performance is needed, and example: http://www.i-programmer.info/news/105-artificial-intelligence/2176-kinects-ai-breakthrough-explained.html And you are able to write and run such GPU kernels from Python code too. Bye, bearophile
Re: [GSoC Proposal] Statically Checked Measurement Units
Thanks for your answer!
- I agree that using strings to represent units is not a particularly good
idea. Since many people have noted related things, I seem not to have been
particularly clear about the way I intend to use strings. Let me try to
explain it in detail:
There is a type that determines the unit:
struct Meter {}
Then every quantity is parametrised with two aliases:
Quantity!(UnitList, ValueType)
UnitList represents a list of pairs (UnitType,Exponent), where UnitType is a
typename (like Meter) and Exponent is a static rational type. Therefore, the
following would be a valid quantity type:
Quantity!( UnitList!( UnitPair!(Meter,1) ), double )
The strings are parsed at compile time and converted (using mixins) into the
UnitList. For example:
ParseUnitString!("meters/second") -> UnitListDivison!( UnitList!(
UnitPair!(Meter,1) ), UnitList!( UnitPair!(Second,1) ) ) -> UnitList(
UnitPair!(Meter,1), UnitPair!(Second,-1) ).
Therefore there is no need to convert all strings to a cannonical form, they
are all converted to an alias tuple (UnitList). To check whether two
UnitList's are the same, one can check double-inclusion. What do you think,
does this make sense.
- The Categorical type sounds like a great idea. I think they could be
passed on as a ValueType to a quantity:
typedef Quantity!(City, BoundedInt!(0,100)) CityID;
And BoundedInt is just a type implicitly-convertible to and from int, that
supports assignment and equality and throws on an out-of-bounds assignment.
What do you think?
On 28 March 2011 21:53, Andrei Alexandrescu
wrote:
> On 3/28/11 10:43 AM, Cristi Cobzarenco wrote:
>
>> First, let me apologize for this very late entry, it's the end
>> of university and it's been a very busy period, I hope you will still
>> consider it.
>>
>> Note this email is best read using a fixed font.
>>
>> PS: I'm really sorry if this is the wrong mailing list to post and I
>> hope you'll forgive me if that's the case.
>>
>> === Google Summer of Code Proposal: Statically Checked Units ===
>>
> [snip]
>
> This is a good place to discuss pre-submission proposals. To submit, go to
> http://d-programming-language.org/gsoc2011.html later today.
>
> This is a strong draft proposal that I am likely to back up when complete.
> A few notes:
>
> * There is a good overview of existing work, which puts the proponent in
> the right position to make the best choices for an implementation in D.
>
> * Human-readable strings as means to generate types is a fertile direction.
> One issue is canonicalization, e.g. "meters^2" would be a different type
> from "meters ^ 2" (and btw that should mimic D's operators, so it should use
> "^^"), and both are different from the semantically equivalent
> "meters*meters". I think this is avoidable by a function that brings all
> strings to a canonical form. This needs to be discussed in the proposal.
>
> * The approach to quantities of discrete objects (widgets, gadgets and I
> hope to see examples with degrees, radians etc.) is very promising. I'm also
> looking forward to a "Categorical" type - an integer-based quantity that
> describes a bounded enumeration of objects, for example "CityID".
> Categorical measures are not supposed to support arithmetic; they simply
> identify distinct objects in an unrelated space.
>
> * In the final proposal the scope of the library should be clarified (e.g.
> what kinds of units and related idioms will be supported, and what kinds you
> chose not to support and why).
>
> * At best the proposal could define and project a relationship with
> std.datetime, which defines a few units itself. Wonder whether it's possible
> to simplify std.datetime by using the future units library.
>
>
> Thanks for your interest, and good luck!
>
> Andrei
>
--
(Cristi Cobzarenco)
Pofile: http://www.google.com/profiles/cristi.cobzarenco
Re: Complete D grammar
On 3/28/11, Walter Bright wrote: > On 3/28/2011 9:02 AM, Luca Boasso wrote: >> A complete D grammar is one of the objectives of my GSOC 2011 ANTLR >> proposal, if I got accepted you will have one :) > > The complete grammar should be part of the D spec. Please post any > errors/fixes > to the existing one to bugzilla! > Sorry for the inaccuracy, I meant a complete grammar up-to-date with the current D spec. that can be used by the ANTLR parser generator.
Re: Managing the review queue
On 28/03/11 21.19, Walter Bright wrote: On 3/28/2011 12:18 PM, dsimcha wrote: == Quote from Walter Bright (newshou...@digitalmars.com)'s article A further issue with the review process is that the bulk of people won't look at something until it is actually released. I think the only way to deal with this is to be willing to correct deficiencies found after release. Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements. I have thought in the past about putting such modules into another package, call it "foo" for lack of a better name, and put it in the dmd distribution. If the package pans out in real life, then move it to std. So, yes, I think your idea is a good one. Please do! I would love to put in the libcurl wrapper in for early feedback. Libcurl supports many other protocols that just HTTP, and it would be very nice to try out the wrapper design initially by implementing HTTP only support. Based on the feedback of that the rest of the protocols could be implemented. /Jonas
Re: GCC 4.6
On 3/28/2011 1:12 PM, bearophile wrote: Walter: By fundamental technical issue, I mean things like Python's numeric types which require runtime testing for every operation, and are very resistant to known techniques of optimization. Life is a bit more complex than that: - The Lua JIT has shown once and for all that dynamic typing is not as bad (performance-wise) as you think. There's a lot of money and manpower behind Python. If this were true, why hasn't this technology been done for Python? Secondly, even Lua's proponents (like ilikecakes) says he uses Lua in hybrid configurations with C and C++, so there is clearly some sort of deficit with Lua. I have floating-point heavy benchmarks that run faster in jitted Lua than in D compiled with DMD. Come on. As has been discussed to death here, dmd's back end does not do floating point well, in particular, it does not make use of XMM instructions. Any code generator that does will perform better. And, Python does not have the dynamic typing issue with floats that it does with integers. Jitted floating point Python code *should* match performance with statically compiled floating point code.
Re: Complete D grammar
"David Nadlinger" wrote in message news:imq92m$1ru0$1...@digitalmars.com... > On 3/28/11 5:17 PM, Kagamin wrote: >> Trass3r Wrote: >> >>> Didn't someone here have a complete D grammar? I vaguely remember that >>> there is at least a D1 one buried somewhere. >> >> huh? >> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=20299 > Like Trass3r said, that's lexing-only right now. > Nope, Trass3r is talking about a grammar for the D language itself, > whereas Goldie is a parser generator for D (which generates parsers for a > given grammar). > Technically speaking, Goldie doesn't actually generate parsers, it has one grammar-independent parser that it uses for all grammars (fairly characteristic for LALR(1), AIUI). Although, in the static-style it does make a slight custom modification to the parser and lexer so that each token emitted is properly typed. Which I suppose amounts to six-of-one, half-dozen-of-the-other... > Unfortunately, I only remember someone working on one (and filing some > related bugs), I lost the details as well. > Yea, I remember that too. Someone took all the BNF sections from D's docs on digitalmars.com, put them together, and filled in some missing/erroneous parts. Maybe it's on wiki4d?
Re: [GSoC Proposal] Statically Checked Measurement Units
Cristi Cobzarenco wrote: > Again I will have to think some more about the latter point. And I'll do > some more tests on the performance of doing linear searches. Is there way to > get the name of a type (as a string) at compile time (not the mangled name > you get at runtime)? I wasn't able to find any way to do this. My original > idea was actually to use the fully qualified typenames to create the > ordering. T.stringof where T is some type gives you the name of the type at compile time. Jens
Re: i like cakes
On Mon, 28 Mar 2011 18:31:54 +0400, FeepingCreature wrote: On 28.03.2011 15:19, random lurker wrote: FeepingCreature Wrote: On 28.03.2011 03:45, Gary Whatmore wrote: Hello again I've stayed quiet for a long time because people started accusing me of trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY TROLL! :-( - G.W. Are you the idiot with the sockpuppets? Good job giving all of us a bad name. Gary Whatmore's message looks like a troll post to me. Could even be iLiekCaeks himself. ILiekCakes actually has some good points once you get past the instinctive fanboy's revulsion for people who are not in awe of D. ;) I always thought FeepingCreature/ILiekCakes/downs are the same person. Am I wrong?
Re: how to use a lib in d
Yoohoo, i got eclipse working with it an compiled without errors. So if i understand it correctly a .h/.di file contains the info abou what's compiled in the lib so you can use it, sounds logical :) And about eclipse: when i let him autocomplete when i haven't typed anything it freezes for 2 minutes. My guess is that it loads all sugestions in one time (instead for example the first 20) causing everything to freeze? Where can i inform the maintainers (apart from the forums)? There are like 4 different plugins and i don't know which one i'm using. It's the not-abondoned one :) And is the ide on dprogramminglanguage.com still maintained? Thanks to all the help so far
[GSOC idea] enhance regular expressions?
Hello,
(this is a long post, you may skip this introduction)
I was sticking around D's NG for about a year and following it's
advancements very closely. I was busy ruthlessly wasting my spare time
for testing this or that of cool features, converting some personal C++
projects. Maybe it's time to introduce myself: I'm student in the middle
of getting my master's degree in Moscow Institute of Physics and
Technology. My main interests for the last years were C++,
metaprogramming, compiler theory and, lately, robotics and
microcontrollers. I got attracted to D2 as a natural way to reinvest my
C++ knowledge (honestly, C++0x is such a mess) and, in fact, looked
forward to do some hackery on some real-world compiler (that would be
DMD). As sort of warm-up to get better grasp on the language and
real-world interpreters alike I did some work on DMDScript (porting it
to D2 among others) it's available on
http://dsource.org/projects/dmdscript-2. Note that I haven't touched it
in couple of dmd releases, it may need cosmetic fixes.
To summarize, I'm no stranger to regular expressions and parsing and
want to utilize this experience to help community, what follows is my
first attempt at proposal, any comments and ideas are warmly welcome.
--- somewhat informal draft ---
Having regular expression (regex) engine in standard library is totally
expected for any modern language.
The solid and performant implementation of regex is one of the greatest
points of pride (if not of sale).
While concrete results and benchmarks got frequently biased, there are
some general conclusions:
regexes usually came in two flavors: Finite Automation (FA, be it
deterministic or nondeterministic) and backtracking, each of these
with their set of traits.
FA are more stable O(N) in time on input, however they are usually more
limited as implementing features such as backreferences becomes
problematic, also not to mention the time for constructing DFA from pattern.
Backtracking allows easily implementing some interesting features like
backreferencing, lookahead/lookbehind and such, but has a dreadful
exponential time on input in worst case.
Not willing to go deeper into the performance/feature/usage topic,
fairly good picture of various regular expression engines can be found
here: http://lh3lh3.users.sourceforge.net/reb.shtml. I though have now
idea why he claims RE2 is feature-rich.
Now speaking of D, what we have now is essentially an optimized
backtracking with some not implemented features it may very well have
had. Also consider important issue that need proper resolution
http://d.puremagic.com/issues/show_bug.cgi?id=941. This situation begs
for a change.
The proposal consists of three parts:
1) Enhance and bugfix the existing engine in std.regex. Sometime ago I
got accustomed with this engine internals and confident that I can get
it done. That's a short-term solution at best and something I plan to do
in spare time even if it's not considered a compelling GSOC proposal ;)
2) Make another one FA-based from scratch, here things go somewhat
speculative.
I plan to start with NFA, leaving DFA on later. Probably NFA with cached
DFA states as optimization tuning aka memory vs time. Someone brought
http://swtch.com/~rsc/regexp/regexp1.html, it could be a starting point,
I see some optimization opportunities I'd like to try. Supporting
unicode of all flavors is of no question. The API for this engine may
stay the same or it even may be integrated into existing one, making
the type of engine a compile-time parameter with default being
Regex.Backtracking. Suppose:
auto dfa = regex!Regex.NFA("(D|N)?FA","g");
3) When I saw Don's comments on fixing CTFE, I remembered something D
can do _better_ than most others mainstream compiled languages -
metaprogramming. So having a StaticRegex compiled at compile-time
(inevitable calambour) would give us an edge over comparative
implementations. Also I can imagine quite a lot of applications not
requiring *any* regex from non-constant pattern. Major exceptions are
editors with find/replace and certain scripting/parsing toolkits.
It looks quite natural:
...
enum sregNum= StaticRegex!"[-+]?[0-9]*\.?[0-9]+([eE][-+]?[0-9]+)";
...
assert(match("PI: 3.1415926",sregNum).hit == "3.1415926");
The best speed gain most likely would be obtained by generating the
whole DFA at compile time, I believe such possibility was previously
discussed on the NG.
This diversity in kinds of regexes may warrant making regex engine an
interface ( for homogeneous storage and parameter passing) with concrete
implementations being classes.
Another thing to sort out is style: are we sticking with ECMA or
switching to Perl / GNU? Shall we provide also different versions of
syntax?
--
Dmitry Olshansky
Re: GCC 4.6
Walter: >There's a lot of money and manpower behind Python. If this were true, why >hasn't this technology been done for Python?< It was done, more than one time. One good JIT was Psyco. And more recently PyPy is about to surpass Psyco in performance: http://codespeak.net/pypy/dist/pypy/doc/ But the Lua JIT is quite better than Psyco, its programmer is very intelligent (Psyco author too is an intelligent programmer, Armin Rigo). And more importantly, this whole discussion can't be reduced to just a static Vs dynamic typing. Lua and Python are different languages, Python is probably more dynamic than Lua, it is quite more powerful than Lua, and it's different. So creating a really efficient JIT for Python is much harder than doing it for Lua, and you can't compare them much. The result is that currently PyPy is generally about 8/10 times slower than D code, while Lua-Jit is about 2-3 times slower than D compiled well, and JavaScript running on the V8-CrankShaft JIT is about 3-4 times slower than D. And Mozilla hopes to someday beat V8, though a local static inferencer (probably to be seen in Firefox 5? See the "(TypeInference)" here, it's in development still: http://arewefastyet.com/?a=b&view=regress ). > Secondly, even Lua's proponents (like ilikecakes) says he uses Lua in hybrid > configurations with C and C++, so there is clearly some sort of deficit with > Lua. Lua is a quite simple language, there are some things you can't do well with it, so you need other languages. And even with a JIT Lua is often not as fast as good C code. I have never said that Lua+JIT is better than D, I am not much interested in Lua. > And, Python does not have the dynamic typing issue with floats that it does > with > integers. Jitted floating point Python code *should* match performance with > statically compiled floating point code. Regarding strictly *dynamic typing* Python floats are as dynamic as Python integers. You probably mean that Python floats are structs that wrap around CPU doubles, while Python3 integers are multi-precision ones (Python2 integers are hybrids). The fact they are multi-precision is orthogonal to dynamic typing: you are able to use multi-precision integers in D too (BigInt). Multi-precision integers are not intrinsically dynamically typed. Regarding multi-precision integers, CommonLisp, OcaML and Factor languages show that tagged integers (that become multi-precision when the stack-allocated fixed ones have an overflow) are not as slow as you think. I have written small programs in Factor (a modern and quite refined stack-based language), and if you don't go past the precision of the tagged integers, they don't slow down the code a lot. Their slowdown is comparable to the difference of runtime performance of array-heavy D code compiled with and with -release switch. Bye, bearophile
Re: i like cakes
On 28.03.2011 20:51, Walter Bright wrote: > On 3/28/2011 7:31 AM, FeepingCreature wrote: >> ILiekCakes actually has some good points once you get past the >> instinctive >> fanboy's revulsion for people who are not in awe of D. ;) > > Trying to give the impression that I'm responsible for Tango's choice of > license isn't one of them. To reiterate: > > 1. None of Phobos is or ever was BSD licensed. > > 2. I never suggested to the Tango devs that they use BSD. > > 3. The Tango devs never asked me what license to use and never included > me in any discussion about it. > > 4. I have offered to them the ability to adapt any Phobos module to > Tango and relicense it as necessary for anything I have the right to do so. I didn't say all his points were good. The Tango mess is just miscommunication and rumours flying left and right, and I do applaud you for persistently trying to clear it up.
Re: i like cakes
Denis Koroskin: > I always thought FeepingCreature/ILiekCakes/downs are the same person. Am > I wrong? Feep is a bit messy programmer, but he's a good programmer, I have seen many things written by him. If they are the same person, then he has a quite complex psychology ;-) Bye, bearophile
Re: Managing the review queue
KennyTM~: > Python's future statement provides features that will certainly be > enabled. It's a feature to provide smoother code compatibility with > earlier versions. Every decision is pretty much settled when it is > available in __future__, and the only step left is to enable it by default. > > This is not the case for incubator/foo/experimental. There is no > guarantee that the module must be voted in, nor the interface will be > the same when transitioning to std. You are right, there are important differences. Beside a Phobos module like std.experimental, I'd like a way to activate experimental features in D too. There is a similar feature in Haskell too, and it's used a lot. Bye, bearophile
Re: Managing the review queue
On Mar 29, 11 04:04, bearophile wrote: Graham Fawcett: I don't see the connection. '__future__' in Python isn't for experimental features, nor is it for introducing stdlib changes. It's a way to 'import' language features which become standard in later releases. But the end result is the same: if they find troubles in a feature present just in __future__, then I am sure they fix them before the feature becomes standard. Bye, bearophile I disagree. Python's future statement provides features that will certainly be enabled. It's a feature to provide smoother code compatibility with earlier versions. Every decision is pretty much settled when it is available in __future__, and the only step left is to enable it by default. This is not the case for incubator/foo/experimental. There is no guarantee that the module must be voted in, nor the interface will be the same when transitioning to std.
Re: Determine the "type" of a delegate
On 28/03/11 8:47 PM, teo wrote: I tried to find a solution, but since I don't exactly know the anatomy of the class object it is not an easy task. Is there any info on how the class object is laid out in memory? Basically I casted the pointer to an Object and then dumped the first 64 bytes looking for hints. The D ABI is described here: http://digitalmars.com/d/2.0/abi.html It describes the class layout.
Re: i like cakes
On 28.03.2011 23:32, bearophile wrote: > Denis Koroskin: > >> I always thought FeepingCreature/ILiekCakes/downs are the same person. Am >> I wrong? > > Feep is a bit messy programmer, but he's a good programmer, I have seen many > things written by him. If they are the same person, then he has a quite > complex psychology ;-) > > Bye, > bearophile I was d|owns but that name was stupid. Got the idea for FeepingCreature in the NHD, checked on Slashdot and it wasn't taken. Then I went ahead and standardized on that across all my accounts. I'm not wm4 either :-)
Re: [GSOC idea] enhance regular expressions?
Dmitry Olshansky: > http://dsource.org/projects/dmdscript-2. Note that I haven't touched it > in couple of dmd releases, it may need cosmetic fixes. I will try it. > http://swtch.com/~rsc/regexp/regexp1.html, it could be a starting point, Before fully embracing the contents of that page, look at its critics too. > 3) When I saw Don's comments on fixing CTFE, I remembered something D > can do _better_ than most others mainstream compiled languages - > metaprogramming. So having a StaticRegex compiled at compile-time > (inevitable calambour) would give us an edge over comparative > implementations. But it inflates the binary too, if overused, because each RE pattern becomes a compiled function (or more than one). > Another thing to sort out is style: are we sticking with ECMA or > switching to Perl / GNU? Shall we provide also different versions of > syntax? One RE syntax in a language is more than enough :-) But there are some features of the Python REs that I'd like to see bolted-on to the ECMA REs used by D. So I suggest a superset of ECMA. Bye, bearophile
Re: GCC 4.6
On Mar 29, 11 04:33, Walter Bright wrote: On 3/28/2011 1:12 PM, bearophile wrote: Walter: By fundamental technical issue, I mean things like Python's numeric types which require runtime testing for every operation, and are very resistant to known techniques of optimization. Life is a bit more complex than that: - The Lua JIT has shown once and for all that dynamic typing is not as bad (performance-wise) as you think. There's a lot of money and manpower behind Python. If this were true, why hasn't this technology been done for Python? Psyco? (http://psyco.sourceforge.net/, though it seems to be stuck at 2.6) PyPy also supports JITting (http://codespeak.net/pypy/dist/pypy/doc/jit/index.html) Secondly, even Lua's proponents (like ilikecakes) says he uses Lua in hybrid configurations with C and C++, so there is clearly some sort of deficit with Lua.
Re: [GSoC Proposal] Statically Checked Measurement Units
On 2011-03-28 12:53, Andrei Alexandrescu wrote: > * At best the proposal could define and project a relationship with > std.datetime, which defines a few units itself. Wonder whether it's > possible to simplify std.datetime by using the future units library. Well, I can't say what's possible before we actually have a proposed units module, but I doubt that there's much in std.datetime which could be simplified by having a units library. The units portion of it is a fairly small piece. There are functions templatized on time units, but that's all so generic that it's not exactly much code. So, it'll be interesting to see how a units module might relate to it, but I question that it would really do much to simplify it. - Jonathan M Davis
Re: GCC 4.6
On 3/28/11 4:31 PM, bearophile wrote: Walter: There's a lot of money and manpower behind Python. If this were true, why hasn't this technology been done for Python?< It was done, more than one time. One good JIT was Psyco. And more recently PyPy is about to surpass Psyco in performance: http://codespeak.net/pypy/dist/pypy/doc/ But the Lua JIT is quite better than Psyco, its programmer is very intelligent (Psyco author too is an intelligent programmer, Armin Rigo). And more importantly, this whole discussion can't be reduced to just a static Vs dynamic typing. To be brutally honest, I'd say that this discussion (and a few others) could be reduced to zero. We have a good list of things we know need to be done, all vying for top positions. We're gearing up for a GSoC 2011 program that will be, it seems, extremely rewarding but quite taxing for those of us who are overseeing the process. This is a good time to stay focused and productive. Discussions about some or another minutia or comparative merits and demerits of various approaches can quickly drown the good content. At best this newsgroup would contain a majority of GSoC proposals and related discussions, review discussions for the currently proposed modules, preliminary design discussions on emerging libraries, progress reports, and the such. Thanks, Andrei
Re: i like cakes
On 03/28/2011 10:29 PM, Andrei Alexandrescu wrote: His recent longer rants reveal some quite interesting personality issues and give insights into his ulterior motives and their origins. Probably an interesting case for a social psychologist. Yeah, the next step is to label him a psycho and put into a nuthouse.
Re: i like cakes
wm4/iLiekCakes is a smart guy, and decent enough if you're not talking about D. However, he consistently makes shit up about D if he doesn't know it, and is a pretty constant troll.
John Song has been accepted as a GSoC 2011 mentor for Digital Mars
My fellow engineer John Song has joined the ranks of our GSoC 2011 mentors. John works with me on the larger ads team at Facebook and we've used or seen each other's code on occasion. He kindly offered to help with a Thrift-related project, so in case David Nadlinger's application is accepted John would likely mentor David. Please join me in congratulating and wishing the best to John. We have five mentors, and are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Registration for students opens later today. Andrei
Re: i like cakes
On Mon, 28 Mar 2011 14:29:42 -0500, Andrei Alexandrescu wrote: > Anyway, just like in the case of 'retard', the main annoyance to me is > wasted time on such a low signal/noise ratio. Reddit is difficult to > browse as is. One of these days I'll spend 15 minutes finding and > installing a good killfile-like reddit browser extension. (Does anyone > know of one?) http://www.reddit.com/r/Enhancement Install that, click the underscore next to one of his postings, enter a tag (doesn't matter what it is) and check 'ignore'. Refresh, and his postings will be replaced with "this user has been ignored". If you want something stronger, you can set it to remove the entire comment block.
Re: i like cakes
On 3/28/11 5:03 PM, Bernard Helyer wrote: On Mon, 28 Mar 2011 14:29:42 -0500, Andrei Alexandrescu wrote: Anyway, just like in the case of 'retard', the main annoyance to me is wasted time on such a low signal/noise ratio. Reddit is difficult to browse as is. One of these days I'll spend 15 minutes finding and installing a good killfile-like reddit browser extension. (Does anyone know of one?) http://www.reddit.com/r/Enhancement Install that, click the underscore next to one of his postings, enter a tag (doesn't matter what it is) and check 'ignore'. Refresh, and his postings will be replaced with "this user has been ignored". If you want something stronger, you can set it to remove the entire comment block. Awesome. Thank you! Andrei
Re: John Song has been accepted as a GSoC 2011 mentor for Digital Mars
On 3/28/2011 2:51 PM, Andrei Alexandrescu wrote: My fellow engineer John Song has joined the ranks of our GSoC 2011 mentors. Congratulations and welcome!
Re: [GSOC idea] enhance regular expressions?
On 29.03.2011 1:47, bearophile wrote: Dmitry Olshansky: http://dsource.org/projects/dmdscript-2. Note that I haven't touched it in couple of dmd releases, it may need cosmetic fixes. I will try it. No problem, feel free to report any issues. There should be working bugtracker if I remember correctly. http://swtch.com/~rsc/regexp/regexp1.html, it could be a starting point, Before fully embracing the contents of that page, look at its critics too. I've seen them, and they are expected, also I thought I clearly presented some of logical considerations. 3) When I saw Don's comments on fixing CTFE, I remembered something D can do _better_ than most others mainstream compiled languages - metaprogramming. So having a StaticRegex compiled at compile-time (inevitable calambour) would give us an edge over comparative implementations. But it inflates the binary too, if overused, because each RE pattern becomes a compiled function (or more than one). Well, in case that result would be a data structure or bytecode created at the compile-time using CTFE. The function for matching or replacing using the resulting structure/program would be the same as run-time one. It's "inflating" binary like any static data. Then StaticRegex!"whatever" should be convenience wrapper hiding all this complexity. Anyway I partly agree, there are limitations and considerations when using such technique. And it would rely on CTFE that does not leak memory like hell. Another thing to sort out is style: are we sticking with ECMA or switching to Perl / GNU? Shall we provide also different versions of syntax? One RE syntax in a language is more than enough :-) But there are some features of the Python REs that I'd like to see bolted-on to the ECMA REs used by D. BTW which ones? Now is the time to propose them. So I suggest a superset of ECMA. Your vote counted ;) Bye, bearophile -- Dmitry Olshansky
Re: John Song has been accepted as a GSoC 2011 mentor for Digital Mars
On 29.03.2011 1:51, Andrei Alexandrescu wrote: My fellow engineer John Song has joined the ranks of our GSoC 2011 mentors. Congratulations! Finally, the D crew is getting manpower at rapid pace :) -- Dmitry Olshansky
Re: [GSoC] RFC: Thrift project proposal (draft)
I just revised the proposal and submitted it via Google's official interface, so don't be confused if you can't find it on my website any longer. David
Re: Managing the review queue
On 03/28/2011 09:18 PM, dsimcha wrote: == Quote from Walter Bright (newshou...@digitalmars.com)'s article A further issue with the review process is that the bulk of people won't look at something until it is actually released. I think the only way to deal with this is to be willing to correct deficiencies found after release. Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements. Anyway,n this is far better than premature adoption (mainly because later found issues often reveal design bugs that require major modification). Denis -- _ vita es estrany spir.wikidot.com
Re: Managing the review queue
On 03/28/2011 09:32 PM, bearophile wrote: Walter: I have thought in the past about putting such modules into another package, call it "foo" for lack of a better name, and put it in the dmd distribution. If the package pans out in real life, then move it to std. So, yes, I think your idea is a good one. It's a nice idea. Possible names: "std.experimental", "std.unstable" or "std.minefield" :-) std.experimental is better than std.foo, because 'foo' is far too useful as variable name ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: Managing the review queue
On 03/28/2011 10:32 PM, Jonas Drewsen wrote: On 28/03/11 21.19, Walter Bright wrote: On 3/28/2011 12:18 PM, dsimcha wrote: == Quote from Walter Bright (newshou...@digitalmars.com)'s article A further issue with the review process is that the bulk of people won't look at something until it is actually released. I think the only way to deal with this is to be willing to correct deficiencies found after release. Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements. I have thought in the past about putting such modules into another package, call it "foo" for lack of a better name, and put it in the dmd distribution. If the package pans out in real life, then move it to std. So, yes, I think your idea is a good one. Please do! I would love to put in the libcurl wrapper in for early feedback. Libcurl supports many other protocols that just HTTP, and it would be very nice to try out the wrapper design initially by implementing HTTP only support. Based on the feedback of that the rest of the protocols could be implemented. This idea seems to find large support very fast... Denis -- _ vita es estrany spir.wikidot.com
Re: i like cakes
Bernard Helyer Wrote: > On Mon, 28 Mar 2011 14:29:42 -0500, Andrei Alexandrescu wrote: > > Anyway, just like in the case of 'retard', the main annoyance to me is > > wasted time on such a low signal/noise ratio. Reddit is difficult to > > browse as is. One of these days I'll spend 15 minutes finding and > > installing a good killfile-like reddit browser extension. (Does anyone > > know of one?) > > http://www.reddit.com/r/Enhancement > > Install that, click the underscore next to one of his postings, enter a > tag (doesn't matter what it is) and check 'ignore'. Refresh, and his > postings will be replaced with "this user has been ignored". If you want > something stronger, you can set it to remove the entire comment block. > That's perfect. One of D's biggest problems are these nutheads. Unfortunately this place isn't unique in any way, I meet these at work too. Often these are in charge of some major open source project like the gnu libc. I hope Andrei's corporation won't ever been hiring these folks. Bruno and Google probably also use their search results and AI competence to block his job applications. In my opinion the best would be if these sick people wouldn't work at all as computer engineers. Preferably they could stay employed and die of starvation or commit a suicide. The world doesn't need them. I'd say they don't even deserve a normal life with benefits such as a girlfriend, but then again these are lonely university dropout nerds living in their parent's basement, still using old CRT tubes and ranting about their superiority on internet forums.
Re: [GSOC idea] enhance regular expressions?
Dmitry Olshansky: > BTW which ones? Now is the time to propose them. Verbose regular expressions, that allow to put space and comments, to format REs more like code and less like a cryptic puzzle language. (?:...) A non-grouping version of regular parentheses. Matches whatever regular expression is inside the parentheses, but the substring matched by the group cannot be retrieved after performing a match or referenced later in the pattern. (?P...) Similar to regular parentheses, but the substring matched by the group is accessible via the symbolic group name name. A symbolic group is also a numbered group. (?P=name) Matches whatever text was matched by the earlier group named name. (?=...) Lookahead assertion. Matches if ... matches next, but doesn't consume any of the string. (?!...) Negative lookahead assertion. Matches if ... doesn't match next. The contained pattern must only match strings of some fixed length. (?<=...) Positive lookbehind assertion. Matches if the current position in the string is preceded by a match for ... that ends at the current position. The contained pattern must only match strings of some fixed length. (?
Re: GCC 4.6
Andrei: > To be brutally honest, I'd say that this discussion (and a few others) > could be reduced to zero. I have suggested the Google Summer of Code for D even the past year, and I agree it's important for D future. But I think Walter has to know something about modern JITs & dynamic languages too. I have had bad experiences with Guido (Python author) that until no more than one or two years ago seemed to didn't even know what a trampoline stub is, and this has caused some problems. You have to take care of the knowledge of your Benevolent Dictator For Life, I want Walter to know lot of things. Bye, bearophile
Re: i like cakes
I don't think discussions like this are productive. Let's just write some code and prove them wrong.
Re: [GSOC Draft Proposal] ANTLR and Java based D parser for IDE usage
You've hit on every point I thought important for the ANTLR project, and it seems to me you understand the underlying influences of the need of it. I'm not a mentor, but I wish you all the best in this project -- a complete ANTLR grammar, with generated code in use, would be a great boon.
Re: [GSOC idea] enhance regular expressions?
On 03/28/2011 11:47 PM, bearophile wrote: Dmitry Olshansky: http://dsource.org/projects/dmdscript-2. Note that I haven't touched it in couple of dmd releases, it may need cosmetic fixes. I will try it. http://swtch.com/~rsc/regexp/regexp1.html, it could be a starting point, Before fully embracing the contents of that page, look at its critics too. 3) When I saw Don's comments on fixing CTFE, I remembered something D can do _better_ than most others mainstream compiled languages - metaprogramming. So having a StaticRegex compiled at compile-time (inevitable calambour) would give us an edge over comparative implementations. But it inflates the binary too, if overused, because each RE pattern becomes a compiled function (or more than one). Another thing to sort out is style: are we sticking with ECMA or switching to Perl / GNU? Shall we provide also different versions of syntax? One RE syntax in a language is more than enough :-) But there are some features of the Python REs that I'd like to see bolted-on to the ECMA REs used by D. So I suggest a superset of ECMA. ... especially the ability to insert free spacing to clarify / comment the string pattern (meaning literal whitespace is escaped like '.', etc) (dunno if D regex supports that already though). Denis -- _ vita es estrany spir.wikidot.com
Re: [GSoC Proposal] Statically Checked Measurement Units
On 03/28/2011 10:13 PM, Cristi Cobzarenco wrote: - The Categorical type sounds like a great idea. I think they could be passed on as a ValueType to a quantity: typedef Quantity!(City, BoundedInt!(0,100)) CityID; And BoundedInt is just a type implicitly-convertible to and from int, that supports assignment and equality and throws on an out-of-bounds assignment. I would implement something like Categorical in a language that has no enum. But I do not see the point in D. What advantage does it bring? Denis -- _ vita es estrany spir.wikidot.com
Re: John Song has been accepted as a GSoC 2011 mentor for Digital Mars
On 3/28/11 11:51 PM, Andrei Alexandrescu wrote: My fellow engineer John Song has joined the ranks of our GSoC 2011 mentors. John works with me on the larger ads team at Facebook and we've used or seen each other's code on occasion. He kindly offered to help with a Thrift-related project, so in case David Nadlinger's application is accepted John would likely mentor David. From student to mentor, this might sound somewhat strange, but nevertheless: Welcome to the D community, John! Thank you for offering to voluntarily spend your time on a GSoC mentorship – if my proposal should be accepted, I'd be glad to work with an experienced Thrift developer/user. If you are reading this, John, would you mind having a short look at my proposal which you should find on your Google Melange dashboard? I'd greatly appreciate any feedback. Registration for students opens later today. Not that it would matter, but registration was already open by the time you wrote your post. ;) David
Re: [GSOC] Database API
On Sun, 27 Mar 2011 07:11:01 +0900, David Nadlinger wrote: On 3/26/11 12:44 AM, Masahiro Nakagawa wrote: Currently, many databases exist. * SQL based: MySQL, PostgresSQL, SQLite, etc.. * KVS: Cassandra, HBase, Kumofs, Redis, etc... * Document Oriented: MongoDB, CouchDB, etc... I think next Database API should support these types. I don't think this is the way to go, as there is a huge conceptional difference between relational database systems and »NoSQL« systems such as, say, CouchDB or Cassandra. It's an open question. Ruby / Rails has Arel (note that Arel is data access abstraction, not database access abstraction. But Database access is a part of data access). Haskell has Database.Persistent. I think other languages will support similar library in the future. How would such a unified API look like? I don't have a detail. I already implemented it if I had a detailed design. In my D tasks, database related task is low priority...
Re: John Song has been accepted as a GSoC 2011 mentor for Digital Mars
On 3/28/11 11:51 PM, Andrei Alexandrescu wrote: My fellow engineer John Song has joined the ranks of our GSoC 2011 mentors. John works with me on the larger ads team at Facebook and we've used or seen each other's code on occasion. He kindly offered to help with a Thrift-related project, so in case David Nadlinger's application is accepted John would likely mentor David. From student to mentor, this might sound somewhat strange, but nevertheless: Welcome to the D community, John! Thank you for offering to voluntarily spend your time on a GSoC mentorship – if my proposal should be accepted, I'd very much appreciate if I could work with an experienced Thrift developer/user. If you are reading this, John, would you mind having a short look at my proposal which you should find on your Google Melange dashboard? I'd be happy about any early feedback. Registration for students opens later today. Not that it would matter, but registration was already open by the time you wrote your post. ;) David
