Re: Pure functions as initializers for immutable structures?

Dnia 18-10-2010 o 20:31:26 Tomek Sowiński napisał(a): Initializing immutable structures is a source of constant grief. Anything non-trivial requires instancing a mutable structure, initializing it, and then either casting to immutable (it's up to you to ensure no alias leaked) or, n

Re: Improving version(...)

Dnia 19-10-2010 o 00:20:29 klickverbot napisał(a): On 10/18/10 9:56 PM, Simen kjaeraas wrote: * require declarations for all version identifiers. Versions which are set from the command line should be explicitly declared, eg: version Lite = extern; version Demo = extern; That would make creat

Re: Looking for champion - std.lang.d.lex

Dnia 22-10-2010 o 00:01:21 Walter Bright napisał(a): As we all know, tool support is important for D's success. Making tools easier to build will help with that. To that end, I think we need a lexer for the standard library - std.lang.d.lex. It would be helpful in writing color syntax hi

Re: Looking for champion - std.lang.d.lex

Dnia 22-10-2010 o 21:48:49 Andrei Alexandrescu napisał(a): On 10/22/10 14:02 CDT, Tomek Sowiński wrote: Interesting idea. Here's another: D will soon need bindings for CORBA, Thrift, etc, so lexers will have to be written all over to grok interface files. Perhaps a generic tokenizer

Improving std.range.Zip

I have noticed an emerging idiom in my code lately: bring together n ranges, transform them to one range using a n-ary function. Currently it's achieved with: map!((a) {return myNaryFun(a._0, a._1, ...); })(zip(range1, range2, ...)); It's a bit of a nuisanse -- rarely do my transforming func

Re: Improving std.range.Zip

Dnia 24-10-2010 o 21:34:54 Philippe Sigaud napisał(a): That's what Haskell calls ZipWith. I called it tmap (as in tuple-map) when I needed it in D. IMHO, it should be a generalization of std.algorithm.map: let it accept n ranges and a n-ary function. It can even do a partial check at compile-

Re: Improving std.range.Zip

Dnia 25-10-2010 o 08:42:31 KennyTM~ napisał(a): On Oct 25, 10 14:04, Andrei Alexandrescu wrote: This is coming full circle. At a point, map _did_ support multiple ranges. Some people found that non-modular - if you want multiple ranges, you should use map with zip... Except that at "that poi

Re: Improving std.range.Zip

Dnia 25-10-2010 o 21:20:24 Tomek Sowiński napisał(a): (Map, Filter, Reduce) reduce is of course not a range ;) -- Tomek

Re: [help]operator overloading with opEquals in a class

Dnia 03-11-2010 o 13:07:25 zhang napisał(a): // It works //bool opEquals(Object a) //{ //writefln("running here."); //return data == (cast(AClass)a).data; //} It should be: override equals_t opEquals(Object o) { writefln("running here."); if (auto a = cast

Re: Scriptometer

Dnia 03-11-2010 o 21:27:00 bearophile napisał(a): This is a comparison, how much good various languages are for scripting purposes: http://rigaux.org/language-study/scripting-language/ This test may be good both to see if there is something essential missing in Phobos2 and to see how D2 i

Re: Scriptometer

bearophile napisał(a): Nice page. I submitted some "scripts" so D will be featured on it. You may show them here too. Good idea. I must say it was fun writing "scripts" in D. They could use community sandblasting before publishing. Remember, the aim is to write the smallest program possib

Re: Scriptometer

Dnia 04-11-2010 o 22:13:12 bearophile napisał(a): But I suggest to not overdo it. Minimizing char count doesn't justify writing space-free programs. So I suggest to add spaces and newlines where they belong to increase readability a little. import std.stdio; void main(){writeln("Hello W

Re: Should pure functions be prevented from reading changeable immutable static variables?

Don napisał: > Pure functions are allowed to read immutable global variables. > Currently, this even includes globals which are initialized from inside > 'static this()'. > Here's an example of how this can be a problem: > > immutable int unstable; > > pure int buggy() { return unstable; } > >

Re: Helper unit testing functions in Phobos (possible std.unittests)

Jonathan M Davis napisał: > I'm proposing a possible new module for phobos which would be called > std.unittests. The code and DDoc file can be found here: > http://is.gd/gLH9Q > > Or you can look at the code here directly (though it has poor > highlighting): http://ideone.com/EOlod > > The modu

Re: The D Scripting Language

Andrei Alexandrescu napisał: >> I'm having trouble thinking of something that would go in this module >> that wouldn't be a better fit somewhere else. What do you envision? > > I thought of it for a bit, but couldn't come up with anything :o). I > think you're right! Yeah, I think std.all would

Re: datetime review part 2 [Update 4]

Jonathan M Davis napisał: > Latest: http://is.gd/gSwDv My 2 cents: Units of time are represented more naturally by an integer enum (could be anonymous) than a string. A problem recurring in many methods: /+ref+/ Date opOpAssign(string op, D)(in D duration) nothrow if((op == "+" ||

Re: The D Scripting Language

Andrei Alexandrescu napisał: >> Speaking of getopt, when writing the 'grep' snippet I missed anonymous >> options a lot: >> >> bool h, i; string expr; string[] files; >> getopt(args, "h",&h, "i",&i,&expr,&files); >> >> They can be implemented with relatively little effort. > > Not getting the exa

Re: The D Scripting Language

Steven Schveighoffer napisał: >> I still don't see added value over the existing situation. Currently >> getopt leaves whatever wasn't an option in args[1 .. $] (without >> shuffling order), so the code above would simply use args[1] for expr >> and args[2 .. $] for files. > > 1. uses same type c

Re: The D Scripting Language

sybrandy napisał: > Foo x = 27; > > x += 15; // X is now 42 > > Foo y = "X is " ~ x; // Here, x is now treated like a string. std.variant? -- Tomek

Re: the D scripting language -- command line

spir napisał: >> // Let's match assignments. >> auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"]; >> bool h, i; string expr; string[] files; >> getopt(args, "h",&h, "i",&i, &expr, &files); >> assert(!h); >> assert(!i); >> assert(expr == ".*=.*;"); >> assert(files == ["file1.d

Re: datetime review part 2 [Update 4]

Jonathan M Davis napisał: > On Wednesday, November 10, 2010 15:03:11 Tomek Sowiński wrote: >> Jonathan M Davis napisał: >> > Latest: http://is.gd/gSwDv >> >> My 2 cents: >> >> Units of time are represented more naturally by an integer enum (could be >

Re: datetime review part 2 [Update 4]

Jonathan M Davis napisał: > On Thursday, November 11, 2010 16:31:56 Tomek Sowiński wrote: > That would require you to be able to have unary +. I didn't think that > that was legal. Upon checking it out though, it looks like it is. I don't > really have any problem with the

Re: Principled method of lookup-or-insert in associative arrays?

Dnia 20-11-2010 o 13:33:29 spir napisał(a): I find this proposal really necessary. But aren't there two issues here? * Comparison (for lookup) by value equality should not care about qualifiers (ie compare raw content, here plain array memory areas). * Assignment should perform "qualificatio

Re: Principled method of lookup-or-insert in associative arrays?

Andrei Alexandrescu napisał(a): TDPL has an example that can be reduced as follows: void main() { uint[string] map; foreach (line; stdin.byLine()) { ++map[line]; } } byLine reuses its buffer so it exposes it as char[]. Therefore, attempting to use map[line] will fail. The prog

Re: Principled method of lookup-or-insert in associative arrays?

Dnia 20-11-2010 o 17:09:00 spir napisał(a): It's busting the whole const system to smithereens. char[] chars = "abc"; char[] backdoor = chars; string s = chars; assert (s == "abc"); backdoor.front = 'k'; assert (s == "abc"); // fails. not so immutable, huh? ??? backdoor and s do not denote th

Re: Principled method of lookup-or-insert in associative arrays?

Tyro[a.c.edwards] napisał(a): What would be the harm if upon seeing your code the compiler did this: char[] chars = "abc".dup; char[] backdoor = chars; string s = chars.idup; assert (s == "abc"); backdoor.front = 'k'; // [1] assert (s == "abc"); Slightly magical but works according to expec

Re: Principled method of lookup-or-insert in associative arrays?

Dnia 21-11-2010 o 02:02:35 Tyro[a.c.edwards] napisał(a): The harm is confusion. Now = on arrays always means aliasing, but with your proposal, it may *sometimes* mean dupping. Imagine real-life code with type aliasing and type inference in play, and trying to determine whether some line makes a

Re: php strings demo

Dnia 20-11-2010 o 22:46:33 Kagamin napisał(a): See attachment. It's just a thought. Anyone want this in the language? --- string sval="ab128#d"; int ival=274; static assert("asdf \{sval} astt35 \{ival} zzf \{uuu} g,d" == "asdf ab128#d astt35 274 zzf uuu g,d"); //(uuu not found) --- std.conv.t

Re: DIP9 -- Redo toString API

Don napisał(a): The efficiency issues are important, but are not the primary motivation. toString() is just wrong. The idea that there is ONE AND ONLY ONE textual representation of an object, is, frankly, idiotic. I always thought of toString() as an aid in debugging, where having one and

Re: const / in

Dmitry Olshansky napisał(a): I think you could still get something very related by const { // entire module here } True, but you can't opt out to mutable. -- Tomek

String to boolean inconsistency

string s = ""; assert(s); // ok assert(s != null); // fails I guess that's a bug. But which one is right? -- Tomek

Re: Infinite BidirectionalRange?

Ali Çehreli wrote: > isRandomAccessRange at > > > http://digitalmars.com/d/2.0/phobos/std_range.html#isRandomAccessRange > > describes what a RandomAccessRange is: > > > > A random-access range is a bidirectional range that also offers the > primitive opIndex, OR an infinite forward range t

Re: Requiring weak purity for opAssign, postblit

dsimcha wrote: > I've been thinking about adding purity to various parts of Phobos and > one > thing that limits this in the case of containers is templated > containers, > arrays, etc. that may be instantiated with a user-defined type. In > theory, > even assigning/copying a user-defined type co

Re: Infinite BidirectionalRange?

Ali Çehreli wrote: > Andrei Alexandrescu wrote: > > On 12/24/10 4:19 PM, Ali Çehreli wrote: > >> isRandomAccessRange at > >> > >> http://digitalmars.com/d/2.0/phobos/std_range.html#isRandomAccessRange > >> > >> describes what a RandomAccessRange is: > >> > >> > >> > >> A random-access range is a

Re: auto init & what the code means

spir wrote: > On Sun, 26 Dec 2010 14:54:12 +0100 > Andrej Mitrovic wrote: > > > int i;// auto-initialized to int.init > > int i = void; // not initialized > > Thanks. Actually this solves my "semantic" issue, did not even think > at 'void'. (I will use it often). By the way, I don't want to

Re: PROPOSAL: Implicit conversions of integer literals to floating point

Don wrote: > BACKGROUND: > D currently uses a very simple rule for parameter matching: > * it matches exactly; OR > * it matches using implicit conversions; OR > * it does not match. > > There's an important extra feature: polysemous literals (those which > can be interpreted in multiple ways) ha

Re: PROPOSAL: Implicit conversions of integer literals to floating point

Tomek Sowiński wrote: > I'd cautiously say it is a reasonable proposal not to bother > application > programmers with minutiae of library evolution. My concern is that > instead, programmers would have to be familiar with minutiae of D > literals to understand overload

Immutable nested functions

A while ago I pointed out that the result of an immutably pure function (all arguments immutable, doesn't mutate globals) can be safely converted to immutable. More here: http://d.puremagic.com/issues/show_bug.cgi?id=5081 It helps with building complex immutable structures. Problem is, virtually

Re: memoize -- AAs don't work for ubyte[4] keys

Andrei Alexandrescu napisał: > BTW I think the rgb2cmyk implementation in Higher Order Perl (which I > copied) is a bit convoluted. A simplified version is: > > ubyte[4] rgb2cmyk(ubyte[3] rgb) > { > immutable m = max(rgb[0], rgb[1], rgb[2]); > return [ cast(ubyte)(m - rgb[0]), cast(uby

Re: memoize -- AAs don't work for ubyte[4] keys

Tomek Sowiński napisał: > I didn't know you have to put them:) > > http://www.digitalmars.com/d/2.0/expression.html#ArrayLiteral > > "The type of the first element is taken to be the type of all the elements, > and all elements are implicitly converted > to tha

Re: Immutable nested functions

Tomek Sowiński napisał: > [snip] Two days, no answer. I was told that silence means agreement on this NG but this is extreme ;-) Seriously, what did I do wrong? Too long/boring post? -- Tomek

Re: std.unittests for (final?) review

Andrei Alexandrescu napisał: > * Remove assertCmp and fold it into assertPredicate. With trivial > metaprogramming you can distinguish an operator from an actual expression. > > assertPredicate!"<"(1 + 1, 2.1); If it's trivial, put it into binaryFun, so that everyone else can reap rewards: sor

Re: Immutable nested functions

Daniel Murphy napisał: > Defining a member function to be immutable doesn't mean it can only access > immutable member variables, it means it must be called with an immutable > class reference. > > class C > { > void fun() immutable {} > } > > void main() > { > auto c = new C(); > c.fun(

Re: Immutable nested functions

Robert Jacques napisał: > >> 3. (vaguely related) Should there be means to express annotated > >> delegates in general (e.g. pure, nothrow). > > > > There is. > > int delegate(int) pure square > > = cast( int delegate(int z) pure ) > > (int z) { return z*z; }; > >

Re: Issue 1323

bearophile napisał: > > Also, IMO, it has no real advantage, why not use std.algorithm.find instead > > ? > > The syntax is worse, I don't like to call a function for something so common > and basic. It's like calling a library > function to join two strings (and find("hello", "llox") doesn't

Re: Issue 1323

Peter Alexander napisał: > What's wrong with std.algorithm.canFind? > > http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#canFind That I didn't.. er.. find it :) Sorry for the noise. -- Tomek

Re: Issue 1323

Daniel Gibson napisał: > "restricted to n log(n)"? I think you meant just "log(n)" > > As far as I remember the last discussion, it was considered to allow it for > arrays of a constant size or with known (at compiletime) contents or > something > like that. > But then again, that would feel k

Re: Issue 1323

Tomek Sowiński napisał: > > What's wrong with std.algorithm.canFind? > > > > http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#canFind > > That I didn't.. er.. find it :) Sorry for the noise. One more thing: the overload for range in range search is

Re: Issue 1323

Andrei Alexandrescu napisał: > I'd be glad to change canFind to contains. Vote by replying to this. We > can put canFind on the slow deprecation chute. Like!

Re: either

Andrei Alexandrescu napisał: > I wrote a simple helper, in spirit with some recent discussions: > > // either > struct Either(Ts...) > { > Tuple!Ts data_; > bool opEquals(E)(E e) > { > foreach (i, T; Ts) > { > if (data_[i] == e) return true; >

Re: either

Andrei Alexandrescu napisał: > Aha, so this encodes the predicate in the operation. With a general > predicate, that would be: > > if (any!"a != b"(expr, 1, 2, 5)) { ... } > > The advantage over > > if (expr != 1 || expr != 2 || expr != 5)) { ... } > > is terseness and the guarantee that expr

Re: Recommendation: "functional" keyword

Sean Eskapp napisał: > It's a programmer contract, nothing more. It forces the code to be > functional, not > procedural. Just like const and @safe are simply programmer contracts, Immutably (strongly) pure (pure + all arguments immutable) functions break D onto functional grounds. > functiona

Re: either

Andrei Alexandrescu napisał: > > bool any(alias pred = "a==b", E, Ts...)(E e, Ts args) if(Ts.length> 1 || > > !isTuple!Ts) { > > foreach (a; args) > > if (binaryFun!pred(a, e)) > > return true; > > return false; > > } > > > > unittest > > { > > assert(!"a

Re: std.unittests for (final?) review [Update]

Jonathan M Davis napisał: > I followed Andrei's suggestion and merged most of the functions into a highly > flexible assertPred. I also renamed the functions as suggested and attempted > to > fully document everything with fully functional examples instead of examples > using types or function

Re: std.unittests for (final?) review [Update]

Jonathan M Davis napisał: > On Monday, January 10, 2011 13:48:50 Tomek Sowiński wrote: > > Jonathan M Davis napisał: > > > I followed Andrei's suggestion and merged most of the functions into a > > > highly flexible assertPred. I also renamed the functions as

Re: VLERange: a range in between BidirectionalRange and RandomAccessRange

Andrei Alexandrescu napisał: > I've been thinking on how to better deal with Unicode strings. Currently > strings are formally bidirectional ranges with a surreptitious random > access interface. The random access interface accesses the support of > the string, which is understood to hold data

Implicit delegate conversions

The profusion of D's attributes has made delegate signature mismatches all too likely thus one must resort to casts too often with e.g. callbacks. const(short)[] delegate(immutable(int)*) dg1; immutable(short)[] delegate(const(int)*) pure nothrow @safe dg2; dg1 = dg2; // fails (if *any* of stora

Re: Implicit delegate conversions

Steven Schveighoffer napisał: > I think this is one place where D can improve by vast amounts without a > lot of effort (no change in code generation, just in implicit casting). Yeah, my thoughts exactly. And bumping into a signature mismatch has gotten really likely. > I've brought this u

Re: repeat

Andrei Alexandrescu napisał: > std.range has a function repeat that repeats one value forever. For > example, repeat(42) is an infinite range containing 42, 42, 42,... > > The same module also has a function replicate that repeats one value a > specific number of times. In fact, replicate can b

Re: repeat

Andrei Alexandrescu napisał: > On 1/17/11 1:53 PM, Tomek Sowiński wrote: > > Andrei Alexandrescu napisał: > > > >> std.range has a function repeat that repeats one value forever. For > >> example, repeat(42) is an infinite range containing 42, 42, 42,... >

Re: repeat

Andrei Alexandrescu napisał: > On 1/17/11 2:14 PM, Tomek Sowiński wrote: > > Andrei Alexandrescu napisał: > > > >> On 1/17/11 1:53 PM, Tomek Sowiński wrote: > >>> Andrei Alexandrescu napisał: > >>> > >>>> std.range has a function re

Ad hoc ranges

Doing my own deeds, I often found myself in need of writing up a range just to e.g. feed it into an algorithm. Problem is, defining even the simplest range -- one-pass forward -- is verbose enough to render this (correct) approach unprofitable. This is how I went about the problem: auto range(

Re: Ad hoc ranges

bearophile napisał: > I am not sure, but I think Andrei has deprecated the "lazy" attribute. Yes, but AFAIR in favor of implicit conversions of expressions to parameterless delegates, which strengthens my little idiom. -- Tomek

Re: Ad hoc ranges

Jonathan M Davis napisał: > > I don't know a terser way to get a full-fledged range. It comes at a cost, > > though. Lazy parameters are just sugar over delegates, so it's not exactly > > Usain Bolt**... And you can't return it because by bug or by design lazy > > parameters (unlike vanilla delega

Re: renamepalooza time

Jonathan M Davis napisał: > > > These should be expanded a bit and camelCased: > > >LS:lineSep, lineSeparator > > >PS:paragraphSep, paragraphSeparator > > > > Isn't there a rule that constants all fully uppercase? > > That would be typical in C++ or Java, but that's n

Re: Ad hoc ranges

Andrei Alexandrescu napisał: > > Like I said, anything that doesn't bother to expose range-interfaced > > iterators and is not performance critical is > > considered a target for ad hoc ranges. Working with non-D libraries, or > > libraries ported to D but preserving > > mother-language idioms.

Re: Ad hoc ranges

Andrei Alexandrescu napisał: > On 1/21/11 7:35 PM, Tomek Sowiński wrote: > > Andrei Alexandrescu napisał: > > > >>> Like I said, anything that doesn't bother to expose range-interfaced > >>> iterators and is not performance critical is > >>

Re: Python's partition

Andrei Alexandrescu napisał: > Looking through Python's string functions > (http://docs.python.org/release/2.5.2/lib/string-methods.html) I noticed > partition(): > > partition(sep) > Split the string at the first occurrence of sep, and return a > 3-tuple containing the part before the se

Re: replaceFirst, findPieces, and takeExactly

Andrei Alexandrescu napisał: > On 1/22/11 5:14 PM, Nick Sabalausky wrote: > > "Andrei Alexandrescu" wrote in message > > news:ihfm34$jvb$1...@digitalmars.com... > >> On 1/22/11 4:16 PM, bearophile wrote: > >>> Andrei: > >>> > Back then people said that STL's find() is better than D's find()

Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)

Steven Schveighoffer napisał: >> BTW I consider this a very important topic. We have _plenty_ of >> examples that don't work and are not mechanically verifiable. The >> reasons range from minor typos to language changes to implementation >> limitations. Generally this is what they call "documentat

Re: std.unittests [updated] for review

Dnia 2011-01-24, o godz. 06:34:49 Jonathan M Davis napisał(a): > In case you didn't know, I have a set of unit test helper functions which > have > been being reviewed for possible inclusion in phobos. Here's an update. > > Most recent code: http://is.gd/F1OHat > > Okay. I took the previous s

Re: Is D still alive?

Steven Schveighoffer napisał: > > Adam Ruppe and Piotr Szturmaj have recently been working on some database > > stuff. See the recent thread "Can your programming language do this?" > > I have ignored that thread (I sometimes just ignore threads because they > start out uninteresting, or become

Re: dlist for phobos

Andrei Alexandrescu napisał: > ref returns should be guaranteed to never escape. Should meaning they're not guaranteed now? I'm curious in what scenarios they escape. -- Tomek

Re: dlist for phobos

Andrei Alexandrescu napisał: > On 1/27/11 4:48 PM, Tomek Sowiński wrote: > > Andrei Alexandrescu napisał: > > > >> ref returns should be guaranteed to never escape. > > > > Should meaning they're not guaranteed now? I'm curious in what scenarios &

Re: immutable

Trass3r napisał: > > But thank you for the answer, I have filed the bug. > > Rats, I've filed one too ;) > http://d.puremagic.com/issues/show_bug.cgi?id=5492 We found it over a year ago :) http://d.puremagic.com/issues/show_bug.cgi?id=3534 -- Tomek

Re: Is D still alive?

Walter Bright napisał: > bearophile wrote: > > Walter: > > > >> The reason that took so long was that few people were using DbC > >> effectively, so it was a low priority. I originally had high hopes that DbC > >> would produce dramatic improvements in code quality, but the real world > >> result

Re: Decision on container design

Michel Fortin napisał: > We already argument this over and over in the past. First, I totally > acknowledge that C++ style containers have a problem: they make it > easier to copy the content than pass it by reference. On the other side > of the spectrum, I think that class semantics makes it t

Re: Decision on container design

Michel Fortin napisał: > > Is there anything implementation specific in the outer struct that provides > > ref semantics to Impl? If not, Container could be generic, parametrized by > > Impl type. > > You could provide an implementation-specific version of some functions > as an optimization.

Re: Decision on container design

Michel Fortin napisał: > As for the case of Appender... personally in the case above I'd be > tempted to use Appender.Impl directly (value semantics) and make fill > take a 'ref'. There's no point in having an extra heap allocation, > especially if you're calling test() in a loop or if there's

Re: Decision on container design

bearophile napisał: > This page: > http://www.jroller.com/scolebourne/entry/the_next_big_jvm_language1 > > A quotation: > > >3) Everything is a monitor. In Java and the JVM, every object is a monitor, > >meaning that you can synchronize on any > >object. This is incredibly wasteful at the JVM l

Re: Suggestion: New D front page

Christopher Bergqvist napisał: > Hi! > > I have been putting some free time into creating a "design skeleton" for a > new http://d-programming-language.org > front > page: > http://digitalpoetry.se/D%20website/D%20overview%20design.png > > My main concern

Re: assert(object) fails to adhere to the principle of least surprise

Bernard Helyer napisał: > If I do > > if (object) { > ... > } > > What happens is fairly obvious, and is equivalent to > > if (object !is null) { > } > > However, if I do > > auto object = new Object(); > assert(object); > > What I expect to happen is > >

Re: structs vs classes

Jim napisał: > I'm only discussing the heap/stack difference. Classes with value semantics would be prone to the slicing problem. -- Tomek

Re: structs vs classes

Matthias Walter napisał: > That is of course a difference, but no argument. The reason is that you > can decide whether you want to allocate a class on the stack: > > http://www.digitalmars.com/d/2.0/memory.html#stackclass AFAIR scope classes are to be banished from the language. There's emplace

Re: Suggestion: New D front page

Russel Winder napisał: > I think the current page style looks fine, actually I like it and do not > consider it "dark and foreboding" (*). This is not though a vote for > not changing if there is something that is going to be more appealing to > a wider range of programmers. > > (*) Or maybe I a

Re: d-programming-language.org

Andrei Alexandrescu napisał: > 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.) The h

(Was: On 80 columns should (not) be enough for everyone)

Andrej Mitrovic napisał: > If you really want to set up a column limit that *everyone* has to abide to, > then make a poll to see what everyone can agree on. Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. Wha

Re: (Was: On 80 columns should (not) be enough for everyone)

Tomek Sowiński napisał: > What is your preferred *maximum* length for a line of D code? (please reply > with a number only) 120. -- Tomek

Re: On 80 columns should (not) be enough for everyone

Sean Kelly napisał: > Print text doesn't have indentation levels though. Assuming a 4 character > indent, the smallest indentation level for code in a D member function is 8 > characters. Add a nested conditional and code is starting 16 characters in, > which when wrapped at 80 characters beg

Re: (Was: On 80 columns should (not) be enough for everyone)

Walter Bright napisał: > > What is your preferred *maximum* length for a line of D code? (please reply > > with a number only) > > 6.022e+23 That's a whole mole of code! ;-) -- Tomek

Max length of a LOC: poll results (Was: On 80 columns...)

Tomek Sowiński napisał: > Actually that's a splendid idea. Let's take it easy. Regardless of that silly > beef I'm really curious what distribution will emerge. > > What is your preferred *maximum* length for a line of D code? (please reply > with a number only)

Re: Max length of a LOC: poll results (Was: On 80 columns...)

Tomek Sowiński napisał: > Alright, I'm wrapping up this toy study. Two things before the numbers come: > > - A few respondents gave 2 numbers, one "reasonable", the other "if I really > have to". I took the latter (larger) number as I was after maximum len

Re: Image Resizing by Seam Carving (Was: On 80 columns should (not) be enough foreveryone)

Nick Sabalausky napisał: > > Now, what we need is the audio-equivalent of this: > > http://www.youtube.com/watch?v=6NcIJXTlugc > > That's really cool, and seems so obvious in retrospect. There's a D implementation: http://dsource.org/projects/seamzgood but it's abandoned. -- Tomek

Re: std.xml should just go

Andrei Alexandrescu napisał: > > I'm not against replacement, but I'd be concerned about removal before a > > replacement is available. > > My problem is that the mere presence is reducing the likelihood of a > replacement coming about, in addition to the other liabilities. Is anyone tasked

Re: std.xml should just go

Andrei Alexandrescu napisał: > > Is anyone tasked with a replacement yet? I had to write an XML parser at > > some point. It's plenty of work bringing up to industrial quality, so I'd > > have to know that before I dive in. > > Nobody that I know of. If you want to discuss design here while w

Re: std.xml should just go

Jonathan M Davis napisał: > I think that at least a couple of people have said that they have the > beginnings > of a replacement, but I don't believe that anyone has stepped up to say that > they'll actually complete and propose a module for inclusion in Phobos. Wimps ;-) > So, std.xml is st

Re: std.xml should just go

Daniel Gibson napisał: > They can claim whatever they want.. if Tomek says he only looked at the > documentation (for an idea how a good interface for a XML lib may look like) > they can hardly prove anything. One remark: I haven't even looked at the doc. That's why I was asking "may I look". -

Re: std.xml should just go

spir spir napisał: > > You probably shouldn't look at the source. > > I dunno about the interface (documentation) - it's certainly not illegal to > > take > > inspiration from it, but maybe then people will again claim that source was > > stolen.. but when you claim that you haven't looked at the

High performance XML parser

I am now intensely accumulating information on how to go about creating a high-performance parser as it quickly became clear that my old one won't deliver. And if anything is clear is that memory is the key. One way is the slicing approach mentioned on this NG, notably used by RapidXML. I alrea

Re: David Simcha's std.parallelism

dsimcha napisał: > 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/paral

  1   2   3   >