> From: Nala Ginrut
> Date: Sun, 15 Dec 2024 20:09:25 +0900
> Cc: guile-user@gnu.org, maximede...@telenet.be, t...@refpersys.org,
> j...@gcc.gnu.org, dmalc...@redhat.com, bas...@starynkevitch.net
>
> Is the IR keeping the design of LIMPLE described in the slide?
Yes.
> From: Nala Ginrut
> Date: Sun, 15 Dec 2024 19:49:59 +0900
> Cc: guile-user@gnu.org, maximede...@telenet.be, t...@refpersys.org,
> j...@gcc.gnu.org, dmalc...@redhat.com, bas...@starynkevitch.net
>
> Was it merged to upstream or abandoned?
It was merged to upstream Emacs 3 years ago, and
> From: Nala Ginrut
> Date: Sun, 15 Dec 2024 17:07:24 +0900
> Cc: guile-user@gnu.org, maximede...@telenet.be, t...@refpersys.org,
> j...@gcc.gnu.org, dmalc...@redhat.com, bas...@starynkevitch.net
>
> I’m referring to the mentioned link
> https://akrl.sdf.org/gccemacs.html
Whose last upda
> From: Nala Ginrut
> Date: Sun, 15 Dec 2024 11:08:25 +0900
> Cc: Maxime Devos , t...@refpersys.org,
> j...@gcc.gnu.org,
> "dmalc...@redhat.com" , bas...@starynkevitch.net
>
> > FWIW libgccjit builds position independent code, and can be used to
> build dynamic libraries (which is what I believ
> From: Ricardo Wurmus
> Date: Sat, 12 Feb 2022 14:49:20 +0100
> Cc: guile-user@gnu.org
>
> > The argument of lack of examples in the Guile/Guix documentation has
> > been made several times now, or at least, I've seen it being made
> > several times
>
> The Guix documentation contains examples,
> Date: Sat, 12 Feb 2022 10:01:25 +0100
> From:
>
> (strftime "%Y-%m-%d %H:%m:%s" (localtime 1607841890))
> => "2020-12-13 07:12:1607845490"
I guess you meant %H:%M:%S, not %H:%m:%s...
> From: Ricardo Wurmus
> Date: Sat, 12 Feb 2022 12:49:10 +0100
> Cc: guile-user@gnu.org
>
>
> Hi adriano,
>
> I’ve got no good answers as to “why” things are the way they are, but
> the manual explains the range of these values:
>
> > It seesm to be
> >
> > (tm:mon %3)
> >
> > This returns
> >
> From: Panicz Maciej Godek
> Date: Sun, 26 Sep 2021 13:55:20 +0200
>
> I forgot to mention that I run Guile in an Emacs session running in a WSL
> console on Windows 10.
> The tests of the C code that I've been performing so far were executed in
> an MSYS terminal, but I have just tried running
> From: Jérémy Korwin-Zmijowski
> Cc: guile-user@gnu.org
> Date: Fri, 19 Feb 2021 11:20:54 +0100
>
> Le vendredi 19 février 2021 à 10:10 +0200, Eli Zaretskii a écrit :
> > Thanks for your work, but would it make sense to coordinate this with
> > the Emacs project,
> From: Ricardo Wurmus
> Date: Thu, 18 Feb 2021 22:54:36 +0100
> Cc: guile-user@gnu.org
>
> Jérémy Korwin-Zmijowski writes:
>
> > For those who missed it, I am also starting a work towards a guile-ide.el
> > for Emacs.
> >
> > https://framagit.org/Jeko/guile-ide
>
> Forgot to include a screen
> From: Christopher Lam
> Date: Sat, 25 Jul 2020 13:56:28 +
> Cc: guile-user , help-g...@gnu.org
>
> Gnucash 4.0 in windows is successfully using libguile-2.2-1.dll from MSYS2.
Is Gnucash a MinGW build or an MSYS2 build? If the latter, it's
expected.
> Date: Sat, 25 Jul 2020 00:48:35 -0300
> From: David Pirotte
> Cc: Dmitry Alexandrov , guile-user@gnu.org, help-g...@gnu.org
>
> fwiw, i've used msys2 (not so much anymore, but i still would if i had
> to ...), easy to install, update, well maintained, very friendly on irc
> when i needed to ask
> From: Dmitry Alexandrov
> Date: Fri, 24 Jul 2020 03:06:53 +0300
> Cc: Guile User , Guix Help
>
> > ## Installation
>
> > ### On Windows
> >
> > No solution yet.
>
> Is that true? Itʼs true (and a pity) that there no official packages, of
> course, but ‘no solution’?
>
> I vaguely recall,
> Date: Tue, 03 Mar 2020 13:31:38 -0500
> From: sirgazil
> Cc: "Eli Zaretskii" , "Ricardo Wurmus" ,
> "guile-user"
>
> > But I guess it wouldn't hurt to try. If something good comes out of it
> (e.g. a default guile-ide), ma
> From: Arne Babenhauserheide
> Date: Sat, 29 Feb 2020 22:15:05 +0100
>
> TLDR: It would be nice if Emacs could at startup offer users to select a
> customization for a specific use-case.
Please report this using "M-x report-emacs-bug", so that an issue is
open with the Emacs issue tracker.
Tha
> Date: Fri, 28 Feb 2020 11:02:00 -0500
> From: sirgazil
> Cc: "Ricardo Wurmus" , "guile-user"
>
> > My point is that a need for extensive customizations might mean that
> > some more general issue exists that the Emacs developers may need to
> > address, either by default or as customizable
> From: Ricardo Wurmus
> Cc: sirga...@zoho.com, guile-user@gnu.org
> Date: Tue, 25 Feb 2020 13:47:36 +0100
>
> > As an Emacs co-maintainer, I was quite surprised to read the above,
> > since AFAIK none of these issues were ever communicated to the Emacs
> > developers. If they were reported (usi
> From: Ricardo Wurmus
> Date: Tue, 25 Feb 2020 10:12:31 +0100
> Cc: guile-user@gnu.org
>
> The pretentiously named “Guile Studio” arose from the observation that
> we often tell new Guile users to learn how to use Emacs first in order
> to get a comfortable Guile development experience. Since E
> From: zimoun
> Date: Wed, 5 Feb 2020 16:39:00 +0100
> Cc: Julien Lepiller , guile-user@gnu.org
>
> > > Is 'ctags -L' a valid option?
> > > Because I do not find the documentation about it.
> >
> > --help of Exuberant Ctags 5.9~svn20110310 say:
> >
> > -L
> >A list of
> Date: Thu, 17 Oct 2019 12:33:33 +0200
> From:
> Cc: zx spectrumgomas , guile-user
> ,
> guile-devel
>
>
> On Thu, Oct 17, 2019 at 12:24:03PM +0200, Mikael Djurfeldt wrote:
> > I think we should trust what Mark says and not second guess him.
>
> Definitely. I think this should count for *al
> From: Christopher Lam
> Date: Thu, 18 Apr 2019 16:22:24 +
> Cc: guile-user
>
> scheme@(guile-user)> (setlocale LC_ALL "")
> $15 = "English_Australia.1252"
> scheme@(guile-user)> (locale-encoding)
> $16 = "CP1252"
> scheme@(guile-user)> (setlocale LC_ALL "C")
> $17 = "C"
> scheme@(guile-use
> From: Christopher Lam
> Date: Tue, 16 Apr 2019 04:13:14 +
>
> I'm struggling with string-ports on Windows.
Which version of Guile are you using, and where/how did you obtain the
Windows binary?
> Last para of
> https://www.gnu.org/software/guile/manual/html_node/String-Ports.html
> "With
> From: Andy Wingo
> Cc: guile-us...@gnu.org, guile-de...@gnu.org
> Date: Sat, 23 Jun 2018 22:07:24 +0200
>
> > MS-Windows (MinGW) doesn't have a C99 compliant C library, although
> > quite a few of what's needed is present.
>
> Hard to say :) I think my questions are limited to, in decreasing
> Date: Fri, 22 Jun 2018 00:09:16 +0100
> From: Chris Vine
>
> I think you will need to use recv! with windows, because you cannot
> read from sockets in windows using POSIX read().
What makes you say that? It isn't true; Gawk does that on Windows,
and it works very well. The only two issues,
> From: Richard Shann
> Cc: guile-user@gnu.org
> Date: Fri, 08 Jun 2018 12:27:37 +0100
>
> > > Should I expect the procedure ftw to work on Microsoft file
> > > systems?
> > > A call that works on Unix seems to hang on M/S
> >
> > Up front, I cannot see why should it not work. Can you show an
>
> From: Richard Shann
> Date: Thu, 07 Jun 2018 14:22:12 +0100
>
> Should I expect the procedure ftw to work on Microsoft file systems?
> A call that works on Unix seems to hang on M/S
Up front, I cannot see why should it not work. Can you show an
example that hangs?
> And, for good measure, wh
> From: Jeremy Korwin-Zmijowski
> Date: Sat, 24 Mar 2018 12:21:11 +0100
>
> I am trying to build Guile from git sources (master branch) but when I
> issue make command, the process is stuck here :
>
> GEN guile-procedures.texi
> make[3]: Leaving directory `/home/jeko/Builds/guile/
> From: David Kastrup
> Date: Sat, 20 Jan 2018 20:14:25 +0100
>
> > Every time I install something I get the following message:
> >
> > /sbin/ldconfig.real: /usr/local/lib/libguile-2.2.so.1.3.0-gdb.scm
> > is not an ELF file
>
> Why would that not be in /usr/local/share instead?
Because GDB
> From: l...@gnu.org (Ludovic Courtès)
> Cc: wi...@pobox.com, guix-de...@gnu.org, guile-user@gnu.org
> Date: Sun, 19 Mar 2017 16:57:22 +0100
>
> > I'm saying that when cross-compiling, it's easy to produce binaries
> > that are unusable on Windows because Guile is not run natively during
> > the
> From: l...@gnu.org (Ludovic Courtès)
> Cc: wi...@pobox.com, guix-de...@gnu.org, guile-user@gnu.org
> Date: Sat, 18 Mar 2017 15:04:52 +0100
>
> I think Andy was referring to the possibility of cross-compiling
> packages that use Guile to MinGW. That is already possible thanks to
> the work of
> From: l...@gnu.org (Ludovic Courtès)
> Date: Fri, 17 Mar 2017 12:30:57 +0100
> Cc: guix-de...@gnu.org, guile-user@gnu.org
>
> > Open questions would be, what about other targets like macOS or Windows
> > or whatever? There I don't know. I suspect that if Guix becomes
> > popular enough, someon
> From: Andy Wingo
> Cc: l...@gnu.org (Ludovic Courtès), guile-user@gnu.org
> Date: Thu, 09 Mar 2017 20:56:09 +0100
>
> > That's what I'm trying to tell you: there's no aggression.
>
> I understand that different people can have different reactions and it's
> great that you can look through "st
> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-user@gnu.org
> Date: Thu, 09 Mar 2017 18:26:09 +0100
>
> > FYI, I've communicated (and occasionally disagreed) with David for
> > many years, and I can assure you that you see something that simply
> > isn't there. He sometimes uses such "colorfu
> From: l...@gnu.org (Ludovic Courtès)
> Date: Thu, 09 Mar 2017 13:09:40 +0100
>
> >> As an aside, please keep the tone friendly as is the norm on this
> >> mailing list.
> >
> > Disagreement is not the same as unfriendliness.
>
> I agree. However I found the tone of your messages patronizing an
> Date: Mon, 27 Feb 2017 20:24:19 + (GMT)
> From: Jan Wedekind
> cc: Eli Zaretskii , guile-user@gnu.org
>
> The encoding support of the Ruby programming language [1] is IMHO pretty
> good. It can handle different encodings for source code, input/output,
> string v
> From: Andy Wingo
> Cc: Chris Vine , guile-user@gnu.org
> Date: Sun, 26 Feb 2017 21:58:00 +0100
>
> On Wed 15 Feb 2017 18:07, Eli Zaretskii writes:
>
> > the [Emacs] MS-Windows port pretends towards Emacs internals that file
> > names are encoded in UTF-8, an
> From: Andy Wingo
> Date: Sun, 26 Feb 2017 22:20:31 +0100
>
> In Scheme, strings are sequences of characters. Encoding and decoding
> is only needed when going to and from bytes. Guile supports a finite
> number of encodings, so in general some encoding/decoding will always be
> needed. The s
> From: Marko Rauhamaa
> Cc: d...@gnu.org, guile-user@gnu.org
> Date: Fri, 17 Feb 2017 10:46:32 +0200
>
> > IMO, it makes no sense to limit this to file names, because (a) you
> > don't always know on all levels of the code which string is a file
> > name or a part thereof; and (b) because situa
> From: Marko Rauhamaa
> Cc: Eli Zaretskii , guile-user@gnu.org
> Date: Thu, 16 Feb 2017 23:13:35 +0200
>
> Python uses the surrogate hole in the middle of the Unicode range to
> represent such stray bytes, but only when naming files.
IMO, it makes no sense to limit this to f
> From: David Kastrup
> Cc: Marko Rauhamaa , guile-user@gnu.org
> Date: Thu, 16 Feb 2017 21:52:48 +0100
>
> Eli Zaretskii writes:
>
> > Yes, to be viable in real-life situation, Guile needs to support
> > character strings with occasional embedded raw bytes tha
> From: Marko Rauhamaa
> Cc: d...@gnu.org, guile-user@gnu.org
> Date: Thu, 16 Feb 2017 21:35:12 +0200
>
> >> If emacs managed to restore a binary/text unification (and infect Guile
> >> in the process), that would be quite an accomplishment.
> >
> > I don't understand what "binary/text unificati
> From: Marko Rauhamaa
> Cc: d...@gnu.org, guile-user@gnu.org
> Date: Thu, 16 Feb 2017 20:38:31 +0200
>
> Eli Zaretskii :
>
> > In any case, this is unrelated to how strings are implemented, because
> > the basic level of string implementation _must_ support bina
> From: Marko Rauhamaa
> Cc: d...@gnu.org, guile-user@gnu.org
> Date: Thu, 16 Feb 2017 18:38:48 +0200
>
> Eli Zaretskii :
>
> > Why is that a problem? Unicode generally mandates that equivalent
> > character (a.k.a. "codepoint") sequences shall be ha
> From: Marko Rauhamaa
> Cc: guile-user@gnu.org
> Date: Thu, 16 Feb 2017 18:35:48 +0200
>
> Eli Zaretskii :
>
> > You assume that Emacs concatenates strings by just splicing its bytes.
> > But that's a far cry from what Emacs does, precisely to countermand
&
> From: Marko Rauhamaa
> Cc: to...@tuxteam.de, guile-user@gnu.org
> Date: Thu, 16 Feb 2017 09:02:09 +0200
>
> Eli Zaretskii :
>
> >> From: Marko Rauhamaa
> >> Cc: to...@tuxteam.de, guile-user@gnu.org
> >> Date: Thu, 16 Feb 2017 08:15:57 +0200
>
> From: Marko Rauhamaa
> Date: Thu, 16 Feb 2017 14:14:41 +0200
> Cc: guile-user@gnu.org
>
> (On the other side of the equation, expressing a filename in Unicode may
> not produce an unambiguous code point sequence... http://unicode.org/faq/normalization.html>)
Why is that a problem? Unicode ge
> From: Marko Rauhamaa
> Cc: guile-user@gnu.org
> Date: Thu, 16 Feb 2017 09:16:21 +0200
>
> If I understood it correctly, someone just told us emacs maps illegal
> UTF-8 to another form of illegal UTF-8 and back. That's better in that
> it's bytes to bytes (leaving Unicode out), but it's not imme
> Date: Thu, 16 Feb 2017 08:29:14 +0200
> From: Eli Zaretskii
> Cc: guile-user@gnu.org
>
> > From: Marko Rauhamaa
> > Cc: to...@tuxteam.de, guile-user@gnu.org
> > Date: Thu, 16 Feb 2017 08:15:57 +0200
> >
> > It is possible to have illegal Unicode ev
> From: Marko Rauhamaa
> Cc: to...@tuxteam.de, guile-user@gnu.org
> Date: Thu, 16 Feb 2017 08:15:57 +0200
>
> It is possible to have illegal Unicode even in Windows filenames, ie,
> filenames not expressible using Guile's strings.
Is it really possible? Can you show a code example that would c
> Date: Wed, 15 Feb 2017 22:15:52 +0100
> From: to...@tuxteam.de
> Cc: guile-user@gnu.org
>
> > > > A possible solution would be to decode each mount point's part as it
> > > > is being resolved.
> > >
> > > ...which can only be based on guesswork: there's no reliable info on
> > > the encoding u
> From: Marko Rauhamaa
> Cc: to...@tuxteam.de, guile-user@gnu.org
> Date: Wed, 15 Feb 2017 23:04:52 +0200
>
> Eli Zaretskii :
>
> > At the file system level (for NTFS volumes at least) Windows file
> > names are always UTF-16 encoded, and Windows just &q
> Date: Wed, 15 Feb 2017 21:20:56 +0100
> From: to...@tuxteam.de
> Cc: guile-user@gnu.org
>
> > > Most notably, the whole path might cross several mount points, thus
> > > the whole path can well have fragments coming from several file systems.
> >
> > A possible solution would be to decode each
> Date: Wed, 15 Feb 2017 21:07:53 +0100
> From: to...@tuxteam.de
> Cc: to...@tuxteam.de, d...@gnu.org, guile-user@gnu.org
>
> > It took many years because those smart, experienced, and patient
> > people made bad decisions, twice, and had to correct them later, which
> > required rewriting several
> Date: Wed, 15 Feb 2017 12:13:09 +
> From: Chris Vine
>
> I am not sure how that would work with windows.
Emacs has solved that problem as well: the MS-Windows port pretends
towards Emacs internals that file names are encoded in UTF-8, and
shadows relevant system APIs that accept or return
> Date: Wed, 15 Feb 2017 11:10:33 +0100
> From:
> Cc: guile-user@gnu.org
>
> Yes, Emacs is the text specialist.
>
> It has taken years and a bunch of very smart, experienced and *patient*
> folks to achieve that.
It took many years because those smart, experienced, and patient
people made bad d
> Date: Wed, 15 Feb 2017 10:18:32 +0100
> From:
>
> > Filenames and locales are not necessarily related. When you access a
> > networked file system, you get the filename encoding you are given,
> > which may or may not be the same as the particular locale encoding on
> > your particular machine
> Date: Mon, 30 Jan 2017 20:42:38 + (UTC)
> From: Mike Gran
> Cc: "guile-user@gnu.org"
>
> Earlier in the 2.0.x release series, Guile had a hack where it started
> up in a Latin-1 encoding, which would be capable of storing any
> 8-bit string of bytes, even if they weren't Latin-1.
Latin-1
> Date: Mon, 30 Jan 2017 21:32:41 +0200
> From: Eli Zaretskii
> Cc: guile-user@gnu.org
>
> > Hm, I know that XEmacs-Mule emphatically does not have unibyte strings
> > (and Stephen considers them a complication and abomination that should
> > never have been
> From: Marko Rauhamaa
> Date: Mon, 30 Jan 2017 21:01:31 +0200
> Cc: guile-user@gnu.org
>
> UTF-8 beautifully bridges the interpretation gap between 8-bit character
> strings and text. However, the interpretation step should be done in the
> application and not in the programming language.
You c
> From: David Kastrup
> Cc: ma...@pacujo.net, guile-user@gnu.org
> Date: Mon, 30 Jan 2017 20:00:03 +0100
>
> Eli Zaretskii writes:
>
> > One other crucial detail is that Emacs also has unibyte strings
> > (arrays of bytes), which are necessary during startup, w
> From: David Kastrup
> Date: Mon, 30 Jan 2017 19:32:14 +0100
> Cc: guile-user@gnu.org
>
> Emacs uses an UTF-8 based encoding internally: basically, valid UTF-8 is
> represented as itself, there is a number of coding points beyond the
> actual limit of UTF-8 that is used for non-Unicode character
> From: ng0
> Date: Tue, 27 Dec 2016 12:42:13 +
> Cc: guile-user@gnu.org
>
> I think I was a bit too verbose with my question. I meant to say:
> the part behind the "|", which originates from a 1:1 conversion of
> the bash based part, is ignored for obvious reasons. But what
> would be a quic
> Date: Mon, 26 Dec 2016 22:24:21 + (GMT)
> From: Jan Wedekind
> Cc: guile-user@gnu.org
>
> I think "libc" is normally loaded already. E.g. the C function "abs" can
> be accessed as follows:
>
> (define main (dynamic-link))
> (define cabs (pointer->procedure long (dynamic-func "ab
> From: M
> Date: Wed, 7 Dec 2016 17:05:43 +
>
> I'm trying the 'make' command for the installation, but get this:
>
> make -C libguile scmconfig.h
> make[1]: Entering directory `/home/user/apps/guile-2.0.13/libguile'
> GEN gen-scmconfig
> /home/user/apps/gc-7.2/include/: file not rec
> From: l...@gnu.org (Ludovic Courtès)
> Date: Thu, 17 Nov 2016 12:02:06 +0100
>
> It seems to work as advertised for me:
>
> --8<---cut here---start->8---
> scheme@(guile-user)> ,use(ice-9 i18n)
> scheme@(guile-user)> (number->locale-string 1.01 2 (make-lo
> Date: Sun, 9 Oct 2016 16:57:35 + (UTC)
> From: Mike Gran
>
> I guess this question is really for Eli. I hope he's lurking.
I am.
> So, I'm trying to put together the next release for the
> Guile-ncurses bindings, and I want to drop 1.8.x compat. MinGW
> seems to be stuck on Guile 1.8.8.
> From: l...@gnu.org (Ludovic Courtès)
> Date: Fri, 17 Jun 2016 10:10:34 +0200
> Cc: "guile-user@gnu.org"
>
> Guile converts file names to the current locale encoding before passing
> them to the POSIX system calls.
>
> What happens here is that the current locale encoding that is detected
> is
> Date: Sun, 29 May 2016 16:17:29 + (UTC)
> From: Mike Gran
>
> And I had to build guile with the "--without-threads" configure
> option. When I use threads, it hangs in scm_i_pthread_cond_wait.
>
> And with that, it builds and runs and passes the majority of the
> "make check" tests, excep
> Date: Mon, 28 Mar 2016 10:24:56 -0400
> From: "Thompson, David"
> Cc: Guile User , Chris Marusich
>
> The environment variable path separator is *not* defined depending on
> the OS. It is up to the programs that interpret these search paths to
> specify what the separator should be. ":" is t
> From: Park SungMin
> Date: Mon, 28 Mar 2016 10:21:46 +0900
>
> (define filename "/Users/byul/Desktop/사진.gif")
>
> (define my-open-file
> (lambda (filename)
> (let* ((fd ((pointer->procedure
>int
>(dynamic-func "open" (dynamic-link))
>(list
> From: Marko Rauhamaa
> Cc: guile-user@gnu.org
> Date: Wed, 23 Dec 2015 21:18:28 +0200
>
> Eli Zaretskii :
>
> >> From: Marko Rauhamaa
> >> The Linux kernel just doesn't care, and shouldn't.
> >
> > Guile is not an OS kernel. Gu
> From: Marko Rauhamaa
> Date: Tue, 22 Dec 2015 23:39:28 +0200
> Cc: guile-user@gnu.org
>
> > No, they aren't, not as file names. E.g., you cannot meaningfully
> > downcase or upcase such "characters", you cannot count characters (as
> > opposed to bytes), you cannot calculate how much screen est
> From: Marko Rauhamaa
> Date: Tue, 22 Dec 2015 22:36:07 +0200
> Cc: guile-user@gnu.org
>
> By setting the character set artificially to Latin-1 in Guile, all
> pathnames are accessible to it.
No, they aren't, not as file names. E.g., you cannot meaningfully
downcase or upcase such "characters"
> Date: Mon, 2 Nov 2015 15:21:00 +0300
> From: Vladimir Zhbanov
> Cc: guile-user@gnu.org
>
> > http://sourceforge.net/projects/ezwinports/files/guile-2.0.11-2-w32-bin.zip/download
> >
>
> I know, thanks :)
>
> Thank you for your great work on the guile port for Windows.
> Unfortunately your pre
> Date: Mon, 2 Nov 2015 15:10:15 +0300
> From: Vladimir Zhbanov
>
> > The reason I ask is that we rely on Gnulib for these portability
> > things. The in libguile/iselect.h is supposed to do the
> > right thing; if it’s not, we should (1) update our Gnulib copy, and (2)
> > fix the problem in G
> Date: Wed, 28 Oct 2015 21:15:33 +0300
> From: Vladimir Zhbanov
>
> The stable-2.0 guile branch contains changes that some of our users
> (that is, users of gEDA/gaf) have been waiting for years, especially
> after guile 2.0 became necessary to build our package. I mean those
> users who have be
>>> From: Marko Rauhamaa
>>> Date: Tue, 23 Jun 2015 11:08:23 +0300
>>> Cc: guile-user@gnu.org
>>>
>>> Michael Tiedtke :
POSIX isn't that important or useful anymore but "full access to
POSIX system calls" it has never been.
>>> What I'd like is a way to communicate open file descriptors
> From: Marko Rauhamaa
> Date: Tue, 23 Jun 2015 11:08:23 +0300
> Cc: guile-user@gnu.org
>
> Michael Tiedtke :
>
> > POSIX isn't that important or useful anymore but "full access to POSIX
> > system calls" it has never been.
>
> What I'd like is a way to communicate open file descriptors between
> Date: Sun, 9 Nov 2014 23:30:07 -0500
> From: jeremy chen
>
> Hi, I am trying to compile guile on windows with Mingw-w64.
> The file libguile/numbers.c signal an error in this function:
>
> static SCM
> scm_i_inum2big (scm_t_inum x)
> {
> /* Return a newly created bignum initialized to X. */
>
> From: l...@gnu.org (Ludovic Courtès)
> Date: Wed, 17 Sep 2014 23:13:59 +0200
> Cc: guile-user@gnu.org
>
> Perhaps a solution would be to use guile-ncurses?
Yes, that should work, assuming guile-ncurses uses ncurses (which can
be built on Windows).
> From: Nala Ginrut
> Cc: guile-user@gnu.org, guile-de...@gnu.org
> Date: Wed, 17 Sep 2014 18:33:50 +0800
>
> > Too bad it requires an ANSI-capable terminal, and therefore will not
> > work on MS-Windows.
>
> Oh, I'm not familiar with Windows, what's the solution on it?
You cannot do that from
> From: Nala Ginrut
> Date: Wed, 17 Sep 2014 18:11:59 +0800
> Cc: guile-devel
>
> Hi folks!
> Here's the latest release of guile-colorized:
> https://github.com/NalaGinrut/guile-colorized/releases
>
> guile-colorized is a repl plugin to make your repl color.
Thanks.
Too bad it requires an ANS
> From: Jan Nieuwenhuizen
> Cc: guile-user@gnu.org, emacs-de...@gnu.org
> Date: Fri, 08 Aug 2014 15:53:11 +0200
>
> +(defcustom compilation-guile-get-load-path-command "guile -c '(write
> %load-path)'"
OK, but for portability to non-Posix platforms, please use only ".."
quotes, as '..' quot
> From: Jan Nieuwenhuizen
> Date: Fri, 8 Aug 2014 13:05:54 +0200
>
> +(defcustom compilation-guile-load-path '("/usr/share/guile/2.0"
> "/usr/share/guile/site")
Not a good idea, IMO. This is inherently system-dependent, and
doesn't support Guile installations with non-default $(prefix). IOW,
> From: Jan Nieuwenhuizen
> Date: Fri, 8 Aug 2014 13:05:53 +0200
>
> Still wondering about my previous set of Guile/Emacs integration
> patches
For the Emacs side: please be patient.
> From: "Diogo F. S. Ramos"
> Date: Sat, 05 Apr 2014 03:28:25 -0300
>
> The following program is aborted:
>
> --8<---cut here---start->8---
> (define number-of-thread 1000)
>
> (do ((i number-of-thread (- i 1)))
> ((zero? i))
> (call-with-new-thread (la
> Date: Wed, 26 Mar 2014 12:02:21 -0700 (PDT)
> From: Mike Gran
> Cc: Ludovic Courtès ,
> "guile-user@gnu.org"
>
> The Guile build uses the in-tree Guile executable in
> the GEN guile-procedure.texi step. Backed when I hacked on Guile,
> failing at that step was pretty common if the executabl
> Date: Wed, 26 Mar 2014 19:44:53 +0100
> From: Panicz Maciej Godek
> Cc: Ludovic Courtès ,
> bd...@lists.opendylan.org, "guile-user@gnu.org"
>
> 2014-03-26 19:24 GMT+01:00 Eli Zaretskii :
> >> I had a "process hacker" tool installed,
> Date: Thu, 20 Mar 2014 11:34:53 +0100
> From: Panicz Maciej Godek
> Cc: bd...@lists.opendylan.org, "guile-user@gnu.org"
>
> >> I did remove the only reference to mkstemp.c that appeared in the
> >> Makefile.am, then run autoreconf and configure, but it turned out that
> >> there were still som
> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-user@gnu.org
> Date: Thu, 16 Jan 2014 14:03:05 +0100
>
> Eli Zaretskii skribis:
>
> >> From: l...@gnu.org (Ludovic Courtès)
> >> Date: Thu, 16 Jan 2014 00:29:06 +0100
> >>
> >> Does
> Date: Thu, 16 Jan 2014 15:07:43 +0100
> From: John Darrington
> Cc: Eli Zaretskii , guile-user@gnu.org
>
> If you know that the filename was always obtained using the Guile's
> interface then the issue is never pertinent.The problem comes when a
> function
>
> From: l...@gnu.org (Ludovic Courtès)
> Date: Thu, 16 Jan 2014 00:29:06 +0100
>
> Does anyone know of systems where the file name encoding is commonly
> different from locale encoding? Is it the case on Windows?
Windows stores file names on disk encoded in UTF-16, but converts them
to the curre
> From: Mark H Weaver
> Date: Wed, 15 Jan 2014 16:47:45 -0500
> Cc: guile-user@gnu.org
>
> > All guile needs to know is what encoding the person creating the
> > filesystem has adopted in naming files and which it needs to map to.
>
> Right, but how does it know that? The closest thing we have
> Date: Wed, 15 Jan 2014 21:42:57 +
> From: Chris Vine
> Cc: m...@netris.org, guile-user@gnu.org
>
> I am not sure what you mean, as I am not talking about internal use.
Then I probably didn't understand why you mentioned the external
encoding. How is that relevant to the issue at hand?
I'
> From: Mark H Weaver
> Cc: ch...@cvine.freeserve.co.uk, guile-user@gnu.org
> Date: Wed, 15 Jan 2014 16:34:26 -0500
>
> Well, I understand that MS has standardized on UTF-16 (right?)
Right.
> but what matters from Guile's perspective is the encoding used by
> the POSIX-style interfaces that Gu
> Date: Wed, 15 Jan 2014 19:50:51 +
> From: Chris Vine
> Cc: guile-user@gnu.org
>
> POSIX system calls are encoding agnostic. The filename is just a series
> of bytes terminating with a NUL character. All guile needs to know is
> what encoding the person creating the filesystem has adopted
> From: Mark H Weaver
> Date: Wed, 15 Jan 2014 13:14:39 -0500
> Cc: guile-user@gnu.org
>
> My hope is that this will become less of an issue over time, as systems
> increasingly standardize on UTF-8. I see no other good solution.
>
> Thoughts?
MS-Windows filesystems will not standardize on UTF
> Date: Sun, 10 Nov 2013 23:09:08 +0100
> From: Panicz Maciej Godek
> Cc: "guile-user@gnu.org"
>
> Well, I think that is the reason of the problem -- that for some reason
> Windows reports "utf8" encoding, while iconv requires it to be "UTF-8".
What do you mean by "Windows reports"? Where did
> Date: Sun, 10 Nov 2013 10:16:51 +0100
> From: Panicz Maciej Godek
> Cc: "guile-user@gnu.org"
>
> The dependency walker shows that libiconv depends only on dlls supplied
> by Windows (kernel32.dll, msvcrt.dll and ntdll.dll). The dependency on
> libgcc appears only in libguile, but it seems to h
> Date: Sat, 9 Nov 2013 23:35:33 +0100
> From: Panicz Maciej Godek
>
> ;;; compiling .\extra\common.scm
> ;;; compiling c:/guile2/share/guile/2.0\system\vm\frame.scm
> Backtrace:
> In unknown file:
>?: 1 ;;; compiling system\vm\frame.scm
> Exception thrown while printing backtrace:
> ERROR: I
1 - 100 of 156 matches
Mail list logo
