I'm having trouble using dig in version 0.76.
Has anyone got it working in 0.76?

By downloading the dig libs that comes with Charles Sanders latest DIDE, I can at least get it to compile.  However, I get an "access violation" at run time.

Also how do I compile Dig?  I tried running the make but I get.
Error: Error reading file 'win32\windef.d'
MAKE : fatal error U1077: 'c:\dmd\bin\digc' : return code '0x1'

Thanks

J Anderson wrote:

> I'm having trouble using dig in version 0.76.
> Has anyone got it working in 0.76?
>
> By downloading the dig libs that comes with Charles Sanders latest DIDE, I can at least get it to compile.  However, I get an "access violation" at run time.
>
> Also how do I compile Dig?  I tried running the make but I get.
> Error: Error reading file 'win32\windef.d'
> MAKE : fatal error U1077: 'c:\dmd\bin\digc' : return code '0x1'
>
> Thanks
>
Ok now I get:
Error: Error reading file 'stream.d'

I put in the std.(for import) and the op (for operators). I've attached my changes.

Any ideas?

-Anderson

J Anderson wrote:
> J Anderson wrote:
> 
>> I'm having trouble using dig in version 0.76.
>> Has anyone got it working in 0.76?
>>
>> By downloading the dig libs that comes with Charles Sanders latest DIDE, I can at least get it to compile.  However, I get an "access violation" at run time.
>>
>> Also how do I compile Dig?  I tried running the make but I get.
>> Error: Error reading file 'win32\windef.d'
>> MAKE : fatal error U1077: 'c:\dmd\bin\digc' : return code '0x1'
>>
>> Thanks
>>
> Ok now I get:
> Error: Error reading file 'stream.d'
> 
> I put in the std.(for import) and the op (for operators). I've attached my changes.

I'm not sure how broken DIG is.  A number of significant changes have occurred to DMD since Burton Radons last posted in this newsgroup.

If you just want to use DIGC, I have a modified version that will compile (I don't really know if it run correctly, though).  As far as the rest of DIG, well, I've had a lot of problems due to the new library names (std.stream, std.c.windows.windows, etc.).  I'm afraid the rest of DIG my be very broken.

At this point the compiler error messages have gotten very cryptic:

net\BurtonRadons\dig\platform\base.d(8): import std conflicts with windows.std at net\BurtonRadons\dig\platform\windows.d(7)

Going to the given lines and it doesn't shed any light on the problem for me, and I've given up trying to fix it.  I'll probably post my work to my webpage sometime later today in case someone is interested.

Justin
http://jcc_7.tripod.com/d/


> 
> Any ideas?
> 
> -Anderson

J C Calvarese wrote:
> ... I'll probably post my work to my webpage sometime later today in case someone is interested.

My modified version is now up at:
http://jcc_7.tripod.com/d/dig.html

> 
> Justin
> http://jcc_7.tripod.com/d/

J C Calvarese wrote:

> J C Calvarese wrote:
>
>> ... I'll probably post my work to my webpage sometime later today in case someone is interested.
>
>
> My modified version is now up at:
> http://jcc_7.tripod.com/d/dig.html
>
>>
>> Justin
>> http://jcc_7.tripod.com/d/
>

Thanks.
I'm most interested in the opengl side of things.  I'll try a bit longer.  Pitty the compiler error messages are so vague.

Anderson

J Anderson wrote:

> J C Calvarese wrote:
>
>> J C Calvarese wrote:
>>
>>> ... I'll probably post my work to my webpage sometime later today in case someone is interested.
>>
>>
>>
>> My modified version is now up at: http://jcc_7.tripod.com/d/dig.html
>>
>>>
>>> Justin
>>> http://jcc_7.tripod.com/d/
>>
>>
>
> Thanks.
> I'm most interested in the opengl side of things.  I'll try a bit
> longer.  Pitty the compiler error messages are so vague.
>
> Anderson
>
Ok, I've done a bit more on that, but now I'm getting:

net\BurtonRadons\dig\platform\canvasGL.d: identifier 'HANDLE' is not defined.

If I try to define it with

typedef void *HANDLE;
or
alias void *HANDLE;

I get:
net\BurtonRadons\dig\platform\canvasGL.d(350): function wglMakeCurrent
(HANDLE hdc,HANDLE hglrc) does not match argument types (HANDLE ,HANDLE )

I don't know what type handle should be. I can't import std.c.windows.windows, as that brings a std conflict.

PS - This time I've only included the source. It's based of J C Calvarese version.

-Anderson

Hi!
Look at Charles Sanders DIDE site. He is working
on replacing DIG. Maybe you'll be interested.
BTW, I'm interested in openGL side of thing too.

Albin

I had gone as far as JC, but I decided to spend a couple of hours trying and
these are the results.
I removed the private import std.c.windows.windows; from
net.BurtonRadons.dig.platform.windows, and instead included the whole file
(kinda desperate, isn't it?). Then I had to comment out some duplicated
names, add all the 'std.' where needed, change the names of the operator
overloadings, and then voila!, the dig library compiled (yes, with dmd
0.76). However, there seems to be a problem with that solution, or with the
dig stripper because when trying to compile diggl, the expanded dig (under
digc_temp) doesn't work properly.
Anyway, in http://earth.prohosting.com/carlos3/ you can find the zip
file containing my advance.

-------------------------
Carlos Santander



---

Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.545 / Virus Database: 339 - Release Date: 2003-11-27

Carlos Santander B. wrote:
> I had gone as far as JC, but I decided to spend a couple of hours trying and
> these are the results.
> I removed the private import std.c.windows.windows; from
> net.BurtonRadons.dig.platform.windows, and instead included the whole file
> (kinda desperate, isn't it?). 
My motto is: If it works, it's right.

> Then I had to comment out some duplicated
> names, add all the 'std.' where needed, change the names of the operator
> overloadings, and then voila!, the dig library compiled (yes, with dmd
> 0.76). However, there seems to be a problem with that solution, or with the
> dig stripper because when trying to compile diggl, the expanded dig (under
> digc_temp) doesn't work properly.
> Anyway, in http://earth.prohosting.com/carlos3/ you can find the zip
> file containing my advance.

Thank you for uploading it.  I've looked at it some.

DIG appearently has an (undocumented?) feature that suppresses deleting the temporary stripped directories: -dontdeletetempdir.


I think I got the same error as you did with diggl:

Library diggl
Searching source for imports.
Expanding import libraries... opengl32.lib, dig.lib, comdlg32.lib, shell32.lib,
40 files and 166.17 kb expanded
d:\dmd\bin\dmd.exe -unittest -release -O -c net\BurtonRadons\dig\gl.d net\BurtonRadons\dig\common\glEnums.d net\BurtonRadons\dig\windows\canvasGL.d opengl32.lib dig.lib advapi32.lib comdlg32.lib gdi32.lib comctl32.lib shell32.lib -I\dmd\src
 -Idigc_temp

digc_temp\net\BurtonRadons\dig\platform\windows.d(191): declaration expected following attribute, not ';'
...

--- errorlevel 1


So I took a look at the DIG-produced header file (I think stripping headers is overrated).

The problem seems start at the double export ("export;export;") at line 191:

190  cFileName[260];WCHAR
191  cAlternateFileName[14];}export;export;HMODULE
192  LoadLibraryA(LPCSTR
193  lpLibFileName);FARPROC
194  GetProcAddress(HMODULE
195  hModule,LPCSTR
196  lpProcName);enum{KEY_QUERY_VALUE=0x0001,KEY_SET_VALUE=0x0002,
     KEY_CREATE_SUB_KEY=0x0004,KEY_ENUMERATE_SUB_KEYS=0x0008,
     KEY_NOTIFY=0x0010,KEY_CREATE_LINK=0x0020,KEY_READ=
     ((STANDARD_RIGHTS_READ|KEY_QUERY_VALUE|KEY_ENUMERATE_SUB_KEYS|
     KEY_NOTIFY)&~SYNCHRONIZE),KEY_WRITE=((STANDARD_RIGHTS_WRITE|
     KEY_SET_VALUE|KEY_CREATE_SUB_KEY)&~SYNCHRONIZE),KEY_EXECUTE=
     (KEY_READ&~SYNCHRONIZE),KEY_ALL_ACCESS=((STANDARD_RIGHTS_ALL|
     KEY_QUERY_VALUE|KEY_SET_VALUE|KEY_CREATE_SUB_KEY|
     KEY_ENUMERATE_SUB_KEYS|KEY_NOTIFY|KEY_CREATE_LINK)
     &~SYNCHRONIZE),}const
197  int
198  REG_CREATED_NEW_KEY=0x00000001;const


This is what the code looks like in the original windows.d:

273  struct WIN32_FIND_DATAW {
274      DWORD dwFileAttributes;
275      FILETIME ftCreationTime;
276      FILETIME ftLastAccessTime;
277      FILETIME ftLastWriteTime;
278      DWORD nFileSizeHigh;
279      DWORD nFileSizeLow;
280      DWORD dwReserved0;
281      DWORD dwReserved1;
282      WCHAR  cFileName[ 260  ];
283      WCHAR  cAlternateFileName[ 14 ];
284  }
285
286  export
287  {
288  BOOL SetCurrentDirectoryA(LPCSTR lpPathName);
289  BOOL SetCurrentDirectoryW(LPCWSTR lpPathName);
290  DWORD GetCurrentDirectoryA(DWORD nBufferLength, LPSTR lpBuffer);
291  DWORD GetCurrentDirectoryW(DWORD nBufferLength, LPWSTR lpBuffer);
292  BOOL CreateDirectoryA(LPCSTR lpPathName, LPSECURITY_ATTRIBUTES
     lpSecurityAttributes);
293  BOOL CreateDirectoryW(LPCWSTR lpPathName, LPSECURITY_ATTRIBUTES
     lpSecurityAttributes);
294  BOOL CreateDirectoryExA(LPCSTR lpTemplateDirectory, LPCSTR
     lpNewDirectory, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
295  BOOL CreateDirectoryExW(LPCWSTR lpTemplateDirectory, LPCWSTR
     lpNewDirectory, LPSECURITY_ATTRIBUTES lpSecurityAttributes);


I don't see a problem with that so I think the stripping function is confused by "export { ..."

It sounds like you've figured this out already, so I guess I'm just thinking out loud.


Justin

> 
> -------------------------
> Carlos Santander
> 
> 
> 
> ---
> 
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.545 / Virus Database: 339 - Release Date: 2003-11-27 

J C Calvarese wrote:

> Carlos Santander B. wrote:
>
>> I had gone as far as JC, but I decided to spend a couple of hours
>> trying and
>> these are the results.
>> I removed the private import std.c.windows.windows; from
>> net.BurtonRadons.dig.platform.windows, and instead included the whole
>> file
>> (kinda desperate, isn't it?).
>
> My motto is: If it works, it's right.
>
>> Then I had to comment out some duplicated
>> names, add all the 'std.' where needed, change the names of the operator
>> overloadings, and then voila!, the dig library compiled (yes, with dmd
>> 0.76). However, there seems to be a problem with that solution, or
>> with the
>> dig stripper because when trying to compile diggl, the expanded dig
>> (under
>> digc_temp) doesn't work properly.
>> Anyway, in http://earth.prohosting.com/carlos3/ you can find the zip
>> file containing my advance.
>
>
> Thank you for uploading it.  I've looked at it some.
>
> DIG appearently has an (undocumented?) feature that suppresses deleting the temporary stripped directories: -dontdeletetempdir.
>
>
> I think I got the same error as you did with diggl:
>
> Library diggl
> Searching source for imports.
> Expanding import libraries... opengl32.lib, dig.lib, comdlg32.lib,
> shell32.lib,
> 40 files and 166.17 kb expanded
> d:\dmd\bin\dmd.exe -unittest -release -O -c net\BurtonRadons\dig\gl.d
> net\BurtonRadons\dig\common\glEnums.d
> net\BurtonRadons\dig\windows\canvasGL.d opengl32.lib dig.lib
> advapi32.lib comdlg32.lib gdi32.lib comctl32.lib shell32.lib -I\dmd\src
>  -Idigc_temp
>
> digc_temp\net\BurtonRadons\dig\platform\windows.d(191): declaration
> expected following attribute, not ';'
> ....
>
> --- errorlevel 1
>
>
> So I took a look at the DIG-produced header file (I think stripping headers is overrated).
>
> The problem seems start at the double export ("export;export;") at line 191:
>
> 190  cFileName[260];WCHAR
> 191  cAlternateFileName[14];}export;export;HMODULE
> 192  LoadLibraryA(LPCSTR
> 193  lpLibFileName);FARPROC
> 194  GetProcAddress(HMODULE
> 195  hModule,LPCSTR
> 196  lpProcName);enum{KEY_QUERY_VALUE=0x0001,KEY_SET_VALUE=0x0002,
>      KEY_CREATE_SUB_KEY=0x0004,KEY_ENUMERATE_SUB_KEYS=0x0008,
>      KEY_NOTIFY=0x0010,KEY_CREATE_LINK=0x0020,KEY_READ=
>      ((STANDARD_RIGHTS_READ|KEY_QUERY_VALUE|KEY_ENUMERATE_SUB_KEYS|
>      KEY_NOTIFY)&~SYNCHRONIZE),KEY_WRITE=((STANDARD_RIGHTS_WRITE|
>      KEY_SET_VALUE|KEY_CREATE_SUB_KEY)&~SYNCHRONIZE),KEY_EXECUTE=
>      (KEY_READ&~SYNCHRONIZE),KEY_ALL_ACCESS=((STANDARD_RIGHTS_ALL|
>      KEY_QUERY_VALUE|KEY_SET_VALUE|KEY_CREATE_SUB_KEY|
>      KEY_ENUMERATE_SUB_KEYS|KEY_NOTIFY|KEY_CREATE_LINK)
>      &~SYNCHRONIZE),}const
> 197  int
> 198  REG_CREATED_NEW_KEY=0x00000001;const
>
>
> This is what the code looks like in the original windows.d:
>
> 273  struct WIN32_FIND_DATAW {
> 274      DWORD dwFileAttributes;
> 275      FILETIME ftCreationTime;
> 276      FILETIME ftLastAccessTime;
> 277      FILETIME ftLastWriteTime;
> 278      DWORD nFileSizeHigh;
> 279      DWORD nFileSizeLow;
> 280      DWORD dwReserved0;
> 281      DWORD dwReserved1;
> 282      WCHAR  cFileName[ 260  ];
> 283      WCHAR  cAlternateFileName[ 14 ];
> 284  }
> 285
> 286  export
> 287  {
> 288  BOOL SetCurrentDirectoryA(LPCSTR lpPathName);
> 289  BOOL SetCurrentDirectoryW(LPCWSTR lpPathName);
> 290  DWORD GetCurrentDirectoryA(DWORD nBufferLength, LPSTR lpBuffer);
> 291  DWORD GetCurrentDirectoryW(DWORD nBufferLength, LPWSTR lpBuffer);
> 292  BOOL CreateDirectoryA(LPCSTR lpPathName, LPSECURITY_ATTRIBUTES
>      lpSecurityAttributes);
> 293  BOOL CreateDirectoryW(LPCWSTR lpPathName, LPSECURITY_ATTRIBUTES
>      lpSecurityAttributes);
> 294  BOOL CreateDirectoryExA(LPCSTR lpTemplateDirectory, LPCSTR
>      lpNewDirectory, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
> 295  BOOL CreateDirectoryExW(LPCWSTR lpTemplateDirectory, LPCWSTR
>      lpNewDirectory, LPSECURITY_ATTRIBUTES lpSecurityAttributes);
>
>
> I don't see a problem with that so I think the stripping function is confused by "export { ..."
>
> It sounds like you've figured this out already, so I guess I'm just thinking out loud.
>
>
> Justin
>
>>
>> -------------------------
>> Carlos Santander
>>
>>
>>
>> ---
>>
>> Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.545 / Virus Database: 339 - Release Date: 2003-11-27
>
Thanks guys.
I got mine to compile before I saw those emails.  Since I don't have a
webspace, I can't upload it to a webserver (although I'll email it).
However, I get a warning message when linking.  It seems I don't have
advapi32.lib.

I don't know how much help it will be, but I've included it.

C:\dmd\bin\digc -unittest -release -O -lib=dig
net/BurtonRadons/dig/main.d net/B
urtonRadons/dig/platform/*.d net/BurtonRadons/dig/common/*.d
-not=net/BurtonRado
ns/dig/platform/canvasGL.d -not=net/BurtonRadons/dig/common/glEnums.d
advapi32.l
ib comdlg32.lib gdi32.lib comctl32.lib shell32.lib -install

------------------------------------------------------------
Library dig
Searching source for imports.
Files are not modified, skipping compilation.

C:\dmd\bin\digc -unittest -release -O -then="copy *.dll &(SystemDirectory)"

------------------------------------------------------------
Program
copy *.dll C:\WINXP\System32
libjpeg.dll
libpng.dll
libz.dll
        3 file(s) copied.

C:\dmd\bin\digc -unittest -release -O -lib=diggl
net/BurtonRadons/dig/gl.d net/B
urtonRadons/dig/common/glEnums.d
net/BurtonRadons/dig/platform/canvasGL.d opengl
32.lib -install

------------------------------------------------------------
Library diggl
Searching source for imports.
Files are not modified, skipping compilation.

rmdir /S /Q C:\dmd\src\dig
The system cannot find the file specified.
copy opengl32.lib C:\dm\lib
        1 file(s) copied.
copy shell32.lib C:\dm\lib
        1 file(s) copied.
copy glu32.lib C:\dm\lib
        1 file(s) copied.
C:\dmd\bin\digc -unittest -release -O
net/BurtonRadons/dig/examples/cartoon.d -e
xe=cartoon

------------------------------------------------------------
Program cartoon
Searching source for imports.
Files are not modified, skipping compilation.

C:\dmd\bin\digc -unittest -release -O
net/BurtonRadons/dig/examples/halhello.d -
exe=halhello

------------------------------------------------------------
Program halhello
Searching source for imports.
Files are not modified, skipping compilation.

make dedit BASEDIR=C:

------------------------------------------------------------
Program deditexec
Searching source for imports.
Files are not modified, skipping compilation.


------------------------------------------------------------
Program dedit
Searching source for imports.
Expanding import libraries... dig.lib, 40 files and 144.40 kb expanded
C:\dmd\bin\dmd.exe -unittest -release -O  dedit.exe
net\BurtonRadons\dedit\docum
ent.d net\BurtonRadons\dedit\fileCommands.d
net\BurtonRadons\dedit\findCommands.
d net\BurtonRadons\dedit\main.d net\BurtonRadons\dedit\mainCommands.d
net\Burton
Radons\dedit\options.d net\BurtonRadons\dedit\projectCommands.d
net\BurtonRadons
\dedit\projectView.d net\BurtonRadons\dedit\syntaxHighlighter.d
net\BurtonRadons
\dedit\view.d net\BurtonRadons\dedit\highlight\bat.d
net\BurtonRadons\dedit\high
light\cecil.d net\BurtonRadons\dedit\highlight\cpp.d
net\BurtonRadons\dedit\high
light\d.d net\BurtonRadons\dedit\highlight\html.d
net\BurtonRadons\dedit\highlig
ht\java.d net\BurtonRadons\dedit\highlight\makefile.d
net\BurtonRadons\dedit\hig
hlight\mango.d net\BurtonRadons\dedit\highlight\msasm.d
net\BurtonRadons\dedit\h
ighlight\python.d dig.lib advapi32.lib comdlg32.lib gdi32.lib
comctl32.lib shell
32.lib -I\dmd\src digc_manifest.res -Idigc_temp

C:\dmd\bin\..\..\dm\bin\link.exe document+fileCommands+findCommands+main+mainCom mands+options+projectCommands+projectView+syntaxHighlighter+view+bat+cecil+cpp+d +html+java+makefile+mango+msasm+python,dedit.exe,,dig.lib+advapi32.lib+comdlg32. lib+gdi32.lib+comctl32.lib+shell32.lib+user32+kernel32/RC:digc_manifest.res/noi;

OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

advapi32.lib
 Warning 2: File Not Found advapi32.lib
C:\dmd\bin\..\lib\dig.lib(registry)
 Error 42: Symbol Undefined _RegCreateKeyA@12
C:\dmd\bin\..\lib\dig.lib(registry)
 Error 42: Symbol Undefined _RegSetValueExA@24
C:\dmd\bin\..\lib\dig.lib(registry)
 Error 42: Symbol Undefined _RegCloseKey@4
C:\dmd\bin\..\lib\dig.lib(registry)
 Error 42: Symbol Undefined _RegQueryValueExA@24
--- errorlevel 4

--- errorlevel 4

--- errorlevel 4
Press any key to continue . . .