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

Compiler errors

 
Post new topic   Reply to topic     Forum Index -> Juno
View previous topic :: View next topic  
Author Message
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Fri Jul 20, 2007 10:07 am    Post subject: Reply with quote

John,

I hope you can you give me a hint about what I'm doing wrong. I'm trying to build a simple Juno example program that I've come up with using DMD 1.018 (using rebuild). And it's giving me a bunch of error messages. Do I need to DMD 2.X or an earlier version in the DMD 1.X series. Or is it something more mysterious? Thanks for your help.

Code:
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(292): found 'char' when e
xpecting ')'
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(292): semicolon expected
following function declaration
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(292): found 's' when expe
cting ';' following 'statement'
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(292): found ',' instead o
f statement
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(299): no identifier for d
eclarator s[index++]
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(300): no identifier for d
eclarator s[index++]
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(301): no identifier for d
eclarator s[index++]
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(302): no identifier for d
eclarator s[index++]
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(308): no identifier for d
eclarator s[jd]
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(309): found ',' when expe
cting ')'
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(309): semicolon expected,
 not 'index'
D:\MyFiles\pgm\d\src\juno\juno.src.0.3\juno\com\core.d(309): no identifier for d
Back to top
View user's profile Send private message AIM Address
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Fri Jul 20, 2007 10:22 am    Post subject: Reply with quote

Ok, nevermind. Juno isn't the problem at all. The problem is that I don't know how to operate rebuild. I don't know how to control which version of DMD that rebuild invokes (I like to keep several versions around so that I can test different version of DMD).

For the sake of curiosity, do you use rebuild or build or make or some tool like that to develop your programs that use Juno?
Back to top
View user's profile Send private message AIM Address
John



Joined: 17 Jan 2006
Posts: 75

PostPosted: Fri Jul 20, 2007 10:47 am    Post subject: Reply with quote

I don't know how to use Rebuild either, sorry. Tried Bud ages ago, but never got it to work. And make files weren't invented for mortals. So I've stuck with good old batch files. They're not sexy, but they work.
Back to top
View user's profile Send private message
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Fri Jul 20, 2007 11:15 am    Post subject: Reply with quote

I had better luck with a newer version of Rebuild. Even when I've been able to figure out how to use Rebuild or Build for a particular experiment, I've still wrapped it in a batch file. So I've always found batch files useful.

So I think I'm getting close. Now I have this error:
Code:
.\juno-locale-core.obj(juno-locale-core)
 Error 42: Symbol Undefined _GetGeoInfoW@20
--- errorlevel 1


I tried adding a new definition to a kernel32.def that I had laying around and creating a new kernel32.lib, but I'm still getting the error. I don't know what the problem is. I wonder if the easier solution for me is to just start commenting out part of juno.locale.core.
Back to top
View user's profile Send private message AIM Address
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Fri Jul 20, 2007 11:26 am    Post subject: Reply with quote

This worked better for me in juno.locale.core:

Code:
private string getGeoInfo(int geoId, uint geoType) {
    /* causes "Error 42: Symbol Undefined _GetGeoInfoW@20" */
/+
    int cch = GetGeoInfo(geoId, geoType, null, 0, 0);
  wchar[] buffer = new wchar[cch];
  cch = GetGeoInfo(geoId, geoType, buffer.ptr, buffer.length, 0);
  if (cch == 0) return null;
+/
  /* inspired by
    http://www.globalyzer.com/gi/help/gihelp/unsafeMethod/GetGeoInfo.htm
    http://www.globalyzer.com/gi/help/gihelp/internationalization/cpplocales.htm */
  return "en_US";//toUTF8(buffer[0 .. cch - 1]);
}
Back to top
View user's profile Send private message AIM Address
John



Joined: 17 Jan 2006
Posts: 75

PostPosted: Fri Jul 20, 2007 12:04 pm    Post subject: Reply with quote

DMD's lib files are pretty old. I don't think they import new functions from Windows XP. I use Microsoft's from the SDK and run coffimplib on them.

For a quick fix, this works:

1) Create a file named kernel32ex.def with the following contents:
LIBRARY kernel32
EXPORTS
_GetGeoInfoW@20 = GetGeoInfoW
_ReplaceFileW@24 = ReplaceFileW

2) Run implib kernel32ex.lib kernel32ex.def

3) Add kernel32ex.lib to your command line (or pragma).
Back to top
View user's profile Send private message
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Mon Jul 23, 2007 8:58 am    Post subject: Reply with quote

John wrote:
DMD's lib files are pretty old. I don't think they import new functions from Windows XP. I use Microsoft's from the SDK and run coffimplib on them.

For a quick fix, this works:

1) Create a file named kernel32ex.def with the following contents:
LIBRARY kernel32
EXPORTS
_GetGeoInfoW@20 = GetGeoInfoW
_ReplaceFileW@24 = ReplaceFileW

2) Run implib kernel32ex.lib kernel32ex.def

3) Add kernel32ex.lib to your command line (or pragma).


Thanks for the tip. I tried your fix, and I think I did it right.

The problem now seems to be that my operating system (Windows 2000) doesn't have that function: "The procedure entry point GetGeoInfoW could not be located in the dynamic link library kernel32.DLL".

If you want to have a certain version of Windows as a requirement, that's your decision, but it'd be nice if there was some kind of runtime check for which operating system is present (or a version that someone could compile with if they don't want to require users to have Windows XP or Vista or whatever the current minimum OS is). I don't know the best way to add some options like that, but Phobos does have a check in file.d that is for a related issue:
Code:
int useWfuncs = 1;

static this()
{
    // Win 95, 98, ME do not implement the W functions
    useWfuncs = (GetVersion() < 0x80000000);
}
Back to top
View user's profile Send private message AIM Address
John



Joined: 17 Jan 2006
Posts: 75

PostPosted: Mon Jul 23, 2007 11:37 am    Post subject: Reply with quote

Quote:
my operating system (Windows 2000)


Now you tell me!

Actually you could have diagnosed the problem earlier by checking MSDN. http://msdn2.microsoft.com/en-us/library/ms776300.aspx
It says the function is included in XP and later.

Quote:
it'd be nice if there was some kind of runtime check for which operating system is present


That wouldn't help with your problem, because it's a link-time issue.
Back to top
View user's profile Send private message
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Mon Jul 23, 2007 2:14 pm    Post subject: Reply with quote

John wrote:
Quote:
my operating system (Windows 2000)

Now you tell me!
Sorry, I didn't realize it'd create a problem running such an ancient operating system. I use either Win2000 or WinXP depending on whether I'm at home or at work, and I forget there's a difference because usually everything runs on both.

John wrote:
Actually you could have diagnosed the problem earlier by checking MSDN. http://msdn2.microsoft.com/en-us/library/ms776300.aspx
It says the function is included in XP and later.
I'm not that good at looking up things in MSDN. I tend to use Google and then jump off of that. (I'm only a semi-professional programmer.)

John wrote:
Quote:
it'd be nice if there was some kind of runtime check for which operating system is present


That wouldn't help with your problem, because it's a link-time issue.
I don't understand. Are you saying that the locales package is an integral part of Juno, and there's no chance that Juno will run without it (and the locales package will always require Windows XP or newer)?

Juno seems to work fine on Windows 2000 if I just version out that function:
Code:
private string getGeoInfo(int geoId, uint geoType) {
    /* causes "Error 42: Symbol Undefined _GetGeoInfoW@20" */

    version(OldWindows)
    {
      /* inspired by
        http://www.globalyzer.com/gi/help/gihelp/unsafeMethod/GetGeoInfo.htm
        http://www.globalyzer.com/gi/help/gihelp/internationalization/cpplocales.htm */
      return "en_US";//toUTF8(buffer[0 .. cch - 1]);
    }   
    else
    {
        int cch = GetGeoInfo(geoId, geoType, null, 0, 0);
      wchar[] buffer = new wchar[cch];
      cch = GetGeoInfo(geoId, geoType, buffer.ptr, buffer.length, 0);
      if (cch == 0) return null;
    }
}


(I don't expect everything to run on Windows 95 and Windows 98 these days, but I don't think I'm the only person around who still uses a Windows 2000 computer.)

Oh, well, maybe they'll replace my computer at work pretty soon and then I won't drift into obsolescence so quickly.
Back to top
View user's profile Send private message AIM Address
John



Joined: 17 Jan 2006
Posts: 75

PostPosted: Mon Jul 23, 2007 3:52 pm    Post subject: Reply with quote

Quote:
Sorry, I didn't realize it'd create a problem running such an ancient operating system.


All I meant was that I could have answered your question sooner had I known you were on Windows 2000, which Juno doesn't support (the wiki homepage says it only compiles on XP and Vista).

Quote:
Are you saying that the locales package is an integral part of Juno, and there's no chance that Juno will run without it (and the locales package will always require Windows XP or newer)?


No. I said the GetGeoInfo issue was a link-time problem. By versioning the declaration out you've prevented it from being compiled, thus the error disappears. That is different to Phobos's useWfuncs test, which is a runtime check. Were your OldWindows version identifier a variable instead (like useWfuncs), the error would still occur.

I'll think about changing the behavior for the next update of Juno.
Back to top
View user's profile Send private message
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Wed Jul 25, 2007 9:18 am    Post subject: Reply with quote

John wrote:
Quote:
Sorry, I didn't realize it'd create a problem running such an ancient operating system.


All I meant was that I could have answered your question sooner had I known you were on Windows 2000, which Juno doesn't support (the wiki homepage says it only compiles on XP and Vista).
I didn't notice that new note on the webpage until after you mentioned that using Windows 2000 was a problem. If you want to keep the XP/Vista requirement, I think you should make the note more clear about this requirement. The current text only hints at Juno's limitations:
Quote:
Juno compiles on Windows XP and Vista is distributed under the MIT licence.
I think this would be much better:
Quote:
Juno only compiles on Windows XP and Vista. Also, programs that use Juno only run on Windows XP and Vista. Juno is distributed under the MIT license.


John wrote:
Quote:
Are you saying that the locales package is an integral part of Juno, and there's no chance that Juno will run without it (and the locales package will always require Windows XP or newer)?


No. I said the GetGeoInfo issue was a link-time problem. By versioning the declaration out you've prevented it from being compiled, thus the error disappears. That is different to Phobos's useWfuncs test, which is a runtime check. Were your OldWindows version identifier a variable instead (like useWfuncs), the error would still occur.

I'll think about changing the behavior for the next update of Juno.
I was hoping that a useWfuncs-like technique could be used to circumvent calling the function that requires XP/Vista if the operating system running the program is older. That's what useWfuncs does when the "W" functions aren't available. Can a "default locale" be hard-coded into Juno for situations where XP/Vista isn't available? How is the locale package "connected" to the rest of Juno? Is it mostly optional, or is it tightly integrated into the rest of Juno?

Many of the computers in office still run Win2000. Eventually, we'll convert over to mostly XP/Vista (but we'll probably still have Win2000 computers around for years to come), but I'd like to be able to use Juno before that happens. If you don't include the option for older systems in Juno, I'll probably try to create my own patch.
Back to top
View user's profile Send private message AIM Address
John



Joined: 17 Jan 2006
Posts: 75

PostPosted: Wed Jul 25, 2007 10:45 am    Post subject: Reply with quote

Quote:
Can a "default locale" be hard-coded into Juno for situations where XP/Vista isn't available? How is the locale package "connected" to the rest of Juno? Is it mostly optional, or is it tightly integrated into the rest of Juno?


The problematic function is only called by the Region class and isn't required for the core locales package to work.

Quote:
If you don't include the option for older systems in Juno, I'll probably try to create my own patch.


Linking to the function at runtime gets around the problem. Just avoid the Region class and your programs will compile fine. Obviously wait till I get around to uploading the updated code.

Update: I've patched the source, so if you want to give it a go, check out juno.base.native from SVN or re-download the zip file. Good luck.
Back to top
View user's profile Send private message
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Wed Jul 25, 2007 1:01 pm    Post subject: Reply with quote

John wrote:
Quote:
Can a "default locale" be hard-coded into Juno for situations where XP/Vista isn't available? How is the locale package "connected" to the rest of Juno? Is it mostly optional, or is it tightly integrated into the rest of Juno?


The problematic function is only called by the Region class and isn't required for the core locales package to work.
Okay, that sounds fine.

John wrote:
Quote:
If you don't include the option for older systems in Juno, I'll probably try to create my own patch.


Linking to the function at runtime gets around the problem. Just avoid the Region class and your programs will compile fine. Obviously wait till I get around to uploading the updated code.

Update: I've patched the source, so if you want to give it a go, check out juno.base.native from SVN or re-download the zip file. Good luck.
I downloaded the newest snapshot of SVN, and it worked great!

Thank you very much for changing this for me.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Juno All times are GMT - 6 Hours
Page 1 of 1

 
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