FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

compiler error
Goto page 1, 2  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Forum Index -> DWT
View previous topic :: View next topic  
Author Message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Sat May 22, 2004 11:32 pm    Post subject: compiler error Reply with quote

I'm getting an error from the compiler that I don't understand, and would appreciate any help. The error is:

Code:
'this' is required, but OS is not a base class of Decorations


The error is on the return OS.DefMDIChildProc() line.

decorations.d:
----------------------------
Code:

public class Decorations : Canvas {

    int callWindowProc (int msg, int wParam, int lParam) {
        return OS.DefMDIChildProc (handle, msg, wParam, lParam);
    }

}


os.d
----------------------------
Code:

class OS {

    int DefMDIChildProc (int hWnd, int Msg, int wParam, int lParam) {
        if (IsUnicode) return DefMDIChildProcW (hWnd, Msg, wParam, lParam);
        return DefMDIChildProcA (hWnd, Msg, wParam, lParam);
    }

}

_________________
I really like the vest!
Back to top
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Sun May 23, 2004 2:34 am    Post subject: Reply with quote

The method needs to be static. In fact, I think every method of the OS class needs to be static.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Sun May 23, 2004 2:43 am    Post subject: Reply with quote

Based on Mike Swieton's identical comment in the NG, I made the method in OS class static, and it still didn't work.

I got farther by adding an instance of the class. It only appears to be a problem for some methods.
Code:

OS os;

os.SendMessage(...)

I don't think this is ideal, but it did allow me to get further.
_________________
I really like the vest!
Back to top
View user's profile Send private message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Sun May 23, 2004 10:37 pm    Post subject: Reply with quote

Okay, I abandoned instantiating an OS object, and made the methods static. This only worked because I also made the OS class static as well. Maybe no-brainers for most, but the SWT object in Java wasn't and maybe that's not required in Java.

Oh well, I'm getting farther Smile
_________________
I really like the vest!
Back to top
View user's profile Send private message
Blandger



Joined: 21 May 2004
Posts: 50
Location: Ukraine, Kharkov

PostPosted: Mon May 24, 2004 2:02 am    Post subject: Zelots of errors and changes. 'Porting guide' Reply with quote

brad wrote:
Oh well, I'm getting farther Smile

Me to.
-------
Hi all.

I've spent all weekend trying to catch up DWT sources (branch 0.1) Brad had given me week ago by mail as I dont' have webDAV support from my ISP this time. But sources were runing away from me and I didn't catch them up. Sad

Oh folks, it was a real struggle with them. I've made a lost of changes/fixes in my local sources. But I didn't succeed in compilation all available files, especially available dwt.widgets.* files. There was HUGE fixing in the HUGE files like gc.d, diplay.d, decorations.d, os.d , now I don't remember all.

I want to share my experience about fixing errors, my thoughts, ideas. And I want to discuss some moments. I'm not familiar with C/C++, only java, so correct me if I wrong.

1. 'I think'....
It's highly essential to port ALL structs from the dwt.internal.(win32/linux)... from the start. That is made now. It's not very hard because this classes are very simple.

This time I'm not absolutely sure is it good idea to place them all in the types.d file. It's good, but is can be bad also. Try to resolve 'clashing' methods and variables, 'string types' from the different files (std.string, dwt.util.string) and you'll understand me.

2. There are some very annoyed BUGS in the OS.d, decorations.d - don't remember all files. When you get error like:

Code:
'this' is required, but OS is not a base class of Decorations
as were mentioned before in this topic.

That is because 'wrapper' method/functions in the dwt.internal.wni32.os.OS is not declared as 'static' (as in the java source).
OR
There is huge error with open/closed bracket in the OS.d. Which leads to situation when you try to use 'NON wrapped WinAPI function' (functions from the 'extern(Windows)' section) and you get 'almost' the same error. They can't be found in the static context of OS class.

Check OS.d it has a wrong structure and many functions are outside of OS's class body - 'extern(Windows)' for example. (Hope Brad have fixed it already).

3. When you have a class with a 'private import dwt.graphics.bla-bla' within class body, but then you find yourself with error like 'imported class 'FOO' is unknown', and you start write something like (for a example) within class body:

Code:

........
public dwt.graphics.image.Image getImage() {...}
........
public setImage(dwt.graphics.image.Image image) {..}
........

but not simply
Code:

public setImage(Image image) {..}


That means you have a wrong open/closed brackets in the file. The methods like that are outside the class body!! There are 2 or 3 files with such annoyed error. They are made because of inaccurate commenting code wthin classes. BE AWARE of them. Smile
It's a lack of good IDE for D with intellisense and other usefull features. Sad

4. I don't think it's good idea to change 'WinAPI' function's, method's signatures in the dwt.internal.win32.os.d from the beggining of library porting. I think it's better leave them as they are in the java source.
Something like (for example):

Code:

int GetIconFoo(int lpBlaBla, ICONSTRUCT icon, int BlaBla)

from the java code was changerd to the
Code:

int GetIconFoo(int lpBlaBla, ICONSTRUCT* icon, int BlaBla)


Because it starts *bang* in the MANY places now, it will bang later for 'new added' files/classes, and it becomes harder to fix. I think much better to make classes compile now WITHOUT such changes in the function's signatures. When we get compilled DWT we will start changing OS functions/methods signatures one by one making changes in all depended classes.

5. Tell me, pls. Is it right to work with struct variables this way.

Code:

// it's a correct code written by someone I saw in the DWT source
BITMAP* bitmap = new BITMAP(); //declare and make instance in heap??
OS.someAPIMethod(.... bitmap ...); //call function
//because it was changed from 'java' to 'D' as: someAPIMethod(.... BITMAP* lpBitmap ...)

is it correct write simply
Code:

// Is it a incorrect code? It compiles but is it runs?
BITMAP bitmap; //just declare it and make instance in stack??
OS.someAPIMethod(.... bitmap ...); //call function
// it's sa it was in the 'java' source: someAPIMethod(.... BITMAP lpBitmap ...)

in order DO NOT change methods in the OS this time but make them later


6. There was some changed variable's names, because they clash with methods names in the 2-3 files. Something like:

Code:

int WindowProc; //clashes with similar method name

to the
Code:

int WindowProcInt; // doesn't clash now



7. I found myself, it's better take *.java stuff, comment out all implicit import directives in the java source and then copy 'SomeClass.java' to the 'someclass.d' stuff.

Code:

// comment out implicit import
//import  org.eclipse.swt.*;

Then make explicit import for ALL classes. Because java IDE makes it 'for free':
Code:

import  org.eclipse.swt.Class1;
import  org.eclipse.swt.Class2;
...
import  org.swt.eclipse.ClassN;

It's easier to insert them all in the D source later as:
Code:

class {...
  private {
    import dwt.graphics.module1;
    import dwt.graphics.module2;
    ....
  }
...
}

8. Don't remember something more... Will remember later.

Now I stuck with 'clash' again in the 'decorations.d' and can't find this clashed function/method anythere. So I don't know how to fix it... drag...Crying or Very sad Actually, it's hard to FIND WHERE clashing happens sometimes because of 'poor' explanation from the D compiler. Sad

For example: try to decomment in the dwt.internal.win32.OS.d file ONLY ONE function, it's called like Rectangle(.....) and you'll get a lots of errors, but you won't know where they are EXACTLY situated !! Smile The collisions will be in the lots of other project's files which use dwt.graphics.rectangle module with Rectangle class. So you have to start search and resolve all Rectagle class usage in the ALL DWT source files.

PS.
I hope to compile current dwt.widgets.* files by the end of this week if I can.
_________________
Regards, Yuriy
Back to top
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Mon May 24, 2004 1:15 pm    Post subject: Reply with quote

re 4:

This has to be done sooner or later. It's not at all optional, since those calls go straight to win32.

re 5:

Code:
// it's a correct code written by someone I saw in the DWT source
BITMAP* bitmap = new BITMAP(); //declare and make instance in heap??
OS.someAPIMethod(.... bitmap ...); //call function

Maybe that was me. It should probably be
Code:
BITMAP bm;
OS.GetObject(hBitmap, BITMAP.size, &bm);

or
Code:
auto BITMAP* bm = new BITMAP();
OS.GetObject(hBitmap, BITMAP.size, bm);

_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Mon May 24, 2004 1:39 pm    Post subject: Reply with quote

Andy,

Are you saying that for Yuriy's #4, we're going to have to supply the WinAPI calls with pointers to those structs? Is it because that's what happens with Java by default for a class, but it's a necessary change to switch to the pointers in D?

Yuriy,

I have made a lot of changes myself, mostly to os.d and menuitem.d, but to a lot of other widgets in smaller ways.

os.d now has all static calls, but I don't believe I've changed the scope of the extern (Windows) block.

For #5
I too was running into the structs being created on the heap (attempting to), and changed it to what you suggested.
Code:

BITMAP bm;

However, calls to bm later in code (in some WinAPI calls) were then expecting pointers in os.d, so I changed it to
Code:

BITMAP* bm;

And then things compiled, but I felt like the code was getting more out of whack from SWT. A lot of the MoveMemory calls were expecting 'int' for the sizeof members in the old Java classes. Well now in D, the struct.sizeof is a uint. So I started doing cast(int) before the struct.sizeof, and those began to look like ugly hacks.

I think I'm in agreement on reverting back to the way OS.java is set up, but I fear we will run into the roadblocks that Andy has mentioned, and has tried to circumvent in his code.

Andy, any way you could post some explanations on why the switch to pointers for the structs and your reasoning for trying to consolidate the MoveMemory calls in os.d to:
Code:

    // :P
    void MoveMemory(void* destination, void* source, int length);


I can get on board with this if I know what to change all of the references to in the widgets code. (See work in menuitem.d) When the other MoveMemory wrappers are commented out, the code using structs doesn't like it. I'll try to jump online later and get some other examples posted to this thread.

Yuriy, we've been doing the same work, and should try to synchronize our efforts a little better. Can you browse the SVN repos? http://svn.dsource.org/svn/projects/dwt/branches/0.1/src/dwt/internal/win32/os.d

It's not as good as checking it out with a SVN client, but it may show you the current code...
_________________
I really like the vest!
Back to top
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Mon May 24, 2004 2:39 pm    Post subject: Reply with quote

brad wrote:
Andy,

Are you saying that for Yuriy's #4, we're going to have to supply the WinAPI calls with pointers to those structs? Is it because that's what happens with Java by default for a class, but it's a necessary change to switch to the pointers in D?

Exactly.

Java has no direct support for this sort of thing at all, so it has this big elaborate wrapper that goes between object instances and pointers to C structs. D has no need of such a thing; we can connect directly to the metal.

brad wrote:
... I felt like the code was getting more out of whack from SWT. A lot of the MoveMemory calls were expecting 'int' for the sizeof members in the old Java classes. Well now in D, the struct.sizeof is a uint. So I started doing cast(int) before the struct.sizeof, and those began to look like ugly hacks.

MoveMemory is completely unneeded: D can do better. Just use a slice assignment:
dest[0 .. length] = src[0 .. length];

Or, in the case of single struct instances being copied, a assignment.

brad wrote:
I think I'm in agreement on reverting back to the way OS.java is set up, but I fear we will run into the roadblocks that Andy has mentioned, and has tried to circumvent in his code.

Andy, any way you could post some explanations on why the switch to pointers for the structs...

In the case of OS.d itself, it's what win32 demands, so there's no option there.

In some of dwt.graphics, I recall using auto'd pointers instead of stack instances merely for the sake of syntax. Those structs are never passed by value anyway, so it amounted to fewer *s and &s. Other than that, there's no reason they couldn't be allocated on the stack.

brad wrote:
...and your reasoning for trying to consolidate the MoveMemory calls in os.d to:
Code:

    // :P
    void MoveMemory(void* destination, void* source, int length);


I can get on board with this if I know what to change all of the references to in the widgets code. (See work in menuitem.d) When the other MoveMemory wrappers are commented out, the code using structs doesn't like it. I'll try to jump online later and get some other examples posted to this thread.

All pointers can be implicitly converted to void*, so the one method fits all.

Like I said, though, MoveMemory is completely extraneous. It may save some porting headaches to have one around, but I doubt it. (I'm willing to be convinced otherwise)
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
Blandger



Joined: 21 May 2004
Posts: 50
Location: Ukraine, Kharkov

PostPosted: Tue May 25, 2004 2:26 am    Post subject: Reply with quote

andy wrote:
re 4:
This has to be done sooner or later. It's not at all optional, since those calls go straight to win32.

I think it's better make it later.

andy wrote:

Code:
BITMAP bm;
OS.GetObject(hBitmap, BITMAP.size, &bm);


I like it more.

brad wrote:

I have made a lot of changes myself, mostly to os.d and menuitem.d, but to a lot of other widgets in smaller ways.
os.d now has all static calls, but I don't believe I've changed the scope of the extern (Windows) block.

May be. When you'll come to code that uses 'direct' WinAPI calls wtihout 'wrapper' methods you see if something is wrong.

brad wrote:

I think I'm in agreement on reverting back to the way OS.java is set up, but I fear we will run into the roadblocks that Andy has mentioned, and has tried to circumvent in his code.

I can't insist but I'm second, approve this way. But just for the beggining. Later we will change API call signatures but let it be LATER. It will be more simple - changing one by one API call signature in the OS.d and it will show all usages in the depended classes.
But this time it's a little hard (as for me) start change code in the widgets.* files , because that are lot of places where they 'bang'.

So my recent new. It seems I'm on the finish with current windget classes. Now I don't have a syntactical errors in any widgets classes (I suppose so). Anyway now I know almost all 'typical' errors from java code and how to change them for D for compiler (not for running of course). But I fell into 'old' error. It's a forward reference in the composite.d again !! Sad

Brad, I looked at your OS.d and I can assume that you are a little bit far from finish then I am. Soon or later you'll come to the changing this:
Code:

static bool SetWindowText (int hWnd, TCHAR lpString) {
if (IsUnicode) {
>> !!! char [] lpString1 = lpString == null ? null : lpString.chars; // compiler fails here
return SetWindowTextW (hWnd, lpString1);
}
>> !!! byte [] lpString1 = lpString == null ? null : lpString.bytes; // compiler fails here
return SetWindowTextA (hWnd, lpString1);
}

I've made it this morning before go to job. It seems to me those are 'almost last' errors though I'm not absolutely sure.

This is my today's compiler log. Sorry for this long listing. I've slightly changed SConscrut file for the compiling dwt.internal.win32.* before the widgets files:
Code:

dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofHelloDWT.obj HelloDWT.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\dwt.obj dwt\dwt.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\dwtmain.obj dwt\dwtmain.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\cloneablecompatibility.obj dwt\internal\cloneablecompatibility.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\callback.obj dwt\internal\callback.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\all.obj dwt\internal\all.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\compatibility.obj dwt\internal\compatibility.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\library.obj dwt\internal\library.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\platform.obj dwt\internal\platform.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\types.obj dwt\internal\types.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\serializablecompatibility.obj dwt\internal\serializablecompatibility.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\os.obj dwt\internal\win32\os.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\createstruct.obj dwt\internal\win32\createstruct.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\drawitemstruct.obj dwt\internal\win32\drawitemstruct.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\lresult.obj dwt\internal\win32\lresult.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\dllversioninfo.obj dwt\internal\win32\dllversioninfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\all.obj dwt\internal\win32\all.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\msg.obj dwt\internal\win32\msg.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\scrollinfo.obj dwt\internal\win32\scrollinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\tchar.obj dwt\internal\win32\tchar.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\wndclass.obj dwt\internal\win32\wndclass.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\accel.obj dwt\internal\win32\accel.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmhdr.obj dwt\internal\win32\nmhdr.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\rect.obj dwt\internal\win32\rect.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\types.obj dwt\internal\win32\types.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\paintstruct.obj dwt\internal\win32\paintstruct.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\iconinfo.obj dwt\internal\win32\iconinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\windowpos.obj dwt\internal\win32\windowpos.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\tvitem.obj dwt\internal\win32\tvitem.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\tvinsertstruct.obj dwt\internal\win32\tvinsertstruct.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\tvhittestinfo.obj dwt\internal\win32\tvhittestinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\trackmouseevent.obj dwt\internal\win32\trackmouseevent.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\tcitem.obj dwt\internal\win32\tcitem.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\tbbuttoninfo.obj dwt\internal\win32\tbbuttoninfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\sipinfo.obj dwt\internal\win32\sipinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\shmenubarinfo.obj dwt\internal\win32\shmenubarinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\shellexecuteinfo.obj dwt\internal\win32\shellexecuteinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\shactivateinfo.obj dwt\internal\win32\shactivateinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\rebarbandinfo.obj dwt\internal\win32\rebarbandinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\openfilename.obj dwt\internal\win32\openfilename.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nonclientmetrics.obj dwt\internal\win32\nonclientmetrics.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmtvcustomdraw.obj dwt\internal\win32\nmtvcustomdraw.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmcustomdraw.obj dwt\internal\win32\nmcustomdraw.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmtoolbar.obj dwt\internal\win32\nmtoolbar.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmrebarchevron.obj dwt\internal\win32\nmrebarchevron.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmlvdispinfo.obj dwt\internal\win32\nmlvdispinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmlistview.obj dwt\internal\win32\nmlistview.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\measureitemstruct.obj dwt\internal\win32\measureitemstruct.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\lvitem.obj dwt\internal\win32\lvitem.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\lvhittestinfo.obj dwt\internal\win32\lvhittestinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\initcommoncontrolsex.obj dwt\internal\win32\initcommoncontrolsex.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\hditem.obj dwt\internal\win32\hditem.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\gradientrect.obj dwt\internal\win32\gradientrect.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\dropfiles.obj dwt\internal\win32\dropfiles.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\docinfo.obj dwt\internal\win32\docinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\compositionform.obj dwt\internal\win32\compositionform.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\comboboxinfo.obj dwt\internal\win32\comboboxinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\choosefont.obj dwt\internal\win32\choosefont.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\browseinfo.obj dwt\internal\win32\browseinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\bitmapinfoheader.obj dwt\internal\win32\bitmapinfoheader.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\choosecolor.obj dwt\internal\win32\choosecolor.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\filetime.obj dwt\internal\win32\filetime.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\gcpresults.obj dwt\internal\win32\gcpresults.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\helpinfo.obj dwt\internal\win32\helpinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\logbrush.obj dwt\internal\win32\logbrush.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\lvcolumn.obj dwt\internal\win32\lvcolumn.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\monitorinfo.obj dwt\internal\win32\monitorinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmheader.obj dwt\internal\win32\nmheader.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmrginfo.obj dwt\internal\win32\nmrginfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\printdlg.obj dwt\internal\win32\printdlg.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\shrginfo.obj dwt\internal\win32\shrginfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\tbbutton.obj dwt\internal\win32\tbbutton.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\toolinfo.obj dwt\internal\win32\toolinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\bitmap.obj dwt\internal\win32\bitmap.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\logfont.obj dwt\internal\win32\logfont.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmttdispinfo.obj dwt\internal\win32\nmttdispinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\osversioninfo.obj dwt\internal\win32\osversioninfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\textmetric.obj dwt\internal\win32\textmetric.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\nmlvcustomdraw.obj dwt\internal\win32\nmlvcustomdraw.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\menuinfo.obj dwt\internal\win32\menuinfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\menuiteminfo.obj dwt\internal\win32\menuiteminfo.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\util\all.obj dwt\util\all.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\util\util.obj dwt\util\util.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\util\runnable.obj dwt\util\runnable.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\util\string.obj dwt\util\string.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\util\throwable.obj dwt\util\throwable.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\imageloader.obj dwt\graphics\imageloader.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\gc.obj dwt\graphics\gc.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\color.obj dwt\graphics\color.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\drawable.obj dwt\graphics\drawable.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\fontdata.obj dwt\graphics\fontdata.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\rgb.obj dwt\graphics\rgb.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\imagedata.obj dwt\graphics\imagedata.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\rectangle.obj dwt\graphics\rectangle.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\cursor.obj dwt\graphics\cursor.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\font.obj dwt\graphics\font.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\devicedata.obj dwt\graphics\devicedata.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\fontmetrics.obj dwt\graphics\fontmetrics.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\device.obj dwt\graphics\device.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\image.obj dwt\graphics\image.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\point.obj dwt\graphics\point.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\palettedata.obj dwt\graphics\palettedata.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\gcdata.obj dwt\graphics\gcdata.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\region.obj dwt\graphics\region.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\graphics\IDrawable.obj dwt\graphics\IDrawable.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\widgets\display.obj dwt\widgets\display.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\widgets\decorations.obj dwt\widgets\decorations.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\widgets\scrollable.obj dwt\widgets\scrollable.d
dwt\widgets\composite.d(51): class Composite is forward referenced
................. [b]THERE are 77 times this line in the log[/b]
dwt\widgets\composite.d(51): class Composite is forward referenced
scons: building terminated because of errors.

The compiler points to the code line:
Code:

public class Composite : Scrollable {


This evening I'll try to play with moving 'private import' from one place to other in classes but I'm not sure if it helps. Can you suggest something?
_________________
Regards, Yuriy
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue May 25, 2004 8:27 am    Post subject: Reply with quote

I'm back (and unfortunately recovering from yet another flu of sorts). It seems you guys have been making some headway.

One question... why are you compiling each source file separately like...

Code:
...
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\all.obj dwt\internal\win32\all.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\msg.obj dwt\internal\win32\msg.d
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofdwt\internal\win32\scrollinfo.obj dwt\internal\win32\scrollinfo.d
...


Is this the way Scons does it? If so, you may eliminate some of these forward references by compiling all source files on a single command line.... or at least module directories at a time. It seems the compiler still expects some combined compiles in order to sort out referencing issues.

Scons may not be able to do this right now. Resorting to a tedious makefile may still be necessary for the time being.
Back to top
View user's profile Send private message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Tue May 25, 2004 8:45 am    Post subject: Reply with quote

Yes, SCons does it this way.

You may be right that one makefile could be the way to go, but if, in the end, they both work the same I'm not sure it matters. If anything we should be using the one that tells us more about where to start looking for issues.

I usually start at the bottom of my scons build results and look into that file. Within that file, I'll follow the imports and try to compile them individually from a command-line. This usually gets me farther.

DMD is much improved for recursing down import trees in the latest versions.

John, I'm not sure what to tell you about where to look at our progress. I feel I've made some in the /branches/0.1 repos, but Yuriy has some files as well.

Maybe Yuriy, you can send yours and we can do some diffs and merge your code in? Maybe after your widgets milestone?
_________________
I really like the vest!
Back to top
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Tue May 25, 2004 9:44 am    Post subject: Reply with quote

I stand corrected on MoveMemory. The overloads involving TCHAR copy either chars or wchars, depending on whether unicode is enabled.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
Blandger



Joined: 21 May 2004
Posts: 50
Location: Ukraine, Kharkov

PostPosted: Tue May 25, 2004 12:36 pm    Post subject: Reply with quote

Today's evening news. I made a 'big progress' today - nothing compiles anymore, forward reference errors are increased from 79 up to the 134. Smile

1. I cleaned up all obj by Scons script, builded project several times fixing minor 'private imports' by a way.

2. I moved all 'private import' directives above class body's declarations in all widgets files. It helped a little. Forw.ref. just moved to the dwt\widgets\scrollable.d

Now nothing compiles, even internal.win32.* Smile I'm just getting f.ref. error:
Code:

scons: Building targets ...
dmd -I. -IC:\dmd\src\phobos -version=Win32 -c -ofHelloDWT.obj HelloDWT.d
dwt\widgets\scrollable.d(34): class Scrollable is forward referenced
......// and 132 lines on forward reference error here
dwt\widgets\scrollable.d(34): class Scrollable is forward referenced
scons: building terminated because of errors.

Compiler points to:
public abstract class Scrollable : Control {...


brad wrote:
You may be right that one makefile could be the way to go, but if, in the end, they both work the same I'm not sure it matters.

Agree. I've tried makefile in the beggining and it was a more headache but error was the same - f.ref. Today I've read you post and started fixing the makefile when I understood it's beyond of my forces.

brad wrote:
DMD is much improved for recursing down import trees in the latest versions.

Now I'm having some doubts in that. Sad

brad wrote:
Maybe Yuriy, you can send yours and we can do some diffs and merge your code in? Maybe after your widgets milestone?

Not a problem I'll send it this days. But I think it will be really hard to merge them as we had a completely different approaches. Mine approach was worse becase I changed many (but to all) winAPI call in the OS.d back to the java calling conventions, fixing other classes 'back to java' OS calls.
My goal was to get compiled files asap. And you know that I have now.

As I see Andy was making changes in a 'right' way fixing code to 'real calls' and I'm greeting this way because it's a right way. But using this way we can reach 'the same hole' after a couple of months (or less). May be it's not bad because compiler will be improved during this time. But forw.ref. is 'fundamental' error for me now in DWT. Better to solve it as early as it possible.

So I don't have any clue what to do now. I'm having this steady error and don't know how to work it around. Any comments and suggestions are welcome.
Went to bed. Good dreams make good ideas.
_________________
Regards, Yuriy
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue May 25, 2004 12:58 pm    Post subject: Reply with quote

Maybe the compiler changes have made things different. I haven't tried it since, so I may not understand the situation completely. For my own experiments, I may stick with the makefile for now merely to maintain a fine control over the compilation process. From what I see, Scons seems so easy to use, such that it will never be an issue setting it up to compile this project sooner or later. The only problem is that it substitutes ease of use for fine control.

A question:

Blandger wrote:
Compiler points to:
public abstract class Scrollable : Control {...


Why is "abstract" being used in the class declaration? Has the compiler been updated to support this? Last I checked delcaring a class abstract in this manner accomplished absolutely nothing. Members within the class have to be declared abstract to accomplish this. Just wondering if this is a recent change.

Later guys,

John
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue May 25, 2004 3:48 pm    Post subject: Reply with quote

You guys are right. It appears that single compilation works fine for the most part. In fact, it allows me to compile some of the directories that I couldn't do before. For example, I've had lots of trouble trying to compile the graphics directory all at once without crashing the compiler. It apparantly chokes on the volume (ongoing issue still present in 0.90). But when I manually single compile the files, everything gets compiled without a hitch as long as I am do it from the correct base directory. So, it appears that the multi-file-compile method has it's own set of challenges....
Back to top
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Forum Index -> DWT All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group