Re: A few notes on choosing between Go and D for a quick project
On 2015-03-23 at 12:59, krzaq wrote:
I'd argue that joiner is intuitive enough, but I agree on byChunk. I am also
baffled why this byLine/byChunk madness is necessary at all, it should be
something like
File("path").startsWith(s)
or
File("path").data.startswith(s)
Yeah, that would be useful for example to test magic values at the beginning of
files:
string[] scripts;
foreach (string path; dirEntries(topDir, SpanMode.depth))
if (isFile(path) && File(path).startsWith("#!"))
scripts ~= path;
but that's the simplest case of a bigger problem, because here you just need
the first few bytes, and you don't want to read the whole file, nor anything
more than a sector.
OTOH, there are also file formats like ZIP that put the meta information at the
end of the file and scatter the rest of the data all over the place using
offset information. You don't need to read everything just to grab the
metadata. But, when I had a look at the sources of libzip, I went crazy seeing
all the code performing tons of file seeking, reading into buffers and handling
them[1].
D's std.zip took a simple approach and doesn't deal with that at all; it reads
the whole file into the memory. That makes the algorithm more clearly visible,
but at the same time it makes the module completely useless if you want to
handle archives that are larger than the available memory, and over-the-top if
all you wanted was to extract a single file from the archive or only read the
directory structure.
So, how do you envision something representing a file, i.e. a mix of "BufferedRange" and
"SeekableRange", that would neatly handle buffering and seeking, without you dropping to
stdc IO or wanting to shoot yourself when you look at the code?
[1] for your amusement: http://hg.nih.at/libzip/file/78b8e3fa72a0/lib/zip_open.c
Re: A few notes on choosing between Go and D for a quick project
On 2015-03-23 at 00:15, krzaq wrote:
Something like
while (n != EOF) {
n = read(fd, buf, sizeof(buf));
if (n==-1) throw(...);
if (strcmp(buf, PREFIX) == 0) {
return buf;
}
}
return NULL;
Requires no prior knowledge, and have similar effect.
I'm surprised nobody commented on "no prior knowledge". How are you supposed to
guess what strcmp(buf, PREFIX) does if you don't know the function? Why is it being
compared to 0? What's this -1 magic number? What does read do? What is EOF? Unless you're
born with C/POSIX programming knowledge, this is prior knowledge. I know C well enough,
but it took me some time to understand what it does.
Indeed. I know of strcmp (because of prior knowledge) but had to have a look at "man
2 read" just in case to verify if read was used correctly. Of course there is also
this conveniently omitted part in throw(...). Throw what? Use switch to go over errno and
pick the suitable Exception or rather pick one generic Exception and put the output of
strerror as its msg? Why should we be bothered with such low-level tasks?
And honestly, compared to
File("/tmp/a").byChunk(4096).joiner.startsWith(s)
you can *easily* guess that you have a file - do some nonobvious magic on it -
and check if *it* starts with `s` just by reading it as plain English.
Now you've injured yourself with your own weapon. I can guess that File(path)
opens the file for reading (probably because of other language libraries) and
that byChunk(size) reads it one chunk at a time (but frankly only because it
looked similar to byLine which I've known before), but what the hell is joiner?
Does it glue ranges together so that they appear as a single contiguous one?
Oh, wait, I may have actually read about it somewhere already. But if I didn't,
I wouldn't have a clue.
What should start with s? The file, any chunk, the joiner - whatever it meant?
It is much clearer than the loop, but I'm not sure I'd guess what it does,
because of the two middle elements in the UFCS chain. This *nonobvious magic*
may have transformed the contents of the file in a way that makes startsWith(s)
do something different.
Re: [Semi OT] The programming language wars
On 2015-03-22 at 11:03, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: On Sunday, 22 March 2015 at 09:30:38 UTC, Atila Neves wrote: Of course there is. Experience and judgement aren't measurable. You don't have science without numbers. WTF? Heh, everything is measurable, but sometimes the chosen metrics and analysis are just ridiculous and not worth the paper they are printed on, even though all rules of scientific reasoning were followed. :)
Re: [Semi OT] The programming language wars
On 2015-03-21 at 20:13, Joakim wrote: "Find me the best deal on a S6" [...] Just tried it on google's voice search, it thought I said "Find me the best deal on a last sex" the first time I tried. Obviously Google tries to converge the query with what is usually searched for. OTOH that's one of the areas you probably wouldn't want to browse through using a voice interface. :) "There was this famous quote QUOTE to be or not to be END QUOTE on page six END PARAGRAPH..." Just read that out normally and it'll be smart enough to know that the upper-case terms you highlighted are punctuation marks and not part of the sentence, by using various grammar and word frequency heuristics. In the rare occurrence of real ambiguity, you'll be able to step down to a lower-level editing mode and correct it. Yeah, I've exaggerated the problem. The deciding factor will be the required amount of stepping down to do low-level editing, even with a system supported by good machine learning, considering all the homonyms and words having many meanings. But let's assume that this was solved. I think the remaining "END PARAGRAPH", "OPEN BRACE" or "COMMA" problem will go away with a compromise: people will just tell stories like they normally do, and let the punctuation be added automatically using AST, interval and intonation analyses. And the dying breed of writers who care about punctuation very much will continue using keyboards. Therefore I just cannot imagine voice being used anywhere where exact representation is required, especially in programming: "Define M1 as a function that takes in two arguments. The state of the machine labelled ES and an integer number in range between two and six inclusive labelled X. The result of M1 is a boolean. M1 shall return true if and only if the ES member labelled squat THATS SQUAT WITH A T AT THE END is equal to zero modulo B. OH SHIT IT WAS NOT B BUT X. SCRATCH EVERYTHING." As Paulo alludes to, the current textual representation of programming languages is optimized for keyboard entry. Programming languages themselves will change to allow fluid speech input. That's true, programming languages will have to change. For example the distinction between lower and upper case is artificial and it was the biggest stumbling block in that video as well. That will have to go away along with other stuff. But if you look at my function definition, it doesn't have that, nor does it use parentheses, semicolons, etc., so it's "voice-ready". My question is: at which point would that be considered an efficient method to define a program's component that we would choose to use instead of the current succinct symbolic notation? We still have some work to do to get these speech recognition engines there, but once we do, the entire visual interface to your computer will have to be redone to best suit voice input and *nobody* will use touch, mice, _or_ keyboards after that. Yeah, right, people will create drawings with voice commands. :) Every interface has its rightful domain and voice ain't best for everything. Or do you mean that touch will go away but instead people will be waving their hands around?
Re: [Semi OT] The programming language wars
On 2015-03-21 at 06:30, H. S. Teoh via Digitalmars-d wrote: On Sat, Mar 21, 2015 at 04:17:00AM +, Joakim via Digitalmars-d wrote: [...] What I was going to say too, neither CLI or GUI will win, speech recognition will replace them both, by providing the best of both. Rather than writing a script to scrape several shopping websites for the price of a Galaxy S6, I'll simply tell the intelligent agent on my computer "Find me the best deal on a S6" and it will go find it. I dunno, I find that I can express myself far more precisely and concisely on the keyboard than I can verbally. Maybe for everyday tasks like shopping for the best deals voice recognition is Good Enough(tm), but for more complex tasks, I have yet to find something more expressive than the keyboard. "Find me the best deal on a S6" is only a little more complex than "make me a cup of coffee." Fine for doing predefined tasks but questionable as an ubiquitous input method. It's hard enough for mathematicians to dictate a theorem without using any symbolic notation. There is too much ambiguity and room for interpretation in speech to make it a reliable and easy input method for all tasks. Even in your example: You say: "Find me the best deal on a S6." I hear: "Fine me the best teal on A.S. six." Computer: "Are you looking for steel?" Now imagine the extra trouble if you mix languages. Also, how do you include meta-text control sequences in a message? By raising your voice or tilting your head when you say the magic words? Cf.: "There was this famous quote QUOTE to be or not to be END QUOTE on page six END PARAGRAPH..." Very awkward, if talking to oneself wasn't awkward already. Therefore I just cannot imagine voice being used anywhere where exact representation is required, especially in programming: "Define M1 as a function that takes in two arguments. The state of the machine labelled ES and an integer number in range between two and six inclusive labelled X. The result of M1 is a boolean. M1 shall return true if and only if the ES member labelled squat THATS SQUAT WITH A T AT THE END is equal to zero modulo B. OH SHIT IT WAS NOT B BUT X. SCRATCH EVERYTHING."
Re: A few notes on choosing between Go and D for a quick project
On 2015-03-19 at 09:41, Walter Bright wrote:
On 3/18/2015 4:41 PM, Walter Bright wrote:
#include
#include
typedef long T;
bool find(T *array, size_t dim, T t) {
int i;
for (i = 0; i <= dim; i++);
{
int v = array[i];
if (v == t)
return true;
}
}
Bugs:
1. i should be size_t
2. <= should be <
3. extraneous ;
4. v should be type T
5. missing return
Two more things, I believe, but they aren't really internal bugs of find:
a null array or array > 2GB on 32-bit that would cause negative indexing:
assert(array != 0);
assert(dim <= PTRDIFF_MAX);
Re: A few notes on choosing between Go and D for a quick project
On 2015-03-21 at 12:34, Laeeth Isharc wrote: has he actually given his sole rights to use his work them? [...] ROTFL, we must be telepathically linked. :)
Re: A few notes on choosing between Go and D for a quick project
On 2015-03-20 at 16:25, weaselcat wrote: On Friday, 20 March 2015 at 15:12:44 UTC, David Gileadi wrote: Someone who knows about copyright/licensing would probably need to check that it's okay if we plan to use them verbatim. If we can't then it might be worth linking to the above page from somewhere on dlang.org. All of the content on rosettacode appears to be licensed under GNU FDL, I believe it would just have to be released under the GNU FDL or a similar copyleft license that fulfills the GNU FDL. Definitely, having a link to http://rosettacode.org/wiki/Category:D would be useful. As for providing some of the examples in-place, there are two pieces of that legal puzzle: 1. The definitions of the problem to solve Most tasks on Rosetta code are common and generic: concatenate strings, sort a collection of integers using merge/quick/whatever sort, etc., so they aren't anything that had its first appearance on RC. Copy-pasting the exact phrasing of those problems from RC would be a violation, but describing them on your own certainly is not. 2. The solutions to problems Copying those code snippets in general may violate GNU FDL (if it exceeds the scope of citation), but if the complete D answer to a challenge on RC was provided by bearophile, and wasn't a modification of an existing answer, *he himself* can give you a separate licensing deal to re-use his code in whatever way you want, because when posting a solution to RC there is no mention (I assume that there isn't, because it would make no sense, but please verify) that you sign over your work to them, giving RC an *exclusive* license to use it.
Re: Replace core language HexStrings with library entity
On 2015-03-15 at 22:41, bearophile wrote: Walter Bright: Unfortunately, it needs to be a dropin replacement for x"...", which returns a string/wstring/dstring. This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string: Then maybe hex!"..." should produce the desired ubyte[] and something with a different name (for example hexString!"...") would be the drop-in replacement for x"...", returning a string. The more complex name being a hint that what you really need is hex.
Re: loci, a C++/D hybrid?
On 2015-02-21 at 11:51, Kagamin wrote: --- void (*f)(); // C void (*)() f; // Loci int (*f)(); // C int (*)() f; // Loci int (*f)(int, int); // C *(int)(int, int) f; // Loci --- Ehh? Why the last declaration is so different? Yeah, everything was fine, but when I got to this part, I almost fell off my chair. What the hell?! I hope it is just a bug in the documentation. Other than that, the documentation looks quite nice, except for the angle braces, or this eyesore: lval value_lval i = lval(value_lval(0)); Moving on, I'm a bit baffled by what their default string type is - http://loci-lang.org/Strings.html - and if it is worth the trouble and complexity, when compared D's default (linear & immutable + cost-less slicing). The most interesting part is that they don't use mangling and function overloading but instead have templates and this: http://loci-lang.org/TemplateGenerators.html to not have to instantiate for every permutation of types encountered. Indeed, it can help make stable APIs, but we'll have to see if it can be optimized to achieve performance. Well, gonna check again how things turn out for Loci in a couple of years.
Re: contiguous ranges
On 2015-02-16 at 07:06, Vlad Levenfeld wrote: *ContigiousRange* has enough length [...] LOL. The clearly masochistic C++ committee needs to be applauded for introducing what may become the biggest source of typos. :) Adjoining would be easier on the non-native English speakers than contiguous. Not to mention that contiguous sounds almost like contagious. Let's better not catch that infection. ;)
Re: Consistency
No, they were still O(n) worst case, for a single bucket with a degenerate binary tree. What binary tree? I don't see any. I see. I was unable to hit this degenerate case in my testing code, but I guess that was possible. Thank you. From what I can see in druntime/rt/aaA.d, the bucket is chosen by dividing the key hash modulo the number of buckets. The number of buckets is a prime number (x in [31, 97, 389, 1543, ...]), so it is very unlikely to write a hash function that would give different results but the same (i % x) value. The most probable cause would therefore be a hash function implementation that gives the exact same hash for a prepared set of keys. Then you'd get the worse case scenario in which you have to walk a list and compare keys one-by-one in O(n). But that's not a problem with the associative array implementation. It's a bad hash problem.
Re: Your 02.14
On 2015-02-14 at 21:41, ketmar wrote: i made a present for myself (as i really really love myself very much): a minimalistic LISP interpreter (yeah, i need a *small* scripting language, and memory/speed doesn't matter in this case, only source code size). and i titled it MILF. MILF as in Minimalistic Interpreter of Lisp Forms or Minimalistic Instant Lisp Fix? ;)
Re: Testing package proposed for Phobos
On 2015-02-11 at 11:58, Walter Bright wrote: Here's another stab at it: http://digitalmars.com/sargon/asinputrange.html I see four lights, err... spaces. There are four spaces. :)
Re: Git, the D package manager
On 2015-02-08 at 14:59, Russel Winder via Digitalmars-d wrote: Well clearly it should be rejected, you have to s/Ruby/Python/ ;-) LOL As far as I can tell Rake remain the de facto standard tool in the Ruby community and absolutely nowhere else. That's by design. A rake gathers hay towards the person using it, and makes the reverse, spreading, very inconvenient. :)
Re: A safer interface for core.stdc
On 2015-02-08 at 03:19, Andrei Alexandrescu wrote: Indeed we have no safe way to wrap free. How about this to prevent double free: Wrapped malloc keeps a static thread-local lookup structure for successful allocations (if having to release memory from the same thread is an acceptable requirement). Wrapped free looks up the pointer in that lookup structure and, if found, frees memory, removes the lookup entry and sets the argument of the call to zero (if it was a pointer) or sets its length and ptr to zero (if it was a dynamic array). It's not completely safe, but for that GC would have to be used instead.
Re: Zero-length static array spec
On 2015-02-07 at 13:21, Iain Buclaw via Digitalmars-d wrote: foo(&p.data)// fine, ubyte* This is OK - gets passed as ubyte* bar(p.data[i]) // fine, ubyte (or memory violation) This is OK - gets passed as ubyte - though will throw arrayBounds error unless -noboundschecks. xxx(p.data) // ERROR, makes no sense, shouldn't compile This is OK - gets passed as ubyte[] - the dynamic array will have a length of '0' and the ptr to &p.data. Oh, I see. That is quite a nice solution. Better than compilation error.
Re: Zero-length static array spec
On 2015-02-07 at 00:42, David Nadlinger wrote:
Imagine you have this in your program:
---
void foo() {
int[0] a0;
int[0] a1;
...
int[0] a99;
// Do something with them.
}
---
How do you choose the addresses for a0 through a99 so that they are distinct,
but you don't end up allocating 100 bytes of stack memory?
Forgive my ignorance and perhaps not seeing the whole picture, but when I read
this:
A static array with a dimension of 0 is allowed, but no space is allocated for
it. It's useful as the last member of a variable length struct...
i am convinced that a0, ..., a99 are not variables but rather *labels* and
should point to *the same address* of whatever could be put in that place (with
1-byte alignment). I do not understand why would they ever point to different
places. Wouldn't that make them useless when used in structs like the following
one (or to access stack, like above)?
struct Packet {
int a, b, c, length;
ubyte[0] data;
ubyte[0] payload; // just a superfluous alias to data
}
unittest {
Packet p;
assert(p.sizeof == 16);
assert(&p + 1 == cast(void*) &p.data);
assert(&p + 1 == cast(void*) &p.payload);
}
As for passing it around, it doesn't make sense, it is like passing an argument
of type void, so shouldn't be allowed. Only a pointer to a zero-length array or
a specified element would be fine:
foo(&p.data)// fine, ubyte*
bar(p.data[i]) // fine, ubyte (or memory violation)
xxx(p.data) // ERROR, makes no sense, shouldn't compile
Re: H1 2015 Priorities and Bare-Metal Programming
On 2015-02-03 at 18:53, captaindet wrote: i am a simple user writing mostly programs to crunch my scientific data. i'd like to move my C code to D. but i deal with GBs of data that i have to sieve through many times. in C, i have lots of repeating integer stunts in the inner loop that must be inlined. i used macros for this. if i cannot mark small helper function in the inner loop so that they are guaranteed to be inlined, i am screwed. i would have to copy and paste lots of code, making the result worse than the C code. Or you'd have to use mixins as you would use C macros. But that's bending over backwards compared to inlining.
Re: H1 2015 - db access support in Phobos
On 2015-02-03 at 16:30, Daniel Kozák via Digitalmars-d wrote:
V Tue, 03 Feb 2015 15:20:40 +
Vadim Lopatin via Digitalmars-d napsáno:
Update in v0.2.19: you can specify field list for select
writeln("reading all user table rows, but fetching only id
and name (you will see default value 0 in flags field)");
foreach(ref e; stmt.select!(User, "id", "name")) {
writeln("id:", e.id, " name:", e.name, " flags:",
e.flags);
}
output:
reading all user table rows, but fetching only id and name (you
will see default value 0 in flags field)
id:1 name:John flags:0
id:2 name:Andrei flags:0
id:3 name:Walter flags:0
id:4 name:Rikki flags:0
id:5 name:Iain flags:0
id:6 name:Robert flags:0
This is dangerous zone, you shoud not do this ;-). In my work I have
writen our ORM-like db layer which has this funcionality (mainly
performance reasons) but if I can go back in time. I will be against
such a misfeature.
A misfeature? If the ORM only allowed SELECT *, it wouldn't be of much use with
records containing blobs or big amounts of other data. If the object was
retrieved only for read and to update a few fields, pulling all columns would
be very wasteful.
So now, for the purpose of performing an update, each field could be marked as
dirty (if its value has changed) or inconsistent (if it wasn't pulled from the
database at all). And BTW, each should be Nullable to prevent loss of
information for columns that aren't marked as NOT NULL. ORM easily becomes
complicated...
Re: [website redesign] PR for the one with the big red menu bar
On 2015-02-02 at 18:29, Nick Sabalausky wrote: On 01/27/2015 03:02 PM, anonymous wrote: PR: https://github.com/D-Programming-Language/dlang.org/pull/869 - For details see here. Live version: http://ag0aep6g-dlang.rhcloud.com - If you've visited this before, you may have to clear your cache to see the proper logo color. The right-side panel is WAY too prominent. It takes nearly an entire third of the horizontal space, leaving the main content much to squished. Yes. The main content is way too narrow when the right panel finally disappears. The upper part of the left-side panel has far too much wasted vertical space. The main links don't even start until almost halfway down the first "screen" (ie, before you start scrolling). I love the logo with the horizon and the color scheme of the navigation panel, but I also feel that too much precious space above the fold is wasted. Compare the two: http://fgda.pl/static/dlang_org_sidebar.png
Re: D, windows developement, frustration and fish
On 2015-02-01 at 12:29, ketmar wrote: the best thing, of course, is to kill that ancient toolchain altogether and switch to binutils, they are already working for mingw and they are free. and there is COFF writer already too. so only one little step is needed: drop dmc and build dmd with mingw. and with dmc all it's tools will go. besides, this will allow makefile unification, as alot of "posix.mak" can be reused for mingw builds. i did that myself while hunting for multithreading heisenbug. the side effect of switching to mingw was faster dmd.exe: compiling phobos took only 2/3 of time comparing to dmc version. What? How did you do that and what problems did you encounter? Does it work with regular DMD/Druntime/Phobos or only with Aliced[1]? [1] I only saw it mentioned once in the forum. What exactly is it?
Re: std.sevenzip - Do you need it?
On 2015-01-30 at 20:39, H. S. Teoh via Digitalmars-d wrote: OTOH, wouldn't a clean-room reimplementation of it be permissible? (And perhaps even desirable, since it can then take advantage of D instead of just wrapping around C/C++ code?) Maybe clean-room won't be necessary. We were looking in the wrong place. There is http://www.7-zip.org/sdk.html - which is in public domain, and contains LZMA, LZMA2, and XZ compression and decompression algorithms in C, plus a C/C++ minimal utility for handling 7z files. It probably doesn't handle encryption and definitely doesn't cover other archive formats supported by 7-zip (the application). Well, screw RAR, because no-one is allowed to write a compressor anyway, but add support for TAR and perhaps BZIP2 and we should be quite happy. And, if someone was willing to implement DEFLATE, even using zlib wouldn't be required any more (which some don't like, as mentioned below). :) On 2015-01-30 at 21:34, Brad Anderson wrote: As other said, the license is an issue but even if it weren't people are pretty opposed to including third party libraries in Phobos these days. The inclusion of zlib and (especially) curl are often considered a mistake. I'm mostly of the opinion that we should be relying less on Phobos and more on dub going forward. sevenzip would be a great addition to the dub registry.
Re: std.sevenzip - Do you need it?
On 2015-01-30 at 19:12, Max Klyga wrote: Is this a port or binding for some existing library? Also all phobos submissions must be Boost licenced. If this is a binding or code cannot be relicenced this might better be suited for inclusion in DUB registry I wonder if it would be possible to get special license terms for the use of 7zip in Phobos. LGPL is not compatible with the Boost License. Suppose that you write a closed-source application. Apart from having to inform about the use of an LGPL library in the application, LGPL requires that you allow the user to relink the application with a modified version of the library. That pretty much implies that the application has to be dynamically linked, because if it can't, things become quite problematic. Therefore, sadly, code from 7zip is unlikely to get into the standard library.
Re: [WORK] Simple and very useful stuff more of us could get into
On 2015-01-29 at 23:52, H. S. Teoh via Digitalmars-d wrote: This is the so-called "documented unittest" or "ddoc'd unittest". It's an awesome feature implemented (IIRC) by Andrey Mitrovic that ensures that generated doc examples are compilable and runnable. Preferably all code examples in Phobos should be ddoc'd unittests, so that they won't suffer from bitrot. Yes, it's great. Documentation and unittest combined, DRY, like Python's doctest. It really should be mentioned on http://dlang.org/ddoc.html
Re: [WORK] Simple and very useful stuff more of us could get into
I don't understand. Does putting an empty ddoc comment before a unittest make
the code inside the unittest appear in the documentation as if it was an
Examples: section? Is this behaviour documented anywhere?
///
unittest
{
...
}
Re: accept @pure @nothrow @return attributes
On 2015-01-28 at 23:27, Walter Bright wrote: Good language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program. I'm quite sure I have read this very same thing not so long ago. :)
Re: std.zip
On 2015-01-26 at 03:41, Vladimir Panteleev wrote: How about submitting this patch as a pull request? Thanks for this suggestion. The expanded patch is now merged: https://github.com/D-Programming-Language/phobos/pull/2914
Re: std.zip
On 2015-01-26 at 03:41, Vladimir Panteleev wrote: On Monday, 26 January 2015 at 02:14:00 UTC, FG wrote: http://fgda.pl/static/std_zip.patch How about submitting this patch as a pull request? http://wiki.dlang.org/Pull_Requests OK, I will. First I'll run some tests and perhaps also do the writer. Wouldn't want to waste your time on something that doesn't work.
Re: std.zip
On 2015-01-25 at 17:02, AndyC wrote: I was looking at this bug report: https://issues.dlang.org/show_bug.cgi?id=2138 and sure enough it doesn't handle zipfiles with more than 65K files. If all you need is the ability to read archives with more than 65K files, I have created a small patch for std.zip to support reading Zip64: http://fgda.pl/static/std_zip.patch The writing part of Zip64 archives isn't done, but that should be only a little harder to do. All other limitations of std.zip are still present. But testing would be required. I haven't tried to unpack archives with this code yet, only listed their contents.
Re: Redesign of dlang.org
On 2014-06-01 07:46, Russel Winder via Digitalmars-d wrote: I think having humour on the site is a good thing, cf. the D figure on dlang.org. It would be good to do more with the D figure, or some other mascot. Java has Duke, Go has the gopher [...] Please, no. Whatever you do, don't create something this hideous. :) http://blog.golang.org/gopher
Re: Redesign of dlang.org
On 2014-05-31 22:52, Kapps wrote: One thing that's a bit broken is that "Modern convenience. Modelling power. Native efficiency." wraps to put "efficiency." on a different line. Perhaps the text should be made smaller there. Or just put nbsp between Native and efficiency. As for page background -- yes, it might be a bit too close to the color of the article, especially since there are no borders around it. Works fine here but in worse lighting conditions and on poor displays the contrast should be higher, say, #c0c0c0 instead of the current #d7d6d6.
Re: Vibe.d featured on HN frontpage - upvote to give some exposure
On 2014-05-26 11:26, simendsjo wrote: https://hn.algolia.com/#!/story/forever/0/Asynchronous%20I%2FO%20that%20doesn%E2%80%99t%20get%20in%20your%20way%2C%20written%20in%20D Or a plain old link that always works: https://news.ycombinator.com/item?id=7797979
Re: A graph data structure usable in @safe pure nothrow functions
On 2014-05-25 16:39, w0rp wrote: I have been wanting graph types which can be used in @safe pure nothrow functions. The big blocker on this was what associative arrays could offer. The current associative array implementation couldn't get me all the way there, so I wrote my own hashmap type. get and setDefault are nice, but can be easily done as small UFCS wrappers around the "element in array" expression. What was blocking you in the current implementation of associative arrays? Can't it be fixed without having to come up with a custom map type?
Re: Associative Arrays max length? 32bit/64bit
Bloody Thunderbird. I think I pressed Reply instead of Followup. Sorry, Steven.
On 2014-05-19 15:31, Steven Schveighoffer wrote:
No, in that DMD file, the bucket is a tree, not a doubly-linked list.
Silly me. A look at the body of delnodes should have made it clear that it's a
binary tree.
opCmp is not used in D's AA.
Really? Then what does TypeInfo.compare(void*, void*) use? For example here:
auto key_hash = keyti.getHash(pkey); Entry *e;
/* ... */
if (key_hash == e.hash) {
auto c = keyti.compare(pkey, e + 1);
if (c == 0) goto Lret;
}
Re: Associative Arrays max length? 32bit/64bit
On 2014-05-17 22:30, bearophile wrote: Sorry, I didn't know the linked list is sorted. It's scanned sequentially, because you can't use a binary search on a regular linked list. Perhaps a skiplist is better to avoid O(n^2) behavour in presence of attacks or degenerate cases (in past the AA used a tree there). if (nodes > buckets_length * 4) rehash(); Skiplist doesn't seem necessary. As seen above, there shouldn't be much of a problem with long lists accumulating in some selected buckets, as long as the hash function is a proper hash (i.e. for any set of x (especially consecutive ones like 0, 1, ... n) hash(x) values cover the range of size_t evenly).
Re: Associative Arrays max length? 32bit/64bit
On 2014-05-17 21:35, bearophile wrote: FG: and don't forget the extra memory needed to store the tree for fast key look-up in the hash array. I think D now uses a linked list for the collision chains (so opCmp is useless, despite it's still required for the hashing protocol). Indeed, I just read https://github.com/D-Programming-Language/dmd/blob/master/src/backend/aa.c Key hash is divided modulo the number of buckets and each bucket points to an ordered double-linked list. That list is walked left or right depending on what value Typeinfo::compare returns for two keys. Hmm... isn't opCmp used by that function? Why useless?
Re: Associative Arrays max length? 32bit/64bit
On 2014-05-17 12:46, sdvcn wrote:
int main(string[] argv)
{
auto flog = File("results.txt", "w");
size_t[string] bary;
for(size_t i=0;i<(size_t.max -1);i++)
{
bary["Key:" ~ to!(string)(i)] = i;
flog.write("stop i=" ~text(i));
flog.seek(0);
flog.flush();
}
return 0;
}
results:
start i=0
stop i=36495998
---
start i=0
stop i=36495992
start i=36495998
stop i=72991099
I guess not see why Overflow.
This code will always make you run out of memory. Why are you surprised?
Each key in the hash table is a string in the form "Key: 1234", so at stop (i =
36495998) the string has 13 bytes. Add to that 16 bytes for slice of that string
(assuming 64-bit architecture), 8 bytes for the value, some space wasted on alignment,
and don't forget the extra memory needed to store the tree for fast key look-up in the
hash array.
You said that you have 16 GB of memory. At i = 36495998 that means at most 470
bytes per item.
As for capturing the problem, you can catch the Out-of-memory error but you
cannot do that by catch(Exception e). OutOfMemory is not an Exception. It is an
Error. Here is the updated example:
import std.stdio, std.string, std.conv, core.exception;
int main(string[] argv) {
size_t[string] bary;
size_t i = 0;
try {
for (; i < (size_t.max - 1); i++)
bary["Key:" ~ to!(string)(i)] = i;
} catch (OutOfMemoryError e) {
writeln(e);
}
writefln("Last index was: %d", i);
return 0;
}
Re: Learn D in x minutes
On 2014-05-14 05:22, Steve D wrote: I came across this site http://learnxinyminutes.com/ which gives a summary of most of the popular languages. Yes, it's definitely a good idea from a promotional point of view to put D in all those places where languages are compared. Then -- like on http://rosettacode.org -- one can compare how typical tasks are written and get sold on D's relatively sane approach. OTOH, seeing the title "Learn X in Y minutes" makes me smile. :) http://norvig.com/21-days.html
Re: Migrating dmd to D?
On 2013-03-11 18:36, Iain Buclaw wrote: (The D conversion seems to think it's lisp). (LOL)
Re: I'd just like to say thanks for D
On 2013-03-11 06:22, H. S. Teoh wrote: And now it's 2013 and g++ is still defaulting to the *old* C++?! I don't mind having to add -std=c++11 as much as dealing with its incomplete implementation. Still have to use the pcre library for regular expressions. http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x Waiting gets me nervous, so in the mean time I'll rather write more D. - And then another roadblock: the compiler says, "hey, buddy, std::hash hasn't been specialized for cache_key_type yet, so it doesn't know how to compute the hash value of the key, and so I can't instantiate that template for you!". Oh, yes, been through this. Why is there no hash function for const char*? The second thing is that not everything has a string representation that can be output on screen without doing extra processing. to_string just barely started working in newest MinGW. If you don't have that available and ask for a different but still _simple_ way to convert a number to string, you are shown the good old stream code: std::stringstream ss; ss << number; out = ss.str(); Seriously? If I could at least chain that... out = std::stringstream(number).str(); Unfortunately, no. So I end up adding my own functions in every project for many trivial tasks, which should be doable out-of-the-box with minimal effort. Yep, to_string helps, but C++11 and its complete support are coming much too late. Therefore, being quite impatient, I'd also like to say thanks for D. :)
Re: Additional Binary Operators
On 2013-03-01 23:56, Era Scarecrow wrote: Those operators seem more useful for scientific math. I wouldn't want them added to to the core language though. ASCII can be typed with (almost) any keyboard and use any editor (new or old); You can still read source code if outputted to a dumb terminal rather than getting odd symbols (whitespace as well) and may be tearing your hair out wondering what this UTF-8 symbol is or what it means. Gotta grab that old APL keyboard from the attic...
Re: bit-level logic operations on enums
On 2013-03-01 20:56, Steven Schveighoffer wrote:
or use normal int enum instead of byte enum, if you have the space for it.
It still fails if int is the enum base. The issue is not whether the bit
pattern will fit in the base type, the issue is assigning an enum from int.
What fails? Are we talking something compiler-version-specific here?
enum BING_e { ... } ... // rest the same as in original post
BING_e c = a & b; // this works for me
BING_e d = a & 1; // fails, and it should fail
Re: bit-level logic operations on enums
On 2013-03-01 20:13, Steven Schveighoffer wrote: D does not (or at least should not) allow assignments of integers back to enumeration types. You have to cast. or use normal int enum instead of byte enum, if you have the space for it.
Re: bit-level logic operations on enums
On 2013-03-01 13:56, d coder wrote: Currently DMD allows me to bit-or two enum variables, but not bit-and. For example in the following code, DMD is OK with line 6, but gives an error for line 9. I do not see any logic why DMD does that. Is it a bug or is it intended. Strange. | and ^ work but & fails. The promotion from byte to int is unnecessary in any of those 3 ops. It works correctly for non-enums: byte x, y, z = 1; z = x | y; z = x ^ y; z = x & y; z = x >> y; // all OK z = x << y; z = x + y; z = x * y; z = x / y; // can't convert int to byte Not sure why byte enum would be handled any differently than simple byte.
Re: Proposal for SentinelInputRange
On 2013-02-28 23:27, Walter Bright wrote: I've spent a lot of time profiling compilers. The result is pretty obvious - dmc is by far the fastest C/C++ compiler available, and dmd blows away about every other language in compile speed. Making this happen means you go after everything that eats time. Even a 5% improvement is a big deal. All those drips and draps add up to big speed increases. I get that, but it doesn't require introducing a new type of range.
Re: optional parens everywhere except last position of function chain.
On 2013-02-28 23:00, timotheecour wrote: spontaneously... I love it! is there any other spontaneous feedback? Spontaneously... I hate it. :) I prefer optional parentheses everywhere.
Re: Proposal for SentinelInputRange
On 2013-02-28 17:43, Walter Bright wrote:
Consider the following code from lexer.c:
p++;
switch (*p)
Written using an InputRange:
popFront();
switch (front)
That code is INVALID. This is why a SentinelInputRange is necessary. You can't
just use an InputRange in an invalid manner by convention.
I do not understand... Why make a special type of InputRange when you can
achieve exactly that with a normal string with an added extra '\0' at the end
and then use it without any calls to empty():
while(1) {
...
popFront();
switch(front) {
case '\0': return;
...
}
}
Cstrings are a very special case because we know the terminator beforehand and
the check is trivial CPU-wise.
Re: Request for comments: std.d.lexer
On 2013-02-28 16:34, Andrej Mitrovic wrote: On 2/28/13, Brian Schott wrote: http://hackerpilot.github.com/experimental/std_lexer/images/times4.png That's a nice plot, but what is the X axis? Lexing time in milliseconds.
Re: Migrating dmd to D?
On 2013-02-28 16:07, Jacob Carlborg wrote: On 2013-02-28 16:02, FG wrote: frankly, I don't care what language the compiler is in, as long as I don't have to install a JVM to use it. :) Then .Net it is :) /irony I was wondering if I should have also mentioned .Net. Now I know the answer. :)
Re: Migrating dmd to D?
On 2013-02-28 11:58, Dicebot wrote: But issues with LDC and GDC need to be settled first. If D front-end in D considerably harms any of those, it is a complete no-no, even if porting will be perfect. Just not worth the loss. Indeed, but even if LDC and GDC don't stop this from happening, I'm more worried (as someone willing to write more of his programs in D instead of picking C++) about stretching resources too thin on this one project, while there are tons of more important things to do first (from my POV). Let's see: 1) shared libraries (loading and being loaded), 2) GC, const refs, manual MM, containers managing their memory, 3) stop hiding AA's implementation, 4) improve libraries: bigint, xml, you name it, ... n) rewrite the compiler's frontend. I'm sure you can find a lot more to fit into the [5..n]. Even the infamous properties could rank higher than this migration, because, frankly, I don't care what language the compiler is in, as long as I don't have to install a JVM to use it. :)
Re: Migrating dmd to D?
On 2013-02-28 02:03, John Colvin wrote: Could you perhaps detail the process you went through to get opencv to D? It would be a big help to me as I'm currently staring down the barrel of having to re-implement a chunk of OpenCV in D for a data processing app. I second that request! :)
Re: D is coming to a town near you
Those are two different approaches: D starts lua, and lua finishes before D. It's _embedding_ LUA in D. Can be easily done now. Try lua starts D, and D finishes before lua. It's _extending_ LUA with D. Requires good D shared library support. :(
Re: The DUB package manager
On 2013-02-20 11:32, Moritz Maxeiner wrote: As for the X11 stuff, that's still more manual than I'd like when it comes to X11. (Like I said, I've had *BIG* problems dealing directly with X11 in the past.) But I may give it a try. I'm sure it's improved since the nightmares I had with it back around 2001/2002, but I still worry *how* much improved... Heck, I've even had X11 problems as recently as Ubuntu 10. Ah, okay, that's strange but I can understand that. The only problems I ever had with X was that I had to add an InputClass to the evdev file because evdev otherwise kept refusing to enable USB mice(s). Diving deeper into the OT... Not strange at all. I had similar experiences around 2001 when I bought a new immitation-of-ATI GFX card -- first there were no drivers for it and, when they finally showed up (proprietary and others), after weeks of configuring Xorg, I still couldn't make 3d acceleration work and ended up without it for the next few years. Not only Xorg are a problem. Even today I can't fire up the newest Ubuntu install CDs without the screen going blank. That's how bad things are with X and even framebuffer console. So I am not surprised hearing about problems in this domain. As for package managers, I'm fine with using the OS ones for almost everything and Python's own system for its extra modules (only because I consider it an ecosystem of its own). Still, I compile some programs and libs myself (when their most current version is required), but only when they aren't a dependency for something I wouldn't want to compile on my own. I am still not convinced why D would need a package manager. Why not use a standardized build script with dependency checks or just use CMake like everybody else does?
Re: What's missing from Phobos for Orbit (package manager)
On 2013-02-13 09:45, Jonathan M Davis wrote: On Wednesday, February 13, 2013 09:34:36 Marco Leise wrote: * format - A simple formatting function http://dlang.org/phobos/std_metastrings.html#.Format format now works in CTFE. Format should go the way of the dodo. It's insanely inefficient. Could you please add this info to std.metastrings' ddoc?
Re: What's missing from Phobos for Orbit (package manager)
On 2013-02-12 20:38, qznc wrote: Do not go down that rabbit hole! Just skim over the following links to get an idea how complicated this becomes. I know that. Usually I define my own pluralize for the one or two languages I use. Good enough solution when you don't need to have your software translated into all possible languages. Last chat we had about i18n and making our own flavor of gettext ended up with the statement that apparently we need keyword arguments in writefln format strings first... so I decided to rest my case. ;)
Re: What's missing from Phobos for Orbit (package manager)
On 2013-02-12 15:21, Steven Schveighoffer wrote:
string pluralize(string x, int count)
{
return count > 1 ? x ~ "s" : x;
}
You mean: return count != 1 ? x ~ "s" : x;
For special cases there could be a third optional argument:
string pluralize(int count, string sng, string pl="") {
return count == 1 ? sng : pl.length ? pl : sng ~ "s";
}
writeln(pluralize(2, "cat"));
writeln(pluralize(2, "radius", "radii"));
That's for simple English-only pluralization, before we jump into translations.
Re: Preliminary submission - std.rational and std.typelist
On 2013-02-12 04:03, bearophile wrote: But I have not yet understood why D isn't using GMP as Haskell does. Especially that when you get dynamic libraries working it would create good common ground for interoperability. In theory Open Source is meant to give a huge help to code reuse, in practice you see wheel reinvention all the time. D should use bigints from GMP, a garbage collector developed in conjunction with Rust and Mono developers, the back-end (that supports 32 bit Windows exceptions) on LLVM, etc. There's this terrible and often terminal Not-invented-here disease. ;) Not sure though whether what's possible in Mono's GC can be ported to D. Thankfully Phobos uses Curl :o) Yay!
Re: Allow object local MessageBox's in concurreny
On 2013-02-12 14:47, monarch_dodra wrote: Does anybody have any preliminary feedback, objections, remarks? You will encounter a possible problem on main thread termination. Normally it's done automatically in static ~this(): a linkDead message is sent to all spawned threads listed in "links" and then close() is called on the mbox. Those linkDead messages have thisTid as sender and that's a problem, because with custom mailbox thisTid != ownerTid, so the child won't treat that message as OwnerTerminated. It's caused by "links" being global and populated by spawn(). And if you make your own spawn, that doesn't touch links, the child won't be informed about parent's sudden death. How do you work around that?
Re: Boost.units ported to D
On 2013-02-11 20:08, bearophile wrote: It seems a lot of work. But code like this is not encouraging Nah, it's quite digestible after replacing "Quantity" with "Q". But would anyone doing numerical processing ever use typed units?
Re: DIP26: properties defined
On 2013-02-09 12:57, Robert wrote: As you can't actually encapsulate the array with free functions just do: ref T front(T)(T[] arr); There is no value in using an actual setter. Ah, sorry, you're right. It's an lvalue, so no setter is needed.
Re: DIP26: properties defined
On 2013-02-09 12:32, Robert wrote:
Has anyone actually read the DIP?
Simply don't call it property.
Fine for getters but this time it will break things for setters:
@property void front(T)(T[] arr, T elem) {...}
and either all code with assignments would have to be changed
or assignments remain allowed for functions -- neither is good.
Re: DIP26: properties defined
On 2013-02-09 11:31, Jonathan M Davis wrote: I just went over this with Kenji in his thread "Partial modification of DIP23 to allow module level property." You _must_ be able to rely on front being a property. front getter MUST be a property... as in RFC2119's MUST?? So all those 75 std @property ref T foo() are also here to stay for good? Bah, banning ref fixed some things, but now it's back to square one again. Maybe it's time to drop the property subject and move on? :)
Re: DIP26: properties defined
On 2013-02-09 08:19, Dmitry Olshansky wrote:
NoUFCS for properties
Properties protect the access to a field of an entity (class/struct/module),
so they actually have to be defined within the entity they belong to, just as
a field would.
Rubbish.
std.array:
@property auto front(T)(T[] arr)
{
return arr[0];
}
Yeah, banning UFCS for properties is too farfetched.
Re: DIP26: properties defined
On 2013-02-09 02:36, Timon Gehr wrote: "Taking the address of a property As this is illegal for properties..." @property ref int foo(); int* y = &(&foo)(); Yes, but this DIP makes it invalid to define a @property ref T foo(). To use ref it would have to be a normal function: ref T foo(). So finally this example no longer ruins the property construct. :)
Re: std.xml validity checking is absurd
On 2013-02-08 18:16, Ali Çehreli wrote:
void foo(double a, double b)
{
enforce(a > b, "a must be greater than b");
sqrt(a - b);
}
void main()
{}
See how sqrt() is *not* on my module's API? I have already enforced that my API
function foo() is called correctly. My call to sqrt() is an internal call of my
module. Therefore the checks inside sqrt() should not be repeated beyond my
testing stage.
This calls for some way to be able to call sqrt without running checks:
sqrt(a - b); // would run all "in" checks
#sqrt(a - b); // tells the compiler to bypass the "in" checks in sqrt
Sorry for inventing clumsy syntax, but you get the picture.
Naturally it won't bypass checking if sqrt is in a compiled library.
Re: Taking address of properties
On 2013-02-08 21:13, Steven Schveighoffer wrote: I can't find anything about that front has to be a property here: http://dlang.org/phobos/std_range.html#isInputRange all it states that you can get the current element by issuing: r.front which would still be possible with the optional parentheses of DIP23. Technically this is true. But the expectation is that r.front is a property/field, not a function. That aspect is difficult to capture in a template, especially in the current implementation where @property on a getter is essentially redundant info. There may be nothing saying that r.front has to be a @property, but don't forget setters. There are many examples of the following statement: r.front = val; Just look at the sources: grep -R "\.front = " ./src/phobos/ General agreement is that plain functions shouldn't be allowed to be called like setters, with assignment operator. So what now? Should all that code be changed to use r.front(val) instead? Or should void front(T val) remain a @property, while ref T front() becomes a plain function?
Re: Request for comments: std.d.lexer
On 2013-02-08 17:35, Brian Schott wrote: GDC decided to randomly not fail to build on my system, so it's time for MOAR CHARTS. Interesting. Seems that LDC is faster than GDC but has a bigger start overhead. OT: Why is the chart's legend in reverse order? :P
Re: std.xml validity checking is absurd
On 2013-02-08 14:59, bearophile wrote: Stewart Gordon has opened this ER (worth voting for): http://d.puremagic.com/issues/show_bug.cgi?id=9483 A good proposal now, when it's the callee that does contract validation. And easier to do than "move in contract checking to the caller side".
Re: Taking address of properties
On 2013-02-07 19:05, Robert wrote: taking the address of the ref return value of a property is of no value at all. If you want someone to be able to take the address of a field, you should make it simply public (without @property), because the @property accessor methods won't gain you anything in this case. Once again. Ref returns are commonly used in ranges. I'd say that being able to take address of someRange.front is good for example for interoperability with external C libraries. Temporarily using a pointer here should be fine. Having said this, I think the solution to the & operator is pretty straight forward, it takes the address of the accessor function [...] Tada. Problem solved :-) Didn't solve the one mentioned above. So either I am wrong, you are wrong or range.front shouldn't be a @property?
Re: const(X) member of Y
On 2013-02-06 23:14, Maxim Fomin wrote: On Wednesday, 6 February 2013 at 21:47:35 UTC, Dan wrote: On Wednesday, 6 February 2013 at 20:30:40 UTC, Maxim Fomin wrote: The fact that bar() does not work and (&bar)() works is terrific. Sorry - but I don't understand what is terrific? Is this sarcasm? This means it is a huge hole in a type system. Ah, so you meant: terrifying or horrific. :)
Re: Expanding Phobos from a flat hierachy
On 2013-02-07 09:19, Jacob Carlborg wrote:
That's way I originally chose Ruby, because it can look just like JSON:
foo = {
a: 3,
b: 4
}
This looks like JSON but doesn't look like Ruby. :)
Re: proposal to disambiguate &a.fun: disable optional parenthesis INSIDE &() expression
On 2013-02-04 15:42, Timon Gehr wrote: On 02/04/2013 02:37 PM, FG wrote: ... The change in behavior of &(expr) makes sense in the light that "expr" should behave the same in every context, not just in &(...), i.e. call foo(). ... The entire optional parens/@property thing is about (limited) context-dependent behaviour! This line of reasoning is simply wrong. There is no difference whatsoever between &expr and &(expr). Indeed, currently there isn't and, considering the use of optional parentheses for delimiting and grouping, it also makes sense to treat &expr as &(expr). Oh, wait, no -- this leads straight to the OP's idea, which is: Rule of optional parentheses omission doesn't work in the context of '&'. Properties on the other hand need a different kind of treatment here. Forcing properties to also use parentheses here is a bad idea: &obj.prop; // a delegate? &obj.prop(); // address of the returned referenced data? Bad! This would make some typical code awkward: void* p1 = &someRange.retro.front; // suddenly it's a function pointer, not pointer to the element :( void* p2 = &someRange.retro.front(); // but having to add () just feels wrong. Therefore it's better for &prop to become the address of return data and to use some __traits or special member (like prop.__delegate) for taking address of the property: auto a = &someRange.retro.front; // address of element, yay auto b = someRange.retro.front.__delegate; // a delegate of front Simple enough? To specify exactly which prop we want it could even become: prop.__delegate(RetType, FirstArgType, SecondArgType)
Re: proposal to disambiguate &a.fun: disable optional parenthesis INSIDE &() expression
On 2013-02-04 11:20, monarch_dodra wrote: As I asked in the other thread: What is the point of even allowing taking the address of a property function? If a property is designed as something that can encapsulate and emulate a field, then it makes to sense to get the address of the getter (As far as I can tell). Yes, but this is not just about properties but also normal functions: foo; // calling foo &foo;// delegate of foo &foo(); // calling and taking address of ref return &(foo());// calling and taking address of ref return &(foo); // OLD: delegate of foo &(foo); // NEW: calling foo and taking address of ref return The change in behavior of &(expr) makes sense in the light that "expr" should behave the same in every context, not just in &(...), i.e. call foo(). As for properties, they will never be truly exchangeable with variables, therefore being able to pass around their function pointers is useful. Naturally taking their address doesn't have to follow the same rules, but why shouldn't they behave like other functions in "typeof(&prop)"? If we already have optional parenthesis, then why even bother having property getters? They would end up being exactly the same thing as a normal function... Indeed, their existence is not essential. They may be more useful when the operator rewriting is done. The biggest problem is with the amount of code that uses "prop = x" syntax, which doesn't play well with optional parentheses. if "b" is a property, then "a.b" should mean "the thing returned by b", *regardless of context*. Simple as that: "&a.b" => address of what is gotten with "a.b" "&(a.b)" => address of what is gotten with "a.b" For me only "&(a.b)" is about the context of "a.b". "&a.b" is something completely different from "a.b", hence doesn't have to produce same output.
Re: Request for comments: std.d.lexer
On 2013-02-04 08:57, Jacob Carlborg wrote: On 2013-02-04 01:50, FG wrote: Ah, fine. Then it's not that bad. :) Have you already made it use slices of the whole source, without copying the string values of tokens? What kind of optimizations have you made? That would be interesting to hear. Three times slower than DMD doesn't sound good. I know that DMD is fast, but three times. Looking at the current source, there is now a StringCache to hold the strings. It is however also used to store all those long comments, so I believe quite some time is unnecessarily wasted on generating hashes for them. But probably there are other parts slowing things down.
Re: Request for comments: std.d.lexer
On 2013-02-04 01:41, Brian Schott wrote: What are you comparing here? How do you time DMD's lexing stage? A simple hack of module.c that prints out the file's token count and then calls exit(0). Ah, fine. Then it's not that bad. :) Have you already made it use slices of the whole source, without copying the string values of tokens? What kind of optimizations have you made?
Re: Request for comments: std.d.lexer
On 2013-02-04 01:22, Brian Schott wrote: After several hours of optimizing I've managed to make it so that dmd's lexer is only three times faster. What are you comparing here? How do you time DMD's lexing stage?
Re: drop html docs from the dmd distribution?
On 2013-02-04 00:58, Walter Bright wrote: They seem rather pointless, considering: 1. them being on the web is better anyway 2. the new pdf version of the spec Theoretically: It's useful, because the docs' version matches the compiler, while the website only lists current documentation. Practically: I'm quite sure few people read those offline html docs.
Re: DIP23 draft: Fixing properties redux
On 2013-02-03 16:35, TommiT wrote:
What happens here?
struct S
{
int _n;
@property ref int prop()
{
return _n;
}
}
@property void prop(ref S s, int n)
{
s._n = 42;
}
void main()
{
S s;
s.prop = 10;
}
This is an interesting problem.
1) I think setters should outrank getters when there's an assignment.
2) Also actual methods outrank UFCS free functions with same arguments.
It's a question which rule has higher precedence.
I think no.2 does and then _n becomes 10.
Re: DIP23 draft: Fixing properties redux
On 2013-02-03 14:33, kenji hara wrote: Two arguments @property function would be declared only in module level, and just be called with UFCS. I think that functions annotated with @property must not have default parameters. As you show, it would introduce not little ambiguity. With such constraints two argument property functions are fine, as long as it is their second argument that is most significant in the assignment. The DIP's 42.fun = 43 is the ideal counter-example of that. :)
Re: DIP23 draft: Fixing properties redux
On 2013-02-03 09:16, Andrei Alexandrescu wrote:
Walter and I have had a discussion on how to finalize properties.
Very reasonable in the majority of the proposal.
I can't, however, get my head around 2-arg property functions:
int a_;
@property void a(int v, bool rev=false) { a_ = rev ? -v : v; }
a = 10; // fine
10.a = true; // this feels backwards, true is just an extra flag
The boolean flag is optional and making it the rhs of the assignment suggests it
is the value which will be set. On the other hand switching argument positions,
resulting in true.a = 10 also feels very strange.
I'd say: allow only 0 or 1 argument in properties.
If you need more arguments, write a normal function for it.
Re: PDF spec
On 2013-02-02 17:57, Andrei Alexandrescu wrote: Links remain an unresolved problem for now. Might as well leave the internal links black for now. Overall great improvement! A much smaller number of page overflows than before. Only thing bothering me are table captions left on the previous page, while table body is on the next page. Perhaps add more stretchable glue before captions?
Re: [your code here]
On 2013-01-31 15:17, bearophile wrote: FG: Strange. No problems here. Only had to switch from dmd32 to gdc64 with 1GB or bigger files. Tested on win7-64. How much memory is it using? What's the performance compared to the diff tool? Two identical files, 1069 MB each. Program compiled with GDC, 64-bit. Used 6272 kB private mem / 2144 MB working set, and took 13.5 seconds. Cygwin's diff took only 1.85 s.
Re: [your code here]
On 2013-01-31 14:21, bearophile wrote: Especially when you are comparing 500 MB files in a loop. :) I have had problems comparing with this program a single pair of files that large... Strange. No problems here. Only had to switch from dmd32 to gdc64 with 1GB or bigger files. Tested on win7-64.
Re: Request for comments: std.d.lexer
On 2013-01-31 13:14, Jacob Carlborg wrote: Just thinking out loud here. Would it be possible to lex a file in parallel? Cutting it in half (or similar) and lex both pieces simultaneously in parallel. Do you know where you can safely cut it without having it lexed beforehand? :)
Re: [your code here]
On 2013-01-31 12:38, Namespace wrote: If you want to do something, then take destroy. AFAIK delete destroy _and_ release the memory immediately. 'destroy' doesn't. And that's why delete is valuable (at least on 32-bit windows). Especially when you are comparing 500 MB files in a loop. :)
Re: Request for comments: std.d.lexer
On 2013-01-30 17:50, Dmitry Olshansky wrote: Instead I suggest to try and allocate a big block of fixed size (say about 16-64K) upfront and copy identifiers one by one there. When it fills just allocate another one and move on. Yeah, similar to what I suggested, except that probably it would be good to also have a look-up structure for identifiers, so that only unique strings go into those blocks. I wonder what would be a practical data structure for such look-ups: A trie is great except for the implementation hurdle to keep it also in one or a few memory blocks to prevent frequent allocations. A simpler approach would be to make it an array of (hash, string_slice) pairs, sorted by hash (of the identifier) - lots of string scanning though. What do you think?
Re: Request for comments: std.d.lexer
On 2013-01-30 10:49, Brian Schott wrote: If my math is right, that means it's getting 4.9 million tokens/second now. According to Valgrind the only way to really improve things now is to require that the input to the lexer support slicing. (Remember the secret of Tango's XML parser...) The bottleneck is now on the calls to .idup to construct the token strings from slices of the buffer. Yep. I'm eager to see what timings you get with the whole file kept in memory and sliced, without copying token strings.
Re: Possible @property compromise
On 2013-01-29 18:10, Steven Schveighoffer wrote: If there is no y field, then then the compiler ALSO tries: x.setY(...); [...] One problem I will note with this scheme, some Unicode symbols that may be valid D symbol starters may NOT have an upper/lower case, making it impossible to use those as properties. But I admit having an English bias so I don't see this as a large problem. Besides, "set" is already English. It's inconceivable why on earth would you call this a "compromise". :)
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On 2013-01-29 15:00, eles wrote: well, make those parens omittableonly if the function name is followed by a dot. This is a sound idea for typical cases: typeof(foo); // works, x = a.chain.of.operations(); // looks good and () are informative. Only the problem with functions returning callable objects remains: write(foo()()); // ugly but explicit and we know what happens, foo().write(); // is it the phobos write or a write method // of the object returned by foo?
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On 2013-01-29 13:13, eles wrote: I also find writeln = "hello" very confusing. Is that a variable assignment, btw? What do you think? To me this is just a lousy party trick... pulling a rabbit out of the hat. ;) Makes absolutely no sense, because writeln doesn't store "hello" in its state - there is no way to read it. Maybe it's a limited mindset, but to me properties should be read-only or read-write, but not write-only. On the other hand, if it was a hypothetical property (let's call it "lastDebugMessage"), that stores and returns the string, while also printing it as a side-effect, then it could be acceptable (although this particular example is of limited practical value).
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On 2013-01-29 09:03, eles wrote: Let me turn the table: why not thinking about the property as a variable that, optionally (start another UFCS/opt-parens discussion here...) accept the syntax: v(2); It is a bit confusing because if it were methods/functions you'd typically have "getV()" and "setV(2)" which show what is being done here. "v(2)" on the other hand doesn't make it clear whether it will set the value or read it. After all "2" might be some flag/index/anything used to specify the return value and it still won't make "v(int)" a setter. In the end one would have to look into the docs to see what "v" does. This is unnecessary if you either tell in the function name what will be performed or use the property like any normal variable. Therefore when using properties I would rather just see "v" and "v = 2" (and also expect "w = v = 2" to work). Assuming that "w" is a plain int variable, I wouldn't expect to see v(2) anywhere outside initialization, just like I would not expect to see w(2).
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On 2013-01-29 02:59, Craig Dillabaugh wrote:
I find such code rather baffling. Perhaps it has valuable uses
somewhere, which is why I am asking.
It sort of reminds me of Python where you can do something like:
' '.join( list_of_strings )
which is very cute and all, but the following, rather mundane
function call would do a better job of conveying to the reader
what is going on, using the same number of keystrokes:
join( list_of_strings, ' ')
Thanks to D I no longer have problems with join in Python. :)
Looking at ' '.join(aList) I now think of UFCS and see it as:
join(' ', aList). Suddenly everything is clear. :)
Re: Request for comments: std.d.lexer
On 2013-01-28 08:47, Jacob Carlborg wrote:
If we're talking about dynamic allocation you can make sure you're just using
value types. A token could look like:
struct Token
{
TokenKind kind;
string value;
uint index;
}
For the "value" you could just slice the buffer. But I think this will prevent
the whole buffer from being collected.
I was also thinking about using slices to limit string allocation. So far the
combined size of source files in D projects is so small, that it wouldn't hurt
to mmap the files and slice them. It is possible though that someone would
create a huge file, even if only just to see this program crash. :)
In that case something else may be useful. Allocate special arrays for holding
value strings, for example 256 kB per array. Token.value will be a slice of such
array. Additionally have a lookup Trie to help reuse repeating values - if a
string is already in an array, the Trie leaf will store its position (slice) and
the token will only have to copy that info. If the lookup doesn't turn up the
string, the string will be added to the end of the array using Appender or, if
it doesn't fit, a new array will be created.
Re: Incorporating D
On 2013-01-26 20:55, SomeDude wrote: AFAWK, at least one major videogames studio is writing its new title in D. For real? You must be joking. :)
Re: PDF spec
On 2013-01-25 18:26, Andrei Alexandrescu wrote:
I'm using \href for the anchors and \label for the targets. What are you using?
\href{url}{text} is for URLs, \hyperref[labelname]{text} is for labels.
Re: PDF spec
On 2013-01-24 21:59, Philippe Sigaud wrote: I know that this is that standard layout/theme of Latex but I don't understand why links need to looks so horrible. A red or cyan square around the text. Isn't this be configurable? Yes, it is. It's just the default for the hyperref package. Yeah, the colorlinks option is much better - boxes are distracting and should be restricted to their main purpose... marking which authors have died. ;) Other suggestion: a bit smaller margins, so the code won't wrap as much, and using footnotesize font in listings for same reason. Now, tables - that's a PITA. I always end up in a cycle where I generate a PDF, preview it, tweak the tables (adjust column sizes, print the whole table in a small font, rotate the table or use a longtable), then generate the PDF again, and so on. I wonder how you approach this problem. Hints inside the documentation itself, perhaps?
Re: Exceptional coding style
Maybe I should invent a programming language in which color has semantic value. And fonts. :-P Why stop here? Go paint your programs in Piet. ;) Fixing const issues in Phobos would be as simple as selecting the entire source code and changing the font to italics. :-P I suggest a special font designed just for D. ;) Bold for const, Black for immutable, UltraLight for volatile, keywords written in Small Caps, comments in Script (must look handwritten)... Colours, as you mention would replace safe, pure, nothrow. Of course a special obligatory colour palette will be created. And as we're at it, it's time to go one step further in creating code friendlier to read, and get those APL keyboards back from the attic, so they can be useful once again. :D
Re: The rfind challenge
On 2013-01-15 21:59, Andrei Alexandrescu wrote:
The generic implementation of before is trivial:
auto before(R)(R theBuck, R stopsHere) {
static struct Result {
bool empty() { return r1 is r2; }
auto ref front() { return r1.front; }
void popFront() { r1.popFront; }
private R r1, r2;
}
return Result(theBuck, stopsHere);
}
I'm scared and would feel safer with:
bool empty() { return r1 is r2 || r1.empty(); }
For random-access ranges:
auto before(R)(R theBuck, R stopsHere) {
return theBuck[0 .. theBuck.length - stopsHere.length];
}
This implies that theBuck._end == stopsHere._end, but why?
Re: The rfind challenge
On 2013-01-15 21:14, monarch_dodra wrote: This is why I'd like to find a way to cut bidirectional ranges: Not just for r* functions, but also for our everyday functions: As you can see, we don't have any way to "findBefore" and store the result in a BR. Ouch. As a user of D, I agree with you that it should "just work". Real life is different though :/ Ah, right. That Take has bitten me before when I was discussing string slicing using negative indexes. :) In that case I wish this cutting that preserves the type of range will get implemented and the cheats in findSplit removed.
