Re: how to pass a malloc'd C string over to be managed by the GC
On Thursday, 28 February 2019 at 03:35:45 UTC, Sam Johnson wrote: On Thursday, 28 February 2019 at 03:33:25 UTC, Sam Johnson wrote: [...] Ignore the `.clone()` call -- that wasn't supposed to be here -- I thought maybe string.clone() might exist but it turns out it does not. Update: it seems that all I need to do is GC.addRoot(output); and memory leak goes away. I think I have answered my own question.
Re: how to pass a malloc'd C string over to be managed by the GC
On Thursday, 28 February 2019 at 03:33:25 UTC, Sam Johnson wrote:
```
string snappyCompress(const string plaintext) {
import deimos.snappy.snappy : snappy_compress,
snappy_max_compressed_length, SNAPPY_OK;
import core.stdc.stdlib : malloc, free;
import std.string : fromStringz, toStringz;
char *input = cast(char *) toStringz(plaintext);
size_t output_length =
snappy_max_compressed_length(plaintext.length);
char *output = cast(char *) malloc(output_length);
if(snappy_compress(input, plaintext.length, output,
_length) == SNAPPY_OK) {
string ret = (cast(string) fromStringz(output)).clone();
// < do something magical here
return ret;
}
assert(0);
}
```
[...]
Ignore the `.clone()` call -- that wasn't supposed to be here --
I thought maybe string.clone() might exist but it turns out it
does not.
how to pass a malloc'd C string over to be managed by the GC
```
string snappyCompress(const string plaintext) {
import deimos.snappy.snappy : snappy_compress,
snappy_max_compressed_length, SNAPPY_OK;
import core.stdc.stdlib : malloc, free;
import std.string : fromStringz, toStringz;
char *input = cast(char *) toStringz(plaintext);
size_t output_length =
snappy_max_compressed_length(plaintext.length);
char *output = cast(char *) malloc(output_length);
if(snappy_compress(input, plaintext.length, output,
_length) == SNAPPY_OK) {
string ret = (cast(string) fromStringz(output)).clone();
// < do something magical here
return ret;
}
assert(0);
}
```
How can I get the GC to automatically garbage collect the
`output` malloc call by tracking the returned `ret` reference? Or
is this already managed by the gc because I cast to a `string`?
Re: Symbols missing, unmangle!
On Wednesday, 30 August 2017 at 22:07:29 UTC, lobo wrote: On Wednesday, 30 August 2017 at 20:23:18 UTC, Johnson Jones wrote: It would be nice if, when symbols are missing, they are unmangled! Error 42: Symbol Undefined _D12mMunchhousin12iMunchhousin11__T4GoTsZ4GoMFS12mMunchhousin18__T10MunchhousinTsZ10sMunchhousinfE12mMunchhousin9eGoffZv (void Munchhousin.Munchhousin.Go!(short).Go() I know some like to read nonsense for fun, but I don't. Sure, I could learn, but it is a useless skill only good for interpreting link errors, writing compilers, and being the life of the party, none of which I want to do for a living. Your error message already displays "void Munchhousin.Munchhousin.Go!(short).Go()" Is this not the missing symbol? I don't read mangled names either and I've found ddemangle tool helps. It ships with dmd. bye, lobo It might be the same. If that is the case then it would be nice if it didn't display the junk that gets in the way(e.g., add a switch). I don't want to have to hunk and peck for stuff(even if it's nearly obvious in some cases). In VisualD, the mangled crap is on a long line that I have to scroll, which is time consuming. Even if wrap is on it still isn't pretty. I mean, if the logic is "It shows the information" then why not just display it directly in binary and let the end user convert it in their head. If they are too stupid to do so then create an online demangler site and a few college classes to teach them how. At some point it becomes ridiculous. Technology is suppose to make our lives easier, not harder. Usually these things are left the way they are until someone gets tired of it and fixes it, it's not that it can't be done, it's that no one seems to care(or it would have been done or the time is now).
Re: Symbols missing, unmangle!
On Wednesday, 30 August 2017 at 21:51:51 UTC, Moritz Maxeiner wrote: On Wednesday, 30 August 2017 at 20:23:18 UTC, Johnson Jones wrote: It would be nice if, when symbols are missing, they are unmangled! Error 42: Symbol Undefined _D12mMunchhousin12iMunchhousin11__T4GoTsZ4GoMFS12mMunchhousin18__T10MunchhousinTsZ10sMunchhousinfE12mMunchhousin9eGoffZv (void Munchhousin.Munchhousin.Go!(short).Go() Since that's a linker error and there are a multitude of linkers that a person could want to use after a D compiler this is a non-trivial issue in general. Options to tackle this include: 1) Have a D compiler capture the linker output and demangle it 2) Try to get demangling of D symbols into upstream of the currently common linkers (GNU linker, gold, lld, etc.) 3) Integrate a (FLOSS) cross platform linker into dmd's backend at the source code level, with support for such demangling (and drop OPTLINK) 4) Fork a (FLOSS) cross platform linker for use with D, add such support, and distribute a binary of it with dmd's binary distribution (and drop OPTLINK) I'm not proposing any of these are what should be done, I've listed them more as an example that something like this would require extensive discussion. [1] https://github.com/ldc-developers/ldc/releases/tag/v1.3.0 A simple wrapper around optilink could possible do this? Not well, but it might be enough? Obviously optilink is the source of the problem. How hard is it to take a string like the above and demangle it in to a readable format? If there is such a funciton in the D compiler, a simple wrapper could be used to parse the output, capture symbol errors, and demangle them. My feeling is that optilink needs to be put to rest. Things die, let them... move on to greener pastures.
Re: ATTN: Andrej Mitrovic: Port Audio
On Sunday, 27 August 2017 at 02:23:32 UTC, Johnson wrote: On Sunday, 27 August 2017 at 02:00:22 UTC, Johnson wrote: You wrote a thread a while back about your callbacks not being called and you had a fix. [...] After going through the code a bit, seems there are some bugs with Only OpenStream seems to take a ** so the other functions are getting passed junk. At least, I got sound! Scared the shit out of me too! I should mention that the callback is still not being called, but I used the sawtooth to modify a buffer and used Pa_WriteStream. Pa_SetStreamFinishedCallback is working. PaStreamFlags.PrimeOutputBuffersUsingStreamCallback still causes an access violation. Seems like the callback address is not being correctly transmitted to PA.
Re: ATTN: Andrej Mitrovic: Port Audio
On Sunday, 27 August 2017 at 02:00:22 UTC, Johnson wrote: You wrote a thread a while back about your callbacks not being called and you had a fix. [...] After going through the code a bit, seems there are some bugs with Only OpenStream seems to take a ** so the other functions are getting passed junk. At least, I got sound! Scared the shit out of me too!
ATTN: Andrej Mitrovic: Port Audio
You wrote a thread a while back about your callbacks not being
called and you had a fix.
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Anyone_using_Portaudio_22343.html
I'm trying to get portAudio to work on my machine and it seems
everything passes yet my callbacks are not being called.
I do not know if it is the same issue you had or what. Could you
describe your fixes, if you remember? You said it was alias
issues, my source uses alias, so maybe I have the updated one.
Also, using paPrimeOutputBuffersUsingStreamCallback causes an
access violation ;/
Here are some dll's I'm using
https://github.com/spatialaudio/portaudio-binaries
I'm including the two files needed to compile what I have in case
you(or anyone else) decide to help figure this out:
Make sure to change the dll location in the DLL_PortAudio struct
and set the appropriate audio interface to use(I have it set to
12, but have tried every value on my system with no luck).
module mPortAudio;
import std.stdio, std.conv;
enum PaError : int
{
NoError = 0,
NotInitialized = -1,
UnanticipatedHostError,
InvalidChannelCount,
InvalidSampleRate,
InvalidDevice,
InvalidFlag,
SampleFormatNotSupported,
BadIODeviceCombination,
InsufficientMemory,
BufferTooBig,
BufferTooSmall,
NullCallback,
BadStreamPtr,
TimedOut,
InternalError,
DeviceUnavailable,
IncompatibleHostApiSpecificStreamInfo,
StreamIsStopped,
StreamIsNotStopped,
InputOverflowed,
OutputUnderflowed,
HostApiNotFound,
InvalidHostApi,
CanNotReadFromACallbackStream,
CanNotWriteToACallbackStream,
CanNotReadFromAnOutputOnlyStream,
CanNotWriteToAnInputOnlyStream,
IncompatibleStreamHostApi,
BadBufferPtr,
FormatIsSupported = 0,
};
enum PaSampleFormat : ulong
{
Float32 = 0x0001,
Int32= 0x0002,
Int24= 0x0004,
Int16= 0x0008,
Int8 = 0x0010,
UInt8= 0x0020,
CustomFormat = 0x0001,
NonInterleaved = 0x8000
}
enum PaHostApiTypeId : int
{
InDevelopment=0,
DirectSound=1,
MME=2,
ASIO=3,
SoundManager=4,
CoreAudio=5,
OSS=7,
ALSA=8,
AL=9,
BeOS=10,
WDMKS=11,
JACK=12,
WASAPI=13,
AudioScienceHPI=14
};
enum PaStreamCallbackResult : int
{
paContinue=0, /**< Signal that the stream should continue
invoking the callback and processing audio. */
paComplete=1, /**< Signal that the stream should stop
invoking the callback and finish once all output samples have
played. */
paAbort=2 /**< Signal that the stream should stop
invoking the callback and finish as soon as possible. */
};
enum PaStreamFlags : ulong
{
NoFlag = 0,
ClipOff = 0x0001,
DitherOff = 0x0002,
NeverDropInput = 0x0004,
PrimeOutputBuffersUsingStreamCallback = 0x0008,
PlatformSpecificFlags = 0x,
}
alias void PaStream;
enum paFramesPerBufferUnspecified = 0;
enum PaStreamCallbackFlags : ulong
{
InputUnderflow = 0x0001,
InputOverflow = 0x0002,
OutputUnderflow = 0x0004,
OutputOverflow = 0x0008,
PrimingOutput = 0x0010,
}
alias extern(C) int function(const(void) *input, void *output,
ulong frameCount, const(PaStreamCallbackTimeInfo)* timeInfo,
PaStreamCallbackFlags statusFlags, void *userData )
PaStreamCallback;
alias void function( void *userData ) PaStreamFinishedCallback;
alias int PaDeviceIndex;
enum paNoDevice = cast(PaDeviceIndex)-1;
enum paUseHostApiSpecificDeviceSpecification =
cast(PaDeviceIndex)-2;
alias int PaHostApiIndex;
alias double PaTime;
struct PaHostApiInfo
{
int structVersion;
PaHostApiTypeId type;
const(char) *name;
int deviceCount;
PaDeviceIndex defaultInputDevice;
PaDeviceIndex defaultOutputDevice;
};
struct PaDeviceInfo
{
int structVersion;
const(char) *name;
PaHostApiIndex hostApi;
int maxInputChannels;
int maxOutputChannels;
PaTime defaultLowInputLatency;
PaTime defaultLowOutputLatency;
PaTime defaultHighInputLatency;
PaTime defaultHighOutputLatency;
double defaultSampleRate;
};
struct PaStreamCallbackTimeInfo
{
PaTime inputBufferAdcTime;
PaTime currentTime;
PaTime outputBufferDacTime;
};
struct PaStreamInfo
{
int structVersion;
PaTime inputLatency;
PaTime outputLatency;
double sampleRate;
};
struct PaHostErrorInfo
{
PaHostApiTypeId hostApiType;
long errorCode;
const(char) *errorText;
};
struct PaStreamParameters
{
PaDeviceIndex device;
int channelCount;
PaSampleFormat sampleFormat;
PaTime suggestedLatency;
void *hostApiSpecificStreamInfo;
};
struct DLL_PortAudio
{
@("DLLImport") public static
in for testing
while(str[i] in [' ', '\r', ...]) rather than having to do each test individually.
OpenMAX bindings
Anyone?
Re: GStreamer issues.
On Tuesday, 22 August 2017 at 15:15:41 UTC, Mike Wey wrote:
On 22-08-17 02:13, Johnson wrote:
I can't get the example to work(although slightly modified).
The installed version of GStreamer is 1.12.2
The file is: D:\temp\test.ogg
Loading
Setting to PLAYING.
Running.
XError: Could not demultiplex stream. dbug:
gstoggdemux.c(4418): gst_ogg_demux_find_chains ():
/GstPipeline:audio-player/GstOggDemux:ogg-parser:
can't get first chain
Actually I was getting a much worse error before ;/ I can't
remember it now.
The installed version of GStreamer is 1.12.2
The file is: D:\temp\test2.wav
Loading
Setting to PLAYING.
Running.
XError: Internal data stream error. dbug:
gstwavparse.c(2249): gst_wavparse_loop ():
/GstPipeline:audio-player/GstWavParse:wav-parser:
streaming stopped, reason not-linked (-1)
Basically all I did was change the sink:
sink = ElementFactory.make("autoaudiosink",
"auto-output");
So it I could get past the error about alsa. I think the last
name doesn't matter?
I downloaded the gstreamer binaries from their site, had some
issues with a few of the dll's complaining about gxx errors, I
removed them(h264, soundtouch, tag).
For the wav I changed
//parser = ElementFactory.make("oggdemux",
"ogg-parser");
//decoder = ElementFactory.make("vorbisdec",
"vorbis-decoder");
parser = ElementFactory.make("wavparse",
"wav-parser");
decoder = ElementFactory.make("audioconvert",
"wav-decoder");
which, is all i could find on line, I don't know if it's right
at all.
Ultimately I want to be able to read somewhat arbitrary audio
formats(most common at least), get the raw channel
data(samples for each channel), play/pause/stop with good
accuracy(no latency or low latency(<20ms), possibly do some
pitch shifting and basic mixing(EQ, limiting, panning, etc),
and eventually play some videos.
Is GstreamerD going to be useful for this or so I look in to
using ffmpeg directly and do some of the stuff(e.g., eq)
myself?
Thanks.
The Gstreamer demo should use an `playbin` instead of
explicitly setting the pipeline, Like this:
https://github.com/gtkd-developers/GtkD/blob/master/demos/gstreamer/helloworld/gstreamer_helloworld.d
This way gstreamer will detect the file type, i don't know if
it helps with the errors.
Thanks, that works!
Could you address some of my concerns:
1. I need to be able to get the raw data, is this easily possible
with gstreamer?
2. It's quite a big package 600mb+ total and about 150 for the
bin and 150 for the lib. Eventually I want to support android,
this seems quite excessive for it. I'm not familiar with
Gstreamer though and maybe most of that space is "junk". It seems
people use it already on android so I'm not too worried, I
imagine it can be customized?
3. Does Gstreamer/D provide any type of EQ, pitch shifting,
stretching, etc?
4. Do you have any idea why the original code would work? I ask
because maybe in the future I'll need to use it for other
purposes and don't wanna hit a brick wall.
Note that I'm completely new to gstreamer and only learned of it
through gtkD... so some of these might be basic questions. I'm
just trying to find something simple to use but is robust so I
don't waste time learning an api that isn't going to really do
what I need. I was plan on using portaudio and ffmpeg, but
ffmpegD doesn't really seem to work(old bindings I guess). I also
had trouble with portaudio not playing any sound, but haven't
spent much time with it to why.
Gstreamer, with your updated example, works though. Just not sure
how far of a leap I'll have to make to get it working the way I
need in my app.
GStreamer issues.
I can't get the example to work(although slightly modified).
The installed version of GStreamer is 1.12.2
The file is: D:\temp\test.ogg
Loading
Setting to PLAYING.
Running.
XError: Could not demultiplex stream. dbug: gstoggdemux.c(4418):
gst_ogg_demux_find_chains ():
/GstPipeline:audio-player/GstOggDemux:ogg-parser:
can't get first chain
Actually I was getting a much worse error before ;/ I can't
remember it now.
The installed version of GStreamer is 1.12.2
The file is: D:\temp\test2.wav
Loading
Setting to PLAYING.
Running.
XError: Internal data stream error. dbug: gstwavparse.c(2249):
gst_wavparse_loop ():
/GstPipeline:audio-player/GstWavParse:wav-parser:
streaming stopped, reason not-linked (-1)
Basically all I did was change the sink:
sink = ElementFactory.make("autoaudiosink", "auto-output");
So it I could get past the error about alsa. I think the last
name doesn't matter?
I downloaded the gstreamer binaries from their site, had some
issues with a few of the dll's complaining about gxx errors, I
removed them(h264, soundtouch, tag).
For the wav I changed
//parser = ElementFactory.make("oggdemux", "ogg-parser");
//decoder = ElementFactory.make("vorbisdec", "vorbis-decoder");
parser = ElementFactory.make("wavparse", "wav-parser");
decoder = ElementFactory.make("audioconvert", "wav-decoder");
which, is all i could find on line, I don't know if it's right at
all.
Ultimately I want to be able to read somewhat arbitrary audio
formats(most common at least), get the raw channel data(samples
for each channel), play/pause/stop with good accuracy(no latency
or low latency(<20ms), possibly do some pitch shifting and basic
mixing(EQ, limiting, panning, etc), and eventually play some
videos.
Is GstreamerD going to be useful for this or so I look in to
using ffmpeg directly and do some of the stuff(e.g., eq) myself?
Thanks.
Re: GtkD: New widget
On Monday, 21 August 2017 at 20:54:04 UTC, Mike Wey wrote:
On 21-08-17 03:45, Johnson Jones wrote:
[...]
If you want gtk to know about the functions you override you
could use gtkd.Implement.ImplementCLass.
[...]
Thanks, I'll test it out when I get a chance. I was able to work
around the issue for now but I imagine I'll need the ability to
implement my own container in the future.
BTW, when I try to create a value I get an error about opCall
Value handleSize = new Value(0);
vs
Value handleSize = Value(0);
I'd rather not create a value on the heap when I only need it
locally.
Could you add a way to create the value with the right type to
Value?
Even static constructors would work(probably could templatize it).
Although, I'm not sure how much it matters since value itself
seems to allocate on the heap ;/
public this()
{
this(new GValue);
}
But it might help reduce some memory waste.
Re: Mixed up over mixins.
On Monday, 21 August 2017 at 07:34:23 UTC, WhatMeForget wrote:
On Sunday, 20 August 2017 at 22:50:40 UTC, Johnson Jones wrote:
On Sunday, 20 August 2017 at 19:27:43 UTC, WhatMeWorry wrote:
[...]
It's not difficult, it's just new. It's not that you are a
poor programmer, but you simply have not learned how to think
about mixins correctly. Stop whining about it and focus that
energy on working with them.
[...]
Thank you. You have rejuvenated my quest for mixin mastery :)
Just stick with it ;) Things will click. The more you trudge
through them and just try to immerse yourself in it the faster it
will happen. I use mixins all the time because they are a great
way to simplify code... although actually writing them can be a
pain because you can't debug them in any sane way.
Remember, that you will generally use string generation a ton
because that is mainly what you are working.
Sometimes, for complex tasks I might have to write a function
that I run at runtime like a normal program that takes in a
string and outputs it. This lets me debug properly. As long as
one doesn't use crazy io(even file IO is blocked ;/) the same
function can be run at compile time(CTFE).
This means
myfoo("asdfasdf");
will be ran at compile time, the reason is simply that the input
is constant, there are no side effects, and so the output can be
computed at compile time.
But the same function can be debugged if ran at runtime... and
remember, the output is a string, so you can just print it out,
no mixin is occuring at this point.
The idea is that you make sure the string output is going to be
the correct D code you want to mixin. It should look like normal
D code, because if you do a mixin on it, it has to be to compile.
Any syntax errors will be picked up and you'll be hunting them
down because D will give you an obtuse error rather than a
specific line number in the mixin(this is a severe issue with D
but no one seem to care). If you debugged at runtime, you will
get a line number where the error occurred, which is why you go
that route.
Once you've gotten your function written to do the code, you
simply wrap a mixin() around it, you might have to change a bit
of runtime to compile time stuff(file io to import) and then all
that string stuff that you generated becomes D code!
mixin("int i = 3"); <- bug
mixin("int i = 3;"); <- ok
same as
int i = 3;
useless example but sometimes it's helpful. Sometimes to get the
things working you have to use mixins of mixins:
mixin("mixin("~something~");");
or, take this example
auto alpha = "hello";
mixin("w"~"r"~"i"~"te(`"~alpha~"`);");
before the mixin we have
"w"~"r"~"i"~"te(`"~alpha~"`);"
which, when simplified is
"write(`"~alpha~"`);"
which, since alpha is a constant, we have
"write(`hello`);"
which, the mixin simply does
write(`hello`);
which is now D code.
A mixin, in a sense, just "unstringifies" it's argument and
inserts it directly in to the source code... it better be valid
code, which also means the string better be a valid string of D
code.
Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing
On Monday, 21 August 2017 at 06:16:49 UTC, Rainer Schuetze wrote: On 21.08.2017 05:24, Johnson wrote: On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote: [...] This just started happening too and a few hours ago I upgraded VS, so maybe the msobj140.dll changed and broke cv2pdb? I copied it to the cv2pdb dir so it should have no trouble finding it. I've also cleaned the dir. It seems it's doing it on about everything I change. Going to reboot to see if that helps. Unfortunately, the VS2017 15.3.1 update seems to cause quite some trouble. Bad linker (breaks TLS), bad vcvars*.bat (change current directory), and this issue, too. I guess they changed something about the (undocumented) interface to the respective DLLs. ;/ That sucks ;/ I guess I might just have to install VS2015, or does that have issues too? Any idea what might be the best VS version that is most compatible with Visual D?
Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing
On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote:
All of a sudden I'm getting this error. All I did was comment
out a huge block of code so I could check something. The code
compiles but the pdb conversion gives me that error ;/
Uncommenting out the code allows it to work again. I can't see
why the code I'm commenting out would give that error ;/
Deleting the code also produces the same result.
It seems to be in use with GTK and event handlers. The handlers
are completely isolated yet are somehow causing the problem.
You won't believe this, I'm sure, but
//Dialog.addOnDestroy((Widget w) { });
causes the error! Must be some serious bug! Uncommenting allows
the code to build fine.
I tried restarting visual D with no luck ;/
This just started happening too and a few hours ago I upgraded
VS, so maybe the msobj140.dll changed and broke cv2pdb? I copied
it to the cv2pdb dir so it should have no trouble finding it.
I've also cleaned the dir. It seems it's doing it on about
everything I change. Going to reboot to see if that helps.
cv2pdb: cannot add symbols to module, probably msobj140.dll missing
All of a sudden I'm getting this error. All I did was comment out
a huge block of code so I could check something. The code
compiles but the pdb conversion gives me that error ;/
Uncommenting out the code allows it to work again. I can't see
why the code I'm commenting out would give that error ;/
Deleting the code also produces the same result.
It seems to be in use with GTK and event handlers. The handlers
are completely isolated yet are somehow causing the problem.
You won't believe this, I'm sure, but
//Dialog.addOnDestroy((Widget w) { });
causes the error! Must be some serious bug! Uncommenting allows
the code to build fine.
I tried restarting visual D with no luck ;/
GtkD on android
Hey Mike, have you put in thought or effort in to getting GtkD working on android? e.g., https://github.com/eugals/GTKAndroid/wiki/Building If I get around to it and no one has beating me before, I will try to compile something like the above and get the gtk libs required then use the new ldc to create an app for android.
Re: GtkD: How to respond to cell edit's?
On Friday, 18 August 2017 at 17:06:42 UTC, Mike Wey wrote:
On 18-08-17 02:30, Johnson Jones wrote:
On Friday, 18 August 2017 at 00:27:05 UTC, Johnson Jones wrote:
[...]
Obvious it is easy when you have ID's, but this is meant for
the original case where I'm not using ID's.
A far as i can tell using id's is the only option.
You can use a templated function as a delegate:
```
void cb(int column)(string index, string text, CellRendererText
r)
{
writeln(column, " - ", index, " - ", text);
}
RT1.addOnEdited(!1);
RT2.addOnEdited(!2);
RT2.addOnEdited(!3);
```
Thanks! Hopefully that will help ease the pain and help avoid the
large switch statement ;) It's strange one can't get the
cellrenderers's from a column ;/
Re: Visual D 0.45 released - better VS2017 integration
On Thursday, 17 August 2017 at 07:49:53 UTC, Rainer Schuetze wrote: On 03.08.2017 09:04, Rainer Schuetze wrote: [...] I have uploaded a new version 0.45.1 that should fix some anti-virus programs to reject the installation or execution of Visual D (by building against the MS runtime instead of the DM runtime). A few other changes crept in aswell, like improved tooltips and a number of bug fixes. See full list of changes here: http://rainers.github.io/visuald/visuald/VersionHistory.html Cool! Thanks!
Re: Debugging Visual D using Visual D
On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze
wrote:
On 16.08.2017 21:18, Johnson Jones wrote:
What's strange is that with your changes, privateregistry
seems to use them... but it still loads the old(I think)
visualD because when I try the debug the BP's are not hit and
the module shows the original visualD directory.
The Visual D installer adds the extension to the VS
installation ("c:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\Common7\IDE\Extensions\Rainer
Schuetze\VisualD") so it is immediately available for all users
and suffixes.
You can move it to
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.
If you run "devenv /RootSuffix Exp /Log" VS writes a log into
"%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml" that also lists detected extensions.
I completely removed the `Extensions\Rainer Schuetze` directories
in all visual studio folders that I know of:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\IDE\Extensions
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
Running visual studio still loads Visual D. It seems that it
doesn't even use the visuald.pkgdef.
Obviously I have those entries in the registry. Which it seems it
pulls from and either doesn't use the extensions folder at all on
my system or is overridden by the registry entries? If that's the
case, how can it be worked around? If not, what else might it be?
If visuald.pkgdef is suppose to be what visual studio uses to
load visual D as an extension, does it import that in to the
registry and then use the registry or does it always use the
pkgdef file?(which doesn't seem to be the case, as, again, visual
D is loading with visual studio without any of those pkgdef's)
What I'm afraid of is that deleting the registry keys will not do
any good, they will just be re-imported by loading the pkgdef(or
not, in which case Visual D won't be found at all) and then the
main registry keys will be used for the Exp, like it is now.
Basically visual studio is not loading the pkgdef files either at
all or only once, or every time but not allow them to overwrite
the registry keys, or something else is going on that I can't
seem to figure out.
Re: Debugging Visual D using Visual D
On Wednesday, 16 August 2017 at 06:58:49 UTC, Rainer Schuetze wrote: On 16.08.2017 08:32, Rainer Schuetze wrote: On 16.08.2017 04:49, Johnson wrote: VisualD.dllC:\Program Files (x86)\VisualD\Debug\VisualD.dll N/AYesSymbols loaded. C:\Program Files (x86)\VisualD\Debug\VisualD.pdb229 0.45.1-rc212/31/1969 7:00 PM13FB-143C* [8972] devenv.exe VisualD.dllC:\Program Files (x86)\VisualD\VisualD.dllN/A YesCannot find or open the PDB file.2710.45.1-rc2 12/31/1969 7:00 PM 18D4-1904E000*[8972] devenv.exe I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset. So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such. I could try to use another, different exp instance(different registry) but I feel the same problem might occur. But I guess it's better than nothing. Good to hear it (kind of) works now. VS2015 also resets the configuration rather often, so it's good to automate the patching. I don't have troubles with exchanging the debug DLL while having the normal VS instance running. Maybe you have experimented with registry changes that now cause the debug DLL to be loaded there, too? Reinstalling Visual D should help in that case (though that will trigger rebuilding the user configuration). I've tried to figure out why both DLLs are actually loaded (it has been bugging me before, too), but could not find the cause yet. I managed to load the Debug DLL into the "experimental" VS without any (explicit) registry patching: 1. delete HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\privateregistry.bin to make sure to start from scratch 2. copy "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD" to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\Extensions\Rainer Schuetze\VisualD" 3. replace paths in Extensions\Rainer Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL 4. start "devenv /RootSuffix Exp" 5. enable "Visual D" in the "Extensions and Updates..." dialog 6. restart VS This even doesn't load the DLL twice for me. This isn't working for me, even though it looks like it should. Those values in the pkgdef are exactly the ones I replaced in the privateregistry hive, but it seems that for some reason it is not being used ;/ (since my changes are not propagating to it) This should work as this is really no different that what I was doing except it is more of the correct way. I'm not sure what's going on but I'll try and figure it out. I probably need to use a clean instance of VS It seems I have something weird going on. I have 15.0 15.0_4d0b469e 15.0_4d0b469eExp 15.0Exp which is empty except for a path containing VSTemplateStore.pkgdef and I don't believe this existed yesterday. I think I just created it with the util I used as I was trying to reset the exp instance(which I thought was the 3rd one). I'm not sure where the others came from but I'm going to create a new rootsuffix and try everything on that. I guess the 15.0_4d0b469eExp is a _4d0b469eExp suffix and hence I'm not loading it ;/ Ok, I ran CreateExpInstance /create /VSInstance=15.0 /RootSuffix=VisualDExp and it created a 15.0VisualDExp dir. So, looks like the 15.0Exp was what I just created and it wasn't being used when I ran /RootSuffix=Exp.. which I guess, because it didn't exist, just used the original data. I ran devenv.exe /RootStuffix VisualDExp and it created 15.0_4d0b469eVisualDExp So, something is funky. I guess 15.0_4d0b469e is the version. It loads, though, Visual D, so it is picking up the extensions from the original. This seems to be a problem with Visual Studio ;/ Yeah, so, tried with a fresh exp copied all the stuff you mentioned, checked the files and same thing. I'm using enterprise on windows 10 creators so there might be bugs. It's clearly not loading the package changes I made so either it's bugged or it's loading them from a different place. I'll try again tomorrow and see if things change ;/
Re: Stefan Koch: New CTFE fix
On Wednesday, 16 August 2017 at 07:24:36 UTC, Biotronic wrote: On Tuesday, 15 August 2017 at 16:10:40 UTC, Johnson wrote: I'm sorry, but you are obviously someone in *need* to prove something. No need to respond, ever. You need to grow up. When Moritz commented on your use of 'do' as a function name, that may have been unnecessary for a discussion of your problem. Your vitriolic and childish reaction to that though, was not just unnecessary, but has done you a massive disservice and is more than unlikely to garner goodwill from others on the forum. Oh, your such a bad boy. How bout you grow up. If I'm childish, you are just a smaller child because you are doing the exact same thing... getting on the internet, pretending to be some bad boy with something to say... like anyone will listen to you. That goes for your buddy too. Probably all the same person that has nothing real to say. But at least we agree on Mortimer. You know, if you people actually focused on the real issues instead of trying to show how bit your (tiny)dick was then there would be less problems in the world.
Re: Stefan Koch: New CTFE fix
On Wednesday, 16 August 2017 at 10:03:56 UTC, Moritz Maxeiner
wrote:
On Wednesday, 16 August 2017 at 07:24:36 UTC, Biotronic wrote:
When Moritz commented on your use of 'do' as a function name,
that may have been unnecessary for a discussion of your
problem.
I would contend that when discussing semantics (that is the
PL's syntax is not open for change as part of the discussion)
it's common courtesy to use valid syntax.
You're right in that it was unnecessary to discuss the issue he
was describing, but it was relevant to me as a matter of
principle.
No, it wasn't. It was a matter of you ego... and I see your
buddies have joined the game.
What if I did
void Do() { }
Would you bitch and complain about that?
Maybe the original was a syntax error then and not a "semantic"
error as you like to call it?
The fact is, the name of the function is completely irrelevant to
the discussion and you had to make a big deal out of it because
of your ego.
What if it were pseudo code?
Again, instead proof that either you are an idiot(which I doubt)
or that you have some need to prove something and will find
anything to nitpick on. This is far more childish than those
morons that say I'm childish, and they even agree with me that
what you did was nonsense... completely irrelevant to the
discussion.
That is, until we have a functioning __ctfeWrite in druntime.
The function is already in druntime's object.d, and is just
awaiting an implementation[2]. That implementation will
possibly have to wait for Stefan's CTFE makeover to complete.
Well, my implementation attempt I linked to earlier [1] passes
the auto tester for the test in Stefan's original PR and so far
it works as expected in all my personal cases. If you find
something wrong with it, please comment on the PR's page :)
[1] https://github.com/dlang/dmd/pull/7082
So, if the people already want what I want, and you already did
your own pull, why the hell are you saying it can't be done?
Again, because you are looking for something to prove, and
calling you out on it is the right thing to do regardless what
idiots think.
You can make the claim that pragma(msg, ...) happens before the
ctfe is ran, but again, which pragma(msg, ...)? With CTFE there
are two levels, the compiler is ran twice, once on the original
code and once on the CTFE to actually compile it. Just because
the compiler run's it the first time DOES not mean that should be
the only way. You talk about semantics but you seem not to
understand the term well. A single symbolic name for something
can have many interpretations. When one, someone like yourself or
the D compiler, only interprets it one way, it leads to problems.
How out pragmaCTFE(msg, ...)? Is that good enough for you, or you
will find something wrong with that too? Do you realize that
there are two levels of compilation going in with ctfe?
Essentially two DMD's? If there are two dmd's then there are two
pragma's, is there not? So the arguments you make may be correct,
you are missing half of the equation and fail to realize that
because you are trying to prove something rather than enlighten
yourself.
Re: Named multi-imports
On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
On Tuesday, 15 August 2017 at 21:12:24 UTC, jmh530 wrote:
On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
Or instead of a new language feature, the gtk-d guys could
have package files ;)
But then that only helps with one specific instance. D is
full of language features, I do not see why everyone is so
against them. Without them, D would be empty, nothing, and no
one would use it. Adding language features should be see as
something good, cause without them, we wouldn't get anywhere.
In the past, I've thought it would be convenient to have
something like
import io = std.stdio : writeln, write;
and allow someone to write
io.write("foo");
io.writeln("bar");
though I don't know if that causes any kinds of problems to
implement.
This looks really clean for code modularity.
import io = std.stdio : {writeln, write}, ...
Yes, and also
import io = {std.stdio : {writeln, write}, ... }
which allows one to create their own "packages" inline. Group the
best functionality they use often. Should be quick, efficient,
and easy to implement. D should have this, where do I vote for it?
Re: Debugging Visual D using Visual D
VisualD.dll C:\Program Files (x86)\VisualD\Debug\VisualD.dll N/A Yes Symbols loaded. C:\Program Files (x86)\VisualD\Debug\VisualD.pdb 229 0.45.1-rc2 12/31/1969 7:00 PM 13FB-143C* [8972] devenv.exe VisualD.dll C:\Program Files (x86)\VisualD\VisualD.dll N/A Yes Cannot find or open the PDB file. 271 0.45.1-rc2 12/31/1969 7:00 PM 18D4-1904E000* [8972] devenv.exe I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset. So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such. I could try to use another, different exp instance(different registry) but I feel the same problem might occur. But I guess it's better than nothing.
Re: Named multi-imports
On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole wrote: On 15/08/2017 2:59 AM, Johnson wrote: Not only that, but it requires adding more files to the command line. I currently have 3 import files to separate the gtk from gdk that and the only reason they exist is to combine them in to one named import ;/ Doesn't seem like much but that's 3 extra files that don't really need to exist. Hopefully D already implements a way to do what I'm asking. Or instead of a new language feature, the gtk-d guys could have package files ;) But then that only helps with one specific instance. D is full of language features, I do not see why everyone is so against them. Without them, D would be empty, nothing, and no one would use it. Adding language features should be see as something good, cause without them, we wouldn't get anywhere.
Re: Stefan Koch: New CTFE fix
I'm sorry, but you are obviously someone in *need* to prove something. No need to respond, ever.
Re: Named multi-imports
Not only that, but it requires adding more files to the command line. I currently have 3 import files to separate the gtk from gdk that and the only reason they exist is to combine them in to one named import ;/ Doesn't seem like much but that's 3 extra files that don't really need to exist. Hopefully D already implements a way to do what I'm asking.
Named multi-imports
Why can't we name multiple imports?
import x = a, b, c;
only a is part of x, b and c are not named!
this can cause some major problems(or the lack of a correctly
solution).
For example,
gdk and gtk both have window. Both imports are needed and both
define many public imports that create a huge spaghetti of mixed
imports. In my code, even without gdk.Window imported, I am
getting variables that are of that time, even though I import
gtk.Window. I declare the variables as Window because it is
automatically generated code and I do not know the actual
import(well, unless I manually create a map from all the D
imports to the glade types).
But I use gdk in just a few areas.
The only solution is to create a separate pulbic imports file
that holds all the imports, but this creates extra files.
Why not something like
import x = {a,b,c};
?
It's a natural extension, makes sense, and should be easy to work
out. Avoids having extra files for no other reason that to do the
above and should easily solve the conflicts. What's nice about it
is that we can even do
import x =
{
a,
b,
c
};
which is like
public
{
}
@{att}
{
}
etc...
See what I mean:
public import gtk.AboutDialog;
public import gtk.AccelGroup;
public import gtk.AccelLabel;
public import gtk.AccelMap;
public import gtk.Accessible;
public import gtk.Action;
public import gtk.ActionableIF;
public import gtk.ActionableT;
public import gtk.ActionBar;
public import gtk.ActionGroup;
public import gtk.ActivatableIF;
public import gtk.ActivatableT;
public import gtk.Adjustment;
public import gtk.Alignment;
public import gtk.AppChooserButton;
public import gtk.AppChooserDialog;
public import gtk.AppChooserIF;
public import gtk.AppChooserT;
public import gtk.AppChooserWidget;
public import gtk.Application;
public import gtk.ApplicationWindow;
public import gtk.Arrow;
public import gtk.ArrowAccessible;
public import gtk.AspectFrame;
public import gtk.Assistant;
public import gtk.Bin;
public import gtk.BindingEntry;
public import gtk.BindingSet;
public import gtk.BooleanCellAccessible;
public import gtk.Border;
public import gtk.Box;
public import gtk.BuildableIF;
public import gtk.BuildableT;
public import gtk.Builder;
public import gtk.Button;
public import gtk.ButtonAccessible;
public import gtk.ButtonBox;
public import gtk.Calendar;
public import gtk.CellAccessible;
public import gtk.CellAccessibleParentIF;
public import gtk.CellAccessibleParentT;
public import gtk.CellArea;
public import gtk.CellAreaBox;
public import gtk.CellAreaClass;
public import gtk.CellAreaContext;
public import gtk.CellEditable;
public import gtk.CellEditableIF;
public import gtk.CellEditableT;
public import gtk.CellLayoutIF;
public import gtk.CellLayoutT;
public import gtk.CellRenderer;
public import gtk.CellRendererAccel;
public import gtk.CellRendererClass;
public import gtk.CellRendererCombo;
public import gtk.CellRendererPixbuf;
public import gtk.CellRendererProgress;
public import gtk.CellRendererSpin;
public import gtk.CellRendererSpinner;
public import gtk.CellRendererText;
public import gtk.CellRendererToggle;
public import gtk.CellView;
public import gtk.CheckButton;
public import gtk.CheckMenuItem;
public import gtk.CheckMenuItemAccessible;
public import gtk.Clipboard;
public import gtk.ColorButton;
public import gtk.ColorChooserDialog;
public import gtk.ColorChooserIF;
public import gtk.ColorChooserT;
public import gtk.ColorChooserWidget;
public import gtk.ColorSelection;
public import gtk.ColorSelectionDialog;
public import gtk.ComboBox;
public import gtk.ComboBoxAccessible;
public import gtk.ComboBoxText;
public import gtk.Container;
public import gtk.ContainerAccessible;
public import gtk.ContainerCellAccessible;
public import gtk.ContainerClass;
public import gtk.CssProvider;
public import gtk.CssSection;
public import gtk.Dialog;
public import gtk.DragAndDrop;
public import gtk.DrawingArea;
public import gtk.EditableIF;
public import gtk.EditableT;
public import gtk.Entry;
public import gtk.EntryAccessible;
public import gtk.EntryBuffer;
public import gtk.EntryCompletion;
public import gtk.EventBox;
public import gtk.EventController;
public import gtk.Expander;
public import gtk.ExpanderAccessible;
public import gtk.FileChooserButton;
public import gtk.FileChooserDialog;
public import gtk.FileChooserIF;
public import gtk.FileChooserNative;
public import gtk.FileChooserT;
public import gtk.FileChooserWidget;
public import gtk.FileFilter;
public import gtk.Fixed;
public import gtk.FlowBox;
public import gtk.FlowBoxAccessible;
public import gtk.FlowBoxChild;
public import gtk.FlowBoxChildAccessible;
public import gtk.FontButton;
public import gtk.FontChooserDialog;
public import gtk.FontChooserIF;
public import gtk.FontChooserT;
public import gtk.FontChooserWidget;
public import gtk.FontSelection;
public import gtk.FontSelectionDialog;
public import gtk.Frame;
public import gtk.FrameAccessible;
public import gtk.Gesture;
public import
Re: Stefan Koch: New CTFE fix
On Tuesday, 15 August 2017 at 01:31:13 UTC, Moritz Maxeiner wrote:
On Monday, 14 August 2017 at 22:51:04 UTC, Johnson Jones wrote:
string do()
{
string x;
x = "adsf";
pragma(msg, x);
return x;
}
"do" is a keyword in D, you can't use it as an identifier.
wow, way to fail to realize generalities.
fails because the compiler believes that x is not known at
compile time.
There are multiple phases making up D's compile time, the wiki
has an excellent page by H. S. Teoh on the subject [1]. Applied
to your example: The pragma in the function body is handled
before the function body is interpreted, so the compiler error
is correct; whether or not the error message should be more
explicit is another matter.
So, that is a generic answer for a generic post. It says nothing
about what can be done, but what only can't be done. There is
nothing stopping one's ability to output compile time information
at compile time from compile time functions. Again, way to fail
to realize generalities. Just because something is defined to be
something doesn't mean that it can't be defined to be something
different. It happens all the time. People create false
constraints based on ignorance and then someone has to come along
and clean up the mess. But some people like messes I suppose...
It obviously is when do is ran as a ctfe. This makes some
types of programming difficult to debug because we have to
duplicate any instance of "do" and cannot output intermediate
values.
But, how can we make this actually work?
[...]
I recommend reading up on the history of CTFE output in
D[2][3][4][5][6].
If you want to see CTFE output in D, you could pick up where
Stefan left off in the latest attempt[6].
[1]
https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
[2]
http://www.digitalmars.com/d/archives/digitalmars/D/CTFE_writeln_140241.html
[3] http://forum.dlang.org/thread/j1n0l7$235r$1...@digitalmars.com
[4] https://github.com/dlang/dmd/pull/296
[5] https://github.com/dlang/dmd/pull/692
[6] https://github.com/dlang/dmd/pull/6101
It seems like he's already done all the heavy lifting and who
knows best rather than him to implement it in his own redesign of
ctfe(to fix the mess that it was in precisely for the reasons I
stated above)?
Re: wth!! ctfe cannot format floating point at compile time?
On Monday, 14 August 2017 at 03:52:40 UTC, HypperParrow wrote:
On Monday, 14 August 2017 at 01:52:16 UTC, Johnson Jones wrote:
Error: uncaught CTFE exception
std.format.FormatException("Cannot format floating point types
at compile-time")
called from here: to(0.75)
pretty simply, trying to convert a floating point to a string
in a ctfe function and it thinks that it is too complex to do
in a ctfe, really?
There is this trick as workaround:
```
auto valueToString(alias v)(){return v.stringof;}
enum a = valueToString!(0.75);
static assert(a == "0.75");
```
The problem with to() and format() is that is requires external
library calls that are not available at compile-time, just like
when you try to use malloc() at CT.
Thanks! You'd think that to would do this internally
automatically ;/
Re: wth!! ctfe cannot format floating point at compile time?
On Monday, 14 August 2017 at 03:44:27 UTC, Adam D. Ruppe wrote:
On Monday, 14 August 2017 at 01:52:16 UTC, Johnson Jones wrote:
pretty simply, trying to convert a floating point to a string
in a ctfe function and it thinks that it is too complex to do
in a ctfe, really?
It uses a C function to do the conversion, which is not
available at compile time since CTFE can't run extern functions.
And it is a LOT harder to do than you might think which is why
it still uses the C function - implementing one in D is legit
pretty complex.
When I first saw this too, I figured it must be simple to slap
something together, even if it is horribly inefficient and
doesn't work everywhere... and I ended up giving up after
spending a few hours on it too. If you search the web, you get
academic papers describing it, eeek.
Of course, it might be reasonable to port one of the C
implementations directly... but even that is a fairly big job
(and you might as well just call the C function itself for all
but CTFE cases) - the GNU one is 1,300 lines, for example. And
that has an incompatible license with the rest of druntime!
I don't believe that! Just run dmd on it like ctfe does. Maybe
the problem is that to should be a bit more intelligent and if it
is ran at ctfe should try something else.
I don't see why it would be all that difficult maybe for complex
floating point numbers it is but for most ordinary numbers used
as most literals(e.g., terminating decimals), it is very very
easy to convert. It is not much more difficult than storing it as
a string.
After all 0.43425 is actually a string that will be converted to
fp. I realize there are accuracy issues but I seriously think
there should be something suitable rather than crapping out ;/
e.g., 0.43425 = 43425/10.
Remember, we are converting a literal string represented floating
point value to a string. It should be a direct conversion.
Basically a copy and paste. (at run time, it is different,
obviously since the value is actually a fp, but at compile time
it is simply a string.
There is this trick as workaround:
As HypperParrow says, it's easy as pi:
```
auto valueToString(alias v)(){return v.stringof;}
enum a = valueToString!(0.75);
static assert(a == "0.75");
```
to!string(float) should detect that and just do it. No need to
try to do anything complex.
Re: task parallelize dirEntries
On Friday, 11 August 2017 at 21:33:51 UTC, Arun Chandrasekaran
wrote:
I've modified the sample from tour.dlang.org to calculate the
md5 digest of the files in a directory using std.parallelism.
When I run this on a dir with huge number of files, I get:
core.exception.OutOfMemoryError@src/core/exception.d(696):
Memory allocation failed
Since dirEntries returns a range, I thought
std.parallelism.parallel can make use of that without loading
the entire file list into the memory.
What am I doing wrong here? Is there a way to achieve what I'm
expecting?
```
import std.digest.md;
import std.stdio: writeln;
import std.file;
import std.algorithm;
import std.parallelism;
void printUsage()
{
writeln("Loops through a given directory and calculates the
md5 digest of each file encountered.");
writeln("Usage: md ");
}
void safePrint(T...)(T args)
{
synchronized
{
import std.stdio : writeln;
writeln(args);
}
}
void main(string[] args)
{
if (args.length != 2)
return printUsage;
foreach (d; parallel(dirEntries(args[1],
SpanMode.depth).filter!(f => f.isFile), 1))
{
auto md5 = new MD5Digest();
md5.reset();
auto data = cast(const(ubyte)[]) read(d.name);
md5.put(data);
auto hash = md5.finish();
import std.array;
string[] t = split(d.name, '/');
safePrint(toHexString!(LetterCase.lower)(hash), " ",
t[$-1]);
}
}
```
Just a thought, maybe the GC isn't cleaning up quick enough? You
are allocating and md5 digest each iteration.
Possibly, an opitimization is use use a collection of md5 hashes
and reuse them. e.g., pre-allocate 100(you probably only need as
many as the number of parallel loops going) and then attempt to
resuse them. If all are in use, wait for a free one. Might
require some synchronization.
Re: gtkD window centering message up and no app on taskbar
Also, could there be an easier way to import everything that is generally required? I'm using an import script that does the work but I have to replace it upgrade time I upgrade gtkD(since I have to delete everything). I find that having a ton of imports is a big ugly. What I use is, which was basically extracted from some gtkD example: [It also lets use generate json for it a bit easier and use with easier. Probably could be enhanced but just something I through together] module GtkD_All; public import gtk.AboutDialog; public import gtk.AccelGroup; public import gtk.AccelLabel; public import gtk.AccelMap; public import gtk.Accessible; public import gtk.Action; public import gtk.ActionableIF; public import gtk.ActionableT; public import gtk.ActionBar; public import gtk.ActionGroup; public import gtk.ActivatableIF; public import gtk.ActivatableT; public import gtk.Adjustment; public import gtk.Alignment; public import gtk.AppChooserButton; public import gtk.AppChooserDialog; public import gtk.AppChooserIF; public import gtk.AppChooserT; public import gtk.AppChooserWidget; public import gtk.Application; public import gtk.ApplicationWindow; public import gtk.Arrow; public import gtk.ArrowAccessible; public import gtk.AspectFrame; public import gtk.Assistant; public import gtk.Bin; public import gtk.BindingEntry; public import gtk.BindingSet; public import gtk.BooleanCellAccessible; public import gtk.Border; public import gtk.Box; public import gtk.BuildableIF; public import gtk.BuildableT; public import gtk.Builder; public import gtk.Button; public import gtk.ButtonAccessible; public import gtk.ButtonBox; public import gtk.Calendar; public import gtk.CellAccessible; public import gtk.CellAccessibleParentIF; public import gtk.CellAccessibleParentT; public import gtk.CellArea; public import gtk.CellAreaBox; public import gtk.CellAreaClass; public import gtk.CellAreaContext; public import gtk.CellEditable; public import gtk.CellEditableIF; public import gtk.CellEditableT; public import gtk.CellLayoutIF; public import gtk.CellLayoutT; public import gtk.CellRenderer; public import gtk.CellRendererAccel; public import gtk.CellRendererClass; public import gtk.CellRendererCombo; public import gtk.CellRendererPixbuf; public import gtk.CellRendererProgress; public import gtk.CellRendererSpin; public import gtk.CellRendererSpinner; public import gtk.CellRendererText; public import gtk.CellRendererToggle; public import gtk.CellView; public import gtk.CheckButton; public import gtk.CheckMenuItem; public import gtk.CheckMenuItemAccessible; public import gtk.Clipboard; public import gtk.ColorButton; public import gtk.ColorChooserDialog; public import gtk.ColorChooserIF; public import gtk.ColorChooserT; public import gtk.ColorChooserWidget; public import gtk.ColorSelection; public import gtk.ColorSelectionDialog; public import gtk.ComboBox; public import gtk.ComboBoxAccessible; public import gtk.ComboBoxText; public import gtk.Container; public import gtk.ContainerAccessible; public import gtk.ContainerCellAccessible; public import gtk.ContainerClass; public import gtk.CssProvider; public import gtk.CssSection; public import gtk.Dialog; public import gtk.DragAndDrop; public import gtk.DrawingArea; public import gtk.EditableIF; public import gtk.EditableT; public import gtk.Entry; public import gtk.EntryAccessible; public import gtk.EntryBuffer; public import gtk.EntryCompletion; public import gtk.EventBox; public import gtk.EventController; public import gtk.Expander; public import gtk.ExpanderAccessible; public import gtk.FileChooserButton; public import gtk.FileChooserDialog; public import gtk.FileChooserIF; public import gtk.FileChooserNative; public import gtk.FileChooserT; public import gtk.FileChooserWidget; public import gtk.FileFilter; public import gtk.Fixed; public import gtk.FlowBox; public import gtk.FlowBoxAccessible; public import gtk.FlowBoxChild; public import gtk.FlowBoxChildAccessible; public import gtk.FontButton; public import gtk.FontChooserDialog; public import gtk.FontChooserIF; public import gtk.FontChooserT; public import gtk.FontChooserWidget; public import gtk.FontSelection; public import gtk.FontSelectionDialog; public import gtk.Frame; public import gtk.FrameAccessible; public import gtk.Gesture; public import gtk.GestureDrag; public import gtk.GestureLongPress; public import gtk.GestureMultiPress; public import gtk.GesturePan; public import gtk.GestureRotate; public import gtk.GestureSingle; public import gtk.GestureSwipe; public import gtk.GestureZoom; public import gtk.GLArea; public import gtk.Gradient; public import gtk.Grid; public import gtk.HandleBox; public import gtk.HBox; public import gtk.HButtonBox; public import gtk.HeaderBar; public import gtk.HPaned; public import gtk.HScale; public import gtk.HScrollbar; public import gtk.HSeparator; public import gtk.HSV; public import gtk.IconFactory; public import gtk.IconInfo; public import gtk.IconSet; public import
Re: gtkD window centering message up and no app on taskbar
On Wednesday, 9 August 2017 at 15:10:46 UTC, Mike Wey wrote:
On 09-08-17 01:00, Johnson Jones wrote:
But, finally, this does seem to work:
// Fixup missing taskbar icon
void SetTaskBarIcon(gtk.ApplicationWindow window)
{
version(Windows)
version(X86)
{
import core.sys.windows.winuser, gdk.Window;
auto handle =
cast(core.sys.windows.winuser.HANDLE)gdk_win32_window_get_handle(gtk.gtk_widget_get_window(window.getWidgetStruct()));
ShowWindow(handle, SW_HIDE);
//SetParent(handle, null);
SetWindowLong(handle, GWL_EXSTYLE,
GetWindowLong(handle, GWL_EXSTYLE) | WS_EX_APPWINDOW);
ShowWindow(handle, SW_SHOW);
}
return;
}
Of course, along with this:
MainWindow.addOnShow((Widget widget) {
MainWindow.SetTaskBarIcon(); });
`gdk_win32_window_get_handle` I spend way to much time looking
for a function like this, before giving up and doing the
pointer arithmetic.
This should do it for getting the function:
```
import gtkd.Loader;
import gdk.c.functions; //Still at gtkc.gdk for 3.6.
__gshared extern(C) HANDLE function(GdkWindow*)
gdk_win32_window_get_handle;
Linker.link(gdk_win32_window_get_handle,
"gdk_win32_window_get_handle", LIBRARY_GDK);
```
I did find out that gdk set the Desktop window as the parent
window and doesn't set `WS_EX_APPWINDOW` i should try if
setting it for top level windows would fix this from within gdk.
ok, I guess I was still using 3.6 cause I couldn't find anything
about gdk.c.functions and had to import it myself. Upgraded.
Actually, searching the install for gdk.c.functions returns
nothing ;/ Oops, I guess you meant the master on git hub. Could
you add a link on the main gtkD page to the github site?
Anyways, looks like this problem is solved/nearly solved so I'll
move on to the next ;)
Re: Visual D no bp's on x64
On Sunday, 18 June 2017 at 21:02:12 UTC, Rainer Schuetze wrote: On 18.06.2017 20:25, Mike B Johnson wrote: Didn't work ;/ All I get on the output wndow is " C:\Windows\System32\dbghelp.dll unloaded. The thread 0x1ea4 has exited with code -1 (0x). The thread 0x1390 has exited with code -1 (0x). The thread 0x1ac has exited with code -1 (0x). The program '[492] Async.exe' has exited with code -1 (0x). " It seems the debug engine is only attached to the process when it starts terminating. Nothing cut off at the top? Strange. Please try switching to the Visual Studio debug engine on the project debugger configuration page. This still uses mago as the D expression evaluator, but has all the other features of the VS debugger. It's actually the new and preferred way to run the debugger since the last Visual D release, especially with mixed languages. Doesn't work. Nothing is cut off. the x86 version is loading a bunch of symbols so maybe it is just a path issue? Is so then it should print a proper error message for it. I'll try to play around with the paths and see.
Re: D and Meson
On Wednesday, 14 June 2017 at 15:25:55 UTC, Russel Winder wrote: Using Meson for D projects is so wonderful. If SCons is to catch up a lot of work is needed, and I am increasingly worrying it isn't worth it. So much so that I am wondering if adding Dub package getting support to Meson should be a higher priority that finishing adding it to SCons. Of course this is only worth doing if Meson gets "all source at once" builds or all D compilers spontaneously fix all versions so that unit-threaded can work with "file at a time" builds. If the person running the D support for Meson is on this list please contact me privately to tell me what I can do to help progress that support further. Funny: "The main design point of Meson is that every moment a developer spends writing or debugging build definitions is a second wasted. So is every second spent waiting for the build system to actually start compiling code." Which is in direct contradiction to what Walter has said... and yet Walter is suppose to be all about fast cars and hot women.
Re: Visual D no bp's on x64
On Sunday, 18 June 2017 at 17:43:20 UTC, Rainer Schuetze wrote: On 18.06.2017 16:50, Rainer Schuetze wrote: On 18.06.2017 16:17, Mike B Johnson wrote: So, there is some issue with x64 and visual d's debugging in visual studio. That is the only file in the project. If it works on your system, keep trying until it doesn't! As you expected, its not simple to reproduce. I have not managed to do so. Could you specify a few more details: - Visual D version? - VS version? - Which Configuration selected? - dmd version? - ldc version (in case you switched to "LDC Debug")? - selected debug engine? Slightly unrelated, but one thing that often bothers me: if you open the project configuration dialog, VS doesn't always show the current configuration (but the last edited one), so you edit options that don't seem to have any effect. I could produce an issue when starting the mago debugger for the first time after firing up VS2015: it showed an error, though, instead of not doing anything at all. Maybe it's a different effect of the same problem. I have added a work around that fixes it for me: https://ci.appveyor.com/project/rainers/visuald/build/job/5a92e21e7hxgty4b/artifacts BTW: the output window should show whether symbols for your application have been loaded. If not, you get the behavior that you reported. Didn't work ;/ All I get on the output wndow is " C:\Windows\System32\dbghelp.dll unloaded. The thread 0x1ea4 has exited with code -1 (0x). The thread 0x1390 has exited with code -1 (0x). The thread 0x1ac has exited with code -1 (0x). The program '[492] Async.exe' has exited with code -1 (0x). "
Visual D no bp's on x64
in the last 20mins I did the following
1. Create a new DMD/LDC project
2. Added the code
import std.stdio;
import core.sys.windows.windows;
import std.array, std.conv;
int main(string[] argv)
{
wchar* pCmd = cast(wchar*)to!wstring(argv.join(" ")).ptr;
STARTUPINFO si;
//ZeroMemory( , sizeof(si) );
si.cb = si.sizeof;
PROCESS_INFORMATION pi;
//ZeroMemory(, sizeof(pi));
// Start the child process.
BOOL result = CreateProcess
(
NULL, // No module name (use command line)
pCmd, // Command line
NULL, // Process handle not inheritable
NULL, // Thread handle not inheritable
FALSE, // Set bInheritHandles to FALSE
DETACHED_PROCESS, // Detach process
NULL, // Use parent's environment block
NULL, // Use parent's starting directory
, // Pointer to STARTUPINFO structure
// Pointer to PROCESS_INFORMATION structure (returned)
);
if (result) return 0;
wchar[2048] msg;
FormatMessage
(
FORMAT_MESSAGE_FROM_SYSTEM,
null,
GetLastError(),
cast(uint)MAKELANGID(LANG_NEUTRAL, SUBLANG_SYS_DEFAULT),
msg.ptr, cast(uint)2048,
null
);
writeln(msg[0..lstrlen(msg.ptr)]);
return -1;
}
3. Modified the command args in the options. Added cmd /c echo
hello
4. Then went to debug it by putting a bp on the first line so I
could check and ran it. Guess what? The program opened and
closed. I've ran in to this problem before.
5. I added a bunch of bp's thinking it was just a problem with
the first one(as that is how I get around it before).
6. Ran the program. Same thing. Ran the program. Same thing. I
noticed that the bp's were turning white the split second the
program was active.
hmmm... I then noticed the program was being built for x64.
7. I then changed it to x86 and voilà!
So, there is some issue with x64 and visual d's debugging in
visual studio. That is the only file in the project. If it works
on your system, keep trying until it doesn't!
Re: Replacing Make for the DMD build
On Saturday, 17 June 2017 at 19:20:54 UTC, Walter Bright wrote: On 6/15/2017 11:30 PM, Russel Winder via Digitalmars-d wrote: A direct question to Walter and Andrei really. If someone, let us say Russel Winder, create a CMake/Ninja and/or Meson/Ninja build for DMD, is there any chance of it being allowed to replace the Make system? If the answer is no, then Russel will obviously not waste his time doing something that will not be accepted. It's highly unlikely it would be accepted: 1. make is ubiquitous. It's not something we have to scrounge to find on platform X, it's already there. People already are familiar with it (even if they hate it). 2. we're in the D business, not the project build business. It's easier to get past that "first 5 minutes" if everything about D other than D itself is familiar and conventional. 3. to steal from Churchill, `make` is the worst form of build system except for all the others 4. much as I dislike make, the time spent wrestling with it is a vanishingly tiny slice of time compared to what spent on the rest of D. Getting that time slice to zero will have no effect on productivity, and I'm not convinced that a newer build system will even reduce that time slice at all (see point 5). 5. D has a more complex build process than it should. Using another build system won't make that complexity go away. 6. unlike the choice to use github, there is no clear winner in the `make` category of build tools. If the industry has moved on from make to X, then we should, too. But it has not. 7. the current makefiles for DMD suffer from over-engineering, i.e. making simple things complicated and excessively using obscure features of make. This isn't really the fault of make. These reasons are terrible. 1. So! Just because something is "universal" doesn't mean it is good. Look at any major religion. Usually those that believe in it tend to use as proof that there are so many other believers. 2. If you are in the D business you are in the make business. 3. Which, you are saying the exact same as make is the best. Yet, those others are just make clones that are not any worse(as they make it better). It is a contradictory argument. 4. You are not taking in to account everyone elses time. Sure, you might only save a penny, but if 7B people saved a penny, that would be 70 million dollars. That is not an insignificant amount. 5. It might, how do you know, have you tried? 6. This is not logical, they haven't moved precisely because they are thinking like you are. "If X hasn't moved from Y then why should we" everyone exclaims. 7. Then come up with something better instead of making excuses... which is what it all boils down to. You could have simply said, in a more logical way: "I do not want to spent the time to create/switch to something new and better because it is not worth it to me"... as that is all you have said(obfuscating in to a 7 point bullet list of meaningless il-arguments doesn't change that). My suggestion is, that, if someone else wants to "waste" their time creating something that is new and better then they should be "allowed" and "supported" in doing so with the only caveat that they must prove, at the end of the day, that it is better. If it is not, then they "wasted" their time. If it is, then everyone is happier and more productive. The question is, are we fighting over pennies or millions?
Re: D needs to get its shit together!
On Saturday, 17 June 2017 at 15:01:34 UTC, Mike Parker wrote: On Saturday, 17 June 2017 at 14:01:38 UTC, Mike B Johnson wrote: You realize your mentality is like a dead rat? It just stinks. Your solutions are not solutions. They are patches. I wouldn't hire you to fix my plumbing because in a few months I'll have to fix it again. You are ok with that, because you get paid either way. Keep kicking the can down the road... It may get you a bit of exercise but in the long run you are just wasting everyone's time. I also suggest you get out of the 1970's. Software and computers have come a long way. We shouldn't have to resort to the same mind set 40+ years ago. I shouldn't have to backup sc.ini, just because you think it is the way doesn't mean it is. That mindset for sc.ini pervades all your so called solutions. There are better ways, too bad you don't care or are too ignorant to see them. That's fine. One more piece of advice I have for you. If you want anyone to take you seriously, check the attitude at the gate. Good luck! Cool. Since we are friends now, I have some advice for you: I suggest that if you want anyone to take you seriously, I suggest you check your mediocrity mentality at the door. See how that works?!?! Probably not. I suggest you get with the program and stop assuming it's ok to waste peoples time, including your own. The world would be a better place if people like you stopped playing your little games and grow up. Then people like me wouldn't have to constantly put you in your place.
Re: D needs to get its shit together!
On Saturday, 17 June 2017 at 13:23:06 UTC, Mike Parker wrote: On Saturday, 17 June 2017 at 06:06:53 UTC, Mike B Johnson wrote: [...] This isn't as severe as you make it sound. If the latest version of VS doesn't work, the one before will. It's easy to prevent such issues in the future. Since we never know if a new version of VS will break things, this can be solved by one person who can monitor the beta releases of VS and submit PRs to the appropriate repositories if the paths change, or (as happened with VS 2015) the C runtime library changes, or some other breakage arises. Then DMD can get support for the new version before it's released. Could that person be you? [...] What I've done in the past is to keep the latest DMD on the system path, then set up Command Prompt shortcuts initialized with a different batch file to set override it with paths to different compilers/versions. If DVM could get support for LDC and GDC, then you'd have everything in one convenient app. [...] Backup the sc.ini file. [...] Like what? [...] So, what are you proposing here? Educate us. What are we supposed to take into account? I use my computer also for graphics, music, programming, document editing, all sorts of stuff. The only breakage I've ever had has usually been related to anti-virus software, though in the past there was an occasional issue with things like SecuRom. What exactly should the D community to in order to alleviate these major breakages you have on your system? [...] I would like to reiterate here what I mentioned earlier in this thread -- people in the D community are currently fixing flaws all the time. That we aren't fixing the flaws that particularly peeve you does not mean nothing is being done. I would also like to reiterate that if something is important enough to you, then you could do something about it besides coming to the forums and calling the rest of us ignorant. Write a DIP. File issues on Bugzilla. Submit pull requests. Take on responsibility for ensuring Visual Studio compatibility. Or do nothing, but please don't act as if we're all just sitting here twiddling our thumbs. You realize your mentality is like a dead rat? It just stinks. Your solutions are not solutions. They are patches. I wouldn't hire you to fix my plumbing because in a few months I'll have to fix it again. You are ok with that, because you get paid either way. Keep kicking the can down the road... It may get you a bit of exercise but in the long run you are just wasting everyone's time. I also suggest you get out of the 1970's. Software and computers have come a long way. We shouldn't have to resort to the same mind set 40+ years ago. I shouldn't have to backup sc.ini, just because you think it is the way doesn't mean it is. That mindset for sc.ini pervades all your so called solutions. There are better ways, too bad you don't care or are too ignorant to see them.
Re: D needs to get its shit together!
On Saturday, 17 June 2017 at 08:27:33 UTC, Sebastien Alaiwan wrote: On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: When a new user goes to start using D for the first time, D is a PITA to get working! Don't believe me?!?! I'm running Debian GNU/Linux (testing). Here's the installation process for the 3 major D compilers. $ apt install gdc $ gdc my_first_program.d GDC is too old for you? Fine, let's use ldc: $ apt install ldc $ ldc2 my_first_program.d Or if you want the bleeding edge version of D: (download dmd .deb package from dlang.org) $ dpkg -i dmd_***.deb $ rdmd my_first_program.d Debian maintainers, one word: Thank you! Sorry, doesn't help me or people in general. Also, simple examples are not proof that the solutions are general. It may be that easy on linux or it may not be, but it's definitely not that case on windows FOR almost ALL installations.
Official D Contributors
It would be nice to see all the hard workers who have helped D become what has become and are helping it become what it will be get noticed for there hard work(effectively they have given money to the D foundation through their time). Is this being done? I think the regulars that have been around should get noticed and supported for their support. The D foundation should try to repay them at some point if possible(in the near or distant future)... but having official recognition is the start. As far as I can tell, the core D team(which is basically Walter and Andrei?), while appreciating the time and money others have put in, kinda take it for granted, so to speak. It isn't about stroking peoples ego's, but about compensating them for their somewhat selfless dedication. After all, it was a choice they made, and they sacrificed their time, money, family time, livelihood, etc to support one persons project or vision without any desires to be compensated. While the money may not be there, it's not much work to make something official. I am not proposing awards or any gimmicks like that but something more from the heart.
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 17:10:41 UTC, Jacob Carlborg wrote: On 2017-06-16 09:53, Mike B Johnson wrote: DVM [1] is doing some of this. Cool, does it keep things well organized It depends on what you definition of organized. DVM is a tool that allows you to easily install D compilers. It also allows to easily switch between multiple versions of the compiler. That is, you can have one window (terminal) with one version and another window with another version. On Posix it installs everything ~/.dvm. Each compiler is placed in its own directory, it's mostly the zip archives available on dlang.org unpacked. Here's an example of how the directory structure looks like on Posix: $ tree -L 2 .dvm .dvm ├── archives │ ├── dmd.2.073.0.osx.zip │ ├── dmd.2.074.0-b1.osx.zip │ └── dmd.2.074.0.osx.zip ├── bin │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 │ ├── dvm │ ├── dvm-current-dc │ ├── dvm-default-dc ├── compilers │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 ├── env │ ├── default │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 └── scripts └── dvm and deals with windows issues(link.exe., dlls, etc) or just uses the "D way" which is a hairball? I'm not that familiar with Windows (the Windows support was contributed by another developer) so I'm not sure which issues you refer to. Thanks. At least D has something going on correctly here. My feeling is, unless DVM works well with windows, that it probably currently doesn't offer much help. If it does manage the versioning well and can deal with the environmental issues well then it is close to what I am asking. If that's the case, it should be polished off and used as the main front end and hosted by D. You didn't state if it works congruently with all the major compilers. The issues in windows are: 1. coff/omf. Requires use of windows and visual studio/C stuff who's locations and versions change over the years. This can be a major headache finding the right version. Mainly because the error messages, when using the wrong version, do not suggest that it is a versioning error. dvm could have the option to search the entire system for the files it needs(e.g., link.exe, various dlls that are generally used, etc) and attempt get things to work. 2. Managing different compilers: Not too bad but if you end up with some problems here, then it gets multiplied by the factor of the number of issues with each compiler. if LDC has an issue with the x64 dlls and dmd with the x32 and they are always looking in the same place because the versions are different and wrong, then it becomes a issue with a "factor of 4" problem. This can become even worse when you try cross compiling and such. 3. Re-installation can be problematic. sci.ini is overwritten. If you hand coded the paths to get everything to work, guess what? Well, who cares? You have plenty of time to waste, right? 4. Reinstalling one thing can break something else. This depends on how fragile the setup was at the start. 5. People that don't have problems with their setup generally think everything "just works" and bitch at others for complaining. Ignorance is bliss, but it's still ignorance. Life is more complicated and everything just doesn't work for everyone because everyone system is different. I don't use standard paths to install things and when an installer hard codes paths that don't exist, it breaks on my system. That is not my fault. The installer shouldn't be so ignorant and do it's job properly. Usually it was written by someone who thinks that when other people have problems on their system, it is due to their ignorance rather than the ignorance of the installer writer(Because they think: Hey, it worked on my system and my system is the same as everyone elses). Same goes for utilities. I have over 1 billion files on my system, I use it for around 20 different non-complementary subjects(graphics, music, programming, etc). When everything is "competing for space" and things are not set up to work together, one seemingly unrelated program and effect every other one. (e.g., simply by adding to the path variable and break things with error messages that are meaningless to the real problem) Most ignorant people do not take those things in to account because they oversimplify... and that usually causes problems down the road for the rest of us. As D becomes increasing popular, there are going to be more variation in the system and the flaws in it will become larger and larger. It's best to start working on fixing those flaws before they become too large to manage and weaken the whole structure. We all know this to be true on some level, but it is actually fact. It is the way of life, everything breaks down. The more flaws it has at the start, the faster it will break down... unless they are fixed at the start. Fixing them near the end just results in a
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: D needs to get its shit together!
DVM [1] is doing some of this. Cool, does it keep things well organized and deals with windows issues(link.exe., dlls, etc) or just uses the "D way" which is a hairball?
D needs to get its shit together!
Seriously! D is starting to gain momentum and if things are not stabilized it's going to slow D down. 1 ==>> The VERY FIRST order of business is very simple: When a new user goes to start using D for the first time, D is a PITA to get working! Don't believe me?!?! Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324". And guess what? This happens to regular users too! They either. A) know how to fix them from fixing them in the past or helping others(so it doesn't count because the problem still exists) or B) have a specific setup that happens to avoid the major issues(e.g., just use linux x86) then act like there isn't any problems with D. But no one wants to work on the part of D that deals with these problems cause it's boring and most "experts" can deal with the problems in a few mins to a few hours... doesn't seem like a huge waste of time(even though it is, since it's a waste). D needs to just work! Library errors, setup problems, IDE integration should just work! It seems the changes of it working are about 75-85%... that IS LOW! It should be 99%. (And I'm talking across the board) DMD, LDC, GDC, Visual D, Coedit(or whatever the other main IDE's are), the utilities(Dustmite, DFormat, etc) should all just work seamlessly and without hassle with each other. What is the main problem? It's very simple: The way the paths are stored and retrieved is ancient and prone to bugs and it seems there is no clear cut way on how to get everything to find everything else. Also, versioning is not always there so even if the paths are right, the files in them may not be! Multiple versions should be able to exist side by side(since D is ever changing and sometimes new versions simply don't work like they should, then downgrading starts causing problems). Solution Ideas: This is a simple problem that needs to be fixed. The installer needs to be updated to act as more of a package manager(a graphical one for us on windows) that has versioning checks and such in it. It doesn't have to be fancy, but should do a bit more work than the current on which is basically more trouble then just compressing the zip and editing sc.ini by hand. 1. A unified path/directory layout that is unambiguous and every D app can rely on. e.g., \Dlang\Compilers\DMD\v2\73.01 (the v2 stuff hence forth replaced with \Dlang\Compilers\DMD\v2\main <- a junction/link to the current version, usually the latest \Dlang\Compilers\DMD\Lib\Phobos\x86\coff\ \Dlang\Compilers\DMD\Lib\Phobos\x86\omf\ \Dlang\Compilers\DMD\Lib\Phobos\x64\coff \Dlang\Compilers\DMD\Lib\Phobos\x64\omf (even though it doesn't exist, just empty, maybe a text file in it stating that it is not used for x64) \DLang\Source\DMD\v... \DLang\Docs\v... \DLang\IDEs\VisualD\v... \DLang\Utilities\DFormat\v... \DLang\Utilities\DustMite\v... \DLang\Packages\Derelict\v... and so fourth. I'm not saying it has to be exactly like the one above, but the above is unambiguous. One could change compiler versions, even have a "master" compiler that simply chooses dmd, ldc, gdc, etc and could verify versions if necessary, etc. Everything gets organized and has a place that is logical and hence easy to find, easy to use, and helps in diagnosing problems. Versioning and dependencies could be charted. (e.g., a change in one version of something doesn't necessarily break it's usage with everything else that hasn't been updated, so we can have a table of things that work with each other based on versions. We can change, say, the version of DMD to use and the front end can consult the master version table to see what utilities that work with it and then update all the hard links. External usages(like windows dlls, link.exe) are all handled. They are a) copied from their windows locations. b) noted the location they are copied from by adding a text file in the directory, etc) (and the installer\manager can refresh everything) One can install on demand any aspect so everything isn't created at once. As time evolves, this system of organization gets cleaner, clearer, and more optimal rather than the current system which seems to just be stagnant and relatively broke. It works, for the most part, but as time goes on it doesn't get any better at it's job. It's usually the same problems over and over and that is why you always get a steady stream of users having issues with D due to problems that are easily fixable with a little elbow grease and thought and a significant amount of desire to get the problem fixed[breath!]. Versioning gets better and better. If D1 had this type of system, we could
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: Isn't it about time for D3?
On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote: Mike B Johnson wrote: Yeah, sounds good, because to make progress, progress has to be made. Most people are very shortsighted and live in a fear based mentality. Mention any type of change and they nearly shit themselves and never actually think about the consequence of those changes. They just assume it means change and it's something they can't handle. Having an "experimental" D allows those crazy and potentially "mind altering" advancements to be worked on, advanced, and polished. It takes time for ideas to grow(because, ultimately, it involves learning and learning takes time). yeah. this is exactly the mentality i want to fight with. in my opition, having such forum "officially blessed" will encourage people to experiment. or at least i hope so. ;-) It's an uphill battle. You are fighting human nature/evolution/ignorance ;/ The good news is that humans are good at mountain climbing when they want to be.
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:
Adam D. Ruppe wrote:
On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
Dev resources are stretched thin as it is, I doubt the core
team would go for it.
I think dev resources are thin because of mismanagement by the
core team failing to attract and retain contributors. Part of
this mismanagement is a really discouraging attitude toward
positive yet breaking change; I propose that mere willingness
to shake up the status quo would help to solve the resource
shortage.
actually, some time ago i proposed to create "experimental and
breaking language changes" subforum, where people can go with
their wild ideas, and other people can post patches/builds with
those (or other) ideas imlemented/half-implemented.
this way we can gather some feedback from someone who is really
using new feature, and have a better vision if it worth further
time investments or not. 'cause having a live compiler with new
feature to play with is not the same as simply dicussing the
possible feature in NG. i maintain my private fork of
dmd/druntime/phobos, and this is the way i evaluate features:
just add what i can, and then see if i'll start using it in my
code. if not, the feature is cutted, otherwise it is retained.
and ah, building dmd from sources is not something many people
want/can to do. sure, downloading binaries from random people
over the net is not the safest thing to do, but if there will
be patch+binary combos, it may work.
i.e. i see that "experimental" subforum as a place for ideas
*and* implementations. and implementors can provide built
binaries for people to play, or other people can build binaries
('cause if you built it for yourself, why don't share it with
others?).
i know that this forum is actually a newsgroup, and it can't
host files. but i believe that this problem can be solved --
either by using some simple js-free (for download; yeah, there
are such things! ;-) service to host binaries, or by some other
means.
Yeah, sounds good, because to make progress, progress has to be
made. Most people are very shortsighted and live in a fear based
mentality. Mention any type of change and they nearly shit
themselves and never actually think about the consequence of
those changes. They just assume it means change and it's
something they can't handle.
Having an "experimental" D allows those crazy and potentially
"mind altering" advancements to be worked on, advanced, and
polished. It takes time for ideas to grow(because, ultimately, it
involves learning and learning takes time).
So, the good experimental changes will eventually be adopted.
Without such a mechanism, they can't EVER be. The problem is that
only the core people of D actually get to decide what is good and
they tend to push through changes that haven't been well
tested(regardless of what they think, D is a prime example by all
the miscalculations as is C).
Most people fear growth because growth requires change and change
ventures in to the unknown... The unknown is where all the good
shit lies and the breakthrough is when someone brings the unknown
in to the known.
Re: tanya 0.6.0, new containers
On Friday, 9 June 2017 at 18:54:12 UTC, Eugene Wissner wrote: Dear community, there is a new release of my gc-free library, tanya. I don't announce each release, so I want to tell short about the latest development and plans for the next releases. [...] Thanks! I'll check it out.. we need this sort of stuff for D. Do you have any plans for a circular/ring buffer?
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: better string
On Thursday, 8 June 2017 at 00:59:06 UTC, Stanislav Blinov wrote: On Wednesday, 7 June 2017 at 23:57:44 UTC, Mike B Johnson wrote: Or will simply setting "alias string = wstring;" at the top of my program end up having the entire program, regardless of what it is, use wstring's instead of strings? It doesn't work that way and it can't work that way: you'd never be able to link against anything if it did. Not true, way to overgeneralize! The reason I say this is because I converted my program to use wstrings... Why? Why trade one variable-width encoding for another, especially a nasty one like UTF-16? um, because I'm god and I get to wear the big boy pants.
Re: better string
On Wednesday, 7 June 2017 at 21:32:25 UTC, ag0aep6g wrote: On 06/07/2017 12:58 PM, Mike B Johnson wrote: Why not alias string so that one can easily switch from the old string or wstring, etc? e.g., rename string internally to sstring or whatever. then globally define alias string = sstring; Which can be over realiased to wstring to affect the whole program alias string = wstring; Or use a command line to set it or whatever makes you happy. I'm not sure what exactly you're asking for, but `string` is an alias already (of `immutable(char)[]`). And you can define your own `string` as you like. `alias string = wstring;` works. But that isn't program/compiler wide. e.g., stringof won't return a wstring if you do the alias, will it? Or will simply setting "alias string = wstring;" at the top of my program end up having the entire program, regardless of what it is, use wstring's instead of strings? e.g., when I do a string literal "This is a string" but do your alias, is the literal a string or wstring? The reason I say this is because I converted my program to use wstrings but I got many errors because of string literals being interpreted as strings and no automatic conversion took place, I had to append w to turn then in to wstrings.
Re: better string
On Wednesday, 7 June 2017 at 10:58:06 UTC, Mike B Johnson wrote: Why not alias string so that one can easily switch from the old string or wstring, etc? e.g., rename string internally to sstring or whatever. then globally define alias string = sstring; Which can be over realiased to wstring to affect the whole program alias string = wstring; Or use a command line to set it or whatever makes you happy. I'm in the progress of converting a large source code database to use the above technique so we can move to using wstring... it is not fun. Most code that works with a string should with any string encoding, so it shouldn't matter. Making D string agnostic(after all, the only main different in 99% of programs is the space they take up). If you are worried about it causing subtle bugs, then don't... because those same bugs would occur if one manually had to switch. By designing techniques to use strings that are agnostic of there internal representation should save a lot of headache. For those few cases that it matters, simple static analysis works fine. I should mention, that with such a design, strings can default to the string type, whatever it would be. e.g., "this is a string" depends on the "alias". If it is sstring then it is an sstring, if it is wstring then it is a wstring. Anything that returns a string will return it depend on the alias, even templated functions such as foreach(name; AliasSeq!(X.tupleof.stringof)) in which, generally makes name a sstring. (I suppose due to stringof returning an sstring regardless).
better string
Why not alias string so that one can easily switch from the old string or wstring, etc? e.g., rename string internally to sstring or whatever. then globally define alias string = sstring; Which can be over realiased to wstring to affect the whole program alias string = wstring; Or use a command line to set it or whatever makes you happy. I'm in the progress of converting a large source code database to use the above technique so we can move to using wstring... it is not fun. Most code that works with a string should with any string encoding, so it shouldn't matter. Making D string agnostic(after all, the only main different in 99% of programs is the space they take up). If you are worried about it causing subtle bugs, then don't... because those same bugs would occur if one manually had to switch. By designing techniques to use strings that are agnostic of there internal representation should save a lot of headache. For those few cases that it matters, simple static analysis works fine.
Why does phobos have collisions?
Error: template std.algorithm.mutation.strip cannot deduce function from argument types !()(string), candidates are: src\phobos\std\algorithm\mutation.d(2280): std.algorithm.mutation.strip(Range, E)(Range range, E element) if (isBidirectionalRange!Range && is(typeof(range.front == element) : bool)) \src\phobos\std\algorithm\mutation.d(2287): std.algorithm.mutation.strip(alias pred, Range)(Range range) if (isBidirectionalRange!Range && is(typeof(pred(range.back)) : bool)) This is on a line of code that simply strips away a string... and works fine when using standard strip(without importing std.algorithm)... but when importing std.algorithm too, those errors pop up... seems like a defect.
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?
Re: DIP66 - Multiple alias this
On Friday, 10 October 2014 at 17:09:08 UTC, IgorStepanov wrote: I've created DIP for my pull request. DIP: http://wiki.dlang.org/DIP66 PR: https://github.com/D-Programming-Language/dmd/pull/3998 Please, comment it. Well, nearly 3 years later and nothing!
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: Typecasting delegates
On Friday, 2 June 2017 at 21:42:57 UTC, Moritz Maxeiner wrote: On Friday, 2 June 2017 at 21:14:29 UTC, Seiji Emery wrote: [...] assume that they're implemented as a pair of pointers; Ah, and uh... one last thing. What's the worst that could happen from calling a `ref Foo` signature through a void* pointer? Undefined behaviour. His computer could expode! Or it could trigger a black hole near Alpha Centauri... You never know!
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: Phobos 2
On Thursday, 1 June 2017 at 20:58:52 UTC, H. S. Teoh wrote:
On Thu, Jun 01, 2017 at 06:40:05PM +, Brad Anderson via
Digitalmars-d wrote:
A (surely controversial) idea popped into my head while
talking in #d on Freenode. The C++ guys are making an STL2
(the highlight of it being that it is range based). What about
taking all the lessons learned from Phobos and creating a
Phobos 2? It wouldn't replace the current version. You could
import either in one program. It also wouldn't be a radical
redesign. Most of Phobos could be used as is. What it would do
is allow fixing some hard or impossible problems without
losing backward compatibility.
+1. I'm for this. There's just too much code in the existing
Phobos that certain (wrong, in hindsight) design decisions are
essentially impossible to fix.
We could do away with auto-decoding.
+1000. ;-)
Design it around using Andrei's allocators throughout. Make
the GC optional from the start.
+1.
Fix a few important naming conflicts and discrepancies.
As well as certain less-than-ideal names that we were forced to
use because the good names have been taken up by not-so-nice
implementations dating from before we had the hindsight to know
what the best design was.
There are problems, of course. Rampant code duplication is
probably the biggest (though maybe public imports of identical
code would help a lot).
I don't really expect this to go anywhere but I am curious to
hear what changes you'd all like to see made to Phobos that
can't happen because of backward compatibility.
1) A big one, not necessarily caused by backward compatibility
but more by the sheer amount of code that would need to be
fixed / rewritten, is the nasty hairball of a dependency graph
among the current Phobos modules.
One particularly egregious example is std.format. Due to the
way it was originally implemented, it depended on a lot of
other code (IIRC including std.bigint), so even if all you ever
did was writefln("%d"), for example, your program would end up
depending on std.bigint, std.complex, and all sorts of other
stuff that never actually gets used. This in itself is not
necessarily *that* bad, but what really makes it hurt is that
many other modules depend on std.format. So you could be
importing a seemingly completely-unrelated module, and it would
pull in std.format, which in turn pulls in other stuff, and by
the end you've basically imported about half of Phobos, with
the associated executable bloat, even though you really only
needed to call 1 function.
And the icing on the cake is that some of these complicated
dependencies are circular, which every now and then cause
mysterious linker errors and/or surprising dependence on
declaration order, that mysteriously vanish when you move
seemingly-unrelated code around.
If we were to go the route of Phobos2, I'd like the principle
of pay-as-you-go to be baked into its design from the very
beginning. If all you need is to format an int, it shouldn't
also pull in std.complex and std.bigint. This can be done by
compile-time format strings (which we now have, though it's
currently just a frontend to the existing hairball code). If
function X and function Y are essentially independent of each
other, they really ought to go into their own (sub)modules, now
that we have package.d support in the compiler.
Of course, certain things like std.range.primitives and
std.allocator will be depended on by 90% of the other modules,
which is unavoidable, but which also means that we need to
think VERY carefully about what we put into these foundational
modules. If at all possible they should not depend on anything
else.
2) A lesser item, perhaps would be to change the definitions of
input / forward ranges, so that forward ranges are just
by-value ranges, and input ranges are by-reference ranges,
instead of forward ranges needing explicit calling of .save to
save the iteration state. See:
http://lists.cubik.org/pipermail/digitalmars-d/2015-November/241712.html
3) An even lesser item, but now that we have a chance: clean up
the mess
that is the current isSomeString, isNarrowString, etc.. Well,
some of
them will be useless since we wouldn't have autodecoding, but
still, we
need to sit down and properly design these traits so that they
are (1)
useful, (2) orthogonal, and (3) have sensible names.
Also, how would you approach doing this? An on disk copy of
Phobos with changes would not be an acceptable approach, I
think.
I'd say, start in a different namespace than std, so that the
two can coexist until Phobos2 is ready to take over prime time.
(And even then, Phobos1 should probably stick around for a
while until people have migrated over.) This new namespace can
either be completely outside std, like std2 (bad name, I know),
or it can be a dedicated sub-namespace, like std.new.
Preferably it should be something unique and easily greppable,
so that
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: Any video editing folks n da house?
On Saturday, 27 May 2017 at 22:28:13 UTC, Nick Sabalausky (Abscissa) wrote: On 05/27/2017 06:19 PM, Era Scarecrow wrote: On Wednesday, 24 May 2017 at 10:04:03 UTC, Wulfklaue wrote: Working on a compressed video to create another compressed video, simply result in lower quality video ( and less professional looking ). Only if you have to recompress it. Some tools like VirutalDub allow you to chop and copy without altering the data stream Good point. Although, AIUI, that does leave you limited to cutting only on full frames, not on the delta frames. Sometimes that's an issue, sometimes it isn't. Right, that's why we need 60kfps so these types of issues do not cause major life threatening problems.
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.
Re: Weak Eco System?
On Wednesday, 17 May 2017 at 08:19:43 UTC, Benro wrote: On Tuesday, 16 May 2017 at 23:17:10 UTC, Mike B Johnson wrote: Grow up! ! is not yelling. It makes no sound, has no meaning, and only exists to insert in to tight anuses that have no life. Thank you for your helpful comment. I wonder if the inability for D community to grow is not more related to the fairly noticeable arrogant attitude of its members. You should ask yourself that question, seriously. You started with your condescending ego based remark about how ! is yelling, when it is not! THIS IS YELLING Which, in fact, it is not because no sound was made. But because of your need to be treated as an authority you pretend to know something and then run around trying to enforce some imaginary law that you have self appointed yourself the judge, jury, and executioner. Then, because you think you are intelligent you try to pretend further to hold some imaginary high ground because you are born from the loins of Jesus himself and the rest of us heathens are too stupid to get it. My suggestion, go back to acting school. Whatever you are doing isn't working.
Re: Weak Eco System?
On Tuesday, 16 May 2017 at 21:08:34 UTC, Benro wrote: On Tuesday, 16 May 2017 at 17:14:49 UTC, Basile B. wrote: For example the build.bat fix could have been made and merged in 10 min. if you would have took the time to report it! First of all. ! is not appreciated. This is considered yelling. Grow up! ! is not yelling. It makes no sound, has no meaning, and only exists to insert in to tight anuses that have no life.
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: D is really cool
On Friday, 12 May 2017 at 22:05:54 UTC, Faux Amis wrote: On 2017-05-10 07:24, nkm1 wrote: So I spent last week (or so) learning D, and it's a great language. Initially I was apprehensive about GC (non generational, conservative...), but now I realize that I can use D as an improved C (combining malloc and GC :). I always liked C better than C++ anyway. I know that every bloody n00b here says something about GC :), so now it's my turn. I do hope that non-GC experience will get better in the future. D is cool, though. So, just saying. Somehow totally missed your message, welcome! After reading all the GC comments on reddit: https://www.reddit.com/r/programming/comments/6as1di/serialization_in_d/ I wish more people could just try it out and experience why the D GC is a handy thing to have on hand. For who? It is a nightmare(ok, not that bad) for some.
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
//
Re: [OT] Algorithm question
On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote: I'm been thinking about the following problem, and thought I'd pick the brains of the bright people around these parts... [...] Since most real world problems would require selecting elements more than once it may be far more efficient to sort by P(x)(filter) then simply select a random element. e.g., a = A.filter(x->P(x)) // Creates a new set a where only the elements of A that satisfy P(x) are added ... e = a.random; this is O(1) if you only have to filter once(you can create a container that always "sorts" on P(x) so to speak.. like a sorted dictionary).
