Re: std.experimental.color, request reviews
On Tuesday, 23 June 2015 at 15:24:44 UTC, John Colvin wrote: std/range/package.d and std/regex/package.d both have a bunch of stuff in. Why not? Those are also mistakes (well, probably just semi-migrated from the old big module). Suppose you want some of that stuff without the rest of the package. How do you get to it? The biggest benefit of breaking up the big modules is so you can access some of it without requiring all of it. But when the part you want is in the package.d, you can't get it independently anymore; importing that also imports everything else, negating the reason it was split up in the first place.
std.experimental.color, request reviews
https://github.com/D-Programming-Language/phobos/pull/2845 I'm getting quite happy with it. I think it's a good and fairly minimal but useful starting point. It'd be great to get some reviews from here.
Re: What have you done with UDAs?
On 22-Jun-2015 22:21, Alex Parrill wrote:
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote:
I never seem to use them for anything, has anyone else done anything
interesting with them?
I'm writing a program that can accept subcommands via either the command
line (ex. `prog mycmd 1 2`) or via a shell. I represent each command as
a function, use UDAs to store the help text and if they can be ran from
the command line or shell. The command list, full help text, and command
dispatcher is generated at compile time via templates, CTFE, and static
foreach.
And I thought that I might be the only one doing this ;)
Declarative command-line handling is much more scalable approach for
swiss-army knife command-line tools.
An example command:
@(nanoseconds) // arguments
@(Sets the amount of time to increment the clock on each frame.) //
description
@ShellOnly // can't be ran from command line
int cmd_set_time_per_frame(string[] args) {
// ...
}
Awesome. Is it open-sourced?
How about handling argument conversion automatically (via to! and/or
custom functions)?
Say :
@(num1 num2)
@CmdName(plus)
void add(int a, int b)
{
writelen(a+b);
}
To be automagically callable like:
./prog plus 2 4
--
Dmitry Olshansky
Re: Future(s) for D.
On Tuesday, 23 June 2015 at 08:58:39 UTC, Laeeth Isharc wrote: And as a consequence, we see: http://marginalrevolution.com/marginalrevolution/2015/06/the-time-needed-to-fill-jobs.html The present state of hiring processes can't go on, and so it won't. http://www.amazon.com/Why-Good-People-Cant-Jobs-ebook/dp/B00850ZOKI This already started in the 1990ies and got worse and worse, this business of looking for the perfect candidate. A lot of skills can be acquired in the first weeks (or months, depending). It's better to train someone who's intelligent and innovative than someone who's worked with all IDEs and build systems, but is fairly un-innovative (problem = for loop).
Re: Learning D Available for Pre-Order
On Tuesday, 23 June 2015 at 14:47:03 UTC, Mike Parker wrote: The project that has taken me away from Derelict since the end of February is now available for pre-order at [1]. I'm currently about 60% through the preliminary draft stage and, given that I've recently acquired a significant amount of free time in my schedule, expect to accelerate my pace on the remaining 40%. I need as much time as I can make for the revisions! I want to emphasize that Learning D is not aiming at those completely new to programming. The target reader is someone with some experience in a C family language. I see it as sitting somewhere between Ali's book and TDPL. One of my overarching goals is to help the target reader avoid some of the common mistakes people make when applying C++ or Java idioms to D. So far in the course of writing this book, I've learned that I knew less about the fundamentals of D than I thought I did and that the more difficult parts of the language aren't so difficult. The tech reviewers have given excellent feedback and done a fine job of correcting my misconceptions mistakes. I don't know how they feel about being named publicly just yet, but they all have my sincerest thanks. I know how tiring and time-consuming it can be to do that sort of thing, as reviewing the English in the papers of Korean doctoral candidates, professors and businessmen is something I do on the side. Once it's all done, I'm going to blog a postmortem about the whole process. It's been very, very different from my experience with Learn to Tango with D. Not a bad experience at all, just more intense and time-consuming than I had anticipated. [1] https://www.packtpub.com/application-development/learning-d What's the cover all about? Autumn for C++, or was it just that the colors matched nicely :-)
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? I've used them along with reflection to describe OpenGL vertex formats from a struct. https://github.com/d-gamedev-team/gfm/blob/master/opengl/gfm/opengl/vertex.d#L25 From this thread it seems UDA are quite successful.
stdx.data.json needs a layer on top
It's great, but it's not quite a replacement for std.json, as I see it. The stream parser is fast, and it's valuable to be able to access it at a low level. However, it was consciously designed to be low-level, and for something else to go on top. As I understand it, there is a gap between what you can currently do with std.json (and indeed vibed json) and what you can do with stdx.data.json. And the capability falls short of what can be done in other standard libraries such as the ones for python. So since we are going for a nuclear-power station included approach, does that not mean that we need to specify what this layer should do, and somebody should start to work on it?
Re: Program exited with code -11
On Tuesday, 23 June 2015 at 11:18:07 UTC, anonymous wrote: On Tuesday, 23 June 2015 at 07:57:26 UTC, Charles Hawkins wrote: Sigh. I'm probably doing something stupid. I tried full paths: dmd -I+/home/charles/projects/d/mylib/source/mylib/ myprog.d What's that plus sign doing there? Looks wrong. /home/charles/projects/d/mylib/build/libmylib.a Same result. myprog.d(4) Error: module mylib is in file 'mylib.d' which cannot be read Statement in myprog is: import mylib; Hey, I was right! Something stupid! I really don't think I made it up. Either I copied from some example that was in error, or was looking at something for another language (I've been looking at several lately) that added to a search path. In any event, I was obviously confused. Thanks, all! I think I'm back on track now. In fact, I've got several test programs working with my library. It isn't so large that compiling it every time was that big of a deal, but nice to know I don't have to.
Re: stdx.data.json needs a layer on top
Am 23.06.2015 um 14:17 schrieb Laeeth Isharc: It's great, but it's not quite a replacement for std.json, as I see it. The stream parser is fast, and it's valuable to be able to access it at a low level. However, it was consciously designed to be low-level, and for something else to go on top. As I understand it, there is a gap between what you can currently do with std.json (and indeed vibed json) and what you can do with stdx.data.json. And the capability falls short of what can be done in other standard libraries such as the ones for python. So since we are going for a nuclear-power station included approach, does that not mean that we need to specify what this layer should do, and somebody should start to work on it? One thing. which I consider the most important missing building block, is Jacob's anticipated std.serialization module [1]*. Skipping the data representation layer and going straight for a statically typed access to the data is the way to go in a language such as D, at least in most situations. Another part is a high level layer on top of the stream parser that exists for a while (albeit with room for improvement), but that I forgot to update the documentation for. I've now caught up on that and it can be found under [2] - see the read[...] and skip[...] functions. Do you, or anyone else, have further ideas for higher level functionality, or any concrete examples in other standard libraries? [1]: https://github.com/jacob-carlborg/orange [2]: http://s-ludwig.github.io/std_data_json/stdx/data/json/parser.html * Or any other suitable replacement, if that doesn't work out for some reason. The vibe.data.serialization module to me is not a suitable candidate as it stands, because it lacks some features of Jacob's solution, such as proper handling of (duplicate/interior) references. But it's a perfect fit for my own class of problems, so I currently can't justify to put work into this either.
Re: std.experimental.color, request reviews
Just a quick concern, I don't think a package.d should ever have anything except imports in it. Put all the actual aliases and color lists in some other submodule that can be imported independently with minimal dependencies.
Re: std.experimental.color, request reviews
On 23-Jun-2015 18:24, John Colvin wrote: On Tuesday, 23 June 2015 at 15:01:59 UTC, Adam D. Ruppe wrote: Just a quick concern, I don't think a package.d should ever have anything except imports in it. Put all the actual aliases and color lists in some other submodule that can be imported independently with minimal dependencies. std/range/package.d and std/regex/package.d both have a bunch of stuff in. Why not? Speaking of regex - it's temporary situation. The idea is to both expose more submodules and keep less cruft in package.d. I'm not for public imports only but for minimizing the amount of code in package.d -- Dmitry Olshansky
Re: What have you done with UDAs?
On Tuesday, 23 June 2015 at 14:52:30 UTC, Dmitry Olshansky wrote:
An example command:
@(nanoseconds) // arguments
@(Sets the amount of time to increment the clock on each
frame.) //
description
@ShellOnly // can't be ran from command line
int cmd_set_time_per_frame(string[] args) {
// ...
}
Awesome. Is it open-sourced?
How about handling argument conversion automatically (via to!
and/or custom functions)?
Say :
@(num1 num2)
@CmdName(plus)
void add(int a, int b)
{
writelen(a+b);
}
To be automagically callable like:
./prog plus 2 4
Not yet; its ATM a bit coupled with the application I'm writing.
Specifying types with the arguments is definitely feasible, but I
haven't gotten around to writing it yet. You could also possibly
specify flag arguments (--foo) by specifying default parameters.
(somewhat related: std.getopts is kinda bad; you can't get help
text without successfully parsing arguments and `required` breaks
`--help`)
Re: std.experimental.color, request reviews
On Tuesday, 23 June 2015 at 15:01:59 UTC, Adam D. Ruppe wrote: Just a quick concern, I don't think a package.d should ever have anything except imports in it. Put all the actual aliases and color lists in some other submodule that can be imported independently with minimal dependencies. std/range/package.d and std/regex/package.d both have a bunch of stuff in. Why not?
Re: Learning D Available for Pre-Order
On 24/06/2015 2:47 a.m., Mike Parker wrote: The project that has taken me away from Derelict since the end of February is now available for pre-order at [1]. I'm currently about 60% through the preliminary draft stage and, given that I've recently acquired a significant amount of free time in my schedule, expect to accelerate my pace on the remaining 40%. I need as much time as I can make for the revisions! I want to emphasize that Learning D is not aiming at those completely new to programming. The target reader is someone with some experience in a C family language. I see it as sitting somewhere between Ali's book and TDPL. One of my overarching goals is to help the target reader avoid some of the common mistakes people make when applying C++ or Java idioms to D. So far in the course of writing this book, I've learned that I knew less about the fundamentals of D than I thought I did and that the more difficult parts of the language aren't so difficult. The tech reviewers have given excellent feedback and done a fine job of correcting my misconceptions mistakes. I don't know how they feel about being named publicly just yet, but they all have my sincerest thanks. I know how tiring and time-consuming it can be to do that sort of thing, as reviewing the English in the papers of Korean doctoral candidates, professors and businessmen is something I do on the side. Once it's all done, I'm going to blog a postmortem about the whole process. It's been very, very different from my experience with Learn to Tango with D. Not a bad experience at all, just more intense and time-consuming than I had anticipated. [1] https://www.packtpub.com/application-development/learning-d Oh thank goodness. It doesn't clash with my book. The way to program - Let's think like a D(eveloper)! For new programmers :)
Re: std.experimental.color, request reviews
On 24/06/2015 3:29 a.m., Adam D. Ruppe wrote: On Tuesday, 23 June 2015 at 15:24:44 UTC, John Colvin wrote: std/range/package.d and std/regex/package.d both have a bunch of stuff in. Why not? Those are also mistakes (well, probably just semi-migrated from the old big module). Suppose you want some of that stuff without the rest of the package. How do you get to it? I use a file called defs for this. Works brilliantly.
Learning D Available for Pre-Order
The project that has taken me away from Derelict since the end of February is now available for pre-order at [1]. I'm currently about 60% through the preliminary draft stage and, given that I've recently acquired a significant amount of free time in my schedule, expect to accelerate my pace on the remaining 40%. I need as much time as I can make for the revisions! I want to emphasize that Learning D is not aiming at those completely new to programming. The target reader is someone with some experience in a C family language. I see it as sitting somewhere between Ali's book and TDPL. One of my overarching goals is to help the target reader avoid some of the common mistakes people make when applying C++ or Java idioms to D. So far in the course of writing this book, I've learned that I knew less about the fundamentals of D than I thought I did and that the more difficult parts of the language aren't so difficult. The tech reviewers have given excellent feedback and done a fine job of correcting my misconceptions mistakes. I don't know how they feel about being named publicly just yet, but they all have my sincerest thanks. I know how tiring and time-consuming it can be to do that sort of thing, as reviewing the English in the papers of Korean doctoral candidates, professors and businessmen is something I do on the side. Once it's all done, I'm going to blog a postmortem about the whole process. It's been very, very different from my experience with Learn to Tango with D. Not a bad experience at all, just more intense and time-consuming than I had anticipated. [1] https://www.packtpub.com/application-development/learning-d
Re: Learning D Available for Pre-Order
Good news! I've just shared the info on our LinkedIn group. :)
Re: auto ref is on the docket
On Tuesday, 23 June 2015 at 09:57:26 UTC, Marc Schütz wrote:
On Monday, 22 June 2015 at 19:05:28 UTC, kinke wrote:
[...]
To clarify: What I meant by my comment was that const-ness
should not be a precondition for allowing rvalue refs. Mutable
rvalue refs are fine.
I know and see it the same way.
As I have already pointed out in another thread, I'd go one
step further and propose an extremely convenient `in T` for
this very common use case:
* The argument is passed by value (`const T`) if the compiler
assumes moving/copying is more efficient than passing a
reference (with its indirection on the callee side) for the
particular target environment (hardware, ABI), e.g., for
plain-old-datatypes T fitting into 1-2 registers, and Object
references obviously.
* Otherwise, the argument is passed by-ref (`in ref T`). As
`in T` doesn't mention any ref at all, it's clear that the
hidden reference cannot escape.
Theoretically, `immutable ref` by itself would already allow
these semantics (without the `scope` that `in` implies).
Because (disregarding identity/addresses) for an immutable
object there is no observable difference between pass-by-value
and pass-by-reference. The same is not always true for `const
ref`, whenever aliasing is possible:
void foo(const ref int a, ref int b) {
int x = a;
b++;
assert(x == a); // can fail if both refer to the same
variable
// similar with global variables
}
To guarantee this from the caller's POV, the callee must be
pure and the parameters must be known not to alias each other.
This is obviously true. Rvalues aren't affected as they cannot
alias another parameter by definition. Lvalues are if passed by
ref and the same instance is accessible by mutable ref from
another parameter or global. But as shown by your example, that
danger is always there. The proposed `in` semantics make it less
obvious, that's true, but I still think it'd be worth it, as
these aliasing bugs are a pain to track down, but in my
experience extremely rare.
Re: D could catch this wave: web assembly
Nick, you might be interested in this quick thing I just wrote up: http://arsdnet.net/articles/web-apps.html A few years ago, I was talking about a new windowing system... and believe it or not, I'm still slowly moving forward with it, but I think existing X is good enough to start with for this idea. My old thing was about thin clients used through the web. Well, I like downloading programs too sometimes, can we solve that problem? Web apps do an ok job, so do app stores. Let's get the best of both worlds: download a program that targets a standard Linux VM distributed with browsers. I go into a bit more detail in the link.
Re: fast way to insert element at index 0
On Tuesday, 23 June 2015 at 11:22:31 UTC, Steven Schveighoffer
wrote:
On 6/23/15 1:51 AM, jkpl wrote:
On Tuesday, 23 June 2015 at 05:16:23 UTC, Assembly wrote:
[...]
* Option 1/
if most of the time you have to insert at the beginning, then
start
reading from the end and append to the end, so that the
existing block
has not to be moved. You just have to add val at the end.
* Option 2/
better way to move the whole block (this can be done with
memmove too).
---
void push(T val)
{
buffer.length += 1;
buffer[1..$] = buffer[0..$-1];
This will fail.
http://dlang.org/arrays.html#overlapping-copying
I will note, dcollections had a deque, which allowed insertion
at the front in O(1) (amortized) time. It basically worked by
having 2 arrays front to front.
-Steve
according to the C library, memmove handle overlapps, you
mismatch with memcpy which does not.
Re: fast way to insert element at index 0
On 6/23/15 8:12 AM, Baz wrote:
On Tuesday, 23 June 2015 at 11:22:31 UTC, Steven Schveighoffer wrote:
On 6/23/15 1:51 AM, jkpl wrote:
On Tuesday, 23 June 2015 at 05:16:23 UTC, Assembly wrote:
[...]
* Option 1/
if most of the time you have to insert at the beginning, then start
reading from the end and append to the end, so that the existing block
has not to be moved. You just have to add val at the end.
* Option 2/
better way to move the whole block (this can be done with memmove too).
---
void push(T val)
{
buffer.length += 1;
buffer[1..$] = buffer[0..$-1];
This will fail.
http://dlang.org/arrays.html#overlapping-copying
I will note, dcollections had a deque, which allowed insertion at the
front in O(1) (amortized) time. It basically worked by having 2 arrays
front to front.
according to the C library, memmove handle overlapps, you mismatch with
memcpy which does not.
The above is not memmove, it's slice assignment, which is specifically
illegal for overlaps:
$ cat testsliceassign.d
void buffer[100];
void main()
{
buffer[1..$] = buffer[0..$-1];
}
$ dmd testsliceassign.d
$ ./testsliceassign
object.Error@(0): Overlapping arrays in copy: 98 byte(s) overlap of 99
-Steve
Re: Walter, Brian, and Daniel's DConf 2015 talks are up
On Tuesday, 23 June 2015 at 07:41:40 UTC, Andrei Alexandrescu wrote: On 6/23/15 12:29 AM, Baz wrote: On Friday, 19 June 2015 at 22:47:03 UTC, Brad Anderson wrote: Walter: https://www.youtube.com/watch?v=znjesAXEEqw Brian: https://www.youtube.com/watch?v=FmFyB9e7edw Daniel: https://www.youtube.com/watch?v=5daHGXSetXk I've only just started watching but the editing seems to be well done so thanks to UVU for that. What did happen at 16' during Bright Talk ? Seemed hilarous however the language barrier stopped me here. The mouse pointer was right there in the middle of the projected slides. It took me 16 minutes to not stand it anymore, after which I went and moved it aside. -- Andrei It's an interesting thing: the relationship between intrinsic personality traits, 'deformation professionnelle' and the problem domain. Were someone unable to assess quality in language design, a degree of obsessiveness would be one thing he might want to see in a designer given the long separation of gratification from seeing the ultimate results of good design and laying the foundation for things well. I once worked with a chap - senior guy - who faked Aspergery traits he didn't really have in order to impress people from outside the firm (he wasn't distinguished by his quant ability, but had other things going for him). And people copy the leader, so watch out for Dconf 2020! ;) [Since it's a forum post, yes, I know you're not faking it and that it's within the normal range ;)].
Re: auto ref is on the docket
On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis wrote:
Which does not generally work in D. It can in some cases, but
const is so restrictive in D that you simply cannot use it just
because you don't intend to mutate a variable. Too many types
won't work with const, and many types _can't_ work with const.
const has its uses, but you have to be careful with it, and in
the general case, that means that you can't put it on function
parameters just to indicate that the function argument is not
going to mutated.
- Jonathan M Davis
Thus the solution cannot require const.
auto is worse because, if you later decide you need to add a
template parameter then the meaning is changed and you get a
_hidden_ performance issue.
Thus requiring neither auto nor const is the least evil of the
above.
You could always use comments, or even dummy aliases to make the
code self-documenting:
alias view(T...) = T;
void example(ref view!int i) {}
Re: stdx.data.json needs a layer on top
On 24/06/2015 12:17 a.m., Laeeth Isharc wrote: It's great, but it's not quite a replacement for std.json, as I see it. The stream parser is fast, and it's valuable to be able to access it at a low level. However, it was consciously designed to be low-level, and for something else to go on top. As I understand it, there is a gap between what you can currently do with std.json (and indeed vibed json) and what you can do with stdx.data.json. And the capability falls short of what can be done in other standard libraries such as the ones for python. So since we are going for a nuclear-power station included approach, does that not mean that we need to specify what this layer should do, and somebody should start to work on it? Please come onto https://www.livecoding.tv/alphaglosined/ and hang out for half an hour. I want to show you something related.
Re: DIP80: phobos additions
On Wednesday, 10 June 2015 at 15:44:40 UTC, Andrei Alexandrescu wrote: On 6/10/15 1:53 AM, ponce wrote: On Wednesday, 10 June 2015 at 07:56:46 UTC, John Chapman wrote: It's a shame ucent/cent never got implemented. But couldn't they be added to Phobos? I often need a 128-bit type with better precision than float and double. FWIW: https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint.d Yes, arbitrary fixed-size integrals would be good to have in Phobos. Who's the author of that code? Can we get something going here? -- Andrei Sorry for the delay. I wrote this code a while earlier. I will relicense it anyway that is needed (if needed). Currently lack the time to polish it more (adding custom literals would be the one thing to do).
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? Amongst other things, I use them in PydMagic to mark functions to be wrapped by pyd and exposed to the python.
[Issue 14720] Template function reported as non-template
https://issues.dlang.org/show_bug.cgi?id=14720 --- Comment #7 from Kenji Hara k.hara...@gmail.com --- (In reply to Kenji Hara from comment #6) Ah, it's order dependent bug in compiler. Test case: Ok, I'll fix it in the auto-ref related PR: https://github.com/D-Programming-Language/dmd/pull/4729 --
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? What a cool thread. This is very valuable info for new(ish) d users. It's often the case for language features that they are just branded cool. But that's just a statement (and you go 'uhm, ok.'). What people usually need is some kind of proof or demonstration why they are useful and how to solve problems with them (which you can usually only get through experience). Wouldn't it be great if there was a wiki page of cool d-features where each feature would have a list like this showcasing what people have done with it? You could then just point people to this wiki page to get a practical view of why d is great.
Re: fast way to insert element at index 0
On Tuesday, 23 June 2015 at 13:29:41 UTC, Steven Schveighoffer
wrote:
On 6/23/15 8:12 AM, Baz wrote:
On Tuesday, 23 June 2015 at 11:22:31 UTC, Steven Schveighoffer
wrote:
[...]
according to the C library, memmove handle overlapps, you
mismatch with
memcpy which does not.
The above is not memmove, it's slice assignment, which is
specifically illegal for overlaps:
$ cat testsliceassign.d
void buffer[100];
void main()
{
buffer[1..$] = buffer[0..$-1];
}
$ dmd testsliceassign.d
$ ./testsliceassign
object.Error@(0): Overlapping arrays in copy: 98 byte(s)
overlap of 99
-Steve
ok. i was, wrongly, suposing that this operation uses memmove
under the hood.
btw you forgot to grow the array size, if i dare.
Re: std.experimental.color, request reviews
On Tuesday, 23 June 2015 at 15:29:42 UTC, Adam D. Ruppe wrote: On Tuesday, 23 June 2015 at 15:24:44 UTC, John Colvin wrote: std/range/package.d and std/regex/package.d both have a bunch of stuff in. Why not? Those are also mistakes (well, probably just semi-migrated from the old big module). Suppose you want some of that stuff without the rest of the package. How do you get to it? The biggest benefit of breaking up the big modules is so you can access some of it without requiring all of it. But when the part you want is in the package.d, you can't get it independently anymore; importing that also imports everything else, negating the reason it was split up in the first place. But that's more an argument against putting anything _except_ the basic definitions into package.d, no? Then you can always exclude the more specific stuff whenever you need it, and those modules themselves can publicly import package.d.
[Issue 14726] New: core.sys.linux.sys.mman out of date
https://issues.dlang.org/show_bug.cgi?id=14726 Issue ID: 14726 Summary: core.sys.linux.sys.mman out of date Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: major Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: rs...@rsw0x.me Various flags are missing from various architectures in the mman.d file. All of this mess has long been consolidated into the uapi headers. see: https://github.molgen.mpg.de/git-mirror/glibc/blob/master/bits/mman-linux.h --
[Issue 14725] New: std.getopt: improve error message for malformed arguments
https://issues.dlang.org/show_bug.cgi?id=14725
Issue ID: 14725
Summary: std.getopt: improve error message for malformed
arguments
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: initrd...@gmail.com
When parsing an argument that isn't a string (ex. an int), getopt just uses
`std.conv.to`, which throws a ConvException that's not very helpful to the end
user.
For example:
import std.stdio;
import std.getopt;
import std.conv;
void main(string[] args) {
int num;
GetoptResult helpinfo;
try {
helpinfo = getopt(args,
num, An integer, num,
);
} catch(ConvException ex) {
stderr.writeln(Error parsing arguments: , ex.msg);
return;
}
if(helpinfo.helpWanted) {
defaultGetoptPrinter(I am help text, helpinfo.options);
}
}
$ rdmd ~/test.d --num=foo
Error parsing arguments: Unexpected 'o' when converting from type string to
type int
It would be nicer if getopt caught the ConvException, then threw a
GetOptException with a more end-user-friendly message. For example:
$ rdmd ~/test.d --num=foo
Error parsing arguments: `num` was passed a non-integer value.
--
Re: Phobos addition formal review: std.experimental.allocator
On 6/23/15 9:53 AM, extrawurst wrote: On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote: On 6/23/15 9:48 AM, extrawurst wrote: I agree with Adam on this: Just a quick concern, I don't think a package.d should ever have anything except imports in it (see http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dlang.org) What is the rationale? -- Andrei I simply quote his following post in the mentioned thread: The biggest benefit of breaking up the big modules is so you can access some of it without requiring all of it. But when the part you want is in the package.d, you can't get it independently anymore; importing that also imports everything else, negating the reason it was split up in the first place. But that doesn't apply to packages that do NOT originate as big modules, so they have no backward compatibility issue. This is the case for std.allocator. I see a net pessimization for everyone involved to change the current packaging. All I'm saying is we shouldn't take it noncritically that packages should be done one particular way. Andrei
Re: Phobos addition formal review: std.experimental.allocator
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote: On 6/23/15 9:48 AM, extrawurst wrote: I agree with Adam on this: Just a quick concern, I don't think a package.d should ever have anything except imports in it (see http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dlang.org) What is the rationale? -- Andrei My reasoning is simple : when `package.d` only contains public imports it allows to both use simple `import std.allocator` for those who want to get started quickly and pick only necessary imports for those who try optimizing build times / code clarity. Not doing that does not change anything for those who prefer `import std.allocator` but makes fine tuning of imports impossible. Thus former approach looks either equal or superior for all use cases.
Re: Phobos addition formal review: std.experimental.allocator
On Tuesday, 23 June 2015 at 16:56:55 UTC, Andrei Alexandrescu wrote: But that doesn't apply to packages that do NOT originate as big modules, so they have no backward compatibility issue. My thought isn't really about backward compatibility but about minimizing dependencies with sibling modules. I don't want to repeat my argument too much from the other thread, but imagine you're writing a minimalist library that is meant to interact with other minimalist libraries. To interact, you want a shared interface and basic types. But to be minimalist, you want to pull as little other standard code as possible. The typical user might just import std.whatever and get it all available. But this minimalist user only wants std.whatever.basic_interface. If the basic interface is shoved inside package.d, she can't get get to it without inadvertently pulling in more modules too. This can quickly grow into a web of dependencies where importing just an interface definition ends up grabbing dozens if implementations you don't want too, bloating compile times and binary sizes.
Re: Phobos addition formal review: std.experimental.allocator
On 6/23/15 2:18 AM, Dicebot wrote: On Monday, 22 June 2015 at 22:38:19 UTC, Andrei Alexandrescu wrote: Perhaps I misunderstood the request - currently the imports in allocator/package.d are: public import std.experimental.allocator.common, std.experimental.allocator.typed; import std.algorithm, std.conv, std.exception, std.range, std.traits, std.typecons, std.typetuple; version(unittest) import std.random, std.stdio; Is that okay, and if not what should change? My concern was about the fact that symbols `IAllocator`, `theAllocator`, `processAllocator` and bunch of others are defined within `package.d` itself and not provided via public import. That means that anyone willing to change default allocator or use `make` MUST import all std.allocator modules even if nothing else is really needed (those utilities look very independent). Which means processing bunch of unnecessary imports - and more of those if more modules will get added to the package. I'd prefer to have a small dedicated module, i.e. `std.allocator.api` (not going to discuss names!) and do public import of it from `std.allocator.package.d`. Makes sense? I see. Well this raises the question whether importing std.xyz automatically means everything under std.xyz is transitorily imported. Right now it's not - the more advanced/obscure building blocks are not automatically imported if you just import std.allocator; for those you'd need to import the std.allocator.building_blocks package, or individual modules from it like std.allocator.building_blocks.region. This idea was proposed by Mike on 2015/05/18: Would it be better to move the porcelain code into package.d so the nomenclature simply becomes `import std.allocator;`? I liked the idea that someone who's not an expert goes let me import std.allocator and call it a day whereas someone who wants to tweak, customize, etc. they'd need to be more specific. If we define an entry point such as std.allocator.api, novices will have one more thing to remember, or some will still import std.allocator thus pulling everything without realizing it. So I'd say let's keep simple things simple. If you want to allocate, import std.allocator. Andrei
Re: D could catch this wave: web assembly
On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote: On Monday, 22 June 2015 at 16:34:58 UTC, Ola Fosheim Grøstad wrote: People are already writing less javascript, but without a GC in webasm most languages are better of compiling to javascript or a mix. The problem is that they may be writing less javascript now, but they're still stuck with the performance of javascript, as they're just compiling to javascript. Webasm making that faster and allowing more languages should change that equation much more. asm.js/Webasm is more restricted. Those restrictions basically tells the JIT that the code has already been optimized, doesn't need higher level support and it can be translated into machine language as is... Although I don't think javascript is the bottle neck at the moment. I think the layout and render engine is. As for a GC, why would webasm need to provide one? I'd think the languages would just be able to compile their own GC to webasm, which seems low-level enough. That would be difficult to get right. This is nonsense. They're just dumping in everything they can think of, that has nothing to do with backwards-compatibility. Web tech is pretty good at backwards-compatibility. Not sure why anyone would argue against that. I think the vendors have realized that they need to take babysteps in concert, because there is to much politics involved to accept a whole-sale solution like PNACL etc. PNaCl is bitcode too. From one party. So it did not get adopted. That doesn't answer the question of why they're using a bitcode and not a textual IR, as you prefer text for SVG. Because we don't edit the IR.
Re: Phobos addition formal review: std.experimental.allocator
Am 23.06.2015 um 18:53 schrieb extrawurst: On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote: On 6/23/15 9:48 AM, extrawurst wrote: I agree with Adam on this: Just a quick concern, I don't think a package.d should ever have anything except imports in it (see http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dlang.org) What is the rationale? -- Andrei I simply quote his following post in the mentioned thread: The biggest benefit of breaking up the big modules is so you can access some of it without requiring all of it. But when the part you want is in the package.d, you can't get it independently anymore; importing that also imports everything else, negating the reason it was split up in the first place. Not to mention https://issues.dlang.org/show_bug.cgi?id=11847
Re: D could catch this wave: web assembly
On 06/23/2015 12:36 PM, Adam D. Ruppe wrote: On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote: Yea, I'll have to take a closer look at that. My first impression is that Linux VM sounds very heavy-weight, but I supposed it need not necessarily be. Well, keep in mind that I want to kill the browser, which is already very heavy-weight! Very true. Fair point. Firefox is like 80 MB http://www.tinycorelinux.net/downloads.html that's 9 MB and probably more than the browser VM would need! ABout 99% of the time, my browser (FF) is soaking up anywhere from 1-1.5GB of RAM. By far the biggest memory hog on my system (at least when I don't have a Windows VM or something running). Well, there is one other exception though: After switching my main desktop to Linux, I found that my favorite editor (Programmer's Notepad 2) has some issues under Wine, so I've been using a lot of Komodo Edit. Unfortunately, among other big annoyances, Komodo seems to have some serious memory leak issues because it's ram usage only ever grows, never shrinks (not even if I close ALL files), and after only a few days it'll hit 1GB+ ram as well, and then start pausing/lagging like crazy. Ugh. I'm trying Kate now. Actually seems to have grown up from an MS Notepad for KDE to a fully legitimate code editor since the last time I really looked closely at it (back in KDE3 days). Seems quite promising so far. The core system should be sharable without copying the file every time, and its only job is to run one program, providing it a familiar, consistent base api. I don't think the weight would be much of a problem, though perhaps it might be on the mobile sphere. If the weight is a problem on mobile, that would unfortunately be a deal-breaker. Mobile web is every bit as important as desktop web these days, and will likely only grow further.
[Issue 14707] std.net.curl using File.write instead of File.rawWrite
https://issues.dlang.org/show_bug.cgi?id=14707 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Keywords||pull Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Marking this a duplicate of the newer bug because I posted the PR there. *** This issue has been marked as a duplicate of issue 14712 *** --
Re: auto ref is on the docket
On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote: On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis wrote: Which does not generally work in D. It can in some cases, but const is so restrictive in D that you simply cannot use it just because you don't intend to mutate a variable. Too many types won't work with const, and many types _can't_ work with const. const has its uses, but you have to be careful with it, and in the general case, that means that you can't put it on function parameters just to indicate that the function argument is not going to mutated. - Jonathan M Davis Thus the solution cannot require const. auto is worse because, if you later decide you need to add a template parameter then the meaning is changed and you get a _hidden_ performance issue. And how does it introduce a hidden performance issue. You'd end up with some template bloat, but that's it, and that's just going to increase the memory footprint of your program slightly, which isn't generally going to be a performance issue. It's just going to make your program slightly larger. - Jonathan M Davis
Re: DIP80: phobos additions
On Wednesday, 17 June 2015 at 09:28:00 UTC, Tofu Ninja wrote: I actually thought about it more, and D does have a bunch of binary operators that no ones uses. You can make all sorts of weird operators like +*, *~, +++, ---, *--, /++, ~~, ~-, -~, --, ++, ^^+, in++, |-, %~, ect... +* is a specially bad idea, as I would read that as a + (*b), which is quite usual in C. But in general very cool. I love ~~ and |- the most :-)
Re: auto ref is on the docket
On Tuesday, 23 June 2015 at 12:45:25 UTC, kink wrote: On Tuesday, 23 June 2015 at 09:57:26 UTC, Marc Schütz wrote: To guarantee this from the caller's POV, the callee must be pure and the parameters must be known not to alias each other. This is obviously true. Rvalues aren't affected as they cannot alias another parameter by definition. You're right, I didn't think of that! They are not _transitively_ unique, but there can indeed be no other references to the rvalues themselves. So for rvalues, const is enough. Nice :-) Lvalues are if passed by ref and the same instance is accessible by mutable ref from another parameter or global. But as shown by your example, that danger is always there. The proposed `in` semantics make it less obvious, that's true, but I still think it'd be worth it, as these aliasing bugs are a pain to track down, but in my experience extremely rare.
Re: Phobos addition formal review: std.experimental.allocator
On 6/23/15 9:48 AM, extrawurst wrote: I agree with Adam on this: Just a quick concern, I don't think a package.d should ever have anything except imports in it (see http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dlang.org) What is the rationale? -- Andrei
Re: std.experimental.color, request reviews
On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:
But that's more an argument against putting anything _except_
the basic definitions into package.d, no? Then you can always
exclude the more specific stuff whenever you need it, and those
modules themselves can publicly import package.d.
What if you want the basic definitions alone to build something
off of?
If I want to write an image library that can share pixels with
your image library, I might import std.color just to get the
pixel format. I don't need the list of colors nor any algorithms,
I just want to share the basic type so our two libraries can pass
data back and forth.
So I write like
RGBA8[] readImage() {}
With the std.color functions, some other library can now take
that pixel array and convert it or whatever they need to do.
Great, you can use my thing pretty easily.
But I don't need any conversions myself. I don't do
transformations. I don't use named colors, blending functions, or
anything else. (Maybe my image format is extremely simple.)
So pulling the rest of the library would waste compile time and
binary space. Especially if a user wanted my extremely simple
image format exactly because they were short on time and space.
So ideally, my module would ONLY import std.color.basic_types or
something like that but alas, RGBA8 is defined in package.d,
so if I want it, whether I like it or not, I just pulled half the
std.color library
which just pulled std.traits and std.typecons, which, thankfully,
didn't import anything else, but that's not the case for so many
Phobos modules.
This layout isn't bad today, the std.color in the PR is pretty
small and pretty lazy thanks to the templates and local imports
in them, but I still want to set a precedent in Phobos of
untangling the web of dependencies by moving as much independent
code as reasonably possible to independent modules.
Re: std.experimental.color, request reviews
On Tue, Jun 23, 2015 at 03:24:41PM +, John Colvin via Digitalmars-d wrote: On Tuesday, 23 June 2015 at 15:01:59 UTC, Adam D. Ruppe wrote: Just a quick concern, I don't think a package.d should ever have anything except imports in it. Put all the actual aliases and color lists in some other submodule that can be imported independently with minimal dependencies. std/range/package.d and std/regex/package.d both have a bunch of stuff in. Why not? That's a temporary situation. When those packages were broken up, we didn't want to make too extensive a change, so we left the less important bits in package.d. Ideally, however, they should be moved into their own subpackages. T -- EMACS = Extremely Massive And Cumbersome System
Re: D could catch this wave: web assembly
On 06/23/2015 09:44 AM, Adam D. Ruppe wrote: Nick, you might be interested in this quick thing I just wrote up: http://arsdnet.net/articles/web-apps.html A few years ago, I was talking about a new windowing system... and believe it or not, I'm still slowly moving forward with it, but I think existing X is good enough to start with for this idea. My old thing was about thin clients used through the web. Yea, totally! Actually, that windowing system of yours has been in the back of my mind whenever I think of web apps for the past several years since you first put it up. Although I wouldn't put too much reliance on X, what with Wayland on the way. Well, I like downloading programs too sometimes, can we solve that problem? Web apps do an ok job, so do app stores. Let's get the best of both worlds: download a program that targets a standard Linux VM distributed with browsers. I go into a bit more detail in the link. Yea, I'll have to take a closer look at that. My first impression is that Linux VM sounds very heavy-weight, but I supposed it need not necessarily be.
Re: Phobos addition formal review: std.experimental.allocator
On Tuesday, 23 June 2015 at 15:56:15 UTC, Andrei Alexandrescu wrote: On 6/23/15 2:18 AM, Dicebot wrote: On Monday, 22 June 2015 at 22:38:19 UTC, Andrei Alexandrescu wrote: Perhaps I misunderstood the request - currently the imports in allocator/package.d are: public import std.experimental.allocator.common, std.experimental.allocator.typed; import std.algorithm, std.conv, std.exception, std.range, std.traits, std.typecons, std.typetuple; version(unittest) import std.random, std.stdio; Is that okay, and if not what should change? My concern was about the fact that symbols `IAllocator`, `theAllocator`, `processAllocator` and bunch of others are defined within `package.d` itself and not provided via public import. That means that anyone willing to change default allocator or use `make` MUST import all std.allocator modules even if nothing else is really needed (those utilities look very independent). Which means processing bunch of unnecessary imports - and more of those if more modules will get added to the package. I'd prefer to have a small dedicated module, i.e. `std.allocator.api` (not going to discuss names!) and do public import of it from `std.allocator.package.d`. Makes sense? I see. Well this raises the question whether importing std.xyz automatically means everything under std.xyz is transitorily imported. Right now it's not - the more advanced/obscure building blocks are not automatically imported if you just import std.allocator; for those you'd need to import the std.allocator.building_blocks package, or individual modules from it like std.allocator.building_blocks.region. This idea was proposed by Mike on 2015/05/18: Would it be better to move the porcelain code into package.d so the nomenclature simply becomes `import std.allocator;`? I liked the idea that someone who's not an expert goes let me import std.allocator and call it a day whereas someone who wants to tweak, customize, etc. they'd need to be more specific. If we define an entry point such as std.allocator.api, novices will have one more thing to remember, or some will still import std.allocator thus pulling everything without realizing it. So I'd say let's keep simple things simple. If you want to allocate, import std.allocator. Andrei I agree with Adam on this: Just a quick concern, I don't think a package.d should ever have anything except imports in it (see http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dlang.org) for convenience the package.d could still import a bunch of default stuff publicly for the normal user.
Re: Phobos addition formal review: std.experimental.allocator
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote: On 6/23/15 9:48 AM, extrawurst wrote: I agree with Adam on this: Just a quick concern, I don't think a package.d should ever have anything except imports in it (see http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dlang.org) What is the rationale? -- Andrei I simply quote his following post in the mentioned thread: The biggest benefit of breaking up the big modules is so you can access some of it without requiring all of it. But when the part you want is in the package.d, you can't get it independently anymore; importing that also imports everything else, negating the reason it was split up in the first place.
[Issue 14712] GIT HEAD : std.net.curl regressions
https://issues.dlang.org/show_bug.cgi?id=14712 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/53e4c659682264321e5339615c7a1c6158f8aa6d fix Issue 14712 - GIT HEAD : std.net.curl regressions https://github.com/D-Programming-Language/phobos/commit/04494ce5aea4f338592cc50306dfdc6052d6b91f Merge pull request #3436 from CyberShadow/pull-20150623-170241 fix Issue 14712 - GIT HEAD : std.net.curl regressions --
Re: Phobos addition formal review: std.experimental.allocator
On 6/23/15 8:56 AM, Andrei Alexandrescu wrote: I see. Well this raises the question whether importing std.xyz automatically means everything under std.xyz is transitorily imported. s/transitorily/transitively/
Re: What have you done with UDAs?
On 6/23/15 8:05 AM, Alex Parrill wrote: (somewhat related: std.getopts is kinda bad; you can't get help text without successfully parsing arguments and `required` breaks `--help`) Could you please submit these as bug reports at http://issues.dlang.org - thanks! -- Andrei
Re: Casting MapResult
On Tuesday, 23 June 2015 at 10:50:51 UTC, John Colvin wrote: If I remember correctly, core.simd should work with every compiler on every supported OS. What did you try that didn't work? I figured out the issue! You have to compile using the -m64 flag to get it to work on Windows (this works on both dmd and rdmd). The 32bit specification does not support SIMD. I don't think I had ever noticed that it wasn't using a 64bit compilation. I was a little disheartened getting an error running one of the first pieces of code on this page http://dlang.org/simd.html the second line below, some casting issue. int4 v = 7; v = 3 * v; // multiply each element in v by 3 Outside of that, I can see one issue. I was overloading a version of exp that takes a real and returns a real. I see no support for a real SIMD type, perhaps because the CPUs don't support it. So I pretty much could only overload the float or double versions. On std.parallelism, I noticed that I could only loop through the static arrays with foreach with I appended them with []. I still get mixed up on that syntax. The good thing about static loops is that I could determine the length at compile time. I'm not positive, but I think I might be able to get it set up so that I could have different functions, one non-parallel below some length and one parallel above some length. This is good because the parallel one may not be able to use all the function attributes of the non-parallel ones. I haven't been able to get anything like that to work for a dynamic array version as the length is not known at compile time, just one big function.
Re: D could catch this wave: web assembly
On 06/23/2015 07:09 AM, Joakim wrote: But if you have some emotional connection with the term desktop and can't take the fact that they're being rendered defunct, I can see why you'd want to ignore all that and just call the new devices converged or desktops. :) As opposed to someone with an emotional connection with the term smartphone and can't take the fact that what such devices are turning into is not what they used to be and that they're getting there by borrowing from an old uncool outdated style of computing ;) I've done so already. It's absolutely terrible. At best, it's an occasional replacement for those already-horrid mini-touchscreen-keyboards (which almost anything is better than). I've been surprised on the few occasions I used google's voice translation about how good it was, but I haven't use it much. It's much better than I expected too, but even still, approx 50% of the time I use it (50% is NOT an exaggeration here) I end up having to go back and edit its mistakes. Plus it's laggy because of yet another problem: It works by sending everything the mic hears straight to Google. So much for end-to-end encryption/privacy. And then here's the one that isn't even conceivably fixable by technological improvements: I've found that oftentimes, dictation is just isn't a very natural fit for your mental process, even if it does work flawlesly. I know that's somewhat vague, because it's difficult to explain. but I'll put it this way: Dictation is almost like the waterfall model of text entry. Versus a keyboard being more naturally suited to iterative refinement, and working out how you want to word something. Sure, you can do that with voice, but it's less natural. (That's actually part of why I prefer email to telephone calls for business and technical communications.)
[Issue 14724] New: std.getopt: config.required breaks --help
https://issues.dlang.org/show_bug.cgi?id=14724
Issue ID: 14724
Summary: std.getopt: config.required breaks --help
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: initrd...@gmail.com
Specifying a required argument to getopt causes `prog --help` to fail with an
error saying that the required argument was missing.
Example program:
import std.getopt;
void main(string[] args) {
string filename;
auto helpinfo = getopt(args,
std.getopt.config.required, filename, A file to read, filename,
);
if(helpinfo.helpWanted) {
defaultGetoptPrinter(I am help text, helpinfo.options);
}
}
$ rdmd test.d --help
std.getopt.GetOptException@/usr/include/dmd/phobos/std/getopt.d(572): Required
option filenamewas not supplied
...
(there's also a typo in the error message, but I submitted a pull request to
fix it awhile ago and it was accepted)
--
Re: D could catch this wave: web assembly
On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote: Although I wouldn't put too much reliance on X, what with Wayland on the way. meh, wayland doesn't look very interesting to me, especially in this use case where I'd want a network protocol because the application runs on an isolated VM and needs to communicate with the host somehow. Yea, I'll have to take a closer look at that. My first impression is that Linux VM sounds very heavy-weight, but I supposed it need not necessarily be. Well, keep in mind that I want to kill the browser, which is already very heavy-weight! Firefox is like 80 MB http://www.tinycorelinux.net/downloads.html that's 9 MB and probably more than the browser VM would need! The core system should be sharable without copying the file every time, and its only job is to run one program, providing it a familiar, consistent base api. I don't think the weight would be much of a problem, though perhaps it might be on the mobile sphere.
[Issue 14712] GIT HEAD : std.net.curl regressions
https://issues.dlang.org/show_bug.cgi?id=14712 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #3 from Vladimir Panteleev thecybersha...@gmail.com --- Introduced in https://github.com/D-Programming-Language/phobos/pull/3319 --
[Issue 14712] GIT HEAD : std.net.curl regressions
https://issues.dlang.org/show_bug.cgi?id=14712 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #5 from Vladimir Panteleev thecybersha...@gmail.com --- *** Issue 14707 has been marked as a duplicate of this issue. *** --
Re: auto ref is on the docket
On Tuesday, 23 June 2015 at 16:27:34 UTC, Jonathan M Davis wrote: On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote: On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis wrote: [...] Thus the solution cannot require const. auto is worse because, if you later decide you need to add a template parameter then the meaning is changed and you get a _hidden_ performance issue. And how does it introduce a hidden performance issue. You'd end up with some template bloat, but that's it, and that's just going to increase the memory footprint of your program slightly, which isn't generally going to be a performance issue. It's just going to make your program slightly larger. - Jonathan M Davis instruction cache misses can really hurt
Re: core.exception.InvalidMemoryOperationError@(0) on File Reading.
On Monday, 22 June 2015 at 20:30:40 UTC, David DeWitt wrote: I am getting an core.exception.InvalidMemoryOperationError@(0) auto recs = f // Open for reading .byLineCopy(); .array; //Here is where is appears to be happening. [...] I have had a chance to try the new phobos. Dealing with the errors related to: http://forum.dlang.org/thread/mm1fdo$q5u$1...@digitalmars.com in debian. Gonna mess with it some more when I have a chance.
Re: std.collection - changing the collection while iterating
On Mon, Jun 22, 2015 at 8:39 PM, philippecp via Digitalmars-d digitalmars-d@puremagic.com wrote: I think the best approach is the following: * Throw exceptions on debug (usability) * Leave undefined on release (performance) Please no. Different behavior between release and non is not something to be desired.
Re: Future(s) for D.
On Tue, 23 Jun 2015 15:04:49 -0400, Nick Sabalausky wrote: Even that intrinsic passion in the field itself isn't strictly necessary to be a good programmer. I know that sounds wrong, but hear me out: All that's REALLY needed at the bare minimum is the basic integrity to say If this is what I'm going to be working on, even if I'm only in it for the money, then goddammit I'm going to do the best job I can. Because this is the job I'm being paid to do. But a lot of the code monkeys can't even muster up that much. i must confess that i too cannot into such way thinking. that's why i never took a job i'm not really interested in: it's simply unfair to take employer's money if i'm not interested in result, an employer surely can hire someone better. signature.asc Description: PGP signature
Re: std.math.isIdentical and NaN
On Mon, 22 Jun 2015 09:41:08 +, Jonathan M Davis wrote: Still, it seems odd to compare part of the NaN for equality but not all of it. it's very useful for NaN-boxing. signature.asc Description: PGP signature
Re: fast way to insert element at index 0
On 6/23/15 10:20 AM, Baz wrote:
On Tuesday, 23 June 2015 at 13:29:41 UTC, Steven Schveighoffer wrote:
On 6/23/15 8:12 AM, Baz wrote:
On Tuesday, 23 June 2015 at 11:22:31 UTC, Steven Schveighoffer wrote:
[...]
according to the C library, memmove handle overlapps, you mismatch with
memcpy which does not.
The above is not memmove, it's slice assignment, which is specifically
illegal for overlaps:
$ cat testsliceassign.d
void buffer[100];
void main()
{
buffer[1..$] = buffer[0..$-1];
}
$ dmd testsliceassign.d
$ ./testsliceassign
object.Error@(0): Overlapping arrays in copy: 98 byte(s) overlap of 99
ok. i was, wrongly, suposing that this operation uses memmove under the
hood.
btw you forgot to grow the array size, if i dare.
Heh, it was just to demonstrate the error :) The code does a whole lot
of nothing, actually.
-Steve
[Issue 9532] scope(exit) + alloca - internal error
https://issues.dlang.org/show_bug.cgi?id=9532 Maxim Fomin maxim-fo...@outlook.com changed: What|Removed |Added Status|NEW |RESOLVED CC||maxim-fo...@outlook.com Resolution|--- |WORKSFORME --- Comment #3 from Maxim Fomin maxim-fo...@outlook.com --- I suggest to close. It is not clear whether it was filed as ICE or as enhancement. If latter, a new issue can be opened. --
Re: D could catch this wave: web assembly
On Tue, 23 Jun 2015 18:26:07 +, deadalnix wrote: I'm not sure of your use case, but wayland is clearly a huge step forward compared to X. yep, they reinvented DirectFB and dropped alot of libs on top of it. really a huge step. signature.asc Description: PGP signature
Re: auto ref is on the docket
On Tue, 23 Jun 2015 14:33:49 -0400, kinke no...@nowhere.com wrote: On Tuesday, 23 June 2015 at 18:11:21 UTC, bitwise wrote: On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr timon.g...@gmx.ch wrote: There is no reason to prevent templates from using the mechanism that generates only one copy. The two mechanisms shouldn't share the same syntax, because then there is no way to tell them apart for template functions. You would be losing the optimization of passing primitive types by value, wouldn't you? Not if you keep the current `auto ref` template syntax AND introduce another syntax `scope ref` for non-escapable references also accepting rvalues. I don't think 'scope ref' is on the table at this point(although I do believe it should be). And I still think Timon's statement is untrue. There is a reason, which is that the new auto ref syntax forces reference parameters for all types(even primitives), where the old template approach does not. Bit
Re: What have you done with UDAs?
On Tuesday, 23 June 2015 at 06:43:21 UTC, Rikki Cattermole wrote: I am currently writing a ui system that defines the majority of the layout in a dsl. The ui element types are defined in D code and I use uda's to mark which fields can be accesses by the dsl. Got a repo yet? Would be interested in reading more about it. Not yet, it's integrated into a game engine I am working on and it's in the early stages of usability, will probably split it off once it gets more mature.
Re: std.experimental.color, request reviews
On Tuesday, 23 June 2015 at 17:11:57 UTC, Adam D. Ruppe wrote:
On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:
But that's more an argument against putting anything _except_
the basic definitions into package.d, no? Then you can always
exclude the more specific stuff whenever you need it, and
those modules themselves can publicly import package.d.
What if you want the basic definitions alone to build something
off of?
If I want to write an image library that can share pixels with
your image library, I might import std.color just to get the
pixel format. I don't need the list of colors nor any
algorithms, I just want to share the basic type so our two
libraries can pass data back and forth.
So I write like
RGBA8[] readImage() {}
With the std.color functions, some other library can now take
that pixel array and convert it or whatever they need to do.
Great, you can use my thing pretty easily.
But I don't need any conversions myself. I don't do
transformations. I don't use named colors, blending functions,
or anything else. (Maybe my image format is extremely simple.)
So pulling the rest of the library would waste compile time and
binary space. Especially if a user wanted my extremely simple
image format exactly because they were short on time and space.
So ideally, my module would ONLY import std.color.basic_types
or something like that but alas, RGBA8 is defined in
package.d, so if I want it, whether I like it or not, I just
pulled half the std.color library
which just pulled std.traits and std.typecons, which,
thankfully, didn't import anything else, but that's not the
case for so many Phobos modules.
This layout isn't bad today, the std.color in the PR is pretty
small and pretty lazy thanks to the templates and local imports
in them, but I still want to set a precedent in Phobos of
untangling the web of dependencies by moving as much
independent code as reasonably possible to independent modules.
Isn't this what selective imports are for? Admittedly it's not
quite as convenient, but it does let you choose exactly what you
want. You can even make a module that wraps a manually selected
set of imports, e.g. you do your own basic_types module.
In the end, if you have specific requirements, you have to be
specific.
Re: std.experimental.color, request reviews
On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote: Isn't this what selective imports are for? Admittedly it's not quite as convenient, but it does let you choose exactly what you want. You can even make a module that wraps a manually selected set of imports, e.g. you do your own basic_types module. In the end, if you have specific requirements, you have to be specific. Unfortunately, selective imports have been broken for 9 years.
Re: We simply must implement this for D to stay competitive
On Sat, 20 Jun 2015 15:38:29 -0700, Walter Bright wrote: https://github.com/rollbear/basicpp this is doable with Adam's jsvar.d and compile-time parser. parser needs to be written, though. i did that once, but found BASIC too complicated and retreated to D. signature.asc Description: PGP signature
Re: auto ref is on the docket
On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr timon.g...@gmx.ch wrote: There is no reason to prevent templates from using the mechanism that generates only one copy. The two mechanisms shouldn't share the same syntax, because then there is no way to tell them apart for template functions. You would be losing the optimization of passing primitive types by value, wouldn't you? Bit
Re: stdx.data.json needs a layer on top
On Tuesday, 23 June 2015 at 14:06:38 UTC, Sönke Ludwig wrote: As I understand it, there is a gap between what you can currently do with std.json (and indeed vibed json) and what you can do with stdx.data.json. And the capability falls short of what can be done in other standard libraries such as the ones for python. So since we are going for a nuclear-power station included approach, does that not mean that we need to specify what this layer should do, and somebody should start to work on it? One thing. which I consider the most important missing building block, is Jacob's anticipated std.serialization module [1]*. Skipping the data representation layer and going straight for a statically typed access to the data is the way to go in a language such as D, at least in most situations. Thanks, Sonke. I appreciate your taking the time to reply, and I hope I represented my understanding of things correctly. I think often things get stuck in limbo because people don't know what's most useful, so I do think a central list of things that need to be done in D ecosystem might be nice, if it doesn't become excessively structured and bureaucratic. (I ain't volunteering to maintain it, as I can't commit to it). Thing is there are different use cases. For example, I pull data from Quandl - the metadata is standard and won't change in format often; but the data for a particular series will. For example if I pull volatility data that will have different fields to price or economic data. And I don't know beforehand the total set of possibilities. This must be quite a common use case, and indeed I just hit another one recently with a poorly-documented internal corporate database for securities. Maybe it's fine to generate the static typing in response to reading the data, but then it ought to be easy to do so (ultimately). Because otherwise you hack something up in Python because it's just easier, and that hack job becomes the basis for something larger then you ever intended or wanted and it's never worth rewriting given the other stuff you need. But even if you prefer static typing generated on the fly (which maybe becomes useful via introspection a la Alexandrescu talk), sometimes one will prefer dynamic typing, and since it's easy to do in a way that doesn't destroy the elegance and coherence of the whole project, why not give people the option ? It seems to me that Guido painted a target on Python by saying it's fast enough, and you are usually I/O etc bound, because the numerical computing people have different needs. So BLAS and the like may be part of that, but also having something like pandas - and the ability to get data in and out of it - would be an important part in making it easy and fun to use D for this purpose, and it's not so hard to do so, just a fair bit of work. Not that it makes sense to undergo a death march to duplicate python functionality, but there are some things that are relatively easy that have a high payoff - like John Colvin's pydmagic. (The link here, which may not be so obvious, is that in a way pandas is a kind of replacement for a spreadsheet, and being able to just pull stuff in without minding your 'p's and 'q's to get a quick result lends itself to the kind of iterative exploration that makes spreadsheets still overused even today. And that's the link to JSON and (de)-serialization). Another part is a high level layer on top of the stream parser that exists for a while (albeit with room for improvement), but that I forgot to update the documentation for. I've now caught up on that and it can be found under [2] - see the read[...] and skip[...] functions. Thank you for the link. Do you, or anyone else, have further ideas for higher level functionality, or any concrete examples in other standard libraries? Will think it through and try to come up with some simple examples. Paging John Colvin and Russell Winder, too. * Or any other suitable replacement, if that doesn't work out for some reason. The vibe.data.serialization module to me is not a suitable candidate as it stands, because it lacks some features of Jacob's solution, such as proper handling of (duplicate/interior) references. But it's a perfect fit for my own class of problems, so I currently can't justify to put work into this either. Is it worth you or someone else trying to articulate well what it does well that is missing from stdx.data.json?
Re: D could catch this wave: web assembly
On 06/23/2015 03:03 PM, ketmar wrote: 2. actually, we should drop that progressive rendering. so-called web apps already dropped that, drawing rotating shit icon instead while they are loading megabytes of js. there is no sense to support progressive rendering anymore: it's either not working completely with modern web- pages, or page looks like random jumping crap until it fully loads. Hadn't thought of that before, but that's a good point. Plus, all that background loading and processing just borks the responsiveness of webpage to the point of being effectively-unusable anyway (and even the browser as a while, depending on browser. Mobile ones seem to be worse here.) I'd just as soon the browser do it's thing and get back to me whenever it's finally ready to show it and actually respond to my input events. Progressive rendering made sense back when you could literally watch each image on the page gradually get pulled in over the wire (and when the layout more or less matched the HTML as it came in over-the-wire). But now it's mostly just a clunky user experience.
Re: Learning D Available for Pre-Order
On Tuesday, 23 June 2015 at 14:47:03 UTC, Mike Parker wrote: The project that has taken me away from Derelict since the end of February is now available for pre-order at [1]. I'm currently about 60% through the preliminary draft stage and, given that I've recently acquired a significant amount of free time in my schedule, expect to accelerate my pace on the remaining 40%. I need as much time as I can make for the revisions! Awesome news. The more books written on D the better. Good work! So far in the course of writing this book, I've learned that I knew less about the fundamentals of D than I thought I did and that the more difficult parts of the language aren't so difficult. That was my experience exactly when i wrote a programming book a decade ago. :)
Re: Future(s) for D.
On Sun, 21 Jun 2015 13:24:14 +, Tobias Müller wrote: For many programmers, programming is just a job, not more. They don't program in their spare time and are not really interested in programming languages as you are. that people called code monkeys, not programmers. it's simply impossible to be a programmer without a passion to learn things. not 'cause well, if i learn XYZ i will be promoted to better job and will get more money, but 'cause hey, that's *interesting*! i may never use that in my job (this is usually wrong), but it's so interesting that i can't pass it by! code monkeys are good when there is a need in writing boilerplate code, but they are bad for solving problems. not necessarily 'cause they're dumb, they simply not interested in problem solving. signature.asc Description: PGP signature
[Issue 10398] Dmd bugs detected by memcheck when compile druntime+phobos
https://issues.dlang.org/show_bug.cgi?id=10398 Maxim Fomin maxim-fo...@outlook.com changed: What|Removed |Added Status|NEW |RESOLVED CC||maxim-fo...@outlook.com Resolution|--- |FIXED --
Re: Future(s) for D.
Chris wrote: This already started in the 1990ies and got worse and worse, this business of looking for the perfect candidate. A lot of skills can be acquired in the first weeks (or months, depending). It's better to train someone who's intelligent and innovative than someone who's worked with all IDEs and build systems, but is fairly un-innovative (problem = for loop). I agree with you, although I don't know how many others would. And not all people are equally gifted in picking things up - it's ability, but also character since when many people get to a certain level of accomplishment they get addicted to the feeling of comfort and would rather die than truly push themselves when they don't know how it will turn out. On Tuesday, 23 June 2015 at 18:15:47 UTC, ketmar wrote: For many programmers, programming is just a job, not more. They don't program in their spare time and are not really interested in programming languages as you are. that people called code monkeys, not programmers. it's simply impossible to be a programmer without a passion to learn things. not 'cause well, if i learn XYZ i will be promoted to better job and will get more money, but 'cause hey, that's *interesting*! i may never use that in my job (this is usually wrong), but it's so interesting that i can't pass it by! code monkeys are good when there is a need in writing boilerplate code, but they are bad for solving problems. not necessarily 'cause they're dumb, they simply not interested in problem solving. Yes - the intriguing thing is that this trend has gone so far that good people and mediocre people are the same price if they look similar on paper (from what I have seen). In fact you may be able to hire someone good for less than someone mediocre since they are less tolerant of a bad working environment and want to work on something that inspires them (whereas the average person lacks imagination to see what might come out of the ordinary-looking seeds of today) . As an entrepreneur, this is one of the biggest arbitrages for many years, I think - provided you are able to tell good from mediocre (or to put it charitably, top notch from merely solid). https://www.quora.com/Why-does-D-E-Shaw-pay-young-Harvard-and-MIT-graduates-over-200-000-per-year-right-out-of-college/answer/Laeeth-Isharc This isn't technology specific, but it fits with what I have heard from talking to people who are in that very specific field. I think that's what the Quora guys mean when they talk of 10x programmers, but it's not at all the description or way of thinking I would apply, since obviously it puts the emphasis on measuring what is not so easy to measure. At my (now defunct - a different story) previous startup fund, we had 1200 applications for 2 junior jobs - that's a lot, even limiting it to the serious candidates. And they all look great on paper, and one couldn't possibly even call them all. (For this role, I was more concerned about missing someone amazing than making the wrong hire - not the normal corporate priorities). So I wrote an Oxbridge style applied economics open-ended question. Most of the perfect candidates on paper just regurgitated what they read in the FT; a few didn't and actually thought about it. And the girl that got the job spent 45 hours writing her paper, which was more useful than the stuff you would get from a 40 year old seasoned guy. No way would we have found her had we had an HR department (or rather had we let HR 'help' us). For technology, it's different, but I think the same way of thinking may prove useful. And if/when I need a tech guy to help me, it's a nobrainer to ask here because of the quality of the people. Although that is not why I am here.
Re: D could catch this wave: web assembly
On Sat, 20 Jun 2015 19:40:35 +, Ola Fosheim Grøstad wrote: On Saturday, 20 June 2015 at 16:20:31 UTC, ketmar wrote: On Sat, 20 Jun 2015 16:14:43 +, Ola Fosheim Grøstad wrote: On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote: it was designed to ignore that fact altogether. html/css layouting is a pitiful attempt and barely usable. bwah, it can't even do normal constraints! Hmmm, what do you mean by normal constraints? google://cassowary that is a *real* constraint engine. what we have in css is a half-assed attemt to emulate the real engine without the engine itself. Keep in mind that a webpage is being rendered while loading⦠1. cassowary is dynamic solver, it can continuously adjust it's solution as more and more constraints are added. actually, that is one of it's core features. 2. actually, we should drop that progressive rendering. so-called web apps already dropped that, drawing rotating shit icon instead while they are loading megabytes of js. there is no sense to support progressive rendering anymore: it's either not working completely with modern web- pages, or page looks like random jumping crap until it fully loads. signature.asc Description: PGP signature
Re: Future(s) for D.
On 06/23/2015 02:15 PM, ketmar wrote: On Sun, 21 Jun 2015 13:24:14 +, Tobias Müller wrote: For many programmers, programming is just a job, not more. They don't program in their spare time and are not really interested in programming languages as you are. that people called code monkeys, not programmers. it's simply impossible to be a programmer without a passion to learn things. not 'cause well, if i learn XYZ i will be promoted to better job and will get more money, but 'cause hey, that's *interesting*! i may never use that in my job (this is usually wrong), but it's so interesting that i can't pass it by! Even that intrinsic passion in the field itself isn't strictly necessary to be a good programmer. I know that sounds wrong, but hear me out: All that's REALLY needed at the bare minimum is the basic integrity to say If this is what I'm going to be working on, even if I'm only in it for the money, then goddammit I'm going to do the best job I can. Because this is the job I'm being paid to do. But a lot of the code monkeys can't even muster up that much.
[Issue 14727] std.json incorrectly supports inf and nan
https://issues.dlang.org/show_bug.cgi?id=14727 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com Hardware|x86_64 |All OS|Linux |All --- Comment #1 from ag0ae...@gmail.com --- I think this has been fixed recently. Git head phobos throws std.json.JSONException@std/json.d(1170): Cannot encode Infinity. Consider passing the specialFloatLiterals flag. Corresponding pull request: https://github.com/D-Programming-Language/phobos/pull/3141 The mentioned specialFloatLiterals is not set by default. Setting it makes it so that inf/nan get stringified to JSON strings (not null). Are you ok with this? --
Re: std.collection - changing the collection while iterating
On Tuesday, 23 June 2015 at 19:13:43 UTC, Jeremy Powers wrote: On Mon, Jun 22, 2015 at 8:39 PM, philippecp via Digitalmars-d digitalmars-d@puremagic.com wrote: I think the best approach is the following: * Throw exceptions on debug (usability) * Leave undefined on release (performance) Please no. Different behavior between release and non is not something to be desired. It's perfectly normal if we're talking about assertions, but in that case, it's an AssertError being thrown, not a normal exception. So, in either case, it's a logic error; it's just that you get better reporting of it in debug mode than in release and don't have the cost of doing the checking in release. - Jonathan M Davis
Re: auto ref is on the docket
On Tuesday, 23 June 2015 at 19:13:28 UTC, bitwise wrote: And I still think Timon's statement is untrue. There is a reason, which is that the new auto ref syntax forces reference parameters for all types(even primitives), where the old template approach does not. Timon suggested using another syntax/name for the new refs, as one couldn't use them in templates [and the different `auto ref` behavior is just prone to confuse beginners, my 2 cents]. One reason for preferring `scope ref` over `auto ref` in templates would be situations where code bloat is more important than runtime performance, another reason the fact that `in ref` is more convenient than `const auto ref`. ;)
Re: std.experimental.color, request reviews
On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote: https://github.com/D-Programming-Language/phobos/pull/2845 I'm getting quite happy with it. I think it's a good and fairly minimal but useful starting point. It'd be great to get some reviews from here. Swizzels would be a nice addition.
Re: Future(s) for D.
On 06/23/2015 03:19 PM, ketmar wrote: On Tue, 23 Jun 2015 15:04:49 -0400, Nick Sabalausky wrote: Even that intrinsic passion in the field itself isn't strictly necessary to be a good programmer. I know that sounds wrong, but hear me out: All that's REALLY needed at the bare minimum is the basic integrity to say If this is what I'm going to be working on, even if I'm only in it for the money, then goddammit I'm going to do the best job I can. Because this is the job I'm being paid to do. But a lot of the code monkeys can't even muster up that much. i must confess that i too cannot into such way thinking. that's why i never took a job i'm not really interested in: it's simply unfair to take employer's money if i'm not interested in result, an employer surely can hire someone better. Of course, that's also a form of respectable personal integrity, too. (one that a lot of people don't share - well, not that everyone always has the luxury of doing so, but still, it's a good attitude to have). And yea, naturally, personal interest does make it a lot easier to coax oneself to do a good job.
Re: std.experimental.color, request reviews
On 6/23/15 1:59 PM, Meta wrote: On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote: Isn't this what selective imports are for? Admittedly it's not quite as convenient, but it does let you choose exactly what you want. You can even make a module that wraps a manually selected set of imports, e.g. you do your own basic_types module. In the end, if you have specific requirements, you have to be specific. Unfortunately, selective imports have been broken for 9 years. Even selective imports being fixed, the benefits in terms of separate compilation and encapsulation are worth it. I agree with the idea to limit package.d to just public imports. I don't think it should be enforced by the compiler, but it should be something Phobos strives for and that we recommend. -Steve
Re: std.experimental.color, request reviews
On Tuesday, 23 June 2015 at 17:59:48 UTC, Meta wrote: On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote: Isn't this what selective imports are for? Admittedly it's not quite as convenient, but it does let you choose exactly what you want. You can even make a module that wraps a manually selected set of imports, e.g. you do your own basic_types module. In the end, if you have specific requirements, you have to be specific. Unfortunately, selective imports have been broken for 9 years. There is hope: https://github.com/D-Programming-Language/dmd/pull/3407
[Issue 11460] ICE for opDispatch and UFCS function (2.064)
https://issues.dlang.org/show_bug.cgi?id=11460 Maxim Fomin maxim-fo...@outlook.com changed: What|Removed |Added Status|NEW |RESOLVED CC||maxim-fo...@outlook.com Resolution|--- |WORKSFORME --- Comment #1 from Maxim Fomin maxim-fo...@outlook.com --- Cannot reproduce on 2.067 --
Re: D could catch this wave: web assembly
On Tuesday, 23 June 2015 at 16:36:21 UTC, Adam D. Ruppe wrote: On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote: Although I wouldn't put too much reliance on X, what with Wayland on the way. meh, wayland doesn't look very interesting to me, especially in this use case where I'd want a network protocol because the application runs on an isolated VM and needs to communicate with the host somehow. I'm not sure of your use case, but wayland is clearly a huge step forward compared to X. Take it from someone that have messed up with both.
Re: Future(s) for D.
On Sun, 21 Jun 2015 23:08:07 +, rsw0x wrote: No, there really are no libraries for D. And it's 1000x worse if you attempt to use D for anything related to system's programming aka no GC available. I got so fed up that I ported my project from D to C. I'll gladly trade a worse language for not having to write an entire standard library by myself. but you don't have to drop D to use C libraries! some of my code is full of calls to libc and other C libs, neatly wrapped in D structs. i don't really want to remember when to write - anymore, or oh, i forgot a typedef here, so it will be `struct my_s`, or use C macros instead of D templates. after decades of C experience i dropped it without any doubts, and i surely don't want to get back. you see, i have alot of libraries written for C during this years, and i dropped all that, 'cause D is so better C, that there are no reasons to use C anymore. and i always can wrap C library if i need that, most of the work on wrapping can be done with sed. ;-) so i really can't see any reason to go back to C instead of using D with C libraries. signature.asc Description: PGP signature
Re: auto ref is on the docket
On Tuesday, 23 June 2015 at 18:11:21 UTC, bitwise wrote: On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr timon.g...@gmx.ch wrote: There is no reason to prevent templates from using the mechanism that generates only one copy. The two mechanisms shouldn't share the same syntax, because then there is no way to tell them apart for template functions. You would be losing the optimization of passing primitive types by value, wouldn't you? Not if you keep the current `auto ref` template syntax AND introduce another syntax `scope ref` for non-escapable references also accepting rvalues.
Re: std.experimental.color, request reviews
Am 23.06.2015 um 16:58 schrieb Manu via Digitalmars-d: https://github.com/D-Programming-Language/phobos/pull/2845 I'm getting quite happy with it. I think it's a good and fairly minimal but useful starting point. It'd be great to get some reviews from here. From a quick glance, looks very nice! If there was channel swizzling and an underlying (low dimensional) vector type, I could use it more or less as a drop-in replacement in my code. One thing that I was wondering if it wouldn't make more sense overall for the color string representation to use RGBA instead of ARGB. The former is a lot more common outside of 3D APIs/hardware and arguably more intuitive.
Re: D could catch this wave: web assembly
On Sat, 20 Jun 2015 17:00:43 +, Kagamin wrote: Well, it's just windows api was simple enough to be usable directly, while X11 didn't fly that way and didn't receive development since everybody used toolkits and all features were implemented in toolkits, which in the end used X11 as plain canvas rather than windowing system. nope, X is a window system. it's windows which is *not* window system, but window system with very simplistic toolkit bolted on top of it. that was not a bad idea considering the hardware windows aimed, but now it's a legacy crap, and almost anyone is hacking around it. Knowing minimal size won't help you if the amount of information simply doesn't fit. somehow it still works for me. Dialogs can be scrolled, but master-detail views can't: master and detail views already reserve scrolling for themselves, so it can't be reused for the entire window, well, at least it won't work naturally. i believe that we should stop here, as we are clearly talking about different things. i can't even imagine why widget may want to reserve scrolling for itself and what that means. and i can't see why any part of window can't be scrolled, especially when you have a clear widget hierarchy, and detail views living in their own containers. signature.asc Description: PGP signature
Re: stdx.data.json needs a layer on top
On Tuesday, 23 June 2015 at 12:28:00 UTC, Rikki Cattermole wrote: Please come onto https://www.livecoding.tv/alphaglosined/ and hang out for half an hour. I want to show you something related. what times GMT or BST are good for you?
Re: Future(s) for D.
On 06/23/2015 04:49 AM, Chris wrote: Yeah. A guy I know had a hard time finding a job with Java. HR would always demand experience with this or that build tool and stuff like this. As if you couldn't learn this in a week or less, at least enough to be able to contribute to a project. Actual programming skills never seemed to be really important. Weird. A big part of the problem is that HR folk know precisely jack shit about the fields they're hiring for, and they're never expected to. My favorite word-for-word quote from a real-life headhunter I once met (and never spoke to again): I don't know anything about programming, but I'm good at identifying people who are. That, right there, sums up EVERYTHING.
Re: std.experimental.color, request reviews
On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote: Isn't this what selective imports are for? Not quite the same thing: selective imports control which symbols you pull into the current namespace, but not which code gets pulled into the binary. If you do `import foo : bar;`, the compiler processes all of foo (consider that it has to, just to find the name), generating the object file for it, but only exposes the name `bar` to you. With smaller basic modules, if you only import the foundation, the compiler only has to look at that small file and only has to include its contents in the object file.
[Issue 14727] New: std.json incorrectly supports inf and nan
https://issues.dlang.org/show_bug.cgi?id=14727
Issue ID: 14727
Summary: std.json incorrectly supports inf and nan
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: lumi.pakka...@gmail.com
The JSON specification intentionally leaves out encodings for Infinity and NaN
as these are global variables in javascript that can be replaced with something
malicious.
std.json currently encodes double.infinity as inf and double.nan as nan. These
variables can also be replaced with malicious versions.
The correct encoding for double.infinity, -double.infinity and double.nan is
null.
import std.json;
void main()
{
assert(JSONValue(double.infinity).toString == null);
assert(JSONValue(-double.infinity).toString == null);
assert(JSONValue(double.nan).toString == null);
}
--
Re: D could catch this wave: web assembly
On 06/23/2015 12:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote: This is nonsense. They're just dumping in everything they can think of, that has nothing to do with backwards-compatibility. Web tech is pretty good at backwards-compatibility. Not sure why anyone would argue against that. Relatively speaking, yea, although it's not 100%: There were ways to embed A/V in a page since ages ago, but HTML5 browsers (most notably Chrome, as I recall) eliminated comparability with that when they put in the new and better way to do it. This was some time ago, but I ended up having to resort to Flash just to play an audio file, just because Chome refused to allow the old way, and some of the other browsers at the time (not just IE) didn't support the new way. (Yea, yea, I know, webpages with audio are evil, but this was a decision coming down from higher up for a project that was going to be used in nursing homes.) And of course *that* method of playing audio broke once iOS Safari got big. And then browser add-ons keep getting broken by automatic browser updates. At least on FF, anyway.
Re: Phobos addition formal review: std.experimental.allocator
On 6/23/15 10:16 AM, Dicebot wrote: On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote: On 6/23/15 9:48 AM, extrawurst wrote: I agree with Adam on this: Just a quick concern, I don't think a package.d should ever have anything except imports in it (see http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dlang.org) What is the rationale? -- Andrei My reasoning is simple : when `package.d` only contains public imports it allows to both use simple `import std.allocator` for those who want to get started quickly and pick only necessary imports for those who try optimizing build times / code clarity. Not doing that does not change anything for those who prefer `import std.allocator` but makes fine tuning of imports impossible. Thus former approach looks either equal or superior for all use cases. The import std.allocator is already minimal - only contains the high level stuff. -- Andrei
Re: Phobos addition formal review: std.experimental.allocator
On 6/23/15 10:15 AM, Adam D. Ruppe wrote: On Tuesday, 23 June 2015 at 16:56:55 UTC, Andrei Alexandrescu wrote: But that doesn't apply to packages that do NOT originate as big modules, so they have no backward compatibility issue. My thought isn't really about backward compatibility but about minimizing dependencies with sibling modules. I don't want to repeat my argument too much from the other thread, but imagine you're writing a minimalist library that is meant to interact with other minimalist libraries. To interact, you want a shared interface and basic types. But to be minimalist, you want to pull as little other standard code as possible. The typical user might just import std.whatever and get it all available. But this minimalist user only wants std.whatever.basic_interface. If the basic interface is shoved inside package.d, she can't get get to it without inadvertently pulling in more modules too. This can quickly grow into a web of dependencies where importing just an interface definition ends up grabbing dozens if implementations you don't want too, bloating compile times and binary sizes. The case with std.allocator is not everything is imported in it, so no bloating no nothing. -- Andrei
