Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GNU Guile 3.0

gnu.org

Post reply on HN
Print view View original

51–60 of 64 posts

Re: GNU Guile 3.0

#51

Post by nrclark »

guenthert wrote: post #50
ken wrote: post #49

Earlier quoted context omitted.

./configure is a generated file. It's not committed to the repository. If you download a release (like "guile-3.0.0.tar.gz"), it has the files you're looking for. Or you can learn autotools and do it yourself, but I don't recommend opening that can of worms.

Hmmh, it's been a decade or two since I used the autotools last, so I'll need a hint. I find it slightly disturbing that the README file is of little help though. Further, if I try naively $ sh -x ./autogen.sh then that fails on a dependency on libtoolize, of which I never have heard of and which doesn't seem to be known to bananian.

libtoolize is a program provided by the libtool package. It's pretty common in the GNU ecosystem, and is used for managing some of the more subtle aspects of build-time and runtime linking.

Agreed that the README needs much better documentation of the package-time dependencies (autoconf, automake, m4, perl, etc), and the build-time dependencies (libtool, libgc, plus a bunch of other libraries).

Re: GNU Guile 3.0

#52

Post by guenthert »

nrclark wrote: post #51
guenthert wrote: post #50

Earlier quoted context omitted.

Hmmh, it's been a decade or two since I used the autotools last, so I'll need a hint. I find it slightly disturbing that the README file is of little help though. Further, if I try naively $ sh -x ./autogen.sh then that fails on a dependency on libtoolize, of which I never have heard of and which doesn't seem to be known to bananian.

libtoolize is a program provided by the libtool package. It's pretty common in the GNU ecosystem, and is used for managing some of the more subtle aspects of build-time and runtime linking. Agreed that the README needs much better documentation of the package-time dependencies (autoconf, automake, m4, perl, etc), and the build-time dependencies (libtool, libgc, plus a bunch of other libraries).

Yeah, that was just my ignorance which a quick search on the Imterwebs remedied. With the bananian (Debian) package 'libtool' installed (and flex and libunistring-dev)

$ sh -x ./autogen.sh completes successfully and I got a ./configure and a INSTALL file (don't recall having seen an INSTALL file be autogenerated, but my memory might very well be failing me there). The './configure' also completes successfully (after a while -- seems like autoconfigure still believes that there are other Unices besides Linux left ;-} but 'make' eventually fails with

--88--

I'll try again with 3.1 ...

Re: GNU Guile 3.0

#53

Post by ncmncm »

Congratulations, Andy!

I have been following along since you first picked up Guile and began running with it.

Displacing badly-designed, slow scripting languages is the natural home for Lisp, and Guile is the right vehicle for it.

Re: GNU Guile 3.0

#54

Post by cyberpunk5000 »

wsgeek wrote: post #36

I would like to ask a genuine question (not trying to provoke anyone!). Where is a good use case for Scheme these days (in any form?). I really love the idea of the language but I can't figure out where it really does a _better_ job that these things: -- JavaScript/Typescript for in-browser or even some server-side stuff (e.g., NodeJS) -- Python seems to be dominant for non-browser code that doesn't need to be fast (…

Scheme has been the 50th most popular language for 50 years running. It has never been the best language for any particular use case, but it has been good enough to inspire a community to keep it running and relevant all this time.

If you made the same kind of list of 4 languages that dominate all use cases back in 1990 (say), Scheme wouldn't have made the list then either; BUT the 4 languages would be different than they are now. If you want the most frictionless and popular language for the tech stack of the moment, use the trendy language du jour, but you have to live with neverending churn. If you want a language that is perpetually "good enough," use something like Scheme.

There are use cases where longevity and inoffensiveness are important. Embedded scripting, the original motivation for Guile, is one of them. Scheme is my go-to for little personal utility programs. After a long day of dealing with headaches from trendy environment du jour, I want to come home to something that's bulletproof, just works, and I already know. The minimalism and clarity make it a good first learning language. It seems like it'd be good for code "for the ages" like reference implementations and government software, but AFAIK there hasn't been much of that.

Re: GNU Guile 3.0

#55

Post by lloda »

coldtea wrote: post #44
chrisseaton wrote: post #35

Earlier quoted context omitted.

> It is not even as easy to install it on Mac brew install guile That's a bottle though. I don't know if it's hard to build but it isn't hard to install .

Can't understand why a Lisp would be hard to build on a Mac or elsewhere. What are the dependencies besides some common C libraries (e.g. for math, unicode handling, etc)?

I build Guile on the Mac regularly. I need to pass the paths to these 4 libraries to configure: libgmp, libunistring, libiconv, and libreadline. The libraries themselves I get from MacPorts. Then make check && make install. Doesn't look all that awful to me to be honest.

Re: GNU Guile 3.0

#56

Post by bjoli »

lloda wrote: post #55
coldtea wrote: post #44

Earlier quoted context omitted.

Can't understand why a Lisp would be hard to build on a Mac or elsewhere. What are the dependencies besides some common C libraries (e.g. for math, unicode handling, etc)?

I build Guile on the Mac regularly. I need to pass the paths to these 4 libraries to configure: libgmp, libunistring, libiconv, and libreadline. The libraries themselves I get from MacPorts. Then make check && make install. Doesn't look all that awful to me to be honest.

Doing it using libraries installed by homebrew is borderline impossible unless you write your own brew formula. I have up on trying to use deps from homebrew and went with macports, and voilà: worked flawlessly.

It is not unique to guile either. Compiling things on Mac os brings back memories from Redhat 8. I have had so much more luck with WSL or even cygwin than Mac os for at least a dozen open source apps.

Re: GNU Guile 3.0

#57

Post by bjoli »

tjr wrote: post #43
chrisseaton wrote: post #35

Earlier quoted context omitted.

> It is not even as easy to install it on Mac brew install guile That's a bottle though. I don't know if it's hard to build but it isn't hard to install .

I've tried to build it on Mac in the past (years ago). I spent hours fiddling with it, and finally gave up and ran brew install guile . It might be better now?

TBH, isnt this just how compiling things on Mac os is? Every single time it is voodoo-fighting ./configure and sed-ing makefiles.

Re: GNU Guile 3.0

#58

Post by vindarel »

wsgeek wrote: post #36

I would like to ask a genuine question (not trying to provoke anyone!). Where is a good use case for Scheme these days (in any form?). I really love the idea of the language but I can't figure out where it really does a _better_ job that these things: -- JavaScript/Typescript for in-browser or even some server-side stuff (e.g., NodeJS) -- Python seems to be dominant for non-browser code that doesn't need to be fast (…

Here's a comparison of CL and Python: https://lisp-journey.gitlab.io/pythonvslisp/

and CL can be super performant btw.

CL allows for live/REPL programming, unmatched elsewhere, and still has features not found elsewhere too. Happy discovery!

Re: GNU Guile 3.0

#59

Post by chriswarbo »

wsgeek wrote: post #36

I would like to ask a genuine question (not trying to provoke anyone!). Where is a good use case for Scheme these days (in any form?). I really love the idea of the language but I can't figure out where it really does a _better_ job that these things: -- JavaScript/Typescript for in-browser or even some server-side stuff (e.g., NodeJS) -- Python seems to be dominant for non-browser code that doesn't need to be fast (…

I once needed to get some complex data out of a very restricted interface (syntax trees from a compiler plugin, where the only communication channel was stderr). The AST nodes provided a generic-programming interface, so I made a dead simple tree traversal which spat out the node type followed by each child, wrapped in a pair of parentheses to disambiguate structure.

Since these dumps turn out to be s-expressions, it seemed like a good idea to do further processing using a Lisp. I picked Racket (a Scheme) and it was great: parsing was a no-op, and the language made recursing through the structure and pattern-matching on the contents really simple.

The only downside was that I wrote a lot of "contracts" (dynamically-checked types), since I'm more comfortable in statically-typed languages (Haskell, StandardML, etc.). Turns out that Racket contracts are REALLY slow, so I ended up using a macro to discard them unless we were running the test suite :(

Re: GNU Guile 3.0

#60

Post by tjr »

bjoli wrote: post #57
tjr wrote: post #43

Earlier quoted context omitted.

I've tried to build it on Mac in the past (years ago). I spent hours fiddling with it, and finally gave up and ran brew install guile . It might be better now?

TBH, isnt this just how compiling things on Mac os is? Every single time it is voodoo-fighting ./configure and sed-ing makefiles.

I have built some other GNU packages without issue. In particular, I remember having easy success with CLISP. But at the same time, I have not needed to try to build a lot of packages, as many are available as pre-built binaries already.
Post reply on HN