View mode: basic / threaded / horizontal-split · Log in · Help
December 06, 2003
Dig broken
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
December 06, 2003
Re: Dig broken
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
December 06, 2003
Re: Dig broken
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
December 06, 2003
Re: Dig broken
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/
December 07, 2003
Re: Dig broken
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
December 07, 2003
Re: Dig broken
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
December 07, 2003
Re: Dig broken
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
December 07, 2003
Re: Dig broken
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
December 07, 2003
Re: Dig broken
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
December 07, 2003
Re: Dig broken
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 . . .
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home