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.
6:27:07
asarch
I read that old-school Common Lisp programmers used to do string operations using symbols
6:41:56
White_Flame
olde timey lisps would break apart symbols into lists of single-character symbols for processing, then intern them back into a single symbol
6:51:27
asarch
For example, the user will input random numbers until he inputs 'q' to exit and do the average of those numbers: http://paste.scsys.co.uk/587907
6:56:19
asarch
I now, even (string=) won't work when you type "1": The value 1 is not of type (OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING SYMBOL CHARACTER)
6:56:38
beach
asarch: Also, why do you not call READ in the LET binding, rather than having a default LET binding and then assigning to it?
6:56:39
beach
asarch: And when you expose code, you should make sure it is indented correctly. Common Lisp programmers rely on indentation to see the structure of the code. If you have the wrong indentation, you force people to count parentheses which is not polite.
6:58:34
no-defun-allowed
Copying from the REPL is going to indent it funny, because the first line is "indented" less in the copied text.
6:59:41
beach
asarch: Clearly, you should not use READ if you want to enter things as strings. READ will produce Common Lisp objects, like numbers, symbols, arrays, etc.