Re: Bulk allocation and partial deallocation for tree data structures.
On Tuesday, 4 July 2017 at 03:13:14 UTC, Filip Bystricky wrote: Oh and I forgot to mention: another use-case for this would be for arrays. For manually managed arrays like std.container.array, it would make it possible to transfer ownership of individual objects from the array back to the program after the array goes out of scope. Not sure I understand you here: If an instance of such a manual array implementation goes out of scope it must destruct (if they are objects and not primitives) and deallocate its elements. There is no ownership transfer going on here (and who would be the target, anyway?). For gc slices, it could enable some gc implementations to deallocate parts of an array even if there are still references pointing inside that array. I'm fairly certain the necessary bookkeeping logic for partial deallocations will outweigh any gain from it. In the case of such gc slices, I would rather just memcpy to a new, smaller block and update pointers to it (-> a moving GC).
Re: Finding all the interfaces and their inheritance relationships at runtime
On Monday, 3 July 2017 at 22:34:51 UTC, FoxyBrown wrote:
On Monday, 3 July 2017 at 20:45:19 UTC, bauss wrote:
On Monday, 3 July 2017 at 13:54:42 UTC, Jean-Louis Leroy wrote:
I know how to find all the classes:
foreach (mod; ModuleInfo) {
foreach (c; mod.localClasses) {
// use c.base to construct inheritance graph
}
}
Can I do the same with all the interfaces? Looking at
object.d gives no clue...
Is there a reason you need to do it with runtime and can't use
__traits?
He didn't say *with* runtime but *at*. Changes the whole
meaning ;)
It's OK I found how to achieve what I want. I'll enumerate the
classes an dfrom there work my way down via ClassInfo.interfaces.
It turns out that Interface.classinfocontains the interface's
inherited interfaces; the 'classinfo' name is a bit misleading
though...
Re: Bulk allocation and partial deallocation for tree data structures.
On Tuesday, 4 July 2017 at 02:53:00 UTC, Filip Bystricky wrote: On Tuesday, 4 July 2017 at 01:56:11 UTC, Moritz Maxeiner wrote: [...] However, in many cases it is unacceptable to have to prevent the whole block from being freed (especially if the memory is managed by a compacting gc). Then you must adjust your acceptance parameters, because: Eventually (down the parent Allocator call chain) you will have to get the memory from the operating system, and AFAIK they only support deallocating via pointers to the beginning of a previously allocated block; let PartiallyDeallocatableAllocator (PDA) be our Allocator implementation supporting partial deallocations via such a parent Allocator (Parent) that can only (de)allocate in whole blocks. That means even if Parent collects garbage it will not be able to allocate memory from within a block previously allocated (by PDA calling Parent's allocate) until that (whole) block has been been deallocated in Parent, either explicitly (by PDA), or implicitly by being collected. And since PDA will want to track deallocated subblocks and hand them out in its own `allocate`, bypassing Parent when feasible (otherwise what's the point of supporting partial deallocations if you can't reuse the freed memory), it will have to have pointers to these subblocks, i.e. even if Parent collects garbage, PDA will block the collection, anyway (live pointers into the block). I think the feature would work better as an additional allocator primitive, which should be easy to implement for most allocators that support reallocate (e.g. bitmapped-block and free-list allocators). I don't see how reallocate helps here, as you can only grow/shrink towards the end of a block, not the beginning (so you can only do mimick partial deallocations at the end of a block). In the meantime I realized that since a child node can only [...] Good to see that you found an easier solution :)
Re: Bulk allocation and partial deallocation for tree data structures.
Oh and I forgot to mention: another use-case for this would be for arrays. For manually managed arrays like std.container.array, it would make it possible to transfer ownership of individual objects from the array back to the program after the array goes out of scope. For gc slices, it could enable some gc implementations to deallocate parts of an array even if there are still references pointing inside that array.
Re: Bulk allocation and partial deallocation for tree data structures.
On Tuesday, 4 July 2017 at 01:56:11 UTC, Moritz Maxeiner wrote: On Monday, 3 July 2017 at 17:06:10 UTC, Ali Çehreli wrote: On 07/02/2017 07:56 PM, Stefan Koch wrote: On Monday, 3 July 2017 at 02:51:49 UTC, Filip Bystricky wrote: Anyone? The answer is no. Partial deallocation in an arbitrary fashion is not advisable. And there are no standard library mechanisms for it. Would it be possible to write a custom std.experimental.allocator that does this? Since the `deallocate` function an Allocator has to implement takes a `void[]` (-> known size), it's possible: At deallocation the Allocator will have to check if the given memory subblock lies within any of the previously allocated memory blocks; if it does, it will have to "tear" the to-be-deallocated memory subblock from within it, storing the resulting prefix and suffix memory subblocks (both remain allocated) and removing the original block. It will still have to track those two subblocks as belonging together, though, since it can only deallocate the original memory block back to the parent allocator (another Allocator, or something else) once both of these subblocks are no longer allocated. Obviously this applies to further partial deallocations of subblocks within subblocks. I tend to agree with Stefan that this is likely not sensible, but if in doubt, benchmark for the specific use case. Thanks for the responses! Moritz, that is a good suggestion. However, in many cases it is unacceptable to have to prevent the whole block from being freed (especially if the memory is managed by a compacting gc). I think the feature would work better as an additional allocator primitive, which should be easy to implement for most allocators that support reallocate (e.g. bitmapped-block and free-list allocators). In the meantime I realized that since a child node can only be freed after its parent is freed, I can allocate all 6 nodes in a single allocation, but in reverse order, (putting the leaf at the front and the root at the tail). That way, to free an ancestor, we just realloc the corresponding leaf's memory.
Re: Bulk allocation and partial deallocation for tree data structures.
On Monday, 3 July 2017 at 17:06:10 UTC, Ali Çehreli wrote: On 07/02/2017 07:56 PM, Stefan Koch wrote: On Monday, 3 July 2017 at 02:51:49 UTC, Filip Bystricky wrote: Anyone? The answer is no. Partial deallocation in an arbitrary fashion is not advisable. And there are no standard library mechanisms for it. Would it be possible to write a custom std.experimental.allocator that does this? Since the `deallocate` function an Allocator has to implement takes a `void[]` (-> known size), it's possible: At deallocation the Allocator will have to check if the given memory subblock lies within any of the previously allocated memory blocks; if it does, it will have to "tear" the to-be-deallocated memory subblock from within it, storing the resulting prefix and suffix memory subblocks (both remain allocated) and removing the original block. It will still have to track those two subblocks as belonging together, though, since it can only deallocate the original memory block back to the parent allocator (another Allocator, or something else) once both of these subblocks are no longer allocated. Obviously this applies to further partial deallocations of subblocks within subblocks. I tend to agree with Stefan that this is likely not sensible, but if in doubt, benchmark for the specific use case.
Re: Funny issue with casting double to ulong
On Mon, Jul 03, 2017 at 07:13:45AM +, Era Scarecrow via Digitalmars-d-learn wrote: > On Monday, 3 July 2017 at 06:20:22 UTC, H. S. Teoh wrote: [...] > > I don't think there's a way to change how the FPU works -- the > > hardware is coded that way and can't be changed. You'd have to > > build your own library or use an existing one for this purpose. > > It's been a while, i do recall there was BCD options, actually found > a few of the instructions; However they are more on loading/storing > the value, not on working strictly in that mode. Last i remember > seeing references to BCD work was in 2000 or so. > > I'll have to look further before i find (or fail to find) all that's > BCD related. Still if it IS avaliable, it would be an x87 only option > and thus wouldn't be portable unless the language or a library offered > support. Wow, that brings back the memories... I used to dabble with BCD (only a little bit) back when I was playing with 8086/8088 assembly language. But I've not heard anything about BCD since that era, and I'm surprised people still know what it is. :-D But all I knew about BCD was in the realm of integer arithmetic. I had no idea such things as BCD floats existed. T -- An imaginary friend squared is a real enemy.
Re: Finding all the interfaces and their inheritance relationships at runtime
On Monday, 3 July 2017 at 20:45:19 UTC, bauss wrote:
On Monday, 3 July 2017 at 13:54:42 UTC, Jean-Louis Leroy wrote:
I know how to find all the classes:
foreach (mod; ModuleInfo) {
foreach (c; mod.localClasses) {
// use c.base to construct inheritance graph
}
}
Can I do the same with all the interfaces? Looking at object.d
gives no clue...
Is there a reason you need to do it with runtime and can't use
__traits?
He didn't say *with* runtime but *at*. Changes the whole meaning
;)
Re: Finding all the interfaces and their inheritance relationships at runtime
On Monday, 3 July 2017 at 13:54:42 UTC, Jean-Louis Leroy wrote:
I know how to find all the classes:
foreach (mod; ModuleInfo) {
foreach (c; mod.localClasses) {
// use c.base to construct inheritance graph
}
}
Can I do the same with all the interfaces? Looking at object.d
gives no clue...
Is there a reason you need to do it with runtime and can't use
__traits?
Re: Accessing part of a struct in an easy way
On Monday, 3 July 2017 at 17:30:51 UTC, Ali Çehreli wrote: hOn 07/03/2017 10:13 AM, Paolo Invernizzi wrote: > [...] struct with > [...] I had difficulty understanding the requirements. For example, it's not clear whether you want the literal "first" and "second" names. [...] Thanks Ali, I'm doing something similar, with inout ref in the b function: I'll stick with that. Thanks again to all! /Paolo
Re: Accessing part of a struct in an easy way
hOn 07/03/2017 10:13 AM, Paolo Invernizzi wrote:
> It's not exactly the same, as first and second should be struct with
> partial fields from Foo, of different types.
I had difficulty understanding the requirements. For example, it's not
clear whether you want the literal "first" and "second" names.
If you want to magically use part of a struct as a separate type, it's
impossible in a strongly typed language like D. However, you have
low-level options that allow you to lay data almost in any way you want.
Obviously, if you have access to Foo's source and it's feasible to
change it, you can do this:
struct Foo {
A a;
B b;
}
Assuming that it's not possible, you can cast addresses of parts of the
struct as addresses of other types. Compiles but not tested:
struct Foo {
int a_1; float a_2; string a_3;
string b_1; double b_2;
}
struct A {
int a_1; float a_2; string a_3;
}
struct B {
string b_1; double b_2;
}
auto ref a(ref Foo foo) {
return *cast(A*)_1;
}
auto ref b(ref Foo foo) {
return *cast(B*)_1;
}
void worksOnA(ref A a) {
}
void worksOnB(ref B b) {
}
void main() {
auto foo = Foo();
foo.a.worksOnA();
foo.b.worksOnB();
}
Ali
Re: Accessing part of a struct in an easy way
On Monday, 3 July 2017 at 16:41:51 UTC, vit wrote:
On Monday, 3 July 2017 at 13:53:45 UTC, Paolo Invernizzi wrote:
[...]
//https://dpaste.dzfl.pl/d59469c264b2
import std.algorithm : map, copy, equal;
import std.range : iota;
struct Foo {
int[3] a;
string[2] b;
}
ref T first(R : T[], T)(ref R x,){return x[0];}
ref T second(R : T[], T)(ref R x){return x[1];}
void worksOnA(R : int[N], size_t N)(ref R r) {
iota(1, N+1)
.map!(x => cast(int)x*2)
.copy(r[]);
}
void worksOnB(string[] r) { }
void main(){
auto foo = Foo();
foo.a.first = 1;
foo.a.second = 2;
assert(foo.a.first == 1);
assert(foo.a.second == 2);
foo.b.second = "test";
assert(foo.b.first == "");
assert(foo.b.second == "test");
foo.a.worksOnA();
assert(foo.a[].equal([2, 4, 6]));
}
Thanks for your solution, Vic!
It's not exactly the same, as first and second should be struct
with partial fields from Foo, of different types.
/Paolo
Re: Bulk allocation and partial deallocation for tree data structures.
On 07/02/2017 07:56 PM, Stefan Koch wrote: On Monday, 3 July 2017 at 02:51:49 UTC, Filip Bystricky wrote: Anyone? The answer is no. Partial deallocation in an arbitrary fashion is not advisable. And there are no standard library mechanisms for it. Would it be possible to write a custom std.experimental.allocator that does this? Ali
Re: Accessing part of a struct in an easy way
On Monday, 3 July 2017 at 13:53:45 UTC, Paolo Invernizzi wrote:
I've struct like that:
struct Foo {
int a_1; float a_2; string a_3;
string b_1; double b_2;
}
I would like to transparently access that like:
foo.a.first
foo.b.second = "baz";
with an helper like:
auto a(...) { ... }
auto b(...) { ... }
that can be used also in functions that are expecting it:
void worksOnA( ) { }
void worksOnB( ) { }
auto foo = Foo( ... )
foo.a.worksOnA();
foo.b.worksOnB();
But I'm struggling in finding a good way to do it...
Suggestions?
Thanks!
/Paolo
//https://dpaste.dzfl.pl/d59469c264b2
import std.algorithm : map, copy, equal;
import std.range : iota;
struct Foo {
int[3] a;
string[2] b;
}
ref T first(R : T[], T)(ref R x,){return x[0];}
ref T second(R : T[], T)(ref R x){return x[1];}
void worksOnA(R : int[N], size_t N)(ref R r) {
iota(1, N+1)
.map!(x => cast(int)x*2)
.copy(r[]);
}
void worksOnB(string[] r) { }
void main(){
auto foo = Foo();
foo.a.first = 1;
foo.a.second = 2;
assert(foo.a.first == 1);
assert(foo.a.second == 2);
foo.b.second = "test";
assert(foo.b.first == "");
assert(foo.b.second == "test");
foo.a.worksOnA();
assert(foo.a[].equal([2, 4, 6]));
}
Re: std.json cannot read an array floats back from file
Yuri wrote: On Monday, 3 July 2017 at 14:04:47 UTC, ketmar wrote: Yuri wrote: On Sunday, 2 July 2017 at 21:15:41 UTC, ketmar wrote: [...] I share your sentiment in relation to std.json, ketmar. On a side note, what would be a better way to serialize/deserialize objects in D if std.json does not cut it? It does not have to be JSON serialization although would be preferred. it depends of the types of your objects. simple json-like (de)serializer for objects with fixed layout can be done in very small amount of code[0]. that's what i am using (and it can *read* json into structs too, i'm actually using it to parse some jsons -- idgames API replies, for example). [0] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/txtser.d Thanks, ketmar, I'll have a look into the code, the objects I am dealing with are not particularly complex, that might work well enough. it doesn't matter if objects are complex or not; the only thing that matters is that you must really have *objects* that can be described by structs, not "freeform" json. i.e. txtser cannot deserialize json into dom-like tree structure, only deserialize structs/arrays/aas. but structs can contain other structs, and AA values can be structs too, and so on. i.e.: if you don't need arbitrary access to arbitrary json fields, but only have to deserialize something with known layout, txtser probably can do the job for you.
Re: std.json cannot read an array floats back from file
On Monday, 3 July 2017 at 14:04:47 UTC, ketmar wrote: Yuri wrote: On Sunday, 2 July 2017 at 21:15:41 UTC, ketmar wrote: [...] I share your sentiment in relation to std.json, ketmar. On a side note, what would be a better way to serialize/deserialize objects in D if std.json does not cut it? It does not have to be JSON serialization although would be preferred. it depends of the types of your objects. simple json-like (de)serializer for objects with fixed layout can be done in very small amount of code[0]. that's what i am using (and it can *read* json into structs too, i'm actually using it to parse some jsons -- idgames API replies, for example). [0] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/txtser.d Thanks, ketmar, I'll have a look into the code, the objects I am dealing with are not particularly complex, that might work well enough.
Re: std.json cannot read an array floats back from file
On Monday, 3 July 2017 at 13:34:50 UTC, Adam D. Ruppe wrote:
On Monday, 3 July 2017 at 13:26:52 UTC, Yuri wrote:
Yes, when accessing .integer instead of .floating then it
works, unfortunately that is not suitable for the task at
hand, it has to be a float.
Just write a helper function that casts it yourself:
double numeric(JSONValue v) {
if(v.type == JSON_VALUE.FLOAT)
return v.floating;
else if(v.type == JSON_VALUE.INTEGER)
return v.integer;
else if(v.type == JSON_VALUE.UINTEGER) // I think it has
this too
return v.uinteger;
throw new Exception("not a numeric type, instead: " ~
to!string(v.type));
}
and then you should be able to do
jj.object["floats"].array[1].numeric.writeln;
and have it return float regardless of if it is 1 or 1.0
Thanks Adam, that will work for me. I wish though there was no
need for jumping these hoops in a standard language lib but I
guess it would be a topic for another discussion.
Re: std.json cannot read an array floats back from file
Yuri wrote: On Sunday, 2 July 2017 at 21:15:41 UTC, ketmar wrote: so, write your own wrapper that will convert INTEGER/UINTEGER/FLOAT to `double`. i think this is the best solution (if there can be "best solution" with std.json at all). I share your sentiment in relation to std.json, ketmar. On a side note, what would be a better way to serialize/deserialize objects in D if std.json does not cut it? It does not have to be JSON serialization although would be preferred. it depends of the types of your objects. simple json-like (de)serializer for objects with fixed layout can be done in very small amount of code[0]. that's what i am using (and it can *read* json into structs too, i'm actually using it to parse some jsons -- idgames API replies, for example). [0] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/txtser.d
Finding all the interfaces and their inheritance relationships at runtime
I know how to find all the classes:
foreach (mod; ModuleInfo) {
foreach (c; mod.localClasses) {
// use c.base to construct inheritance graph
}
}
Can I do the same with all the interfaces? Looking at object.d
gives no clue...
Accessing part of a struct in an easy way
I've struct like that:
struct Foo {
int a_1; float a_2; string a_3;
string b_1; double b_2;
}
I would like to transparently access that like:
foo.a.first
foo.b.second = "baz";
with an helper like:
auto a(...) { ... }
auto b(...) { ... }
that can be used also in functions that are expecting it:
void worksOnA( ) { }
void worksOnB( ) { }
auto foo = Foo( ... )
foo.a.worksOnA();
foo.b.worksOnB();
But I'm struggling in finding a good way to do it...
Suggestions?
Thanks!
/Paolo
Re: std.json cannot read an array floats back from file
On Monday, 3 July 2017 at 13:26:52 UTC, Yuri wrote:
Yes, when accessing .integer instead of .floating then it
works, unfortunately that is not suitable for the task at hand,
it has to be a float.
Just write a helper function that casts it yourself:
double numeric(JSONValue v) {
if(v.type == JSON_VALUE.FLOAT)
return v.floating;
else if(v.type == JSON_VALUE.INTEGER)
return v.integer;
else if(v.type == JSON_VALUE.UINTEGER) // I think it has this
too
return v.uinteger;
throw new Exception("not a numeric type, instead: " ~
to!string(v.type));
}
and then you should be able to do
jj.object["floats"].array[1].numeric.writeln;
and have it return float regardless of if it is 1 or 1.0
Re: std.json cannot read an array floats back from file
On Sunday, 2 July 2017 at 21:15:41 UTC, ketmar wrote: so, write your own wrapper that will convert INTEGER/UINTEGER/FLOAT to `double`. i think this is the best solution (if there can be "best solution" with std.json at all). I share your sentiment in relation to std.json, ketmar. On a side note, what would be a better way to serialize/deserialize objects in D if std.json does not cut it? It does not have to be JSON serialization although would be preferred.
Re: std.json cannot read an array floats back from file
On Sunday, 2 July 2017 at 21:12:48 UTC, Adam D. Ruppe wrote: On Sunday, 2 July 2017 at 21:07:40 UTC, Yuri wrote: It is expected to print '2' in the console, however an exception is thrown: std.json.JSONException@/build/ldc-I3nwWj/ldc-0.17.1/runtime/phobos/std/json.d(235): JSONValue is not a floating type I think it just read the json string of "1" as being an integer instead of a float, so the reader thought it was integral instead of floating. It should prolly just transparently auto-convert, but it doesn't seem to. Try accessing the int instead and see waht happens. Yes, when accessing .integer instead of .floating then it works, unfortunately that is not suitable for the task at hand, it has to be a float.
Re: Funny issue with casting double to ulong
On Monday, 3 July 2017 at 05:38:56 UTC, Era Scarecrow wrote: On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote: 6.251 has no perfect double representation. It's real value is: I almost wonder if a BCD, fixed length or alternative for floating point should be an option... Either library, or a hook to change how the FPU works since doubles are suppose to do 16-18 digits of perfect simple floatingpoint for the purposes of money and the like without relying on such imperfect transitions. IBM zSeries and POWER since POWER6 have BCD floating point unit...
Re: Need simple sound
On Monday, 3 July 2017 at 09:24:35 UTC, Guillaume Piolat wrote: On Monday, 3 July 2017 at 08:55:20 UTC, Martin Tschierschke wrote: Hello for a simple game I would like to add some very simple sound, not much different than the beeps of "PAC Man". Is there anything I can use for this? DerelictSDL supports the loading of SDL_mixer, which makes it very practical. Thank you for the hint, a short google search was not so successful, can you give me an additional hint / link? I think I would have to produce a time series of a sinus for example and to play it?
Re: Funny issue with casting double to ulong
On Monday, 3 July 2017 at 04:06:23 UTC, Saurabh Das wrote: On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote: On Monday, 3 July 2017 at 03:50:14 UTC, Saurabh Das wrote: [...] 6.251 has no perfect double representation. It's real value is: 6.215099962483343551867E0 Hence when you cast to ulong after the product by 10_000, this is the equivalent of trunc(62150.99962483343551867E0) which gives 62150 CQFD ;-] That explains it! Thank you. There's been a small typo in my answer. "6.251" i meant obviously "6.2151". Anyway it doesn't change anything the most accurate double representation is well the long number i said.
Re: Need simple sound
On Monday, 3 July 2017 at 08:55:20 UTC, Martin Tschierschke wrote: Hello for a simple game I would like to add some very simple sound, not much different than the beeps of "PAC Man". Is there anything I can use for this? DerelictSDL supports the loading of SDL_mixer, which makes it very practical.
Need simple sound
Hello for a simple game I would like to add some very simple sound, not much different than the beeps of "PAC Man". Is there anything I can use for this?
Re: Funny issue with casting double to ulong
On Mon, Jul 03, 2017 at 05:38:56AM +, Era Scarecrow via Digitalmars-d-learn wrote: > On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote: > > 6.251 has no perfect double representation. It's real value is: > > I almost wonder if a BCD, fixed length or alternative for floating > point should be an option... Either library, or a hook to change how > the FPU works since doubles are suppose to do 16-18 digits of perfect > simple floatingpoint for the purposes of money and the like without > relying on such imperfect transitions. >From what I've heard, word on the street is to avoid using floating-point for money calculations, and use fixed-point arithmetic instead (i.e., basically ints / longs, with a built-in decimal point in a fixed position). Inexact representations of certain fractions of tens like the above are one reason for this. I don't think there's a way to change how the FPU works -- the hardware is coded that way and can't be changed. You'd have to build your own library or use an existing one for this purpose. T -- Food and laptops don't mix.
