Linas Vepstas :
> I cannot speak to GC, but I freuqently encounter situations in guile
> where using the parallel constructs e.g. par-for-each, end up running
> slower than the single-threaded version. For example, using 2 or 3
> threads, I get a 2x and 3x speedup, great, but using 4x gives a
> slo
Hans Åberg :
> I saw overhead also for the small allocations, 20-30% maybe. This is
> in a program that makes a lot of allocations relative other
> computations. So that made me wonder about Guile.
I don't have an answer to your question although I would imagine GC
cannot be effectively scaled acr
Christopher Allan Webber :
> I thought they weren't but now I'm not really sure where I got that
> idea from. Does anyone know for sure?
I don't think the language spec says anything about any particular
object or object type being garbage collected. Symbols are first-class
objects and undergo th
Linas Vepstas :
> Well that's a can of worms. Aside from static typing to benefit the
> compiler, there's static typing to help the programmer understand what
> the heck is being passed as an argument to some poorly documented,
> overly-long function. This has always been a kind-of bugaboo of
> re
l...@gnu.org (Ludovic Courtès):
> I don’t know to what extent that is applicable to your software, but my
> recommendation would be to treat that network socket as a Scheme port,
> pass it to ‘read’, and pass the result to ‘eval’ (as opposed to reading
> the whole string from C++ and passing it to
Linas Vepstas :
> On Sun, Sep 10, 2017 at 3:36 PM, Marko Rauhamaa wrote:
>
>> Linas Vepstas :
>> > which suggests that the vast majority of time is spent in GC, and not
>> > in either scheme/guile, or my wrapped c++ code.
>>
>> That may well be
Linas Vepstas :
> which suggests that the vast majority of time is spent in GC, and not
> in either scheme/guile, or my wrapped c++ code.
That may well be normal.
> 4 gc's/minute means one every 15 seconds, which sounds reasonable,
> except that RAM usage is so huge, that each GC takes many secon
Linas Vepstas :
> So if you used GC_malloc_atomic() in your code, then gc will NOT scan
> that region for pointers. guile-2.2 does this correctly for strings (I
> checked) because strings will never contain pointers. I have not
> checked other uses.
The question about mmap(2) is addressed more dir
Christopher Howard :
> Thank you! This looks very helpful! However, there is too much code
> here for me to use it without an explicit license. Would you please
> let me know under which license you are releasing the code?
Public domain.
Marko
Christopher Howard :
> Hello, where do I find a self-balancing tree structure to use with
> guile? I'm new to guile, but I can't seem to find what I'm looking for
> in the guile info document, or in the gnu guile library collection.
If you can't find anything else, here's mine:
http://pacujo.
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer"):
> Marko Rauhamaa writes:
>> I wonder, though, if doing that is fast enough in Scheme code.
>
> Since Guile supports syntax-case, the "macro API" of the library can
> be used so the library itself adds
Mark H Weaver :
> Marko Rauhamaa writes:
>
>> Mark H Weaver :
>>
>>> Marko Rauhamaa writes:
>>>
>>>> l...@gnu.org (Ludovic Courtès):
>>>>
>>>>> libgc knows which regions it must scan and mmap’d regions like
>>&
Chris Vine :
> On Fri, 21 Jul 2017 09:15:28 +0300
> Marko Rauhamaa wrote:
>> The closest I could find is:
>>
>>* Static data region(s). In the simplest case, this is the region
>> between DATASTART and DATAEND, as defined in gcconfig.h. However,
>>
Mark H Weaver :
> Marko Rauhamaa writes:
>
>> l...@gnu.org (Ludovic Courtès):
>>
>>> libgc knows which regions it must scan and mmap’d regions like this
>>> are not among them.
>>
>> Wow, where is that documented? I would have imagined it scanned
l...@gnu.org (Ludovic Courtès):
> libgc knows which regions it must scan and mmap’d regions like this are
> not among them.
Wow, where is that documented? I would have imagined it scanned all
writable RAM and CPU registers.
Marko
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer"):
> Marko Rauhamaa writes:
>
>> l...@gnu.org (Ludovic Courtès):
>>
>>> I’m very skeptical about this use case (I’d use ‘mmap’ and get a
>>> bytevector.)
>>
>> Please elaborate.
>&
l...@gnu.org (Ludovic Courtès):
> I’m very skeptical about this use case (I’d use ‘mmap’ and get a
> bytevector.)
Please elaborate.
1. Does Guile offer mmap to Scheme code?
2. What would prevent Guile's GC from scanning the mmapped area for
pointers?
3. How do I efficiently encode infor
Freja Nordsiek :
> I checked the implementation of bytecectors and SRFI-4 in Guile and
> they are definitely not scanned for pointers. But I would say hacking
> them is not a good general solution for this problem. They are good
> and natural data structures for large arrays of numerical data that
Freja Nordsiek :
> If I was to hazard a reason for why Guile gets very slow when loading
> 20 GB or more (may or may not be related to it being buggy and
> crashy), my guesses would be a lot of the data when loaded into Guile
> was allocated such that the GC scans it for pointers (using
> scm_gc_m
Linas Vepstas :
> String handling in guile is a disaster area: If I give it a
> 10-megabyte-long string in utf8, it promptly tries to convert all of
> that string in utf32, for utterly pointless reasons. This just makes
> it slow.
It's not only the conversion. Strings should be bytes. Python3's e
Amirouche Boubekki :
> I consider dynamic-wind an advanced concept not required for usual
> hacking.
Hm. Python's try/finally has several uses in virtually every program.
Trouble is, Scheme's continuations make it impossible to know when
something is really final. In fact, implementing coroutine
Jan Nieuwenhuizen :
> Christopher Allan Webber writes:
>
>> I've noticed that it's common in Guile modules to use "foo?" for
>> variable names involving booleans. It's tempting,
>
>> But is it a good idea?
>
> It's an idea that I like and use.
There are also the traditional:
(let ((name$ "He
Christopher Allan Webber :
> ((name . "buttercup")
>(age . 6)
>(animal . "horse")
>(food . #("carrot" "oats"))
>(mood-noises
> ("frustrated" . "haurrrfff")
> ("happy" . "negh")
> ("angry" . "*SNORT*")))
>
> I'd be open to the change... if we're going to do the c
Christopher Allan Webber :
> In sum though, it has a nice s-expression based syntax:
>
> scheme@(guile-user)> (define a-horse
> '(@ ("name" "buttercup")
> ("age" 6)
> ("animal" "horse")
>
Mark H Weaver :
> We need to keep all Guix package definitions within Guix itself, for
> the same reason that Linux (the kernel) developers insist on keeping
> all device drivers within a single monolithic tree.
I think that's one of the most unfortunate aspects of Linux.
Just saying.
Marko
Eli Zaretskii :
>> From: Marko Rauhamaa
>> 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 file names, because (a) you
> don't always know
David Kastrup :
> Eli Zaretskii writes:
>> Yes, to be viable in real-life situation, Guile needs to support
>> character strings with occasional embedded raw bytes that cannot be
>> interpreted as characters.
>
> They can be interpreted as "characters", just not inside the _Unicode_
> character ra
Eli Zaretskii :
>> From: Marko Rauhamaa
>> You could leave character strings to application libraries for
>> newsreaders, IRC clients etc, and have a separate byte string data
>> type for the system interface.
>
> I don't know what you mean by "applicati
Eli Zaretskii :
> In any case, this is unrelated to how strings are implemented, because
> the basic level of string implementation _must_ support binary,
> character by character (and byte by byte) comparison. Otherwise, you
> won't be able to compare file names equal, for example, at least on
>
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
> such problems.
Good to hear. If Guile is to adopt a similar approach, it should pay
attention to these details as well.
> The important
Eli Zaretskii :
> Why is that a problem? Unicode generally mandates that equivalent
> character (a.k.a. "codepoint") sequences shall be handled the same by
> applications, both while processing the text (e.g., searching it etc.)
> and when displaying it.
As I just said in another reply, emacs 25
David Kastrup :
> Marko Rauhamaa writes:
>> And the point of bringing concatenation into the discussion was that
>> remapping byte sequences to byte sequences breaks concatenation
>> additivity:
>>
>>U(x) + U(y) = U(x + y)
>
> But Emacs'
David Kastrup :
> It's still irrelevant since split does not _use_ the existing file name
> for constructing new file names.
Split was just an example of a command that concatenates bytes sequences
to get pathnames, nothing more.
Such concatenation is commonplace in Linux programs of all kinds.
David Kastrup :
> Marko Rauhamaa writes:
>> You probably cannot produce valid UTF-8 out of invalid UTF-8 snippets
>> with split(1). However split(1) does form filenames out of its
>> arguments by concatenation:
>>
>> split --additional-suffix=suffix file pre
David Kastrup :
> Marko Rauhamaa writes:
>> That operation fails if you try to translate the snippets to strings
>> before concatenation. Such concatenation operations are commonplace
>> when dealing with filenames (eg, split(1)).
>
> split(1) does not "deal wit
Eli Zaretskii :
> Btw, if by "UCS-2" you meant to say that only characters within the
> BMP are supported in file names on Windows, then this is wrong
No, I'm claiming Windows allows pathnames to contain isolated surrogate
code points, which cannot be decoded back to Unicode with UTF-16.
The sit
Eli Zaretskii :
>> 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.
Eli Zaretskii :
>> 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 ar
Eli Zaretskii :
> At the file system level (for NTFS volumes at least) Windows file
> names are always UTF-16 encoded, and Windows just "knows" that.
Hm, I had the impression NTFS filenames were UCS-2 (https://en.wikipedia.org/wiki/Talk%3AUTF-16/UCS-2>).
Marko
Eli Zaretskii :
>> Date: Wed, 15 Feb 2017 10:18:32 +0100
>> From:
>> I think the only sane way to see a Linux file system path is the way
>> Linux sees it: as a byte string.
>
> This would lose a lot in 99% of use cases. You are, in effect,
> suggesting a "reverse optimization", whereby the major
:
> On Wed, Feb 15, 2017 at 12:58:41AM +0100, David Kastrup wrote:
>> LilyPond is getting removed from Debian and other distributions
>> because it is still hopeless to get it to run under Guile-2 (the
>> experimental support has encoding and stability problems and runs
>> about a factor of 5 slow
David Kastrup :
> If you tell Emacs that some external entity is in UTF-8, it will
> represent all valid UTF-8 sequences as properly decoded characters,
> and it has special codes for all bytes not part of valid UTF-8.
>
> As a result, it works with valid UTF-8 perfectly as expected but will
> rep
Chris Vine :
> On Tue, 14 Feb 2017 21:52:01 + (UTC)
> Mike Gran wrote:
>> True. Linux should follow OpenBSD and make all locales UTF-8.
>
> Filenames and locales are not necessarily related.
Linux *could* force that reality.
> When you access a networked file system, you get the filename en
Mike Gran :
> On Tuesday, February 14, 2017 1:07 PM, Marko Rauhamaa
> wrote:
>> Unicode strings are a special data type that have relatively little>
>> practical use. Byte strings are much more fundamental. C's "char *"
>> is perfect.
>
> Human la
Mike Gran :
> The great difficulty with the UTF-8 Guile prototype was the need to
> interrogate every string access or index to decide if it was a
> codepoint index or a byte index.
Unicode strings are a special data type that have relatively little
practical use. Byte strings are much more funda
Linas Vepstas :
> Unicode is just a bunch of bytes that are null-terminated.
That is not what Unicode is. Maybe you are thinking of UTF-8, an
ingenious way to map a Unicode sequence onto a byte sequence. Trouble
is, there are byte sequences that are illegal UTF-8. While they are
illegal for Unico
Arne Babenhauserheide :
> Marko Rauhamaa writes:
>> Then, there's GOOPS, which in my opinion is simply an unnatural way
>> to go about object-oriented programming. It does violence both to
>> ordinary OO way of thinking and classic Lisp idioms.
>
> GOOPS works p
Panicz Maciej Godek :
> I think that Python is popualr because you don't need Emacs to work
> with it.
You do need a special editor to work with Python, and emacs is perfect
for it.
Python is popular because it is a very traditional, dynamic, high-level
programming language. It is conceptually v
Eli Zaretskii :
>> From: Marko Rauhamaa
>>
>> 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
David Kastrup :
> Marko Rauhamaa writes:
>> Guile's mistake was to move to Unicode strings in the operating system
>> interface.
>
> Emacs uses an UTF-8 based encoding internally [...]
C uses 8-bit characters. That is a model worth emulating.
UTF-8 beautifully brid
David Kastrup :
> But at any rate, this cannot easily be fixed since Guile uses libraries
> for encoding/decoding that cannot deal reproducibly with improper byte
> patterns.
Guile's mistake was to move to Unicode strings in the operating system
interface.
> The problem here is that Guile cannot
David Kastrup :
> Marko Rauhamaa writes:
>> l...@gnu.org (Ludovic Courtès):
>>> Guile assumes its command-line arguments are UTF-8-encoded and
>>> decodes them accordingly.
>>
>> I'm afraid that choice (which Python made, as well) was a bad one
>
l...@gnu.org (Ludovic Courtès):
> In C, argv is just an array of byte sequences, but in Guile,
> (command-line) returns a list of strings, not a list of bytevectors.
>
> Guile decodes its arguments according to the encoding of the current
> locale. So if you’re in a UTF-8 locale (say, zn_CH.utf8 o
Chris Vine :
> On Fri, 29 Jul 2016 21:00:42 +0300
> Marko Rauhamaa wrote:
> [snip]
>> More generally, take a look at > http://www.delorie.com/gnu/docs/guile/guile-tut_10.html> and how
>> MAKE-CELL has been defined. That's true OOP without classes or slots.
>
Kovacsics Róbert :
> Thank you, I am still thinking in Java terms at the moment.
>
> [...]
>
> But this is a very classes-contain-methods approach and given what you
> said, makes me think that I'm doing this wrong thing.
I'm thinking GOOPS is the wrong thing here.
A better, more Schemey way is
Pierre Lairez :
> No, forget what I just wrote, this is obvious.
Two mathematicians met in the university cafeteria. They exchanged
hellos and started chatting. It turned out one of them had just prepared
a paper and was about to send it out for peer review. He had a draft
copy with him and the f
Chris Vine :
> First, there will always be a use for an event loop to do event-loopy
> things, irrespective of whether and how a coroutine interface is put
> around it. Sometimes you want to abstract things away, sometimes you
> don't.
Callback hell is my preferred programming paradigm. Any attem
Andy Wingo :
> The trouble is that AFAIU there is no way to make non-blocking input
> work reliably with O_NONBLOCK file descriptors in the approach that
> Guile has always used.
>
> [...]
>
> The problem with this is not only spurious wakeups, as you note, but
> also buffering. Throwing an except
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer"):
> By the way, R7RS has standardized the syntax |foo| to denote symbols,
What is the R7RS notation for the symbol "|" (without the quotes)?
Marko
Christopher Allan Webber :
> Marko Rauhamaa writes:
>> (run-delay (lambda (hello-snore)) 1)
>
> I'm not sure how this one would run...
Typo on my part: (lambda () (hello-snore))
Marko
Christopher Allan Webber :
> http://dustycloud.org/tmp/8sync-tutorial-part1.html
>
> It gets into the basics of the agenda, using delays to keep things
> simple.
Comments:
* A typo: The text talks about "run-at" but the example has
"run-delay".
* I'm guessing "run-delay" is a macro. In m
Jan Wedekind :
> On Thu, 31 Mar 2016, Marko Rauhamaa wrote:
>> (get-x) is only a fig leaf for (slot-ref). In general, no user of an
>> object should think the object holds a piece of information
>> called x. Instead, you should be interacting with the abstract object
>>
Barry Fishman :
> On 2016-03-30 22:57:25 +0300, Marko Rauhamaa wrote:
>> All you can serialize is information. Objects are living things we
>> experience through interactions alone.
>
> Do we really want our computers to behave like organic black boxes?
I'll say yes.
Jan Wedekind :
> On Wed, 30 Mar 2016, Marko Rauhamaa wrote:
>> GOOPS' has the worst possible object model: objects are seen as mere
>> data records. The concept of a "slot" is an anathema to OOP.
>
> Ok, I have updated the example to use accessor functions
Jan Wedekind :
> GOOPS supports "open" classes and multiple-dispatch. E.g. you can extend
> the "write" method to control how an object is displayed within the
> Guile REPL [1]. Another interesting approach are multi-methods in
> Clojure which don't even require explicit types for dispatching.
>
>
Panicz Maciej Godek :
> 2016-03-30 19:53 GMT+02:00 Marko Rauhamaa :
> The problem with closures is, among others, that they are
> non-serializable
What is there to serialize in objects? How do you serialize a car? How
do you serialize an ant? How do you serialize a person?
All you can
Panicz Maciej Godek :
> 2016-03-30 13:18 GMT+02:00 Jan Nieuwenhuizen :
>
>> Panicz Maciej Godek writes:
>>
>> > I also used GOOPS, which I regret to this day, and so the
>> > whole framework needs a serious rewrite
>>
>> What is it that you do not like about GOOPS?
>
> Most specifically, I dislike
Alex Kost :
> Ah, thanks! I get it. But I also want to check an exit status of the
> running command (sorry, that I didn't mention it). So I would like to
> have the following procedure:
>
> (define (system-no-output* . args)
> "Like 'system*' but suppress the output of the command indicated
Alex Kost :
> Hello, in the guile REPL I evaluated the following:
>
> (with-output-to-port (%make-void-port "w")
> (lambda () (display "foo") (newline)))
>
> and I got no output as expected. Then I tried the following:
>
> (with-output-to-port (%make-void-port "w")
> (lambda () (syste
l...@gnu.org (Ludovic Courtès):
> (Back in the day I thinking
> about something like that to avoid the callback hell in Guile-Avahi.)
Don't know anything about Guile-Avahi, but callback hell happens to be
my favorite programming model.
Marko
Matt Wette :
> [2] may be possible if it is supported by the Guile regexp library.
> But I’m not sure there is a clean way to do this, given that
> syntax-case bindings are lexical.
Additionally, you have a problem with the different regexp flags
(newline semantics, case-sensitivity etc).
Maybe
Matt Wette :
> Comments on syntax appreciated. — Matt
>
> === test
> (define str "foo")
>
> (regex-case str
>(("^([a-z]+)\\(([0-9]+)\\)$" v i)
> (list v i))
>(("^([a-z]+)$" v)
> (list v "1”)))
> =>
> (“foo” “1”)
>
>
> === syntax ==
> (regex-case
> (
David Kastrup :
> That's more economical than Python's method which uses the encodings
> of surrogate words not allowed in properly encoded UTF-8, taking
> 3 bytes rather than the 2 Emacs makes do with. Using high codepoints
> above the Unicode space would even take 4 bytes.
Actually, CPython rep
Eli Zaretskii :
>> From: Marko Rauhamaa
>> Why don't you tell me already what emacs does?
>
> I did, you elided that. It represents text as superset of UTF-8, and
> uses high codepoints above the Unicode space for raw bytes.
Excellent. If that works, Guile needs th
Eli Zaretskii :
>> From: Marko Rauhamaa
>> The Linux kernel just doesn't care, and shouldn't.
>
> Guile is not an OS kernel. Guile is an environment for writing
> applications. On the application level, you _should_ care, or else you
> won't be able to m
Eli Zaretskii :
>> From: Marko Rauhamaa
>> 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",
Chris Vine :
> So I guess the best rule is that, even if you don't stick to the
> Portable Filename Character Set, stick to ASCII for filenames/paths.
The filenames are not in my control or Guile's. Guile can't simply wish
the filenames to be strings, or, like Python, it would at least need
some
Vicente Vera :
> Should this be sent to the bugs list?
Go ahead.
Marko
Chris Vine :
> On Tue, 22 Dec 2015 03:14:18 +0200
> Marko Rauhamaa wrote:
>> For example,
>>
>> scheme@(guile-user)> (opendir ".")
>> $1 = #
>> [...]
>> scheme@(guile-user)> (readdir $1)
>> $4 = "?9t\
Chris Vine :
> I think the problem is that calling the native 'primitive-load'
> procedure on a filename with UTF-8 encoding with a character outside
> the ASCII range (when the locale encoding is also UTF-8) fails to work
> unless you call '(set-locale LC_ALL "")' in the program first.
>
> Of cou
Vicente Vera :
> Hello. I'm sorry if this is the wrong list (I'm not sure if its a
> bug).
Must be a bug.
> I wrote a small test script:
The error is reproduced with an empty scm file:
touch test.scm
guile test.scm
[...]
ERROR: In procedure open-file: No such file or directory: [..
Marko Rauhamaa :
> It seems to me whoever wrote the spec wasn't thinking of nonblocking
> ports at all. Are nonblocking ports recognized by RnRS?
Took a quick glance at the R6RS spec. It would appear nonblocking ports
are *not* mentioned or thought of in it.
Thus, *any* nonblocki
Chris Vine :
> I think better non-blocking RnRS input procedures would be advantageous
> for the reasons you have given, but R6RS and R7RS seem to me to be clear
> on any reasonable reading: apart from get-bytevector-some they require
> blocking behaviour if the request has not been met and end-of
Mark H Weaver :
> While I'm reluctant to guarantee any fixed limit, I can offer this: the
> returned bytevector will always be of a manageable size,
>
> [...]
>
> Would this work for you?
It suits my immediate needs, thank you.
However, I think the whole slew of bytevector I/O could take a more
Amirouche Boubekki :
> I can't make work `get-bytevector-some` with my code. It only returns
> a single cell bv.
Run my test code as follows:
cat | guile test.scm
That way, you get the natural pipe semantics for stdin.
> Instead I use `char-ready?`. Here is the definition of `recv-some`:
>
Marko Rauhamaa :
> l...@gnu.org (Ludovic Courtès):
>> That’s because get-bytevector-n{,!} are specified as blocking if
>> necessary until N bytes are read or EOF is reached.
>
> Ok, the Guile manual description leaves it a ambiguous. Even the R6RS
> wording could be gra
l...@gnu.org (Ludovic Courtès):
>> If you replace (get-bytevector-some port) with
>> (get-bytevector-n port 8192) or (get-bytevector-n! port bv 0 8192),
>> no partial data is returned.
>
> That’s because get-bytevector-n{,!} are specified as blocking if
> necessary until N bytes are read or EOF is
Guile 2.0.11 provides:
get-bytevector-n
get-bytevector-n!
get-bytevector-some
Of these, only get-bytevector-some seems to behave as expected when the
port is nonblocking:
(use-modules (rnrs io ports)
I'm using (ice-9 getopt-long) with Guile 2.0.11.
The documentation (https://www.gnu.org/software/guile/manual/htm
l_node/getopt_002dlong-Reference.html#getopt_002dlong-Reference>)
states:
getopt-long signals an error if [...]
A required option is omitted.
The leading comment in the s
Arne Babenhauserheide :
> Making Scheme as usable as Python requires finding an elegance which
> fits Scheme and allows creating applications at least as easily as
> with Python — but not necessarily in the same style.
The main thing is to keep the S expressions' data/code duality. Python
doesn't
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer"):
> So we are back to square one: anyone who wants to use Scheme for
> something real needs to pick a specific implementation,
Which is true for other programming languages as well: C, C++, Python,
..
For me, in practice, C/C++ is gcc, Pyth
Panicz Maciej Godek :
> The best thing that Scheme does for programming is that it promotes
> writing software that can be read, and not only executed.
Really? I think the best thing Scheme does for programming is it brings
you closer to God. Seriously, Lisp in general and Scheme in particular
is
Tomas By :
> In a Guile program I am using (system ) to start a C binary
> which I then communicate with over the network.
>
> I'm wondering if there is any way to get the process id of this binary?
>
> Have tried to call "ps -A|grep " using with-output-to-string and
> with-error-to-string, but am
Markus Gothe :
> You should make some buzz outside the mailing-list
I have definite use cases in mind where I might be interested in
migrating to Guix. I hope to be able to investigate Guix one day.
However, it's a complex beast, and the introductory material hasn't been
prepared with my use case
"Pascal J. Bourguignon" :
> Marko Rauhamaa writes:
>
>> Similarly, in my mind, objects don't have slots, they interact.
>
> You are right. Slots are an implementation detail. Notice that you
> have them in all (common) OO systems. But the difference with CL
Ralf Mattes :
> Guile's GOOPS is a (rather impressive) clone of CLOS, the Common Lisp
> Object System. I such a system functions/methods don't "belong" to a
> class.
>
> [...]
>
> Message passing only exists in object systems where methods belong to
> a class/object. Generic functions don't "belo
Michael Tiedtke :
> Nice! What about (define-class () ...)? In GOOPS every
> primitive type is (or should be) a class that can be used with
> multiple inheritance. It's enough to (use-modules (oop goops)).
My "simpleton" doesn't have classes. It's *object* oriented, not *class*
oriented.
> Then
Michael Tiedtke :
> Perhaps it's better to recreate a clean object model without 3,000
> lines of C code like GOOPS. But then GOOPS really creates the illusion
> of an object oriented environment with a MOP ...
I'd stay away from GOOPS -- it's a leap away from functional
programming, IMO.
Here's
Eli Zaretskii :
>>>> From: Marko Rauhamaa
>> I'd like to produce Guile code that works on Linux. As it stands, I
>> can't.
>
> Of course you can: write it in C and load it via FFI.
Well, for that, I don't even need Guile; all I need is gcc.
It'
Eli Zaretskii :
>> 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 ha
1 - 100 of 132 matches
Mail list logo
