Difference between revisions of "Talk:Apertium on Windows"

From Apertium
Jump to navigation Jump to search
(some replies)
Line 34: Line 34:
   
 
:I'm not aware of any parameter for that, although... the deformatters aren't 100% necessary for the correct functioning of the system. I would recommend leaving them until last. - [[User:Francis Tyers|Francis Tyers]] 19:53, 23 November 2008 (UTC)
 
:I'm not aware of any parameter for that, although... the deformatters aren't 100% necessary for the correct functioning of the system. I would recommend leaving them until last. - [[User:Francis Tyers|Francis Tyers]] 19:53, 23 November 2008 (UTC)
  +
  +
::I got that stuff working in the win32 branch, no? I have a function to fix, because I did completely the wrong thing, but the deformatters should work. -- [[User:Jimregan|Jimregan]] 13:13, 25 November 2008 (UTC)
   
 
:: apertium_desodt.cc also has a line "wchar_t cad[filename.size()];" with same error (constant waited), probably many files will have the same problem. [[User:Mlavaud|Mlavaud]] 20:07, 23 November 2008 (UTC)
 
:: apertium_desodt.cc also has a line "wchar_t cad[filename.size()];" with same error (constant waited), probably many files will have the same problem. [[User:Mlavaud|Mlavaud]] 20:07, 23 November 2008 (UTC)
Line 82: Line 84:
 
#define isnan(x) _isnan(x)
 
#define isnan(x) _isnan(x)
 
</pre>
 
</pre>
  +
  +
:This, IIRC, is also fixed in the win32 branch. You're not the first person to suggest something like this - though, also IIRC, there is already an qeuivalent of isinf() in Windows land. And by the way, the correct way to add those kinds of definitions is to add an #ifdef MSCVER or whatever :P --[[User:Jimregan|Jimregan]] 13:13, 25 November 2008 (UTC)
   
 
If someone ever compiled this program with Visual Studio, he should tell me how to allow vector<wstring> translation_window[window.size()]; because there too many arrays defined with a variable instead of a constant and I doubt I will be able to fix them all. [[User:Mlavaud|Mlavaud]] 22:55, 24 November 2008 (UTC)
 
If someone ever compiled this program with Visual Studio, he should tell me how to allow vector<wstring> translation_window[window.size()]; because there too many arrays defined with a variable instead of a constant and I doubt I will be able to fix them all. [[User:Mlavaud|Mlavaud]] 22:55, 24 November 2008 (UTC)
Line 93: Line 97:
   
 
strcasecmp() -> strcmpi()
 
strcasecmp() -> strcmpi()
  +
  +
::Those are also fixed in the win32 branch. There are still other problems remaining though. One thing is that Windows does something stupid with wstring, and has to be told specifically to open files as unicode. That's fixed in a lot of parts of Apertium, but I'm not sure if I got them all. The other thing is that something gets broken in the tagger in the changes from arrays to vectos, and I still don't know exactly what's happening there -- [[User:Jimregan|Jimregan]] 13:13, 25 November 2008 (UTC)
   
 
4 exe compile now but the next one needs the full pcre to link I think, I will have to recompile it first.
 
4 exe compile now but the next one needs the full pcre to link I think, I will have to recompile it first.

Revision as of 13:13, 25 November 2008

Packaging a windows release?

Perhaps Cygwin license[1] would allow a packging of apertium and the required cygwin items to create a windows release?

Ote 22:55, 9 November 2007 (UTC)

It should be possible, but cygwin distribution must be optimized for size. I've tried compiling apertium with cygwin last week, but it gave some errors and could not advance further. I would also appreciate if someone had packaged cygwin with apertium and also supplied a batch file which enables translation with a simple double click under Windows environment.--Msalperen 09:14, 10 November 2007 (UTC)

I'm sorry, but you're wrong. It's not possible to build Apertium with any currently existing version of Cygwin. Cygwin's great, but it's not 100%. Cygwin 1.7 reputedly has the missing pieces of Unicode support that we need, but it doesn't as yet use GCC 4, which we also need. As soon as Cygwin 1.7 is available with GCC 4, I'll look into it again. -- Jimregan 18:05, 22 November 2008 (UTC)
Oh, and to answer the original question; the licence of Cygwin is not a problem. Apertium hasn't been packaged for cygwin due to technical issues -- Jimregan 18:07, 22 November 2008 (UTC)

Compilation

Is "valgrind" the correct version to use for Windows ? But next, directory Win32 is missing, on the other hand "branches\apertium" has a Win32 dir. but no lttoolbox. The page can be updated depending on the answer.

All of the Windows stuff is now merged into the trunk. We should really delete the branch[es]. - Francis Tyers 12:51, 22 November 2008 (UTC)
Correction: the win32 work on lttoolbox has all been merged - it should build without problems in VC++. The work on Apertium hasn't all been merged, and it's not yet complete. I'll get to it, I'm just not majorly motivated, because I despise Windows :) -- Jimregan 18:05, 22 November 2008 (UTC)
I think all the necessary stuff has been merged no ? A couple of weeks ago we guided a guy through compiling it on Windows, and he managed it without any patches. It might be worth looking at the mailing list posts, look up the thread [Apertium-stuff] Help on errors in Windows build. - Francis Tyers 18:10, 22 November 2008 (UTC)
I remember that thread. Nope, no magical fixes slipped in under my nose. Same problems exist. -- Jimregan 22:08, 22 November 2008 (UTC)

Windows not supported ?

But the code I am trying to compile now will work right ? Mlavaud 18:32, 23 November 2008 (UTC)

Yes. What "not supported" means is that we don't really know _how_ it works, and can't offer the same level of support as on *nix. :) At least two or three people have got it working under Windows, so it is possible. - Francis Tyers 18:35, 23 November 2008 (UTC)
I will help fix things with pleasure if I can. Mlavaud 18:38, 23 November 2008 (UTC)
Cool thanks :) I think that at the moment the main thing we're lacking is documentation. So any details you can add or clarify we'd be very happy :) - Francis Tyers 18:54, 23 November 2008 (UTC)

First I need a few parameters to be correctly positioned: I have "#define MB_CUR_MAX ___mb_cur_max_func()" activated in stdlib.h and it is not compatible with "char symbol[MB_CUR_MAX+1];" in apertium_deshtml.cc -> "error constant needed", also I have "wchar_t cad[filename.size()];" in the same file, but an array definition needs a constant, or is there a parameter somewhere in Visual C++ for that ? Mlavaud 19:47, 23 November 2008 (UTC)

I'm not aware of any parameter for that, although... the deformatters aren't 100% necessary for the correct functioning of the system. I would recommend leaving them until last. - Francis Tyers 19:53, 23 November 2008 (UTC)
I got that stuff working in the win32 branch, no? I have a function to fix, because I did completely the wrong thing, but the deformatters should work. -- Jimregan 13:13, 25 November 2008 (UTC)
apertium_desodt.cc also has a line "wchar_t cad[filename.size()];" with same error (constant waited), probably many files will have the same problem. Mlavaud 20:07, 23 November 2008 (UTC)
I think only the files which are generated from flex (e.g. the de/re-formatters) will have this. - Francis Tyers 20:16, 23 November 2008 (UTC)
A problem at linking, how do I include the libraries needed ? Mlavaud 20:11, 23 November 2008 (UTC)
"apertium_desodt.cc
Linking CXX executable apertium-desodt.exe
apertium_desodt.cc.obj : error LNK2019: symbole externe non rÚsolu _regcomp rÚfÚ
rencÚ dans la fonction "void __cdecl init_escape(void)" (?init_escape@@YAXXZ)
apertium_desodt.cc.obj : error LNK2019: symbole externe non rÚsolu _regexec rÚfÚ
rencÚ dans la fonction "class std::basic_string<wchar_t,struct std::char_traits<
wchar_t>,class std::allocator<wchar_t> > __cdecl escape(class std::basic_string<
char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?esca
pe@@YA?AV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@ABV?$ba
sic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@2@@Z)
apertium-desodt.exe : fatal error LNK1120: 2 externes non résolus"
Can you show me which libraries it is linking (or trying to link) to ? - Francis Tyers
It needs regcomp and regexec, so I guess it needs a regex lib ? Well my \pcre\lib is empty, that is the problem I think. Mlavaud 20:20, 23 November 2008 (UTC)
Yes that could well be the problem. Did you install libpcre from source or from a binary package ? - Francis Tyers 20:24, 23 November 2008 (UTC)
A package found at http://gnuwin32.sourceforge.net/packages/pcre.htm, but no file pcrecpp.lib is provided, only a pcre-bcc.lib and it doesn't work more. Mlavaud 20:55, 23 November 2008 (UTC)
Try building PCRE from source then I guess... - Francis Tyers 20:58, 23 November 2008 (UTC)
I removed the ref. to pcrecpp.lib and it linked. Mlavaud 15:18, 24 November 2008 (UTC)
Ok, so long as it was in the de/re-formatters or tagger and not any of the transfer modules, it should work fine. - Francis Tyers 17:48, 24 November 2008 (UTC)

An idea to fix this error ? Mlavaud 19:33, 24 November 2008 (UTC)

C:\Apertium\trunk\apertium\apertium\collection.cc(70) : error C2440: 'initialisation' : impossible de convertir de 'std::_Tree<_Traits>::const_iterator' en 'std::_Tree<_Traits>::iterator' with
[ _Traits=std::_Tset_traits<int,std::less<int>,std::allocator<int>,false> ] Aucun constructeur n'a pu prendre le type de source, ou la résolution de la surcharge du constructeur était ambiguë
C:\Apertium\trunk\apertium\apertium\collection.cc(71) : error C2440: 'initialisation' : impossible de convertir de 'std::_Tree<_Traits>::const_iterator' en 'std::_Tree<_Traits>::iterator' with 
[ _Traits=std::_Tset_traits<int,std::less<int>,std::allocator<int>,false> ] Aucun constructeur n'a pu prendre le type de source, ou la résolution de la surcharge du constructeur était ambiguë
set<int>::const_iterator it = element[i]->begin() works, you know what ? I "despise" STL. ;) Mlavaud 20:52, 24 November 2008 (UTC)
Haha :) Did it work finally? - Francis Tyers 22:00, 24 November 2008 (UTC)
not yet, searching for isinf() definition now. Mlavaud 22:04, 24 November 2008 (UTC)
This will do I hope. Mlavaud 22:33, 24 November 2008 (UTC)
#define isinf(x) ((_fpclass(x) == _FPCLASS_PINF) || (_fpclass(x) == _FPCLASS_NINF))
#define isnan(x) _isnan(x)
This, IIRC, is also fixed in the win32 branch. You're not the first person to suggest something like this - though, also IIRC, there is already an qeuivalent of isinf() in Windows land. And by the way, the correct way to add those kinds of definitions is to add an #ifdef MSCVER or whatever :P --Jimregan 13:13, 25 November 2008 (UTC)

If someone ever compiled this program with Visual Studio, he should tell me how to allow vector<wstring> translation_window[window.size()]; because there too many arrays defined with a variable instead of a constant and I doubt I will be able to fix them all. Mlavaud 22:55, 24 November 2008 (UTC)

I've emailed one of the guys who managed it before, hopefully he will reply here soon... although I suspect that he changed them all, unless there is a flag to Visual Studio? - Francis Tyers 06:27, 25 November 2008 (UTC)
Yes, a VS flag would be nice. Mlavaud 08:55, 25 November 2008 (UTC)
I try this: vector<wstring> *translation_window = new vector<wstring>[window.size()]; [...] delete translation_window;

"if (wcstok(news, delim, &ptr))" -> "if (ptr = wcstok(news, delim))"

strcasecmp() -> strcmpi()

Those are also fixed in the win32 branch. There are still other problems remaining though. One thing is that Windows does something stupid with wstring, and has to be told specifically to open files as unicode. That's fixed in a lot of parts of Apertium, but I'm not sure if I got them all. The other thing is that something gets broken in the tagger in the changes from arrays to vectos, and I still don't know exactly what's happening there -- Jimregan 13:13, 25 November 2008 (UTC)

4 exe compile now but the next one needs the full pcre to link I think, I will have to recompile it first.

Great! Which ones compile ? It would be interesting to see if those that compile work as expected as they have done in the past. - Francis Tyers 10:57, 25 November 2008 (UTC)
The first four in the makefile, I'll check this tonight and I'll do the testing, can you suggest something ? Mlavaud 11:18, 25 November 2008 (UTC)

By the four files you mean: apertium-pretransfer apertium-tagger apertium-preprocess-transfer apertium-filter-ambiguity ? PS. Looking at the Makefile you can remove apertium-lextor, it isn't used at the moment. For testing, how about trying analysis and tagging. Grab the SVN of oc-ca, and do:

$ lt-comp lr apertium-oc-ca.ca.dix ca-oc.automorf.bin
apostrophes@postblank 1001 1543
final@inconditional 28 537
main@standard 36360 66910

$ echo "Això és una prova" | lt-proc ca-oc.automorf.bin 
^Això/Això<prn><tn><p3><nt>$ ^és/ser<vbser><pri><p3><sg>$ ^una/un<num><f><sp>/un<det><ind><f><sg>$ ^prova/prova<n><f><sg>/provar<vblex><imp><p2><sg>/provar<vblex><pri><p3><sg>$

$ echo "Això és una prova" | lt-proc ca-oc.automorf.bin  | apertium-tagger -g ca-oc.prob 
^Això<prn><tn><p3><nt>$ ^ser<vbser><pri><p3><sg>$ ^un<det><ind><f><sg>$ ^prova<n><f><sg>$

- Francis Tyers 11:23, 25 November 2008 (UTC)

Grandmercé l'amic, aquò m'agrada fòrça. Mlavaud 11:40, 25 November 2008 (UTC)
de res ;) - Francis Tyers 11:56, 25 November 2008 (UTC)

Dive right in

Dead link "dive right in" at top of page ? http://wiki.apertium.org/w/index.php?title={{{PAGENAME}}}&action=edit Mlavaud 12:37, 25 November 2008 (UTC)