Re: [Chicken-users] Re : Re: package fmt crash on Windows 7 64-bits

2014-12-15 Thread combier

Hi,

You are right, apply-hack.x86-64.S looks to be disabled. I didn't notice 
before.

Does it mean that Windows 64 bits is not fully supported?

I tried to add Apply-hack.x86-64.S in the build, but it does not compile 
correctly.

Strange, the syntax of the gcc assembly is different from Windows and Linux?

I don't understand why Apply-hack.x86-64.S is available, but not 
compiled on Windows 64.

Is it more complicated than fixing some syntax issues?

Log:
http://paste.call-cc.org/paste?id=f4a486ea0e09e7582dd0b13c21bf7389cb604bdc

Thanks in advance!

Regards,
Pascal


On 12/14/2014 4:36 PM, Christian Kellermann wrote:

Hi!

* f...@laposte.net f...@laposte.net [141213 14:59]: 

I believe it's a 64-bit related issue, because I didn't reproduce
this problem on Windows 32 bits with the same steps (another toolchain
and ARCH=x86).

On 64 bit Windows the apply hack is disabled, we need a port of
that.  Not having the apply hack means that the number of arguments
a procedure can have is limited.

Maybe this causes trouble with the fmt egg...

Kind regards,

Christian




___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


[Chicken-users] package fmt crash on Windows 7 64-bits

2014-12-09 Thread combier
Hello, 

I made some build of chicken on 64 bits and 32 bits. 

Basically, the system looks to work correctly: i tried some random packages, 
for example win32-msgbox works correctly. 
A few other packages also works out-of-the-box, you have made a good job! 

I would like to use slime with Emacs (I used slime with SBCL one year ago). 

It seems the package fmt does not work correctly on the 64 bit build. 
See the logs: 
http://paste.call-cc.org/paste?id=2a057fadcb842db915ed765f3c6ed6b9b063b7a4 
http://paste.call-cc.org/paste?id=d3a88dec6839653f47fdbaa44239f5768f877fd1 

From my tests, the issue does not appear on 32 bits build. 

1. How to fix this issue? 
2. In the case we use the retrieve option of chicken-install to download the 
sources of the packages, how to install the local files locally? 

Thanks in advance. 

Regards, 
Pascal 
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Strange behavior of Chicken Scheme interpreter on Windows 7

2014-12-06 Thread combier
Peter, 

I found the root cause of my issue, it is not related to Chicken Scheme, it's 
pretty simple. 

Actually, it took me a long time to realize there is some kind of sandboxing 
mechanisms in avast! antivirus. 
It redirect the input/output to some temporary window during the scanning of 
the binary file. 
I am sorry for wasting your time! 

 That doesn't make sense. PREFIX is *never* the current directory on 
 Linux. The PREFIX is where you are going to _install_ the program, not 
 where you're compiling it. 

I made a mistake when writing the sentence. 
I now understand there is a big difference between the behavior on Windows and 
Linux. 
On Linux PREFIX is an option, you can decide to set it, but the default 
location is a valid directory. 

Now I am a little bit confused by your answer. 

1. PREFIX looks to be mandatory in Chicken and is an absolute path 
2. I want to package everything in an archive file which will be in different 
places on different computers 

Do you think it can work out-of-the-box playing with environment variables? 
What will be the restrictions? 

Regards, 
Pascal 

- Mail original -

De: Peter Bex peter@xs4all.nl 
À: comb...@laposte.net 
Cc: chicken-users@nongnu.org 
Envoyé: Jeudi 4 Décembre 2014 16:00:26 
Objet: Re: [Chicken-users] Strange behavior of Chicken Scheme interpreter on 
Windows 7 

On Tue, Dec 02, 2014 at 03:20:05PM +0100, comb...@laposte.net wrote: 
 Thank you for your fast answer :) 
 
 My target is to have a standalone archive file (including Chicken + GCC) that 
 I can copy on my USB key and use on different computers. 
 Usage: portable Chicken scheme development environment for Windows without 
 admin privileges. 
 It probably already exist somewhere, but I didn't find the URL. 

I'm not aware of anything like that. 

 I got something not so far from my needs with chicken-iup prebuilt files and 
 a small batch script which override CHICKEN_INSTALL_PREFIX and 
 CHICKEN_PREFIX. 

Cool. 

  Perhaps this has something to do with mingw32-64. Did you read the README 
  instructions to invoke mingw32-make with ARCH=x86-64 and use forward 
  slashes in all paths? If not, does that help? If it doesn't help, is it 
  at all possible to do a 32-bit build on 64-bit Windows? 
 
 If I don't add the option ARCH=x86-64 the compilation phase fails when 
 compiling ASM instructions for apply-hack function. 
 I guess x64 ASM have a different instruction set from 32 bits. 

Yes, that's what ARCH is for. I thought you were trying to build a 
64 bit binary, hence my suggestion. 

 From what I understand, there is no way to cross-compile for Windows 32 bits 
 from a 64 bits host with ming32-64. 
 If you use ARCH=x86-64 it means both HOST and TARGET are 64 bits. 

I don't think there's a Windows-to-Windows cross build. 

 Did you use mingw 32 bits? Which version? I would like to try on my side. 

Yeah, I used the 32-bits mingw. I generally just download the latest 
from the website. 

 Actually I did read the README, but I didn't follow all the instructions: 
 - I didn't set PREFIX, coming from Linux world, I expect it to be the current 
 directory by default 

That doesn't make sense. PREFIX is *never* the current directory on 
Linux. The PREFIX is where you are going to _install_ the program, not 
where you're compiling it. 

 - Since I override 2 variables at execution level, it should have no issue 
 
 Anyway, I have just tried again to compile with an absolute PREFIX including 
 drive letter and normal slash /. 
 The issue remains. I tried with the 2 compilers. 

Did you set PREFIX to the target where you are going to install it, or to 
the directory where the CHICKEN sources are? If the latter, that's 
probably what's going wrong. 

 Honestly, I don't understand the needs to have an absolute PREFIX. 
 In the common cases, when you want to use unix tools on Windows, you just 
 have to override the PATH locally with batch script. 
 Can you confirm the PREFIX is not mandatory and can be overridden by 
 environment variables at execution level? 

No, PREFIX is required and I think it really must be an absolute path. 

Cheers, 
Peter 
-- 
http://www.more-magic.net 

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Strange behavior of Chicken Scheme interpreter on Windows 7

2014-12-02 Thread combier
Thank you for your fast answer :) 

My target is to have a standalone archive file (including Chicken + GCC) that I 
can copy on my USB key and use on different computers. 
Usage: portable Chicken scheme development environment for Windows without 
admin privileges. 
It probably already exist somewhere, but I didn't find the URL. 

I got something not so far from my needs with chicken-iup prebuilt files and a 
small batch script which override CHICKEN_INSTALL_PREFIX and CHICKEN_PREFIX. 

Now I would like to compile Chicken from sources for Windows 32 and 64 bits. 

 Perhaps this has something to do with mingw32-64. Did you read the README 
 instructions to invoke mingw32-make with ARCH=x86-64 and use forward 
 slashes in all paths? If not, does that help? If it doesn't help, is it 
 at all possible to do a 32-bit build on 64-bit Windows? 

If I don't add the option ARCH=x86-64 the compilation phase fails when 
compiling ASM instructions for apply-hack function. 
I guess x64 ASM have a different instruction set from 32 bits. 
From what I understand, there is no way to cross-compile for Windows 32 bits 
from a 64 bits host with ming32-64. 
If you use ARCH=x86-64 it means both HOST and TARGET are 64 bits. 

Did you use mingw 32 bits? Which version? I would like to try on my side. 

Actually I did read the README, but I didn't follow all the instructions: 
- I didn't set PREFIX, coming from Linux world, I expect it to be the current 
directory by default 
- Since I override 2 variables at execution level, it should have no issue 

Anyway, I have just tried again to compile with an absolute PREFIX including 
drive letter and normal slash /. 
The issue remains. I tried with the 2 compilers. 

Honestly, I don't understand the needs to have an absolute PREFIX. 
In the common cases, when you want to use unix tools on Windows, you just have 
to override the PATH locally with batch script. 
Can you confirm the PREFIX is not mandatory and can be overridden by 
environment variables at execution level? 

Regards, 

Pascal 

- Mail original -

De: Peter Bex peter@xs4all.nl 
À: comb...@laposte.net 
Cc: chicken-users@nongnu.org 
Envoyé: Lundi 1 Décembre 2014 23:15:26 
Objet: Re: [Chicken-users] Strange behavior of Chicken Scheme interpreter on 
Windows 7 

On Mon, Dec 01, 2014 at 03:40:10PM +0100, comb...@laposte.net wrote: 
 Hi everybody, 

Hello and welcome to CHICKEN! 

 My problem is not really an issue, since the scheme interpreter is working 
 correctly in my test conditions. 
 But I noticed a strange behavior on Chicken interpreter with my 4.9.0.1 build 
 of Chicken. 
 
 Expected behavior: 
 - open cmd.exe and cd to the build directory 
 - type csi 
 - the current version, build date and additional information is displayed in 
 the SAME terminal 
 - the REPL let write Scheme program in the SAME terminal 

This is what should happen. 

 Observed behavior: 
 - open cmd.exe and cd to the build directory 
 - type csi 
 - A new window is opened (looks like a cmd.exe terminal), the current 
 version, build date and additional information is displayed in this window 
 - (wait around 15 seconds) 
 - The new window is automatically closed (!) and all the output of the closed 
 window in redirected in the original terminal 

This definitely should not happen. 

 This behavior does not appears in the prebuilt binaries of chicken-iup (32 
 bits). 
 
 2 questions: 
 - This behavior is it normal? Can it be explained? 

It is definitely not normal, and I can't explain it. I've never seen 
this happen, and I've built CHICKEN on Windows quite a few times already. 

 - How to avoid this behavior? 

Without knowing why it happens, I'm afraid I can't tell you how to avoid it. 

 Conditions: 
 - Windows 7 64-bits, Intel 
 - Compiled from sources with Mingw (tried with mingw32-64 SJLC, mingw32-64 
 FEH) 
 - Chicken Scheme 4.9.0.1 (also tried with chicken-4.6.3, chicken-4.8.0.5, 
 chicken-4.8.1) 
 - With the makefile.mingw and makefile.mingw-MSYS (msys binaries of 2011) 

Perhaps this has something to do with mingw32-64. Did you read the README 
instructions to invoke mingw32-make with ARCH=x86-64 and use forward 
slashes in all paths? If not, does that help? If it doesn't help, is it 
at all possible to do a 32-bit build on 64-bit Windows? 

Cheers, 
Peter 
-- 
http://www.more-magic.net 

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


[Chicken-users] Strange behavior of Chicken Scheme interpreter on Windows 7

2014-12-01 Thread combier
Hi everybody, 

My problem is not really an issue, since the scheme interpreter is working 
correctly in my test conditions. 
But I noticed a strange behavior on Chicken interpreter with my 4.9.0.1 build 
of Chicken. 

Expected behavior: 
- open cmd.exe and cd to the build directory 
- type csi 
- the current version, build date and additional information is displayed in 
the SAME terminal 
- the REPL let write Scheme program in the SAME terminal 

Observed behavior: 
- open cmd.exe and cd to the build directory 
- type csi 
- A new window is opened (looks like a cmd.exe terminal), the current version, 
build date and additional information is displayed in this window 
- (wait around 15 seconds) 
- The new window is automatically closed (!) and all the output of the closed 
window in redirected in the original terminal 

So basically, everything works correctly except that there is a strange 
temporary window which appears and take input/output for around 15 seconds. 
The output of the window is redirected to the original window, with some 
undefined mechanism (pipe? socket?). 

This behavior does not appears in the prebuilt binaries of chicken-iup (32 
bits). 

2 questions: 
- This behavior is it normal? Can it be explained? 
- How to avoid this behavior? 

Conditions: 
- Windows 7 64-bits, Intel 
- Compiled from sources with Mingw (tried with mingw32-64 SJLC, mingw32-64 FEH) 
- Chicken Scheme 4.9.0.1 (also tried with chicken-4.6.3, chicken-4.8.0.5, 
chicken-4.8.1) 
- With the makefile.mingw and makefile.mingw-MSYS (msys binaries of 2011) 

Thank you in advance. 

Pascal 
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users