Re: protobuf-d
On Tuesday, 29 September 2020 at 15:38:43 UTC, Robert Aron wrote: 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. ImageAnnotatorClient isn't described in any of *.proto file in https://github.com/googleapis/googleapis repository. (I found only ImageAnnotator) So, maybe here is messed up proto3 and gRPC or something like it?
Trying to create a trivial 64 bit D Lang DLL on a Windows 10 machine and cant get past linking.
module user;
export { int myAddSeven(int a, int b); }
void main()
{
int total = myAddSeven(2, 3);
}
dmd -m64 -c user.d
module mydll;
export extern(D) {
int myAddSeven(int a, int b) { return a+b+7; } /* <--
function body */
}
dmd -c -shared -m64 mydll.d
link mydll.obj /DLL /NOENTRY
Microsoft (R) Incremental Linker Version 14.27.29111.0
Copyright (C) Microsoft Corporation. All rights reserved.
Creating library mydll.lib and object mydll.exp
link user.obj /implib:mydll.lib
Microsoft (R) Incremental Linker Version 14.27.29111.0
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : fatal error LNK1104: cannot open file 'phobos64.lib'
or when I give the linker phobos64.lib
link user.obj /implib:mydll.lib /LIBPATH:C:\D\dmd2\windows\lib64
Microsoft (R) Incremental Linker Version 14.27.29111.0
Copyright (C) Microsoft Corporation. All rights reserved.
user.obj : error LNK2019: unresolved external symbol
__imp__D4user10myAddSevenFiiZi referenced in function _Dmain
phobos64.lib(stacktrace_1be8_3e5.obj) : error LNK2019: unresolved
external symbol snprintf referenced in function
_D4core3sys7windows10stacktrace10StackTrace13resolveNoSyncFAxmZAAa
phobos64.lib(demangle_c96_79b.obj) : error LNK2001: unresolved
external symbol snprintf
phobos64.lib(parseoptions_e2c_21b.obj) : error LNK2001:
unresolved external symbol snprintf
phobos64.lib(parseoptions_e2c_21b.obj) : error LNK2019:
unresolved external symbol sscanf referenced in function
_D4core8internal12parseoptions5parseFNbNiAxaKANgaKfQkZb
user.exe : fatal error LNK1120: 3 unresolved externals
Re: Memory management
On Tuesday, 29 September 2020 at 16:03:39 UTC, IGotD- wrote: That little simple example shows that you don't necessarily need to know things in advance in order to have static lifetimes. However, there are examples where there is no possibility for the compiler to infer when the object goes out of scope. Multiple ownership is an obvious example of that. Seems like a mix of Go and Rust... People will probably end up using array indexes instead of references... Just like in Rust.
Re: Accessing non-binary Unicode properties with std.uni
On Tue, Sep 29, 2020 at 06:14:45PM +, Chloé Kekoa via Digitalmars-d-learn wrote: > On Tuesday, 29 September 2020 at 17:04:51 UTC, H. S. Teoh wrote: > > OTOH, the relevant Unicode data file that contains East_Asian_Width > > data (EastAsianWidth.txt) is relatively straightforward to parse. > > In one of my projects, I wrote a little helper program to parse this > > file and generate a function that tells me if a given dchar is wide > > or narrow. > > Thank you. Analyzing the data file seems simple enough. :) If you're daring, you can try parsing it at compile-time... but in this case, it's kinda pointless, since the data file doesn't change, so statically generating the desired code as a separate step seems a more logical thing to do. T -- Curiosity kills the cat. Moral: don't be the cat.
Re: Deprecation in traits
On 9/29/20 10:08 AM, Frak wrote:
Hi folks,
I've this:
/Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711):
Deprecation: function `std.typecons.Nullable!long.Nullable.get_` is
deprecated - Implicit conversion with `alias Nullable.get this` will be
removed after 2.096. Please use `.get` explicitly.
I'm trying to find out WHERE this is generated to fix it, dependency
included, without success.
Suggestions?
I've just ported my code to 2.094 and had to clean up that issue.
Luckily, in my case they were all in user code. I had to access my
Nullable objects with .get:
if (n) {
// n.foo();<-- from
n.get.foo(); <-- to
}
So, look at all your Nullable objects maybe.
Ali
Re: Memory management
On Tuesday, 29 September 2020 at 10:57:07 UTC, novice3 wrote: Naive newbie question: Can we have (in theory) in D lang memory management like V lang? Quote: https://github.com/vlang/v/blob/master/doc/docs.md#memory-management "V doesn't use garbage collection or reference counting. The compiler cleans everything up during compilation. If your V program compiles, it's guaranteed that it's going to be leak free." Completely avoiding the question about D, all it says in that section is "The strings don't escape draw_text, so they are cleaned up when the function exits. In fact, the first two calls won't result in any allocations at all. These two strings are small, V will use a preallocated buffer for them." That's a toy example. It would be hard to mess that up in C, and I'd expect it to be easy for the compiler to handle it.
Re: Deprecation in traits
On 9/29/20 1:08 PM, Frak wrote: Hi folks, I've this: /Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711): Deprecation: function `std.typecons.Nullable!long.Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly. I'm trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions? Because it's probably coming from a constraint, you probably can't figure out the exact usage. What's more annoying is that likely it is a spurious warning. A lot of traits "try something", and then alias to false or true depending on what works. But it's not going to make a difference in your code. It's one of the most annoying things in the library. If you see this warning coming from *your* code, then you should fix it. But it will tell you the location if that was the case, not std.traits. -Steve
Re: Accessing non-binary Unicode properties with std.uni
On Tuesday, 29 September 2020 at 17:04:51 UTC, H. S. Teoh wrote: OTOH, the relevant Unicode data file that contains East_Asian_Width data (EastAsianWidth.txt) is relatively straightforward to parse. In one of my projects, I wrote a little helper program to parse this file and generate a function that tells me if a given dchar is wide or narrow. Thank you. Analyzing the data file seems simple enough. :)
Re: Safe to remove AA elements while iterating over it via .byKeyValue?
On Tue, Sep 29, 2020 at 09:56:41AM +, ikod via Digitalmars-d-learn wrote: > Hello, > > Sorry if I unintentionally hurt anybody in this thread. > I'll try to implement sane and correct iteration behavior for AA > without noticeable performance loss, and propose it if I succeed. No feelings were hurt, don't worry. :-) I just wanted to point out that it's quite a tricky issue, and solving it may not be quite as easy as it appears. But if you manage to break new ground in this area, I'd be very interested to hear! T -- It's amazing how careful choice of punctuation can leave you hanging:
Deprecation in traits
Hi folks, I've this: /Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711): Deprecation: function `std.typecons.Nullable!long.Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly. I'm trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions?
Re: Accessing non-binary Unicode properties with std.uni
On Tue, Sep 29, 2020 at 04:22:18PM +, Dukc via Digitalmars-d-learn wrote:
> On Monday, 28 September 2020 at 18:23:43 UTC, Chloé Kekoa wrote:
> > The documentation of std.uni [1] says that the unicode struct
> > provides sets for several binary properties. I am looking for a way
> > to query non-binary properties of a character. Is that possible with
> > std.uni or do I need to use a third-party library?
> >
> > I am specifically interested in the East_Asian_Width property [2]
> > (which has six allowed values). Trying to access
> > std.uni.unicode.East_Asian_Width results in the error message:
> >
> > > No unicode set by name East_Asian_Width was found.
> >
> > [1]: https://dlang.org/library/std/uni.html
> > [2]: https://www.unicode.org/reports/tr11/tr11-38.html
>
> It seems the East Asian width is Unicode standard 13.0, while Phobos
> implements 6.2. So seems like ca case for a third-party library :(.
[...]
OTOH, the relevant Unicode data file that contains East_Asian_Width data
(EastAsianWidth.txt) is relatively straightforward to parse. In one of
my projects, I wrote a little helper program to parse this file and
generate a function that tells me if a given dchar is wide or narrow.
Here's the generated function (just copy-n-paste this into your code, no
need for yet another external library dependency):
bool isWide(dchar ch) @safe pure nothrow @nogc
{
if (ch < 63744)
{
if (ch < 12880)
{
if (ch < 11904)
{
if (ch < 4352) return false;
if (ch < 4448) return true;
if (ch == 9001 || ch == 9002) return true;
return false;
}
else if (ch < 12351) return true;
else
{
if (ch < 12353) return false;
if (ch < 12872) return true;
return false;
}
}
else if (ch < 19904) return true;
else
{
if (ch < 43360)
{
if (ch < 19968) return false;
if (ch < 42183) return true;
return false;
}
else if (ch < 43389) return true;
else
{
if (ch < 44032) return false;
if (ch < 55204) return true;
return false;
}
}
}
else if (ch < 64256) return true;
else
{
if (ch < 65504)
{
if (ch < 65072)
{
if (ch < 65040) return false;
if (ch < 65050) return true;
return false;
}
else if (ch < 65132) return true;
else
{
if (ch < 65281) return false;
if (ch < 65377) return true;
return false;
}
}
else if (ch < 65511) return true;
else
{
if (ch < 127488)
{
if (ch == 110592 || ch == 110593) return true;
return false;
}
else if (ch < 127570) return true;
else
{
if (ch < 131072) return false;
if (ch < 262142) return true;
return false;
}
}
}
}
Here's the utility that generated this code:
/**
* Simple program to parse EastAsianWidth.txt to extract some useful
info.
*/
import std.algorithm;
import std.conv;
import std.range;
import std.regex;
import std.stdio;
struct CodeRange
{
dchar start, end;
bool overlaps(CodeRange cr)
{
return ((start >= cr.start && start < cr.end) ||
(end >= cr.start && end < cr.end));
}
unittest
{
assert(CodeRange(1,11).overlaps(CodeRange(11,12)));
assert(!CodeRange(1,10).overlaps(CodeRange(11,12)));
}
void merge(CodeRange cr)
{
start = min(start, cr.start);
end = max(end, cr.end);
}
unittest
{
auto cr = CodeRange(10,20);
cr.merge(CodeRange(20,30));
Re: Accessing non-binary Unicode properties with std.uni
On Monday, 28 September 2020 at 18:23:43 UTC, Chloé Kekoa wrote: The documentation of std.uni [1] says that the unicode struct provides sets for several binary properties. I am looking for a way to query non-binary properties of a character. Is that possible with std.uni or do I need to use a third-party library? I am specifically interested in the East_Asian_Width property [2] (which has six allowed values). Trying to access std.uni.unicode.East_Asian_Width results in the error message: No unicode set by name East_Asian_Width was found. [1]: https://dlang.org/library/std/uni.html [2]: https://www.unicode.org/reports/tr11/tr11-38.html It seems the East Asian width is Unicode standard 13.0, while Phobos implements 6.2. So seems like ca case for a third-party library :(.
Re: Memory management
On Tuesday, 29 September 2020 at 15:47:09 UTC, Ali Çehreli wrote:
I am not a language expert but I can't imagine how the compiler
knows whether an event will happen at runtime. Imagine a server
program allocates memory for a client. Let's say, that memory
will be deallocated when the client logs out or the server
times that client out. The compiler cannot know either of that
will ever happen, right?
Ali
It doesn't need to know when a certain event happens but based on
ownership and program flow. Let's think Rust for a moment.
You get a connection and you allocate some metadata about it.
Then you put that metadata on a list and the list owns that
object. It will stay there as long there is a connection and the
program can go and do other things, the list still owns the
metadata.
After a while the client disconnects and the program finds the
metadata in the list and removes it and puts it in a local
variable. Some cleanup is one but the metadata is still owned by
the local variable and when that variable goes out of scope
(basically end of a {} block), then it will deallocated.
It's really a combination of ownership and scopes.
That little simple example shows that you don't necessarily need
to know things in advance in order to have static lifetimes.
However, there are examples where there is no possibility for the
compiler to infer when the object goes out of scope. Multiple
ownership is an obvious example of that.
Re: Memory management
On 9/29/20 3:57 AM, novice3 wrote:> Naive newbie question: > > Can we have (in theory) in D lang memory management like V lang? > > Quote: > https://github.com/vlang/v/blob/master/doc/docs.md#memory-management > > "V doesn't use garbage collection or reference counting. The compiler > cleans everything up during compilation. If your V program compiles, > it's guaranteed that it's going to be leak free." I am not a language expert but I can't imagine how the compiler knows whether an event will happen at runtime. Imagine a server program allocates memory for a client. Let's say, that memory will be deallocated when the client logs out or the server times that client out. The compiler cannot know either of that will ever happen, right? Ali
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: help: cannot build profdump, dub error (bug): Enforcement failed
On 9/29/20 4:38 PM, drug wrote: It reproduces. As a workaround you can use ``` dub run profdump ``` this command works as expected, I guess it is a bug of dub Do not execute this command in cloned `profdump` repository - it will fail too. It works if is called from other places, for example in home.
Re: help: cannot build profdump, dub error (bug): Enforcement failed
On 9/29/20 3:41 PM, mw wrote: I remember I used to able to build this package: https://github.com/AntonMeep/profdump but now, I cannot. Since that package haven't changed for 2 years, maybe it's a dub bug? System information $ uname -a Linux 4.15.0-117-generic #118-Ubuntu SMP Fri Sep 4 20:02:41 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ /usr/bin/dub --version DUB version 1.23.0, built on Sep 27 2020 $ /usr/bin/dmd --version DMD64 D Compiler v2.094.0 Copyright (C) 1999-2020 by The D Language Foundation, All Rights Reserved written by Walter Bright $ /usr/bin/dub build -v Using dub registry url 'https://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json ... ... No valid package found in current working directory: Enforcement failed Enforcement failed Bug Description Enforcement failed How to reproduce? ``` git clone https://github.com/AntonMeep/profdump cd profdump dub build ``` https://github.com/dlang/dub/issues/2017 It reproduces. As a workaround you can use ``` dub run profdump ``` this command works as expected, I guess it is a bug of dub
Re: Array Slicing
On Sunday, 27 September 2020 at 14:25:34 UTC, H. S. Teoh wrote: On Sun, Sep 27, 2020 at 01:59:07PM +, DMon via Digitalmars-d-learn wrote: Are these in the Specification or Phobos? See: https://dlang.org/articles/d-array-article.html T Or in Articles? Thanks, Teoh.
help: cannot build profdump, dub error (bug): Enforcement failed
I remember I used to able to build this package: https://github.com/AntonMeep/profdump but now, I cannot. Since that package haven't changed for 2 years, maybe it's a dub bug? System information $ uname -a Linux 4.15.0-117-generic #118-Ubuntu SMP Fri Sep 4 20:02:41 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ /usr/bin/dub --version DUB version 1.23.0, built on Sep 27 2020 $ /usr/bin/dmd --version DMD64 D Compiler v2.094.0 Copyright (C) 1999-2020 by The D Language Foundation, All Rights Reserved written by Walter Bright $ /usr/bin/dub build -v Using dub registry url 'https://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json ... ... No valid package found in current working directory: Enforcement failed Enforcement failed Bug Description Enforcement failed How to reproduce? ``` git clone https://github.com/AntonMeep/profdump cd profdump dub build ``` https://github.com/dlang/dub/issues/2017
Memory management
Naive newbie question: Can we have (in theory) in D lang memory management like V lang? Quote: https://github.com/vlang/v/blob/master/doc/docs.md#memory-management "V doesn't use garbage collection or reference counting. The compiler cleans everything up during compilation. If your V program compiles, it's guaranteed that it's going to be leak free."
Re: Safe to remove AA elements while iterating over it via .byKeyValue?
Hello, Sorry if I unintentionally hurt anybody in this thread. I'll try to implement sane and correct iteration behavior for AA without noticeable performance loss, and propose it if I succeed. Igor
Re: App hangs, GC.collect() fixet it. Why?
On Monday, 28 September 2020 at 21:58:31 UTC, Steven Schveighoffer wrote: On 9/28/20 3:28 PM, Bastiaan Veelo wrote: I’m leaning towards ditching the memory mapped I/O on the D end, and replace it by regular serialisation/deserialisation. That will be a manual rewrite though, which is a bit of bummer as memory mapped files are widely used in our Pascal code. But this will probably give the best end result. 2 things: 1. I agree this is the answer. If you ever ditch the old Pascal code, then you can reactivate the memory-mapped code. 2. You can possibly do the translation outside of your programs. That is, it wouldn't be entirely impossible to simply have a process running that ensures the "D view" and the "Pascal view" of the same file is kept in sync. Then you can keep the memory mapped code the same, and just define sane structures in your D code. If you aren't required to have both Pascal and D programs reading and writing the file at the same time, this shouldn't be a problem. There is no need to run both versions concurrently. The issue is that design offices typically maintain a library of past designs for as long as they are in existence, to build new designs off of. So being able to read or import the files that were written with an ancient version of our software is very valuable. Our old compiler offered two alternatives for file i/o: one where all elements are of the same type, the other one (memory mapped files) being the "only" option for files of mixed type. Ideally, the structs that are used for i/o do not have any pointers in them, and certainly in the more recent file versions that would be the case. In older versions that might not be the case; then the pointers obviously would be given meaningful values after the structs would have been read back in. These cases we would be able to work around, though, by converting the old structs to new ones upon import. BTW, one further thing I don't understand -- if this is memory mapped data, how come it has issues with the GC? And what do the "pointers" mean in the memory mapped data? I'm sure there's good answers, and your actual code is more complex than the simple example, but I'm just curious. The main problem is that the transpiler doesn't know which structs are used for i/o and would need 1-byte alignment, and which structs have pointers into GC memory and must not be 1-byte aligned. The alternative to switching to serialisation/deserialisation is to stay with the automated translation of the memory mapped file implementation, not automatically 1-byte align every struct but manually align the ones that are used in i/o. This is however sensitive to mistakes, and the translated mmfile implementation has a bit of a smell to it. It is also not portable, as it uses the WinAPI directly. Still, it may be the quickest route to get us back on track. I am very glad to have identified the problem, and there being ways to deal with it. I just hope this will be the last big hurdle :-) -Bastiaan.
Re: Safe to remove AA elements while iterating over it via .byKeyValue?
On Sunday, 27 September 2020 at 13:02:04 UTC, Per Nordlöw wrote:
Is it safe to remove AA-elements from an `aa` I'm iterating
over via aa.byKeyValue?
I'm currently doing this:
foreach (ref kv; aa.byKeyValue)
{
if (pred(kv.key))
aa.remove(kv.key); // ok?
}
if (aa.length == 0)
aa = null;
Is there a better way?
If you're okay with the allocation that comes with it:
foreach(k; aa.keys)
{
if(pred(key)) aa.remove(key);
}
