Re: State of D for webassembly
On Monday, 17 May 2021 at 20:38:12 UTC, Chris Piker wrote: What is the general state of support for GC dependent D-code running as webassembly? If the runtime is not ready that's okay, just wanted to inquire about the state of things. There is a partial port of full runtime but it is still alpha level. A couple people have tried it and there's various bugs they worked through but some remained. I wouldn't recommend using it at this time unless you're prepared to do some specific webassembly hacks and maybe dive into the druntime a bit yourself. on the other hand if you are willing to dive in yourself a bit, you totally can make it work. I have a little website where I compiled some of my games to webasm: http://webassembly.arsdnet.net/ http://webassembly.arsdnet.net/tetris I did it with a custom runtime and a specialized port of my relevant D libraries.
State of D for webassembly
Hi D Our group has some spectragram (aka dynamic spectra) creation algorithms that are fast in Java and since D has many Java-ish concepts it looks like it would be do-able to port the code to D. If I take on this project my target would be to run as a webassembly program. What is the general state of support for GC dependent D-code running as webassembly? If the runtime is not ready that's okay, just wanted to inquire about the state of things. Thanks,
Re: PyD - accessing D class fields in Python
On Monday, 17 May 2021 at 17:16:27 UTC, Imperatorn wrote:
On Monday, 17 May 2021 at 16:54:07 UTC, mw wrote:
On Tuesday, 19 March 2019 at 23:58:48 UTC, Bastiaan Veelo
wrote:
[...]
I filed the issue here (still no response yet):
https://github.com/ariovistus/pyd/issues/152
[...]
https://github.com/symmetryinvestments/autowrap
Thanks, I just tried, but still cannot get access to class field:
I build this example:
https://github.com/symmetryinvestments/autowrap/tree/master/examples/pyd
and test this:
https://github.com/symmetryinvestments/autowrap/blob/master/examples/pyd/source/class_wrap.d
class Bizzy {
int _m;
...
}
```
$ dub build --config=python36
$ ln -s lib/pyd/libpydtests.so pyd.so
$ python3
import pyd
b = pyd.Bizzy(0)
b
bye(0)
b._m = 3
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'pyd.Bizzy' object has no attribute '_m'
```
Add `public` does not work either:
```
class Bizzy {
public int _m;
...
}
```
Any hints?
Re: ugly and/or useless features in the language.
On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:
Which parts in dlang don't you use and why?
There is one feature (actually a mix of features) I'd be happy
not to use, but it is not possible: I call it autoreals, because
it resembles somewhat the idea behind autodecoding - in both
cases the compiler (or Phobos) does something automatically that
you cannot avoid and sometimes causes real headache, but which
you could do easily yourself if it were not done automatically):
What I'm talking about is
- reals being differently implemented on different computers
- reals being internally used for computation and intermediate
storage
- reals being automatically used in CTFE (and reals in CTFE might
differ from the reals at runtime)
All together this ends in generic code (for example in libraries)
behaving more or less like a random generator; at least it feels
like this.
I would be able to cope with the first point by either not using
reals at all or `static if` to generate separate code for every
version. But together with the other two "features" reals cannot
be ignored anymore. You cannot even assume a function with return
type double to return a double. So to be sure to have a double,
when a double is needed you need to do stuff like
```
double d = some_fun();
ulong tmp = *cast(ulong*)
tmp ^= 12543;
/* maybe here some more ugly stuff that doesn't change the value
until it is enough to trick the optimizer */
tmp ^= 12543;
d = *cast(double*)
```
Even worse with CTFE, where you get values that are neither NaN,
nor infinity but larger then `.max`. And you cannot even
use `static if` to find out which reals are used in CTFE, because
CTFE might use different reals or reals on an other platform or
whatever. So to be able to find out which real you use, you need
to add more ugly code like
```
if (__ctfe)
{
if (real.max + 1 != real.infinity && real.max + 10 - 20 <
real.max)
{
...
}
else
{
}
}
```
Finally you end up writing several hundred lines of code for
something that would have fitted in one line without autoreals;
probably you would prefer to write a library (using heavy amount
of `asm` parts) with types `Float` and `Double` that is just
doing what float and double are normally supposed to do.
What I really dislike about this is, that you have no means to
escape from it, while the other way round it would be easy: If
you really want to use reals instead of double, you could just
use reals...
Re: DMC + Win32Api: Error: undefined identifier 'SetDCBrushColor'
Why gdi32.lib in dmc is not a Valid Library File?
Re: Anyone tried?
On 5/17/21 10:49 AM, Imperatorn wrote: https://www.educative.io/courses/programming-in-d-ultimate-guide That's the interactive version of (first half of) "Programming in D"[1]. The entire conversion was done by Educative and some editing was added by them. The main difference is the ability to compile and execute the code samples. I'm curious of others' opinion as well. Ali [1] http://ddili.org/ders/d.en/index.html
Re: Encryption
On Monday, 17 May 2021 at 16:54:18 UTC, noid wrote: Hi! I am pretty new on Dlang and I wanted to make a small password manager that used some sort of encryption on a file (for example AES256) and save a password to decrypt it later, so you can copy the password. I haven't done this specifically myself, but if I did, I'd probably use bindings to the C libsodium and let it do most the encryption work. this looks reasonable but again I haven't used myself. https://code.dlang.org/packages/libsodiumd Since it is a simple binding to the C library, you'd use it the same way you would from C itself and can look up tutorials for that and easily translate to D. I also don't know how I could store the password (for example in a SHA256 hash) for decrypting the files. Now this I have done myself, and again, I delegated the real work to a C library called argon2. My library is https://code.dlang.org/packages/arsd-official%3Aargon2 And my docs: http://arsd-official.dpldocs.info/arsd.argon2.html If you get the C argon2 library installed, then you can use that D module easily with the `encode` and `verify` functions.
Anyone tried?
https://www.educative.io/courses/programming-in-d-ultimate-guide
Re: PyD - accessing D class fields in Python
On Monday, 17 May 2021 at 16:54:07 UTC, mw wrote: On Tuesday, 19 March 2019 at 23:58:48 UTC, Bastiaan Veelo wrote: [...] I filed the issue here (still no response yet): https://github.com/ariovistus/pyd/issues/152 [...] https://github.com/symmetryinvestments/autowrap
Re: Encryption
On Monday, 17 May 2021 at 17:08:41 UTC, noid wrote: On Monday, 17 May 2021 at 17:03:39 UTC, Imperatorn wrote: On Monday, 17 May 2021 at 16:54:18 UTC, noid wrote: Hi! I am pretty new on Dlang and I wanted to make a small password manager that used some sort of encryption on a file (for example AES256) and save a password to decrypt it later, so you can copy the password. I couldn't find any way of doing encryption on Dlang, is there a lib that's better for doing this? Secured and some other libs i tried didn't quite work. I also don't know how I could store the password (for example in a SHA256 hash) for decrypting the files. https://code.dlang.org/search?q=crypto crypto prints the error i just posted last post, botan lib gives me this error: Try different compiler options (version=??? to make the static assert true). If still not working, log an issue on the library's git repo page.
Re: Encryption
On Monday, 17 May 2021 at 16:59:28 UTC, mw wrote: On Monday, 17 May 2021 at 16:54:18 UTC, noid wrote: Hi! I am pretty new on Dlang and I wanted to make a small password manager that used some sort of encryption on a file (for example AES256) and save a password to decrypt it later, so you can copy the password. I couldn't find any way of doing encryption on Dlang, is there a lib that's better for doing this? Secured and some other libs i tried didn't quite work. I also don't know how I could store the password (for example in a SHA256 hash) for decrypting the files. https://code.dlang.org/search?q=SHA okay thanks i'll take a look at those libs but what about AES256? the crypto lib gave me some errors every time i ran "dub run" about the crypto lib "cannot call impure function 'core.bitop.volatileStore'"
Re: Encryption
On Monday, 17 May 2021 at 17:03:39 UTC, Imperatorn wrote:
On Monday, 17 May 2021 at 16:54:18 UTC, noid wrote:
Hi! I am pretty new on Dlang and I wanted to make a small
password manager that used some sort of encryption on a file
(for example AES256) and save a password to decrypt it later,
so you can copy the password.
I couldn't find any way of doing encryption on Dlang, is there
a lib that's better for doing this? Secured and some other
libs i tried didn't quite work.
I also don't know how I could store the password (for example
in a SHA256 hash) for decrypting the files.
https://code.dlang.org/search?q=crypto
crypto prints the error i just posted last post, botan lib gives
me this error:
```
/home/anon/.dub/packages/memutils-1.0.4/memutils/source/memutils/utils.d:65:18:
error: class botan.cert.x509.x509cert.X509CertificateImpl member init is not
accessible
65 | return cast(TR)T.init;
| ^
/home/anon/.dub/packages/memutils-1.0.4/memutils/source/memutils/utils.d:65:18:
error: function botan.cert.x509.x509_obj.X509Object.init
(RefCounted!(DataSourceImpl, AppMem) input, const(string) labels) is not
callable using argument types ()
65 | return cast(TR)T.init;
| ^
/home/anon/.dub/packages/memutils-1.0.4/memutils/source/memutils/refcounted.d:31:52:
error: template instance memutils.utils.ObjectAllocator!(X509CertificateImpl,
ThreadMem).alloc!() error instantiating
31 | ret.m_object = ObjectAllocator!(T, ALLOC).alloc(args);
|^
/home/anon/.dub/packages/memutils-1.0.4/memutils/source/memutils/refcounted.d:199:29:
note: instantiated from here: opCall!()
199 |auto newObj = this.opCall();
| ^
/home/anon/.dub/packages/botan-1.12.19/botan/source/botan/cert/x509/x509cert.d:41:25:
note: instantiated from here: RefCounted!(X509CertificateImpl, ThreadMem)
41 | alias X509Certificate = RefCounted!X509CertificateImpl;
| ^
/home/anon/.dub/packages/botan-1.12.19/botan/source/botan/constants.d:98:73:
error: static assert (BOTAN_HAS_SIMD) is false
98 | version(SIMD_SSE2) {enum BOTAN_HAS_SIMD_SSE2 =
true; static assert(BOTAN_HAS_SIMD); }
|
^
/usr/bin/gdc failed with exit code 1.
```
Re: Encryption
On Monday, 17 May 2021 at 16:54:18 UTC, noid wrote: Hi! I am pretty new on Dlang and I wanted to make a small password manager that used some sort of encryption on a file (for example AES256) and save a password to decrypt it later, so you can copy the password. I couldn't find any way of doing encryption on Dlang, is there a lib that's better for doing this? Secured and some other libs i tried didn't quite work. I also don't know how I could store the password (for example in a SHA256 hash) for decrypting the files. https://code.dlang.org/search?q=crypto
Re: Encryption
On Monday, 17 May 2021 at 16:54:18 UTC, noid wrote: Hi! I am pretty new on Dlang and I wanted to make a small password manager that used some sort of encryption on a file (for example AES256) and save a password to decrypt it later, so you can copy the password. I couldn't find any way of doing encryption on Dlang, is there a lib that's better for doing this? Secured and some other libs i tried didn't quite work. I also don't know how I could store the password (for example in a SHA256 hash) for decrypting the files. https://code.dlang.org/search?q=SHA
Encryption
Hi! I am pretty new on Dlang and I wanted to make a small password manager that used some sort of encryption on a file (for example AES256) and save a password to decrypt it later, so you can copy the password. I couldn't find any way of doing encryption on Dlang, is there a lib that's better for doing this? Secured and some other libs i tried didn't quite work. I also don't know how I could store the password (for example in a SHA256 hash) for decrypting the files.
Re: PyD - accessing D class fields in Python
On Tuesday, 19 March 2019 at 23:58:48 UTC, Bastiaan Veelo wrote:
On Monday, 18 March 2019 at 22:25:10 UTC, clothlen wrote:
Howdy;
I'm trying to extend my Python program with D, but I'm having
trouble accessing a D class's
field/attribute/property/something.
My D file looks like this:
```
module simpletest;
import pyd.pyd;
import std.stdio;
class ExampleTest{
int _a = 3;
int a(){
return _a;
}
void a(int a){
this._a = a;
}
int b = 4;
}
extern(C) void PydMain() {
module_init();
wrap_class!(
ExampleTest,
Property!(ExampleTest.a),
Property!(ExampleTest.b)
// Member!("b")
Maybe you need `Member!(“b”, “rw”)`?
);
}
If that doesn’t work, maybe you find help by filing an issue on
PyD.
I filed the issue here (still no response yet):
https://github.com/ariovistus/pyd/issues/152
Just tried:
```
Member!("m_i", Mode!"rw"),
```
Still the same error:
```
/usr/local/lib/python3.6/dist-packages/pyd/infrastructure/pyd/make_wrapper.d(127): Error: no
property shim for type pyd.struct_wrap.Member!("m_i", Mode!"rw")
/usr/local/lib/python3.6/dist-packages/pyd/infrastructure/pyd/make_wrapper.d(137): Error: template instance
pyd.make_wrapper.class_decls!(0u, Foo, Member!("m_i", Mode!"rw"), Init!int, Init!(int, int), Property!(i,
Docstring!"A sample property of Foo."), BinaryOperatorX!("+", false, Guess), Def!(opSlice, PyName!"__iter__",
Range function()), Def!(foo, Docstring!"A sample method of Foo."), Def!(a), Def!(b), Def!(c), Def!(d), Def!(e),
Def!(f), Def!(g), Def!(h), Def!(j), Def!(k), Def!(l), Def!(m),
Def!(n)) error instantiating
```
Anyone know how to expose D class data member to Python?
Thanks!
Re: property functions
On Sunday, 16 May 2021 at 15:47:55 UTC, Adam D. Ruppe wrote: On Sunday, 16 May 2021 at 15:12:25 UTC, Nick wrote: Is this warning still valid? The @property thing doesn't do much. All it does is change typeof(a.prop) from function over to the return value of the function. (Which actually makes it required for the range empty and front things!) But since it doesn't do much it makes it very easy to misuse it too - putting it somewhere where it doesn't belong will NOT cause the compiler to issue an error. So that's why it is warned: the current behavior is extremely minimal and if that expands and you misused it, you'll see broken code down the line. But on the other hand, @property has been a do-nothing for a decade now, so I wouldn't expect that to change any time soon. My general rule is to put it on something that should be replaceable with a public data member. If you can't do that, don't make it @property. In particular, do NOT put it on something for the sole reason of not using () on the call. @property is not really related to parenthesis syntax. Only use it when it is specifically meant to be replaceable with a public member. Thanks for the detailed explanation. I guess the wording of the warning seems strange to me, in that it recommends not to use property functions; but, in actuality (and regardless?), these functions are used a lot (even in the standard library; at least from what I've seen). Also, although this warning is delivered, there is nothing in the documentation that explicitly addresses a concrete downside (or recommended limitation) to using them. However, your explanation does provide some context to this warning.
Re: ugly and/or useless features in the language.
On Sunday, 16 May 2021 at 16:16:22 UTC, H. S. Teoh wrote: I cannot live without auto return types and Voldemort types. They are my bread and butter. Take them away, and I might as well go back to C/C++. C++ has both? What I find ugly: - shared, and all of its quirks and incomplete implementation. Shared semantics are wrong, as in not safe. Someone with a theoretical background should have been consulted... I am not really sure why it was given semantics with no complete solution, you cannot evolve concurrency designs. - The fact that byte + byte cannot be assigned back to a byte without a cast. I dont think you should be able to do anything with bytes without a cast... - Attribute proliferation. We should have had type inference integrated into the language from the beginning, but alas, that ship has already long sailed and it's too late to change that now Why is it too late? I dont think it is.
Re: property functions
On Monday, 17 May 2021 at 14:56:21 UTC, Steven Schveighoffer wrote: It used to be required, but we removed that requirement a long time ago. yeah i remember ElementType required it last time i checked but that was a while ago indeed it is all fixed now
Re: property functions
On 5/16/21 11:47 AM, Adam D. Ruppe wrote: On Sunday, 16 May 2021 at 15:12:25 UTC, Nick wrote: Is this warning still valid? The @property thing doesn't do much. All it does is change typeof(a.prop) from function over to the return value of the function. (Which actually makes it required for the range empty and front things!) It used to be required, but we removed that requirement a long time ago. It was inconsistently applied (some features required @property, and some did not). -Steve
Re: dual-context deprecation
On Monday, 17 May 2021 at 14:35:51 UTC, Steven Schveighoffer wrote: [snip] The feature is deprecated in its current form. The issue as I understand it (i.e. very little) is that compilers other than DMD could not use this same way to implement dual contexts, and so they could not have the feature. This means that valid code in DMD would not compile on GDC or LDC. The way forward was to deprecate the mechanism used to implement it for DMD, and at some point tackle it in a backend-agnostic way. Personally, I don't know why we can't fix it so that it's portable, but I understand so little about compilers that I've pretty much stayed out of it. The feature is very much needed. -Steve That's a good summary. Thanks.
Re: dual-context deprecation
On Monday, 17 May 2021 at 14:35:51 UTC, Steven Schveighoffer
wrote:
On 5/17/21 9:47 AM, jmh530 wrote:
The code below (simplified from my actual problem) generates a
warning that member function b "requires a dual-context, which
is deprecated".
However when I look at the list of deprecated features [1],
I'm not seeing which one this is referring to. Is it a valid
deprecation?
I could only find this [2] reference to dual-contexts, which
suggests that the problem relates to passing aliases into
member functions. Moving it to a member function fixes the
problem. Alternately, I could make the alias part of Foo's
type. My use case it is just a little easier structured like
this, but I get that there are workarounds.
My bigger question is about why it isn't listed more than
anything. I.e., should I file something in bugzilla.
```d
struct Foo
{
double a;
this(double x)
{
this.a = x;
}
double b(alias inverse)()
{
return inverse(a);
}
}
void main()
{
auto foo = Foo(2.0);
auto x = foo.b!(a => (10.0 ^^ a))();
}
```
The feature is deprecated in its current form. The issue as I
understand it (i.e. very little) is that compilers other than
DMD could not use this same way to implement dual contexts, and
so they could not have the feature. This means that valid code
in DMD would not compile on GDC or LDC.
The way forward was to deprecate the mechanism used to
implement it for DMD, and at some point tackle it in a
backend-agnostic way.
Personally, I don't know why we can't fix it so that it's
portable, but I understand so little about compilers that I've
pretty much stayed out of it. The feature is very much needed.
-Steve
The dual context that warning is referring to is vthis2, which
the gdc maintainer struggle to implemented for the gdc compiler.
A correct fix involves templates having their own context.
-Alex
Re: dual-context deprecation
On 5/17/21 9:47 AM, jmh530 wrote:
The code below (simplified from my actual problem) generates a warning
that member function b "requires a dual-context, which is deprecated".
However when I look at the list of deprecated features [1], I'm not
seeing which one this is referring to. Is it a valid deprecation?
I could only find this [2] reference to dual-contexts, which suggests
that the problem relates to passing aliases into member functions.
Moving it to a member function fixes the problem. Alternately, I could
make the alias part of Foo's type. My use case it is just a little
easier structured like this, but I get that there are workarounds.
My bigger question is about why it isn't listed more than anything.
I.e., should I file something in bugzilla.
```d
struct Foo
{
double a;
this(double x)
{
this.a = x;
}
double b(alias inverse)()
{
return inverse(a);
}
}
void main()
{
auto foo = Foo(2.0);
auto x = foo.b!(a => (10.0 ^^ a))();
}
```
The feature is deprecated in its current form. The issue as I understand
it (i.e. very little) is that compilers other than DMD could not use
this same way to implement dual contexts, and so they could not have the
feature. This means that valid code in DMD would not compile on GDC or LDC.
The way forward was to deprecate the mechanism used to implement it for
DMD, and at some point tackle it in a backend-agnostic way.
Personally, I don't know why we can't fix it so that it's portable, but
I understand so little about compilers that I've pretty much stayed out
of it. The feature is very much needed.
-Steve
Re: dual-context deprecation
On Monday, 17 May 2021 at 13:51:32 UTC, Paul Backus wrote: [snip] See this issue for context: https://issues.dlang.org/show_bug.cgi?id=5710 Thanks. Lots of details there that I don't follow all of. I mentioned in the deprecation PR [1] that it was not listed in the list of deprecated features. [1] https://github.com/dlang/dmd/pull/9702
Re: dual-context deprecation
On Monday, 17 May 2021 at 13:47:28 UTC, jmh530 wrote: The code below (simplified from my actual problem) generates a warning that member function b "requires a dual-context, which is deprecated". However when I look at the list of deprecated features [1], I'm not seeing which one this is referring to. Is it a valid deprecation? See this issue for context: https://issues.dlang.org/show_bug.cgi?id=5710
dual-context deprecation
The code below (simplified from my actual problem) generates a
warning that member function b "requires a dual-context, which is
deprecated".
However when I look at the list of deprecated features [1], I'm
not seeing which one this is referring to. Is it a valid
deprecation?
I could only find this [2] reference to dual-contexts, which
suggests that the problem relates to passing aliases into member
functions. Moving it to a member function fixes the problem.
Alternately, I could make the alias part of Foo's type. My use
case it is just a little easier structured like this, but I get
that there are workarounds.
My bigger question is about why it isn't listed more than
anything. I.e., should I file something in bugzilla.
```d
struct Foo
{
double a;
this(double x)
{
this.a = x;
}
double b(alias inverse)()
{
return inverse(a);
}
}
void main()
{
auto foo = Foo(2.0);
auto x = foo.b!(a => (10.0 ^^ a))();
}
```
[1] https://dlang.org/deprecate.html
[2]
https://forum.dlang.org/thread/mkeumwltwiimkrelg...@forum.dlang.org
Re: stack out of scope ?
I now compile with the following flags, ``` # DIP25 , return ref # DIP1000 , scoped pointers # --boundscheck=on , perform array bounds check # --safe-stack-layout , enable safe stack layout #--D , generate documentation, #--g , symbolic debug info #--d-debug ,it enables all debug checks (i.e. asserts, boundschecks, contracts and invariants) as well as acting as -d-debug=1. #--w , treat warning as error #--de: halt on deprecated ldc2 --dip1000 --dip25 --safe-stack-layout --boundscheck=on --D --g --w --de --d-debug test.d ```
Re: stack out of scope ?
Thanks. Alot of info,but the flag dip1000 is not show in help hidden. The solution seems to be compiling with flag dip1000 and putting @safe on top on the file then all the errors are catched by the compiler.
