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: 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.
*/
Voting for std.experimental.checkedint
http://forum.dlang.org/post/wgsguzbgrcejptuxf...@forum.dlang.org
std.experimental.checkedint Formal Review
http://forum.dlang.org/post/mnounbaobgphbmanf...@forum.dlang.org
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
}
Re: The D Language Foundation is now a tax exempt non-profit organization
Awesome Job
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.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: 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: Release D 2.071.1
Awesome, releases are becoming more and more boring. I like it!
std.experimental.checkedint is ready for comments!
http://forum.dlang.org/post/jxaisipbdqfifpncn...@forum.dlang.org
Re: Battle-plan for CTFE
awesome news :-) thanks you
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: 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: D Structs(Enums) to Typescript Interfaces(Enums)
Update: It now also generates functions that call the vibe.d rest service in typestrict.
D Structs(Enums) to Typescript Interfaces(Enums)
dstructtotypescript is a program that created typescript
interfaces/enums out of D
structs/enums.
https://github.com/burner/dstructtotypescript
The web framework vibe.d was very good at serializing data into
json.
Typescript allows the user to have a typed version of
javascript. Which means the user has to keep two version of the
same structure
in sync. That is tedious and error prone task.
dstructtotypescript alleviates
this problem as its automatically generates the typescript
interfaces for the
user.
## Example
Given a D two structs (test/teststruct.d):
```D
module test.teststruct;
struct Other {
string id;
}
struct Obj {
string name;
int id;
float value;
int[] ids;
int[5][] ids2;
Other other;
Other[] others;
Other[][5][] others2;
bool[][5] bools;
}
enum Colors {
red = 0,
blue = 1,
green = 4
}
```
```bash
dstructtotypescript -i test/teststruct.d -p
test/testfileprefix.ts -s Obj -s Colors -s Other -d
```
will create the following typescript interfaces:
```
// THIS FILE WAS GENERATED DO NOT MODIFY
///
interface Obj {
name: string;
id: number;
value: number;
ids: number[];
ids2: number[][];
other: Other;
others: Other[];
others2: Other[][][];
bools: boolean[][];
}
enum Colors {
red = 0,
blue = 1,
green = 4
}
interface Other {
id: string;
}
```
test/testfileprefix.ts is a file which contains is prefixed to
the resulting
.ts file
Re: Release D 2.069.2
wonderful!
Re: Beta D 2.069.0-b2
On Thursday, 15 October 2015 at 10:33:11 UTC, Andrei Alexandrescu wrote: On 10/15/15 10:51 AM, Robert burner Schadek wrote: On Thursday, 15 October 2015 at 05:47:16 UTC, Andrei Alexandrescu wrote: Brian, should we add you? LMK. -- Andrei indeed! Dunn. -- Andrei nice
Re: Beta D 2.069.0-b2
On Thursday, 15 October 2015 at 05:47:16 UTC, Andrei Alexandrescu wrote: Brian, should we add you? LMK. -- Andrei indeed!
Voting for std.experimental.testing
http://forum.dlang.org/post/jnihyetudelpkvrxl...@forum.dlang.org
Re: Release D 2.068.2
On Thursday, 24 September 2015 at 00:10:34 UTC, Martin Nowak wrote: Glad to announce D 2.068.2. Congratulations
std.experimental.testing formal review
http://forum.dlang.org/post/stbdckpfsysjtppld...@forum.dlang.org
Re: D-Day for DMD is today!
Awesome job Daniel!
Re: Voting for std.experimental.allocator
Yes
Re: Arch Linux D package update
On Thursday, 4 June 2015 at 14:46:39 UTC, Dicebot wrote: dcd - new package, release 0.6.0 - only x86_64 for now (upstream bug) - provides systemd service : `sudo systemctl enable dcd.service` to start automatically upon system startup this is totally awesome, thank you
Re: D 2.067.1
awesome job
Re: Release D 2.067.0
On Wednesday, 25 March 2015 at 02:02:50 UTC, Paul O'Neil wrote: I have been eagerly awaiting this release for a while - especially for std.experimental.logger! let me know how you like it! I always need feedback on it
Re: D 2.067.0-b3
On Wednesday, 4 March 2015 at 16:14:31 UTC, Mario Kröplin wrote: I just tried the beta with one of our applications, which receives and decodes tens of thousands of XML documents and makes heavy use of the garbage collector. Compared to D 2.066.1, there is a speed-up from 34.5 seconds to 26.5 seconds. Nice! this should be headline news.
Re: DConf 2015 discounted hotel rooms now available
On Monday, 2 March 2015 at 15:14:57 UTC, Andrew Edwards wrote: What is the unofficial hangout spot for this year? DConf15 takes place at a university, can't we hang on campus.
Re: D idioms list
that a really nice idea, thanks. substring position, std.string.(last)indexOf(|Any|Neither) may be better btw. this should move to the dlang wiki. Any takers?
Re: Dutyl - a Vim plugin for running D tools
nice, thanks
Re: DConf 2014 Lightning Talks
On Monday, 21 July 2014 at 22:08:26 UTC, Brian Schott wrote: On Monday, 21 July 2014 at 22:04:58 UTC, Ali Çehreli wrote: Thanks! I will wait at least another year before watching the video. I don't think I can stand seeing myself cramming 26 slides in 10 minutes! :) Ali I know how you feel. I don't want to watch my talk either. I did watch mine and I'm a cocky son of a . that will not look in the mirror for a week. But IMO it is a good tool for self-reflection. I learned that my voice is annoying and that I had to much food lately. @Brian and @Ali you're fine, don't worry.
Re: DConf 2014 publishes schedule, opens registration
On 05/22/2014 11:51 PM, Ali Çehreli via Digitalmars-d-announce wrote: On 03/03/2014 04:13 PM, Ali Çehreli wrote: On 03/03/2014 04:09 PM, Alessandro Stamatto wrote: Damn! No spoilers about the mysterious Scott Meyers talk, what is the last thing D needs?!?!?! Curious! 8-) Scott himself? ;) Ali It turns out, I was right for the wrong reason. :) It was an excellent talk. Ali They only problem with his talk was that I now feel very bad about my C++ skills ;-)
Re: DConf 2014 publishes schedule, opens registration
On 05/23/2014 01:41 PM, Atila Neves via Digitalmars-d-announce wrote: On Friday, 23 May 2014 at 16:47:25 UTC, Robert BuRnEr Schadek via Digitalmars-d-announce wrote They only problem with his talk was that I now feel very bad about my C++ skills ;-) You? I was the one he said that's cute to! :P Atila By that point I was crying inside already. If that would had been directed at me, I would have crawled under the table eating my shoe ;-)
Re: DConf 2013 Pictures
thank you On 05/20/2014 12:37 PM, Ali Çehreli via Digitalmars-d-announce wrote: I hope it's not too stale. :p http://acehreli.org/DConf_2013_Pictures/ Ali
