freenode/#lisp - IRC Chatlog
Search
11:40:20
no-defun-allowed
I should not be lamenting over below average results while half asleep (nor is it exactly on topic), so I'll head off for the night. See you later.
13:05:29
jmercouris
strangely though, *standard-output* -> #<SB-SYS:FD-STREAM for "file /Users/jmercouris/.local/share/next/standard-out.txt" {100936F393}>
13:06:14
jmercouris
it seems that I need to add an appender to log4cl to also append to *standard-output* or so
22:01:10
cgay
Is anyone here aware of anyone using https://gitlab.common-lisp.net/qitab/cl-protobufs ?
22:16:56
no-defun-allowed
jcowan: Many people avoid USE-ing packages, because they may cause symbol conflicts or their package may overwrite the used packages' state in some weird way, should they change.
22:17:27
cgay
mrSpec: I'm trying to gather anecdata on whether breaking compatibility in that package would affect anyone.
22:26:08
Shinmera
More and more of my libraries are making use of PLNs, so there's at least some of that out there now.
22:27:07
jcowan
Okay, that's encouraging. It's a nice convergence with Scheme, where all (pseudo-)package names are local.
22:30:51
cgay
Shinmera: how are local nicknames achieved in practice? (Apologies, I'm only familiar with the way we do it at $work via a special defpackage* macro.) Pointer?
22:31:55
Shinmera
if the implementation supports plns it'll do the right thing. if not, it'll error.
22:45:08
_death
cgay: thanks for that protobufs reference.. I did not know about this library.. the brown one uses code generation, which is silly, and s-protobuf looked cool but was buggy and out-of-date.. this one's likely out-of-date as well, but maybe less buggy
23:05:26
_death
cgay: CL is a dynamic, interactive language.. it's better to have a Lisp function that can read a schema and make it ready for use than to use a C++ tool to generate Lisp code every time
23:06:36
cgay
A .proto file is the canonical definition of a protocol buffer. If you want to interface with other languages, you want your code to be compatible with the canonical definition.
23:06:58
_death
cgay: I believe the protoc approach came about because in C++ (and other statically typed language) such code generation is more tolerable
23:08:37
jmercouris
much in the same way that if I write a new python interpreter and add some features and/or different behavior than the standard one, I can expect my python will not work with other people's code so nicely
23:09:33
jmercouris
you know what really really sucks? cryptic code with many layers of indirection to the point where it is fully undebuggable
23:09:53
cgay
_death: let's assume there were no .proto file to syncronize between languages. What do you envision is keeping them in sync? good will? :) It's the Interface Definition Language, to harken back to CORBA.
23:10:55
_death
cgay: I am not talking about proto:define-schema, which is nice to have, but something that can load a .proto file at run-time.. in C++ etc. they may assume it would have to be interpreted at runtime or something, but in Lisp you can just generate efficient code (say via COMPILE or EVAL)
23:11:50
_death
cgay: so then you have a load-proto-file and it's the lispy, dynamic, interactive way.. similar to LOAD
23:11:56
cgay
just don't use define-schema directly. (unless you want to live in an only-lisp world.)
23:12:59
jmercouris
here's the tough part, SHOULD THE STANDARD CHANGE, your Lisp code that generates the functions will have to change too
23:13:07
jmercouris
and so that is a moving maintenance target that I would rather not be responsible for
23:13:51
_death
cgay: protoc is just a tool.. Google has a spec for the protobuf write format and interface description language
23:14:43
_death
jmercouris: a spec is much better.. it is complete, because tons of google data is encoded using protobuf format
23:15:25
_death
and there are many tools to work with that, and they have a huge interest in maintaining backwards compatibility (that's a main reason for protobufs, after all)
23:16:49
cgay
Protocol buffer... because it's a buffer for a gRPC message and is re-used over and over (usually).
23:18:18
_death
indeed it's a google product, but one they've become very dependent on, so there are parts of it they cannot change
23:21:27
_death
jmercouris: there are other formats, but there aren't many high quality lisp libraries for them
23:26:23
_death
there are also many projects that use protobufs already, e.g. openstreetmaps.. so it makes it easier to play with them
23:27:21
cgay
what are the competing technologies (I mean if we're going to ignore protobuf because of politics)?