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: 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: 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: 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?

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: 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

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 ...