Re: dub windows unrecognised file extension a
On Sunday, 9 September 2018 at 04:53:05 UTC, Nicholas Wilson
wrote:
On Sunday, 9 September 2018 at 04:01:30 UTC, Nicholas Wilson
wrote:
On windows with dub it seems to be creating libfoo.a instead
of foo.lib, I don't think I changed any settings. Old build
based on 2.078 DMDFE seem to have built .lib but LDC based on
2.082 seems to be building .a
This definitely seems to be dubs fault: it passes
-of/path/to/output/libFoo.a to LDC which compiles. `dub
describe` also has
{
...
"packages" : [
...
{
...
"targetFileName" : "libFoo.a",
https://github.com/dlang/dub/pull/1559
Ugh time to recompile LLVM & LDC again.
Re: dub windows unrecognised file extension a
On Sunday, 9 September 2018 at 04:01:30 UTC, Nicholas Wilson
wrote:
On windows with dub it seems to be creating libfoo.a instead of
foo.lib, I don't think I changed any settings. Old build based
on 2.078 DMDFE seem to have built .lib but LDC based on 2.082
seems to be building .a
This definitely seems to be dubs fault: it passes
-of/path/to/output/libFoo.a to LDC which compiles. `dub describe`
also has
{
...
"packages" : [
...
{
...
"targetFileName" : "libFoo.a",
dub windows unrecognised file extension a
On windows with dub it seems to be creating libfoo.a instead of foo.lib, I don't think I changed any settings. Old build based on 2.078 DMDFE seem to have built .lib but LDC based on 2.082 seems to be building .a
Re: Is it's correct to say that ALL types that can grow are place on heap?
On 09/08/2018 02:19 AM, Suliman wrote:
> Is it's correct to say that ALL types that can grow are place on heap
> and types that not growing (int, char, pointer) are place on stack?
The question is not that simple. :)
First, there is also the area used for objects that are static and
object that are defined at module scope. That is different from both the
call stack and the heap. Let's ignore them...
There are automatic objects like local variables inside a function and
function parameters. They normally live on the stack. (However, the
compiler may pass some parameters in CPU registers without allocating
any memory at all.)
As you say, whenever memory is dynamic in nature e.g. we don't know the
size before hand, the memory is normally allocated from the heap.
However, heap can be used for allocating even an int:
import std.stdio;
void main() {
auto p = new int(42);
writeln(p);
writeln(*p);
}
Although the memory used for the elements of a dynamic array is on the
heap, the slice itself is usually on the stack:
import std.stdio;
void main() {
auto arr = [ 42 ];
writeln("Local slice variable is at ", ); // stack
writeln("The elements of the array are at ", arr.ptr); // heap
}
Then there are member variables of a user-defined type: Obviously, those
variables are wherever the actual object lives.
> Or there is some exceptions?
>
> Is there any tools that can visualize place of data in memory?
I think there are some debuggers that visualize data like that but I
don't have experience with those.
Ali
Re: thread phobos and creating threads
On Saturday, 8 September 2018 at 18:21:07 UTC, drug wrote:
On 08.09.2018 20:59, Marcin wrote:
void main()
{
snipped
}
This? https://run.dlang.io/is/SHyCXA
Thanks :)
Re: thread phobos and creating threads
//Ten przyklad po prostu tworzy wątek w którym są trzy obiekty
import core.thread;
import std.stdio: write, writeln, writef, writefln;
class Sinus{
double a;
this(){writeln("No Args");}
this(double a){writeln("U give 1 argument");
writeln(sin(a));}
this(double[]a){writeln("U give an array");
foreach(double arg; a){writeln(sin(arg));}}
double sin(double argument){return
core.stdc.math.sin(argument);}
}
void main()
{
new Thread({
auto jeden= new Sinus();
auto dwa= new Sinus(11);
auto trzy= new Sinus([1,2]);
// Codes to run in the newly created thread.
}).start();
}
Ok, Finally I've get it to work.
Re: thread phobos and creating threads
On 08.09.2018 20:59, Marcin wrote:
void main()
{
snipped
}
This? https://run.dlang.io/is/SHyCXA
Re: thread phobos and creating threads
https://run.dlang.io/is/PQkOfF
How to make it work?
void main()
{
import core.stdc.math : sin;
import core.thread;
import std.stdio : write, writeln, writef, writefln;
class DerivedThread : Thread
{
double d;
this()
{
super();
}
this(double a)
{
super();
this.d = sin(a);
writeln(d);
this.getD();
}
private:
void setD(double d)
{
this.d = d;
}
double getD()
{
writeln(d);
return d;
}
void run()
{
// Derived thread running.
}
}
// create and start instances of each type
auto derived = new DerivedThread(22).start().setD(11).getD();
}
Re: thread phobos and creating threads
I made somthing else... it works at the moment. https://run.dlang.io/is/KdOeRz But i need somthing like this to work: https://run.dlang.io/is/lGD5YQ
thread phobos and creating threads
Ive got problem with https://run.dlang.io/is/4a4CJp Why it prints 111 forever?
Re: Error: expression `update` of type `void` does not have a boolean value
On Saturday, 8 September 2018 at 03:12:56 UTC, Josphe Brigmo
wrote:
auto foo(bool update = false)()
{
static if(update)
{ }
}
and the compiler, after upgrading to 2.082 from 2.080 now says:
Error: expression `update` of type `void` does not have a
boolean value
when update is clearly a bool.
Why the hell is the compiler now thinking update is a void?
1. This code compiles fine in a test app and 2. when I rename
update to something else it works fine.
2. There is no other use of update in the entire module(not
that it should matter)
Seems this is a compiler bug but only has a problem in context.
Remember, it worked find before I updated dmd and there is no
reason why it shouldn't work.
- put
`pragma(msg, __FILE_FULL_PATH__ ~ "(" ~ __LINE__.stringof ~ "):" ~
typeof(return).stringof);`
in your update function.
- recompile.
- look at the compiler output
You should be sure at this point if the problem comes from your
update function of from the recent addition in object.d
Re: Process in parallel and output result to stdout theread-safely
On 09/03/2018 08:13 PM, Dr.No wrote:
But it in the middle of output, I got output like this:
outjson = {"barCode":"20","ade":"20"}♪◙outjson =
{"barCode":"X21","ade":"21"}
also there's that extra ♪◙ character. Thos sounds memory violation
somewhere.
This only happens when using parallel. Any guess what's possibily happeing?
If that only ever happens at line breaks, then that doesn't necessarily
look like memory corruption to me.
I looked around a bit and found code page 437 [1]. It has those
characters at 0xD and 0xA which is where ASCII has \r and \n. So it
might be that code page 437 is used when displaying that particular
entry. Why that would happen, I have no idea.
To get better help, you should post a complete test case that people can
just copy/paste. That includes imports, a `main` function, and the
command you use to compile. Also add information about your environment
(OS, compiler version).
[1] https://en.wikipedia.org/wiki/Code_page_437
Re: Process in parallel and output result to stdout theread-safely
Does anyone have some tips to try trace the error with debug or so? I haven't fixed this issue yet... any help is very appreciated
Re: std.process: spawnProcess
On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote:
From what I can see, processes created with std.process:
spawnProcess are not terminated when the creating process
terminates, i.e. it seems Config.detached is the default for
these process.
Is there a way of all spawned processes being terminated on
main termination?
On Python std lib, there's a way to daemonize a process [1]. I
tried to accomplish something equivalent by spawning a process
inside a daemon thread in D:
```
auto daemonizedProc() {
import std.process;
import std.stdio;
auto pid = spawnProcess(["telnet"]);
writeln(pid.processID);
}
void main() {
import core.thread;
auto t = new Thread();
t.isDaemon(true);
t.start();
// just to see it running for a few secs..
Thread.sleep(10.seconds);
}
```
Based on my tests, whenever the main process exits (which is
called "proctest" in the output bellow) the spawned process was
terminated as a result as well, I tested on Linux:
```
~/repos/dlang master*
❯ ps -ax | egrep "telnet|proctest"
14456 pts/13 S+ 0:00 ./proctest
14458 pts/13 S+ 0:00 /usr/bin/telnet
14537 pts/7S+ 0:00 grep -E telnet|proctest
~/repos/dlang master*
❯ ps -ax | egrep "telnet|proctest"
14456 pts/13 S+ 0:00 ./proctest
14458 pts/13 S+ 0:00 /usr/bin/telnet
14633 pts/7S+ 0:00 grep -E telnet|proctest
~/repos/dlang master*
❯ ps -ax | egrep "telnet|proctest"
14731 pts/7S+ 0:00 grep -E telnet|proctest
```
[1] -
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Process
Re: Error: expression `update` of type `void` does not have a boolean value
On Saturday, 8 September 2018 at 07:30:35 UTC, Alex wrote: On Saturday, 8 September 2018 at 06:56:40 UTC, Josphe Brigmo wrote: My project does not use the term update at all in any other context except that one. But I did find: void update(K, V, C, U)(ref V[K] aa, K key, scope C create, scope U update) Ok... found something here: https://dlang.org/changelog/2.082.0.html#require_update and here: https://dlang.org/spec/hash-map.html#advanced_updating It seems, they were added in 2.082.0. No idea why they are conflicting with your existing code, however... And even whether they are the source of conflict... obviously who ever added it screwed the pooch.
Re: std.process: spawnProcess
On Sat, 2018-09-08 at 10:24 +, FreeSlave via Digitalmars-d-learn wrote: > On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote: > > From what I can see, processes created with std.process: > > spawnProcess are not terminated when the creating process > > terminates, i.e. it seems Config.detached is the default for > > these process. > > No, detached is not default. By default you should call wait on > processes to free OS resources. Process may stay as zombie > otherwise and it can be visible in process manager. Annoying but yes, it looks like having a global registry of processes has to be created so they can be killed on main termination. :-( Though I am going to tinker with Basile B's suggestion of using a managing object with a destructor to see if that can avoid the global registry. > > Is there a way of all spawned processes being terminated on > > main termination? > > You probably need to register all child processes. Or spawn them > as detached so you won't need to worry about freeing them. Detached is not a good idea, the spawned processes should not outlive the spawning process. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Returning dynamic array from the function?
On Sat, 08 Sep 2018 10:22:38 +, SuperPrower wrote: > Also, is this me and my bad English, or first comment in code in this > paragraph (linked above, not in the discussion) is supposed to be > something different? Shouldn't it be reference? Static arrays are value types, so the values are copied (see section 12.1.2 on that page). That said, static arrays do make that example a bit strange.
Re: std.process: spawnProcess
On Friday, 7 September 2018 at 16:44:09 UTC, Russel Winder wrote: I guess this might work on Windows, but I am on Linux and OSX, so I'll have to try another route. On Posix systems you may try using SIGCHLD handler. Google for exact examples.
Re: Returning dynamic array from the function?
On Saturday, 8 September 2018 at 10:05:31 UTC, rikki cattermole wrote: onReceive: "The event handler that receives incoming data. Be sure to copy the incoming ubyte[] since it is not guaranteed to be valid after the callback returns." It could be a buffer on the stack, either way, .dup it before you cast. Yeah, it worked, thank you. I knew it was something trivial like that. It appears I slightly misunderstood by this paragraph https://dlang.org/spec/arrays.html#array-copying - I missed that slice operator is supposed to be on the left-side rather than right (I thought adding `[]` to the `data` would do the trick). Also, is this me and my bad English, or first comment in code in this paragraph (linked above, not in the discussion) is supposed to be something different? Shouldn't it be reference?
Re: std.process: spawnProcess
On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote: From what I can see, processes created with std.process: spawnProcess are not terminated when the creating process terminates, i.e. it seems Config.detached is the default for these process. No, detached is not default. By default you should call wait on processes to free OS resources. Process may stay as zombie otherwise and it can be visible in process manager. Is there a way of all spawned processes being terminated on main termination? You probably need to register all child processes. Or spawn them as detached so you won't need to worry about freeing them.
Re: How to understand context type of a delegate?
On Wednesday, 5 September 2018 at 16:53:42 UTC, NX wrote: Is there a way to know what kind of context a delegate has either in compile time or runtime? Also is there any way to check whether a pointer legitimately points to an Object instance? No and no. I was fighting this problem in std.signals but found only one way to fix that without breaking backwards compatibility: we can use core.memory.GC class in order to check whether the object was allocated by GC (GC.addrOf). If it was, we need to retain the delegate context pointer to prevent accidental deallocation of this class by GC. And if the object is not managed by GC, it means that the delegate's context is a simple anonymous function, struct function, or manually allocated delegate's heap (there are few more cases though). In this case we just allow the user to manage this object manually. So if he decides to deallocate the entity behind the context pointer, he should be ready for a segmentation fault if he didn't remove an object from listeners before deallocation. The main reason why std.signals allows only objects to be used as a delegate context is that every object is tracked by D runtime (by the so-called Monitor object) and even in the case of manual deallocation (if you're using the std.experimental.allocator), you will be notified about object destruction if you were subscribed to this event. This makes the implementation extremely safe, but the author of the original library didn't finish his work properly. So std.signals now is a good candidate for replacement. I'm working on the fix and will create a pull request soon. Not sure if it will be accepted, but this module definitely needs to be replaced. If you want to join me in this work, I can share additional details about the situation around std.signals in general. If you don't want to spend your time on this, check this module: https://github.com/buggins/dlangui/blob/master/src/dlangui/core/signals.d - it's a part of the DlangUI project which already contains most of the things you may need.
Re: Returning dynamic array from the function?
On 08/09/2018 9:46 PM, SuperPrower wrote:
On Saturday, 8 September 2018 at 09:36:21 UTC, rikki cattermole wrote:
We're going to need to see a minified version of the code to see what
you're doing.
Sure, here it is:
```
auto getBoards()
{
string[] boardList;
auto url = baseUrl ~ "/api/v2/boards";
auto http = HTTP(url);
http.method = HTTP.Method.get;
http.onReceive = (ubyte[] data) {
auto content = cast(string) data[];
auto content = cast(string)(data.dup);
boardList = strip(content, "[", "]").split(",");
foreach (ref b; boardList) {
b = strip(b, `"`);
}
return data.length;
};
http.perform();
writeln(boardList);
return boardList;
}
```
This is a member function of some class. It doesn't really have any
fields, so I left if out. In it, I use curl library to getch some data
and split it. Next, I try to use this function to get this list:
```
Fetcher fetcher = new Fetcher;
auto boards = fetcher.getBoards();
writeln(boards);
```
I printed array twice: inside the function and after return. Here is the
output:
```
["a", "burg", "cyb", "d", "lain", "mu", "new", "tech", "test", "u", "v",
"all"]
[x"F9"c, x"FA 01 00 00"c, "\0\0\0", "d", "lain", "mu", "new", "tech",
"test", "u", "v", "all"]
```
As you can see, when outside of the funtion, first few elements of the
array contain garbage. I would like to know both why this happens and
how do I avoid it (i.e. what is the correct way of returning dynamic
array).
onReceive:
"The event handler that receives incoming data. Be sure to copy the
incoming ubyte[] since it is not guaranteed to be valid after the
callback returns."
It could be a buffer on the stack, either way, .dup it before you cast.
Re: Returning dynamic array from the function?
On Saturday, 8 September 2018 at 09:36:21 UTC, rikki cattermole
wrote:
We're going to need to see a minified version of the code to
see what you're doing.
Sure, here it is:
```
auto getBoards()
{
string[] boardList;
auto url = baseUrl ~ "/api/v2/boards";
auto http = HTTP(url);
http.method = HTTP.Method.get;
http.onReceive = (ubyte[] data) {
auto content = cast(string) data[];
boardList = strip(content, "[", "]").split(",");
foreach (ref b; boardList) {
b = strip(b, `"`);
}
return data.length;
};
http.perform();
writeln(boardList);
return boardList;
}
```
This is a member function of some class. It doesn't really have
any fields, so I left if out. In it, I use curl library to getch
some data and split it. Next, I try to use this function to get
this list:
```
Fetcher fetcher = new Fetcher;
auto boards = fetcher.getBoards();
writeln(boards);
```
I printed array twice: inside the function and after return. Here
is the output:
```
["a", "burg", "cyb", "d", "lain", "mu", "new", "tech", "test",
"u", "v", "all"]
[x"F9"c, x"FA 01 00 00"c, "\0\0\0", "d", "lain", "mu", "new",
"tech", "test", "u", "v", "all"]
```
As you can see, when outside of the funtion, first few elements
of the array contain garbage. I would like to know both why this
happens and how do I avoid it (i.e. what is the correct way of
returning dynamic array).
Re: Returning dynamic array from the function?
On 08/09/2018 9:34 PM, SuperPrower wrote: I have a function that produces dynamic array of strings. I would like to return this array from this function. I understand that dynamic arrays are of reference type, and thus if I try to return array variable, I will actually return a pointer to the first element of the array on the heap. Problem is, when I return dynamic array and try to print it outside of the function, I see garbage in a first few elements. My humble experience with languages like C++ doesn't really help with understanding how Garbage Collector (if it's because of it, because if I understand correctly, I can imagine memory being de-allocated because we get out of scope of local variable that points to the array, thus there are no more pointers to this memory, thus it gets de-allocated, but we still return reference to this memory, so GC shouldn't really free it?) can cause this - can anyone please explain me what's exactly going on and what would be the proper way to return dynamic array from the function? Thanks in advance. We're going to need to see a minified version of the code to see what you're doing.
Returning dynamic array from the function?
I have a function that produces dynamic array of strings. I would like to return this array from this function. I understand that dynamic arrays are of reference type, and thus if I try to return array variable, I will actually return a pointer to the first element of the array on the heap. Problem is, when I return dynamic array and try to print it outside of the function, I see garbage in a first few elements. My humble experience with languages like C++ doesn't really help with understanding how Garbage Collector (if it's because of it, because if I understand correctly, I can imagine memory being de-allocated because we get out of scope of local variable that points to the array, thus there are no more pointers to this memory, thus it gets de-allocated, but we still return reference to this memory, so GC shouldn't really free it?) can cause this - can anyone please explain me what's exactly going on and what would be the proper way to return dynamic array from the function? Thanks in advance.
Re: std.process: spawnProcess
On Sat, 2018-09-08 at 02:38 +, Basile B. via Digitalmars-d-learn wrote:
>
[…]
> You can wrap in a Process struct or class and take advantage of
> the destructor to do that. Assuming you write standard GC-ed code
> the destructor should be called at the end or if you free
> manually the resources.
But as with other GC systems, there is no guarantee that the destructor will
ever be called, or perhaps there is something here that gets round that?
> example API:
>
> struct SpawnedProcess
> {
> private:
> Pid pid;
> public:
> this();
> void execute();
> void terminate();
> bool running();
> ~this(){ if (running) terminate();}
> }
struct or class? Given it is of necessity a heap located value I'd have used
class, but is struct better here?
> P.S: i just see that in my own Process class i forgot to do that.
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
Is it's correct to say that ALL types that can grow are place on heap?
Is it's correct to say that ALL types that can grow are place on heap and types that not growing (int, char, pointer) are place on stack? Or there is some exceptions? Is there any tools that can visualize place of data in memory?
Re: Error: expression `update` of type `void` does not have a boolean value
On Saturday, 8 September 2018 at 06:56:40 UTC, Josphe Brigmo wrote: My project does not use the term update at all in any other context except that one. But I did find: void update(K, V, C, U)(ref V[K] aa, K key, scope C create, scope U update) Ok... found something here: https://dlang.org/changelog/2.082.0.html#require_update and here: https://dlang.org/spec/hash-map.html#advanced_updating It seems, they were added in 2.082.0. No idea why they are conflicting with your existing code, however... And even whether they are the source of conflict...
Re: Error: expression `update` of type `void` does not have a boolean value
On Saturday, 8 September 2018 at 05:39:39 UTC, Alex wrote:
On Saturday, 8 September 2018 at 03:12:56 UTC, Josphe Brigmo
wrote:
auto foo(bool update = false)()
{
static if(update)
{ }
}
and the compiler, after upgrading to 2.082 from 2.080 now says:
Error: expression `update` of type `void` does not have a
boolean value
when update is clearly a bool.
Why the hell is the compiler now thinking update is a void?
1. This code compiles fine in a test app and 2. when I rename
update to something else it works fine.
2. There is no other use of update in the entire module(not
that it should matter)
Seems this is a compiler bug but only has a problem in
context. Remember, it worked find before I updated dmd and
there is no reason why it shouldn't work.
Could you show some more code, as this works for me:
´´´
import std.stdio;
void main()
{
foo;
}
auto foo(bool update = false)()
{
static if(update)
{
}
}
´´´
compiled with
dmd --version
DMD64 D Compiler v2.082.0
Copyright (C) 1999-2018 by The D Language Foundation, All
Rights Reserved written by Walter Bright
dmd ./source/app.d
used on a Mac with Darwin Kernel Version 17.7.0
I can't, the code is from a very large project and it's too
intertwined.
I already said it worked in simple form and that it worked with a
previous compiler, so this is a regression.
Changing no code and only swapping compilers produces this bug...
and as you can see, it's obviously a bug given the form of the
function and the error message and that it worked before without
changes.
Why the specific term update? I don't know.
My project does not use the term update at all in any other
context except that one. But I did find:
void update(K, V, C, U)(ref V[K] aa, K key, scope C create, scope
U update)
