unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Curiosity: Microkernel implemented in Guile ?
@ 2022-06-23  6:11 Matias Jose Seco Baccanelli
  2022-06-23  6:57 ` Mikael Djurfeldt
                   ` (6 more replies)
  0 siblings, 7 replies; 29+ messages in thread
From: Matias Jose Seco Baccanelli @ 2022-06-23  6:11 UTC (permalink / raw)
  To: guile-user

Good morning Guilers!
Being a huge fan of Libre Software and Guile powers, i was having a big
curiosity in regards to the kernel languages arena:
was ever made an attempt to implement a Microkernel from scratch in
Guile language ?
Isn't a cool mix the functional approach of Guile and the modular one
of Microkernel ? (and loads of more features i suppose!)

Feels like a nice recipe for User Empowerment !
Just asking as a total beginner on this topic,   
Happy Hacking!
Matias



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23  6:11 Curiosity: Microkernel implemented in Guile ? Matias Jose Seco Baccanelli
@ 2022-06-23  6:57 ` Mikael Djurfeldt
  2022-06-23  9:01   ` Ricardo G. Herdt
  2022-06-23  7:02 ` Dr. Arne Babenhauserheide
                   ` (5 subsequent siblings)
  6 siblings, 1 reply; 29+ messages in thread
From: Mikael Djurfeldt @ 2022-06-23  6:57 UTC (permalink / raw)
  To: Matias Jose Seco Baccanelli; +Cc: guile-user, Mikael Djurfeldt

To my knowledge, the answer is no. No such attempt has been made.

The Guile language is essentially Scheme. Scheme lacks various constraints,
with regard to typing, memory management, etc, needed for it to be compiled
to predictable and near maximally efficient machine code, something which
is needed, at least for portions of the code, when implementing a useful
microkernel.

In theory, it is possible to extend the language for such purposes, though.

An alternative high level language which can be used to implement a kernel
is Rust.

Best regards,
Mikael

Den tors 23 juni 2022 08:12Matias Jose Seco Baccanelli <
matias_jose_seco@autoproduzioni.net> skrev:

> Good morning Guilers!
> Being a huge fan of Libre Software and Guile powers, i was having a big
> curiosity in regards to the kernel languages arena:
> was ever made an attempt to implement a Microkernel from scratch in
> Guile language ?
> Isn't a cool mix the functional approach of Guile and the modular one
> of Microkernel ? (and loads of more features i suppose!)
>
> Feels like a nice recipe for User Empowerment !
> Just asking as a total beginner on this topic,
> Happy Hacking!
> Matias
>
>


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23  6:11 Curiosity: Microkernel implemented in Guile ? Matias Jose Seco Baccanelli
  2022-06-23  6:57 ` Mikael Djurfeldt
@ 2022-06-23  7:02 ` Dr. Arne Babenhauserheide
  2022-06-23  7:32 ` zimoun
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 29+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-06-23  7:02 UTC (permalink / raw)
  To: Matias Jose Seco Baccanelli; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

Moin Matias,

Matias Jose Seco Baccanelli <matias_jose_seco@autoproduzioni.net> writes:
> Isn't a cool mix the functional approach of Guile and the modular one
> of Microkernel ? (and loads of more features i suppose!)
>
> Feels like a nice recipe for User Empowerment !

The most practical way forwards for that might be Guile bindings for the
Hurd. Those would enable to move more Guile in incrementally while
always keeping a working state.

The incubator already has bindings for common-lisp.¹ Those could be a
good starting point. And there is Guix for the Hurd.

http://git.savannah.gnu.org/cgit/hurd/incubator.git/?h=clisp

Those bindings would allow for stuff like this to be done in Guile:

    Deferred Authorization translator for the Hurd
    https://www.draketo.de/software/hurd-authorization-translator

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23  6:11 Curiosity: Microkernel implemented in Guile ? Matias Jose Seco Baccanelli
  2022-06-23  6:57 ` Mikael Djurfeldt
  2022-06-23  7:02 ` Dr. Arne Babenhauserheide
@ 2022-06-23  7:32 ` zimoun
  2022-06-23  7:34 ` Maxime Devos
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 29+ messages in thread
From: zimoun @ 2022-06-23  7:32 UTC (permalink / raw)
  To: Matias Jose Seco Baccanelli, guile-user

Hi,
On Thu, 23 Jun 2022 at 08:11, Matias Jose Seco Baccanelli <matias_jose_seco@autoproduzioni.net> wrote:
> Good morning Guilers!
> Being a huge fan of Libre Software and Guile powers, i was having a big
> curiosity in regards to the kernel languages arena:
> was ever made an attempt to implement a Microkernel from scratch in
> Guile language ?
> Isn't a cool mix the functional approach of Guile and the modular one
> of Microkernel ? (and loads of more features i suppose!)

Well, it is not what you are asking but maybe you could be interested
by:

https://icfp20.sigplan.org/details/scheme-2020-papers/3/Running-Scheme-On-Bare-Metal-Experience-Report-
https://www.youtube.com/watch?v=GWr4iQfc0uw



Cheers,
simon



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23  6:11 Curiosity: Microkernel implemented in Guile ? Matias Jose Seco Baccanelli
                   ` (2 preceding siblings ...)
  2022-06-23  7:32 ` zimoun
@ 2022-06-23  7:34 ` Maxime Devos
  2022-06-23  9:13 ` pukkamustard
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 29+ messages in thread
From: Maxime Devos @ 2022-06-23  7:34 UTC (permalink / raw)
  To: Matias Jose Seco Baccanelli, guile-user

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

Matias Jose Seco Baccanelli schreef op do 23-06-2022 om 08:11 [+0200]:
> Feels like a nice recipe for User Empowerment !

How does this empower users?  Sure, if the user is a programmer they
can modify their custom microkernel in Scheme, but then you have a very
niche OS that practically no other software already supports, which is
very inconvenient for the user and the user will have practical
difficulties sharing the software with other people using other OSes,
so I think you're better of modifying another pre-existing microkernel
to be usable from Guile (see answer by Dr. Arne Babenhauserheide).

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23  6:57 ` Mikael Djurfeldt
@ 2022-06-23  9:01   ` Ricardo G. Herdt
  2022-06-24  5:40     ` Dr. Arne Babenhauserheide
  0 siblings, 1 reply; 29+ messages in thread
From: Ricardo G. Herdt @ 2022-06-23  9:01 UTC (permalink / raw)
  To: guile-user

Never tried it myself, but in case you are interested in exploring 
Scheme for this kind of development, check Loko Scheme, which runs on 
bare-metal and is developed to be a "platform for application and 
operating system development":

https://scheme.fail/

There is also a #loko channel on libera.

Ricardo

Am 23.06.2022 08:57 schrieb Mikael Djurfeldt:
> To my knowledge, the answer is no. No such attempt has been made.
> 
> The Guile language is essentially Scheme. Scheme lacks various 
> constraints,
> with regard to typing, memory management, etc, needed for it to be 
> compiled
> to predictable and near maximally efficient machine code, something 
> which
> is needed, at least for portions of the code, when implementing a 
> useful
> microkernel.
> 
> In theory, it is possible to extend the language for such purposes, 
> though.
> 
> An alternative high level language which can be used to implement a 
> kernel
> is Rust.
> 
> Best regards,
> Mikael
> 
> Den tors 23 juni 2022 08:12Matias Jose Seco Baccanelli <
> matias_jose_seco@autoproduzioni.net> skrev:
> 
>> Good morning Guilers!
>> Being a huge fan of Libre Software and Guile powers, i was having a 
>> big
>> curiosity in regards to the kernel languages arena:
>> was ever made an attempt to implement a Microkernel from scratch in
>> Guile language ?
>> Isn't a cool mix the functional approach of Guile and the modular one
>> of Microkernel ? (and loads of more features i suppose!)
>> 
>> Feels like a nice recipe for User Empowerment !
>> Just asking as a total beginner on this topic,
>> Happy Hacking!
>> Matias
>> 
>> 



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23  6:11 Curiosity: Microkernel implemented in Guile ? Matias Jose Seco Baccanelli
                   ` (3 preceding siblings ...)
  2022-06-23  7:34 ` Maxime Devos
@ 2022-06-23  9:13 ` pukkamustard
  2022-06-23 10:09 ` Nala Ginrut
  2022-06-23 12:13 ` Ognen Duzlevski
  6 siblings, 0 replies; 29+ messages in thread
From: pukkamustard @ 2022-06-23  9:13 UTC (permalink / raw)
  To: Matias Jose Seco Baccanelli; +Cc: guile-user


As mentioned, Scheme lacks various things that you might need to
implement a bare-metal microkernel (for example manual memory
management).

There is PreScheme
(https://thintz.com/resources/prescheme-documentation) - a low-level
dialect of Scheme that gives you the necessary primitives. PreScheme can
be run from Scheme (see
https://thintz.com/resources/prescheme-documentation#Running-Pre_002dScheme-as-Scheme)
by emulating lower-levels. This allows you to hack on low-level code
directly from the REPL.

You might also be interested in the 3L project (https://3lproject.org/)
that did some work towards using PreScheme for bare-metal programming.

Regards,
pukkamustard

Matias Jose Seco Baccanelli <matias_jose_seco@autoproduzioni.net> writes:

> Good morning Guilers!
> Being a huge fan of Libre Software and Guile powers, i was having a big
> curiosity in regards to the kernel languages arena:
> was ever made an attempt to implement a Microkernel from scratch in
> Guile language ?
> Isn't a cool mix the functional approach of Guile and the modular one
> of Microkernel ? (and loads of more features i suppose!)
>
> Feels like a nice recipe for User Empowerment !
> Just asking as a total beginner on this topic,   
> Happy Hacking!
> Matias




^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23  6:11 Curiosity: Microkernel implemented in Guile ? Matias Jose Seco Baccanelli
                   ` (4 preceding siblings ...)
  2022-06-23  9:13 ` pukkamustard
@ 2022-06-23 10:09 ` Nala Ginrut
  2022-06-23 11:22   ` Maxime Devos
  2022-06-23 15:38   ` Nala Ginrut
  2022-06-23 12:13 ` Ognen Duzlevski
  6 siblings, 2 replies; 29+ messages in thread
From: Nala Ginrut @ 2022-06-23 10:09 UTC (permalink / raw)
  To: Matias Jose Seco Baccanelli; +Cc: Guile User

Personally, I don't think Guile (as Scheme) is suitable for a system level
language for low-level programming. But it's a good choice to use Guile to
extend a C implemented microkernel.

Such a design, is actually the real GNU operating system described in
imagination. So the question should be: is there any attempt to write GNU
Hurd binding with Guile, and implement the multi server OS to complete GNU?

I never heard of such a libre project, but I do think it's worth to try.

Best regards.

On Thu, Jun 23, 2022, 14:12 Matias Jose Seco Baccanelli <
matias_jose_seco@autoproduzioni.net> wrote:

> Good morning Guilers!
> Being a huge fan of Libre Software and Guile powers, i was having a big
> curiosity in regards to the kernel languages arena:
> was ever made an attempt to implement a Microkernel from scratch in
> Guile language ?
> Isn't a cool mix the functional approach of Guile and the modular one
> of Microkernel ? (and loads of more features i suppose!)
>
> Feels like a nice recipe for User Empowerment !
> Just asking as a total beginner on this topic,
> Happy Hacking!
> Matias
>
>


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23 10:09 ` Nala Ginrut
@ 2022-06-23 11:22   ` Maxime Devos
  2022-06-23 15:38   ` Nala Ginrut
  1 sibling, 0 replies; 29+ messages in thread
From: Maxime Devos @ 2022-06-23 11:22 UTC (permalink / raw)
  To: Nala Ginrut, Matias Jose Seco Baccanelli; +Cc: Guile User

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

Nala Ginrut schreef op do 23-06-2022 om 18:09 [+0800]:
> Such a design, is actually the real GNU operating system described in
> imagination. So the question should be: is there any attempt to write GNU
> Hurd binding with Guile, and implement the multi server OS to complete GNU?
> 
> I never heard of such a libre project, but I do think it's worth to try.

I've tried converting the clisp bindings to Scheme in
<https://notabug.org/guile-hurd/guile-hurd>, though it didn't quite
work out.  Someone could try continuing that effort?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23  6:11 Curiosity: Microkernel implemented in Guile ? Matias Jose Seco Baccanelli
                   ` (5 preceding siblings ...)
  2022-06-23 10:09 ` Nala Ginrut
@ 2022-06-23 12:13 ` Ognen Duzlevski
  2022-06-23 13:30   ` Dr. Arne Babenhauserheide
  6 siblings, 1 reply; 29+ messages in thread
From: Ognen Duzlevski @ 2022-06-23 12:13 UTC (permalink / raw)
  To: guile-user

Matias Jose Seco Baccanelli <matias_jose_seco@autoproduzioni.net> writes:

> Good morning Guilers!
> Being a huge fan of Libre Software and Guile powers, i was having a big
> curiosity in regards to the kernel languages arena:
> was ever made an attempt to implement a Microkernel from scratch in
> Guile language ?
> Isn't a cool mix the functional approach of Guile and the modular one
> of Microkernel ? (and loads of more features i suppose!)

What I think would be easier to do is embed Scheme inside an OS kernel....



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23 12:13 ` Ognen Duzlevski
@ 2022-06-23 13:30   ` Dr. Arne Babenhauserheide
  2022-06-23 17:47     ` Paul Emsley
  0 siblings, 1 reply; 29+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-06-23 13:30 UTC (permalink / raw)
  To: Ognen Duzlevski; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]


Ognen Duzlevski <maketo@sdf.org> writes:

> Matias Jose Seco Baccanelli <matias_jose_seco@autoproduzioni.net> writes:
>> Isn't a cool mix the functional approach of Guile and the modular one
>> of Microkernel ? (and loads of more features i suppose!)
>
> What I think would be easier to do is embed Scheme inside an OS kernel....

With the Hurd you reduce the scope of what is the kernel, so Scheme can
do lots of jobs usually reserved for lower-level languages. You could
for example write your complete filesystem or networking layer in
Scheme.

This may sound strange at first, but LuaJIT is already used for packet
filtering, so it’s not that far out. For the performance critical parts,
you can still FFI to Rust or C.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23 10:09 ` Nala Ginrut
  2022-06-23 11:22   ` Maxime Devos
@ 2022-06-23 15:38   ` Nala Ginrut
  2022-06-23 22:03     ` Dr. Arne Babenhauserheide
  1 sibling, 1 reply; 29+ messages in thread
From: Nala Ginrut @ 2022-06-23 15:38 UTC (permalink / raw)
  To: Matias Jose Seco Baccanelli; +Cc: Guile User

Many folks shared great Scheme for lower-level. I think I have to clarify
that I agree that Scheme is good for low-level, depends on implementation.
But we are talking about Guile, and Guile was not designed for that
purpose, it's dedicated to extend C program, so the better choice is to
extend a C microkernel with Guile. That is what it was designed for,
originally.


On Thu, Jun 23, 2022, 18:09 Nala Ginrut <nalaginrut@gmail.com> wrote:

> Personally, I don't think Guile (as Scheme) is suitable for a system level
> language for low-level programming. But it's a good choice to use Guile to
> extend a C implemented microkernel.
>
> Such a design, is actually the real GNU operating system described in
> imagination. So the question should be: is there any attempt to write GNU
> Hurd binding with Guile, and implement the multi server OS to complete GNU?
>
> I never heard of such a libre project, but I do think it's worth to try.
>
> Best regards.
>
> On Thu, Jun 23, 2022, 14:12 Matias Jose Seco Baccanelli <
> matias_jose_seco@autoproduzioni.net> wrote:
>
>> Good morning Guilers!
>> Being a huge fan of Libre Software and Guile powers, i was having a big
>> curiosity in regards to the kernel languages arena:
>> was ever made an attempt to implement a Microkernel from scratch in
>> Guile language ?
>> Isn't a cool mix the functional approach of Guile and the modular one
>> of Microkernel ? (and loads of more features i suppose!)
>>
>> Feels like a nice recipe for User Empowerment !
>> Just asking as a total beginner on this topic,
>> Happy Hacking!
>> Matias
>>
>>


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23 13:30   ` Dr. Arne Babenhauserheide
@ 2022-06-23 17:47     ` Paul Emsley
  0 siblings, 0 replies; 29+ messages in thread
From: Paul Emsley @ 2022-06-23 17:47 UTC (permalink / raw)
  To: guile-user


On 23/06/2022 14:30, Dr. Arne Babenhauserheide wrote:
> Ognen Duzlevski <maketo@sdf.org> writes:
>
>> Matias Jose Seco Baccanelli <matias_jose_seco@autoproduzioni.net> writes:
>>> Isn't a cool mix the functional approach of Guile and the modular one
>>> of Microkernel ? (and loads of more features i suppose!)
>> What I think would be easier to do is embed Scheme inside an OS kernel....
> With the Hurd you reduce the scope of what is the kernel, so Scheme can
> do lots of jobs usually reserved for lower-level languages. You could
> for example write your complete filesystem or networking layer in
> Scheme.


FWIW, some time ago I wrote a version of "top" for the Hurd (it didn't 
have one) using Guile (1.3 maybe?) and libps. It may be possible to find 
it with some searching (not tried).


Paul.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23 15:38   ` Nala Ginrut
@ 2022-06-23 22:03     ` Dr. Arne Babenhauserheide
  2022-06-24  1:12       ` Nala Ginrut
  2022-06-24  3:27       ` Ognen Duzlevski
  0 siblings, 2 replies; 29+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-06-23 22:03 UTC (permalink / raw)
  To: Nala Ginrut; +Cc: Matias Jose Seco Baccanelli, guile-user

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]


Nala Ginrut <nalaginrut@gmail.com> writes:
> Many folks shared great Scheme for lower-level. I think I have to clarify
> that I agree that Scheme is good for low-level, depends on implementation.
> But we are talking about Guile, and Guile was not designed for that
> purpose, it's dedicated to extend C program, so the better choice is to
> extend a C microkernel with Guile. That is what it was designed for,
> originally.

In recent years the scope of Guile widened in that respect, so it’s very
suited to implement many more parts of the system than it was with Guile
1.x — with Guile 3 it starts to compete in performance.

It might be suitable for many parts of the kernel nowadays.

And the Hurd is a good way to get low level with much fewer risks than
Linux kernel hacking.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23 22:03     ` Dr. Arne Babenhauserheide
@ 2022-06-24  1:12       ` Nala Ginrut
  2022-06-24  5:45         ` Dr. Arne Babenhauserheide
  2022-06-24  7:01         ` Jean Abou Samra
  2022-06-24  3:27       ` Ognen Duzlevski
  1 sibling, 2 replies; 29+ messages in thread
From: Nala Ginrut @ 2022-06-24  1:12 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide; +Cc: Matias Jose Seco Baccanelli, Guile User

Agreed, Guile's design was widened. But I think we are talking about
different "low-level", for Hurd, Guile can be used to write OS components,
say, filesystem. However, except for GNU Mach, most OS components are
implemented in userland, and Guile is good for that, this is what it's
designed for.
The "low-level" in my mind is to write GNU Mach part, which is not suitable
for Guile.

BTW, I think Hurd people inclined to call Hurd as "multi-server OS", so
when we talk about microkernel, I was thinking about something like GNU
Mach or L4. :-)

Best regards.

On Fri, Jun 24, 2022, 06:08 Dr. Arne Babenhauserheide <arne_bab@web.de>
wrote:

>
> Nala Ginrut <nalaginrut@gmail.com> writes:
> > Many folks shared great Scheme for lower-level. I think I have to clarify
> > that I agree that Scheme is good for low-level, depends on
> implementation.
> > But we are talking about Guile, and Guile was not designed for that
> > purpose, it's dedicated to extend C program, so the better choice is to
> > extend a C microkernel with Guile. That is what it was designed for,
> > originally.
>
> In recent years the scope of Guile widened in that respect, so it’s very
> suited to implement many more parts of the system than it was with Guile
> 1.x — with Guile 3 it starts to compete in performance.
>
> It might be suitable for many parts of the kernel nowadays.
>
> And the Hurd is a good way to get low level with much fewer risks than
> Linux kernel hacking.
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein,
> ohne es zu merken.
> draketo.de
>


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23 22:03     ` Dr. Arne Babenhauserheide
  2022-06-24  1:12       ` Nala Ginrut
@ 2022-06-24  3:27       ` Ognen Duzlevski
  2022-06-24 21:24         ` Dr. Arne Babenhauserheide
  1 sibling, 1 reply; 29+ messages in thread
From: Ognen Duzlevski @ 2022-06-24  3:27 UTC (permalink / raw)
  To: guile-user


"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> [[PGP Signed Part:Undecided]]
>
> And the Hurd is a good way to get low level with much fewer risks than
> Linux kernel hacking.

I considered embedding a scheme interpreter into a kernel for fun (!)
but even then (non-commercial interest), I only thought of kernels that
are actually used by others ;)



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-23  9:01   ` Ricardo G. Herdt
@ 2022-06-24  5:40     ` Dr. Arne Babenhauserheide
  0 siblings, 0 replies; 29+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-06-24  5:40 UTC (permalink / raw)
  To: Ricardo G. Herdt; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]


"Ricardo G. Herdt" <r.herdt@posteo.de> writes:

> Never tried it myself, but in case you are interested in exploring
> Scheme for this kind of development, check Loko Scheme, which runs on
> bare-metal and is developed to be a "platform for application and
> operating system development":
>
> https://scheme.fail/
>
> There is also a #loko channel on libera.

And loko is crazy fast. See https://ecraven.github.io/r7rs-benchmarks/

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-24  1:12       ` Nala Ginrut
@ 2022-06-24  5:45         ` Dr. Arne Babenhauserheide
  2022-06-24  7:01         ` Jean Abou Samra
  1 sibling, 0 replies; 29+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-06-24  5:45 UTC (permalink / raw)
  To: Nala Ginrut; +Cc: Matias Jose Seco Baccanelli, Guile User

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]


Nala Ginrut <nalaginrut@gmail.com> writes:

> Agreed, Guile's design was widened. But I think we are talking about
> different "low-level", for Hurd, Guile can be used to write OS
> components, say, filesystem. However, except for GNU Mach, most OS
> components are implemented in userland, and Guile is good for that,
> this is what it's designed for. The "low-level" in my mind is to write
> GNU Mach part, which is not suitable for Guile.

Ah, there’s you’re right.

Though the loko linked by Ricardo sounds interesting. The license is
AGPL compatible.

And the tagline is neat: “Give it some RAM and a supported machine, and
it gives you a REPL.”

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-24  1:12       ` Nala Ginrut
  2022-06-24  5:45         ` Dr. Arne Babenhauserheide
@ 2022-06-24  7:01         ` Jean Abou Samra
  2022-06-24  7:41           ` Dr. Arne Babenhauserheide
  2022-06-24 12:42           ` Nala Ginrut
  1 sibling, 2 replies; 29+ messages in thread
From: Jean Abou Samra @ 2022-06-24  7:01 UTC (permalink / raw)
  To: Nala Ginrut
  Cc: Dr. Arne Babenhauserheide, Matias Jose Seco Baccanelli, Guile User



> Le 24 juin 2022 à 03:13, Nala Ginrut <nalaginrut@gmail.com> a écrit :
> 
> Agreed, Guile's design was widened.


Let’s be honest: it wasn’t widened, but shifted. I don’t think today’s Guile is a good fit for an extension language.

Regards,
Jean



> But I think we are talking about
> different "low-level", for Hurd, Guile can be used to write OS components,
> say, filesystem. However, except for GNU Mach, most OS components are
> implemented in userland, and Guile is good for that, this is what it's
> designed for.
> The "low-level" in my mind is to write GNU Mach part, which is not suitable
> for Guile.
> 
> BTW, I think Hurd people inclined to call Hurd as "multi-server OS", so
> when we talk about microkernel, I was thinking about something like GNU
> Mach or L4. :-)
> 
> Best regards.
> 
>> On Fri, Jun 24, 2022, 06:08 Dr. Arne Babenhauserheide <arne_bab@web.de>
>> wrote:
>> 
>> 
>> Nala Ginrut <nalaginrut@gmail.com> writes:
>>> Many folks shared great Scheme for lower-level. I think I have to clarify
>>> that I agree that Scheme is good for low-level, depends on
>> implementation.
>>> But we are talking about Guile, and Guile was not designed for that
>>> purpose, it's dedicated to extend C program, so the better choice is to
>>> extend a C microkernel with Guile. That is what it was designed for,
>>> originally.
>> 
>> In recent years the scope of Guile widened in that respect, so it’s very
>> suited to implement many more parts of the system than it was with Guile
>> 1.x — with Guile 3 it starts to compete in performance.
>> 
>> It might be suitable for many parts of the kernel nowadays.
>> 
>> And the Hurd is a good way to get low level with much fewer risks than
>> Linux kernel hacking.
>> 
>> Best wishes,
>> Arne
>> --
>> Unpolitisch sein
>> heißt politisch sein,
>> ohne es zu merken.
>> draketo.de
>> 




^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-24  7:01         ` Jean Abou Samra
@ 2022-06-24  7:41           ` Dr. Arne Babenhauserheide
  2022-06-25 14:35             ` Jean Abou Samra
  2022-06-24 12:42           ` Nala Ginrut
  1 sibling, 1 reply; 29+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-06-24  7:41 UTC (permalink / raw)
  To: Jean Abou Samra; +Cc: Nala Ginrut, Matias Jose Seco Baccanelli, Guile User

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]


Jean Abou Samra <jean@abou-samra.fr> writes:

>> Le 24 juin 2022 à 03:13, Nala Ginrut <nalaginrut@gmail.com> a écrit :
>> 
>> Agreed, Guile's design was widened.

> Let’s be honest: it wasn’t widened, but shifted. I don’t think today’s Guile is a good fit for an extension language.

Why? Which change caused it to not be good as extension language?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-24  7:01         ` Jean Abou Samra
  2022-06-24  7:41           ` Dr. Arne Babenhauserheide
@ 2022-06-24 12:42           ` Nala Ginrut
  1 sibling, 0 replies; 29+ messages in thread
From: Nala Ginrut @ 2022-06-24 12:42 UTC (permalink / raw)
  To: jean; +Cc: Dr. Arne Babenhauserheide, Matias Jose Seco Baccanelli, Guile User

Could elaborate on it?

On Fri, Jun 24, 2022, 15:01 Jean Abou Samra <jean@abou-samra.fr> wrote:

>
>
> Let’s be honest: it wasn’t widened, but shifted. I don’t think today’s
> Guile is a good fit for an extension language.
>
> Regards,
> Jean
>
>


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-24  3:27       ` Ognen Duzlevski
@ 2022-06-24 21:24         ` Dr. Arne Babenhauserheide
  0 siblings, 0 replies; 29+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-06-24 21:24 UTC (permalink / raw)
  To: Ognen Duzlevski; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]


Ognen Duzlevski <maketo@sdf.org> writes:

> I considered embedding a scheme interpreter into a kernel for fun (!)
> but even then (non-commercial interest), I only thought of kernels that
> are actually used by others ;)

There actually are people using the Hurd. Not many, but some. And with
Guix, the hurd is just a service definition away:

 (services (append
            (list
	     ; login to temporary hurd-vm via sudo herd start childhurd && ssh root@localhost -p 10022
             (service hurd-vm-service-type
                      (hurd-vm-configuration
                       (options '("--snapshot" "-cpu host"))
                       (disk-size (* 30 (expt 2 30))) ;30G
                       (memory-size 8192)))             ;8192MiB
;; ... other services ...
)))

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-24  7:41           ` Dr. Arne Babenhauserheide
@ 2022-06-25 14:35             ` Jean Abou Samra
  2022-06-26  6:22               ` Dr. Arne Babenhauserheide
  2022-06-26 10:37               ` Nala Ginrut
  0 siblings, 2 replies; 29+ messages in thread
From: Jean Abou Samra @ 2022-06-25 14:35 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide, Nala Ginrut
  Cc: Matias Jose Seco Baccanelli, Guile User



>  Le 24 juin 2022 à 09:45, Dr. Arne Babenhauserheide 
> <arne_bab@web.de> a écrit :
> 
>  
>  Jean Abou Samra <jean@abou-samra.fr> writes:
> 
>>>>  Le 24 juin 2022 à 03:13, Nala Ginrut <nalaginrut@gmail.com> a 
>>>> écrit :
>>> 
>>>  Agreed, Guile's design was widened.
> 
>>  Let’s be honest: it wasn’t widened, but shifted. I don’t 
>> think today’s Guile is a good fit for an extension language.
> 
>  Why? Which change caused it to not be good as extension language?



(Also replying to Nala.) On the one hand, you have Guile without 
compiled
bytecode, which is slow to run, and more importantly painful to use
because there are no error locations and often no function names in
error messages. On the other hand, Guile with bytecode takes compilation
time, which is an impediment in applications where it is merely being
used as a language that is practical to use for small extensions to an
existing program, without a need for optimized code. It forces you to
recompile even if you just touched one file, since otherwise it emits
;;; messages about outdated .go files that create noise and/or affect
correctness. The compilation is impractical to set up when interfacing
with C if your main function is on the C side since compiling is started
from the Scheme side. There is no dependency tracking, so you need to
recompile everything whenever you change one file, which does not 
encourage
quick experiments. Bytecode is fussy to integrate in installers: when 
the user
unpacks an archive, you need to ensure that the .go files are unpacked
after the .scm files, otherwise Guile will consider them outdated. I
could list more …

As a developer on one of the main applications extended with Guile in
existence (LilyPond), I would not recommend Guile to anyone looking
for an extension language for a new application today.

Sorry for not exactly bringing enthusiasm to this otherwise interesting
thread.

Best regards,
Jean









^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-25 14:35             ` Jean Abou Samra
@ 2022-06-26  6:22               ` Dr. Arne Babenhauserheide
  2022-06-26  7:55                 ` Ricardo Wurmus
  2022-06-28 22:23                 ` Jean Abou Samra
  2022-06-26 10:37               ` Nala Ginrut
  1 sibling, 2 replies; 29+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-06-26  6:22 UTC (permalink / raw)
  To: Jean Abou Samra; +Cc: Nala Ginrut, Matias Jose Seco Baccanelli, Guile User

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]


Jean Abou Samra <jean@abou-samra.fr> writes:
> (Also replying to Nala.) On the one hand, you have Guile without
> compiled
> bytecode, which is slow to run, and more importantly painful to use
> because there are no error locations and often no function names in
> error messages. On the other hand, Guile with bytecode takes compilation
> time, which is an impediment in applications where it is merely being
> used as a language that is practical to use for small extensions to an
> existing program, without a need for optimized code. It forces you to
> recompile even if you just touched one file, since otherwise it emits
> ;;; messages about outdated .go files that create noise and/or affect
> correctness. The compilation is impractical to set up when interfacing
> with C if your main function is on the C side since compiling is started
> from the Scheme side. There is no dependency tracking, so you need to
> recompile everything whenever you change one file, which does not
> encourage
> quick experiments. Bytecode is fussy to integrate in installers: when
> the user
> unpacks an archive, you need to ensure that the .go files are unpacked
> after the .scm files, otherwise Guile will consider them outdated. I
> could list more …

Please do! I’ve been trying to get a concrete list for issues hurting
Lilypond for a long time.

To summarize what I understood so far (with notes):

- The compilation-messages (I hate them; these also hurt when writing
  interactive utilities for the command-line, and I have too many
  half-working fixes in script files to still be comfortable; I think I
  once had a fix in configuration, but I lost it again — or maybe I had
  just hacked Guile)

- No dependency tracking for the explicit compilation, so changes to
  Guile-code used elsewhere require an expensive re-compilation step,
  even though compile-times are just what you want to avoid with a
  scripting language ⇒ auto-compilation should just work and be
  *silent*. Could this be fixed with a tool that recovers those
  dependencies from Scheme-files? Something like
  ./list-dependent-files.scm --start foo.scm bar.scm baz.scm moo.scm goo.scm
  ⇒ bar.scm
    baz.scm

> Sorry for not exactly bringing enthusiasm to this otherwise interesting
> thread.

Don’t worry. I asked, and I’m glad you answered. There might be things
that cannot be fixed, but I have not yet seen one here.

Though I don’t want to give false hope: I am not a core developer, so I
cannot promise fast fixes. I can only promise that I will help pushing
Guile more into the direction that Lilypond needs.

Because for me, Lilypond is one of the most important tools that use
Guile. I use several Guile-using tools nowadays, but the only one I
could really not do without is Lilypond.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-26  6:22               ` Dr. Arne Babenhauserheide
@ 2022-06-26  7:55                 ` Ricardo Wurmus
  2022-06-26  8:32                   ` Dr. Arne Babenhauserheide
  2022-06-28 22:23                 ` Jean Abou Samra
  1 sibling, 1 reply; 29+ messages in thread
From: Ricardo Wurmus @ 2022-06-26  7:55 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide
  Cc: Jean Abou Samra, Nala Ginrut, Matias Jose Seco Baccanelli, guile-user


"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> - The compilation-messages (I hate them; these also hurt when writing
>   interactive utilities for the command-line, and I have too many
>   half-working fixes in script files to still be comfortable; I think I
>   once had a fix in configuration, but I lost it again — or maybe I had
>   just hacked Guile)

I use compilation (of Wisp) in the GWL and I silence output while
compiling by redirecting the current-error-port / current-output-port.

-- 
Ricardo



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-26  7:55                 ` Ricardo Wurmus
@ 2022-06-26  8:32                   ` Dr. Arne Babenhauserheide
  0 siblings, 0 replies; 29+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-06-26  8:32 UTC (permalink / raw)
  To: Ricardo Wurmus
  Cc: Jean Abou Samra, Nala Ginrut, Matias Jose Seco Baccanelli, guile-user

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]


Ricardo Wurmus <rekado@elephly.net> writes:

> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
>> - The compilation-messages (I hate them; these also hurt when writing
>>   interactive utilities for the command-line, and I have too many
>>   half-working fixes in script files to still be comfortable; I think I
>>   once had a fix in configuration, but I lost it again — or maybe I had
>>   just hacked Guile)
>
> I use compilation (of Wisp) in the GWL and I silence output while
> compiling by redirecting the current-error-port / current-output-port.

Those are my half-working fixes, too :-)

But from time to time I have a real error in a file and don’t get the
compilation messages (like "using unbound variable"). That’s why I think
that they are only half-working.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-25 14:35             ` Jean Abou Samra
  2022-06-26  6:22               ` Dr. Arne Babenhauserheide
@ 2022-06-26 10:37               ` Nala Ginrut
  2022-06-28 22:30                 ` Jean Abou Samra
  1 sibling, 1 reply; 29+ messages in thread
From: Nala Ginrut @ 2022-06-26 10:37 UTC (permalink / raw)
  To: Jean Abou Samra
  Cc: Dr. Arne Babenhauserheide, Matias Jose Seco Baccanelli, Guile User

OK, let's face the issues, I encountered similar problems like what you
described.

1. To avoid the irritating compiling message, I have to use parameters to
rebind current-error-port.

2. Sometimes folks compile the Guile code and installed it in a wrong load
path, so when you run it, it will auto compile everthing again.

3. The debug information seems broken for a long time, it's not good to
trace the error. But I don't think it's because of the design of Guile,
it's broken when Guile had upgraded the VM implementation. It was good
before that.

4. For quick experiment attempt you described, I confess I have no better
idea. But it's good to hear your experiences.

Best regaeds.


On Sat, Jun 25, 2022, 22:36 Jean Abou Samra <jean@abou-samra.fr> wrote:

>
>
> >  Le 24 juin 2022 à 09:45, Dr. Arne Babenhauserheide
> > <arne_bab@web.de> a écrit :
> >
> >  
> >  Jean Abou Samra <jean@abou-samra.fr> writes:
> >
> >>>>  Le 24 juin 2022 à 03:13, Nala Ginrut <nalaginrut@gmail.com> a
> >>>> écrit :
> >>>
> >>>  Agreed, Guile's design was widened.
> >
> >>  Let’s be honest: it wasn’t widened, but shifted. I don’t
> >> think today’s Guile is a good fit for an extension language.
> >
> >  Why? Which change caused it to not be good as extension language?
>
>
>
> (Also replying to Nala.) On the one hand, you have Guile without
> compiled
> bytecode, which is slow to run, and more importantly painful to use
> because there are no error locations and often no function names in
> error messages. On the other hand, Guile with bytecode takes compilation
> time, which is an impediment in applications where it is merely being
> used as a language that is practical to use for small extensions to an
> existing program, without a need for optimized code. It forces you to
> recompile even if you just touched one file, since otherwise it emits
> ;;; messages about outdated .go files that create noise and/or affect
> correctness. The compilation is impractical to set up when interfacing
> with C if your main function is on the C side since compiling is started
> from the Scheme side. There is no dependency tracking, so you need to
> recompile everything whenever you change one file, which does not
> encourage
> quick experiments. Bytecode is fussy to integrate in installers: when
> the user
> unpacks an archive, you need to ensure that the .go files are unpacked
> after the .scm files, otherwise Guile will consider them outdated. I
> could list more …
>
> As a developer on one of the main applications extended with Guile in
> existence (LilyPond), I would not recommend Guile to anyone looking
> for an extension language for a new application today.
>
> Sorry for not exactly bringing enthusiasm to this otherwise interesting
> thread.
>
> Best regards,
> Jean
>
>
>
>
>
>
>


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-26  6:22               ` Dr. Arne Babenhauserheide
  2022-06-26  7:55                 ` Ricardo Wurmus
@ 2022-06-28 22:23                 ` Jean Abou Samra
  1 sibling, 0 replies; 29+ messages in thread
From: Jean Abou Samra @ 2022-06-28 22:23 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide; +Cc: Guile User

Hi,

Le 26/06/2022 à 08:22, Dr. Arne Babenhauserheide a écrit :
> Jean Abou Samra <jean@abou-samra.fr> writes:
>> (Also replying to Nala.) On the one hand, you have Guile without
>> compiled
>> bytecode, which is slow to run, and more importantly painful to use
>> because there are no error locations and often no function names in
>> error messages. On the other hand, Guile with bytecode takes compilation
>> time, which is an impediment in applications where it is merely being
>> used as a language that is practical to use for small extensions to an
>> existing program, without a need for optimized code. It forces you to
>> recompile even if you just touched one file, since otherwise it emits
>> ;;; messages about outdated .go files that create noise and/or affect
>> correctness. The compilation is impractical to set up when interfacing
>> with C if your main function is on the C side since compiling is started
>> from the Scheme side. There is no dependency tracking, so you need to
>> recompile everything whenever you change one file, which does not
>> encourage
>> quick experiments. Bytecode is fussy to integrate in installers: when
>> the user
>> unpacks an archive, you need to ensure that the .go files are unpacked
>> after the .scm files, otherwise Guile will consider them outdated. I
>> could list more …
> Please do! I’ve been trying to get a concrete list for issues hurting
> Lilypond for a long time.
>
> To summarize what I understood so far (with notes):
>
> - The compilation-messages (I hate them; these also hurt when writing
>    interactive utilities for the command-line, and I have too many
>    half-working fixes in script files to still be comfortable; I think I
>    once had a fix in configuration, but I lost it again — or maybe I had
>    just hacked Guile)
>
> - No dependency tracking for the explicit compilation, so changes to
>    Guile-code used elsewhere require an expensive re-compilation step,
>    even though compile-times are just what you want to avoid with a
>    scripting language ⇒ auto-compilation should just work and be
>    *silent*. Could this be fixed with a tool that recovers those
>    dependencies from Scheme-files? Something like
>    ./list-dependent-files.scm --start foo.scm bar.scm baz.scm moo.scm goo.scm
>    ⇒ bar.scm
>      baz.scm


Add:

- There is no simple way to byte-compile when the main
   function is in C(++). See the thread
https://lists.gnu.org/archive/html/guile-user/2022-02/msg00129.html
   about this one.

- A smarter strategy than looking at modification dates should
   be found for deciding when a bytecode file is outdated, for
   example storing a hash of the source file in the bytecode.
   This should avoid the problems with extracting and installing.

- Unless compilation is made really fast and can be used on-the-fly
   for large code chunks, interpreted code should be able to give
   meaningful error locations and backtraces.



>> Sorry for not exactly bringing enthusiasm to this otherwise interesting
>> thread.
> Don’t worry. I asked, and I’m glad you answered. There might be things
> that cannot be fixed, but I have not yet seen one here.



Sure, everything can be fixed with enough time and motivation.
We're in the free software world after all, and I have no
problem with tinkering with Guile myself to fix issues that
affect me. The problem, though, is getting the patches in Guile
after they have been produced. For example, exactly three months
ago I posted a patch fixing docstrings in curried definitions
<https://lists.gnu.org/archive/html/guile-devel/2022-03/msg00024.html>
which would fix a problem that prevents functions defined using
curried define from being listed in LilyPond's autogenerated
documentation. So far the patch has not received a reply. The
same holds for most patches being posted. This is the single one
thing that saddens me most about Guile, before all the technical
issues. Quite frankly, Guile is on the right path to abandonware.
I've said this before and I hoped the discussion
<https://lists.gnu.org/archive/html/guile-devel/2021-12/msg00012.html>
would lead to some change, but it didn't seem to happen.


> Though I don’t want to give false hope: I am not a core developer, so I
> cannot promise fast fixes. I can only promise that I will help pushing
> Guile more into the direction that Lilypond needs.


In my view, the most significant direction that LilyPond
needs is a situation where maintenance fixes can make it
to the main branch.


Thanks,
Jean




^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Curiosity: Microkernel implemented in Guile ?
  2022-06-26 10:37               ` Nala Ginrut
@ 2022-06-28 22:30                 ` Jean Abou Samra
  0 siblings, 0 replies; 29+ messages in thread
From: Jean Abou Samra @ 2022-06-28 22:30 UTC (permalink / raw)
  To: Nala Ginrut; +Cc: Dr. Arne Babenhauserheide, Guile User

Le 26/06/2022 à 12:37, Nala Ginrut a écrit :
> OK, let's face the issues, I encountered similar problems like what 
> you described.
>
> 1. To avoid the irritating compiling message, I have to use parameters 
> to rebind current-error-port.

OK, interesting to know, thanks.

> 2. Sometimes folks compile the Guile code and installed it in a wrong 
> load path, so when you run it, it will auto compile everthing again.


This one is a real problem, but not one we're facing in LilyPond.

> 3. The debug information seems broken for a long time, it's not good 
> to trace the error. But I don't think it's because of the design of 
> Guile, it's broken when Guile had upgraded the VM implementation. It 
> was good before that.


Yes. I remember seeing the bug on debbugs, but I can't seem to find it 
right now. I recall that Mark H. Weaver commented that interpreted code 
went through primitive-eval on traditional expressions (not syntax objects).


Best,
Jean




^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2022-06-28 22:30 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-23  6:11 Curiosity: Microkernel implemented in Guile ? Matias Jose Seco Baccanelli
2022-06-23  6:57 ` Mikael Djurfeldt
2022-06-23  9:01   ` Ricardo G. Herdt
2022-06-24  5:40     ` Dr. Arne Babenhauserheide
2022-06-23  7:02 ` Dr. Arne Babenhauserheide
2022-06-23  7:32 ` zimoun
2022-06-23  7:34 ` Maxime Devos
2022-06-23  9:13 ` pukkamustard
2022-06-23 10:09 ` Nala Ginrut
2022-06-23 11:22   ` Maxime Devos
2022-06-23 15:38   ` Nala Ginrut
2022-06-23 22:03     ` Dr. Arne Babenhauserheide
2022-06-24  1:12       ` Nala Ginrut
2022-06-24  5:45         ` Dr. Arne Babenhauserheide
2022-06-24  7:01         ` Jean Abou Samra
2022-06-24  7:41           ` Dr. Arne Babenhauserheide
2022-06-25 14:35             ` Jean Abou Samra
2022-06-26  6:22               ` Dr. Arne Babenhauserheide
2022-06-26  7:55                 ` Ricardo Wurmus
2022-06-26  8:32                   ` Dr. Arne Babenhauserheide
2022-06-28 22:23                 ` Jean Abou Samra
2022-06-26 10:37               ` Nala Ginrut
2022-06-28 22:30                 ` Jean Abou Samra
2022-06-24 12:42           ` Nala Ginrut
2022-06-24  3:27       ` Ognen Duzlevski
2022-06-24 21:24         ` Dr. Arne Babenhauserheide
2022-06-23 12:13 ` Ognen Duzlevski
2022-06-23 13:30   ` Dr. Arne Babenhauserheide
2022-06-23 17:47     ` Paul Emsley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).