Re: [Chicken-users] Windows deployment - Numbers egg

[Robert Herman]

Matt,

I tried -deploy, -deploy -static, -static combinations.

"csc -deploy -static Pi-Ch.scm" creates a deploy directory, and the
resulting executable is 1.6MB vs 77KB, but it still throws the "cannot the
load the extension: numbers".

I then tried putting libchicken.dll in the deploy directory that was
created, and making numbers.so a numbers.dll file, since Windows does not
use .so files, only .dll. I used chicken-install -r to retrieve the numbers
egg into the current directory. I then tried "csc -dll numbers.scm" and it
created numbers.so. I tried putting it in the deploy directory, but no
luck. I changed the .so to .dll, and again no luck.

I know why some people fall back on Java or Clojure: One example is
Nightcode or Nightmod. They both have a single jar file, Nightmod or
Nightcode, that is a full IDE, and can deploy to all platforms with a
single click, no fuss (except you're on the JVM!). I really don't like
Clojure or Java, but I can only get CHICKEN working within MinGW on
Windows, and then I am still not able to deploy a working exe file to
anybody else who does not have a full install of CHICKEN and MinGW. Please
help me stay in the CHICKEN :) Please!

Rob

On 4 October 2015 at 13:31, Matt Welland  wrote:

> An alternative to statically compiling is to use the deploy feature of csc
> to make a directory with all the items you need. When you start working
> with IUP I think it will be your only choice. Here is a snippet of a
> Makefile that I used to deploy a project to a directory on windows. You can
> then use Inno Setup to make an installer
> http://www.jrsoftware.org/isinfo.php with the directory contents or just
> zip it up and share.
>
> =Makefile example===
>
> PROXY =
>
> CHICKEN_INSTALL=chicken-install $(PROXY) -deploy -p farmsim
>
> farmsim/farmsim : farmsim.scm boxes.scm common.scm ezxcolors.scm 
> simevents.scm farmsim/coops.so farmsim/format.so farmsim/ezxdisp.so 
> farmsim/ezxgui.so farmsim/qtree.so farmsim/vcd.so farmsim/geolib.so 
> farmsim/pdf.so farmsim/regex.so
>   csc -deploy farmsim.scm
>
> farmsim/coops.so :
>   $(CHICKEN_INSTALL) coops
>
> farmsim/ezxdisp.so :
>   $(CHICKEN_INSTALL) ezxdisp
>
> farmsim/regex.so :
>   $(CHICKEN_INSTALL) regex
>
> farmsim/pdf.so :
>   $(CHICKEN_INSTALL) pdf
>
> farmsim/format.so :
>   $(CHICKEN_INSTALL) format
>
> farmsim/regex.so :
>   $(CHICKEN_INSTALL) regex
>
> farmsim/qtree.so : # $(MATTSUTILS)/qtree/qtree.scm
>   $(CHICKEN_INSTALL) qtree -l $(MATTSUTILS) -transport local
>
> farmsim/vcd.so :   # $(MATTSUTILS)/vcd/vcd.scm
>   $(CHICKEN_INSTALL) vcd -l $(MATTSUTILS) -transport local
>
> farmsim/ezxgui.so : # $(MATTSUTILS)/ezxgui/ezxgui.scm
>   $(CHICKEN_INSTALL) ezxgui -l $(MATTSUTILS) -transport local
>
> farmsim/geolib.so : # $(MATTSUTILS)/geolib/geolib.scm
>   $(CHICKEN_INSTALL) geolib -l $(MATTSUTILS) -transport local
>
>
> On Sat, Oct 3, 2015 at 6:50 PM, Robert Herman  wrote:
>
>> I have been learning Chicken by incrementally building a program that
>> returns a number of digits of Pi based on an already-existing algorithm
>> that implements the Chudnovsky method. I have a command line version
>> working, thanks to all of the help here, that writes the file as well as
>> displays the output in the command line.
>> If I just: csc Pi-Ch.scm I get a 77kB exe that runs fine on my machine.
>> In order to share it with my son, I need to statically compile it with all
>> of its dependencies, like so:
>>
>> csc -deploy -static Pi-Ch.scm
>>
>> I returns an error:
>>
>> Error: (require) cannot load extension: numbers
>> Call history:
>> Pi-Ch.scm:16: ##sys#require <--
>>
>> I found the numbers.so file, but Windows needs a dll file. I plan on
>> downloading the numbers egg source, and seeing if there's any reason I
>> could not compile the numbers.so file to numbers.dll. Any leads or tips?
>>
>> Next step will be to create an IUP GUI for the program to complete the
>> exercise.
>>
>> Thanks!
>>
>> Rob
>>
>> PS: Here's the code to date:
>>
>> ;;; Program to use the chudnovsky formula to compute pi.
>> ;;; Written by Bakul Shah.
>> ;;; Changed by Bradley Lucier to use standard arithmetic operations
>> ;;; available in Gambit Scheme and to replace (floor (/ ...)) by
>> ;;; (quotient ...)
>>
>> ;; Don't try running this benchmark with Gauche, it'll consume all
>> ;; your computer's memory!
>>
>>  I removed the conditional statements to make it run across different
>>  scheme implementations.
>>  I added the use numbers and extras at the top, and the last 8 lines
>>  to prompt user and to display the results and write to a file.
>>  TODO: Deploy to Windows 32-bit, and create an IUP-based GUI for it.
>>  RPH - 4/10/2015
>>
>> (use numbers extras)
>>
>> (define integer-sqrt exact-integer-sqrt)
>>
>> (define ch-A 13591409)
>> (define ch-B 545140134)
>> (define ch-C 640320)
>> 

Re: [Chicken-users] Windows deployment - Numbers egg

[Peter Bex]

On Sun, Oct 04, 2015 at 10:51:49PM +0800, Robert Herman wrote:
> Whoa! Hold on. When I ran "csc -deploy Pi-Ch.scm" it created a 77kb exe
> Pi-Ch.exe in a newly-created directory, Pi-Ch. When I look at the command
> line information, I found this error:
> 
> C:\Users\Robert\Desktop\Chicken-IUP-Examples\Pi>csc -deploy Pi-Ch.scm
> The system cannot find the file specified.
> 
> Error: shell command terminated with non-zero exit status 1: "copy /Y
> "c:\chicken-iup\lib\libchicken.dll" "Pi-Ch""

This looks like you may have renamed the chicken directory.  Is that
possible?

> I manually copied numbers.so into the Pi-Ch directory and libchicken.dll,
> and it ran! Thanks to all.

I'm not sure if that's going to work in the general case.  If you
include an egg that itself depends on other eggs, it might not be
able to load them because the egg doesn't know it's linked into a
deployed executable.

> Next question is what does 'csc -static' do?

It's supposed to generate a statically linked executable.

> I don't mind sending libchicken.dll and numbers.so along with the exe,
> but why does 'csc -dynamic -static Pi-Ch.scm' do the same,

I think those options are supposed to be mutually exclusive, but
maybe the latter overrides the former.

Compiling a program statically only works if you also have static
versions of all the libraries it uses.  Most eggs don't install
static copies of their libraries (neither does numbers).  Besides,
(use numbers) says "load the numbers module dynamically".  If you
want to compile statically, you'd have to do something like

(declare (uses numbers))
(import numbers)

But I'm not 100% sure.  This is going to be made easier in CHICKEN 5,
at least that's the plan.

> but the exe is now 1.6mb vs 77kb?

It does include libchicken.dll (but not numbers because you didn't
declare it statically)

> I was hoping the two csc switches would combine numbers.os and
> libchicken.dll in the exe, in other words, statically link them.

You can't load a .dll file statically; it's inherently dynamic.
However, if you have libchicken.a, you can link _that_ statically
into your program.  Like I said, you'll also need to somehow create
a "numbers.a" file to link into your program.

> Also, I guess there is some issue with the copy command in
> MinGW64-32 bit or paths, but the format looks correct even in the
> Error line?

Does the file it mentions exist?

Cheers,
Peter


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

Re: [Chicken-users] Windows deployment - Numbers egg

[Robert Herman]

Yes, I read the manual. All of the examples seem to be a linux host with
.so files. Windows uses .dll files.
When I try to deploy a static build of the exe, it makes an exe, and the
size makes you think it has bundled any dependencies like numbers (from
77kb to 1.6mb), but on MinGW64-32 bit, it hasn't. If you try and run the
exe on a different Windows box, or through a non-MinGW command line on the
same Windows box, it complains it cannot find the numbers extension. My
guess is that it has statically linked and bundled libchicken.dll in the
exe, but not the numbers extension that is in a '(use numbers)' statement
in the source file.
If I simply compile the file in the MinGW command line, the exe works
perfectly. It knows where to find the numbers library it needs, my guess
from the CHICKEN install directory. The program works. What I am trying to
do is make a static exe with the dependencies all in the exe. This way I
can give it to somebody who is not a programmer and does not have CHICKEN
installed, to run as is. Later I would like to dynamically compile, so the
user only needs the libchicken.dll once, but I would like to statically
link any program-specific libs (like numbers). This way the user only needs
one copy of libchicken.dll in a directory, and any exe I send them will
have the oddball dependencies statically linked right in the exe.
For instance, the same program on a Gambit-C MinGW64-64 bit system is
compiled: "gsc -exe "file.scm"" The resulting exe (4 mb) runs to whomever I
send it on their Windows box. It includes all of what it needs, i.e. the
gambit runtime dll, and any libs (like numbers). I guess they made Gambit-C
more Windows friendly, but it  alas it does not have the packages CHICKEN
has. On the other hand, if the packages (eggs) only work  if you have
MinGW64-32 bit installed with a CHICKEN dev environment, it sort of defeats
the purpose of being able to create stand alone exe files.

I apologize for the lengthy description, and I am grateful for the help! I
hope I was clear (need sleep) :)

Rob

On 4 October 2015 at 21:30, Peter Bex  wrote:

> On Sun, Oct 04, 2015 at 08:50:59PM +0800, Robert Herman wrote:
> > Matt,
> >
> > "csc -deploy -static Pi-Ch.scm" creates a deploy directory, and the
> > resulting executable is 1.6MB vs 77KB, but it still throws the "cannot
> the
> > load the extension: numbers".
> >
> > I then tried putting libchicken.dll in the deploy directory that was
> > created, and making numbers.so a numbers.dll file, since Windows does not
> > use .so files, only .dll.
>
> I think this is incorrect; looking at my VM mingw install, and all the eggs
> (even all the import libraries from CHICKEN core), it uses .so for all the
> dynamically loaded extensions.  And if I install it normally, and type
> (use numbers) at the REPL, it prints that it's loaded /path/to/numbers.so
>
> Renaming manually is something I would definitely not recommend, because
> then you would be messing with the names that CHICKEN expects.
>
> > I used chicken-install -r to retrieve the numbers
> > egg into the current directory. I then tried "csc -dll numbers.scm" and
> it
> > created numbers.so. I tried putting it in the deploy directory, but no
> > luck. I changed the .so to .dll, and again no luck.
>
> I've tried to do it "by the book" on mingw (msys):
>
> $ /path/to/chicken-install.exe numbers
> $ echo '(use numbers) (print 1/2)' > foo.scm
> $ /path/to/csc.exe -deploy -X numbers-syntax foo.scm
> $ /path/to/chicken-install.exe -deploy -prefix foo numbers
> $ # To prove that it's not loading numbers from install dir:
> $ /path/to/chicken-uninstall.exe numbers
> $ ./foo/foo.exe
> 1/2
>
> This works perfectly.  The book, incidentally, is here:
> http://wiki.call-cc.org/man/4/Deployment
>
> Hope this helps,
> Peter
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Hypergiant egg install fails, and some other eggs

[Peter Bex]

On Sun, Oct 04, 2015 at 10:50:24AM -0600, Jeremy Steward wrote:
> I suppose as one of the few people who has used / uses CHICKEN on
> Windows I should chime in :)

Thanks for this!

> On 02/10/15 12:57 PM, Peter Bex wrote:
> > The reason behind this seems to be that Blas itself is a bit of an
> > old-fashioned library[...]
> 
> BLAS is problematic not because it is old, but because it is made
> available through multiple implementations. For example, BLAS can be
> made available through Intel's MKL, ATLAS, OpenBLAS, and of course the
> original netlib.org reference implementation. Keep in mind BLAS is
> often implemented in Fortran and then exported to C, so depending on
> your implementation you might also need to expose `-lgfortran` to csc
> as well.

Thanks for explaining this.  It's good to know about that.  Do none
of the BLAS implementation offer pkg-config support, though?  Even
if you only support one BLAS library, it can still be installed in
several different locations, depending on the platform and packaging
system used.

> Agreed, please do not give up. Currently the way I use CHICKEN on
> Windows is through Cygwin, because it is currently the easiest way to
> install and link things (using plain MinGW64 is an exercise in
> patience, IMO). Hopefully the midipix project (http://midipix.org/)
> picks up, which will provide a much better way to use CHICKEN (and
> other C libraries / programs) on Windows.

Wow, this Midipix project sounds very promising!  Definitely something
to keep an eye on, so we can (eventually?) get rid of the mess that
is cygwin & mingw.

Cheers,
Peter


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

Re: [Chicken-users] Windows deployment - Numbers egg

[Peter Bex]

On Sun, Oct 04, 2015 at 08:50:59PM +0800, Robert Herman wrote:
> Matt,
> 
> "csc -deploy -static Pi-Ch.scm" creates a deploy directory, and the
> resulting executable is 1.6MB vs 77KB, but it still throws the "cannot the
> load the extension: numbers".
> 
> I then tried putting libchicken.dll in the deploy directory that was
> created, and making numbers.so a numbers.dll file, since Windows does not
> use .so files, only .dll.

I think this is incorrect; looking at my VM mingw install, and all the eggs
(even all the import libraries from CHICKEN core), it uses .so for all the
dynamically loaded extensions.  And if I install it normally, and type
(use numbers) at the REPL, it prints that it's loaded /path/to/numbers.so

Renaming manually is something I would definitely not recommend, because
then you would be messing with the names that CHICKEN expects.

> I used chicken-install -r to retrieve the numbers
> egg into the current directory. I then tried "csc -dll numbers.scm" and it
> created numbers.so. I tried putting it in the deploy directory, but no
> luck. I changed the .so to .dll, and again no luck.

I've tried to do it "by the book" on mingw (msys):

$ /path/to/chicken-install.exe numbers
$ echo '(use numbers) (print 1/2)' > foo.scm
$ /path/to/csc.exe -deploy -X numbers-syntax foo.scm
$ /path/to/chicken-install.exe -deploy -prefix foo numbers
$ # To prove that it's not loading numbers from install dir:
$ /path/to/chicken-uninstall.exe numbers
$ ./foo/foo.exe
1/2

This works perfectly.  The book, incidentally, is here:
http://wiki.call-cc.org/man/4/Deployment

Hope this helps,
Peter


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

Re: [Chicken-users] Windows deployment - Numbers egg

[Peter Bex]

On Sun, Oct 04, 2015 at 10:23:26PM +0800, Robert Herman wrote:
> Yes, I read the manual. All of the examples seem to be a linux host with
> .so files. Windows uses .dll files.

Hi again Robert,

This is of course true, but the .so files that CHICKEN generates on mingw
are just misnamed .dll-files.  Try running "file" on it to inspect the
type; it'll let you know that they're DLL files.  I suppose because
CHICKEN loads those dynamically, the extension is irrelevant.

> When I try to deploy a static build of the exe, it makes an exe, and the
> size makes you think it has bundled any dependencies like numbers (from
> 77kb to 1.6mb), but on MinGW64-32 bit, it hasn't. If you try and run the
> exe on a different Windows box, or through a non-MinGW command line on the
> same Windows box, it complains it cannot find the numbers extension. My
> guess is that it has statically linked and bundled libchicken.dll in the
> exe, but not the numbers extension that is in a '(use numbers)' statement
> in the source file.

I don't know about static linking on Windows, but the deploy mode should
take care of this.

> On the other hand, if the packages (eggs) only work  if you have
> MinGW64-32 bit installed with a CHICKEN dev environment, it sort of defeats
> the purpose of being able to create stand alone exe files.

This is also true of course.  However, I tested again on the Windows Vista
box I tried earlier.   I even renamed the chicken directory so it couldn't
possibly be found by the binary I produced.  Worked like a charm.

> I apologize for the lengthy description, and I am grateful for the help! I
> hope I was clear (need sleep) :)

If you're really tired, perhaps tomorrow you can take a look at it with
a fresh mind.  Just follow the steps I did, and you'll see it'll produce
a directory which includes the binary and any dependencies, and you can
take it and move to another Windows machine, and it will "just work".

If it still doesn't work, can you provide is with _exactly_ the steps
you did, so we can try to reproduce it?

Cheers,
Peter


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

Re: [Chicken-users] Windows deployment - Numbers egg

[Robert Herman]

Whoa! Hold on. When I ran "csc -deploy Pi-Ch.scm" it created a 77kb exe
Pi-Ch.exe in a newly-created directory, Pi-Ch. When I look at the command
line information, I found this error:

C:\Users\Robert\Desktop\Chicken-IUP-Examples\Pi>csc -deploy Pi-Ch.scm
The system cannot find the file specified.

Error: shell command terminated with non-zero exit status 1: "copy /Y
"c:\chicke
n-iup\lib\libchicken.dll" "Pi-Ch""

I manually copied numbers.so into the Pi-Ch directory and libchicken.dll,
and it ran! Thanks to all.

Next question is what does 'csc -static' do? I don't mind sending
libchicken.dll and numbers.so along with the exe, but why does 'csc
-dynamic -static Pi-Ch.scm' do the same, but the exe is now 1.6mb vs 77kb?
I was hoping the two csc switches would combine numbers.os and
libchicken.dll in the exe, in other words, statically link them. Also, I
guess there is some issue with the copy command in MinGW64-32 bit or paths,
but the format looks correct even in the Error line?

Rob

On 4 October 2015 at 22:23, Robert Herman  wrote:

> Yes, I read the manual. All of the examples seem to be a linux host with
> .so files. Windows uses .dll files.
> When I try to deploy a static build of the exe, it makes an exe, and the
> size makes you think it has bundled any dependencies like numbers (from
> 77kb to 1.6mb), but on MinGW64-32 bit, it hasn't. If you try and run the
> exe on a different Windows box, or through a non-MinGW command line on the
> same Windows box, it complains it cannot find the numbers extension. My
> guess is that it has statically linked and bundled libchicken.dll in the
> exe, but not the numbers extension that is in a '(use numbers)' statement
> in the source file.
> If I simply compile the file in the MinGW command line, the exe works
> perfectly. It knows where to find the numbers library it needs, my guess
> from the CHICKEN install directory. The program works. What I am trying to
> do is make a static exe with the dependencies all in the exe. This way I
> can give it to somebody who is not a programmer and does not have CHICKEN
> installed, to run as is. Later I would like to dynamically compile, so the
> user only needs the libchicken.dll once, but I would like to statically
> link any program-specific libs (like numbers). This way the user only needs
> one copy of libchicken.dll in a directory, and any exe I send them will
> have the oddball dependencies statically linked right in the exe.
> For instance, the same program on a Gambit-C MinGW64-64 bit system is
> compiled: "gsc -exe "file.scm"" The resulting exe (4 mb) runs to whomever I
> send it on their Windows box. It includes all of what it needs, i.e. the
> gambit runtime dll, and any libs (like numbers). I guess they made Gambit-C
> more Windows friendly, but it  alas it does not have the packages CHICKEN
> has. On the other hand, if the packages (eggs) only work  if you have
> MinGW64-32 bit installed with a CHICKEN dev environment, it sort of defeats
> the purpose of being able to create stand alone exe files.
>
> I apologize for the lengthy description, and I am grateful for the help! I
> hope I was clear (need sleep) :)
>
> Rob
>
> On 4 October 2015 at 21:30, Peter Bex  wrote:
>
>> On Sun, Oct 04, 2015 at 08:50:59PM +0800, Robert Herman wrote:
>> > Matt,
>> >
>> > "csc -deploy -static Pi-Ch.scm" creates a deploy directory, and the
>> > resulting executable is 1.6MB vs 77KB, but it still throws the "cannot
>> the
>> > load the extension: numbers".
>> >
>> > I then tried putting libchicken.dll in the deploy directory that was
>> > created, and making numbers.so a numbers.dll file, since Windows does
>> not
>> > use .so files, only .dll.
>>
>> I think this is incorrect; looking at my VM mingw install, and all the
>> eggs
>> (even all the import libraries from CHICKEN core), it uses .so for all the
>> dynamically loaded extensions.  And if I install it normally, and type
>> (use numbers) at the REPL, it prints that it's loaded /path/to/numbers.so
>>
>> Renaming manually is something I would definitely not recommend, because
>> then you would be messing with the names that CHICKEN expects.
>>
>> > I used chicken-install -r to retrieve the numbers
>> > egg into the current directory. I then tried "csc -dll numbers.scm" and
>> it
>> > created numbers.so. I tried putting it in the deploy directory, but no
>> > luck. I changed the .so to .dll, and again no luck.
>>
>> I've tried to do it "by the book" on mingw (msys):
>>
>> $ /path/to/chicken-install.exe numbers
>> $ echo '(use numbers) (print 1/2)' > foo.scm
>> $ /path/to/csc.exe -deploy -X numbers-syntax foo.scm
>> $ /path/to/chicken-install.exe -deploy -prefix foo numbers
>> $ # To prove that it's not loading numbers from install dir:
>> $ /path/to/chicken-uninstall.exe numbers
>> $ ./foo/foo.exe
>> 1/2
>>
>> This works perfectly.  The book, incidentally, is here:
>> http://wiki.call-cc.org/man/4/Deployment
>>
>> Hope this helps,
>> 

Re: [Chicken-users] Hypergiant egg install fails, and some other eggs

[Jeremy Steward]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I suppose as one of the few people who has used / uses CHICKEN on
Windows I should chime in :)

On 02/10/15 12:57 PM, Peter Bex wrote:
> On Sat, Oct 03, 2015 at 02:29:35AM +0800, Robert Herman wrote:
>> Maybe Termbox is too reliant on a linux terminal as the target,
>> but how come Blas fails, when I have the Blas libraries
>> installed, and working in other language implementations?
> 
> Hard to say without more info.  The Blas egg is a bit of a pain to
> get working, even on *nix.  It has its own attempt at
> "auto-detection" of how it should invoke the compiler & linker,
> which is quite error-prone and probably very Linux-oriented anyway.
> The reason behind this seems to be that Blas itself is a bit of an
> old-fashioned library, and doesn't have a way to discover how to
> link against it (no pkg-config, for example).

BLAS is problematic not because it is old, but because it is made
available through multiple implementations. For example, BLAS can be
made available through Intel's MKL, ATLAS, OpenBLAS, and of course the
original netlib.org reference implementation. Keep in mind BLAS is
often implemented in Fortran and then exported to C, so depending on
your implementation you might also need to expose `-lgfortran` to csc
as well.

The "auto-detection" code is more or less attempting to figure out
which BLAS library you're using, and tries to deduce which files to
link into the build process. You can, for example, try the following:

#include 
#include 

int main() {
cblas_ddot(0, NULL, 0, NULL, 0);
return 0;
}

You'll then want to compile this as follows:

gcc test.c -o test -lm -lblas

OR

gcc test.c -o test -lm -lcblas

If either of those work, you should be good to go with regards to
installing BLAS automatically. Otherwise, you may need to figure out
where libblas.dll or libcblas.dll reside and you'll need to expose
those libraries in your INCLUDE path.

If you're getting weird errors with blas or atlas-lapack, you can post
here and I can try to help. I did some work with atlas-lapack earlier
this year (and I mean to do more), but I've had good success with it
on Windows thus far.

>> I will try and see why other eggs fail and look into tracing
>> them, and share what I find. I really want to be able to make
>> CHICKEN my platform on Windows.
> 
> Don't give up!  It's just that you're charting new territory; not
> many people are currently using CHICKEN on Windows.  Most egg
> authors will be happy to patch their eggs to make things work, if
> you can inform them what is needed to make things build on
> Windows.

Agreed, please do not give up. Currently the way I use CHICKEN on
Windows is through Cygwin, because it is currently the easiest way to
install and link things (using plain MinGW64 is an exercise in
patience, IMO). Hopefully the midipix project (http://midipix.org/)
picks up, which will provide a much better way to use CHICKEN (and
other C libraries / programs) on Windows.

I suppose midipix / musl-libc support should be it's own thread though.

Cheers,

- -- 
Jeremy Steward

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJWEVjOAAoJEHVwwAZUeZnZ31YP/jmwMZYQ0T7UjGdoZ5an1lXH
NSBuEebN1888RzMbmNVe/nWLq/RhTrEZZpGJ4m4/IeWA09PBLSLEhe/E4JBAjV1d
v3Rx5UlAUTSP4zh9rP4sZO9EV09X7xbTh2IoIjU3udyJ9SJv/XqHU0RyIsv4xmum
EjNXoCOswBkfZLZ8ErsKUPyYWykS1F8vQ0QSxNoYdnfiDnhtfpNKV3w4+f6CUtKo
QxHWzUf8UGT9My0PHd0ZMgqsxumuXTSZs9OTFEphjys4BOSz/ppVROe840Nj8GOb
qutG0/ELRoEJoMcgBhNZSVXqFkvgRAkoB7U9iv5pc1e+5+qDgNKgUyqTxNdPH8pA
DRskUMotAcwqjF5gSp6j04HikI7resIHzmshzyO+rT9Az6AervDereFIBCULzeTh
D7/iwCjvEaDxUlFDt5nOeXA0APVSpzYYwKqKAnQQ3Mu7gNt18EzC0kuVmqakTAuC
4X6uKyoKFFUk7e16tQAyzfpzvrtpRVm4J/I2wBuRF+vmFlGObAWg1pPkdS+mIbsZ
/v1VGiQxW3f7AHa2jiMHkj7lipqKOHCglD3dh9kpEJMdOHxFaZSRwA0EbxWoh/rm
5MCZ0VkikZC2FiVvnAqyqqUnk0dV9YY+0+SPcLR8Vr5RFETr1h2dgh6QzX+ZUSpO
87yk7FsY40OB1HW29Icj
=YCKH
-END PGP SIGNATURE-

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

Re: [Chicken-users] Hypergiant egg install fails, and some other eggs

[Jeremy Steward]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/10/15 11:09 AM, Peter Bex wrote:
> On Sun, Oct 04, 2015 at 10:50:24AM -0600, Jeremy Steward wrote:
>> I suppose as one of the few people who has used / uses CHICKEN
>> on Windows I should chime in :)
> 
> Thanks for this!
> 
>> On 02/10/15 12:57 PM, Peter Bex wrote:
>>> The reason behind this seems to be that Blas itself is a bit of
>>> an old-fashioned library[...]
>> 
>> BLAS is problematic not because it is old, but because it is
>> made available through multiple implementations. For example,
>> BLAS can be made available through Intel's MKL, ATLAS, OpenBLAS,
>> and of course the original netlib.org reference implementation.
>> Keep in mind BLAS is often implemented in Fortran and then
>> exported to C, so depending on your implementation you might also
>> need to expose `-lgfortran` to csc as well.
> 
> Thanks for explaining this.  It's good to know about that.  Do
> none of the BLAS implementation offer pkg-config support, though?
> Even if you only support one BLAS library, it can still be
> installed in several different locations, depending on the platform
> and packaging system used.

As far as I can tell, none of the ones I mentioned above do. The
OpenBLAS guys would do it, but their issue tracker on Github suggested
they don't know how to write pkg-config files [1]. As for Intel's MKL,
it's proprietary. This means 1) I haven't utilized it much, and 2) I
have never seen it play nice with FOSS tooling. It could very well
export pkg-config bindings, but I doubt it.

As for ATLAS and netlib BLAS, they both suffer from being maintained
by a single developer who hasn't updated the software much (beyond
architecture compatibility) in years. That isn't to say that ATLAS is
out of date or bitrotted (it is in fact quite optimized and useful),
but the code itself is robust and well-tested, and prioritizes
platform compatibility over new features (IMO, I don't know or talk
with the developer, but this is the impression I get).

>> Agreed, please do not give up. Currently the way I use CHICKEN
>> on Windows is through Cygwin, because it is currently the easiest
>> way to install and link things (using plain MinGW64 is an
>> exercise in patience, IMO). Hopefully the midipix project
>> (http://midipix.org/) picks up, which will provide a much better
>> way to use CHICKEN (and other C libraries / programs) on
>> Windows.
> 
> Wow, this Midipix project sounds very promising!  Definitely
> something to keep an eye on, so we can (eventually?) get rid of the
> mess that is cygwin & mingw.
> 
> Cheers, Peter
> 

Indeed, it would be a great day when Windows is as easy to support as
Linux or BSD!

[1] https://github.com/xianyi/OpenBLAS/issues/598

- -- 
Jeremy Steward

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJWEWtRAAoJEHVwwAZUeZnZh8AQAKjGh/LqhSce/3gzWXSFeL8Z
ESk7ttbO3qszc266w9gTFBpA6HGaloLawy+3/PfknHnbV8lvr24Thn/gikfx0ja/
L/9BpCKwr48eQelWmKVQdf5VPaAk2xk49tqhtqF0WMsUX6ppBeIiNMQH1F4EY074
M6iAZXfvdaxiuYx7i3hhKiNHiXuCWRDqEF8Uot10FIgbnvlF5wmJbbJjKXrYmX/R
sa1JeUmLZYamSRbYP/PY0o+X/brnhWrYD5nrAcbZZeyWXPSYjQuvySk3DLXsly3+
YP0H3darVuQu5s81WNLDMm5xm6pGs2PbAFZy24YHHBuVtKG44gdPyGTAI5NeZL/V
IDzsTWz80pD2mEkp5ll5pSn72giUofYo9ryYLL2oYhBeomqmv0x2kcmJdreHfjc7
6OCjoRNaIjzdfcu2kRZQBn/ZllWuNEPhxOKB296ptaWN8aBk3fX/ryDYF5S79KfW
uwpsueOzHvnACvIesJD/7YmCde+Z20560nV8GBdiu8dJdpYCoQWY1wLrDCYhF1Z2
AS9jxUpkAMYjHsPWBFM5O3vifytpuJDvebLRhP6U9Eydgw+0Uz1M45NZzH/y7pLT
0KABXqWvHiBnwmaSN7wuJlwAIc7B3bAO4MCGPMXGYY4aEPRLsw8nCG8b/8FT2QU/
WiBsGMsp17ccdbQUkW4N
=f0Rp
-END PGP SIGNATURE-

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

Re: [Chicken-users] Windows deployment - Numbers egg

[Robert Herman]

Peter,

Thank you, that explains everything I was confused about!
The only issue remaining is the error with the compile deploy process
trying to copy files from the CHICKEN directory. I didn't rename the
CHICKEN directory to CHICKEN-IUP, that's what the pre-built binary for
Windows with IUP called it, and the path is correct, but libchicken.dll is
in c:\chicken-iup\bin not c:\chicken-iup\lib. Instead, c:\chicken-iup\lib
has libchicken.a and libchicken.dll.a within it. I only needed to manually
copy numbers.so from the C:\chicken-iup\lib\chicken\7 directory to make it
work.

Rob

On 4 October 2015 at 23:00, Peter Bex  wrote:

> On Sun, Oct 04, 2015 at 10:51:49PM +0800, Robert Herman wrote:
> > Whoa! Hold on. When I ran "csc -deploy Pi-Ch.scm" it created a 77kb exe
> > Pi-Ch.exe in a newly-created directory, Pi-Ch. When I look at the command
> > line information, I found this error:
> >
> > C:\Users\Robert\Desktop\Chicken-IUP-Examples\Pi>csc -deploy Pi-Ch.scm
> > The system cannot find the file specified.
> >
> > Error: shell command terminated with non-zero exit status 1: "copy /Y
> > "c:\chicken-iup\lib\libchicken.dll" "Pi-Ch""
>
> This looks like you may have renamed the chicken directory.  Is that
> possible?
>
> > I manually copied numbers.so into the Pi-Ch directory and libchicken.dll,
> > and it ran! Thanks to all.
>
> I'm not sure if that's going to work in the general case.  If you
> include an egg that itself depends on other eggs, it might not be
> able to load them because the egg doesn't know it's linked into a
> deployed executable.
>
> > Next question is what does 'csc -static' do?
>
> It's supposed to generate a statically linked executable.
>
> > I don't mind sending libchicken.dll and numbers.so along with the exe,
> > but why does 'csc -dynamic -static Pi-Ch.scm' do the same,
>
> I think those options are supposed to be mutually exclusive, but
> maybe the latter overrides the former.
>
> Compiling a program statically only works if you also have static
> versions of all the libraries it uses.  Most eggs don't install
> static copies of their libraries (neither does numbers).  Besides,
> (use numbers) says "load the numbers module dynamically".  If you
> want to compile statically, you'd have to do something like
>
> (declare (uses numbers))
> (import numbers)
>
> But I'm not 100% sure.  This is going to be made easier in CHICKEN 5,
> at least that's the plan.
>
> > but the exe is now 1.6mb vs 77kb?
>
> It does include libchicken.dll (but not numbers because you didn't
> declare it statically)
>
> > I was hoping the two csc switches would combine numbers.os and
> > libchicken.dll in the exe, in other words, statically link them.
>
> You can't load a .dll file statically; it's inherently dynamic.
> However, if you have libchicken.a, you can link _that_ statically
> into your program.  Like I said, you'll also need to somehow create
> a "numbers.a" file to link into your program.
>
> > Also, I guess there is some issue with the copy command in
> > MinGW64-32 bit or paths, but the format looks correct even in the
> > Error line?
>
> Does the file it mentions exist?
>
> Cheers,
> Peter
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Windows deployment - Numbers egg

[John Cowan]

Peter Bex scripsit:

> On Sun, Oct 04, 2015 at 10:23:26PM +0800, Robert Herman wrote:
> > Yes, I read the manual. All of the examples seem to be a linux host with
> > .so files. Windows uses .dll files.
> 
> Hi again Robert,
> 
> This is of course true, but the .so files that CHICKEN generates on mingw
> are just misnamed .dll-files.  Try running "file" on it to inspect the
> type; it'll let you know that they're DLL files.  I suppose because
> CHICKEN loads those dynamically, the extension is irrelevant.

Right.  When Chicken loads something dynamically on Windows, it uses the
equivalent of Linux dlopen(): it understands LDLIBRARYPATH and its defaults,
and it doesn't really care what the extension is.

But when an executable file has libraries linked into it, there is no
LDLIBRARYPATH (it uses PATH instead), and it insists on the extension "DLL".
That's because the brain-dead Windows loader has to be used, as your
application does not yet have control.
-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
In politics, obedience and support are the same thing.  --Hannah Arendt

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