testing out the left knee again, but in the real world. it was fine, took it easy but not super easy so it was a good test.
#running
testing out the left knee again, but in the real world. it was fine. took it easy but not super easy so it was a good test.
#running
testing out the left knee again, but in the real world. it was fine. took it easy but not super easy so it was a good test.
#running
testing out the left knee again, but in the real world. it was fine. took it easy but not super easy so it was a good test.
#running
grep-able version, that's very neat. Interesting choice of aligning the colons at the values and not the keys, I think I never came across this.
Being also a Python programmer, I wish there would be more indentation-based stuff. I do like that part with YAML.
Oh no! :-( That's bad to hear. I configured ejabberd years ago and it just is Erlang if I remember correctly. Quite a cool choice for that software.
* as the bullet point wherever possible, e.g. markdown and RST. Not sure if YAML has it, too. I just know at work we use - for lists as well. But then use blank lines to separate list items that are spanning multiple lines. That helps a bit.
> You can't catch the kill signal. Should this be syscall.SIGTERM instead of os.Kill, xuu? https://git.sour.is/sour-is/go-paste/src/branch/main/main.go#L21
You are totally right.. i think i was going for SIGTERM and SIGQUIT
> You can't catch the kill signal. Should this be syscall.SIGTERM instead of os.Kill, xuu? https://git.sour.is/sour-is/go-paste/src/branch/main/main.go#L21
You are totally right.. i think i was going for SIGTERM and SIGQUIT
“Today + 1 year = 2025-02-29” …=
“Today + 1 year = 2025-02-29” …=
“Today + 1 year = 2025-02-29” …=
#catsoftwtxt
/https://duque-terron.cat/media/photos/photo_8829-02-2024_10-58-27.jpg) #catsoftwtxt
#catsoftwtxt
foo.bar or a glob like foo.* or trace the hierarchy trace:some.deep.name.space which will give me the namespaces some, some.deep, some.deep.name, and some.deep.name.space. These can be combined.
foo.bar or a glob like foo.* or trace the hierarchy trace:some.deep.name.space which will give me the namespaces some, some.deep, some.deep.name, and some.deep.name.space. These can be combined.
@namespace
# multi
# line
# comment
root :value
# example space comment
@namespace.name space-tag
# attribute comments
attribute attr-tag :value for attribute
# attribute with multiple
# lines of values
foo :bar
:bin
:baz
repeated :value1
repeated :value2
each
@ starts the definition of a namespace kinda like [name] in ini format. It can have comments that show up before. then each attribute is key :value and can have their own # comment lines. Values can be multi line.. and also repeated..
the namespaces and values can also have little meta data tags added to them.
the service can define webhooks/mqtt topics to be notified when the configs are updated. That way it can deploy the changes out when they are updated.
@namespace
# multi
# line
# comment
root :value
# example space comment
@namespace.name space-tag
# attribute comments
attribute attr-tag :value for attribute
# attribute with multiple
# lines of values
foo :bar
:bin
:baz
repeated :value1
repeated :value2
each
@ starts the definition of a namespace kinda like [name] in ini format. It can have comments that show up before. then each attribute is key :value and can have their own # comment lines. Values can be multi line.. and also repeated..
the namespaces and values can also have little meta data tags added to them.
the service can define webhooks/mqtt topics to be notified when the configs are updated. That way it can deploy the changes out when they are updated.
[[foo.bars]] [[foo.bars]] [[foo.bars]]
[[foo.bars]] [[foo.bars]] [[foo.bars]]
I think the appeal with YAML is that is has comments, is kind of easy to write and read and also provides unlimited nesting levels. But it has all its drawbacks, no question. Forbidding tabs, thousands of different string flavors, having so many boolean options (poor Norwegians) etc. I use it, but I don't particularly enjoy it.
Among simple key value pairs, I like INI files, but with
# for comments, not ;. I never used TOML, read up on it yesteray before writing this question, but it looks a bit weird and has some strange rules. I guess I have to give it a try one day.And yes, as mentioned by several of you, it always depends on the complexity of the configuration at hand.
I'm developing something for the scouts at the moment with rather simple requirements on the config. Currently, there are just four settings. Even INI would be overkill with its section. I selected JSON for now, because that's readily available with Go's std lib. But I do not like it.
Btw. what's your own config format, @xuu?
#running #treadmill
just an easy run after a few days resting the knee. had a few pings the first half mile and then it went away until about 2.75 miles in. called it soon after.
#running #treadmill
just an easy run after a few days resting the knee. had a few pings the first half mile and then it went away until about 2.75 miles in. called it soon after.
#running #treadmill
just an easy run after a few days resting the knee. had a few pings the first half mile and then it went away until about 2.75 miles in. called it soon after.
#running #treadmill
dict. For C with GTK, it’s INI because GLib comes with an INI parser. For minimalistic C, it’s just a config.h. You get the idea. 😃
dict. For C with GTK, it’s INI because GLib comes with an INI parser. For minimalistic C, it’s just a config.h. You get the idea. 😃
dict. For C with GTK, it’s INI because GLib comes with an INI parser. For minimalistic C, it’s just a config.h. You get the idea. 😃
I do prefer toml for the old school ini style with added support for object lists.
my second would be hjson or any other json with comments style.
I do prefer toml for the old school ini style with added support for object lists.
my second would be hson or any other json with comments style.
I do prefer toml for the old school ini style with added support for object lists.
my second would be hjson or any other json with comments style.
Anyway, they definitely should teach that, I fully agree! :-)
What we should teach kids in elementary school: If you receive some notification/message that appears to be actually important and you’re not sure if it’s legit or not, then contact the sender of that message *through another totally unrelated channel* and try to verify it.
What we should teach kids in elementary school: If you receive some notification/message that appears to be actually important and you’re not sure if it’s legit or not, then contact the sender of that message *through another totally unrelated channel* and try to verify it.
What we should teach kids in elementary school: If you receive some notification/message that appears to be actually important and you’re not sure if it’s legit or not, then contact the sender of that message *through another totally unrelated channel* and try to verify it.
#catsoftwtxt
#catsoftwtxt
/https://duque-terron.cat/media/photos/photo_8726-02-2024_15-30-52.jpg) #catsoftwtxt