Re: How create a function that receive a function and run it in another threading?
On Friday, 27 December 2019 at 07:06:52 UTC, mipri wrote:
On Friday, 27 December 2019 at 06:08:16 UTC, Marcone wrote:
import std;
import core.thread;
auto threading(lazy void fun){ return
task!fun().executeInNewThread(); }
void main(){
threading(writeln("Hello World!"));
}
I want to create a function threading() to run some function
in other threading, but I get this error bellow. How can I get
success?
Error: static function Programa.threading.Task!(fun).Task.impl
cannot access frame of function Programa.threading
Error: template instance `Programa.threading.Task!(fun)` error
instantiating
This works:
import std;
import core.thread;
auto threading(void function() fun){ return
task(fun).executeInNewThread(); }
void main(){
writeln("Main: ", thisTid);
threading({ writeln("Hello, ", thisTid); });
}
Very Good! Thank you:
import std;
import core.thread;
alias threading = compose!(fun => fun.executeInNewThread(), fun
=> task(fun));
void main(){
threading({writeln("Ola Mundo!");});
}
Re: How to debug in vscode Windows?
On Friday, 27 December 2019 at 18:48:50 UTC, cfcd14f496326e429ce03c48650b7966 wrote: Hello. I spent many time to searching for find a solutions. Many posts not clearly or tell like brief. :( I tried "Microsoft C/C++(ms-vscode.cpptools)" and "Native Debug (webfreak.debug )" plugin. And I found this post: https://forum.dlang.org/post/jxnnfzjsytoneqvxe...@forum.dlang.org Yeah, "Native Debug" is not work on windows. I guess, can only use a GDB with "Microsoft C/C++(ms-vscode.cpptools)" for debug on windows. But I can't find setup guide for D clearly. I use the Microsoft plugin and it was working out of the box. There was no D specific setting to be done but as far as I remember just setting the executable file path in the debug json file. The only thing you have to take care of: with older versions of Dub, the executable has OMF architecture, recent versions of dub defaults to COFF (64 bit). Out of the box debugging works only for COFF. Kind regards Andre
Re: What type does byGrapheme() return?
On Fri, Dec 27, 2019 at 06:26:58PM +0100, Robert M. Münch via Digitalmars-d-learn wrote: > 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. [...] 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. 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; T -- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous
Re: Difference in compiletime vs compiletime or compiler bug?
On Friday, 27 December 2019 at 18:51:31 UTC, Adam D. Ruppe wrote: On Friday, 27 December 2019 at 18:49:32 UTC, Sjoerd Nijboer wrote: Should concatenating the list and mixing that in work too? yeah that'd work too. As long as all the overloads are coming from the same source, D allows it. but if you add something manually in the struct then you have two sources again so this rule can bite back. It's a completely generated body of a struct, so that won't be an issue. It was just convenient to have a static foreach loop and generate some functions out of that by invoking a mixin template, which will cause the scoping problem. I'll probably generate the `string[]` using a function, join it and then mixin the result to have it all in one scope. I thought I had a valid usecase for mixin templates. :/ They're quite daunting beasts with these kind of constraints.
Re: Difference in compiletime vs compiletime or compiler bug?
On Friday, 27 December 2019 at 18:49:32 UTC, Sjoerd Nijboer wrote: Should concatenating the list and mixing that in work too? yeah that'd work too. As long as all the overloads are coming from the same source, D allows it. but if you add something manually in the struct then you have two sources again so this rule can bite back.
Re: Difference in compiletime vs compiletime or compiler bug?
On Friday, 27 December 2019 at 18:34:49 UTC, Adam D. Ruppe wrote: On Friday, 27 December 2019 at 18:22:10 UTC, Sjoerd Nijboer wrote: When calling the mixin directly instead of through the template mixin it breaks with thesame error message. What exactly did you do here? I meant to say that that is when it does work. I shoul've caught this when I proof-read this post. template mixins take things in two different scopes: mix!one_string mix!other_string creates two separate things that do not overload each other. You have to `alias name = xxx` twice in the same scope to merge them. string mixin works differently, it doesn't produce a scope. In your case you probably just want to use string mixin and take the `mix` item out entirely. Should concatenating the list and mixing that in work too? I'll probably remove the mixin template completely, concatenate the array of strings and mixin the entire array if that should be the proper way for solving this. Thank you!
How to debug in vscode Windows?
Hello. I spent many time to searching for find a solutions. Many posts not clearly or tell like brief. :( I tried "Microsoft C/C++(ms-vscode.cpptools)" and "Native Debug (webfreak.debug )" plugin. And I found this post: https://forum.dlang.org/post/jxnnfzjsytoneqvxe...@forum.dlang.org Yeah, "Native Debug" is not work on windows. I guess, can only use a GDB with "Microsoft C/C++(ms-vscode.cpptools)" for debug on windows. But I can't find setup guide for D clearly.
Re: Difference in compiletime vs compiletime or compiler bug?
On Friday, 27 December 2019 at 18:22:10 UTC, Sjoerd Nijboer wrote:
When calling the mixin directly instead of through the template
mixin it breaks with thesame error message.
What exactly did you do here?
struct C
{
static foreach (m; mixins)
{
mixin(m);
}
}
works for me...
I don't know if this an actual compiler bug or if this is me
not properly understanding D.
This is a case of the function hijacking rules biting you:
https://dlang.org/articles/hijack.html
template mixins take things in two different scopes:
mix!one_string
mix!other_string
creates two separate things that do not overload each other. You
have to `alias name = xxx` twice in the same scope to merge them.
string mixin works differently, it doesn't produce a scope. In
your case you probably just want to use string mixin and take the
`mix` item out entirely.
But anyway the mixin results from the two things do NOT
automatically merge whcih is what causes your errors.
Difference in compiletime vs compiletime or compiler bug?
I've got a snippet of code which I have narrowed down to the
following:
'import std.stdio;
enum string[] mixins = ["public bool qux(int i, char c)
{
throw new Exception(\"not implemented\");
// Add all arguments to a struct and serialize
that struct.
};", "
public bool qux(string s)
{
throw new Exception(\"not implemented\");
// Add all arguments to a struct and serialize
that struct.
};
"];
struct C
{
static foreach (m; mixins)
{
mixin mix!m;
}
}
mixin template mix(string s)
{
mixin(s);
}
void main()
{
import std.traits : ReturnType;
auto c = C();
pragma(msg, c.qux.mangleof); // writes 'v' to the console
pragma(msg, ReturnType!(c.qux));
}'
The exact error this returns is as follows:
'Error: template instance std.traits.ReturnType!(qux) does not
match template declaration ReturnType(func...)
with func = (qux)
must satisfy the following constraint:
isCallable!func
source/app.d(34,2):while evaluating pragma(msg,
ReturnType!(qux)
'
As far as I know, this "should" work.
When I delete one of the functions out of the mixin it suddenly
compiles with a mangled name, but when I place the second
function in there it won't.
When calling the mixin directly instead of through the template
mixin it breaks with thesame error message.
I don't know if this an actual compiler bug or if this is me not
properly understanding D.
I'm using DMD64 D Compiler v2.089.1
Any help is appreciated.
Re: What type does byGrapheme() return?
On 12/27/19 12:26 PM, Robert M. Münch wrote:
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.
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.
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;
}
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.
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.
-Steve
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 Fri, Dec 27, 2019 at 01:23:57PM +0100, Robert M. Münch via Digitalmars-d-learn wrote: > On 2019-12-23 15:05:20 +, H. S. Teoh said: [...] > > 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. [...] Ah, I see. In that case you might want to consider using graphemes by default, since that's what most closely corresponds to how the user will perceive a "character". For processing outside of editing, though, you might want to consider converting to some other representation for manipulation, since graphemes are slow (the decoding process is complex, and we can't work around that because that's what Unicode requires). T -- Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder
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
