Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

\[cmd] fails #581

Closed
hkinds opened this issue Jan 29, 2020 · 27 comments
Closed

\[cmd] fails #581

hkinds opened this issue Jan 29, 2020 · 27 comments
Labels

Comments

@hkinds
Copy link

hkinds commented Jan 29, 2020

When I start the latest version (1.959 kB with msys-2.0.dll) the cmd-line does not run, e.g. \dir yields a domain error.

@tavmem tavmem added the bug label Feb 3, 2020
@tavmem
Copy link
Collaborator

tavmem commented Feb 6, 2020

There are now 2 bugs in Windows (this one and #464).
My msys environment has not been working at all for quite a while.
Seems like it's time that I fixed it.

@tavmem
Copy link
Collaborator

tavmem commented Feb 6, 2020

Got my msys2 environment to work.
Could not replicate the domain error

$ ./k
kona      \ for help. \\ to exit.

  \dir
bench  k.exe  k_test.exe  Kona.png  LICENSE  Makefile  misc  README.md  src  verb

Maybe it's because I am using msys2 and you are using msys.

@tavmem
Copy link
Collaborator

tavmem commented Feb 6, 2020

Just published release 72 with k, k_test and msys-2.0.dll that works on my Windows box.

@hkinds
Copy link
Author

hkinds commented Feb 6, 2020 via email

@tavmem
Copy link
Collaborator

tavmem commented Feb 6, 2020

Yes, I am aware that you are experiencing the domain error.
Trying to figure out why.
One possibility is a difference in our versions of msys-2.0.dll

Could you please download release 72 into a separate folder on your Windows box and then double click on k in that folder using Windows file explorer?

Let me know if kona still fails when using that procedure.

@hkinds
Copy link
Author

hkinds commented Feb 7, 2020 via email

@hkinds
Copy link
Author

hkinds commented Feb 7, 2020 via email

@tavmem
Copy link
Collaborator

tavmem commented Feb 7, 2020

Strange ...
I am running Windows 10 Pro
Version 1809
64 bit operating system, x64-based Intel processor

@tavmem
Copy link
Collaborator

tavmem commented Feb 8, 2020

Upgraded my box to Windows 10 Pro Verseion 1909
(the latest available)

If I start kona using a msys2 console, \dir works:

$ pwd
/home/tavme/kona
$ ./k
kona      \ for help. \\ to exit.

  \dir
bench  k.exe  k_test.exe  Kona.png  LICENSE  Makefile  misc  msys-2.0.dll  README.md  src  verb

and k_test works:

$ ./k_test
t:0
t:50
t:100
t:150
t:200
t:250
t:300
t:350
t:400
t:450
t:500
t:550
t:600
t:650
t:700
t:750
t:800
t:850
t:900
t:950
t:1000
t:1050
t:1100
Test pass rate: 1.0000, Total: 1124, Passed: 1091, Skipped: 33, Failed: 0, Time: 0.421000s
OK

If I start kona using file explorer by double-clicking on k
then I get the error you describe

kona      \ for help. \\ to exit.

  \dir
domain error
>

but, if I run k_test from file explorer, it works

t:0
t:50
t:100
t:150
t:200
t:250
t:300
t:350
t:400
t:450
t:500
t:550
t:600
t:650
t:700
t:750
t:800
t:850
t:900
t:950
t:1000
t:1050
t:1100
Test pass rate: 1.0000, Total: 1124, Passed: 1091, Skipped: 33, Failed: 0, Time: 0.422000s
OK
kona      \ for help. \\ to exit.

@tavmem
Copy link
Collaborator

tavmem commented Feb 10, 2020

On my box, the problem is the "system" call to Windows.
Making this change to one line in src/c.c

$ git diff
diff --git a/src/c.c b/src/c.c
index c8e6303..938e141 100644
--- a/src/c.c
+++ b/src/c.c
@@ -439,7 +439,7 @@ K backslash(S s, I n, K*dict)
 #ifdef WIN32
   s++;
 #endif
-  R system(s)?DOE:_n();
+  O("S: %s\n",s); I z=system(s); O("z: %lld\n",z); R z?DOE:_n();
 }

 Z K backslash_b(S s,I n) {
$

Then, using an MSYS2 console

$ ./k
kona      \ for help. \\ to exit.

  \dir
S: dir
bench  k.exe  k_test.exe  Kona.png  LICENSE  Makefile  misc  README.md  src  verb
z: 0

Running from file explorer

kona      \ for help. \\ to exit.

  \dir
S: dir
z: 127
domain error
>

Not sure how to fix this.
I am quite sure that this worked fine using Windows Pro Version 1809,
and became broken when updating to version 1909.
I don't know what version you use, but you have problems with both kona and k_test, and you have problems when using an msys2 console and when using file explorer.

k_test works fine on my box using either a MSYS2 console or from file explorer with version 1909.

However, I have k3.2 on the same box.
It uses a custom file named k20.dll instead of msys-2.0.dll
It has no problems under Wondows Pro version 1909, using an MSYS2 console or file explorer.
The results are somewhat different than kona (but the same in both the console and explorer):

$ ./k
K 3.2 2005-06-25 Copyright (C) 1993-2004 Kx Systems
  \dir
 Volume in drive C is OS
 Volume Serial Number is 80D8-1879

 Directory of C:\msys64\home\tavme\k3.2

02/09/2020  06:33 PM    <DIR>          .
02/09/2020  06:33 PM    <DIR>          ..
05/19/2019  07:54 PM    <DIR>          doc
08/31/2014  11:27 AM             3,072 k.exe
08/31/2014  11:27 AM           181,760 k20.dll
01/07/2008  03:54 PM           778,673 kdoc.zip
01/07/2008  03:56 PM           139,776 ksetup.exe
01/07/2008  03:54 PM           127,417 kwin.zip
02/06/2020  07:53 PM                20 x.bat
               6 File(s)      1,230,718 bytes
               3 Dir(s)  48,113,115,136 bytes free

However, one major difference is that k3.2 is 32 bit.

@tavmem
Copy link
Collaborator

tavmem commented Feb 10, 2020

The following is from http://wiki-errors.com/err.php?wiki=127

127 Error Code is caused in one way or another by misconfigured system files 
in your windows operating system.

So, If you got 127 Error then We strongly recommend that 
you Download (Error 127) Repair Tool.

@tavmem
Copy link
Collaborator

tavmem commented Feb 10, 2020

However, that website seems to be for Windows 7, Vista XP and 2000.

@hkinds
Copy link
Author

hkinds commented Feb 10, 2020 via email

@tavmem
Copy link
Collaborator

tavmem commented Feb 10, 2020

I don't use a Windows virtual box either. I use 3 separate machines: one for Fedora, one for Windows and one for MacOS. I find that easier.

It seems that my Windows box may also have gotten mis-configured also when I upgraded from version 1809 to version 1909, but probably not as badly as yours as "\dir" still works form an msys2 console.
It is theoretically possible for me to restore my Windows system back to version 1809 and verify that "\dir" works there when starting kona from file explorer. But that is only if I had set up a System Restore point before upgrading to version 1909, and of course, I failed to do that.

I don't see how the k3.2 files would help you. They aren't helping me.
I can run k3.2, but they don't help me fix the mis-configuration problem with kona.
k3.2 uses a file named k20.dll, instead of msys-2.0.dll
When you move k20.dll to the kona directory instead of msys-2.0.dll, msys2 fails to work.
Even if you rename k20.dll to msys-2.0.dll, the renamed file is 32-bit and kona is 64 bit.
Furthermore, my license for k3.2 does not allow me to share the files with anyone else.
In addition to that, there is some sort of secret safeguard somewhere.
I once tried to move k3.2 to one of my other Windows boxes and it would not work there!

@hkinds
Copy link
Author

hkinds commented Feb 12, 2020 via email

@tavmem
Copy link
Collaborator

tavmem commented Feb 12, 2020

Hi --
All the documentation is already accessible from the wiki at kona on GitHub.
Scroll down in the wiki to "Links".
Near the end you will see entries for:

  • K 2.0 User Manual
  • K 2.0 Reference Manual
  • K 2.0 C-K Interface Manual

These are exactly the documents that are contained in kdoc.zip on my computer.
New manuals for K3 were never produced.

@hkinds
Copy link
Author

hkinds commented Feb 12, 2020 via email

@tavmem
Copy link
Collaborator

tavmem commented Mar 3, 2020

So ... the above raises the question:
How are you starting kona? :

  • are you using an msys2 console and using the command ./k, or
  • are you using file explorer and double clicking on k

@tavmem
Copy link
Collaborator

tavmem commented Mar 4, 2020

I downloaded the kona version of k.exe and msys-2.0.dll to another Windows computer that did not have msys2 installed on it. I started kona from File Explorer and got the same domain error when running \dir.

My hypothesis is that the msys2 console is required for \[cmd] to work using kona on a Windows machine when the executable release was created using msys2.

I think that I need to use an environment other than msys2 to create the k.exe executable where a user of a kona release is not required to install the console for that environment on their machine.

@tavmem
Copy link
Collaborator

tavmem commented Mar 4, 2020

I think that I will probably try the Fedora cross-compiler (which uses Mingw-w64).

@hkinds
Copy link
Author

hkinds commented Mar 5, 2020 via email

@tavmem
Copy link
Collaborator

tavmem commented Mar 5, 2020

As a further test of the hypothesis, I wrote the following simplistic program:

$ cat tst.c
#include <stdio.h>
#include <stdlib.h>

int value=0;

int main()
{ int n=system("dir");
  if(n) printf("error\n");
  scanf("%d",&value);       // waits for you to enter a number
  return 0; }

$

I compiled it in 2 different ways
tst1.exe was compiled on a Windows machine in an msys2 console.
tst2.exe was compiled on a Fedora machine using the cross-compiler.

When I run tst1.exe on the Windows box from an msys2 console, I get

$ ./tst1.exe
msys-2.0.dll  tst.c  tst1.exe  tst2.exe

When I run tst1.exe on the Windows box by double clicking from File Explorer, I get

error

When I run tst2.exe on the Windows box from an msys2 console, I get

$ ./tst2.exe
 Volume in drive C is OS
 Volume Serial Number is 80D8-1879

 Directory of C:\msys64\home\tavme\test

03/05/2020  02:09 PM    <DIR>          .
03/05/2020  02:09 PM    <DIR>          ..
03/03/2020  11:31 PM         3,209,960 msys-2.0.dll
03/05/2020  01:40 PM               193 tst.c
03/05/2020  01:41 PM           143,658 tst1.exe
03/05/2020  01:55 PM            92,964 tst2.exe
               4 File(s)      3,446,775 bytes
               2 Dir(s)  69,513,404,416 bytes free

I get the very same result when I run tst2.exe by double clicking it from File Explorer.

@tavmem
Copy link
Collaborator

tavmem commented Mar 5, 2020

Using the Fedora cross-compiler is not a solution.
The cross-compiler uses Mingw-w64, which is a very minimal port of the GCC compiler for the Windows environment.
When you compile kona using the cross-compiler, you find a multitude of missing elements.
These incude (but are not limited to):

undefined reference to `mmap'
undefined reference to `munmap'
undefined reference to `msync'
undefined reference to `pread'
undefined reference to `dlerror'
undefined reference to `dlsym'
undefined reference to `__imp_send'
undefined reference to `__imp_getaddrinfo'
undefined reference to `__imp_socket'
undefined reference to `__imp_connect'
undefined reference to `__imp_WSAGetLastError'
undefined reference to `__imp_closesocket'
undefined reference to `__imp_freeaddrinfo'
undefined reference to `__imp_send'
undefined reference to `__imp_recv'
undefined reference to `__imp_gethostname'
undefined reference to `__imp_htonl'
undefined reference to `__imp_getnameinfo'
undefined reference to `__imp_getaddrinfo'
undefined reference to `__imp_ntohl'
undefined reference to `fnmatch'
undefined reference to `win_usleep'
undefined reference to `__imp_WSACleanup'
undefined reference to `__imp_WSAStartup'

However, kona appears to work fine if you compile it and run it from an Msys2 console on Windows.
This is because Msys2 is a much more complete port of the GCC compiler to Windows.

I am closing this issue.
People cloning the kona repository to Windows already need the Msys2 environment to compile it.
I will include a note in each pre-compiled release that you need to run kona from an Msys2 console in order for it to work properly on Windows.

It is not that difficult for someone who wishes to to use kona on Windows to install Msys2 on their machine.

@tavmem tavmem closed this as completed Mar 5, 2020
@tavmem tavmem reopened this Mar 5, 2020
@tavmem
Copy link
Collaborator

tavmem commented Mar 5, 2020

Just re-opened this issue.

I had begun deleting very old releases of kona as I thought they were of little use to anyone.
I noticed that some of these old releases mentioned that they had been compiled on Mingw-w64.

In retrospect, I'm sorry that I deleted the very old releases as some of the descriptive text outlined testing procedures for multiple sessions of kona.

But more to the point:

  • the remaining oldest release does work on Windows if started from File Explorer without having msys-2.0.dll in the same directory.
  • although the Fedora cross-compiler did not work for me, it should be possible to get kona to compile on Mingw-w64 somehow, since I did it successfully years ago (when I had a different Windows machine).

As an additional note:
If you try \dir on the oldest remaining release you get the error message that \dir is not recognized as an internal or external command.
That is because when using Mingw-w64 the initial backslash should not be included in passing the system command to Windows.

@tavmem
Copy link
Collaborator

tavmem commented Mar 8, 2020

This is a note from the Fedora documentation:

Setting up a cross-building environment is oftentimes more work than it is worth. 
If you can compile applications and build packages on the target system, do that. 
The cross-building option should be used only if you really cannot build packages 
on the target system.

As I have a Windows system, I'm going to stop trying to get it to work using the Fedora cross compiler.

@tavmem tavmem closed this as completed in 79a5e0a Mar 10, 2020
@hkinds
Copy link
Author

hkinds commented Mar 11, 2020 via email

@tavmem
Copy link
Collaborator

tavmem commented Mar 11, 2020

Thanks !!

All bug issues are now resolved.
There is 1 remaining crash issue (#468) ... but that issue initially identified 12,380 cases in which invalid syntax can cause a segmentation fault in the kona interpreter.
That issue will probably take a long time to completely rectify.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants