Symbols missing, unmangle!
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.
D Multidimensional arrays wierdness
I need to get this straight: A normal single dimensional array in D is defined as T[] arr and is a linear sequential memory array of T's with an unbound length and is effectively the same as T*(although D treats them differently?)? We can fix the length by adding a upper bound: T[N] arr; and this is equivalent to auto arr = cast(T[])malloc(T.sizeof*N)[0..N]; possibly auto arr = cast(T[N])malloc(T.sizeof*N); But then arr is a fixed type and we can't use to resize the array later if needed. these don't actually work, for some odd reason, so auto arr = cast(T*)malloc(T.sizeof*N)[0..N]; seems to be the way to go. So, what this "shows" is that in memory, we have relative address type 0 T 1*sizeof(T)T 2*sizeof(T)T ... N-1*sizeof(T) T This is pretty basic and just standard arrays, all that is fine and dandy! Now, when it comes to multidimensional arrays: T[][] arr; There are two ways that the array can be laid out depending on how we interpret the order of the row/col or col/row. The most natural way to do this is to extend single dimensional arrays: T[][] is defined to be (T[])[] or, lets used a fixed array so we can be clear; T[N][M] which means we have M sequential chunks of memory where each chunk is a T[N] array. This is the natural way because it coincides with single arrays. Similary, to access the element at the nth element in the mth chunk, we do t[n][m] because, again, this conforms with out we think of single arrays. Now, in fact, it doesn't matter too much if we call a row a column and a column a row(possibly performance, but as far as dealing with them, as long as we are consistent, everything will work). BUT! D seems to do something very unique, If one defines an array like T[N][M] one must access the element as t[m][n]! The accessors are backwards! This is a huge problem! int[3][5] a; Lets access the last element: auto x = a[4][2]; auto y = a[2][4]; <- the logical way, which is invalid in D This method creates confusion and can be buggy. If our array is not fixed, and we use the *correct* way, then our bugs are at runtime and maybe subtle. Why? Because the correct way only has one thing to get right, which is being consistent, which is easy. In D, we not only have to be consistent, we also have to make sure to reverse our array accessors from how we defined it. While it is a unique approach and may have something to do with quantum entanglement, I'm curious who the heck came up with the logic and if there is actually any valid reason? Or are we stuck in one of those "Can't change it because it will break the universe" black holes?
Re: C callbacks getting a value of 0! Bug in D?
On Tuesday, 29 August 2017 at 01:56:43 UTC, Moritz Maxeiner wrote: On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote: [...] produces 4 on both x86 and x64. So, I'm not sure how you are getting 8. There are different 64bit data models [1] and it seems your platform uses LLP64, which uses 32bit longs. Am I correct in assuming you're on Windows (as they are the only major modern platform that I'm aware of that made this choice)? [1] https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models Yes. I found this, which gives a map for all the types: https://dlang.org/spec/interfaceToC.html Seems only long and ulong are issues.
Re: C callbacks getting a value of 0! Bug in D?
On Tuesday, 29 August 2017 at 00:42:45 UTC, Steven Schveighoffer
wrote:
On 8/28/17 7:47 PM, Johnson Jones wrote:
[...]
Then I think possibly the port audio bindings are not correct.
It's also possible that long is not 64-bit even on the platform
you are using. Finally, it's also possible that the D compiler
is not generating the call correctly.
When I test on my mac, c_long is 8-bytes. I'm not sure what it
is in your case, try this code and see what happens:
import core.stdc.config;
pragma(msg, c_long.sizeof); // prints 8 on my box.
And in c:
#include
int main()
{
printf("%lu\n", sizeof(long)); // also prints 8 on my box
return 0;
}
They should match. If they don't, that's a D bug (in either
core.stdc.config or the compiler, I'm not sure which). If they
do, then one of the other two possibilities is happening, and I
would lean towards the bindings being incorrect.
-Steve
import core.stdc.config;
pragma(msg, c_long.sizeof);
prints 4UL
both on x64 and x86
and and C:
void foo()
{
int dummy;
switch (dummy) {
case sizeof(long) :
case sizeof(long) :
break;
}
}
produces 4 on both x86 and x64. So, I'm not sure how you are
getting 8.
Re: C callbacks getting a value of 0! Bug in D?
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer wrote: On 8/27/17 10:17 PM, Johnson Jones wrote: Looking at the assembly shows something like this: 0041ea98 push 0x0 0041ea9a push 0x0 0041ea9c push 0x0 0041ea9e push dword 0x100 0041eaa3 mov ecx, [typeid(PaStreamParameters)+0xe36fc (0x80d4cc)] 0041eaa9 mov eax, [fs:0x2c] 0041eaaf mov edx, [eax+ecx*4] 0041eab2 push dword [edx+0x1c] 0041eab8 push dword [edx+0x18] 0041eabe push dword [ebp-0x54] 0041eac1 push dword [ebp-0x5c] 0041eac4 mov ebx, PA.stream (0x823f30) 0041eac9 push ebx 0041eaca call dword near [Pa_OpenStream (0x823f18)] I noticed that those 0's were the values being fed in to the function. I remember converting c_ulong's to ulong's and that they were probably uint's in D. Converting those fixed the problem and the callback is now called! I converted all the ulongs to uint's but there were a few longs and I don't know if they are c_longs or d_longs... Anyways, At least I'm on the right track. For C/C++ interaction, always use c_... types if they are available. The idea is both that they will be correctly defined for the width, and also it will mangle correctly for C++ compilers (yes, long and int are mangled differently even when they are the same thing). -Steve In portaudio, this doesn't seem to be the case. I changed all the longs to ints and ran my code in x64 and it worked fine. It may just be that the stuff that uses long is not used in my code. In port audio I see it using unsigned long and so this should be 64-bits in x64. Surprised it worked. Maybe conversion is taking place or the high bits of the long are 0'ed and so there is not much difference. Anyways, I guess I'll deal with any of those bugs when I run in to them, if they exist.
Re: C callbacks getting a value of 0! Bug in D?
On Monday, 28 August 2017 at 22:41:56 UTC, Moritz Maxeiner wrote: On Monday, 28 August 2017 at 22:21:18 UTC, Johnson Jones wrote: On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer wrote: [...] and where are these c_ types defined? The reason I replaced them was precisely because D was not finding them. core.stdc.config , which unfortunately doesn't appear in the online documentation AFAICT (something that ought to be fixed). A common workaround is to use pattern searching tools like grep if you know the phrase to look for: $ grep -Er c_long /path/to/imports , or in this case, since these things are usually done with aliases: $ grep -Er 'alias\s+\w*\s+c_long' /path/to/imports Thanks. I copied over stuff from the bindings and from the original header and I guess I missed the import.
Re: C callbacks getting a value of 0! Bug in D?
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer wrote: On 8/27/17 10:17 PM, Johnson Jones wrote: [...] For C/C++ interaction, always use c_... types if they are available. The idea is both that they will be correctly defined for the width, and also it will mangle correctly for C++ compilers (yes, long and int are mangled differently even when they are the same thing). -Steve and where are these c_ types defined? The reason I replaced them was precisely because D was not finding them.
Re: C callbacks getting a value of 0! Bug in D?
Looking at the assembly shows something like this: 0041ea98 push 0x0 0041ea9a push 0x0 0041ea9c push 0x0 0041ea9e push dword 0x100 0041eaa3 mov ecx, [typeid(PaStreamParameters)+0xe36fc (0x80d4cc)] 0041eaa9 mov eax, [fs:0x2c] 0041eaaf mov edx, [eax+ecx*4] 0041eab2 push dword [edx+0x1c] 0041eab8 push dword [edx+0x18] 0041eabe push dword [ebp-0x54] 0041eac1 push dword [ebp-0x5c] 0041eac4 mov ebx, PA.stream (0x823f30) 0041eac9 push ebx 0041eaca call dword near [Pa_OpenStream (0x823f18)] I noticed that those 0's were the values being fed in to the function. I remember converting c_ulong's to ulong's and that they were probably uint's in D. Converting those fixed the problem and the callback is now called! I converted all the ulongs to uint's but there were a few longs and I don't know if they are c_longs or d_longs... Anyways, At least I'm on the right track.
C callbacks getting a value of 0! Bug in D?
Trying to set a callback for portaudio and it's seeing zero for
the value passed.
Pa_OpenStream(, input, output, sampleRate, cast(ulong)0,
cast(PaStreamFlags)(PaStreamFlags.NoFlag +
0*PaStreamFlags.PrimeOutputBuffersUsingStreamCallback),
cast(PaStreamCallback)(a,b,c,d,e,f){
callbackCalled = true;
return 0;
},
null);
I am using a debug build of portaudio that prints out all the
parameters before anything else, so it's not an issue with
portaudio.
I've tried passing a normal function:
__gshared int sawtooth(const(void)* inputBuffer, void*
outputBuffer, ulong framesPerBuffer,
const(PaStreamCallbackTimeInfo)* timeInfo, PaStreamCallbackFlags
statusFlags, void *userData)
{ return 0; }
and passing it as
with the same issue.
I've tried changing the calling convention and using __gshared
but the value is always 0. It seems other values are 0 too and
can't seem to get any value in to the callback(Even a random one).
The output essentially always looks like this:
Opening Stream!
Pa_OpenStream called:
PaStream** stream: 0x00823EA0
PaStreamParameters *inputParameters: NULL
PaStreamParameters *outputParameters: 0x02C6C1C0
PaDeviceIndex outputParameters->device: 3
int outputParameters->channelCount: 4
PaSampleFormat outputParameters->sampleFormat: 1
PaTime outputParameters->suggestedLatency: 0.135000
void *outputParameters->hostApiSpecificStreamInfo:
0x
double sampleRate: 44100
unsigned long framesPerBuffer: 256
PaStreamFlags streamFlags: 0x0
PaStreamCallback *streamCallback: 0x
void *userData: 0x
Pa_GetSampleSize called:
PaSampleFormat format: 8
Pa_GetSampleSize returned:
int: 2
Pa_GetSampleSize called:
PaSampleFormat format: 8
Pa_GetSampleSize returned:
int: 2
Pa_GetSampleSize called:
PaSampleFormat format: 1
Pa_GetSampleSize returned:
int: 4
Pa_GetSampleSize called:
PaSampleFormat format: 8
Pa_GetSampleSize returned:
int: 2
Pa_GetSampleSize called:
PaSampleFormat format: 8
Pa_GetSampleSize returned:
int: 2
Pa_OpenStream returned:
*(PaStream** stream): 0x03BEAD50
PaError: 0 ( Success )
everything seems correct except:
PaStreamCallback *streamCallback: 0x
void *userData: 0x
You can find the full code at
https://forum.dlang.org/thread/lkbswgpsgxynhfyzw...@forum.dlang.org
This is either a bug in D, an issue with calling conventions, or
how one passes the data.
The original portaudio open stream function, so you can see that
it simply prints it's arguments:
PaError Pa_OpenStream( PaStream** stream,
const PaStreamParameters *inputParameters,
const PaStreamParameters *outputParameters,
double sampleRate,
unsigned long framesPerBuffer,
PaStreamFlags streamFlags,
PaStreamCallback *streamCallback,
void *userData )
{
PaError result;
PaUtilHostApiRepresentation *hostApi = 0;
PaDeviceIndex hostApiInputDevice = paNoDevice,
hostApiOutputDevice = paNoDevice;
PaStreamParameters hostApiInputParameters,
hostApiOutputParameters;
PaStreamParameters *hostApiInputParametersPtr,
*hostApiOutputParametersPtr;
#ifdef PA_LOG_API_CALLS
PA_LOGAPI_ENTER_PARAMS( "Pa_OpenStream" );
PA_LOGAPI(("\tPaStream** stream: 0x%p\n", stream ));
if( inputParameters == NULL ){
PA_LOGAPI(("\tPaStreamParameters *inputParameters:
NULL\n" ));
}else{
PA_LOGAPI(("\tPaStreamParameters *inputParameters:
0x%p\n", inputParameters ));
PA_LOGAPI(("\tPaDeviceIndex inputParameters->device:
%d\n", inputParameters->device ));
PA_LOGAPI(("\tint inputParameters->channelCount: %d\n",
inputParameters->channelCount ));
PA_LOGAPI(("\tPaSampleFormat
inputParameters->sampleFormat: %d\n",
inputParameters->sampleFormat ));
PA_LOGAPI(("\tPaTime inputParameters->suggestedLatency:
%f\n", inputParameters->suggestedLatency ));
PA_LOGAPI(("\tvoid
*inputParameters->hostApiSpecificStreamInfo: 0x%p\n",
inputParameters->hostApiSpecificStreamInfo ));
}
if( outputParameters == NULL ){
PA_LOGAPI(("\tPaStreamParameters *outputParameters:
NULL\n" ));
}else{
PA_LOGAPI(("\tPaStreamParameters *outputParameters:
0x%p\n", outputParameters ));
PA_LOGAPI(("\tPaDeviceIndex outputParameters->device:
%d\n", outputParameters->device ));
PA_LOGAPI(("\tint outputParameters->channelCount: %d\n",
outputParameters->channelCount ));
pipeProcess not returning immediately
I am running ffplay.exe and my application does not return
immediately from pipeProcess. I have to close ffplay for my
program to continue execution.
pipeProcess is suppose to return immediately/run asynchronously,
and it does with ffmpeg or other programs that return. (which I
do not know if it is returning immediately or not on those
because they execute so quickly)
But I have a feeling it is not running asynchronously at all. Any
ideas? This is on windows and simply calling pipeProcess directly
with a simple "ffplay filename" example.
ffplay opens up a window showing the spectrogram while the file
is playing. After I close it out, my app then does what it is
suppose to. This suggests the pipeProcess is not running
asynchronously.
void ExecuteCommand(T...)(T args)
{
foreach(t; AliasSeq!T)
static assert(is(t == string),
typeof(this).stringof~":"~__PRETTY_FUNCTION__~" requires string
arguments!");
pipes = pipeProcess([args[0], (AliasSeq!args)[1..$]],
Redirect.stdout);
}
call it like
ExecuteCommand("ffplay.exe", "test.wav");
function cannot access frame
cannot access frame of function
I declared a helper function outside a lambda that is passed to C.
The semantics are the same inside of the function as they are
outside as far as code goes.
How can I declare a function that essentially works inside the
lambda also without having to do any real rewriting?
e.g., if I could use a define
#define foo(a,b) a + b
would work great, that is all I really need, templates have the
same issue as functions though.
To make it work I used a mixin template, but that seems a bit
obtuse ;/
e.g.,
template put()
{
int foo(a,b) { return a + b; }
}
mixin put;
then I mixin it inside the lambda also. That way I have both
contexts covered, not bad but...
GtkD: New widget
Hey Mike, I bet you can answer this!
I'd like to extend a widget to add some functionality.
class MyBox : Box
{
protected GtkBox* gtkBox;
import std.typecons;
_gtk.Box Wrapped;
mixin Proxy!Wrapped;
public this(Box b)
{
this.gtkBox = b.getBoxStruct();
super(gtkBox, false);
}
}
Trying something like the above does extend the box, as far as
allowing one to replace it, I think(using the code);
auto b = new MyBox(W1);
auto p = W1.getParent();
auto c = cast(Box)W4;
c.remove(W1);
c.add(b);
So, W4 is the main boxx, W1 is the box inside the main box I
replaced with the new box b.
When running that code, nothing changes, which, assuming we are
actually using the new box, then that is fine.
But I'm pretty sure that gtk never has a clue about `MyBox`? I
say this because I'd like to simply modify the reported sizes of
the box.
A gtkBox is not the same as a gtk.Box.
It seems like the best I can do is use a gtk.Container and
inherit from that.
e.g.,
class FixableSizedBox : Container
{
protected GtkContainer* gtkContainer;
import std.typecons;
_gtk.Container Wrapped;
mixin Proxy!Wrapped;
public this(Container b)
{
this.gtkContainer = b.getContainerStruct();
super(gtkContainer, false);
}
}
But even the GtkD container doesn't seem to contain any code to
deal with handling the sizes.
All I'm really looking to do is set the size of a container to
whatever I want.
Re: GtkD: Build script
On Sunday, 20 August 2017 at 20:13:17 UTC, Mike Wey wrote: On 20-08-17 20:41, Johnson Jones wrote: I guess I see why now you did what you did! ;) .LIB pagesize exceeds 512 https://issues.dlang.org/show_bug.cgi?id=15418 Wanna take bets on how many *years* this takes to get fixed?!? That one happens when GtkD is build with debug symbols. The main library is build by package because optlink or omf doesn't support more that 32767 symbols in one object file, and i hit that limit. ;/ After all, who will ever need more than 32767 symbols? Is this a problem with the linker or the object format? Maybe both oplink and dmd could be upgraded to use an extended omf format that allows more symbols?
Re: Mixed up over mixins.
On Sunday, 20 August 2017 at 19:27:43 UTC, WhatMeWorry wrote:
It's stuff like this which makes me very frustrated. Or
depressed because it demonstrates just how poor a programmer I
am:
string printStatement(string message) {
return `writeln("` ~ message ~ `");`;
}
void main()
{
// Mixins are for mixing in generated code into the source
code.
// The mixed in code may be generated as a template instance
// or a string.
mixin(printStatement("hello world"));
mixin(`writeln(` ~ `Hello` ~ `);` );
mixin("writeln(`World`);");
}
Compiling gives me the errors:
Error: undefined identifier Hello
To me, `writeln(` ~ `Hello` ~ `);` is a valid D string? Okay,
maybe a
string expression but a string nevertheless.
So, am I giving mixin more magical powers than it possesses?
Should we say that mixin needs to be given a "fully pre-formed
D compilable" string?
Thanks. especially to let me vent.
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.
String mixins are very simple. It takes any string and inserts it
as code in to the program directly as if you typed it by hand.
What makes them useful is that you can build strings a compile
time and so essentially introduce compile time code generation.
e.g.,
L324: mixin("Hello World")
becomes
L324: Hello World
and so
mixin(N)
gets inserted as
N, as if you typed it in directly. (this is the important part. N
isn't inserted but the contents of N as a string.
What this is good for, is say you want to generate code based off
stuff at compile time, e.g., a configuration file. You can
generate valid D code using strings that load the configuration
file at compile time and do what you want with it.
e.g.,
enum config = import(myconfigfile);
config now contains, as a string, the contents of myconfigfile AT
COMPILE TIME. Normally we think of config as being a run time
variable, but it is simply a compile time variable(well, it can't
vary, unfortunately, the compile time processing is not a fully
integrated compile time compiler.
enum configCode = process(config);
let process be a function that takes config, extracts the data
from it and bundles it all up in new D code.
mixin(configCode);
Now mixes in that code direct in to the source as if we typed it.
e.g.,
enum classes = import("classNames");
string code;
foreach(n; classes.split(","))
code ~= "class "~n~";\n";
// at this point code should be something like "class X;\nclass
Y;" etc, but it depends on the file.
mixin(code);
has the same effect if we typed
class X;
class Y;
But the difference is that we used a file to extract the class
names and a string mixin that inserted the code. This way we
don't have to manually change the class names in our D file, we
just change the classNames file, which is probably autogenerated
anyways.
String mixins come in very handy when you have D code that can be
"generalized" (parameterized).
It's sort of the place holder concept: You have a D string like
"
if (alpha_1 > 0) { Alpha1(); }
if (alpha_2 > 0) { Alpha2();}
if (alpha_3 > 0) { Alpha3();}
if (alpha_4 > 0) { Alpha4();}
"
...
Obviously if you can simplify all that code it would be nice,
well you can!
for(int i = 0; i < N; i++)
mixin("if (alpha_"~i~" > 0) { Alpha"~i~"();}");
this will mix N of those lines with the proper mapping. I only
have to make one change rather than N.
You have to think of them as D code generators. Of course, you
don't have to use them to generate code, but they are insert,
foremost, in D code and will be interpreted by the D compiler.
mixin("string X = \"mixin string X = \""mixin string X =
\"""mixin string X = .);
is the same as
string X = \"mixin string X = \""mixin string X = \"""mixin
string X = .;
and, if we used enums(compile time object) instead of strings(run
time object), we could do
mixin(X); and it would mix in the next layer, which would redfine
X each time.
It's not difficult, just requires a different way to think about
them, as does anything that is unfamiliar.
Re: Fix D's segfaults!
On Sunday, 20 August 2017 at 18:35:07 UTC, Daniel Kozak wrote: This is not segfault. This is an uncatched exception. So it is your error. You does not do proper error handling. But still IIRC you should be able to see place where things go wrong Dne 20. 8. 2017 8:06 odpoledne napsal uživatel "Johnson Jones via Digitalmars-d" <digitalmars-d@puremagic.com>: D has a major issue with segfaults! It always reports the fault in the lowest function that it occurs! This is completely useless! std.file.FileException@std\file.d(755): Attempting to rename file X.lib to Y.lib: The system cannot find the file specified. 0x0041015E 0x00402C69 0x004025A3 0x00413ECF 0x00413E93 0x00413D94 0x0040DAD7 0x76D78744 in BaseThreadInitThunk 0x76FD582D in RtlGetAppContainerNamedObjectPath 0x76FD57FD in RtlGetAppContainerNamedObjectPath This tells me nothing about where the error occurred in *my* program! Dmd needs to be modified so that errors try to show from the source code. This should be obvious the reasons, if it is not possible, make it possible! There are no excuses why dmd should make me go on an easter egg hunt when a seg fault occurs. Um, That was just an example, the same type of output occurs with segfaults or any error/crash that D outputs stuff trying to be "helpful". Anyways, your missing the point. You expect me to write try/catches in every level of my program to create the granularity one needs to simply get the location the error occured in? Where is that exactly? How hard is it for dmd to know if std.file.FileException@std\file.d occurs in the code I created or somewhere else? It should be able to say "Hey, that is part of a standard library or other non-user component, let me try to walk back a little and see if I can find a location in the user code that led to this problem". This should be quite easy with a stacktrace, simply walk back until the location is in user code. So, regardless of anything, D telling me stuff like "Hey, your error occurred in phobos" doesn't tell me shit except the error occurred in phobos. I'm still looking for easter eggs, and I don't like easter(which is why I don't capitalize it).
Re: GtkD: Build script
I guess I see why now you did what you did! ;) .LIB pagesize exceeds 512 https://issues.dlang.org/show_bug.cgi?id=15418 Wanna take bets on how many *years* this takes to get fixed?!?
Re: Debugging Visual D using Visual D
I should state though, that I could be wrong(and haven't tested it out yet). It's possible that some of the caching "features" screwed up what I think is going on. But the typical thing that got stuff to work was deleting the visual D entries in the registry(of course, it broke mago also). So, I'm not 100%. It may be no keys that are needed to be removed, just a few of them, or all of them.
Re: Debugging Visual D using Visual D
On Friday, 18 August 2017 at 06:37:44 UTC, Rainer Schuetze wrote:
Glad you figured it out. I had to enable Visual D in the
extension manager when using the local pkgdef.
Visual D installs for all users, so I think just installing
into the users AppData is not an option. VS 2017 doesn't seem
to inspect the "All Users" folders.
The installer is not supposed to write to the system registry
for VS2017 related components. I see some bad entries for mago
and two entries for marshalling some data, though, but they
don't seem to have an impact on extension detection (IIRC they
are needed during build).
It writes a few clsID's I think. about 2 or 3, let me check...
Computer\HKEY_CLASSES_ROOT\TypeLib\{002a2de9-8bb6-484d-9903-7e4ad4084715}
C:\Program Files (x86)\VisualD\vdserver.tlb
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002A2DE9-8BB6-484D-980E-7E4AD4084715}
C:\Program Files (x86)\VisualD\visuald.dll
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002a2de9-8bb6-484d-aa05-7e4ad4084715}
C:\Program Files (x86)\VisualD\DParser\DParserCOMServer.exe
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{97348AC0-2B6B-4B99-A245-4C7E2C09D403}
C:\Program Files (x86)\VisualD\Mago\MagoNatDE.dll
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MagoDebugger
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VisualD
I also had to reinstall VisualD because for x64 the debugger
would not run. That probably came from me deleting one of those
directories(the ones referring to mago I guess).
So, I'm not sure if some of those keys are interfering with
getting isolation between the VS versions or what, but it seems
that Visual Studio load the registry version first before the
extension package and also then caches it. This makes it
impossible to actually use the isolated visual D even when
everything is setup right as far as the pkgdef's.
GtkD: Build script
I've modified the build script:
changed 2 things: 1. Builds for all archs. 2. Replaced the
specialized x86 build with the generic used for 64-bit. You were
building for each individual directory for some reason, I guess
for more granularity, but it produced a different result than the
64 build because it left out the root gtk dir, when I put some
package files in to help make it easier to deal with all the
modules.
It might be better to put the libs in their own unique
directories. I was just tired of having to build for each version
so I simplified it. Probably could use some output mentioning
what is going on, although it works well, so maybe not.
I assume for 2 you just did that for more control? The lib file
was quite a bit larger(I think it went from 30 megs to 50 or
something).
Maybe a script such as this could be added and called buildAll.
module Build;
import core.stdc.stdlib: exit;
import std.algorithm;
import std.array;
import std.file;
import std.getopt;
import std.path;
import std.process;
import std.stdio;
import std.string;
string dcflags;
string ldflags;
int main(string[] args)
{
version(Posix)
{
writeln("This build script is currently Windows only.");
return(1);
}
getopt(args, "dcflags", , "ldflags", );
args.popFront();
foreach ( arg; args )
{
if ( !["gtkd", "gtkdgl", "sv", "gstreamer", "vte", "peas",
"all"].canFind(arg) )
{
writefln("Unknown option: %s", arg);
return 1;
}
}
if ( args.length == 0 )
args = ["gtkd", "sv"];
if ( args.canFind("all") )
args = ["gtkd", "sv", "gstreamer", "peas"];
foreach ( arg; args )
{
switch ( arg )
{
case "gtkd":
build("generated\\gtkd", "gtkd");
break;
case "gtkdgl":
build("generated\\gtkdgl", "gtkdgl");
break;
case "sv":
build("generated\\sourceview", "gtkdsv");
break;
case "gstreamer":
build("generated\\gstreamer", "gstreamerd");
break;
case "peas":
build("generated\\peas", "peasd");
break;
default:
assert(false);
break;
}
}
return(0);
}
void build(string dir, string lib)
{
import std.algorithm;
foreach(i; [0,1,2])
switch(i)
{
// 64bit
case 1:
std.file.write("build.rf", format("-m64 -c -lib %s %s
-Igenerated/gtkd -of%sx64.lib %s ", dcflags, ldflags, lib,
dFiles(dir)));
auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 ) exit(1);
break;
default: goto case 0;
case 0:
std.file.write("build.rf", format("-m32 -c -lib %s %s
-Igenerated/gtkd -of%sx86.lib %s ", dcflags, ldflags, lib,
dFiles(dir)));
auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 ) exit(1);
break;
case 2:
std.file.write("build.rf", format("-m32mscoff -c -lib %s %s
-Igenerated/gtkd -of%sx86coff.lib %s", dcflags, ldflags, lib,
dFiles(dir)));
auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 ) exit(1);
break;
}
std.file.remove("build.rf");
}
string dFiles(string sourceDir)
{
string files;
auto entries = dirEntries(sourceDir, SpanMode.breadth);
foreach ( DirEntry entry; entries )
{
if ( entry.isDir == false && entry.name.extension == ".d" )
{
files ~= entry.name ~ " ";
}
}
return files;
}
Fix D's segfaults!
D has a major issue with segfaults! It always reports the fault in the lowest function that it occurs! This is completely useless! std.file.FileException@std\file.d(755): Attempting to rename file X.lib to Y.lib: The system cannot find the file specified. 0x0041015E 0x00402C69 0x004025A3 0x00413ECF 0x00413E93 0x00413D94 0x0040DAD7 0x76D78744 in BaseThreadInitThunk 0x76FD582D in RtlGetAppContainerNamedObjectPath 0x76FD57FD in RtlGetAppContainerNamedObjectPath This tells me nothing about where the error occurred in *my* program! Dmd needs to be modified so that errors try to show from the source code. This should be obvious the reasons, if it is not possible, make it possible! There are no excuses why dmd should make me go on an easter egg hunt when a seg fault occurs.
ffmpeg
Trying to get it to work. 1. The libraries from the main download site seem to be in coff format for x86. This means they don't really work for dmd. I use omf and I tried to use coffimplib on the lib files and it says they are not import libraries. 2. The x64 version works without issue. (I was able to run the test version after adding the dll's, since the libs seem to require them for some oddball reason) 3. When I use -m32mscoff I get Win32\Debug DMD\test.obj Offset 0H Record Type 004C Error 138: Module or Dictionary corrupt 4. Also, visual Studio cannot launch the x64 program with the debugger attached so I have to run it from the command line. It was working before, but when I started messing with the ffmpeg stuff it broke. So at this point the only way I can use ffmpeg is x64 and running stuff from the command line... This is not the way I want to go.
Re: Module Info error
On Saturday, 19 August 2017 at 02:07:25 UTC, Johnson Jones wrote:
Still getting this!
What I don't understand is why I can import certain libraries
and they compile fine while others don't!
So, moduleInfo is a "function" per module that is created at
compilation, right?
If one doesn't compile the module then the error results, just
like standard extern functions. When I don't include the file
in the project, it doesn't get compiled, even though it gets
"imported"? Why? Why can't D just know, hey, module X imports
module Y, module Y needs to be compiled to add moduleInfo?
For example, I am trying to get ffmpeg to work. I downloaded
from
https://github.com/complistic-gaff/ffmpeg-d
extracted, put that path in my includes(sc.ini). created a
module to import the standard modules, tried to compile my
project and I get a bunch of ModuleInfo errors relating to the
imports I added.
I use GtkD exactly the same, yet no errors.
Now, the only difference is that I import the gtkD.lib. I'm
assuming that all the moduleInfo's of the 1000+ gtk files are
in that lib and so That is the reason I don't have the compile
them all, is that correct?
If so, how can I generate such a lib of moduleInfo's
recursively for a directory so I can pick up all the files and
just import it once?
ffmpeg doesn't require compiling but I don't wanna have to
include ever file in to my project just to be able to get it to
work because of the moduleInfo's are missing.
Looking at the build.d for gtkD, it looks like it builds a list
of all the files to compile and does it recursively.
I imagine it can be modified for ffmpeg too to create a utility
to solve this problem. Dmd should have a mode to do this
automatically, it's quite an annoying problem ;/
So, I was able to hack the build script and solve my problem. I
simply replaced the dir entries and such for ffmpeg instead.
module Build;
import core.stdc.stdlib: exit;
import std.algorithm;
import std.array;
import std.file;
import std.getopt;
import std.path;
import std.process;
import std.stdio;
import std.string;
string dcflags;
string ldflags;
int main(string[] args)
{
build("ffmpeg", "ffmpeg");
return(0);
}
void build(string dir, string lib)
{
version(Win64)
{
std.file.write("build.rf", format("-m64 -c -lib %s %s
-Igenerated/gtkd -of%s.lib %s", dcflags, ldflags, lib,
dFiles(dir)));
auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 )
exit(1);
}
else
{
if (lib == "gtkd")
{
string[] subDirs = ["libavcodec", "libavdevice",
"libavfilter", "libavformat", "libavutil", "libswscale"];
foreach(directory; subDirs)
buildObj(dFiles(directory), directory);
string objects;
foreach(directory; subDirs)
objects ~= directory ~".obj ";
executeShell(format("dmd -lib %s -of%s.lib %s", ldflags, lib,
objects));
foreach(directory; subDirs)
std.file.remove(directory ~".obj");
}
else
{
buildObj(dFiles(dir), lib);
executeShell(format("dmd -lib %s -of%s.lib %s.obj", ldflags,
lib, lib));
std.file.remove(lib ~".obj");
}
}
std.file.remove("build.rf");
}
void buildObj(string files, string objName)
{
std.file.write("build.rf", format("-c %s -Igenerated/gtkd
-of%s.obj %s", dcflags, objName, files));
auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 )
exit(1);
}
string dFiles(string sourceDir)
{
string files;
auto entries = dirEntries(sourceDir, SpanMode.breadth);
foreach ( DirEntry entry; entries )
{
if ( entry.isDir == false && entry.name.extension == ".d" )
{
files ~= entry.name ~ " ";
}
}
return files;
}
So the question is, is there a direct way to do this? e.g., have
dmd do it recursively for us, or rdmd, or a tool that is designed
to do stuff like this for the general case? (the above code could
be made more general, which I might do in the future)
Module Info error
Still getting this! What I don't understand is why I can import certain libraries and they compile fine while others don't! So, moduleInfo is a "function" per module that is created at compilation, right? If one doesn't compile the module then the error results, just like standard extern functions. When I don't include the file in the project, it doesn't get compiled, even though it gets "imported"? Why? Why can't D just know, hey, module X imports module Y, module Y needs to be compiled to add moduleInfo? For example, I am trying to get ffmpeg to work. I downloaded from https://github.com/complistic-gaff/ffmpeg-d extracted, put that path in my includes(sc.ini). created a module to import the standard modules, tried to compile my project and I get a bunch of ModuleInfo errors relating to the imports I added. I use GtkD exactly the same, yet no errors. Now, the only difference is that I import the gtkD.lib. I'm assuming that all the moduleInfo's of the 1000+ gtk files are in that lib and so That is the reason I don't have the compile them all, is that correct? If so, how can I generate such a lib of moduleInfo's recursively for a directory so I can pick up all the files and just import it once? ffmpeg doesn't require compiling but I don't wanna have to include ever file in to my project just to be able to get it to work because of the moduleInfo's are missing. Looking at the build.d for gtkD, it looks like it builds a list of all the files to compile and does it recursively. I imagine it can be modified for ffmpeg too to create a utility to solve this problem. Dmd should have a mode to do this automatically, it's quite an annoying problem ;/
Re: Named multi-imports
On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
On 17.08.2017 23:03, aberba wrote:
On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
This looks really clean for code modularity.
import io = std.stdio : {writeln, write}, ...
What does this add? A line like below would be confusing.
import io = std.stdio : {writeln, write}, writefln;
The following code compiles and the imports are less
confusing.
import io = std.stdio : writeln, write;
import std.stdio : writefln;
void main()
{
io.write("foo");
io.writeln("bar");
writefln("My items are %(%s %).", [1,2,3]);
}
Its more like this:
import oo = {std.stdio : {writeln, write}, std.algorithm:
{filter, map}, …};
oo.writeln();
oo.write();
oo.filter(...);
oo.map(...);
private struct oo{
import std.stdio: writeln, write;
import std.algorithm: filter, map;
// …
}
void main(){
oo.write("result: ");
oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}
Wow, that might solve the problem! A little more verbose but it
does combine everything.
Any downsides?
Thanks.
Re: GtkD: How to respond to cell edit's?
On Friday, 18 August 2017 at 00:27:05 UTC, Johnson Jones wrote:
I should also mention that when I use an ID to do what I
want(again, something I don't want to do), I also need to get
the column that was edited. This is because I'm using one
delegate for all the edits.
auto cb = delegate(string index, string text, CellRendererText
r)
{
// How to get the column of that we are editing? An index
would be fine.
writeln(index, " - ", text);
};
RT1.addOnEdited(cb);
RT2.addOnEdited(cb);
RT2.addOnEdited(cb);
Looks like I might have to use separate edit handlers ;/
I wonder if I can somehow template it so I can do something like
RT1.addOnEdited(cb!1);
RT2.addOnEdited(cb!2);
RT2.addOnEdited(cb!3);
without having to write a bunch of code to make it happen.
Maybe there is a library function that can help?
Obvious it is easy when you have ID's, but this is meant for the
original case where I'm not using ID's.
Re: GtkD: How to respond to cell edit's?
I should also mention that when I use an ID to do what I
want(again, something I don't want to do), I also need to get the
column that was edited. This is because I'm using one delegate
for all the edits.
auto cb = delegate(string index, string text, CellRendererText r)
{
// How to get the column of that we are editing? An index
would be fine.
writeln(index, " - ", text);
};
RT1.addOnEdited(cb);
RT2.addOnEdited(cb);
RT2.addOnEdited(cb);
Looks like I might have to use separate edit handlers ;/
I wonder if I can somehow template it so I can do something like
RT1.addOnEdited(cb!1);
RT2.addOnEdited(cb!2);
RT2.addOnEdited(cb!3);
without having to write a bunch of code to make it happen. Maybe
there is a library function that can help?
GtkD: How to respond to cell edit's?
Trying to setup a callback that will propagate changes from a cell(and editable GtkCellRendererText) to my model. Can't seem to find any way to get the actual GtkCellRendererText CellRendererText has an addOnEdited but I can't find a way to get the CellRendererTExt for a TreeViewColumn ;/ All the examples I've seen create the renderer programmatically, while I'm using glade. https://github.com/gtkd-developers/GtkD/blob/master/demos/gtkD/DemoMultiCellRenderer/DemoMultiCellRenderer.d While I could ID the cell renderer in glade, I'd like to get it programmatically. Any ideas?
Re: Problem with BP's
On Friday, 18 August 2017 at 00:02:23 UTC, Johnson Jones wrote:
On Thursday, 17 August 2017 at 22:41:51 UTC, Johnson Jones
wrote:
I was doing something strange ;/
I had code like
mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();
And no BP's could be hit in side the function call. D would
say that there was an error in the symbols for the project.
but making MyFile.d a module(adding module MyFile; at the top)
and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
I guess this is a related problem with mixin debugging, which
still doesn't work for me. In a sense, it might be a good why
to debug them because the file exists already and one doesn't
have to have it generated by the compiler to debug. This
should help get the symbols and line numbers correct and the
line mappings. Might help make a seemless way to debug them.
e.g., any BP's in Myfile.d have to be translated to the
original file they are mixed in at and vice versa when
debugging them(open Myfile D).
Hmm, maybe that wasn't the fix, still getting the error in some
cases:
The error is "Unexpected symbol reader error while processing
test.exe"
It might have been coincidence that the above change worked or
it might be that it only partially fixed it.
What's strange about it is that delegates inside the function I'm
calling are hit but code in the root of the function are not.
void CallSomeFunctionInMyFile()
{
addDelegate(()
{
foo();
});
foo();
}
The first foo will break on a BP assinged to it but the second
one won't.
Re: Problem with BP's
On Thursday, 17 August 2017 at 22:41:51 UTC, Johnson Jones wrote:
I was doing something strange ;/
I had code like
mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();
And no BP's could be hit in side the function call. D would say
that there was an error in the symbols for the project.
but making MyFile.d a module(adding module MyFile; at the top)
and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
I guess this is a related problem with mixin debugging, which
still doesn't work for me. In a sense, it might be a good why
to debug them because the file exists already and one doesn't
have to have it generated by the compiler to debug. This should
help get the symbols and line numbers correct and the line
mappings. Might help make a seemless way to debug them. e.g.,
any BP's in Myfile.d have to be translated to the original file
they are mixed in at and vice versa when debugging them(open
Myfile D).
Hmm, maybe that wasn't the fix, still getting the error in some
cases:
The error is "Unexpected symbol reader error while processing
test.exe"
It might have been coincidence that the above change worked or it
might be that it only partially fixed it.
Problem with BP's
I was doing something strange ;/
I had code like
mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();
And no BP's could be hit in side the function call. D would say
that there was an error in the symbols for the project.
but making MyFile.d a module(adding module MyFile; at the top)
and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
I guess this is a related problem with mixin debugging, which
still doesn't work for me. In a sense, it might be a good why to
debug them because the file exists already and one doesn't have
to have it generated by the compiler to debug. This should help
get the symbols and line numbers correct and the line mappings.
Might help make a seemless way to debug them. e.g., any BP's in
Myfile.d have to be translated to the original file they are
mixed in at and vice versa when debugging them(open Myfile D).
Re: Debugging Visual D using Visual D
On Thursday, 17 August 2017 at 21:18:35 UTC, Johnson Jones wrote:
On Thursday, 17 August 2017 at 17:45:35 UTC, Rainer Schuetze
wrote:
On 17.08.2017 19:05, Johnson wrote:
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.
I think you are right that VS imports the settings from the
pkgdef only once, then uses the registry only.
Maybe try deleting the cache files in
"%APPDATA%\Local\Microsoft\VisualStudio\15.0_\Extensions".
Ok, It seems to be caching. I deleted everything in the main
registry related to visualD and ran visual studio and it was
still there!
Searched on line and came up with devenv updateconfiguration,
reran VS, and VisualD was no longer there! Ran experimental and
it's still there!
Used the same process to remove it from Exp.
So, this surely has to be caching, although I removed all the
cache files I could fine from both versions.
As of this point there is nothing related to visualD in the
registry nor the VS folders as far as I can tell and both
versions are not finding visualD.
I will copy the modified pkgdef file to the exp dir and run it:
Did nothing, Vi sual D didn't load! Copied the original pkgdef,
no go.
Seems Visual studio is not using the pkgdef in
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp\Extensions\Rainer
Schuetze\VisualD
I put the extensions folder in all the visual studio versions
in that base dir and it didn't help(so it's not using any
directory in
C:\Users\Main\AppData\Local\Microsoft\VisualStudio).
Of course, at this point it means something is fubar'ed.
I went ahead and installed latest VD so I could get some work
done. Seems like no problem.
So either visual studio is not doing what it's suppose to or it
has more cache files laying around that I failed to delete,
unless you see something different?
[Just me going step by step for reference:
I should mention that after installing the latest, Visual D also
gets installed in the Exp version ;/ so it "magically" propagated
to it.
The evidence seems to point to visual studio simply loading
visual D from the system registry and completely bypassing
everything else. It doesn't even look at the pkgdef's(or looked
at them once and installed them, then uses the registry
thereafter).
Does the visualD installer install registry keys? or just the
pkgdef file and then somehow informs VS and then VS does it?
My guess is that Visual D installs the registry keys, possibly
wrong/old way, VS uses
Re: Debugging Visual D using Visual D
On Thursday, 17 August 2017 at 17:45:35 UTC, Rainer Schuetze
wrote:
On 17.08.2017 19:05, Johnson wrote:
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.
I think you are right that VS imports the settings from the
pkgdef only once, then uses the registry only.
Maybe try deleting the cache files in
"%APPDATA%\Local\Microsoft\VisualStudio\15.0_\Extensions".
Ok, It seems to be caching. I deleted everything in the main
registry related to visualD and ran visual studio and it was
still there!
Searched on line and came up with devenv updateconfiguration,
reran VS, and VisualD was no longer there! Ran experimental and
it's still there!
Used the same process to remove it from Exp.
So, this surely has to be caching, although I removed all the
cache files I could fine from both versions.
As of this point there is nothing related to visualD in the
registry nor the VS folders as far as I can tell and both
versions are not finding visualD.
I will copy the modified pkgdef file to the exp dir and run it:
Did nothing, Vi sual D didn't load! Copied the original pkgdef,
no go.
Seems Visual studio is not using the pkgdef in
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp\Extensions\Rainer
Schuetze\VisualD
I put the extensions folder in all the visual studio versions in
that base dir and it didn't help(so it's not using any directory
in C:\Users\Main\AppData\Local\Microsoft\VisualStudio).
Of course, at this point it means something is fubar'ed.
I went ahead and installed latest VD so I could get some work
done. Seems like no problem.
So either visual studio is not doing what it's suppose to or it
has more cache files laying around that I failed to delete,
unless you see something different?
Re: Named multi-imports
On Thursday, 17 August 2017 at 21:03:33 UTC, aberba wrote:
On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
This looks really clean for code modularity.
import io = std.stdio : {writeln, write}, ...
What does this add? A line like below would be confusing.
import io = std.stdio : {writeln, write}, writefln;
The following code compiles and the imports are less confusing.
import io = std.stdio : writeln, write;
import std.stdio : writefln;
void main()
{
io.write("foo");
io.writeln("bar");
writefln("My items are %(%s %).", [1,2,3]);
}
Its more like this:
import oo = {std.stdio : {writeln, write}, std.algorithm:
{filter, map}, …};
oo.writeln();
oo.write();
oo.filter(...);
oo.map(...);
Someone gets it! ;)
Re: New Features [was Named multi-imports]
On Wednesday, 16 August 2017 at 19:05:54 UTC, Jesse Phillips
wrote:
On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole
wrote:
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.
Its an important challenge of software development, and a
number of articles out there about it.
https://www.google.com/search?q=the+cost+of+features=utf-8=utf-8
At first glance I wasn't finding anything which uniquely
tackles compilers and languages.
Backwards compatibility isn't just for programming languages
but can be more important.
Yes, but you are choosing a side, like most people. What about
the cost of not advancing? How many man hours are wasted because
someone won't implement feature because they "think" it will
cause problems or because they are too lazy or won't get enough
$$$ to do it?
Cost is not a one way street. When you don't do something it is
doing something. The whole problem with backwards compatibility
is that it is based on ignorance. When computers were first
hitting the street, people were doing what I am suggesting, as
that's all they could do. They screwed up a lot of things and
wasted a lot of time. But then 50 years later people use that as
an example, out of ignorance, to suggest that the same mistakes
will occur. They completely neglect the fact that we wouldn't
have what we have without all those mistakes either.
You can argue all you want, until you are purple in the face, but
you cannot deny what I have said as being the truth and your
arguments are baseless for the same reasons you claim mine is.
If one had to do things blindly and ignorantly, then yes, your
arguments are sound. But by using your brain, learning from past
mistakes, and moving forward to make progress, the issues can be
minimized and a balanced can be made.
You cannot apply some general statement to all specific instances
unless that statement is truly general. The backwards
compatibility plague is based on ignorance, e.g., "We don't know
what will be the ramifications of doing X so we will stick with
the status quo!". That is a purely ignorant statement, that is,
it is saying the same as "We are ignorant of what will happen if
we do X so we won't do anything".
When you apply that logic to something that one doesn't have to
be ignorant of, one is missing out on doing X and if X is good
and done and improves things then it is a same and real ignorance
wins again. No progress could ever be made if people didn't try
things. If people try things intelligent then they minimize the
problems that people like you are afraid of.
The best solution is a balance, wouldn't you agree?
When a "feature" offers no foreseeable issues(essentially nearly
mathematically proved to be correct), then it shouldn't be looked
as bad.
Again, as I pointed out, where would anything be if everyone had
the mentality you state?
Would D have mixins? No, because who knows what kinda problems
they could introduce in the language?
Would D have traits? No, because who knows what kinda problems
they could introduce in the language?
etc...
etc..
etc..
etc..
And these cause problems not just in programming but in real
life. No one wants to fix the problems, say, of America because
who knows what kinda problems that will introduce... and given
the track record of those that do the "problem fixing" we can be
pretty sure of the outcome. But the problem is then not the
problem fixing but those that fix the problems.
So, my point is that your argument is baseless and doesn't mean
anything in the real world. It is a guide, a parable about the
past and potentially the future, but people like you seem to like
to make it a law, like gravity, which it is not. The sad fact is
that it slows down real progress. One could make arguments about
and if progress is a good thing or not in and of itself, but that
is a different issue.
A good UI can help a user with complexity. So does consistency.
Adding a syntax for special meaning can be difficult to
remember. My personal example is properties in C#. The syntax
is straight forward and clean, but only recently have I been
able to remember how to write one: ReturnType Name { get {
return a; } set(value) { a = value; } }
As for your specific suggestion I think it would be nice at
times but the complexity you haven't specified is how do deal
with ambiguities if two modules provide the same symbol name.
D may have a number of features which C++ doesn't and visa
versa, the complexity of the language for C++ to have those
features means I work with D and not C++.
Then why are you so against adding features? That is what made D
Re: Debugging Visual D using Visual D
On Wednesday, 16 August 2017 at 17:54:39 UTC, Rainer Schuetze wrote: On 16.08.2017 16:48, Johnson wrote: 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 ;/ Starting with VS2017, it's supposed to be possible to have different copies of VS installed. I guess the additional hex value after 15.0 is represents each of these different installations. I don't run "CreateExpInstance", I just start "devenv /RootSuffix Exp" (or another suffix) which creates 15.0_ade21380Exp for me. There is no 15.0 folder on my AppData
Re: Named multi-imports
On Wednesday, 16 August 2017 at 17:14:49 UTC, jmh530 wrote:
On Wednesday, 16 August 2017 at 14:42:51 UTC, Mike Wey wrote:
Wouldn't that just move the problem?
You then get an package that imports gtk.Window and a other
package that imports gdk.Window, and if you want to use both
you still need to add a renamed import or a static import in
your own file.
I don't know anything about gtkd, but I think he means
something like below.
.\gtkd\package.d
module gtkd;
public import gtk;
public import gdk;
...etc
.\gtkd\gtk\package.d
module gtk;
public import gtk.Window;
...etc
.\gtkd\gdk\package.d
module gdk;
public import gdk.Window;
...etc
So you should then be able to do something like
import gtkd : functionThatDoesntOverlap;
import gtk = gtkd.gtk : functionThatDoesOverlap;
import gdk = gtkd.gdk : functionThatDoesOverlap;
A longer-term solution is for something like
import gtkd;
to only pull in the functions/structs/classes/etc that are
actually used.
Not really, I'm not doing selective imports.
I want to be able to use an import symbol that contains a whole
crapload of imports. Which, the only way now is to create a
separate file and public import all those imports one wants, then
use that file and name it.
test.d
import _gtk = crapload;
import _gdk = crapload2;
crapload.d
public import gtk.TreeView;
public import gtk.Window;
crapload2.d
public import gdk.Window
But this requires creating files for every one group one wants.
It would be much nicer and easier, and it is easy if D added the
language feature, to do
import _gtk = {gtk.TreeView, gtk.Window, ... }
import _gdk = {gdk.Window, ... }
The semantics are the same, it is just a rewrite rule
basically... but all it really solves is not requiring extra
files, which means keeping track of more junk.
It's not necessarily all that useful if one uses such imports all
the time since it would bloat the files, But we could then add
some wildcards:
import _gtk = gtk.*;
import _gdk = gdk.*;
which would be functionally the same but far less verbose.
But as it stands now, there is only one way to do that and that
way is the most verbose and hardest to maintain... that really
isn't acceptable when it is such an easy problem to fix and
doesn't have any downside in implementing it.
Stefan Koch: New CTFE fix
Hi Stefan,
I have a suggestion/request for you for newCTFE:
string do()
{
string x;
x = "adsf";
pragma(msg, x);
return x;
}
fails because the compiler believes that x is not known at
compile time. 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?
One way may be to treat all strings as enums internally and allow
normal string operations on them, effectively creating a
string_enum type.
In fact, maybe a new type would be the easiest way. string_enum
is a string at runtime but an enum with string operations at
compile time. (for memory efficiency they could be more like
string builders)
Another possible way is for the compiler to emit the pragma(msg,
x) as sort of writelns. i.e., ctfe_writeln, which if I recall,
hasn't been added yet.
Then we end up something like
string do()
{
string x;
x = "adsf";
ctfe_writeln(x);
return x;
}
which either could immediately display x if possible, or the
compiler could collect all output then display after the function
is called(issues are that errors might break the output).
I'm sure other solutions are possible. pragma(msg, ) could act
different depending on if it is use on a variable that is used
inside a ctfe vs a compile time "variable" used inside a ctfe.
Maybe your newCTFE already has the ability to do this or make it
easy? It would surely help me because I tend to use a lot of
mixins and generally cannot easily output the results for
debugging purposes(and since mixins already are nearly impossible
to debug like normal code, we need something useful to help us
out).
wth!! ctfe cannot format floating point at compile time?
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?
Re: Debugging Visual D using Visual D
One can prevent building the other projects using the configuration manager. Seems to work fine. One problem is that I cannot seem to get breakpoints to work. Same issues as I mentioned before with visual D saying the symbols haven't been loaded for the document. I do not know if it's the cross debugging issue or Visual D's issue though.
Debugging Visual D using Visual D
So, just to let you know, I seemed to be able to setup Visual
Studio so that I can debug Visual D(with visual D).
To do this:
Load the experimental hive:
https://blog.agchapman.com/updating-registry-settings-for-visual-studio-2017/
Load the privateregistry.bin file from
%localappdata%\Microsoft\VisualStudio\15.0_[instanceid]{RootSuffix}\privateregistry.bin
Modify all visual D install dirs with a location one wants to use
for the debugged version, there are quite a few. I simply made a
sub-dir called debug and copied the original data to that
location(and, of course, made a backup).
Create a way to copy the debug version of visual D to that
directory(a build event, batch file, etc).
Then run visual studio with /RootSuffix Exp
https://msdn.microsoft.com/en-us/library/bb166560.aspx
It should load a new exp visual studio using the new visual D.
Now one can copy the dll without issue since they are different
versions being used.
The only thing left to do is have it automatically run visual
studio on "start". There seems to be no csproj for visualD though
so it can't be modified, I guess a post build event could be used.
Also, it seems that one can't disable building for a project.
Visual D has several projects and I'm so used to building using
F6 that I tend to rebuild the whole thing. Is it possible to get
some way to disable building for a project in the solution?
Re: string hash significant speedup
On Thursday, 10 August 2017 at 20:07:35 UTC, Steven Schveighoffer wrote: On 8/10/17 3:36 PM, Johnson Jones wrote: when using T[string], hashing is used. Computing the hash is slow(relatively speaking). Does D cache the hashes? Strings are immutable so there is absolutely no reason why the hash ever need to be computed more than once. It computes them on insertion, and caches the result in the structure of the hash table. -S Thanks. What is the cache size?
string hash significant speedup
when using T[string], hashing is used. Computing the hash is slow(relatively speaking). Does D cache the hashes? Strings are immutable so there is absolutely no reason why the hash ever need to be computed more than once. Essentially the hash should be attached to strings like their length and address. Does D compute the hash of a string every time it is looked up? If so, any way to optimize that it?
Import modules too verbose in some cases
Sometimes one doesn't want to import either the whole module nor specify a single function to import. It seems that basically D has all the info to import the function implicitly because it usually gives a nice error message tells us which module to import for the function. e.g., A.B.C() "Did you forget to import module A.B?" and so we have to do import A.B; A.B.C(); Sometimes we still need to specify the fully qualified name due to conflicts with other modules. Rather, how about a new feature were we do not have to import modules at all by specifying the fully qualified name? Since conflicts might occur, how bout using a symbol to express that? #A.B.C(); or @A.B.C(); or $A.B.C(); same as import A.B; A.B.C(); So, for one offs we don't have to write the import statement.
delegates/lambas do not pick up calling convention
given somethign like Threads.threadsAddIdle
which takes an extern(C) int (void*)
we can't seem to do
threadsAddIdle((void*) { }, null);
nor
because D complains is not the correct type nor can we do
delegate(void*)
or
extern(C) delegate(void*) {}
and have to resort to verbosity to get it to work. Is there a way
around that? Why can't D realize that an inline lambda should use
the same calling convention? There is no harm in doing so.
Maybe I'm doing it wrong:
I've tried
import gdk.Threads;
alias DD = static extern(C) int delegate(void*);
auto x = (void*)
{
return 1;
};
gdk.Threads.threadsAddIdle(x, null);
which gives the error
(extern (C) int function(void* userData) funct, void* data) is
not callable using argument types
int function(void* _param_0) pure nothrow @nogc
@safe, typeof(null))
While one can do something like
gdk.Threads.threadsAddIdle(cast(GSourceFunc)(void* data)
{
return 1;
}, null);
which seems to work but the cast seems superfluous as D should be
able to implicitly figure that out since it's an inline delegate.
Re: GC operates in LIFO sequence?
On Wednesday, 9 August 2017 at 17:38:15 UTC, Swoorup Joshi wrote: On Wednesday, 9 August 2017 at 15:47:17 UTC, Guillaume Piolat wrote: On Wednesday, 9 August 2017 at 13:46:29 UTC, MGW wrote: Memory allocation and deallocation when an application is being completed in GC operates in FIFO sequence. Is there a possibility to shift GC memory deallocation to LIFO mode? It`s connected with the fact that GUI library (Qt) creates QApplication first, but GC destroys this object first when an application is being completed. This leads to the application failure. If the sequence of memory deallocation on LIFO is shifted, it will essentially simplify the cooperation with C++ libraries. https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors Is garbage collection even useful besides managing memory? Of course! Once a week it is useful! Else things start piling up and getting really smelly! Not very healthy!
Re: ModuleInfo Error
On Wednesday, 9 August 2017 at 22:00:56 UTC, Adam D. Ruppe wrote: On Wednesday, 9 August 2017 at 21:29:07 UTC, Johnson Jones wrote: I routinely get this error when I forget to add a module that I import to the project. You learn it pretty quickly though, don't you? no ;/ I have a memory like a rock. Which is either infinite or zero ;/ I tend to do a lot of things and after months of not seeing something I tend to flush my cache. Specially if I don't program in D for a while. It's one thing when you do something every day but when you do things in squirts, you tend to memorize what you need to know for that purpose then soon forget when you no longer need it. I guess this is due to the fact that the module does not have a library backing and the __ModuleInfo function isn't generated for it so it doesn't exist anywhere? (Just guessing) Yeah, basically. __ModuleInfo isn't a function, rather it is a block of static data telling the runtime where its static ctors, dtors, unittests, etc. are, but same idea. When you compile a .d file, the module info is automatically generated and put in the file with the functions you write. When you import a module, the compiler emits a reference to that moduleinfo so it can run its static ctors, etc., if present in your program. Importing a module without linking in its library or object file causes the error you see. Surely we could get a better error message for this or dmd could somehow try and automatically remedy the situation? So it technically isn't actually dmd generating that error... it happens at the link step, after dmd is done. Though dmd could parse the linker output and replace it with different text... but that is a pretty big pain and like I hinted above, this is the kind of thing you might be slightly baffled by the first time, but quickly learn what it means so the ongoing cost is pretty small. Replacing the text from the linker isn't just a one time implementation either: it'd have to keep up with changes from other linkers or version updates, and would likely break any special output (such as colors) that it tries to do. However... If so, why not keep track of all the modules that have bee used and if this error occurs, compile the module or do whatever needs to be done so the error is not necessary? ...that's what rdmd does. I think it is distributed with the compiler. dmd itself doesn't do that though since a valid use case (and fairly common with dmd's corporate users) is to compile and link separately, like people do with C++, to improve working with their complex build systems (speed, external assets, proprietary libraries, etc. don't work as well with my preferred "dmd *.d" strategy so they make it fancy af), so automatically compiling everything would actually be a step backward for those people. But you might want to try using rdmd. You just pass it the function with main and it figures out the rest by walking the import path, then calls dmd to actually compile. New users to D will be thrown by this error. It is meaningless as far as being helpful and there is virtually no online help for it... It is a FAQ... though cannot easily be found. Maybe you (or someone else) should ask on SO and put an answer up there so we can start linking to that? Well, I use Visual D and not sure if it can use rdmd(I'm sure it can be hacked) . Is there any benefits or downsides to doing this? I guess it's not a huge deal at the end of the day... but stuff like this just shouldn't be an issue. Are we going to be dealing with such things 50 years down the road? (well, not us, but the next generation?) I find most of the problems that we have(not just as programmers, but as human beings) tend to be because people cannot cut ties with the past and learn from their mistakes. Do we even need to separate the linker and compiler? Shouldn't they be able to communicate with each other internally to get the most information they can to make our lives easier? A simple switch could be used to separate linking and compiling. I feel that "modern" programming is still trapped in the past and we all ultimately suffer from it. Most people just don't realize how much better it could be. How many people have quit using D because of all the issues it has or simply because it doesn't have the momentum to carry them through life? I've seen a couple recently simply cut ties. They wouldn't have to do this if they could make a living using D, which means that D is has failed them, which is sad ;/ I don't think the powers at be really comprehend those things as they have don't have to worry nor experience those things to understand... hence, there is no motivation to get D on the right footing so it is not such a problem. An unfortunate set of circumstances. Anyways, I'll just try to remember, ranting about that stuff makes it stick in my mind better I guess, and at least a forum search
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 added
import core.sys.windows.winuser;
__gshared extern(C) core.sys.windows.winuser.HANDLE
function(GdkWindow*) gdk_win32_window_get_handle;
Linker.link(gdk_win32_window_get_handle,
"gdk_win32_window_get_handle", LIBRARY_GDK);
to GtkD\generated\gtkd\gdk\c\functions.d
and rebuilt and it seems to work. Hopefully that is the right
place so in the future when I replace GtkD with it won't show up
as a bug in my code somewhere. I assume master will be updated
with this at some point?
Re: Get Dll functions at compile time
Was buggy due to refactoring.
module DLLImport;
/* Import DLL functions in to type T. The following example shows
methodology
struct DLL_gdk
{
@("DLLImport") public static extern(Windows)
{
@("libgdk-3-0.dll")
{
void* function(GdkWindow *window)
gdk_win32_window_get_handle;
}
}
}
// Fixes static functions and function pointers to point to their
specified DLL's
ImportDLLs!DLL_gdk;
*/
void ImportDLLs(T)()
{
version(Windows)
{
import core.sys.windows.windows, std.conv, std.meta, std.traits;
HINSTANCE[string] DLLs;
foreach(fname; __traits(allMembers, T))
{
mixin("enum isf = isFunction!(T."~fname~");");
mixin("enum isfp = isFunctionPointer!(T."~fname~");");
mixin("enum attrs = __traits(getAttributes,
T."~fname~");");
static if ((isf || isfp) && attrs.length == 2 && attrs[0] ==
"DLLImport")
{
auto dllName = attrs[1];
if (dllName !in DLLs)
DLLs[dllName] =
LoadLibrary(to!wstring(dllName~"\0").ptr);
auto dll = DLLs[dllName];
if (dll == null)
assert(0, "Cannot load DLL
`"~dllName~"'");
auto func = GetProcAddress(dll, fname);
mixin("import "~moduleName!(T)~";");
static if (isf)
mixin("auto p = cast(void**)&"~T.stringof~"."~fname~"; *p =
cast(typeof(p))func;");
else static if (isfp)
mixin(""~T.stringof~"."~fname~" =
cast(typeof("~T.stringof~"."~fname~"))func;");
else
static assert("DLLImport Error");
}
}
}
}
ModuleInfo Error
I routinely get this error when I forget to add a module that I import to the project. It throughs me for a loop because the error doesn't really make sense for what is actually wrong(or does it?): Error 42: Symbol Undefined _D9DLLImport12__ModuleInfoZ (DLLImport.__ModuleInfo) Adding DLLImport.d to the project solves the problem. I'm using Visual D so I guess adding the file to the project adds it to the includes on the command line. I guess this is due to the fact that the module does not have a library backing and the __ModuleInfo function isn't generated for it so it doesn't exist anywhere? (Just guessing) Surely we could get a better error message for this or dmd could somehow try and automatically remedy the situation? What is __ModuleInfo? An automatically generated function for a module by dmd when a module is compiled? If so, why not keep track of all the modules that have bee used and if this error occurs, compile the module or do whatever needs to be done so the error is not necessary? New users to D will be thrown by this error. It is meaningless as far as being helpful and there is virtually no online help for it... and one doesn't get this for standard stuff like phobos modules, again, I guess because they have a library that has these functions in it. I'm pretty sure dmd could auto detect this issue and try to resolve it internally. I've gotten it several times in different projects in the past.
Re: Get Dll functions at compile time
On Wednesday, 9 August 2017 at 02:11:13 UTC, Johnson Jones wrote:
I like to create code that automates much of the manual labor
that we, as programmers, are generally forced to do. D
generally makes much of this work automatable. For example, I
have created the following code which makes loading dlls
similar to libs:
/* Import DLL functions in to type T. The following example
shows methodology
struct DLLImports
{
@("DLLImport") public static extern(Windows)
{
@("libgdk-3-0.dll")
{
void* function(GdkWindow *window)
gdk_win32_window_get_handle;
}
}
}
// Fixes static functions and function pointers to point to
their specified DLL's
DllImport!DLLImports;
*/
void DLLImport(alias T)()
{
version(Windows)
{
import core.sys.windows.windows, std.conv, std.meta,
std.traits;
HINSTANCE[string] DLLs;
foreach(fname; __traits(allMembers, T))
{
mixin("enum isf = isFunction!(T."~fname~");");
mixin("enum isfp = isFunctionPointer!(T."~fname~");");
mixin("enum attrs = __traits(getAttributes,
T."~fname~");");
static if ((isf || isfp) && attrs.length == 2 && attrs[0] ==
"DLLImport")
{
auto dllName = attrs[1];
if (dllName !in DLLs)
DLLs[dllName] =
LoadLibrary(to!wstring(dllName~"\0").ptr);
auto dll = DLLs[dllName];
if (dll == null)
assert(0, "Cannot load DLL
`"~dllName~"'");
auto func = GetProcAddress(dll, fname);
if (isf)
mixin("auto p = cast(void**)&"~T.stringof~"."~fname~"; *p
= cast(typeof(p))func;");
else
mixin(""~T.stringof~"."~fname~" =
cast(typeof("~T.stringof~"."~fname~"))func;");
}
}
}
But this got me thinking that we don't even need to have to
specify the function in D, hell, they already exist in the lib
and we are just duplicating work.
What if, at compile time, D could get all the functions and
their type information and build a class for them for us? We
could then just write something like
struct DLLImports
{
@("DLLImport") string libgdk = "libgdk-3-0.dll";
}
and have some ctfe meta functions extract all the function from
libgdk and insert them in to the struct.
There are two problems with this, one easy and one
hard/impossible(which would be easy if people were intelligent
enough to have foresight):
1. Get the dll function by name from the dll at compile time.
This would probably require manually reading the dll file and
scanning for the function.
2. Get the type information to build a declaration. This is
probably impossible since dll's do not contain the type
information about their parameters and return type(or do
they?). If they did, it would be easy. I would suggest that all
dll's generated by D include this information somewhere and an
easy way to extract it for future programmers so such things
could be implemented.
Alternatively, maybe a master database could be queried for
such information by using the function names and dll name? I
don't know if D has network capabilities at compile time though.
Alternatively, completely scrap the lethargic way things are
done in the name of backwards compatibility and $$$ and do
things right(learn from the past, stop repeating same mistakes,
etc). Sure it's a lot of work, but in the end is far less than
one thinks considering the increased productivity... but I
guess the we gotta keep buying the kids christmas presents.
And while we are at it, here is a set of meta functions that make
using glade files easier:
// Loads the glade interface element id's and types directly from
the glade interface file so we do not have to declare them
manually
// Use: @("Glade") {
mixin(DeclareGladeInterfaceElements!gladeFile); } where ever
variables will be defined and InstantiateGladeInterfaceElements(
to initalize them
public string DeclareGladeInterfaceElements(string filename)()
{
auto token1 = " // Matched class/object type, get name actual type then get id
if it has one.
if (i+token1.length < data.length && data[i..i+token1.length]
== token1)
{
i += token1.length;
auto pos = i;
while(i < data.length && data[i] != '"') i++;
auto type = cast(string)data[pos..i];
// Match id if it has one.
while(i+token2.length < data.length && data[i] != '>' &&
data[i] != '<' && data[i] != '"' && data[i..i+token2.length] !=
token2) i++;
Get Dll functions at compile time
I like to create code that automates much of the manual labor
that we, as programmers, are generally forced to do. D generally
makes much of this work automatable. For example, I have created
the following code which makes loading dlls similar to libs:
/* Import DLL functions in to type T. The following example shows
methodology
struct DLLImports
{
@("DLLImport") public static extern(Windows)
{
@("libgdk-3-0.dll")
{
void* function(GdkWindow *window)
gdk_win32_window_get_handle;
}
}
}
// Fixes static functions and function pointers to point to their
specified DLL's
DllImport!DLLImports;
*/
void DLLImport(alias T)()
{
version(Windows)
{
import core.sys.windows.windows, std.conv, std.meta, std.traits;
HINSTANCE[string] DLLs;
foreach(fname; __traits(allMembers, T))
{
mixin("enum isf = isFunction!(T."~fname~");");
mixin("enum isfp = isFunctionPointer!(T."~fname~");");
mixin("enum attrs = __traits(getAttributes,
T."~fname~");");
static if ((isf || isfp) && attrs.length == 2 && attrs[0] ==
"DLLImport")
{
auto dllName = attrs[1];
if (dllName !in DLLs)
DLLs[dllName] =
LoadLibrary(to!wstring(dllName~"\0").ptr);
auto dll = DLLs[dllName];
if (dll == null)
assert(0, "Cannot load DLL
`"~dllName~"'");
auto func = GetProcAddress(dll, fname);
if (isf)
mixin("auto p = cast(void**)&"~T.stringof~"."~fname~"; *p =
cast(typeof(p))func;");
else
mixin(""~T.stringof~"."~fname~" =
cast(typeof("~T.stringof~"."~fname~"))func;");
}
}
}
But this got me thinking that we don't even need to have to
specify the function in D, hell, they already exist in the lib
and we are just duplicating work.
What if, at compile time, D could get all the functions and their
type information and build a class for them for us? We could then
just write something like
struct DLLImports
{
@("DLLImport") string libgdk = "libgdk-3-0.dll";
}
and have some ctfe meta functions extract all the function from
libgdk and insert them in to the struct.
There are two problems with this, one easy and one
hard/impossible(which would be easy if people were intelligent
enough to have foresight):
1. Get the dll function by name from the dll at compile time.
This would probably require manually reading the dll file and
scanning for the function.
2. Get the type information to build a declaration. This is
probably impossible since dll's do not contain the type
information about their parameters and return type(or do they?).
If they did, it would be easy. I would suggest that all dll's
generated by D include this information somewhere and an easy way
to extract it for future programmers so such things could be
implemented.
Alternatively, maybe a master database could be queried for such
information by using the function names and dll name? I don't
know if D has network capabilities at compile time though.
Alternatively, completely scrap the lethargic way things are done
in the name of backwards compatibility and $$$ and do things
right(learn from the past, stop repeating same mistakes, etc).
Sure it's a lot of work, but in the end is far less than one
thinks considering the increased productivity... but I guess the
we gotta keep buying the kids christmas presents.
Re: gtkD window centering message up and no app on taskbar
On Tuesday, 8 August 2017 at 21:37:40 UTC, Mike Wey wrote:
On 07-08-17 23:52, Johnson Jones wrote:
On Monday, 7 August 2017 at 20:57:08 UTC, Mike Wey wrote:
On 07-08-17 22:46, Johnson Jones wrote:
[...]
This appears to be a GTK issue, a work around might be to get
the Window handle from gtk and use the Windows API to set the
taskbar visibility.
Yeah, I was thinking about that but haven't yet figured out
how to find the window handle ;/
To get the Window handle you could use this for 32bit Windows:
```
import gtk.c.functions;
// Danger, Will Robinson!
HANDLE handle =
*(cast(HANDLE*)((cast(void*)gtk_widget_get_window(w.getWidgetStruct()))+4));
```
Where w is your application window, i used this in the map
event signal so the handle is actually set. To complicate
things there is a race condition in gdk some ware so at random
the handle isn't valid.
I haven't been able to set the taskbar icon with is tough.
The two attempts:
-Setting the parent window to null as windows with no parent
should have an taskbar icon:
```
ShowWindow(handle, SW_HIDE);
SetParent(handle, null);
ShowWindow(handle, SW_SHOW);
```
Or set the extended window style to WS_EX_APPWINDOW as that
should fore an taskbar icon according to msdn.
```
ShowWindow(handle, SW_HIDE);
SetWindowLong(handle, GWL_EXSTYLE, WS_EX_APPWINDOW);
ShowWindow(handle, SW_SHOW);
```
Yeah, they keep returning null or some integer < 100(probably
junk values).
There surely has to be a way to get the windows handle? We could
use Win32 api and "search" for the window and get the handle but
that isn't that safe unless we can specify the windows classname
or title uniquely.
Things like ispy can find windows by coordinates but I think they
essentially use the above methods and region compares. e.g.,
there is no FindWindowByCoordinates... which still wouldn't be
very accurate.
// Fixup missing taskbar icon
void SetTaskBarIcon(gtk.ApplicationWindow window)
{
version(Windows)
version(X86)
{
import core.sys.windows.winuser, gdk.Window;
auto x = window.getWidgetStruct();
auto y =
((cast(void*)gtk.gtk_widget_get_window(window.getWidgetStruct()))+4);
auto handle =
*(cast(core.sys.windows.winuser.HANDLE*)((cast(void*)gtk.gtk_widget_get_window(window.getWidgetStruct()))+4));
ShowWindow(handle, SW_HIDE);
SetParent(handle, null);
SetWindowLong(handle, GWL_EXSTYLE, WS_EX_APPWINDOW);
ShowWindow(handle, SW_SHOW);
}
return;
}
Sometimes I get y = 4, which I think is what you were saying
before. Sometimes I get handle = < 100.
I've tried in a few places but not after Main.run(), which maybe
is needed for gtk to register the window and all that? I guess I
can run that function in a callback and see if it is valid...
Didn't work.
I can't really find anything on line about getting a windows
handle from gtk ;/
There is this:
https://stackoverflow.com/questions/23021327/how-i-can-get-drawingarea-window-handle-in-gtk3
Gdk.threads_enter()
#get the gdk window and the corresponding c gpointer
drawingareawnd = drawingarea.get_property("window")
#make sure to call ensure_native before e.g. on realize
if not drawingareawnd.has_native():
print("Your window is gonna freeze as soon as you
move or resize it...")
ctypes.pythonapi.PyCapsule_GetPointer.restype =
ctypes.c_void_p
ctypes.pythonapi.PyCapsule_GetPointer.argtypes =
[ctypes.py_object]
drawingarea_gpointer =
ctypes.pythonapi.PyCapsule_GetPointer(drawingareawnd.__gpointer__, None)
#get the win32 handle
gdkdll = ctypes.CDLL ("libgdk-3-0.dll")
hnd =
gdkdll.gdk_win32_window_get_handle(drawingarea_gpointer)
#do what you want with it ... I pass it to a gstreamer
videosink
Gdk.threads_leave()
which suggests that maybe gdk_win32_window_get_handle can be used
Ok, I was able to get it to work using that code. I had to do
some wonky dll imports and stuff but that function seems to be
the correct one. I could not use it until after the window was
created(I used it in a button handler), else it crashed the app
for some reason.
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, WS_EX_APPWINDOW);
ShowWindow(handle, SW_SHOW);
Seems to work.
So you might want to add gdk_win32_window_get_handle as an export
in gtkD so it can be used easier.
Thread sequencer
I'm wondering if there is an easy way to create a single extra
thread that one can pass delegates(code) to and it executes it
properly. The thread never closes except at shutdown.
The idea is that isn't of creating one thread per task, there is
one thread that executes each task.
Obviously the idea is not hard but I'd like to wrap those tasks
up in lamdas so I can instantiate them at the point I need
them(and possibly even reuse them). I don't wanna stick all the
code in one thread with a giant switch nor create multiple
threads.
The main problem is that each delegate might have different
arguments and return values associate with it and, while
templates probably can handle it, it seems like it could be a
mess.
Any ideas how to accomplish this effectively? The main thread
will effectively be a task scheduler that will will be able to
execute tasks sequentially and in parallel and interrupt with
interval execution(probably using fibers to do so).
An easy way to think about this is for animations. We might want
to animate several things at the same time at different rates. So
each task will do the frame of the animation then yield. The
scheduler does it's job and sequences everything so it all comes
out correctly(each animation frame is rendered as soon as it is
suppose to. If it's a 30fps second animation then the scheduler
tries to call the task 30 times a second. If it's 1fps then it
does so once a second... interleaving everything etc.
e.g.,
int N = 100;
scheduler.AddTask((int N) { for(int i = 0; i < N; i++) {
displayImage("Animation", i); yeild; } }, 100, N); // Display the
ith frame of animation at 10fps.
Or whatever.
Essentially the scheduler should do nothing until a task is
added, schedule them as it should, etc.
Now, the hard thing, I think is that the delegates should capture
the local context, but they are ran on a different thread so any
local values are passed along... which requires templates since
they might be different for each delegate: e.g.
Event e = widgetEvent;
scheduler.AddTask((Event e) { for(int i = 0; i < e.Count; i++) {
AddEventCycles(e.Cycle[i]); yield; } }, 10, e);
and I think that is probably the hard part since we need to store
the delegates in a heterogeneous container of delegates.
Anyways, Would be nice if something like this already existed or
would be easy to implement.
Re: x64 build time 3x slower?
On Tuesday, 8 August 2017 at 00:01:05 UTC, Johnson Jones wrote: On Monday, 7 August 2017 at 22:56:37 UTC, Moritz Maxeiner wrote: On Monday, 7 August 2017 at 22:19:57 UTC, Johnson Jones wrote: Why would that be. Program take about 4 seconds to compile and 12 for x64. There is fundamentally no difference between the two versions. I do link in gtk x86 and gtk x64 depending on version, and that's it as far as I can tell. Debug x86 4 x64 12 Release x86 3 x64 5 The timings are pretty steady. Split up the build time in compile time and link time and see how the difference is distributed between the two. If it's distributed overwhelmingly to the link time it could be that you're using Microsoft's linker for x64 and OPTLINK for x86? Yeah, I guess that is probably it. Forgot that two different linkers were used... although, Not much is being linked. Visual D doesn't split up the two easily, I suppose I can't separate them. It should probably do individual profiling between the two. Usually the build times are pretty close and I don't recall it being slow when I first started building, and my code hasn't changed much... But I did modify a few options such as debug diagnostics and such as those were causing visual studio to freeze. I guess I could perfmon it to see what exactly it is doing. It takes about 3 seconds to write the map file(I have it generating cross references, not sure what it actually does but I thought it might help with debugging issues. I have it enabled for both x86 and x64. I thought I disabled it with no differences, but maybe I missed it). It takes another 4 seconds to create the pdb. But it seems that about 6 seconds are done doing thing 7:13:14.7148555 PM link.exe 9860 QueryStandardInformationFile C:\D\Libraries\x64\gtkd.lib SUCCESS AllocationSize: 84,443,136, EndOfFile: 84,439,450, NumberOfLinks: 1, DeletePending: False, Directory: False 7:13:14.7148665 PM link.exe 9860 CreateFileMapping C:\D\Libraries\x64\gtkd.lib SUCCESS SyncType: SyncTypeOther 7:13:15.7801685 PM ServiceHub.IdentityHost.exe 4952 Thread Exit SUCCESS Thread ID: 11224, User Time: 0.000, Kernel Time: 0.000 7:13:17.2481064 PM ServiceHub.VSDetouredHost.exe 5004 Thread Create SUCCESS Thread ID: 10976 7:13:17.4141043 PM devenv.exe 1040 Thread Create SUCCESS Thread ID: 11200 7:13:17.8990951 PM DParserCOMServer.exe 4492 Thread Create SUCCESS Thread ID: 9176 7:13:18.7481654 PM ServiceHub.VSDetouredHost.exe 5004 Thread Exit SUCCESS Thread ID: 10976, User Time: 0.000, Kernel Time: 0.000 7:13:18.9163321 PM devenv.exe 1040 Thread Exit SUCCESS Thread ID: 11200, User Time: 0.000, Kernel Time: 0.000 7:13:19.4011479 PM DParserCOMServer.exe 4492 Thread Exit SUCCESS Thread ID: 9176, User Time: 0.000, Kernel Time: 0.000 7:13:19.9681080 PM ServiceHub.VSDetouredHost.exe 5004 Thread Create SUCCESS Thread ID: 10416 Not sure what is happening in there but it seems like Visual D or Visual Studio issue rather than dmd ;/ I'll look in to it some more to see what I can find.
Re: rename file, execute os, etc at compile time
On Monday, 7 August 2017 at 12:39:31 UTC, lobo wrote: On Monday, 7 August 2017 at 00:07:26 UTC, Johnson Jones wrote: On Sunday, 6 August 2017 at 23:11:56 UTC, Nicholas Wilson wrote: On Sunday, 6 August 2017 at 19:56:06 UTC, Johnson Jones wrote: [...] It is deliberately not possible. reproducible builds security ect. have a look at dubs preBuildCommand(?) So it is intensionally preventing me from doing something I should be able to do if I want without issue because it thinks I will harm myself? Why not a compiler switch that enables it? It's blocking something that might be an issue but is almost surely not and prevents the vast capabilities that it would otherwise be able to accomplish. I guess one can always patch the compiler... But Dmd does give an error about security, it usually says that the there are not source code available for compile time or something like that. How is this a blocking anything when you can do it already with nearly every build tool available. Invoke a script or prebuilt binary etc. as a target that does the munging for you at pre-compile time. Very easy, it's blocking me from setting up templates that automatically do what I need when I copy and paste code from one project to another... ya didn't think about that, did ya? Oh, I know... you have some way out! I should be able to shoot myself in the foot if I want... no one should be able to decide what is best for me except me. They don't like it when I decide what is best for them and so should abide by the law of reciprocity.
Re: gtk interface responsiveness
On Monday, 7 August 2017 at 22:59:16 UTC, Moritz Maxeiner wrote:
On Monday, 7 August 2017 at 22:02:21 UTC, Johnson Jones wrote:
I have an icon that I toggle which clicked. It seems that I
can't toggle it any faster than about a second.
The handler is being called each click but it seems the gui is
not updated more than about 1fps in that case? Although, I'm
sure it update faster than 1fps, just seems the icon/image
isn't.
The code I use to set the image is:
Image.setFromStock("gtk-go-up", GtkIconSize.SMALL_TOOLBAR);
or
Image.setFromStock("gtk-go-down", GtkIconSize.SMALL_TOOLBAR);
[...]
Could you please post the complete minimal code (and compiler
options) (or a link to them) required to reproduce the issue?
It takes about 3 seconds to write the map file(I have it
generating cross references, not sure what it actually does but I
thought it might help with debugging issues. I have it enabled
for both x86 and x64. I thought I disabled
it with no differences, but maybe I missed it).
It takes another 4 seconds to create the pdb.
But it seems that about 6 seconds are done doing thing
7:13:14.7148555
PM link.exe 9860 QueryStandardInformationFile C:\D\Libraries\x64\gtkd.lib SUCCESS AllocationSize: 84,443,136, EndOfFile: 84,439,450, NumberOfLinks: 1, DeletePending: False, Directory: False
7:13:14.7148665
PM link.exe 9860 CreateFileMapping C:\D\Libraries\x64\gtkd.lib SUCCESS SyncType: SyncTypeOther
7:13:15.7801685 PM ServiceHub.IdentityHost.exe 4952 Thread
Exit SUCCESS Thread ID: 11224, User Time: 0.000, Kernel
Time: 0.000
7:13:17.2481064 PM ServiceHub.VSDetouredHost.exe 5004 Thread
Create SUCCESS Thread ID: 10976
7:13:17.4141043 PM devenv.exe 1040 Thread Create SUCCESS Thread
ID: 11200
7:13:17.8990951 PM DParserCOMServer.exe 4492 Thread
Create SUCCESS Thread ID: 9176
7:13:18.7481654 PM ServiceHub.VSDetouredHost.exe 5004 Thread
Exit SUCCESS Thread ID: 10976, User Time: 0.000, Kernel
Time: 0.000
7:13:18.9163321 PM devenv.exe 1040 Thread Exit SUCCESS Thread
ID: 11200, User Time: 0.000, Kernel Time: 0.000
7:13:19.4011479 PM DParserCOMServer.exe 4492 Thread
Exit SUCCESS Thread ID: 9176, User Time: 0.000, Kernel Time:
0.000
7:13:19.9681080 PM ServiceHub.VSDetouredHost.exe 5004 Thread
Create SUCCESS Thread ID: 10416
Not sure what is happening in there but it seems like Visual D or
Visual Studio issue rather than dmd ;/
I'll look in to it some more to see what I can find.
Re: gtk interface responsiveness
On Monday, 7 August 2017 at 22:59:16 UTC, Moritz Maxeiner wrote:
On Monday, 7 August 2017 at 22:02:21 UTC, Johnson Jones wrote:
I have an icon that I toggle which clicked. It seems that I
can't toggle it any faster than about a second.
The handler is being called each click but it seems the gui is
not updated more than about 1fps in that case? Although, I'm
sure it update faster than 1fps, just seems the icon/image
isn't.
The code I use to set the image is:
Image.setFromStock("gtk-go-up", GtkIconSize.SMALL_TOOLBAR);
or
Image.setFromStock("gtk-go-down", GtkIconSize.SMALL_TOOLBAR);
[...]
Could you please post the complete minimal code (and compiler
options) (or a link to them) required to reproduce the issue?
I'll try to formulate something when I get some time to do so.
Just trying to get things to work the way I need them to see if
gtk is gonna be the gui library I use lots of problems but
hopefully it's just growing pains.
Re: x64 build time 3x slower?
On Monday, 7 August 2017 at 22:56:37 UTC, Moritz Maxeiner wrote: On Monday, 7 August 2017 at 22:19:57 UTC, Johnson Jones wrote: Why would that be. Program take about 4 seconds to compile and 12 for x64. There is fundamentally no difference between the two versions. I do link in gtk x86 and gtk x64 depending on version, and that's it as far as I can tell. Debug x86 4 x64 12 Release x86 3 x64 5 The timings are pretty steady. Split up the build time in compile time and link time and see how the difference is distributed between the two. If it's distributed overwhelmingly to the link time it could be that you're using Microsoft's linker for x64 and OPTLINK for x86? Yeah, I guess that is probably it. Forgot that two different linkers were used... although, Not much is being linked. Visual D doesn't split up the two easily, I suppose I can't separate them. It should probably do individual profiling between the two. Usually the build times are pretty close and I don't recall it being slow when I first started building, and my code hasn't changed much... But I did modify a few options such as debug diagnostics and such as those were causing visual studio to freeze. I guess I could perfmon it to see what exactly it is doing.
x64 build time 3x slower?
Why would that be. Program take about 4 seconds to compile and 12 for x64. There is fundamentally no difference between the two versions. I do link in gtk x86 and gtk x64 depending on version, and that's it as far as I can tell. Debug x86 4 x64 12 Release x86 3 x64 5 The timings are pretty steady.
gtk interface responsiveness
I have an icon that I toggle which clicked. It seems that I can't
toggle it any faster than about a second.
The handler is being called each click but it seems the gui is
not updated more than about 1fps in that case? Although, I'm sure
it update faster than 1fps, just seems the icon/image isn't.
The code I use to set the image is:
Image.setFromStock("gtk-go-up", GtkIconSize.SMALL_TOOLBAR);
or
Image.setFromStock("gtk-go-down", GtkIconSize.SMALL_TOOLBAR);
I also have been experiencing significant slow downs when the gui
load for the first time. Doesn't always seem to happen but
basically keyboard output across the os is unresponsive then
everything occurs at once(when whatever catches up for quits
interfering with the keyboard). It takes about 20 seconds for
that to occur then everything works fine afterwards best I can
tell.
(BTW, thanks mike for all the help ;))
Re: gtkD window centering message up and no app on taskbar
On Monday, 7 August 2017 at 20:57:08 UTC, Mike Wey wrote: On 07-08-17 22:46, Johnson Jones wrote: [...] This appears to be a GTK issue, a work around might be to get the Window handle from gtk and use the Windows API to set the taskbar visibility. Yeah, I was thinking about that but haven't yet figured out how to find the window handle ;/
Re: gtkD: events being triggered twice
On Monday, 7 August 2017 at 21:01:33 UTC, Mike Wey wrote: On 06-08-17 21:27, FoxyBrown wrote: [...] Also seems to be working properly with a Separator. Ok, I guess it's on my end, I don't see how since I'm not doing a hell of a lot and only gtk is calling those event handlers, I'll try to create a test app at some point. I've already added logic to prevent multiple reentries though so, for now I've solved the problem.
Re: gtkD window centering message up and no app on taskbar
On Saturday, 5 August 2017 at 20:56:10 UTC, Mike Wey wrote: Windows will only show the taskbar icon if you are not running the application from the console. Now in x64 it is showing, not in x86. So, not sure what's going on but at least it is showing. I was in a windows console and added a main.def but dmd says that it's not compatible with x64 or something: main.def(1) : warning LNK4017: EXETYPE statement not supported for the target platform; ignored main.def(4) : warning LNK4017: SUBSYSTEM statement not supported for the target platform; ignored but adding that file seemed to allow the icon like you said. I'm not doing anything different for x86 except switching gtk versions... but maybe there is a flag or setting somewhere that is causing the problem. and, in the x64 version I get both the console and gtk app task bar icons... which is what I originally wanted and expected.
Visual D: Unexpected symbol reader error while processing test.exe
I'm very few BP's are working now ;/ Getting that error on most of the lines of code I have https://ibb.co/cVVSSF Not sure why it broke all of a sudden. Since these things seem to be relatively random I'll play around with it after a while. Maybe a more informative error message could be added for things like this? or a logging feature? Whats strange is that the BP works in the delegate but not in the main program ;/
VisualD: Intellisense broke?
Tried to do some work this morning and Intellisense is not
showing.
Not sure what happened. Working fine yesterday.
It seems that when I converted my code to automatically generate
some fields, the semantic engine is not seeing them ;/
I went from something like
struct X
{
int a;
}
to
struct X
{
mixin("int a;");
}
and now x. doesn't list a.
(or rather, I'm using with(x) and a. does nothing (a is a struct
in that case))
There surely has to be a better way to get all this stuff to work
consistently? It isn't magic that's going on behind the scenes
and everything ultimately has to be well defined and meaningful.
Re: gtkD window centering message up and no app on taskbar
and I do have skipTaskbar disabled... tried enabling it with no long... and fidgeting with other settings and using a Window instead of Application Window. Maybe gtk needs to be told that that the window is the "main window" of the application?
Re: gtkD window centering message up and no app on taskbar
On Saturday, 5 August 2017 at 20:56:10 UTC, Mike Wey wrote: On 05-08-17 20:14, Johnson Jones wrote: When trying to center the window. If one uses ALWAYS_CENTERED any resizing of the window is totally busted. CENTER also does not work. move(0,0) seems to not be relative to the main display. I'd basically like to center the window on the main display or at least be able to set coordinates properly. Windows sets (0,0) to be the lower left corner of the main display I believe. What happens is that the gtk window, when using 0,0 actually is like -1000,0 or something in windows coordinates and ends up on my secondary monitor. When the app starts there's no taskbar icon. Luckily I still have the console shown but Eventually I'll need the taskbar. I'm not setting skipTaskBarHint, but I have tried both true and false without any difference. Windows will only show the taskbar icon if you are not running the application from the console. This doesn't seem to be true. I switched over, changed everything to windows, and I still get no taskbar icon. I changed the settings L:Subsystem to windows and added the appropriate def file. I think I did this in another app and it worked fine. So it's probably a gtk glade setting(I was using the older glade versions that we talked about). Now I have no console window and no taskbar icon.
Re: gtkD: events being triggered twice
On Monday, 7 August 2017 at 16:13:18 UTC, Adam D. Ruppe wrote: On Sunday, 6 August 2017 at 19:27:15 UTC, FoxyBrown wrote: I don't know gtk, but I would suspect moving the mouse over the child triggers the enter/leave notifications too and it bubbles up to the parent. Yeah, but both those events are from EventBox. If that were true I'd except Separator to be shown as the widget that has the event. I do return true from the handler which I believe is suppose to stop any more handlers. Although, it does sound something like what you are saying... but it also doesn't explain why the events are not paired, which is the more serious issue.
Re: rename file, execute os, etc at compile time
On Sunday, 6 August 2017 at 23:11:56 UTC, Nicholas Wilson wrote: On Sunday, 6 August 2017 at 19:56:06 UTC, Johnson Jones wrote: is it possible to do? I would like to pre-configure some stuff at "pre-compilation"(in ctfe but before the rest of the program actually gets compiled). I know it's not safe and all that but in my specific case it would help. I'll probably use pre-build events, which is probably the best, but just curious about it in general... I've been wanting to write a ctfe virus in D for a while now! j/k. It is deliberately not possible. reproducible builds security ect. have a look at dubs preBuildCommand(?) So it is intensionally preventing me from doing something I should be able to do if I want without issue because it thinks I will harm myself? Why not a compiler switch that enables it? It's blocking something that might be an issue but is almost surely not and prevents the vast capabilities that it would otherwise be able to accomplish. I guess one can always patch the compiler... But Dmd does give an error about security, it usually says that the there are not source code available for compile time or something like that.
rename file, execute os, etc at compile time
is it possible to do? I would like to pre-configure some stuff at "pre-compilation"(in ctfe but before the rest of the program actually gets compiled). I know it's not safe and all that but in my specific case it would help. I'll probably use pre-build events, which is probably the best, but just curious about it in general... I've been wanting to write a ctfe virus in D for a while now! j/k.
Re: gtkD window centering message up and no app on taskbar
On Saturday, 5 August 2017 at 20:56:10 UTC, Mike Wey wrote: On 05-08-17 20:14, Johnson Jones wrote: When trying to center the window. If one uses ALWAYS_CENTERED any resizing of the window is totally busted. CENTER also does not work. move(0,0) seems to not be relative to the main display. I'd basically like to center the window on the main display or at least be able to set coordinates properly. Windows sets (0,0) to be the lower left corner of the main display I believe. What happens is that the gtk window, when using 0,0 actually is like -1000,0 or something in windows coordinates and ends up on my secondary monitor. When the app starts there's no taskbar icon. Luckily I still have the console shown but Eventually I'll need the taskbar. I'm not setting skipTaskBarHint, but I have tried both true and false without any difference. gtk.Widget.translateCoordinates or gtk.Fixed could be useful for positioning the widgets. Windows will only show the taskbar icon if you are not running the application from the console. Is there a way to get it to show up or have it correlate with the console's taskbar? What I'm finding is that if the window has no title bar(maximized) and/or behind other windows I have to do some window juggling to find it. I need the console for debugging. I could probably set the project as win32 and then create a console manually if necessary but seems to be overkill for something relatively basic.
Re: Did dmd forget how to read?
On Sunday, 6 August 2017 at 00:22:45 UTC, Cym13 wrote: On Saturday, 5 August 2017 at 23:54:45 UTC, Johnson Jones wrote: main.d(157): Error: no property 'SetCursor' for type 'gdk.Window.Window', did you mean 'getCursor'? um... anyone see bug? It's there, I promise. "setCursor" exists, but "SetCursor" doesn't (or your "bug" depends on code that you wrote and didn't share). I believe as both "setCursor" and "getCursor" are one character away from "SetCursor" dmd took the first one in alphabetic order or something. No need to panic ;) No one is panicking, so you can stop panicking that you think they are panicking. The point is that setCursor is much closer to SetCursor than getCursor. It should prioritize case differences first. SETCURSOR should still match setcursor better than getcursor or getCURSOR or whatever. But I'll get you a ascii star for realizing the issue /\ < > \/
gtkD: events being triggered twice
GtkEventBox - Enter
GtkEventBox - Enter
Down
GtkEventBox - Leave
Up
GtkEventBox - Leave
GtkEventBox - Leave
That is when I move the mouse over the event box then click then
move out out then release.
I would expect
Enter Down Leave Up
The fact that enter and leave are not paired equally is a
problem. Can be worked around but seems like it would be a bug.
the code is simply
ebox.addOnEnterNotify(delegate(Event e, Widget w)
{
writeln(w.getName(), " - ", "Enter");
return true;
});
ebox.addOnLeaveNotify((Event e, Widget w)
{ writeln(w.getName(), "
- ", "Leave");
return true;
});
Re: Create class on stack
On Saturday, 5 August 2017 at 23:09:09 UTC, Moritz Maxeiner wrote: On Saturday, 5 August 2017 at 17:08:32 UTC, Johnson Jones wrote: using gtk, it has a type called value. One has to use it to get the value of stuff but it is a class. Once it is used, one doesn't need it. Ideally I'd like to treat it as a struct since I'm using it in a delegate I would like to minimize unnecessary allocations. Is there any way to get D to allocate a class on the stack like a local struct? The easy way is through std.typecons.scoped [1]. Here be dragons, though, because classes are reference types. [1] https://dlang.org/phobos/std_typecons.html#.scoped Thanks, I didn't think it created on the stack but it makes sense to do so. The only issue is that it escaping the reference?
Did dmd forget how to read?
main.d(157): Error: no property 'SetCursor' for type 'gdk.Window.Window', did you mean 'getCursor'? um... anyone see bug? It's there, I promise.
Re: lambda function with "capture by value"
On Saturday, 5 August 2017 at 18:17:49 UTC, Simon Bürger wrote:
If a lambda function uses a local variable, that variable is
captured using a hidden this-pointer. But this capturing is
always by reference. Example:
int i = 1;
auto dg = (){ writefln("%s", i); };
i = 2;
dg(); // prints '2'
Is there a way to make the delegate "capture by value" so that
the call prints '1'?
Note that in C++, both variants are available using
[&]() { printf("%d", i); }
and
[=]() { printf("%d", i); }
respectively.
There is, but it isn't pretty.
import std.stdio;
void main()
{
int i = 1;
int* n = null;
auto dg = (){ if (n is null) n = cast(int*)i; else writefln("%s",
n); }; dg();
i = 2;
dg(); // prints '1'
}
1. I'm pretty sure that D creates the delegate "lazily" in the
sense that the first call is what captures the variable. Hence,
we must call it where we want to capture, not after the change
occurs.
2. We use a temp local variable to act as a place holder. A
singleton basically.
You might be able to wrap this up in some type of template that
makes it easier to use but it does work.
gtkD window centering message up and no app on taskbar
When trying to center the window. If one uses ALWAYS_CENTERED any resizing of the window is totally busted. CENTER also does not work. move(0,0) seems to not be relative to the main display. I'd basically like to center the window on the main display or at least be able to set coordinates properly. Windows sets (0,0) to be the lower left corner of the main display I believe. What happens is that the gtk window, when using 0,0 actually is like -1000,0 or something in windows coordinates and ends up on my secondary monitor. When the app starts there's no taskbar icon. Luckily I still have the console shown but Eventually I'll need the taskbar. I'm not setting skipTaskBarHint, but I have tried both true and false without any difference.
Create class on stack
using gtk, it has a type called value. One has to use it to get the value of stuff but it is a class. Once it is used, one doesn't need it. Ideally I'd like to treat it as a struct since I'm using it in a delegate I would like to minimize unnecessary allocations. Is there any way to get D to allocate a class on the stack like a local struct?
Re: gtk: get property
On Saturday, 5 August 2017 at 15:19:43 UTC, Gerald wrote:
On Saturday, 5 August 2017 at 15:08:21 UTC, Johnson Jones wrote:
I am trying to get the handle size of panned. Not sure if I'm
doing it right but
[...]
I'm using this in Tilix:
Value handleSize = new Value(0);
paned.styleGetProperty("handle-size", handleSize);
Awesome! Thanks! I didn't see that method in the list of 1000's
of function in Visual D ;/ Figured everything that was a getter
started with get.
gtk get actual pixel height of widget
I am trying to set positions of widgets automatically. e.g., I have a paned widget and I to set the position of the handle manually based on a percentage of the window. e.g., 0.5 will set the handle midway and both children will have the same height. I 0.2 will set it to to 20%. I want it to retain this proportion when the window is resized. The problem is I cannot get get the paned widgets actual height(nor the handle size). paned.getHeight() returns -1. If I use the main window's height, things go wonky because, I guess the border size and title bar size skew the calculations. I'm still learning this api and how it all functions and works. Some things are not so obvious nor logical. getHeight should return the height. If -1 means "leave it up to the internals" then there should be some other height function that works like getActualHeight() but there isn't or I can't find anything that works. If I do writeln(mainPaned.getAllocatedHeight()); writeln(mainPaned.getChild1.getAllocatedHeight()); writeln(mainPaned.getChild2.getAllocatedHeight()); then I get something like 800 1 1 where 800 is the height I used to set the window using auto width = 1000, height = 800; mainWindow.resize(width,height); which, I'd expect it to actually be smaller as either it doesn't take in to account the titlebar or the resize function above is not for the full application window.
gtk: get property
I am trying to get the handle size of panned. Not sure if I'm
doing it right but
Value value = new Value();
paned.getProperty("handle-size", value);
GLib-GObject-CRITICAL **: g_object_get_property: assertion
'G_IS_VALUE (value)' failed
or I get stuff like
GLib-GObject-WARNING **: g_object_get_property: object class
'GtkStyle' has no property named 'handle-size'
if I do
mainPaned.getStyle().getProperty("handle-size", value);
I haven't been able to figure out how to get it.
I've also tried
mainPaned.getStyle().getStyleProperty(...
but the first parameter is a GType which is suppose to be the
widget type yet I am getting value types like INT BOOl, etc.
Not sure if there are two types of GTypes
enum GType : size_t
{
INVALID = 0<<2,
NONE = 1<<2,
INTERFACE = 2<<2,
CHAR = 3<<2,
UCHAR = 4<<2,
BOOLEAN = 5<<2,
INT = 6<<2,
UINT = 7<<2,
LONG = 8<<2,
ULONG = 9<<2,
INT64 = 10<<2,
UINT64 = 11<<2,
ENUM = 12<<2,
FLAGS = 13<<2,
FLOAT = 14<<2,
DOUBLE = 15<<2,
STRING = 16<<2,
POINTER = 17<<2,
BOXED = 18<<2,
PARAM = 19<<2,
OBJECT = 20<<2,
VARIANT = 21<<2,
}
If that what I'm suppose to use then not sure which one I use for
Paned ;)
Re: gtkD load images
On Saturday, 5 August 2017 at 12:51:13 UTC, Mike Wey wrote:
On 03-08-17 21:56, Johnson Jones wrote:
If I do something like
import gdkpixbuf.Pixbuf;
Pixbuf.newFromResource("C:\\a.jpg");
There are two issues here, you need to properly escape the
slash: "C:a.jpg".
And a.jpg is not a resource file, so you would use the Pixbuf
constuctor to load an image file.
```
Pixbuf p = new Pixbuf(r"C:\\a.jpg");
```
Thanks. Why do I need 4 slashes? Is that standard with gtk
because strings are interpreted twice or something? Seemed to
work though.
Re: ASCII-ART mandelbrot running under newCTFE
On Friday, 4 August 2017 at 22:50:03 UTC, Stefan Koch wrote: Hey Guys, I just trans-compiled a brainfuck mandelbrot into ctfeable D. newCTFE is able to execute it correctly (although it takes 3.5 minutes to do so). The code is here https://gist.github.com/UplinkCoder/d4e4426e6adf9434e34529e8e1f8cb47 The gist it evaluates the function at runtime since the newCTFE version capable of running this, is not yet available as a preview release. If you want a laugh you can compile the code with ldc and -Oz flag set. LLVM will detect that the function is pure and will try to constant-fold it. I do not know how long this takes though since my patience is limited. Cheers, Stefan Any screenshots? I don't wanna have to install something I won't use but once or twice but would be interested in seeing what is going on since I used to be a fractal freak ;)
Re: Fix gtkD api display
On Friday, 4 August 2017 at 23:14:38 UTC, Adam D. Ruppe wrote: On Friday, 4 August 2017 at 21:53:14 UTC, Johnson Jones wrote: When I click on gtk on the link you gave it gives basically an empty page(a single module). Yeah, there is no overview page in the source code... but I can make it create one automatically. http://dpldocs.info/experimental-docs/gtk.HButtonBox.HButtonBox.html Does not list any members to the left. That's intentional, actually. For the left nav, I show parents and siblings, not children (that's in the main content on the right). I sometimes miss children there too, but siblings are actually usually more useful to me. Easier to see the value in Phobos since it is flatter: http://dpldocs.info/experimental-docs/std.algorithm.sorting.isSorted.html you can see the bolded isSorted showing where you are now, and then its other siblings to navigate the module over there. Yeah, that is a nice feature. But I do not think we are talking about the same thing. While having the siblings only is also nice and desirable to reduce clutter, one needs to quickly see all methods in a module rather than having to hunt and peck. This is actually done in the phobos link you gave and is what am I talking about. The problem then is that we do not see the hierarchy of all the modules and how they relate without having to click clinks. e.g., http://dpldocs.info/experimental-docs/std.algorithm.sorting.nextPermutation.html but http://dpldocs.info/experimental-docs/std.html shows all the modules in the main view which is very long and takes time to scroll. It would be nice if those were shown in the left pane rather than nothing. This way, instead of having to scroll down the long list to find a module one can see it usually instantaneously to the left. Basically the same as the functions that are listed in the first link. The way I would do it, probably, is to have a complete hierarchy tree. std ... experimental ... allocator ... building_blocks ... region ... InSituRegion Now, obviously this is a very big list. (For speed, probably ajax would be used to load only the most relevant) Also, everything cannot be expanded at the start. Only the most current position is expanded + any siblings. So, it is sorta like what you have but offers a way to see the entire library and navigate it relatively quickly but without having to leave that panel to find something. It's all their, just not the descriptions, etc.(although mouse over could provide some basic description when required) Because humans are amazing and have figured out vast ways to do things, I'd probably have a small toolbar at the top that lets one go between different views. If you want a flat list you click the flat button. If you want a full hierarchy you can click a button for that. If you want a reduced hierarchy(immediate module only, still in tree form but all the other branches off the root are not shown) you could get that. Siblings only would have a button. Since all these are basically just different "views" of the same data, they all have their pros and cons and some are more useful than others at different times. The more ways one can view data the more ways one can understand the data. gtkd has really shallow modules with just one class per module, so this appears less useful... but in general I find it really easily to navigate. Maybe I could detect the one class per module pattern and collapse it though. My problem with gtkD's docs is that one cannot quickly(within a click) go from one module to another. One must select the packages tab then find the module and click on it. Do whatever, then when one wants to go to another module, repeat the process. It's not slow in an absolute sense(whatever that means) but it takes a few seconds when it can be done < 1s. Since the packages and module are tabbed, one can't have them both open. If they were side by side, it would probably work fine... not much different than a tree view. Also, the package tree is not collapsed by default. This means more scrolling. Scrolling is a slow process. It may seems fast but it's just a waste of time ultimately because we cannot do anything while we are doing it... and all those little scrolls add up to significant time loss. It's similar to how banks try to get a few extra cents per customer because it's billions at the end of the day... or how manufactures try to cut costs on a product that are a few cents work per product but add up to billions. Similar for programmers. Imagine if we could instantly find the help we wanted how much more time we would have over our lives. E.g., some type of brain interface device that we could transmit our thoughts in to and it would do a search for the data and present the results. That is effectively what we have with google or
Re: Fix gtkD api display
On Friday, 4 August 2017 at 15:24:51 UTC, Gerald wrote: On Friday, 4 August 2017 at 15:08:27 UTC, Mike Wey wrote: Improving the documentation is something i want to do but there are always some more important things to do. Like the Questions/Issues you posted earlier. So unless somebody volunteers it won't happen anytime soon. Mike I had contributed the makeddox.sh script awhile ago, it generates much nicer documentation then candydocs in my IHMO and includes a nice search box. If there is something lacking in it that needs to be improved before it can be used let me know and I'll do the work. The only issue with it that I am aware of is you need to manually copy the public ddox css into the generated folder. I didn't see an easy way to determine it's location automatically. Is there any online demo of it working? Thanks.
Re: Fix gtkD api display
On Friday, 4 August 2017 at 13:59:11 UTC, Adam D. Ruppe wrote: On Friday, 4 August 2017 at 02:08:31 UTC, Johnson Jones wrote: https://api.gtkd.org/gtkd/gtk/ApplicationWindow.html So I ran gtkd through my doc generator too http://dpldocs.info/experimental-docs/gtk.ApplicationWindow.ApplicationWindow.html and I didn't make a top-level package file either... but doing that wouldn't be hard. However, I noticed it is basically the same as the official C documents: https://developer.gnome.org/gtk3/stable/GtkApplicationWindow.html so idk if it is worth spending a lot of time on it. Looks nicer in some ways and in others I prefer the original. I particularly like the members list. The use of the different font sizes, colors, and boxes/lines help contrast elements well. When I click on gtk on the link you gave it gives basically an empty page(a single module). If I click on ApplicationWindow it takes me to a page that lists all the members on the left, which is nice. Probably minor bugs or issues. e.g., http://dpldocs.info/experimental-docs/gtk.HButtonBox.HButtonBox.html Does not list any members to the left. The left list should be an independent panel. When one scrolls down to view a long page one doesn't want to have to scroll all the way back up to view the members list again. It results in a slower process. Seems that is how many of the D docs are but it's wrong/unnecessary as it slows searching down. e.g., the original gtkD docs have a scrollable panel like I'm talking about, but they just list one module at a time, which makes it difficult: https://api.gtkd.org/gtkd/gtk/AboutDialog.html and https://developer.gnome.org/gtk3/stable/GtkApplicationWindow.html has no side panel. So, with a little tightening up, I'd definitely prefer your docs over the other two versions. (It's always good to have multiple versions though) I think any type of documentation should aim at two goals: As much information as possible and to quickly access any point in that information from any other point with information points that are closer being more quickly accessed(A metric). The way the info is organized is, of course, going then to be dependent on the above. Since many programs spend a significant portion of their life searching through docs online, I think it's important to optimize that routine. Would be nice if programmers learned to optimize not only programs but the art of programming itself... we'd all get much more done. After all, many of the same principles apply. But things are way better than they used to be, so that's a good sign ;) I'm not sure what Geralds docs look like but it might solve many of the problems already and you don't have to waste your time if you don't want to. OTH, since you are using an automated utility, it might be worth while to optimize it a little more since it will effect everything it's used on(although, I don't know how time consuming it would be to rerun it on all the docs you've generated... hopefully you've automated that too ;). Thanks.
Re: Who maintains the D website?
On Friday, 4 August 2017 at 09:13:33 UTC, Mike Parker wrote: On Friday, 4 August 2017 at 06:08:04 UTC, captaindet wrote: i see you didn't hold your horses... not sure if i should reply again to such an angry rant. i will stay calm and focused though. This guy has a history of insulting nearly everyone who responds to him, even those who help him, as he has just shown again in his last response to you. You can find more of his posts under the handles Mike B. Johnson and FoxyBrown. My advice to you is, if you'd like to help him, that's fine, but don't expect any sort of reasoned debate from him. Long posts in response to anything he says are a waste of your time. He just doesn't respond well to reason. Way to go Mr. Professional. You have a long way to go to grow up. You think your you can veil your attitude but it's clear you are not a professional. A real professional would simply ignore the situation... And if you note, I only have a problems with a few people here. Mainly you and a one or two others... people that think they can write the shittiest software and how it effects others is of no importance. Instead of giving 100%, it's ok to give 25% and reap the benefits while others suffer the consequences. That attitude is BS and as long as you have it I will offend the fuck out of you all I want. If you don't like it simply ignore me, ban me(if you can), or do whatever you want. Until you grow up and stop acting like you are god I won't. You wanna preach but you don't wanna be preached to. I can take your BS but you can't take mine. It's a two way street... and until you can captain retard get that I won't play nice. There are plenty of people on here I respect. I'll give the top two: Adam Ruppe and H S Teoh. I've not seen any unprofessional nor condescending behavior from these guys. They don't pretend to know it all and don't preach their BS to others. They help the best they can and that is all they do... altruistic people. The kinda of human behavior that the world needs, not the kind that is destroying humanity(Which, you might not be at the bottom of the barrel, but your attitude is the same type that politicians, lawyers, and others have). I'm sorry if you can't grow up and act like those guys... maybe you should take notes from them and see how they act. Maybe you will stop being such an ass when you don't realize it because you think your such an intelligent person, authority, or simply too much ego... whatever it is, I'll make a point of pissing you off every time I get until you stop behaving that way. Your actions have consequences. The code you write has consequences. The "help" you give has consequences. When you stop dictating to other people how you *think* things should be and realize that it is just your opinion then we will get a long much better. Until then, later asshole.
Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum
On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote: See - https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce But can a digital wallets/crypto currency ever be secure ? Nope... as long as humans continue to build house of cards on quicksand this sort of stuff will always happen. You do realize it's all fake nonsense? If the only sort of currency that existed was what you could immediately do with your own body, then it would be impossible to ever steal anything(except for slavery, which is essentially still fake). Basically this is how the story goes: Someone comes up with some scheme to gather resources from others. The scheme is complex and designed in such a way that only those that have created the scheme or invested enough time to understand the scheme benefit from all those that don't but were to stupid not to buy in to the scheme. Eventually those at the top win. It's called a pyramid scheme and it exists in all forms of currency, employment, governments, even in most relationships, etc. Only when all participants equally share complete responsibility can the scheme be fair... but that never happens, too much to gain when it becomes unbalanced... and the more unbalanced it becomes the more those that unbalance it get. I wouldn't doubt that most of these people who create these currencies are the ones that ultimately are behind these thefts. After all, they are the ones that know most about it and why else would they spend their time developing it? For the benefit of human kind? Yeah right! What a joke!
Re: gtkD load images
On Friday, 4 August 2017 at 06:58:00 UTC, Antonio Corbi wrote: On Thursday, 3 August 2017 at 21:06:36 UTC, Johnson Jones wrote: [...] Hi! I load images using Gtk like this (I use gtk under gnu/linux): [...] Thanks! I'm sure it will if it works ;)
Re: Who maintains the D website?
On Friday, 4 August 2017 at 06:08:04 UTC, captaindet wrote: i see you didn't hold your horses... not sure if i should reply again to such an angry rant. i will stay calm and focused though. How pathetic, you are not worth my time. Seeing how you equate accuracy with typos and insecurity shows just how ignorant you are. Go bait someone else. Sorry that your life is so pathetic... but I'm sure it's your own fault.
Re: Fix gtkD api display
Also, interfaces are not linkable. e.g., for gtk.ApplicationWindow, it inherits from gtk.Window but I have to go back to the packages and scroll down to find gtk.Window to see it's properties and methods. Would be nice if I could just click on the gtk.Window and it jump me to it. https://api.gtkd.org/gtkd/gtk/ApplicationWindow.html class ApplicationWindow : gtk.Window.Window, gio.ActionGroupIF.ActionGroupIF, gio.ActionMapIF.ActionMapIF; since the hierarchy is gtk/Window/Window, click on gtk should take one to the gtk package, the first Window should take one to gtk.Window and the second should take one to gtk.Window.Window
Fix gtkD api display
https://api.gtkd.org It is difficult to navigate. 1. clicking the documentation on the main site takes it to the gtk.AboutDialog api. That is all it shows, I was confused at first, as I'm sure most people would be. 2. The packages list lists all the packages, but all the sub elements are expanded, making it time consuming to hunt down anything specific. Initially collapsing them and adding a search box would be nice. 3. When clicking on any packages it reloads the page and shows only the package in the first tab. This requires one to then go back to packages and hunt for something else again. Because the position of the scroll is not saved, one has to scroll down through the entire list. It would be better, I think, if it was one single tab all in a single hierarchy that never reloaded the page so that it is easier to navigate quickly. e.g., instead of Package atk atk.ActionIF atk.Action ... we have atk atk.ActionIF GetActionStruct GetStruct ... atk.Action ... ... and so effectually combining both tabs. It should solve the issues that the current way has without really causing any problems. Everything should be collapsed by default and since no reloading of the page should occur(which might require having the api descriptions in a separate frame that is loaded separately on package changes to avoid reloading the tree view which will recollapse everything). It will make navigating the gtkD api much more fun ;)
Re: Who maintains the D website?
On Friday, 4 August 2017 at 00:52:34 UTC, captaindet wrote: On 2017-08-04 12:13, Johnson Jones wrote: No, sorry. The lead team uses nttp which is old school forum technology. They won't move in to the present and instead insist everyone else stay in the past with them. It's sort of like those guys that drive 1970's camaro's because they think it makes them look cool. I'm sure it's a psychological condition but not much can be done about it. hold your horses! quite a number of users incl myself prefer nttp. nice as the forum web interface is, following a newsgroup with a newsgroup reader like eg the thunderbird built-in is way more comfortable, you should try it one day. eg: you don't have to sign in, can reply immediately, you can customize display/behaviour more thoroughly to your liking, and more. /det It's not! I've used nntp and it crap. You cannot edit your posts, simple as that! You can claim all you want that your method is better but it doesn't make it so. Just based on human nature and the fact that you are saying with an ancient archaic system suggests it's all based in fear of change. The sad part about this is that it forces everyone else to stay in the same broken system. How about this: Dlang.org keeps the old interface like nntp and adds a new one. Anyone that wants to continue to use the old one can and those that one to use the new one can. In a year we can see which one is the most popular and let everyone decide rather than a few old crusty goats. Of course, it won't happen because those in power know the outcome. You can see how nntp is dead. There are few nntp servers and most of the groups are dead and only those that used in in the past still use it. There is not a migration towards nntp but away, and that is fact... which suggests that it is not as good as its opposition. Hence, if I'm right, and I almost surely am(surely you are not going to argue that nntp is becoming more popular, are you?) then those that think that nntp is a great thing and better than the alternatives have psychological issues with change. You can make a forum that behaves similarly(no login), customizable, or whatever else you are saying that you like about nntp. In fact, someone could write a nntp like interface for the forum in D just so to please you guys. I personally have nothing against nntp... while it isn't great it does the job EXCEPT editing. I know people claim that editing posts causes problems but that is rarely the case and the benefits far out weight any negatives. The reasons not to move forward are the same reasons that plague humans in many other areas and it is all psychological/evolutionary reasons rather than based on logic and facts. Familiarity is a prime factor. Many humans, specially older ones, fear change because it is unfamiliar and unknown. Those factors are the same that are at play here and it is unfortunate because I imagine there would be a lot more younger users that have the motivation to help D gain traction that do not participate because they feel like it is a step backwards rather than forwards. One day all the old fogies will die and nntp will be gone.. and some young kid interested in D will start a modern D forum and maybe D will get back on track. Think of it this way: D claims to be this sort of futuristic compiler(it can do thinks "light years" ahead of most other compilers...) yet it uses communications methods that are 50 years old. That's a bit contradictory. It's like a young pretty woman who dresses like a skank and wears so much make up that it makes her look 20 years older than what she is. While she might think she looks good, the people that actually look at her think otherwise. This is sorta what happens with D. It's amazing in some ways but has so much baggage in so many areas that many people are not going to waste their time. The D community can be delusional all they want, but it just works against them instead of allowing D to really shine.
Re: Who maintains the D website?
On Thursday, 3 August 2017 at 23:28:36 UTC, 12345swordy wrote: On Thursday, 3 August 2017 at 00:18:38 UTC, Andrej Mitrovic wrote: Is there a single person who's the main maintainer of the D website..? If not, I have some ideas on how to improve it. Not just ideas, I'd like to give a host at improving it myself, really. Can we gain the ability to edit our own post? I typically make some grammar/spelling mistacks here and there and it would be nice for me to fix this. No, sorry. The lead team uses nttp which is old school forum technology. They won't move in to the present and instead insist everyone else stay in the past with them. It's sort of like those guys that drive 1970's camaro's because they think it makes them look cool. I'm sure it's a psychological condition but not much can be done about it.
Re: Bug in gtkd?
On Thursday, 3 August 2017 at 21:00:17 UTC, Mike Wey wrote: On 03-08-17 22:40, Johnson Jones wrote: Ok, so, I linked the gtk to the msys gtk that I installed before when trying to get glade to work and it worked! seems that msys is much more up to date than anything else as it just works(I need to remember than in the future). The problem I see is this: When I get ready to release my app to the public, I can't expect them to all have to install msys and build. msys seems to clump everything together and I don't know what files I need to extract to be able to bundle everything together. Any ideas how to solve that problem? At least now I can move ahead and actually make some progress on my app. Would still be nice to get the x86 vs x64 issue resolved so I don't have to keep switching between the two for testing purposes. Since Visual D was just patched to handle x64 BP's I guess I can stay with that for now. I'll try to build and test some new installers tomorrow that will include the loaders. Thanks. Could you take a look at the loading image thread I started when you get time? I can't seem to get an image to load even though it seems straight forward. These are the pixbufs I'm using mingw32/mingw-w64-i686-gdk-pixbuf2 2.36.6-2 [installed] An image loading library (mingw-w64) mingw64/mingw-w64-x86_64-gdk-pixbuf2 2.36.6-2 [installed] An image loading library (mingw-w64) in x64 it crashes completely without an exception though... which is why I want an easy way to switch between the two architectures... since x64 seems to be more unstable than x86 but sometimes it's the reverse, and ultimately I'll want to release in x64. Also, do I ever need to rebuild gdk when changing gtk installations? Does it ever grab anything from them at compile time or is it all at runtime?
Re: gtkD load images
On Thursday, 3 August 2017 at 13:12:03 UTC, Mengu wrote:
On Thursday, 3 August 2017 at 03:59:40 UTC, Johnson Jones wrote:
How can be use gtkD to load images, I assume through
gdkpixbuf? While I am getting errors loading images through
glade's image:
(test.exe:8188): Gtk-[1;33mWARNING[0m **: Could not load
image 'a.jpg': Couldn't recognize the image file format for
file 'test\a.jpg'
(loads fine in glade)
which needs to be resolved, I'd also like to be able to use
gdkpixbuf to load images programmatically. There seems to be
no demos on the gtkD github page that deals with image loading.
I've tried to do something like
import gtkc.gdkpixbuf;
auto x = c_gdk_pixbuf_get_formats().data;
but I don't know how to interpret x.
Also something like
import gtkc.gdkpixbuf;
void* x;
auto p = c_gdk_pixbuf_get_formats();
for(int i = 0; i < 10; i++)
{
x = p.data;
p = p.next;
}
which doesn't offer any help.
Aside: How can we call the gtk functions directly using gtkD?
Seems it uses stuff like
Linker.link(gdk_pixbuf_get_formats, "gdk_pixbuf_get_formats",
LIBRARY_GDKPIXBUF);
It does seem to alias to these function but something is off
and I'm not sure what.
hi
- is the gtk.Image class not working for you?
https://api.gtkd.org/gtkd/gtk/Image.html
- there's also a gdkpixbuf.Pixbuf that you can use.
https://api.gtkd.org/gtkd/gdkpixbuf/Pixbuf.html
- you can import those functions from gdkpixbuf.c.functions.
So, like I said, I've tried
import gdkpixbuf.Pixbuf;
auto x = Pixbuf.newFromResource("C:\\a.jpg");
which gives me that error I stated before for x86. For x64 it
simply crashes and no exception is given.
If I use a dummy image I get the same error:
"Unhandled exception: glib.GException.GException The resource at
“C:\adf.jpg” does not exist at
generated\gtkd\glib\GException.d(40)"
The error message makes look like like it should be
"Unhandled exception: glib.GException.GException The resource at
“C:\adf.jpg” does not exist at “C:\”
generated\gtkd\glib\GException.d(40)"
I'd rather use Pixbuf than image because I don't need to generate
a full blow image widget.
If I do
GError* err = null;
auto p = gdk_pixbuf_new_from_resource(Str.toStringz("C:\\a.jpg"),
);
p is null and err is
The resource at “D:\a.jpgâ€. does not exist.
which is clearly not true.
So not sure what is going on ;/ Seems to be a bug in pixbuf or am
I specifying the path wrong? If gtk.Image uses these internally
then it is working so...
Re: Bug in gtkd?
On Thursday, 3 August 2017 at 15:11:46 UTC, Mike Wey wrote: On 03-08-17 05:00, Johnson Jones wrote: On Wednesday, 2 August 2017 at 14:51:45 UTC, Mike Wey wrote: On 02-08-17 08:04, Johnson Jones wrote: Ok, Using msys I was able to get glade 3.20 running. Maybe that will fix everything. Great, unfortunately "Use msys2" seems to be the official way to install anything GTK related on windows. ... Also, I cannot seem to load a jpg using an imageview (test.exe:1628): Gtk-[1;33mWARNING[0m **: Could not load image 'a.jpg': Couldn't recognize the image file format for file 'a.jpg' Just a normal jpg. Tried a bmp, same thing. It shows fine in glade itself. It looks like the pixbuf loaders are missing from the installer. Ok, so, I linked the gtk to the msys gtk that I installed before when trying to get glade to work and it worked! seems that msys is much more up to date than anything else as it just works(I need to remember than in the future). The problem I see is this: When I get ready to release my app to the public, I can't expect them to all have to install msys and build. msys seems to clump everything together and I don't know what files I need to extract to be able to bundle everything together. Any ideas how to solve that problem? At least now I can move ahead and actually make some progress on my app. Would still be nice to get the x86 vs x64 issue resolved so I don't have to keep switching between the two for testing purposes. Since Visual D was just patched to handle x64 BP's I guess I can stay with that for now.
Re: Bug in gtkd?
On Thursday, 3 August 2017 at 15:11:46 UTC, Mike Wey wrote: On 03-08-17 05:00, Johnson Jones wrote: On Wednesday, 2 August 2017 at 14:51:45 UTC, Mike Wey wrote: On 02-08-17 08:04, Johnson Jones wrote: Ok, Using msys I was able to get glade 3.20 running. Maybe that will fix everything. Great, unfortunately "Use msys2" seems to be the official way to install anything GTK related on windows. ... Also, I cannot seem to load a jpg using an imageview (test.exe:1628): Gtk-[1;33mWARNING[0m **: Could not load image 'a.jpg': Couldn't recognize the image file format for file 'a.jpg' Just a normal jpg. Tried a bmp, same thing. It shows fine in glade itself. It looks like the pixbuf loaders are missing from the installer. I tried to use the mingw version of gtk with no luck. It first looks in C:\MinGW even though I have MinGW installed somewhere else. Using a junction doesn't help becomes then it when it finds the dll it has missing symbols "The Procedure Entry Point gdk_pixbuf_gettext could not be located in the dynamic link library C:\MinGW\lib\gdk-pix-buf-2.0\2.10.0\loaders\libpixbufloader-gdip-jpeg.dll". I actually just copied over the loaders rather than using the full gtk mingw install because when I do that it complains about some lib??svg missing. I guess one can't mix mingw installs with non-mingw... but the gtk mingw install is incomplete too ;/ I hope this isn't going to be an on going thing... seems I've wasted quite a bit of time to try and get gdk to work. I probably could have written my own gui by now.
Re: Visual D no bp's on x64
On Thursday, 3 August 2017 at 07:06:06 UTC, Rainer Schuetze wrote: On 31.07.2017 19:51, Johnson Jones wrote: On Saturday, 22 July 2017 at 12:54:17 UTC, Rainer Schuetze wrote: On 18.06.2017 20:25, Mike B Johnson wrote: [...] After installing VS2017 on a fresh Win10 install I could reproduce this issue: the mago debug engine failed to load the symbols when only VS2017 is installed, because the COM-CLSID to load msdia140.dll changed. Switching to the VS debug engine worked, though. Should be fixed in the next release. I installed a fresh VS2017 and the latest beta visual D and same issues. As of today, was this suppose to be fixed? It hasn't been released until now: https://github.com/dlang/visuald/releases/tag/v0.45.0 Thanks! Seems to be working.
Re: gtkD load images
On Thursday, 3 August 2017 at 13:12:03 UTC, Mengu wrote:
On Thursday, 3 August 2017 at 03:59:40 UTC, Johnson Jones wrote:
How can be use gtkD to load images, I assume through
gdkpixbuf? While I am getting errors loading images through
glade's image:
(test.exe:8188): Gtk-[1;33mWARNING[0m **: Could not load
image 'a.jpg': Couldn't recognize the image file format for
file 'test\a.jpg'
(loads fine in glade)
which needs to be resolved, I'd also like to be able to use
gdkpixbuf to load images programmatically. There seems to be
no demos on the gtkD github page that deals with image loading.
I've tried to do something like
import gtkc.gdkpixbuf;
auto x = c_gdk_pixbuf_get_formats().data;
but I don't know how to interpret x.
Also something like
import gtkc.gdkpixbuf;
void* x;
auto p = c_gdk_pixbuf_get_formats();
for(int i = 0; i < 10; i++)
{
x = p.data;
p = p.next;
}
which doesn't offer any help.
Aside: How can we call the gtk functions directly using gtkD?
Seems it uses stuff like
Linker.link(gdk_pixbuf_get_formats, "gdk_pixbuf_get_formats",
LIBRARY_GDKPIXBUF);
It does seem to alias to these function but something is off
and I'm not sure what.
hi
- is the gtk.Image class not working for you?
https://api.gtkd.org/gtkd/gtk/Image.html
- there's also a gdkpixbuf.Pixbuf that you can use.
https://api.gtkd.org/gtkd/gdkpixbuf/Pixbuf.html
- you can import those functions from gdkpixbuf.c.functions.
no, they are not... I haven't tried though, but there seems to be
a problem with the pixbuf not having loaders for any images.
using a gtk Image widget does not load the image and complains
about the image format.
If I do something like
import gdkpixbuf.Pixbuf;
Pixbuf.newFromResource("C:\\a.jpg");
Unhandled exception: glib.GException.GException The resource at
'C:\a.jpg' does not exist at generated\gtkd\glib\GException.d(40)
occurred
which doesn't seem to make much sense.
The resource exists where I say it is and not sure if this is
related to the missing pixbuf loaders.
