freenode/#lisp - IRC Chatlog
Search
4:46:07
loke
Question 1: WOuld you be able to put it on Quicklisp, in order for users to not have to manually download it?
4:47:04
loke
Question 2: Do you have a suggestion how to implement ranges? (similar to how Emacs implements text properties and overlays)
4:47:54
loke
I was thinking of implement a rangeusing two cursors. That would track the start/end of the range properly. However, I need an efifcient way to find all ranges that cover a given cursor position.
4:49:54
ck_
but maybe you'll want to read the discussion on that during the xemacs / gnu emacs diverging. I believe there's a balancing tree for intervals in emacs since then.
4:50:06
beach
ck_: It might be more difficult than that, given that individual cursors can change independently, and that text can be inserted and deleted anywhere.
4:51:47
LdBeth
a character with properties could also be a pair of the codepoint and a reference to the properties
4:53:11
LdBeth
I don’t think emacs does this with ranges, since text properties can be preserved even cut and paste from a buffer to another
4:54:13
loke
But the ranges are not directly accessible. The API presented to the user is simply a set of text properties per character.
4:54:25
beach
An interesting idea would be to exploit the open/closed line idea of Cluffer. Conceptually, each character would be what LdBeth suggests, namely a pair of code-point and properties. But when a line is closed, a more compact representation could be computed.
4:57:03
loke
Well, the peorperties describe things like fonts/colours/etc, as well as arbitrary other things), so there is a lot of variations.
4:59:28
beach
Otherwise, you will have to scan the entire buffer for each character you insert or delete.
5:00:18
loke
Well, not the entire buffer. It scans backwars to some synchronisation point (usually the beginning of the defun)
5:01:24
loke
Clearly I want to make best use of your parser. I should probably take a look at its API to make sure I understand it.
5:08:58
beach
But it will depend on Eclector, once scymtym adds the functionality to Eclector that I need.
5:15:36
beach
It is impossible to imagine a complete specification of things until different ways are tested in real code.
5:15:39
loke
So far, my “view” has been the visual representation of the buffer content on a line-by-line basis. I.e. every line in the cluffer buffer has a visual representation that has a given height.
5:17:54
beach
I think you need very different representations of different views for different kinds of text you are editing.
5:19:03
beach
And it may be right for many other things as well, like HTML, markdown, and other stuff with some syntax imposed.
5:25:52
beach
I think you just gave me some of the reasons why I prefer to invent my own solutions before looking at what was done in the past. I do not want to be influenced by solutions that may have been appropriate in one context, but that aren't in others.
5:27:39
beach
Of course, with my preferred way, I then occasionally re-invent something that has already been done.
5:28:37
beach
loke: I think they may have cooked up solutions to problems based on what they had to work with, i.e. the old core.
5:30:56
loke
My current work has been a learning experience, and has taught me a lot. That's the nicest thing I can say about it :-)
5:31:15
ArthurStrong
"Xterm originated prior to the X Window System. It was originally written as a stand-alone terminal emulator for the VAXStation 100 (VS100) by Mark Vandevoorde, a student of Jim Gettys, in the summer of 1984, when work on X started." ( https://en.wikipedia.org/wiki/Xterm )
6:02:48
beach
I don't know ECL in that level of detail, but technically, the MOP is not part of the Common Lisp standard.
6:03:12
beach
I guess jackdaniel would have to address that issue. He is the current ECL maintainer.
6:04:11
ober
so I'm interested in why if it's not in the standard, the statement that it's compliant with the standard would apply to a question about it...
6:06:42
beach
ober: There is a part of CLOS that is in the Common Lisp standard, but the MOP has many more features than that, some of which are even contradicting the standard.
6:29:08
aeth
loke: I think it's something small like something that's normally a function, but with MOP is a generic function instead or something. But apparently that isn't against the standard, so I have to be misremembering the details
6:56:53
beach
It may have been small stuff like one saying "the consequences are undefined" and the other one that "an error is signaled".
7:11:20
no-defun-allowed
I don't think whoever came up with the spam bot programmed it to explain itself, sadly.
7:12:04
beach
I am not looking for an explanation. I am looking for the absence of one, so that I don't have to follow the link.
7:13:31
White_Flame
LdBeth: one interesting use of &aux that I've found is computing derived struct slot values in the declared BOA constructor without needing a function body
7:17:31
loke
Wow. I didn't know that was possible. And even though I now know about it, I don't think I'll ever use it.
7:19:27
White_Flame
ACTION likes shortcuts when possible and fits the intent. Plus, with Lisp it's pretty easy to unroll into "full form" if it gets past the scope of the shortcut
10:51:24
jmercouris
Ok, so yesterday we established that we can't do FFI to C++ because the ABI is not standard in C++ world
11:43:06
no-defun-allowed
Standardise the C++ ABI? That would be half-polite of the – well, sure. No good if you want to use Qt though.
11:45:03
beach
But I will be quiet now because I am not adding anything new that I haven't already said.
11:48:53
no-defun-allowed
I agree life is much simpler if you are able to avoid FFI completely or avoid it as much as possible, or if you grow vegetables; but there may be reasons one wants to use Qt.
11:51:34
no-defun-allowed
My favourite reason is to use the Qt WebEngine to load documents off a CL server, and implement the UI in HTML/CSS/JavaScript. Then use your favourite C->JavaScript transpiler to run Qt in the browser, and repeat until you get bored.
11:55:24
no-defun-allowed
But seriously, it may be less effort per individual to bite the bullet and work with Qt than to test/port/develop/&c a CL toolkit, even though all the time taken to accomodate for foreign code would probably add up to more than enough required to make that toolkit work.
13:18:29
beach
I am convinced we represent an instance of the prisoner's dilemma. The optimal solution is to collaborate to create Common Lisp solutions to our collective software needs, but individually, it is better to take the FFI route.
13:18:31
beach
As a result, everybody pays the price of increased development and maintenance burden. Except those who can and do choose to work on something that can be done entirely in Common Lisp.
13:22:09
beach
FFI solutions require a different kind of maintenance, namely catching up with moving targets, like Qt versions, LLVM versions, Gnome versions.
13:28:44
Xach
I wrote pure lisp stuff for gifs and pngs because I was frightened by the thought of foreign code crashing my long-running server.
13:31:09
_death
I didn't write OpenCV in pure lisp because it would require tens of thousands of man hours or more..
13:33:11
beach
Anyway, having identified the reason for the state of things, I now understand much better what is going on, and I know that it would usually be futile to try to influence someone's choice.
13:33:45
_death
beach: but you could also flip it, so that the utilitarian solution is to use the language where most effort has already gone to, and the choosing Lisp is the egoistic individual choice
13:36:06
beach
That might have been true if the "utilitarian solution" were effortless or nearly so. The many questions and problems related to FFI solutions that are discussed here suggest otherwise.
13:41:26
_death
there is reason, but it is an egoistic reason.. I like CL better than C++, so I don't mind putting effort into making the rest of the world work with CL.. only a small group of people may benefit from this choice
13:41:52
beach
_death: You don't need an excuse to choose the FFI solution ("tens of thousands of man hours or more"). Like I said, it is perfectly clear to me now why this solution is optimal to the individual.
13:45:40
beach
_death: I think that is a very good idea, i.e. create a Common Lisp "wrapper" for an existing foreign library. However, what I usually observe is a badly documented wrapper library that requires the user to understand both the foreign library, the foreign language it is written in, *and* the undocumented code of the wrapper.
13:45:41
beach
I am not saying this is the case with yours of course. I haven't looked at it at all.
13:47:31
_death
beach: I definitely agree with this observation.. I think it's difficult to design good interfaces, and the Lisp standard is a high one.. it's much easier to ape the foreign library's existing interface.. in the past I did that, but also did the harder work at times
13:49:34
_death
beach: it also has to do with means and ends.. if utilization of this library is just a means to an urgent end, then it's likely the initial solution would involve less thought about the interface
13:50:22
beach
Yes, but then it is not really usable by a wide audience. And we are back to the prisoner's dilemma.