Q 2 of 2: GUI and turnkey compiler?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Q 2 of 2: GUI and turnkey compiler?

Gan Uesli Starling
I think I need to define what is meant by turn-key compiler. That is
what they called it in JForth. In Perl this same feature goes by the
term "packed archive" and in LabVIEW they call it a "built application".

It is a feature in those languages whereby you can issue an standalone
*.exe having within itself, complete unto itself, all that is needed to
run the script, program, application. The output appears as a single
file to the end user with the expected extension of *.exe but functions
in fact more like those ZIP installers which also come with *.exe
extensions. The size will be bloated, since packed archive has within it
all from the parent language, modules included, that are needful to run
the script, at least for Perl. For JForth it was much the same. For
LabVIEW the output of a "build" requires to have the "runtime engine"
installed, but which, once installed, is good for ALL applictions and
will run them but not allow editing.

So, it would be something to allow an author to issue programs which
end-users would NOT have to know anything about Haskell itself and would
have to, at most, perform a two-step, wholly automatic installation
procedure. Short of this, anything I might aspire to give away free to
the public en masse, could not conceivably be written in Haskell. In
which case, I'll respectfully bow out from endeavoring to learn it
myself, however useful it serves for many another purpose.


Reply | Threaded
Open this post in threaded view
|

Q 2 of 2: GUI and turnkey compiler?

Brandon Allbery
On Fri, May 31, 2013 at 10:20 PM, Gan Uesli Starling <gan at starling.us>wrote:

> So, it would be something to allow an author to issue programs which
> end-users would NOT have to know anything about Haskell itself and would
> have to, at most, perform a two-step, wholly automatic installation
> procedure. Short of this, anything I might aspire to give away free to the
> public en masse, could not conceivably be written in Haskell. In which
> case, I'll respectfully bow out from endeavoring to learn it myself,
> however useful it serves for many another purpose.


Aside from system libraries, if you don't configure your packages to be
dynamic GHC works that way. You can also force system libraries if you use
-static; but note that this also links libc static, which is problematic on
at least Linux and Solaris. (Usually, the only problematic system library
is gmp.)

Note that the gmp case is also not significantly different from any random
Linux program, and you could in fact choose to bundle the appropriate
libgmp.so.whatever with your program and use a wrapper script which sets
LD_LIBRARY_PATH (on Linux or Solaris; DYLD_FALLBACK_LIBRARY_PATH on recent
OS X).

Part of whats throwing you off, I suspect, is that GHC is a native code
compiler. You might want to look at what it takes for applications for
other native compilers, such as C and C++, to bundle necessary libraries.
Perl is an interpreter, and bundling just means including the necessary
modules in a local library and making use of local::lib, or at worst 'use
lib'. It's a much simpler situation than native code compilation. Even in
the case where a .exe is generated for Windows, it's still making use of
interpreted code; Perl cannot be compiled to native code at all sanely. The
.exe instead is instead either a bit like a self-unpacking archive, or a
wrapper which invokes a Perl interpreter on a module tree with various
environment variables and paths set. JForth, similarly, is based on the JVM
instead of native code, and it's trivial to bundle up everything needed in
a jar.

(Apple's done a fair amount of work to make bundling native code easier by
means of special linker paths in application and framework bundles which
both the compile-time ld and the runtime dyld can interpret, but this is of
course not of any use on Windows or Linux.)

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130531/7111ad13/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

Q 2 of 2: GUI and turnkey compiler?

Rustom Mody
On Sat, Jun 1, 2013 at 8:14 AM, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Fri, May 31, 2013 at 10:20 PM, Gan Uesli Starling <gan at starling.us>wrote:
>
>> So, it would be something to allow an author to issue programs which
>> end-users would NOT have to know anything about Haskell itself and would
>> have to, at most, perform a two-step, wholly automatic installation
>> procedure. Short of this, anything I might aspire to give away free to the
>> public en masse, could not conceivably be written in Haskell. In which
>> case, I'll respectfully bow out from endeavoring to learn it myself,
>> however useful it serves for many another purpose.
>
>
> Aside from system libraries, if you don't configure your packages to be
> dynamic GHC works that way. You can also force system libraries if you use
> -static; but note that this also links libc static, which is problematic on
> at least Linux and Solaris. (Usually, the only problematic system library
> is gmp.)
>
> Note that the gmp case is also not significantly different from any random
> Linux program, and you could in fact choose to bundle the appropriate
> libgmp.so.whatever with your program and use a wrapper script which sets
> LD_LIBRARY_PATH (on Linux or Solaris; DYLD_FALLBACK_LIBRARY_PATH on recent
> OS X).
>
> Part of whats throwing you off, I suspect, is that GHC is a native code
> compiler. You might want to look at what it takes for applications for
> other native compilers, such as C and C++, to bundle necessary libraries.
> Perl is an interpreter, and bundling just means including the necessary
> modules in a local library and making use of local::lib, or at worst 'use
> lib'. It's a much simpler situation than native code compilation. Even in
> the case where a .exe is generated for Windows, it's still making use of
> interpreted code; Perl cannot be compiled to native code at all sanely. The
> .exe instead is instead either a bit like a self-unpacking archive, or a
> wrapper which invokes a Perl interpreter on a module tree with various
> environment variables and paths set. JForth, similarly, is based on the JVM
> instead of native code, and it's trivial to bundle up everything needed in
> a jar.
>
> (Apple's done a fair amount of work to make bundling native code easier by
> means of special linker paths in application and framework bundles which
> both the compile-time ld and the runtime dyld can interpret, but this is of
> course not of any use on Windows or Linux.)
>
>
I believe the problem is deeper than just moving executables from here to
there.

Recently after my debian upgrade, cabal broke.
http://groups.google.com/group/haskell-cafe/browse_thread/thread/72ed1e1eca117fef#

Note: I am not saying that something earlier built with cabal broke with
the upgrade.
cabal itself broke and the message implied something to do with libgmp.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130601/38d62d62/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Q 2 of 2: GUI and turnkey compiler?

Chaddaï Fouché
On Sat, Jun 1, 2013 at 8:43 AM, Rustom Mody <rustompmody at gmail.com> wrote:

>
>
> On Sat, Jun 1, 2013 at 8:14 AM, Brandon Allbery <allbery.b at gmail.com>wrote:
>
>> On Fri, May 31, 2013 at 10:20 PM, Gan Uesli Starling <gan at starling.us>wrote:
>>
>>> So, it would be something to allow an author to issue programs which
>>> end-users would NOT have to know anything about Haskell itself and would
>>> have to, at most, perform a two-step, wholly automatic installation
>>> procedure. Short of this, anything I might aspire to give away free to the
>>> public en masse, could not conceivably be written in Haskell. In which
>>> case, I'll respectfully bow out from endeavoring to learn it myself,
>>> however useful it serves for many another purpose.
>>
>>
>> Aside from system libraries, if you don't configure your packages to be
>> dynamic GHC works that way. You can also force system libraries if you use
>> -static; but note that this also links libc static, which is problematic on
>> at least Linux and Solaris. (Usually, the only problematic system library
>> is gmp.)
>>
>
> I believe the problem is deeper than just moving executables from here to
> there.
>

No, there is nothing "deep" about this, and there's nothing specific to
Haskell either...

As Brandon explained, the notion of a "turn-key compiler" itself isn't
adapted here, not because it is Haskell but because ghc is a real compiler
: it takes Haskell programs an compile them to native code, that is an
executable that can be run directly on the OS/architecture you've compiled
for.

What I'm going to explain isn't Haskell specific at all but rather general
to all compiled languages (C, C++, Go, Pascal, Ada, ...) :
So in the beginning the compiler took your code, your libraries and all
that and made an self-sufficient executable that contained the native code
that could run on your machine and all was good in the world. But the
problem is that you put in all this content from your libraries, some of
them all your programs are using, and that's a waste, you've got the same
native code replicated dozens, hundreds of time all throughout your
executables... So we invented shared libraries (.dll on Windows, .so on
Linux/Unix) that are already compiled and contains the native code from a
library and now when compiling (and linking) an executable, we don't
include the library code, we just put in a reference to the shared library
and thus our executable are smaller !
So we're better off now, no ? Well.... What if you download an executable
and you don't have all the shared libraries it needs (or the wrong
versions) ? Suddenly your executable is not self-sufficient anymore !

In Linux, we resolved the problem by using package manager that know what
libraries need to be installed for each package to work but it means that
if you're not using your manager to install a soft, you'll have to install
manually the libraries you need (which is probably what happened to Rustom,
its debian upgrade removed or upgraded the libgmp.so his manually installed
cabal needed).
In Windows we resolved the problem by... nah, let's just pretend we don't
care and let the application developers on their own ! Which is the source
of dll hell and the reason for which every single application comes with
all the dll that are not explicitly provided by windows itself, so that you
have a ton of identical versions of the same library in your filesystem.

Now in practice, you could still compile all static (no shared libraries,
all necessary library code is included in the executable) with the right
options to GHC, or you could just compile normally and include the shared
libraries in the zip you distribute (on Windows, on Linux it would be
better to use the package managers facilities).

--
Jeda?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130601/81e36520/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Q 2 of 2: GUI and turnkey compiler?

Rustom Mody
On Sat, Jun 1, 2013 at 8:36 PM, Chadda? Fouch? <chaddai.fouche at gmail.com>wrote:

>
> In Linux, we resolved the problem by using package manager that know what
> libraries need to be installed for each package to work but it means that
> if you're not using your manager to install a soft, you'll have to install
> manually the libraries you need (which is probably what happened to Rustom,
> its debian upgrade removed or upgraded the libgmp.so his manually installed
> cabal needed).
>

Not sure how you come to that diagnosis.
As far as I can see on my machine
- cabal is /usr/bin/cabal
- the apt package cabal-install is installed and lists /usr/bin/cabal as a
file

So unless something really weird or magic-y happened, my cabal is debian's
cabal.

And so -- my diagnosis -- the fact that cabal broke after an OS upgrade
suggests that the apt package cabal has something wrong in its dependencies.

Of course, as I said, this is my diagnosis, and since I am not much more
than a layman in this area, I'll be happy to be corrected :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130601/9238a217/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Q 2 of 2: GUI and turnkey compiler?

Brandon Allbery
On Sat, Jun 1, 2013 at 12:21 PM, Rustom Mody <rustompmody at gmail.com> wrote:

> As far as I can see on my machine
> - cabal is /usr/bin/cabal
> - the apt package cabal-install is installed and lists /usr/bin/cabal as a
> file
>
> So unless something really weird or magic-y happened, my cabal is debian's
> cabal.
>
> And so -- my diagnosis -- the fact that cabal broke after an OS upgrade
> suggests that the apt package cabal has something wrong in its dependencies.
>

That sounds reasonable, but also means that your issue is not with Haskell
but with Debian. In particular, it is Debian which does things like
shifting from ghc's own private libgmp to its system one, thus introducing
the possibility that a missed dependency can break things this way.

(That said, make certain that you don't have a ~/.cabal/bin/cabal running
around first --- if you mix distribution and cabal-install packages, you
can easily get into this kind of mess. Which is why we recommend going with
one or the other, and in particular not upgrading/replacing anything
installed via the distribution except via the distribution.)

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130601/5dea8ebe/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Q 2 of 2: GUI and turnkey compiler?

Chaddaï Fouché
In reply to this post by Rustom Mody
On Sat, Jun 1, 2013 at 6:21 PM, Rustom Mody <rustompmody at gmail.com> wrote:

> On Sat, Jun 1, 2013 at 8:36 PM, Chadda? Fouch? <chaddai.fouche at gmail.com>wrote:
>
>>
>> In Linux, we resolved the problem by using package manager that know what
>> libraries need to be installed for each package to work but it means that
>> if you're not using your manager to install a soft, you'll have to install
>> manually the libraries you need (which is probably what happened to Rustom,
>> its debian upgrade removed or upgraded the libgmp.so his manually installed
>> cabal needed).
>>
>
> Not sure how you come to that diagnosis.
> As far as I can see on my machine
> - cabal is /usr/bin/cabal
> - the apt package cabal-install is installed and lists /usr/bin/cabal as a
> file
>
> So unless something really weird or magic-y happened, my cabal is debian's
> cabal.
>
> And so -- my diagnosis -- the fact that cabal broke after an OS upgrade
> suggests that the apt package cabal has something wrong in its dependencies.
>

Well yes, that's always a possibility as well but your post seemed to imply
that this was a Haskell problem. If Debian does not track the dependencies
of its packages correctly, this is in no way due to it being Haskell and
could happen with any other executable, whatever language their source may
be in.

--
Jeda?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130601/eb247304/attachment-0001.htm>