Random Access I/O
I need to be able to perform random access I/O against a file, creating a new file if it doesn't exist, or opening as-is (no truncation) if it already exists. None of the access modes for std.stdio.File seem to allow that. Any usage of the "w" mode causes my code to consider the file empty if it pre-exists (though, it doesn't always actually truncate the disk on file?) If I was coding in C, I would use open() as it gives more options for access: http://pubs.opengroup.org/onlinepubs/009695399/functions/open.html However, I don't see this exposed in phobos anywhere?
Re: GSOC 2015 - GNU dmd
On Wednesday, 4 March 2015 at 22:08:44 UTC, Walter Bright wrote: On 3/3/2015 1:15 PM, notna wrote: not sure if someone should inform them about the DMD name clash... or just enjoy the popularity ;) http://www.gnu.org/software/dmd I sent them a note. I'd suggest Daemon Hurder or dhurd.
Re: Let's Play Code Golf
On Monday, 23 February 2015 at 22:58:22 UTC, Charles wrote: I didn't beat your score, but I did it with ranges (full character count was 174): stdin.readln(); foreach(x; stdin.byLine) writefln(%0.15f, map!(a = (a1?-1:1)/(2.0*a+1))(iota(x.to!int)).sum); I think if I didn't have to import so many things, I would have done much better :) -Steve Yeah, imports were my issue too. Especially with readln, because using that meant I needed std.conv. Why don't reals initialize to zero? That'd save me 4 characters! :P For real programming purposes, having floating types initialize to an invalid state helps developers to catch logic errors that allow a variable to go into a mathematical operation without having been initialized.
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 00:14:55 UTC, deadalnix wrote: On Tuesday, 17 February 2015 at 19:03:49 UTC, Chris Williams wrote: Every throwable function call could be assumed to have a typed result (even void functions) and if, after the return, the caller checks the type and detects that it was an error, bubbles that up, then eventually you get to wherever the catcher is. But so basically, the current ABI doesn't support it and there's no desire to change it? How do exceptions currently happen, if not via some official ABI declaration of how throwable methods interact with one another? The compiler/linker determines where the catcher is and inserts code to cut down the stack and perform a long jump all the way back? If so, how do scope statements work? This kind of stunt is taxing on the fast path. It can be implemented as setjmp/longjmp but is more and more avoided in favor of libunwind based solutions for languages that have code running on unwinding. libunwind based solution is slower to unwind, but is not very taxing in the fast path (only prevent some optimizations to be done like tail call). This solution is a non starter perforamnce-wize for D. I didn't mean it as a solution. As said, I was just looking for an intro to the topic, so that I (and others) could meaningfully contribute or at least understand the options. I'll look up libunwind and, if that has enough info for me to grok it, create a wiki page on the subject.
Re: Template constraints
On Saturday, 14 February 2015 at 17:00:33 UTC, Andrei
Alexandrescu wrote:
There's been recurring discussion about failing constraints not
generating nice error messages.
void fun(T)(T x) if (complicated_condition) { ... }
struct Type(T)(T x) if (complicated_condition) { ... }
If complicated_condition is not met, the symbol simply
disappears and the compiler error message just lists is as a
possible, but not viable, candidate.
I think one simple step toward improving things is pushing the
condition in a static_assert inside type definitions:
void fun(T)(T x) if (complicated_condition) { ... } // no change
struct Type(T)(T x)
{
static assert(complicated_condition, Informative message.);
...
}
This should improve error messages for types (only). The
rationale is that it's okay for types to refuse compilation
because types, unlike functions, don't overload. The major
reason for template constraints in functions is allowing for
good overloading.
Andrei
This seems like a lot of manual labor to cover a compiler
limitation that is going to affect not just Phobos, but every D
project which uses constraints (or template type specialization?)
instead of interfaces. Ideally, the compiler would be able to
say, Well the function name and the parameter list exactly match
these possibilities, so let's run through each constraint applied
in the set of possibilities and explicitly dump the boolean
result for each constraint.
Re: Plan for Exceptions and @nogc?
On Tuesday, 17 February 2015 at 15:54:17 UTC, Andrei Alexandrescu wrote: On 2/16/15 3:17 PM, Jonathan Marler wrote: Is there a proposal for how D will support throwing Exceptions in @nogc code in the future? Nothing definite. We will get on to that right after 2.067. This is a good time to start discussions. -- Andrei Could someone give a description of the minutiae of why Exception throwing uses memory allocation as it is and why (for example) passing it back on the stack isn't an option?
Re: Plan for Exceptions and @nogc?
On Tuesday, 17 February 2015 at 18:50:46 UTC, Tobias Pankrath wrote: Could someone give a description of the minutiae of why Exception throwing uses memory allocation as it is and why (for example) passing it back on the stack isn't an option? The stack frame of the thrower is the first one to be rolled back. So you cannot allocate in the stack frame of the thrower, but a function cannot now, who (if anyone) is catching the exceptions it might throw. So I fear the stack is out. Every throwable function call could be assumed to have a typed result (even void functions) and if, after the return, the caller checks the type and detects that it was an error, bubbles that up, then eventually you get to wherever the catcher is. But so basically, the current ABI doesn't support it and there's no desire to change it? How do exceptions currently happen, if not via some official ABI declaration of how throwable methods interact with one another? The compiler/linker determines where the catcher is and inserts code to cut down the stack and perform a long jump all the way back? If so, how do scope statements work?
Static convertability testing?
I have a template function that gets values out of a tree of
variant types. My goal is to be able to write code like;
node.get!string(path, to, leaf);
Inside get(), I would like to use std.conv to dynamically convert
(where able) to the target type (T) or, if that is not possible,
to return T.init.
If I wanted to force the user to request the correct type as is
stored in the structure, I could write code like:
switch (leafType) {
case STRING:
static if (is(T : string)) {
return leftValue;
}
else {
return T.init
}
break;
...
But since I want to allow all possiblities that std.conv
supports, I want something like:
static if (isConvertible!(T, string)) {
return leftValue.to!T;
}
else {
return T.init;
}
Is there something like isConvertible() in the library somewhere?
Re: Time from timestamp?
On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote: On a slightly related note, I have code for UTC+0 to unix time stamp. https://github.com/Devisualization/util/blob/b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/core/time.d Unix timestamps can be negative, so you should probably be using longs instead of ulongs.
Time from timestamp?
I'm attempting to print a human-readable version of a timestamp.
The timestamp is coming from an external service, via JSON. An
example is:
1421865781342
Which I know to be:
2015-01-21T18:43:01.342Z
The only method I see which takes an epoch-style timestamp, so
that I can convert it to something printable, is the SysTime
constructor:
pure nothrow @safe this(long stdTime, immutable TimeZone tz =
null);
According to the reference, this seems to take the value in
hnsecs. My expectation would be that this means multiplying my
initial value by 1_000_000. But if I do that, I get a random date
2500 years in the future.
I created this sample code:
void main() {
long time = 1421865781342L;
writefln(%s, SysTime(time));
writefln(%s, SysTime(time * 10L));
writefln(%s, SysTime(time * 100L));
writefln(%s, SysTime(time * 1_000L));
writefln(%s, SysTime(time * 10_000L));
writefln(%s, SysTime(time * 100_000L));
writefln(%s, SysTime(time * 1_000_000L));
writefln(%s, Clock.currTime.stdTime);
}
Outputs:
0001-Jan-02 07:36:48.5781342
0001-Jan-17 03:04:47.781342
0001-Jun-14 05:44:39.81342
0005-Jul-04 08:23:20.1342
0046-Jan-21 10:50:03.342
0451-Jul-28 11:17:15.42
4506-Sep-18 16:42:14.2
635582516
My expectation would be that the final line would be something
beginning with 14 at least. Playing around with possible
multipliers, there doesn't even seem to be any integer value that
would allow conversion between the timestamp I received and
whatever SysTime expects.
I'm using:
DMD64 D Compiler v2.066.1
Ubuntu from .deb package
Is this a bug, or am I doing something wrong?
Re: Time from timestamp?
On Saturday, 31 January 2015 at 00:20:07 UTC, ketmar wrote: On Sat, 31 Jan 2015 00:03:43 +, Chris Williams wrote: since most database software probably stores birthdates (many of which are pre-1970) in this format O_O a perfectly broken software. And stdc: http://h50146.www5.hp.com/products/software/oe/tru64unix/manual/v51a_ref/HTML/MAN/MAN3/3955.HTM And UNIX: http://www.lehman.cuny.edu/cgi-bin/man-cgi?mktime+3
Re: Time from timestamp?
On Friday, 30 January 2015 at 22:38:21 UTC, Chris Williams wrote: On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote: On a slightly related note, I have code for UTC+0 to unix time stamp. https://github.com/Devisualization/util/blob/b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/core/time.d Unix timestamps can be negative, so you should probably be using longs instead of ulongs. Yup, there was a world before January 1st, 1970.
Re: Time from timestamp?
On Friday, 30 January 2015 at 23:50:53 UTC, ketmar wrote: On Fri, 30 Jan 2015 23:42:04 +, Chris Williams wrote: On Friday, 30 January 2015 at 22:38:21 UTC, Chris Williams wrote: On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote: On a slightly related note, I have code for UTC+0 to unix time stamp. https://github.com/Devisualization/util/blob/ b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/ core/time.d Unix timestamps can be negative, so you should probably be using longs instead of ulongs. Yup, there was a world before January 1st, 1970. not for unix timestamps. please, stop that, unix timestamp was not designed to present any dates before 1970. negative timestamp is a bug in code. Unless you know something I don't, everything I've ever read says that a negative unix timestamp is meant to refer to a time before 1970. It may not have been intentional, but since most database software probably stores birthdates (many of which are pre-1970) in this format, having a library be unable to support them just makes the library useless for many situations.
Re: Time from timestamp?
On Saturday, 31 January 2015 at 00:14:37 UTC, Steven
Schveighoffer wrote:
On 1/30/15 5:18 PM, Chris Williams wrote:
I'm attempting to print a human-readable version of a
timestamp. The
timestamp is coming from an external service, via JSON. An
example is:
1421865781342
Which I know to be:
2015-01-21T18:43:01.342Z
http://dlang.org/phobos/std_datetime.html#.unixTimeToStdTime
It's kind of convoluted because there is no epoch, but you can
make one:
import std.datetime;
import std.stdio;
void main(string[] args)
{
// can't make this enum because of time zone...
auto epoch = SysTime(unixTimeToStdTime(0), UTC());
writeln(epoch + 1_421_865_781_342.msecs);
}
output:
2015-Jan-21 18:43:01.342Z
Note the reason your code didn't work is because SysTime uses
1/1/1 as the epoch.
-Steve
D'oh, I missed that in the description:
and convert it to hnsecs in UTC since midnight, January 1st, 1
A.D. UTC
That does explain it. I also didn't spot the declaration of
unixTimeToStdTime(), which assuredly helps.
Thank you!
Re: How to copy object of class A to another object of class B?
On Wednesday, 28 January 2015 at 09:44:29 UTC, zhmt wrote:
Sometime , I need to copy them:
thrift.Card tc;
db.Card dc;
dc.id = tc.id;
dc.pwd = tc.pwd;
...
It is boring coding, I want a solution to copy them
automatically:
void copyObj(SRC,DEST)(SRC src,DEST dest)
{
foreach (i, type; typeof(SRC.tupleof)) {
auto name = SRC.tupleof[i].stringof;
__traits(getMember, dest, name) = __traits(getMember, src,
name);
writeln(name);
}
}
Unfortunitely, it doesnt work, how to improve it?
Assuming that the hibernated class isn't auto-generated and you
can redefine its contents freely, the following style may be an
alternative that works for you:
struct Foo {
public:
string a;
int b;
}
class FooClass {
public:
union {
struct {
string a;
int b;
};
Foo foo;
}
}
void main() {
Foo f = Foo(a, 10);
FooClass c = new FooClass();
c.foo = f;
writefln(%s %s, c.a, c.b);
}
Probably the anonymous struct will break the UDAs, but it should
be worth testing.
Re: Using std.net.curl to stream data
On Wednesday, 28 January 2015 at 14:18:38 UTC, Trollgeir wrote:
I'm having some trouble trying to stream data to my plot.ly
graph:
https://plot.ly/62/~Trollgeir/
The API: https://plot.ly/streaming/
I am able to post messages that get recorded into the stream
live, although right after curl uploads it, it just seems to
wait for a response it's not getting, and eventually timeouts.
Does anyone have any advice?
auto client = HTTP(stream.plot.ly);
client.addRequestHeader(plotly-streamtoken,e8bg6omat6);
client.verbose = true;
string msg = { \x\: 500, \y\: 500 } \n;
client.postData(msg);
client.perform;
You have to define a handler for HTTP.onReceive before calling
HTTP.perform. It will receive ubyte arrays for each packet that
comes in. For most purposes, you just copy that onto the end of a
string in an external scope. But if you're streaming content,
you'll need to do something more fancy.
Re: how convert the range to slice ?
On Wednesday, 28 January 2015 at 22:43:36 UTC, bearophile wrote: Nordlöw: Is there any chance we could add logic to dmd+phobos that hints user about this? It's such a fundamental part of D+Phobos that newbies are forced to learn this quickly. On the other hand an informative error message could be useful... What error message do you suggest? Bye, bearophile Range is not castable to array. See std.array.array to generate an array from a Range.
Re: D3
On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) Powers of two are magic.
Re: Russian translation of the range term?
On Wednesday, 12 November 2014 at 11:38:52 UTC, thedeemon wrote: On Tuesday, 11 November 2014 at 11:50:18 UTC, Ivan Kazmenko wrote: Hi! I'm unsure what is the Russian equivalent for the term range, as in D range, the generalization of a pair of iterators. I think последовательность (sequence) is the most appropriate, because the defining characteristic of an input range (most common one) is ability to provide data sequentially. Also, afaik, some languages like F# and Clojure use this term (often shortened to 'seq') for the same thing that D calls ranges. While sequence makes more sense for how std.range thinks of ranges, I think the history of the term is closer to how we use slices. So another (English) alternative to try might be a view. It's a fairly common term in SQL databases, so presumably there's a translation for it in Russian.
Re: DIP68: Adding @nogc to types
On Monday, 10 November 2014 at 12:59:14 UTC, Tomer Filiba wrote:
http://wiki.dlang.org/DIP68
This DIP proposes the addition of a compiler-enforced @nogc
attribute on types.
I would probably suggest extending this to variables.
class Foo {
@nogc Bar var1;
void doStuff() {
@nogc char* cStrPtr;
}
}
Re: Library inheritance
On Tuesday, 4 November 2014 at 15:03:08 UTC, Felix wrote: Hi, just wondering if it's possible, due to the lag of header files, to inherit from some class that exists within a library, that has been written in D? How did you solve that? Thanks in advance. You can run the compiler to create library and header (.di) files. Anything that requires compile-time execution, like templates, will remain in the .di. Anything that can be compiled as-is, will go in the library and just be represented as a function/method declaration in the .di file. So, basically, the same as C++ except you don't have to manually write your own header files.
Re: Why do some language-defined attributes have @ and some not?
On Thursday, 23 October 2014 at 07:39:21 UTC, Gary Willoughby wrote: On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma via Digitalmars-d- I submit that the syntax for attributes should be streamlined. Shall I go and open a Bugzilla item? No need: http://wiki.dlang.org/DIP64 Besides the @ symbols, isn't there also some inconsistency on whether attributes go before or after the declaration? @property public static void foo() const @safe pure nothrow I've never bothered to ascertain how much of the positioning is optional, but definitely none of it makes sense.
Re: Endovena: a dependency injection framework.
On Friday, 17 October 2014 at 22:55:24 UTC, Orfeo wrote: * [endovena] https://github.com/o3o/endovena Boost License 1.0 I would suggest naming the class something other than Container. Injector or Factory or something. Container gets confusing with std.container.
Re: example of pointer usefulness in D
On Tuesday, 21 October 2014 at 19:36:50 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 21 October 2014 at 19:33:14 UTC, Freddy wrote: On Tuesday, 21 October 2014 at 12:22:54 UTC, edn wrote: Could someone provide me with examples showing the usefulness of pointers in the D language? They don't seem to be used as much as in C and C++. https://en.wikipedia.org/wiki/XOR_linked_list Uhm. That won't work with the GC… It won't work with the GC, but one could still safely implement an XOR linked list in D, if they used malloc/free manually, so that the collector was never aware of the existence of those allocations. As to the OP, at the moment, D doesn't support structs as a reference type so if you want a container that stores references to structs rather than copies, the container will probably use pointers.
Re: RFC: std.concepts
On Sunday, 19 October 2014 at 21:10:12 UTC, Shammah Chancellor wrote: It was request that I create a NG thread about a module I was hoping to merge with phobos. (std.concepts) Please take a look. It seems like it might have some good use cases, but I'm not sure that it warrants a new module. I would probably recommend putting it into std.traits, as a more advanced version of the isX range of functionality.
Re: Segmented stack
On Thursday, 16 October 2014 at 19:46:42 UTC, Shucai wrote: I am doing research on segmented stack mechanisms, and in addition to academic papers, I am surveying whether segmented stack mechanism is still useful on 64-bit machines. On 64 bit machines, why they don’t just use a big enough stack, for example, 1GB or even larger? Are segmented stacks only useful for 32 bit machines? Are there other reasons for segmented stacks on 64 bit machines? Any response is appreciated, thanks, Shucai While the implementation isn't guaranteed, I think that Java mandates that the VM behave like every function receives a fresh stack. I imagine that the advantage of this was that it allows the VM to supply only the minimal necessary memory for a function to operate, at any given time. On small devices, it can swap the stack out to disk. On large devices, it can just keep everything in memory. Optimization for size/speed is handled for you, making your code more portable. (Theoretically.) Another possibility is that, while I can't think of the application, being able to preserve discarded chunks of the stack might be useful in some way. In a traditional stack arrangement, a new function entry will generally cause the data from the previous function entry to be overwritten. If you're allocating each new entry as its own thing, then all of the old functions continue to sit around to be processed by another thread, until you're ready to completely get rid of them.
Re: Worse is better?
On Friday, 10 October 2014 at 21:54:32 UTC, Peter Alexander wrote: (a) gives users full control over how every function allocates/manages memory (control). (b) makes the implementation of those functions easy (simple). (c) makes it easy to compose functions with different management policies (expressive). Probably the method would be to make garbage management an aspect of the language itself, like how Go handles parallel processing at the compiler level. Developers write everything like it's all magically garbage collected, with maybe a few metatags/keywords sprinkled around, and then tells the compiler what the default garbage collection should be, and the garbage collector goes in and rewrites code according to different strategies, including an option for static-analysis based collection like Mercury. D could potentially be moved that direction, but I would imagine that adding reference versions of structs would be necessary first, so that pointers became less prevalent, and pointers only allowed in blocks marked dangerous where the programmer has to perform any management himself.
Re: Worse is better?
On Friday, 10 October 2014 at 22:25:10 UTC, Walter Bright wrote: So it's not that we don't care about simplicity anymore. We care about what is simple for the programmer to get complex work done quickly and accurately. I like to think of D as a fully equipped machine shop, where the programmer doesn't have to make do with inadequate (but simple) tools. As professional programmers, isn't that what we really care about? Agreed. Overall, I'd say that there's a third way beyond better or worse, which is non-whollistic better. I always start any new task not by designing the whole application nor by start to hack together parts as I need them. Instead, I identify tools - parts of the application that I know will exist, but could be used in any variety of applications - and build nicely designed, generic libraries for those. With a set of better libraries the remaining code that links them together is fairly small, so it's easy to shuffle things around or build out new functionality.
Re: Search Engine
On Wednesday, 8 October 2014 at 18:15:08 UTC, ANtlord wrote: It would be stable? I mean program, that will use C++ extern interface. Trying to link to C++ code will cause some work to solve build issues, but there shouldn't be any stability impacts other than recognizing that C++ won't be using memory management.
Re: RFC: moving forward with @nogc Phobos
On Monday, 29 September 2014 at 12:29:33 UTC, Dicebot wrote: Any assumption that library code can go away with some set of pre-defined allocation strategies is crap. This whole discussion was about how important it is to move allocation decisions to user code (ranges are just one tool to achieve that, Don has been presenting examples of how we do that with plain arrays in DConf 2014 talk). I think the key to this sort of issue is to try and get as much functionality in Phobos marked @nogc as possible. After that, building new library-like functionality into a DUB package that assumes @nogc and only uses the @nogc code in Phobos would be the next step. Should that get to a state where it's popular and supported, pulling it in as std.nogc.* might make sense, but trying to redo Phobos as a manual memory collection library is infeasible. Were I your company, I'd start working on leading such an effort. Unlike Tango, I don't think a development like this would split the community nor the community's resources in a useless fashion.
Re: RFC: moving forward with @nogc Phobos
On Monday, 29 September 2014 at 10:49:53 UTC, Andrei Alexandrescu
wrote:
On the caller side:
auto p1 = setExtension(hello, .txt); // fine, use gc
auto p2 = setExtension!gc(hello, .txt); // same
auto p3 = setExtension!rc(hello, .txt); // fine, use rc
So by default it's going to continue being business as usual,
but certain functions will allow passing in a (defaulted)
policy for memory management.
Forcing someone (or rather, a team of someones) to call into the
library in a consistent fashion like this seems like a rather
risky venture. I suppose that you could add some special compiler
checks to make sure that people are being consistent, but I'd
probably rather see some way of templating modules so that the
chances for human error are reduced.
--- foo.d ---
module std.foo(GC = gc);
void bar() {
static if (gc) {
...
}
}
--- usercode.d ---
import std.foo!rc;
void fooCaller() {
bar();
}
Though truthfully, I'd rather it be a compiler flag. But I
presume that there's an issue with that, which it is too early
for my brain to think of.
Re: Momentary Eh?! for a Dynamic Language Programmmer. Tuples vs Arrays. Just rambling.
On Monday, 23 June 2014 at 22:08:59 UTC, John Carter wrote: On Monday, 23 June 2014 at 21:26:19 UTC, Chris Williams wrote: More likely what you want are variants: Hmm. Interesting. Yes, Variant and VariantArray are much closer to the dynamic language semantics... But the interesting thing is Tuple is much closer to What I Mean when I create these things. I probably should used Rubies http://ruby-doc.org/core-2.0/Struct.html but apart from naming the elements it gives me nothing beyond more keystrokes to enter. Tuple is very similar, but also grants type safety. D has structs. If you have any problem working with Tuples, you might consider moving over.
Re: Is void* compatible with function pointers?
On Monday, 23 June 2014 at 20:49:27 UTC, Steven Schveighoffer wrote: Since most architectures use same-size words for function addresses and object addresses, D would be fine to say it's defined and valid. I think the extreme outliers are architectures that are not equal, and D will not be harmed too badly by making this distinction. Any D flavor that would be ported to such an architecture may have to be a derived language. -Steve While it might be fine, I would be concerned that people wouldn't understand the difference between a function and a delegate. They would figure that if you can store a function reference in a void* then you should be able to fit a delegate in as well, and proceed to lose data. I would make it something where the compiler forces you to make an explicit cast. Before that, it should warn you about the potential loss of data.
Re: Momentary Eh?! for a Dynamic Language Programmmer. Tuples vs Arrays. Just rambling.
On Monday, 23 June 2014 at 21:18:39 UTC, John Carter wrote: I guess between perl and Ruby and Scheme etc. I got used to creating hybrid containers Want a pair of [string, fileList]? Just make an Array with two items, one a string, one and array of strings. Done. D barfed... leaving me momentarily stunned... then Oh Yes, type safety, Tuple's are the answer where Tuples where Tuples... Eventually found http://dlang.org/tuple.html and more specifically the somewhat unexpectedly named http://dlang.org/phobos/std_typecons.html and off I went... I do have a personal design guideline of when you adding too much behaviour to a heterocontainer, refactor into a class. But I guess I have never realised how often I do casually create heterogenous containers Just rambling and musing. More likely what you want are variants: http://dlang.org/library/std/variant/variantArray.html http://dlang.org/library/std/variant.html Tuples can hold multiple types, but they're only available during compile time.
Re: D Logos
On Friday, 13 June 2014 at 03:33:41 UTC, Khaled wrote: https://drive.google.com/file/d/0B_LJS0oMStiPVzJvRzBhTC1EaXc/edit?usp=sharing Overall, I like them. I agree that it's not intuitive that it's a d, but I don't think that's a strong drawback, if all you want is something cool to put on a shirt or coffee cup. In the last picture, I don't think the top and bottom lines are parallel, so it's making it look like weird perspective.
Re: extern(Windows) behavior on non-Windows systems
On Wednesday, 11 June 2014 at 22:20:27 UTC, Walter Bright wrote: I've got an enhancement request to have it behave like extern(C): https://issues.dlang.org/show_bug.cgi?id=12894 Thoughts? Anyone use extern(Windows) on non-Windows systems? No, but if I had a 3rd party .lib that had been built on Windows and it was the only known source for that library, I would prefer to be able to convert it to a .a and link against it using extern(Windows) (if possible). I would vote that extern(Windows) should do what it says on the tin OR issue an error telling people that a Mac/Linux build of the compiler can't build binaries that have any chance of being compatible with any library they'll ever find or make, so not to include it as a build target.
Separate allocation and construction?
If I wanted to allocate memory for a class and then call its
constructor as two separate steps, while still having the object
be managed by the garbage collector, is there any way to do that?
I believe that I've figured out a way to accomplish the first
step, but not the second.
import std.stdio;
class Foo {
this(string bar) {
writeln(bar);
}
}
void main() {
Foo f = (new Foo[1])[0];
f(Hello); // doesn't compile
}
Re: Separate allocation and construction?
On Thursday, 5 June 2014 at 22:25:03 UTC, Adam D. Ruppe wrote: On Thursday, 5 June 2014 at 22:22:16 UTC, Chris Williams wrote: If I wanted to allocate memory for a class and then call its constructor as two separate steps, while still having the object be managed by the garbage collector, is there any way to do that? Check out std.conv.emplace http://dlang.org/phobos/std_conv.html#emplace First, allocate the memory block for the class. The size is __traits(classInstanceSize, Yourclass). Then slice it: enum size = __traits(classInstanceSize, YourClass); auto memory = GC.malloc(size)[0 .. size]; Why slice? There seems to be a version of emplace that accepts a pointer, which is what GC.malloc() seems to return.
Re: Performance of std.json
On Monday, 2 June 2014 at 00:39:48 UTC, Jonathan M Davis via Digitalmars-d wrote: I know that vibe.d uses its own json implementation, but I don't know how much of that is part of its public API and how much of that is simply used internally: http://vibed.org In general, I've been pretty happy with vibe.d, and I've heard that the parser speed of the JSON implementation is good. But I must admit that I found the API to be fairly obtuse. In order to do much of anything, you really need to serialize/deserialize from structs. The JSON objects themselves are pretty impossible to modify. I haven't looked at how vibe's parser works, but any very-fast parser would probably need to support an input stream, so that it can build out data in parallel to I/O, and do a lot of manual memory management. E.g. you probably want a stack of reusable node buffers that you use to add elements to as you scan the JSON tree, then clone off purpose-sized nodes from the work buffers when you encounter the end of the definition. Whereas, the current implementation in std.json only accepts a complete string and for each node starts with no memory and has to allocate/reallocate for every fresh piece of information. Having worked with JSON libraries quite a bit, the key to a good one is the ability to refer to paths through the data. So besides the JSON objects themselves, you need something like a struct JPath that represents an array of strings and size_ts, which you can pass into get, set, has, and count methods. I'd view the lack of that as the larger issue with the current JSON implementations.
Re: Performance of std.json
On Monday, 2 June 2014 at 20:10:52 UTC, David Soria Parra wrote: I think the main question is, given that std.json is close to be unusable for anything serious due to it's poor performance, can we come up with something faster that has the same API. I am not sure what phobos take on backwards compatibility is, but I'd rather keep the API than breaking it for whoever is using std.json. std.json really only has two methods parseJson and toJson. Any implementation is going to have those two methods, so in terms of not breaking anything, you're pretty safe there. Since it doesn't have any methods except those two, it really comes down to the underlying data structure. Right now, you have to read the source and understand the structure in order to operate on it, which is a hassle, but is presumably what people are doing. So maintaining the current structure would be the key necessity. I think that limits the optimizations which could be performed, but doesn't make them impossible. Adding a stream-based parsing method would probably be the main optimization. That adds to the API, but is backwards compatible. The module has a lot of inner methods and recursion. Reducing the number of function calls, using manual stack management instead of recursion, etc. might give another significant gain. How parseJson() works is irrelevant to the caller, so all of that can be optimized to the heart's content.
Re: std.experimental – DConf?
On Friday, 30 May 2014 at 01:39:26 UTC, Jonathan M Davis via Digitalmars-d wrote: On Thu, 29 May 2014 20:55:32 + Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: I have discussed this with Andrei shortly after he has merged PR that adds `std.experimental` to Phobos. Looks like he actually thinks about it as `std.staging` - place for almost complete Phobos modules to bring more attention to them while still being able to make breaking API changes. If that's the case, then I'd be inclined to argue that what should go in std.experimental is modules that past the Phobos review process so that rather than sticking them in std directly, they go in std.experimental for a release or two so that they get better battle-tested before actually being put into std, where APIs shouldn't be changing. So, rather than doing anything to speed up the development process, std.experimental is for making sure that APIs are solid before they get set in stone in Phobos proper. - Jonathan m Davis While I like the idea of a std.experimental, I would also suggest an attribute like deprecated. I had been intending (should I ever have free time...) to add some features to std.concurrency, but I don't think there's any way to access the module-level private variables from a different file (?). Short of duplicating the contents of concurrency.d into a new file under experimental/, I don't know that there would be any way to trial the features without going straight to main.
Re: std.experimental – DConf?
On Friday, 30 May 2014 at 16:33:06 UTC, H. S. Teoh via Digitalmars-d wrote: Maybe we should call it std.broken_in_next_release. ;-) T import std.heretherebedragons.all;
Re: std.experimental – DConf?
On Friday, 30 May 2014 at 17:35:39 UTC, Steven Schveighoffer wrote: You mean like http://dlang.org/attribute#deprecated ? Yes, except named experimental. I had been intending (should I ever have free time...) to add some features to std.concurrency, but I don't think there's any way to access the module-level private variables from a different file (?). Short of duplicating the contents of concurrency.d into a new file under experimental/, I don't know that there would be any way to trial the features without going straight to main. First, if it is a minor increment, it can be proposed as a pull request for std.concurrency. If it is a major overhaul, we need to review it more broadly. This is kind of the problem with just adding things to std, which is why the std.experimental branch was proposed -- it's so difficult to get bad design out of the standard library after it has been released. The deprecation schedule takes years. -Steve Not an overhaul but also not minor, just adding different interfaces: http://forum.dlang.org/thread/kfmkxsgeeijwkndld...@forum.dlang.org Again, this is assuming I ever have the free time to do it, but I could see other such issues popping up. In the case of std.concurrency, since each thread gets its own set of global variables, the module itself is effectively the struct of information for each thread, including the thread message box. If I wanted to insert into the message box, I would need access to the module privates.
DConf Recommendation
My first day at DConf, during lunch, I ended up sitting next to the CTO/CEO of a startup company that was considering D as their language of choice. He commented to me, and which makes sense to me, that the format of the conference wasn't very well geared to people who are just interested in figuring out what the language is like and how to get started with it. His recommendation was to offer two tracks over two days (instead of one over three), whith one track focussing on things like how to get a development environment set up on different platforms, how to debug, overview of language features, etc. That way a CTO or other interested party could use the conference as a way to evaluate the language for use at their companies. I also got the sense that he was hiring, should anyone be interested. Apakau.com
Re: DConf Recommendation
On Wednesday, 28 May 2014 at 22:04:47 UTC, Andrej Mitrovic via Digitalmars-d wrote: Personally I think there were too many talks *per day*, it was hard not getting tired and all the talks were extremely interesting. But I understand that it's hard for people to take more free days for dconf alone. I suspect that for a power D user, keeping awake through a How to set up Visual D step-through would be pretty impossible. If only one person like the guy I mentioned is going to show up, then to Walter's point, there's not much value in providing such a session in the conference. But maybe next year advertize an intro to D class that will be on the first day if there's enough interest, and then make people choose between interested or not interested when they register.
