www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - Can't Link DWT in Linux 64-bit

reply "Mike" <none none.com> writes:
I'm trying to compile my single main.d program in Arch Linux 
64-bit, but it won't link, and I don't understand why.

Attempt 1:
----------
dmd source/main.d -Idwt/imp 
-Jdwt/org.eclipse.swt.gtk.linux.x86/res -L-Ldwt/lib -L--verbose 
-L-l:org.eclipse.swt.gtk.linux.x86 -L-l:dwt-base -L-lgtk-x11-2.0 
-L-lgdk-x11-2.0 -L-latk-1.0 -L-lgdk_pixbuf-2.0 -L-lgthread-2.0 
-L-lpangocairo-1.0 -L-lfontconfig -L-lXtst -L-lXext -L-lXrender 
-L-lXinerama -L-lXi -L-lXrandr -L-lXcursor -L-lXcomposite 
-L-lXdamage -L-lX11 -L-lXfixes -L-lpango-1.0 -L-lgobject-2.0 
-L-lgmodule-2.0 -L-ldl -L-lglib-2.0 -L-lcairo -L-lgnomeui-2

...
attempt to open main.o succeeded
main.o
attempt to open org.eclipse.swt.gtk.linux.x86 failed
attempt to open dwt/lib/org.eclipse.swt.gtk.linux.x86 failed
attempt to open /usr/lib/org.eclipse.swt.gtk.linux.x86 failed
...
attempt to open dwt-base failed
attempt to open dwt/lib/dwt-base failed
attempt to open /usr/lib/dwt-base failed

...
/usr/bin/ld: cannot find org.eclipse.swt.gtk.linux.x86
/usr/bin/ld: cannot find dwt-base
...

But the libs are there...
ls -al dwt/lib
total 26488
drwxr-xr-x  2 mike users     4096 Jul 13 15:02 .
drwxr-xr-x 11 mike users     4096 Jul 13 10:04 ..
-rw-r--r--  1 mike users  2216828 Jul 13 13:02 dwt-base.a
-rw-r--r--  1 mike users 24894894 Jul 13 13:02 
org.eclipse.swt.gtk.linux.x86.a


Attemp 2: Add .a to the missing lib files
attempt to open org.eclipse.swt.gtk.linux.x86.a failed
attempt to open dwt/lib/org.eclipse.swt.gtk.linux.x86.a succeeded
attempt to open /usr/lib/org.eclipse.swt.gtk.linux.x86.a failed
...
attempt to open dwt-base.a failed
attempt to open dwt/lib/dwt-base.a succeeded
attempt to open /usr/lib/dwt-base.a failed
...
/usr/bin/ld: cannot find org.eclipse.swt.gtk.linux.x86.a
/usr/bin/ld: cannot find dwt-base.a
...

It says it finds the files, but still fails to link.  All other 
libs seem to link fine.  What am I doing wrong?

Thanks,
Mike
Jul 12 2014
parent reply "Mike" <none none.com> writes:
On Sunday, 13 July 2014 at 06:24:29 UTC, Mike wrote:

 I'm trying to compile my single main.d program in Arch Linux 
 64-bit, but it won't link, and I don't understand why.

 Attempt 1:
 ----------
 dmd source/main.d -Idwt/imp 
 -Jdwt/org.eclipse.swt.gtk.linux.x86/res -L-Ldwt/lib -L--verbose 
 -L-l:org.eclipse.swt.gtk.linux.x86 -L-l:dwt-base 
 -L-lgtk-x11-2.0 -L-lgdk-x11-2.0 -L-latk-1.0 -L-lgdk_pixbuf-2.0 
 -L-lgthread-2.0 -L-lpangocairo-1.0 -L-lfontconfig -L-lXtst 
 -L-lXext -L-lXrender -L-lXinerama -L-lXi -L-lXrandr -L-lXcursor 
 -L-lXcomposite -L-lXdamage -L-lX11 -L-lXfixes -L-lpango-1.0 
 -L-lgobject-2.0 -L-lgmodule-2.0 -L-ldl -L-lglib-2.0 -L-lcairo 
 -L-lgnomeui-2

 ...
 attempt to open main.o succeeded
 main.o
 attempt to open org.eclipse.swt.gtk.linux.x86 failed
 attempt to open dwt/lib/org.eclipse.swt.gtk.linux.x86 failed
 attempt to open /usr/lib/org.eclipse.swt.gtk.linux.x86 failed
 ...
 attempt to open dwt-base failed
 attempt to open dwt/lib/dwt-base failed
 attempt to open /usr/lib/dwt-base failed

 ...
 /usr/bin/ld: cannot find org.eclipse.swt.gtk.linux.x86
 /usr/bin/ld: cannot find dwt-base
 ...

 But the libs are there...
 ls -al dwt/lib
 total 26488
 drwxr-xr-x  2 mike users     4096 Jul 13 15:02 .
 drwxr-xr-x 11 mike users     4096 Jul 13 10:04 ..
 -rw-r--r--  1 mike users  2216828 Jul 13 13:02 dwt-base.a
 -rw-r--r--  1 mike users 24894894 Jul 13 13:02 
 org.eclipse.swt.gtk.linux.x86.a


 Attemp 2: Add .a to the missing lib files
 attempt to open org.eclipse.swt.gtk.linux.x86.a failed
 attempt to open dwt/lib/org.eclipse.swt.gtk.linux.x86.a 
 succeeded
 attempt to open /usr/lib/org.eclipse.swt.gtk.linux.x86.a failed
 ...
 attempt to open dwt-base.a failed
 attempt to open dwt/lib/dwt-base.a succeeded
 attempt to open /usr/lib/dwt-base.a failed
 ...
 /usr/bin/ld: cannot find org.eclipse.swt.gtk.linux.x86.a
 /usr/bin/ld: cannot find dwt-base.a
 ...

 It says it finds the files, but still fails to link.  All other 
 libs seem to link fine.  What am I doing wrong?

 Thanks,
 Mike


Nevermind, just found out only 32-bit libs are created.
Jul 12 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-13 08:32, Mike wrote:


 Nevermind, just found out only 32-bit libs are created.


Yes, currently DWT only supports 32bit.

-- 
/Jacob Carlborg
Jul 13 2014
parent reply "Mike" <none none.com> writes:
On Sunday, 13 July 2014 at 10:00:46 UTC, Jacob Carlborg wrote:

 On 2014-07-13 08:32, Mike wrote:


 Nevermind, just found out only 32-bit libs are created.


 Yes, currently DWT only supports 32bit.


I'm using Arch Linux 64, and the multilibs are missing 
libgnomeui-2.

What are your future plans for DWT?  Are you still interested in 
investing into it or are you yielding to gtkd/qtd/etc..?

I really like the library and was able to pick it up very 
quickly.  If you're interested in putting more into it, what can 
I do to help?  Can you gude me through the changes necessarry to 
port it to 64-bit?

Mike
Jul 14 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-14 18:57, Mike wrote:


 I'm using Arch Linux 64, and the multilibs are missing libgnomeui-2.

 What are your future plans for DWT?  Are you still interested in
 investing into it or are you yielding to gtkd/qtd/etc..?


I'm currently not working on DWT. When I will do that again it will be 
on the OS X port. I'm still trying to keep it up to date with the latest 
version of DMD, reviewing pull requests and helping out here.


 I really like the library and was able to pick it up very quickly.  If
 you're interested in putting more into it, what can I do to help?  Can
 you gude me through the changes necessarry to port it to 64-bit?


Absolutely. First, there are someone else that is already working on a 
64bit port, if I understand it correctly [1]. Perhaps you could collaborate.

As for the guidance. I think it's easiest to just try and compile it for 
64bit and see what errors you get. Then I can help with more specific 
problems that you encounter.

Start by removing the "-m32" flags in build.d [2], which forces it to 
compile for 32bit. Then I would guess most errors will be for types 
declared as "int" when they should be declared as "size_t" or "ptrdiff_t".

I have no idea how the GTK and Gnome interfaces work, if they are 
different on 64bit. I didn't write the original code for DWT.

[1] http://forum.dlang.org/thread/cpmhhmslzyvtpkzsgkaj forum.dlang.org

[2] https://github.com/d-widget-toolkit/dwt/blob/master/build.d

-- 
/Jacob Carlborg
Jul 14 2014
parent reply "Mike" <none none.com> writes:
On Monday, 14 July 2014 at 19:18:46 UTC, Jacob Carlborg wrote:

 As for the guidance. I think it's easiest to just try and 
 compile it for 64bit and see what errors you get. Then I can 
 help with more specific problems that you encounter.


Well, I haven't tried to build yet, but I have been going through 
the source code, and I found something interesting.

I downloaded the swt source code for both Win32 and Win64, and 
compared them in WinMerge.

What's interesting is the source code is littered with stuff like 
this:

File: org/eclipse/swt/widgets/IME.java


SWT - Win32
*******************
LRESULT WM_KILLFOCUS (int /*long*/ wParam, int /*long*/ lParam) {
	if (!isInlineEnabled ()) return null;
	int /*long*/ hwnd = parent.handle;
	int /*long*/ hIMC = OS.ImmGetContext (hwnd);
	if (hIMC != 0) {
		if (OS.ImmGetOpenStatus (hIMC)) {
			OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR, OS.CPS_COMPLETE, 
0);
		}
		OS.ImmReleaseContext (hwnd, hIMC);
	}
	return null;
}

SWT - Win64
********************
LRESULT WM_KILLFOCUS (long /*int*/ wParam, long /*int*/ lParam) {
	if (!isInlineEnabled ()) return null;
	long /*int*/ hwnd = parent.handle;
	long /*int*/ hIMC = OS.ImmGetContext (hwnd);
	if (hIMC != 0) {
		if (OS.ImmGetOpenStatus (hIMC)) {
			OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR, OS.CPS_COMPLETE, 
0);
		}
		OS.ImmReleaseContext (hwnd, hIMC);
	}
	return null;
}


DWT
********************
LRESULT WM_KILLFOCUS (int /*long*/ wParam, int /*long*/ lParam) {
     if (!isInlineEnabled ()) return null;
     auto hwnd = parent.handle;
     auto hIMC = OS.ImmGetContext (hwnd);
     if (hIMC !is null) {
         if (OS.ImmGetOpenStatus (hIMC)) {
             OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR, 
OS.CPS_COMPLETE, 0);
         }
         OS.ImmReleaseContext (hwnd, hIMC);
     }
     return null;
}

It appears DWT has modeled any `Handle`s as `void*`, and 
therefore uses `auto` whenever possible.  I could probably do a 
search & replace for "int /*long*/" or "/*long*/ int" and replace 
it with "ptrdiff_t" and cover 80% of the necessary changes.

Thoughts?

Also, could you please answer the following questions for me?
* What version of SWT is the current DWT source code based on?
* How would you like me to submit pull requests?  
Little-by-little, or one big whopper?
* How does one go about testing DWT?

Thanks for the help.

Mike
Jul 18 2014
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-19 01:47, Mike wrote:


 Well, I haven't tried to build yet, but I have been going through the
 source code, and I found something interesting.

 I downloaded the swt source code for both Win32 and Win64, and compared
 them in WinMerge.

 What's interesting is the source code is littered with stuff like this:

 File: org/eclipse/swt/widgets/IME.java


Yes, they have a tool (or built step) that replaces "int /*long*/" with 
"long /*int*/" to convert to 64bit.


 SWT - Win32
 *******************
 LRESULT WM_KILLFOCUS (int /*long*/ wParam, int /*long*/ lParam) {
      if (!isInlineEnabled ()) return null;
      int /*long*/ hwnd = parent.handle;
      int /*long*/ hIMC = OS.ImmGetContext (hwnd);
      if (hIMC != 0) {
          if (OS.ImmGetOpenStatus (hIMC)) {
              OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR,
 OS.CPS_COMPLETE, 0);
          }
          OS.ImmReleaseContext (hwnd, hIMC);
      }
      return null;
 }

 SWT - Win64
 ********************
 LRESULT WM_KILLFOCUS (long /*int*/ wParam, long /*int*/ lParam) {
      if (!isInlineEnabled ()) return null;
      long /*int*/ hwnd = parent.handle;
      long /*int*/ hIMC = OS.ImmGetContext (hwnd);
      if (hIMC != 0) {
          if (OS.ImmGetOpenStatus (hIMC)) {
              OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR,
 OS.CPS_COMPLETE, 0);
          }
          OS.ImmReleaseContext (hwnd, hIMC);
      }
      return null;
 }


 DWT
 ********************
 LRESULT WM_KILLFOCUS (int /*long*/ wParam, int /*long*/ lParam) {
      if (!isInlineEnabled ()) return null;
      auto hwnd = parent.handle;
      auto hIMC = OS.ImmGetContext (hwnd);
      if (hIMC !is null) {
          if (OS.ImmGetOpenStatus (hIMC)) {
              OS.ImmNotifyIME (hIMC, OS.NI_COMPOSITIONSTR,
 OS.CPS_COMPLETE, 0);
          }
          OS.ImmReleaseContext (hwnd, hIMC);
      }
      return null;
 }

 It appears DWT has modeled any `Handle`s as `void*`, and therefore uses
 `auto` whenever possible.  I could probably do a search & replace for
 "int /*long*/" or "/*long*/ int" and replace it with "ptrdiff_t" and
 cover 80% of the necessary changes.

 Thoughts?


Ideally I would like that the native type is used, that's what I've done 
in the OS X port. But if the existing code uses "int /*long*/" then I 
would say it's acceptable to use "ptrdiff_t". Perhaps we want to come up 
with a new name?


 Also, could you please answer the following questions for me?
 * What version of SWT is the current DWT source code based on?


It's 3.449.0, at least according to this [1].


 * How would you like me to submit pull requests? Little-by-little, or
 one big whopper?


If possible, smaller changes. But I would prefer DWT to be buildable 
in-between pull requests.


 * How does one go about testing DWT?


[1] 
https://github.com/d-widget-toolkit/org.eclipse.swt.win32.win32.x86/blob/master/src/org/eclipse/swt/internal/Library.d#L31-L41

-- 
/Jacob Carlborg
Jul 19 2014
parent reply "Mike" <none none.com> writes:
On Saturday, 19 July 2014 at 15:04:33 UTC, Jacob Carlborg wrote:

 Ideally I would like that the native type is used, that's what 
 I've done in the OS X port. But if the existing code uses "int 
 /*long*/" then I would say it's acceptable to use "ptrdiff_t". 
 Perhaps we want to come up with a new name?


What do you mean by "native type"?  I thought the only native 
types in D were `size_t` and `ptrdiff_t`.  What's the actual 
syntax you use in the OSX port?


If you're looking for alternative names for `size_t` and 
`ptrdiff_t` how about:

alias native_int = ptrdiff_t;
alias native_uint = size_t;

Mike
Jul 19 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-07-20 02:46, Mike wrote:


 What do you mean by "native type"?  I thought the only native types in D
 were `size_t` and `ptrdiff_t`.  What's the actual syntax you use in the
 OSX port?


External C functions that take pointers are declared to take int/long in 
the Java code. I would prefer that the original type is used.


 If you're looking for alternative names for `size_t` and `ptrdiff_t` how
 about:

 alias native_int = ptrdiff_t;
 alias native_uint = size_t;


Hmm, I don't know. Perhaps ptrdiff_t is good enough.

-- 
/Jacob Carlborg
Jul 20 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-19 01:47, Mike wrote:


 * How does one go about testing DWT?


I don't have a good answer to that. I mostly try the snippets and see 
that they behave correctly. For some snippets it might not always be 
easy to see what they're supposed to do or behave. In that case I 
compare with the the behavior of the Java version.

SWT has some kind of tests [1], which probably should be ported at some 
time.

[1] 
http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/tests/org.eclipse.swt.tests

-- 
/Jacob Carlborg
Jul 19 2014
parent reply "Mike" <none none.com> writes:
On Saturday, 19 July 2014 at 15:10:11 UTC, Jacob Carlborg wrote:

 On 2014-07-19 01:47, Mike wrote:


 * How does one go about testing DWT?


 I don't have a good answer to that. I mostly try the snippets 
 and see that they behave correctly. For some snippets it might 
 not always be easy to see what they're supposed to do or 
 behave. In that case I compare with the the behavior of the 
 Java version.

 SWT has some kind of tests [1], which probably should be ported 
 at some time.

 [1] 
 http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/tests/org.eclipse.swt.tests


Interesting! How was the original port from SWT to DWT done?  Was 
some utility used?

Mike
Jul 19 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-20 01:40, Mike wrote:


 Interesting! How was the original port from SWT to DWT done?  Was some
 utility used?


It's manually ported. There was a try to create a tool [1] to 
automatically port the code but that required a too big part of the Java 
standard library to be ported as well.

[1] http://dsource.org/projects/tioport

-- 
/Jacob Carlborg
Jul 20 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-20 15:52, Jacob Carlborg wrote:


 It's manually ported. There was a try to create a tool [1] to
 automatically port the code but that required a too big part of the Java
 standard library to be ported as well.


It might be worth investigation to try and do an automatic port again. I 
had a look and saw that in Java 6 there's an API for parsing Java. It 
would be really nice to have completely automatic tool for porting. It 
could be hard coded for SWT, I think Tioport tried to be usable for 
other Java projects.

-- 
/Jacob Carlborg
Jul 20 2014
parent reply "Mike" <none none.com> writes:
On Sunday, 20 July 2014 at 19:33:35 UTC, Jacob Carlborg wrote:

 On 2014-07-20 15:52, Jacob Carlborg wrote:


 It's manually ported. There was a try to create a tool [1] to
 automatically port the code but that required a too big part 
 of the Java
 standard library to be ported as well.


 It might be worth investigation to try and do an automatic port 
 again. I had a look and saw that in Java 6 there's an API for 
 parsing Java. It would be really nice to have completely 
 automatic tool for porting. It could be hard coded for SWT, I 
 think Tioport tried to be usable for other Java projects.


Well, what's the GUI future of D?  Does DWT have a role to play?

Mike
Jul 20 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 21/07/14 03:00, Mike wrote:


 Well, what's the GUI future of D?  Does DWT have a role to play?


I think so. But not so many others do. They either want to use Qt, GTK 
or create a completely new framework.

* GTK - doesn't native drawing operations. Requires separate download

* Qt - written in C++, hard to interface with. I don't think it uses 
native drawing on all platforms. Requires separate download

* Completely new framework - huge undertaking, will take a massive 
amount of time and resources

-- 
/Jacob Carlborg
Jul 20 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 21/07/14 03:00, Mike wrote:


 Well, what's the GUI future of D?  Does DWT have a role to play?


If we could make the process completely automatic (or nearly automatic) 
to make it easy to keep up with SWT. And also create a GUI builder then 
I think DWT is in a very good position.

-- 
/Jacob Carlborg
Jul 20 2014
parent reply "Mike" <none none.com> writes:
On Monday, 21 July 2014 at 06:12:29 UTC, Jacob Carlborg wrote:

 On 21/07/14 03:00, Mike wrote:


 Well, what's the GUI future of D?  Does DWT have a role to 
 play?


 If we could make the process completely automatic (or nearly 
 automatic) to make it easy to keep up with SWT. And also create 
 a GUI builder then I think DWT is in a very good position.


Well, I've never written any Java code before, and I'm not 
looking forward to learning yet another language. Is it possible 
to utilize the java parser from D?

I'm thinking I should probably just get the 64-bit port done for 
now, but if you can think of a way to write the porting utility 
in D I'll consider giving it a try.

Mike
Jul 21 2014
next sibling parent reply "Mike" <none none.com> writes:
On Monday, 21 July 2014 at 09:35:30 UTC, Mike wrote:

 On Monday, 21 July 2014 at 06:12:29 UTC, Jacob Carlborg wrote:

 On 21/07/14 03:00, Mike wrote:


 Well, what's the GUI future of D?  Does DWT have a role to 
 play?


 If we could make the process completely automatic (or nearly 
 automatic) to make it easy to keep up with SWT. And also 
 create a GUI builder then I think DWT is in a very good 
 position.


 Well, I've never written any Java code before, and I'm not 
 looking forward to learning yet another language. Is it 
 possible to utilize the java parser from D?


Or, is there a utility out there that can dump Java source to xml 
or something more consumable by D?  Then I might have some hope.

Mike
Jul 21 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-07-21 11:52, Mike wrote:


 Or, is there a utility out there that can dump Java source to xml or
 something more consumable by D?  Then I might have some hope.


No, not that I know of. You might be able to find a Java grammar for 
some parser generator that could be used. But, as I wrote in the other 
post, I think semantic analyze is required to do this well enough.

-- 
/Jacob Carlborg
Jul 21 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-07-21 11:35, Mike wrote:


 Well, I've never written any Java code before, and I'm not looking
 forward to learning yet another language. Is it possible to utilize the
 java parser from D?


In theory it should be possible to access via JNI (Java Native 
Interface), but that's very cumbersome and it would be easier to write 
the tool in Java, or any other language that runs on the JVM (Scala, 
Ruby and so on).


 I'm thinking I should probably just get the 64-bit port done for now,
 but if you can think of a way to write the porting utility in D I'll
 consider giving it a try.


Possibly if there's a parser wirtten in C. But I'm not sure if a parser 
is enough, I think a full front end is needed, including the semantic 
analyzer.

-- 
/Jacob Carlborg
Jul 21 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-21 11:35, Mike wrote:


 Well, I've never written any Java code before, and I'm not looking
 forward to learning yet another language. Is it possible to utilize the
 java parser from D?


Just for the record, I started a project to do this [1]. It's very 
simple so far. But the basic structure is there. It sets up the 
compiler, starts the parsing and so on. Just start adding visitor 
methods like this [2] for different language constructs.

[1] https://github.com/d-widget-toolkit/jport
[2] 
https://github.com/d-widget-toolkit/jport/blob/master/src/dwt/jport/analyzers/CodeAnalyzerTreeVisitor.scala#L14

-- 
/Jacob Carlborg
Jul 25 2014
next sibling parent "Mike" <none none.com> writes:
On Friday, 25 July 2014 at 20:15:39 UTC, Jacob Carlborg wrote:

 On 2014-07-21 11:35, Mike wrote:


 Well, I've never written any Java code before, and I'm not 
 looking
 forward to learning yet another language. Is it possible to 
 utilize the
 java parser from D?


 Just for the record, I started a project to do this [1]. It's 
 very simple so far. But the basic structure is there. It sets 
 up the compiler, starts the parsing and so on. Just start 
 adding visitor methods like this [2] for different language 
 constructs.

 [1] https://github.com/d-widget-toolkit/jport
 [2] 
 https://github.com/d-widget-toolkit/jport/blob/master/src/dwt/jport/analyzers/CodeAnalyzerTreeVisitor.scala#L14


This is good to see.  Unfortunately, scala is even more foreign 
to me than Java.  I hope you're able to show some promising 
results soon.  I'm rooting for this.

Mike
Jul 25 2014
prev sibling parent reply "Mike" <none none.com> writes:
On Friday, 25 July 2014 at 20:15:39 UTC, Jacob Carlborg wrote:

 On 2014-07-21 11:35, Mike wrote:


 Well, I've never written any Java code before, and I'm not 
 looking
 forward to learning yet another language. Is it possible to 
 utilize the
 java parser from D?


 Just for the record, I started a project to do this [1]. It's 
 very simple so far. But the basic structure is there. It sets 
 up the compiler, starts the parsing and so on. Just start 
 adding visitor methods like this [2] for different language 
 constructs.

 [1] https://github.com/d-widget-toolkit/jport
 [2] 
 https://github.com/d-widget-toolkit/jport/blob/master/src/dwt/jport/analyzers/CodeAnalyzerTreeVisitor.scala#L14


I've been thinking more about this.  If you could use this scala 
code to output the java code is something more consumable by D, 
it may be easier for others in this community to help build on it.

I realize there will need to be semantic analysis, but as long 
the syntax is appropriately annotated as methods, parameters, 
types, expressions, etc... and maintains lexical order, D could 
do the semantic analysis.

I'm thinking something like JaML: 
http://www2.informatik.uni-wuerzburg.de/uploads/media/jaml_technical_report.pdf

Mike
Jul 26 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-26 15:49, Mike wrote:


 I've been thinking more about this.  If you could use this scala code to
 output the java code is something more consumable by D, it may be easier
 for others in this community to help build on it.

 I realize there will need to be semantic analysis, but as long the
 syntax is appropriately annotated as methods, parameters, types,
 expressions, etc... and maintains lexical order, D could do the semantic
 analysis.

 I'm thinking something like JaML:
 http://www2.informatik.uni-wuerzburg.de/uploads/media/jaml_technical_report.pdf


I can just as easy output it directly to D as XML. Or is there are tool 
that can do that already. Is that what JaML is?

-- 
/Jacob Carlborg
Jul 26 2014
parent "Mike" <none none.com> writes:
On Saturday, 26 July 2014 at 14:23:21 UTC, Jacob Carlborg wrote:

 On 2014-07-26 15:49, Mike wrote:



 I can just as easy output it directly to D as XML. Or is there 
 are tool that can do that already. Is that what JaML is?


JaML appears to just be a schema.  I tried to find a utility that 
already did such a thing, but failed.  Otherwise, I would have 
started the project.

I was thinking that the conversion would take quite a bit of 
logic, and if so, could be deferred to D so others could help 
with it.  But if it's no more of a burden to output D code, then 
let it be D.

Mike
Jul 26 2014