Re: Typescript with vibe.d
On Monday, 9 March 2020 at 17:46:42 UTC, Steven Schveighoffer wrote: On 3/9/20 1:23 PM, GreatSam4sure wrote: [...] You can use it, but you have to compile it yourself. Vibe.d does nothing with the javascript except serve it to the browser. It has no restrictions on what files can be sent, but does not convert anything for you. [...] No. This means that if you wanted to use, for instance, a diet template to generate typescript, this would not work. My recommendation in that case is to generate javascript data using diet templates, and use it from a Typescript file that is pre-compiled before being served via vibe.d. -Steve Thanks, that is what I want to know
New with alias
I write a code as below: auto result = new char[4]; It allocates memory as expected. Later I define an alias and do the above step: alias Pattern = char[4]; auto result = new Pattern; But compiler says: Error: new can only create structs, dynamic arrays or class objects, not `char[4]`'s Is this a bug, or `alias` doesn't work how I was thinking?
Introduction and request for help
Hey Everyone,
I'm a new D developer and therefore new to Gtkd. By day I'm an
android developer using Kotlin and most of my hobby projects are
in Go.
So far I've enjoyed my time working in D. I've been working on
this project, https://gitlab.com/kendellfab/rest-scope, a rest
testing project much like postman.
So far I've had no problems building this project with DUB.
However I want to move over to meson so that I can build it for
flatpak. I am finding that I am unable to build with meson.
I've had two issues. First, I was unable to find the dependencies
wit this, gtkd_dep = dependency('gtk-d:gtkd', version: '~>3.9.0',
method: 'dub'). This dep is added to the dependencies array
passed to the executable. The build would fail as it could not
find the gsv.SourceView.
I was able to fix this issue, by passing in a directory to the
dependency array, such as this.
declaredependency(includedirectories: packagedir +
'/gtk-d-3.9.0/gtk-d/generated/sourceview'). The packagedir string
being set by an option with generating the meson build directory,
this is to my home folder .dub directory.
But this created a new build issue with the linker. The linker
can not find the source view objects to link with the executable.
So again my builds are failing. But I'm unsure where to find the
object files for the linker to link in.
Does any one have any insights on how I could get this project to
build?
-- Cross post from gtkd forum
Re: @property with opCall
On 09.03.20 13:14, Adam D. Ruppe wrote: Here's a wiki page referencing one of the 2013 discussions https://wiki.dlang.org/Property_Discussion_Wrap-up https://wiki.dlang.org/DIP24
Re: Docs 6.9.4: Implicit Conversion to bool
On Monday, 9 March 2020 at 16:44:55 UTC, Steven Schveighoffer wrote: You're not the first person to ask. Accepted.
Re: An struct copy constructor that can cope with an AA?
On 3/9/20 11:49 AM, mark wrote: On Monday, 9 March 2020 at 14:45:15 UTC, Steven Schveighoffer wrote: On 3/9/20 9:23 AM, mark wrote: I have this struct: [snip] I would name it dup instead of copy for consistency with D. A copy constructor is pretty heavy for a struct to do a complete duplication of the AA. You should have to opt-in to that. Thanks, I'd already realised I ought to rename it .dup. Also, I only actually need to create it from the keys since I'm using the tags AA as a set so every value is the same. I did try tags.dup but got this: src/deb.d(25,24): Error: cannot implicitly convert expression dup(this.tags) of type const(void[0])[string] to void[0][string] Right, because it's inside a const member function, the tags member is const. Right now, it looks like dup does not work even for value types (e.g. const int[int] -> int[int]) let alone types with indirection (it should also work for string keys). If there's not an issue already, someone should file it. -Steve
Re: Typescript with vibe.d
On 3/9/20 1:23 PM, GreatSam4sure wrote: On Monday, 9 March 2020 at 15:11:48 UTC, Steven Schveighoffer wrote: On 3/9/20 5:42 AM, GreatSam4sure wrote: I want to know if it is possible to use typescript with the vibe.d since typescript is a superset of javascript. I will appreciate any example if it is possible My understanding is that Typescript needs to be compiled to javascript. You can't serve typescript directly to a browser. So as long as you are doing this in a separate file, vibe.d can serve up the javascript files just fine. -Steve I am working on a web app using a vibe.d but I prefer typescript to javascript. So I want to use typescript. My question is that can I use typescript instead of javascript since it must be compiled to javascript? You can use it, but you have to compile it yourself. Vibe.d does nothing with the javascript except serve it to the browser. It has no restrictions on what files can be sent, but does not convert anything for you. Does the vibe.d framework compile typescript to javascript? No. This means that if you wanted to use, for instance, a diet template to generate typescript, this would not work. My recommendation in that case is to generate javascript data using diet templates, and use it from a Typescript file that is pre-compiled before being served via vibe.d. -Steve
Re: Typescript with vibe.d
On Monday, 9 March 2020 at 15:11:48 UTC, Steven Schveighoffer wrote: On 3/9/20 5:42 AM, GreatSam4sure wrote: I want to know if it is possible to use typescript with the vibe.d since typescript is a superset of javascript. I will appreciate any example if it is possible My understanding is that Typescript needs to be compiled to javascript. You can't serve typescript directly to a browser. So as long as you are doing this in a separate file, vibe.d can serve up the javascript files just fine. -Steve I am working on a web app using a vibe.d but I prefer typescript to javascript. So I want to use typescript. My question is that can I use typescript instead of javascript since it must be compiled to javascript? Does the vibe.d framework compile typescript to javascript?
Re: Docs 6.9.4: Implicit Conversion to bool
On 3/9/20 11:35 AM, Manfred Nowak wrote: Having a function `f' overloaded for argument types `bool' and `ulong', the specs guarantee, that for `f( 1uL)' the boolean overload of `f' is called. What is this good for? You're not the first person to ask. https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1015.md -Steve
Re: std.datetime & timzone specifier: 2018-11-06T16:52:03+01:00
On Sunday, March 8, 2020 11:19:33 PM MDT tchaloupka via Digitalmars-d-learn
wrote:
> On Sunday, 8 March 2020 at 17:28:33 UTC, Robert M. Münch wrote:
> > On 2020-03-07 12:10:27 +, Jonathan M Davis said:
> >
> > 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.
>
> You just need to use SysTime.fromISO*String functions for that,
> as DateTime does't work with timezones, SysTime do.
Exactly. DateTime does not support timezones or fractional seconds. If you
want that, then use SysTime. And if you want to get a DateTime from a string
such as "2018-11-06T16:52:03+01:00", then just use SysTime's
fromISOExtString and convert the result to DateTime. e.g.
auto dt =
cast(DateTime)SysTime.fromISOExtString("2018-11-06T16:52:03+01:00"");
The documentation for the from*String functions say what they support.
- Jonathan M Davis
Re: An struct copy constructor that can cope with an AA?
On Monday, 9 March 2020 at 14:45:15 UTC, Steven Schveighoffer wrote: On 3/9/20 9:23 AM, mark wrote: I have this struct: [snip] I would name it dup instead of copy for consistency with D. A copy constructor is pretty heavy for a struct to do a complete duplication of the AA. You should have to opt-in to that. -Steve Thanks, I'd already realised I ought to rename it .dup. Also, I only actually need to create it from the keys since I'm using the tags AA as a set so every value is the same. I did try tags.dup but got this: src/deb.d(25,24): Error: cannot implicitly convert expression dup(this.tags) of type const(void[0])[string] to void[0][string]
Docs 6.9.4: Implicit Conversion to bool
Having a function `f' overloaded for argument types `bool' and `ulong', the specs guarantee, that for `f( 1uL)' the boolean overload of `f' is called. What is this good for?
Re: static foreach / How to construct concatenated string?
On Sunday, 8 March 2020 at 20:28:01 UTC, Robert M. Münch wrote: You can get rid of the enum [...] That depends on your use case. You will need enum if you want to use the value at compile time (e.g. when using it as a template parameter). Otherwise a normal string will suffice. und the static and it will work too. Yesh, I forgot about the old implicit static foreach loop.
Re: Typescript with vibe.d
On 3/9/20 5:42 AM, GreatSam4sure wrote: I want to know if it is possible to use typescript with the vibe.d since typescript is a superset of javascript. I will appreciate any example if it is possible My understanding is that Typescript needs to be compiled to javascript. You can't serve typescript directly to a browser. So as long as you are doing this in a separate file, vibe.d can serve up the javascript files just fine. -Steve
Re: Typescript with vibe.d
On Monday, 9 March 2020 at 09:42:16 UTC, GreatSam4sure wrote: I want to know if it is possible to use typescript with the vibe.d since typescript is a superset of javascript. I will appreciate any example if it is possible What do you want to do?
Re: An struct copy constructor that can cope with an AA?
On 3/9/20 9:23 AM, mark wrote:
I have this struct:
struct Deb {
string name;
...
Unit[string] tags; // set of tags
Deb copy() const {
Deb deb;
...
foreach (key, value; tags) // XXX
deb.tags[key] = value;
return deb;
}
void clear() {
name = "";
...
tags.clear;
}
}
I am populating an AA with these structs:
Deb[string] debForName;
I'm using this approach (pseudo-code):
Deb deb;
foreach (datum; data) {
populateDeb(datum, deb);
debForName[deb.name] = deb.copy; // YYY
deb.clear;
}
(1) XXX Is there a nicer way to copy an AA?
aa.dup. However, this isn't going to work in a const member function
(though technically there shouldn't be anything wrong with it).
(2) YYY Is there a nicer way to copy a struct? Use a copy constructor or
implement a dup or idup?
I would name it dup instead of copy for consistency with D. A copy
constructor is pretty heavy for a struct to do a complete duplication of
the AA. You should have to opt-in to that.
-Steve
Re: " include imported modules in the compilation " should exclude di file
On Monday, 9 March 2020 at 13:55:08 UTC, Calvin P wrote: The current compiler "-i=module_name" option will include imported modules as source code. When the module define from di file extension, I think compiler should avoid treat it as source file. What do you think? The use case: If I want to define a collection function only use for ctfe, I can put them into di file to avoid binary bloat. It also can be used create helper module for BetterC library, so you can use "new Struct" in the di and import it from betterC module. without use "-I=-lib_helper" to exclude every helper module in the library.
" include imported modules in the compilation " should exclude di file
The current compiler "-i=module_name" option will include imported modules as source code. When the module define from di file extension, I think compiler should avoid treat it as source file. What do you think?
Re: @property with opCall
On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote:
Here's a wiki page referencing one of the 2013 discussions
https://wiki.dlang.org/Property_Discussion_Wrap-up
though i'll note the thing is older than that.
What especially drove me nuts is people would so often say
"property *syntax*" instead of "property semantics" - everyone
would go on and on and on about banning optional parenthesis
which should be a totally unrelated discussion when we should
have been talking about the semantic question and focusing on
the case you discovered - the case that actually matters.
Thanks for reply.
after read the wiki, I am try answer some question.
Some people find it difficult to decide if something is a
property or a function
How can we get the getter / setter functions? Do we need to get
those?
This can be fixed with a new __traits. and should allow get
getter/setter functions.
Some people think the additional @property attribute clutters
the source code
I think it made code more readable.
Can we get a reference to the property? What does &x.property_
mean?
this should be decide base the Getter function attribute, ref
function should allow get reference. ref scope function allow
get scope ref.
> What is the type of the property? Return type, setter function
type or getter function type? How to get the other types?
I think setter should force return void, typeof(@property)
should return getter return type, if no getter should return void.
What does x.property_++ do?
this should only allow for ref getter with a setter.
Is returning ref values from the getter OK?
returning ref values from getter should be allowed.
I find one nice use case will be create a scope ref @property
base on pointer filed.
struct A {
B* _ptr;
@property ref auto b() return scope
{
return *_ptr;
}
}
Is taking ref values in the setter OK?
I think no harm to allow this.
UCFS and @property
If can not avoid conflict with UCFS, we can force @property only
work for class|struct instance method function.
How many parameters are allowed for property functions?
limit to 1 parameter. use backtrace for caller position.
Are templated properties allowed?
I think better not allow templated properties to keep it simple.
Ambiguous / complicated if a function returns a delegate or
similar (solvable with special case rules)
Complicates semantics for human reader of the code (see
comments about readability in "How those are (not!) related")
I can not answer this. but I think a simple rule can be apply to
@property:
When there is conflict, treat it like field, not function.
base on this rule, I think getter function should be @nogc, no
memory alloc.
Re: @property with opCall
On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote: On Monday, 9 March 2020 at 10:09:56 UTC, Calvin P wrote: @property exists so many years, Druntime & Phobos use it 2280 times. I can't believe it is not recommended. They never implemented it right. This opCall type thing was THE case we brought up to introduce @property in the first place but it never actually affected this. For years, @property did absolutely nothing. We were told to use it for the future. Some people tried to put on a compiler switch to make it do something, but they consistently made that switch do the wrong thing! Then @property got frozen for fear of broken changes. LOL. Now @property changes the result of `typeof(a.prop)`... but nothing else. @property is one of the biggest WTFs of D's development. no kidding, d should just copy c# property semantics as the current implementation of it is wonky. Mike attempted to add binary operations to it, but instead close his dip pull request and the following dmd pull requested. -Alex
An struct copy constructor that can cope with an AA?
I have this struct:
struct Deb {
string name;
...
Unit[string] tags; // set of tags
Deb copy() const {
Deb deb;
...
foreach (key, value; tags) // XXX
deb.tags[key] = value;
return deb;
}
void clear() {
name = "";
...
tags.clear;
}
...
}
I am populating an AA with these structs:
Deb[string] debForName;
I'm using this approach (pseudo-code):
Deb deb;
foreach (datum; data) {
populateDeb(datum, deb);
debForName[deb.name] = deb.copy; // YYY
deb.clear;
}
(1) XXX Is there a nicer way to copy an AA?
(2) YYY Is there a nicer way to copy a struct? Use a copy
constructor or implement a dup or idup?
Re: @property with opCall
On Monday, 9 March 2020 at 10:09:56 UTC, Calvin P wrote: @property exists so many years, Druntime & Phobos use it 2280 times. I can't believe it is not recommended. They never implemented it right. This opCall type thing was THE case we brought up to introduce @property in the first place but it never actually affected this. For years, @property did absolutely nothing. We were told to use it for the future. Some people tried to put on a compiler switch to make it do something, but they consistently made that switch do the wrong thing! Then @property got frozen for fear of broken changes. LOL. Now @property changes the result of `typeof(a.prop)`... but nothing else. @property is one of the biggest WTFs of D's development. Here's a wiki page referencing one of the 2013 discussions https://wiki.dlang.org/Property_Discussion_Wrap-up though i'll note the thing is older than that. What especially drove me nuts is people would so often say "property *syntax*" instead of "property semantics" - everyone would go on and on and on about banning optional parenthesis which should be a totally unrelated discussion when we should have been talking about the semantic question and focusing on the case you discovered - the case that actually matters.
Re: static foreach / How to construct concatenated string?
On 07.03.20 17:41, MoonlightSentinel wrote: 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: It turns out that if you do use this standard idiom, you might end up getting blamed for an unrelated DMD bug though: https://github.com/dlang/dmd/pull/9922 :o)
Re: @property with opCall
On Monday, 9 March 2020 at 09:44:40 UTC, Simen Kjærås wrote: As written on https://dlang.org/spec/function.html#property-functions: WARNING: The definition and usefulness of property functions is being reviewed, and the implementation is currently incomplete. Using property functions is not recommended until the definition is more certain and implementation more mature. So no, I don't think it's necessary to file a bug - we're aware they're somewhat wonky, and until a resolution has been agreed on, I don't think filing bugs on what's undecided behavior is worth it. -- Simen Thanks for your reply. @property exists so many years, Druntime & Phobos use it 2280 times. I can't believe it is not recommended. Is there any discuss link or documents about the review process?
Re: @property with opCall
On Monday, 9 March 2020 at 09:25:31 UTC, Calvin P wrote:
Is this a bugs ?
==
struct A {
ref auto opCall(string tmp) scope return {
return this;
}
}
struct B {
A _a;
@property ref auto a() scope return {
return _a;
}
}
extern(C) int main(){
A a;
a("a")("b");
B b;
b.a("a")("b"); // Error: function test_opCall.B.a() is
not callable using argument types (string)
return 0;
}
==
I has to use b.a()("a")("b") to avoid the compiler error. I
think it should work to avoid the unnecessary ()
Should I submit a bugs ?
As written on
https://dlang.org/spec/function.html#property-functions:
WARNING: The definition and usefulness of property functions is
being reviewed, and the implementation is currently incomplete.
Using property functions is not recommended until the
definition is more certain and implementation more mature.
So no, I don't think it's necessary to file a bug - we're aware
they're somewhat wonky, and until a resolution has been agreed
on, I don't think filing bugs on what's undecided behavior is
worth it.
--
Simen
Typescript with vibe.d
I want to know if it is possible to use typescript with the vibe.d since typescript is a superset of javascript. I will appreciate any example if it is possible
@property with opCall
Is this a bugs ?
==
struct A {
ref auto opCall(string tmp) scope return {
return this;
}
}
struct B {
A _a;
@property ref auto a() scope return {
return _a;
}
}
extern(C) int main(){
A a;
a("a")("b");
B b;
b.a("a")("b"); // Error: function test_opCall.B.a() is
not callable using argument types (string)
return 0;
}
==
I has to use b.a()("a")("b") to avoid the compiler error. I
think it should work to avoid the unnecessary ()
Should I submit a bugs ?
Re: Idiomatic way to express errors without resorting to exceptions
On Saturday, 7 March 2020 at 15:44:38 UTC, Arine wrote: The case when there isn't a value should be handled explicitly, not implicitly. Propogating a None value isn't useful Except when it is useful, and shouldn't be handled explicitly. I have code in D, C and C++ that looks like this: ReturnValue result = someInitialValue; auto foo = getFoo(); if (!foo) return result; auto bar = foo.fun(); if (!bar) return result; return bar.gun(); In C#, this would be: return getFoo()?.fun().gun() ?? someInitialValue; And with implicit handling in Optional!T, it looks like this: return getFoo().oc.fun().gun().or(someInitialValue); Clearly the latter two are more readable, and I'm not gonna care that it's a little slower in the 99% of cases where speed is not important. -- Simen
Re: How to use sets in D?
On Sunday, 8 March 2020 at 17:58:16 UTC, Jesse Phillips wrote: On Friday, 7 February 2020 at 19:37:08 UTC, mark wrote: [snip] I think I've usually used the associative arrays, but I also think I tend to avoid using this approach but couldn't quite remember what I do instead. I believe I have started just using an array. arr ~= addMyData; arr.sort.uniq Then I make use of the algorithms here. https://dlang.org/phobos/std_algorithm_setops.html I can see the sense in that for use with union & intersection. However, AA's (assuming they are hashes under the hood) give O(1) for `in` whereas those algorithms like the rbtree are O(lg n) for `in`, and most of what I'm doing at the moment is `in`. I'll keep the idea in mind though, because I have use cases for intersection.
