freenode/#lisp - IRC Chatlog
Search
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)?
0:22:45
_death
anyway, with a small patch it seems to work: https://plaster.tymoon.eu/view/1680#1680
0:39:21
ebrasca
I don't know why I am geting 'System "next/ring" not found' . I updated someting and asdf can't load next.
4:57:40
verisimilitude
I keep seeing this stupid advice to avoid :USE, so I figured I'd start an argument about it here. Also, this local nicknames nonsense isn't standard and shouldn't be encouraged.
4:59:20
no-defun-allowed
Sure. Here's my two cents: eazy-opencl is decent, except that it accidentally overwrites a macro in CFFI which I presume it did not have before.
4:59:43
beach
verisimilitude: You need to tell #lisp participants that you come here mainly when you are bored and want to argue.
5:01:50
no-defun-allowed
When eazy-opencl was written, it assumed some properties of the set of symbols CFFI exports, notably that WITH-FOREIGN-ARRAY was not exported by CFFI; but it is now.
5:03:19
no-defun-allowed
Now eazy-opencl overwrites that macro, and code loaded after eazy-opencl that uses that macro could break in awkward ways.
5:04:12
no-defun-allowed
It is a somewhat high-level abstraction over a OpenCL interface, which I use for my GPU-accelerated Petalisp backend.
5:04:58
verisimilitude
Is there any reason it needs the CFFI or would it be possible to interface with it in Common Lisp?
5:05:54
no-defun-allowed
And its use of CFFI isn't the problem here; the problem is that it :USEd CFFI and overwrote one of its macros.
5:06:47
verisimilitude
Both can be issues; anyway, this could be solved by changing either or using a CFFI before the change.
5:09:33
no-defun-allowed
phoe often mentions a similar situation with Alexandria, where packages that use that could also break other packages subtly. That has a greater probability of being a problem, because more packages use Alexandria than eazy-opencl (which isn't even in Quicklisp), and it's often treated like a necessity like the CL package to use.
5:10:48
verisimilitude
I've had the misfortune of reading through code which uses Alexandria, yes. There's no little good reason, I think, to not simply add to Alexandria if it's desired. Fretting over hypothetical ``breakage'' is silly.
5:11:00
no-defun-allowed
(defpackage netfarm (:use :cl :ironclad :s-base64 :flexi-streams :split-sequence) ...) ;; There's something else I have to clean up, then.
5:12:25
no-defun-allowed
It's not really hypothetical; I just described a case where we got some breakage, and I am saying that for that one case with two seldom used packages, there are dozens of cases with Alexandria and everything that depends on it.
5:12:46
verisimilitude
Thinking about ALEXANDRIA, I'm reminded of some discussion here where it was acknowledged a very inefficient implementation was in-place, where unnecessary.
5:13:19
verisimilitude
It's fine to design a library which isn't intended to be USEd, but to advocate against it entirely is silly.
5:14:24
verisimilitude
An easy solution is to not use a newer version of a library unless you've audited it. This does make the accumulation of dozens of dependencies harder, though.
5:14:57
no-defun-allowed
Sure, I'll name a case where it is useful: in decentralise2, I have a package decentralise-utilities that has parsers and generators for some of my internal formats, and some other macros.