Re: construct range from tuple?
On Sunday, 18 September 2016 at 09:36:13 UTC, e-y-e wrote:
On Sunday, 18 September 2016 at 08:06:54 UTC, Lutger wrote:
[...]
Use std.range's 'only' function [1], it takes variadic
arguments of the same type and constructs a range consisting of
them.
Example:
import std.meta : AliasSeq;
import std.range : only;
import std.algorithm.comparison : equal;
alias names = AliasSeq!("Alice", "Bob");
auto range = only(names, "Chuck");
assert(range.equal(["Alice", "Bob", "Chuck"]));
That's *exactly* what I was looking for, thanx!
Re: Can vibe d leverage existing web technologies?
On Thursday, 15 September 2016 at 20:56:19 UTC, Intersteller wrote: On Thursday, 15 September 2016 at 14:31:28 UTC, Martin Tschierschke wrote: On Tuesday, 13 September 2016 at 23:45:18 UTC, Intersteller wrote: vibe.d does not have much lateral support as the most commons web technologies do. Can vibe.d leverage pre-existing techs such as php, ruby/rails, etc? Starting from scratch and having to build a robust and secure framework is really not the way to go. A good way to mix different technologies is to use a Apache or nginx proxy on the same server, so you can start using vibe.d for some parts and keep the rest at its place. Regards mt. How is this done? How can it be done smoothly? I'm not sure how to partition the work load. While, say, some pages might be served from php, and others from vibe2, etc, it seems like it would be nightmare to maintain consistency and interactivity. True. It is easier to maintain if you do a 'vertical split'. So each subsystem maintains a strict boundary. You have to be clear about the dependencies between subsystems and any data exchange should happen via an explicit api. So there is no shared database between the D part and the php part for example. Communication with json over http is common and well supported by vibe.d. See: http://martinfowler.com/articles/microservices.html This a more coarse grained approach which reduces coupling between the different parts. For example, you could write a small api with vibe.d which does image processing, or collects and manipulates data from third party apis, or whatever. The rails app handles authentication and ui, making use of the services that your vibe.d api provides. Another example: if you have a reasonably standalone part of a webapplication such as administrative pages or whatever, you could program that in vibe.d and let an nginx server route everything /admin/* to that part. The rails app exposes an api to modify its data which the admin app build in vibe.d makes use of.
construct range from tuple?
I have a tuple of strings generated at compile time, for example:
alias names = AliasSeq!("Alice", "Bob");
How is it possible to construct a range of strings from this, in
order to use it at runtime with other range algorithms?
For example, this
chain(names, ["Chuck"])
doesn't work as intended because it expands to
chain("Alice", "Bob", ["Chuck"])
I want some function makeRange that works like this:
assert(chain(makeRange(names), ["Chuck"]).fold!( (x,y) => x ~ " "
~ y) ==
"Alice Bob Chuck");
What would be a good way to do that?
Equivalent of FirstOrDefault with ranges
I was looking for something like FirstOrDefault* from .NET in
phobos. For example, I have this piece of code:
string findBobOrReturnNull(string[] names)
{
auto r = names.find("bob");
if(r.empty) return null;
return r.front;
}
assert(findBobOrReturnNull(["alice", "bob"]) == "bob");
assert(findBobOrReturnNull(["alice"]) is null);
How can I turn that into something like this, or is there another
idiomatic way to write it as a single expression?
string findBobOrReturnNull(string[] names)
{
return names.find("bob").firstOrDefault;
}
*
https://msdn.microsoft.com/en-us/library/bb340482%28v=vs.110%29.aspx
Re: documented unit tests as examples
On Friday, 13 May 2016 at 21:00:04 UTC, Steven Schveighoffer wrote: On 5/13/16 4:55 PM, Meta wrote: When I was new to D and I first saw the `assert(...)` idiom in an example in the documentation, it confused me for a minute or two, but if you know what `assert` does you can quickly wrap your head around the fact that it's both a test and an example. This would benefit users that are completely new to programming in general, however. Given the fact that asserts aren't always run, it's never comforting to me to run a program that tests something and have it give NO feedback. In fact, I frequently find myself triggering the assert to make sure it's actually being run (and I've caught the build not actually running it many times). This has a negative affect on anyone actually looking to see how a D function works. I can write a program that does nothing easily enough, why such a complicated example? -Steve This is a flaw of the simplistic test runner, not of the idea of unittests itself. Every other unittest system I worked with, including for example unit-threaded in D, reports a summary of the amount of tests that are ran. Very simple and just enough information that the test you just added has indeed been executed. One line is enough. Honestly I think keeping asserts in examples is better than the assert/writeln hybrid approach, because 1) asserts give the reader exact information about the expected behavior and contracts of a function (this information is lost to the reader when the asserts are reduced to print statements) and 2) having unittests compile to something very differently depending on context sounds like adding too much accidental complexity. Ideally there would be a way to print the values of all arguments given to an assert, that would be the most informative. And zooming out just a one liner with the number of tests or asserts ran and the number succeeded. I think this should be the domain of an external tool or library though, not the compiler itself. It is certainly possible to create such a tool and have phobos use it, no reason to add more complexity to the language itself.
Re: The end of curl (in phobos)
I was at dconf, but missed the discussion where this was spoken of. I'm curious to know what is wrong with the curl wrapper. I've only recently been following D again after a gap of several years and remember curl being received quite favorablyt at the time, several people used it as an example of good api design. Its such a useful and simple piece of functionality to have out of the box, greatly increasing the amount of interesting things you can do with D without installing additional packages. Phobos already has lackluster support for common web technologies, it would be a bummer if curl is deprecated before a replacement was in place.
Re: D projects list
Denis Shelomovskij wrote: I think it will be great to have a single place for all D related projects so a developer can easily find what is already done (for an example of I didn't now about you project see, e.g. Modern COM Programming in D thread), what is *planned* and what great projects have already failed (and, maybe, reveal it). A draft variant of how I see such page is this with a few projects added (note Planned tag (yes, empty for now)): http://deoma-cmd.ru/d/d-projects-list/ Usage examples: * lets find a D compiler with release or beta maturity: http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release * lets find not abandoned GUI library for D: http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into GitHub so developers can fork and edit it. I'd like to hear (but yes, I can only read, this is NG) any thoughts about this idea. It's a great idea. I used djangopackages.com a lot when I was doing a django project, something like this would be awesome for D. You might like to check it out, it has some nice features. So, apparently djangopackages.com is built with opencomparison, which is an open source project in itself: http://opencomparison.org/
Re: Website message overhaul
Andrei Alexandrescu wrote: On 11/13/11 8:37 PM, bearophile wrote: Andrei Alexandrescu: Feedback is welcome. The overall look is nice, I like the foldable examples, but I think there's too much text for a home page. I think it's better to move lot of text in a introduction page. I suggest to avoid titles like Multi-paradigm power, because they sound a bit too much too buzzwordy. What characteristic of D would you substitute as a major differentiating feature? I like the term modeling power a lot, and would use this as the main point. It's straightforward, suggests a trade-off and has a pragmatic connotation.
Re: The CAPI Manifesto
Walter Bright wrote: On 10/17/2011 12:42 AM, Jacob Carlborg wrote: Already working on a package manager for D: https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D https://github.com/jacob-carlborg/orbit/ Is it possible (and worthwhile) to layer a package manager over a github repository? Yes, pip (for python) can do it.
Re: [std.database]
Jacob Carlborg wrote: On 2011-10-12 20:13, Steve Teale wrote: The way this discussion is going we're going to have four layers, with the top one written by Jacob. Hehe. As long as there are database connections available in Phobos and a fairly good API with different levels available it should be possible to create an ORM API as a separate project. That should be the way to go, an ORM is a huge and difficult project.
Re: Lazy Literal Range: Stooid late-nite idea?
Jacob Carlborg wrote:
On 2011-10-09 08:33, Vladimir Panteleev wrote:
On Sun, 09 Oct 2011 06:06:21 +0300, Nick Sabalausky a@a.a wrote:
Great, right? But what about this?:
auto x = [runtimeExpressionA, runtimeExprB, runtimeExprC,
etc].find(blah);
With the anonymous delegate literal syntax suggested by Andrei a while
ago, you should be able to write this as:
auto x = [() = runtimeExpressionA, () = runtimeExprB, () =
runtimeExprC, () = etc].find(blah);
I guess it looks quirky with an empty parameter list, but it's shorter
than writing {return runtimeExpressionA;}, {return runtimeExpressionB;}
etc.
Or wrap it in a function taking a list of lazy parameters:
http://www.d-programming-language.org/function.html#parameters
auto x = lazyRange(runtimeExpressionA, runtimeExprB, runtimeExprC);
typesafe variadics with delegates also allow for this syntax, though not
with type inference. I hacked this together:
struct LazyRange(T)
{
import std.array;
this(T delegate()[] input...)
{
_input = input;
}
@property
bool empty() const
{
return std.array.empty(_input);
}
void popFront()
{
std.array.popFront(_input);
_isCached = false;
}
@property
T front()
{
if (_isCached)
return _front;
_front = std.array.front(_input)();
_isCached = true;
return _front;
}
private:
T _front;
bool _isCached = false;
T delegate()[] _input;
}
unittest
{
import std.algorithm;
auto stuff = LazyRange!string(foo,
foo ~ bar,
{ assert(false); return bat; }(),
meow);
assert(find(stuff,foobar).front == foobar);
}
Re: Simple I know, but could use some help compiling with make
Roderick Gibson wrote: ... Hmm, looks like it would be awesome, unfortunately it spits out a bunch of previous definition different errors on the linker, in relation to the libraries. Oh well, I seem to be able to get it working with dmd for now. This could be caused by having two 'main' functions in all the modules that rdmd finds.
Re: Don't use arrays as stacks
Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.160.1316939358.26225.digitalmar...@puremagic.com... On Sunday, September 25, 2011 03:18:29 Andrew Wiley wrote: Isn't this exactly what assumeSafeAppend is for? Hmm, I didn't know about that. (Actually, I remember hearing it mentioned before, but then totally forgot about it.) and if you're using assumeSafeAppend, then you need to guarantee that nowhere else has a reference to that array (otherwise it's _not_ safe to assume that it's safe to append) Would the consequences of failing to do that be any worse (or any different at all?) than what I mentioned about: One caveat about this method: If you save a slice of the stack, pop elements off the stack, and then push new values back on, the old slice you took will likely reflect the new values, not the original ones. ...? It looks like it behaves the same, but the docs mention this: 'Calling this function, and then using references to data located after the given array results in undefined behavior.' So it is not wise to depend on it. One thing that wasn't clear to me (but might be obvious): after modifying an array, the behavior is reset and you will need to call assumeSafeAppend again.
Re: Multithreaded file IO?
Jerry Quinn wrote:
Jonathan M Davis Wrote:
On Saturday, September 24, 2011 01:05:52 Jerry Quinn wrote:
Jonathan M Davis Wrote:
On Friday, September 23, 2011 23:01:17 Jerry Quinn wrote:
A direct rewrite would involve using shared and synchronized (either
on the class or a synchronized block around the code that you want to
lock). However, the more idiomatic way to do it would be to use
std.concurrency and have the threads pass messages to each other
using send and receive.
I'm trying the direct rewrite but having problems with shared and
synchronized.
class queue {
File file;
this(string infile) {
file.open(infile);
}
synchronized void put(string s) {
file.writeln(s);
}
}
queue.d(10): Error: template std.stdio.File.writeln(S...) does not
match any function template declaration queue.d(10): Error: template
std.stdio.File.writeln(S...) cannot deduce template function from
argument types !()(string)
Remove the synchronized and it compiles fine with 2.055.
Technically, sychronized should go on the _class_ and not the function,
but I'm not sure if dmd is currently correctly implemented in that
respect (since if it is, it should actually be an error to stick
synchronized on a function). Regardless of that, however, unless you use
shared (I don't know if you are), each instance of queue is going to be
on its own thread. So, no mutexes will be necessary, but you won't be
able to have multiple threads writing to the same File. It could get
messy.
I get similar errors if I put synchronized on the class, or shared. My
best guess is that a File struct cannot currently (2.055) be shared or
accessed in a synchronized context.
If I make the class synchronized and use __gshared on the File then it
compiles. I don't know if it works, though.
You could embed a File pointer in the synchronized queue, make sure it is
the sole owner, and then cast to File* when using it. The concurrency
chapter has a paragraph on this method that explains why it is not covered
by the type system.
I believe this is closest to your C++ example, I never did this though so
I'm not 100% sure it works.
Re: Any way to expand a tuple?
Andrej Mitrovic wrote:
import std.typetuple;
import std.typecons;
struct Foo
{
void test(int x, double y) { }
void opOpAssign(string op, T...)(T t)
if (op == ~)
{
test(t);
}
}
void main()
{
Foo foo;
foo.opOpAssign!~(4, 5.0); // ok
foo ~= tuple(4, 5.0); // fail
}
If I understand this correctly in the first call T becomes a D
language tuple, while in the second one it's a phobos library tuple. I
really hate this distinction and would love these two to be merged so
the second call could compile.
.expand on Tuple and generally .tupleof does the trick. Language tuples are
quite different and more general than typecons Tuple. If tuples would
automatically expand, this would not be possible:
import std.typetuple;
import std.typecons;
import std.stdio;
struct Foo
{
void test(Tuple!(int, int), double y) { writeln(overload a); }
void test(int, int, double y) { writeln(overload b); }
void opOpAssign(string op, T...)(T t)
if (op == ~)
{
test(t);
}
}
void main()
{
Foo foo;
foo.opOpAssign!~(tuple(4, 2), 5.0);// overload a
foo.opOpAssign!~(tuple(4, 2).tupleof, 5.0);// overload b
}
Re: Multithreaded file IO?
If you didn't know, the concurrency chapter of tdpl is a free chapter: http://www.informit.com/articles/article.aspx?p=1609144 It has an example of file copying with message passing: http://www.informit.com/articles/article.aspx?p=1609144seqNum=7
Re: Anonymous function syntax
Andrei Alexandrescu wrote:
On 9/22/11 10:42 AM, pillsy wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
On 9/22/11 1:47 AM, Max Klyga wrote:
Actually Scala doesn't need type declarations in labmda literals. Most
of the time argument types are infered.
Already does. We're looking for a briefer syntax.
What is the problem with just inferring the `return`, allowing you to
replace
(a,b) { return a + b; }
with
(a, b) { a + b; }
This seems competitive with the other syntaxes for brevity, but ISTR
there was some objection to doing things that way.
The objection is that it introduces a number of questions:
1. How about using that syntax in regular functions?
2. What if the lambda wants to actually evaluate the expression but
return void?
As an alternative, a brief syntax could just be restricted to lambda
expressions because we already have complete function literals for
statements, unlike python for example. A void returning function is only
used for side-effects, I am not be bothered at all to have to use full
punctuation for that.
(a, b) { a + b } or (a, b) = a + b would be sweet :)
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis wrote: On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, and I suspect that given the current issues with the GC, if you were working on a AAA game, then you'd probably want the folks doing it to be good C/C++ programmers so that they would know how to do what needed doing when they can't use the GC or most of the standard libraries. For projects where performance isn't quite as critical, then D stands a much better chance of working. It _is_ easier to learn and has some definite advantages over C++. Any programmer should be able to learn any language on the job. This doesn't make sense for small projects, but for larger projects the overhead can be small enough to warrant hiring competent programmers without any knowledge of the language. D is familiar enough for C++/C#/Java programmers to pick it up quickly. Especially for C++ programmers, given a sufficiently large timescale, it is not unthinkable that all time spent learning is recuperated by the productivity and scalability gains. I just cannot image a good C++ programmer having difficulty picking up D quickly.
User defined safety?
I wonder if anybody has brought up the idea of using or expanding the SafeD features to cover a user-defined kind of safety? Right now, @safe means memory safe and it is defined by the language. However, there are many kinds of safety that benefit from being layered in a manner similar to how safe/trusted/system works. A web application for example might want to restrict raw sql access in one layer, where care is taken to avoid injection attacks. The rest of the application trusts only this layer and is forbidden from accessing the sql drivers directly. A security audit script can grep for such forbidden use of sql, thus enforcing a 'provable' safe use of sql (with the liberal use of the word provable). In D it could be possible to enforce this layered design by the compiler. It is possible right now by an application programmer through the (ab)use of safe/trusted/system, by lumping memory and sql-injection safety together, though this has some serious drawbacks. What do you think of this, is it a good or bad use of these features? Going further, SafeD could be expanded by allowing user defined security labels as parameters of safe/trusted/system. For example, the user could define @system(SQL) and @trusted(SQL) as well as @system(SMTP) and @trusted(SMTP). @safe code can use the @trusted sql and smtp components, but not @system. In this model, @trusted(SMTP) is only allowed to call @system(SMTP) and not @system(SQL).
Re: Why callers should explicitly document storage classes
Mehrdad wrote:
Consider this example:
// In module foo.d:
void baz(bool condition, lazy int value)
{
if (condition)
writeln(value);
}
// In module bar.d:
import foo;
bool someCondition() { return false; }
void main()
{
auto vals = [1, 2, 3, 4];
while (!vals.empty)
baz(someCondition(), items.moveFront());
}
There is **absolutely NO WAY** to figure out what's wrong at the calling
site. You need to check /every/ method call and make sure nothing weird
is happening (e.g. lazy), and it's pretty much impossible to figure it
out unless you're intimately familiar with the entire library you're
calling -- something which (obviously) doesn't scale.
I'm not convinced that intimately is the right word here. Lazy evaluation is
a pretty big deal in the interface of a function, just like ref is. If you
have no idea at all what a function does, there is no hope to figure out
what the code at the call site does to begin with. Even without lazy/out/ref
you could be passing an object with reference semantics to a function which
mutates the object, same deal. Not everything is 'const correct', so this
may also be surprising if you do not know the function.
I don't know of a similar example off the top of my head for out/ref,
but the same idea applies.
Is this convincing enough that we need to document storage classes at
the CALLING site, rather than just the CALLEE site?
Do you mean literally documenting it or having the compiler require you to
state the storage class? If the first, I'd say it depends on the context.
The enforce function in phobos for example is clear and well known enough to
leave it out. I would not want the latter. But yes, if it's not clear enough
then it's a good idea. Preferably it would be clear from the function name
and purpose how it operates on the parameters though.
Re: [GSOC] regular expressions beta is here
Don wrote: bearophile wrote: Contracts don't replace unittests, they complement each other. They are nice but have little value over plain assert _unless_ we are talking about classes and _inheritance_, which isn't the case here. It's easy to forget to test the output of a function, the out contracts help here. In structs the invariant helps you avoid forgetting to call manually a sanity test function every time you come in and out of a method. You're conflating a couple of things here. Invariants are tremendously helpful for structs as well as classes. out contracts seem to be almost useless, unless you have a theorem prover. The reason is, that they test nothing apart from the function they are attached to, and it's much better to do that with unittesting. They have very little in common with 'in' contracts. I think that EVERY struct and class in Phobos should have an invariant (except for something like Complex, where there are no invalid values). But I don't think 'out' contracts would add much value at all. What about out contracts on interfaces in a library (where you use the library by implementing them).
Re: const assignments problem again
bearophile wrote: ... In my precedent post about this topic I have discussed nested constness and another partially silly idea. Recently I have seen a language that suggests me this: // version #6 const foo; if (abs(e.x - v.x) double.min) foo = (v.y - e.y) / (v.x - e.x); else foo = double.max; The compiler makes sure all paths assign values with the same type to foo (as in the case of the two returns inside the delegate, that must be of the same type). But if you introduce goto instructions version #6 looks fragile. If the assign is far away from the definition the code looks not so nice any more, so this feature is meant for short-range initializations only. Bye, bearophile I like the ternary operator the best for this, as it is the simplest. I always write them like this though, liberally include parenthesis and never nest: (condition) ? (truth value) : (false value) When it gets more complicated, you can always rewrite either the whole expression (to if/else or a function) or refactor parts of the expression to small functions. I never find this to be much of a burden. Python has if/else expressions, but due to it's (messy) scoping rules I almost never find them an improvement to if/else statements. I like the single assignment feature, but not for this reason. I think it would be more useful for creating immutable data in general.
Re: const assignments problem again
Timon Gehr wrote: Lutger Blijdestin wrote: I like the ternary operator the best for this, as it is the simplest. I always write them like this though, liberally include parenthesis and never nest: (condition) ? (truth value) : (false value) What is the benefit of this, compared to leaving parentheses away entirely? Oh, I didn't mean to *always* include parenthesis. Just that when a more complicated expression is involved, I find it often faster to understand if there are some redundant parenthesis.
Re: std.concurrency wrapper over MPI?
link for the D implementation: https://bitbucket.org/repeatedly/msgpack4d/
Re: std.concurrency wrapper over MPI?
dsimcha wrote: On 8/7/2011 11:36 AM, Jacob Carlborg wrote: Currently, the only available format is XML. Ok, I'll look into writing a binary archiver that assumes that the CPU architecture on the deserializing end is the same as that on the serializing end. If it works, maybe Orange is a good choice. Just in case you missed it, the messagepack protocol has a D implementation which seems to be what you're looking for: http://msgpack.org/ The last commit on bitbucket reveals it should be compatible with 2.054. Perhaps it can be adapted as an archiver for Orange.
Re: Where is 'tuple' in the language reference
Steve Teale wrote: I see the term used, but I can't find where it is defined. It's here: http://www.d-p-l.org/template.html#variadic-templates A Tuple is not a type, an expression, or a symbol. It is a sequence of any mix of types, expressions or symbols. The language terminology is easily confused with the constructs that phobos defines, where TypeTuple and Tuple mean different things.
Re: What library functionality would you most like to see in D?
Brad Roberts wrote: On Monday, August 01, 2011 7:31:13 PM, Andrei Alexandrescu wrote: On 8/1/11 7:51 PM, Brad Roberts wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Python has something and as far as I can tell people are fine with that. Andrei It has something _in the base library_? It has wrappers for all/most of the popular libraries? The standard distributions install some combination of those? I don't use python so I'm ill equipped to discuss, but my guess is that it's not the first but rather the last. It only has a wrapper for the Tkinter (from Tcl/Tk). I don't think a lot of people use it for serious stuff, it's kinda ancient. A lot of people use the Qt bindings though - these are not in the standard library.
Re: What library functionality would you most like to see in D?
Jimmy Cao wrote: 2011/8/2 so s...@so.so On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts bra...@slice-2.puremagic.com wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad I agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not! If a GUI library were included in Phobos, that would make D a much better competitor against C#. That's why I hope such an inclusion would be possible in the future. I see why it might not be possible, though. I really doubt that. You don't get to really compete with C# until D runs on .NET and perhaps even until microsoft adopts it. I don't think a standard gui lib will make any difference.
Re: What library functionality would you most like to see in D?
streams and network programming is most desirable, this also impacts other libraries. Another big one is async programming. Some kind of unified, higher level framework to deal with this could be a huge help - it's a hard problem. It's interesting to see that in .NET a lot of new stuff concerning async programming is coming out, suggesting that the (many) existing patterns are considered inadequate. In C# 5, async operations will be a language level feature with the async/await keywords. There is also the reactive extensions library for async streams: http://msdn.microsoft.com/en-us/data/gg577609. Most interesting about this one is how easy it is to compose async operations.
Re: error when std.range.Cycle of static array is a member
Steven Schveighoffer wrote: On Mon, 25 Jul 2011 11:25:17 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: Please file a 'rejects-valid' bug. http://d.puremagic.com/issues/show_bug.cgi?id=6385 Thanks, I'm sorry for slacking, have been a bit busy the last couple of days.
error when std.range.Cycle of static array is a member
I'm trying to have a Cycle range of a static array as a struct member, but
getting a compilation error. Can anybody tell me if I'm doing something
wrong, or is this a bug?
import std.range;
struct Foo
{
ubyte[] buf;
Cycle!(typeof(buf)) cbuf1; // ok
ubyte[1024] staticBuf;
Cycle!(typeof(staticBuf)) cbuf2; // error
void test()
{
Cycle!(typeof(staticBuf)) cbuf3;
cbuf3 = cycle(staticBuf); // ok
}
}
/std/range.d(228): Error: template instance std.array.front!(ubyte[1024u])
incompatible arguments for template instantiation
Re: error when std.range.Cycle of static array is a member
Jonathan M Davis wrote:
On Sunday 24 July 2011 12:06:47 Lutger Blijdestijn wrote:
I'm trying to have a Cycle range of a static array as a struct member,
but getting a compilation error. Can anybody tell me if I'm doing
something wrong, or is this a bug?
import std.range;
struct Foo
{
ubyte[] buf;
Cycle!(typeof(buf)) cbuf1; // ok
ubyte[1024] staticBuf;
Cycle!(typeof(staticBuf)) cbuf2; // error
void test()
{
Cycle!(typeof(staticBuf)) cbuf3;
cbuf3 = cycle(staticBuf); // ok
}
}
/std/range.d(228): Error: template instance
std.array.front!(ubyte[1024u]) incompatible arguments for template
instantiation
static arrays are not ranges. You can't pop the front off of them, so no
range- based algorithm would work with a static range. Now, you _can_ get
a dynamic range over a static range and _that_ is a valid range, so what
you need to do is make the Cycle a Cycle!(ubyte[]) rather than
Cycle!(ubyte[1024]), and you when you pass the static array to cycle, you
need to slice it: cycle(staticBuf[]).
- Jonathan M Davis
That would work, but the docs explicitly mention that Cycle is specialized
for static arrays (for performance reasons). This is how cycle is
implemented:
Cycle!(R) cycle(R)(ref R input, size_t index = 0) if (isStaticArray!R)
{
return Cycle!(R)(input, index);
}
Re: D Programming Language Specification ebook
Walter Bright wrote: On 7/4/2011 3:40 AM, Jonathan M Davis wrote: On 2011-07-04 03:24, bearophile wrote: Maybe older people equate free with bad, but newer generations are used to find good content for free on Internet. Is D designed for older people, people used to C and C++, that hate JavaScript? There's a difference between free on the internet and a free book. Exactly. It may not make rational sense, but it's true. Free books are regarded today like free software was 20 years ago - it must be crap. This does not hold for technical documentation. For TDPL yes, but not for a programming language specification. This view is also losing ground for programming books. There are a quite a few high quality books distributed online for free, even with a paper publishing deal.
Re: D Programming Language Specification ebook
Walter Bright wrote: On 7/4/2011 1:50 AM, Johann MacDonagh wrote: On 7/3/2011 10:11 PM, Walter Bright wrote: What do you all think? $0? $4.99? $9.99? What about skipping Amazon and putting it up on d-programming-language.org and ask for donations? I think Paypal will handle the processing for you for free if you show you're not doing it for profit. People at the airport press a free gift on me, and then harangue me for a donation. I think that's the wrong image for D. People shouldn't be made to feel guilty about using D and not making a donation. I know it would turn me off, at least. You can do it in a tasteful manner, without playing the guilt card. A price- pot for competitions sounds like a good idea. Think of it this way: you enable people to contribute to D with money instead of time and expertise, something that is not that easy to do right now.
Re: Why I'm hesitating to switch to D
Robert Clipsham wrote: On 29/06/2011 19:14, Walter Bright wrote: On 6/29/2011 4:03 AM, Adam Richardson wrote: I'll admit that I looked through to see what I could help out with on the website, but ddoc stopped me in my tracks. How did it stop you? DDoc vs Markdown: * Pretty much everyone who uses github, stackoverflow, and many other sites knows some amount of markdown * I've been using D for years and I pride myself on not knowing the hideous DDoc beyond Params: Example: etc. * DDoc macros make even the simplest things ugly Sure, but it's really apples and oranges. Any such template system for markup is both complicated, limited and convenient at once. It has no power at all. DDoc is the other way around, it's a very different approach. The equivalent to ddoc's extensibility would be hacking the sources of a markdown processor to extend it. Now that's painful. You could, for example, write everything in markdown but first put it through ddoc and then process it's output with some markdown tool. That way you write mostly simple markdown and have some extra power from the macro system. That's actually the approach that ddoc for D code has: very limited sugar for the most common cases, but with the optional power to extend it. The other way around should be possible too: a markdown macro which tags a fragment for postprocessing.
Re: DIP11: Automatic downloading of libraries
Jacob Carlborg wrote: On 2011-06-14 15:53, Andrei Alexandrescu wrote: http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11 Destroy. Andrei Instead of complaining about others ideas (I'll probably do that as well :) ), here's my idea: https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D I'm working on both of the tools mentioned in the above link. The ideas for the package manager are heavily based on Rubygems. Looks good, and has a cool name too! I love the reference to the mars / phobos theme. After 'cloning into orbit...', I think I'm missing a ruby ffi binding. Is it possible to build it already? Or is it too early for that? If I'm not mistaken the dependency on ruby is nicely factored into a very small part of orbit and could easily be replaced if someone would be inclined to do so. I'd prefer this over ruby, but I prefer ruby over the dsss format. In the end, what matters is the value of the tool.
Re: DIP11: Automatic downloading of libraries
Johannes Pfau wrote: Lutger Blijdestijn wrote: Jacob Carlborg wrote: On 2011-06-14 15:53, Andrei Alexandrescu wrote: http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11 Destroy. Andrei Instead of complaining about others ideas (I'll probably do that as well :) ), here's my idea: https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D I'm working on both of the tools mentioned in the above link. The ideas for the package manager are heavily based on Rubygems. Looks good, and has a cool name too! I love the reference to the mars / phobos theme. After 'cloning into orbit...', I think I'm missing a ruby ffi binding. Is it possible to build it already? Or is it too early for that? If I'm not mistaken the dependency on ruby is nicely factored into a very small part of orbit and could easily be replaced if someone would be inclined to do so. I'd prefer this over ruby, but I prefer ruby over the dsss format. In the end, what matters is the value of the tool. I personally think that ruby is a good choice for the config format (lua, python, whatever would be fine too), as we definitely need a programming language for advanced use cases (debian uses makefiles, which are a pita, but together with bash and external tools they still count as a programming language) It should be noted though that replacing the config syntax later on will be difficult: even if it's factored out nicely in the code, we could have thousands of d packages using the old format. In order not to break those, we'd have to deprecate the old format, but still leave it available for some time, which leads to more dependencies and problems... For D programmers that need this kind of advanced functionality it means they have to learn ruby as well. Whereas it's pretty safe to assume they already know D :) Another advantage of D is that built related scripts and extensions can be distributed easily with orbit itself. I'm thinking that maybe it is possible for dakefile.rb and dakefile.d to coexist in the same tool? I'm not sure if that creates problems, or if such extra complexity is worth it. However, those that really want to use D could try to convince Jacob Carlborg that D is a good alternative by implementing it, if he is open to that.
Re: [OT] D's community is awesome!
Andrej Mitrovic wrote: Holy hell Chrome loads it in a blink of an eye, no lag whatsoever and there's no laggy scrollbar either. Kudos to Google, I guess. Google did an awesome job with webkit and v8 (plus loads of caching). I'm running firefox 5 beta however and it's catching up with IE9 and chrome in performance. std.algorithm loads in 1-2 seconds and scrolling is fine.
Re: Flag proposal
bearophile wrote: Andrei: This module won't compile in today's D, but not for a matter of principles; it's just a random limitation of the language. (It does work if you import from within a class or struct.) You can insert most declarations in a scope, so the ones you can't insert are just awkward exceptions, unless there's a good reason to actively disable them. Any code should work if you just wrap another scope around it. Walter and I call the above a turtle feature, in allusion to the turtles all the way down meme. Walter wants to fix this, and similar limitations that act unturtly. Imports inside a scope won't be visible outside that scope, and importing the same module from several different functions will come at no cost in compilation time. You are allowed to import modules inside functions in Python too (there is a just a minor restriction), but I have never asked for this feature in D because this feature has a cost too. Putting all imports at the top of the module is more tidy, it allows the person that reads the code to find all the used imports very quickly. If they are spread in the module they become less easy to find, you need to use your editor/IDE to search for them. Bye, bearophile Why would you have to find local imports? It's considered good practice to narrow scope of variables and put declarations as close as possible to point of use, yet you don't hunt for local variable declarations all the time. If an import is local, it is simply (supposedly) only of concern to that scope and relevant when doing work concerning whatever is in that scope. In effect this could as well lead to reducing to need to look for imports! Python is a bit different because there's an awful lot more going on when importing, with increased chances of bugs when not careful. Simply importing something more than once can introduce errors. Hopefully, that is less so with D. The only really tricky thing are module constructors (circular imports). But at this level, it's probably easier to use facilities of dmd to tell you what imports what.
Re: Article discussing Go, could well be D
Caligo wrote: On Wed, Jun 8, 2011 at 6:06 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: That's it. We need a package management expert on board to either revive dsss or another similar project, or define a new package manager altogether. No yeah I have some code somewhere feel free to copy from it; we need professional execution. Then we need to make that tool part of the standard distribution such that library discovery, installation, and management is as easy as running a command. I'm putting this up for grabs. It's an important project of high impact. Wondering what you could do to help D? Take this to completion. Andrei Andrei, I have to respectfully disagree with you on that, sorry. D is supposed to be a system programming language, not some scripting language like Ruby. Besides, the idea of some kind of package management for a programming language is one of the worst ideas ever, specially when it's a system programming language. You have no idea how much pain and suffering it's going to cause the OS developers and package maintainers. I can see how the idea might be attractive to non-*nix users, but most other *nix OSs have some kind of package management system and searching for, installing, and managing software is as easy as running a command. For software libraries it is a different case imho, for the following reasons: - for most software development needs, not enough libraries get packaged by the major distro's - there's no way library authors are going to maintain packages of their libs for all the popular distro's with their incompatible systems - distro maintainers often package older versions, sometimes they are years behind - most, if not all native package management systems deal poorly with the need for having several versions of a library available. So there is still a need for tools like virtualenv. With dsss it's also trivial to setup multiple installations to manage version requirements - language specific package management can span across operating systems The net result is that languages which have package managers (python, ruby, haskell, perl and now also .net) have in fact far more and up to date libraries available than any distro will ever be able to manage.
Re: Flag proposal
Nick Sabalausky wrote: Nick Sabalausky a@a.a wrote in message news:istv62$2skn$1...@digitalmars.com... Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:isttf6$2oub$1...@digitalmars.com... On 6/10/11 1:52 PM, Robert Clipsham wrote: foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I agree it's more legible. The crucial question is whether the added legibility warrants adding a new feature to the language. I really see Flag more as a way to try to rationalize avoiding adding named parameters to the language. I don't, even though I like named parameters. boolean parameters for binary options are kind of an exception imho, because they decrease readability at the call site much more often than other types do. Somebody one this newsgroup - maybe it was Don Clugston, also made a good point against named parameters: it introduces inflexibility because now the names of the parameters of a function become part of the public api. Changing a name will now break client code. I'd still probably welcome named parameters though. And yes, the legibility of foo(Flag!param.yes, Flag!otherParam.no);, combined with the frequency of need for such a thing, and the complete inability of Flag to address the problem for anything but bool, the inability to document it separately (as Jonathan Davis pointed out), is all definitely much much more than enough to warrant adding a tried-and-proven feature that's become standard in damn near every other modern language. Regarding the complete inability of Flag to address the problem for anything but bool, how are we going to wind up papering over that? Like: box(Int!x(3), Int!y(4), Int!width(100), Int!height(150), Int!depth(1), UInt!color(0xFFAA77)); ?
Re: Flag proposal
Andrej Mitrovic wrote: On 6/10/11, Lutger Blijdestijn lutger.blijdest...@gmail.com wrote: Changing a name will now break client code. The flag template suffers from the same issue. Not strictly, but practically yes. It's also the point of them, exposing this name in the api. But its *only* for those parameters, which I understand are right now just 7 functions in the whole of phobos. With named parameters, the issue affects every function, including those already written without this dependency issue in mind.
Re: web development in D
joe wrote: I currently do most of my web development in PHP, with some work in Ruby with RoR. Right now I'm starting to think about building my own stack for web dev (I already use my own MVC framework and libs in PHP), but I'd really like to move to something faster and more powerful. Java or ASP.NET are two obvious choices, but I'm currently researching other alternatives (like D). So first I was wondering if there has been any web development using D, and if there are many (or any) libraries/frameworks/other resources already available for this? As mentioned Adam D. Ruppe has nice libs for web development, he managed to make a living out of it too so he must be doing something right :) There is one other web framework for D2 called serenity, I'm not sure how far it is but you can check it out here: https://github.com/mrmonday/serenity Perhaps this is unnecessary to mention, but would you choose ASP.NET, I'd recommend against webforms and look into ASP.NET mvc. If haven't used the latter myself but I didn't like webforms too much and heard good things about the mvc framework. Good luck!
Re: [OT] Re: There's new GIT instructions on Github now
Daniel Gibson wrote: Am 21.05.2011 01:34, schrieb Andrej Mitrovic: What's there to configuring visual studio? You just open a solution file and hit compile. If there are any dependencies you usually download the libs and put them in some subfolder. I don't have much experience with visual studio, but I've read that using a project from one version in another (newer) version may not always be painless, e.g. http://twitter.com/#!/ID_AA_Carmack/status/45616436995039232 Going from one version of a *solution* to the next usually just works. I expect tech5 to be somewhat more complex though. What usually doesn't work is going from one compiler version to the next, at least for C++. 'Managed' .Net is a different story. And how well do projects from a professional version work in the free (Visual Studio Express) version? That should work, the professional version is mostly about extra ide features, the basics and the toolchain is exactly the same. At least that's my experience. Now compare that to having to follow that gigantic tutorial for compiling GDC using msys. That's not really a fair comparison, GDC is very complex. There are also a lot of OSS projects which are much less arcane than what GNU usually does. Windows has it's share of complex build setups too, I believe the visual studio shell is such an example. I generally also find the boatloads of msbuild / nant xml scripts to be pretty incomprehensible when you need to work with them if something doesn't work.
Re: There's new GIT instructions on Github now
Andrej Mitrovic wrote: Also I'd add the first time I tried using GIT GUI a few months ago it froze and crashed when I tried to do a simple clone. I like git cola for gui. I has some nice features such as picking the lines from a file you want to stage for a commit. http://cola.tuxfamily.org/
Re: There's new GIT instructions on Github now
Andrej Mitrovic wrote: What the duck has happened to this topic? Ok anyway, I found out a few things: I can change $HOME by adding this line into C:\Program Files\Git\etc\profile file: HOME=/d/dev/git/ right *above* this line: HOME=$(cd $HOME ; pwd) This was from someone's blogs post. And then if I want to start git bash from a different initial directory I just change the git bash shortcut Start In field to whatever directory. Anyways I've made a bunch of commits to my forked repo of dpl.org, and now have to figure out how to make a pull request. I haven't made any branches or anything because I'm way too new to this. I would also like to know how to uncommit a change which hasn't been pushed yet. So if I locally do: git add someFile.d git commit -m woops wrong comment I recently starting using interactive rebasing which is a tremendous help for these kind of situations. This is usually what I do: start a branch for work on feature foo: git checkout -b foo * do a bunch of commits on foo * update master with newest changes: git checkout master git pull when foo is done, rebase it on top of master: git checkout foo git rebase -i master This will popup your editor and let you squash some commits together and edit the message. The text in your editor is fairly self-explanatory. It also 'replays' the commits on top of those from master you have pulled in *after* creating the foo branch. This helps with two things: you can resolve any conflicts inside the foo branch and prevents annoying merge commits. It will look in history like you have starting the foo branch from the latest commit from master. Sometimes this is not what you want, but most of the time it makes sense. From here you can either merge it with master (it will fast-forward) and push to github, or push the foo branch to a foo branch on github. Doing interactive rebasing like this allows you to organize the series of commits and messages *after* you are done developing something, resulting in very nice pull requests. There is one thing you should never do: rebase a branch which you have already pushed to some place other people can see / use / depend on. Then you are taking away the history on which people have build. It is to be used strictly with private branches. I use this workflow to work concurrently on lot's of different topics, each in a seperate branch. Without rebasing the history will be cluttered with merge commits. I also don't have to worry anymore about other people when I commit, since making nice messages and such is postponed to the point of a rebase. This makes life much more pleasant.
Re: [OT] Re: There's new GIT instructions on Github now
David Nadlinger wrote: On 5/21/11 1:09 PM, Lutger Blijdestijn wrote: And how well do projects from a professional version work in the free (Visual Studio Express) version? That should work, the professional version is mostly about extra ide features, the basics and the toolchain is exactly the same. I have encountered quite a few problems though. For example, 64 bit code generation used to be absent by default from Express versions (maybe it still is, haven't checked), which is a sensible marketing decision per se. However, it was implemented in such a way that I couldn't open a solution file from an open source project I was working on with my Express edition installation, just because it contained an x64 target… David ouch, that sucks. Wikipedia suggests this works now for 2010 though.
Re: There's new GIT instructions on Github now
Andrej Mitrovic wrote: Anywho, I'll start reading this http://progit.org/book/ to get the hang of things. That's a good book. I recommend to read closely chapter 3 and 9, goof around in a test repo and browse the .git/refs directory. Doing that made me understand how simple the core of git really is and then a lot of commands suddenly made much more sense.
Re: Cannot interpret struct at compile time
Robert Clipsham wrote:
Hey all,
I was wondering if anyone could enlighten me as to why the following
code does not compile (dmd2, latest release or the beta):
struct Foo
{
int a;
}
string test()
{
string str = struct ~ Foo.stringof ~ _{;
foreach (j, f; Foo.tupleof)
{
enum fullFieldName = Foo.tupleof[j].stringof;
str ~= typeof(f).stringof ~ ' ' ~
fullFieldName[Foo.stringof.length + 3 .. $];
}
return str ~ };
}
void main()
{
mixin(test());
}
If fails with the errors:
test.d(9): Error: Cannot interpret Foo at compile time
test.d(19): Error: cannot evaluate test() at compile time
test.d(19): Error: argument to mixin must be a string, not (test())
test.d(19): Error: cannot evaluate test() at compile time
test.d(19): Error: argument to mixin must be a string, not (test())
Thanks,
test also doesn't compile normally on my box, dmd errors on Foo.tupleof. Not
sure if this is illegal or not. I think you want the allMembers trait or
something similar. Something like this:
import std.traits;
string test(T)()
{
string str = struct ~ T.stringof ~ _{;
alias FieldTypeTuple!T FieldTypes;
foreach (i, fieldName; __traits(allMembers, T ) )
{
str ~= FieldTypes[i].stringof ~ ~ fieldName ~ ;;
}
return str ~ };
}
This works for your example but is a bit crude, I'm sorry for that, you'll
have to modify it. ( allMembers also returns functions, including ctors
while FieldTypeTuple doesn't. I also haven't read anything about the order
in which FieldTypeTuple and allMembers return their elements )
Re: Patterns of Human Error - my presentation at the DC ACM
Nice slides, very simple and elegant. This reminds me of when I started with D. I found a lot of these 'details' unload quite some burden I had with C++ and made programming that much more enjoyable.
Re: Context sensitivity
bearophile wrote:
I was away.
This is D code adapted from a blog post about C language:
http://eli.thegreenplace.net/2011/05/02/the-context-sensitivity-of-
c%E2%80%99s-grammar-revisited/
http://www.reddit.com/r/programming/comments/h23h3/the_context_sensitivity_of_cs_grammar_revisited/
Three little D2 programs that compile with no errors. Similar code is
allowed in C too:
//
alias int Foo;
void foo() {
Foo bar;
float Foo;
}
void main() {}
//
alias int Foo;
void foo() {
Foo Foo;
int bar = Foo + 2;
assert (bar == 2);
}
void main() {}
//
alias char Foo;
void foo() {
int bar = Foo.sizeof, Foo, spam = Foo.sizeof;
assert(bar == 1);
assert(spam == 4);
}
void main() {}
//
Note: currently I have put nothing about this in Bugzilla.
My question is: is it OK to keep allowing such kind of code in D2 too? Or
is it better to statically forbid it?
A disadvantage of statically disallowing it is the breakage of some valid
C code. On the other hand I don't think I want to find code like that in D
programs.
Bye,
bearophile
That's surprising, I didn't know it. I agree it should be statically
forbidden, which does not violate the principles wrt C compatibility because
it doesn't silently change semantics.
Tt also interacts with templates because they can pick up the redefined
name. Not sure if it's really a problem, it would be interesting to think of
a situation where this can occur in practice. Maybe with lots of templates,
ctfe and mixins it can became non-obvious? It sure as hell would be
confusing to run into such a bug.
Re: Ceylon language
Nick Sabalausky wrote:
spir denis.s...@gmail.com wrote in message
news:mailman.3497.1302788057.4748.digitalmar...@puremagic.com...
On 04/13/2011 02:34 PM, bearophile wrote:
If a value of type T can be null, it must be declared as type
OptionalT, which may be abbreviated to T?
String? name = process.args.first;
if (exists name) {
writeLine(Hello name !);
}
else {
writeLine(Hello World!);
}
Use of an optional value must be guarded by the if (exists ... )
construct. Therefore, NullPointerExceptions are impossible.
This is exactly what I suggested for D in a enhancement request.
It seems this kind of stuff is becoming a standard in new languages.
+++
But I guess optionality could, and should, extend to non-ref types; thus,
null is just a particular case of non-existence. And this would apply
especially on function parameters:
void f (int i?) {...}
Oh absolutely. Haxe has nullable-primatives which really comes in handly
at times (it often prevents the need for a separate bool to keep track
of). Only problem is that in Haxe, not only is nullable the default, but
it doesn't even *have* any non-nullables at all, for any type.
I don't get the diff between currying partial app. And find this
feature much complication for close to uselessness.
I'm not certain either, but I *think* partial application is just like
currying except there's some sort of arbitrary limitaion on what
combination(s) of paramaters you can choose to specify or not specify. And
that limitation is based purely on what order the function defines its
parameters. So basically, my understanding is that partial application is
an arbitrarily-gimped currying.
partial application is getting a new function out of an existing one where
one of the arguments is fixed / bound. More or less what std.functional
curry does, confusingly.
currying however doesn't involve specifying parameters at all, it means to
get a function with one parameter out of a function with more than one
parameter. This new function returns a function with one parameter, and so
on and so forth until there is nothing left to curry. An example is clearer:
int foo(int a, int b, int c) {
return a + b + c;
}
auto curriedFoo(int a) {
return (int b) {
return (int c) {
return foo(a, b, c);
};
};
}
assert( curriedFoo(1)(2)(3) == 6 );
Whereas partial application could be something like:
auto partialApply(F)(int x, F fun) {
return (ParameterTypeTuple!(F)[1..$] args) {
return fun(x, args);
};
}
assert( partialApply(1, foo)(2,3) == 6);
Re: traits and class protection
Adam D. Ruppe wrote: Is there a way in today's D to exclude members marked private and protected from processing in the __traits(allMembers) family of functions? I thought if I at least put it in a separate module, trying to get a private member would fail to compile, but I tried it and it seems to work anyway... my private members are both showing up and being called from another module. I'm open to filthy hacks too. Worst case is I can use a naming convention but I'd really like the public keyword to be the thing that actually matters. Maybe some variation on the pimple idiom with opDispatch could work? It may be more trouble than its worth though. Most reflection mechanisms allow you to look at private symbols. This is probably not helpful to you, but whatever code that uses allMembers should just not do that and filter out private/protected members.
Re: Linux: How to statically link against system libs?
Alexander wrote: On 29.04.2011 11:41, Spacen Jasset wrote: You still *cannot* link statically to kernel32.dll. That's the difference. Linux glibc contains the C library functions *and* the syscalls, which is the bit that causes the problems. But at least I know, that no matter where I am, as long as I am using kernel32 only (no more dependencies), it will work on *any* Windows system (obviously, keeping backward compatibility in mind - something compiled on WinXP will work on all later versions) - which is not he case of Linux/glibc, unfortunately. msvcrt.dll and msvcrt.lib don't have any syscalls in them. they call though kernel32.dll dynamically. Actually, they do. Calling kernel32 is like making a syscall, that's the base of Win32 API, which is equivalent of Linux syscall. A syscall is generally understood to be a call into the kernel for doing something that can't be done with user level privileges. So a call is either a syscall or it isn't, and none of kernel32 are. There are even functions in kernel32 which do not make a syscall.
Re: GUI library for D
Nick Sabalausky wrote: Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.3178.1301970383.4748.digitalmar...@puremagic.com... On 4/5/11, Nick Sabalausky a@a.a wrote: After all, I *really* want to get around to making my own web browser (based off either Mozilla or Chromium) - I'm getting really fed up with the current state of available web browsers. Well, and the web as a whole (god I fucking hate the web), but one step at a time, I guess). I'll be the first to install it. Btw, there's a full web browser example in the QtD sources. But it has to be ported to D2. And then you have to deal with any eventual bugs along the way. :] Ha! I may not need to do much after all: I was just looking through Wikipedia's giant list of browsers, found a few that looked potentially promising, tried them all and...well, was mostly disappointed. But the *last* one I had left to try I've been really impressed with so far: Arora (Qt/WebKit) http://code.google.com/p/arora/ I've only tried it breifly, but the UI is *actually nice*! Only modern browser out there with a UI that isn't absolutely horrid. I didn't even see *one* instance of invisible-text on my light-on-dark system, which is unbeleivavly rare among all software these days. And it has a lot of essential stuff built in, like ad blocking, disableable JS, and a ClickToFlash which I haven't tried out yet. There's still a few things it seems like it might be missing, like equivalents to NoScript, BetterPrivacy and maybe DownloadHelper and DownThemAll, but most of those are less important to me, and even as it is right now it's a damn good start. Maybe I could add some of that remaining stuff, or heck, maybe even port the whole thing to D ;) Even it it would involve looking at C++ code? Did you know Arora *is* the Qt webbrowser example that got out of control and became a real browser? (it uses webkit) iirc QtD has a sizeable chunk of that example already ported to D.
Re: Is the world coming to an end?
spir wrote: On 04/03/2011 02:52 AM, bearophile wrote: Michel Fortin: The new syntax is certainly usable, it's just inelegant and hackish. Its your language, it's your choice, and I'll admit it won't affect me much. My suggestions for Walter are: - To turn 01 .. 07 too into errors; - to deprecate the octal! Phobos template. - To introduce the 0o leading that works from 0o0 to the uint.max; - To change the new error message, so it suggests to use 0o. - To ask opinions to the community here next time before changing things in D2/D3 :-) I'm very surprised of this move -- aside the concrete details. What I point out here is how far sentiments about what is obvious or correct can be, for a given issue, that most of us considered wrong for the same reason. When I introduced the topic of octal notation 0nnn beeing bad, I was 100% sure that (if a move was ever made) either octals would be thrown out of D all together for beeing nearly useless, or the syntax would be fixed -- the obvious correct solution if octals remain. While I new about octal!, this was so hackish and obviously wrong *for me*, that I did not even imagine one second it could become the official solution. I'm certainly not the only one. Questions of detail, sure, but we all know what the details hide ;-) Denis I don't understand why it is hackish if it's a pure library approach. (it is right?) I find it actually rather nice that D can do this. This is not a syntax change, octals are out of the language and the library now has an octal template. Where's the problem?
Re: Complete D grammar
Nick Sabalausky wrote: ... 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? Not sure if this is what you meant, but Jascha Wetzel had made a D grammar used by seatd / APaGeD: http://seatd.mainia.de/grammar.html
Re: constexpr and CTFE
bearophile wrote: This first question is mostly for D.learn, but below I show a partially related link too, so I put both of them here. If you have library code, and the users of your library run one of your functions at compile time, later if you change your function it may not run at compile time any more. So isn't the quality of being able to run at compile time part of the signature of the function? An attribute similar to pure that can be checked by the compiler might be useful. However, the signature affects the type right? I'm not sure that is the intent of ctfe. A simple ddoc annotation and a unittest is probably enough to both ensure and convey the ctfe-ability. --- GCC 4.6 implements the C++0x constexpr. I've found a note about constexpr, that touches the topic of logic const too, purity, memoization: http://stackoverflow.com/questions/4748083/when-should-you-use-constexpr- capability-in-c0x/4750253#4750253 Bye, bearophile
Re: GSoC-2011 project:: Containers
Ishan Thilina wrote: As to my understanding algorithms are seperated from the containers so that the code is maintainable. But in std.container I can see that all the algorithms are in the container method definitions. Why is this? Have I got the things incorrectly? Slightly, D ranges use the same basic principles as the STL so any documentation on that can be used to understand the big picture. You'll see that no container implements all of std.algorithm, in fact containers have a very small interface. Normally algorithms work with different kinds of ranges and containers can provide one or more ranges, thus achieving very loose coupling and reuse. If a container provides a certain range then *all* algorithms which operate on that kind of range will work with the container. For example, any container that can be accessed with a random access range can be used by std.sort. However, containers usually have more to offer than what can be expressed by ranges. std.container documents a large set of methods that particular containers can implement as they see fit, as a convention. These methods are usually specific to a particular container implementation and necessary to use a container or take advantage of it's specific properties.
Re: Sample source code for D
Ishan Thilina wrote: I am a novice to D. Is there any place that I can get sample source codes for D ? Thanks...! examples from TDPL: http://erdani.com/tdpl/code/ You could browse github and dsource. Some blogposts also contain examples, see http://planet.dsource.org/
Re: GSoC-2011 project:: Containers
Ishan Thilina wrote: @ steve Johannes: Yeah, it works for me now :). I informed the site owners about this and he has rectified it :) @Denis: You are right, indeed. To say it shortly, ranges are D's version of iterators or generators, especially powerful and general. With its own set of issues (somewhat complicated, rather opaque types, various bugs remaining), but globally extremely useful and usable. Most of Phobos2 (the std lib) builds on ranges; this applies even more to collections: if you wish to implement new collections for D, it is certainly required that they hold range factories for iteration. Sometimes, more than one (eg tree traversal breadth-first vs depth-first, leaves only...). 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. Use the D learn mailing list to ask people for help in understanding D's more advanced features and issues. Denis -- Thank you very much for that helpful answer. The biggest challenge now i have is to find good resources to learn about ranges. Any suggestions ? Boostcon 2009 talk 'iterators must go' also recommended: http://blip.tv/file/2432106 The docs and sourcecode of std.range and std.algorithm is most relevant though, and this newsgroup or .learn for discussion and questions. I'll look at the dcollections. I didn't know such a thing existed. It will be a great help for me :).
Re: a cabal for D ?
Russel Winder wrote: On Thu, 2011-03-17 at 20:44 +, Jason E. Aten wrote: Please correct me if I'm wrong, but I observe that there doesn't appear to be a package management system / standard repository for D libraries. Or is there? I'm talking about something as easy to use as R's CRAN, install.packages(rforest) or cpan for perl, ctan for latex, dpgk/apt for debian, cabal for Haskell/ Hackage, etc. Note that every language-specific package manager conflicts directly with every operating system package manager. Thus RubyGems, CPAN, Cabal, Maven, Go, etc. conflicts with the package management of Debian, Fedora, SUSE, FreeBSD, MacPorts, etc. leading to pain. Pain leads to anger. Anger leads to hate. Hate leads to suffering. If there's not a commonly utilized one currently, perhaps we could borrow cabal, with a trivial port. cabal is Haskell's package manager. Not only does having a standard package install system facilitate adoption, it greatly facilitates code sharing and library maturation. At the expense of easy system administration. Not necessarily, fedora has rpm packages of gems for example. I guess the only up side of language specific package management is that it enables people whose operating systems are not package structured to do things sensibly. Alternatively Windows users could switch to a sensible operating system ;-) It's also often easier to package libraries with system specifically designed to do so for a particular language. That, combined with a common repository, usually results in a much wider selection of apis than a native distribution offers.
Re: a cabal for D ?
Jason E. Aten wrote: Please correct me if I'm wrong, but I observe that there doesn't appear to be a package management system / standard repository for D libraries. Or is there? I'm talking about something as easy to use as R's CRAN, install.packages(rforest) or cpan for perl, ctan for latex, dpgk/apt for debian, cabal for Haskell/ Hackage, etc. If there's not a commonly utilized one currently, perhaps we could borrow cabal, with a trivial port. cabal is Haskell's package manager. Not only does having a standard package install system facilitate adoption, it greatly facilitates code sharing and library maturation. There used to be one called dsss (d shared software system). It was widely used, I think some D1 libraries still use it but it hasn't been maintained for years.
Re: Curl support RFC
Jonas Drewsen wrote:
On 11/03/11 22.21, Jesse Phillips wrote:
I'll make some comments on the API. Do we have to choose Http/Ftp...? The
URI already contains this, I could see being able to specifically request
one or the other for performance or so www.google.com works.
That is a good question.
The problem with creating a grand unified Curl class that does it all is
that each protocol supports different things ie. http supports cookie
handling and http redirection, ftp supports passive/active mode and dir
listings and so on.
I think it would confuse the user of the API if e.g. he were allowed to
set cookies on his ftp request.
The protocols supported (Http, Ftp,... classes) do have a base class
Protocol that implements common things like timouts etc.
And what about properties? They tend to be very nice instead of set
methods. examples below.
Actually I thought off this and went the usual C++ way of _not_ using
public properties but use accessor methods. Is public properties
accepted as the D way and if so what about the usual reasons about why
you should use accessor methods (like encapsulation and tolerance to
future changes to the API)?
I do like the shorter onHeader/onContent much better though :)
/Jonas
Properties *are* accessor methods, with some sugar. In fact you already have
used them, try it:
http.setReceiveHeaderCallback = (string key, string value) {
writeln(key ~ : ~ value);
};
Marking a function with @property just signals it's intended use, in which
case it's nicer to grop the get/set prefixes. Supposedly using parenthesis
with such declarations will be outlawed in the future, but I don't think
that's the case currently.
Jonas Drewsen Wrote:
//
// Simple HTTP GET with sane defaults
// provides the .content, .headers and .status
//
writeln( Http.get(http://www.google.com;).content );
//
// GET with custom data receiver delegates
//
Http http = new Http(http://www.google.dk;);
http.setReceiveHeaderCallback( (string key, string value) {
writeln(key ~ : ~ value);
} );
http.setReceiveCallback( (string data) { /* drop */ } );
http.perform;
http.onHeader = (string key, string value) {...};
http.onContent = (string data) { ... };
http.perform();
Re: Curl support RFC
dsimcha wrote: I don't know much about this kind of stuff except that I use it for very simple use cases occasionally. One thing I'll definitely give your design credit for, based on your examples, is making simple things simple. I don't know how it scales to more complex use cases (not saying it doesn't, just that I'm not qualified to evaluate that), but I definitely would use this. Nice work. BTW, what is the license status of libcurl? According to Wikipedia it's MIT licensed. Where does that leave us with regard to the binary attribution issue? Walter contacted the author, it's not a problem: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=112832
Re: Proposal for std.path replacement
Jonathan M Davis wrote: On Sunday 06 March 2011 22:51:55 Christopher Nicholson-Sauls wrote: On 03/07/11 00:24, Jonathan M Davis wrote: On Sunday 06 March 2011 22:09:22 Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2280.1299459971.4748.digitalmar...@puremagic.com... This reminds me. I should look into mime types one of these days to see what the appropriate way (if any) would be to put support for them in Phobos. It would be nice to not have to go by extension for the few programs that I have which have to worry about file type. I'm no unix expert, but my understanding is that mime types in the filesystem don't even exist at all, and that what it *really* does is use some complex black-box-ish algorithm that takes into account the first few bytes of the file, the extention, the exec flag, and god-knows-what-else to determine what type of file it is. Contrary to how people keep making it sound, mime type is *not* the determining factor (and cannot possibly be), but rather nothing more than the way the *result* of all that analysis is represented. I thought that the first few bytes of the file _were_ the mime type. Certainly, from what I've seen, extension has _no_ effect on most programs. Konqueror certainly acts like it does everything by mime type - file associations are set that way. - Jonathan M Davis As someone who uses hex editors quite a bit (resorting these days to using Okteta mainly), I can tell you I have yet to see any file's mime embedded at the beginning, nor have I seen it in any headers/nodes when scanning raw. Doesn't mean it's impossible of course, and certain file systems certainly might do this[1] but I haven't seen it yet[2]. You are quite right, though, that extension doesn't matter at all, except in certain corner cases. Even then, they are reasonable and predictable things -- like SO's having the right extension. Considering the posix convention of hiding files/directories by starting the name with a dot, it'd be hard to rely on extensions in any naive way anyhow. ;) -- Chris N-S [1] I'd just about expect the filesystem of BeOS/Haiku to do so, or something similar to it at least. [2] Also not saying I wouldn't want to see it, necessarily. Done right, it'd be a damn nifty thing. I've never studied mime types, so I don't know much about them. It's just that it was my understanding the the first few bytes in a file indicated its mime type. If that isn't the case, I have no idea how you determine the mime type of a file or what's involved in doing so. I _would_, however, like to have a way to get a file's mime type in D, so one of these days, I'll likely be looking into the matter. - Jonathan M Davis A good place to start is likely freedesktop.org, which maintains specifications, libraries and utilities aimed at enhancing interoperability between desktop systems. This is the page about mime types: http://freedesktop.org/wiki/Specifications/shared-mime-info-spec
Re: We need to rethink remove in std.container
Jonathan M Davis wrote: Okay, removing elements from a container sucks right now. You can do stuff like removeAny (generally pretty useless IMHO) or removeFront just fine, but removing an arbitrary range from a container just plain sucks. remove takes a range type which is the range type for the container that it's on. That makes sense. It's obviously not going to be able to a take an arbitrary range and remove that from itself. How would it know which elements in that range corresponded to which elements in itself - especially when it could be a range which skips elements or something similar? So, _that_ part makes sense. I don't understand why not. Given, as you said, that a lot of functions return a new type it would make sense. My answer as to how would be something like: while range not empty container.remove range.front range.popFront Is there a problem with that? But have you actually tried to get a range of the appropriate type to remove from a container? It seems like almost ever function in std.range and std.algorithm returns a new range type, making them completely useless for processing a range to be removed from a container. I was looking to remove a single element for a RedBlackTree. The best function that I could think to get the proper range was findSplit. The middle portion of the return value would be the portion that I was looking for. I'd take that and pass it to RedBlackTree's remove. Wrong. It uses takeExactly in its implementation and the first two portions of the result of findSplit aren't the right range type. So, what do I do? The _only_ thing that I can think of at the moment is to use find to locate the beginning of the range that I want, take the length of the range with walkLength and then use popBackN to pop of the elements I don't want. e.g. The table in the docs mention stableRemoveAny(v) which says Same as c.removeAny(v), but is guaranteed to not invalidate any iterators. Though c.removeAny(v) itself is not listed in the table nor implemented in RedBlackTree, isn't this the right function for the job? (I take it v stands for a value of the container, rather than a range). builtin aa's also implement this function.
Re: We need to rethink remove in std.container
Jonathan M Davis wrote: On Tuesday 22 February 2011 01:04:48 Lutger Blijdestijn wrote: Jonathan M Davis wrote: Okay, removing elements from a container sucks right now. You can do stuff like removeAny (generally pretty useless IMHO) or removeFront just fine, but removing an arbitrary range from a container just plain sucks. remove takes a range type which is the range type for the container that it's on. That makes sense. It's obviously not going to be able to a take an arbitrary range and remove that from itself. How would it know which elements in that range corresponded to which elements in itself - especially when it could be a range which skips elements or something similar? So, _that_ part makes sense. I don't understand why not. Given, as you said, that a lot of functions return a new type it would make sense. My answer as to how would be something like: while range not empty container.remove range.front range.popFront Is there a problem with that? It's horribly inefficient for one. Also, I'm not sure that the range is valid any more after the remove, since it's front was removed. popFront may not work correctly. It's a matter of range (in)validation right? I admit at this point I'm not sure how it is supposed to work. remove + popFront is a bad idea if the range is a view into the contained from where stuff is removed, but in c++ this works for map: some_map.erase(i++) where i is an iterator. So it depends on the type of container what is supported I think. But perhaps this falls under Walter's category of useless wankery, since it is easy to write yourself. But have you actually tried to get a range of the appropriate type to remove from a container? It seems like almost ever function in std.range and std.algorithm returns a new range type, making them completely useless for processing a range to be removed from a container. I was looking to remove a single element for a RedBlackTree. The best function that I could think to get the proper range was findSplit. The middle portion of the return value would be the portion that I was looking for. I'd take that and pass it to RedBlackTree's remove. Wrong. It uses takeExactly in its implementation and the first two portions of the result of findSplit aren't the right range type. So, what do I do? The _only_ thing that I can think of at the moment is to use find to locate the beginning of the range that I want, take the length of the range with walkLength and then use popBackN to pop of the elements I don't want. e.g. The table in the docs mention stableRemoveAny(v) which says Same as c.removeAny(v), but is guaranteed to not invalidate any iterators. Though c.removeAny(v) itself is not listed in the table nor implemented in RedBlackTree, isn't this the right function for the job? (I take it v stands for a value of the container, rather than a range). builtin aa's also implement this function. removeAny doesn't solve the problem. For starters, the table appears to be wrong in that stableRemoveAny takes a value and removeAny doesn't. So, either stableRemoveAny is supposed to not take a value or there's supposed to be another version of removeAny which takes a value, and it's missing. So, I don't know what exactly is intended with stableRemoveAny. Regardless of that, however, remove still needs to work. It's perfectly valid to want to remove a range of elements rather than just one. - Jonathan M Davis (stable)removeAny does not solve the problem of removing ranges, but there must be *something* that solves the problem of removing one element. You found one way to do it for RedBlackTree (i gave up), but if I am not mistaken it doesn't have the right complexity and efficient removal is a key property of this container.
Re: Ranges and Algorithms -- Templates, Delegates, or Ranges?
Mafi wrote:
Am 22.02.2011 11:29, schrieb %u:
Having learned functional programming in Scheme a couple months ago, I
tried my hand at using map(), reduce(), and filter() in D:
int addend = 5;
map(delegate int(int x) { return x + addend; }, iota(1, 5));
but it didn't work. It turned out that map() actually took the mapper as
its _template_ argument, not as a function argument. Not too much of a
problem, it probably seemed to be... except that it's a critical problem.
It makes map(), reduce(), filter(), etc. to become 10x less useful,
because there's no way to change their behavior at runtime, depending on
program's state.
I did never try and so I'm unsure but shouldn't you be able to give a
delegate variable as template parameter.
std.algorithms.map's parameter is an alias parameter so it should be
able alias your variable and use it's runtime value.
If it does not work this way it's a bug IMO.
Mafi
yes it works: map!((int x) { return x + addend; })(iota(1, 5));
It's called local template instantiation iirc, and is restricted to global
templates (which map is).
Re: We need to rethink remove in std.container
Jonathan M Davis wrote: On Tuesday 22 February 2011 03:52:34 Lutger Blijdestijn wrote: Jonathan M Davis wrote: On Tuesday 22 February 2011 01:04:48 Lutger Blijdestijn wrote: Jonathan M Davis wrote: Okay, removing elements from a container sucks right now. You can do stuff like removeAny (generally pretty useless IMHO) or removeFront just fine, but removing an arbitrary range from a container just plain sucks. remove takes a range type which is the range type for the container that it's on. That makes sense. It's obviously not going to be able to a take an arbitrary range and remove that from itself. How would it know which elements in that range corresponded to which elements in itself - especially when it could be a range which skips elements or something similar? So, _that_ part makes sense. I don't understand why not. Given, as you said, that a lot of functions return a new type it would make sense. My answer as to how would be something like: while range not empty container.remove range.front range.popFront Is there a problem with that? It's horribly inefficient for one. Also, I'm not sure that the range is valid any more after the remove, since it's front was removed. popFront may not work correctly. It's a matter of range (in)validation right? I admit at this point I'm not sure how it is supposed to work. remove + popFront is a bad idea if the range is a view into the contained from where stuff is removed, but in c++ this works for map: some_map.erase(i++) where i is an iterator. So it depends on the type of container what is supported I think. But perhaps this falls under Walter's category of useless wankery, since it is easy to write yourself. It depends on the implementation. It's possible that iterating an iterator or popping the front of a range where that iterator no longer points to a valid element actually works. It's also possible that, because it no longer points to a valid element, it _doesn't_ work. It wouldn't surprise me at all that some_map.erase(i++) isn't guaranteed to work in C++ at all but that you've just gotten lucky with the STL implementation that you've been using. I'd have to research it to be sure. But my guess would be that you've been lucky. I'm fairly certain this is guaranteed, but specifically tied to std::map. The iterator returns the old value and is incremented before erasure, which doesn't invalidate iterators except the one that got removed. But have you actually tried to get a range of the appropriate type to remove from a container? It seems like almost ever function in std.range and std.algorithm returns a new range type, making them completely useless for processing a range to be removed from a container. I was looking to remove a single element for a RedBlackTree. The best function that I could think to get the proper range was findSplit. The middle portion of the return value would be the portion that I was looking for. I'd take that and pass it to RedBlackTree's remove. Wrong. It uses takeExactly in its implementation and the first two portions of the result of findSplit aren't the right range type. So, what do I do? The _only_ thing that I can think of at the moment is to use find to locate the beginning of the range that I want, take the length of the range with walkLength and then use popBackN to pop of the elements I don't want. e.g. The table in the docs mention stableRemoveAny(v) which says Same as c.removeAny(v), but is guaranteed to not invalidate any iterators. Though c.removeAny(v) itself is not listed in the table nor implemented in RedBlackTree, isn't this the right function for the job? (I take it v stands for a value of the container, rather than a range). builtin aa's also implement this function. removeAny doesn't solve the problem. For starters, the table appears to be wrong in that stableRemoveAny takes a value and removeAny doesn't. So, either stableRemoveAny is supposed to not take a value or there's supposed to be another version of removeAny which takes a value, and it's missing. So, I don't know what exactly is intended with stableRemoveAny. Regardless of that, however, remove still needs to work. It's perfectly valid to want to remove a range of elements rather than just one. - Jonathan M Davis (stable)removeAny does not solve the problem of removing ranges, but there must be *something* that solves the problem of removing one element. You found one way to do it for RedBlackTree (i gave up), but if I am not mistaken it doesn't have the right complexity and efficient removal is a key property of this container. If you could just do take or takeExactly on the range you got from find and pass it to remove, then it wouldn't matter whether you wanted to remove 1 element or many. The only difference is the number passed
Re: We need to rethink remove in std.container
Andrei Alexandrescu wrote: On 2/22/11 3:04 AM, Lutger Blijdestijn wrote: The table in the docs mention stableRemoveAny(v) which says Same as c.removeAny(v), but is guaranteed to not invalidate any iterators. Though c.removeAny(v) itself is not listed in the table nor implemented in RedBlackTree, isn't this the right function for the job? (I take it v stands for a value of the container, rather than a range). builtin aa's also implement this function. I don't think removeAny() works for his case because he wants to remove a specific element from a container. removeAny() is useful when you want to express pick one element from that container in the easiest way possible. Andrei I was looking for remove(ElementType value) but this function is not listed anywhere in std.container. The entry for stableRemoveAny(v) references removeAny(v) - note the parameter - so I thought that indicated the intent of a function removeAny(ElementType) but it doesn't exist in the table either. I assumed (mistakenly) that removeAny(v) would remove any value x where x == v from the container, where the choice of which would be left up to the container.
Re: We need to rethink remove in std.container
Steven Schveighoffer wrote: On Mon, 21 Feb 2011 21:55:20 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: Okay, removing elements from a container sucks right now. You can do stuff like removeAny (generally pretty useless IMHO) or removeFront just fine, but removing an arbitrary range from a container just plain sucks. remove takes a range type which is the range type for the container that it's on. That makes sense. It's obviously not going to be able to a take an arbitrary range and remove that from itself. How would it know which elements in that range corresponded to which elements in itself - especially when it could be a range which skips elements or something similar? So, _that_ part makes sense. But have you actually tried to get a range of the appropriate type to remove from a container? It seems like almost ever function in std.range and std.algorithm returns a new range type, making them completely useless for processing a range to be removed from a container. I was looking to remove a single element for a RedBlackTree. The best function that I could think to get the proper range was findSplit. The middle portion of the return value would be the portion that I was looking for. I'd take that and pass it to RedBlackTree's remove. Wrong. It uses takeExactly in its implementation and the first two portions of the result of findSplit aren't the right range type. RedBlackTree supports the equalRange function, which gives you a range of elements equal to the value you give. oo how I missed that. When you are working on RedBlackTree, would you please consider putting an example in the doc that uses it to this effect?
Re: using a binary tree container
Sorry I almost forgot: http://d.puremagic.com/issues/show_bug.cgi?id=5640 The issue with remove is talked about in digitalmars.D and perhaps not really specific to RedBlackTree.
Re: Can I parametrize template mixin's identifiers?
Nick wrote:
I know I can parametrize template mixin types, but how about mixin
identifiers? This is the code:
mixin template Box(T) {
T val;
}
class Set(A, B) {
mixin Box!A a;
mixin Box!B b;
}
alias Set!(int, int) IntSet;
int main(string[] argv) {
scope auto s = new IntSet();
s.a.val = 3;
}
As you can see, the A and B types can be changed and with them the boxed
values. But they need disambiguation, since they have identically named
members. I know only to hard-code that disambiguation.
I need this because I intend to change (A, B) with a type list
eventually and I need to make operations on the boxed types independent
on the template mixin identifiers (a, b).
This pattern comes from C++ code, where Box(T) would be classes, Set (A,
B, ...) would recursively apply multiple inheritance on the type list.
Then each Box members could be addressed by casting to the correct Box(T).
Any idea if this is possible in D?
Thanks!
Possible yes, but probably not so pretty. There must be some places in
phobos where something like this is done (better), perhaps in the code for
tuples in std.typecons. Here is my unpolished attempt:
mixin template Box(T)
{
T val;
}
mixin template MixinFields(P...)
{
/* P[0] is the template to use as mixin
* P[1] is the type to be use as parameter for P[0]
* P[2] is the symbol name the mixin will be aliased to
*/
mixin(mixin ~ __traits(identifier, P[0]) ~ !( ~ P[1].stringof ~ )
~ P[2] ~ ;);
static if(P.length 3)
mixin MixinFields!(P[0], P[3..$]);
}
class Set(T...)
{
mixin MixinFields!(Box, T);
}
alias Set!(int, a, int, b) IntSet;
void main()
{
scope auto s = new IntSet();
s.a.val = 3;
}
Re: tooling quality and some random rant
retard wrote: Mon, 14 Feb 2011 20:10:47 +0100, Lutger Blijdestijn wrote: retard wrote: Mon, 14 Feb 2011 04:44:43 +0200, so wrote: Unfortunately DMC is always out of the question because the performance is 10-20 (years) behind competition, fast compilation won't help it. Can you please give a few links on this? What kind of proof you need then? Just take some existing piece of code with high performance requirements and compile it with dmc. You lose. http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html http://permalink.gmane.org/gmane.comp.lang.c++.perfometer/37 http://lists.boost.org/boost-testing/2005/06/1520.php http://www.digitalmars.com/d/archives/c++/chat/66.html http://www.drdobbs.com/cpp/184405450 That is ridiculous, have you even bothered to read your own links? In some of them dmc wins, others the differences are minimal and for all of them dmc is king in compilation times. DMC doesn't clearly win in any of the tests and these are merely some naive examples I found by doing 5 minutes of googling. Seriously, take a closer look - the gcc version is over 5 years old. Nobody even bothers doing dmc benchmarks anymore, dmc is so out of the league. I repeat, this was about performance of the generated binaries, not compile times. Like I said: take some existing piece of code with high performance requirements and compile it with dmc. You lose. I honestly don't get what I need to prove here. Since you have no clue, presumably you aren't even using dmc and won't be considering it. You go on ranting about dmc as if it is dwarfed by other compilers (which it might very well be), then provide 'proof' that doesn't prove this at all and now I must be convinced that it's because the other compilers are so old? You lose. You don't have to prove anything, but when you do, don't do it with dubious and inconclusive benchmarks. That's all.
Re: ref const(T) the same as C++'s const T?
Jonathan M Davis wrote: ... Personally, it wouldn't hurt my feelings any to have const ref take temporaries. I do not understand why it's a problem. But Andrei insists that it is. Presumably Walter agrees, but I don't know. They could very well be right and that it's overall better _not_ to have const ref take temporaries, but it _is_ annoying. Since I don't understand what the real problem with not knowing whether const ref is actually referring to an lvalue or rvalue is, I can't really judge whether they're right or wrong. However, Andrei is certain that it's on of C++'s biggest mistakes. Regardless, the general push has been that structs be cheap to copy, and I would argue that if you're structs _aren't_ relatively cheap to copy, you should at least consider rethinking your design. Sometimes COW or ref semantics will probably be required though. There may be a way to solve this problem reasonably and still have const ref require lvalues, but for the moment, we have to deal with it. - Jonathan M Davis For reference, here is a link to the thread discussing it: http://www.mail- archive.com/digitalmars-d@puremagic.com/msg44075.html If I understood that discussion correctly, 'auto ref' is supposed to solve the rvalue references problem but are not completely implemented yet.
Re: Integer conversions too pedantic in 64-bit
Nick Sabalausky wrote: Nick Sabalausky a@a.a wrote in message news:ijesem$brd$1...@digitalmars.com... Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vqx78nkceav7ka@steve-laptop... size_t works, it has a precedent, it's already *there*, just use it, or alias it if you don't like it. One could make much the same argument about the whole of C++. It works, it has a precedent, it's already *there*, just use it. The whole reason I came to D was because, at the time, D was more interested in fixing C++'s idiocy than just merely aping C++ as the theme seems to be now. I don't see any difference, D has always kept a strong link to it's C++ heritage. It's just a matter of what you define as idiocy.
Re: ref const(T) the same as C++'s const T?
Peter Alexander wrote: On 15/02/11 10:47 PM, Lutger Blijdestijn wrote: For reference, here is a link to the thread discussing it: http://www.mail- archive.com/digitalmars-d@puremagic.com/msg44075.html If I understood that discussion correctly, 'auto ref' is supposed to solve the rvalue references problem but are not completely implemented yet. Thanks Lutger. From the thread, it seems like the correct annotation would be 'auto ref const T', would it not? Yes, I think so.
Re: tooling quality and some random rant
Walter Bright wrote: Michel Fortin wrote: But note I was replying to your reply to Denis who asked specifically for demangled names for missing symbols. This by itself would be a useful improvement. I agree with that, but there's a caveat. I did such a thing years ago for C++ and Optlink. Nobody cared, including the people who asked for that feature. It's a bit demotivating to bother doing that again. Let me take the opportunity to say I care about an unrelated usability feature: the spelling suggestion. However small it's pretty nice so thanks for doing that.
Re: tooling quality and some random rant
retard wrote: Mon, 14 Feb 2011 04:44:43 +0200, so wrote: Unfortunately DMC is always out of the question because the performance is 10-20 (years) behind competition, fast compilation won't help it. Can you please give a few links on this? What kind of proof you need then? Just take some existing piece of code with high performance requirements and compile it with dmc. You lose. http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html http://permalink.gmane.org/gmane.comp.lang.c++.perfometer/37 http://lists.boost.org/boost-testing/2005/06/1520.php http://www.digitalmars.com/d/archives/c++/chat/66.html http://www.drdobbs.com/cpp/184405450 That is ridiculous, have you even bothered to read your own links? In some of them dmc wins, others the differences are minimal and for all of them dmc is king in compilation times.
Re: Stupid little iota of an idea
foobar wrote: Andrei Alexandrescu Wrote: On 2/11/11 7:07 AM, foobar wrote: Andrei Alexandrescu Wrote: I don't find the name iota stupid. Andrei Of course _you_ don't. However practically all the users _do_ find it poorly named, including other developers in the project.. This is the umpteenth time this comes up in the NG and incidentally this is the only reason I know what the function does. If the users think the name is stupid than it really is. That's how usability works and the fact the you think otherwise or that it might be more accurate mathematically is really not relevant. If you want D/Phobos to be used by other people besides yourself you need to cater for their requirements. Not all users dislike iota, and besides arguments ad populum are fallacious. Iota rocks. But have at it - vote away, and I'll be glad if a better name for iota comes about. Andrei Usability seems to be Achilles' heel of D and is a recurrent theme on the NG. Usability cannot be mathematically deduced even though you seem to try hard to do just that. This reminds me the story of a Google designer that quit the company, being frustrated by the engineering mind-set of the company. He gave many amusing examples of a complete lack of understanding of design principals such as choosing the shade of blue by doing a scientific comparison of a thousand different shades. could we for once put aside otherwise valid implementation concerns such as efficiency and mathematical correctness and treat usability as valid important concern? Could we for once accept that The users' opinion is not fallacious and have a user oriented design is not a bad thing or are we implementing for the sake of boosting ones own ego and nothing else? first rule of usability: don't listen to users http://www.useit.com/alertbox/20010805.html
Re: tooling quality and some random rant
Paulo Pinto wrote: Hi, still you don't convice me. So what language features has C that are missing from D and prevent a linker to be written in D? The issue is not if I can beat Walter, the issue is that we have a language which on its official home page states lots of reasons for using it instead of C and C++, and its creator decides to use C when porting the linker to an high level language. So doesn't Walter belive in its own language? From Walter himself: Why use C instead of the D programming language? Certainly, D is usable for such low level coding and, when programming at this level, there isn't a practical difference between the two. The problem is that the system to build Optlink uses some old tools that only work with an old version of the object file format. The D compiler uses newer obj format features, the C compiler still uses the old ones. It was just easier to use the C compiler rather than modify the D one. Once the source is all in C, it will be trivial to shift it over to D and the modern tools. http://www.drdobbs.com/blog/archives/2009/11/assembler_to_c.html
Re: tooling quality and some random rant
gölgeliyele wrote: ... I think what we need here is numbers from a project that everyone has access to. What is the largest D project right now? Can we get numbers on that? How much time does it take to compile that project after a change (assuming we are feeding all .d files at once)? Well you can take phobos, I believe Andrei used it once to compare against Go. With std.datetime it is now also much bigger :) Tango is another large project, I remember someone posted a compilation speed of a couple of seconds (Tango is huge, perhaps 300KLoC). But projects and settings may vary a lot. For sure, optlink is one hell of a speed monster and you might not get similar speeds with ld on a large project.
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Walter Bright wrote: Akakima wrote: Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files. I found some doc there: http://pierrelib.pagesperso-orange.fr/exec_formats/index.html Microsoft Symbol and Type Information By TIS / Microsoft. Entry added 12/28/2004. Keywords: ms, symbol, type, info File: MS_Symbol_Type_v1.0.pdf « This document describes Microsoft Symbol and Type Information, a debugging information format fromMicrosoft Corporation for the 32-bit Windows environment. » That document describes the Codeview symbol debug format, which Microsoft abandoned 15 years ago in favor of a proprietary format. Dmd generates that older format :-) Are you going to do Elf? With optlink in D? (Does that even make sense?)
Re: Double-dispatch
Sean Eskapp wrote:
I remember in C++, I had to do double-dispatch using the visitor pattern.
This is cumbersome, just because each subclass has to have the exact same
singly-dispatched code that looks like:
void dispatch(Base other)
{
other.dispatch(*this);
}
Is there a nicer way to do this in D, or am I stuck with the same thing?
There isn't really, but you can take out some of the boilerplate with a
mixin, which goes a long way:
// The template parameter Visitor is not actually needed, depending on
// what you want to do
mixin template Accept(Visitor)
{
void accept(Visitor v)
{
v.visit(this);
}
}
class Stuff
{
mixin Accept!IStuffVisitor;
}
With some ctfe it's also not too hard to take out the boilerplate of
creating the visitor interface with a bit of code generation, though I'm not
sure if it's worth it.
Re: std.xml should just go
Andrej Mitrovic wrote: On 2/4/11, spir denis.s...@gmail.com wrote: About that, I would love a tutorial about eponymous templates starting with their /purpose/ (why does this feature even exist? what does it /mean/? what does it compare/oppose to? why is one supposed to need/enjoy it? how is it supposed to help make code better mirror model?) Same for alias template params. Same for a rather long list of features, probably. But both of these are already explained in the manual: http://www.digitalmars.com/d/2.0/template.html (search for Implicit Template Properties) http://www.digitalmars.com/d/2.0/template.html (search for Template Alias Parameters) Granted, eponymous templates aren't explained in much detail on that page. As for explaining how they work together, I did write that short template tutorial (http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Templates), but you've already seen that. :) However, I do not think we should write tutorials on single features alone. I've read a bunch of books that explain the language in feature-by-feature basis, but neglect to tie everything together. For example, Learning Python is this 1200 page book about Python 3, explaining the language feature by feature but never really discussing the language as a whole. It's only good as a reference, which ironically defeats the book's title. OTOH Dive into Python 3 gradually introduces you to more features of the language, but always has code examples where you can see multiple features of the language being used. (IIRC there were string processing examples which used regex, multiple modules, and unittests all at once). Having a perspective on how all features tie together is crucial to understanding the purpose of individual features themselves. In my opinion! I agree, most of the 'dive into' books are excellent and complementary to reference materials. TDPL also has great little examples that illustrate the why of things, without ever becoming a mindless tutorial. It's hard to write such things however (witness the abundant amount of horrible technical writing), I truly admire those who can.
Re: d-programming-language.org
Andrei Alexandrescu wrote: I've had some style updates from David Gileadi rotting in a zip file in my inbox for a good while. It took me the better part of today to manually merge his stale files with the ones in the repository, which have in the meantime undergone many changes. The result is in http://d-programming-language.org. It has (or at least should have) no new content, only style changes. I added a simple site index, see http://d-programming-language.org/siteindex.html. It's not linked from anywhere but gives a good entry point for all pages on the site. One other link of possible interest is http://d-programming-language.org/phobos-prerelease/phobos.html which will contain the latest and greatest Phobos committed to github. I've included build targets to synchronize /phobos-prerelease/ and /phobos/. (Right now both contain the prerelease version; don't let that confuse you.) In agreement with Walter, I removed the Digitalmars reference. The message is simple - D has long become an entity independent from the company that created it. (However, this makes the page header look different and probably less visually appealing.) Anyway, this all is not done in relation or in response to the recent related activity on redesigning the homepage. I just wanted to make sure that we have a clean basis to start from, and am looking with interest at the coming developments. Cheers, Andrei It looks great. Is it possible to create a github repository specifically for this site? That would help a lot with contributing. I'll revisit taking a stab at creating good indexes soon, sorry for the delay.
Re: Suggestion: New D front page
Adam D. Ruppe wrote: Sorry to harp on security issues, but what are you doing to protect yourself from those compile and run arbitrary code boxes? It runs a separate process which is suid'd to a single purpose restricted user that only has access to one directory and a number of ulimits in force. So they could in theory write evil things, but the operating system won't let it gain much ground. I'm currently setting up a separate virtual machine on a different domain to handle that, so even if they broke it, the system is completely expendable anyway. Problems with this would be if someone wanted to set up a network spammer or a CPU eater. Perhaps a cron job that loops around killing processes would help with that. I need to think about it some more. Redirecting the user to ideone might end up being the best solution (or dropping the feature) but I want to shoot for something higher first. ideone also has an api you can use, instead of just redirecting
Re: d-programming-language.org
Vladimir Panteleev wrote: On Sun, 30 Jan 2011 16:25:20 +0200, Lutger Blijdestijn lutger.blijdest...@gmail.com wrote: It looks great. Is it possible to create a github repository specifically for this site? That would help a lot with contributing. I believe one already exists: https://github.com/D-Programming-Language/d-programming-language.org o wow, somehow I missed that. That's great!
Re: On 80 columns should (not) be enough for everyone
Andrej Mitrovic wrote: The unittest topic is about to get derailed so I want to continue this silly discussion here. 80 colums is an artifact of the old age. Just like the preprocessor is an artifact of the C language. And many other old things are artifacts. There's no reason to keep these artifacts around anymore. Yes, but there has to be some limit, horizontal scrolling is much worse. Someone at my workplace likes to make 400+ columns lines of code for example, he likes it but it confuses the shit out of me. A couple of things, Andrei: 1. 80 colums is way too restrictive. 80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware. Who will run a brand new language like D in a freakin' Terminal? Terminals can host more than 80 columns these days. If you want to see more files on the screen, get multiple screens. Is Facebook running out of money, can't they afford a few monitors for the C++ guru? Yes, I know you're not allowed to comment on that one. :) iirc Andrei commented facebook installed him a 30inch screen.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky wrote:
David Nadlinger s...@klickverbot.at wrote in message
news:ihkub8$1ia4$1...@digitalmars.com...
On 1/24/11 10:20 PM, Nick Sabalausky wrote:
Does Git really not have real revision/changeset numbers?
[.]
Not that I've actually used DVCSes much yet, but my understanding is
that the same can be set of Hg and yet Hg handles revision/changeset
numbers just
fine. The nice things (plural) about those is that they're both readable
and
comparable.
Hg has no �real revision/changeset numbers� either - there is a
more-or-less-monotonic number assigned to the various changesets, but
it's only valid for a single, *local* checkout, using them e.g. in a NG
post would be a very wrong thing to do
(http://mercurial.selenic.com/wiki/RevisionNumber).
Even without really using DVCSes it always seemed clear to me that an
incremented number would be relative to a particular branch. So if you
specify what branch you're talking about (which could usually just be
assumed to be the main official one unless otherwise specified), shouldn't
that be enough?
Git supports a relative notation as well, which is what I personally want
to use most of the time anyway (e.g. HEAD^, master~4, something@{1 year
ago}, .).
Ah, so it *does* then? Great! Happen to have a link that explains it?
This covers most of it to see what's possible:
http://progit.org/book/ch6-1.html
You can customize git log with a format string, try this for example:
git log --pretty=format:%h - %an, %ar : %s %d
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky wrote:
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote in message
news:ihn21d$2esd$1...@digitalmars.com...
Nick Sabalausky wrote:
David Nadlinger s...@klickverbot.at wrote in message
news:ihkub8$1ia4$1...@digitalmars.com...
On 1/24/11 10:20 PM, Nick Sabalausky wrote:
Does Git really not have real revision/changeset numbers?
[.]
Not that I've actually used DVCSes much yet, but my understanding is
that the same can be set of Hg and yet Hg handles revision/changeset
numbers just
fine. The nice things (plural) about those is that they're both
readable
and
comparable.
Hg has no ?real revision/changeset numbers? either - there is a
more-or-less-monotonic number assigned to the various changesets, but
it's only valid for a single, *local* checkout, using them e.g. in a NG
post would be a very wrong thing to do
(http://mercurial.selenic.com/wiki/RevisionNumber).
Even without really using DVCSes it always seemed clear to me that an
incremented number would be relative to a particular branch. So if you
specify what branch you're talking about (which could usually just be
assumed to be the main official one unless otherwise specified),
shouldn't
that be enough?
Git supports a relative notation as well, which is what I personally
want
to use most of the time anyway (e.g. HEAD^, master~4, something@{1
year ago}, .).
Ah, so it *does* then? Great! Happen to have a link that explains it?
This covers most of it to see what's possible:
http://progit.org/book/ch6-1.html
You can customize git log with a format string, try this for example:
git log --pretty=format:%h - %an, %ar : %s %d
Ahh, that's not remotely what I was hoping it was. Everything is all
relative to the current version which means that *every* time you commit,
*every* changeset gets completely renamed (HEAD@{5} becomes HEAD@{6},
etc), and there doesn't appear to be any syntax to refer to the next
changeset (only the previous), which makes it barely useful at all. And
not only that, but they *dissapear* after a certain amount of time.
Browsing through http://hginit.com/index.html, it looks like with Hg,
everything works just as well as with SVN, the only difference being that
you need to remember to specify which repository you're talking about
whenever you give a number.
I see, you want a convenient name for a particular commit, is that it? But
even the hg revision number is discouraged to be used to talk with others,
this is from the manual:
It is a strictly local convenience identifier (...) Revision numbers
referring to changesets are very likely to be different in another copy of a
repository. Do not use them to talk about changesets with other people
When there is a lot of branching going on (even in a local repository) these
revisions numbers become useless and confusing. A unique identifier is much
more useful. You can't expect other people to piece together how the
revision number has come to be, that is extremely brittle.
Obviously I'm not saying DMD should have gone Hg, I'm just kinda shocked
by how horrid Git's approach is for referring to changesets. (Personally,
that alone would be enough to get me to use Hg instead of Git for my own
projects. Heck, I've become pretty much sold on the idea of DVCS, but
because of this I think I'd actually sooner use SVN for a new project than
Git.)
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky wrote: ... You can't expect other people to piece together how the revision number has come to be, that is extremely brittle. They don't need to piece it together because you can just say... ...which repository you're talking about. ...which repository you're talking about. ...which repository you're talking about. . . . . ...which repository you're talking about. . . . . . ok ok ok ok ok I get it. I spend some quality time with google and have found this: $ git describe --tags phobos-2.046-664-g938e1cc So phobos is at the 664th commit since 2.046 http://gitfu.wordpress.com/2008/05/25/git-describe-great-another-way-to- refer-to-commits/
Re: first git commit
Andrei Alexandrescu wrote: We've moved the entire camp to github: dmd compiler, phobos, druntime, website, installer. I'm happy to report that we have our first git commit: https://github.com/D-Programming- Language/phobos/commit/81a4a4034aabe83d41cf2a0a202fedb428da66b6 Andrei Congrats! Isn't it shiny?
Re: join
Andrei Alexandrescu wrote: On 1/18/11 2:55 PM, so wrote: 2. joiner uses an idiom that I've experimented with in the past: it defines a local struct and returns it. As such, joiner's type is impossible to express without auto. I find that idiom interesting for many reasons, among which the simplest is that the code is terse, compact, and doesn't pollute the namespace. I'm thinking we should do the same for Appender - it doesn't make much sense to create an Appender except by calling the appender() function. Didn't know there was a solution to namespace pollution. This one is a very nice idea, are you planning to use it in phobos in general? Retro, Stride... there should be many. I plan to, albeit cautiously. Sometimes people would want e.g. to store a member of that type in a class. They still can by saying typeof(joiner(...)) but we don't want to make it awkward for them. Andrei I do this sometimes with Appender for splitting complex construction of a string between functions. Is that bad practice? What is the alternative idiom? If possible, please reconsider making Appender an existential type.
Re: join
Andrei Alexandrescu wrote: ... Good idea, done. Will be part of the next commit. I plan to make one more pass through std.algorithm anyway. If there's stuff you wish were there (including stuff generalized from other modules), please let me know. Andrei I had need for a group() that constructs a range of ranges instead of tuple with count.
Re: renamepalooza time
Andrei Alexandrescu wrote: The following symbols in std.string don't satisfy the Phobos naming conventions and need to be renamed: LS PS capwords countchars entab expandtabs hexdigits icmp iswhite ljustify lowercase maketrans newline octdigits removechars rjustify sformat splitlines stripl stripr tolower tolowerInPlace toupper toupperInPlace tr whitespace zfill Opinions on what to rename? Thanks, Andrei Are there any conventions beyond what case to use? I see this common pattern: verb-noun (expand-tabs) but for what I think is called adverbs in English it is a bit mixed (ljustify vs stripl). These ones should be simply lower camel case: capwords countchars entab expandtabs hexdigits octdigits removechars tolower tolowerInPlace toupper toupperInPlace lowercase maketrans splitlines newline and whitespace: not sure how it is called in English, but these look like they have become single words and are fine. LS and PS: since these are constants, upper case is ok, although LS is inconsistent with std.path.linesep. iswhite - isWhitespace tr: would say translate, but it's already there. Doesn't it overlap too much? Then these remain, I'm less sure about them: icmp ljustify rjustify sformat stripl stripr zfill Possibly: icmp: ok, it's a single abbreviation and insensitiveCompare is too much ljustify - leftJustify rjustify - rightJustify sformat - stringFormat (?) stripl - leftStrip stripr - rightStrip zfill - zeroFill (or better, ditch it and overload justify to take the filling char)
Re: Texas LinuxFest 2011 call for papers now open
Andrei Alexandrescu wrote: http://www.texaslinuxfest.org/callforpapers/ One topic of interest is Open Source Programming Languages. If someone could explain to me the various subtle nuances of what an open source programming language is, I'll try to make a D-related submission and of course I recommend anyone else to do the same. Andrei This is a matter of perspective, I think these are the possibly interesting angles and issues for D: - availability and development of Open Source compilers (OSI compatible license) - cross-platform design, this extends beyond linux but is often a concern and goal in the Open Source world - development process of the language (and std lib) itself: here the community participation is important. For D it's an interesting (and ongoing) story to tell. - usefulness and place in the open source ecosystem: I believe D has a potential here as a serious alternative for both mono and java. Mono, the open source implementation of .net, has loads of potential patent issues and for this reason is not supported by some distro's. Java also has it's issues. Positioning D as a solution to those problems (rather than an alternative for C++ or dynamic languages) will please the crowd, for sure :) Interoperability with C is also important here.
Re: Texas LinuxFest 2011 call for papers now open
Daniel Gibson wrote: ... You can never be sure with patents, as someone else in another thread already pointed out: it's virtually impossible to write a piece of software that doesn't infringe patents. Yes, it's like bugs: you can tell when you found one, but never know your software is free of it. (well, that is almost true) Of course, the situation is worse with Java (as seen in Oracle suing Google for using a Java-derivate in Android) and Mono (you never know if Microsoft will tolerate this forever. Even if they promised not to sue for current .net related patents, you never know about patents applying to features in future versions of .net). With D at least people still would have to find patents that are infringed - and even then the case isn't as clear as with Java/mono, where it's obvious that the Java/.net related patents are infringed. So yes, the point that D may cause less trouble than Java/.net can be made, but you probably shouldn't claim that D doesn't infringe any patents, because you can't possibly know (nobody can, there are just too many software patents to check, even for big companies). Technically that is right, but I find it a bit of an understatement because every non trival software project has potential issues. With .NET and Java you *know* you have patent issues, with D any potential patent issue is a tragic mistake that still has to be proven to exist. Those are not on the same scale, so I wouldn't use the term 'less trouble' You also have ownership to take into account, I would rather trust Walter Bright not using submarine patent traps than MS or Oracle :)
Re: Texas LinuxFest 2011 call for papers now open
Daniel Gibson wrote: ... So yes, the point that D may cause less trouble than Java/.net can be made, but you probably shouldn't claim that D doesn't infringe any patents, because you can't possibly know (nobody can, there are just too many software patents to check, even for big companies). Perhaps I should elaborate a bit. mono is simply out of the question in a large part of linux. Fedora for example, has D as a feature for its 14 release but doesn't support mono. Java is more complex, but if we take it out of the picture it leaves (some of) linux with C / C++ on the one hand and a lot of higher level dynamic languages on the other. In between are some more 'exotic' languages such as haskell. Perhaps I'm wrong, but I see a big void there where D can step in, mostly because of its set of features. In the non-open-source world, Java and .NET are already taking care of much of this void.
