Re: Breaking news: std.uni changes!

[Robert Schadek via Digitalmars-d-announce]

Awesome work, thank you

Re: text based file formats

[Robert Schadek via Digitalmars-d-announce]

replay -> reply

Re: text based file formats

[Robert Schadek via Digitalmars-d-announce]

Curious why CSV isn't in the list. I encounter that a lot at 
tax time.


As Adam said, std.csv is already there and its at least from my 
perspective okay enough.


That being said, I liked how you quoted me here

On Monday, 19 December 2022 at 09:55:47 UTC, Walter Bright wrote:

On 12/18/2022 7:56 AM, Robert Schadek wrote:

So stop talking, and start creating PR's.


Yup!



and replay, create an PR that puts it on the list ;-)

text based file formats

[Robert Schadek via Digitalmars-d-announce]

I complaint before that D and phobos needs more stuff.
But I can't do it all by myself, but I can ask for help.

So here it goes https://github.com/burner/textbasedfileformats

As on the tin, text based file formats is a library of SAX and 
DOM parsers for text based file formats.


I would like to get the following file formats in.

* json (JSON5) there is actually some code in there already
* xml, there is some code already, the old std.experimental.xml 
code

* yaml, maybe there is something in code.dlang.org to be reused
* toml, maybe there is something in code.dlang.org  to be reused
  * ini, can likely be parsed by the toml parser
* sdl, I know I know, but D uses it.

There are a few design guidelines I would like to adhere to.
* If it exists in phobos, use phobos
* have the DOM parser based on the sax parser
* no return by ref
* make it @safe and pure if possible (and its likely possible)
* share the std.sumtype type if possible (yaml, toml should work)
* no @nogc, this should eventually get into phobos

So stop talking, and start creating PR's.
For the project admin stuff, this will use github. There are 
milestones for the five formats, so please start creating the 
issues you want/can work on and start typing.

Re: Initial release of newxml done!

[Robert Schadek via Digitalmars-d-announce]

cool, keep up the good work.

Re: DConf 2022 in London?

[Robert Schadek via Digitalmars-d-announce]

Yes please, sign me up

Re: Error message formatter for range primitives

[Robert Schadek via Digitalmars-d-announce]

On Wednesday, 5 January 2022 at 12:32:10 UTC, Elronnd wrote:

Cool project!

The mechanism you use is very special-purpose, in that you have 
to write a lot of specific code to get such nice output.  
There's a trick I came up with, that I've been meaning to post 
about, which gives slightly less nice output, but requires no 
manual effort and is completely general.


I would guess with my library your manual effort, at least for 
range primitives, is down to


```sh
dub add range_primitives_helper
```

;-)

Error message formatter for range primitives

[Robert Schadek via Digitalmars-d-announce]

In 
https://forum.dlang.org/post/tfdycnibnxyryizec...@forum.dlang.org 
I complained
that error message related to range primitives like isInputRange, 
especially on

template constraints, are not great.

As talk is cheap, and you put your code where your mouth is, I 
created


https://github.com/burner/range_primitives_helper

which you can know add to your project in version in v1.0.0 by

```sh
dub add range_primitives_helper
```


# Range Primitives Helper

Range primitives like `isInputRange` are used in many places in D 
code.
When the usage of those primitives leads to a compile error, 
because e.g. the
passed type is not an InputRange, the error messages are often 
not very helpful.
This is especially true, if range primitives are used as function 
constraints

for function overloading.

For example:
```dlang
void fun(T)(T t) if(isInputRange!T && !isRandomAccessRange!T) {
}

void fun(T)(T t) if(isRandomAccessRange!T) {
}
```

This is at least annoying, and avoidable at best.
This library **Range Primitives Helper** helps making this less 
annoying.


## Usage

```dlang
import range_primitives_helper;

enum string result = isInputRangeErrorFormatter!(T);
```

If the passed type `T` is an InputRange the `enum string result` 
will read


```dlang
T.stringof ~ " is an InputRange"
```

if `T` is not an InputRange the string will list which criteria 
of the

InputRange concept is not fulfilled by `T`;

But this is only half the work.
The other part is a bit of a refactoring effort.
Instead of having to template functions that use function 
constraints to do the
overload resolution, a better approach is to have what I would 
call a

*dispatch function* like this.

```dlang
import range_primitives_helper;

void fun(T)(T t) {
static if(isRandomAccessRange!T) {
funRAR(t);
} else static if(isInputRange!T) {
funIR(t);
} else {
static assert(false, "'fun' expected 'T' = "
~ T.stringof ~ " either to be
~ an InputRange or"
~ " a RandomAccessRange but\n"
~ isInputRangeErrorFormatter!(T)
~ "\n"
~ isRandomAccessRangeErrorFormatter!(T));
}
}

private void funIR(T)(T t) {
}

private void funRAR(T)(T t) {
}
```

Calling `fun` with an `int` for example results in, IMO very 
nice, error message


```sh
SOURCE_LOCATION: Error: static assert:  "
'fun' expected 'T' = 'int' either to be an InputRange or a 
RandomAccessRange but

int is not an InputRange because:
the property 'empty' does not exist
and the property 'front' does not exist
and the function 'popFront' does not exist
int is not an RandomAccessRange because
the property 'empty' does not exist
and the property 'front' does not exist
and the function 'popFront' does not exist
and the property 'save' does not exist
	and int must not be an autodecodable string but should be an 
aggregate type

and int must allow for array indexing, aka. [] access"
```

If we call `fun` with a custom `struct` that looks like

```dlang
struct Thing {
void popFront();
@property int front() { return 0; }
}
```

we get the error string

```sh
SOURCE_LOCATION: Error: static assert:  "
'fun' expected 'T' = 'Thing' either to be an InputRange or a 
RandomAccessRange but

Thing is not an InputRange because:
the property 'empty' does not exist
Thing is not an RandomAccessRange because
the property 'empty' does not exist
and the property 'save' does not exist
and must allow for array indexing, aka. [] access"
```

## Primitives

The are primitives for:

| Type | std.range | range\_primitives\_helper |
|  | - | --- |
| InputRange | isInputRange | isInputRangeErrorFormatter |
| BidirectionalRange | isBidirectionalRange | 
isBidirectionalRangeErrorFormatter |

| ForwardRange | isForwardRange | isForwardRangeErrorFormatter |
| RandomAccessRange | isRandomAccessRange | 
isRandomAccessRangeErrorFormatter |

| OutputRange | isOutputRange | isOutputRangeErrorFormatter |

Re: GDC has just landed v2.098.0-beta.1 into GCC

[Robert Schadek via Digitalmars-d-announce]

Awesome congratulations

Re: code-d 0.23.0

[Robert Schadek via Digitalmars-d-announce]

for nvim with coc's I do

```js
{
"languageserver": {
"d": {
			"command": 
"/home/burner/.dub/packages/serve-d-0.7.0/serve-d/serve-d",

"filetypes": ["d"],
"trace.server": "on",
"rootPatterns": ["dub.json", "dub.sdl"],
"initializationOptions": {
},
"settings": {
}
}
},
"suggest.autoTrigger": "none",
"suggest.noselect": false
}
```

Which works very nicely.

countries_currencies_languages the most boring package ever

[Robert Schadek via Digitalmars-d-announce]

If you deal with people in your software at some point these 
three,

countries, currencies, and languages will become relevant.
Instead of hacking it why not use structured recognized 
information.


This is where

https://code.dlang.org/packages/countries_currencies_languages

comes in. As the name stats this package contains a lot of 
information

about these three topics.

On top of all information of iso639, iso3166, and iso4217 some 
additional information is contained.

Re: From the D Blog: Driving with D

[Robert Schadek via Digitalmars-d-announce]

Very cool

Re: dub 502 bad gateway

[Robert Schadek via Digitalmars-d-announce]

very nice, thank you

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

Thank you, very nice test

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

On Thursday, 23 January 2020 at 20:50:09 UTC, Sebastiaan Koppe 
wrote:

Haven't tried Inclusive.no yet. I'll leave that to someone else.


Indirectly you already did, invert turns Inclusive.yes bound into 
Inclusive.no bounds.

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

dud needs your help.

I'm starting work on the dependency resolution and for that I had
to implement proper handling for Semantic Versions, Version 
Ranges,

and Version Unions(VersionUnion is basically a VersionRange[]).
The dependency resolution algorithm I want to implement (based on
the algorithm used by Dart) needs a few checks and operations on
those types.

```D
SemVer parseSemVer(string input);

Nullable!VersionRange parseVersionRange(string input);

alias Types = AliasSeq!((SemVer,VersionRange,VersionUnion);
static foreach(T, Types) {
auto inv = invert(T);
static foreach(S, Types) {
bool allowsAll(T, T);
bool allowsAll(T, S);
bool allowsAll(S, T);

bool allowsAny(T, T);
bool allowsAny(T, S);
bool allowsAny(S, T);

auto unionOf(T, T);
auto unionOf(T, S);
auto unionOf(S, T);

auto intersectionOf(T, T);
auto intersectionOf(T, S);
auto intersectionOf(S, T);

auto differenceOf(T, T);
auto differenceOf(T, S);
auto differenceOf(S, T);
}
}
```

I think I did okay work and the tests cover all/most cases.
But that's properly being a bit overconfident.

Therefore, it would be awesome if you could try to break
these functions and create PRs that break the functions.

The code can be found in the git here 
https://github.com/symmetryinvestments/dud

the relevant folder is semver.
The tests are located in the files:

allowsAny: semver/source/dud/semver/checkstest.d
allowsAll: semver/source/dud/semver/checkstest1.d
allowsAll: semver/source/dud/semver/setoperationtest.d
intersectionOf: semver/source/dud/semver/setoperationtest1.d
invert, differenceOf: semver/source/dud/semver/setoperationtest2.d
semver/source/dud/semver/versionrangetest.d

Building dud, and semver should be as easy as cloning and typing 
dud, dub test.


```sh
git clone https://github.com/symmetryinvestments/dud.git
cd dud/semver
dub test
```
should get you going.

DESTROY!

Re: Article about D in the iX magazine

[Robert Schadek via Digitalmars-d-announce]

On Saturday, 21 December 2019 at 10:43:05 UTC, Andre Pany wrote:
On Saturday, 21 December 2019 at 09:15:26 UTC, Robert burner 
Schadek wrote:

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 ;-)



It is out since a few days. Yes, my comment from 
https://www.heise.de/forum/heise-online/Kommentare/Multiparadigmensprache-Programmieren-in-D/Sehr-zu-empfehlen/posting-35645917/show/ was added to the print edition.


Kind regards
Andre


Thank you for the info and the link.

Re: What is the point of a synchronized lock on a single return statement?

[Robert Schadek via Digitalmars-d-learn]

But be aware, even though the bool is returned from a 
synchronized block,

its actual value has no meaning at all.

All the meaning you get out of that bool is that the MessageBox 
was closed

when you called that function.
If there is a function in MessageBox that can reopen the instance,
you can not assume that the MessageBox is still closed when you
read the bool.
Assuming your program has more than one thread touching that 
instance of

the MessageBox.

Consider

```
auto mb = new MessageBox();
bool c = mb.isClosed();
// this thread gets preempted, and another thread
// does something with mb that changes its state

if(!c) { // the value of c might not what you expected
   // start rockets
}
```

This problem, at least partly, spawn concepts like Monitors,
the Rendezvous concept, Message Passing, and others.

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

On Monday, 25 November 2019 at 13:14:09 UTC, Sebastiaan Koppe 
wrote:
The biggest thing for me would be incremental compilation. As 
well as a dub build and test 'watch' mode to avoid scanning the 
dependencies every time.


I think there are two levels to incremental compilation (IC).

1. File level IC. Meaning, if you have one file change, you only 
recompile
all files that depend on that directly or transitively. Finally, 
you relink.


2. Symbol level IC. Meaning, the compiler becomes a daemon, and 
you track

dependency on a symbol basis.

For 1. my goal with dud is to do that. My first target is to emit 
ninja files.

So IC is going to be the default, at least at first.

For 2. dud is build as a library first, meaning should the 
compiler
become a daemon at some point, libdud can be used to pull in 
packages from

code.dlang.org and resolve dub packages dependencies.

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

Regarding dependency resolution:

Did anybody here had a look at what the Dart people are
doing with pubgrab?

https://github.com/dart-lang/pub/blob/master/doc/solver.md
https://medium.com/@nex3/pubgrub-2fb6470504f
https://www.youtube.com/watch?v=Fifni75xYeQ

Especially the error reporting looks promising to me.

Re: Article about D in the iX magazine

[Robert Schadek via Digitalmars-d-announce]

I can only recommend to get in contact
with the magazine if anybody feels they have something to say.
Everybody I had contact with at the
magazine was nice and helpful.

It was a very interesting, and good
experience to write that article.

Re: Article about D in the iX magazine

[Robert Schadek via Digitalmars-d-announce]

shameless_promotion_on()

Buy the magazine.
If Our know D already you get a lot
more out of the other articles in it.

shameless_promotion_off()

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

I assume you don't mean the documentation for std.array 
specifically,

but the act of having documentation of the module.

Then, yes I do think documentation should not be needed.

I think it would be far better if I only needed the signatures of
the functions and the members of the structs to use them.
That I need to look at an example usage of a function to grasp its
meaning or read some text about it, is not a good sign IMHO.

Please keep in mind, I'm striving for an ideal, not reality.
dud will be documented, no question about it.
But I think, the longer documentation is not needed to understand
dud, the better.

p.s. I find it hard to explain this in writing.
It makes perfect sense in my head. Maybe I can convince you in 
person

at the next dconf.

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

On Tuesday, 19 November 2019 at 17:13:49 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 11/19/19 11:30 AM, Steven Schveighoffer wrote:


And I would complain that the fact json exists as a file 
format already screws up dub add -- using dub add removes ALL 
comments in an SDL file, and rewrites the file in the order it 
sees fit.


result: I don't use dub add any more.


Oops, that's probably actually my fault, not dub's. Those are 
current limitations of the sdl lib, SDLang-D.


dud has its own sdlang parser, I wanted to have no dependencies 
other than

phobos and SDLang-D was not pure nor @safe, mostly because of
static Key[5] keywords; in Lexer.lexIdentKeyword.

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

On Tuesday, 19 November 2019 at 16:30:26 UTC, Steven 
Schveighoffer wrote:
And I would complain that the fact json exists as a file format 
already screws up dub add -- using dub add removes ALL comments 
in an SDL file, and rewrites the file in the order it sees fit.


result: I don't use dub add any more.

-Steve


I haven't implemented dud add yet, but it should be as easy as
parsing the file checking if the dep is already in.
If it is not the case add a new line to the end of the file.
dub.sdl files have no order after all.

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

On Monday, 18 November 2019 at 12:59:25 UTC, Joseph Rushton 
Wakeling wrote:


Cool :-)  Since I have also been experiencing a fair bit of 
production-use DUB pain in the last year, I really appreciate 
your taking action on this.


A few things that would be good to understand up front:

  * what are the particular issues with DUB that you want to 
address?


  - making the codebase cleaner and more functional is 
obviously
nice but is at most a means to an end -- what's the 
real end

you have in mind?


My reason for making it cleaner is, because I assume this will 
give

me a build tool I can fix when broken. And hopefully it has less
bugs to begin with because its cleaner.



  - I would imagine getting dependency resolution really 
right
would be top of the list -- it would be good to aim to 
fix

issues like https://github.com/dlang/dub/issues/1732


That is one thing yes.



  - I would personally really appreciate it if you would 
make it
a design goal to better separate concerns in terms of 
what
DFLAGS are used and why (for example, the fact that 
right now
`dub test --build=release` will not actually run 
unittests,

as `--build=release` drops the `-unittest` flag)

  * are there any particular known issues with DUB that this 
definitely

will NOT address?


I'm not sure yet.



  * are there any key _breaking_ changes you have in mind?

  * where does this stand w.r.t. some of the proposals to break 
DUB apart
into more cleanly separated components, e.g. determining 
compatible
dependencies, downloading dependencies, building or running 
tests ... ?


It is build as a library first. The CLI is just using the library
constructs.



Some concrete feedback on the project as it stands:

  * the tickboxes of compatible commands are nice, but it would 
be good to
have a more contextualized roadmap, in particular outlining 
the design

concerns for core data structures and functionality

  - this should probably be in issues rather than the 
README, but
it needs to be somewhere, otherwise it's hard for 
anyone outside

to identify things they can do


True, I'll work on that.



  - it might be nice to use a GitHub project to manage 
things so that
us outside folks can identify better what's being 
worked on and

what's blocked by what


I already started that, somewhat.



  * I don't mind breaking changes in either the config format 
or the command
line API if it gets us to a nicer tool, so please embrace 
the opportunity

where appropriate

  - I can imagine this might be the reason why the aim is 
to support
a "tasteful subset" of DUB's features: it means that 
others can

be re-implemented in an incompatible but better way

  - auto-conversion mechanisms may be preferable to 
outright support

for old formats and commands

  * I really recommend trying to start writing clean, clear 
commit messages
from the very start -- think of this as another form of 
code documentation
that communicates to all interested readers the intent and 
considerations
behind any particular change to the codebase.  This makes 
it much easier
for outsiders to get a clear understanding of the project 
and get into the

habit of contribution

  - right now, pretty much all the commit messages read 
like spontaneous
notes where even YOU won't remember the whys or 
wherefores in a few

months' time


I know, I'll try to do better



  - long term it saves a LOT of time when trying to look 
back and understand
"Why did we do things that way?" -- particularly useful 
when trying to

fix some subtle design bug

  * for the same reasons, really try to provide good 
documentation and comments
for all code from the start -- this really makes it much 
easier for anyone
interested to grasp the major design concerns and get 
contributing


Here is disagree, to a degree I consider comments a code smell.
If I have to write them, I failed to convey the information
needed to understand the code in the code.



  * these concerns are going to be strongest for the key data 
structures and
algorithms -- please make sure these are REALLY documented 
well, from the

very start

Hope all of that's helpful, and best wishes for taking this 
forward -- I will try to help as I can, but time right now is 
very constrained ... ;-)


Thanks & best wishes,

 -- Joe


Thank you

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

On Monday, 18 November 2019 at 16:31:09 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 11/18/19 7:59 AM, Joseph Rushton Wakeling wrote:
   - I would imagine getting dependency resolution really 
right
     would be top of the list -- it would be good to aim 
to fix

     issues like https://github.com/dlang/dub/issues/1732


As has been discussed elsewhere a few months ago, dependency 
resolution should be outsourced to an established SAT 
 
solving lib, to avoid re-inventing a notoriously difficult 
wheel. This is what all the serious package managers have been 
moving towards, after invariably hitting problems (much like 
dub) trying to roll-their-own.


OT: By saying "all the __serious__" you effectively ended this 
part of the thread.
You basically say, that whatever I do, solve P=NP for instance, 
dud will

never be a __serious__ package manager because it does not use an
existing SAT solver.
That's just bad arguing.

The thing I want from dud, is to tell me what dependency chain 
let to conflicts

and this I find hard to extract from current SAT solvers.
Most I have worked with just told me: "This solution works" "NO"
Also the debug experience is not really great most of the time.
And I like a good debug experience.

I'm not saying I will or want to reinvent the wheel on dependency 
resolution,
but if there is a choice of Understandability + debugability vs. 
performance.

Performance will suffer.

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

On Monday, 18 November 2019 at 23:08:13 UTC, Laurent Tréguier 
wrote:


I don't understand why this would apply to JSON specifically. 
Whatever the language is, the config files will be 
hand-written; spelling errors are pretty universal, and 
anything we write is prone to mistakes to some extent


dud already tells you if you mistyped a key.

Adding new file formats is "trivial" with dud current code base.

This 
https://github.com/symmetryinvestments/dud/blob/master/pkgdescription/source/dud/pkgdescription/package.d is the data structure used to mirror the file content.


This 
https://github.com/symmetryinvestments/dud/blob/master/pkgdescription/source/dud/pkgdescription/json.d is the json reader.


Currently, I have no plans to add any other file format.
But PR's are always welcome.
The decision on json and sdl has been made a long time ago, for 
better

or for worse.
Please don't turn this thread into bike-shedding.
Additionally, dub/dud is already on the way to add cli functions 
to manipulate

the config file.
A look at adding dependencies with "dub add" already shows that.

Re: dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

On Friday, 15 November 2019 at 10:29:07 UTC, FeepingCreature 
wrote:
Are you looking to replace dub as the reference build tool for 
D? (Please say yes...)


reference build tool, I don't know. We will see.



Any estimate what the schedule looks like until dud can be used 
in practice?


dub convert works already ;-)

No, PR's welcome

dud: A dub replacement

[Robert Schadek via Digitalmars-d-announce]

So dub has some problems, and personally I find its code base 
very hard to get

into.
At Symmetry we are a very heavy user of dub, resulting in many 
wasted hours.


So I started to write dud [1]. I kept some boring/nice parts from 
dub, but most

code so far is a complete rewrite.

The goal of dud is mostly do what dub does, but more 
understandable.

dud will/does aim for a tasteful subset of dub's features.
Meaning, most dub files should be good with dud.
If they are not, you will/should get an error message telling you 
whats wrong.
The bigger goal, at least personally, is to have a code base of 
pure functions

that is "trivial" to understand and debug.
The rules of thumb is: "When your line gets longer than 80 
characters,

restructure your code!", "Branch statements are code smells."

So what can dud do right now.

$ dud convert

works.
IMO that is an important step, as this involves ingesting 
dub.(json|sdl) into

a common representation.

I use dubproxy [2] to get all ~1.6k packages from code.dlang.org 
and create a

git working tree for all the versions of all the packages.
Currently, that results in ~60k (package|dub).(json|sdl) files.
Then, I run dud on those and see what breaks.
Only a few percent are not ingestable by dud, and those are in 
IHMO not valid

anyway (to be fair, there is some strange  out there).

Now that dud can parse dub files, the next step will be a 
semantic phase,

checking the input for errors.
After that, path expansion and dependency resolution.

PR's are always welcome.

Destroy!

[1] https://github.com/symmetryinvestments/dud
[2] https://github.com/symmetryinvestments/dubproxy

Re: Oberon to D

[Robert Schadek via Digitalmars-d-announce]

very sweet! Blog Post please

Juliad: A library for interop between D and Julia

[Robert Schadek via Digitalmars-d-announce]

As the name says on the tin, juliad is a library to call Julia 
from D and call D from Julia.

The calling D from Julia part is not there yet.
Its still very rough, not only on the edges, but it is a running 
start.


https://github.com/symmetryinvestments/juliad
https://code.dlang.org/packages/juliad

PRs and Issues are always welcome.

Re: dubproxy: Easy private repos and code.dlang.org mirror

[Robert Schadek via Digitalmars-d-announce]

classic noob error: forget the urls

* https://code.dlang.org/packages/dubproxy
* https://github.com/symmetryinvestments/dubproxy

dubproxy: Easy private repos and code.dlang.org mirror

[Robert Schadek via Digitalmars-d-announce]

# dubproxy

dubproxy is a library and cli to efficently use private dub 
packages and mirror

code.dlang.org, all without a private registry.
It is a standalone library/cli and is completely transparent for 
dub.


## private libraries

Sometimes a dub project needs access to private library.
Subpackages are one solution, but getting dub to correctly work 
with subpackages

is not always easy.
Therefor, it is sometimes desirable to complete split out 
subpackages into there

own dub project.
Dubproxy allows to do that.
One of dubproxy's features is to take local/remote dub projects, 
located in a
git, and insert them into ~/.dub/packages such that dub thinks 
its just another

package from code.dlang.org.

## code.dlang.org mirroring

Code.dlang.org is not always accessible, but a still might be 
required right

now.
Maybe you are on a flight to dconf or code.dlang.org is down.
Dubproxy allows you to get a storable list of all packages and 
upstream urls.
This list can then be used by dubproxy to get a particular 
package or

package-version.
You need internet access of course.
As time of writing this Aug. 2019 all gits of all package of 
code.dlang.org

require about 6.5 GB of space.

## Examples

1. Get dubproxy(cli)
```sh
$ dub fetch dubproxy
$ dub run dubproxy
```

2. put dubproxy in your path or use `$ dub run dubproxy --`
3. get list of code.dlang.org packages
```sh
$ dubproxy -m -n codedlangorg.json
```

4. get a package from a dubproxyfile
```sh
$ dubproxy -i codedlangorg.json -g xlsxd
```
By default dubproxy will try to place the git in system default 
dub directory.


5. get a package and place the git a user specified directory
```sh
$ dubproxy -i codeldangorg.json -g xlsxreader -f GitCloneFolder
$ dubproxy -i codeldangorg.json -g xlsxreader:v0.6.1 -f 
GitCloneFolder

```

6. place the dub package in a user specified directory
```sh
$ dubproxy -i codeldangorg.json -g graphqld -o SomePackageFolder
```

7. get multiple packages
```sh
$ dubproxy -i codeldangorg.json -g graphqld -g inifiled
```

8. get all packages in a file (run before long flight)
```sh
$ dubproxy -i codeldangorg.json -a -u
```

The `-u` is necessary to disable user interaction, because some 
listed packages
on code.dlang.org do not exist anymore and github.com therefore 
askeds for a

username password combination.

9. dub is not in your path
```sh
$ dubproxy -d path_to_dub
```

10. git is not in your path
```sh
$ dubproxy -p path_to_git
```

11. generate a dummy dubproxy.json file with filename 
myPrivateProjects.json

```sh
$ dubproxy --dummy --dummyPath myPrivateProjects.json
```

12. get help
```sh
$ dubproxy -h
```

## PRs are always welcome!

About Kaleidic Associates
-
We are a boutique consultancy that advises a small number of 
hedge fund clients.
We are not accepting new clients currently, but if you are 
interested in working
either remotely or locally in London or Hong Kong, and if you are 
a talented
hacker with a moral compass who aspires to excellence then feel 
free to drop me

a line: laeeth at kaleidic.io

We work with our partner Symmetry Investments, and some 
background on the firm

can be found here:

http://symmetryinvestments.com/about-us/

Re: Started a neat 3D model project of D's mascot in Paint3D

[Robert Schadek via Digitalmars-d-announce]

sweet!
any change to get a stl, so I can put it on my 3d printer

Re: Darser: A LL(1) to Recursive Decent Parser/AST/Visitor Generator

[Robert Schadek via Digitalmars-d-announce]

On Wednesday, 20 March 2019 at 21:30:29 UTC, Cym13 wrote:

This looks nice! I'm familiar with pegged which uses PEG 
grammars, could you maybe comment on the differences and 
possible benefits of Darser in comparison?


Pegged can recognise a lot more than LL(1) 
(left-recursion,retry,...), Darser can not.

Pegged is really smart, Darser is really stupid.

Pegged error messages are really bad, Darser's are really good.
The Darser AST has actual classes you can set breakpoint on, 
pegged does not.

Darser has a in-build visitor class generated, pegged does not.
Stepping through a parse of some input is really easy in Darser, 
just set your breakpoints inside the parser class, in pegged that 
is not possible.


Pegged runs a CT, Darser puts out files you have to compile.

graphqld: A graphql backend written in D

[Robert Schadek via Digitalmars-d-announce]

At Symmetry [6] we needed a graphql [1] backend.
So I wrote one.

Grapqhl is a query language, initially developed by facebook, 
that can be considered to be a replacement for REST.
Grapqhl allows you efficiently query an endpoint and select what 
data you actually want.
Clients are trivial to created, all they need to be able to do is 
a http get/post (curl)

Graphql endpoint are introspectable.
If all you know is the ip of the endpoint you can query for all 
possible types, queries, and how they relate to each other.
The tool graphiql-app [4] uses this information to implement 
typeahead.

Look at [5] to see what is possible with that.

Using graphqld [2,3] you can now do the following.

So given a schema:
```D
interface Query {
Nullable!Starship starship(long id);
Starship[] starships(float overSize = 100.0);
}

class Schema {
Query queryType;
}

abstract class Character {
long id;
string name;
Nullable!Starship ship;
}

abstract class Humanoid : Character {
string species;
}

abstract class Android : Character {
string primaryFunction;
}

class Starship {
string name;
string designation;
double size;

Character[] crew;
}
```

you can send a query like:
```
query a {
  starships {
name
crew {
  ...charac
}
  }
}

fragment hyooman on Humanoid {
  species
}

fragment robot on Android {
  primaryFunction
}

fragment charac on Character {
  id
  ...robot
  ...hyooman
  name
  series
}
```

and get back json like that:
```json
{
  "error": [],
  "data": {
"starships": [
  {
"name": "Enterprise"
"crew": [
  {
"species": "Human",
"series": [
  "TheNextGeneration",
  "DeepSpaceNine"
],
"id": 0,
"name": "Jean-Luc Picard"
  },
  {
"species": "Klingon",
"series": [
  "TheNextGeneration",
  "DeepSpaceNine",
  "DeepSpaceNine"
],
"id": 1,
"name": "Worf"
  },
  {
"primaryFunction": "Becoming Human",
"series": [
  "TheNextGeneration"
],
"id": 5,
"name": "Data"
  },
  ...
}
```

Graphqld is still somewhat rough around the edges, but should be 
in a usable state.
The example in the test folder gives a good impression of how to 
work with

resolvers.
To play with the example, I suggest the tool graphiql-app [4].

The parser is build using darser [7].

[1] https://graphql.org/
[2] https://github.com/burner/graphqld
[3] https://code.dlang.org/packages/graphqld
[4] https://github.com/skevy/graphiql-app
[5] 
https://github.com/burner/graphqld/blob/master/test/introspectionquery.gql

[6] http://symmetryinvestments.com/
[7] https://code.dlang.org/packages/darser

Darser: A LL(1) to Recursive Decent Parser/AST/Visitor Generator

[Robert Schadek via Digitalmars-d-announce]

To get graphqld up and running I needed a parser/ast/visitor.
Being lazy, I created parser/ast/visitor generated for that.

Darser is the result.

Given a language BNF, as e.yaml, darser will generate a recursive 
decent parser, a set of classes making up the AST, a visitor 
class and a AST printer class. The parser, AST, and visitor can 
be extended by hand written extensions.


Given a yaml file like this:
```
PrimaryExpression:
Identifier: [ identifier#value ]
Float: [ float64#value ]
Integer: [ integer#value ]
Parenthesis: [lparen, Expression#expr, rparen]
```

darser will create a parser function as such:
```D
PrimaryExpression parsePrimaryExpressionImpl() {
string[] subRules;
subRules = ["Identifier"];
if(this.lex.front.type == TokenType.identifier) {
Token value = this.lex.front;
this.lex.popFront();

return new PrimaryExpression(PrimaryExpressionEnum.Identifier
, value
);
} else if(this.lex.front.type == TokenType.float64) {
Token value = this.lex.front;
this.lex.popFront();

return new PrimaryExpression(PrimaryExpressionEnum.Float
, value
);
} else if(this.lex.front.type == TokenType.integer) {
Token value = this.lex.front;
this.lex.popFront();

return new PrimaryExpression(PrimaryExpressionEnum.Integer
, value
);
} else if(this.lex.front.type == TokenType.lparen) {
this.lex.popFront();
subRules = ["Parenthesis"];
if(this.firstExpression()) {
Expression expr = this.parseExpression();
subRules = ["Parenthesis"];
if(this.lex.front.type == TokenType.rparen) {
this.lex.popFront();

return new 
PrimaryExpression(PrimaryExpressionEnum.Parenthesis
, expr
);
}
auto app = appender!string();
formattedWrite(app,
"Found a '%s' while looking for",
this.lex.front
);
throw new ParseException(app.data,
__FILE__, __LINE__,
subRules,
["rparen"]
);

}
auto app = appender!string();
formattedWrite(app,
"Found a '%s' while looking for",
this.lex.front
);
throw new ParseException(app.data,
__FILE__, __LINE__,
subRules,
["float64 -> PostfixExpression",
 "identifier -> PostfixExpression",
 "integer -> PostfixExpression",
 "lparen -> PostfixExpression"]
);

}
auto app = appender!string();
formattedWrite(app,
"Found a '%s' while looking for",
this.lex.front
);
throw new ParseException(app.data,
__FILE__, __LINE__,
subRules,
["identifier","float64","integer","lparen"]
);

}
```

and an AST class like that:
```D
enum PrimaryExpressionEnum {
Identifier,
Float,
Integer,
Parenthesis,
}

class PrimaryExpression {
PrimaryExpressionEnum ruleSelection;
Token value;
Expression expr;

this(PrimaryExpressionEnum ruleSelection, Token value) {
this.ruleSelection = ruleSelection;
this.value = value;
}

this(PrimaryExpressionEnum ruleSelection, Expression expr) {
this.ruleSelection = ruleSelection;
this.expr = expr;
}

void visit(Visitor vis) {
vis.accept(this);
}

void visit(Visitor vis) const {
vis.accept(this);
}
}
```

The lexer has to be hand written.

Re: Darser: A LL(1) to Recursive Decent Parser/AST/Visitor Generator

[Robert Schadek via Digitalmars-d-announce]

https://code.dlang.org/packages/darser

https://github.com/burner/Darser

FakeD

[Robert Schadek via Digitalmars-d-announce]

FakeD [2,3] is a fake data generator with support for 
localisation.

It is based on faker.js [1].
See [4] for a list of available methods.

void main() {
import std.stdio;
import faked;

auto f = new Faker(/*random seed */ 1337);

writeln(f.loremText());
writeln(f.addressCity());
writeln(f.nameName());

// localized to german
f = new Faker_de(/*random seed */ 1338);

writeln(f.loremText());
writeln(f.addressCity());
writeln(f.nameName());
}

[1] https://github.com/marak/Faker.js/
[2] https://code.dlang.org/packages/faked
[3] https://github.com/kaleidicassociates/faked
[4] https://kaleidicassociates.github.io/faked/

Re: xlsxd: A Excel xlsx writer

[Robert Schadek via Digitalmars-d-announce]

On Saturday, 10 November 2018 at 10:55:04 UTC, Dave wrote:
Could you please elaborate a bit on your workflow for D with 
Vim? E.g. what do you use for debugging, refactoring, ... ?


I had a lot of functions looking like this

void chart_axis_set_name(lxw_chart_axis* handle, const(char)* 
name)


I had to transform into

void setName(string name) {
chart_axis_set_name(this.handle, toStringz(name));
}

For that I created a handful of (neo)vim macros that basically it 
the transformations for me.


On my neovim setup. I use dutly. Dscanner generates ctags 
recursively when I press F7. Which Ctrl-P uses for jump marks.
I use kdbg to debug, its just a somewhat pretty frontend to gdb. 
Thats pretty much it.

Re: xlsxd: A Excel xlsx writer

[Robert Schadek via Digitalmars-d-announce]

dpp and a handful of vim macros did most of the work

Re: xlsxd: A Excel xlsx writer

[Robert Schadek via Digitalmars-d-announce]

On Wednesday, 7 November 2018 at 16:49:58 UTC, H. S. Teoh wrote:


Is there support for reading xlsx files too?



No, Pull Requests are welcome

xlsxd: A Excel xlsx writer

[Robert Schadek via Digitalmars-d-announce]

https://code.dlang.org/packages/xlsxd

Announcing xlsxd a OO wrapper for the C library libxlsxwriter [1].

Run:

import libxlsxd;
auto workbook  = newWorkbook("demo.xlsx");
auto worksheet = workbook.addWorksheet("a_worksheet");
worksheet.write(0, 0, "Hello to Excel from D");


and you have created a Excel spreadsheet in the xlsx format with 
name demo.xlsx
that contains the string "Hello to Excel from D" in row 0, column 
0.


[1] https://github.com/jmcnamara/libxlsxwriter

Re: Opportunities for D

[Robert Schadek via Digitalmars-d]

On 07/10/2014 05:59 PM, Dicebot via Digitalmars-d wrote:
 On Thursday, 10 July 2014 at 15:52:45 UTC, Andrei Alexandrescu wrote:
 On 7/10/14, 8:29 AM, Sean Kelly wrote:
 Robert's struggle with getting std.logger accepted is the stuff told to
 children around the campfire so they don't venture out into the dark.

 Actually we use his logger at Facebook quite extensively (and
 happily). -- Andrei

 And I still waiting for him to call for next formal review / voting
 round ;)
please, lets get cracking

Re: Opportunities for D

[Robert Schadek via Digitalmars-d]

On 07/10/2014 06:05 PM, Sean Kelly via Digitalmars-d wrote:
 On Thursday, 10 July 2014 at 15:52:45 UTC, Andrei Alexandrescu wrote:
 On 7/10/14, 8:29 AM, Sean Kelly wrote:
 Robert's struggle with getting std.logger accepted is the stuff told to
 children around the campfire so they don't venture out into the dark.

 Actually we use his logger at Facebook quite extensively (and
 happily). -- Andrei

 Yep, it's good!  But still not in Phobos despite his efforts.  At this
 point I honestly don't know what the blocker is either.  Maybe just
 inertia.
It is not just the logger.

I have multiple PRs who addressed all the critics, but are still getting
nowhere it seams.
I find myself rebasing from time to time just to get an autotester run
to see if it still merges and performs.

I know this is a bit OT and personal, but could somebody please merge
indexOfNeither aka indexOfNone. I just hate to copy this function from
one personal project to the next.

Re: Opportunities for D

[Robert Schadek via Digitalmars-d]

On 07/10/2014 10:31 PM, Walter Bright via Digitalmars-d wrote:
 On 7/10/2014 12:57 PM, Robert Schadek via Digitalmars-d wrote:
 I know this is a bit OT and personal, but could somebody please merge
 indexOfNeither aka indexOfNone. I just hate to copy this function from
 one personal project to the next.

 I don't know the PR link nor do I know what pseudonym you use on
 github, so please help!
https://github.com/D-Programming-Language/phobos/pull/1977 indexOfNeither
https://github.com/D-Programming-Language/phobos/pull/2072 getoptX

 I reiterate my complaint that people use virtual functions for their
 github handles. There's no reason to. Who knows that 9il is actually
 Ilya Yaroshenko? Took me 3 virtual function dispatches to find that out!

burner
 Take a look at the contributor list:

 https://github.com/D-Programming-Language/phobos/pulls

 I'm sure y'all know your own handles, but how many of the others do
 you know who they are?
I'm starting to know faces to the usernames, but yes it is not optimal

Re: SCons and D

[Robert Schadek via Digitalmars-d]

On 07/05/2014 07:00 PM, Russel Winder via Digitalmars-d wrote:
 SCons 2.3.2 has been released which has the revamped D tooling.

 I appreciate Dub is becoming the build system of choice for new D
 projects, so I will maintain the D support in SCons but definitely in
 maintenance mode rather than development mode. 
awesome, thank you

Re: D Hackday Round 2

[Robert Schadek via Digitalmars-d-announce]

On 07/04/2014 01:17 AM, Jonathan Crapuchettes via Digitalmars-d-announce
wrote:
 After the success of the last D hackday, EMSI is going to attempt to have 
 a D hackday once a month as close as we can to the first Friday of the 
 month. Our next round will be Friday July 11.

 Last time 24 issues were marked as resolved by the community (including 
 EMSI).

 Please join us in squashing bugs on #d.

 ---
 Jonathan Crapuchettes, Justin Whear, Brian Schott
I will have my PR rebased to master and I'll start sniffing through
bugzilla this weekend for low hanging and obsolete fruits. 

Re: Update on Aurora

[Robert Schadek via Digitalmars-d]

On 06/30/2014 07:29 AM, Adam Wilson via Digitalmars-d wrote:
 On Sun, 29 Jun 2014 21:57:22 -0700, Suliman everm...@live.ru wrote:

 Post screenshots please...

 Sadly I don't have anything that is visually beyond what I demoed at
 DConf so it's still just a blank window. I'm still down in the bowels
 of interacting with the operating system and time has been at a
 premium lately. Once I get multi-window rendering up and running I'll
 do some really simple color animations and post a video. After that
 I'll start on primitives and do a video of the user moving around some
 a square in the window. But there is a lot of infrastructure between
 here and there. :-)

I just have to ask, no blinking?

Re: EMSI has a Github page

[Robert Schadek via Digitalmars-d-announce]

On 06/27/2014 09:16 AM, Walter Bright via Digitalmars-d-announce wrote:
 On 6/26/2014 2:26 PM, Brian Schott wrote:
 https://github.com/economicmodeling

 Stuff that's been made available:
 * D implementation of the DDoc macro processor
 * Documentation generator that doesn't need the compiler
  - No more requirement to use all the -I options to just get docs.
  - Template constraints don't vanish.
  - size_t doesn't turn into ulong.
  - Javascript-based offline search.
 * Containers library backed by std.allocator
  - Less sitting around waiting for the GC

 Very nice. Thank you!
Indeed, very nice!

but where is the dub package?

Re: Perlin noise benchmark speed

[Robert Schadek via Digitalmars-d]

On 06/20/2014 02:34 PM, Nick Treleaven via Digitalmars-d wrote:
 On 20/06/2014 13:32, Nick Treleaven wrote:
 It apparently shows the 3 main D compilers producing slower code than
 Go, Rust, gcc, clang, Nimrod:

 Also, it does appear to be using the correct compiler flags (at least
 for dmd):
 https://github.com/nsf/pnoise/blob/master/compile.bash
I added some final pure @safe stuff

Re: Perlin noise benchmark speed

[Robert Schadek via Digitalmars-d]

On 06/20/2014 02:56 PM, David Nadlinger via Digitalmars-d wrote:
 On Friday, 20 June 2014 at 12:34:55 UTC, Nick Treleaven wrote:
 On 20/06/2014 13:32, Nick Treleaven wrote:
 It apparently shows the 3 main D compilers producing slower code than
 Go, Rust, gcc, clang, Nimrod:

 Also, it does appear to be using the correct compiler flags (at least
 for dmd):
 https://github.com/nsf/pnoise/blob/master/compile.bash

 -release is missing, although that probably isn't playing a big role
 here.

 Another minor issues is that Noise2DContext isn't final, making the
 calls to get virtual.

 This should cause such a big difference though. Hopefully somebody can
 investigate this more closely.

 David
I converted Noise2DContext into a struct, I gone add some more to my patch

Yet another CT ini file parser: inifiled

[Robert Schadek via Digitalmars-d-announce]

On my way back from DConf I was bored with in the in-flight
entertainment and start to hack.

The result is inifiled a compile time ini file reader and writer that
fills and stores a annotated struct.
It excepts typical ini files with sections, comments and to some extend
nesting and arrays. The only
unique characteristic is that the struct and struct member annotations
require comments. Config
options without descriptive comments just make me troll. So comments for
options are required.

dub: http://code.dlang.org/packages/inifiled
github: https://github.com/burner/inifiled



@INI(A Person) 
struct Person {
@INI(The lastname of the Person) string lastname;

@INI(The height of the Person) float height;

@INI(Some strings with a very long long INI description that is longer ~
 than eigthy lines hopefully.
) string[] someStrings;
}

void main() {
Person person;

readINIFile(p, filename.ini);

writeINIFile(p, filename.ini);
}

Re: D port of docopt

[Robert Schadek via Digitalmars-d-announce]

On 06/16/2014 11:11 PM, Dicebot via Digitalmars-d-announce wrote:
 On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote:
 Pretty cool idea. Are you aware of that in D you can, at compile
 time, parse the doc string and generate a command line parser for
 that particular documentation.

 I don't think it gives any advantage here :)

 docopt looks cool, though my I'd prefer something that works other way
 around - automatically generates argument parsing code and help
 messages from aggregate that represents configuration and/or CLI API
 (with help of few UDA).
+1 I could use reviews for this PR
https://github.com/D-Programming-Language/phobos/pull/2072

Re: AutoTester file limit

[Robert Schadek via Digitalmars-d]

On 06/13/2014 04:03 AM, Steven Schveighoffer via Digitalmars-d wrote:
 On Thu, 12 Jun 2014 21:22:25 -0400, Kapps opantm2+s...@gmail.com wrote:

 I could be wrong about this, but from what I remember this comes down
 to DMC's runtime library. The max number of open file descriptors
 with apis such as fopen is pretty low (about 70 from what I remember)

 It's 64.

 But I would hope std.socket doesn't use DMC file descriptors. Winsock
 doesn't use them.

 -Steve
thanks for the info.

AutoTester file limit

[Robert Schadek via Digitalmars-d]

Currently I have problems with my Logger PR. It magically fails from
time to time.
Whenever it fails std.socket fails with:

Open file hard limit too low

As far as I can see that is why my tests fail as well. Is this limit a
known problem? Suggestions?

Re: D Grammar in BNF Text Form?

[Robert Schadek via Digitalmars-d]

On 06/06/2014 12:29 PM, Tom Browder via Digitalmars-d wrote:
 Can anyone point me to a text version of the D grammar in some kind of
 BNF or EBNF format?  The D lang web site's info is close, but it's
 buried in html which I'ld rather not have to wrestle with.

 My purpose is to attempt to write a D language parser in Perl using
 Damian Conway's Regex::Grammars module (on CPAN).

 Thanks.

 Best regards,

 -Tom
The site says it creates recursive decent parser. D does not even fit
into lalr1. So it will not work, unless you can inject handwritten parse
function for the critical parts

Re: Building phobos documentation

[Robert Schadek via Digitalmars-d-learn]

On 06/06/2014 12:22 PM, Damian Day via Digitalmars-d-learn wrote:
 I'm having some trouble with building Phobos documentation locally on
 Win32.

 I've been referring to this guide:
 http://wiki.dlang.org/Building_DMD#Building_the_Docs

 I don't want to pull it from github and I don't really need the tools
 building either.
you need the tools, the docs are generated from the source with ddoc
which is part of dmd.

 My make command is: make -f win32.mak DMD=..\dmd\src\dmd\src html

 I keep getting error: don't know how to make '../dlang.org/std.ddoc'
maybe the slash need to be backslashed, because of windows

if you find a fix please add that to the wiki

DateTime custom string format

[Robert Schadek via Digitalmars-d-learn]

Is there a function in phobos that lets me do something like
DateTime.format(MM:DD: ) with a DateTime instance?

Re: DateTime custom string format

[Robert Schadek via Digitalmars-d-learn]

On 06/03/2014 07:12 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
 On Tue, 03 Jun 2014 17:07:02 +0200
 Robert Schadek via Digitalmars-d-learn
 digitalmars-d-learn@puremagic.com wrote:

 Is there a function in phobos that lets me do something like
 DateTime.format(MM:DD: ) with a DateTime instance?
 Not currently. It's on my todo list. I intend to get back to it after I've
 finished with splitting std.datetime (which I should get to fairly soon but
 have been doing some cleanup in std.datetime first), but I don't know when it
 will actually be ready. So, for now, you'd have to use std.string.format and
 the getters on DateTime.

 - Jonathan M Davis
Ok, I had people asking me for this because of my std.logger default
output format.

Do you accept PRs for that?

Re: DateTime custom string format

[Robert Schadek via Digitalmars-d-learn]

On 06/03/2014 08:22 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
 On Tue, 03 Jun 2014 19:39:14 +0200
 Robert Schadek via Digitalmars-d-learn
 digitalmars-d-learn@puremagic.com wrote:

 On 06/03/2014 07:12 PM, Jonathan M Davis via Digitalmars-d-learn
 wrote:
 On Tue, 03 Jun 2014 17:07:02 +0200
 Robert Schadek via Digitalmars-d-learn
 digitalmars-d-learn@puremagic.com wrote:

 Is there a function in phobos that lets me do something like
 DateTime.format(MM:DD: ) with a DateTime instance?
 Not currently. It's on my todo list. I intend to get back to it
 after I've finished with splitting std.datetime (which I should get
 to fairly soon but have been doing some cleanup in std.datetime
 first), but I don't know when it will actually be ready. So, for
 now, you'd have to use std.string.format and the getters on
 DateTime.

 - Jonathan M Davis
 Ok, I had people asking me for this because of my std.logger default
 output format.

 Do you accept PRs for that?
 Well, I would prefer to do it myself, but I obviously can't say that I
 wouldn't accept it if someone else did it and did a good job of it. The main
 problem however is that we need to come up with a good formatting scheme -
 that is the format of the custom time strings. What C has doesn't cut it, and
 what I proposed a while back turned out to be too complicated.  There's this
 3rd party library which had some interesting ideas:

 http://pr.stewartsplace.org.uk/d/sutil/doc/datetimeformat.html

 but I'm convinced that what's there is too simplistic. I'll need to dig up my
 old proposal and look at how I can simplify it (possibly making it more like
 what's at that link) without removing too much power from it.

 Once I have the custom time format strings sorted out, I intend to create both
 functions which take the format string as a runtime argument and those which
 take them as compile-time arguments and their corresponding from functions
 as well (e.g. toCustomString and fromCustomString). We'll end up with
 functions for SysTime, DateTime, Date, and TimeOfDay (possibly by templatizing
 functions or creating specifically named functions for each of them). My
 intention is to put them in std.datetime.format once std.datetime has been
 split (and they've been implemented) rather than sticking them on the types
 directly.

 I'll probably also look at adding a way to get at the exact pieces of
 information you want efficiently without having to have flags for everything
 in the custom time format strings, making it easier to create strings that are
 more exotic but still do so without having to call all of the individual
 getters (which isn't necessarily efficient). But by doing something like that
 I should be able to simplify the custom time format strings somewhat and avoid
 some of the more complicated constructs that I had in my previous proposal.

 - Jonathan M Davis
I see. I like that format functionality. Maybe I can find some time on
the weekend

Re: 1st Call for Ideas for Google Summer of Code 2015

[Robert Schadek via Digitalmars-d]

On 05/30/2014 09:49 PM, Tobias Pankrath via Digitalmars-d wrote:
 I know this is very early, but I work slowly :o)

 * Something like boost::log
phobos PR #1500 https://github.com/D-Programming-Language/phobos/pull/1500
 * Something like boost::program_options
phobos PR #2072 https://github.com/D-Programming-Language/phobos/pull/2072
 * An parser generator on par with antlr4
 * std.stream replacement / buffers
 * std.xml
 * SSL implementation?

Re: The GC and performance, but not what you expect

[Robert Schadek via Digitalmars-d]

On 05/29/2014 12:41 PM, Jacob Carlborg via Digitalmars-d wrote:
 On 2014-05-29 12:09, Atila Neves wrote:

 The GC is preventing me from beating Java, but not because of
 collections. It's the locking it does to allocate instead! I
 don't know about the rest of you but I definitely didn't see that
 one coming.

 Doesn't the runtime know how many threads currently exist? If it's
 only one, could the GC avoid the locking?

properly, but collections is not atomar and you have to prevent threads
that are created during collection from collecting. so you still need to
lock

Re: Recommendation on option parsing

[Robert Schadek via Digitalmars-d-learn]

On 05/14/2014 06:15 AM, Jesse Phillips via Digitalmars-d-learn wrote:
 On Tuesday, 13 May 2014 at 17:05:15 UTC, Chris Piker wrote:
 I tried that, but you're using private members of std.getopt
 (which of course is okay for the way you intended the code
 to be used) so I stopped pursuing this solution.

 Not sure why he had you break up the file. It should be as simple as
 changing the line module std.getopt; to something simple like
 module getopt then importing import getopt; and include the new
 file within the build.
he is right, my bad

 Anyway, D's libraries are not as extensive as Python/Ruby/Perl.

Re: Recommendation on option parsing

[Robert Schadek via Digitalmars-d-learn]

On 05/13/2014 05:40 AM, Chris Piker via Digitalmars-d-learn wrote:
 On Monday, 12 May 2014 at 23:11:57 UTC, Robert Schadek via
 Digitalmars-d-learn wrote:

 Okay, I replaced the std.getopt that came with dmd with your
 version.  My code compiles, but of course it doesn't link
 against the old libphobos.so.  I'm a complete newbe to D and
 am not ready to build a new version of libphobos.so, that's
 for the library maintainers to do, which is not a job I'm ready
 to sign up for yet.  Right now I'm just trying to get my own
 project done, and so far D's standard library is being a HUGE
 impediment.  It's like programming against bare glibc all over
 again when I hoped it would be a little more like the Python
 standard libary.

 Just being a random developer my opinon isn't that important
 but, for what it's worth, I think an expanded option handling
 feature should be implemented in a separate module.  That way
 users can try it out without affecting their existing libphobos.

 I like your enthusiasm.  If you have any modules that don't
 require me to rebuild libphobos, I'll be happy to give them a
 whirl.  Thank's for responding to my inquiry.

 -- 
 Chris
Well, it is a pull request for std.getopt, therefore it can't stand
alone. That been said, get into getopt.d and copy anything below line
1061 ( the begin of the comment for GetoptExRslt) into a new file. Add
all imports from getopt.d + std.getopt and then add the new file to
you're build. This allows you to use getoptEx without modifying your
systems default libphobos.

Re: Recommendation on option parsing

[Robert Schadek via Digitalmars-d-learn]

On 05/12/2014 10:44 PM, Chris Piker via Digitalmars-d-learn wrote:
 On Saturday, 10 May 2014 at 11:59:03 UTC, Robert Schadek via
 Digitalmars-d-learn wrote:
 On 05/10/2014 01:09 AM, Chris Piker via Digitalmars-d-learn wrote:
 Phobos' std.getopt is a bit spare for my taste, as there is
 no builtin general help facility with word-wrapping.
 ...
 -- 
 Chris
 please help to make this happen
 https://github.com/D-Programming-Language/phobos/pull/2072

 I'm not sure what you are asking for.  Would you like me to tryout
 getoptEx?  If so, then sure I can do that, why not.  (Assuming I
 can
 figure out how to download your source file from github.)
yes please test it

Re: Recommendation on option parsing

[Robert Schadek via Digitalmars-d-learn]

On 05/10/2014 01:09 AM, Chris Piker via Digitalmars-d-learn wrote:
 Phobos' std.getopt is a bit spare for my taste, as there is
 no builtin general help facility with word-wrapping.

 Does anyone have a recommendation on which of the existing
 command line option parsing libraries floating around in the
 wild to use?  If it doesn't compile against the current
 version of phobos I'm willing to put in a little work, but
 since I'm very new to D I probably would not make the best
 design decisions.

 -- 
 Chris
please help to make this happen
https://github.com/D-Programming-Language/phobos/pull/2072

Re: [OT] DConf - How to survive without a car?

[Robert Schadek via Digitalmars-d]

On 05/07/2014 06:32 AM, Walter Bright via Digitalmars-d wrote:

 I had a car last year, and we stuffed it to the gills with people
 going between FB and Aloft. Will do so again this year.

I will have a car as well, but I'm staying on the other side of the bay.
I can take three people from FB to Aloft and back to anywhere between FB
and Main Street.

Re: SQLite3

[Robert Schadek via Digitalmars-d-learn]

On 05/07/2014 08:21 AM, Jack via Digitalmars-d-learn wrote:
 First off a Disclaimer: I'm a noob and still learning. Please
 don't bash me like some forums.

 Now to the questions: I'm searching for a quick and easy way to
 integrate SQLite3 in my application. I came across the
 etc.c.sqlite3 and the DSQLite
 library(https://github.com/bioinfornatics/DSQLite).

 Thinking that the C bindings is more documented I tried learning
 that. Though I can't understand the arguements of the callback
 function.

 extern(C) int callback(
 void* NotUsedAtAll, // Null variable
 int argc, // What?
 char** results, // Results?
 char** columnNames //Column Names?

 ){

 for(int i = 0; iargc; i++){
  writeln(results);
  getchar();
 }

 I've been reading through many explanations about this and I
 understand why the callback is needed but I can't seem to
 understand how to really use the callback function. Can someone
 provide a brief explanation or just point me in the right
 direction?
maybe
http://forum.dlang.org/thread/mailman.44.1397577433.2763.digitalmars-d-annou...@puremagic.com
this is something for you

Re: Bountysource activity

[Robert Schadek]

On 03/13/2014 07:40 PM, Vladimir Panteleev wrote:
 Looks like most of these are on compiler bugs.

 The only Phobos one is the std.getopt one, however its situation is
 two abandoned patches and no clear goal as to what constitutes a
 change worthy of marking the issue as fixed and paying out the bounty.
I made another PR for that one.

Re: sqlite-statement CTFE Generation (UniformAccess) / Benchmark

[Robert Schadek]

On 04/16/2014 01:55 PM, justme wrote:

 You may be on to something here.
Maybe I should create a wanted feature list and get started. Any feature
you would like to see?

sqlite-statement CTFE Generation (UniformAccess) / Benchmark

[Robert Schadek]

Lately I had to write some sqlite3 code in D. And I really hated writing
it. So I wrote me some CTFE generator for it. It uses all the fun UDA,
CTFE string mixin template magic, we all love. The generated code is as
fast as the hand written one. I wrote some of it down.
http://rburners.tumblr.com/ The article also holds a link to the
source/benchmark. Maybe this is to some interest to other people as well.

Best Regards
Robert

p.s. PRs and corrections welcome

Re: sqlite-statement CTFE Generation (UniformAccess) / Benchmark

[Robert Schadek]

On 04/15/2014 07:05 PM, Dicebot wrote:
 Some quick observations:

 1) toStringz(insertStmt) - as inserStmt is actually a string literal,
 no need to use toStringz, literals are alway null-terminated.
did not know that. Thanks

 2) in block immediately after `throw` has extra level of indentation
will check

 3) excessive sqlite3_finalize(stmt), one from first scope(exit) should
 have been enough
will check

 Will read actual article a bit later :P

Re: DIP58: .. as a Binary Operator

[Robert Schadek]

replace .. with : to make lexing easier, please

Re: DIP58: .. as a Binary Operator

[Robert Schadek]

On 03/17/2014 11:24 PM, H. S. Teoh wrote:
 On Mon, Mar 17, 2014 at 11:16:12PM +0100, Robert Schadek wrote:
 replace .. with : to make lexing easier, please
   auto b = arr[(someCondition) ? w:x : y:z];

 :-(


 T

Thats a parsing problem.

1..1 makes you think you got a prefix of a float 1. but actually you got
an int slice_operator int. If there where no .. flex like generator
could handle D, at least as far as I can see it.

Re: DIP58: .. as a Binary Operator

[Robert Schadek]

On 03/17/2014 11:43 PM, Timon Gehr wrote:
 No, it does not. The lexer does not need to change.
you're right, but at some distant  future I would like .. to be replaced
by :

GladeD - Gtk Glade Files to GtkD classes

[Robert Schadek]

Writing gui's by hand is not that much fun. Using glade files is also
not so entertaining. GladeD creates class, out of glade files, you can
inherited and implement.

Glade is just a very small tool, I thought other people might find hand.

Check: https://github.com/burner/gladeD

Re: GladeD - Gtk Glade Files to GtkD classes

[Robert Schadek]

On 03/13/2014 11:26 PM, captaindet wrote:
 very neat!

 the test worked under windows as well. just a few tweaks were
 necessary cause i did not want to move yr logger into std, ... yet.
well, a boy must have dreams ;-) I didn't expect it to run under win,
but hey, nice to hear

 i have been working on the same matter recently as well, from quite a
 different angle though. requires a bit more polishing and testing
 before i can show it. i am a little bit less motivated now that there
 is a viable solution to the glade awkwardness ;)
or you can fix up a pull request and we can work together ...

Re: dlang.sexy

[Robert Schadek]

On 03/12/2014 05:44 PM, Andrei Alexandrescu wrote:
 On 3/12/14, 4:08 AM, Iain Buclaw wrote:
 Andrei, I'm looking at you.

 Hope not in a sexy way :o). I'm not sure that's a good idea - those
 are adult domains.

 Andrei

bad publicity is better than none at least we're not as uptight as
go.sexy ;-)

Re: Major performance problem with std.array.front()

[Robert Schadek]

On 03/07/2014 12:56 PM, Vladimir Panteleev wrote:
 I'm glad I'm not the only one who feels this way. Implicit decoding
 must die.

 I strongly believe that implicit decoding of character points in
 std.range has been a mistake.

 - Algorithms such as countUntil will count code points. These
 numbers are useless for slicing, and can introduce hard-to-find bugs.
+1 see my pull requests for std.string:
https://github.com/D-Programming-Language/phobos/pull/1952
https://github.com/D-Programming-Language/phobos/pull/1977

Re: Top-3 for 2.066

[Robert Schadek]

this one is just annoying, at least to me

https://d.puremagic.com/issues/show_bug.cgi?id=648

std.copy (to multiple output ranges),

[Robert Schadek]

I'm searching the docs for something similar to:
copy(someInputRange, firstOutputRange, secondOutputRange, );
I know how to write it by hand, but I'm suspecting that something like
this is already in phobos.

And secondly, is there some function that gives me a forward range to
some input range?

Re: phobos dependencies

[Robert Schadek]

On 12/21/2013 10:43 PM, Andrej Mitrovic wrote:
 The compiler matches the missing symbol with the selective import
 writeln, so it knows it only has to load std.stdio, *but not*
 std.algorithm.

 Test-case 3:
 -
 import std.stdio : writeln;
 import std.algorithm : map;
 import std.range;  // might be here (compiler doesn't know)
 import std.container;  // or here

 void main()
 {
 foo.front;
 }
 -

 The compiler tries to find a selective import front, but it doesn't
 find it. What's important here is that it still does not have to load
 std.stdio or std.algorithm, as we're explicitly loading only a set of
 symbols which were never referenced from the test.d module.

 So the next step here is for the compiler to try and load each module
 in sequence (probably via the declaration order, first std.container),
 and if there's a match the compiler would stop loading other modules
 (no need to load std.container if std.range has front).
There is a flaw in that design. What if std.range and std.container both
have a matching .front? If you stop after the first you'll not find that
conflict. If you search both you'll not have any speed gain.

Re: D Programmer Jobs at Sociomantic Labs

[Robert Schadek]

On 12/04/2013 09:24 PM, Andrej Mitrovic wrote:
 On 11/1/13, Marenz mathias.baum...@sociomantic.com wrote:
 we at Sociomantic Labs are once again (or still) looking for
 D-Developers in Berlin.
 Does that imply only people living near to Berlin should apply? If
 not, what does Sociomantic offer for people living abroad, e.g.
 perhaps some kind of rent financing?
properly not, as long as our a citizen of the European Union working in
Berlin/Germany is easy, just move there. any other country, I'm not sure.

Re: Early review of std.logger

[Robert Schadek]

On 11/06/2013 02:21 PM, Dicebot wrote:

I see

Re: Early review of std.logger

[Robert Schadek]

On 11/04/2013 06:27 PM, Dicebot wrote:
 On Monday, 4 November 2013 at 17:08:21 UTC, Robert Schadek wrote:
 4.

 Static namespace classes are redundant and should be replaced with
 module-scope globals.
 not sure either

 My concern here is that if we need explicit additional symbol
 qualification to avoid collisions, D module system has failed. But I
 believe it actually works just fine, the problem is in habit of using
 imports in a way similar to C++ includes. Phobos should do more about
 endorsing power usage of D modules, not resort to demands of
 unad(a/o)pted ones :)
Can you give an example, I'm not sure if I know what you mean.

Re: D Programmer Jobs at Sociomantic Labs

[Robert Schadek]

On 11/05/2013 11:56 AM, t-dog wrote:

+1

Re: D parsing

[Robert Schadek]

On 11/04/2013 06:48 AM, Philippe Sigaud wrote:
 On Sun, Nov 3, 2013 at 7:08 PM, Timothee Cour
 thelastmamm...@gmail.com mailto:thelastmamm...@gmail.com wrote:


 On Sun, Nov 3, 2013 at 1:13 AM, Philippe Sigaud
 philippe.sig...@gmail.com mailto:philippe.sig...@gmail.comwrote:


 My current plan is to write different engines, and letting
 either the user select them at compile-time, or to have the
 parser decide which one to use, depending on the grammar. I'm
 pretty sure the 'Type 3' parts of a grammar (regular
 expressions) could be bone by using std.regex, for example.


 even lexing can't be done with regex, eg nesting comments : /+ ... +/
 Also, although it may seem cleaner at first to combine lexing and
 parsing in 1 big grammar (as done in pegged), it usually is faster
 do feed a (separate) lexer output into parser. 


 Lexing, yes. I was imprecise: even in a context-free grammar, some
 rules are regular and could use std.regex (the ct part) as the
 underlying engine, just for that rule.
Lexing can not be done with regex. Think myArray[1. ] ! What is next a
dot or a number.

Re: D parsing

[Robert Schadek]

On 11/04/2013 06:52 AM, Philippe Sigaud wrote:

 On Mon, Nov 4, 2013 at 1:55 AM, Timothee Cour
 thelastmamm...@gmail.com mailto:thelastmamm...@gmail.com wrote:


 I guess I'll have to write a CT-compatible LALR(1) engine...
  
 D does not fit into LALR(1), you need glr.


 Well, too bad. GLR is also on my plate, but I fear its cubic behavior
 (IIRC, it degrades gracefully, though).
Thats one part, and even worse is that you need a decider function if
more than one rule accepts.
 Do you know what part of the D grammar makes it non-LALR(1)?
I had big trouble with the IdentifierList rules.

Re: Early review of std.logger

[Robert Schadek]

On 11/04/2013 02:46 PM, Dicebot wrote:
 On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
 As `std.logger` is still marked as work in progress this thread is
 less formal that typical pre-voting review. Goal is to provide as
 much input about desirable `std.logger` functionality and current
 state and let module author to use this information for preparing
 proposal for actual review / voting.

 Lets unleash the forces of constructive destruction.

 = Meta =

 Code: https://github.com/D-Programming-Language/phobos/pull/1500/files
 Docs: http://burner.github.io/phobos/phobos-prerelease/std_logger.html

 First announcement / discussion thread :
 http://forum.dlang.org/post/mailman.313.1377180809.1719.digitalmar...@puremagic.com

 Ok, finally making some conclusions.

 ===
 As a review manager
 ===

 This what needs to be done before moving to next review stage:

 1.

 Judging by review comments it is clear that some more efforts need to
 be put into demonstrating how existing platform can be used as a
 standard API for more complex logging functionality. Addition of
 `MultiLogger` is good thing here, but providing either separate
 article on topic or extra module that demonstrates enhancing existing
 system feels like a good way to avoid confusion.

 That said, I do agree that std.logger itself should not be all
 batteries included module as it does contradict overall Phobos style.
 It may be extended in future once we start using sub-packages much
 more but right now having good standard API is much more important.
I looked at journalctl, it looks promising any small enough to fit in
the docu as an example.

 2.

 Standard logger must be made thread-safe by default. Out of the box
 safety is very important for standard library.

on my todo list: My first idea is to make the global logger shared and
StdIoLogger and FileLogger synchronized in the right places.
 3.

 Making default `log` a conditional logger does not seem to be gladly
 accepted decision. I'd recommend to swap it with `logf` and rename to
 `logIf`.
I don't see the fuss. the bool in front is just a transparent. But If
people really want to write the 2 extra chars, be my guest.

 Naming overall should be reviewed to make sure there is no word
 duplication in typical usage pattern - Phobos does favor plain
 procedural/functional approach as default and D module system makes it
 unnecessary to encode namespaces into names.

 
 Personal preferences
 

 It is a matter of personal taste but any single thing in that list
 will make me vote No on logger proposal:

 1.

 API it too verbose.
 I want stuff as short and simple as this:
 ```
 import std.logger;
 warn(1);
 inform(2);
 die(3);
 ```
 I don't want to refer logger class instances explicitly for any
 typical task.

 Stuff like `auto logger = new MultiLogger();
 logger.insertLogger(someOtherLogger);` is redundant beyond absurd -
 just how many times one may insert word logger in a single sentence? :)

no and yes, the warn inform, maybe.
The MultiLogger part ... it needs a better constructor. Put it on my
todo list
 2.

 Logging payload needs to include fully qualified module name. This is
 necessary for enabling module-local output.
Easy fix, put it on my todo list.

 3.

 I am not sure if proper global vs local log separation can be done
 without providing two distinct default instances in std.logger (as I
 have already said, I don't consider solutions which imply tracking
 class instance manually).
I'm not sure as well

 4.

 Static namespace classes are redundant and should be replaced with
 module-scope globals.
not sure either


Thank you for taking effort to work on this soon to be review.
Robert

Re: D parsing

[Robert Schadek]

On 11/03/2013 09:13 AM, Philippe Sigaud wrote:

 Oh, for D it works (it's even the biggest grammar I know), but it's
 too slow to be of practical interest. But that just means the
 generated parser is not top-notch, which is reasonable: I'm not a
 parsing pro, just a guy doing this during his free time :)

  

 Other promising options are using lemon, a LALR(1) parser generator.


 My current plan is to write different engines, and letting either the
 user select them at compile-time, or to have the parser decide which
 one to use, depending on the grammar. I'm pretty sure the 'Type 3'
 parts of a grammar (regular expressions) could be bone by using
 std.regex, for example.

 I guess I'll have to write a CT-compatible LALR(1) engine...
  
D does not fit into LALR(1), you need glr.

Another idea would be to make the engine a template argument, and than
combine multiple parser!(engines). And even allow hand written stuff.
This way you could use ll(1) for the ll(1) parts and the crazy hand
written black magic for the hard parts.

Re: review queue: next?

[Robert Schadek]

On 10/29/2013 11:02 AM, Dicebot wrote:
 On Tuesday, 29 October 2013 at 07:30:41 UTC, ilya-stromberg wrote:
 It looks like we finished std.logger review.
 Is it time to make some conclusion?

 Sorry, having lot of distraction lately. I am hoping to make a summary
 for std.logger and proceed with the queue within a week or two.
Sounds good, as I need at least one evening to finish the doc for
multilogger.

Re: Early review of std.logger

[Robert Schadek]

On 10/21/2013 06:19 AM, SomeDude wrote:
 On Tuesday, 15 October 2013 at 08:47:00 UTC, Robert Schadek wrote:
 On 10/15/2013 09:32 AM, Sönke Ludwig wrote:
 Am 15.10.2013 09:08, schrieb Jacob Carlborg:
 On 2013-10-14 23:22, Dicebot wrote:

 If we need to care about that, D module system is a failure.
 But I don't think it is a valid concern.

 People already complain about conflict function names in Phobos.


 And I'd agree with them. At least inside of a library, care IMO should
 be taken to minimize overlap (of course functionally equivalent ones
 in different overload sets are fine, though). But in case of logXXX
 this seems to be very unlikely, much in contrast to log
 (std.math.log).
 yes and no. Of course does logXXX create less conflict, but I like to
 simply write log and don't care about the LogLevel. So again pros and
 cons

 I for once have never seen any log API with
 log.level = INFO;
 Logger.log(Here be dragons);

 And this I believe for a good reason: in 99% of production code I've
 seen, several log levels are mixed, i.e INFO, CRITICAL and DEBUG for
 instance, so the case where a single log level is used, even in the
 same method, just never happens. The proposed solution looks extremely
 inconvenient to me as it will almost always necessit two lines of code
 instead of one.
How good than, that you can pass the LogLevel as first argument to the
log function.

 I am with Sönke on this one, as well as the need for multi logger
 output. That's the absolute minimum requirement. If this doesn't
 exist, what will happen is, someone will make something better.
I added a MultiLogger five days ago...

Re: Early review of std.logger

[Robert Schadek]

On 10/21/2013 08:27 AM, SomeDude wrote:

 In practive, you really want a powerful logging facility.
 Another feature I used once in a project, was to log to RAM. We
 decided to log TRACE logs in production in order to catch a rare bug,
 but of course, it would output too many logs. So we decided to log
 everything in RAM and keep the last 1000 logs. Whenever there would be
 an exception or a CRITICAL log, the whole 1000 logs would be dumped on
 disk. That feature proved very useful. 
That was a feature you added or was it part of the logging library?

Re: Early review of std.logger

[Robert Schadek]

On 10/21/2013 10:19 PM, Dejan Lekic wrote:
 On Mon, 14 Oct 2013 13:39:51 +0200, Dicebot wrote:

 As `std.logger` is still marked as work in progress this thread is
 less formal that typical pre-voting review. Goal is to provide as much
 input about desirable `std.logger` functionality and current state and
 let module author to use this information for preparing proposal for
 actual review / voting.

 Lets unleash the forces of constructive destruction.

 = Meta =

 Code:
 https://github.com/D-Programming-Language/phobos/pull/1500/files Docs:
 http://burner.github.io/phobos/phobos-prerelease/std_logger.html

 First announcement / discussion thread :
 http://forum.dlang.org/post/mailman.313.1377180809.1719.digitalmars-
 d...@puremagic.com

 std.logger is a good start, but I must admit I do not like the way it is 
 architectured. I use Java's Logging and Log4J for years so naturally I 
 compare std.logger with these two frameworks (that are heavily used in 
 production).
unfamiliar or bad (details please).

Re: Early review of std.logger

[Robert Schadek]

On 10/20/2013 08:52 AM, ilya-stromberg wrote:
 Also, Tango have log module:
 https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/util/log/Log.d
I looked through the source and IMO the tango logger is my logger + (
configuration and more default logger) or the other way round. And this
thread had that discussion.

Re: Early review of std.logger

[Robert Schadek]

On 10/18/2013 02:55 PM, Dicebot wrote:
 Can you please re-generate the documentation after all recent updates?
I usually do that. The only documentation missing is for MultiLogger, as
I'm not sure if the current implementation is done.

Re: Early review of std.logger

[Robert Schadek]

On 10/18/2013 03:49 PM, Dicebot wrote:
 On Friday, 18 October 2013 at 13:35:19 UTC, Robert Schadek wrote:
 On 10/18/2013 02:55 PM, Dicebot wrote:
 Can you please re-generate the documentation after all recent updates?
 I usually do that. The only documentation missing is for MultiLogger, as
 I'm not sure if the current implementation is done.

 Hm. I don't see anything related to Logger names there. It is supposed
 to be part of MultiLogger?

 As discussion was slowly fading I wanted to make some sort of summary
 for this thread judging by personal observations - having quick
 overview of current state in form of docs will be helpful.
I rebuild the docs and pushed them. MultiLogger docu is just a stub.

Re: Early review of std.logger

[Robert Schadek]

On 10/17/2013 09:34 AM, qznc wrote:
 On Thursday, 17 October 2013 at 02:13:12 UTC, Eric Anderton wrote:
 The strength of this is that it would allow us to freely integrate D
 libraries that use std.logger, yet filter their log output from
 *outside* the library through the std.logger API.

 This is one of the most important aspects in my opinion.
 Std.logger should be easy to use, so library writers are
 encouraged to use it. Compare this with the unittest keyword,
 which makes it easy to write some simple tests. Of course,
 flexibility to use complex machinery for using the messages/tests
 is necessary. Just like we can hook up more advanced unit testing
 frameworks, we should be able to hook up more advanced logging
 machinery. The advanced stuff is not for Phobos though. Advanced
 stuff for unittests is for example, parallel execution and
 graphical reports. Advanced stuff for logging is for example log
 rotation and networking.
+1