Re: Struct immutable data and dict
On Thursday, 6 October 2016 at 03:05:18 UTC, Patric Dexheimer
wrote:
But why i´m overwriting the struct if its the first time i´m
putting it there? (like on the array).
There's a difference between initialization and assignment.
```
// Given this structure
struct MyStruct { int x; }
// Both of these lines are initializstion
auto mystruct1 = MyStruct(10);
MyStruct mystruct2;
assert(mystruct1.x == 10);
assert(mystruct2.x == 0);
// And both of these are assignments.
mystruct2 = MyStruct(11);
mystruct1 = mystruct2;
assert(mystruct2.x == 11);
assert(mystruct1.x == 11);
```
If x were immutable, both initializations would succeed, but both
assignments would fail.
Re: Struct immutable data and dict
On Thursday, 6 October 2016 at 03:05:18 UTC, Patric Dexheimer wrote: But why i´m overwriting the struct if its the first time i´m putting it there? (like on the array). The compiler doesn't know it is the first time (it doesn't follow the data from creation, it just looks at that individual line, and first time write is no different than later writes with the associative array index, whereas array append is different so it can tell).
Re: Struct immutable data and dict
On Thursday, 6 October 2016 at 02:09:44 UTC, Adam D. Ruppe wrote: On Thursday, 6 October 2016 at 01:23:35 UTC, Patric Dexheimer wrote: Why? Because you'd be overwriting that immutable member. Structs just put structure around their contents, but it doesn't change their nature. That struct is no different than if you wrote `immutable size_t` as the value - and of course, overwriting that; changing that violates that promise that you won't change it. You could store pointers to those structs though, and overwrite the pointer. But why i´m overwriting the struct if its the first time i´m putting it there? (like on the array).
Re: obscure messages relating to linking and imports in 2.071.1
On Wednesday, 5 October 2016 at 12:12:24 UTC, Basile B. wrote: On Wednesday, 5 October 2016 at 11:45:49 UTC, Laeeth Isharc wrote: I noticed the problem before - previously it was my fault. I had a circulator dependency where A imported B, B did a selective import of C and C imported A selectively. That led to link problems with module constructors. [...] It looks like there's a conflict between HackerPilot's fork and the phobos version. But HackerPilot's fork is not used anymore. Have you pulled the latest versions recently (or dub upgrade if you use DUB) ? (verification: https://github.com/economicmodeling/containers/commit/528cae2880c0e5faa57d192621ad0533b0124b7b) Aha, thank you. Obvious after the fact now you point it out, and I guess that must be it. Laeeth
Re: Stupid User error with DUB/Derelict runtime issue?
On Thursday, 6 October 2016 at 00:13:20 UTC, WhatMeWorry wrote: Dub/Derelict is returning the following error at the D line: DerelictFT.load(); // Load the FreeType library derelict.util.exception.SharedLibLoadException@C:\Users\kheaser\AppData\Roaming\dub\packages\derelict-util-2.0.6\source\derelict\util\exception.d(35): Failed to load one or more shared libraries: freetype.dll - The specified module could not be found. libfreetype.dll - The specified module could not be found. libfreetype-6.dll - %1 is not a valid Win32 application. What's up with the three DLLs? Shouldn't just one suffice? Some shared libraries can be found in the wild using different formats for the file names. In the cases where I'm aware of it, as in this one, I've implemented the loaders to attempt to load them all. If any one of them is present, the load will be successful. If not, they are all listed in the exception message. And what's up with %1 ? This is an error message from the operating system. The 'not a valid Win32 application' message usually arises when you try when you have an architecture mismatch between the shared library you are trying to load and your application. That is, one of them is 32-bit and the other 64-bit. My guess is you are compiling using the default DMD toolchain, which is 32-bit, but your FreeType DLL is 64-bit. Could that be your problem?
Re: Struct immutable data and dict
On Thursday, 6 October 2016 at 01:23:35 UTC, Patric Dexheimer wrote: Why? Because you'd be overwriting that immutable member. Structs just put structure around their contents, but it doesn't change their nature. That struct is no different than if you wrote `immutable size_t` as the value - and of course, overwriting that; changing that violates that promise that you won't change it. You could store pointers to those structs though, and overwrite the pointer.
Struct immutable data and dict
struct Test{
immutable size_t id;
}
Test[string] dict;
Test[] array;
void main(){
array~=Test(1);//work
dict["teste"] = Test(1); //fail ??
}
"Error: cannot modify struct dict["teste"] Test with immutable
members"
Why?
Stupid User error with DUB/Derelict runtime issue?
Dub/Derelict is returning the following error at the D line: DerelictFT.load(); // Load the FreeType library derelict.util.exception.SharedLibLoadException@C:\Users\kheaser\AppData\Roaming\dub\packages\derelict-util-2.0.6\source\derelict\util\exception.d(35): Failed to load one or more shared libraries: freetype.dll - The specified module could not be found. libfreetype.dll - The specified module could not be found. libfreetype-6.dll - %1 is not a valid Win32 application. What's up with the three DLLs? Shouldn't just one suffice? And what's up with %1 ? Strangely enough, I've got a working Visual Studio project with the same FreeType load command that works fine? It uses 09/17/2015 08:28 PM 593,920 libfreetype-6.dll I tried just copying and pasting this .dll into the same folder as the failing .exe but it still returns the above error. Thanks.
Re: Shared an non-shared
On Wednesday, 5 October 2016 at 12:48:07 UTC, Jonathan M Davis wrote: On Wednesday, October 05, 2016 11:25:57 Begah via Digitalmars-d-learn wrote: [...] Unless you're writing lock-free algorithms (which really should only be done by experts, and even then, they should probably reconsider it, since they're so insanely hard to get right), _every_ variable/object that's going to be accessible from multiple threads needs to be protected by a mutex so that it's guaranteed that only one thread accesses the object at a time. That would be just as true in C/C++ as it is in D. It's just that D requires that they be marked as shared. That being said, how many objects should be protected by a given mutex depends entirely on what you're doing. In some cases, it makes sense to protect a lot of objects with the same mutex (e.g. all of the member variables of a class could be protected with a single mutex, which is what would happen with synchronized functions/classes), and in other cases, it makes sense to have as many as a mutex per variable. Having fewer mutexes is easier to handle, but it can also mean that code gets blocked waiting more. And of course, in some cases, the state in question is really spread across multiple variables, and they all need to be protected together. I really can't judge how many mutexes would be needed without knowing what you're doing. [...] Thanks, Although the triple buffer seems a good idea, there is one problem. I will need three time as much ram than what i currently need. Not to mention, every time i switch buffer i will need to copy all changes made to the updated buffer to the next buffer to be updated (Which i think, doing it a few hundred times a second might become a bottleneck ).
Re: Why can't static arrays be sorted?
On 10/05/2016 12:30 PM, Jonathan M Davis via Digitalmars-d-learn wrote: > On Wednesday, October 05, 2016 19:22:03 pineapple via Digitalmars-d-learn > wrote: >> Would just like to point out that this is design weirdness on >> Phobos' part - the library I've been writing does not have this >> problem. > > It doesn't even make conceptual sense for a static array to be a range, > because you can't remove elements from it. But algorithms like sort() need not require popFront(). I guess we need another range type: NonShrinkingRandomAccessRange. :) Ali
Re: Why can't static arrays be sorted?
On Wednesday, October 05, 2016 19:22:03 pineapple via Digitalmars-d-learn wrote: > On Wednesday, 5 October 2016 at 18:19:27 UTC, TheGag96 wrote: > > On Wednesday, 5 October 2016 at 02:19:13 UTC, Jonathan M Davis > > > > wrote: > >> The problem is that static arrays aren't ranges (calling > >> popFront on them can't work, because their length isn't > >> mutable). However, you can slice a static array to get a > >> dynamic array which _is_ a range. e.g. > >> > >> thing[].sort(); > >> > >> Just make sure that such a dynamic array does not outlive the > >> static array, or it will refer to invalid memory (which would > >> not be a problem in this case). > >> > >> - Jonathan M Davis > > > > Ah thanks guys. I think I just got used to thinking arrays > > would always be found to be ranges by the compiler. Good to > > know! > > Would just like to point out that this is design weirdness on > Phobos' part - the library I've been writing does not have this > problem. It doesn't even make conceptual sense for a static array to be a range, because you can't remove elements from it. - Jonathan M Davis
Re: Why can't static arrays be sorted?
On Wednesday, 5 October 2016 at 18:19:27 UTC, TheGag96 wrote: On Wednesday, 5 October 2016 at 02:19:13 UTC, Jonathan M Davis wrote: The problem is that static arrays aren't ranges (calling popFront on them can't work, because their length isn't mutable). However, you can slice a static array to get a dynamic array which _is_ a range. e.g. thing[].sort(); Just make sure that such a dynamic array does not outlive the static array, or it will refer to invalid memory (which would not be a problem in this case). - Jonathan M Davis Ah thanks guys. I think I just got used to thinking arrays would always be found to be ranges by the compiler. Good to know! Would just like to point out that this is design weirdness on Phobos' part - the library I've been writing does not have this problem.
Re: Why can't static arrays be sorted?
On Wednesday, 5 October 2016 at 02:19:13 UTC, Jonathan M Davis wrote: The problem is that static arrays aren't ranges (calling popFront on them can't work, because their length isn't mutable). However, you can slice a static array to get a dynamic array which _is_ a range. e.g. thing[].sort(); Just make sure that such a dynamic array does not outlive the static array, or it will refer to invalid memory (which would not be a problem in this case). - Jonathan M Davis Ah thanks guys. I think I just got used to thinking arrays would always be found to be ranges by the compiler. Good to know!
Re: obscure messages relating to linking and imports in 2.071.1
On Wednesday, 5 October 2016 at 12:12:24 UTC, Basile B. wrote: On Wednesday, 5 October 2016 at 11:45:49 UTC, Laeeth Isharc wrote: I noticed the problem before - previously it was my fault. I had a circulator dependency where A imported B, B did a selective import of C and C imported A selectively. That led to link problems with module constructors. [...] It looks like there's a conflict between HackerPilot's fork and the phobos version. But HackerPilot's fork is not used anymore. Have you pulled the latest versions recently (or dub upgrade if you use DUB) ? (verification: https://github.com/economicmodeling/containers/commit/528cae2880c0e5faa57d192621ad0533b0124b7b) Forgot to say but let's say you're not using DUB but rather git modules + script/makefile...git fails to physically delete the submodules when it has to (i.e after "git pull && git submodules update" the content is still there). So you have to delete the content of the folder experimental_allocator manually. Then update your build script or makefile.
Re: Using OpenGL
On Tuesday, 4 October 2016 at 16:09:34 UTC, Darren wrote: Back again with another little problem that isn't specifically OpenGL related, but is a result of getting such code to work. I actually figured it out; my own mistakes.
Re: artistic and boost licenses compatibility
Depends on the license text.
Re: Shared an non-shared
On Wednesday, October 05, 2016 11:25:57 Begah via Digitalmars-d-learn wrote:
> On Wednesday, 5 October 2016 at 07:36:58 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, October 04, 2016 19:22:10 Begah via
> >
> > Digitalmars-d-learn wrote:
> >> How can I make a method that accepts being called by both a
> >> shared and non-shared object, to prevent having to copy
> >> methods and adding a "shared"?
> >
> > You could templatize them, but really, the idea is that you
> > _don't_ call much of anything on a shared object. It's not
> > thread-safe to do so unless it's protected by a mutex or
> > sychronized block. shared is as unwieldy as it is in part
> > because it's easy to use incorrectly, and most code should not
> > be using shared at all, because the stuff that actually needs
> > to be shared across threads is normally pretty minimal.
>
> Thanks for the reply,
>
> One of my problem is that, i need all of my data to be accessible
> by both threads ( I have two ). I am making a 3d application and
> decided to separate the update loop and the render loop ( I just
> created another thread for the update loop meanwhile the render
> loop has to remain on the main thread ).
>
> I just want to ensure that when my render loop ( or update loop )
> updates/render an object, the other loop cannot ( To avoid
> potential bugs whereas one loop changes the position component
> and the render loop renders the object with only the new x
> position because the y and z variable haven't been changed yet ).
>
> As i will have many of those objects, do i need to create a mutex
> for everyone of them?
Unless you're writing lock-free algorithms (which really should only be done
by experts, and even then, they should probably reconsider it, since they're
so insanely hard to get right), _every_ variable/object that's going to be
accessible from multiple threads needs to be protected by a mutex so that
it's guaranteed that only one thread accesses the object at a time. That
would be just as true in C/C++ as it is in D. It's just that D requires that
they be marked as shared. That being said, how many objects should be
protected by a given mutex depends entirely on what you're doing. In some
cases, it makes sense to protect a lot of objects with the same mutex (e.g.
all of the member variables of a class could be protected with a single
mutex, which is what would happen with synchronized functions/classes), and
in other cases, it makes sense to have as many as a mutex per variable.
Having fewer mutexes is easier to handle, but it can also mean that code
gets blocked waiting more. And of course, in some cases, the state in
question is really spread across multiple variables, and they all need to be
protected together. I really can't judge how many mutexes would be needed
without knowing what you're doing.
That being said, if you're dealing with a rendering loop where you have one
thread updating the information, and another thread rendering, you probably
want to be using double or triple buffering.
https://en.wikipedia.org/wiki/Multiple_buffering
Basically, you have one buffer (or object or group of objects or whatever is
holding the state) which is updated by one thread, and then when it's ready,
it's swapped with another buffer. So, only the swap would need to be
protected by a mutex, because each buffer would only be referenced by a
single thread at a time. So, you could probably do something as simple as
having a pointer/reference to the buffer (or whatever object is holding the
state), and you swap that. There are a variety of ways that you could do it,
but one way would be something like
// update loop
while(cond)
{
// update data in backBuffer...
// update done
synchronized(mutex)
{
auto temp = cast(Buffer)sharedBuffer;
sharedBuffer = cast(shared Buffer)backBuffer;
backBuffer = temp;
}
}
// render loop
while(cond)
{
// render...
// wait...
synchronized(mutex)
{
auto temp = cast(Buffer)sharedBuffer;
if(temp !is frontBuffer)
{
sharedBuffer = cast(shared Buffer)frontBuffer;
frontBuffer = temp;
}
}
}
This isn't necessarily the best way to do it, but in this particular scheme,
you have 3 buffers so that the render loop always has something to render
from while the update loop can keep swapping buffers as it updates and isn't
stuck waiting for the render loop to be done with the buffer, whereas the
render loop can always just render from the same buffer as long as there
isn't an update.
This does end up locking in a somewhat different way from the basic example
I gave before, because it's just the swap that's being protected, with each
thread passing ownership of a buffer via the middle/shared buffer. However,
it does rely on making sure that all references to the buffer and everything
that it references are passed to the other thread each time so that
operating on a buffer outside of
Re: What exactly does the compiler switch -betterC do?
On 2016-10-05 11:39, Martin Nowak wrote:
Because you're linking with druntime/phobos which drags in plenty of
symbols (including a GC). Also Jakob is showing the symbols of the
object file, not executable.
No. There's a difference between DMD 2.070.0 and 2.071.0:
$ cat main.d
module main;
extern (C) int printf(in char*, ...);
extern (C) void main()
{
printf("asd\n");
}
$ dvm use 2.070.0
$ dmd --version
DMD64 D Compiler v2.070.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
$ dmd -betterC main.d
$ nm main | wc -l
4
$ dvm use 2.071.0
$ dmd --version
DMD64 D Compiler v2.071.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
$ dmd -betterC main.d
$ nm main | wc -l
2428
Note that "main" is declared as "extern (C)", which makes all the
difference.
--
/Jacob Carlborg
Re: Convert type tuple to array?
On Wednesday, 5 October 2016 at 11:46:14 UTC, Adam D. Ruppe wrote: On Wednesday, 5 October 2016 at 11:43:12 UTC, John C wrote: Is there a way to convert something like AliasSeq!(int, int, int) to an int[] - the opposite of aliasSeqOf? If it is a legal array (matching types), just put [] around it. int[] arr = [ AliasSeq!(1,2,3) ]; An AliasSeq is considered by the language to be basically the same as a comma-separated list... you can almost "copy/paste" it into any context where those are legal, including function calls and array literals. Great to know!
Re: obscure messages relating to linking and imports in 2.071.1
On Wednesday, 5 October 2016 at 11:45:49 UTC, Laeeth Isharc wrote: I noticed the problem before - previously it was my fault. I had a circulator dependency where A imported B, B did a selective import of C and C imported A selectively. That led to link problems with module constructors. [...] It looks like there's a conflict between HackerPilot's fork and the phobos version. But HackerPilot's fork is not used anymore. Have you pulled the latest versions recently (or dub upgrade if you use DUB) ? (verification: https://github.com/economicmodeling/containers/commit/528cae2880c0e5faa57d192621ad0533b0124b7b)
Re: Convert type tuple to array?
On Wednesday, 5 October 2016 at 11:43:12 UTC, John C wrote: Is there a way to convert something like AliasSeq!(int, int, int) to an int[] - the opposite of aliasSeqOf? If it is a legal array (matching types), just put [] around it. int[] arr = [ AliasSeq!(1,2,3) ]; An AliasSeq is considered by the language to be basically the same as a comma-separated list... you can almost "copy/paste" it into any context where those are legal, including function calls and array literals.
obscure messages relating to linking and imports in 2.071.1
I noticed the problem before - previously it was my fault. I had a circulator dependency where A imported B, B did a selective import of C and C imported A selectively. That led to link problems with module constructors. Here I noticed it in a different context. Simple two-page main code imports dateparser from code.dlang.org. dateparser uses emsi containers, which use std.experimental.allocator. If I don't import std.experimental.allocator in main module (where it isn't actually used) I get the link errors below. If I import it, it goes away. Might be fixed in 2.071.2 - will upgrade when I can. Not certain it's a bug and if it is whether it might be fixed, but if you think I should I will report. I can't share code publicly, but I can share gist privately. Laeeth. Linking... /usr/lib/libphobos2.a(gc_allocator_2c45_42b.o):(.bss+0x0): multiple definition of `_D3std12experimental9allocator12gc_allocator11GCAllocator6__initZ' ../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):(.bss+0x0): first defined here /usr/lib/libphobos2.a(gc_allocator_2c45_42b.o): In function `_D3std12experimental9allocator12gc_allocator11GCAllocator8allocateMOFNemZAv': (.text._D3std12experimental9allocator12gc_allocator11GCAllocator8allocateMOFNemZAv+0x0): multiple definition of `_D3std12experimental9allocator12gc_allocator11GCAllocator8allocateMOFNemZAv' ../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/gc_allocator.d:(.text._D3std12experimental9allocator12gc_allocator11GCAllocator8allocateMOFNemZAv+0x0): first defined here /usr/lib/libphobos2.a(gc_allocator_2c45_42b.o): In function `_D3std12experimental9allocator12gc_allocator11GCAllocator10reallocateMOFKAvmZb': (.text._D3std12experimental9allocator12gc_allocator11GCAllocator10reallocateMOFKAvmZb+0x0): multiple definition of `_D3std12experimental9allocator12gc_allocator11GCAllocator10reallocateMOFKAvmZb' ../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/gc_allocator.d:(.text._D3std12experimental9allocator12gc_allocator11GCAllocator10reallocateMOFKAvmZb+0x0): first defined here /usr/lib/libphobos2.a(gc_allocator_2c45_42b.o): In function `_D3std12experimental9allocator12gc_allocator11GCAllocator22resolveInternalPointerMOFPvZAv': (.text._D3std12experimental9allocator12gc_allocator11GCAllocator22resolveInternalPointerMOFPvZAv+0x0): multiple definition of `_D3std12experimental9allocator12gc_allocator11GCAllocator22resolveInternalPointerMOFPvZAv' ../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/gc_allocator.d:(.text._D3std12experimental9allocator12gc_allocator11GCAllocator22resolveInternalPointerMOFPvZAv+0x0): first defined here /usr/lib/libphobos2.a(gc_allocator_2c45_42b.o): In function `_D3std12experimental9allocator12gc_allocator11GCAllocator10deallocateMOFAvZb': (.text._D3std12experimental9allocator12gc_allocator11GCAllocator10deallocateMOFAvZb+0x0): multiple definition of `_D3std12experimental9allocator12gc_allocator11GCAllocator10deallocateMOFAvZb' ../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/gc_allocator.d:(.text._D3std12experimental9allocator12gc_allocator11GCAllocator10deallocateMOFAvZb+0x0): first defined here /usr/lib/libphobos2.a(gc_allocator_2c45_42b.o):(.bss+0x1): multiple definition of `_D3std12experimental9allocator12gc_allocator11GCAllocator8instanceOS3std12experimental9allocator12gc_allocator11GCAllocator' ../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):(.bss+0x1): first defined here /usr/lib/libphobos2.a(gc_allocator_2c45_42b.o): In function `_D3std12experimental9allocator12gc_allocator11GCAllocator7collectMOFNeZv': (.text._D3std12experimental9allocator12gc_allocator11GCAllocator7collectMOFNeZv+0x0): multiple definition of `_D3std12experimental9allocator12gc_allocator11GCAllocator7collectMOFNeZv'
Convert type tuple to array?
Is there a way to convert something like AliasSeq!(int, int, int) to an int[] - the opposite of aliasSeqOf?
Re: Shared an non-shared
On Wednesday, 5 October 2016 at 07:36:58 UTC, Jonathan M Davis wrote: On Tuesday, October 04, 2016 19:22:10 Begah via Digitalmars-d-learn wrote: How can I make a method that accepts being called by both a shared and non-shared object, to prevent having to copy methods and adding a "shared"? You could templatize them, but really, the idea is that you _don't_ call much of anything on a shared object. It's not thread-safe to do so unless it's protected by a mutex or sychronized block. shared is as unwieldy as it is in part because it's easy to use incorrectly, and most code should not be using shared at all, because the stuff that actually needs to be shared across threads is normally pretty minimal. Thanks for the reply, One of my problem is that, i need all of my data to be accessible by both threads ( I have two ). I am making a 3d application and decided to separate the update loop and the render loop ( I just created another thread for the update loop meanwhile the render loop has to remain on the main thread ). I just want to ensure that when my render loop ( or update loop ) updates/render an object, the other loop cannot ( To avoid potential bugs whereas one loop changes the position component and the render loop renders the object with only the new x position because the y and z variable haven't been changed yet ). As i will have many of those objects, do i need to create a mutex for everyone of them?
Re: What exactly does the compiler switch -betterC do?
On Monday, 19 September 2016 at 21:09:39 UTC, Gary Willoughby wrote: On Monday, 20 June 2016 at 06:35:32 UTC, Jacob Carlborg wrote: On 2016-06-19 21:53, Gary Willoughby wrote: If compiled with -betterC, it contains these: T _main U _printf I get significantly more symbols than that when compiling the following program any idea why? Because you're linking with druntime/phobos which drags in plenty of symbols (including a GC). Also Jakob is showing the symbols of the object file, not executable.
Re: How dub select versions?
That makes sense :). Thanks Dne 5.10.2016 v 10:27 Mike Parker via Digitalmars-d-learn napsal(a): On Wednesday, 5 October 2016 at 08:23:25 UTC, Mike Parker wrote: The ~> constrains the dependency to the minor version number, meaning DUB will not try to use a version of the dependency that has a higher minor version. Oh, that came out wrong. TO be clear for anyone who doesn't read the linked wiki page in detail: The ~> constrains the dependency to the minor version number when used with the n.n.n format. It constrains to the major version when using n.n (e.g. ~>1.0 is the same as >=1.0 && <2.0).
Re: How dub select versions?
On Wednesday, 5 October 2016 at 08:23:25 UTC, Mike Parker wrote: The ~> constrains the dependency to the minor version number, meaning DUB will not try to use a version of the dependency that has a higher minor version. Oh, that came out wrong. TO be clear for anyone who doesn't read the linked wiki page in detail: The ~> constrains the dependency to the minor version number when used with the n.n.n format. It constrains to the major version when using n.n (e.g. ~>1.0 is the same as >=1.0 && <2.0).
Re: How dub select versions?
On Wednesday, 5 October 2016 at 08:01:33 UTC, Daniel Kozak wrote: I really does not understand how does DUB works. I have small app which use vibe-d:core as dependency, and I use libasync as subConfiguration. When I try to build my app it always try to download libasync-0.7.9 instead of libasync-0.8.0. Why? I would expect to select the latest one frum dub repository If you look into the vide.d dub.sdl, you'll see the following listed in the "libasync" configuration [1]: dependency "libasync" version="~>0.7.8" The ~> constrains the dependency to the minor version number, meaning DUB will not try to use a version of the dependency that has a higher minor version. In this case, it means >=0.7.8 && <0.8.0. See [2] for details. [1] https://github.com/rejectedsoftware/vibe.d/blob/master/dub.sdl#L76 [2] https://github.com/dlang/dub/wiki/Version-management
How dub select versions?
I really does not understand how does DUB works. I have small app which use vibe-d:core as dependency, and I use libasync as subConfiguration. When I try to build my app it always try to download libasync-0.7.9 instead of libasync-0.8.0. Why? I would expect to select the latest one frum dub repository
Re: Shared an non-shared
On Tuesday, October 04, 2016 19:22:10 Begah via Digitalmars-d-learn wrote:
> How can I make a method that accepts being called by both a
> shared and non-shared object, to prevent having to copy methods
> and adding a "shared"?
You could templatize them, but really, the idea is that you _don't_ call
much of anything on a shared object. It's not thread-safe to do so unless
it's protected by a mutex or sychronized block. shared is as unwieldy as it
is in part because it's easy to use incorrectly, and most code should not be
using shared at all, because the stuff that actually needs to be shared
across threads is normally pretty minimal. The fact that most operations are
illegal on shared objects prevents misuse. But of course, it leaves the
question of how you go about actually doing anything with a shared object,
since obviously, you're going to do need to do more than just create the
thing.
TDPL talks about synchronized classes where the outer layer of shared gets
automatically cast away within the member functions of the class (since the
compiler can guarantee that only one thread at a time is in the member
functions of the class). However, synchronized classes haven't been
implemented as of yet, and we just have synchronized functions, which do
protect those functions with a mutex, but without requiring that all
functions within the class be synchronized and make it illegal to access the
member variables except via the member functions, the compiler can't cast
away the outer layer of shared, because it can't guarantee that the member
is actually protected by a mutex.
So, the way to solve this is that when you want to operate on a shared
object, you first make sure that it's protected by a mutex (like you would
in a language like C or C++), then you cast away shared to operate on the
object, and then when you're done, you make sure that no non-shared
references to the object exist, and release the mutex. e.g. something like
shared MyClass mySharedObj = getSharedObj();
synchronized(myMutex)
{
auto obj = cast(MyClass)mySharedObj;
// do stuff with obj...
// obj should be the only non-shared reference to the object
// referred to by mySharedObj when the sychronized block exits.
}
So, ultimately, the code is basically the same as what you'd do in C/C++
except that you have to cast away shared to actually do much of anything to
the object. It _is_ unfortunately more error-prone than synchronized classes
would be, because you're forced to do a manual cast, but since we don't
actually have synchronized class, you don't have much choice, and since
synchronized classes would only strip away the outer layer of shared,
there's a halfway decent chance that you'd still need to do something like
this even if we did have synchronized classes.
- Jonathan M Davis
