I am converting a c source to D - I had it run a few times under C compile but there were too many issues. Decided to transition to 'D' for the reasons discussed ...

I got this far, compiler is stating I should:
     "semicolon expected, not 'TWAIN_AcquireNative'"

    /*
     * Class:     ocr_zarf
     * Method:    zarf_AcquireNative
     * Signature: ()I
     */
    export extern (Windows) synchronized long
    Java_ocr_zarf_zarf_1AcquireNative
    (JNIEnv * JEnvironmentPointer, jobject jayObject)

So JNI has a way of doing things that does not translate directly in my mind, should I just make JNIEnv a class - and put ....

There's some 1,700 calls or lines of code or something in the JNI headers. Seems to me to be an excellent time for me to ask for intervention > this what D is all about.

I need to get a dll working that will interface to EZTwain, that is called from Java. ( Note the attachment is first draft - I started on D yesterday so spare me some critical review )

Sun, 15 Mar 2009 21:37:48 +0000 (UTC), Nicholas Jordan wrote:

> I got this far, compiler is stating I should:
>      "semicolon expected, not 'TWAIN_AcquireNative'"

You use lots of undefined symbols in this module: HANDLE, EZTAPI, HWND, unsigned etc.  The compiler can't read your mind so you must tell it exactly what you mean.

Most common Windows definitions are available in std.c.windows.windows:

import std.c.windows.windows;

You probably should define things like 'unsigned' yourself:

alias uint unsigned;

I have absolutely no idea what EZTAPI is, it's up to you to define it correctly, or find existing bindings.

Sergey Gromov wrote:
> Sun, 15 Mar 2009 21:37:48 +0000 (UTC), Nicholas Jordan wrote:
> 
>> I got this far, compiler is stating I should:
>>      "semicolon expected, not 'TWAIN_AcquireNative'"
> 
> You use lots of undefined symbols in this module: HANDLE, EZTAPI, HWND,
> unsigned etc.  The compiler can't read your mind so you must tell it
> exactly what you mean.
> 
> Most common Windows definitions are available in std.c.windows.windows:
> 
> import std.c.windows.windows;
> 
> You probably should define things like 'unsigned' yourself:
> 
> alias uint unsigned;
> 
> I have absolutely no idea what EZTAPI is, it's up to you to define it
> correctly, or find existing bindings.

I think Nicholas is talking about EZTwain. A twain DLL ( scanner and the like )
What I don't get is why Nicholas is trying to convert the Java source(s) instead  of converting the C header with  h2d.

Björn

Great, I was afraid .....

I will read all the replies, it is rather clear I need to run h2d - will have to find it. I will read the other posts, I could lose my internet connection at any time so silence is on to be taken as an ignore.

Correct, I decided to get scanner images for study use while reading Jeff Heaton's book and site. Soon I found EZTwain, got to the point of getting one run to return to Java. Pretty sure none of the image data transferred, but things like int's were showing up with correct values.

Due to not being able to get a link when I started again from scratch, preserving all work first, I decided to transition to "D" ( for the arguments cited ) - I had been working on it 18-hours and started to bog on how to get the "headers" from javap reachable from "D" code.

Totally lost, decided to ask.

import placed in source file, will do a build later today as I am swamped with simple survival stuff today.

What I don't get is, given that javap pulls headers, I tried to use the headers so that the JVM could call the dll. So far, so good, except that it would be much more in the style intent and manner of D to just write the calls and make the whole thing reliant on a header style we are trying to get away from.

Thus, I don't know how to prototype the function. There is JNIEnv / jobject both of which resolve to "some computer stuff like we have always known it" ... the JNIEnv is double indirection, jobject amounts to something along the lines of a strongly typed pointer.

If we could expose the function entry points to the JVM using D syntax, I am sure the entry from the JVM would be 190% better.

That is what my question actually is: "How do I expose the function entry points to a running JVM - given that this code is called as a loadable runtime?"

I re-coded my def file several times, think I have got the entire syntax starting to memorize. I put everything in there I could find in the docs, have to recode the EXPORTS as on of the editors I tried ate my sources last night.

The massive array running down the middle is a bench hack as the compiler kept complaining about how I was doing the pointers. That is to be a data space some 1 to 100 kb by which I can pass data if I can not get anything else to work.

The intent is to write Java code, bring in an image using EZTwain, do OCR on it.

Mon, 16 Mar 2009 15:46:46 +0000 (UTC), Nicholas Jordan wrote:

> import placed in source file, will do a build later today as I am swamped with simple survival stuff today.
> 
> What I don't get is, given that javap pulls headers, I tried to use the headers so that the JVM could call the dll. So far, so good, except that it would be much more in the style intent and manner of D to just write the calls and make the whole thing reliant on a header style we are trying to get away from.
> 
> Thus, I don't know how to prototype the function. There is JNIEnv / jobject both of which resolve to "some computer stuff like we have always known it" ... the JNIEnv is double indirection, jobject amounts to something along the lines of a strongly typed pointer.
> 
> If we could expose the function entry points to the JVM using D syntax, I am sure the entry from the JVM would be 190% better.
> 
> That is what my question actually is: "How do I expose the function entry points to a running JVM - given that this code is called as a loadable runtime?"
> 
> I re-coded my def file several times, think I have got the entire syntax starting to memorize. I put everything in there I could find in the docs, have to recode the EXPORTS as on of the editors I tried ate my sources last night.
> 
> The massive array running down the middle is a bench hack as the compiler kept complaining about how I was doing the pointers. That is to be a data space some 1 to 100 kb by which I can pass data if I can not get anything else to work.
> 
> The intent is to write Java code, bring in an image using EZTwain, do OCR on it.

I suggest you take an iterative approach.  You're trying to make too many non-trivial things at once: learn D, make Java correctly interface with your DLL, make your DLL correctly interface with JRE, make your DLL correctly interface with TWAIN drivers.

I suggest you create a very simple Java class, with a single native function taking an integer argument and returning its square, and implement this function in D.  After this works, try adding another function, taking a string as an argument and returning another string. After you do that you'll have some grasp on D and on Java interfacing. Then you may try implementing one of your actual functions, but even then I suggest you skip TWAIN interactions first and fake them instead. Or try to write a simple console application doing exclusively TWAIN interactions.

Currently, in your zarfOCR.d almost every single line requires fixing.

Sir, I run massive projects - that is my style. I get things running that way.

I totally totally realize every line needs fixing, I just got several thousand lines moved from c to d thanks to the help
here.

I have a great deal of experience working this way, once I fix one thing - the rest of the file gets fixed in minutes.

I work extremely fast under pressures that break most people withing days. If you have never seen anyone crack, it is not
something to get involved with.

Again, my apologies again to Jarrett Billings, I probably pushed a reply button when,... okay - I see what I did wrong.

It was a wrong button push.

I use the iterative approach, I just have a 500 line file to do it on. Usually, I have about five or ten "issues" or
problems I am trying to grasp at any arbitrary moment on a transition like this. The guy across the hall in I talk in full
duplex ( both people talking - about different issues ) while thinking about something not even vocalized yet.

It's just a pressure level most people cannot work at.