Re: Why doesn't mktspec() use clock_gettime?
On 2015-01-12 02:19, Jonathan M Davis via Digitalmars-d wrote: It's probably because Mac OS X doesn't have clock_gettime, even though it's POSIX. std.datetime.Clock.currTime currently uses gettimeofday for getting the wall clock time on OS X (and clock_gettime on the other POSIX systems), which I'm not a fan of, but AFAIK, it works. However, I probably should try at some point to find a more precise wall clock function than gettimeofday for Mac OS X. I don't know if this is what you're looking for but I found these two [1], [2]. I don't know if they're monotonic or not. I also found this stackoverflow post [3] saying that mach_absolute_time and clock_get_time pauses when sleeping on iOS. Don't know if that's a problem or not. There seems to be a workaround in the post as well. [1] https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/services/services.html [2] http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/man/clock_get_time.html [3] http://stackoverflow.com/questions/12488481/getting-ios-system-uptime-that-doesnt-pause-when-asleep/12490414#12490414 -- /Jacob Carlborg
Re: Why exceptions for error handling is so important
Walter Bright: I do understand that the packed error code technique can be made to work, but the inconvenience seems to be high. Apparently if the language syntax is designed for that style of functional programming, the inconvenience seems to be very low. Bye, bearophile
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 09:41:08 UTC, bearophile wrote: Walter Bright: I do understand that the packed error code technique can be made to work, but the inconvenience seems to be high. Apparently if the language syntax is designed for that style of functional programming, the inconvenience seems to be very low. Yes, dataflow.
Re: core.stdc.* documentation
On 2015-01-12 02:24, Andrei Alexandrescu wrote: Problem is not that, but instead the repeated description. -- Andrei How about folding symbols with the same documentation, like ditto does? -- /Jacob Carlborg
Re: Writing a small linux binary
On 12 January 2015 at 08:46, Mike via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 12 January 2015 at 05:59:36 UTC, NVolcz wrote:
Can this be done in D? How easy is it? What about the runtime?
https://www.reddit.com/r/programming/comments/2s1sgg/151byte_static_linux_binary_in_rust/
Here's a link to my 56 byte Hello, World! program for the ARM Cortex-M
platform in D. And, if I only used the string Hello! like the rust
example, I believe it would be 47 bytes.
http://goo.gl/qWhpVX
Mike
Without performing any linker magic.
root@f6e559d2d853:~# cat small.d EOF
import core.stdc.stdio;
import core.stdc.stdlib;
extern(C) void main()
{
printf(Hello!\n);
exit(0);
}
EOF
root@f6e559d2d853:~# gdc -frelease -Os -nophoboslib
-fno-emit-moduleinfo -nostdlib --entry=main small.d -lc -o small
root@f6e559d2d853:~# wc -c small
2488 small
root@f6e559d2d853:~# ./small
Hello!
Re: Writing a small linux binary
On Monday, 12 January 2015 at 09:00:58 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 12 January 2015 at 08:46, Mike via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 12 January 2015 at 05:59:36 UTC, NVolcz wrote:
Can this be done in D? How easy is it? What about the runtime?
https://www.reddit.com/r/programming/comments/2s1sgg/151byte_static_linux_binary_in_rust/
Here's a link to my 56 byte Hello, World! program for the
ARM Cortex-M
platform in D. And, if I only used the string Hello! like
the rust
example, I believe it would be 47 bytes.
http://goo.gl/qWhpVX
Mike
Without performing any linker magic.
root@f6e559d2d853:~# cat small.d EOF
import core.stdc.stdio;
import core.stdc.stdlib;
extern(C) void main()
{
printf(Hello!\n);
exit(0);
}
EOF
root@f6e559d2d853:~# gdc -frelease -Os -nophoboslib
-fno-emit-moduleinfo -nostdlib --entry=main small.d -lc -o small
root@f6e559d2d853:~# wc -c small
2488 small
root@f6e559d2d853:~# ./small
Hello!
Would be considered linker magic to use _start(), write() and
_exit() instead? :)
--
Paulo
Re: Writing a small linux binary
On Monday, 12 January 2015 at 05:59:36 UTC, NVolcz wrote: Can this be done in D? How easy is it? What about the runtime? https://www.reddit.com/r/programming/comments/2s1sgg/151byte_static_linux_binary_in_rust/ Here's a link to my 56 byte Hello, World! program for the ARM Cortex-M platform in D. And, if I only used the string Hello! like the rust example, I believe it would be 47 bytes. http://goo.gl/qWhpVX Mike
Re: core.stdc.* documentation
On 1/12/15 12:05 AM, Jacob Carlborg wrote: On 2015-01-12 02:24, Andrei Alexandrescu wrote: Problem is not that, but instead the repeated description. -- Andrei How about folding symbols with the same documentation, like ditto does? I used ditto to generate that. -- Andrei
Re: Writing a small linux binary
On Mon, 12 Jan 2015 05:59:35 + NVolcz via Digitalmars-d digitalmars-d@puremagic.com wrote: Can this be done in D? yes. How easy is it? it depends of your experience and readyness to live without phobos and GC. What about the runtime? you may need to write one which will include only functions your program requires. p.s. i've not visited the link. signature.asc Description: PGP signature
Re: Writing a small linux binary
On Monday, 12 January 2015 at 08:46:57 UTC, Mike wrote: On Monday, 12 January 2015 at 05:59:36 UTC, NVolcz wrote: Can this be done in D? How easy is it? What about the runtime? https://www.reddit.com/r/programming/comments/2s1sgg/151byte_static_linux_binary_in_rust/ Here's a link to my 56 byte Hello, World! program for the ARM Cortex-M platform in D. And, if I only used the string Hello! like the rust example, I believe it would be 47 bytes. http://goo.gl/qWhpVX Mike Just posted the link to HN. -- Paulo
Re: Why exceptions for error handling is so important
On 1/11/2015 11:53 PM, Tobias Pankrath wrote: On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote: This matters very much for pipeline style programming (i.e. ranges and algorithms). Here is one approach to it: http://fsharpforfunandprofit.com/posts/recipe-part2/ I don't fully understand it, but it appears to require that each component have two paths coded into it - the regular path, and the error path, and there has to be adapters for components that only have a regular path. Exceptions means only one path has to be coded. I do understand that the packed error code technique can be made to work, but the inconvenience seems to be high.
Re: Is anyone working on a D source code formatting tool?
On Sun, 11 Jan 2015 13:15:22 -0800 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1/11/2015 11:50 AM, Andrei Alexandrescu wrote: On 1/11/15 10:48 AM, Walter Bright wrote: The main problem is what to do about comments, which don't fit into the grammar. In the first version comments might go through unchanged. Consider: for /*comment*/ (a; b; c) Do what with that? it's easy: put it before `for`. /*comment*/ for (...) or just ignore it. and i must confess that i've never seen comment like this in my lifetime. signature.asc Description: PGP signature
Re: Foreach, return not exist the function.
On Sunday, 11 January 2015 at 23:50:18 UTC, Ali Çehreli wrote:
On 01/11/2015 12:25 PM, Zaher Dirkey wrote:
reproduce example here
http://dpaste.dzfl.pl/13fb453d0b1e
That link doesn't work for me. (?)
Does opApply return the delegate's return value ('b' below)?
import std.stdio;
struct S
{
int opApply(int delegate(int) dg)
{
foreach (i; 0 .. 10) {
int b = dg(i);
if (b) {
writefln(Exiting opApply with %s, b);
return b;
}
}
return 0;
}
}
int foo()
{
auto s = S();
foreach (i; s) {
writeln(i);
return 42;
}
return 0;
}
void main()
{
assert(foo() == 42);
}
Ali
It in breaking the loop in opApply
if (result==0) {
must be
if (result) {
Thanks to Ali, and Zor at #D (freenode)
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 09:31:25 UTC, Walter Bright wrote: On 1/11/2015 11:53 PM, Tobias Pankrath wrote: On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote: This matters very much for pipeline style programming (i.e. ranges and algorithms). Here is one approach to it: http://fsharpforfunandprofit.com/posts/recipe-part2/ I don't fully understand it, but it appears to require that each component have two paths coded into it - the regular path, and the error path, and there has to be adapters for components that only have a regular path. Exceptions means only one path has to be coded. I do understand that the packed error code technique can be made to work, but the inconvenience seems to be high. Not really, after you have the library that can handle all code paths, the code just needs to be written using such building blocks[0], as they are quite general. Which is relatively easy in FP first languages. [0] Aka monadic combinators
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 11:43:26 UTC, Ola Fosheim Grøstad wrote: Does this mean that D will get fast EH? It is fast already...
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote: When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), Do you have to log? I've never had a problem calling C free functions in a class destructor in D.
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 13:25:26 UTC, Adam D. Ruppe wrote: On Monday, 12 January 2015 at 11:43:26 UTC, Ola Fosheim Grøstad wrote: Does this mean that D will get fast EH? It is fast already... What makes you say that? Doesn't D still use the standard zero-cost EH that was created for Itanium, where you take the performance hit on unwinding?
Re: core.atomic: atomicFence, atomicLoad, atomicStore
On Monday, 12 January 2015 at 13:37:19 UTC, ref2401 wrote: Thanks for the links. I have shared class instance. There are two threads which can read/write fields of the class. As i understand i can declare class as synchronized or i can read/write using atomicLoad/atomicStore. What's the difference between these two approaches? In what circumstances should i consider synchronized classes or using std.atomic? synchronized uses locks, and as such is good for (rule-of-thumb) low contention situations, i.e. you don't have lots of threads all trying to access the same data at the same time (or few threads doing lots of repeated access). It has significant overhead as there is a cost to taking and releasing the lock and can be very slow under high-contention. Its advantage is that it's merely difficult to get right. Using core.atomic and lock-free techniques in general is great for getting good performance in high-contention situations and/or reducing overhead in low-contention environments. However, it is very difficult to get right, very difficult to know if you have got it right and insanely difficult to debug when things go wrong.
Re: casting SysTime to ubyte[]
On 1/12/15 8:59 AM, Laeeth Isharc wrote:
import std.datetime;
import std.stdio;
import std.conv;
void main(string[] arg)
{
auto a=Clock.currTime();
auto b=cast(ubyte[])a;
writefln(%s,b);
}
how do i get the time as a binary representation I can write to a file?
You can always cast one pointer to another without complaint:
(cast(ubyte *)a)[0..a.sizeof];
-Steve
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote: On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote: When does invalidMemoryOperationError happen and how do you avoid it? Typical example: using (a slightly outdated version of) gfm library, I have few gfm objects lying around on which I forget to call a close() function. When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), invalidMemoryOperationError pops up. This usually only happens at the end of execution, sometimes however it happens randomly during program execution due to the randomness of GC operations. The only way out of this is manually closing everything correctly. I.e: I'm almost back to C++ manual memory management. Catching the exception is an unsatisfactory solution because I would still be leaking resources[1]. If possible, things are made even worse in that RefCounted doesn't work for classes, but that you can work around that (class instance into refcounted struct, not really elegant and requires lots of discipline, since it's easy to escape an extra reference). [1] For everyone who doesn't know: non trivial destructors are really useful in gfm because it wraps some C libraries, and cleaning up C allocated resources is usually important. Proper execution of gfm's close() for every class would be ideal. Sounds like an exact same problem I have run into recently: class wrappers around HDF5 C library need to do something not @nogc in a destructor and also have to call the C-level releasing functions. Can't do that in a destructor since then you get the invalidMemoryOperationError; can't make classes structs and use refcounted since there's an implied type hierarchy which becomes a mess with alias this... the only way is to put that in close() and then not forget to call it manually. Wish there was a standardized way of running non-@nogc user code before the dtor actually runs (and anytime after it's known to be guaranteed to run).
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 12:23:51 UTC, ponce wrote: Especially since destructors called by GC would release resources from the wrong thread, at the wrong moment, etc. Yeah, I almost forgot about this: destructing GC resources interacting with OpenGL was sooo fun :P
[almostOT] Shared experience from GUI toolkit development
No, not my experience, and not about DWT, but seems to be the closest forum that allows posting this. From the Ultimate++ library developers: http://www.ultimatepp.org/www$uppweb$overview$en-us.html Who owns widgets One of the things we discovered over our countless experiments with C++ GUI is the fact that the GUI toolkit should not own widget objects. GUI objects should be always owned by the client, belonging to some scope of client code (everything belongs somewhere). GUI toolkit just references them, it neither creates them nor destroys them. Each widget object can play its GUI role in some context (like being visible in some window), but at the same time it is always a stand-alone entity with its set of attributes that can be modified or queried regardless of its current GUI status. This has many serious implications. The most important is that Ultimate++ does not require widget objects to be allocated on the heap. [snip] and Dialog templates are C++ templates Now that we have laid down the foundations, it is time to introduce the coolest aspect of Ultimate++ GUI programming - layout templates: If you visually design a layout (usually, but not limited to, the layout of a dialog box) using TheIDE's Layout designer, this layout is in in your code reflected as a C++ template that derives from a widget-based class and declares all widgets as its member variables, and a matching function (InitLayout) that sets up the widget positions and their pre-designed attribute defaults. [snip] This approach provides radical reduction of complexity - many annoying things that seem to be necessary to identify widgets in client code (like widget IDs or names) are simply gone for good. All you have to deal with in Ultimate++ are your instance variables. The whole page is quite interesting (see: Value and Null, Display and Convert etc.) PS I also made Akismet happy: Akismet thinks your post looks like spam. Please solve a CAPTCHA to continue.
Re: Could D compete in a competition like this?
On Monday, 12 January 2015 at 07:19:16 UTC, Ola Fosheim Grøstad wrote: On Monday, 12 January 2015 at 03:35:32 UTC, Craig Dillabaugh wrote: On Sunday, 11 January 2015 at 13:10:12 UTC, Ola Fosheim Grøstad wrote: On Sunday, 11 January 2015 at 13:01:36 UTC, Gary Willoughby wrote: Could D compete in a competition like this? The guts will have to be done in assembly or Intel intrinsics... Why do you say that. Seems like picking the correct data structure/algorithms would be of more importance than the programming language. I don't see why this couldn't be made 'fast' with just about any programming language. 1. It is a basic spatial indexing problem. This is a heavily researched GIS area. 2. They list the hardware. But, they are cheating you: «All submissions will become public-domain DLLs.» + «prize money will be awarded to the three fastest solutions that are quicker than our fast solution.» They are basically trying to get master-level students to do highly valuable work for peanuts in order to improve their own commercial systems... :-/ OK, if they gave the hardware list then that makes sense.
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote: On 1/11/2015 5:06 AM, Dicebot wrote: What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it. It's a great question. I have a lot of experience with error codes, and with exceptions. I have zero with the packed scheme, though that doesn't stop me from having an opinion :-) Perhaps I misunderstand, but given A calls B calls C, A = B = C The general solution in functional programming is error chaining. An example, C is a function that reads in lines of a program and B is a function that takes all those lines and counts words. C will either return an error or lines and B will either immediately return that error to A or convert the lines to word counts. This works especially well with function chaining, because you can hide the error propagation in a generic chaining method (called map). http://danielwestheide.com/blog/2012/12/26/the-neophytes-guide-to-scala-part-6-error-handling-with-try.html
casting SysTime to ubyte[]
import std.datetime;
import std.stdio;
import std.conv;
void main(string[] arg)
{
auto a=Clock.currTime();
auto b=cast(ubyte[])a;
writefln(%s,b);
}
how do i get the time as a binary representation I can write to a
file?
Thanks.
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 11:09:01 UTC, Walter Bright wrote: On 1/12/2015 3:02 AM, Tobias Pankrath wrote: As far as I understand is, it requires each component to settle on the same discriminated union that packs the error and result, which he calles Result but is usually Choice in F#. Now in D we use the opDot to chain components, which works since we have UFCS. In F# there a simply three different opDots: , = and = which take care of the adaption. Or we could just use exceptions, which require none of that. Interesting little rant about exceptions (and more), from the author of a large and successful project in C++ http://250bpm.com/blog:4
Re: core.atomic: atomicFence, atomicLoad, atomicStore
Thanks for the links. I have shared class instance. There are two threads which can read/write fields of the class. As i understand i can declare class as synchronized or i can read/write using atomicLoad/atomicStore. What's the difference between these two approaches? In what circumstances should i consider synchronized classes or using std.atomic?
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 00:33:52 UTC, Andrei Alexandrescu wrote: On 1/11/15 4:33 PM, MattCoder wrote: On Sunday, 11 January 2015 at 23:27:34 UTC, Nick B wrote: Perhaps its better to have a number (average or mean) than no number. Just ask 50 or 100 uers (or more) for their number of downloads for the last 12 or 18 months. This is turn will give you a guess-estimate as to the size of the community. If the number is small, say 4, then this will indicate that the community is near 100,000 users. Interesting for example, in my case I downloaded twice on the last 12 months (2.062 and 2.066). Answers from others would be helpful. Thanks! -- Andrei 3-4 times per release (have 3 windows machines and on mac)
Re: Is anyone working on a D source code formatting tool?
On 2015-01-11 19:48, Walter Bright wrote: The main problem is what to do about comments, which don't fit into the grammar. Both Clang and Eclipse JDT provide API's for accessing comments. -- /Jacob Carlborg
Re: Is anyone working on a D source code formatting tool?
On 2015-01-12 09:11, ketmar via Digitalmars-d wrote: it's easy: put it before `for`. /*comment*/ for (...) or just ignore it. and i must confess that i've never seen comment like this in my lifetime. I agree. clang-format manage to keep it in the same place. -- /Jacob Carlborg
Re: casting SysTime to ubyte[]
V Mon, 12 Jan 2015 13:59:27 +
Laeeth Isharc via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com napsáno:
import std.datetime;
import std.stdio;
import std.conv;
void main(string[] arg)
{
auto a=Clock.currTime();
auto b=cast(ubyte[])a;
writefln(%s,b);
}
how do i get the time as a binary representation I can write to a
file?
Thanks.
import std.datetime;
import std.stdio;
import std.conv;
void main(string[] arg)
{
auto a=Clock.currTime();
auto b= (cast(ubyte*)a)[0 .. a.sizeof];
writefln(%s,b);
}
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 13:27:55 UTC, Adam D. Ruppe wrote: On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote: When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), Do you have to log? I've never had a problem calling C free functions in a class destructor in D. Not me personally, but gfm does that, and I'm not going to remove all the logging from the destructors :P I know the log example is weak, but I really think this issue is still valid. To be completely honest, it is my only real gripe with D.
Re: Is anyone working on a D source code formatting tool?
On Monday, 12 January 2015 at 01:53:20 UTC, Brian Schott wrote: On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? https://github.com/Hackerpilot/dfmt The above is the work of one afternoon and not well tested. Thanks Brian, looks promising.
Re: GSOC - Holiday Edition
On Sunday, 11 January 2015 at 12:53:53 UTC, Russel Winder via Digitalmars-d wrote: On Sat, 2015-01-10 at 19:30 +, Craig Dillabaugh via Digitalmars-d wrote: 8) Russel Winder and QML ... see #4. Should we drop QML support from our GSOC due to: http://forum.dlang.org/thread/hapeegrotkazppwdn...@forum.dlang.org Or promote it even more with filcuc as a co-mentor as it is active and something can come of it? Sounds good. I will see if filcuc is interested in being a Mentor.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 18:25:39 UTC, francesco.cattoglio wrote: They have not broken any promise just yet! :P And I somehow hope they can really manage a high level of stability after discussing throughtly this much about every bikeshed topic (including the recent int/uint change). Yes... And whether to embed 2K of poetry in the runtime or not... https://github.com/rust-lang/rust/issues/13871
Re: Why exceptions for error handling is so important
On 11 January 2015 at 10:48, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: Over the last few days, I have been getting weird errors from various programs I run on Windows 7. Programs would just fail, or produce corrupt output (I'm looking at you, Windows Moviemaker). I have a 128Gb SSD drive for my system drive, for speed, and a 4T secondary spinning drive for storage. I knew I was getting nearly out of space on the SSD drive, and had a 256Gb SSD drive ready to swap in. To migrate the system to the new disk, the idea was to use Windows Backup/Restore of the image. Unfortunately, Windows Backup would get a ways through the process, then fail with no message beyond an error code. Googling the error code produced a vast number of results, and various schemes for fixing it, some official, some not. None of them were applicable. Many involved loading new drivers, editting the system registry, and all sort of unappealing solutions. Up to this point, I you reminded me of a talk by Joe Armstrong (inventor of Erlang) https://www.youtube.com/watch?v=lKXe3HUG2l4
Re: endsWith - for a string vs an array of strings
Thanks for the help to everyone. It seems a common thing to want
to check an array as one may not know the variables at compile
time. Not that it's more than a few lines to do in D. But in
terms of language adoption, small frictions can have large
consequences over time. (Modern people don't have much patience
or sticking power even if viewed rationally the ROI makes these
things trivial. That's also because in a corporate environment
management are not always patient when somebody tries something
new and not yet mainstream). Making the standard library easy
with no sharp edges might have a high payoff over time.
How would one add this note about needing to pass a tuple not an
array to the docs or wiki ? For docs, clone and submit a pull
request? How about wiki?
On Monday, 12 January 2015 at 07:49:16 UTC, Mengu wrote:
On Saturday, 10 January 2015 at 23:32:47 UTC, bearophile wrote:
Laeeth Isharc:
In D there is a feature that allows a function to accept
both an array of items and items,
yes - it is funny there is not an overloading that accepts
arrays
I meant this D feature:
void foo(T)(T[] items...) {
import std.stdio;
items.writeln;
}
void main() {
foo(red, green, blue);
foo([red, green, blue]);
auto a = [red, green, blue];
foo(a);
}
Bye,
bearophile
for the curious, expanding tuples and typetuples on ali's book
is explained at
http://ddili.org/ders/d.en/tuples.html#ix_tuples..expand and at
http://ddili.org/ders/d.en/tuples.html#ix_tuples.TypeTuple,
std.typetuple.
Re: Why exceptions for error handling is so important
On 1/12/2015 3:28 AM, Andrej Mitrovic via Digitalmars-d wrote: If you haven't read this I highly recommend it, just for the entertainment value: http://blog.seattlepi.com/microsoft/2008/06/24/full-text-an-epic-bill-gates-e-mail-rant/ Epic! But we all have such issues. And it ain't just software, either, every machine that has a user interface, like cars and airplanes and dishwashers, have these usability issues that are so obviously wrong yet nobody thought of them.
Re: core.stdc.* documentation
On 1/11/15 7:29 PM, Andrei Alexandrescu wrote: I just fixed documentation to generate docs for all symbols in core.stdc.complex. Looks unhelpful: http://erdani.com/d/library-prerelease/core/stdc/complex.html Any idea on how to make this better? Yeah, ddox should put the prototype in the overview. How annoying to have to click on the name to figure out what the function call requires as parameters. Is there a command-line parameter to fix this? -Steve
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote: On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote: When does invalidMemoryOperationError happen and how do you avoid it? Typical example: using (a slightly outdated version of) gfm library, I have few gfm objects lying around on which I forget to call a close() function. When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), invalidMemoryOperationError pops up. This usually only happens at the end of execution, sometimes however it happens randomly during program execution due to the randomness of GC operations. The only way out of this is manually closing everything correctly. I.e: I'm almost back to C++ manual memory management. Catching the exception is an unsatisfactory solution because I would still be leaking resources[1]. If possible, things are made even worse in that RefCounted doesn't work for classes, but that you can work around that (class instance into refcounted struct, not really elegant and requires lots of discipline, since it's easy to escape an extra reference). [1] For everyone who doesn't know: non trivial destructors are really useful in gfm because it wraps some C libraries, and cleaning up C allocated resources is usually important. Proper execution of gfm's close() for every class would be ideal. Yeah the current situation force much discipline vs C++, and I made it worse by having class destructors call close() which turn things to work sometimes only by chance. I think more and more that I should have class destructors that don't call close(), and simply don't do anything. It's what glamour does (https://github.com/Dav1dde/glamour/blob/master/glamour/shader.d#L207) and it seems way more practical. Especially since destructors called by GC would release resources from the wrong thread, at the wrong moment, etc. It would be great if we settle on a name for this releasing function, whether it is close(), release(), dispose()... it seems it is a blocker for owning pointers of class instances.
Re: Wrapping a C library with its own GC + classes vs refcounted structs
Laeeth. Thanks for the reply. Yes, this concerns my HDF5 wrapper project; the main concern is not that the memory consumption of course, but rather explicitly controlling lifetimes of the objects (especially objects like files -- so you are can be sure there are no zombie handles floating around). An easy way is to just use scope(exit) to either close the HDF5 object directly, or indirectly call destroy on the wrapper. If you want to make it 'idiot proof', maybe ref counting structs will get you there (at possible cost of small overhead). I personally don't tend to forget to close a file or dataset; its much easier up forget to close a data type or data space descriptor. But struct vs class depends somewhat on how you want to represent the object hierarchy in D, no ? Incidentally there are some nice things one can do using compile time code to map D structs to HDF5 types (I have implemented a simple version of this in my wrapper). A bit more work the other way around if you don't know what's in the file beforehand.
Re: Why exceptions for error handling is so important
On 1/12/2015 3:02 AM, Tobias Pankrath wrote: As far as I understand is, it requires each component to settle on the same discriminated union that packs the error and result, which he calles Result but is usually Choice in F#. Now in D we use the opDot to chain components, which works since we have UFCS. In F# there a simply three different opDots: , = and = which take care of the adaption. Or we could just use exceptions, which require none of that.
Re: Why exceptions for error handling is so important
On 1/12/2015 2:04 AM, Iain Buclaw via Digitalmars-d wrote: Up to this point, I you reminded me of a talk by Joe Armstrong (inventor of Erlang) https://www.youtube.com/watch?v=lKXe3HUG2l4 I've found another problem with Windows Moviemaker, it can read, but cannot write, movies larger than 4Gb. Looks like some sort of internal 32 bit overflow. I am once again a unique snowflake, because in googling around I can find nobody else with this issue. (I have many 6Gb video files, as they come from my old 6 hour VHS tapes made in the 80's. I decided to digitize them and throw the tapes away. VHS tapes are only supposed to last 10 years, I am frankly amazed that they are in good shape after 30. My video capture device generates about 1Gb per hour of video.)
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 11:09:01 UTC, Walter Bright wrote: On 1/12/2015 3:02 AM, Tobias Pankrath wrote: As far as I understand is, it requires each component to settle on the same discriminated union that packs the error and result, which he calles Result but is usually Choice in F#. Now in D we use the opDot to chain components, which works since we have UFCS. In F# there a simply three different opDots: , = and = which take care of the adaption. Or we could just use exceptions, which require none of that. .. and have many other issues instead :) Right now my experience from some quick experiments with Rust seems to indicate that it is a good sort inconvenience for medium-to-big applications as it forces you to explicitly consider all possible exceptional paths possible in application without and does not add any runtime overhead. For smaller / less important programs verbosity does seem inconvenient in an unpleasant way indeed.
Re: Why exceptions for error handling is so important
On 1/12/15, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: I've found another problem with Windows Moviemaker, it can read, but cannot write, movies larger than 4Gb. Looks like some sort of internal 32 bit overflow. If you haven't read this I highly recommend it, just for the entertainment value: http://blog.seattlepi.com/microsoft/2008/06/24/full-text-an-epic-bill-gates-e-mail-rant/
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 09:31:25 UTC, Walter Bright wrote: On 1/11/2015 11:53 PM, Tobias Pankrath wrote: On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote: This matters very much for pipeline style programming (i.e. ranges and algorithms). Here is one approach to it: http://fsharpforfunandprofit.com/posts/recipe-part2/ I don't fully understand it, but it appears to require that each component have two paths coded into it - the regular path, and the error path, and there has to be adapters for components that only have a regular path. Exceptions means only one path has to be coded. As far as I understand is, it requires each component to settle on the same discriminated union that packs the error and result, which he calles Result but is usually Choice in F#. Now in D we use the opDot to chain components, which works since we have UFCS. In F# there a simply three different opDots: , = and = which take care of the adaption.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote: When does invalidMemoryOperationError happen and how do you avoid it? Typical example: using (a slightly outdated version of) gfm library, I have few gfm objects lying around on which I forget to call a close() function. When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), invalidMemoryOperationError pops up. This usually only happens at the end of execution, sometimes however it happens randomly during program execution due to the randomness of GC operations. The only way out of this is manually closing everything correctly. I.e: I'm almost back to C++ manual memory management. Catching the exception is an unsatisfactory solution because I would still be leaking resources[1]. If possible, things are made even worse in that RefCounted doesn't work for classes, but that you can work around that (class instance into refcounted struct, not really elegant and requires lots of discipline, since it's easy to escape an extra reference). [1] For everyone who doesn't know: non trivial destructors are really useful in gfm because it wraps some C libraries, and cleaning up C allocated resources is usually important. Proper execution of gfm's close() for every class would be ideal.
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 11:09:01 UTC, Walter Bright wrote: On 1/12/2015 3:02 AM, Tobias Pankrath wrote: As far as I understand is, it requires each component to settle on the same discriminated union that packs the error and result, which he calles Result but is usually Choice in F#. Now in D we use the opDot to chain components, which works since we have UFCS. In F# there a simply three different opDots: , = and = which take care of the adaption. Or we could just use exceptions, which require none of that. Well, yes. I don't think though, that either exception or railway requires more boilerplate than the other. They just offer different strength. The plus side for railway (as compared D exceptions): Easier comprehension of control flow and scope(exit) and scope(failure) are not needed anymore. Using something like this in @nogc functions seems easier than making exceptions work by preallocating them. Haven't programmed anything of value in F# though.
Re: Is anyone working on a D source code formatting tool?
On Sun, 2015-01-11 at 11:19 -0800, Walter Bright via Digitalmars-d wrote: […] It would be in the DMD front end, so LDC and GDC would it automatically. s/it/get it/ ? What wouldn't be automatic would be the command line options and other surrounding bits and pieces. […] The rules are always going to be wrong. But in this case, that's ok. For someone, not everyone. For some the rules will be right or at least acceptable. […] Sometimes it's better to just conform. It depends if the grievances are small enough to ignore and/or the benefits outweight. Sometimes conformance is a bridge too far and non-use, or use of an alternative is the right course of action. […] Really? Like what? After many years of arguing about formatting myself, I decided that I had better things to waste my time on. I do not see a point in opening up the debate. An official style exists, it is that which is required for Phobos. This is the style that will be implemented by dfmt. […] So you decided to conform rather than not use Go. Yes. My grievances against the enforced style are not sufficient to abandon, and the need to deal with error codes at all times is not a sufficient pain to stop me using Go. What is the counterbalance? Go routines, the use of channels, and the eshewing of any form of shared mutable memory. Go has a lot of crap, a lot of positive and negative hype, and dataflow built into the language. I find it surprising easy to ignore the crap. (Anyhow, I suggest that gofmt is only mandatory if you wish to contribute to offical Go code, not for your own projects.) I suspect applying gofmt to Phobos code would have interesting results ;-) PEP-8 allows for some minor variations. It can be applied as is for official PEP-8 compliant code or you can have variation. Of course the pep8 code is only an advisor, gofmt rewrites your code. Originally the gc compiler automatically rewrote your code, but that was seen as too fascist, so gofmt was split off as a separate tool. Now though everyone uses gofmt anyway adhering to the one true style. Having gofmt separate is though still the right thing as there is gc and gccgo which share no code. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 11:41:06 UTC, Walter Bright wrote: For me the primary advantage of EH is put the code to deal with the error in the place where it is most appropriate to deal with it. With error codes, you have to deal with propagating Does this mean that D will get fast EH?
Re: Why exceptions for error handling is so important
On 1/12/2015 3:27 AM, Dicebot wrote: .. and have many other issues instead :) Right now my experience from some quick experiments with Rust seems to indicate that it is a good sort inconvenience for medium-to-big applications as it forces you to explicitly consider all possible exceptional paths possible in application without and does not add any runtime overhead. For smaller / less important programs verbosity does seem inconvenient in an unpleasant way indeed. For me the primary advantage of EH is put the code to deal with the error in the place where it is most appropriate to deal with it. With error codes, you have to deal with propagating the errors everywhere. Error codes still require manual insertion of unwinding code, and that can get fairly ugly when dealing with transactions: http://dlang.org/exception-safe.html Scope guard and RAII deal with most of the issues with having correct error recovery.
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 13:54:18 UTC, Ola Fosheim Grøstad wrote: On Monday, 12 January 2015 at 13:25:26 UTC, Adam D. Ruppe wrote: On Monday, 12 January 2015 at 11:43:26 UTC, Ola Fosheim Grøstad wrote: Does this mean that D will get fast EH? It is fast already... What makes you say that? Doesn't D still use the standard zero-cost EH that was created for Itanium, where you take the performance hit on unwinding? The advantage of return code / union type error handling is that the exceptional case is as fast as the successful case. The disadvantage of return code / union type error handling is that the successful case is as slow as the exceptional case. So which method is faster depends on how exceptional your exceptions are.
Good post about out-of-the-box experience with D
http://www.reddit.com/r/programming/comments/2s67en/evaluating_d_for_games/ I encourage you to comment on reddit instead of here. Andrei
Re: Set null as function array parameter
On Mon, 12 Jan 2015 16:32:30 +
Oleg via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Monday, 12 January 2015 at 15:59:43 UTC, Adam D. Ruppe wrote:
Why are you using ref? Take that off and you can pass any
array, including null, with ease.
Because dynamic arrays are passed by value to functions. Will it
make another copy of array, if I'll pass array by value?
Looks like it won't (I've checked pointers), but I read in wiki
(http://en.wikibooks.org/wiki/D_%28The_Programming_Language%29/d2/Strings_and_Dynamic_Arrays#Passing_Dynamic_Arrays_to_Functions)
that it will copy structure that contains the -pointer to the
first element- and the length is copied and passed. Does it mean
something else? maybe i don't understand it correctly.
nope, it means exactly what is written there. except that dynamic array
is represented by struct like this:
struct {
void *dataptr;
size_t itemCount;
}
this is what D calls dynamic array, and this is what passed by value:
struct with two members. dynamic array contents are *not* a part of
dynamic array type.
yes, this is confusing.
signature.asc
Description: PGP signature
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 14:34:41 UTC, francesco.cattoglio wrote: On Monday, 12 January 2015 at 13:27:55 UTC, Adam D. Ruppe wrote: On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote: To be completely honest, it is my only real gripe with D. Yes, but it's at the very root of the language.
Re: Is anyone working on a D source code formatting tool?
On 2015-01-12 03:23:28 +, deadalnix said: On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? That is amongst the plans for libd. I'd be happy to support anyone that want to work on it :) This is part of the reason I wanted to de-couple libd's parsing from with libd-llvm can currently handle and have separate tests for that libd. Is this something we might be able to consider doing? We can easily have some code and do Code-ast-fmt Code-ast as tests for libd. -Shammah
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 16:15:34 UTC, Matthias Bentrup wrote: The disadvantage of return code / union type error handling is that the successful case is as slow as the exceptional case. It is in a register...
Re: Set null as function array parameter
On Monday, 12 January 2015 at 15:51:17 UTC, Oleg wrote:
void foo(ref int[] param1) {}
Why are you using ref? Take that off and you can pass any array,
including null, with ease.
The only difference is changes to length won't be seen outside
the foo function.
Re: Set null as function array parameter
On Monday, 12 January 2015 at 15:59:43 UTC, Adam D. Ruppe wrote: Why are you using ref? Take that off and you can pass any array, including null, with ease. Because dynamic arrays are passed by value to functions. Will it make another copy of array, if I'll pass array by value? Looks like it won't (I've checked pointers), but I read in wiki (http://en.wikibooks.org/wiki/D_%28The_Programming_Language%29/d2/Strings_and_Dynamic_Arrays#Passing_Dynamic_Arrays_to_Functions) that it will copy structure that contains the -pointer to the first element- and the length is copied and passed. Does it mean something else? maybe i don't understand it correctly.
Re: GSOC - Holiday Edition
On Mon, 2015-01-12 at 15:16 +, CraigDillabaugh via Digitalmars-d wrote: […] Sounds good. I will see if filcuc is interested in being a Mentor. I am happy to be the backup mentor for this one. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: core.stdc.* documentation
On 1/12/15 3:53 AM, Steven Schveighoffer wrote: On 1/11/15 7:29 PM, Andrei Alexandrescu wrote: I just fixed documentation to generate docs for all symbols in core.stdc.complex. Looks unhelpful: http://erdani.com/d/library-prerelease/core/stdc/complex.html Any idea on how to make this better? Yeah, ddox should put the prototype in the overview. How annoying to have to click on the name to figure out what the function call requires as parameters. Is there a command-line parameter to fix this? -Steve Yah, for stdc it seems the page-per-module approach is better. -- Andrei
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 18:11:56 UTC, Dicebot wrote: On Sunday, 11 January 2015 at 17:35:19 UTC, Andrei Alexandrescu wrote: On 1/11/15 7:29 AM, Dicebot wrote: On Sunday, 11 January 2015 at 14:43:08 UTC, Ola Fosheim Grøstad wrote: Maybe we should do a comparison thread between D and Rust. It might be interesting, and perhaps encourage some improvements to D. I am actually writing a Rust guide as read by D developer article now making random notes on topic. But I don't see this affecting D much as most of the things I liked in Rust more were also things I complained about in D for ages before. That sounds like a very interesting article. Looking forward to it. -- Andrei http://blog.dicebot.lv/2015/01/thoughts-about-rust-from-d-programmer.html Here it is, as promised. It is not very complete but it was getting pretty damn long so I decided to limit myself to something that caught my eye first. I'd really appreciate someone doing the proof reading of my terrible English before reddit'ing away :) There's a lot of missing articles (the/an/a), but other than that it's quite readable. The import example misses that in D you can just do: import mod1 = my.long.mod1; import mod2 = my.long.mod2;
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 18:55:49 UTC, John Colvin wrote: The import example misses that in D you can just do: import mod1 = my.long.mod1; import mod2 = my.long.mod2; I was originally intending to mention how this is possible but not pushed by language/compiler as the standard import approach and thus effectively ignored. But it is the longest part already. Do you thing it is important?
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 18:45:22 UTC, H. S. Teoh via Digitalmars-d wrote: The only sane way is to have the user specify a default value if the key wasn't found, since not all types have a null value (and besides, what if null is a valid value in the dictionary?). IOW something like TryGetValue that takes multiple arguments instead of operator[]. Yes, and then think about the original foundation for exceptions. An exception is mean to resolve situations where you call from a higher level layer into a lower level layer (or framework). The basic idea is that the higher level layer has information that the lower layer does not. So if you have exceptions with retry you get this: 1. High Level calls into low level 2. Low Level goes Lord High Level, I am your humble servant, but cannot compute 3/0. What shall I do? 3. High Level ponders for a while and says replace it with infinity and continue 4. Low Level comes back and say Lord High Level, I cannot find 'flowers.png'. 5. High Level responds Use 'default.png' instead. 6. Low Level comes back crying I can't find that either. 7. High Level gives up and says roll back, backtrack... Exceptions are basically about deferring decision making from an encapsulated context to the calling context. Without retries, you just have a backtracking mechanism. Don't get hung upon the terminology. Use it for writing maintainable code! You really should be using operator[] only when the key is expected to exist. If during normal operations there's a 50% chance the key doesn't already exist, you shouldn't be using []. This is getting very normative. Where did you get that 50% from? If you had exceptions with retry you could just look it up in a default directory for instance, or even made a call to another process to get a substitute value. Besides, if you are doing validation then it is desirable to get an exception for an illegal key. Don't let a crappy implementation of exception handling define general semantics. Improve the implementation instead.
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 18:11:56 UTC, Dicebot wrote: I'd really appreciate someone doing the proof reading of my terrible English before reddit'ing away :) I wrote these down, which will get you through the introduction: My job is all about D programming language -- the D Programming. find time to try it in more details. -- more detail. reading official guide -- the official guide notes on that topic with sort -- with a sort reasonably short from. -- form. I have come to opinion -- the opinion especially transitive ones, most -- the most (The rest of the article is well-written and bad English is not noticeable.)
Re: GSOC - Holiday Edition
On Monday, 12 January 2015 at 15:28:01 UTC, Russel Winder via Digitalmars-d wrote: On Mon, 2015-01-12 at 15:16 +, CraigDillabaugh via Digitalmars-d wrote: […] Sounds good. I will see if filcuc is interested in being a Mentor. I am happy to be the backup mentor for this one. Great. Thank you.
Re: Is anyone working on a D source code formatting tool?
On Monday, 12 January 2015 at 15:30:42 UTC, qznc wrote: So I started conceiving of a language in which even the *comments* were part of the AST. For, me this would be the aesthetic ideal. It just seemed like the next step in total AST integration. The clang-format approach is to make decisions based on the AST, but edit the byte array. AST nodes contain exact positions: line and column numbers. Sometimes more of them. For example, an if-statement needs to know the position of 'else' as well. Here is another example: void setX(int position /* inches */); However, I think it should really be wrapped into a struct instead to get type checker's approval. Initially, clang-format only did whitespace changes. I am not sure if they weakened this already. For example, stripping parens in expressions (x = x) would be acceptable for me. btw +1 for https://github.com/Hackerpilot/dfmt Last time I checked, it work on the lexer rather than the AST.
D Beginner Trying Manual Memory Management
I'm new to D. I have some modest knowledge of C++, but am more
familiar with scripting languages (Matlab, Python, R). D seems so
much easier than C++ in a lot of ways (and I just learned about
rdmd today, which is pretty cool). I am concerned about
performance of D vs. C++, so I wanted to learn a little bit more
about manual memory management, in case I might ever need it (not
for any particular application).
The D Language book Section 6.3.4-5 covers the topic. I basically
copied below and made some small changes.
import core.stdc.stdlib;
import std.stdio;
class Buffer {
private void* data;
// Constructor
this()
{
data = malloc(1024);
}
// Destructor
~this()
{
free(data);
}
}
unittest {
auto b = new Buffer;
auto b1 = b;
destroy(b); //changed from clear in book example
assert(b1.data is null);
writeln(Unit Test Finished);
}
I was thinking that it might be cool to use scope(exit) to handle
the memory management. It turns out the below unit test works.
unittest {
auto b = new Buffer;
scope(exit) destroy(b);
writeln(Unittest Finished);
}
However, if you leave in the auto b1 and assert, then it fails. I
suspect this is for the same reason that shared pointers are a
thing in C++ (it can't handle copies of the pointer).
Alternately, you can use some other scope and something like this
unittest {
{
Buffer b = new Buffer;
scope(exit) destroy(b);
}
destroy(b);
writeln(Unittest Finished);
}
will fail because b has already been destroyed. I thought this
behavior was pretty cool. If you followed this approach, then you
wouldn't have to wait until the end of the program to delete the
pointers. The downside would be if you need to write a lot of
pointers and there would be a lot of nesting. (likely the
motivation for the reference counting approach to smart pointers).
I wasn't sure how to figure out a way to combine these two
components so that I only have to write one line. I thought one
approach might be to put a scope(exit) within the constructor,
but that doesn't work. Also, if I try to do it within a template
function, then the scope(exit) is limited to the function scope,
which isn't the same thing.
Outside of writing a unique_ptr template class (which I have
tried to do, but couldn't get it to work) I don't really know how
to combine them into one line. Any ideas?
Re: Is anyone working on a D source code formatting tool?
On Monday, 12 January 2015 at 08:11:27 UTC, ketmar via Digitalmars-d wrote: it's easy: put it before `for`. /*comment*/ for (...) or just ignore it. and i must confess that i've never seen comment like this in my lifetime. You can't ignore. That is why building such tool in not that easy.
Re: Why exceptions for error handling is so important
On Mon, 12 Jan 2015 18:11:01 + via Digitalmars-d digitalmars-d@puremagic.com wrote: returning state with exceptions (banging his head against a wall) NO. THIS NEVER HAS ANY SENSE. signature.asc Description: PGP signature
Re: Why exceptions for error handling is so important
On 1/12/15 11:30 AM, Russel Winder via Digitalmars-d wrote: On Mon, 2015-01-12 at 10:43 -0800, H. S. Teoh via Digitalmars-d wrote: […] And what exactly should operator[] return if a key wasn't found? […] Go has an interesting solution, key lookup in a map return a pair (result, ok), if lookup succeeded then result is the associated value, if ok is false then result is undefined. I quite like this. How can you like undefined? That's a terrible solution again underlining Go's conflation of union and product types. -- Andrei
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 19:30:10 UTC, Russel Winder via Digitalmars-d wrote: On Mon, 2015-01-12 at 10:43 -0800, H. S. Teoh via Digitalmars-d wrote: […] And what exactly should operator[] return if a key wasn't found? […] Go has an interesting solution, key lookup in a map return a pair (result, ok), if lookup succeeded then result is the associated value, if ok is false then result is undefined. I quite like this. That's basically the same as a pointer to the value. If the pointer is null, dereferencing it is undefined.
Re: Why exceptions for error handling is so important
On Sunday, 11 January 2015 at 13:06:27 UTC, Dicebot wrote: What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it. Rust has an approach very similar to exception, but they do not unwind and trash the whole task instead. Under the hood, it is exception, but tend to be faster as you don't go through the landing pad/personality function dance, but do not fundamentally differ. The second approach is to pack the result in some kind of object that require checking (but you often don't have anything meaningful to do on failure where you need to check) or propagate the wrapper, à la maybe monad, and get rid of the wrapper where you know what to do on error. These approach tend to be faster while keeping safety, but requiring more work from the dev. They make sense if the error is common, but are not pulling their weight for very rare failure scenarios like disc running out of space.
Re: Is anyone working on a D source code formatting tool?
On Monday, 12 January 2015 at 15:30:34 UTC, qznc wrote: The clang-format approach is to make decisions based on the AST, but edit the byte array. dfix uses a similar approach. It uses the AST location information to make decisions while iterating through the token array. I think I will end up doing the same thing with dfmt.
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 19:01:06 UTC, Dicebot wrote: On Monday, 12 January 2015 at 18:55:49 UTC, John Colvin wrote: The import example misses that in D you can just do: import mod1 = my.long.mod1; import mod2 = my.long.mod2; I was originally intending to mention how this is possible but not pushed by language/compiler as the standard import approach and thus effectively ignored. But it is the longest part already. Do you thing it is important? I do, because the article gives the impression D has no answer to this problem. Why don't you use this feature yourself?
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 19:01:06 UTC, Dicebot wrote: On Monday, 12 January 2015 at 18:55:49 UTC, John Colvin wrote: The import example misses that in D you can just do: import mod1 = my.long.mod1; import mod2 = my.long.mod2; I was originally intending to mention how this is possible but not pushed by language/compiler as the standard import approach and thus effectively ignored. But it is the longest part already. Do you thing it is important? I think so. It might not be compiler-enforced but it's both possible and I would recommend people doing it.
Re: Is anyone working on a D source code formatting tool?
On Monday, 12 January 2015 at 15:20:24 UTC, Shammah Chancellor wrote: On 2015-01-12 03:23:28 +, deadalnix said: On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? That is amongst the plans for libd. I'd be happy to support anyone that want to work on it :) This is part of the reason I wanted to de-couple libd's parsing from with libd-llvm can currently handle and have separate tests for that libd. Is this something we might be able to consider doing? We can easily have some code and do Code-ast-fmt Code-ast as tests for libd. -Shammah The lexer/parser can be used without the semantic analysis part. It should be alright for now.
Re: Is anyone working on a D source code formatting tool?
On Mon, 12 Jan 2015 19:17:47 + deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 12 January 2015 at 08:11:27 UTC, ketmar via Digitalmars-d wrote: it's easy: put it before `for`. /*comment*/ for (...) or just ignore it. and i must confess that i've never seen comment like this in my lifetime. You can't ignore. That is why building such tool in not that easy. by ignore i meant live it where it was. if somebody is so smart that he writes such comments... oh, well, then he is smart enough to reformat the source manually. and if this is some other person's source... i'd say don't use it, that person is sick. signature.asc Description: PGP signature
Re: Why exceptions for error handling is so important
On Mon, 2015-01-12 at 09:54 -0800, H. S. Teoh via Digitalmars-d wrote: […] Yeah, exceptions are supposed to be ... well, *exceptions*, rather than the norm. :-) If you're using exceptions to do flow control, you're doing something wrong. […] Unless you are writing Python code. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Why exceptions for error handling is so important
On Mon, 2015-01-12 at 10:43 -0800, H. S. Teoh via Digitalmars-d wrote: […] And what exactly should operator[] return if a key wasn't found? […] Go has an interesting solution, key lookup in a map return a pair (result, ok), if lookup succeeded then result is the associated value, if ok is false then result is undefined. I quite like this. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Thoughts on replacement languages (Reddit + D)
On 1/12/15 11:01 AM, Dicebot wrote: On Monday, 12 January 2015 at 18:55:49 UTC, John Colvin wrote: The import example misses that in D you can just do: import mod1 = my.long.mod1; import mod2 = my.long.mod2; I was originally intending to mention how this is possible but not pushed by language/compiler as the standard import approach and thus effectively ignored. But it is the longest part already. Do you thing it is important? http://www.reddit.com/r/programming/comments/2s70mm/thoughts_about_rust_from_a_d_programmer/ Andrei
Re: D Beginner Trying Manual Memory Management
On Mon, 12 Jan 2015 19:29:53 +
jmh530 via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
the proper answer is too long to write (it will be more an article that
a forum answer ;-), so i'll just give you some directions:
import std.typecons;
{
auto b = scoped!B(); // `auto` is important here!
...
}
`scoped!` allocating class instance *on* *stack*, and automatically
calls destructor when object goes out of scope.
but you'd better consider using struct for such things, as struct are
stack-allocated by default (unlike classes, which are reference type
and should be allocated manually).
there is a big difference between `class` and `struct` in D, much
bigger that in C++ (where it's only about default protection,
actually).
signature.asc
Description: PGP signature
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 19:24:35 UTC, ketmar via Digitalmars-d wrote: On Mon, 12 Jan 2015 18:11:01 + via Digitalmars-d digitalmars-d@puremagic.com wrote: returning state with exceptions (banging his head against a wall) NO. THIS NEVER HAS ANY SENSE. Sure it has. It is a state machine. You cannot not return state. :-P
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 19:25:28 UTC, Andrei Alexandrescu wrote: On 1/12/15 11:01 AM, Dicebot wrote: On Monday, 12 January 2015 at 18:55:49 UTC, John Colvin wrote: The import example misses that in D you can just do: import mod1 = my.long.mod1; import mod2 = my.long.mod2; I was originally intending to mention how this is possible but not pushed by language/compiler as the standard import approach and thus effectively ignored. But it is the longest part already. Do you thing it is important? http://www.reddit.com/r/programming/comments/2s70mm/thoughts_about_rust_from_a_d_programmer/ Andrei I have asked to not post on reddit right now for a reason _
Re: D Beginner Trying Manual Memory Management
Thanks for the reply, I wasn't familiar with scoped. I was aware
that structs are on the stack and classes are on the heap in D,
but I didn't know it was possible to put a class on the stack.
Might be interesting to see how this is implemented.
After looking up some more C++, I think what I was trying to do
is more like make_unique than unique_ptr.
On Monday, 12 January 2015 at 19:42:14 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 12 Jan 2015 19:29:53 +
jmh530 via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
the proper answer is too long to write (it will be more an
article that
a forum answer ;-), so i'll just give you some directions:
import std.typecons;
{
auto b = scoped!B(); // `auto` is important here!
...
}
`scoped!` allocating class instance *on* *stack*, and
automatically
calls destructor when object goes out of scope.
but you'd better consider using struct for such things, as
struct are
stack-allocated by default (unlike classes, which are reference
type
and should be allocated manually).
there is a big difference between `class` and `struct` in D,
much
bigger that in C++ (where it's only about default protection,
actually).
Re: D Beginner Trying Manual Memory Management
On Mon, 12 Jan 2015 20:14:19 + jmh530 via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Thanks for the reply, I wasn't familiar with scoped. I was aware that structs are on the stack and classes are on the heap in D, but I didn't know it was possible to put a class on the stack. Might be interesting to see how this is implemented. actually, there is nothing complicated there (if you don't want to write an universal thing like `emplace!` ;-). it builds a wrapper struct big enough to hold class instance, copies class `.init` there and calls class' constructor. the rest of the magic is done by the compiler: when struct goes out of scope, compiler calls struct destructor, which in turn calls class destructor. ah, and it forwards all other requests with `alias this` trick. After looking up some more C++, I think what I was trying to do is more like make_unique than unique_ptr. i don't remember C++ well, but nevertheless i encouraging you to take a look at `std.typecons`. there are some handy things there, like `Rebindable!` or `Nullable!`. and some funny things like `BlackHole!` and `WhiteHole!`. ;-) it even has `RefCounted!`, but it doesn't play well with classes yet (AFAIR). signature.asc Description: PGP signature
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 20:07:17 UTC, deadalnix wrote: On Sunday, 11 January 2015 at 13:06:27 UTC, Dicebot wrote: What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it. Rust has an approach very similar to exception, but they do not unwind and trash the whole task instead. Under the hood, it is exception, but tend to be faster as you don't go through the landing pad/personality function dance, but do not fundamentally differ. The second approach is to pack the result in some kind of object that require checking (but you often don't have anything meaningful to do on failure where you need to check) or propagate the wrapper, à la maybe monad, and get rid of the wrapper where you know what to do on error. These approach tend to be faster while keeping safety, but requiring more work from the dev. They make sense if the error is common, but are not pulling their weight for very rare failure scenarios like disc running out of space. Exceptions in Rust are more like Errors in D (but they terminate tasks, not the process!), Result wrapper seems to be standard approach for tasks D uses exceptions for, thus my original question.
Re: Why exceptions for error handling is so important
On 1/12/2015 10:11 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: There are plenty of situations where exceptions used for retries is the most sensible solution. Heck, that's even how x86 floating point exceptions work. There are plenty of situations where returning state with exceptions makes the most sense, e.g. a web service request handler. I've never encountered any IEEE FP code that ever, and I mean ever, checked the 'exception' sticky flag that IEEE operations require. Outside of a FP test suite, that is. Nobody has ever turned on the FP hardware exception faults, either. Bringing up IEEE 754 FP exceptions as an example of it being done right when it is a complete failure severely damages your case.
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 20:07:17 UTC, deadalnix wrote: On Sunday, 11 January 2015 at 13:06:27 UTC, Dicebot wrote: What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it. Rust has an approach very similar to exception, but they do not unwind and trash the whole task instead. Under the hood, it is exception, but tend to be faster as you don't go through the landing pad/personality function dance, but do not fundamentally differ. It is difficult to introduce exceptions without causing problems for linear typing. http://www.serc.iisc.ernet.in/~govind/NHC-07/final/ExceptionsSlides.pdf
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 13:33:40 UTC, John Colvin wrote: On Monday, 12 January 2015 at 11:09:01 UTC, Walter Bright wrote: On 1/12/2015 3:02 AM, Tobias Pankrath wrote: As far as I understand is, it requires each component to settle on the same discriminated union that packs the error and result, which he calles Result but is usually Choice in F#. Now in D we use the opDot to chain components, which works since we have UFCS. In F# there a simply three different opDots: , = and = which take care of the adaption. Or we could just use exceptions, which require none of that. Interesting little rant about exceptions (and more), from the author of a large and successful project in C++ http://250bpm.com/blog:4 Exception in C++ is different. It is full of pitfalls and generally a usability disaster. I can understand that C++ dev do not like exception, but that say more about C++ than it does about exceptions.
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 19:09:37 UTC, Zach the Mystic wrote: On Monday, 12 January 2015 at 18:11:56 UTC, Dicebot wrote: I'd really appreciate someone doing the proof reading of my terrible English before reddit'ing away :) I wrote these down, which will get you through the introduction: My job is all about D programming language -- the D Programming. find time to try it in more details. -- more detail. reading official guide -- the official guide notes on that topic with sort -- with a sort reasonably short from. -- form. I have come to opinion -- the opinion especially transitive ones, most -- the most (The rest of the article is well-written and bad English is not noticeable.) Thanks, updated
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 21:13:10 UTC, Dicebot wrote: The section under Uncertain has a huge font size now and repeats what was just said. Have just fixed, beg my pardon. Please check again. Looks good. You're clear for launch! Oh wait... (looks up in the sky...)
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 21:11:44 UTC, Walter Bright wrote: There's another downside to returning two values - extra code is generated, and it consumes another register. It allocates very scarce resources to rare cases - not a recipe for high performance. In server applications there is no such thing as a rare case though and this trade-off looks quite appealing.
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 19:13:40 UTC, Zach the Mystic wrote: On Monday, 12 January 2015 at 19:01:06 UTC, Dicebot wrote: On Monday, 12 January 2015 at 18:55:49 UTC, John Colvin wrote: The import example misses that in D you can just do: import mod1 = my.long.mod1; import mod2 = my.long.mod2; I was originally intending to mention how this is possible but not pushed by language/compiler as the standard import approach and thus effectively ignored. But it is the longest part already. Do you thing it is important? I do, because the article gives the impression D has no answer to this problem. Why don't you use this feature yourself? http://www.reddit.com/r/programming/comments/2s70mm/thoughts_about_rust_from_a_d_programmer/cnmsnip
Re: Good post about out-of-the-box experience with D
On Monday, 12 January 2015 at 16:16:30 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2s67en/evaluating_d_for_games/ Array!int(RefCounted!(Payload, cast(RefCountedAutoInitialize)0)(RefCountedStore(20D9590))) Why does std.container.array use refcounted? Seems like serious overhead compared to std::vector in C++.
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 13:54:18 UTC, Ola Fosheim Grøstad wrote: On Monday, 12 January 2015 at 13:25:26 UTC, Adam D. Ruppe wrote: On Monday, 12 January 2015 at 11:43:26 UTC, Ola Fosheim Grøstad wrote: Does this mean that D will get fast EH? It is fast already... What makes you say that? Doesn't D still use the standard zero-cost EH that was created for Itanium, where you take the performance hit on unwinding? LDC, GDC and SDC do all use this.
Article Evaluating D for games
https://news.ycombinator.com/item?id=8874633 Someone evalutaing D for games. GC still seems to be the most hated D feature. D devs might want to reply ;)
Re: Why exceptions for error handling is so important
On 1/12/2015 10:06 AM, Tobias Müller wrote: On Mon, Jan 12, 2015 at 05:22:26PM +, Adam D. Ruppe via Digitalmars-d wrote: Yeah, exceptions are supposed to be ... well, *exceptions*, rather than the norm. :-) If you're using exceptions to do flow control, you're doing something wrong. But what's exceptional for you is normal for me. It's not a subjective truth, it's an objective fact. If code is throwing exceptions as part of its normal operation, it is designed wrong. And yes, if you take that as a challenge to try and concoct a counterexample, the point still stands :-)
Re: Good post about out-of-the-box experience with D
On Monday, 12 January 2015 at 20:35:13 UTC, weaselcat wrote: On Monday, 12 January 2015 at 16:16:30 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2s67en/evaluating_d_for_games/ Array!int(RefCounted!(Payload, cast(RefCountedAutoInitialize)0)(RefCountedStore(20D9590))) Why does std.container.array use refcounted? Seems like serious overhead compared to std::vector in C++. Because std.container have reference semantics.
Re: Why exceptions for error handling is so important
On 1/12/2015 11:30 AM, Russel Winder via Digitalmars-d wrote: Go has an interesting solution, key lookup in a map return a pair (result, ok), if lookup succeeded then result is the associated value, if ok is false then result is undefined. I quite like this. That's just putting the responsibility of array bounds checking on the caller. Would you want (result, ok) returned every time you indexed an array? I sure wouldn't. An associative array isn't conceptually any different.
