Re: Breaking news: std.uni changes!
Awesome work, thank you
Re: text based file formats
replay -> reply
Re: text based file formats
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
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!
cool, keep up the good work.
Re: DConf 2022 in London?
Yes please, sign me up
Re: Error message formatter for range primitives
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
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
Awesome congratulations
Re: code-d 0.23.0
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
properly -> probably
Re: DConf Online 2020 Videos Re-edited
Awesome, properly tedious, work. Thank you
countries_currencies_languages the most boring package ever
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
Very cool
Re: Computing the next SemVer for dlang packages with dsemver
On Wednesday, 21 October 2020 at 17:58:53 UTC, Sönke Ludwig wrote: The thing is just that I don't think it is possible to find a set of rules that always work. There will always be something that should "obviously" be flagged as a breaking change and something that is extremely annoying to be detected as such (forcing a major version increment). True, but if we can get 90% of the way there by a tool we would be a lot better of then where we are today. You should always be able to increment the SemVer by hand. But as some kind of warning/hint and with some kind of integration into the version tagging process (maybe forcing a manual version release on the registry after warnings come up) it could definitely be really nice. I'm thinking of a service that gives you a batch that shows you next SemVer of the master branch, as a start.
Re: Computing the next SemVer for dlang packages with dsemver
On Wednesday, 21 October 2020 at 17:55:00 UTC, Sönke Ludwig wrote: 0.x.y vs. 1+.x.y is about the development process/state. Quite often a design is not yet fully fleshed out in the beginning and there are many incremental changes to the API. If 0.x.y didn't exist, that would simply mean that either the project gets more or less stuck with the initial (bad) design, or that it quickly increments major versions, effectively providing no more stability as in the 0.x.y case. I think that is the one mistake SemVer does. 0.x.y is just one big loophole. After the 1.x.y release an breaking api change requires a major version increment. The way it should be. Stability or unstable is only mentioned in the 0.x.y definitions. You are not stuck on a bad design, break the api, improve the api, increment the major version number. If you break the api in an 0.x.y version the hard part does not change. In both instances the users have to update their usage. In know in theory 0.x.y should be considered unstable. But by amount of 0.x.y we have you pretty much can't get anything done in D if you only use stable packages. The loophole has become the normal case. So what can we do, I see two major options: 1. we can live on the edge and use unstable packages and have no meaning in the SemVer number 2. we can acknowledge that most of them are stable, put a 1. in front and ignore the 0.x.y part of the SemVer definition and have the SemVer mean something dsemver does 2. And true there might be cases where dsemver does not increment the number correctly, but you can always increment by hand. Also if your api is not stable after your 1.x.y release and you break everything in 2.x.y, so what. Your users are also annoyed when you break your api from 0.1.x to 0.1.1. Only difference is they could have seen in coming by looking at the SemVer. I should stop ranting now.
Re: Computing the next SemVer for dlang packages with dsemver
On Wednesday, 21 October 2020 at 15:27:46 UTC, Sönke Ludwig wrote: To really get it correct properly most of dmd is needed anyway. But this might a good first step to get out under the 0.x.x rug we are currently in and a lot closer to actual meaning in the semver of a lib on code.dlang.org
Re: Computing the next SemVer for dlang packages with dsemver
On Wednesday, 21 October 2020 at 15:27:46 UTC, Sönke Ludwig wrote: However, I definitely don't see this as a potential feature of the registry in the sense that it automatically creates new versions for all packages. That is why I said in an ideal world and baby steps. Also, dsemver does not call git yet to create the new tag.
Computing the next SemVer for dlang packages with dsemver
https://code.dlang.org/packages/dsemver is a program that computes the next SemVer for your dlang package. It uses a slightly modified SemVer definition. It does this by using the -X flag for dmd to get a json file of the symbols and then compares them to the most recent git tag that resembles a SemVer. First release is 1.0.0. If a symbol is removed or its signature changed the major version is increment and the minor and the bugfix number reset to 0. If a new symbol is added, the minor number is incremented and the bug fix number is set to 0. If all symbol stay the same the bugfix number is incremented. In an ideal world the dub registry would use this to compute the SemVer for you, but baby steps. I hope to see many bug reports and PRs.
Re: vibe.d / experience / feedback
On 13 Oct 2020 at 09:57:14 CEST, "aberba" wrote: > D is a great language that is capable of solving any problem > easier than what it'll take to do in equivalent languages. Don't get me wrong, D is great, it has a lot of technically cool things on board. As said, those technical things won't be our major decision aspect. The non-technical aspects are more important when looking from a company perspective. > D is a language you learn once and use every. The question is: Which language and eco-system take how much time to learn to become productive? As team? How to handle a code-base that requires multi-year maintenance? > Just hope the ecosystem gets better to meet business needs... Well, from a business perspective "hope" is a very bad advisor. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: vibe.d / experience / feedback
On 12 Oct 2020 at 21:58:12 CEST, "Ola Fosheim Grøstad" wrote: > On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote: >> Go seems to be kept as simple as possible, even if you have to >> write more code. Which is, in the long run, the cheaper and >> smaller burden. No tricks, no surprises... that has a lot of >> merits. > > Btw, Go has some major weaknesses related to tricks and surprises: I don't expect Go to be perfect and as with every language you need to get a good sense of the dark corners. At least it looks like there are not so many of them, and as long as you are doing "normal" stuff you won't be bitten too frequent. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: vibe.d / experience / feedback
On 12 Oct 2020 at 13:13:27 CEST, "Ola Fosheim Grøstad" wrote: > Yes, it is a good fit for web services with medium sized code > bases. We don't have a lot of "big project" experience with Go yet, but we would use it for a plain-old desktop application. Even most people seem to use Go for the web services stuff, I think it might be underrate for desktop apps. Viele Grüsse. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: vibe.d / experience / feedback
On 11 Oct 2020 at 21:10:20 CEST, "tastyminerals" wrote: > And I feel like you guys will just pick Go because it will get > stuff done. That's the main focus from a company perspective. We try to waste as less time & money as possible. > When I just started learning about D ecosystem, vibe frequently > popped up as one of the popular frameworks available for the > language AND also a reason for ppl to jump in and try out D. I love D, like it a lot, follow it for many years, use it from time to time... but it's not about me, but a team and a product we need to develop and maintain. There are much more non-technical aspects important then technical... And, deciding about your tech-stack base is a path-dependent decision. Turning to something else, has a very high cost impact. > However, as time goes, I also pick up many complaints about vibe, > its performance and ease of use compared to competitors. This > post just solidifies the impression. Bad documentation is the > worst thing that can happen to a project which gets promoted as a > one of the gems of the language ecosystem and actually hurts the > language image much more than does good. Sigh... Well... I expect a lot of people taking a look at D do it like we do with other solutions: I take a list of things I want to try out and start the timer to see how long I take to get it done. This gives a good impression of the eco-system, etc. Taking a step back, D looks a bit scattered. A lot of stuff is there, the standard lib is pretty good, many half-done packages, many corners to take a look at. D is a big language, with a lot of concepts to learn and building up experience is not fast. > I will never advice vibe to anyone because I know that better alternatives > exist. People will use Go, Python, Ruby, Rust whatever has better > docs to get it running fast and not risk wasting time. I'm pretty sure Vide is suitable for all kind of applications today. But you need to have a higher "experimentation" scope in what you do. Once you build up experience with all this stuff, I think there is no big difference to other approaches. But the question is how long is this? 1, 2, X years? > Sadly, this is how some languages grow and some don't. And it's > not all about the corporate support, hype, GC or random luck, > it's about cases like the above. I think less is more, and D is pretty huge tpday. And, it's an OS project, so people do what makes fun. Go is mostly driving from a corporate perspective and the OS part is a side aspect. That has some merits too. Viele Grüsse. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: vibe.d / experience / feedback
On 11 Oct 2020 at 16:46:13 CEST, "Ola Fosheim Grøstad" wrote: > Ada, Java, Eiffel are supposed to. Yes... beside Java, the other two are already in the exotic department... > I'm not sure if Go is a success in that department either. I > suspect it tanks when programs get large. Go seems to be kept as simple as possible, even if you have to write more code. Which is, in the long run, the cheaper and smaller burden. No tricks, no surprises... that has a lot of merits. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: vibe.d / experience / feedback
On 6 Oct 2020 at 10:07:56 CEST, "ddcovery" wrote: > I found myself in a similar situation recently, and I can't help > but ask you: What technology do you use regularly? Hi, well we use a couple of different things. Scripting languages, C, Lua, .. > What drives/draws you to try dlang/vibe.d? A prototype we wanted to build while evaluating D as our next tech stack foundation. > Do you have other alternatives to dlang/vibe.d for your project? Yes. We are currently looking into Go as well. > In my case we usually work in Node+js/ts (previously Scala+Play) > and I wanted to jump to something really performant for a new > project without losing code expressiveness and development speed. > Dlang seemed a good alternative (I like it much more than Go or > Rust). Well, for us it's getting more and more clear, that a decision what to use in the future will be based on less and less technical aspects. The interesting thing about Go is, that their main focus is thinking from an enterprise perspective, not only from a technical one. So, their focus is getting stuff done, keeping maintainability in big, constantly changing teams and stripping everything away, that reduces productivity in such an environment... I don't know about any other language which puts all these non-technical aspects on the top of the agenda. Viele Grüsse. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: vibe.d / experience / feedback
On 3 Oct 2020 at 13:14:57 CEST, "0xEAB" wrote: > On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote: >> On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin >> wrote: >>> Because standard implementation worse? >> >> What do you mean with "worse"? > > It's said to be pretty slow… Well, then it should be fixed... it doesn't make sense to spread N version because everyone things, A or B is not fitting for such a code framework. And, this argument sounds like pre-mature optimization. Who has a real life use-case where the std lib JSON thing is too slow? By how much? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
vibe.d / experience / feedback
Hi, we are currently using vibe.d for a prototype and I want to post some experiences. I know one shouldn't only address the problems but provide some solutions. However, our current use-case is that we want to get a job done, and not creating a web-framework. 1. For many things the docs are missing, or inconsistent, or wrong. So, it's pretty hard to make your way through it. Or you just start reading the code and reverse engineer vibe. => We are waisting a lot of time. 2. There are many inconsistencies / half-done implementations in vibe. Again, this makes it hard to find out what works, what doesn't or which parts behave differently. => Costs a lot of time. 3. Vibe can't handle GET & POST on the same URL... and the bad thing is, the later route will just be ignored, so you don't get any hint or crash. The docs don't mention this clearly. => We waisted a lot of time to find out, that this doesn't work. 4. Vide uses an own JSON type, not the standard one. We don't understand why, this just makes things much more complicated and one has to mess around with this. 5. One can't access the raw HTTP request body, things must be go through Vibe's JSON parser. To get access to the raw body, a lot of workarounds are necessary. So, overall... compared to other web-frameworks we know, there are many pitfalls which just cost a lot of time... We think it's a good base, but there needs to be much less magic, much better docs, much less complexity. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
protobuf-d
Hello! I am currently working on "D Language Client Libraries for Google APIs" project[0][1]. The first step was to familiarize myself with protobuf and to generate client library for cloud/vision using python plugin with protoc. Today I generated the same library with protobuf-d[2]. When I tried to translate this example[3] from python to D, I noticed that some pieces of code are missing from the D generated library, for example the ImageAnnotatorClient class(or struct) (I could not found it anywhere in the generated code). Here is the command that I used to generate the client library: protoc path/to/cloud/vision/proto/files --proto_path=path/to/common/api/protos --proto-path=. --plugin=path/to/protobuf-d --d_opt=message-as-struct --d_out=path/to/output/files Is that ok? Does it work as it should? Also I read here[4] that the C++ generator defines some default methods. Wasn't the proto-gen-d supposed to do the same? Thanks! [0] https://github.com/dlang/projects/issues/66 [1] https://forum.dlang.org/post/eaefvlbgikujonfjj...@forum.dlang.org [2] https://github.com/dcarp/protobuf-d [3] https://gapic-generator-python.readthedocs.io/en/stable/getting-started/docker.html#verifying-the-library [4] https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#message
Re: The ABC's of Templates in D
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
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)
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)
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)
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!
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!
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
vibe / CTRL+C not terminating server
After a CTRL+C I still have the server process running on OSX. Any idea? [main() INF] Listening for requests on http://[::1]:8080/ [main() INF] Listening for requests on http://127.0.0.1:8080/ [main() INF] Please open http://127.0.0.1:8080/ in your browser. ^C [main() INF] Received signal 2. Shutting down. After this, the server is still running. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Rationale for accepting DIP 1028 as is
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
Are compile time generated, stable and unique IDs possible?
Let's assume I have an GUI application and I want to record some user-actions which can be replayed. And this replay should be possible even if the application layout changes. Hence, I somehow need to identify the run-time objects in a way that this identification stays the same while the app is further developed and between user sessions. And I don't want to manually manage all IDs (initially) but use the compiler for this. Is there any way to generate such stable unique IDs at compile-time? I can imagine that his maybe needs to be combined with a mixin that is used inside a constructor to get IDs into run-time objects. -- 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)
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)
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)
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)
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)
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
Re: countUntil with negated pre-defined predicate?
On 2020-05-03 21:59:54 +, Harry Gillanders said:
I'm unsure as to which part is unclear,
Well, I was trapped by this formatting/syntax:
size_t drawableCharacterCount (CodePoints) (auto ref CodePoints
codePoints)
if (isInputRange!CodePoints && is(ElementType!CodePoints : dchar))
{
and was wondering what the first line contributes... now understanding
that it's the function signature and the following "if" line is
template contraint (IIRC). So it's actually:
size_t drawableCharacterCount (CodePoints) (auto ref CodePoints
codePoints)
if (isInputRange!CodePoints && is(ElementType!CodePoints :
dchar))
{
However, I find this sytax a bit unfortunate because I can't spot
quickly that this "if" is a tempalte constraint... but maybe I get more
used to it.
--
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)
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: countUntil with negated pre-defined predicate?
On 2020-05-02 22:33:59 +, Harry Gillanders said:
This depends on what you classify as drawable, and what you consider to
be a character (the joys of Unicode),
Absolutely... however, trying getting close to what works in most cases.
and why you want to search for them anyway.
I'm doing some cursor-movement in a text-field. So, need to find out
where the cursor should be positioned.
One way (I haven't verified this) could be to check if any of the
code-points within a grapheme are graphical[1], and not white-space
(and are not any other code-point you consider non-drawable).
Yes, that makes sense. I wasn't aware about graphical category... so
would have used the !isWhite approach only. Thanks.
Which could look like so:
import std.algorithm;
import std.range;
import std.uni;
size_t drawableCharacterCount (CodePoints) (auto ref CodePoints
codePoints)
What does this line do?
if (isInputRange!CodePoints && is(ElementType!CodePoints : dchar))
{
bool isDrawableCodePoint (dchar c)
{
return c.isGraphical() && !c.isWhite();
}
return codePoints.byGrapheme().count!(
g => g[].any!isDrawableCodePoint
);
}
I want to identify spans of drawable and isWhite in a grapheme array.
So, I think any! just gives the total count of the whole thing. But
anyway, thanks for the input, helps to better understand the whole
thing.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Idomatic way to guarantee to run destructor?
On 2020-05-02 20:43:16 +, Steven Schveighoffer said: destroy sets all the values to the .init value. And it nulls the vtable pointer. Ok, that makes sense. Thanks for all the deep internal details. There is always a lot to learn. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Idomatic way to guarantee to run destructor?
On 2020-05-02 18:18:44 +, Steven Schveighoffer said: On 5/2/20 4:44 AM, Robert M. Münch wrote: How would that help, because the class instance is now unusable anyway. So I have it around like a zombie and others might think: "Hey you look normal, let's get in contact" and then you are doomed... The difference is that if you use it, you get an error and a crash. If you clean up the memory, that memory could be reallocated to something else with a completely different type, and now you have memory corruption. I didn't thought about the "memory is re-used" case here... And how is the instance made unusable so that a crash happens (which I prefer too!)? Does .destroy zero the memory? Just curious how the crash situation is detected. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
countUntil with negated pre-defined predicate?
This works:
countUntil!(std.uni.isWhite)("hello world"))
How can I switch this to (not working);
countUntil!(!std.uni.isWhite)("hello world"))
without having to write my own predicate?
Or is there an even better way to search for all "drawable unicode characters"?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Idomatic way to guarantee to run destructor?
On 2020-04-30 17:45:24 +, Steven Schveighoffer said: No, auto is declaring that there's about to be a variable here. In actuality, auto does nothing in the first case, it just means local variable. But without the type name, the type is inferred (i.e. your second example). This does not do any automatic destruction of your class, it's still left to the GC. Ok, that was my understand too. As said, I found some older posts and was a bit confused... You can use scope instead of auto, and it will then allocate the class on the stack, and destroy it as Ben Jones said. There is danger there, however, as it's very easy to store a class reference elsewhere, and then you have a dangling pointer. Ok. Can't this be combined with some "don't let the refrence escape my function" feature of D? A safer thing to do is: auto X = new MyClass(); scope(exit) destroy(X); This runs the destructor and makes the class instance unusable, but does not free the memory (so any remaining references, if used, will not corrupt memory). How would that help, because the class instance is now unusable anyway. So I have it around like a zombie and others might think: "Hey you look normal, let's get in contact" and then you are doomed... If your concern is guaranteeing destructors are run, that's what I would pick. If in addition you want guaranteed memory cleanup, then use scope (and be careful). Ok, thanks. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Idomatic way to guarantee to run destructor?
On 2020-04-30 17:04:43 +, Ben Jones said: I think you want to use scope rather than auto which will put the class on the stack and call its destructor: https://dlang.org/spec/attribute.html#scope Yes, thanks. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Idomatic way to guarantee to run destructor?
For ressource management I mostly use this pattern, to ensure the
destructor is run:
void myfunc(){
MyClass X = new MyClass(); scope(exit) X.destroy;
}
I somewhere read, this would work too:
void myfunc(){
auto MyClass X = new MyClass();
}
What does this "auto" does here? Wouldn't
void myfunc(){
auto X = new MyClass();
}
be sufficient? And would this construct guarantee that the destructor
is run? And if, why does "auto" has this effect, while just using "new"
doesn't guarantee to run the destructor?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: openmethods 1.3.0
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
Wich: opIndex overloading by return type
Wouldn't it make a lot of sense to allow different opIndex
implementations based on return type?
class myC {
myT1 opIndex(int x)
myT2 opIndex(int x)
}
Depending on the types involved myC[1] woudl return myT1 or myT2.
Use-case: I have a geomentry object and in one case I get x0,y0,x1,y1
and in the other case x,y,w,h
IMO that would make a lot of sense.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: __init unresolved external when using C library structs converted with dstep
On 2020-04-17 09:06:44 +, Dominikus Dittes Scherkl said: On Friday, 17 April 2020 at 08:59:41 UTC, Robert M. Münch wrote: How would that look like? myStruct ms = void; // ??? Exactly. Cool... never saw this / thought about it... will remember it, hopefully. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: __init unresolved external when using C library structs converted with dstep
On 2020-04-16 18:33:51 +, Basile B. said: On Tuesday, 14 April 2020 at 17:51:58 UTC, Robert M. Münch wrote: I use a C libary and created D imports with dstep. It translates the C structs to D structs. When I now use them, everything compiles fine but I get an unresolved external error: WindowsApp1.obj : error LNK2019: unresolved external symbol "myCstruct.__init" (_D7myCStruct6__initZ) referenced in function _Dmain Any idea what this is about and how to fix it? I'm wondering why D tries to find the __init function in the C library and not compile it from the import. One way to prevent the problem is to do void initialization each time you declare a variable of this type. How would that look like? myStruct ms = void; // ??? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: __init unresolved external when using C library structs converted with dstep
On 2020-04-15 15:18:43 +, Steven Schveighoffer said: The difference is you are telling the compiler that it should generate any symbols for those types. If you just import them, then it's expecting something else to build those symbols. Maybe I'm a bit confused, but that's quite different to a C compiler, right? If I include header and have a .lib things fit. With D I have a .lib, I have the imports and still need the imports somehow compiled (included in project, or as a 2nd .lib) to make everything work. Do I understand that correct? You could also build a library that builds those symbols, and link in that library instead. That would be the 2nd .lib approach than. What's strange is, that for a dub project that uses the same imports, I didn't had to add them to the dub.json file. There, it just works without any problems. dub builds all dependencies so this is like the library solution. But I didn't include the library as a dub dependency. I just have the C/C++ compiled lib file and the D imports path for this lib. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: __init unresolved external when using C library structs converted with dstep
On 2020-04-14 18:44:55 +, Steven Schveighoffer said:
On 4/14/20 2:29 PM, Robert M. Münch wrote:
Ah, ok. That's why the problem went (temporarly) away when I did a:
myCstruct a = {0,0}; for example?
I don't know what causes it to be emitted when. Sometimes it doesn't
make a whole lot of sense to me.
Hu... I wouldn't expect this to behave arbitrary...
Yes, everything is "extern(C) :" for the complete import files.
Then apparently the compiler still expects to have initializers even
for foreign language structs.
Which surprised me, or more precise, I don't understand why these are
not done implicitly using the D basic-type initializers.
This is not a huge issue though, as the structs are ABI compatible
even if compiled in D.
Yes, fortunately.
Are you compiling the D file that contains the struct definition as well?
No. Is that the missing part?
Probably. I think the compiler expects whatever is compiling the
imported file to provide the symbol. If you aren't compiling it
separately, then you need to include it in the compilation.
The C lib contains the smybols and I thought that the compiler just
needs the imports to get an idea about the structures, types, etc. and
later on the links resolves everything.
But, it works when I explicitly add the import source files to the
VisualD project. Not sure what difference this makes, because the
source can be compiled without any problems with/without those files
added. But it seems that the linker now sees different things.
What's strange is, that for a dub project that uses the same imports, I
didn't had to add them to the dub.json file. There, it just works
without any problems.
All a bit strange and confusing...
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: __init unresolved external when using C library structs converted with dstep
On 2020-04-14 18:23:05 +, Steven Schveighoffer said:
On 4/14/20 1:51 PM, Robert M. Münch wrote:
I use a C libary and created D imports with dstep. It translates the C
structs to D structs.
When I now use them, everything compiles fine but I get an unresolved
external error:
WindowsApp1.obj : error LNK2019: unresolved external symbol
"myCstruct.__init" (_D7myCStruct6__initZ) referenced in function _Dmain
Any idea what this is about and how to fix it? I'm wondering why D
tries to find the __init function in the C library and not compile it
from the import.
__init is not a function, it's a static member variable. It's the
`intializer` property inside TypeInfo used for initialization.
Ah, ok. That's why the problem went (temporarly) away when I did a:
myCstruct a = {0,0}; for example?
Did you extern(C) the struct?
Yes, everything is "extern(C) :" for the complete import files.
Are you compiling the D file that contains the struct definition as well?
No. Is that the missing part?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
__init unresolved external when using C library structs converted with dstep
I use a C libary and created D imports with dstep. It translates the C structs to D structs. When I now use them, everything compiles fine but I get an unresolved external error: WindowsApp1.obj : error LNK2019: unresolved external symbol "myCstruct.__init" (_D7myCStruct6__initZ) referenced in function _Dmain Any idea what this is about and how to fix it? I'm wondering why D tries to find the __init function in the C library and not compile it from the import. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: A D port of utf8proc
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
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
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: No implicit opOpAssign for structs with basic types?
On 2020-04-04 10:32:32 +, Ferhat Kurtulmuş said:
struct S {
float a;
float b;
S opOpAssign(string op)(ref S rhs) if (op == "+"){
this.a += rhs.a;
this.b += rhs.b;
return this;
}
}
If the struct is from some 3rd party source, how can I add such an
operator overloading to it? Is it possible to "extend" a struct later?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: No implicit opOpAssign for structs with basic types?
On 2020-04-04 10:32:32 +, Ferhat Kurtulmuş said:
Probably I didn't understand what you mean. Sorry if this is not the
case, but this one is easy.
...
struct S {
float a;
float b;
S opOpAssign(string op)(ref S rhs) if (op == "+"){
this.a += rhs.a;
this.b += rhs.b;
return this;
}
}
void main()
{
S a = {1, 5};
S b = {2, 5};
a += b;
writeln(a);
}
...
Yes, sure, but in C++ I don't have to explicitly write this down. It
just works. IMO that makes a lot of sense as long as all types fit.
This just looks superfluously.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
No implicit opOpAssign for structs with basic types?
D doesn't have implicit operators for structs?
struct S {float a, float b};
S a = {1, 5};
S b = {2, 5);
a += b;
Error: a is not a scalar, it is a S
So I really have to write an overloaded operator for such cases?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Dynamically init a struct with values calculated from other values in the struct?
I need to dynamically initialize a fixed number of entries of the form:
(start, length) and iterate over them.
Hence, I think a struct makes sense:
struct S {
s1, l1
, s2, l2
, s3, l3
}
Now I need to initialize the values like this:
S myS = {s1:0, l1:10, s2:(2*s1), ...};
So I somehow would like to reference the prior values to initialize the
other members. I haven't found a way to do it. Is this possible at all?
Or do I just init the struct empty and then set the entries?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: static foreach / How to construct concatenated string?
On 2020-03-07 16:41:47 +, MoonlightSentinel said:
You can use an anonymous lambda to build the string in CTFE:
--
struct S {
int a;
bool b;
}
import std;
enum string sql = {
string s = "CREATE TABLE data(";
static foreach(f; FieldNameTuple!S) {
s ~= f ~ ",";
}
s ~= ");";
return s;
} ();
pragma(msg, sql);
--
This prints "CREATE TABLE data(a, b);"
You can get rid of the enum und the static and it will work too.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: std.datetime & timzone specifier: 2018-11-06T16:52:03+01:00
On 2020-03-07 12:10:27 +, Jonathan M Davis said:
I take it that you're asking why you don't get the time zone as part of the
string when you call one of the to*String functions?
The problem is, the from* functions give an error, that this is not an
ISO date.
I get this in an XML response and extract the datetime:
But I have to do:
DateTime dt =
DateTime.fromISOExtString(split("2018-11-06T16:52:03+01:00",
regex("\\+"))[0]);
IMO such a string should be feedable directly to the function.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: static foreach / How to construct concatenated string?
On 2020-03-07 16:41:47 +, MoonlightSentinel said:
On Saturday, 7 March 2020 at 16:30:59 UTC, Robert M. Münch wrote:
Is this possible at all?
You can use an anonymous lambda to build the string in CTFE:
--
struct S {
int a;
bool b;
}
import std;
enum string sql = {
string s = "CREATE TABLE data(";
static foreach(f; FieldNameTuple!S) {
s ~= f ~ ",";
}
s ~= ");";
return s;
} ();
pragma(msg, sql);
--
This prints "CREATE TABLE data(a, b);"
Nice... is the enum a so called "manifest constant" for which the
initializer is evaluated at compile time?
OT: The pragma seems to print the string twice... at least here on my side.
OT2: Looks like I have to read through the language spec again... and
most likely over and over again, to have all these tricks at my
finger-tips.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: static foreach / How to construct concatenated string?
On 2020-03-07 16:40:15 +, Adam D. Ruppe said: Use regular foreach with a regular string. Put that inside a function. Then simply use that function to initialize your other thing and enjoy the magic of CTFE! Perfect! This implicit CTFE is a tricky thing to see/remember/... Feeling a bit dumb but, hey it works :-) -- Robert M. Münch http://www.saphirion.com smarter | better | faster
static foreach / How to construct concatenated string?
I want to create a "CREATE TABLE data (...)" where the columns are
derived from struct member names. Something like:
string s = "CREATE TABLE data(";
static foreach(f; FieldNameTuple!myStruct) {
s ~= f ~ ",";
}
s ~= ");";
Which of course doesn't work... I didn't find any reference how to
build-up strings in a statif foreach loop.
Is this possible at all?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
std.datetime & timzone specifier: 2018-11-06T16:52:03+01:00
It looks like std.datetime is not anticipating the +1:00 part of a date like: "2018-11-06T16:52:03+01:00" Those dates are used all over on the internet and I'mm wondering why it's not supported. Any reason? Is this +01:00 not ISO conforming? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: DIP 1027---String Interpolation---Format Assessment
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
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
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
Dynamic array of Cycle buffers of size 2 which use a struct?
I don't get how I can create a dynamic array of Cycle buffers of size 2
which use a struct.
struct ms {
int a;
int b;
}
ms[2] msBuffer;
alias circularStructBuffersT = typeof(cycle(msBuffer));
circularStructBuffersT[int] circularStructBuffers;
int i = 2;
auto x = circularStructBuffers.require(i, (){
ms[2] t;
return cycle(t,2);
});
This give an error:
Error: template object.require cannot deduce function from argument
types !()(Cycle!(ms[2])[int], int, Cycle!(ms[2]) function() pure
nothrow @nogc @system), candidates are:
/Library/D/dmd/src/druntime/import/object.d(3225):require(K,
V)(ref V[K] aa, K key, lazy V value = V.init)
Not sure if the `m[2] t` survives the scope exit in form of a closure
(?) or if cycle takes a reference to it...
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
dub / use git branch
I want to use a specific branch version if a package. I specified the branch version in a dub.selections.json file. But it seems that dub requires a ZIP file that can be downloaded from code.dlang.org, which of course fails because the branch is only available on github. Fetching rtree ~fix-#3 (getting selected version)... Downloading https://code.dlang.org/packages/rtree/~fix-#3.zip failed with 404 (Not Found). How am I supposed to switch to a branch version of a package to try a bug-fix version for example? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
How to explicitly state the expression in with(...)?
I have quite often this pattern:
with(x.y.z){
xyzFunc(); // = x.y.z.xyzFunc()
myFunc(x.y.z, ...);
}
and it would be cool to write:
with(t = x.y.z){ // work like an implicit alias
xyzFunc(); // = x.y.z.xyzFunc()
myFunc(t, ...);
}
Is there anything which comes near this idea?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: dub 502 bad gateway
very nice, thank you
Re: D GUI Framework (responsive grid teaser)
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
Thank you, very nice test
Re: dud: A dub replacement
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
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
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
How to use -profile when I initialize D-runtime myself?
Hi, I had a related question in the "Does -profile need the D runtime?" thread. Since D runtime is required for profile to work, the question is how can I use profile when initializing it myself? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: What is the difference between a[x][y] and a[x,y]?
On 2020-01-07 19:06:09 +, H. S. Teoh said: It's up to you how to implement all of this, of course. The language itself doesn't ship a built-in type that implements this, but it does provide the scaffolding for you to build a custom multi-dimensional array type. Hi, thanks for your extensive answer! Helped a lot... And the above paraghraph brings it to the core. How can this be added to the D docs? I think adding such clear "this is the idea how you should use it" intros would help a lot to see the world from a d-ish perspective. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: What is the difference between a[x][y] and a[x,y]?
On 2020-01-07 17:42:48 +, Adam D. Ruppe said: So [x][y] indexes an array of arrays. Yes, that's what I understand. And both can be dynamic, so that I can have a "flattering" layout where not all arrays have the same length. [x,y] indexes a single array that has two dimensions. Does this fix the dimension sizes? So I can't add a "row" or "column" at runtime? What are the difference use-cases for these two? For example, I'm doing a grid widget but want to add/remove rows/columns. Can this only be done with a array-of-array? Is the memory continuous in the [x,y] case, whereas in the [x][y] this is not necessarily the case? This can be kinda confusing because we often think of int[4][4] as being a 2d array, but the D language actually technically sees that as an array of arrays. So it is indexed with [x][y]. Yes, it's confusing as I don't understand the [x,y] case :-) There is no built in multi-dimensional array, it is only syntax provided for library types to implement with the opIndexAssign overloads. I don't get that sentence. Above you write "a single array that has two dimensions" which IMO is exactly a multi-dimensional array. So the operator there like += or -= or *= etc become opAssign, whereas plain = is just plain Assign. Got it. Thanks. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
What is the difference between a[x][y] and a[x,y]?
I read all the docs but I'm not toally sure. Is it that [x][y] is a 2D
array-index, where as [x,y] is a slice?
But the example in docs for opIndexAssign uses the [x,y] syntax, which
is confusing:
```
struct A
{
int opIndexAssign(int value, size_t i1, size_t i2);
}
void test()
{
A a;
a[i,3] = 7; // same as a.opIndexAssign(7,i,3);
}
```
And what is the difference between opIndexAssign and opIndexOpAssign?
Background: I have a class with a 2D array of some other class objects
as memember and want to be able to use it as LHS and RHS.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: What type does byGrapheme() return?
On 2020-01-05 04:18:34 +, H. S. Teoh said: At a minimum, I think we should file a bug report to investigate whether Grapheme.opSlice can be implemented differently, such that we avoid this obscure referential behaviour that makes it hard to work with in complex code. I'm not sure if this is possible, but IMO we should at least investigate the possibilities. Done... my first bug report :-) I copied togehter all the findings from this thread. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
decodeGrapheme & static array
I have: Grapheme[] gr; dchar[1] buf; encode(buf, cast(dchar)myData); gr =~ decodeGrapheme(buf[]); Which gives: Error: template std.uni.decodeGrapheme cannot deduce function from argument types !()(dchar[]), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7164,10): decodeGrapheme(Input)(ref Input inp) I some how need an InputRange for buf and though that buf[] should work. But it doesn't seem to be an L-value... which I don't understand. I thought buf[] returns a temporary dynamic array initialized with the buf content. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: What type does byGrapheme() return?
On 2019-12-31 21:36:56 +, Steven Schveighoffer said: The fact that a Grapheme's return requires you keep the grapheme in scope for operations seems completely incorrect and dangerous IMO (note that operators are going to always have a ref this, even when called on an rvalue). So even though using ref works, I think the underlying issue here really is the lifetime problem. Thanks for all the answers, pretty enlighting even I'm not sure I get everything 100%. So, what to do for now? File a bug-report? What needs to be fixed? I'm using the ref approach for now, in hope it will be OK for my use-case, which is converting a wstring to a grapheme[], alter the array, and map it back to a wstring. Sounds like a lot of porcessing for handling unicode text, but I don't think it gets a lot simpler than that. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: What type does byGrapheme() return?
On 2019-12-27 19:44:59 +, H. S. Teoh said:
Since graphemes are variable-length in terms of code points, you can't
exactly *edit* a range of graphemes -- you can't replace a 1-codepoint
grapheme with a 6-codepoint grapheme, for example, since there's no
space in the underlying string to store that.
Hi, my idea was that when I use a grapheme range, it will abstract away
that graphemes consist of different sized code-points. And the docs at
https://dlang.org/phobos/std_uni.html#byGrapheme show an example using
this kind of range:
auto gText = text.byGrapheme;
gText.take(3);
gText.drop(3);
But maybe I need to get a better understanding of the ranges stuff too...
If you want to add/delete/change graphemes, what you *really* want is to
use an array of Graphemes:
Grapheme[] editableGraphs;
You can then splice it, insert stuff, delete stuff, whatever.
When you're done with it, convert it back to string with something like
this:
string result = editableGraphs.map!(g => g[]).joiner.to!string;
I played around with this approach...
string r1 = "Robert M. Münch";
// Code-Units = 16
// Code-Points = 15
// Graphemes = 15
Grapheme[] gr1 = r1.byGrapheme.array;
writeln(" Text = ", gr1.map!(g => g[]).joiner.to!string);
// Text = obert M. Münch
writeln("wText = ", gr1.map!(g => g[]).joiner.to!wstring);
// wText = obert M. Münch
writeln("dText = ", gr1.map!(g => g[]).joiner.to!dstring);
// dText = obert M. Münch
Why is the first letter missing? Is this a bug?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: What type does byGrapheme() return?
On 2019-12-27 17:54:28 +, Steven Schveighoffer said:
This is the rub with ranges. You need to use typeof. There's no other
way to do it, because the type returned by byGrapheme depends on the
type of Range.
Hi, ok, thanks a lot and IMO these are the fundamental important
information for people using D (beginners, causual programmers, etc.)
to understand how things fit together.
If you know what type Range is, it would be:
struct S
{
typeof(string.init.byGrapheme()) gText;
// or
alias GRange = typeof(string.init.byGrapheme());
GRange gText;
}
Ah... I didn't know that I can use a basic type "string" combined with
".init" to manually build the type. Neat...
Subbing in whatever your real range for `string`. Or if it's the result
of a bunch of adapters, use the whole call chain with typeof.
Ok, and these are good candidates for alias definitions to avoid
re-typing it many times.
Why not just declare the real range type? Because it's going to be
ugly, especially if your underlying range is the result of other range
algorithms. And really, typeof is going to be the better mechanism,
even if it's not the best looking thing.
I think I got it... thanks a lot.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
What type does byGrapheme() return?
I love these documentation lines in the D docs: auto byGrapheme(Range)(Range range) How should I know what auto is? Why not write the explicit type so that I know what to expect? When declaring a variable as class/struct member I can't use auto but need the explicit type... I used typeof() but that doesn't help a lot: gText = [Grapheme(53, 0, 0, 72057594037927936, [83, , 1)]Result!string I want to iterate a string byGrapheme so that I can add, delete, change graphemes. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: D-ish way to work with strings?
On 2019-12-23 15:05:20 +, H. S. Teoh said: On Sun, Dec 22, 2019 at 06:27:03PM +0100, Robert M. Münch via Digitalmars-d-learn wrote: Want to add I'm talking about unicode strings. Wouldn't it make sense to handle everything as UTF-32 so that iteration is simple because code-point = code-unit? And later on, convert to UTF-16 or UTF-8 on demand? [...] Be careful that code point != "character" the way most people understand the word "character". I know. My point was that with UTF-8 code-points (not being a character) have different sizes. Which you need to take into account if you want to iterate by code-points. The word you're looking for is "grapheme". Which, unfortunately, is rather complex and very slow to handle in Unicode. See std.uni.byGrapheme. Yes, that's when we come to "characters". And a "grapheme" can consists of several code-points. Is grapheme handling just slow in D or in general? If it's the latter, well, than that's just how it is. Usually you want to just stick with UTF-8 (usually) or UTF-16 (for Windows and Java interop). UTF-32 wastes a lot of space, and *still* doesn't give you what you think you want, and Grapheme[] is just dog slow because of the amount of decoding/recoding needed to manipulate it. I need to handle graphemes when things are goind to be rendered and edited. What are you planning to do with your strings? Pretty simple: Have user editable content that is rendered using different fonts supporting unicode. So, all editing functions: insert, replace, delete at all locations in the string supporting all unicode characters. Viele Grüsse. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: D-ish way to work with strings?
On 2019-12-22 18:45:52 +, Steven Schveighoffer said: switch to using char[]. Unfortunately, there's a lot of code out there that accepts string instead of const(char)[], which is more usable. I think many people don't realize the purpose of the string type. It's meant to be something that is heap-allocated (or as a global), and NEVER goes out of scope. Hi Steve, thanks for the feedback. Makes sense to me. It really depends on your use cases. strings are great precisely because they don't change. slicing makes huge sense there. My "strings" change a lot, so not really a good fit to use string. Again, use char[] if you are going to be rearranging strings. And you have to take care not to cheat and cast to string. Always use idup if you need one. Will do. If you find Phobos functions that unnecessarily take string instead of const(char)[] please post to bugzilla. Ok, will keep an eye on it. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: D-ish way to work with strings?
Want to add I'm talking about unicode strings. Wouldn't it make sense to handle everything as UTF-32 so that iteration is simple because code-point = code-unit? And later on, convert to UTF-16 or UTF-8 on demand? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
D-ish way to work with strings?
I want to do all the basics mutating things with strings: append, insert, replace What is the D-ish way to do that since string is aliased to immutable(char)[]? Using arrays, using ~ operator, always copying, changing, combining my strings into a new one? Does it make sense to think about reducing GC pressure? I'm a bit lost in the possibilities and don't find any "that's the way to do it". -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Article about D in the iX magazine
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
