Re: good reasons not to use D?
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: Any other thoughts? Floating point operations can be extended automatically (without some kind of 'fastmath' flag) up to 80bit fp on 32 bit intel processors. This is worst solution for language that want to be used in accounting or math. Thoughts like "larger precision entails more accurate answer" are naive and wrong. --Ilya
Re: good reasons not to use D?
On Sat, 2015-10-31 at 20:55 +, David Nadlinger via Digitalmars-d- learn wrote: > On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote: > > My opinion is that a decimal data type must be builtin in any > > modern language, not implemented as a library. > > "must be builtin in any modern language" – which modern languages > actually have decimals as a built-in type, and what is your > rationale against having them as a solid library implementation? > It seems like it would only be interesting for a very fringe > sector of users (finance, and only the part of it that actually > deals with accounting). > > — David It is really a question of symmetry: if there are hardware implementations of both binary and denary floating point, then if a language has binary floating point in the language, then it should have denary floating point in the language. To support one hardware type in the language but relegate another hardware type to the library is inappropriate discrimination. If I remember correctly (I am on a very poor Internet connection just now and can't do the necessary research), IBM z-series has two different denary hardware types, and there is currently a question as to which of these to draw into the IEEE standard as the preferred type. I think Intel are muttering about which one to support. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Allocation strategies question
On Friday, 30 October 2015 at 05:21:17 UTC, Rikki Cattermole
wrote:
What I normally do for memory to be owned by the thread is:
auto foo(IAllocator alloc=theAllocator()) {...}
Where as for if it is global to the process:
auto foo(IAllocator alloc=processAllocator()) {...}
Basically it is the difference between a screenshot of a
display and a window instance.
What do other think?
Re: good reasons not to use D?
On Saturday, 31 October 2015 at 23:16:04 UTC, Ali Çehreli wrote: Although still years away from production, the Mill CPU will have decimal floating point: http://millcomputing.com/wiki/Instruction_Set Mill is a fun project, and there are also base 10 floating point FPGA coprocessors available, but probably not widely deployed. I've personally settled for storing in cents instead, as integers have accurate precision (storing "30.0" instead of "0.3"). The problem is then reduced to writing a wrapper for floats with a dedicated string_to_float conversion that is loss free.
Lazy std.algorithm.replace()
Is there a reason why Phobos doesn't contain a lazy range variant of std.string.replace?
Can't get winapi working
Hi. I was trying all day to get this working, but i give up and
post it here.
module tryingwinapi;
import core.runtime;
import std.utf;
auto toUTF16z(S)(S s)
{
return toUTFz!(const(wchar)*)(s);
}
import win32.windef;
import win32.winuser;
extern (Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int iCmdShow)
{
int result;
void exceptionHandler(Throwable e) { throw e; }
try
{
Runtime.initialize();
result = myWinMain(hInstance, hPrevInstance, lpCmdLine,
iCmdShow);
Runtime.terminate();
}
catch (Throwable o)
{
MessageBox(null, o.toString().toUTF16z, "Error", MB_OK |
MB_ICONEXCLAMATION);
result = 0;
}
return result;
}
int myWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int iCmdShow)
{
MessageBox(NULL, "Hello, Windows!", "Your Application", 0);
return 0;
}
I have found that code here
https://github.com/AndrejMitrovic/DWinProgramming/blob/master/Samples/Chap01/HelloMsg/HelloMsg.d
I have copied the win32 directory from his github.
Thats how my directory looks:
ls
win32 winapi.d
Getting this error:
dmd winapi.d
win32/winnt.d(2130): Error: undefined identifier 'CONTEXT', did
you mean alias 'PCONTEXT'?
win32/winnt.d(2130): Error: undefined identifier 'CONTEXT', did
you mean alias 'PCONTEXT'?
win32/winbase.d(2004): Error: undefined identifier 'CONTEXT', did
you mean alias 'PCONTEXT'?
I was trying another code what i found on the web:
module tryingwinapi;
import core.runtime;
import core.sys.windows.windows;
extern(Windows) int WinMain( HINSTANCE hInstance, HINSTANCE
hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
{
MessageBox( NULL, "text", "title", MB_OKCANCEL);
return 0;
}
This returns me:
dmd winapi.d
winapi.d(6): Error: undefined identifier 'HINSTANCE'
winapi.d(6): Error: undefined identifier 'HINSTANCE'
winapi.d(6): Error: undefined identifier 'LPSTR'
What is the correct code to show the MessageBox in windows?
Re: Capturing __FILE__ and __LINE in a variadic templated function
On 01.11.2015 23:49, Adam D. Ruppe wrote:
Yeah, just make the other args normal runtime instead of template:
Or make it two nested templates:
template show(T ...)
{
void show(string file = __FILE__, uint line = __LINE__,
string fun = __FUNCTION__)()
{
...
}
}
Access violation when calling C DLL from D
Hi, I am trying to write a simple interface to the MRuby Ruby
interpreter so I can use ruby scripts in my D program. I was able
to get MRuby compiled as a DLL without too much difficulty, but
the headers are very long and complicated, and porting them
entirely to D would be a huge project in and of itself. I am
trying to get by with only what I need, so here is what I have so
far:
module script.mruby;
alias mrb_bool = bool;
alias mrb_int = int;
alias mrb_float = double;
alias mrb_sym = uint;
alias mrb_aspec = uint;
struct mrb_value
{
}
struct RObject
{
}
struct RClass
{
}
struct mrb_value
{
}
struct mrb_state
{
}
extern(C) char *mrb_string_value_cstr(mrb_state *mrb, mrb_value
*ptr);
extern (C) mrb_value mrb_load_string(mrb_state *mrb, const char
*s);
extern (C) mrb_value mrb_load_nstring(mrb_state *mrb, const char
*s, int len);
extern (C) mrb_state *mrb_open();
extern (C) void mrb_close(mrb_state *mrb);
In theory, this should be enough to test that MRuby is working,
so I tried to run the following code:
mrb = mrb_open();
mrb_value result = mrb_load_string(mrb,
toStringz("String('test')"));
Log.info(to!string(mrb_string_value_cstr(mrb, )));
But the result was:
object.Error@(0): Access Violation
I wasn't able to get the Visual D debugger to trace into the
code, but after some investigation, I figured out that the error
was occurring in the strlen runtime function. I don't think I did
anything wrong with the way I passed a string into the
mrb_load_string function, so I am kind of at a loss as to what
the problem might be.
Re: Access violation when calling C DLL from D
On Monday, 2 November 2015 at 02:13:29 UTC, BBasile wrote: On Monday, 2 November 2015 at 01:02:45 UTC, AnoHito wrote: [...] the headers are very long and complicated, and porting them entirely to D would be a huge project in and of itself. [...] You can give a try at h2d, the C header to D interface converter: http://dlang.org/htod.html I did, but it just produced a ton of errors...
Re: Access violation when calling C DLL from D
On Monday, 2 November 2015 at 01:02:45 UTC, AnoHito wrote: [...] the headers are very long and complicated, and porting them entirely to D would be a huge project in and of itself. [...] You can give a try at h2d, the C header to D interface converter: http://dlang.org/htod.html
Re: Can't get winapi working
On Sunday, 1 November 2015 at 17:52:08 UTC, dozksaw wrote: I have copied the win32 directory from his github. Try the official repository: https://github.com/smjgordon/bindings/tree/master/win32 These headers will also be available as core.sys.windows.* starting with D 2.070.
Re: good reasons not to use D?
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: I'm writing a talk for codemesh on the use of D in finance. I want to start by addressing the good reasons not to use D. (We all know what the bad ones are). I don't want to get into a discussion here on them, but just wanted to make sure I cover them so I represent the state of affairs correctly. So far what comes to mind: heavy GUI stuff (so far user interface code is not what it could be); cases where you want to write quick one-off scripts that need to use a bunch of different libraries not yet available in D and where it doesn't make sense to wrap or port them; where you have a lot of code in another language (especially non C, non Python) and defining an interface is not so easy; where you have many inexperienced programmers and they need to be productive very quickly. Any other thoughts? I would advise against using D in applications where memory is essential. Idiomatic D uses a garbage collector which has a non free runtime cost.
Capturing __FILE__ and __LINE in a variadic templated function
Is it possible to make the following definition
void show(alias T, string file = __FILE__, uint line = __LINE__,
string fun = __FUNCTION__)()
{
import std.stdio: writeln;
try { debug writeln(file, ":",line, ":" /* , ": in ",fun */,
" debug: ", T.stringof, ":", T); }
catch (Exception) { }
}
used as
unittest
{
int x = 11;
int y = 12;
int z = 13;
show!x;
show!y;
show!z;
}
variadic so that it, instead, can be called as
unittest
{
int x = 11;
int y = 12;
int z = 13;
show!(x,y,z);
}
and still capture current file, line and function?
Re: Capturing __FILE__ and __LINE in a variadic templated function
Yeah, just make the other args normal runtime instead of template:
void show(T...)(string file = __FILE__, uint line = __LINE__,
string fun = __FUNCTION__) {
// same body
}
// same usage
Re: Allocation strategies question
On Sunday, 1 November 2015 at 09:48:20 UTC, ref2401 wrote:
On Friday, 30 October 2015 at 05:21:17 UTC, Rikki Cattermole
wrote:
What I normally do for memory to be owned by the thread is:
auto foo(IAllocator alloc=theAllocator()) {...}
Where as for if it is global to the process:
auto foo(IAllocator alloc=processAllocator()) {...}
Basically it is the difference between a screenshot of a
display and a window instance.
What do other think?
Create a "repository" of allocators. The "programmers" query the
allocators for their "best fit", but because it is a repository,
they are easier to deal with than hard coding.
E.g.,
auto allocator =
GetAllocator(allocatorsRepository.processAllocator);
GetAllocator would get the actual allocator using the arg as a
"hint".
One could, hypothetically, make this as complex as one would
want. e.g., passing the file name as an argument(hidden) which
can then be used as a constraint on the allocator allocation(pun
;). e.g., you can have file specific optimization techniques by
altering the allocation strategy per file(or better yet, per
line).
Since all that can be done retroactively, it alleviates some of
the problems with the programmers interfacing directly with
std.experimental.allocator. They have to go through your
interface first which gives you some control.
You could then print special debug messages sort of like -vgc but
instead, for allocation strategies. The sky's the limit! Have fun
with it!
