Re: Thread pools
On Wednesday, 22 July 2015 at 14:28:48 UTC, Chris wrote: What would be the best way to manage different threads (spawned via std.concurrency), e.g. to tell them to stop at once, once a new command comes in? A thread pool? How would that look like in D? I feel my knowledge of D threads is still a bit limited. `std.parallelism` includes a TaskPool class [1] and a taskPool property [2], but they spawn their own threads. I'm not sure why you need a thread pool to tell std.concurrency threads to stop; why not send a stop message to each of them? [1]: http://dlang.org/phobos/std_parallelism.html#.TaskPool [2]: http://dlang.org/phobos/std_parallelism.html#.taskPool
Re: Thread pools
On Wednesday, 22 July 2015 at 15:51:23 UTC, Chris wrote:
On Wednesday, 22 July 2015 at 15:41:06 UTC, Alex Parrill wrote:
On Wednesday, 22 July 2015 at 14:28:48 UTC, Chris wrote:
What would be the best way to manage different threads
(spawned via std.concurrency), e.g. to tell them to stop at
once, once a new command comes in? A thread pool? How would
that look like in D? I feel my knowledge of D threads is
still a bit limited.
`std.parallelism` includes a TaskPool class [1] and a taskPool
property [2], but they spawn their own threads.
I'm not sure why you need a thread pool to tell
std.concurrency threads to stop; why not send a stop message
to each of them?
[1]: http://dlang.org/phobos/std_parallelism.html#.TaskPool
[2]: http://dlang.org/phobos/std_parallelism.html#.taskPool
Thanks. I'm dealing with nested threads at the moment.
main
{
spawn(thread1)
{
// Does some processing
spawn(thread2)
{
// Plays audio
}
}
}
If main receives a signal, all threads should stop immediately
(thread1 and thread2).
I would send a message to terminate to thread1, which would in
turn send a similar message to any threads it has started, wait
until they've all stopped (maybe with a time-out), then return.
I.e. every thread knows how to cleanly terminate itself when
instructed, so you just send a terminate message down the tree of
threads and then wait for the effects to bubble back up to main.
Re: Thread pools
On Wednesday, 22 July 2015 at 15:41:06 UTC, Alex Parrill wrote:
On Wednesday, 22 July 2015 at 14:28:48 UTC, Chris wrote:
What would be the best way to manage different threads
(spawned via std.concurrency), e.g. to tell them to stop at
once, once a new command comes in? A thread pool? How would
that look like in D? I feel my knowledge of D threads is still
a bit limited.
`std.parallelism` includes a TaskPool class [1] and a taskPool
property [2], but they spawn their own threads.
I'm not sure why you need a thread pool to tell std.concurrency
threads to stop; why not send a stop message to each of them?
[1]: http://dlang.org/phobos/std_parallelism.html#.TaskPool
[2]: http://dlang.org/phobos/std_parallelism.html#.taskPool
Thanks. I'm dealing with nested threads at the moment.
main
{
spawn(thread1)
{
// Does some processing
spawn(thread2)
{
// Plays audio
}
}
}
If main receives a signal, all threads should stop immediately
(thread1 and thread2).
Re: Sending an immutable object to a thread
On Wednesday, 22 July 2015 at 09:04:49 UTC, Marc Schütz wrote:
But as long as the original pointer is still on the stack, that
one _will_ keep the object alive. It is only a problem if all
pointers to a GC managed object are stored in places the GC
isn't informed about.
Sorry, I have gotten confused. In Ali's example, the pointer to a
class object (via the address-of '' operator) actually points
into the GC heap. It is *not* a pointer to a pointer, right?
My reading of the Garbage web doc page is that this pointer to
memory in the GC heap is sufficient (by some magic) to keep the
memory alive, in and of itself.
So the pointer, passed to the other thread is sufficient to keep
the memory alive, even if the original reference disappears.
Or, to put it another way, getting threads out of the equation,
is this safe?
class MyThing { ... }
MyThing* create_a_thing() {
MyThing mt = new MyThing();
do_something_with(mt);
return mt;
}
void main() {
MyThing* pmt = create_a_thing();
// ...
}
The thing will remain alive for the duration of main() ??
Thanks
Re: Thread pools
On Wednesday, 22 July 2015 at 16:16:36 UTC, John Colvin wrote:
On Wednesday, 22 July 2015 at 15:51:23 UTC, Chris wrote:
On Wednesday, 22 July 2015 at 15:41:06 UTC, Alex Parrill wrote:
[...]
Thanks. I'm dealing with nested threads at the moment.
main
{
spawn(thread1)
{
// Does some processing
spawn(thread2)
{
// Plays audio
}
}
}
If main receives a signal, all threads should stop immediately
(thread1 and thread2).
I would send a message to terminate to thread1, which would in
turn send a similar message to any threads it has started, wait
until they've all stopped (maybe with a time-out), then return.
I.e. every thread knows how to cleanly terminate itself when
instructed, so you just send a terminate message down the tree
of threads and then wait for the effects to bubble back up to
main.
You can probably simply terminate the main thread, which will
send an OwnerTerminated message to all dependent threads. The
threads need to `receive()` this message and terminate.
Re: Sending an immutable object to a thread
On Wednesday, 22 July 2015 at 17:17:17 UTC, Frank Pagliughi wrote:
On Wednesday, 22 July 2015 at 09:04:49 UTC, Marc Schütz wrote:
But as long as the original pointer is still on the stack,
that one _will_ keep the object alive. It is only a problem if
all pointers to a GC managed object are stored in places the
GC isn't informed about.
Sorry, I have gotten confused. In Ali's example, the pointer to
a class object (via the address-of '' operator) actually
points into the GC heap. It is *not* a pointer to a pointer,
right?
My reading of the Garbage web doc page is that this pointer to
memory in the GC heap is sufficient (by some magic) to keep the
memory alive, in and of itself.
So the pointer, passed to the other thread is sufficient to
keep the memory alive, even if the original reference
disappears.
Or, to put it another way, getting threads out of the equation,
is this safe?
class MyThing { ... }
MyThing* create_a_thing() {
MyThing mt = new MyThing();
do_something_with(mt);
return mt;
}
void main() {
MyThing* pmt = create_a_thing();
// ...
}
The thing will remain alive for the duration of main() ??
Thanks
No.
this is actually returning an address of a temporary.
How to get *32mscoff libraries for phobos?
I have tried to build this and failed miserably. I have some questions? What make do you use? digital mars, gnu. what tools do you need? is it possible? I also failed to build zlib32coff.lib make[2]: *** No rule to make target `zlib32mscoff.lib'. Stop. I could say more but it probably wouldn't be useful.
Re: Passing struct and struct[] into a template
On Wednesday, July 22, 2015 04:29:23 Taylor Gronka via Digitalmars-d-learn
wrote:
I have a template function, and I want it to do something if the
input variable is a list of structs, and something else if the
input is a struct.
If you want a template to be different for different types, then overload it
via template constraints. e.g.
auto query(T)(string s)
if(isDynamicArray!T)
{
}
auto query(T)(string s)
if(!isDynamicArray!T)
{
}
You can use static if internally instead if the difference in code between
the two is small, though in most cases, unless the types are very similar,
it's cleaner to use a template constraint.
- Jonathan M Davis
Re: Sending an immutable object to a thread
On Tuesday, 21 July 2015 at 21:50:35 UTC, rsw0x wrote: On Tuesday, 21 July 2015 at 21:44:07 UTC, rsw0x wrote: On Sunday, 19 July 2015 at 17:12:07 UTC, rsw0x wrote: [...] wow, I don't even remember posting this. This is (mostly) wrong, but I'm unsure if a pointer to another pointer on the stack would correctly keep its object alive(but, I believe this would just be a bug I think,) If the pointer was pointing to a pointer on the heap, then AFAICT it would keep it alive. addendum: http://dlang.org/garbage.html Pointers in D can be broadly divided into two categories: Those that point to garbage collected memory, and those that do not. Examples of the latter are pointers created by calls to C's malloc(), pointers received from C library routines, pointers to static data, pointers to objects on the stack, etc. and those that do not ... pointers to objects on the stack, etc. I believe this implies that it would *not* keep the object alive. Sorry for the confusion/noise. But as long as the original pointer is still on the stack, that one _will_ keep the object alive. It is only a problem if all pointers to a GC managed object are stored in places the GC isn't informed about.
Re: Code Coverage Analysis, how do I skip (ignore) a line?
On Wednesday, July 22, 2015 02:19:52 antropod via Digitalmars-d-learn wrote: I want my coverage analysis to be 100%, how do I skip lines like assert(0); from being counted? AFAIK, there is no way to so, and I've mentioned that problem to Walter before, so I would have expected him to mention how to get around it if there were a way. You pretty much just have to live with not getting 100%, as annoying as that may be. - Jonathan M Davis
Re: Measuring Execution time
On Wednesday, 22 July 2015 at 09:32:15 UTC, John Colvin wrote: On Wednesday, 22 July 2015 at 09:23:36 UTC, Clayton wrote: [...] The normal way of doing this would be using std.datetime.StopWatch: StopWatch sw; sw.start(); algorithm(); long exec_ms = sw.peek().msecs; Much appreciated, that works well John . Learning goes on... thanks again
Measuring Execution time
How does one represent Duration in only Micro-seconds, or
milliseconds. Trying to measure the execution time of an
algorithm and I get 4 ms, 619 μs, and 8 hnsecs , I want to sum
all these and get total hnsecs or μs .
I would also appreciate advise on whether this is the best way
to measure the execution time of an algorithm.
import std.datetime;
import std.stdio;
void algorithm( ){
writeln(Hello!);
}
void main(){
auto stattime = Clock.currTime();
algorithm( );
endttime = Clock.currTime();
auto duration = endttime - stattime;
writeln(Hello Duration == , duration);
}
Re: Measuring Execution time
On Wednesday, 22 July 2015 at 09:23:36 UTC, Clayton wrote:
How does one represent Duration in only Micro-seconds, or
milliseconds. Trying to measure the execution time of an
algorithm and I get 4 ms, 619 μs, and 8 hnsecs , I want to
sum all these and get total hnsecs or μs .
I would also appreciate advise on whether this is the best
way to measure the execution time of an algorithm.
import std.datetime;
import std.stdio;
void algorithm( ){
writeln(Hello!);
}
void main(){
auto stattime = Clock.currTime();
algorithm( );
endttime = Clock.currTime();
auto duration = endttime - stattime;
writeln(Hello Duration == , duration);
}
The normal way of doing this would be using
std.datetime.StopWatch:
StopWatch sw;
sw.start();
algorithm();
long exec_ms = sw.peek().msecs;
std.net.curl and PATCH
It seems that PATCH http method is missing from std.net.curl http methods. No way to use it?
Re: How to get *32mscoff libraries for phobos?
On Wednesday, 22 July 2015 at 23:39:46 UTC, Jonathan M Davis wrote: On Wednesday, July 22, 2015 20:27:35 Taylor Hillegeist via Digitalmars-d-learn wrote: I have tried to build this and failed miserably. I have some questions? What make do you use? digital mars, gnu. what tools do you need? is it possible? I also failed to build zlib32coff.lib make[2]: *** No rule to make target `zlib32mscoff.lib'. Stop. I could say more but it probably wouldn't be useful. AFAIK, COFF is not supported by dmd for 32-bit Windows. Walter made it so that the 64-bit support used COFF and the VS linker rather than optlink, but he left the 32-bit stuff as it was, so it still uses OMF and optlink. - Jonathan M Davis Rainer worked on it last year. I believe 2.067 was the first release to support it, though it isn't documented in the compiler's help list.
Re: How to get *32mscoff libraries for phobos?
On Thursday, 23 July 2015 at 01:39:05 UTC, Mike Parker wrote: post at [1] where Rainer shared the relevant bits of a batch Gah, hate it when I forget the links. [1] http://forum.dlang.org/post/m456t5$2jc4$1...@digitalmars.com
Re: C bindings: typedef struct conflicts with method
On Tuesday, 21 July 2015 at 05:53:26 UTC, yawniek wrote:
i tried to automagically create bindings for librdkafka
(https://github.com/edenhill/librdkafka)
with dstep.
now the code contains typedefs structs with the same name as
methods:
```
typedef struct rd_kafka_metadata {
int broker_cnt; /* Number of brokers in
'brokers' */
struct rd_kafka_metadata_broker *brokers; /* Brokers */
int topic_cnt; /* Number of topics in
'topics' */
struct rd_kafka_metadata_topic *topics;/* Topics */
int32_t orig_broker_id; /* Broker originating this
metadata */
char *orig_broker_name; /* Name of originating
broker */
} rd_kafka_metadata_t;
rd_kafka_metadata (rd_kafka_t *rk, int all_topics,
rd_kafka_topic_t *only_rkt,
const struct rd_kafka_metadata **metadatap,
int timeout_ms);
```
what the correct way to bind these?
Just FYI, the D side knows absolutely nothing about what the
struct is called on the C side and vice versa. Only functions
(and any global variables if you need them) are actually bound.
Types are translated. So you can call the struct anything you
want on the D side.
That said, it's usually a good idea to use the the same name as
the C code uses for consistency. It means existing C code can be
ported to D, or with custom libraries you can switch back and
forth, without needing to remember that a struct is call bloob_t
in C and Blarg in D.
In your case, rd_kafka_metadata is the name of the struct, but in
C instances would need to be declared like so:
struct rd_kafka_metadata instance;
The typedef makes it so that instances can be declared in C
without the struct keyword:
rd_kafka_metadata_t instance;
That makes the latter a better choice to use on the D side.
Re: How to get *32mscoff libraries for phobos?
On Wednesday, 22 July 2015 at 20:27:37 UTC, Taylor Hillegeist wrote: I have tried to build this and failed miserably. I have some questions? What make do you use? digital mars, gnu. what tools do you need? is it possible? I also failed to build zlib32coff.lib make[2]: *** No rule to make target `zlib32mscoff.lib'. Stop. I could say more but it probably wouldn't be useful. First off, make sure you build a 32-bit COFF version of Phobos. DMD does not ship with it by default. You can use the Druntime and Phobos source included in the DMD distribution. You'll need to make sure you have Microsoft toolchain installed. See the post at [1] where Rainer shared the relevant bits of a batch file he uses to build. Visual Studio provides links in the Start menu to open up command prompts with a preconfigured environment, so if you use that you don't need the configuration at the top of the batch file. Once the library is built, it will be written out in the Phobos source directory. I learned that it's not enough to copy it to DMD's lib directory -- it's never picked up. I copied it to the 8.1 SDK lib directory. Any C libraries you use will need to be compiled with Visual Studio (or a version of clang using the MS toolchain). When compiling D libraries or apps with DMD, pass the -m32mscoff switch. If you use DUB, you'll need to add it to your configuration in an -lflags directive.
Re: Getting this to work similar to self in Python
On Wednesday, July 22, 2015 23:19:35 nurfz via Digitalmars-d-learn wrote: Hmm, is there a specific reason aside from the encapsulation violation? It seems needlessly complicated. If you have someone/something that has direct access to your source code, isn't a getter/setter the least of your concerns? It has nothing to do with people having access to your source code. It's leaking how your class is implemented when you provide access to its member variables, which makes it so that code that uses it is more likely to depend on how it's currently implemented, and it makes it harder to change your code later. Users of your class should not depend on the internal implementantion of that class, since it creates unnecessary dependencies. Search on high cohesion and low coupling, and you'll find stuff talking about how your code is more maintainable and of better quality when internals are kept internal, and dependencies across types are kept to a minimum. And remember that just because a getter/setter or property function happens to currently wrap a member variable, doesn't mean that it will later. For instance, you may need to change your code later so that the value in question is actually calculated rather than stored directly in the class. If the member variable is public, then making that change will break all code that uses that member variable, whereas if it's accessed via getters and setters (or property functions), then all of the code that uses that class will continue to work as it did before, which could save you a fair bit of time and effort, and if your code is part of an API that's publicly available, then you avoid breaking a lot of other people's code. And even if your getter/setter/property function will always wrap a member variable, it could be that you'll need to add code to the function(s) later that does extra checks, or sets another variable, or calls another function in addition to getting the current value of the member variable or setting it to a new value. It may not always simply access the variable. If you've made the member variable public, you'll be forced to break existing code when you need to wrap it in a function later. It's just good practice to make all of your member variable private and not provide direct access to any of them. It'll save you from pain later when you have to change how your class works, even if it's as simple as adding log messages. Even worse in D, invariants get called before and after a public member function is called. They don't get called when you access a public member variable. So, if you have a public member variable in a class with an invariant, you're just shooting yourself in the foot, because you can't guarantee the invariant anymore. It's not getting called when the member variable is accessed, and the code accessing it can do whatever it wants to it, including violate the invariant, and you won't catch it until a public member function gets called later, which could be in completely unrelated code. If you start searching for encapsulation and programming, or encapsulation and OOP, or data encaplusation, or anything like unto it, you will very quickly find a lot of stuff telling you to never make your member variables public. It's commonly considered bad practice in languages like C++, Java, C#, D, etc. because it's a mantainance problem when you do, and it really doesn't play well with OOP, since very few languages that support OOP have polymorphic variables (since to do that, you need wrap their access in function calls internally anyway). Does the @property decorator incur a large runtime cost? @property is only applicable to functions and has no effect on the runtime cost, though if a function is not inlined, then it will cost more than accessing a variable directly. So, if your question is whether wrapping member variable access in a getter/setter or a property function costs more, then that depends on whether the call gets inlined. If the call is inlined, then the cost is the same, and if they're not virtual one line functions are going to be inlined if you compile with -inline (which you would normally use in a release build). And if you're comparing with python, D would win regardless, because the only way that python can have polymorphic variables is by looking them up rather than simply accessing them directly as occurs in a language like D, C++, Java, etc. So, python is essentially always wrapping your variable accesses in getters and setters. - Jonathan M Davis
Connection to server socket Invalid argument
I have some code.
//client.d
import std.stdio;
import std.socket;
import std.conv;
void main() {
Socket client = new TcpSocket(AddressFamily.INET);
autoaddr = new InternetAddress(localhost, 2021);
autoaddrServer = new InternetAddress(localhost,
2017);
client.bind(addr);
client.blocking(true);
writeln(Connection...);
client.connect(addrServer);
void[] buffer = new void[245];
while(1) {
ulong size = client.receive(buffer);
if(size 0) {
writeln(cast(string)buffer);
}
}
scope(exit) {
client.shutdown(SocketShutdown.BOTH);
client.close();
}
}
//server.d
import std.stdio;
import std.socket;
import std.process;
import std.conv;
void main(string[] args) {
Socket client;
Socket server = new TcpSocket(AddressFamily.INET);
auto addr = new InternetAddress(args[1],
to!(ushort)(args[2]));
server.bind(addr);
server.listen(1);
server.blocking(true);
while(1){
try {
client = server.accept();
writeln(New Connection);
}
catch{}
writeln(Running sensors...)
auto sensors = executeShell(sensors);
//writeln(sensors.output);
//wait(sensors);
writeln(Sending data..)
client.send(cast(void[])(sensors.output));
}
scope(exit) {
server.shutdown(SocketShutdown.BOTH);
server.close();
}
}
When i use localhost address how address of server for client
socket, i getting working connection, but when i use address like
192.168.106.91, i get error:
std.socket.SocketOSException@std/socket.d(2768): Unable to
connect socket: Invalid argument
How i can to solve my problem?
Getting this to work similar to self in Python
How could I get this D code to work similar to this Python code?
So, here is the D code:
import std.stdio;
class Vehicle {
int speed;
void printSpeed() {
writeln(this.speed);
}
}
class Airplane: Vehicle {
int speed = 100;
}
int main() {
auto v = new Vehicle();
auto a = new Airplane();
v.printSpeed(); // 0
a.printSpeed(); // 0 not 100
writeln(v.speed); // 0
writeln(a.speed); // 100
}
Here is the Python code:
class Vehicle:
speed = 0
def printSpeed(self):
print(self.speed)
class Airplane(Vehicle):
speed = 100
if __name__ == __main__:
v = Vehicle()
a = Airplane()
v.printSpeed() # 0
a.printSpeed() # 100
print(v.speed) # 0
print(a.speed) # 100
I guess I'm confused as to why the D code isn't acting similar to
the Python code in the sense that you would expect this to
reference the speed property of the current instance and not
statically reference the parent. Am I having these issues
because these attributes are being initialized statically?
Would using constructors be the way to go about this? I suppose
I'm just trying to find a way to implement fairly clean and
intuitive object oriented inheritance that isn't crippled by
getters/setters, is resolved at compile time, and doesn't impose
any kind of runtime cost other than what you would assume is
associated with fundamental level OOP.
Sorry for the long winded post, but this has just been confusing
me to no end. Hopefully you guys can help me out! :)
Re: Getting this to work similar to self in Python
Hmm, is there a specific reason aside from the encapsulation violation? It seems needlessly complicated. If you have someone/something that has direct access to your source code, isn't a getter/setter the least of your concerns? Does the @property decorator incur a large runtime cost?
Re: Getting this to work similar to self in Python
On Wednesday, 22 July 2015 at 22:22:02 UTC, nurfz wrote:
How could I get this D code to work similar to this Python code?
So, here is the D code:
import std.stdio;
class Vehicle {
int speed;
void printSpeed() {
writeln(this.speed);
}
}
class Airplane: Vehicle {
int speed = 100;
}
int main() {
auto v = new Vehicle();
auto a = new Airplane();
v.printSpeed(); // 0
a.printSpeed(); // 0 not 100
writeln(v.speed); // 0
writeln(a.speed); // 100
}
Here is the Python code:
class Vehicle:
speed = 0
def printSpeed(self):
print(self.speed)
class Airplane(Vehicle):
speed = 100
if __name__ == __main__:
v = Vehicle()
a = Airplane()
v.printSpeed() # 0
a.printSpeed() # 100
print(v.speed) # 0
print(a.speed) # 100
I guess I'm confused as to why the D code isn't acting similar
to the Python code in the sense that you would expect this to
reference the speed property of the current instance and not
statically reference the parent. Am I having these issues
because these attributes are being initialized statically?
Would using constructors be the way to go about this? I suppose
I'm just trying to find a way to implement fairly clean and
intuitive object oriented inheritance that isn't crippled by
getters/setters, is resolved at compile time, and doesn't
impose any kind of runtime cost other than what you would
assume is associated with fundamental level OOP.
Sorry for the long winded post, but this has just been
confusing me to no end. Hopefully you guys can help me out! :)
Fields of classes are not in any way polymorphic in D (this is
the same as C++ and I think java too). Base class members can be
accessed like so:
class Vehicle {
int speed;
void printSpeed() {
writeln(this.speed);
}
}
class Airplane: Vehicle {
this()
{
Vehicle.speed = 100;
}
}
or if you really want to use the same variable name:
class Airplane: Vehicle {
alias speed = Vehicle.speed;
this()
{
speed = 100;
}
}
You can even automatically do that sort of thing by various
means, the shortest/simplest way I can think of would be:
class Airplane: Vehicle {
private @property Vehicle base() { return this; }
alias base this;
this()
{
speed = 100;
}
}
Re: Getting this to work similar to self in Python
On Wednesday, July 22, 2015 22:22:00 nurfz via Digitalmars-d-learn wrote:
How could I get this D code to work similar to this Python code?
So, here is the D code:
import std.stdio;
class Vehicle {
int speed;
void printSpeed() {
writeln(this.speed);
}
}
class Airplane: Vehicle {
int speed = 100;
}
int main() {
auto v = new Vehicle();
auto a = new Airplane();
v.printSpeed(); // 0
a.printSpeed(); // 0 not 100
writeln(v.speed); // 0
writeln(a.speed); // 100
}
Here is the Python code:
class Vehicle:
speed = 0
def printSpeed(self):
print(self.speed)
class Airplane(Vehicle):
speed = 100
if __name__ == __main__:
v = Vehicle()
a = Airplane()
v.printSpeed() # 0
a.printSpeed() # 100
print(v.speed) # 0
print(a.speed) # 100
I guess I'm confused as to why the D code isn't acting similar to
the Python code in the sense that you would expect this to
reference the speed property of the current instance and not
statically reference the parent. Am I having these issues
because these attributes are being initialized statically?
Would using constructors be the way to go about this? I suppose
I'm just trying to find a way to implement fairly clean and
intuitive object oriented inheritance that isn't crippled by
getters/setters, is resolved at compile time, and doesn't impose
any kind of runtime cost other than what you would assume is
associated with fundamental level OOP.
Sorry for the long winded post, but this has just been confusing
me to no end. Hopefully you guys can help me out! :)
Variables are not polymorphic. Only public or protected member functions are
polymorphic. If you want to override behavior in a derived class, you have
to use a function. And generally, it's not good practice to either have
member variables be public or to reuse their names in derived classes.
Making them public breaks encapsulation, and reusing names makes it too easy
to confuse which name you're dealing with.
A related question on SO:
http://stackoverflow.com/questions/31436506
- Jonathan M Davis
Re: How to get *32mscoff libraries for phobos?
On Wednesday, July 22, 2015 20:27:35 Taylor Hillegeist via Digitalmars-d-learn wrote: I have tried to build this and failed miserably. I have some questions? What make do you use? digital mars, gnu. what tools do you need? is it possible? I also failed to build zlib32coff.lib make[2]: *** No rule to make target `zlib32mscoff.lib'. Stop. I could say more but it probably wouldn't be useful. AFAIK, COFF is not supported by dmd for 32-bit Windows. Walter made it so that the 64-bit support used COFF and the VS linker rather than optlink, but he left the 32-bit stuff as it was, so it still uses OMF and optlink. - Jonathan M Davis
Re: Sending an immutable object to a thread
On Wednesday, 22 July 2015 at 09:04:49 UTC, Marc Schütz wrote: On Tuesday, 21 July 2015 at 21:50:35 UTC, rsw0x wrote: On Tuesday, 21 July 2015 at 21:44:07 UTC, rsw0x wrote: [...] addendum: http://dlang.org/garbage.html [...] [...] I believe this implies that it would *not* keep the object alive. Sorry for the confusion/noise. But as long as the original pointer is still on the stack, that one _will_ keep the object alive. It is only a problem if all pointers to a GC managed object are stored in places the GC isn't informed about. correct, I managed to confuse myself :o)
Thread pools
What would be the best way to manage different threads (spawned via std.concurrency), e.g. to tell them to stop at once, once a new command comes in? A thread pool? How would that look like in D? I feel my knowledge of D threads is still a bit limited.
