Re: DConf Online 2020 Videos Re-edited
properly -> probably
Re: DConf Online 2020 Videos Re-edited
Awesome, properly tedious, work. Thank you
Re: Computing the next SemVer for dlang packages with dsemver
On Wednesday, 21 October 2020 at 17:58:53 UTC, Sönke Ludwig wrote: The thing is just that I don't think it is possible to find a set of rules that always work. There will always be something that should "obviously" be flagged as a breaking change and something that is extremely annoying to be detected as such (forcing a major version increment). True, but if we can get 90% of the way there by a tool we would be a lot better of then where we are today. You should always be able to increment the SemVer by hand. But as some kind of warning/hint and with some kind of integration into the version tagging process (maybe forcing a manual version release on the registry after warnings come up) it could definitely be really nice. I'm thinking of a service that gives you a batch that shows you next SemVer of the master branch, as a start.
Re: Computing the next SemVer for dlang packages with dsemver
On Wednesday, 21 October 2020 at 17:55:00 UTC, Sönke Ludwig wrote: 0.x.y vs. 1+.x.y is about the development process/state. Quite often a design is not yet fully fleshed out in the beginning and there are many incremental changes to the API. If 0.x.y didn't exist, that would simply mean that either the project gets more or less stuck with the initial (bad) design, or that it quickly increments major versions, effectively providing no more stability as in the 0.x.y case. I think that is the one mistake SemVer does. 0.x.y is just one big loophole. After the 1.x.y release an breaking api change requires a major version increment. The way it should be. Stability or unstable is only mentioned in the 0.x.y definitions. You are not stuck on a bad design, break the api, improve the api, increment the major version number. If you break the api in an 0.x.y version the hard part does not change. In both instances the users have to update their usage. In know in theory 0.x.y should be considered unstable. But by amount of 0.x.y we have you pretty much can't get anything done in D if you only use stable packages. The loophole has become the normal case. So what can we do, I see two major options: 1. we can live on the edge and use unstable packages and have no meaning in the SemVer number 2. we can acknowledge that most of them are stable, put a 1. in front and ignore the 0.x.y part of the SemVer definition and have the SemVer mean something dsemver does 2. And true there might be cases where dsemver does not increment the number correctly, but you can always increment by hand. Also if your api is not stable after your 1.x.y release and you break everything in 2.x.y, so what. Your users are also annoyed when you break your api from 0.1.x to 0.1.1. Only difference is they could have seen in coming by looking at the SemVer. I should stop ranting now.
Re: Computing the next SemVer for dlang packages with dsemver
On Wednesday, 21 October 2020 at 15:27:46 UTC, Sönke Ludwig wrote: To really get it correct properly most of dmd is needed anyway. But this might a good first step to get out under the 0.x.x rug we are currently in and a lot closer to actual meaning in the semver of a lib on code.dlang.org
Re: Computing the next SemVer for dlang packages with dsemver
On Wednesday, 21 October 2020 at 15:27:46 UTC, Sönke Ludwig wrote: However, I definitely don't see this as a potential feature of the registry in the sense that it automatically creates new versions for all packages. That is why I said in an ideal world and baby steps. Also, dsemver does not call git yet to create the new tag.
Computing the next SemVer for dlang packages with dsemver
https://code.dlang.org/packages/dsemver is a program that computes the next SemVer for your dlang package. It uses a slightly modified SemVer definition. It does this by using the -X flag for dmd to get a json file of the symbols and then compares them to the most recent git tag that resembles a SemVer. First release is 1.0.0. If a symbol is removed or its signature changed the major version is increment and the minor and the bugfix number reset to 0. If a new symbol is added, the minor number is incremented and the bug fix number is set to 0. If all symbol stay the same the bugfix number is incremented. In an ideal world the dub registry would use this to compute the SemVer for you, but baby steps. I hope to see many bug reports and PRs.
Re: Article about D in the iX magazine
On Friday, 20 December 2019 at 21:26:00 UTC, Andre Pany wrote: In the new iX (1 Januar 2020) there is also a Leserbrief for the article;) Kind regards André I assume you wrote it? As I think the Jan. issue isn't out yet. I hope you are not destroying the article too hard ;-)
reduxed - Redux for D
After working some with Angular and ngrx/store I really came to like the redux pattern. Unfortunately, I couldn't find a package on code.dlang.org that filled that spot when coming back to D. So I build my own. It is called reduxed. If you're interested you can find reduxed here https://code.dlang.org/packages/reduxed and https://github.com/burner/reduxed. It is still rough around the corners and https://issues.dlang.org/show_bug.cgi?id=19084 gives me somewhat of a hard time, but give it try and scream at me because it is not nogc.
Re: Beta 2.078.0
I think https://issues.dlang.org/show_bug.cgi?id=18047 is also fixed in 2.078. It was fixed in https://github.com/dlang/phobos/pull/5911, but it is not shown in the changelog. https://issues.dlang.org/show_bug.cgi?id=17459 was also fixed in the same PR and it is shown in the changelog. Could you investigate this please?
Re: Time to move logger from experimental to std ?
On Wednesday, 29 November 2017 at 21:40:13 UTC, Jonathan M Davis wrote: It was my understanding that there were still problems with its design that Robert wanted to fix, but I don't know where any of that stands. But certainly, I don't think that it makes sense to push forward with trying to get the logger out of experimental without his feedback. That is correct, I had the code nearly ready, but then didn't found time create the PR. Its a api change, but it would make the api safer to log into manually handled memory, and would reduce the gc pressure. I'll try to squeeze my schedule for time to get this going again.
Re: Time to move logger from experimental to std ?
On Wednesday, 29 November 2017 at 21:14:57 UTC, Claude wrote: ... Did I miss anything? to write a bugzilla issue about it
Re: Time to move logger from experimental to std ?
On Wednesday, 29 November 2017 at 19:48:44 UTC, Nathan S. wrote: Considering that one of those issues is that the logger outputs garbage when given a wstring or a dstring, I would not take this as an indication that it's time to "graduate" the logger from experimental. That was fixed at dconf17 and merged a couple of days later.
Re: args.d | a command line argument and config file parser
On Tuesday, 1 August 2017 at 17:46:57 UTC, H. S. Teoh wrote: I think UDA-driven configuration parsing is ultimately the right direction to go. And by that I mean more than just command-line parsing, but the parsing of configuration parameters in general, including command-line options, configuration files, etc.. Usually a lot of boilerplate is involved in constructing a parser, enumerating options, then mapping that to configuration variables, adding helpful descriptions, etc.. All of which are a maintenance burden on the programmer, because any of these components can become out-of-sync with each other: the parsing of parameters, the mapping of these parameters to internal variables, and the help text. args.d uses the same parser for command line options and for the config file. The parser gets adapted between the two with some compile time parameters. With UDAs, it's possible to unify all three in one declaration, thereby ensuring things will never go out-of-sync, and also greatly reduces the amount of boilerplate the programmer has to type. I didn't look too closely at args.d yet, but in my implementation, I have UDAs for specifying alternate names for common configuration parameters (e.g., "outfile=..." instead of "outputFilename=..."). This allows more user-friendly option names, and also decouples it from internal variable naming schemes. I found that good variable names make good command line option names. And you remove one indirection, which I always like. Plus, you can always use short options, which are checked for uniqueness at compile time by args.d. There's also UDAs for optionally flattening a nested struct, so that internally I can have separate structs for configuring each module, but the main program combines all of them into a single flattened struct, so that to the user all the options are top-level (can specify "outfile=..." instead of "backend.outputFilename=..."). The user shouldn't need to know how the program is organized internally, after all, yet I can still properly encapsulate configuration parameters relevant to only that module, thereby avoiding spaghetti dependencies of modules on a single global configuration struct. I thought about that as well, but didn't do it because if found: --mysql.ipAddress Type: string default: localhost Help: --redis.ipAddress Type: string default: localhost Help: looks and works just awesome. At least better than --mysqlipAddress and --redisipAddress.
args.d | a command line argument and config file parser
args.d is a command line argument and config file parser.
The basic idea of args.d is that that command line options and
config file options are basically the same or should be.
The configuration options are build from UDA annotated structs
that can be nested.
The package can be used with dub "argsd": "~>0.2.0"
http://code.dlang.org/packages/argsd
Less talking more example:
```D
import args;
/** args.d arguments are structures as shown below.
Each argument that should be searched for needs to have $(D
@Arg())
attached to it.
$(D @Arg()) takes three kinds of parameter.
1. A $(D string) which is used as the help message for that
argument.
2. A $(D char) which is used as the character for the short
argument
selector.
3. A $(D Optional) value to make the argument as optional or not
(default
Optional.yes).
The order of the three parameter is not relevant.
Arguments can be nested, see the nested $(D NestedArgument) $(D
struct) in
$(D MyAppArguments).
Arguments can be of all primitive types, arrays of primitive
types and $(D
enum)s.
All arguments take the shape "name value". Equal sign syntax is
not
supported.
Array values can be given as separate values of as comma
separated values.
The name of the argument will be derived from the name of the
member in
the struct. The names are case sensitive.
Arguments in nested structs have the name of the struct prefixed
(compare
"--nested.someFloatValue).
Short names must be unique. If they are not unique an Exception
will be
thrown. Short names are used by prefixing the character with a
single "-".
The short name "-h" is reserved for requestion the help page.
Long names are unique by definition. Long names are prefixed with
"--".
The long name "--help" is reserved for requestion the help page.
If $(D parseArgsWithConfigFile) is used two more long names are
reserved,
"--config", and "--genConfig". Both take a $(D string) as
argument.
"--config filename" will try to parse the file with name $(I
filename) and
assign the values in that file to the argument struct passed.
"--genConfig filename" can be used to create a config file with
the default values of the argument struct. The name of the config
file is
again $(I filename).
*/
/** A enum used inside of NestedArguments */
enum NestedEnumArgument {
one,
two,
many
}
/** A struct nested in MyAppArguments */
static struct NestedArguments {
@Arg("Important Help Message") float someFloatValue;
// D allows to assign default values to the arguments
@Arg('z') NestedEnumArgument enumArg = NestedEnumArgument.two;
@Arg() bool someBool;
}
/** The options to the created program. */
static struct MyAppArguments {
@Arg(Optional.no) string inputFilename;
@Arg('b') int[] testValues;
/** All options inside of $(D nested) need to be prefixed with
"nested.".
*/
@Arg() NestedArguments nested;
}
import std.algorithm.comparison : equal;
import std.format : format;
import std.math : approxEqual;
/** It is good practice to have the arguments write-protected by
default.
The following three declarations show a possible implementation.
In order to look up a argument the developer would use the $(D
config())
function, returning him a write-protected version of the
arguments.
In order to populate the arguments the writable version returned
from
$(D configWriteable) is passed to $(D parseArgsWithConfigFile).
This, and the option definitions is usually placed in a separate
file and
the visibility of $(D MyAppArguments arguments) is set to $(D
private).
*/
MyAppArguments arguments;
ref MyAppArguments configWriteable() {
return arguments;
}
ref const(MyAppArguments) config() {
return arguments;
}
/** This $(D string[]) serves as an example of what would be
passed to the
$(D main) function from the command line.
*/
string[] args = ["./executablename",
"--nested.someBool",
"--nested.someFloatValue", "12.34",
"--testValues", "10",
"-b", "11,12",
"--nested.enumArg", "many",
"--inputFilename", "nice.d"];
/** Populates the argument struct returned from configWriteable
with the
values passed in $(D args).
$(D true) is returned if the help page is requested with either
"-h" or
"--help".
$(D parseArgsWithConfigFile), and $(D parseArgs) will remove all
used
strings from $(D args).
After the unused strings and the application name are left in $(D
args).
Replacing $(D parseArgsWithConfigFile) with $(D parseArgs) will
disable
the config file parsing option.
*/
bool helpWanted = parseArgsWithConfigFile(configWriteable(),
args);
if(helpWanted) {
/** If the help page is wanted by the user the $(D printArgsHelp)
function can be used to print help page.
*/
printArgsHelp(config(), "A text explaining the program");
}
/** Here it is tested if the parsing of $(D args) was successful.
*/
Re: Benchmark
On Friday, 2 June 2017 at 18:51:24 UTC, Andrei Alexandrescu wrote: That's indeed worth it. Robert, we discussed first deploying the library and a driver for dmd/druntime/phobos on dub, is this your plan? Thanks! -- Andrei I think a practical approach is to create another dub project that solely consists of benchmarks for functions of phobos, and prints pretty pictures of their performance. This will properly help to find shortcomings of the benchmark library, and help to develop idioms for benchmarking and random testing. If that works out, the next step is properly to integrate that in the phobos/druntime/dmd CI. Which properly means putting the benchmark library through the experimental integration process, and finding a place for the benchmarks to life.
Re: Benchmark
On Friday, 2 June 2017 at 18:49:49 UTC, Jack Stouffer wrote: And reject out of hand any PR which reduces performance in order to "ratchet" performance over time. I would also do this to a lesser degree to DMD as well. I think being binary about it is the wrong approach. Lets say we fix a bug, and the function is slower afterwards. Do we merge the bugfix? I say yes. Lets say we add a feature to a function that makes more useful. Do we merge it? I say yes. This is just another hammer, it does not mean everything is a nail now.
Re: Benchmark
On Thursday, 1 June 2017 at 21:08:43 UTC, Robert burner Schadek wrote: they do not cover performance regressions. That is bad, we are basically, currently just hoping that performance diminishes. diminishes -> does not diminishes
Benchmark
At this years DConf I gave a very short overview of the benchmarking library I'm working on [1]. The source can be found here [2] The general idea goes as following. Unit tests in D help us to find bugs and avoid regressions, but they do not cover performance regressions. That is bad, we are basically, currently just hoping that performance diminishes. So my idea is to eventually get this library into phobos, write benchmarks for all functions in phobos, execute the benchmarks for every merge into master, use gnuplot to display the results on the dlang webpage, profit. Right now I need people to give feedback on the library. You can find it on code.dlang.org [3] [1] https://www.youtube.com/watch?v=QELK73JSpFk=PL3jwVPmk_PRxo23yyoc0Ip_cP3-rCm7eB=30 [2] https://github.com/burner/benchmark [3] http://code.dlang.org/packages/std_benchmark
Re: Voting for std.experimental.checkedint
checkedint got voted in. With 2 Yes and 2 yes with remarks. I will set the autotester to merge. Thank you @andralex for the hard work.
Re: auto ref escaping local variable
Nice idea, but didn't work either. Just got more errors. And my eyes hurt now.
auto ref escaping local variable
I have this program that used to compile with 72 but with 73 dmd
is complaining that
"Error: escaping reference to local variable t"
auto ref f2(T)(auto ref T t, auto ref T s) {
return t;
}
auto ref f1(T)(auto ref T t, auto ref T s) {
return f2(t, s);
}
unittest {
int a = f1(1,2);
}
I'm not sure why, or how to fix that.
https://issues.dlang.org/show_bug.cgi?id=17117
Re: Voting for std.experimental.checkedint
On Friday, 13 January 2017 at 12:49:53 UTC, deadalnix wrote: Is the doc available somewhere in a readable form ? CyberShadow/DAutoTest build the docs, you can find the link at the end of the PR under checks
Voting for std.experimental.checkedint
http://forum.dlang.org/post/wgsguzbgrcejptuxf...@forum.dlang.org
Voting for std.experimental.checkedint
This is the voting thread to decide if the proposed addition to Phobos, std.experimental.checkedint, should be accepted. To vote, please respond to this post. You have three options: * Yes * Yes with a single condition * No If you vote "yes" you can still mention something you'd like improved, but please be explicit if that problem is a non starter for you and you are choosing option two. If you vote no, please state why, though you aren't required to. Some things to consider when making a vote: * Is this functionality needed in Phobos? * The API is practically permanent once the module is accepted. Some minor changes can be made, but a full redesign is no longer an option. The voting will end 2017-01-31 The PR can be found here: https://github.com/dlang/phobos/pull/4613 The dub package can be found here: http://code.dlang.org/packages/checkedint_andralex The review thread can be found here: http://forum.dlang.org/post/mnounbaobgphbmanf...@forum.dlang.org
Re: std.experimental.checkedint Formal Review
The review is over, there has been one comment on github "build error with DAutoTest:". It has been fixed. If there are no comments until 2017-01-12 and Andrei agrees I will put checkedint to a vote.
Re: Question on std.experimental
On Thursday, 5 January 2017 at 02:57:40 UTC, Jack Stouffer wrote: You were the one who told me about it: https://github.com/dlang/phobos/pull/1500#issuecomment-155457980 I totally forgot about that, I guess I need to start to write things down. Sorry for the noise.
Re: Question on std.experimental
On Wednesday, 4 January 2017 at 19:33:13 UTC, Jack Stouffer wrote: Promotion of std.logger has been officially stalled until reference counted strings are part of D. When? That is the first I hear about that.
Re: std.experimental.logger + threadIds
The ugly way is to create a @trusted function/lambda that coverts the threadId to a string. Not sure about the pretty way.
Re: std.experimental.checkedint Formal Review
**2017-01-05 (AoE)** of course
std.experimental.checkedint Formal Review
http://forum.dlang.org/post/mnounbaobgphbmanf...@forum.dlang.org
std.experimental.checkedint Formal Review
It is time to formally review Andrei's checkedint. Checkedint is a wrapper for integer types that allows to run code on over/underflows, define NaN like init states and more. The PR can be found here: https://github.com/dlang/phobos/pull/4613 The dub package can be found here: (1) http://code.dlang.org/packages/checkedint_andralex The docs can be seen through CyberShadow/DAutoTest in the PR. Due to the holidays the review period is extended to **2016-01-05 (AoE)** Please browse through the comments of the PR to keep this discussion DRY. Style nitpicks should be made on github. The discussion in this thread should be about the design and phobos inclusion worthiness (PIW) of the module, not about where to place braces. (1) Andrei, please make sure they are in sync.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On 2016-12-14 14:26, Dominikus Dittes Scherkl via Digitalmars-d wrote:
> On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>
> Why not leave it as it is and only change the compiler to
> perform inputs _within_ a function before evaluating the declaration,
> so that the symbols imported can be used in the declaration?
>
> e.g.
>
> fun(Range x) if(isInputRange!x)
> {
>import std.range;
>auto a = x.front();
> }
>
> this is especially more clean if a function needs several imports and
> maybe some of them in the declaration but not all of them. This would
> otherwise split the imports to two different points, some within the
> (already much too long) declaration and some within the function. I
> consider this ugly.
I like that, +1
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
I really like that solution. +1
Re: Code example in std.parallelism fails to compile
Not that I know of, https://github.com/dlang/phobos/pull/4399. I think std.parallelism was designed around a D feature that was more a bug than a feature. This bug/feature seamed to be fixed some years ago. But I'm not 100%, as this was before my time.
Re: readln and readf issues
On Friday, 11 November 2016 at 09:43:51 UTC, Jacob Marek wrote:
Hi! so I'm probably being dumb here however I'm having an issue
getting readf and readln to work properly. It seems to be
superseding the rest of my code. Allow me to explain. No matter
where I put the readf/readln function it will get hung up in
the console waiting for input. An example is below where this
occurs (only after inputting an int and pressing enter does
hello print) I am using eclipse with the standard DMD compiler.
Any help is appreciated!
void main() {
writeln("hello");
int q;
readf(" %s", );
}
What platform? I'm not 100%, but on *nix writeln goes to stdout
of the process and read* reads from stdin of the same process.
The problem is that stdout is not connected stdin of the same
process. In other words readf never gets past the "hello". Create
two programs and connect them as such "writeProgram |
readProgram".
p.s. next time, please post such to the learn subforum, thats
properly a better place for this.
Re: PDF generation in D?
I used text files and LaTeX in the past, it works with everything textfile -> process -> LaTeX -> pdf
Re: Trailing catch on function?
On Tuesday, 8 November 2016 at 01:50:26 UTC, Walter Bright wrote:
You don't. The exception is also rethrown, so it isn't an exact
replacement. (The 'nothrow' is a mistake on my part.)
this:
scope(failure, Exception e) {
// Do something with e
}
would be nice
Re: Trailing catch on function?
On Tuesday, 8 November 2016 at 00:12:09 UTC, Robert burner Schadek wrote: Who to get the Exception thrown in the scope(failure) Who to --> How do you ...
Re: Trailing catch on function?
On Monday, 7 November 2016 at 23:37:18 UTC, Walter Bright wrote:
void callback() nothrow
{
scope (failure)
{
...log error or abort...
}
...lots of code...
}
Who to get the Exception thrown in the scope(failure)
Re: DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.
the backend/view for it: https://github.com/kamon-io/docker-grafana-graphite
Re: DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.
On Tuesday, 11 October 2016 at 12:47:55 UTC, Atila Neves wrote: I didn't even know that this existed, and I have a feeling that soon I'll wonder how I lived without it. Awesome! I had the exact same feeling
DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.
http://code.dlang.org/packages/dstatsd
StatsD allows to collect statistics about any application by
using counters, gauges and more through UDP.
Usage:
auto s = new StatsD("127.0.0.1", 1234, ""); // connect to statsd
server
s(Counter("Foo")); // increment counter "Foo"
s.inc("Bar"); // increment counter "Foo"
s(Counter("Args"), // send stats to Args, H, and timeA
Counter("H", someIntValue), // in one UDP message
Timer("timeA", someTimeInMS)
);
{
auto a = ScopeTimer("args", s); // automatic time collection
}
Falcor Router in D
Is anybody working on a falcor-router [1] written in D? [1] https://github.com/Netflix/falcor
Re: checkedint submission
Who is your review manager?
Re: checkedint submission
The last commit to https://github.com/andralex/checkedint was 21 days ago? Something is off! Or was the last change to checkedint 21 days ago?
Re: New reviewing flow on github
They also have kanban style project management stuff now. I would really like to see anything (bugzilla, trello) moved to github.
Re: checkedint submission
could you please update the dub package
Re: The D Language Foundation is now a tax exempt non-profit organization
Awesome Job
Re: Do you like bounded integrals?
what about two types. alias BI = Bound!int; alias CBI = CheckedInt!BI; if Bound behaves as an integer people can choose.
Re: dub test
Lets move that back to https://github.com/dlang/phobos/pull/2995
Re: On the future of DIP1000
On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote: It would be nice to have the whole picture now, before implementing DIP1000. Then it's possible to review them together, making sure the end goal is actual possible to achieve. Now we just have to trust Andrei and Walter that all features will come together making the end goal possible. We've already seen in the past that some features don't play well together. It's also not possible/harder to come up with alternatives, that might work better, if we don't have the whole picture. I'm also not a big fan that the DIP is approved right from the start. Then it's not a DIP, it's more of a FYI. It makes the whole process kind of pointless since Andrei and Walter can choose to ignore the feedback. What he said !
Re: std.experimental.logger threading design
On Wednesday, 17 August 2016 at 07:48:02 UTC, kookman wrote: I was interested low(er) cost logging and stumbled across a proposal by Max Klimov from about 16 months ago to add an AsyncLogger to std.experimental.logger (ref http://forum.dlang.org/thread/lcsjtxorbbagmbvbl...@forum.dlang.org). The resulting PR 3194 has been dormant for some time. I was going to resuscitate it, but I wanted to change the approach - rather than make AsyncLogger a generic wrapper for another logger type, I wanted to make a specialist logger that was designed to always be the stdThreadLocalLogger. It would be a stub that merely sends a LogEntry (as a message) to the stdSharedLogger (which would be any logger type). When taking a closer look at std.experimental.logger I realized that with the current design, becauseThreadLocalLog is just another Logger, it is paying all the cost of sychronization, even though it is thread local. Am I interpreting the purpose of stdThreadLocalLogger differently to how it was intended? stdThreadLocalLog's log functions are synchronized because they read global and instance global data structures. And I didn't want make in possible to introduce the possibilities for race conditions. Thats why the logXXX member functions of Logger are synchronized. You can still build up a LogEntry and send it, it just has to be in synchronized block.
Re: DIP1000: Scoped Pointers (Discussion)
public final void foo() scope inout @nogc nothrow @safe pure {}
I think the solution is to turn every function into a no-args
template, but then you can't use virtual methods.
** sarcasm on **
Don't say that, you give them ideas ;-)
** sarcasm off **
Re: DIP1000: Scoped Pointers (Discussion)
On Friday, 12 August 2016 at 14:02:50 UTC, Chris Wright wrote:
In the worst case, you can change the API so you can write:
rcs.update("bar", (x) { x.a = 1337; x.b = 1338; });
yes, but that will not catch on. And I think (x) must be (scope
ref x)
Re: DIP1000: Scoped Pointers (Discussion)
No, the DIP doesn't handle several levels of indirection.
What about:
struct Bar { int a; int b }
auto rcs = RefCountedTree!(string,Bar)();
fcs["bar"].a = 1337; // log n
fcs["bar"].b = 1338; // log n
? I need to pay log n twice to assign two members
Re: DIP1000: Scoped Pointers (Discussion)
On Thursday, 11 August 2016 at 22:00:06 UTC, Walter Bright wrote:
On 8/11/2016 4:46 AM, Robert burner Schadek wrote:
Can I do this:
```
struct Foo { int a; }
auto rcs = RefCountedSlice!Foo(); // assume rcs.length > 0
scope Foo zero = rcs[0];
zero.a = 1337;
assert(rcs[0].a == 1337);
```
No, because the lifetime of zero exceeds the lifetime of rcs[0].
Hm, that is really bad IMO. The shown use case is properly the
most common use case. Is there no way to make it transitive so
the lifetime of rcs[0] is the lifetime of rcs.
To be blunt, this is a real show-stopper for me.
Re: DIP1000: Scoped Pointers (Discussion)
Can I do this:
```
struct Foo { int a; }
auto rcs = RefCountedSlice!Foo(); // assume rcs.length > 0
scope Foo zero = rcs[0];
zero.a = 1337;
assert(rcs[0].a == 1337);
```
with the DIP. I could find it.
Re: DIP1000: Scoped Pointers (Discussion)
Ok, I disagree, but there is no way that I can proof to be right. You can also not proof that you're right, so I'll trust your judgement.
Re: DIP1000: Scoped Pointers (Discussion)
On Thursday, 11 August 2016 at 09:45:07 UTC, Martin Nowak wrote: It's already clear that we need much better escape analysis and guards for safe reference counting. There isn't any open question that this is the necessary enabler for more RC and less GC. How do you know? Is there a sketch for the planed RC implementation (where can I read it?)
Re: DIP1000: Scoped Pointers (Discussion)
```
void foo() {
int c;
int* e;
e = // Error, lifetime(e's view) is and is
greater than lifetime(c)
}
```
The DIP should make clear that this is wanted for a container
library.
Additionally, I miss how this DIP fits in the overall plan of
getting rid of the GC. As long as there isn't a written
masterplan how to combine those ideas I consider this DIP to be
incomplete.
I think this change is not worth it. I believe there is an
inherent trade-off for every programming language between
usability and theoretically correctness. And IMO this DIP is
pushing D way to far in the direction of theoretically
correctness. There are far more important things for the adoption
of D, like making the frontend a library, shipping with multiple
backends.
Re: std.experimental.xml available on DUB
On Wednesday, 3 August 2016 at 09:04:30 UTC, Jacob Carlborg wrote: Another question. I see that there are a couple of different lexers available. Can those be exposed with the same interface/type instead of using different types? Perhaps based on the input type. Well, currently you have to make that choice as developer, and there is always the BufferedLexer which should be good choice is most cases. Polymorphic design was not a goal of the project, so I think it is going to be hard to add that without sacrificing to much.
Re: Battle-plan for CTFE
On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote: please share your thoughts. When is this moving into dmd master?
Re: Overflows in Phobos
A perfect example for an item for your action list.
Re: Our docs should be more beautiful
** RANT ON ** A perfect example for an item for your action list. And it pretty much looks like the syntax the wiki is using already. I bet you a drink at next years DConf that it will take you at least 10 minutes to find and reread this thread next time you create a vision document just to rewrite parts of it for you next vision document. ** RANT OFF **
Re: Vision document for H2 2016
On Friday, 8 July 2016 at 18:04:16 UTC, Andrei Alexandrescu wrote: It seems to me six months is a sweet spot. Large companies such as Google and Facebook also use a six-months horizon because it's long enough to avoid micromanagement hysteria and short enough to be verifiable and accountable. Yes, I do have a vision for a longer horizon, but it's too vague to be useful - "D will be a major programming language by 2020". But we are not Facebook or Google. And I bet even they have some mid/long-term visions. I consider it competition with other things that Walter and I need to worry about. Walter put it cleverly: you can't add more administration without administrators. IMO that is wrong, well not so much wrong as misleading. We don't just need more administration because we need more administration. We need more administration or lets say more management and delegation to get things done. A semestrial vision document summarizing our outlook and intentions is about as much as we can bear. Well, you and Walter graduated from engineering to management. That, reviewing other peoples work and delegating is your job now. Like it or not. Would trello help with that kind of stuff? Yes if anybody had access to the trello and would want to use yet another tool. I think that is unrealistic. But we already have the wiki and github. So extending the VD to rolling VD in the wiki is the way to go IMO. Or move everything to github including bugtracker and start using milestones etc. Again, IMO in the long run a long term VD, updated on a need to basis with subtasks will save you work. I don't think preapproved work would lead to less rejection. Rejection is of work of insufficient quality, not of work that has not been preapproved. Conversely, preapproval does not guarantee any work will be actually approaved. Considering the current event is disagree. Maybe preapproved work is not the right wording. Maybe preapproved designs.
Re: Vision document for H2 2016
On Thursday, 7 July 2016 at 20:44:05 UTC, Andrei Alexandrescu wrote: On 7/7/16 3:55 PM, Andrei Alexandrescu wrote: https://wiki.dlang.org/Vision/2016H2 -- Andrei In the next pass I will integrate Walter_Andrei_Action_List I'm quite underwhelmed by the Vision Document (VD). I think that is because it is a biyearly VD, and IMO in half a year nothing really visionary can be done for D (because D is already pretty awesome and pushing the envelope takes a lot of time). Also I think, that you treat the Action_List as competition to the VD. If you don't, even better but consider this: You create a VD roughly twice a year. You have to compare it with the last VD and see what was done. That is a lot of overhead IMO. Why not create "THE VISION DOCUMENT" and update it when needed. You would be able to add long term visions like "Awesome Container Library using Allocators", then add subpoints to it like "Create Allocator library" (strikethrough because it is already done). We could then link the relevant forum threads to the points and subpoints, discussing the work item. People would have a go to place looking for pre-approved work. Leading to no more gatekeeper rejection frustration. Additionally, I think that the vision for phobos is really weak, no mentions of containers, xml, (si)-units, unit-testing (framework), benchmarking, blas, json ... . I'm not the much in the DMD process, but what about making the frontend a library and being able to select the backend at the time of compilation, as shortly mentioned at DConf. I bet there are a lot of subpoints to that as well.
Re: Logical location of template instantiations
IMO, this is one of these places where theory meets practice. Do what works, write a comment explaining the problem, and move on ;-)
Re: Call to Action: making Phobos @safe
On Monday, 27 June 2016 at 19:33:45 UTC, Walter Bright wrote: Sorry to have offended you, I worded things badly. Thank you for making the list. It's just that I'm feeling a bit overwhelmed at the moment with trying to get things done and being asked to do more every day, and I'd like to delegate. Don't sweat it. I just replied in the heat of the moment and thereby violated my personal 24 hour no reply rule. Back to topic, I think this list will save you and Andrei work in the long run. I mean if the list is up to date, you do not have to repeat yourself. Well expect "read the list!" ;-)
Re: Release D 2.071.1
Awesome, releases are becoming more and more boring. I like it!
Re: Call to Action: making Phobos @safe
On Sunday, 26 June 2016 at 22:38:54 UTC, Walter Bright wrote: It's a wiki, feel free to add it. I have to say that reply really makes me angry. I created that list so Andrei and you have an easy to find spot where you can write down tasks so people can work on them. You did not disagree with the list at the time, and didn't disagree so far. I really think it is clear that these are two list that you two are maintaining, how else should anybody know what work is pre-approved and where D is going. I think I'm not asking too much here, if I ask you to decide if you want to maintain that list or if you want to delete it. The current limbo state is just making things worse.
Re: DbI checked integral
On Sunday, 26 June 2016 at 16:03:57 UTC, Andrei Alexandrescu wrote: like. Default to NaN or throwing Exceptions. That is a side discussion as trivial as deciding the defaul second argument for Checked(T, Hook = DefaultHook). Fair enough. I was looking into creating a NaN Hook. I could create it by doing some ugly stuff inside the Hook. Things would have been nicer if there is a ctor hook. p.s. a dub package would be nice
Re: Call to Action: making Phobos @safe
It would be awesome if you would create that process model in the wiki and at it to your action list http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List So it does not get lost and people can find it.
Re: DbI checked integral
On Saturday, 25 June 2016 at 21:32:00 UTC, Andrei Alexandrescu wrote: So it stands to reason that if you want to design a checked integral types offering a variety of checking policies, one point in the design space that needs to be attainable is "no checks at all". Then the syntactic shell works the same as with any policy, and ideally there's no overhead at all. There should be away to avoid all checks, true. But I think that problem is solved by alias Int = * . I think we have to take a step back and discuss what this type should actually be used for. IMO it is a debug type and as such should have sensible default debug features like. Default to NaN or throwing Exceptions. One good design principle is pushing policy up and implementation down. A NaN is a very specific policy, which is appropriate for a Hook definition but would look out of place in the Checked shell. See my above argument. If it is a debug type, and that is what I think it is, it should have sensible default hooks.
Re: DbI checked integral
On Friday, 24 June 2016 at 21:31:14 UTC, Andrei Alexandrescu wrote: By default, if Hook has no state and implements none of these methods, e.g. is void, then Checked!(int, void) is a user-defined type that mimics the behavior of int to the maximum extent possible. I think there is a major problem with the proposed design. when Checked!(int, void) is to behave as an int, why do we need it in the first place. I mean we have int as a basic type. Can't we do: alias Int = int; alias Int = Checked!(int, SomeUsefulHook); On second thought, the only feature of Checked!(int, void) is to be a slower int ;-) IMO the default CheckedInt!(int, void) needs a NaN like init/failure state. After any operation that overflows the value should be NaN.
Re: std.experimental.randomized_unittest_benchmark is ready for comments
On Sunday, 19 June 2016 at 18:51:09 UTC, Jack Stouffer wrote: I would like to try this out on my date parsing library, but I don't see a way to generate strings of a specific format. take a look at https://github.com/dlang/phobos/pull/2995/files#diff-1a5f159e09980950bb9931ac674cbf40R358 just create a new Gen struct that generates what you want and make it a parameter to a function. And you should be done.
Re: std.experimental.randomized_unittest_benchmark is ready for comments
Thank you Seb for taking over the review management. Some additional feature for the proposed module is. * Simple way to create test data for user defined types * Benchmark data is stored into csv file for comparing the benchmark results between runs * Standalone tool to create gnuplot graphs from generated csv benchmark files The long time vision (2+ years) is to have a benchmark for every function in phobos and have the resulting graph on the Dlang webpage (merged PRs -> webpage). So we can track the performance of everything.
Re: std.experimental.checkedint is ready for comments!
I created this: https://wiki.dlang.org/Walter_Andrei_Action_List And PR's to dmd, druntime, and phobos' README.md that points to it. If you could keep that list up to date, would be really hopeful IMO. https://github.com/dlang/druntime/pull/1597 https://github.com/dlang/dmd/pull/5874 https://github.com/dlang/phobos/pull/4435 What do you want to work on? * I'm working on mentoring the GSoC xml replacement (https://github.com/lodo1995/experimental.xml) it is looking really good btw. * I have https://github.com/dlang/phobos/pull/2995 in the pipeline which I think will help us to spot performance regeression in phobos and in any other D code for that matter * I'm also working on getting that PR into unit-threaded as I fear the PR will sit in the queue for some time to come. * recently I worked on std.parallelism and tried to get all tests run by default. https://github.com/dlang/phobos/pull/4399 No fun! std.parallelism or at least way the author indented its use, as shown in the unittests, is just broken. * Then I'm working on my DConf project. * And I'm reviewing phobos PR's
Re: std.experimental.checkedint is ready for comments!
Ok, where is this list? And where is list for phobos? Sure, some people are a allowed to pull stuff into phobos. But only stuff that does not introduce new names and Andrei does not veto. Of course you can not appoint people, but you should have an idea who you think is sharing your overall vision of D. And then you can ask them. Delegating work is nice, but I would like you to delegate power.
Re: std.experimental.checkedint is ready for comments!
What you said is true, but IMO you're missing the point. IMO the current D Process is just backward. Having people working on stuff openly, with intend for phobos inclusion, for a lot of months and that putting it up for review clearly does not work. And if you and/or Andrei at that point say "Na". That is just frustrating, no matter how good the reasons are. So I propose that you and Andrei create a list of high level goals for the compiler as well as for phobos/druntime. Nothing abstract, specific stuff properly also design specifics. And attach explanations why those things should be done. For example: Stuff that needs to be in phobos: * sync/async Database abstraction that is nogc * Value Range Integer type * I think you get the idea about the list. Than you write in big letters. "To everybody that wants to contribute a modules to phobos look at the above list and pick you module. All other module ideas may be rejected for whatever reason by Andrei. If you have an idea for a module not on the list get the design approved by Andrei before you start coding to avoid frustration later." I know, this is an open source project and you can't tell people what to do because you don't pay us any money. But you could tell us what you think is important to make D number one. At least then people know what the lay of the land is and don't have to guess. And by saying "yes" or "no" at the end of the development of new stuff, you're actually doing this already. Only at the wrong point in time, IMO. Additionally, IMO at some point you two have to delegate/trust other people/lieutenants. You two simply don't have the time to do all the necessary reviewing to make the D Process scale. And you two make mistakes as well. core.checkedint and etc.c.odbc is just deadbeef. (Please nobody start a discussion about that here. Even if those two module are a success, last time I checked Walter and Andrei are human so they make mistakes. And Andrei actually said so at DConf as well.) So an action list from my POV. * Andrei, Walter create a specific task list and designs * make this list obvious to find. github README (See comment above) * disable the auto quote feature of the forum. This feature is just poisonous for the discussion culture of this forum. Everybody is just trying to disprove the other without actually trying to bring the discussion/D forward. * something like https://github.com/facebook/mention-bot would be nice. It will properly also help finding lieutenants. rant off p.s. Warning: Parent post is not quoted. Ignore Explain Fit it for me I f** hate it.
Re: std.experimental.checkedint is ready for comments!
In two weeks I will talk to tsbockmann how much time he needs to work in all comments. After he is done I will start the formal review phase. p.s. @everybody please take an interest. This module can give D another strategic advantage over our competition.
std.experimental.checkedint is ready for comments!
http://forum.dlang.org/post/jxaisipbdqfifpncn...@forum.dlang.org
std.experimental.checkedint is ready for comments!
As with many other languages (C, C++, Java, etc.), D's built-in integer data types are quite difficult to use correctly. It is tempting to think of int, for example, as if it were an actual mathematical integer. Doing so, however leads to buggy code due to unintuitive behaviour like: * Wrapped overflow * Reinterpretation of signed values as unsigned in mixed expressions * Floating Point Exceptions which aren't Exceptions and have nothing to do with floating point * Formally "undefined behaviour" with some inputs for various operations This checkedint module provides alternative operations and types (SafeInt,SmartInt) that protect the user from most difficulties of this sort, while maintaining good performance (provided that inlining and optimizations are enabled). == SmartInt == SmartInt smartOp strive to actually give the mathematically correct answer whenever possible, rather than just signaling an error. == SafeInt == SafeInt safeOp strive to match the behaviour of the basic integral types exactly, $(B except) that where the behaviour of the basic type is wrong, or very unintuitive, an error is signaled instead. The main downsides to using checkedint are: Some added friction when interfacing to non-checkedint-aware code. Slower compilation and larger binaries. PR: https://github.com/dlang/phobos/pull/4407 DUB: http://code.dlang.org/packages/checkedint I will do the review management.
Re: A technique to mock "static interfaces" (e.g. isInputRange)
On Thursday, 26 May 2016 at 09:42:59 UTC, Atila Neves wrote: Internal, and not really a mock. I used a range as an example - anything with an accompanying interface would be supported. I see, I thought as much What's wrong with dmocks revived (I've never used it)? I'm not afraid of classes, I was just trying to extend mocking to static interfaces since there's so much emphasis on them in D. Regular mocking is boring and easily doable :P I was not clear. I mean, D has a community has to get past its GC Angst.
Re: A technique to mock "static interfaces" (e.g. isInputRange)
+1 having a look at AutoImplement For testing ranges, I usually use https://github.com/dlang/phobos/blob/master/std/internal/test/dummyrange.d even though its internal ;-) anyway, more and better testing always good. p.s. I think at some point we have to build some (the perfect) mocking framework with dependency injection and all the other awesome stuff. But before that can happen we have to lose the fear of classes and OO. Please no OT!
Re: How are you enjoying DConf? And where to go next?
what about Singapore. * pretty easy to travel to from all over the world * english speaking
Re: Battle-plan for CTFE
awesome news :-) thanks you
Re: Always false float comparisons
On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote: So, should the compiler emit a warning for the former case? I'm not for a compiler change. IMO a library called std.sanity_float with a equal and a notequal function would be better.
Re: The end of curl (in phobos)
On Friday, 6 May 2016 at 09:00:24 UTC, Dicebot wrote: Deprecated modules don't get bugfixes. It is quite important to put it into undead the same moment it gets deprecated because there is no real replacement available so existing projects must have a clean migration path to keep working. sounds fair enough so the changed schedule is 1. undocument everything curl related in may 2016 2. deprecate everything curl related in may 2017 2.1 move curl stuff to undead 2.2 no more bugfixes for curl stuff 3. delete everything curl related in phobos in may 2018
Re: The end of curl (in phobos)
On Friday, 6 May 2016 at 08:43:09 UTC, Johannes Pfau wrote: Wouldn't it make sense to do 3.1 right now so people can switch earlier? Then every bugfix to curl needs to be put in two repos. And the idea is that people have two years to find a better solution. So hopefully when we put curl in undead in 2018 nobody is using it anymore.
The end of curl (in phobos)
As discussed yesterday at DConf, curl in phobos must go. The plan is as follows. 1. undocument everything curl related in may 2016 2. deprecate everything curl related in may 2017 3. delete everything curl related in may 2018 3.1 move curl stuff to undead PR: https://github.com/dlang/phobos/pull/4283
Re: Proposed: start DConf days one hour later
On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei +1 so the breakfast is from 9:30 to 10:00 at the location?
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 15 March 2016 at 09:08:11 UTC, Nordlöw wrote: On Monday, 14 March 2016 at 19:08:18 UTC, Robert burner Schadek wrote: have a look at this! https://github.com/biozic/quantities Could you briefly outline why you prefer this over David's work? - has been in code.dlang.org since 2014 - maintained - good CT string parsing abilities - ... have a look at the github page! its inclusion has been discussed before (did go nowhere because author was busy, issue is still assigned to his github project)
Re: RFC: Units of measurement for D (Phobos?)
have a look at this! https://github.com/biozic/quantities
Re: unit-threaded v0.6.5 - Type-parametrized tests
On Friday, 11 March 2016 at 14:26:34 UTC, Atila Neves wrote: Didn't Robert have a QuickCheck-alike as well? Yes, https://github.com/D-Programming-Language/phobos/pull/2995
Re: My whereabouts
On Wednesday, 9 March 2016 at 12:58:24 UTC, Andrei Alexandrescu wrote: Next on my coding agenda is rcstring. I thought you were working on the container, or has [1] established itself as pseudo standard. About rcstring, I have [2] which works for what I need for. I plan to extend it some more to make it more mutable (CoW). [1] https://github.com/economicmodeling/containers [2] https://github.com/burner/std.rcstring
Re: std.xml2 (collecting features)
On Saturday, 5 March 2016 at 15:20:12 UTC, Craig Dillabaugh wrote: Robert, we have had some student interest in GSOC for XML. Would you be interested in mentoring a student to work with you on this. Craig Of course
Re: std.xml2 (collecting features)
On Thursday, 18 February 2016 at 15:39:01 UTC, Robert burner Schadek wrote: On Thursday, 18 February 2016 at 12:30:29 UTC, Andrei Alexandrescu wrote: Would the measuring be possible with 2995 as a dub package? -- Andrei yes, after have synced the dub package to the PR brought the dub package up to date with the PR (v0.0.6)
Re: std.xml2 (collecting features) control character
On Friday, 19 February 2016 at 12:55:52 UTC, Kagamin wrote: http://dpaste.dzfl.pl/2f8a8ff10bde like this? yes
Re: std.xml2 (collecting features) control character
On 2016-02-19 11:58, Kagamin via Digitalmars-d wrote: > On Thursday, 18 February 2016 at 16:56:08 UTC, Robert burner Schadek > wrote: >> the hex dump is "3C 66 6F 6F 3E C2 80 3C 2F 66 6F 6F 3E" > > http://dpaste.dzfl.pl/80888ed31958 like this? No, The program just takes the hex dump as string. you would need to do something like: ubyte[] arr = cast(ubyte[])[3C, 66, 6F, 6F, 3E, C2, 80, 3C, 2F, 66, 6F, 6F, 3E]); string s = cast(string)arr; dstring ds = to!dstring(s); and see what happens
