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.

Re: DConf Online 2020 Videos Re-edited

[Robert burner Schadek via Digitalmars-d-announce]

properly -> probably

Re: DConf Online 2020 Videos Re-edited

[Robert burner Schadek via Digitalmars-d-announce]

Awesome, properly tedious, work.

Thank you

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: Computing the next SemVer for dlang packages with dsemver

[Robert burner Schadek via Digitalmars-d-announce]

On Wednesday, 21 October 2020 at 17:58:53 UTC, Sönke Ludwig wrote:
The thing is just that I don't think it is possible to find a 
set of rules that always work. There will always be something 
that should "obviously" be flagged as a breaking change and 
something that is extremely annoying to be detected as such 
(forcing a major version increment).


True, but if we can get 90% of the way there by a tool we would be
a lot better of then where we are today.
You should always be able to increment the SemVer by hand.



But as some kind of warning/hint and with some kind of 
integration into the version tagging process (maybe forcing a 
manual version release on the registry after warnings come up) 
it could definitely be really nice.


I'm thinking of a service that gives you a batch that shows you 
next SemVer

of the master branch, as a start.

Re: Computing the next SemVer for dlang packages with dsemver

[Robert burner Schadek via Digitalmars-d-announce]

On Wednesday, 21 October 2020 at 17:55:00 UTC, Sönke Ludwig wrote:

0.x.y vs. 1+.x.y is about the development process/state. Quite 
often a design is not yet fully fleshed out in the beginning 
and there are many incremental changes to the API. If 0.x.y 
didn't exist, that would simply mean that either the project 
gets more or less stuck with the initial (bad) design, or that 
it quickly increments major versions, effectively providing no 
more stability as in the 0.x.y case.


I think that is the one mistake SemVer does. 0.x.y is just one 
big loophole.
After the 1.x.y release an breaking api change requires a major 
version increment.
The way it should be. Stability or unstable is only mentioned in 
the 0.x.y

definitions.

You are not stuck on a bad design, break the api, improve the 
api, increment the major version number.
If you break the api in an 0.x.y version the hard part does not 
change.

In both instances the users have to update their usage.

In know in theory 0.x.y should be considered unstable. But by 
amount of 0.x.y we have you pretty much can't get anything done 
in D if you only use stable packages.

The loophole has become the normal case.

So what can we do, I see two major options:
1. we can live on the edge and use unstable packages and have no 
meaning in the

   SemVer number
2. we can acknowledge that most of them are stable, put a 1. in 
front and ignore
   the 0.x.y part of the SemVer definition and have the SemVer 
mean something


dsemver does 2.

And true there might be cases where dsemver does not increment 
the number correctly, but you can always increment by hand.


Also if your api is not stable after your 1.x.y release and you 
break everything in 2.x.y, so what. Your users are also annoyed 
when you break your api from 0.1.x to 0.1.1. Only difference is 
they could have seen in coming by looking at the SemVer.


I should stop ranting now.

Re: Computing the next SemVer for dlang packages with dsemver

[Robert burner Schadek via Digitalmars-d-announce]

On Wednesday, 21 October 2020 at 15:27:46 UTC, Sönke Ludwig wrote:

To really get it correct properly most of dmd is needed anyway.
But this might a good first step to get out under the 0.x.x rug 
we are currently in
and a lot closer to actual meaning in the semver of a lib on 
code.dlang.org

Re: Computing the next SemVer for dlang packages with dsemver

[Robert burner Schadek via Digitalmars-d-announce]

On Wednesday, 21 October 2020 at 15:27:46 UTC, Sönke Ludwig wrote:

However, I definitely don't see this as a potential feature of 
the registry in the sense that it automatically creates new 
versions for all packages.


That is why I said in an ideal world and baby steps.

Also, dsemver does not call git yet to create the new tag.

Computing the next SemVer for dlang packages with dsemver

[Robert burner Schadek via Digitalmars-d-announce]

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

is a program that computes the next SemVer for your dlang package.

It uses a slightly modified SemVer definition.

It does this by using the -X flag for dmd to get a json file of 
the symbols
and then compares them to the most recent git tag that resembles 
a SemVer.


First release is 1.0.0.
If a symbol is removed or its signature changed the major version 
is increment

and the minor and the bugfix number reset to 0.
If a new symbol is added, the minor number is incremented and the 
bug fix

number is set to 0.
If all symbol stay the same the bugfix number is incremented.

In an ideal world the dub registry would use this to compute the 
SemVer for you,

but baby steps.

I hope to see many bug reports and PRs.

Re: The ABC's of Templates in D

[Robert M. Münch via Digitalmars-d-announce]

A bit late... but I don't understand this part:

"Unlike x, p is not a member of the template. The type Pair is a 
member, so we can’t refer to it without the prefix."


* Why is it not a member of the template (specification)?
* Later it is a member... of what if not of the template (specification)?

Confusing...

--

Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Visual D 1.0.0 released

[Robert M. Münch via Digitalmars-d-announce]

On 2020-07-04 13:00:16 +, Rainer Schuetze said:


after having passed the 10 year anniversary of public availability
recently, it is finally time to release version 1.0 of Visual D, the
Visual Studio extension that adds D language support to VS 2008-2019.


Even I don't use an IDE, the debugger support alone is so valuable that 
I can't imagine wokring without it... Great job!


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2020-06-23 04:29:48 +, Виталий Фадеев said:


Width of the element can be set:
- by hand
--- fixed
- by automate
--- inherited from parent
--- from childs ( calculated max width )
--- generated by parent layout ( like a HBox, VBox, may be CircleLayout... )

and for each case:
- check min width
- check max width

https://drive.google.com/file/d/1ZbeSkQD2BY06JB1R17CT17te1H9ecRnI/view?usp=sharing 



Not sure if this is a question or some project you do. However, yes on 
all points for what we do.



and childs can be aligned in container cell to: left. center, right, stretched.

https://drive.google.com/file/d/1Xm4m7DLaUoPu5wzvPSalgW3i1-WkTeek/view?usp=sharing 



Yes.


I love beauty UI too. :)


Well, beauty lies in the eye of the beholder.


I love fast perfect UI too.


:-)


And I do D Windows GUI too.  :)


Cool... so, anything to see?


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2020-06-22 23:56:47 +, aberba said:


Will it be open source? Curious why its not hosted public


We will see...

The main point is, such a thing only lifts off if the quality and 
out-of-the-box experience is high enough. I think we don't need an 
other project, that might not get any tracktion.


And, if things have a good quality and are used, a project needs a bit 
of management. This bit can become quite intensive, especially in the 
beginning until enough know-how is build-up by others. And, this 
requires that others are picking it up, which needs a good quality... 
and the circle closes.


Reality tells us, that most OS projects don't take off. Small libs, 
with a narrow scope are a totally different story than a GUI framework.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-19 21:01:33 +, Robert M. Münch said:

Hi, we are currently build up our new technology stack and for this 
create a 2D GUI framework.


Some now teaser, again might not look like a lot had happend but we 
move forward, slow but steady:


https://www.dropbox.com/s/jjefzyneqnxr7pb/dgui_teaser-1.mp4

The framework can now handle 9-patch images for decoration of any widget parts.

And here an older one I think I never posted, about text editing:

https://www.dropbox.com/s/cfqy21q4s7d0zxr/Bildschirmaufnahme%202020-04-07%20um%2017.08.24.mov?dl=0 



Cut & Paste, marking, cursor movement etc. is all working correctly. 
All text stuff (rendering and handling) is done in Unicode.


What we first get to work is a way to create simple applications with 
input-forms, text-lists feed from a database and single line 
text-editing.



--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!

[Robert M. Münch via Digitalmars-d-announce]

On 2020-06-15 13:01:02 +, Timon Gehr said:


The talk will be on YouTube.


Great.


Papers:
https://www.sri.inf.ethz.ch/publications/bichsel2020silq
https://www.sri.inf.ethz.ch/publications/gehr2020lpsi

Source code:
https://github.com/eth-sri/silq
https://github.com/eth-sri/psi/tree/new-types


Thanks, somehow missed these.

What's the main difference of your approach WRT something like this: 
http://pyro.ai/


BTW: I'm located in Zug... so not far away from you guys.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!

[Robert M. Münch via Digitalmars-d-announce]

On 2020-06-14 20:22:41 +, Timon Gehr said:

https://pldi20.sigplan.org/details/pldi-2020-papers/46/-PSI-Exact-Inference-for-Higher-Order-Probabilistic-Programs 



This one sounds pretty interesting. Will there be a recording and a 
published paper be available?


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Rationale for accepting DIP 1028 as is

[Robert M. Münch via Digitalmars-d-announce]

On 2020-05-27 06:59:28 +, Bruce Carneal said:

Walter has confirmed that this is indeed the case.  As you can read a 
few posts up his response to my "What am I missing?" query was "Nothing 
at all."


Yes, it's really that bad.


Will it be possible to see a report of these "greenwashed" call-chains, 
so that at least there is a chance to detect them?


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: $750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)

[Robert M. Münch via Digitalmars-d-announce]

On 2020-05-05 21:41:39 +, Dmitry Olshansky said:


Felt a bit like cheating. Russian traditions preclude taking money for things
you (think you) wanted to do anyway.


Well, that's a good habit and still IMO it's OK to offer and take an incentive.

I started on it, and it turned out a bit more then I hope for + I'm 
doing it on simple Windows workstation without much of my usual power 
tools. LDC for Windows works like a charm though.


It seems Unicode 13.0.0 pulled a plug on a couple of "derived" tables, 
that is data files that can be reconsturcted from other primary ones. 
Took at least half an hour to figure that out and rebuild the missing 
bits.


If you don't mind I'll go with 100$ per hour estimate which is 
basically my usual contract rate. It took me about 2 hours for now, and 
I think I'd be done in a one or two more.


Great and deal.

Merging this into Phobos though is the otehr 90% of the legwork, I hope 
somebody will help me with that and maybe we'll just split your 
generous bounty this way.


Sure. As said, I'm not totally sure how this code-merging process 
works, who can do it, who approves things (if at all) or if it's enough 
of the automated tests don't fail.


I mean I know what this table does by its usage but the codegen part is 
missing, likely a classic missing commit problem of being a single 
maintainer of the codegen tool (and the fact that it's not in the main 
dlang repos).


Got it.

Absolutely. I mean I'm in no shape to do the heavy lifting of day in 
day out maintanance of std.* stuff but I'd love to coach somebody to 
learn how std.regex and std.uni work. I can also share my vision for 
improvement, and will gladly help with refactoring.


With focus on std.uni I think what would help is a short description of 
the whole process. A context setting chapter "unicode pitfalls, 
important things to know, general process" and a "step-by-step" 
description/log of what needs to be done, what the step does and where 
it fits into the overall picture.


Just found out that std.regex is from you too... nice.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: $750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)

[Robert M. Münch via Digitalmars-d-announce]

On 2020-05-05 15:39:12 +, Dmitry Olshansky said:


On Monday, 4 May 2020 at 17:01:01 UTC, Robert M. Münch wrote:
Following my "Is it time for a Unicode update of std.uni?" post in D 
group, I would like to try out to sponsor this effort for "Issue 16416 
- Phobos std.uni out of date (should be updated to latest Unicode 
standard)" [1]


For me, this, too, is an experiment to find out if it's possible to 
move specific issues/topics forward. And maybe even find people that 
are open to contact work too. For me, all these things are pretty 
related.


So, not knowing how much work it is, nor knowing what a good amount 
would be, I took the other route and asked me, what is it worth for me 
to get it done? Note: Getting #16416 done is not critical for me; most 
likely, I could even live with the current state of std.uni. On the 
other hand, std.uni is a very fundamental building block, and having it 
up to date and maybe even extended should be much value to D.


So, I'm offering $750 to get it done.



I'm guess I'm not eligible for the bounty ;)


Why not?


Anyhow if anyone wants easy money - shoot me an email, or reply in this thread.


Well, as I wrote, since I don't have a real good understanding about 
the necessary effort I started from "what is it worth for me in $ to 
get it done?". So, if it's a simple script-change and a re-run and you 
are the only one knowing this and keeping it for yourself... yes, it's 
easy money.


On the other hand, if you can help someone to get started and it's a 
couple of hours, I would expect people to be fair enough and state: 
Hey, $400 (or whatever) is OK, let's take the rest to sponsor something 
else. That's what I would do.


Spoiler is - the whole thing is code generated and there is only one 
table that I forgot about (i.e. I have no idea what is the source table 
for it in Unicode standard).


With "forgot" you mean, you can't remember, or it's missing at all in 
your prior work?


P.S. I'm kind of back, but very busy and my health is mostly great 
despite the COVID outrage out there.


That's great to hear... and maybe std.uni support/coaching for someone 
stepping up is possible. That would be great too. If, maybe even I can 
try to do it...


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: $750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)

[Robert M. Münch via Digitalmars-d-announce]

On 2020-05-04 21:34:27 +, rikki cattermole said:


On 05/05/2020 7:26 AM, notna wrote:
Maybe you want to add an additional constraint... It would be great if 
this would result in a tool, scripts or at least a simple-to-follow 
to-do (say Wiki?!)... so best case we could use this also for the next 
updates / releases in the future?!


The reason we can't just grab a newer copy of the unicode database and 
throw it into Phobos is because the format was changed.


Sure, nevertheless, I think it makes sense to have the reproducibility 
of the process in mind. Maybe not with a script that lasts for 10 
years. But the process, some tools for a specific version, which can be 
used as inspiration for upcoming changes.


IMO it makes a lot of sense for D to keep up close with the unicode 
development.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: $750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)

[Robert M. Münch via Digitalmars-d-announce]

On 2020-05-04 21:14:49 +, welkam said:

If changes to phobos do not bring breaking changes then I dont see how 
update to std.uni might not be merged


Well, but that's a weak statement for an invest.

If unicode is developing in a way that results in breaking changes, 
what to do? Never update? Doesn't make sense...


So, breaking-changes because unicode requires these, have to be taken IMO.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: $750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)

[Robert M. Münch via Digitalmars-d-announce]

On 2020-05-04 17:30:41 +, Arine said:

I feel like this is going to be the biggest obstacle. I worked on a bug 
bounty in the past, made a pull request, and it just sat there for 
months. It's a waste of time to try and get anything merged. Especially 
on the scale that this would be at.


Thanks for the feedback. Was the PR eventually merged? Did you get any 
feedback why it wasn't merged, what needs to be done so that it gets 
merged, who decides this, etc.?


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

$750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)

[Robert M. Münch via Digitalmars-d-announce]

Following my "Is it time for a Unicode update of std.uni?" post in D 
group, I would like to try out to sponsor this effort for "Issue 16416 
- Phobos std.uni out of date (should be updated to latest Unicode 
standard)" [1]


For me, this, too, is an experiment to find out if it's possible to 
move specific issues/topics forward. And maybe even find people that 
are open to contact work too. For me, all these things are pretty 
related.


So, not knowing how much work it is, nor knowing what a good amount 
would be, I took the other route and asked me, what is it worth for me 
to get it done? Note: Getting #16416 done is not critical for me; most 
likely, I could even live with the current state of std.uni. On the 
other hand, std.uni is a very fundamental building block, and having it 
up to date and maybe even extended should be much value to D.


So, I'm offering $750 to get it done.

Besides getting the work done, there is one constraint: The work needs 
to get into Phobos. It doesn't make sense to have it sit around, 
because it's not being merged. I don't have any clue who is in charge, 
who decides this. Or if there need to be some conditions full-filled so 
that the result gets merged.


[1] https://issues.dlang.org/show_bug.cgi?id=16416

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: openmethods 1.3.0

[Robert M. Münch via Digitalmars-d-announce]

On 2020-04-19 13:13:55 +, Jean-Louis Leroy said:

You can read more about openmethods on githubL 
https://github.com/jll63/openmethods.d


This is very interesting stuff! Thanks a lot.

I just read your blog post [1] and wonder if it's still up-to-date or 
maybe an update would make sense?


This stuff sounds like a very fundamental concept/pattern and IMO would 
be a good member of Phobos.


[1] https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: A D port of utf8proc

[Robert M. Münch via Digitalmars-d-announce]

On 2020-04-11 23:36:17 +, Ferhat Kurtulmuş said:


I could not find a similar library working with -betterC, so I ported utf8proc.

https://github.com/aferust/utf8proc-d

Please test it, contribute it, and enjoy!


What does it provide more then std.utf and std.uni beside BetterC support?

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: NanoSVG port

[Robert M. Münch via Digitalmars-d-announce]

On 2020-04-10 17:23:28 +, Adam D. Ruppe said:


On Friday, 10 April 2020 at 17:18:05 UTC, Robert M. Münch wrote:

Repro [2] is gone... Does anyone has an idea where the code could be accessed?


I also maintain a copy of it:

https://github.com/adamdruppe/arsd/blob/master/svg.d

minimal dox http://dpldocs.info/experimental-docs/arsd.svg.html


Ah, good.

I'am/was confused because I don't understand how "NanoVega.SVG" fits 
into the picture. Is it a 2nd SVG parser? Is it using svg.d? Why have 
two?



but the very bottom of that link shows svg -> png with my libs easily.


Ok, I will take a look. Most likely I'm going to use a different 
rasterizer... thanks a lot so far!


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: NanoSVG port

[Robert M. Münch via Digitalmars-d-announce]

On 2016-07-09 11:06:34 +, ketmar said:

i also made NanoSVG[1] port[2]: simple SVG parser and rasterizer. it is 
using `malloc()` to allocate memory, but otherwise was rewritten to use 
`const(char)[]` input for svg, and do not use `sscanf()` from libc.


the port lives in NanoVG package, but it is actually completely independent.


[1] https://github.com/memononen/nanosvg
[2] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/nanovg/svg.d


Repro [2] is gone... Does anyone has an idea where the code could be 
accessed? Is Ketmar still active?


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: DIP 1027---String Interpolation---Format Assessment

[Robert M. Münch via Digitalmars-d-announce]

On 2020-02-24 09:51:16 +, Walter Bright said:

I talk it over with Atila after the review threads are done, then 
decide. Voting is a terrible way to do engineering design, for many 
reasons I can list if you like.


You don't need to, I'm not a fan of such a voting approach too. I just 
added a bunch of variants as I didn't know how the process works nor 
who is involved at what step.


Not totally. I was unable to convince people that printf format 
validation was an orthogonal feature. So I went ahead and implemented 
that to show it had nothing to do with the proposal:


https://github.com/dlang/dmd/pull/10812

It turned out kinda sweet, and found a huge number of latent bugs in 
our own code, proving we shoulda done that long ago :-) Bad printfs 
turned out to be much more common than I'd anticipated.


Proving by showing the results... Ok, looking forward how things develop.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: DIP 1027---String Interpolation---Format Assessment

[Robert M. Münch via Digitalmars-d-announce]

On 2020-02-24 10:02:26 +, Mike Parker said:


The DIP review process is outlined here:

https://github.com/dlang/DIPs

The final decision rests with the language maintainers. Now, that means 
Walter and Atila.


Thanks, and sorry for my ignorance... How about adding a note who the 
"language maintainers" are?


... If that proposal and its review manage to convince Walter and 
Atila, then the feature gets in.


Ok. I understand.

The DIP process is one way to approach that. It allows everyone to 
provide feedback and influence the drafting of the DIP. That requires 
convincing the DIP author to revise the DIP and ultimately convincing 
the language maintainers to accept it. It means there's a high barrier 
for acceptance, but in my own opinion that's how it should be.


I agree. My impression and point was (after following the topic loosly) 
that the DIP might be close to find a good solution and that it was 
suddenly withdrawn. But anyway...



--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: DIP 1027---String Interpolation---Format Assessment

[Robert M. Münch via Digitalmars-d-announce]

On 2020-02-23 16:22:46 +, Mike Parker said:

DIP 1027, "String Interpolation", has been rejected. The decision was 
primarily influenced by the lack of consensus over the implementation 
and the syntax demonstrated in the two review threads. As the DIP 
author, Walter also rejected the suggestion to go with an 
implementation that resolves to a library template. He sees that as 
equivalent to AST macros, a feature which he has previously rejected.


https://github.com/dlang/DIPs/blob/4be15bd40381667c0ab1c0aef360d0daa4b8c82c/DIPs/rejected/DIP1027.md 



Out of curiosity, how and who makes such a decision? Is there a voting? 
Is there a committee? Is there a structured pro/con overview and 
highlight of blocking-points that need to be resolved?


I mean, people spend a lot of time thinking, making suggestions, etc. 
and the end result is: we now have nothing. Which, IMO is the worst 
result for all.


As a community with highly skilled people I think there should be a way 
to come to a good solution, not only a good enough. If not, this 
doesn't shed light on D and the community...


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: dub 502 bad gateway

[Robert Schadek via Digitalmars-d-announce]

very nice, thank you

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-19 21:01:33 +, Robert M. Münch said:

Hi, we are currently build up our new technology stack and for this 
create a 2D GUI framework.


Hi, some more teaser showing a text-input field, with clipping, 
scrolling, etc.:


https://www.dropbox.com/s/wp3d0bohnd59pyp/Bildschirmaufnahme%202020-01-28%20um%2017.16.26.mov?dl=0 



We have text-lables, text-input and basic text-list now working. Slow 
but steady progress. The whole framework follows a free compisition 
idea. You can add a table to the slider-knob of a slider if you want 
and it will just work.


Style and decoration is totally seperate and currently not done at all. 
Hence, the ugly wireframe look.


This whole project is a side-project I currently do beside our normal 
product development work.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

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: Visual D 0.51.0 - semantic engine based on dmd frontend

[Robert M. Münch via Digitalmars-d-announce]

On 2020-01-18 14:22:41 +, Rainer Schuetze said:


I'm happy to announce the release of Visual D 0.51.0.


Great stuff! Especially the debugging support.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Article about D in the iX magazine

[Robert M. Münch via Digitalmars-d-announce]

On 2019-12-20 21:26:00 +, Andre Pany said:


In the new iX (1 Januar 2020) there is also a Leserbrief for the article;)


Even there are only few comments, every comment helps.

It's very hard to convince programmers to give something else a try and 
stay to it long enough to see the light. Most of the time, evangelizing 
is very frustrating. The better strategy from my experience is: Deliver 
a cool product and than tell everyone "we are 10 times more productive 
than our competitors while delivering a better product." You can be 
sure, everyone wants to know how you do it.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

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: Article about D in the iX magazine

[Robert burner Schadek via Digitalmars-d-announce]

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

Re: interfaces and contracts - new pattern

[Robert M. Münch via Digitalmars-d-announce]

On 2019-12-03 07:53:48 +, Ola Fosheim Grøstad said:


On Tuesday, 3 December 2019 at 02:57:13 UTC, Adam D. Ruppe wrote:

On Monday, 2 December 2019 at 22:31:08 UTC, Ola Fosheim Grøstad wrote:

Interesting, could be useful, but now you have to remember to add "in(false)".


Yeah, it is kinda tempting to propose a language change, where an 
override method does this by default if nothing else is specified. I 
think it would probably usually be the right thing to do, and then 
you'd opt into extending it all the way by doing `in(true)` instead.


Yes, I agree, if you forget to add a specification then it probably 
should have the same strictness as the superclass. That is what I would 
expect.


+1 having to add something explicit to get the superclass contract 
activated looks weired.


In large scale projects this will become a big problem as you can't 
assume that every developer knows about all the contracts of a 
superclass.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Proposal for porting D runtime to WebAssembly

[Robert M. Münch via Digitalmars-d-announce]

On 2019-11-23 09:51:13 +, Sebastiaan Koppe said:

This is my proposal for porting D runtime to WebAssembly. I would like 
to ask you to review it. You can find it here: 
https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d


Not sure if you are aware of this:

https://wasmtime.dev/

Maybe it helps or gives some inspiration.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

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

[Robert M. Münch via Digitalmars-d-announce]

On 2019-08-11 19:16:22 +, Tiberiu Lepadatu said:

... But I think that the question that should be asked is which one of 
those will be more impactful to the community? Which one will better 
serve the D future? I will try by Wednesday to prepare an application 
for both of them. But I can't wait to hear your opinions.


+1 Reactive Programming

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Symantec has been sold to Broadcom

[Robert M. Münch via Digitalmars-d-announce]

On 2019-08-08 23:46:38 +, Walter Bright said:

https://finance.yahoo.com/news/broadcom-buy-symantec-enterprise-division-201706500.html 



It's the end of an era. Symantec bought my company, Zortech, and now is 
bought in return. The D community, and myself personally, owe a debt of 
gratitude to Symantec.


Thank you, Symantec!


Walter, you might not remember, but we once met at an exhibiton in 
Wiesbaden (I think), Germany, where you were with Symantec for the C++ 
compiler and we had a short chat. And I once tested a bunch of C++ 
compilers for a German computer magazine... this all must be around 25 
years ago.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

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: Release D 2.087.0

[Robert M. Münch via Digitalmars-d-announce]

On 2019-07-04 10:11:18 +, Mike Franklin said:

I don't know what digger is doing, but from the error messages, it 
appears that the new files in `rt/array` can't be found.  I believe the 
build is trying to use a new compiler with an older or existing 
runtime.  You'll need both the latest compiler and the latest runtime 
together for them to work.


If you can identify a bug in the makefiles, or some other such problem 
preventing the build, let me know and I'll try to fix it right away.


So, the problem is, that digger somehow misses to copy over the new 
source to the install directory. It does for some parts (phobos, but 
I'm not sure if for every file necessary) but not for druntime files.


I just manually copied the files now.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Release D 2.087.0

[Robert M. Münch via Digitalmars-d-announce]

On 2019-07-04 08:11:26 +, Martin Nowak said:


Glad to announce D 2.087.0, ♥ to the 63 contributors.

This release comes with types matching single template alias parameters,
nested template methods/local template functions, multi-threaded GC
marking, and a phobos compiled with -preview=DIP1000.

http://dlang.org/download.html
http://dlang.org/changelog/2.087.0.html

-Martin


I just updated with Digger to the newest version and get:

...d-language\test> dub test -a=x86_64 -f
Failed to invoke the compiler C:\D\dmd2\windows\bin\dmd.exe to 
determine the build platform: predefs   DigitalMars Windows 
CRuntime_Microsoft CppRuntime_Microsoft LittleEndian D_Version2 all 
D_SIMD D_InlineAsm_X86_64 X86_64 Win64 D_LP64 assert D_ModuleInfo 
D_Exceptions D_TypeInfo D_HardFloat

binaryC:\D\dmd2\windows\bin\dmd.exe
version   v2.087.0

configC:\D\dmd2\windows\bin\sc.ini
DFLAGS-IC:\D\dmd2\windows\bin\..\..\src\phobos 
-IC:\D\dmd2\windows\bin\..\..\src\druntime\import -L/OPT:NOICF

parse dub_platform_probe_956c8798_90a5_4300_b011_2b9e6cc8ace5
importall dub_platform_probe
importobject
(C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d)
C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(42): Error: 
module `comparison` is in file 'rt\array\comparison.d' which cannot be 
read

import path[0] = C:\D\dmd2\windows\bin\..\..\src\phobos
import path[1] = C:\D\dmd2\windows\bin\..\..\src\druntime\import

Not sure what this is telling me. Related to the release?

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

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: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-28 07:22:06 +, Ola Fosheim Grøstad said:

Just be aware that implementing a multithreaded constraint solver is 
something that you will have to spend a lot of time on.


I am... and I didn't meant that we want use MT everywhere.

MT is a tool, and after measuring and understanding the problem, the 
decision for or against MT is made.



Rendering is easy to do in parallel.


Yep, and that's something that will be done with MT.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-28 15:54:14 +, Nick Sabalausky (Abscissa) said:

It's incredibly refreshing to hear a developer say that, instead of the 
usual, "As a *developer*, I'm the most important part and my time is 
most valuable. So, my users should just go buy faster hardware."


In the mid 90s I co-invented & designed reconfigurable CPU systems. Our 
goal these days was to do real-time ray-tracing. So, we even said: just 
wait, we are going to make a faster hardware first. ;-)


Anyway, you statement is unfortunatly very true. It's the same idotic 
thing happening in every company: "I make my life easy and do things 
quick & dirty" without understanding that down the processes there are 
hundred of points where this stuff is used, and everyone needs to 
figure out the pitfalls over and over again... that's what I call very 
efficient thinking.


The software we sell, would still fit on one floppy disk (if there are 
still people knowing what it is). And I'm always saying: "Every good 
software fits on one floppy-disk." Most people can't believe that this 
is still possible.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-27 20:56:15 +, Ola Fosheim Grøstad said:

If Robert is aiming for embedded and server rendering then he probably 
wants a simple structure with limited multi-threading.


We are considering MT. A GUI should never stuck, as a user I'm the most 
important part and my time is most valuable. So, an application should 
never ever slow me down.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-27 04:46:42 +, Nick Sabalausky (Abscissa) said:

Besides, from what Robert described, it sounds like he already has it 
decoupled and modular enough that performance *can* likely be improved 
later (probably by an order of magnitude) without too much disruption 
to it's core design. So, on that, believe it or not, it sounds like we 
already agree. ;)


That's the case. The 2D layer could be replaced. It's not yet perfectly 
isolated and minified, because we are still learning & experimenting to 
see how things fit together. Refactoring for isolation comes after this.



And @Robert: FWIW, I *am* definitely curious to see where this project goes.


We too :-)

Also: While it *looks* in the video like a simple grid being resized, 
you've commented that under-the-hood it's really more of a flexbox-like 
design.


Correct.

The grid is structured like this: root-> 1..X columns -> 1..Y cells per 
column and the only property given is to use the available vertical and 
horizontal space evenly.


This suggests that the computations you're doing are (or will be) 
capable of far more flexibility than what is apparent in the video.


Yes, the idea is that you get a responsive app GUI, which resizes in a 
smart way which fits your app layout. So, you have control over this. 
Getting browsers to do what you want can be pretty tedious. We want to 
avoid this.


I'm curious what sorts of CSS flex-like features are currently being 
accommodated for in the computations, and are projected in the 
(hopefully?) near future?


The stuff that one really needs, so no frills. We want to create a node 
structure with layout rules/hints per node and as a result you get a 
perfect responsive layout for your app.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-25 23:23:31 +, Ethan said:

Right. I'm done. This thread reeks of a "Year of Linux desktop" 
mentality and I will also likely never read it again just for my sanity.


That's your best statement so far. Greate move.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-24 23:35:18 +, Exil said:

Is the source available anywhere? Would be interesting to look through 
unless this is close source?


No, not yet. Way to early and because we can't support it in anyway.

I see that there is quite some interest in the topic, but I think we 
should get it to some usable point before releasing. Otherwise the 
noise level will be to high.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-24 10:12:10 +, Ola Fosheim Grøstad said:

I guess server rendering means that you can upgrade the software 
without touching the clients, so that you have a network protocol that 
transfers the graphics to a simple and cheap client-display. Like, for 
floor information in a building.


Even much simpler use-cases make sense, example: Render 3D previews of 
100.000 CAD models and keep them up to date when things change. You 
need some CLI tool to render it, but most likely you don't have OpenGL 
or a GPU on the server.


If running an app on a server and using an own front-end client instead 
of a browser these days makes sense, I'm not sure. However, all people 
have tremendous CPU power on their desks, which isn't used. So, I'm 
still favoring desktop apps, and a lot of users do it too. Be 
contrarian in this sector makes a lot of sense :-)


You are probably right. What I find particularly annoying about GPUs is 
that the OS vendors keep changing and deprecating the APIs. Like Apple 
is no longer supporting OpenGL, IIRC.


Yep, way too much hassles and possibilities to break things from 
external. Can become a support hell. Better to stay on your own as much 
as possible.



Sadly, GPU features provide a short path to (forced) obsoletion…


In the 2D realm I don't see so much gain using a GPU over using a CPU.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-23 17:27:09 +, Ola Fosheim Grøstad said:

Yeah, that leaves a lot of headroom to play with. Do you think there is 
a market for a x86 CPU software renderer though?


Well, the main market I see for a software renderer is the embedded 
market and server rendering. Making money with development tools, 
components or frameworks is most likely only possible in the B2B sector.


One needs to find a niche where companies are interested in: speed and 
ressource-efficency is definetely one.



Or do you plan on support CPUs where there is no GPU available?


Currently we don't use a GPU, it's only CPU based. I think CPU 
rendering has its merits and is underestimated a lot.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-23 20:22:28 +, Ola Fosheim Grøstad said:

STILL, I think Robert M. Münch is onto something good if he aims for 
accuracy and provides say a canvas that draws bezier curves to the spec 
(whether it is PDF or SVG). I think many niche application areas 
involve accuracy, like a CNC router program, or a logo cutter or 3D 
printing. So I think there is a market.


I'm not fully understand the discussion about accuracy WRT GUIs. Of 
course you need to draw things accurate. And my interjection WRT 35-FPS 
was just to give an idea about the possible achievable performance. I 
like desktop apps that are fast and small, nothing more.


If you can provide everything people need in one framework, then people 
might want to pay for it. If you just provide what everyone else 
sloppily does, then why bother (just use Gtk, Qt or electron instead). 
*shrug*


Exactly. Our goals is to create a GUI framework which you can use to 
make desktop apps without caring about the OS specifics (which doesn't 
mean we are limiting in a way that you can't care if you wish). For 
this we are creating a set of building-blocks that fit perfectly 
together following a radical KISS and minimal dependency strategy.


If you want, you should be able to maintain a desktop app using a 
specific version of the framework for 15+ years, without running into 
any limitations.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-23 19:29:26 +, Ola Fosheim Grøstad said:

When creating a user interface framework you should work with 
everything from sound editors, oscilloscopes, image editors, vector 
editors, CAD programs, spreadsheets etc. You cannot really assume much 
about anything. What you want is max flexibility.


That's exactly the right direction.

Most GUI frameworks fail at this, so you have to do all yourself if you 
want anything with descent quality, but that is not how it should be.


Yep, I can't agree more.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-23 07:28:49 +, Ola Fosheim Grøstad said:


On Thursday, 23 May 2019 at 06:07:53 UTC, Robert M. Münch wrote:

On 2019-05-22 17:01:39 +, Manu said:
I mean, there are video games that render a complete screen full of 
zillions of high-detail things every frame!


Show me a game that renders this with a CPU only approach into a memory 
buffer, no GPU allowed. Total different use-case.


I wrote a very flexible generic scanline prototype renderer in the 90s 
that rendered 1024x768 using 11 bits each for red and green and 10 for 
blue and hardcoded alpha blending. It provided interactive framerates 
on the lower end for a large number of circular objects covering the 
screen, but it took almost all the CPU.


When doing the real-time resizing in the screencast, the CPU usage is 
around 5% - 6%


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-23 09:28:59 +, kdevel said:

Awesome. Compared to the video you posted some days ago there is also 
almost no visible aliasing.


Thanks.


 Do you plan to create a web browser based on your framework?


No, I don't see any business model behind a web browser...

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-22 17:01:39 +, Manu said:

The worst case defines your application performance, and grids are 
pretty normal.


That's true, but responsive grids are pretty unusal.


You can make a UI run realtime ;)


I know, that's what we seek for.

I mean, there are video games that render a complete screen full of 
zillions of high-detail things every frame!


Show me a game that renders this with a CPU only approach into a memory 
buffer, no GPU allowed. Total different use-case.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-21 16:51:43 +, Manu said:


The screencast shows a responsive 40x40 grid. Layouting the grid takes
about 230ms, drawing it about 10ms.


O_o ... I feel like 230 *microseconds* feels about the right time, and
~100 microseconds for rendering.


I don't think that's fast enough :-)


So this gives us 36 FPS which is IMO pretty good for a desktop app target


Umm, no. I would expect 240fps is the modern MINIMUM for a desktop
app, you can easily make it that fast.


;-) Well, they key is to layout & render only changes. A responsive 
grid is an evil test-case as this requires a full cylce on every frame.



Incidentally, we have a multimedia library workgroup happening to
build out a flexible and as-un-opinionated-as-we-can gfx and gui
libraries which may serve a wider number of users than most existing
libraries,


Ah, ok. Sounds interesting...


perhaps you should join that effort, and leverage the perf
experts we have? There's a channel #graphics on the dlang discord.


I will have a look... need to get discord up & running. Too many chat 
channels these days...


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-21 16:07:33 +, Basile B. said:


What kind of layouting ? GTK-like ? DelphiVCL-like ? Flex-like ?


Flex-Box like.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-21 17:29:51 +, Ola Fosheim Grøstad said:


On Tuesday, 21 May 2019 at 14:04:29 UTC, Robert M. Münch wrote:
Here is a new screencast: 
https://www.dropbox.com/s/ywywr7dp5v8rfoz/Bildschirmaufnahme%202019-05-21%20um%2015.20.59.mov?dl=0 



That looks better :-)


:-) For a pixel perfect full responsive GUI I need to think about it a 
bit more. But that's not high priority at the moment.


Just make sure that you pick an architecture that allows you to use 
spatial datastructures later on!


The nice thing about the design is, that the necessary parts are 
totally indepdent. For example changing the spatial index to an other 
approach just needed 5 lines of code change in the framework. The 
places where the different parts meet, are kept to an absolut minimum 
and the interfaces are as thin as possible.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-21 15:57:20 +, Basile B. said:


openGL backend I presume ?


No, CPU rendering to memory-buffer.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-19 21:21:55 +, Ola Fosheim Grøstad said:


Interesting, is each cell a separate item then?

So assuming 3GHz cpu, we get 0.23*3e9/1600 = 431250 cycles per cell?

That's a lot of work.


Here is a new screencast: 
https://www.dropbox.com/s/ywywr7dp5v8rfoz/Bildschirmaufnahme%202019-05-21%20um%2015.20.59.mov?dl=0 



I optimized the whole thing a bit, so now a complete screen with 
layouting, hittesting, drawing takes about 28ms, that's 8x faster than 
before. Drawing is still around 10ms, layouting around 16ms, spatial 
index handling 2ms.


So this gives us 36 FPS which is IMO pretty good for a desktop app 
target. There might be some 2-3ms speed-up still possible but not worth 
the effort yet.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

On 2019-05-19 21:21:55 +, Ola Fosheim Grøstad said:


Interesting, is each cell a separate item then?


Yes, it's organized like this:

root => grid => 1..X columns ==(each colum)==> 1..Y cells

So assuming 3GHz cpu, we get 0.23*3e9/1600 = 431250 cycles per cell? 
That's a lot of work.


I must be fair, and add some other measurement in between. This 
includes managing a 2D spatial index for hit testing too, not only 
layouting.


 Are you using some kind of iterative physics based approach since you 
use hundreds of thousands of computations per cell?


It's like the browser's flex-box model.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

D GUI Framework (responsive grid teaser)

[Robert M. Münch via Digitalmars-d-announce]

Hi, we are currently build up our new technology stack and for this 
create a 2D GUI framework.


https://www.dropbox.com/s/iu988snx2lqockb/Bildschirmaufnahme%202019-05-19%20um%2022.32.46.mov?dl=0 



The screencast shows a responsive 40x40 grid. Layouting the grid takes 
about 230ms, drawing it about 10ms. The mouse clicks are handled via a 
reactive message stream and routed to all graphical objects that are 
hit using a spatial-index. The application code part is about 50 lines 
of code, the rest is handled by the framework.


With all this working now, we have all necessary building blocks 
working together.


Next steps are to create more widgets and add a visual style system. 
The widgets themself are style-free and wire-frame only for debugging 
purposes.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: DStep 1.0.0

[Robert M. Münch via Digitalmars-d-announce]

On 2019-04-22 11:02:24 +, Jacob Carlborg said:


... and support for one more platform has been added: Windows...


Are there are any functional differences between the platforms? Or can 
I just use the OSX version and use the generated .d files with the DMD 
Windows version too?


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

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

Re: DConf 2019 Schedule

[Robert M. Münch via Digitalmars-d-announce]

On 2019-03-17 22:43:28 +, Mike Parker said:

The schedule is now live! There are a few DConf veterans and a few new 
speakers. We're also holding an Annual General Meeting prior to the 
Hackathon (thanks to Nicholas Wilson for the proposal).


http://dconf.org/2019/schedule/index.html


Typo in Walter's abstract: ... "D supports a number of techniques for 
allocating meory." => memory


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: dlang tutorial just posted on Derek Banas's YouTube channel

[Robert M. Münch via Digitalmars-d-announce]

On 2019-03-06 01:44:45 +, Zaydek said:

tl;dr Derek Banas is a YouTuber that makes long-form programming 
tutorials. He has almost one million subscribers. He just posted a 
90-minute tutorial that covers D beginning to end. This could be great 
promotional for this community to share with people learning D!


This is much cooler than I thought and very accessible. Very cool.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

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/