libera/#commonlisp - IRC Chatlog
Search
3:17:23
beach
merazi: http://www.total-knowledge.com/~ilya/mips/ugt.html#:~:text=UGT%20%28abbr.%29%3A%20Universal%20Greeting%20Time.%20UGT%20is%20convention,time%20of%20any%20member%20of%20channel%20is%20irrelevant.
3:20:00
merazi
I'm learning Scheme, a lisp implementation (I know it's not the same as Common Lisp), and I wanted to be part of the lisp community.
3:31:14
beach
merazi: I should tell you, usually #commonlisp is fairly lively, but this is Sunday morning in Europe, and many people here are Europeans with families, so it is a bit slow during the weekend.
3:32:30
merazi
That's completely understandable, I won't be here 24/7 but I'll hang out occasionally.
3:58:11
jcowan
merazi: Not to steal you away or anything, but there is a #scheme channel as well as the #lisp channel, which is about all the Lisps.
3:59:13
merazi
I'm already in the #scheme channel and... *click* Now I am in the #lisp channel as well :)
4:05:55
beach
That dictionary entry says how a conflict should be resolved when an imported symbol conflicts with an existing inherited symbol, and when it conflicts with a symbol that is present.
4:05:59
beach
But what about this scenario: A new symbol conflicts with a symbol that is present, but the present symbol is a shadowing symbol, and there are external symbols in the used packages that would conflict if it weren't for the fact that the present symbol is a shadowing symbol.
4:06:00
beach
So here is my question: Should a conflict be reported that contains also the inherited symbols? If not, what happens if the user uninterns the present symbol? Should the new symbol also be a shadowing symbol right away, or should a new conflict be reported?
4:09:18
beach
I am leaning toward not including inherited symbols in the conflict report and to make it shadowing if the present symbol is a shadowing symbol.
8:57:20
beach
We are accumulating "issues" for WSCL: https://github.com/s-expressionists/wscl/tree/main/wscl-issues/proposed which is good. But we could use some help from people who have easy access to implementations other than SBCL.
8:57:25
beach
Many issues have a line "TODO: check other implementations." where the behavior of other implementations should go.
9:08:20
beach
Some of the issues have been transferred from (I think) Cliki to WSCL. This one was transferred by Bike.
9:09:02
moon-child
yeah, I saw it was dated to 2004, which was why I was surprised I had never heard about it
9:12:59
beach
shka: yes, maybe you prefer to make an "issue" that PROG2 should be deprecated since there is an operator doing the same thing. :)
9:24:48
Alfr
PROG2 shouldn't be deprecated, as its second form is mandatory thus not redundant to prog1. But fixing the description of result-2 (under Arguments and Values) for consistency could be considered.
9:28:00
Alfr
I was thinking about the following fixup: result-2---the primary value resulting from the evaluation of first-form.
9:32:40
Alfr
beach, what do you mean? clhs already uses the name result-2 for the only value of prog2.
9:37:07
Alfr
It isn't a serious proposal anyways apart from keeping prog2 alive. I think there is a know better fix for that.
10:18:42
pjb
beach: there are arguments to deprecate prog2. For example, there's no multiple-value-prog2, only a multiple-value-prog1 :-)
11:15:16
scymtym
deprecate all three and generalize to MULTIPLE-VALUE-PROG-NTH N FORM* where N is evaluated. i'm sure there will be no negative impact in terms of ergonomics or performance
11:40:33
scymtym
that's hard to answer in general. GTK has gpu acceleration, more complete text and font support, more supported platforms and probably looks more appealing to many users. McCLIM works without foreign libraries, has the presentation and command sub-systems, is easy to extend due to the stratified design and has a specification. but again, advantages and disadvantages will depend on the use-case
12:16:45
lotuseater
a friend of mine said McCLIM looks old but I more tend to use the term "baroque"
12:25:32
beach
lotuseater: So here is what bugs me. People would rather spend a lot of time and energy debugging FFI solutions that serve only their own projects, and complain about the looks of McCLIM, rather than spending a small amount of time making McCLIM look the way they would like it to, thereby providing a better solution for the entire community.
12:50:02
contrapunctus
lotuseater: there's been some lovely art from the Baroque era, is that a compliment? 😏
14:28:41
beach
The grammatical structure of the sentence makes that clear to a native speaker. Sorry about that shka.
14:30:50
beach
I am not sure what the message is here. The initial creators of McCLIM didn't take into account the necessity for everything to be just bitmaps, so therefore, since coding is required to make it look the way we want, we should all give up and use gtk instead?
14:33:53
pjb
Also, it's an impossible task. Apple is not in the computing business, it's in the fashion business. The look WILL change every year! If you try to follow, you are only wasting resources that would be better spent elsewhere.
14:35:34
pjb
The more bland the look anyways, the faster and the better. We can compete on other things, such as ergonomics and smarts.
14:36:39
lisp123
is it possible to build a bridge between any Lisp GUI system and the default GUI tools of each OS?
14:39:26
lisp123
shka: thanks, I guess its too time consuming so hasn't really happened. Its very hard to go up against Apple (in particular) due the amount of money & time they spend on design - and anything that doesn't follow the native look on MacOS will look off to some degree
14:39:35
beach
lisp123: There are great advantages to a GUI toolkit written entirely in Common Lisp.
14:40:46
lisp123
beach: I was more thinking if its possible to keep everything but using the end visual components of a native system
14:42:54
lisp123
beach: oh I see, I misread his comment as I thought it mean its not enough to only reuse bitmaps, but required more
14:43:35
beach
Exactly, you can't just plug in new bitmaps into McCLIM the way it is now structured.
14:44:08
beach
So, in order to reuse the native look without FFI, all you can do is copy their bitmaps, but that's not currently enough.