convert environment to module `name'
I am working on “Compiling to the Virtual Machine”. Guile passes an `env’ object to the parser/compiler which is apparently the module object for the desired execution environment. To reference top-level variables in (external) tree-il I am using '(toplevel foo) but I guess I should be using '(@ (mod from env) foo) I don’t know how to get the list-symbol path “mod from env” from the env argument. Any ideas? The following generates an error: `(@ ,env foo) where env in write format looks like Matt
Re: Guile 2.1.8 on 9 March / 2.2.0 on 16 March
Andy Wingo writes: > Finally for the release we should consider publicity -- what do we do? > Anything special? Volunteers are welcome here. The NEWS is quite > verbose, so condensing it into a set of 5-10 big-ticket items could be > useful; dunno. One important point would be to send advance press releases with an explicit EMBARGO (not to be released before ... = EMBARGOED UNTIL ...) to many newspapers, including as many as possible in India, china and any other non-US country with many programmers. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: How to make GNU Guile more successful
If I may add my two cents as a Scheme layman: the question is not so much about making Guile more popular, but about making Scheme itself more popular. One big reason for Python’s popularity is something I haven’t seen mentioned in this thread so far: if you know pseudocode you basically know Python already. Of course this is hyperbolic, there are a lot of finer details to Python, but the superficial simplicity of Python makes you think you already know the language and that you can get started right away. By the time you encounter the more arcane aspects of Python you have already invested enough time into it that you will put up with learning something new. Scheme on the other hand is weird; weird in a good way, but still weird. For me the reason for picking up Scheme was working my way through SICP, but even before that I had heard of the Lisp family. Every time I tried to find out what the fuss was about Lisp all I could find was nebulous concepts like “it’s a programmable programming language” without explaining what that even meant and why I would ever want to use it. Of course once I got over the weird parentheses and I understood why they are actually a beneficial aspect I liked it. Yet, even after getting into Scheme there are problems. The r5rs standard is pretty limited, and so every implementation does its own thing. There was not even a standard module system until r6rs. Unfortunately r6rs never got fully adopted by any of the major implementations, so we are back to where we were with r5rs more or less. r7rs-small looks like it could finally fill in the most glaring gaps, and r7rs-large is still nowhere done. All this is very frustrating, and getting into a new language is a long-term commitment to learn something new. When faced with Python, Ruby, JavaScript, Lua and Scheme, it’s easy to go with the flow and just use what everyone else is using. I think someone here mentioned the lack of a proper Scheme IDE, other than Dr. Racket for Racket. I don’t use IDEs anymore, but I can see how that can be a problem for other people who only want to do intermediate scripting rather than write entire applications. Writing a full IDE would be quite a lot of work, so perhaps integrating with existing IDEs would be better. Think something like Geiser for programs other than Emacs. There is the “language server protocol" by Microsoft, the idea is to have a standardised protocol that can be supported by a language server and an editor application. https://github.com/Microsoft/language-server-protocol I know it’s Microsoft, but this is just a specification. With this protocol one would write a Scheme server that receives instructions form the editor via RPC and sends the result back to the server via RPC as well. This would allow using the same Scheme server regardless of the editor (Emacs, Vim, Neovim, Eclipse, …). I had wanted to write something like this for Neovim myself, but I don’t know enough of Scheme yet. I hope these ramblings of mine offer something useful from an outsider perspective to you guys.
Re: How to make GNU Guile more successful
David Kastrup writes: > Nala Ginrut writes: > >> I think we have to elaborate the question clearer. >> >> 1. How to make guile-scheme more successful? >> I think this is similar to ask "how to make scheme more successful". >> This is the big question to the whole scheme community. >> >> 2. How to make guile platform more successful? >> I this case, let me ask a question, if we have guile-python3 >> (compatible with most of Python3 features), and provide more >> convenient FFI helper function to help bind more libraries in short >> time, is it possible to attract more people from Python land? Given >> we'll have good JIT compiler in the future. > > Frankly, I doubt that migration of large Python-based applications is > going to be a thing when nobody can even be bothered with immersing > himself in the problems with migrating LilyPond from Guile-1.8 to > Guile-2. I worked on testing Lilypond with user installed Guile 2.x, does that count? Just to have it recorded somewhere, here’s a patch to lilypond along with a copy of the bash history of the setup (cleaned up, it was many times as long): ## patch From bd2ffea6f4c4c1ede13f5ac82d0a8ce31ccfe3c7 Mon Sep 17 00:00:00 2001 Subject: [PATCH] Build fixes for Guile 2.1.x (not yet functional) --- configure.ac | 7 ++- lily/pdf-scheme.cc | 4 scm/memory-trace.scm | 3 ++- 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index d77ea15..393976b 100644 --- a/configure.ac +++ b/configure.ac @@ -267,7 +267,12 @@ STEPMAKE_FREETYPE2(freetype2, REQUIRED, 2.1.10) STEPMAKE_WINDOWS # guile executable for some scripts -STEPMAKE_GUILE(OPTIONAL, 1.8.2, 1.9.0) +if test "$GUILEv2" = "yes" +then +STEPMAKE_GUILE(OPTIONAL, 2.0.7, 2.2.0) +else +STEPMAKE_GUILE(OPTIONAL, 1.8.2, 1.9.0) +fi # perl for help2man and for mf2pt1.pl STEPMAKE_PERL(REQUIRED) diff --git a/lily/pdf-scheme.cc b/lily/pdf-scheme.cc index da2ce2c..f5ae70c 100644 --- a/lily/pdf-scheme.cc +++ b/lily/pdf-scheme.cc @@ -91,7 +91,11 @@ LY_DEFINE (ly_encode_string_for_pdf, "ly:encode-string-for-pdf", * (string->utf16 str 'big) */ if (g) +#if GUILEV2 +return scm_take_locale_stringn (g, bytes_written); // scm_take_str eventually frees g! +#else return scm_take_str (g, bytes_written); // scm_take_str eventually frees g! +#endif else return str; } diff --git a/scm/memory-trace.scm b/scm/memory-trace.scm index d8ffeb9..9ebd722 100644 --- a/scm/memory-trace.scm +++ b/scm/memory-trace.scm @@ -2,7 +2,8 @@ (define-module (scm memory-trace)) (use-modules (lily) - (ice-9 format)) + (ice-9 format) + (ice-9 threads)) (define-public (mtrace:start-trace freq) (set! usecond-interval (inexact->exact (/ 100 freq))) -- 2.10.2 ## bash history sudo emerge media-fonts/tex-gyre sudo nano /etc/portage/package.keywords/sonstiges sudo emerge media-fonts/tex-gyre sudo pmerge dblatex git clone git://git.sv.gnu.org/lilypond.git cd lilypond/ ./autogen.sh --prefix ~/.local --enable-guile2 mkdir -p ~/texmf/lh cp ~/Downloads/lhfnt35g-source.zip ~/texmf/lh/ unzip lhfnt35g-source.zip cd ~/texmf/source/latex/lh latex lcyfonts.ins latex ot2fonts.ins; latex t2ccfonts.ins ls ~/texmf/examples/ mkdir ~/texmf/lh cp *sty ~/texmf/lh/ ./autogen.sh --prefix ~/.local --enable-guile2 sudo emerge dev-texlive/texlive-langcyrillic sudo pmerge dev-texlive/texlive-langcyrillic make out/lilypond-invoke-editor cd scripts/ /home/arne/lilypond/scripts/build/out/help2man out/lilypond-invoke-editor --no-discard-stderr /home/arne/lilypond/scripts/build/out/help2man out/lilypond-invoke-editor ./autogen.sh --prefix ~/.local --enable-guile2 make LD_LIBRARY_PATH=/home/arne/.local/lib/guile/2.2/ g++ -o out/lilypond ./out/modified-font-metric.o ./out/sequential-iterator.o ./out/hara-kiri-group-spanner.o ./out/completion-note-heads-engraver.o ./out/slur-score-parameters.o ./out/flag.o ./out/span-arpeggio-engraver.o ./out/beam-quanting.o ./out/dynamic-performer.o ./out/parse-scm.o ./out/tie.o ./out/bend-engraver.o ./out/staff-spacing.o ./out/rest-collision-engraver.o ./out/simple-spacer-scheme.o ./out/audio-item.o ./out/pdf-scheme.o ./out/paper-score.o ./out/slur-configuration.o ./out/constrained-breaking.o ./out/score-engraver.o ./out/unpure-pure-container.o ./out/multi-measure-rest-engraver.o ./out/system-start-delimiter-engraver.o ./out/context-property.o ./out/freetype.o ./out/interval-minefield.o ./out/kievan-ligature.o ./out/completion-rest-engraver.o ./out/pure-from-neighbor-engraver.o ./out/horizontal-bracket-engraver.o ./out/grob-closure.o ./out/default-bar-line-engraver.o ./out/control-track-performer.o ./out/file-name-map.o ./out/audio-staff.o ./out/line-spanner.o ./out/grob-info.o ./out/spring.o ./out/slur.o ./out/music-scheme.o ./out/program-option.o ./out/fretboard-engraver.o ./out/hyphen-engraver.o ./out/page-marker.o ./out/global-vars.o ./out/stream-event-scheme.o ./o
Re: How to make GNU Guile more successful
Alejandro Sanchez writes: > If I may add my two cents as a Scheme layman: the question is not so much > about making Guile more popular, but about making Scheme itself more popular. > > One big reason for Python’s popularity is something I haven’t seen > mentioned in this thread so far: if you know pseudocode you basically > know Python already. Of course this is hyperbolic, there are a lot of > finer details to Python, but the superficial simplicity of Python > makes you think you already know the language and that you can get > started right away. By the time you encounter the more arcane aspects > of Python you have already invested enough time into it that you will > put up with learning something new. This is basically what wisp¹ is intended to address: define : hello who format #t "Hello ~a!\n" who hello "World" And it’s still full scheme. Just looking like pseudocode. I documented that in py2guile: http://draketo.de/py2guile ¹: http://draketo.de/english/wisp > I think someone here mentioned the lack of a proper Scheme IDE, other > than Dr. Racket for Racket. I don’t use IDEs anymore, but I can see > how that can be a problem for other people who only want to do > intermediate scripting rather than write entire applications. I also see lots of people at work using Python IDEs, which all bring their own problems but provide the kind of information I get from the commandline. Just having a geiser setup for Emacs properly documented — or maybe an Emacs customized for Scheme development — would help a lot, I think. "This is our canonical interface for writing Scheme" ← That is what people need to be able to find. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: How to make GNU Guile more successful
2017-03-05 0:44 GMT+01:00 Arne Babenhauserheide : > > David Kastrup writes: > >> Nala Ginrut writes: >> >>> I think we have to elaborate the question clearer. >>> >>> 1. How to make guile-scheme more successful? >>> I think this is similar to ask "how to make scheme more successful". >>> This is the big question to the whole scheme community. >>> >>> 2. How to make guile platform more successful? >>> I this case, let me ask a question, if we have guile-python3 >>> (compatible with most of Python3 features), and provide more >>> convenient FFI helper function to help bind more libraries in short >>> time, is it possible to attract more people from Python land? Given >>> we'll have good JIT compiler in the future. >> >> Frankly, I doubt that migration of large Python-based applications is >> going to be a thing when nobody can even be bothered with immersing >> himself in the problems with migrating LilyPond from Guile-1.8 to >> Guile-2. > > I worked on testing Lilypond with user installed Guile 2.x, does that > count? > > Just to have it recorded somewhere, here’s a patch to lilypond along > with a copy of the bash history of the setup (cleaned up, it was many > times as long): > > ## patch > > From bd2ffea6f4c4c1ede13f5ac82d0a8ce31ccfe3c7 Mon Sep 17 00:00:00 2001 > Subject: [PATCH] Build fixes for Guile 2.1.x (not yet functional) > > --- > configure.ac | 7 ++- > lily/pdf-scheme.cc | 4 > scm/memory-trace.scm | 3 ++- > 3 files changed, 12 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index d77ea15..393976b 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -267,7 +267,12 @@ STEPMAKE_FREETYPE2(freetype2, REQUIRED, 2.1.10) > STEPMAKE_WINDOWS > > # guile executable for some scripts > -STEPMAKE_GUILE(OPTIONAL, 1.8.2, 1.9.0) > +if test "$GUILEv2" = "yes" > +then > +STEPMAKE_GUILE(OPTIONAL, 2.0.7, 2.2.0) > +else > +STEPMAKE_GUILE(OPTIONAL, 1.8.2, 1.9.0) > +fi > > # perl for help2man and for mf2pt1.pl > STEPMAKE_PERL(REQUIRED) > diff --git a/lily/pdf-scheme.cc b/lily/pdf-scheme.cc > index da2ce2c..f5ae70c 100644 > --- a/lily/pdf-scheme.cc > +++ b/lily/pdf-scheme.cc > @@ -91,7 +91,11 @@ LY_DEFINE (ly_encode_string_for_pdf, > "ly:encode-string-for-pdf", > * (string->utf16 str 'big) > */ >if (g) > +#if GUILEV2 > +return scm_take_locale_stringn (g, bytes_written); // scm_take_str > eventually frees g! > +#else > return scm_take_str (g, bytes_written); // scm_take_str eventually frees > g! > +#endif >else > return str; > } > diff --git a/scm/memory-trace.scm b/scm/memory-trace.scm > index d8ffeb9..9ebd722 100644 > --- a/scm/memory-trace.scm > +++ b/scm/memory-trace.scm > @@ -2,7 +2,8 @@ > > (define-module (scm memory-trace)) > (use-modules (lily) > - (ice-9 format)) > + (ice-9 format) > + (ice-9 threads)) > > (define-public (mtrace:start-trace freq) >(set! usecond-interval (inexact->exact (/ 100 freq))) > -- > 2.10.2 > > > ## bash history > > sudo emerge media-fonts/tex-gyre > sudo nano /etc/portage/package.keywords/sonstiges > sudo emerge media-fonts/tex-gyre > sudo pmerge dblatex > git clone git://git.sv.gnu.org/lilypond.git > cd lilypond/ > ./autogen.sh --prefix ~/.local --enable-guile2 > mkdir -p ~/texmf/lh > cp ~/Downloads/lhfnt35g-source.zip ~/texmf/lh/ > unzip lhfnt35g-source.zip > cd ~/texmf/source/latex/lh > latex lcyfonts.ins > latex ot2fonts.ins; latex t2ccfonts.ins > ls ~/texmf/examples/ > mkdir ~/texmf/lh > cp *sty ~/texmf/lh/ > ./autogen.sh --prefix ~/.local --enable-guile2 > sudo emerge dev-texlive/texlive-langcyrillic > sudo pmerge dev-texlive/texlive-langcyrillic > make out/lilypond-invoke-editor > cd scripts/ > /home/arne/lilypond/scripts/build/out/help2man out/lilypond-invoke-editor > --no-discard-stderr > /home/arne/lilypond/scripts/build/out/help2man out/lilypond-invoke-editor > ./autogen.sh --prefix ~/.local --enable-guile2 > make > LD_LIBRARY_PATH=/home/arne/.local/lib/guile/2.2/ g++ -o out/lilypond > ./out/modified-font-metric.o ./out/sequential-iterator.o > ./out/hara-kiri-group-spanner.o ./out/completion-note-heads-engraver.o > ./out/slur-score-parameters.o ./out/flag.o ./out/span-arpeggio-engraver.o > ./out/beam-quanting.o ./out/dynamic-performer.o ./out/parse-scm.o ./out/tie.o > ./out/bend-engraver.o ./out/staff-spacing.o ./out/rest-collision-engraver.o > ./out/simple-spacer-scheme.o ./out/audio-item.o ./out/pdf-scheme.o > ./out/paper-score.o ./out/slur-configuration.o ./out/constrained-breaking.o > ./out/score-engraver.o ./out/unpure-pure-container.o > ./out/multi-measure-rest-engraver.o ./out/system-start-delimiter-engraver.o > ./out/context-property.o ./out/freetype.o ./out/interval-minefield.o > ./out/kievan-ligature.o ./out/completion-rest-engraver.o > ./out/pure-from-neighbor-engraver.o ./out/horizontal-bracket-engraver.o > ./out/grob-closure.o ./out/default-bar-line-engraver.o > ./out/control-track-perfo
Re: How to make GNU Guile more successful
On 03/04/2017 06:41 PM, Alejandro Sanchez wrote: > If I may add my two cents as a Scheme layman: the question is not so much > about making Guile more popular, but about making Scheme itself more popular. > > One big reason for Python’s popularity is something I haven’t seen mentioned > in this thread so far: if you know pseudocode you basically know Python > already. Of course this is hyperbolic, there are a lot of finer details to > Python, but the superficial simplicity of Python makes you think you already > know the language and that you can get started right away. By the time you > encounter the more arcane aspects of Python you have already invested enough > time into it that you will put up with learning something new. > > Scheme on the other hand is weird; weird in a good way, but still weird. For > me the reason for picking up Scheme was working my way through SICP, but even > before that I had heard of the Lisp family. Every time I tried to find out > what the fuss was about Lisp all I could find was nebulous concepts like > “it’s a programmable programming language” without explaining what that even > meant and why I would ever want to use it. > > Of course once I got over the weird parentheses and I understood why they are > actually a beneficial aspect I liked it. Yet, even after getting into Scheme > there are problems. The r5rs standard is pretty limited, and so every > implementation does its own thing. There was not even a standard module > system until r6rs. Unfortunately r6rs never got fully adopted by any of the > major implementations, so we are back to where we were with r5rs more or > less. r7rs-small looks like it could finally fill in the most glaring gaps, > and r7rs-large is still nowhere done. > > All this is very frustrating, and getting into a new language is a long-term > commitment to learn something new. When faced with Python, Ruby, JavaScript, > Lua and Scheme, it’s easy to go with the flow and just use what everyone else > is using. > > I think someone here mentioned the lack of a proper Scheme IDE, other than > Dr. Racket for Racket. I don’t use IDEs anymore, but I can see how that can > be a problem for other people who only want to do intermediate scripting > rather than write entire applications. Writing a full IDE would be quite a > lot of work, so perhaps integrating with existing IDEs would be better. Think > something like Geiser for programs other than Emacs. There is the “language > server protocol" by Microsoft, the idea is to have a standardised protocol > that can be supported by a language server and an editor application. > https://github.com/Microsoft/language-server-protocol > > I know it’s Microsoft, but this is just a specification. With this protocol > one would write a Scheme server that receives instructions form the editor > via RPC and sends the result back to the server via RPC as well. This would > allow using the same Scheme server regardless of the editor (Emacs, Vim, > Neovim, Eclipse, …). I had wanted to write something like this for Neovim > myself, but I don’t know enough of Scheme yet. > > I hope these ramblings of mine offer something useful from an outsider > perspective to you guys. > I think one issue when you want to compare languages like Python to Scheme is that these languages are dominated by a single implementation. Python, Ruby, Go, Rust, Clojure, and many others have a single dominate implementation. The compatibility of libraries isn't something devs usually have to worry about (except for breaking changes in the language like Python 2 to Python 3). I agree with how r5rs standard is pretty limited, languages with multiple implementations tend to have pretty large standards so that these implementations are somewhat compatible. I am liking the direction of r7rs and I hope it will bring scheme implementations closer together. Probably the other option for scheme would be for everyone to get behind a single implementation like Chez Scheme. Of course that isn't the only thing needed to make Scheme or Guile more popular. I believe a programming language needs a somewhat unique and powerful library or framework, an awesome application to show off the power of the language, good tooling, and some luck. The language server protocol is pretty cool and I would like to see a lisp implement it. An IDE for a lisp obviously needs to implement more features to be useful, I believe being able to easily interact with a REPL is one of those.
