Re: how to write services
Hi Maxime, On 18-06-2022 14:23, Maxime Devos wrote: indieterminacy schreef op za 18-06-2022 om 13:53 [+0200]: Additionally, based upon a decent demonstration on LMDB, I realised that my annotation system makes it more feasible to adapt documents into LDIF database-like-files (is that the correct terminology Maxime?) - potentially turning each document into an LDAP ready database. If your asking me, I don't know. What's LDAP doing here? Isn't LDAP about authenticating users, which doesn't seem relevant to the documentation effort? If this is about databases: is the exact database format relevant, or would any do -- e.g., Guix uses SQLite in some places, will SQLite do? The prod was a little tongue in cheek, more of a nod to the thread discussing file-like aspects of computing. I have no focus on LDAP nor authentification per se (though my own annotations would be able to map some of the parameters. My understanding is that LDIF can hold keys and values and as such is capable of representing concepts (or at least pointing to them). As such I fancy a good 'ol hack. In any case I shall be experimenting and breaking things and I should be treated at this point as speculating. I have no desire for substituting existing Guix databases - though I would contend that knowledge-management has different requirements and needs than system-maangement or coding. As such different toiling and tooling is advisable. And the text above seems about databases and RDF, but there appear to be missing some things: * what's the RDF and database for? As I understand it, it's for something about documentation and terminology, but currently it's super vague. * what stuff goes in the RDF and database, and what documents are you speaking of? The Guix manual? All the package definitions, to use them as examples? The mails in the ML? Manually written things? Likewise, how is this database written or generated? * How will this RDF be used? I mean, RDF can be flexible (see e.g. Wikidata), but someone has to actually write some applications that make use of the information, otherwise the fancy RDF is useless. * How is the RDF an improvement on the TeXinfo documentation? I guess I'm missing something important here, but I prefer reading TeXinfo documentation over RDF. Greetings, Maxime. The RDF is something experimental based upon feedback from my own project. Suppose we return to Brian's (apt) analogy concerning buildings and building materials: I would hazard that there would exist chains across triples which would permeate from the concept stages of a building down to the point whereby nails are contextualised (including with regards to safety; purchasing; type; context; implementation). Guix users should be able to build and resolve without the expertise of all layers and abstractions pertinent to Guile and our community. At my end, Ive spent a considerable time creating loose annotations - which I inject everywhere. Here is an example of task orientated annotations operating within my Emacs config: https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/init.el#L138 and for policy positions: https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/init.el#L155 These annotations recurse through my entire system, for instance operating as directory prefixes for specific concerns: https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/rqr_organise https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/iq_policy My own bundle of knowledge repos can be found just from searching for '3q' references within my system. Some can be found here (I will upload some Guix repos eventually) https://git.sr.ht/~indieterminacy/?search=3q Feel free to root around for approaches I have been taking to document and plan in modern ways. Similarly, these annotations can operate literate-programming style within comments. The fact that I can operate within Emacs-Hyperbole's Koutliner (block orientated) filetype to provide hierarchy and hyperlinking keeps me in a very terse and tactile state everywhere. Currently I am able to grok my system with ease. Ive been advised that outputting the interpretation of these files into RDF would be advantageous to make use of the graph orientated and folksonomic qualities of Icebreaker's approach. FYI, I did a Fosdem talk. About 21 mins in some of the concepts coalesce into an area more pertinent with regards to RDF themes https://fosdem.org/2022/schedule/event/minimalsyntaxes/ Im hoping that RDF can mitigate some of the chaos from users personal behaviours. My work operates more akin to body-language and philology as opposed to more classical approaches to computer-programming and computer-science. I personally use my annotation system everywhere and adapt it for my own needs. I think of it like
Re: how to write services
indieterminacy schreef op za 18-06-2022 om 13:53 [+0200]: > Additionally, based upon a decent demonstration on LMDB, I realised that > my annotation system makes it more feasible to adapt documents into LDIF > database-like-files (is that the correct terminology Maxime?) - > potentially turning each document into an LDAP ready database. If your asking me, I don't know. What's LDAP doing here? Isn't LDAP about authenticating users, which doesn't seem relevant to the documentation effort? If this is about databases: is the exact database format relevant, or would any do -- e.g., Guix uses SQLite in some places, will SQLite do? And the text above seems about databases and RDF, but there appear to be missing some things: * what's the RDF and database for? As I understand it, it's for something about documentation and terminology, but currently it's super vague. * what stuff goes in the RDF and database, and what documents are you speaking of? The Guix manual? All the package definitions, to use them as examples? The mails in the ML? Manually written things? Likewise, how is this database written or generated? * How will this RDF be used? I mean, RDF can be flexible (see e.g. Wikidata), but someone has to actually write some applications that make use of the information, otherwise the fancy RDF is useless. * How is the RDF an improvement on the TeXinfo documentation? I guess I'm missing something important here, but I prefer reading TeXinfo documentation over RDF. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: how to write services
Hello Brian, On 16-06-2022 15:09, Brian Cully via "Development of GNU Guix and the GNU System distribution." wrote: caton...@gmail.com writes: I asked for indications about the process (what magic to use in the REPL) My experience with Guix, in general, is that the REPL isn't particularly useful for any task beyond very simple testing (eg, what are the contents of ‘%base-services’). It's a shame, but I suspect it's like this because it's hard to make it more functional, and there are more important problems to work on. Even though I would much prefer to do almost all work with a REPL, I have not invested the effort into figuring it out because I don't have the time or expertise, currently. I can't fault anyone else for making similar choices. This should be covered in the cookbook I agree. The cookbook could use a lot of work. Guix's documentation suffers in the middle ranges. There's a lot of very high level overview, and all the low level bits are reasonably documented, but there's very little on how to integrate them. Personally, Im somebody who requires examples to hack off. As many as possible, to compare and contrast concepts and feed my imagination. I wish I could reach for any API to explore and extrapolate with the same ease as I do with a dictionary. Probably a cognitive failing from me getting into coding so late in life. As with many things, I rely on conversational models to wash over me, so MLs have been useful as filling gaps - though I have to be patient waiting for solutions and ideals to reveal themselves over time. The Guix mailing lists are hugely important to serve as the bridge between higher and lower level concepts. This method may not be optimal to or known by some hoping to users hoping to utilise Guix further however. Similarly, Im sure IRC/Matrix is useful, though I find the volume of the official (Matrix?) room to be like a firehose with its volume and too much to passively observe. If we were building a house, it'd be like having instructions that say: our house is made out of rooms. Then being given a bill of materials for all the different types of nails, boards, etc that can be used to build a house. There's no (or almost no) instructions for how to use those parts to build the shepherd service room, or how to connect the activation plumbing, etc. Unfortunately, those are the instructions that are most important, I think. I like the analogy. I feel that there is an information-governance issue in terms of competencies, knowledge and requirements not fully intersecting. Its not only because of the scale of the Guix community and as you mention the weaker middle layer but problems of time and perspective making it hard for specific solutions to find troubled users with minimal costs. In many respects its not only a problem of documenting and publishing - there needs to be something in place to help orchestrate connections in a way akin to pollination. Like the moribund efficacy of forums such as GitHub Issues, I do feel that the 'classic' model of SEO based search does not serve our individual or collective requirements. I have been nudged into considering RDF more proactively, it would be super if Guix related knowledge could be represented in a semantic form, as it could be that triples can serve to provide 'knowledge-corridors', which connect up aspects of the ecosystem in ways unintended by contributors. I have been keeping notes on my process of learning Guix in the hopes of starting something along these lines, but I'm not sure I'll ever have the time to get around to it; and I'm not much of a writer, besides. You are a cogent and thoughtful writer so please write more and tell people when you make progress! My own research project, Icebreaker, has focused on trying to utilise GemText and augment it with minimal syntaxes to support domains such as knowledge-management and kanban boards. GemText's minimal syntax could allow you to write your thoughts down unimpeded and can be interpreted with ease. See Genenetwork's own approach to such concepts to see how such habits can build out over time: https://github.com/genenetwork/gn-gemtext-threads Midway through my NLNet grant (once a move past a hospice related issue), Ill be integrating two interpreters covering formats (GemText and Koutliner) and my own annotation system (Qiuy). https://git.sr.ht/~indieterminacy/1q20hqh_kq_parsing_gemtext https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_glean For me, this has put me in a situation whereby I can annotate anywhere and soon I shall have a graph of resources to inspect and extrapolate. To aid others comprehension and interoperability I shall be trying to map my opaque seeming annotation syntax into RDF, hopefully something positive can come from that phase. Additionally, based upon a decent demonstration on LMDB, I realised that my annotation system makes it more feasible to adapt
Re: how to write services (was: Re: Teams)
caton...@gmail.com writes: I asked for indications about the process (what magic to use in the REPL) My experience with Guix, in general, is that the REPL isn't particularly useful for any task beyond very simple testing (eg, what are the contents of ‘%base-services’). It's a shame, but I suspect it's like this because it's hard to make it more functional, and there are more important problems to work on. Even though I would much prefer to do almost all work with a REPL, I have not invested the effort into figuring it out because I don't have the time or expertise, currently. I can't fault anyone else for making similar choices. This should be covered in the cookbook I agree. The cookbook could use a lot of work. Guix's documentation suffers in the middle ranges. There's a lot of very high level overview, and all the low level bits are reasonably documented, but there's very little on how to integrate them. If we were building a house, it'd be like having instructions that say: our house is made out of rooms. Then being given a bill of materials for all the different types of nails, boards, etc that can be used to build a house. There's no (or almost no) instructions for how to use those parts to build the shepherd service room, or how to connect the activation plumbing, etc. Unfortunately, those are the instructions that are most important, I think. I have been keeping notes on my process of learning Guix in the hopes of starting something along these lines, but I'm not sure I'll ever have the time to get around to it; and I'm not much of a writer, besides. In fact Tryton modules are not python modules and there's a patch modifying how Tryton retrieves its modules in Guix Yet there's no service for Tryton This is the case for many packages. The good news(?) is that you can create your services your operating system config, and if you can get them working acceptably, send a patch. I think the friction on how to write a service is not in the semantics involved It's more menial See above: there's no documentation for assembly. Everything I've learned was from studying the source. As I'm writing this, I noticed someone replied to my toot (here https://tines.spork.org/objects/a2ff7376-c9a2-4bbd-9307-a5374571edb4 ) as you can see, they also noticed a difference in the experience between creating home services and system services I wasn't following this thread at the time, and didn't know whether you were talking about shepherd services or not. In terms of shepherd services, yes, there's quite a difference (maybe it would be a good idea to define a generic service type, akin to ‘home-shepherd-service-type’ that only extends the ‘shepherd-root-service-type’ with a shepherd service?). As I said there, if you have questions, feel free to ask! I may not be able to write the cookbook/how-to that I want to, but I can try to answer questions and share what little knowledge I do have with a fellow neophyte. However, for the types of services you'd add to the ‘services’ slot of the home/operating-system config, I don't think there is much of a difference; or maybe none at all. Guix is being successful, these days but that's an exception in the free software world and more so in the GNU world I'm happy that Guix is growing, and more people are using it and adding to it (I'm a recent adopter, too!). But I think it's still a niche distribution, and it shows in things like the documentation, the builds breaking, old or broken packages, etc. I want to be very clear on this point, though: I don't blame anyone for this, and I don't mean to downplay anyone's work because of these problems. Creating and maintaining a distribution, especially one as different as Guix, is a tremendous amount of work, and it's frankly incredible how well Guix does on such a small core crew. It's simply impossible to have the same level of polish as a bigger, more established distribution, with an order of magnitude (or more) contributors. I have a job now (and it has to do with Odoo), I also train in a gym, I like to spend the free time I have on the beach (as it's evident from my presence on the fediverse) so I don't know it's not like I have any slots to assign to attempt this We're, all of us, in a similar situation, and we're few in number (relatively), with a lot of work to do. I think this explains the state of Guix more than anything else. -bjc
Re: how to write services (was: Re: Teams)
Blake Shaw schreef op do 16-06-2022 om 06:20 [+0700]: > But, perhaps it's just getting late and the matters are now & the > details are slipping my mind, but im starting to realize im unsure of > many examples of file-like objects that aren't a file? The email > where you responded re: packages was cut short, but it seemed to be > that you were saying that record-types *aren't* file-like, I wrote that a package record # is not a file (as it lacks a lot of operations and properties that would be expected of a package, such as 'stat', 'read', 'write', and a file name’. Likewise, the record type (!= an instance of the record type ) is not a file, but that's going rather meta. However, packages (not the package _type_, but packages) are definitely file-like, because when used in a G-exp with #$ or #+, Guix is able to automatically ‘lower’ it in the store (resulting in a /gnu/store/.../ file name). > when I had thought they are; I thought anything with simple means of > serialization could be considered file-like, > [...] It depends on the serialisation. Not any serialisable object can do, it must be an object that _Guix_ considers to be serialisable -- in Guix terminology, this is called a ‘lowerable’ (low-level terminology) or ‘file-like’ (high-level terminology, equivalent to ‘lowerable’ AFAICT) object. > Would anyone care to share an explanation of what is/is not a > file-like object in Guix? > Are fluids not considered file-like? They aren't, as they do not implement lowering. (Technically: they don't have a ‘define-gexp-ompiler’). > I had thought that would be a use case where this geneticity becomes > important. Why would one put a fluid in a G-exp? I suppose we could define what lowering is for fluids (probably: get the value of what's inside and lower that value), implement it in the Guix code and document it, and hence consider fluids to be file-like. I suppose that's all technically possible, though shouldn't it then be extended to SRFI-111 boxes, parameter objects, variable objects, promises and thunks as well? Where would we stop? And is this behaviour actually useful? > I remember when I first encountered gexps I thought, as FLOs didn't > seem to be files, they were either records or fluids. There is only a single mention of fluids in the manual (concerning %guile-for-build). The related concept of parameters is never used in (guix)G-expressions, (except for 'with-parameters’). So I fail to see where this could have come from. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: how to write services (was: Re: Teams)
caton...@gmail.com writes: > Ricardo, the general map of the concepts involved in conceiving a > service is useful > > But in my toot I asked for something different > > I asked for indications about the process (what magic to use in the > REPL) There is no REPL magic. I write the service in chunks that I *could* run separately (like the start command). The rest I just write, and then build a system with “guix system build” until it works. Your assumption that there’s some guarded secret knowledge is wrong. > as you can see, they also noticed a difference in the experience > between creating home services and system services > > While you somewhat downplayed that > > Now I want to be clear, here > > In the past I have misunderstood some of your contributions about > macros in Guile (that I had asked about) > > I came to terms with the fact that you're doing your best and in total > good faith, so I hope it's clear that's not what's happening today > > But I also hope you can see why I could get a bit frustrated with your > reply No, I don’t. I answered a vague question with what I hoped would be helpful. My bad. I won’t do it again. This is not the first time that my attempt to answer your question is just met with a barrage of criticism, so I won’t expose myself to this situation again. -- Ricardo
Re: how to write services (was: Re: Teams)
Il giorno mer, 15/06/2022 alle 17.01 +, Blake Shaw ha scritto: > > Catonano: > I think writing a home-service is much easier given that you don't > need to do produce an entire system generation before you find out > what you did wrong; I suspected something like this This is why I hypotized that a gradual passage with a Home service could be convenient Ricardo, the general map of the concepts involved in conceiving a service is useful But in my toot I asked for something different I asked for indications about the process (what magic to use in the REPL) if you prefer, I asked for something more menial Which buttons do I have to push (metaforically) ? As for the semantics involved in thinking a service, I feel I can work them out myself (to some extent) This should be covered in the cookbook I see there's a package for Tryton (that's a relative of Odoo) and the package definition for Tryton is quite sought after In fact Tryton modules are not python modules and there's a patch modifying how Tryton retrieves its modules in Guix Yet there's no service for Tryton I asked Hartmut (I remembered they were involved in this) and they declared their surrender in writing services (Here https://nerdculture.de/@kirschwipfel/108477739857485544 ) Maybe there's some cognitive friction about how to produce services ? This reminds me of an argument about Haskell I read Some "expert" haskellers are deeply involved in "plug ins" to the compiler that actually change the language and many haskellers with a lower level of proficiency are confused by this And this hampers the Haskell field as a whole Too bad I can't provide a pointer to this My point being that I think this is a case of curse of knowledge (mentioned here https://www.hillelwayne.com/post/learning-a-language/ ) I think the friction on how to write a service is not in the semantics involved It's more menial As an blueprint for what I mean, you can think of Smalltalk, the programming language There a famous implementation of Smalltalk called Squeak I played with Squeak myself, many years ago That's how I learned object orientation ,really The experience Squeak offers is NOT Posix based (thank God) A GNU implementation of Smalltalk also exists and it's totally Posix based (because of the unfortunate "GNU System" delusion) Do you think the GNU Smalltalk would have been as effective in teaching me object orientation ? I honestly doubt it yet the language is exactly the same because the problem is not the language, that is something people CAN work out themselves (roughly) The problem is the experience As I'm writing this, I noticed someone replied to my toot (here https://tines.spork.org/objects/a2ff7376-c9a2-4bbd-9307-a5374571edb4 ) as you can see, they also noticed a difference in the experience between creating home services and system services While you somewhat downplayed that Now I want to be clear, here In the past I have misunderstood some of your contributions about macros in Guile (that I had asked about) I came to terms with the fact that you're doing your best and in total good faith, so I hope it's clear that's not what's happening today But I also hope you can see why I could get a bit frustrated with your reply Guix is being successful, these days but that's an exception in the free software world and more so in the GNU world Guile is less exceptional in that it's suffering from its marginality and it has been doing so for several years now and I believe these cultural issues are part of why and they are threatening the whole user freedom movement Sorry if I went off on a tangent, I just feel a bit about this > it just depends on if you need your service initialized at startup > (system-services, globally defined and available prior to login) > rather than at login (home-services, per-user/locally defined). > > I'm not on Mastodon but feel free to send your service my way for > some help, I'm still a beginner but a second pair of eyes is always > nice to have. That's very kind of you, thank you I don't know if I'll ever attempt to write a service for Odoo Or for Tryton I have a job now (and it has to do with Odoo), I also train in a gym, I like to spend the free time I have on the beach (as it's evident from my presence on the fediverse) so I don't know it's not like I have any slots to assign to attempt this It's just that if the _process_ to write a service (home or system) was made explicit, I could have played with it in the few moments of grace
Re: how to write services (was: Re: Teams)
Thanks for the feedback, abelian groups are a good example because so many groups are abelian (fields etc). But, perhaps it's just getting late and the matters are now & the details are slipping my mind, but im starting to realize im unsure of many examples of file-like objects that aren't a file? The email where you responded re: packages was cut short, but it seemed to be that you were saying that record-types *aren't* file-like, when I had thought they are; I thought anything with simple means of serialization could be considered file-like, and that pseudofiles (/devs, /procs, etc) were also in the file-like category (which is apparently a misnomer on my part). Would anyone care to share an explanation of what is/is not a file-like object in Guix? Are fluids not considered file-like? I had thought that would be a use case where this geneticity becomes important. I remember when I first encountered gexps I thought, as FLOs didn't seem to be files, they were either records or fluids. It took me a good while to realize a file-like object is usually just a file, haha On Thu, Jun 16, 2022, 05:28 Maxime Devos wrote: > Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > > On the contrary, lets say I'm writing an intro book on CT. If I'm > > demonstrating something trivial, say the initial object, I'm not > > going to refer to it as "an initial-like object" for the sake of > > generality. > > Neither does Guix? If you're in a context where only the basic object > (in this case, your demonstration the initial object) is used, just > talk about the basic object. But in a later section where you > generalize things to ‘initial-like objects’ (whatever that would be in > CT, I don't know any CT), you talk about ‘initial-like objects’, not > ‘initial object and initial-like objects’. > > For an example from another domain, consider groups in algebra. > In group theory, we have e.g. the fundamental theorem on homomorphisms. > Wikipedia formulates this as: > > Given two groups G and H and a group homomorphism f : G → H, let K be a > normal subgroup in G and φ the natural surjective homomorphism G → G/K > (where G/K is the quotient group of G by K). If K is a subset of ker(f) > then there exists a unique homomorphism h: G/K → H such that f = h∘φ. > > An equivalent statement could be made by replacing ‘given a group’ by > ‘given an Abelian group or a group’: > > Given two Abelian groups or groups G and H and a group homomorphism f : > G → H, let K be an Abelian normal subgroup or normal subgroup in G and > φ the natural surjective homomorphism G → G/K (where G/K is the > quotient group of G by K). If K is a subset of ker(f) then there exists > a unique homomorphism h: G/K → H such that f = h∘φ.’ > > But why do such a pointless thing, wouldn't just talking about groups > instead of ‘Abelian groups or groups’ be much simpler? > > TBC: here ‘file-like object’ ≃ ‘group’ and ‘file’ = ‘Abelian group’. > > Greetings, > Maxime. >
Re: how to write services (was: Re: Teams)
Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > On the contrary, lets say I'm writing an intro book on CT. If I'm > demonstrating something trivial, say the initial object, I'm not > going to refer to it as "an initial-like object" for the sake of > generality. Neither does Guix? If you're in a context where only the basic object (in this case, your demonstration the initial object) is used, just talk about the basic object. But in a later section where you generalize things to ‘initial-like objects’ (whatever that would be in CT, I don't know any CT), you talk about ‘initial-like objects’, not ‘initial object and initial-like objects’. For an example from another domain, consider groups in algebra. In group theory, we have e.g. the fundamental theorem on homomorphisms. Wikipedia formulates this as: Given two groups G and H and a group homomorphism f : G → H, let K be a normal subgroup in G and φ the natural surjective homomorphism G → G/K (where G/K is the quotient group of G by K). If K is a subset of ker(f) then there exists a unique homomorphism h: G/K → H such that f = h∘φ. An equivalent statement could be made by replacing ‘given a group’ by ‘given an Abelian group or a group’: Given two Abelian groups or groups G and H and a group homomorphism f : G → H, let K be an Abelian normal subgroup or normal subgroup in G and φ the natural surjective homomorphism G → G/K (where G/K is the quotient group of G by K). If K is a subset of ker(f) then there exists a unique homomorphism h: G/K → H such that f = h∘φ.’ But why do such a pointless thing, wouldn't just talking about groups instead of ‘Abelian groups or groups’ be much simpler? TBC: here ‘file-like object’ ≃ ‘group’ and ‘file’ = ‘Abelian group’. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: how to write services (was: Re: Teams)
Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > > AFAIK no relation to GNU. > > I thought recalled hearing it used in relation to GNU/Linux. A quick > search > brings up this stackexchange discussion[1], which quotes the book > "Linux > Philosophy" with the following: > > #+begin_example > Whenever possible, Linux makes its components available via files or > objects > that look like files. Processes, devices, and network sockets are all > represented > by file-like objects, and can often be worked with using the same > utilities used > for regular files. > #+end_example > > So the contents of /proc are file-like objects, but AFAIK they > strictly aren't files > per-se, but representations of processes that take the shape of a > file at a > particular instance in time. > > [1] > https://unix.stackexchange.com/questions/416778/what-is-file-like-objects-in-linux From Guix and Guile's perspective, things in /proc are just (OS) files that happen to be dynamically generated. Devices are weird files that need a special I/O API, but still files). Some information on processes is available in files, but the process itself isn't a file. I would say that sockets (except for unix domain sockets) aren't files and are rather unlike files (you cannot copy, hardlink, mv, symlink or stat them, they don't have file names, they don't have an owner/group/...) -- the only similarity seems to be the basis on file descriptors and the possibility of read/write. However, you cannot save sockets in the store, so from Guix perspective even Unix domain sockets aren't file-like. Though good point about the potential confusing with Linux' notion of file-like objects! Greetings Maxime. signature.asc Description: This is a digitally signed message part
Re: how to write services (was: Re: Teams)
Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > > Something I dislike about the ‘file AND file-like objects’ > > construction > > is that it suggests that files and file-like objects are separate > > and > > are handled separately, whereas files (as in, 'local-file' or > > 'computed-file') are just another case of file-like objects to Guix > > (next to 'file-append', 'package', 'git-checkout', ...). > > Furthermore, > > usually file-like objects aren't files but more often they are > > packages. > > Going off the packages example, are they not often handled > differently? While I may want to (load "gnu/packages/base.scm"), > a file, Files can be loaded by Guile, yes. > a that I can work with , That's not a file, it's a package record. You ca > as a record I > will get an error if I've included (gnu packages base) in my module > and then try to invoke (load coreutils), although its defined. > > But I think i'm missing your point here. signature.asc Description: This is a digitally signed message part
Re: how to write services (was: Re: Teams)
Blake Shaw schreef op wo 15-06-2022 om 17:01 [+]:
> Thats very good advice and will be a useful guide in refactoring the
> parts of the system services documentation. I think in general, we
> need to find a nice middle ground between the extremely general and
> the immediately sensible, as I remember when I first got into guix
> 1.5 years ago, arriving at services left me very confused.
I don't doubt your confusal, though personally I'm confused on the
confusal and I think I would have been confused by ‘file AND file-like
object’. Even more so since we both come from a mathematical
background, where AFAICT this kind of terminology and Guix'
interpretation is standard.
> mathematics I'm a fellow appreciator of the power of generality (the
> extreme genericity of scheme and guix is why I'm here!), I also think
> if it doesn't obey strict linguistic rules it can antithetical to its
> original purpose.
I don't see what linguistic rule the term ‘file-like object’ does not
follow.
> For example, I remember being very confused about
> "file-like objects", for the simple reason that it wasn't "a file or
> file-like object". While this might come from a GNU terminological
> lineage i'm unaware of,
AFAIK no relation to GNU.
> my immediate reaction to trying to understand
> file-likeness is the simple rule that a semblance is strictly not
> what it resembles, and likeness qualifies semblance. It would be
> improper to place phones in a category of "phone-like objects",
> because the likeness assumes a distinction from the thing itself.
An object being ‘X-like’ merely means that it is like an X. This does
not imply it _isn't_ an X, only suggests that in some cases it might be
a non-X.
More concretely, to me phones resemble phones and are objects, so
phones are phone-like objects.
Summarised, to me semblance/similar/likeness is reflexive, I don't see
where the non-reflexivity would come from?
Something I dislike about the ‘file AND file-like objects’ construction
is that it suggests that files and file-like objects are separate and
are handled separately, whereas files (as in, 'local-file' or
'computed-file') are just another case of file-like objects to Guix
(next to 'file-append', 'package', 'git-checkout', ...). Furthermore,
usually file-like objects aren't files but more often they are
packages.
For a comparison, suppose we have a hierarchy of concepts, e.g.
{0}⊊ℕ⊊ℤ⊊ℚ⊊ℝ⊊ℂ
Whole numbers can (informally speaking) be considered to be natural-
like numbers. Yet, that doesn't make natural numbers non-whole.
Compare:
File-like objects are objects that are like a file. Yet, that doesn't
make files non-file-like.
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part
Re: how to write services (was: Re: Teams)
Ricardo: Thats very good advice and will be a useful guide in refactoring the parts of the system services documentation. I think in general, we need to find a nice middle ground between the extremely general and the immediately sensible, as I remember when I first got into guix 1.5 years ago, arriving at services left me very confused. While as a recent PhD candidate in philosophy of mathematics I'm a fellow appreciator of the power of generality (the extreme genericity of scheme and guix is why I'm here!), I also think if it doesn't obey strict linguistic rules it can antithetical to its original purpose. For example, I remember being very confused about "file-like objects", for the simple reason that it wasn't "a file or file-like object". While this might come from a GNU terminological lineage i'm unaware of, my immediate reaction to trying to understand file-likeness is the simple rule that a semblance is strictly not what it resembles, and likeness qualifies semblance. It would be improper to place phones in a category of "phone-like objects", because the likeness assumes a distinction from the thing itself. Perhaps it could be justified if we dive into the minutiae of paraconsistent logic, but I think then we are going to far (also, isn't 'everything a file' a motto of Unix, even if gnu is strictly not?). But I've digressed; I think your straightforward description above communicates many of the ideas better than the docs, but I think this is a situation where we can have our cake and eat it too, so to speak; usually, an appendage such as "file AND file-like objects" will accomplish much of the work for us. Catonano: I think writing a home-service is much easier given that you don't need to do produce an entire system generation before you find out what you did wrong; it just depends on if you need your service initialized at startup (system-services, globally defined and available prior to login) rather than at login (home-services, per-user/locally defined). I'm not on Mastodon but feel free to send your service my way for some help, I'm still a beginner but a second pair of eyes is always nice to have. ez, b --- Blake Shaw Director, SWEATSHOPPE sweatshoppe.org --- On Wed, Jun 15, 2022 at 2:04 PM Ricardo Wurmus wrote: > > caton...@gmail.com writes: > > > Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto: > >> > >> I found the documentation to be a bit confusing (understandably, as > >> its new), but once the workflow snapped together its been amazing to > >> see how easy it is to create new services. > > > > This is something I'm specifically interested in > > > > In fact, I wrote this toot that got several boosts and likes but NO > > answer > > https://floss.social/web/@abbienormal/108378060174601402 > > I don’t know Odoo, but the general process is this: > > - look up the relevant documentation of your application to figure out > what commands must be executed. Take note of any way to pass a > configuration file. > > - copy an existing shepherd service. Maybe start with > gnu/services/audio.scm, because it’s pretty simple while not completely > trivial. > > - adjust the commands and names. > > In gnu/services/audio.scm you see the definition of mpd-service-type, > which is a *system* service that 1) adds a user account, 2) does some > one-shot preparation work, and 3) registers the mpd-shepherd-service. > > mpd-shepherd-service is a procedure returning a shepherd service. The > service has a start and stop command. Adjust this for your service. > > mpd-shepherd-service refers to its argument “config”, which is supposed > to be a Scheme configuration value. It’s just a record defined higher > up as . mpd-config->file turns that Scheme value > into a string that can live in a file as the mpd configuration file. > > This is pretty much all there is to it. Some services are simpler and > don’t need any one-shot setup, nor do they need system user accounts, so > they would just boil down to a shepherd service definition. > > -- > Ricardo >
Re: how to write services (was: Re: Teams)
caton...@gmail.com writes: > Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto: >> >> I found the documentation to be a bit confusing (understandably, as >> its new), but once the workflow snapped together its been amazing to >> see how easy it is to create new services. > > This is something I'm specifically interested in > > In fact, I wrote this toot that got several boosts and likes but NO > answer > https://floss.social/web/@abbienormal/108378060174601402 I don’t know Odoo, but the general process is this: - look up the relevant documentation of your application to figure out what commands must be executed. Take note of any way to pass a configuration file. - copy an existing shepherd service. Maybe start with gnu/services/audio.scm, because it’s pretty simple while not completely trivial. - adjust the commands and names. In gnu/services/audio.scm you see the definition of mpd-service-type, which is a *system* service that 1) adds a user account, 2) does some one-shot preparation work, and 3) registers the mpd-shepherd-service. mpd-shepherd-service is a procedure returning a shepherd service. The service has a start and stop command. Adjust this for your service. mpd-shepherd-service refers to its argument “config”, which is supposed to be a Scheme configuration value. It’s just a record defined higher up as . mpd-config->file turns that Scheme value into a string that can live in a file as the mpd configuration file. This is pretty much all there is to it. Some services are simpler and don’t need any one-shot setup, nor do they need system user accounts, so they would just boil down to a shepherd service definition. -- Ricardo
