freenode/#clim - IRC Chatlog
Search
7:01:01
loke
GENVARS is a special variable that holds a list of the underlying variables/expressions that is represented by the gensyms in the EXP list.
7:01:37
loke
It's pretty insane. EXP is meaningless without the content in VARLIST to go along with it, so why do they even bother passing it along as an argument. it could all be speical variables :-)
7:01:58
loke
Anyway, I could rant about that stuff for a while. I'm pretty sure that code was originally written in the 60's.
8:56:40
beach
loke: Would you like to collaborate on developing Second Climacs, or did you have something entirely different in mind?
8:58:35
beach
I may have gone overboard in my attempt to make Second Climacs independent of the underlying GUI library. I am not pleased with that pat of it at all.
8:59:13
beach
My main work has been with parsing Common Lisp code in the buffer, because that's what I think will make Second Climacs unique.
9:23:07
beach
So I guess what I am suggesting is to abandon my overly complex GUI layer in favor of something better (written by you) and then plug in my parsing framework and my buffer representation into that better thing.
9:43:02
loke
beach: Well, my intent was to build a minimally-functional Emacs-like. That is, fundamental editing capabilities and then see where it leads me.
9:43:11
jackdaniel
I've added two more commits to the pull request with refactor-regions (they move utilities to a separate file), since this is still no semantic change I think it belongs to this batch
9:43:33
loke
I did not consider Second Climacs as a starting point because frankly, I didn't think about it. Also, you told me you wanted to finish the base first. :-)
9:43:39
jackdaniel
next batch of changes will provide faster (and more complete) implementation of region-intersects-region-p
9:43:54
loke
I'm more intersted in starting as small as possible. To make as minimally viable product as it were ;-)
9:47:00
jackdaniel
with geometry module? currently they improve nothing functionally, until know I was organizing a module to be more comprehensible
9:47:31
jackdaniel
there are some tweaks (i.e generic region-difference was not defined by ommission)
9:48:41
jackdaniel
the gist of the current pull request is that geometry module is split into multiple parts which implement parts of the protocol. so if you want to "see" something you may compare previous "region.lisp" with current "geometry/region*"
9:54:46
jackdaniel
ultimately I hope to have more complete implementation (some methods are missing) and a faster one at that
9:55:25
jackdaniel
i.e region-intersects-region-p is currently: (not (region-equal +nowhere+ (region-intersection a b))) what is a total waste - you don't need to compute full intersectio nto tell that
12:31:04
beach
loke: You can look at it if you like, but like I said, I am not happy with the structure of the GUI.
14:11:58
loke
I will learn how to make a gadget from scratch by building a small text editor. After that I will know if working on a bigger one is a project I want to undertake.
14:13:44
beach
Here are some hints: You need an efficient buffer implementation. I created Cluffer for that.
14:14:19
beach
You probably need to manipulate the hierarchy of output records in an application-specific way.
14:30:33
jackdaniel
I've pushed final version of utilities with refactored map-over-overcuts-line/polygon
14:35:59
ck_
jackdaniel: map-over-schnitt-gerade is probably more aptly translated as map-over-intersection-line, if you'd like to consider my opinion on this
14:51:00
beach
ck_: Me and gilberth had some interesting discussions about the German language, for instance that "Mobiltelefon" ought to be called "Kraftwgenfernsprecher" instead.
14:51:58
beach
loke: However, the protocol is designed so that it is efficient to do character-by-character operations inside a region.
14:53:52
beach
loke: The secret is that the GUI refresh is not done until after a command has finished completely. This is a very important design consideration.
14:54:50
beach
loke: Cluffer is also designed so that a hidden view is never updated, and once it becomes visible again, it only sees the previous and the new contents, not the intermediate operations.
14:56:57
ck_
beach: translation is a very fun topic. I'll pose this puzzle to you: the now-defunct babelfish.altavista.com site translated this german word into english as: 'impactsuspect'. Which word or phrase was it?
15:08:55
loke
beach: I'm trying to understand the basics of cluffer. I read the documentation, but I'm having some troubles.
15:24:49
beach
I don't see any problem right away, and I don't have time to investigate today. In just a few minutes, I will serve dinner to my (admittedly small) family. I'll try to remember to look at it first thing tomorrow morning.
15:47:32
loke
beach: FYI, I changed cluffer-standard-{line,cursor} to cluffer-simple-* and it worked.
16:10:47
jackdaniel
because it doesn't map over a line, but over parameters (from which you may infere overcut points)
16:19:09
jackdaniel
or to put it the other way around: it computes the parameter which is the argument to a function from overcut points between the polygon and a line (note, unbounded line, not a segment)
16:30:06
ck_
jackdaniel: my point was more that 'overcut' is probably not the term you wanted. But ok, sure.
16:32:58
jackdaniel
ck_: do you have another suggestion then? intersection (in our case) is too ambigous (and whole function is used in the other "intersection" context, where we mean intersection of a path and an area)
16:35:07
jackdaniel
n.b if we take meaning "to cut excessively" it makes actually sense, because we also cut beyond the segment (but on the same line ;)
17:37:51
ck_
jackdaniel: aha, all right. I had 'overcut' filed mentally as something exclusively to do with woodwork.
17:40:01
ck_
still, translating map-over-schnitt-gerade/polygon as map-over-overcuts-line/polygon is a distortion of meaning, and (for me) the latter is not understandable by name alone. That's all I wanted to say in the first place.
17:58:39
jackdaniel
ck_: I'm not overly attached to the name, if you could propose better alternative I can rename it
17:59:34
jackdaniel
s/could/can/ with a stipulation, that the word "intersection" is ambigous in this context
18:39:29
jackdaniel
just in case it stays as it is I've added a comment above the function explaining the used term