Hi folks!
Now that we all have such need, why bother to polish the nasty REPL way for
remote execution?
Let's discuss serializable-continuations which I always expect very much!
2017年9月20日 上午4:38，"Chris Vine" 写道：
> On Tue, 19 Sep 2017 21:18:40 +0100
> Chris Vine wrote:
> > ... Ports are also no
On Tue, 19 Sep 2017 21:18:40 +0100
Chris Vine wrote:
> ... Ports are also not thread safe (rightly so in my view), and I
> believe that extends to the global stdout and stdin ports.
By that I mean that any one port object is not thread safe against
concurrent use by two or more different threads,
On Tue, 19 Sep 2017 19:04:21 +0800
Linas Vepstas wrote:
> On Fri, Sep 15, 2017 at 3:56 PM, Ludovic Courtès wrote:
[snip]
> > That said, if you run a REPL server in a separate thread and mutate
> > the global state of the program, you could possibly crash it—no
> > wonders here.
> >
>
> Yes, we
Hi Ludo,
On Fri, Sep 15, 2017 at 3:56 PM, Ludovic Courtès wrote:
> Linas Vepstas skribis:
>
> > On Mon, Sep 11, 2017 at 2:26 AM, Ludovic Courtès wrote:
> >
> >> Hello,
> >>
> >> Linas Vepstas skribis:
> >>
> >> > The stuff coming over the network sockets are bytes, not s-exps. Since
> >> none
Linas Vepstas skribis:
> On Mon, Sep 11, 2017 at 2:26 AM, Ludovic Courtès wrote:
>
>> Hello,
>>
>> Linas Vepstas skribis:
>>
>> > The stuff coming over the network sockets are bytes, not s-exps. Since
>> none
>> > of the bytes are ever zero, they are effectively C/C++ strings, and are
>> > hand
On Mon, Sep 11, 2017 at 2:26 AM, Ludovic Courtès wrote:
> Hello,
>
> Linas Vepstas skribis:
>
> > The stuff coming over the network sockets are bytes, not s-exps. Since
> none
> > of the bytes are ever zero, they are effectively C/C++ strings, and are
> > handled as such. These C strings are sen
Hi Marko,
Marko Rauhamaa skribis:
> 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
>>
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
Hello,
Linas Vepstas skribis:
> The stuff coming over the network sockets are bytes, not s-exps. Since none
> of the bytes are ever zero, they are effectively C/C++ strings, and are
> handled as such. These C strings are sent to scm_eval_string() wrapped
> by scm_c_catch().
I don’t know to wha
Hi Ludo,
Perhaps I was too brief in my remarks. By a networked REPL, I meant this:
https://www.gnu.org/software/guile/manual/html_node/REPL-Servers.html
For accidental, historical reasons, (i.e. I did not know the above existed)
I wrote my own variant, which accepts network connections, handles
Hi,
Linas Vepstas skribis:
> 1) There is a need to pass messages between subsystems running on different
> machines.
>
> 2) Solutions include ROS, ZeroMQ, google protocol buffers... whatever. All
> require lots of work, a learning curve, complexity, etc.
>
> 3) Wait! I know! I will just send a
Hi Marko,
On Sat, Sep 9, 2017 at 5:31 PM, Marko Rauhamaa wrote:
> 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
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
Stale reply to old message, but maybe its still helpful:
On Fri, Jul 21, 2017 at 1:15 AM, Marko Rauhamaa wrote:
> 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 am
Hi Ludo, a very late reply...
On Thu, Jul 20, 2017 at 10:28 AM, Ludovic Courtès wrote:
>
> > 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 mak
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 absolutely zero runtime overhead.
No
Marko Rauhamaa writes:
>>> 1. Does Guile offer mmap to Scheme code?
>>
>> It's pretty easy to call C functions from Scheme.
>
> Not good enough. I would have to precompile libraries for different
> target platforms (or require the target environment to have a C
> compiler). Besides, the need is
> On Jul 20, 2017, at 9:22 AM, Marko Rauhamaa wrote:
>
> 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
Marko Rauhamaa writes:
> What you're saying points out a secondary problem that applies to
> Guile C programming. If you have stored Guile smob references in, say,
> third-party library objects, you'll need to carefully protect and
> unprotect them.
It may be worth mentioning that this includes
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
> this are not among them.
Wow, where is that documented? I would have imag
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 this
are not among them.
>>>
>>> Wow, where is that documented? I would have imagined it scanned all
>>> writab
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,
>> in most cases, this will also inv
On Fri, 21 Jul 2017 09:15:28 +0300
Marko Rauhamaa wrote:
> 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?
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 all
>> writable RAM and CPU registers.
>
> It's do
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 all
> writable RAM and CPU registers.
It's documented here: http://www.hbo
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
Hi Marko,
Marko Rauhamaa skribis:
> taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer"):
[...]
>>> 2. What would prevent Guile's GC from scanning the mmapped area for
>>> pointers?
>>
>> I don't know the details but AFAIK this is no problem with Boehm GC.
>
> I don't understand. It c
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.
>>
>> 1. Does Guile offer mmap to Scheme code?
>
> It's pretty
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.
>
> 1. Does Guile offer mmap to Scheme code?
It's pretty easy to call C functions from Scheme. Here's a trivial
example.
$ cat m
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
Hi Linas,
Linas Vepstas skribis:
> Lack of decent science libraries for scheme is a major stumbling block, for
> me. Simply having sine and cosine is not enough. I got excited (a decade
> ago) when I realized that guile supported GnuMP, and then rapidly deflated
> when I realized it only suppo
31 matches
Mail list logo
