Re: [debate] About D's pretension for homoiconicicity
Doo de doo.. *google homoiconic*... program representation is data structure of primitive type of language or somesuch Hm. templates are advance metaprogramming capabilities, string mixins are quite primitive, and ctfe is too immature to say one way or the other. In my mind, the advantage of a homoiconic language is not so much the ability to generate code (though it is pain when your language doesn't have that) as it is the ability to manipulate code. First, that presupposes a real data structure which can be manipulated. Second, since your code is represented the same way as any other data, your meta programming code isn't any different from other code. Two strengths: 1) you're working with the language; given the operators and syntactic support your meta programming should be fairly eloquent. 2) you get to use the same libraries as you do for everything else. You can probably see where I'm going. Strings are an able medium for generating code. They're pretty fundamental and generating code-as-string is a snap. However, once you have that string, you really can't do anything with it except pass it to the compiler. You can't even insert or replace some piece of code with another (with special cases you can, but special cases are fragile and break quickly whenever you want to do something slightly different). This limits how you can perform string generation. Whereas with templates, you see the top level code with some small pieces which get customized, with string generation you have to generate those small pieces first, and then progressively concatenate things around them. In terms of string operations, that may be eloquent, but in terms of code, it is rather unreadable. Then there's the fact that the compiler doesn't represent code as strings. If the compiler exposed the AST, all this might be less of an issue. ASTs aren't a primitive type, but D's library capabilities are strong enough that you might be able to design an AST such that AST manipulation doesn't suck as much as in other c-style languages. It wouldn't be much more readable than string generation, though. At best, its an implementation issue, as is ctfe (unless something's changed recently, you can't program ctfe in idiomatic D. bad.) In short, D isn't there yet. On 10/21/2010 09:51 AM, Justin Johansson wrote: Nothing about this subject line is purported to be true or false or otherwise conjectured; the subject is simply proposed as a topic for debate. The formal subject proposed for debate is "D's advanced meta-programming capabilities essentially makes it (D) as if it were a homoiconic language, and brings with it all the advantages of homoiconic languages." Hoping this is a nice topic for all to enjoy and to participate in. Cheers Justin Johansson
Re: Looking for champion - std.lang.d.lex
and how about 6. ctfe compatible ?
Re: TDPL Errata site is down
On 10/24/2010 04:36 PM, retard wrote: Walter has many times mentioned how segfaults are actually better than exceptions. They force you to fix your code and the debugger is halfway built in the CPU and operating system. null dereference exploits notwithstanding?
Re: Lints, Condate and bugs
On 10/26/2010 04:21 PM, Walter Bright wrote: 7. Certainly the idea of non-null types has a lot of adherents, D doesn't have that. 8. The only successful solution to this I've seen is Java's simply not having unsigned types. Analysis tools just produce false positives. or python's variation: not having fixed integer types at all. Question: would it be feasible to make D use some sort of bignum type as the default index type for arrays, etc, but make it possible for the programmer to use uint or ulong or whatever for e.g. places where performance is an issue? I don't think there's much value left for add-on static analysis tools. I went to the trouble of modifying dmd to warn on unsigned/signed comparison. It found me some bugs which probably would not have been noticed otherwise. Did it produce false positives? Yes. Did that make me wish I hadn't done it? Hell no. As long as there are things which dmd doesn't warn about, there will be value in add-on static analysis tools. The key idea is leave the warnings off unless the programmer explicitly asks for it.
Re: Temporary suspension of disbelief (invariant)
On 10/26/2010 07:25 PM, Walter Bright wrote: An invariant that is not invariant is a meaningless attribute. It's like "logical constness" where classes claim to be const but aren't. an invariant which isn't used because it is too strict isn't much better. Example: class with some sort of state and public property function which grabs a bit out of some field or something inside method, state violates invariant and I can't call this property function I needed to use the property function, but I also needed the invariant so I shoehorned it into a regular function and explicitly made the calls. Ugly. Though I suppose it was a slightly different case than what bearophile is proposing
Re: Lints, Condate and bugs
Short story: long time ago, lost code, think it's already in bugzilla (259?) On 10/26/2010 08:25 PM, bearophile wrote: Ellery Newcomer: I went to the trouble of modifying dmd to warn on unsigned/signed comparison. It found me some bugs which probably would not have been noticed otherwise. Did it produce false positives? Yes. Did that make me wish I hadn't done it? Hell no. Please, put this patch in a Bugzilla entry :-) (Later more comments on this thread) Bye, bearophile
Re: Lints, Condate and bugs
On 10/26/2010 09:26 PM, Walter Bright wrote: That's a good sentiment, but it doesn't work that way in practice. Warnings always become de-facto requirements. They aren't the solution to a disagreement about how the language should work. My point was that your claim to be trying to put static analysers out of business while refusing to include simple functionality I want is silly.
Re: Lints, Condate and bugs
Here's an idea: if warnings as a requirement actually become a phenomenon for a compiler which warns on ambiguous issues: insert a warning which gives a random warning on randomly selected code On 10/28/2010 06:15 AM, bearophile wrote: This warning is useful, I use it on default when I write C code. Walter doesn't like warning in general (because he says warnings become de facto errors), and because he says this warning creates too many false positives.
Re: Spec#, nullables and more
On 11/04/2010 03:44 PM, bearophile wrote: Spec# is a Microsoft language, its development started in 2003, so it's not a new language. But both its specs and its implementation are unfinished still. Designing it is a long& hard task. I have recently found a quite nice introduction to Spec#, "Using the Spec# Language, Methodology, and Tools to Write Bug-Free Programs" di K. Rustan M. Leino and Peter Muller (2009): http://research.microsoft.com/en-us/um/people/leino/papers/krml189.pdf Plus a nice Microsoft site that allows you to try it in interactive way, this is very good: http://www.rise4fun.com/SpecSharp hey, cool stumbled on sing# a while ago and thought it was intriguing, or at least the fact that ms was using it to write an OS kernel
Re: Spec#, nullables and more
On 11/05/2010 01:39 PM, Walter Bright wrote: It's infinitely worse. Null pointers do not result in memory corruption, buffer overflows, and security breaches. Not true. Null pointer dereference exploits are difficult, but very real.
Re: Spec#, nullables and more
On 11/05/2010 02:24 PM, Walter Bright wrote: Ellery Newcomer wrote: On 11/05/2010 01:39 PM, Walter Bright wrote: It's infinitely worse. Null pointers do not result in memory corruption, buffer overflows, and security breaches. Not true. Null pointer dereference exploits are difficult, but very real. Is that like worrying that an airliner will crash into your house and explode? Don't know. Has anyone ever crashed into my house with an airliner and lived to tell about it?
Re: Multichar literals
It doesn't look like he says that 'ABC' is actually an integer. If he's just expressing a character string as a little endian integer (which you see a lot of in e.g. debuggers), then it makes sense. On 11/12/2010 09:02 PM, bearophile wrote: Reading a bit about the C-like language used in the LoseThos Operating System, I have found one thing. In this language a single quote can encompass multiple characters. 'ABC' is equal to 0x434241. So it's not the same thing as D Hex Strings, because 'ABC' represents an integral value, so it's a more like a base-256 integer literal :-) So I guess '' is zero, equals to '\0' (currently in D '' gives a "unterminated character constant" error). What's the purpose of them? Bye, bearophile
Re: Multichar literals
On 11/12/2010 11:28 PM, Rainer Deyke wrote:
On 11/12/2010 20:02, bearophile wrote:
In this language a single quote can encompass multiple characters.
'ABC' is equal to 0x434241.
I seem to recall that this is feature is also present in C/C++, although
I can't say that I've ever used it.
Oh wow.
#include
#include
void main(void){
int i = 'ABC';
printf("0x%x\n", i);
}
yields:
0x414243
And that's backwards from what I would have expected
Re: Looking for champion - std.lang.d.lex
On 11/19/2010 05:45 PM, Todd VanderVeen wrote: I agree. I do like the suggestion for developing the D grammar in Antlr though and it is something I would be interested in working on. With this in hand, the prospect of adding D support as was done for C++ to Eclipse or Netbeans becomes much more feasible. Has a complete grammar been defined/compiled or is anyone currently working in this direction? Having a robust IDE seems far more important than whether it is written in D itself. D is not a parser generator friendly language. I have pretty complete ANTLR2 grammars for D1 and D2, but they are slow.
Re: Looking for champion - std.lang.d.lex
On 11/24/2010 09:13 AM, Bruno Medeiros wrote: I don't know about Ellery, as you can see in that thread he/she(?) mentioned interest in working on that, but I don't know anything more. Normally I go by 'it'. Been pretty busy this semester, so I haven't been doing much. But the bottom line is, yes I have working antlr grammars for D1 and D2 if you don't mind 1) they're slow 2) they're tied to a hacked-out version of the netbeans fork of ANTLR2 3) they're tied to some custom java code 4) I haven't been keeping the tree grammars so up to date I've not released them for those reasons. Semester will be over in about 3 weeks, though, and I'll have time then. As for me, I didn't work on that, nor did I plan to. Nor am I planning to anytime soon, DDT can handle things with the current parser for now (bugs can be fixed on the current code, perhaps some limitations can be resolved by merging some more code from DMD), so I'll likely work on other more important features before I go there. For example, I'll likely work on debugger integration, and code completion improvements before I would go on writing a new parser from scratch. Plus, it gives more time to hopefully someone else work on it. :P Unlike Walter, I can't write a D parser in a weekend... :) Not even on a week, especially since I never done anything of this kind before. It took me like 3 months to read his parser to figure out what was going on.
Re: Looking for champion - std.lang.d.lex
On 11/24/2010 02:09 PM, Bruno Medeiros wrote: I didn't meant to offend or anything, I was just unsure of that. None taken; I'm just laughing at you. As I understand it, though, 'Ellery' is a unisex name, so it is entirely ambiguous. It took me like 3 months to read his parser to figure out what was going on. Not 3 man-months for sure!, right? (Man-month in the sense of someone working 40 hours per week during a month.) Probably not
Re: Spec#, nullables and more
On 11/25/2010 10:28 AM, Bruno Medeiros wrote: I think Walter's point remains true: null pointers bugs are an order of magnitude less important, if not downright insignificant, with regards to security breaches. I mean, from my understanding of that article, a NPE bug on its own is not enough to allow an exploit, but other bugs/exploits need to be be present. (in that particular case, a straight-flush of them it seems). On the other hand, buffer overflows bugs nearly always make possible an exploit, correct? From a language designer's perspective, I think programmer association of semantic meaning to null (along with null's weak typing) is a more serious problem than npe vulnerabilities.
Re: String compare performance
how well does dmd perform when you use a switch statement?
value range propagation for %
Hello. Today I've been thinking about calculating the range of values for x % y it is bounded by -|y| and |y|, but for small ranges for x, it is possible to do better. When x is a subrange of y, the result range can be computed exactly and in constant time; however when x is not a subrange of y, I can't think of an exact algorithm that has a better running time than O(yrange). I'm vaguely certain that for unbounded positive integers, you can't do better than linear, consider x = m! y in [1, m] But that certainty would evaporate in the presence of tricks or may not apply when y is bounded above by 2^^n. Anybody know any tricks?
Re: value range propagation for %
Jerome hit it. Looking for the minimum and maximum (though more precise constraints would be nice). I forgot to say that at the moment, I'm considering x to be fixed because it's (approximately) the most difficult case, but x generally goes through a range. On 11/27/2010 12:30 PM, Matthias Walter wrote: On 11/27/2010 12:54 PM, Ellery Newcomer wrote: Hello. Today I've been thinking about calculating the range of values for x % y You might want to state the problem more precisely. What exactly is a "range of values x % y" ? Do you look at the result for x,y in some sets? Or is either x or y fixed? From your example I would suppose that x shall be fixed and y goes through a range?! Matthias
Re: [review] new string type
On 11/30/2010 12:52 PM, Steven Schveighoffer wrote: On Tue, 30 Nov 2010 13:34:50 -0500, Jonathan M Davis 4. Indexing is no longer O(1), which violates the guarantees of the index operator. Indexing is still O(1). 5. Slicing (other than a full slice) is no longer O(1), which violates the guarantees of the slicing operator. Slicing is still O(1). There definitely is value in being able to index and slice into utf strings without resulting in invalid utf, but I think the fact that it indexes on code unit and returns code point is sufficiently strange that it qualifies as abuse of operator overloading. That said, I like this proposal better than the current state of affairs. I'll try to play with it more on the weekend
Re: [review] new string type
On 12/01/2010 03:35 PM, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 18:31:05 -0500, Ellery Newcomer
There definitely is value in being able to index and slice into utf
strings without resulting in invalid utf, but I think the fact that it
indexes on code unit and returns code point is sufficiently strange
that it qualifies as abuse of operator overloading.
Maybe :) The other alternative is to throw an exception if you try to
access a code unit that is not the beginning of a code point.
That might actually be less weird, I'll try doing that on the next
iteration.
in my mind, the problem isn't so much indexing an intermediate code unit
gets you earlier code units (it's a little strange, and I'm not sure
whether greater strictness would be better - on the one hand, less
strictness would be more tolerant of bugs and make it that much more
difficult to detect them, but on the other hand if you were doing
something like getting a random or approximate slice into your string,
less strictness would mean that much less annoyance, though I have no
idea why you would want to do that) as it is just the difference between
the two and the confusion that it's bound to cause the noobies.
I find that iteration over string characters using index is a very rare
thing anyways, you either use foreach, which should give you dchars, or
you use something like find, which should never give you an invalid index.
-Steve
find was the counterargument I had in mind for keeping the operator
overload, as something like
s[find(s,'\u2729') .. s.codeUnits]
is just a bit better than
s.codePointSliceAt(find(s,'\u2729'), s.codeUnits);
I really don't know.
One thing that strikes me, though, if you're going to keep opIndex, is
that being able to do
foreach(size_t codeuniti, dchar c; s){
}
would be nice. Actually, it looks like you can do that with current strings.
Re: value range propagation for _bitwise_ OR
is it just me, or does this fail for minA = 0 minB = 0 maxA = 0x80_00_00_00 maxB = 0x80_00_00_00 I'm pretty sure you need to handle 1 << 32 specially
Re: value range propagation for _bitwise_ OR
On 12/04/2010 01:21 PM, Ellery Newcomer wrote:
is it just me, or does this fail for
minA = 0
minB = 0
maxA = 0x80_00_00_00
maxB = 0x80_00_00_00
I'm pretty sure you need to handle 1<< 32 specially
i'm thinking this is better:
uint32_t maxOr (uint32_t minA, uint32_t minB,
uint32_t maxA, uint32_t maxB)
{
assert (minA <= maxA);
assert (minB <= maxB);
if (maxA == 0) return maxB;
if (maxB == 0) return maxA;
uint32_t a = maxA ^ minA;
if (a != 0) {
a |= (1 << highbit (a)) - 1;
a = a & maxA & maxB;
if (a != 0)
a = (1 << highbit (a)) - 1;
}
uint32_t b = maxB ^ minB;
if (b != 0) {
b |= (1 << highbit (b)) - 1;
b = b & maxA & maxB;
if (b != 0)
b = (1 << highbit (b)) - 1;
}
return maxA|maxB|a|b;
}
Re: double.min - should be 5e-324?
On 12/04/2010 03:22 PM, Dmitry Olshansky wrote:
Well, to keep things short, double.min returns something weird.
See the following for demonstration:
import std.stdio;
void main(){
double r = double.max, r2 = double.min;
writeln(r);//1.79769e+308
r *= 2;//test if it's max
writeln(r); // infinity, ok
writeln(r2);//2.22507e-308, wtf ?
r2 /= 2.0;
writeln(r2);// 1.11254e-308, a logical consequence of above
double dmin = 5e-324;
writeln(dmin);// 4.94066e-324
dmin /= 2.0;
writefln(dmin);// 0
}
looks like double.min is returning double.min_normal
oddly enough, double.min is undefined in the spec
Re: DMD2 .deb fails to install on Ubuntu 10.10 – just remove »shell« ?
Quick - which gets executed first - /usr/bin/* or /usr/local/bin/* ? Either way, someone or something is going to be surprised. It would probably be a better idea to either remove or rename the less used ones. 'shell' is uncomfortably generic. Don't know if anyone does, but I have never used any of the binaries except dmd and rdmd. Except when I can't remember which is objdump and which is dumpobj. On 12/08/2010 07:29 PM, Walter Bright wrote: Walter Bright wrote: Andrei Alexandrescu wrote: This seems pretty urgent. Walter? I asked Jordi, who prepares the .deb files. Should the binaries be installed on /usr/local/bin instead?
Re: Why Ruby?
On 12/11/2010 12:12 AM, Nick Sabalausky wrote: I can definitely see in Ruby how the designer was trying for a "natural language/thought-process" feel, but it just ends up feeling sloppily-designed. I never feel completely confident that what I write is actually going to get parsed as I intended. First time I used ruby, I did something like a = 1 * (4 + 5 + 6) cuz you can do that in python and you would expect ruby to be similar. So I scratched my head for about an hour trying to figure out why a was always 6. I don't know why, but ruby ignores the 4 and 5 unless they are all on the same line. That was about the last time I used ruby.
Re: String to boolean inconsistency
I forget, why are we supposed to use is instead of == with null? On 12/11/2010 08:18 PM, Tomek Sowiński wrote: string s = ""; assert(s); // ok assert(s != null); // fails I guess that's a bug. But which one is right? -- Tomek
Re: Slides from my ACCU Silicon Valley talk
On 12/15/2010 08:34 AM, Lars T. Kyllingstad wrote: And if someone *really* wants to put the "i" in there, they can just define it in their own app: enum i = Complex!double(0, 1); auto z = 0.998 + 2.72e-2*i; -Lars or Complex!"0.998 + 2.72e-2i"
Re: Patterns of Bugs
On 01/08/2011 02:37 PM, Iain Buclaw wrote: Never let indentation fool you, the else clause will be assumed to be for the first condition. :o) I don't believe you
Re: Too much flexibility is dangerous for large systems
On 01/18/2011 06:46 AM, spir wrote: On 01/18/2011 12:41 PM, Walter Bright wrote: bearophile wrote: Found through Reddit, similar things can be said about D2: http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.html I think that article is bunk. Large Java programs (as related to me by corporate Java programmers) tend to be excessively complex because the language is too simple. Too often people think that with a simple language, the programs created with it must be simple. This is dead wrong. Simple languages lead to complex, incomprehensible programs. Oh, how true! Think at Lisp, for instance, probably one of the most simple languages ever. This simplicity, precisely, forces to create tons of abstraction levels just to define notions not present in the language --due to simplicity-- but absolutely needed to escape too low-level programming. please elucidate?
Re: D 2 target architectures
On 01/17/2011 10:24 PM, new2d wrote: Why doesn't the "official" D compiler generate fast code? Is the main priority reliability or standards conformance? But.. I'll test how well GDC works with GCC 4.5 and 4.6. My perception of DMD is that it may be adequately described as "Walter's playground". One of his main priorities (and points of pride) is efficiency of compilation, which is rather antithetical to reliability, as is the fact that he's maintaining it nearly on his own. Concerning standards, they exist more completely in Walter's head and in the heads of others in the community than they do on paper or pixels anywhere that I'm aware of.
Re: Constructors (starstruck noob from C++)
Welcome! On 01/20/2011 07:18 PM, Luke J. West wrote: how do I, in c++ speak, do the D for... A b(a); // or if you prefer... A* b = new A(a); try A b = new A(a); I'm sure this must be trivial. Many many thanks, Luke
Re: immutable
On 01/26/2011 02:40 PM, Steven Schveighoffer wrote:
On Wed, 26 Jan 2011 15:32:58 -0500, Robert
wrote:
Hello,
I have just recently started programming in D (a very pleasant
experience so
far I must say), but when experimenting with the the immutable
attribute I
discovered that the following code does not generate a compile time nor a
runtime error:
//Decalare immutable string
immutable char[] buf = "hello";
//Print the value of buf
writefln("buf = %s",buf);
//Change buf by using standard input
stdin.readln(buf);
//Print buf again
writefln("buf = %s",buf);
This is a bit confusing to be because I had assumed that immutable
data really
would be immutable (without casting). Why does the code above work?
It shouldn't. I don't know where the bug is. Please file a bug with a
complete program (with a main() function) here:
http://d.puremagic.com/issues/enter_bug.cgi
BTW, this has a segfault in Linux, so it's definitely trying to
overwrite immutable data.
-Steve
I'd guess this is the problem:
void badurk(C,E)(ref C[] x, E y){
x ~= y;
}
void main(string[] args){
immutable char[] buf = "hello";
static assert(is(typeof(buf) == immutable(char[])));
badurk(buf,'a'); //compiler: la la, this is okay!
}
OT: this function confuses me:
size_t readln(C)(ref C[] buf, dchar terminator = '\n') if (isSomeChar!C)
{
static if (is(C == char))
{
enforce(p && p.handle, "Attempt to read from an unopened
file.");
return readlnImpl(p.handle, buf, terminator);
}
else
{
// TODO: optimize this
string s = readln(terminator);
if (!s.length) return 0;
buf.length = 0;
foreach (wchar c; s) <- (?!)
{
buf ~= c;
}
return buf.length;
}
}
Re: Is D still alive?
On 01/27/2011 05:41 PM, Walter Bright wrote: Unit testing has produced a dramatic improvement in coding. agreed. unit testing (maybe with dbc, I don't remember) was the only reason I noticed issue 5364.
Re: containers, iteration, and removal
On 08/27/2012 06:27 AM, Steven Schveighoffer wrote:
On Fri, 24 Aug 2012 13:35:57 -0400, Steven Schveighoffer
wrote:
foreach(bool doRemove, item; container)
{
doRemove = predicate(item);
}
Whoops, should be
foreach(ref bool doRemove, item; container)
-Steve
Right, I totally forgot about that one.
Re: containers, iteration, and removal
On 08/24/2012 12:23 PM, JN wrote: I feel kinda stupid here, what's wrong with C++ remove_if ( http://www.cplusplus.com/reference/algorithm/remove_if/ )? you mean something like c.erase(remove_if(c.begin(), c.end(), predicate), c.end()) ? That actually is the sort of thing one could accomplish with position ranges: c.remove(filter!(anti_predicate)(c.position_range()));
Re: containers, iteration, and removal
On 08/27/2012 12:46 PM, Ellery Newcomer wrote:
On 08/24/2012 12:23 PM, JN wrote:
I feel kinda stupid here, what's wrong with C++ remove_if (
http://www.cplusplus.com/reference/algorithm/remove_if/ )?
you mean something like
c.erase(remove_if(c.begin(), c.end(), predicate), c.end())
?
That actually is the sort of thing one could accomplish with position
ranges:
c.remove(filter!(anti_predicate)(c.position_range()));
Doh.
import std.stdio;
import std.container;
void main(){
auto sl = SList!int([1,2,3,4,5,6,7,8]);
auto rng = sl[];
writeln(sl[]);
sl.linearRemove(remove_if!"a % 2 == 1"(sl[]));
writeln(sl[]);
}
auto remove_if(alias _pred, Rng)(Rng rng) {
import std.functional;
alias unaryFun!_pred pred;
Rng res = rng.save();
while(!rng.empty) {
if(!pred(rng.front)) {
res.front = rng.moveFront();
res.popFront();
}
rng.popFront();
}
return res;
}
Hmm. In multi_index,
res.front = rng.moveFront();
has some slightly nasty ramifications which I am not sure how to get
around (without access to the node pointer of the element being
assigned, multi_index has to remove the element and then add it back
in). I wonder what boost::multi_index does?
Re: Building LDC from source
On 09/06/2012 10:16 AM, Andrei Alexandrescu wrote: On 9/6/12 11:14 AM, Dejan Lekic wrote: Andrei, Fedora has LDC in the official repository (that should be clearly stated there). So, a Fedora user installs LDC by simple: yum install ldc-2 Done, let me know. Andrei the -2 is not necessary; also this doesn't install phobos or druntime. yum install ldc ldc-phobos-devel ldc-druntime-devel should bring in everything necessary for compiling.
Re: GDC Explorer - an online disassembler for D
On 09/21/2012 03:04 AM, Jens Mueller wrote: But it's nice to have source code and assembly side by side. Jens And very nice to have demangled names in assembly.
Re: Preliminary submission - std.rational and std.typelist
On 10/08/2012 07:56 AM, Aziz K. wrote: Incidentally, I would very much need a BigFloat class/struct, written in D and independent of any C library. I'm trying to write one myself, but it seems to be rather tricky. Could this be implemented in a short amount of time by someone with more knowledge about this topic? Wasn't Paul D. Anderson working on a BigFloat?
Re: Request for Help: D tool for SCons
On Friday, 19 October 2012 at 15:53:45 UTC, Russel Winder wrote: The need is to fix the new stuff on Windows. Clearly for testing in an ideal world we need a Windows with no D, one with each of GDC, LDC and DMD alone, and then all the various combinations. But what is needed immediately is to test with no D and some D so as to get the functional tests not to fail. Point me at some failing tests!
Re: Why D is annoying =P
On 10/24/2012 01:16 PM, Mehrdad wrote:
On Wednesday, 24 October 2012 at 20:03:44 UTC, H. S. Teoh wrote:
What's wrong with RedBlackTree? You can just do something like:
RedBlackTree!(RedBlackTree!MySet) setOfSets;
The last time I checked two RedBlackTrees for equality, they seemed to
have reference semantics...
Dang.
import std.container;
import std.stdio;
void main() {
auto a = make!(RedBlackTree!int)(1,2,3,4);
auto b = make!(RedBlackTree!int)(1,2,3,4);
writeln(a == b);
}
prints
false
Explanation: RedBlackTree doesn't override opEquals. Either file an
enhancement request or use equal(a[], b[]), depending on whether
opEquals *should* have reference semantics.
Actually, it shouldn't, since that would differ from array/string
opEquals semantics.
SList works
Array works
Oop. DList goes into infinite loop. Dibs on this bug report.
Re: Why D is annoying =P
On 10/25/2012 09:19 PM, H. S. Teoh wrote: Hmph. This is what I don't like about the built-in ==. Its semantics are inconsistent once you leave the realm of ints and floats and other numerical types. I think this one is worthy of a bug report. Well, if nobody else is going to take it http://d.puremagic.com/issues/show_bug.cgi?id=8896
Re: std.signals2 proposal
On 11/05/2012 05:36 AM, Robert wrote:
I just developed a proof-of-concept implementation of an improved
std.signals.
Cool.
1. Passing a delegate to connect, which basically is an extended (void*)
and assuming it is an object delegate, does not feel quite right in D,
where we usually try to guarantee correctness by the compiler wherever
possible.
Not sure I understand why such hatred is rational?
Point 2 does not really bother me,
It bothers me.
So I tried to improve std.signals, code:
(warning at least one bug is remaining, explained below)
https://github.com/eskimor/phobos/tree/new_signal
in emit:
if(slot.indirect.ptr) {
}else{
slot.indirect.ptr =
slot.indirect(i);
}
will not be executed more than once?
in addSlot:
you use malloc &friends to allocate objs, but the gc to allocate slots?
The correct thing to do here is use allocators, which we will totally
have fleshed out by Christmas (right, Andrei?).
in connect [Object]:
It's not formatted right!
You might s/is(T2 : Object)/is(T2 == class)/
Also, it looks like it will not delegate to any overriding methods, but
I don't know if that is desired. I doubt it differs from existing
std.signal.
invariant:
assert(slots_idx==slots.length); // I probably even remove slots_idx
all together.
Yes you should. Also, you should assert that slots.length == objs.length.
private:
union DelegateTypes
{
void delegate(void*, T1) indirect;
void delegate(T1) direct;
}
Could you explain why indirect must have its first param void* ?
You can easily connect to an object's method with:
obj.signal.connect!"someMethod"(obj);
instead of the old implementation:
obj.signal.connect(&obj.someMethod);
The improvement is where?
In addition a method allowing wrapper delegates was added:
class Observer {
void addNumber(int i) {
sum+=i;
}
int sum;
}
class Button {
Signal!(bool) clicked;
// ...
}
void main() {
auto b=new Button;
auto o=new Observer;
// Ignore boolean parameter and pass some int:
b.connect!Observer(o, (o, p) { o.addNumber(7); });
// or even:
b.connect!Observer(o, (o, p) => o.addNumber(7));
// For some reason the compiler is not able to deduce "o" being
// Observer, so the !Observer is needed, but it is still very
// neat and readable.
}
Nice.
Should that be b.clicked.connect?
By passing the object explicitly to the delegate, it is possible to
maintain the 'weak ref' semantics to the target object, while ensuring
that the delegates context won't be freed.
When would the delegate's context be freed? I think it wouldn't.
As a side effect it is now even possible to use struct delegates or even
any non object delegate. Simply pass null for the obj parameter. It is
completely safe, the only drawback is that the struct won't be deleted
until the Button gets destroyed. (Because it holds a reference to the
struct, by means of the delegate.) But for long lived structs this
usually is perfectly acceptable.
I like this capability, but the api could handle the case of non-object
delegates better.
Not completely safe if the struct was allocated on the stack
In my implementation I changed the Signal mixin to be a simple template
struct, because I hit strange compiler errors with it being a mixin. The
most prominent:
Welcome to D.
Also I did not really get the point why a mixin was used in the first
place, it does not really gain us anything? What was the reasoning about
it?
So you can do b.connect in the simplest case?
What do you think?
I like the way this is headed.
Re: std.signals2 proposal
On 11/06/2012 04:10 AM, Robert Klotzner wrote:
Not sure I understand why such hatred is rational?
nvm
in emit:
if(slot.indirect.ptr) {
}else{
slot.indirect.ptr =
slot.indirect(i);
}
will not be executed more than once?
is: "slot.indirect(cast(void*)(objs[index]), i);"
and gets executed for every slot. I am not sure I understand your
question.
// slot[i].indirect.ptr == null
thing.emit(params);
// slot[i].indirect.ptr != null
thing.emit(params);
well yes, because every class derives from Object. But the requirement I
need is that T2 is derived from Object, so it makes the intent more
clear.
IsExpression rarely does what you want it to, especially with that
colon. I have come across many such IsExpression usages.
Off the top of my head in your case:
is(shared(Object) : Object);
is(const(Object) : Object);
is(immutable(Object) : Object);
is(AnyInterface : Object);
std.traits.BaseTypeTuple might be the way to go if you want clarity.
Also, this brings us to the spectre of const correctness, which I will
drop just as quickly (but keep it in mind - phobos already has too much
code that isn't const correct)
-> No I should not, at least in the current implementation this would be
wrong. I did not yet made up my mind how I want to implement it in the
end, so I left it for now.
Ah. Well, do something so I stop double-taking every time I see
objs[slot_idx-1] or somesuch.
That you can not pass some arbitrary slot like:
Ok, I'm starting to see what you're doing here.
I knew this was coming. Well I haven't done anything with closures yet,
the usage is an escaping of a reference so the compiler should allocate
it on the heap, if not than you got a problem, but its not specific to
signals -> So I still consider the signal API safe ;-)
Heh. Perhaps trusted is a more apt description.
Also I did not really get the point why a mixin was used in the first
place, it does not really gain us anything? What was the reasoning about
it?
So you can do b.connect in the simplest case?
Yes, that's the only reason that comes to mind. I personally think that
a struct is a cleaner solution, that also avoids cluttering the
containing objects namespace.
I think you're right.
Re: Pyd thread
On 11/09/2012 07:03 AM, bearophile wrote: An unusually positive thread on D: http://www.reddit.com/r/Python/comments/12w2i4/have_you_used_python_with_d/ Bye, bearophile He's been writing python extensions in C; he *should* be happy :) btw, what's the status on druntime support for shared libraries? Pyd is kind of walking on thin ice until this is straightened out.
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
On 11/10/2012 04:11 AM, Jacob Carlborg wrote: On 2012-11-10 12:30, Alix Pexton wrote: What a coincidence, I just installed VirtualBox and was looking for advice on what distro of linux to install... All I want to be able to do with my VM is be able to build GDC for my RasPi (via all the hoops that are necessary to get cross compilation working), not bothered about any GUI stuff or bells/whistles, suggestions for a good distro to go with are welcome! Ubuntu 12.04 was working perfectly fine for me. Another alternative could be Linux Mint. I haven't used it myself but I heard it's basically Ubuntu with less bells and whistles, i.e they're not using the Unity GUI. http://linuxmint.com/ Ubuntu 12.10/gnome classic works well enough; just turn off compiz. I tried mint and ran into trouble while compiling llvm. make gobbled memory for a while, and then the desktop restarted itself (I guess?). All my windows: gone.
Re: Pyd thread
On 11/09/2012 11:33 PM, Russel Winder wrote: What is guaranteed now is that the ctypes package works in CPython and PyPy and would seem to be the right "API" for people interested in using Python with D. If the ctypes overhead is significant to the execution then writing a native code extension is probably the wrong solution to the problem? Never used ctypes. How difficult would it be to get python objects/functions to the extension side?
Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken
On 11/11/2012 02:50 AM, Jacob Carlborg wrote: On 2012-11-10 17:14, Ellery Newcomer wrote: Ubuntu 12.10/gnome classic works well enough; just turn off compiz. I tried mint and ran into trouble while compiling llvm. make gobbled memory for a while, and then the desktop restarted itself (I guess?). All my windows: gone. I manage to turn of compiz but I don't know if I made some bad choices in the process because now I only have the desktop. No left or top bar. Ouch. Looks like what I should have said is gnome classic (no effects), and I guess compizconfig didn't actually turn anything off. Also, I'm working from a clean install, so that might account for behavior difference. It still sucks, though. Found myself wishing I had installed server instead.
dlang.org: library reference
Can we get this updated? std.traits.ParameterIdentifierTuple and std.traits.ParameterDefaultValueTuple are not showing up, but have been around at least since 2.060 was released
Re: Pyd thread
Just tried building a shared library on linux with dmd (and calling it from C). It works! Holy crap, it even runs my static constructors and unittests! I only had to screw with the linking process a little bit! It doesn't work for x64, though. Gives me /usr/bin/ld: /usr/lib64/dmd/libphobos2.a(object__c_58c.o): relocation R_X86_64_32 against `_D10TypeInfo_m6__initZ' can not be used when making a shared object; recompile with -fPIC /usr/lib64/dmd/libphobos2.a: could not read symbols: Bad value collect2: ld returned 1 exit status --- errorlevel 1 Though why it doesn't do this for x32 is beyond me. Those object files don't appear to be -fPIC either.
Re: DLLs and friends
__declspec(dllimport): This symbol exists somewhere else. I [the linker] am going to try to pull it in from some library at [runtime? link time? I [ellery] don't remember] __declspec(dllexport): This symbol exists in this image. I [the linker] am going to make it available to other dlls and executables if they want to use it. CD __declspec(dllimport) <-> export [apparently] __declspec(dllexport) <-> extern export ** ** with dmd on linux, apparently __declspec(dllexport) <-> [nothing]. Noticed this when trying to link to the python c api. But it could just be python isn't using dllexport.
Re: DLLs and friends
On Saturday, 24 November 2012 at 20:08:10 UTC, Ellery Newcomer wrote: CD __declspec(dllimport) <-> export __declspec(dllexport) <-> extern export I might have these backwards if you're implementing your own library.
[RFC] semantics of containers of const
Gonna make multi_index take const and immutable element types. I think it makes perfect sense to support insert/remove/replace operations for containers of const elements. My only arguments are it's possible without violating D's constness rules and the constness of the element should have no bearing on the constness of the container. But it does look kinda funny to see container[i] = newitem; for a container of immutable(T). (replace index assign with front=, etc, as fit) Requesting discussion as there isn't much precedence for this in D at the moment. And with arrays, the semantics of const are married up with the semantics of contiguous memory, so I don't think it provides the best guide for containers in general.
dlang.org Library Reference
Is anyone else noticing e.g. std.datetime taking upwards of 30 seconds to render the blob of links at the top? It's freakin freezing my entire browser.
Re: Moving towards D2 2.061 (and D1 1.076)
On 12/11/2012 12:08 AM, Denis Shelomovskij wrote: 11.12.2012 3:01, Walter Bright пишет: On 12/10/2012 8:28 AM, Denis Shelomovskij wrote: This was the result of DustMite-ing my sources: http://d.puremagic.com/issues/show_bug.cgi?id=6296 Currently the bug state is a bit confusing. It is a regression (but I didn't mark it that way, only write in description, sorry) but is resolved as a duplicate of a non-regression unfixed bug 4269. It was a small war between "regression" and "normal" state of 4269 and now it is marked as "normal". It isn't a regression, and the test cases you reported work in D1 and D2. How can I suppress DMD "abnormal program termination" pop-up when launched with "dmd ... 2>&1"? DustMite's code: https://github.com/CyberShadow/DustMite/wiki/Suppressing-DMD-crashes fails in this call: "FindWindowExA(h, null, "Button", "OK");" Edit dmd with OllyDbg cf http://forum.dlang.org/thread/k1954u$lsq$1...@digitalmars.com#post-k1lkbv:2421n7:241:40digitalmars.com for the calls you're looking for
Re: Compilation strategy
On 12/15/2012 10:30 AM, RenatoUtsch wrote: Well, the idea is good. Small projects usually don't have much packages, so there will be just a few compiler calls. And compiling files concurrently will only have a meaningful efect if the project is large, and a large project will have a lot of packages. Maybe adding an option to choose between compiling all sources at once, per package, or per source. For example, in development and debug builds the compilation is per file or package, but in release builds all sources are compiled at once, or various packages at once. I always thought it would be cool if my build tool could automatically determine the dependency graph of my d code and use it to intelligently break my project into small enough semi-independent chunks to compile.
Re: Fedora 17 will include support for the D programming language
On 12/13/2011 05:47 PM, Andrei Alexandrescu wrote: > http://www.reddit.com/r/programming/comments/nbndg/fedora_17_will_include_support_for_the_d/ > > > Andrei it would be nice if there were d bindings to libraries in fedora
Re: Octal-like integer literals
OT: http://d.puremagic.com/issues/show_bug.cgi?id=5132 On 02/11/2012 10:06 AM, Daniel Murphy wrote: interpreted differently is just errors waiting to happen.
multi_index
Felicitations. Last summer I wrote a port of boost::multi_index when I had some down time (I haven't had too much since until now). It is here: https://bitbucket.org/ariovistus/multi_index/ some cursory ddoc here: http://ariovistus.bitbucket.org/multi_index.html It is functional, if not fully featured and also not heavily tested. I welcome feedback on design, missing/possible functionality, additional index types, bikeshedding, etc. Enjoy [the C++-esque error messages that come with waaay too much template abuse] Hi Steve, I stole your red black tree code.
Re: PyD abandoned?
I think PyD is all there is. But it seems like someone around here (other than me) was trying to bring it back to life. Can't remember who or if I was dreaming, though. When I tried to do this, I found I had problems building shared libraries for any compiler but ldc (thus no windows support), and there might have been some problems with starting up druntime from multiple shared libs, I don't remember. What are you interested in doing with it? On 02/22/2012 09:17 AM, Neal Becker wrote: It looks like now recent devel on PyD. Is there some other python-D effort?
Re: PyD
Well, I can't make any promises, but you can try this: https://bitbucket.org/ariovistus/pyd it seems not to be compiling with the 2.058 front end, but I think it should with the 2.057 front end and ldc. python headers are updated to support 2.5 thru 2.7, though I only tested with 2.7 good luck! On 02/23/2012 12:43 PM, Neal Becker wrote: I'm interested in using it! I want to write python extension libs in D.
Re: PyD
On 02/23/2012 11:40 PM, Ellery Newcomer wrote:
Well, I can't make any promises, but you can try this:
https://bitbucket.org/ariovistus/pyd
it seems not to be compiling with the 2.058 front end, but I think it
should with the 2.057 front end and ldc.
crumb, I take that back
Anyone know why following code gives
test.d(5): Error: f.fn() is not an lvalue
import std.traits;
template _py(Dg){
Dg func(){
F f = new F();
return &f.fn!(ReturnType!Dg);
}
}
class F{
Tr fn(Tr, T ...)(T t){
}
}
void main(){
alias _py!(void delegate()) tz;
}
Re: PyD
On 02/23/2012 11:40 PM, Ellery Newcomer wrote: it seems not to be compiling with the 2.058 front end 3 (4 but for a segfault during shutdown) out of the 5 examples compile with 2.058 and run!
Re: multi_index
On 03/05/2012 07:05 AM, Andrei Alexandrescu wrote:
Great! I meant for a long time to suggest Steve Schveighoffer to accept
a variadic number of predicates for the red-black tree. This is even
more general (nevertheless I still think it would be great if
RedBlackTree accepted multiple predicates).
Andrei
The point of that would just be to have your collection sorted multiple
ways, right? It kinda seems like multi_index is most useful in that
case, but then I don't use multi_index that often, so I don't know.
It would be a nice addition for RedBlackTree.
import multi_index;
import replace;
template RBTreeZ(Value, Preds...){
template Splat(size_t i, size_t N){
static if(i >= N) enum Splat = "";
else{
enum Splat = Replace!(q{
OrderedUnique!("a", Preds[$i]),
}, "$i",i) ~ Splat!(i+1, N);
}
}
enum ss = (Replace!( q{
alias MultiIndexContainer!(Value,
IndexedBy!($indeces)) RBTreeZ;
}, "$indeces",Splat!(0,Preds.length)));
mixin(ss);
}
void main(){
alias RBTreeZ!(int, "ab") MahRBTree;
// it compiles; good enough for me
}
Re: Fortran DLL and D
On 03/13/2012 05:15 PM, Michael wrote:
Hi everyone)
dmd 2.058
os: win 7 64 bit
fortran compilers: gfortran, ftn95
Here's apples to oranges, since I'm on linux 64 bit, but with your code
and this:
pragma(lib, "flib");
extern(C) void fsu_(int*i);
void main(){
int i = 1;
fsu_(&i);
}
when compiled on my box gives
The answer is x = 2.5004E-02 1
If something similar doesn't work for you, can you post disassembly
dumps of your dll function and calling function?
Re: rpm spec for rhel and fedora
bash completion? where does this come from? On 04/05/2012 01:27 PM, lzzll wrote: Hey, I created a new rpm spec. I already test it on rhel6 32bit and 64bit and works well both.
Re: Shared library in D on Linux
On 04/08/2012 03:45 AM, "Timo Westkämper" "
wrote:
extern(C) {
void gc_init();
void gc_term();
void _init() {
gc_init();
}
void _fini() {
gc_term();
}
}
I think you want rt_init and rt_term here.
Re: Shared library in D on Linux
Well, if you're really hankering for a shared lib, try ldc. I have gotten it to compile working shared libs in the past. On 04/09/2012 01:24 AM, "Timo Westkämper" " wrote: On Sunday, 8 April 2012 at 17:59:28 UTC, Timo Westkämper wrote: Does someone know why the lib (.a) packaging instead of objects (.o) works better in this case? Didn't work after all with -lib. I mixed up outputs.
Re: Shared library in D on Linux
On 04/09/2012 03:31 PM, "Timo Westkämper" " wrote: For some reasons, the _init and _fini parts don't yet work properly. what's wrong with them? if it is a link problem, use gcc -nostartfiles. Well, I'm doing that, and it compiles and rt_init is called, but doesn't seem to be calling the module constructors, so maybe that is a very bad idea.
Re: Shared library in D on Linux
On 04/10/2012 01:31 AM, Jacob Carlborg wrote:
The module info (contains the module constructors) need to be setup
differently when linking as a shared library.
The odd thing is, when you skip _init and _fini and just do
rt_init();
writeln("stuff");
rt_term();
it doesn't segfault
Re: Shared library in D on Linux
On 04/10/2012 12:04 PM, Jacob Carlborg wrote:
The odd thing is, when you skip _init and _fini and just do
rt_init();
writeln("stuff");
rt_term();
it doesn't segfault
Are the module constructors run?
they would have to be for writeln to not segfault
Re: Shared library in D on Linux
On 04/10/2012 12:21 PM, Jacob Carlborg wrote: On 2012-04-10 19:12, Ellery Newcomer wrote: they would have to be for writeln to not segfault Ok, I see. tried using __attribute__((constructor)) instead of _init. If I'm getting this line to fail in rt.minfo.sortCtorsImpl: /* Internal runtime error, dependency on an uninitialized * module outside of the current module group. */ (stackidx < modules.length) || assert(0); would that be the problem you were referring to above?
Re: MD5, SHA1, SHA256, CRC32
you might see if the tango d2 port impls are working https://github.com/SiegeLord/Tango-D2/tree/d2port/tango/util/digest On 04/10/2012 04:25 AM, Russel Winder wrote: I'm in need of calculating these numbers as part of a program. Java, Python, Go, all provide these algorithms "out of the box". From what I can see D does not. There is a crc32 module and a std/md5 module but... Have I just missed something? Thanks.
Re: PyD forum?
On 02/19/2013 06:55 AM, mrkafk wrote: First I apologize for bringing this topic up here, because that's obviously not quite correct forum - but can't find info anywhere else.. Is there any active forum/mailing list for PyD? Afraid not. This seems to have been abandoned: http://dsource.org/forums/viewforum.php?f=95 Yup. But bitbucket repo for PyD seems quite active, so the project seems to live. Do you know how I can contact people active on PyD development? Thanks! That would be me. You can message me on bitbucket. You can email me at ellery-newco...@utulsa.edu. You can post right here and I'll probably see it.
Re: Slower than Python
On 03/03/2013 07:31 PM, bearophile wrote: jerro: $ time python3 test.py Are Python3 strings still like wstrings/dstrings, or have they applied the patch that makes them UTF8? Bye, bearophile Looks like 3.3 will store them as utf8, but not 3.2 or below.
Re: Linq and the like
On Tuesday, 5 February 2008 at 06:28:04 UTC, Don Clugston wrote: AFAICT, there's nothing in LINQ that D couldn't (in theory*) do with a library -- today implemented using ctfe and mixins, in future with the front end replaced by macros. IMHO, LINQ is a classic example of something that should be in a library. If it can't be implemented in a library, then the solution is to make the language more powerful, not to shove the library into the compiler. * not in practice, mainly because of the compiler CTFE bug: temporary strings never get deleted, so CTFE runs out of memory extremely quickly. LINQ is dependent on .NET's ability to decompose a lambda expression into a parse tree, e.g. in converting qry = qry.Where(a => a.field == localvar); into an appropriate sql where clause. What I like about LINQ is it provides a centralized interface for high-level query operations that any .NET library worthy of the name is going to support. To some extent, ranges and std.algorithm, std.range, etc fills this space in D, but it trips up in terms of extensibility. A .NET ORM can support the LINQ interface; it is an interface and .NET provides the necessary tools to implement it (translation of a LINQ query to a SQL query). A D ORM could (and would) support the range interface, but this is insufficient for a general query (e.g. you would usually want filter!pred(sqlresult) to be done by the database, not by std.algorithm). And std.algorithm is an implementation, not an interface. I'm trying to think of how one would implement a rich query syntax for a D ORM, and the best I can come up with is something like qry = qry.Where(a => a.eq(localvar)); where a is a proxy type that makes use of operator overloads and methods and maybe opDispatch that return query trees. But it's ugly. And you can't reuse predicates in ORM queries and phobos functions. Can anyone else think of a better alternative?
Re: Linq and the like
On 03/17/2013 05:03 PM, Kapps wrote: As for the implementation of lambdas to generate SQL queries and the like, there was a pull request for a __traits(codeof) that could have been used to do such a thing. Unfortunately, there were issues with it in some fundamental way, and it was scrapped. A __traits(astof) would be quite interesting for this. qry = qry.Where(a => a.field == localvar); Would it be sufficient to get at that local var?
posix.mak wants my private key
trying to build d-programming-language.org from master, and make -f posix.mak all results in Enter passphrase for key '/home/ellery/.ssh/id_rsa' wtf?
status of shared libs
is there a roadmap for druntime/phobos support of shared libraries? just built dmd from master, and I still can't coax out a 64 bit .so
Re: status of shared libs
On 04/05/2013 07:22 PM, Walter Bright wrote: On 4/5/2013 7:18 PM, Ellery Newcomer wrote: is there a roadmap for druntime/phobos support of shared libraries? just built dmd from master, and I still can't coax out a 64 bit .so awaiting: https://github.com/D-Programming-Language/phobos/pull/1240 goody
Re: status of shared libs
On 04/05/2013 07:22 PM, Walter Bright wrote: On 4/5/2013 7:18 PM, Ellery Newcomer wrote: is there a roadmap for druntime/phobos support of shared libraries? just built dmd from master, and I still can't coax out a 64 bit .so awaiting: https://github.com/D-Programming-Language/phobos/pull/1240 trying out the spiffy new shared lib support, I get this: dmd -unittest -fPIC -defaultlib=phobos2so -shared test1.d -oflibtest1.so gcc test1.c `pwd`/libtest1.so -L/usr/lib64/dmd/ -L/usr/lib/dmd/ -o test1.x /lib64/libphobos2so.so: undefined reference to `_Dmain' collect2: error: ld returned 1 exit status _Dmain? wat?
Re: status of shared libs
On Sunday, 7 April 2013 at 06:03:38 UTC, Walter Bright wrote: On 4/6/2013 7:15 PM, Ellery Newcomer wrote: dmd -unittest -fPIC -defaultlib=phobos2so -shared test1.d -oflibtest1.so gcc test1.c `pwd`/libtest1.so -L/usr/lib64/dmd/ -L/usr/lib/dmd/ -o test1.x /lib64/libphobos2so.so: undefined reference to `_Dmain' collect2: error: ld returned 1 exit status _Dmain? wat? _Dmain is the mangled name for main() in your program. Yes, I know, but does it make sense to provide it when I call my shared lib from C?
Re: status of shared libs
On Monday, 8 April 2013 at 04:35:59 UTC, Maxim Fomin wrote: DMD inserts some additional info in object file if main() is present and sometimes it is required. One of the solutions is to use dummy D module (with main function defined) which forwards startup arguments to C main function. My target is python extension modules. I can't touch c main. I can provide a dummy _Dmain and then manually start up and shut down the d runtime; that's the way PyD's been doing it for the last seven years, but I think it breaks when you have more than one shared lib.
Re: David Simcha's std.parallelism
svn ls http://svn.dsource.org/projects/scrapple/trunk/parallelFuture/ works for me On 02/04/2011 11:28 AM, Russel Winder wrote: On Fri, 2011-02-04 at 08:09 -0500, dsimcha wrote: I could move it over to github, though I'll wait to do that until I get a little more comfortable with Git. I had never used Git before until Phobos switched to it. In the mean time, to remind, the code is at: http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d It seems that DSource Subversion service is even worse (much worse) than that of GoogleCode. I appear to be unable to checkout just the parallelFuture directory with any of Git, Mercurial, Bazaar, or Subversion (!). It either gives a 500 Error or a OPTIONS failure :- This does not bode well for extracting anything from that area of the Subversion repository. (Unless I am doing something wrong, which is entirely possible.)
Re: buffered input
On 02/04/2011 11:46 PM, Andrei Alexandrescu wrote: I've had the opportunity today to put some solid hours of thinking into the relationship (better said the relatedness) of what would be called "buffered streams" and ranges. They have some commonalities and some differences, but it's been difficult to capture them. I think now I have a clear view, caused by a few recent discussions. One was the CSV reader discussed on the Phobos list; another was the discussion on defining the "right" std.xml. First, let's start with the humblest abstraction of all - an input range, which only defines the troika empty/front/popFront with the known semantics. An input range consumes input destructively and has a one-element horizon. It may as well considered a buffered stream with the buffer length exactly one. Going from there, we may say that certain streaming can be done by using an input range of ubyte (or dchar for text). That would be the UTFpowered equivalent of getchar(). The readf function operates that way - it only needs to look one character ahead. Incidentally, the CSV format also requires lookahead of 1, so it also can operate on a range of dchar. At this point we need to ask ourselves an essential question. Since we have this "input range" abstraction for a 1-element buffer, what would its n-elements buffer representation look like? How do we go from "input range of T" (which really is "unbuffered input range of T" to "buffered input range of T"? Honestly, the answer was extremely unclear to me for the longest time. I thought that such a range would be an extension of the unbuffered one, e.g. a range that still offers T from front() but also offers some additional functions - e.g. a lookahead in the form of a random-access operator. I still think something can be defined along those lines, but today I came together with a design that is considerably simpler both for the client and the designer of the range. I hereby suggest we define "buffered input range of T" any range R that satisfies the following conditions: 1. R is an input range of T[] 2. R defines a primitive shiftFront(size_t n). The semantics of the primitive is that, if r.front.length >= n, then shiftFront(n) discards the first n elements in r.front. Subsequently r.front will return a slice of the remaining elements. Does shiftFront literally move element n to index 0 and so on? It seems to me that if you do, its going to have horrid performance, and if you don't, then you will eventually run into situations where appendToFront will require a wrap around, which loses you your contiguity, or a reallocation of the buffer.
Re: Complete D grammar
On 03/29/2011 07:53 AM, Bruno Medeiros wrote: On 28/03/2011 18:19, Luca Boasso wrote: You can find an ANTLR grammar for D v1 at http://www.dsource.org/projects/antlrd/browser/toys/v3d/parsed.g (by Ellery Newcomer) I never should have uploaded that file. Indeed, Ellery is (AFAIK) the only one who has worked on ANLTR-based D parser recently and possibly got any significant work done in that. It's definitely worth looking at his work and see if anything can be reused. However, according to his most recent message on the subject: ...it may not provide much of head-start. Been working on them for 3 years now. I should hope it would. As it is, I think I'm done with D and I probably won't be continuing that project, so if anyone wants to do anything further with it, they're welcome to it. https://bitbucket.org/ariovistus/d-jvm-cc I also have some netbeans plugin code somewhere. If memory serves, it can do syntax highlighting. If anyone wants it.
Re: D in your browser? possible?
On 06/17/2012 11:38 AM, Damian wrote: I've noticed a few languages are adopting this, for example Haskell: http://tryhaskell.org Go: http://play.golang.org those sure look a lot more polished than ideone.com
containers, iteration, and removal
Hello.
Today I was thinking about Java. Specifically, java.util.Iterator and
the pattern
while(iter.hasNext()) {
Object item = iter.next();
if(predicate(item)) {
iter.remove();
}
}
You can do this in Java. Easily. You can also do this in C++ with
iterators and erase. Bit more cumbersome, bit more dangerous, but it's
possible.
And D?
auto r = container[];
while(!r.empty) {
auto item = r.front;
if(predicate(item)) {
r = container.linearRemove(take(r, 1));
}else {
r.popFront();
}
}
wut?
The java version exhibits two properties of interest
A) the iterator knows when to stop, and it's kind of hard for the
programmer to screw that aspect up.
B) the whole thing is pretty flexible for selecting the elements you
want [to get rid of]
The C++ version, were it shown, would keep (B), but loses (A).
The D version above keeps (B), but somewhat loses (A). The range knows
when to stop, but it seems so easy for the programmer to mess up
placement of that popFront.
I also take (erk) issue with the implementation of linearRemove. It
depends on an interface from the container range that is not part of the
general range interface. This poses problems. You can't wrap the
container range with another range and pass the result to linearRemove.
The special interface is gone. Case in point, there is a specific
overload for Take!Range, which also uses nonstandard interface.
This doesn't fit the range philosophy. You can't do this
container.linearRemove(filter!predicate(r));
or this
container.linearRemove(takeOne(r));
or this
container.linearRemove(chain(r1,r2,r3));
But what if you could? It would give you (A) and (B) back.
Suppose you define
// look at me! I'm a really fat pointer (kind of)
class Position {
Value v;
private:
}
and expose a way to get a range of positions from a container
container.position_range();
Then your linearRemove can accept any range of element type Position,
and your user can compose the position range to her heart's content
(predicates are a few characters longer), but cannot access the
container internals.
What of this? Are there any downsides to this approach that I haven't
thought of?
Re: Next in Review Queue: The New std.path
Looks nice. a thought: alternate data streams are fringe and probably don't warrant support (you might look into them), but windows \\?\ paths probably should be supported in eg joinPath and pathSplitter
Re: Signed-unsigned comparisons in Phobos
On 08/12/2011 04:06 PM, Don wrote:
No, it was specifically disallowed.
Version D 2.037 Dec 3, 2009
New/Changed Features
No more comma operators allowed between [ ].
I think that was for type declarations, not index expressions.
you can still do this:
import std.stdio;
struct X{
void opIndex(int i, int j){
writeln(i, " ", j);
}
}
void main()
{
X x;
x[1,2];
}
Re: Sorting algorithm
tinkered with timsort a bit a few months ago. comparing that to your sort, I get numbers like xinokSort random: 77 ascending: 0 descending: 21 timsort random: 354 ascending: 1 descending: 4 where each are sorting a 500k element array of int, times are msecs, compilation flags were -O -inline -release, sources are http://personal.utulsa.edu/~ellery-newcomer/timsort.d http://personal.utulsa.edu/~ellery-newcomer/xinokSort.d Nice job, Xinok. anyone want to try to optimize my timsort? :)
Re: Sorting algorithm
On 10/07/2011 01:20 PM, Andrei Alexandrescu wrote: > Also, which version of D are you using? I'm seeing that > std.algorithm.sort (introSort) performs quite badly; for example, it's > twice as slow on shuffled data against quickSort, and it also deals > badly with already sorted data. Generally it does much worse than the > quickSort baseline. Wonder why. > > > Andrei stable sort is flat out broken http://d.puremagic.com/issues/show_bug.cgi?id=4584
Re: Sorting algorithm
it'd be nice if there were some convenience templates somewhere for converting a lt function to le,gt,ge, etc On 10/08/2011 10:04 AM, Andrei Alexandrescu wrote: > > I don't understand. Say all you have is "<". Then you can do everything: > > a <= b is !(b < a) > a > b is b < a
Re: Containers I'd like to see in std.containers
On 05/30/2010 04:53 PM, Philippe Sigaud wrote: There are some simple containers I'd like to see in std.containers: - a priority queue (incf vote) It seems like I'm always writing priority queue implementations whose elements get mutated at weird times and need to be resorted. - a heap - a stack, a queue alias + doubly linked list - a set want Do people here also consider them as containers and useful ones in a standard library? Philippe
Re: Containers I'd like to see in std.containers
On 05/30/2010 06:25 PM, Jonathan M Davis wrote: Philippe Sigaud wrote: There are some simple containers I'd like to see in std.containers: - a priority queue - a heap - a stack, a queue - a set Do people here also consider them as containers and useful ones in a standard library? Philippe A sorted map in addition to a hash map would be good, and for a set, both a sorted and a hash variety woud be good. And of course, multisets and multimaps would be useful too. We also lack a doubly-linked list. Maybe an ordered map, i.e. keeps track of order of insertion? I think I saw this in python once. Looked handy. I do agree with others that a normal stack and queue are either unnecessary or that they should be achieved via aliasing or some other thin wrapper. Creating a whole new container just for a name seems a bit silly and creates more code to maintain. - Jonathan M Davis
Re: eliminating std.range.SListRange?
On 05/30/2010 06:00 PM, bearophile wrote: I'd like a single linked one, and a double linked one (but in my opinion in modern programming linked lists are uncommon. In most situations dynamic arrays are better). I think you just program too much in python
Re: Containers I'd like to see in std.containers
On 05/30/2010 07:41 PM, Andrei Alexandrescu wrote: On 05/30/2010 07:10 PM, Ellery Newcomer wrote: On 05/30/2010 06:25 PM, Jonathan M Davis wrote: Philippe Sigaud wrote: There are some simple containers I'd like to see in std.containers: - a priority queue - a heap - a stack, a queue - a set Do people here also consider them as containers and useful ones in a standard library? Philippe A sorted map in addition to a hash map would be good, and for a set, both a sorted and a hash variety woud be good. And of course, multisets and multimaps would be useful too. We also lack a doubly-linked list. Maybe an ordered map, i.e. keeps track of order of insertion? I think I saw this in python once. Looked handy. I'm thinking of a slightly different course for std.container. Instead of defining an OrderedMap structure that doesn't specify its implementation, std.container will define _explicit_ consecrated data structures, such as BinaryTree and RedBlackTree (Steve Schveighoffer graciously contributed his R-B tree implementation). Later on, we might define a set of generic aliases for typical container choices, but I want std.container to actually reflect the interesting personalities and tradeoffs that data structures have. Andrei My bad. alias RedBlackTreeWithDoublyLinkedListFieldsInRBNodeAndMaraschinoCherryOnTop OrderedMap; Disregarding implementation, do you think this one would be useful enough to merit inclusion?
Re: need clarification: will typedef, C struct initialization, etc.
On 05/31/2010 03:54 PM, bearophile wrote: Andrei Alexandrescu: typedef is gone. *mewls* I have shown here some examples of typedef usage, and I'll keep posting few more in future. I'd like to pull it back from the grave and keep it :-) Bye, bearophile user specified T.init?
