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.
14:45:11
beach
I think the people complaining about McCLIM looks haven't really seen the great advantages that presentations and a dynamic programming language give in a toolkit.
14:45:37
lisp123
(p.s. not complaining :-) ) - out of curiousity, why not just go down the FFI route
14:46:16
beach
lisp123: Because it always results in a debugging nightmare, as you can see from the numerous cries for help here, when people are lost.
14:46:45
shka
beach: the problem is that no matter how cool is to program applications using McCLIM, there is distinction between nerd software and normal people software
14:48:10
beach
Oh, and commercial mass software is what all the #commonlisp participants who complain about McCLIM are into?
14:49:09
beach
But Common Lisp is totally useless for commercial software anyway, as I understand it. So I don't see the problem.
14:51:48
shka
well, that's how it is, i can write prototype in McClim, and it will be fun, but there is no way in hell that boss would allow it go to the user with the company logo slapped on
14:53:30
beach
My message is that there is A LOT of collective energy spent in debugging FFI solutions. I think the effort to make McCLIM look like the native toolkit would be WAY LESS than the collective wasted effort we witness here on a regular basis.
14:54:22
beach
Yet, people choose FFI all the time, complain about McCLIM, and then come here and cry because they can't figure out the FFI stuff, thereby wasting other people's time too.
14:55:41
shka
well, from my point of view, making mcclim look and feel exactly like native toolkit is not exactly required
14:57:36
beach
shka: Let me make that very clear. I was not addressing you here. I don't consider you one of the complainers.