Re: repl like interface with D app
On Friday, 16 June 2017 at 18:13:33 UTC, Seb wrote:
On Friday, 16 June 2017 at 07:57:46 UTC, Mike B Johnson wrote:
I am developing a D app and I have a need to test things out.
I do not want to have to recompile the app every time I want
to test some functionality out.
[...]
There is drepl, it's not fancy, but works for basic use cases...
https://github.com/drepl/drepl
But that doesn't interface with ones own program? I'm not talking
about a standalone repl but something what can use from their own
program and then use that command line interface of it(or just
send command through text) and interact with the original program:
string foo() { writeln("foo"); }
void main()
{
repl.init();
writeln(repl.exec("foo()"));
writeln(repl.exec(readline()));
repl.OpenInterface(); // <- A new command window is open that
lets us run code from it, code that has access to this programs
code.
}
Or whatever.
Re: repl like interface with D app
On Friday, 16 June 2017 at 18:43:24 UTC, Sameer Pradhan wrote: On Friday, 16 June 2017 at 07:57:46 UTC, Mike B Johnson wrote: [...] Please check out: https://github.com/DlangScience/PydMagic/blob/master/README.md I haven't used it myself, but fits right in the Jupyter/IPython ecosystem. -- Sameer Thanks, not sure if this will work and I don't like python much, but I'll give a look at some point and see. Maybe it can be integrated back in to a D program and then work out well: D->python->D.
repl like interface with D app
I am developing a D app and I have a need to test things out. I do not want to have to recompile the app every time I want to test some functionality out. Suppose I have an app with some functions like foo, bar, etc... in some module m. I would like to be able to do basic stuff like writeln(m.foo()); or auto x = m.bar() + 3; etc... This way I can write the functions, compile, then test them out without compiling. e.g., m.FlipLightSwitch(34); which turns on the 34th light in the house, then m.FlipLightSwitch(34); which turns it off. This should take about 1-2 seconds to test RATHER than about 1m to do the compilation, running, etc. Having a history buffer would be nice too and even a debugger showing the basic state(nothing fancy). Anything like this out there. Lua has things like this that are very nice to do because they allow for quick testing and prototyping.
Re: Implementing interfaces using alias this
On Wednesday, 14 June 2017 at 09:41:49 UTC, ketmar wrote:
Balagopal Komarath wrote:
Why doesn't this work? The Test!Duck type has a void quack()
method but the compiler says it is not implemented.
'cause `alias this` is *not* a tool that can be used to emulate
inheritance. no, `quack` is NOT impemented. `alias this` won't
automagically paste the code.
I don't think it has to do with pasting code.
d.Quack() is well defined through the alias. Inheritance requires
that a Quack() exists, and it does, through the alias.
The compiler could easily create an implementation wrapper that
uses the alias this.
I believe it is simply because the logic is not implement in the
compiler, not because there is some logic issue in it.
import std.stdio;
interface IDuck
{
void quack();
}
class Test(T) : IDuck
{
T data;
alias data this;
void quack() { data.quack(); }
}
struct Duck
{
void quack()
{
writeln("Quack");
}
}
void main()
{
Test!Duck d;
d.quack();
}
which, unfortunately causes a segmentation fault ;)(from dpaste)
(even if you remove IDuck) https://dpaste.dzfl.pl/69ddb3f2b1e9
The main issue is that the compiler would have to parse the alias
and see if it has members that are to be used, not hard... but
this is probably not standard behavior and might lead to other
problems down the road(specially with multiple alias this).
Basically, which quack to call? I think it's better to require it
to be explicit(as I have tried to do).
Re: .sort vs sort(): std.algorithm not up to the task?
On Thursday, 8 June 2017 at 01:57:47 UTC, Andrew Edwards wrote: If I hand you a chihuahua for grooming, why am I getting back a pit bull? I simply want a groomed chihuahua. Why do I need to consult a wizard to get back a groomed chihuahua? Because is like a poodle and unless you get your hair cut in a special way you won't be considered for the job! The wizard only exists to balance the symmetric arrangement of the interplanetary forces, don't fear him, he does his job in a very predictable way.
Re: Make enum auto castable
On Monday, 5 June 2017 at 03:15:46 UTC, Jonathan M Davis wrote: On Monday, June 05, 2017 02:14:14 Mike B Johnson via Digitalmars-d-learn wrote: On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote: > On Monday, June 05, 2017 01:30:47 Mike B Johnson via > > Digitalmars-d-learn wrote: >> [...] > > It's not a bug. The alias this conversion only goes one way. > It provides a way to convert _from_ the type that it's > declared on to another type, not from the other type to the > type that it's declared on. There is no way in D to declare > an implicit conversion in the direction you're trying. So, > if you have a struct that wraps an int like this, and you > want to assign it an int, you're going to need to explicitly > construct the struct - e.g. EnumX(1). > > - Jonathan M Davis That's pretty crappy! Defeats the whole point! Well, implicit conversions tend to cause a lot of bugs in C++ code, so Walter decided to restrict them quite a bit more in D than they are in C++. This therefore prevents a number of bugs in D, but it also prevents implicit conversions from being used in a number of situations where they're useful. Whether the end result is better or worse, I don't know and certainly YMMV. As it is, some of the implicit conversions that we still allow have a tendency to cause bugs (e.g. conversions between integral values and character types tend to be error-prone - especially when arrays are involved - and using implicit conversions with templated code is almost always a bad idea). So, at times, I tend to think that all implicit conversions should be banned. But at other times, it would be really nice to be able to have more than we do (e.g. it would be a lot more user-friendly if you could pass a T to a function that takes a Nullable!T). In any case, I think that the reality of the matter with D is that you tend to have to use explicit conversions rather than implicit ones, and if you're looking to do much with implicit conversions, you're usually going to be frustrated, and obviously, that sucks, but at least you're less likely to have bugs related to implicit conversions. - Jonathan M Davis The problem is bugs are only a possibility. If you remove a feature from a language the feature does not exist, period. So, throwing the baby out with the bath water because he pooped in it is not a solution. Instead, if there is a problem with implicit autonomous conversion or construction, then the solution is not to remove all implicit conversions or constructions but to remove the autonomous part. e.g., make the user specify the implicit conversion explicitly. This way, if bugs do creep in, it is due to the user. It is much easier to diagnose and fix then.
Re: Make enum auto castable
On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote: On Monday, June 05, 2017 01:30:47 Mike B Johnson via Digitalmars-d-learn wrote: [...] It's not a bug. The alias this conversion only goes one way. It provides a way to convert _from_ the type that it's declared on to another type, not from the other type to the type that it's declared on. There is no way in D to declare an implicit conversion in the direction you're trying. So, if you have a struct that wraps an int like this, and you want to assign it an int, you're going to need to explicitly construct the struct - e.g. EnumX(1). - Jonathan M Davis That's pretty crappy! Defeats the whole point!
Re: Make enum auto castable
On Monday, 5 June 2017 at 00:51:15 UTC, Jonathan M Davis wrote:
On Monday, June 05, 2017 00:16:15 Mike B Johnson via
Digitalmars-d-learn wrote:
On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote:
> [...]
I might be able to change the enum, I assume you mean
something like
enum myenum : S { }
where S is the struct that implicitly converts?
Yes.
However, be aware that you can currently only define one alias
this per type. So, the rest of the code will then need to be
able to deal with the fact that the enum is a struct that
implicitly converts to VARIANT and does not implicitly convert
to int. So, if you're just passing the enums around and
comparing them, you're fine, but if you need to treat them as
ints somewhere, then you'll need to provide an explicit
conversion (via overloading opCast or by creating a specific
function for it or just exposing a member with the int value or
whatever), and that could get annoying in the same way that
you're annoyed about the VARIANT issue right now.
But if you don't actually need to treat the enum as an int, and
you can make it a struct that implicitly converts to VARIANT
instead, then that will fix your VARIANT conversion problem.
- Jonathan M Davis
enum X : EnumX
{
a = 1,
}
struct EnumX
{
int x;
alias x this;
void opAssign(int y)
{
x = y;
}
double opCall()
{
return x;
}
}
doesn't work because "1" is not castable to EnumX, even though
EnumX is aliased to an int, and hence it should work fine.
Seems like a bug to me.
Re: Implicit casting of int enum members to int
On Monday, 3 October 2016 at 09:21:37 UTC, Jonathan M Davis wrote:
[...]
Is this bug ever going to be fixed?
I can't do
enum X : Y
{
a = 1
}
because 1 is not implicitly convertible to Y, even though Y is
aliased to an int so it should be.
Re: dmd casts but ldc doesn't, and doesn't work in template in dmdm
On Monday, 5 June 2017 at 00:56:52 UTC, Jonathan M Davis wrote: On Monday, June 05, 2017 00:18:04 Mike B Johnson via Digitalmars-d-learn wrote: [...] I assume that guid is a string or array of byte or somesuch? If it's an array of byte or char, then you can probably do auto bytes = cast(byte[16])guid[0 .. 16]; I doubt that it will work with CTFE though, because this is basically a reinterpret cast, and CTFE gets picky about casts like that. If you need to do something like that in CTFE, you'll probably need to use if(__ctfe) to add a branch that does this it in a for loop or something without any casts. Also, you probably want ubyte, not byte. byte is signed, so it really only makes sense to use it as an integral value that holds [-128, 128] rather than for an actual byte value. - Jonathan M Davis Guid is a struct and I am trying to get the "bytes" of the struct" to get the guid bytes. It is quicker than accessing all the elements one at a time.
Re: Make enum auto castable
On Monday, 5 June 2017 at 00:51:15 UTC, Jonathan M Davis wrote:
On Monday, June 05, 2017 00:16:15 Mike B Johnson via
Digitalmars-d-learn wrote:
On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote:
> On Sunday, June 04, 2017 22:52:55 Mike B Johnson via
>
> Digitalmars-d-learn wrote:
>> [...]
>
> Aside from whatever implicit conversions are built into the
> language, the only way to define an implicit conversion in D
> is via alias this on a user-defined type, which then tells
> that type that it can convert to whatever type the result of
> the alias this is. e.g. if you have
>
> [...]
I might be able to change the enum, I assume you mean
something like
enum myenum : S { }
where S is the struct that implicitly converts?
Yes.
However, be aware that you can currently only define one alias
this per type. So, the rest of the code will then need to be
able to deal with the fact that the enum is a struct that
implicitly converts to VARIANT and does not implicitly convert
to int. So, if you're just passing the enums around and
comparing them, you're fine, but if you need to treat them as
ints somewhere, then you'll need to provide an explicit
conversion (via overloading opCast or by creating a specific
function for it or just exposing a member with the int value or
whatever), and that could get annoying in the same way that
you're annoyed about the VARIANT issue right now.
But if you don't actually need to treat the enum as an int, and
you can make it a struct that implicitly converts to VARIANT
instead, then that will fix your VARIANT conversion problem.
- Jonathan M Davis
Well, I do need to to treat it as an int at times and opCast only
works with cast. While I could set it up to do a cast(VARIANT),
which is better than nothing, I'd get same result as to!VARIANT,
which is shorter and effectively the same.
When will we get multiple alias this? all I need is two?
Hell, why not make alias this an "overloadable" function similar
to opCast and such?
dmd casts but ldc doesn't, and doesn't work in template in dmdm
The following line is causing some problems. auto bytes = cast(byte[16])guid; compiles fine in dmd but ldc says it can't convert... also, it doens't work in ctfe/template either. (I'm not sure if ctfe is kicking in or not though, but definitely doesn't work in a template)
Re: Make enum auto castable
On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote:
On Sunday, June 04, 2017 22:52:55 Mike B Johnson via
Digitalmars-d-learn wrote:
[...]
Aside from whatever implicit conversions are built into the
language, the only way to define an implicit conversion in D is
via alias this on a user-defined type, which then tells that
type that it can convert to whatever type the result of the
alias this is. e.g. if you have
[...]
I might be able to change the enum, I assume you mean something
like
enum myenum : S { }
where S is the struct that implicitly converts?
Make enum auto castable
I am dealing with some COM stuff and some functions use VARIANT, which can hold an enum. Instead of having to manually convert the enum(and for that matter, other things) to VARIANT, is it possible to have them automatically converted? This is because an enum is always convertible to a VARIANT but not the other way around. So, when a enum is passed to a function accepting a VARIANT, it should just work. Overloading is not an option.
Re: string to wchar*?
On Saturday, 3 June 2017 at 23:09:56 UTC, Stanislav Blinov wrote: On Saturday, 3 June 2017 at 22:54:22 UTC, Mike B Johnson wrote: How to convert a string to wchar*? C-style null-terminated wchar*? https://dlang.org/phobos/std_utf.html#toUTF16z This didn't work. More errors than the first. In any case, it conv should work.
string to wchar*?
How to convert a string to wchar*? string s; to!(wchar*)(s) gives phobo's deduction problems. \dmd2\windows\bin\..\..\src\phobos\std\conv.d(194): Error: template std.conv.toImpl cannot deduce function from argument types !(wchar*)(string), candidates are: \dmd2\windows\bin\..\..\src\phobos\std\conv.d(435): std.conv.toImpl(T, S)(S value) if (isImplicitlyConvertible!(S, T) && !isEnumStrToStr!(S, T) && !isNullToStr!(S, T)) \dmd2\windows\bin\..\..\src\phobos\std\conv.d(549): std.conv.toImpl(T, S)(ref S s) if (isStaticArray!S) \dmd2\windows\bin\..\..\src\phobos\std\conv.d(565): std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, T) && is(typeof(S.init.opCast!T()) : T) && !isExactSomeString!T && !is(typeof(T(value \dmd2\windows\bin\..\..\src\phobos\std\conv.d(616): std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, T) && is(T == struct) && is(typeof(T(value \dmd2\windows\bin\..\..\src\phobos\std\conv.d(665): std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, T) && is(T == class) && is(typeof(new T(value
Re: D scripting in D
On Saturday, 3 June 2017 at 00:02:54 UTC, Lewis wrote: On Friday, 2 June 2017 at 20:47:31 UTC, Mike B Johnson wrote: [...] For sure. I actually want to post the source code at some point, but the changes I made are very much set up specifically for this project. I'll sift through at some point and see if I can gather together something worth posting. [...] Thanks. Maybe some of this could be overcome by a design pattern that removes them from being an issue(e.g., script can not use GC... only to demonstrate that if that were the case, then you wouldn't have to worry about GC issues ;)? I imagine that if "dll"'s were used that one would have all the power to debug and develop them as normal d code, which is nice and doesn't require a "script editor and debugger".
Re: Creating and loading D plugins in D app
On Friday, 2 June 2017 at 12:19:48 UTC, Adam D. Ruppe wrote: On Friday, 2 June 2017 at 11:09:05 UTC, aberba wrote: 1. Get shared libs to work in D (the best approach for all D code) I have done very little with this myself but other people have so it is doable. 1. some kind of embeddable interpreter for a scripting language like (a mini js engine) which exposes callable native D APIs at runtime My script.d does this kind of thing http://dpldocs.info/experimental-docs/arsd.script.html#examples it is slow though. You should put a link on the help somewhere so one can get to the github page easily to view the source(or have the ability to go from the module to the github source easily(small icon next to module name in modules list). This would help peruse the source to see how you came up with some of your stuff ;)
Re: D scripting in D
On Friday, 2 June 2017 at 15:55:53 UTC, Lewis wrote: On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote: I wonder if it is possible to somehow turn D in to a scripting language that can be run inside D? On a game project I'm working on at home, I've done: - Hot reloading via a DLL - A build script that runs in the background, detects file changes, and automatically rebuilds - A code structure that keeps build times to a minimum (currently 1.8s) All these combined, and D feels pretty script-like. The setup is far from ideal, since it imposes some limitations on the language (only limited use of classes/finalizers, be careful with static data, some changes to the program state struct require a restart, etc). It also took a significant amount of work to get it up and running, requiring several changes to druntime. But writing an entire feature with the game still running, followed by testing and iterating, all without closing the game, is pretty great. Way nicer than at work, where I have 1-15 minute rebuilds, with a restart for every change. Would you mind, when you get some time, to write up a more detailed analysis of the problems you had to overcome to get it to work? Possibly we could get some type of library solution that just "works" with very little change and restriction? After all, dll's effectively already solve the problem, in some sense... except they are generally not meant to be reloaded on demand. Solving the issues that reloading causes, I think, would be the bulk of the problem?
Re: D scripting in D
On Friday, 2 June 2017 at 03:33:37 UTC, Adam D. Ruppe wrote: On Friday, 2 June 2017 at 02:32:43 UTC, Mike B Johnson wrote: But it would be nice if a D had a scripting language that used the same D syntax as this would make porting a piece of cake. So my script.d has kinda similar syntax, but fairly different semantics than good D code (though my jsvar.d provides a type to D that is very similar to the type in the script)... Which means copy/paste might even compile, but it would be liable to work differently. I'm looking for something like this in D because D's features are much better. having meta capabilities in scripting would be cool. Mine also doesn't do the meta stuff... yet. I could prolly add it easily enough but I never got around to it. But I really think you can find a lot of use just using D itself. Make your application into some kind of library you can link to and you can be testing stuff in like a second from the time you write it. I think that is more prone to errors and much harder to implement and maintain(assuming we had such a Dscript already). If one could integrate it easily and well then possibly that could be Dscript... 1. Have ldc/dmd compile the "script"(D source) that exports, automatically, an entry point(main?). (easy) 2. Somehow allow different scripts to communicate(a real script doesn't have a problem with this, but a D app would need to "register" itself somehow). This could be easy or hard. 3. Link everything together(dll like stuff). 4. Passing of the hosting D app's context. this could be pretty hard to get right? 5. Allow for plug and play of the "dll's" generated... this could be tricky too. Remember, we have to minimize all the junk code that won't be used in the D "equivalent" of the script. If one has to access all variables through some marshaling process and it slows down the code then we loose the ability to optimize by compiling to native code... which defeats the whole purpose. Thoughts? anyway i g2g will talk more later Ok, buddy! Thanks!
Re: D scripting in D
On Friday, 2 June 2017 at 02:39:47 UTC, Stefan Koch wrote: On Friday, 2 June 2017 at 02:32:43 UTC, Mike B Johnson wrote: 1. change test12.wav to test123.wav 2. save file 3. recompile. 4. run 5. Get back to same test point(could be a lot or a little amount of work). If that is all you want; then compile your code into a dll/so and load the new version. The D compiler is fast enough that it will not break your flow. program-state management would be taken by the static part of your program. I thought about that but the state management would not be trivial and would prevent recompilation in most cases(because the state would not exist in the same format in recompiled version). While it is possible, it doesn't seem like the way to go(and not only that, one doesn't get all the benefits a scripting language has(sandboxing, jit, etc). We can come up with alternatives all day long but it will never fulfill the role...
Re: D scripting in D
On Friday, 2 June 2017 at 02:15:27 UTC, Adam D. Ruppe wrote:
On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:
I wonder if it is possible to somehow turn D in to a scripting
language that can be run inside D?
Why not just use regular compiled D?
Because it requires one to recompile and relink the code for
every change(and to possibly restart the app and redo all the
work to get to some point to start testing the code). In a
scripting engine one can simply call a function and execute
commands immediately in an interactive way. This allows for much
faster testing.
e.g., with a hypothetical app that has an interactive Dscript,
one could do
App.PlaySound("test123.wav");
instead of
1. change test12.wav to test123.wav
2. save file
3. recompile.
4. run
5. Get back to same test point(could be a lot or a little amount
of work).
Regardless, that is not the point though. If that was the only
reason, lua or some other scripting language would suffice.
The problem is that the grammars of all those languages do not
translate directly in to D. Anglescript is a C++ like script that
has a near 1-1 correspondence so "porting" code from it to C++ is
easy.
But it would be nice if a D had a scripting language that used
the same D syntax as this would make porting a piece of cake.
The point is, why should I develop, say, 100's of algorithms in
the scripting language that can never easily be ported to native
and be fast as possible simply because the of the amount of work
to rewrite the code when, semantically, nothing changes?
Wouldn't it be much better to be able to confidently write the
code in a scripting environment that allows for nearly instance
response knowing that it can simply be recompiled to native
without issue when the time comes for performance optimizations?
Anglescript effectively does this. Note only does it have a C++
like syntax, it has the ability to compile to native directly
with an addon.
I'm looking for something like this in D because D's features are
much better. having meta capabilities in scripting would be cool.
D scripting in D
I wonder if it is possible to somehow turn D in to a scripting language that can be run inside D? The point? To have the same uniform syntax for quickly developing scripts that can then be easily transferred, if desired, in to a complete binary. e.g., suppose I am working in some type of analysis software. Use a Dscript like feature to develop and test different analysis algorithms quickly(rather than using the compile and execute model)... then once everything is working, move the code to a D file and compile it directly. Since the syntax would be identical(or nearly so) it would be quite easy to copy and paste... unlike, say, using lua or some other non-D like scripting language.
Re: Rosetta Commatizing numbers
If you still insist you are doing the right thing and all others are wrong, let's agree to disagree on that, and please just leave the original solution there by introducing two versions. Or we could just agree that the original was wrong and needs fixing? That is obviously the right thing to do, so why not agree that it should be done? At the very least...
Re: Out of memory error (even when using destroy())
On Friday, 26 May 2017 at 18:19:48 UTC, H. S. Teoh wrote: On Fri, May 26, 2017 at 06:06:42PM +, Mike B Johnson via Digitalmars-d-learn wrote: On Friday, 26 May 2017 at 14:05:34 UTC, ag0aep6g wrote: > On 05/26/2017 10:15 AM, realhet wrote: > > But hey, the GC knows that is should not search for any > > pointers in those large blocks. And the buffer is full of > > 0-s at the start, so there can't be any 'false pointers' > > in it. And I think the GC will not search in it either. > > The issue is not that the block contains a false pointer, > but that there's a false pointer elsewhere that points into > the block. The bigger the block, the more likely it is that > something (e.g. an int on the stack) is mistaken for a > pointer into it. Wow, if that is the case then the GC has some real issues. The GC should be informed about all pointers and an int is not a pointer. Unfortunately, it can't, because (1) D interfaces with C code, and you don't have this kind of information from a C object file, and (2) you can turn a pointer into an int with a cast or a union in @system code, and since the GC cannot assume @safe for all code, it needs to be conservative and assume any int-like data could potentially be a pointer. You could improve GC performance by giving it type info from @safe code so that it skips over blocks that *definitely* have no pointers (it already does this to some extent, e.g., data in an int[] will never be scanned for pointers because the GC knows it can't contain any). But you can't make the GC fully non-conservative because it may crash the program when it wrongly assumes a memory block is dead when it's actually still live. All it takes is one pointer on the stack that's wrongly assumed to be just int, and you're screwed. And what if one isn't interfacing to C? All pointers should be known. You can't access memory by and int or any other non-pointer type! Hence, when pointers are created or ints are cast to pointers, the GC should be informed and then handle them appropriately(then, instead of scanning a 100MB block of memory for "pointers" it should scan the list of possible pointers(which will generally be much much lower). Therefor, in a true D program(no outsourcing) with no pointers used, the GC should never have to scan anything. It seems the GC can be smarter than it is instead of just making blanket assumptions about the entire program(which rarely hold), which is generally always a poor choice when it comes to performance... In fact, When interfacing with C or other programs, memory could be partitioned and any memory that may escape D is treated differently than the memory used only by D code. After all, if we truly want to be safe, why not scan the entire memory of the system? Who knows, some pointer externally might be peeping in on our hello world program.
Re: binding to C++
On Friday, 26 May 2017 at 15:17:08 UTC, drug wrote: Trying to bind to cpp code I stop at some moment having undefined reference to some cpp function. But objdump -Ct cpplibrary.so shows me that this cpp function exists in the library. linker message about cpp function is _identical_ to objdump message so I don't know where is the difference. For example linker says: `undefined reference to `Namespace::StructName::method_name(Namespace::Otherstruct const*)` And ojbdump called by command: ``` objdump -Ct libLibrary.so | method_name ``` shows the following: ``` 00026ed0 wF .text 0025 Namespace::StructName::method_name(Namespace::Otherstruct const*) ``` That is two outputs are identical. Could someone help what to do to investigate the problem? Thanks in advance Hi, Welcome to D! Hi, Welcome to D!
Re: Out of memory error (even when using destroy())
On Friday, 26 May 2017 at 14:05:34 UTC, ag0aep6g wrote: On 05/26/2017 10:15 AM, realhet wrote: But hey, the GC knows that is should not search for any pointers in those large blocks. And the buffer is full of 0-s at the start, so there can't be any 'false pointers' in it. And I think the GC will not search in it either. The issue is not that the block contains a false pointer, but that there's a false pointer elsewhere that points into the block. The bigger the block, the more likely it is that something (e.g. an int on the stack) is mistaken for a pointer into it. Wow, if that is the case then the GC has some real issues. The GC should be informed about all pointers and an int is not a pointer.
Current LDC Android status
So what is currently the state of affairs with LDC and android? Last time I remember, it *could* compile to android but barely.
Re: avoid extra variable during void pointer cast
On Sunday, 14 May 2017 at 20:18:24 UTC, Kevin Brogan wrote:
I have a piece of code that takes a callback function.
The callback has the signature void callback(void* state, void*
data)
There are several of these functions. All of them use state and
data as differing types.
As an example, let's look at one that uses both of them as int*.
addInt(void* state, void* data)
{
*cast(int*)state += *cast(int*)data;
}
Is it not possible to specify the cast as an alias so that I
can declare the cast once at the beginning of the function?
Something like this?
addInt(void* state, void* data)
{
alias _state = cast(int*)state; // Error: basic type
expected, not cast
alias _data = cast(int*)data; // Error: basic type
expected, not cast
*_state += *_data;
}
I can always do this:
addInt(void* state, void* data)
{
int* _state = cast(int*)state;
int* _data = cast(int*)data;
*_state += *_data;
}
But I don't want to create a new variable and assign it
everytime I call the function. The examples I'm using are
contrived, but in the c code I am porting this from, the
callback gets called thousands of times a second, every
optimization matters, and the variables are used many times per
function. I don't want to riddle the code with casts if i can
avoid it and I don't want to create and destroy useless proxy
variables every time the function is called.
1. Use template, that is what they are for
addInt(A, B)(A* state, B* data)
{
static if(is(B == int))
{
// B is an int if this block is called so no reason to
cast.
}
}
2. Use overloads, basically same as templates.
addInt(int* state, int* data)
{
}
3. Don't worry about it, any extra temp variables will almost
surely be optimized away.
Re: How to avoid throwing an exceptions for a built-in function?
On Thursday, 11 May 2017 at 16:07:22 UTC, k-five wrote:
On Wednesday, 10 May 2017 at 21:19:21 UTC, Stanislav Blinov
wrote:
On Wednesday, 10 May 2017 at 15:35:24 UTC, k-five wrote:
On Wednesday, 10 May 2017 at 14:27:46 UTC, Stanislav Blinov
---
I don't understand. If you don't want to take care of
exceptions, then you just don't do anything, simply call
to!int(str).
Well I did that, but when the string is a valid type like: "10"
there is no problems. But when the string is not valid, like:
"abc", then to! function throws an exception.
Why I do not want to take care of that? Because I just need the
value, if the string is valid, otherwise no matter what the
value of string is.
First I just wrote:
index = to!int( user_apply[ 4 ] );
And this code is a part of a command-line program and the user
may enter anything. So, for a valid string:
./program '10' // okey
but for:
./program 'non-numerical' // throws an exception an 10 lines of
error appear on the screen( console )
I just want to silent this exception. Of course it is useful
for handling when someone wants to. But in my code I no need to
handle it. So I want to silent that, without using
try{}catch(){} block. I just wondered about try-catch and I
want to know may there would be a better way instead of a dummy
try-catch block.
Thanks for replying and mentioning. And I am sorry, since I an
new in English Writing, if you got confuse.
You are not making a lot of sense:
1. Exception do bubble up, so you don't need to "handle"
exceptions at the call site if you don't want to. The whole point
of exceptions is do effectively do what you want.
2. You say that you don't have to deal with it in your code but
you are trying to deal with it now.
You are not clear on exactly what you are trying to accomplish.
Can you be more specific on why you do not want to add a
try/catch/if-else/ifThrown/etc? Is it because you don't need to
handle it in your own usage? If that is true, will others ever
use it?
Basically all you have to do is ask yourself this:
"Do I need to EVER handle the case where the data is invalid?"
If you do(e.g., other users will use your code) then you better
implement some type of exception handling. Else all you have to
do is always put in the right data(not good because it might bite
you in the ass one day).
If you just want less noise when the program crashes, just put a
try/catch block in main and catch all generic exceptions and exit
with a simple error message like "There was an ERROR, I do not
know why...".
get vtable size
how many elements(virtual functions) are in the __vptr?
How to get field default value at CT
I'd like to get the value assign to a field at CT.
struct
{
int x = 3434;
}
I'd like to get the assigned "value" 3434 for x at CT.
Re: COM Expertise needed: COM Callbacks
I've modified the code and it seems to call GetTypeInfo but the
values passed seem frivolous. The modified code I'm using is
below. Maybe we can get this to work? I'm interested in a
photoshop interop too. Seems like it should be rather trivial to
get to work but things don't add up ;/
module main;
import std.stdio;
import core.sys.windows.winnt;
import Gen;
string Guid2Str(GUID guid)
{
import std.conv, std.string, std.algorithm;
auto bytes = cast(byte[16])guid;
auto a = to!string(*(cast(DWORD*)(bytes[0..4])),
16).rightJustify(8, '0');
auto b = to!string(*(cast(WORD*)(bytes[4..6])),
16).rightJustify(4, '0');
auto c = to!string(*(cast(WORD*)(bytes[6..8])),
16).rightJustify(4, '0');
auto d = to!string(*(cast(BYTE*)(bytes[8..9])),
16).rightJustify(1, '0');
auto e = to!string(*(cast(BYTE*)(bytes[9..10])),
16).rightJustify(1, '0');
auto q = bytes[10..16];
reverse(q);
auto f = to!string(*(cast(long*)(q)) & 0x,
16).rightJustify(12, '0');
auto ret = a~"-"~b~"-"~c~"-"~d~e~"-"~f;
return ret;
}
// Creates a guid from a guid hex string. e.g.,
"B3C35001-B625-48D7-9D3B-C9D66D9CF5F1" -> {0xC09F153E, 0xDFF7,
0x4EFF, [0xA5, 0x70, 0xAF, 0x82, 0xC1, 0xA5, 0xA2, 0xA8]}
GUID GuidN(string str)
{
// 3 2 15E5C5D5C5B5A4L4H
// 4dc0c1dbecc8691b 49af51c5f6655e85
//DEFINE_GUID(IID_INoMarshal,0xecc8691b,0xc1db,0x4dc0,0x85,0x5e,0x65,0xf6,0xc5,0x51,0xaf,0x49);
//MIDL_INTERFACE("ecc8691b-c1db-4dc0-855e-65f6c551af49")
import std.string;
GUID guid;
auto bytes = cast(byte*)(cast(void*));
if (str == "") return IID.init;
auto parts = split(str, "-"); auto p3 = parts[3].rightJustify(4,
'0'); auto p4 = parts[4].rightJustify(12, '0');
*(cast(long*)(bytes[0..8])) = to!long(parts[2].rightJustify(4,
'0')~parts[1].rightJustify(4, '0')~parts[0].rightJustify(8, '0'),
16);
*(cast(long*)(bytes[8..16])) =
to!long(p4[10..$]~p4[8..10]~p4[6..8]~p4[4..6]~p4[2..4]~p4[0..2]~p3[2..$]~p3[0..2], 16);
return guid;
}
int main(string[] argv)
{
// Issue QueryInterface seems to have the issue(not the same
behavior as what is returned by the PS COM Interface)
auto x = new cApplication();
auto x1 = x.Path();
auto x2 = x.Name();
auto x3 = x.SystemInformation();
auto x4 = x.Version();
auto e = x.RecentFiles();
auto g = x.DisplayDialogs();
auto x5 = x.Documents();
auto x6 = x5.Count();
auto dd = x.ForegroundColor();
auto __red = dd.RGB().Red();
auto __green = dd.RGB().Green();
auto __blue = dd.RGB().Blue();
GUID clsID = Guid!("4549DC9D-8A15-46F0-A0ED-7DB9C02FCB18");
GUID iID = Guid!("45F1195F-3554-4B3F-A00A-E1D189C0DC3E");
auto rgb1 = dd.RGB();
auto clsids = Guid2Str(rgb1.clsID);
auto rgb2 = new icRGBColor();
rgb2.iDispatch = rgb2;
//auto rgb = cast(icRGBColor)
//dd.RGB(cast(cRGBColor)(cast(void*)rgb));
//dd.RGB(cast(icRGBColor)(cast(void*)rgb));
cSolidColor.RGBSet =
auto rgb = new icRGBColor();
//auto rgb = cast(icRGBColor)(cast(void*)dd.RGB());
dd.RGB(rgb, rgb1);
//dd.RGB2(rgb1);
return 0;
}
void RGB(icRGBColor ic, cRGBColor c, cSolidColor s)
{
GUID clsIDa = Guid!("AEADF007-9EE5-41D7-8CB1-AB5F353D1151");
GUID iIDa = Guid!("D2D1665E-C1B9-4CA0-8AC9-529F6A3D9002");
ic.iDispatch = s.iDispatch;
ic.rgb = c;
import main;
EXCEPINFO exception;
uint argErr = 0;
auto iidNULL = IID_NULL;
auto RT = new VARIANT();
VARIANT[1] paramVars;
DISPPARAMS params = {rgvarg: paramVars.ptr, cArgs: 1,
cNamedArgs: 0};
auto ID = s.COMMethodIDs[`RGB`];
paramVars[0].punkVal = ic; paramVars[0].vt =
VARENUM.VT_DISPATCH; scope(exit) VariantClear([0]);
DISPID mydispid = DISPID_PROPERTYPUT;
params.rgdispidNamedArgs =
params.cNamedArgs = 1;
writeln("---");
auto res = s.iDispatch.Invoke(cast(int)ID, , 0,
DISPATCH_PROPERTYPUT, , cast(VARIANT*)RT, ,
);
assert(res == S_OK, `Could not invoke COM Function
cSolidColor.RGB. Error `~to!string(res, 16));
}
//version = wrap;
import std.conv, core.sys.windows.windows, core.sys.windows.com,
core.sys.windows.wtypes, core.sys.windows.basetyps,
core.sys.windows.unknwn, core.sys.windows.oaidl;
public class icRGBColor : IDispatch
{
import std.conv, core.sys.windows.windows, core.sys.windows.com,
core.sys.windows.wtypes, core.sys.windows.basetyps,
core.sys.windows.unknwn, core.sys.windows.oaidl;
public IDispatch iDispatch = null;
int RefCount = 0;
cRGBColor rgb;
version(all)
{
void printFunc(string S = __FUNCTION__)()
{
writeln(S);
}
double Red()
Re: MAKELCID C++ translation
On Friday, 5 May 2017 at 23:02:53 UTC, Adam D. Ruppe wrote: On Friday, 5 May 2017 at 22:57:50 UTC, Mike B Johnson wrote: D seems to be missing these macros and definitions import core.sys.windows.winnt; then they should work thanks.
MAKELCID C++ translation
How to translate something like? #define LCID_ENGLISH MAKELCID(MAKELANGID(0x09, 0x01), SORT_DEFAULT) #define LCID_GERMAN MAKELCID(MAKELANGID(0x07, 0x01), SORT_DEFAULT) D seems to be missing these macros and definitions
Re: COM Expertise needed: COM Callbacks
On Friday, 28 April 2017 at 09:25:31 UTC, John Chapman wrote:
On Thursday, 27 April 2017 at 20:20:23 UTC, Nierjerson wrote:
I think the main issue though, is that I really don't know
what is going on when I invoke the PS function. It seems to
call the server method that takes the interface and then the
server does it's "magic"(which is calling my QueryInterface)
but how the implemented QueryInterface is suppose to respond
is beyond me... I've tried some based stuff but nothing seem
to work. The good news is that it is doing something(calling
QueryInterface) which means that the server is at work.
Any more ideas? I think the issue currently is is the
QueryInterface(it is simply not doing what it is suppose to).
I'll probably have to look at some other implementations to
see what is going on.
QueryInterface is COM's version of opCast. It asks if you
support the interface represented by an IID (riid). If you
don't, then you return E_NOINTERFACE. If you do, then you point
the result (pvObject) to yourself and return S_OK. Here's a
basic implementation:
extern(Windows)
HRESULT QueryInterface(IID* riid, void** pvObject) {
if (pvObject is null) return E_POINTER;
*pvObject = null;
if (*riid == IID_IUnknown) *pvObject =
cast(void*)cast(IUnknown)this;
else if (*riid == IID_IDispatch) *pvObject =
cast(void*)cast(IDispatch)this;
// and so on for all interfaces we support
if (*pvObject is null) return E_NOINTERFACE;
(cast(IUnknown)this).AddRef();
return S_OK;
}
AddRef/Release perform the COM object's reference counting, so
you should implement them too.
I wrapped the COM interface that is returned by PS and the
queryInterface works and everything passes(as it should) but when
I use your query interface it results in the COM error specified.
Seems that the QueryInterface code is not 100% correct or
something else is going on.
What I notices is that when PS's QueryInterface routine is used,
it is called only 3 times(queries 3 interfaces like IUnknown,
etc) while when I use your code about 10 interfaces are
queried(including those 3 from PS).
PS's RGB QueryInterface
QueryInterface Called: 0003---C00-0046(GUID),
19F178(Object)
QueryInterface Called:
ECC8691B-C1DB-4DC0-855E-65F6C551AF49(GUID), 19F124(Object)
QueryInterface Called: 0003---C00-0046(GUID),
19EFE8(Object)
main.icRGBColor.Release
Yours
QueryInterface Called: 0003---C00-0046(GUID),
19F178(Object)Not Supported
QueryInterface Called:
ECC8691B-C1DB-4DC0-855E-65F6C551AF49(GUID), 19F124(Object)
Not Supported
QueryInterface Called: 0003---C00-0046(GUID),
19EFE8(Object)Not Supported
QueryInterface Called: 001B---C00-0046(GUID),
19F00C(Object)Not Supported
QueryInterface Called: ---C00-0046(GUID),
19F040(Object)IUnknown Supported
main.icRGBColor.AddRef
QueryInterface Called: 0018---C00-0046(GUID),
19EF1C(Object)Not Supported
QueryInterface Called:
334D391F-0E79-3B15-C9FF-EAC65DD07C42(GUID), 19EEF4(Object)
Not Supported
QueryInterface Called: 0040---C00-0046(GUID),
19EF30(Object)Not Supported
QueryInterface Called:
334D391F-0E79-3B15-C9FF-EAC65DD07C42(GUID), 19EEF4(Object)
Not Supported
QueryInterface Called:
94EA2B94-E9CC-49E0-C0FF-EE64CA8F5B90(GUID), 19EF34(Object)
Not Supported
QueryInterface Called:
334D391F-0E79-3B15-C9FF-EAC65DD07C42(GUID), 19EEF4(Object)
Not Supported
QueryInterface Called:
77DD1250-139C-2BC3-BD95-900ACED61BE5(GUID), 19EF2C(Object)
Not Supported
QueryInterface Called:
334D391F-0E79-3B15-C9FF-EAC65DD07C42(GUID), 19EEF4(Object)
Not Supported
QueryInterface Called:
BFD60505-5A1F-4E41-88BA-A6FB07202DA9(GUID), 19EF28(Object)
Not Supported
QueryInterface Called:
334D391F-0E79-3B15-C9FF-EAC65DD07C42(GUID), 19EEF4(Object)
Not Supported
QueryInterface Called:
03FB5C57-D534-45F5-A1F4-D39556983875(GUID), 19EF24(Object)
Not Supported
QueryInterface Called:
334D391F-0E79-3B15-C9FF-EAC65DD07C42(GUID), 19EEF4(Object)
Not Supported
QueryInterface Called:
2C258AE7-50DC-49FF-9D1D-2ECB9A52CDD7(GUID), 19EF20(Object)
Not Supported
QueryInterface Called: 0019---C00-0046(GUID),
2B5A3C0(Object) Not Supported
QueryInterface Called:
4C1E39E1-E3E3-4296-AA86-EC938D896E92(GUID), 19EF18(Object)
Not Supported
main.icRGBColor.Release
QueryInterface Called: 00020400---C00-0046(GUID),
19ED8C(Object)IDispatch Supported
main.icRGBColor.AddRef
QueryInterface Called:
F37B4894-3ED2-48AF-AD38-BB1B27E93869(GUID), 2D3EAAC(Object)
Not Supported
QueryInterface Called: 0003---C00-0046(GUID),
19EFE8(Object)
I don't know if things are passed off to another query method or
what. The query interface I use is
//
Get name of current function
I'd like to get the symbolic name of the current function I'm in
void foo()
{
writeln(thisFunc.stringof()); // prints foo
}
I need something short, elegant and doesn't require modifying
preexisting code... I'm sure D has something along those lines?
Re: How to get return type of current method?
On Tuesday, 18 April 2017 at 23:49:35 UTC, ketmar wrote: Mike B Johnson wrote: How can I get the return type of the current method without specifying the name or any complexity? Similar to typeof(this). typeof(return) Thanks, sweet and simple!
How to get return type of current method?
How can I get the return type of the current method without specifying the name or any complexity? Similar to typeof(this).
Out of data wiki
can this be updated to work? https://wiki.dlang.org/Timing_Code
