Re: Library design
On Friday, 13 June 2014 at 04:11:38 UTC, Rutger wrote:
I'm trying to create a minimal tweening library in D based on
the
commonly used easing equations by Robert Penner
(http://www.robertpenner.com/easing/).
One of the goals with the design of the library is that any
numeric type should be tweenable.(The user of the library
shouldn't have to do any casting of their own etc) Now how do I
go about and design a data structure that can take either
floats,
ints or doubles, store them and modify them?
This is what I hacked together earlier today:
abstract class TweenWrapper{
}
class Tween(T) : TweenWrapper{
T owner;
string[] members;
/** Duration in milliseconds */
int duration;
/** Elapsed time in milliseconds */
int elapsedTime;
bool isComplete;
/** Type of easing */
EasingType easingType;
}
TweenWrapper is just what it sounds like, a wrapper so I don't
have to specify any type for the container holding the Tween
objects(DList!TweenWrapper).
__traits(getMember, owner, members[0]) =
valueReturnedFromEasingFunction;
Was How I planned to use this class.. but you know, compile time
only.
Let me know if this isn't enough to go on.
Is what I'm asking even possible(the easy way) in D?
TL;DR
Help me make D Dynamic!
From what i can tell you want something similar to this.
interface ITween
{
void update(int elapsedTime);
}
class Tween(T, string member) : ITween
{
//Expands to
//|alias memberType = typeof(T.memberName);|
mixin("alias memberType = typeof("
~ T.stringof ~ "." ~ member ~ ");");
memberType from;
memberType to;
EasingType type;
int duration;
int elapsedTime;
T owner;
@property bool isComplete()
{
return elapsedTime >= duration;
}
void update(int time)
{
elapsedTime = min(elapsedTime + time, duration);
double amount = elapsedTime / cast(double)duration;
auto tweened = ease(type, from, to, amount);
__traits(getMember, owner, member) = tweened;
}
}
Where ease is a method that will look something like this:
T ease(T)(EasingType type, T from, T to, double amount)
if(isNumeric!T)
{
double result;
if(type == EasingType.linear)
result = linearEase(amount);
else
assert(0, "Not yet implemented");
return cast(T)((to - from) * result + from));
}
double linearEase(double amount)
{
return amount;
}
This will work for all number types.
Hope this was helpful.
__traits(position,symbol) to get the file:line:column:index of a symbol (module,unittest etc)
Wouldn't that be nice? it's all known at CT so why not expose it among other things it'd allow proper association of modules to files in stacktraces (sometimes this is impossible / ambiguous), custom user defined error messages involving lambdas, printing unittest lines etc.
Library design
I'm trying to create a minimal tweening library in D based on the
commonly used easing equations by Robert Penner
(http://www.robertpenner.com/easing/).
One of the goals with the design of the library is that any
numeric type should be tweenable.(The user of the library
shouldn't have to do any casting of their own etc) Now how do I
go about and design a data structure that can take either floats,
ints or doubles, store them and modify them?
This is what I hacked together earlier today:
abstract class TweenWrapper{
}
class Tween(T) : TweenWrapper{
T owner;
string[] members;
/** Duration in milliseconds */
int duration;
/** Elapsed time in milliseconds */
int elapsedTime;
bool isComplete;
/** Type of easing */
EasingType easingType;
}
TweenWrapper is just what it sounds like, a wrapper so I don't
have to specify any type for the container holding the Tween
objects(DList!TweenWrapper).
__traits(getMember, owner, members[0]) =
valueReturnedFromEasingFunction;
Was How I planned to use this class.. but you know, compile time
only.
Let me know if this isn't enough to go on.
Is what I'm asking even possible(the easy way) in D?
TL;DR
Help me make D Dynamic!
Re: win64 as orphan?
On 6/9/2014 11:42 AM, lurker wrote: i agree with you, but you should have posted in "announce", so that adrei can use it for some marketing. i too wait now for a long, long time to use it with win64. i am also giving up - i guess it will stay a linux/apple show. maybe, as a multiple os compiler, you can use lazarus or code typhon. cheers. On Monday, 9 June 2014 at 15:04:19 UTC, trail wrote: will the sorry state of the win64 headers and programs like dfl be fixed or is it time to leave the language to linux and move on to something else? Clang can parse windows.h these days, it might be worthwhile to use their toolchain to dump the various SDKs of windows.h into some kind of database with it, and write an exporter for the database to D. I imagine there is some overlap here that other languages could use something like this to provide up to date windows bindings (MingW in particular, and anyone else making new languages) I'm sure some hand additions would need to exist but a huge amount of the API could probably be handled with something like that.
Re: HeadUnshared in core.atomic
On Thursday, 12 June 2014 at 05:29:39 UTC, Mike Franklin wrote:
Hello,
I was recently exposed to this template in core.atomic:
private
{
template HeadUnshared(T)
{
static if( is( T U : shared(U*) ) )
alias shared(U)* HeadUnshared;
else
alias T HeadUnshared;
}
}
Could someone please explain/elaborate on what this is doing,
and why it's necessary and used so often in core.atomic?
This is used to generate the return type when the return value is
a copy of the input. This is of particular importance for
operations like atomicLoad, whose purpose is to atomically obtain
a local copy of a shared value.
Re: one of the weirdest bugs ever - request for testing
On 2014-06-12 17:27, Rene Zwanenburg wrote: On Thursday, 12 June 2014 at 22:14:23 UTC, captaindet wrote: On 2014-06-12 14:20, captaindet wrote: before i file it, i'd like to know if it is still around in the latest DMD version and/or if other platforms and 64bit code is affected as well. thanks andrew, philippe, i had the suspicion that it is a windows only problem anyway because the only thing that an unused std.file would do is pulling a lot of windows specific stuff (on my system). if now someone could test this with the current DMD on windows, 64 and 32 bit executables... /det No problems with 2.065 on win, both 32 and 64 bit. great, thanks, so no need to file a bug report. some other bugfix seemed to have taken care of the issue alongside. (in the meantime i had the bug confirmed on another win7/64 machine, however, using DMD2.0642 again.) hopefully it is still fixed in 2.066 which will be my next upgrade step once it is out. /det
Known problem? DMD commandline module order matters for debugging on amd64 linux
I'm not sure if this is a known problem, or if it's something
that I'd need to file a new bug for, but if a program is compiled
with a module besides the one containing main() first on the
commandline, certain debug info is clobbered on 64-bit linux.
An easy testcase, with module afunc.d:
module afunc;
auto inc (size_t var) {
return ++var;
}
and module main.d:
import afunc;
void main() {
size_t counter;
while (counter < size_t.max) {
counter++;
}
}
Compile with the following command:
$ dmd -m64 -g -ofbadsymbols afunc.d main.d
$ gdb ./badsymbols
if you run the program for a moment, then ^C and type 'print
counter', gdb gives the error 'Could not find the frame base for
"D main".'
However, compiling with this command:
$ dmd -m64 -g -ofgoodsymbols main.d afunc.d
using print counter in gdb will actually work.
Re: Cannot alias null
On 06/12/2014 03:38 PM, monarch_dodra wrote: > Yet you can alias variables... > > int i; > alias j = i; Initially I forgot about the fact that symbols can be alias'ed as well. So that's fine. > So there's something special about "null". The difference is that null is an expression. It is the same limitation as not being able to alias a literal. alias zero = 0; alias blah = null; Those two declarations fail for the same reason: Error: basic type expected, not 0 Error: semicolon expected to close alias declaration Error: basic type expected, not null Error: semicolon expected to close alias declaration The pair of error messages are somewhat silly: The first one is misleading because as we know, it should say "basic type *or symbol* expected"; and the second one is bogus because there actually is a semicolon there: :p Ali
Re: Cannot alias null
On Thursday, 12 June 2014 at 20:44:16 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Thu, Jun 12, 2014 at 03:26:13PM -0500, Tom Browder via Digitalmars-d-learn wrote: This will not compile: alias blah = null; [...] 'null' is a value, not a type. Try: alias blah = typeof(null); T Yet you can alias variables... int i; alias j = i; So there's something special about "null".
Re: Cannot alias null
On Thursday, 12 June 2014 at 21:58:32 UTC, Adam D. Ruppe wrote:
since null is a value maybe you want
enum blah = null;
you may also give it a type after the enum word
I *think* the issue might be that "null" is an rvalue? Because
you can alias variable names all you want. I do it all the time
for templates where I *may* need a temporary.
eg:
void foo(T)(T val)
{
static if (isUnsigned!T)
alias uval = val;
else
auto uval = unsigned(val);
...
}
It's also quite useful with varargs:
alias a0 = args[0];
Also, you can't alias things like "int.init" either. I'm not sure
the "rvalue" thing is the source, because these work:
//struct S
{
static int i;
static int j() @property;
}
alias a = S.i;
alias b = S.j;
//
I'd consider filling a bug report.
Re: Core dump with dstep on 64-bit Linux (Debian 7): testers needed
On Thu, Jun 12, 2014 at 5:17 PM, Dicebot via Digitalmars-d-learn wrote: > confirmed and commmented in that issue Thank you! That makes me feel better, but I guess Jacob has a valid bug on his hands. It will be interesting to see the fix. Best regards, -Tom
Re: one of the weirdest bugs ever - request for testing
On Thursday, 12 June 2014 at 22:14:23 UTC, captaindet wrote: On 2014-06-12 14:20, captaindet wrote: before i file it, i'd like to know if it is still around in the latest DMD version and/or if other platforms and 64bit code is affected as well. thanks andrew, philippe, i had the suspicion that it is a windows only problem anyway because the only thing that an unused std.file would do is pulling a lot of windows specific stuff (on my system). if now someone could test this with the current DMD on windows, 64 and 32 bit executables... /det No problems with 2.065 on win, both 32 and 64 bit.
Re: Core dump with dstep on 64-bit Linux (Debian 7): testers needed
confirmed and commmented in that issue
Re: Cannot alias null
On Thu, Jun 12, 2014 at 4:58 PM, Adam D. Ruppe via Digitalmars-d-learn wrote: > since null is a value maybe you want > > enum blah = null; That works. > you may also give it a type after the enum word But I can't get any other variant to work so far. -Tom
Re: one of the weirdest bugs ever - request for testing
On 2014-06-12 14:20, captaindet wrote: before i file it, i'd like to know if it is still around in the latest DMD version and/or if other platforms and 64bit code is affected as well. thanks andrew, philippe, i had the suspicion that it is a windows only problem anyway because the only thing that an unused std.file would do is pulling a lot of windows specific stuff (on my system). if now someone could test this with the current DMD on windows, 64 and 32 bit executables... /det
Core dump with dstep on 64-bit Linux (Debian 7): testers needed
I built dstep from this repo on a Debian Linux 64-bit system (after building and installing the dmd suite from its repos). But I'm having problems using it. Given a file t.h with sole contents: extern const char *const sys_errlist[]; I run dstep on it and get a core dump: $ dstep -x c -o t.d t.c Segmentation fault (core dumped) Jacob Carlborg, dstep's maintainer, cannot duplicate the problem on OS X. Can anyone hear try it on another system and see results? I know Jacob would appreciate it. The problem is filed as bug #26 and can be seen here: https://github.com/jacob-carlborg/dstep/issues/26#issuecomment-45435438 Thanks. Best regards, -Tom
Re: Cannot alias null
since null is a value maybe you want enum blah = null; you may also give it a type after the enum word
Re: Cannot alias null
On Thu, Jun 12, 2014 at 4:17 PM, Ali Çehreli wrote: > On 06/12/2014 02:06 PM, Tom Browder via Digitalmars-d-learn wrote: ... >> What I was really trying to do was D'ify C expressions like this: >> >>typedef ((struct t*)0) blah; ... >> So, taking your advice, I found this to work (at least it compiles as >> a translation: >> >>alias blah = typeof(null); > > I suspect you need something else. :) Undoubtedly, indeed! [Still a WIP (work in progress).] Best, -Tom
Re: Cannot alias null
On 06/12/2014 02:06 PM, Tom Browder via Digitalmars-d-learn wrote: > What I was really trying to do was D'ify C expressions like this: > >typedef ((struct t*)0) blah; Is that actually a function pointer typedef? I can't parse that line. :) > So, taking your advice, I found this to work (at least it compiles as > a translation: > >alias blah = typeof(null); I suspect you need something else. :) Ali
Re: Cannot alias null
On Thu, Jun 12, 2014 at 3:42 PM, H. S. Teoh via Digitalmars-d-learn wrote: > On Thu, Jun 12, 2014 at 03:26:13PM -0500, Tom Browder via Digitalmars-d-learn > wrote: >> This will not compile: >> >> alias blah = null; > [...] > > 'null' is a value, not a type. Try: > > alias blah = typeof(null); Great, that works! What I was really trying to do was D'ify C expressions like this: typedef ((struct t*)0) blah; So, taking your advice, I found this to work (at least it compiles as a translation: alias blah = typeof(null); Thanks,T and Ali. Best, -Tom
Re: Cannot alias null
On 06/12/2014 01:36 PM, Andrew Edwards wrote:
> void foo() {}
> alias bar = foo();
>
> Am I just misunderstanding what is meant by types?
Seems to be an old behavior. That does not compile with 2.066:
Error: function declaration without return type. (Note that constructors
are always named 'this')
The following compiles though:
alias bar = foo;
I stand corrected: alias works not only with types but with symbols as
well. I was right about the original code though: "Aliases cannot be
used for expressions".
Ali
Re: Cannot alias null
On Thu, Jun 12, 2014 at 03:26:13PM -0500, Tom Browder via Digitalmars-d-learn wrote: > This will not compile: > > alias blah = null; [...] 'null' is a value, not a type. Try: alias blah = typeof(null); T -- If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.
Re: Cannot alias null
On 6/12/14, 4:29 PM, Ali Çehreli wrote:
On 06/12/2014 01:26 PM, Tom Browder via Digitalmars-d-learn wrote:
> This will not compile:
>
>alias blah = null;
>
> The dmd message are:
>
> di/test_hdr.d(10): Error: basic type expected, not null
> di/test_hdr.d(10): Error: semicolon expected to close alias declaration
> di/test_hdr.d(10): Error: Declaration expected, not 'null'
>
> Are there any other objects that cannot be aliased?
alias works only with types. Being an expression (not an object), null
cannot not work with alias.
Ali
void foo() {}
alias bar = foo();
Am I just misunderstanding what is meant by types?
Re: Cannot alias null
On 06/12/2014 01:26 PM, Tom Browder via Digitalmars-d-learn wrote: > This will not compile: > >alias blah = null; > > The dmd message are: > > di/test_hdr.d(10): Error: basic type expected, not null > di/test_hdr.d(10): Error: semicolon expected to close alias declaration > di/test_hdr.d(10): Error: Declaration expected, not 'null' > > Are there any other objects that cannot be aliased? alias works only with types. Being an expression (not an object), null cannot not work with alias. Ali
Cannot alias null
This will not compile: alias blah = null; The dmd message are: di/test_hdr.d(10): Error: basic type expected, not null di/test_hdr.d(10): Error: semicolon expected to close alias declaration di/test_hdr.d(10): Error: Declaration expected, not 'null' Are there any other objects that cannot be aliased? Thanks, Best, -Tom
Re: one of the weirdest bugs ever - request for testing
>> // wrong code gen(*) with -release -O -inline -noboundscheck or
>> // with -release -inline -noboundscheck but only if std.file is imported:
>>
>> auto x = countUntil( names, "FOO" );
>> write(x);
>> if( 0 <= x ) writeln(" found a FOO"); // (*) not found!
>> }
>
>
> I'm running OSX Mavericks with DMD v2.065.0. This behavior cannot be
> reproduced.
Linux, 64bits, DMD v2.065.0
Works OK for me ("1 found a FOO"), with or without importing std.file
and compiling with -release -inline -noboundscheck
Re: one of the weirdest bugs ever - request for testing
On 6/12/14, 3:20 PM, captaindet wrote:
import std.stdio;
import std.algorithm;
import std.file;// not needed, but if imported, causing trouble, see
below
void main()
{
auto names = ["one","FOO","two","three"];
// wrong code gen(*) with -release -O -inline -noboundscheck or
// with -release -inline -noboundscheck but only if std.file is imported:
auto x = countUntil( names, "FOO" );
write(x);
if( 0 <= x ) writeln(" found a FOO"); // (*) not found!
}
I'm running OSX Mavericks with DMD v2.065.0. This behavior cannot be
reproduced.
Re: Working on a library: request for code review
On Wednesday, 11 June 2014 at 18:29:27 UTC, Mike wrote:
Here's the link to the repo: http://bit.ly/1mIuGhv
I usually don't trust shortened URL's. Can you please post full
URL's when not constrained by a character limit?
Any feedback would be great!
First of all, I like your coding style. It's nice and readable :)
https://github.com/emesx/TGA/blob/develop/source/tga/model/utils.d
All those functions can be marked pure. Pure is D is a bit
different than in other languages. I can recommend the following
article as a good explanation:
http://klickverbot.at/blog/2012/05/purity-in-d/
Also, depending on your preference, you may want to put those
functions in a
pure nothrow
{
}
block, or put
pure nothrow:
at the top of the source file. I'm not sure if all those
functions can be nothrow though.
https://github.com/emesx/TGA/blob/develop/source/tga/model/utils.d#L8
These array literals will be allocated every time the function is
called. 'only' can be used instead:
only(16, 32).canFind // etc..
http://dlang.org/library/std/range/only.html
I remember a function which does something like only only +
canFind on one go. It would look something like
header.colorMapDepth.among(16, 32);
but I can't find it right now.. Maybe it was only proposed but
never added.
https://github.com/emesx/TGA/blob/develop/source/tga/model/utils.d#L101
This has a pretty bad time complexity. In the worst case this is
O(n^2), I think. You could use a hashmap to build the table, then
convert to an array. Or even only use hashmaps as color tables
internally to improve performance across the board.
https://github.com/emesx/TGA/blob/develop/source/tga/model/types.d#L11
Depending on your taste, a union + anonymous struct could be used:
struct Pixel
{
union
{
ubyte[4] bytes;
struct
{
ubyte b, g, r, a;
}
}
}
https://github.com/emesx/TGA/blob/develop/source/tga/model/validation.d#L47
to!string is so common it has a special alias: text. It's placed
in std.conv so you still need to import that.
"Invalid color map pixel depth: " ~ header.colorMapDepth.text
https://github.com/emesx/TGA/blob/develop/source/tga/io/readers.d#L24
Yeah, we need something to read an entire struct from a file and
convert it to the correct endianness..
https://github.com/emesx/TGA/blob/develop/source/tga/io/readers.d#L24
https://github.com/emesx/TGA/blob/develop/source/tga/io/readers.d#L91
Unnecessary GC allocation in a hot loop == :(
Make a buffer outside the loop and call the normal rawRead:
auto buffer = new ubyte[colorMapByteDepth];
foreach(i; 0 .. (header.colorMapLength - header.colorMapOffset))
{
file.rawRead(buffer);
colorMap[i] = pixelReader(buffer);
}
Even better, use a static array with the max byte depth, then
slice to the correct length:
ubyte[MaxByteDepth] buffer;
foreach(i; 0 .. (header.colorMapLength - header.colorMapOffset))
{
colorMap[i] = file.rawRead(buffer[0 ..
colorMapByteDepth]).pixelReader;
}
Do the same thing here:
https://github.com/emesx/TGA/blob/develop/source/tga/io/utils.d#L5
T read(T)(File file) if(isNumeric!T){
ubyte[T.sizeof] bytes;
file.rawRead(s[]);
return littleEndianToNative!T(bytes);
}
https://github.com/emesx/TGA/blob/develop/source/tga/io/readers.d#L144
Depending on your taste. The first is built in, the other needs
std.algorithm.
pixel.bytes[] = chunk[];
chunk.copy(pixel.bytes);
https://github.com/emesx/TGA/blob/develop/source/tga/io/utils.d#L40
There's a version in std.algorithm:
http://dlang.org/phobos/std_algorithm.html#min
I need to go. Please don't mind any typo's and untested code ;).
Didn't take a look at writers yet, readers and util need some
more scrutiny, but the main theme is: eliminate unnecessary
temporary GC allocations.
one of the weirdest bugs ever - request for testing
hi,
i just run into a (wrong code gen?) bug that manifests itself only under
certain conditions.
before i file it, i'd like to know if it is still around in the latest DMD
version and/or if other platforms and 64bit code is affected as well.
bug description:
std.algorithm.countUntil fails to find the needle
my system:
DMD 2.0642 compiling into 32bit code on Win7 64bit
required conditions:
compile with -release -inline -noboundscheck
(an additional -O will also cause the bug)
AND the module imports std.file
/det
import std.stdio;
import std.algorithm;
import std.file;// not needed, but if imported, causing trouble, see below
void main()
{
auto names = ["one","FOO","two","three"];
// wrong code gen(*) with -release -O -inline -noboundscheck or
// with -release -inline -noboundscheck but only if std.file is imported:
auto x = countUntil( names, "FOO" );
write(x);
if( 0 <= x ) writeln(" found a FOO"); // (*) not found!
}
Re: Working on a library: request for code review
I can shed some light on my, beginners, point of view and the rationale behind this tiny library. I want to create a bar/matrix-code generator (QR, DataMatrix etc.). I really like graphics-related subjects and I thought this would be a good start in D. Coming from Java island and having experience in Go I expected to find some basic imaging functionalities in the standard library: not necessary support for all image formats, but at least some bitmap i/o and data model (Pixel, Image, Filter ...). I found none of that :-( IMHO (one of the) pain(s) of C++ is that the stdlib is far behind what a modern developer would consider "elementary". But I expected something from D, because Phobos is already more than C++'s stdlib is: Phobos has e.g. digests. IMO digests are not (as) necessary for a standard library as, say, a qsort is. So if there are digests, why not imaging? Either way, D is really nice and if I can help, I will :-) So far - the TGA lib. Best, Mike
Re: Working on a library: request for code review
Le 12/06/2014 20:35, Xavier Bigand a écrit : Le 12/06/2014 20:09, Rene Zwanenburg a écrit : On Thursday, 12 June 2014 at 15:46:12 UTC, Mike wrote: On Thursday, 12 June 2014 at 00:20:28 UTC, cal wrote: Might it be worth stitching things together into a proper image processing package? Well I started working on TGA because I was disappointed that no image abstraction is present in Phobos. Go has some imaging APIs and I think D would benefit from having one too (out of the box). Would I work on std.image? Sure. Best, Mike I'm looking over your code ATM but I'd like to reply to this first. IMO it's not a good idea to create something like std.image. The std lib should ideally never have breaking changes, so it's easy to get stuck with a sub optimal API or become increasingly hard to maintain. We have Dub. Better keep the std lib lean and maintainable. If you're looking to create an awesome idiomatic D image library you're probably better of building it on top of derelict-devil or derelict-freeimage, then publish it on code.dlang.org The discoverability of good code.dlang.org projects is still limited. Some kind of rating or like system would be useful, but that's another discussion. I think it can be a great advantage to have some things like image management in phobos, cause often dub projects are big and users don't want necessary a complete multimedia library but just small pieces that are standard. For example a GUI library, will allow image manipulations, but not only, and extracting only the image modules can be hard. That the case of our DQuick project. For a project like DQuick, I would be happy to find things like images, geometric algebra,environment analysis,... in phobos. This will allow use to be focused on other things making an UI framework (Windows, events, rendering, resource management,...). Having such minimalistic APIs would be a great benefit IMO, maybe in this case some extending libraries would appear in dub. I am thinking an other benefit is what you see as a default, the assurance of D standard conformances (portability, safety, quality, support,...).
Re: Working on a library: request for code review
Le 12/06/2014 20:09, Rene Zwanenburg a écrit : On Thursday, 12 June 2014 at 15:46:12 UTC, Mike wrote: On Thursday, 12 June 2014 at 00:20:28 UTC, cal wrote: Might it be worth stitching things together into a proper image processing package? Well I started working on TGA because I was disappointed that no image abstraction is present in Phobos. Go has some imaging APIs and I think D would benefit from having one too (out of the box). Would I work on std.image? Sure. Best, Mike I'm looking over your code ATM but I'd like to reply to this first. IMO it's not a good idea to create something like std.image. The std lib should ideally never have breaking changes, so it's easy to get stuck with a sub optimal API or become increasingly hard to maintain. We have Dub. Better keep the std lib lean and maintainable. If you're looking to create an awesome idiomatic D image library you're probably better of building it on top of derelict-devil or derelict-freeimage, then publish it on code.dlang.org The discoverability of good code.dlang.org projects is still limited. Some kind of rating or like system would be useful, but that's another discussion. I think it can be a great advantage to have some things like image management in phobos, cause often dub projects are big and users don't want necessary a complete multimedia library but just small pieces that are standard. For example a GUI library, will allow image manipulations, but not only, and extracting only the image modules can be hard. That the case of our DQuick project. For a project like DQuick, I would be happy to find things like images, geometric algebra,environment analysis,... in phobos. This will allow use to be focused on other things making an UI framework (Windows, events, rendering, resource management,...). Having such minimalistic APIs would be a great benefit IMO, maybe in this case some extending libraries would appear in dub.
Re: crt1.o: could not read symbols: Bad value
On Wednesday, 11 June 2014 at 17:21:54 UTC, Tim wrote:
On Wednesday, 11 June 2014 at 17:11:51 UTC, Tim wrote:
On Wednesday, 11 June 2014 at 10:09:50 UTC, FreeSlave wrote:
I conclude that because I have similar errors when trying to
build 64-bit library on 32-bit system.
/usr/bin/ld:
/usr/lib/x86_64-linux-gnu/libphobos2.a(format_712_5b3.o):
relocation R_X86_64_32 against `.rodata' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/x86_64-linux-gnu/libphobos2.a: error adding symbols:
Bad value
collect2: error: ld returned 1 exit status
--- errorlevel 1
But paths in your error log look like you're on x64, so it's
probably not the case.
Yes, I'm using a x64 system (CentOS 6.5), but I also use dmd64.
It seems that -defaultlib=libphobos2.so solved the problem.
When I use the following compile command:
dmd test.d -shared -defaultlib=libphobos2.so
I don't get any error. I hope the shared object works as
expect...
I can compile my so-library (which contains MySQL UDF Functions).
It also works - as long as I try to create objects or assign
something like this:
export extern(C):
char* mysql_custom_udf(UDF_INIT* initid, UDF_ARGS* args, char*
result, c_ulong *length, char* is_null, char* error)
{
JSONValue json = null;
json = ["myObject" : "AssignSomething"]; // <- That throws the
exception
string res = "Hello World!";
result = cast(char*) res.ptr;
*length = res.length;
return cast(char*) result;
}
The function above is contained inside the shared object (so)
file. When I remove/comment out the "json = ["myObject" :
"AssignSomething"];"-line I can call the udf from MySQL. But when
I uncomment/insert the line I'm getting the following error:
Thread pointer: 0x1d24250
Attempting backtrace. You can use the following information to
find out
where mysqld died. If you see no messages after this, something
went
terribly wrong...
stack_bottom = 7fc98804ae18 thread_stack 0x4
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8cea15]
/usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x65e0d4]
/lib64/libpthread.so.0(+0xf710)[0x7fc98abcb710]
/usr/lib64/libphobos2.so.0.65(gc_malloc+0x29)[0x7fc951a70e05]
Any suggestions how to solve that error? It seems that there's
anything wrong with gc_malloc in libphobos2...
Re: Working on a library: request for code review
On Thursday, 12 June 2014 at 15:46:12 UTC, Mike wrote: On Thursday, 12 June 2014 at 00:20:28 UTC, cal wrote: Might it be worth stitching things together into a proper image processing package? Well I started working on TGA because I was disappointed that no image abstraction is present in Phobos. Go has some imaging APIs and I think D would benefit from having one too (out of the box). Would I work on std.image? Sure. Best, Mike I'm looking over your code ATM but I'd like to reply to this first. IMO it's not a good idea to create something like std.image. The std lib should ideally never have breaking changes, so it's easy to get stuck with a sub optimal API or become increasingly hard to maintain. We have Dub. Better keep the std lib lean and maintainable. If you're looking to create an awesome idiomatic D image library you're probably better of building it on top of derelict-devil or derelict-freeimage, then publish it on code.dlang.org The discoverability of good code.dlang.org projects is still limited. Some kind of rating or like system would be useful, but that's another discussion.
Re: Nameless Static Array
On Thursday, 12 June 2014 at 15:58:25 UTC, Taylor Hillegeist
wrote:
So, Lately I have been avoiding the NEW keyword.
Why? Is malloc OK?
I have recently given up static allocation of classes using
CTFE. I guess they must be const or immutable?
Funny, because you *are* allowed to default initialized a class
member variable to a static class instance. And basically, it's
just a thread local global. So you can "work around" with:
//
class MyClass
{
int i = 5;
}
void main() {
static struct S
{
MyClass g = new MyClass();
}
static S s;
writeln(s.g.i);
}
//
Disclaimer: Not sure if actually legal, or will cease to work in
a few releases.
So naturally i can do most of what i need to with structs. They
are statically allocated no NEW necessary. But without the NEW
strategy. I must allocate static arrays and set them to a
pointer in my struct. Not too big of deal really.
uint[12] Buffer;
R_R_Buffer RRB=R_R_Buffer(Buffer);
uint[24] OtherBuffer;
R_R_Buffer RRB2 = R_R_Buffer(OtherBuffer);
I feel though i might end up having OtherOtherOtherBuffers, and
it pollutes my local symbols. I just dont like it.
Is there a way to not give the buffer a name and do lika dis:
R_R_Buffer RRB=R_R_Buffer(uint[12]);
R_R_Buffer RRB2 = R_R_Buffer(uint[24]);
This obviously fails to compile, but i think you get the idea.
Mostly, I don't care what the static array name is.
If you have a pointer, then at the end of the day *someone*
*somewhere*, is going to have to declare and hold the buffers.
That said, you could simply have a *single* static array that
holds all your data. Furthermore, you could package it into a
single convenient struct package:
struct Buffer(T, size_t N)
{
T[N] buffer;
size_t used;
T[] getBufferSlice(size_t n) {
assert(used + n <= N, "You've overused your buffer!");
auto low = used;
used += n;
return buffer[low .. used];
}
ref T[n] getBufferSlice(size_t n)() {
return *cast(T[n]*) getBufferSlice(n).ptr;
}
}
void main()
{
Buffer!(int, 36) myData;
int[] a= myData.getBufferSlice(12);
int[24]* p = &myData.getBufferSlice!24();
}
Notice that with this approach, you can extract a dynamic slice
referencing stack data, if you don't know the size you want. If
you statically know the size you want, then you can call your
function template style, and have a more strongly typed return
value, that can be passed by ref.
Re: Nameless Static Array
On Thursday, 12 June 2014 at 16:08:49 UTC, Taylor Hillegeist
wrote:
I am considering having different sized arrays for the buffer.
I just figured that meant having different structs with various
sizes.
You might be able to do it with a templated struct and alias
this. Check this out:
struct R_Buffer {
int[] buffer;
}
struct R_Buffer_Sized(size_t bufferSize) {
int[bufferSize] buffer;
R_Buffer getGenericBuffer() { return R_Buffer(buffer[]); }
alias getGenericBuffer this;
}
usage:
R_Buffer_Sized!48 buffer;
then you can pass buffer to any function expecting a regular
R_Buffer and it will just work. Be careful not to store the
buffer though, since it is stack allocated, escaping a reference
to it will lead to crashes.
That's also the reason why something like this is a bit
problematic:
R_R_Buffer RRB=R_R_Buffer(uint[12]);
What's the lifetime of the uint[12]? It is in the scope of the
function call only, so if this were allowed, the compiler might
consider it a temporary... and then you'd escape a reference to
it and get corrupted data.
Putting the buffer up top as a separate variable at least gives
it a clear lifetime scope.
Re: Nameless Static Array
On Thursday, 12 June 2014 at 16:02:18 UTC, Adam D. Ruppe wrote: On Thursday, 12 June 2014 at 15:58:25 UTC, Taylor Hillegeist wrote: But without the NEW strategy. I must allocate static arrays and set them to a pointer in my struct. Not too big of deal really. Have you considered just making the buffer a struct member? I have indeed! I am considering having different sized arrays for the buffer. I just figured that meant having different structs with various sizes.
Re: Nameless Static Array
On Thursday, 12 June 2014 at 15:58:25 UTC, Taylor Hillegeist wrote: But without the NEW strategy. I must allocate static arrays and set them to a pointer in my struct. Not too big of deal really. Have you considered just making the buffer a struct member?
Nameless Static Array
So, Lately I have been avoiding the NEW keyword. I have recently given up static allocation of classes using CTFE. I guess they must be const or immutable? So naturally i can do most of what i need to with structs. They are statically allocated no NEW necessary. But without the NEW strategy. I must allocate static arrays and set them to a pointer in my struct. Not too big of deal really. uint[12] Buffer; R_R_Buffer RRB=R_R_Buffer(Buffer); uint[24] OtherBuffer; R_R_Buffer RRB2 = R_R_Buffer(OtherBuffer); I feel though i might end up having OtherOtherOtherBuffers, and it pollutes my local symbols. I just dont like it. Is there a way to not give the buffer a name and do lika dis: R_R_Buffer RRB=R_R_Buffer(uint[12]); R_R_Buffer RRB2 = R_R_Buffer(uint[24]); This obviously fails to compile, but i think you get the idea. Mostly, I don't care what the static array name is.
Re: Working on a library: request for code review
On Thursday, 12 June 2014 at 00:20:28 UTC, cal wrote: Might it be worth stitching things together into a proper image processing package? Well I started working on TGA because I was disappointed that no image abstraction is present in Phobos. Go has some imaging APIs and I think D would benefit from having one too (out of the box). Would I work on std.image? Sure. Best, Mike
Re: Cannot understand deprecation message recently added to Phobos
On Wed, 11 Jun 2014 17:06:41 -0400, Kapps wrote: On Wednesday, 11 June 2014 at 20:59:25 UTC, Nordlöw wrote: Can somebody explain the meaning of split in the error message Deprecation: function core.time.Duration.weeks is deprecated - Please use split instead. weeks was too frequently confused for total!"weeks". given by function shortDurationString() at https://github.com/nordlow/justd/blob/master/pprint.d https://github.com/D-Programming-Language/druntime/pull/825 Now fixed, is the message clearer for you? https://github.com/D-Programming-Language/druntime/pull/837 -Steve
Re: Version() for unittest OR debug?
On Wednesday, 11 June 2014 at 06:50:08 UTC, Kagamin wrote:
debug version = DebugOrUnittest;
else version(unittest)version = DebugOrUnittest;
version(DebugOrUnittest) { static
assert(false,"DebugOrUnittest"); }
I like this option more. I didn't knew you could assign to
"version".
Thanks,
Juanjo
Re: HeadUnshared in core.atomic
On 6/12/14, 1:29 AM, Mike Franklin wrote:
Hello,
I was recently exposed to this template in core.atomic:
private
{
template HeadUnshared(T)
{
static if( is( T U : shared(U*) ) )
alias shared(U)* HeadUnshared;
else
alias T HeadUnshared;
}
}
Could someone please explain/elaborate on what this is doing, and why
it's necessary and used so often in core.atomic?
Thanks,
Mike
Hello Mike,
As to why it's necessary, I cannot really say. My only guess is that it
will be used at a site that requires a pointer to shared data. Anyway,
it simply observes the template parameter at compile time by creating a
local variable U (or is U type?) and checking to see if it is a shared
pointer. If it is, then it produces a pointer to the shared data:
shared(U)* HeadUnshared;
Note: in this re-designation, the pointer is not shared, just the data
to which it points.
Otherwise, it simply passes on the type:
alias T HeadUnshared;
For example if you instantiate with uint:
HeadUnshared!uint p1;
Then p1 is now a variable of type uint. The type is just forwarded. This
would be the exact thing as:
uint p1;
However, if you use a shared pointer:
HeadUnshared!(shared(uint*)) p2;
The p2 is now a pointer to shared(uint).
Also note that if you just pass a shared(type), you will get the same
shared(type) in return.
Hope that helps... someone more knowledgeable may be able to explain better.
Re: Basics of calling C from D
On 6/12/2014 12:17 AM, Colin wrote: So a find an replace will do that for you quite easily. Other things like structs and typedefs are a bit more difficult to do with a find & replace. All the info you need is here anyway: wiki.dlang.org/Bind_D_to_C And here: http://dlang.org/interfaceToC.html And: http://www.gamedev.net/page/resources/_/technical/game-programming/binding-d-to-c-r3122
