libera/#commonlisp - IRC Chatlog
Search
6:04:28
beach
Am I reading the page on ENSURE-GENERIC-FUNCTION right in that the keyword arguments are required? The phrase that explains how the properties of the generic function will change according to the values of those arguments seems to suggest that.
6:09:44
beach
It does seem a bit excessive to require that, though. I mean, all those keyword arguments could reasonably default to the existing ones if the generic function already exists.
6:22:16
beach
The phrase that explains how the properties of the generic function will change according to the values of those arguments seems to suggest that.
6:26:17
pillton
beach: Yeah the page could do with some work. It does say "The keyword arguments correspond to the option arguments of defgeneric, ..." though.
6:26:38
pillton
beach: Based on that you could probably argue that the lambda-list keyword is required.
6:27:19
beach
pillton: You could do that, but the initialization protocol for generic functions does not require the lambda-list argument to be present.
6:28:34
beach
The MOP specifies that the generic function is created without this information, and that it will be set when a method is added, or the function is reinitialized.
6:29:42
beach
So it makes sense for ENSURE-GENERIC-FUNCTION to call MAKE-INSTANCE without the LAMBDA-LIST argument.
6:30:35
beach
I think I'll just do what SBCL does. It seems conforming in that if ENSURE-GENERIC-FUNCTION is called without any of those arguments, the consequences seem to be undefined.
7:05:26
beach
That page seems to be a case for WSCL. Can people with other Common Lisp implementations installed confirm that those implementations do not require the keyword arguments, please?
7:38:46
beach
gilberth: Have you considered making the Nova Spec "annotatable" like you did with the CLIM II specification?
7:54:56
gilberth
However, this time I believe I would need some safe-guards. And I want some addressing scheme, so that annotations are not tied to this particular rendefing of the draft spec.
7:58:21
gilberth
It could be something simple like section 4.5.6.2.1, third paragraph. Some specs actually number their paragraphs, like ISO C (which I happen to read atm).
8:08:27
gilberth
So this doesn't solve anything. Besides I don't expect that ANSI CL will ever be updated. And our sections have names as well.
9:13:28
beach
gilberth: What I would really like is to annotate the dictionary entries with WSCL issues.
9:18:46
gilberth
What would be easy though would be to just compile a list of annotations asoociated with a section, either a number like 4.5.6.1.1 or a dictionary entry. For dictionary entries there could just be a subsection "Remarks" or something below all the other subsections like "Description", "See also", etc.
9:21:38
gilberth
Not important: I don't like any buttons that hide or reveal information. It's IMHO a UX nono. Scrollbars have been invented already.
9:23:12
gilberth
Same as popups that pop up while the mouse (which mouse btw on a tablet or phone?) hovers over something. Those annoy me most as I have the habit to use the mouse pointer as a virtual finger following text as I read that text.
9:24:37
gilberth
So the very text that I am reading is then obscured by a popup. One offender is wikipedia. I need to take an effort and "park" the mouse pointer at some safe spot.
9:31:55
beach
scymtym already did this, but then as I recall, he said that the Nova Spec is better than what he dis.
9:32:23
beach
gilberth: Yes, the ones we worked on seriously are formatted exactly like the issues in the standard.
9:33:50
beach
It is plain text, but they have a certain layout that makes it possible to parse them.
9:35:44
gilberth
Good, good. So when I attend to the spec again, I better get in contact with scymtym, so that we can come up with something.
9:37:24
gilberth
Ok, those things look more like actual articles and not like remarks. I think that would call for some subsection in dictionary entries, like "WSL Notes" or something pointing to that text files, perhaps typeset or not.
9:37:25
beach
Some of them exist only in the form of abbreviated GitHub issues. Like when we detect something but don't have time to write it down in the right layout.
9:40:13
gilberth
However, some symbols have multiple dictionary entries. Like CONS. Which is a function and a system class.
9:40:31
beach
Great! Yes, we modeled those issues after the X3J13 (did I get that right?) issues to make them as precise as possible.
9:42:23
gilberth
I looked at a few. I can tell sections just fine. What I cannot tell though is verbatim text (example Lisp) from prose.
9:44:35
gilberth
You already separate paragraphs by two newlines. You say "Foo:", newline, some indented text. That's a section.
9:47:23
gilberth
Otherwise those text files look fine. I can pickup FOO-BAR and recognize that as Lisp or pointers to other proposals or issue.
9:51:28
beach
The other thing I suggested was a web form to create WSCL issues, so that one would not have to remember the layout. I suck at web stuff myself, so I was suggesting it to others, but nobody seemed interested.
9:53:37
gilberth
The web part would be almost trivial. The github part is what I have no clue about.
9:55:41
gilberth
Well, you craft your WSCL issue, and what happens then? I was assuming that you want it to appear in that github repo.
9:56:05
beach
That would be good. But even if that required some manual intervention, that would be no problem.
9:58:35
beach
I just think it would encourage more people if we could just give them a link here to a web form to fill out.
9:59:23
gilberth
Who would be authorized to do so? Would there be a moderator? How would you deal with spam?
10:02:01
gilberth
You wanted a web form for anybody to enter a WSCL issue and that issue should make it to github. No?
10:02:47
beach
Well, like I said, manual intervention would be fine. If the files ended up in some directory that I can access on the web, I can move them myself.
10:06:19
gilberth
beach: Anyhow, any relays or proxies are troublesome. At the moment the completely open clim-spec annotation would just harm myself, so that's ok. I don't feel comfortable when a service that I run can harm someone else. Or their infrastructure.
10:26:27
alcor
So I've been using ocicl recently – am I correct in the assumption that the systems are stored project-locally, similarly to npm's node_modules? If so, that's pretty cool.
10:27:07
beach
gilberth: Or the resulting text file could just be sent to me as an email attachment.
12:16:24
alcor
Bubblegumdrop: Thanks, I found the global (-g) option earlier, but the default behavior is preferrable for me. I prefer self-contained project setups.
12:17:05
Bubblegumdrop
systems.csv is the folder you'll want to check into vcs, I have systems/ in my .gitignore for my projects
12:19:21
Bubblegumdrop
Oh, if you look at the Makefile from the ocicl project you can see some useful stuff
12:19:24
Bubblegumdrop
sbcl --dynamic-space-size 2048 --no-userinit --eval "(require 'asdf)" --eval "(progn (push (uiop:getcwd) asdf:*central-registry*) (asdf:make :ocicl) (sb-ext:quit))"