drop SLOC limit

sevz17 commented

2023-10-12 07:42:18 +02:00

(Migrated from github.com)

No description provided.

👍 11 🎉 8

djpohly commented

2023-10-16 20:22:14 +02:00

(Migrated from github.com)

This would be a pretty major change to the project, which I know you understand. dwl was created in response to discussions I read on the suckless MLs, with the intent of providing a Wayland option that adherents of the suckless philosophy could honestly try. That's what established dwl's niche versus other excellent tiling compositors (Vivarium, River, Hyprland, Sway, etc.). You can imagine that, to me at least, abandoning that feels like admitting that the diehards on the mailing list were right about Wayland versus X11.

I'm open to increasing the line limit for core dwl under the right circumstances, but I still feel that it's important that we have one. The SLOC restriction limits the amount of code we're responsible to maintain, forces us to think hard about what features are truly indispensable, and encourages us to innovate to keep code simple (e.g. bar -> stdout and session manager). I'm confident that we still have room to work with - whether that's refactoring, recognizing what can be done by cooperating with other programs, or upstreaming useful default/auto stuff to wlroots.

Is this proposal in the context of specific missing functionality?

This would be a pretty major change to the project, which I know you understand. dwl was created in response to discussions I read on the suckless MLs, with the intent of providing a Wayland option that adherents of the suckless philosophy could honestly try. That's what established dwl's niche versus other excellent tiling compositors (Vivarium, River, Hyprland, Sway, etc.). You can imagine that, to me at least, abandoning that feels like admitting that the diehards on the mailing list were right about Wayland versus X11. I'm open to increasing the line limit for core dwl under the right circumstances, but I still feel that it's important that we have one. The SLOC restriction limits the amount of code we're responsible to maintain, forces us to think hard about what features are truly indispensable, and encourages us to innovate to keep code simple (e.g. bar -> stdout and session manager). I'm confident that we still have room to work with - whether that's refactoring, recognizing what can be done by cooperating with other programs, or upstreaming useful default/auto stuff to wlroots. Is this proposal in the context of specific missing functionality?

fauxmight commented

2023-10-17 00:01:39 +02:00

(Migrated from github.com)

Missing functionality that is present in dwm:

pointer constraints
touch-screen input
tablet input

It has been pointed out in the past that things like touch-screen input are insignificant or are of minimal concern to the "majority of users" on a tiling window manager and should thus be relegated to patch status.

It has also been noted that serious people using dwl are not wasting their time playing games and thus pointer constraints are of no real significance (despite being brought up by several different users in several different issues) and belong in patch status as well.

In opposition to these dismissals, I would point out that parity with dwm is an explicit goal of dwl. Parity with dwm is even the primary reason for insisting on adherence to 2000 SLOC.

Is this about what the majority of users use, or is this about parity with dwm?

If it's about the majority of dwl users, are the majority of users concerned with 2000 SLOC?

if it's about parity with dwm, then which is more critical, divergence from dwm in missing functionality or divergence from dwm in SLOC?

If parity with dwm is the most significant concern, then adhering to 2000 SLOC is a single point of parity in what keeps becoming a larger pool of non-parity points.

Missing functionality that is present in dwm: - *pointer constraints* - touch-screen input - tablet input It has been pointed out in the past that things like touch-screen input are insignificant or are of minimal concern to the "majority of users" on a tiling window manager and should thus be relegated to patch status. It has also been noted that serious people using dwl are not wasting their time playing games and thus pointer constraints are of no real significance (despite being brought up by several different users in several different issues) and belong in patch status as well. In opposition to these dismissals, I would point out that parity with dwm is an explicit goal of dwl. Parity with dwm is even the primary reason for insisting on adherence to 2000 SLOC. Is this about what the majority of users use, or is this about parity with dwm? If it's about the majority of dwl users, are the majority of users concerned with 2000 SLOC? if it's about parity with dwm, then which is more critical, divergence from dwm in missing functionality or divergence from dwm in SLOC? If parity with dwm is the most significant concern, then adhering to 2000 SLOC is a single point of parity in what keeps becoming a larger pool of non-parity points.

djpohly commented

2023-10-17 01:08:01 +02:00

(Migrated from github.com)

Hi fauxmight,

Thanks for your contributions to dwl. I can tell there are some strong feelings here, so hopefully I can gently clear up the misconceptions and the mistaken statements/questions that arose from them.

Keeping the codebase under a fixed SLOC has always been a top priority. More than feature parity with dwm - that's why dwl hasn't had a built-in bar since day one. :) So the statement "Parity with dwm is even the primary reason for insisting on adherence to 2000 SLOC" is not true.

With an intentionally limited amount of code, we have to be very deliberate about how we choose to invest it. Several considerations are weighed against each other on a case-by-case basis:

What is the cost in terms of SLOC?
Does it have utility to the vast majority of users of dwl (i.e. nearly all)?
Is it something provided by dwm/Xlib?
Is it more important than some other feature which could be relegated to a patch?

None of these trumps the others, so the questions in the second half of the post don't really make sense - they're based on the assumption that there is a simple priority order among these concerns, which isn't the case.

I do also want to note that the words chosen for your first couple of points sounds like they're intended to make the dwl developers sound rude and dismissive. I've been careful about who I give access to the project, because I know there are some corners of the suckless community that can be toxic sometimes, and I would never want ours to become one of them. I know that it can be easy to take rejection personally when you're campaigning for a favorite feature, but not being included in core doesn't mean that a feature is insignificant. There is just a high bar to clear for inclusion and retention of a feature - even I patch my dwl, knowing that what I need is not what everyone needs.

Hi fauxmight, Thanks for your contributions to dwl. I can tell there are some strong feelings here, so hopefully I can gently clear up the misconceptions and the mistaken statements/questions that arose from them. Keeping the codebase under a fixed SLOC has always been a top priority. More than feature parity with dwm - that's why dwl hasn't had a built-in bar since day one. :) So the statement "Parity with dwm is even the primary reason for insisting on adherence to 2000 SLOC" is not true. With an intentionally limited amount of code, we have to be very deliberate about how we choose to invest it. Several considerations are weighed against each other on a case-by-case basis: 1. What is the cost in terms of SLOC? 2. Does it have utility to the *vast majority* of users of dwl (i.e. nearly all)? 3. Is it something provided by dwm/Xlib? 4. Is it more important than some other feature which could be relegated to a patch? None of these trumps the others, so the questions in the second half of the post don't really make sense - they're based on the assumption that there is a simple priority order among these concerns, which isn't the case. <details> I do also want to note that the words chosen for your first couple of points sounds like they're intended to make the dwl developers sound rude and dismissive. I've been careful about who I give access to the project, because I know there are some corners of the suckless community that can be toxic sometimes, and I would never want ours to become one of them. I know that it can be easy to take rejection personally when you're campaigning for a favorite feature, but not being included in core doesn't mean that a feature is insignificant. There is just a high bar to clear for inclusion and retention of a feature - even I patch my dwl, knowing that what I need is not what everyone needs. </details>

fauxmight commented

2023-10-17 01:59:46 +02:00

(Migrated from github.com)

@djpohly Many thanks for your creation. There would be no passionate stances on any matters regarding dwl if you had not gifted us all with this creation in the first place.

My opinions are just that, opinions. They stand as they are. However, reading your reply, I recognize that I came off harshly and abrasively in my previous reply. That is neither constructive nor productive and I apologize.

@djpohly Many thanks for your creation. There would be no passionate stances on any matters regarding dwl if you had not gifted us all with this creation in the first place. My opinions are just that, opinions. They stand as they are. However, reading your reply, I recognize that I came off harshly and abrasively in my previous reply. That is neither constructive nor productive and I apologize.

dimkr commented

2023-10-17 02:02:22 +02:00

(Migrated from github.com)

(sorry to intrude the conversation)

(very grateful for dwl, I appreciate you and your work a lot)

pointer constraints

IMO the usefulness of this patch outweighs any benefits of having a SLOC limit.

forces us to think hard about what features are truly indispensable

As a maintainer, you can choose not to merge a PR until you're convinced it belongs in the "core" project and find it elegant enough. An arbitrary SLOC limit is not the only way (and IMO definitely not the best way) to keep things compact, maintainable and useful.

(sorry to intrude the conversation) (very grateful for dwl, I appreciate you and your work a lot) > * pointer constraints IMO the usefulness of this patch outweighs any benefits of having a SLOC limit. > **forces** us to think hard about what features are truly indispensable As a maintainer, you can **choose** not to merge a PR until you're convinced it belongs in the "core" project and find it elegant enough. An arbitrary SLOC limit is not the only way (and IMO definitely not the best way) to keep things compact, maintainable and useful.

sevz17 commented

2023-10-19 07:11:13 +02:00

(Migrated from github.com)

... dwl was created in response to discussions I read on the suckless MLs, with the intent of providing a Wayland option that adherents of the suckless philosophy could honestly try. ...

I'm interested in read those discussions, can you point me to the threads?.

I'm open to increasing the line limit for core dwl under the right circumstances, but I still feel that it's important that we have one. The SLOC restriction limits the amount of code we're responsible to maintain, forces us to think hard about what features are truly indispensable, and encourages us to innovate to keep code simple (e.g. bar -> stdout and session manager). I'm confident that we still have room to work with - whether that's refactoring, recognizing what can be done by cooperating with other programs, or upstreaming useful default/auto stuff to wlroots.

My intention of this is not to start to merge things like madmans, as dimkr pointed above, we can (and must) consider what features we introduce to core dwl (maybe add a clarification).
We can start to refactoring code, but we still need to look carefully about the protocols we currently implement, i.e: I think we need to revert 9071ce6c84 because we do not respond to the client when it request a different mode. I'm fine doing hacks to save a few lines, but not when it comes to not following protocols.

Is this proposal in the context of specific missing functionality?

It's not exclusive for it but part of the reason is pointer constraints.

Keeping the codebase under a fixed SLOC has always been a top priority. More than feature parity with dwm - that's why dwl hasn't had a built-in bar since day one. :) So the statement "Parity with dwm is even the primary reason for insisting on adherence to 2000 SLOC" is not true.

We need seriously rewrote that part of the readme, I always understood that the SLOC limit was because dwm.

With an intentionally limited amount of code, we have to be very deliberate about how we choose to invest it. Several considerations are weighed against each other on a case-by-case basis:
1. What is the cost in terms of SLOC?

2. Does it have utility to the _vast majority_ of users of dwl (i.e. nearly all)?

I have always considered dwl a compositor that anyone (with at least a basic knowledge of C) can use. I do not think is necessary to know how wayland works if you only want to use dwl. The problem here is that our users have to maintain patches (with functionality provided by the xserver) that they do not fully understand, which brings the risk of breaking the patches.
How would we know the needs of nearly all users of dwl?, actually how many users does dwl have?

3. Is it something provided by dwm/Xlib?

I want to add here the xorg-server, we talk about dwm/Xlib but not about the xorg-server, as pointed in the commit there is a big difference between X11 and Wayland, it's (as you know) that we have to be not only the window manager but also the server, the reason because dwm can exist with less than 2000 lines is because it does not have to do the things that the xserver does (i.e: touch, pointer-constraints, enable/disable outputs, handle input (I do not mean handle keybindings, I mean notify the clients about the events), rendering, and so on), wlroots does (most) part of this for us, but still we need to tell wlroots to do it (which consumes lines).

4. Is it more important than some other feature which could be relegated to a patch?

> ... dwl was created in response to discussions I read on the suckless MLs, with the intent of providing a Wayland option that adherents of the suckless philosophy could honestly try. ... I'm interested in read those discussions, can you point me to the threads?. > I'm open to increasing the line limit for core dwl under the right circumstances, but I still feel that it's important that we have one. The SLOC restriction limits the amount of code we're responsible to maintain, forces us to think hard about what features are truly indispensable, and encourages us to innovate to keep code simple (e.g. bar -> stdout and session manager). I'm confident that we still have room to work with - whether that's refactoring, recognizing what can be done by cooperating with other programs, or upstreaming useful default/auto stuff to wlroots. My intention of this is not to start to merge things like madmans, as dimkr pointed above, we can (and must) consider what features we introduce to core dwl (maybe add a clarification). We can start to refactoring code, but we still need to look carefully about the protocols we currently implement, i.e: I think we need to revert 9071ce6c848ce214939fb84f85ae77de86de88d7 because we do not respond to the client when it request a different mode. I'm fine doing hacks to save a few lines, but not when it comes to not following protocols. > Is this proposal in the context of specific missing functionality? It's not exclusive for it but part of the reason is pointer constraints. > Keeping the codebase under a fixed SLOC has always been a top priority. More than feature parity with dwm - that's why dwl hasn't had a built-in bar since day one. :) So the statement "Parity with dwm is even the primary reason for insisting on adherence to 2000 SLOC" is not true. We need seriously rewrote that part of the readme, I always understood that the SLOC limit was because dwm. > With an intentionally limited amount of code, we have to be very deliberate about how we choose to invest it. Several considerations are weighed against each other on a case-by-case basis: > > 1. What is the cost in terms of SLOC? > > 2. Does it have utility to the _vast majority_ of users of dwl (i.e. nearly all)? I have always considered dwl a compositor that anyone (with at least a basic knowledge of C) can use. I do not think is necessary to know how wayland works if you **only** want to use dwl. The problem here is that our users have to maintain patches (with functionality provided by the xserver) that they do not fully understand, which brings the risk of breaking the patches. How would we know the needs of nearly all users of dwl?, actually how many users does dwl have? > 3. Is it something provided by dwm/Xlib? > I want to add here the xorg-server, we talk about dwm/Xlib but not about the xorg-server, as pointed in the commit there is a big difference between X11 and Wayland, it's (as you know) that we have to be not only the window manager but also the server, the reason because dwm can exist with less than 2000 lines is because it does not have to do the things that the xserver does (i.e: touch, pointer-constraints, enable/disable outputs, handle input (I do not mean handle keybindings, I mean notify the clients about the events), rendering, and so on), wlroots does (most) part of this for us, but still we need to tell wlroots to do it (which consumes lines). > 4. Is it more important than some other feature which could be relegated to a patch?

👍 4

Fuseteam commented

2023-10-21 07:11:04 +02:00

(Migrated from github.com)

I would say the limited SLOC does promote hackability, i would never be able to do some of things i do now, if dwm wasn't that small of a codebase that allowed me to go in an hack things. i believe this would also be useful for dwl.

Things being in patch status gives a lot more flexibility as well, imo If users are applying patches they don't understand, we could spend time on documentating it in such a way that they do understand

I would say the limited SLOC does promote hackability, i would never be able to do some of things i do now, if dwm wasn't that small of a codebase that allowed me to go in an hack things. i believe this would also be useful for dwl. Things being in patch status gives a lot more flexibility as well, imo If users are applying patches they don't understand, we could spend time on documentating it in such a way that they do understand

sevz17 commented

2023-10-24 05:57:13 +02:00

(Migrated from github.com)

I would say the limited SLOC does promote hackability, i would never be able to do some of things i do now, if dwm wasn't that small of a codebase that allowed me to go in an hack things. i believe this would also be useful for dwl.

Sure, I don't want to remove the limit to end up with 5000 lines (I want to keep the SLOC low too!), unfortunately, for the reasons I pointed above I think we should remove it, I don't think it's good idea to keep raising the limit.

Things being in patch status gives a lot more flexibility as well, imo If users are applying patches they don't understand, we could spend time on documentating it in such a way that they do understand

We could, but for patches that implement a protocol the users first would have to read the protocol, and then read the docs the author made (note: I'm not going to write docs for patches except for my own). Which you may understand is a hassle to the users who just want add a protocol to their dwl

> I would say the limited SLOC does promote hackability, i would never be able to do some of things i do now, if dwm wasn't that small of a codebase that allowed me to go in an hack things. i believe this would also be useful for dwl. Sure, I don't want to remove the limit to end up with 5000 lines (I want to keep the SLOC low too!), unfortunately, for the reasons I pointed above I think we should remove it, I don't think it's good idea to keep raising the limit. > Things being in patch status gives a lot more flexibility as well, imo If users are applying patches they don't understand, we could spend time on documentating it in such a way that they do understand We could, but for patches that implement a protocol the users first would have to read the protocol, and then read the docs the author made (note: I'm not going to write docs for patches except for my own). Which you may understand is a hassle to the users who just want add a protocol to their dwl

sevz17 commented

2023-10-24 05:59:22 +02:00

(Migrated from github.com)

I'm open to increasing the line limit for core dwl under the right circumstances

@djpohly, I just thought about this while writing the previous reply.
What would those circumstances be?

> I'm open to increasing the line limit for core dwl under the right circumstances @djpohly, I just thought about this while writing the previous reply. What would those circumstances be?

zenrough commented

2023-10-26 10:59:12 +02:00

(Migrated from github.com)

I agree with this sentiment, I know basic C and use dwl daily. dwm misses proper parenting because it is not absolutely needed, which makes many java programs not work.
Therefore it is better to have the protocols implemented by default for reliability's sake.
Also having the protocols in by default probably allows people to choose their minimal toolset instead of just not being able to use dwl as it does not .

example input methods engines, in wayland you must have an protocol, if that protocol is not available, then many indic, sinetic and japonic speakers cannot use your windowmanager.
I already have an minor annoyence with the shift+number row, this is different from the us than the danish keyboard, only ! and % are the same, I have add a patch to let me use the windowmanager. This is very hard to do with protocols they are much more complex.

I agree with this sentiment, I know basic C and use dwl daily. dwm misses proper parenting because it is not absolutely needed, which makes many java programs not work. Therefore it is better to have the protocols implemented by default for reliability's sake. Also having the protocols in by default probably allows people to choose their minimal toolset instead of just not being able to use dwl as it does not . example input methods engines, in wayland you must have an protocol, if that protocol is not available, then many indic, sinetic and japonic speakers cannot use your windowmanager. I already have an minor annoyence with the shift+number row, this is different from the us than the danish keyboard, only ! and % are the same, I have add a patch to let me use the windowmanager. This is very hard to do with protocols they are much more complex.

fbushstone commented

2023-10-26 18:39:08 +02:00

(Migrated from github.com)

You can imagine that, to me at least, abandoning that feels like admitting that the diehards on the mailing list were right about Wayland versus X11.

Maybe, but I think the error these diehards make is not taking dependencies into account. wlroots is what, over 10x smaller than the whole of X11? So, a theoretical version of dwl that implements many protocols that causes it to be technically be smaller than dwm once you take dependencies into account. However, I'd consider most of these quality of life protocols extremely unnecessary (e.g. tearing, HDR, etc.) while others that affect the behavior of programs (pointer constraints) necessary.

>You can imagine that, to me at least, abandoning that feels like admitting that the diehards on the mailing list were right about Wayland versus X11. Maybe, but I think the error these diehards make is not taking dependencies into account. `wlroots` is what, over 10x smaller than the whole of X11? So, a theoretical version of `dwl` that implements many protocols that causes it to be technically be smaller than `dwm` once you take dependencies into account. However, I'd consider most of these quality of life protocols extremely unnecessary (e.g. tearing, HDR, etc.) while others that affect the behavior of programs (pointer constraints) necessary.

pm4rcin commented

2023-10-26 23:25:30 +02:00

(Migrated from github.com)

In my opinion there is some risk with abolishing the SLOC limit but it's a matter of good maintainers that understand why the project was created in the first place and which philosophy it follows and IMO we definitely have one. If we take a look at the list here we can see mpv as an example of software that "rocks" and it has much more than 2k SLOC checking several files as there are not many comments. Maybe it's twice as much as we have or more but I don't think there are people that consider this player bloated (maybe some lua haters if something like that exists) since it doesn't even have GUI.
I'll also add totally different point to discussion because there are arguments to increase or not to increase. The conservative vs pragmatic approach etc. So maybe it's a good time to make a list of things that xorg/dwm has but we don't and things we have already implemented. Then we could approximate how much of potentially new code has to be written for full parity and make some decisions on what to do with that because I presume right now nobody really remembers every small thing that we lack.
@djpohly you have mentioned mailing lists diehards but could you provide some links? I'd like to see how "external" people see the project and what are they afraid of.

However, I'd consider most of these quality of life protocols extremely unnecessary (e.g. tearing, HDR, etc.) while others that affect the behavior of programs (pointer constraints) necessary.

@fbushstone tearing is probably to be implemented with pointer constraints because both are related to games so it probably makes sense to have both or neither. As for HDR I agree because it's not even complete as of today on any DE (only SteamDeck tries something) and most people doesn't have display capable of that.

1. In my opinion there is some risk with abolishing the SLOC limit but it's a matter of good maintainers that understand why the project was created in the first place and which philosophy it follows and IMO we definitely have one. If we take a look at the list [here](https://suckless.org/rocks/) we can see `mpv` as an example of software that "rocks" and it has much more than 2k SLOC checking several files as there are not many comments. Maybe it's twice as much as we have or more but I don't think there are people that consider this player bloated (maybe some lua haters if something like that exists) since it doesn't even have GUI. 2. I'll also add totally different point to discussion because there are arguments to increase or not to increase. The conservative vs pragmatic approach etc. So maybe it's a good time to make a list of things that `xorg`/`dwm` has but we don't and things we have already implemented. Then we could approximate how much of potentially new code has to be written for full parity and make some decisions on what to do with that because I presume right now nobody really remembers every small thing that we lack. 3. @djpohly you have mentioned mailing lists diehards but could you provide some links? I'd like to see how "external" people see the project and what are they afraid of. > However, I'd consider most of these quality of life protocols extremely unnecessary (e.g. tearing, HDR, etc.) while others that affect the behavior of programs (pointer constraints) necessary. @fbushstone tearing is probably to be implemented with pointer constraints because both are related to games so it probably makes sense to have both or neither. As for HDR I agree because it's not even complete as of today on any DE (only SteamDeck tries something) and most people doesn't have display capable of that.

timmypidashev commented

2023-11-08 19:43:14 +01:00

(Migrated from github.com)

Dropping the sloc limit should only be if dwl is to implement more core features such as #504. However, I still tend to agree with @sevz17. Adding features not required to actually run dwl should be handled by a patch. However, the problem arises when a multitude of patches have to support each others features... it can get messy fast.

zoriya commented

2023-11-19 11:22:05 +01:00

First-time contributor

I feel dropping SLOC limit will in turn promote hackability. This might sound weird at first, but I feel like every dwl user needs to add patch for basic functionalities, so adding custom patches is harder and take more effort to maintain (more conflicts...).

I feel like I should patch dwl not to make apps work, but to customize my workflow. Adding more wayland protocols and dropping the sloc limit sounds like a good direction to me, even tho I don't know much about maintaining dwl.

I feel dropping SLOC limit will in turn promote hackability. This might sound weird at first, but I feel like every dwl user needs to add patch for basic functionalities, so adding custom patches is harder and take more effort to maintain (more conflicts...). I feel like I should patch dwl not to make apps work, but to customize my workflow. Adding more wayland protocols and dropping the sloc limit sounds like a good direction to me, even tho I don't know much about maintaining dwl.

👍 2

sevz17 commented

2023-11-22 01:34:24 +01:00

(Migrated from github.com)

I feel dropping SLOC limit will in turn promote hackability. This might sound weird at first, but I feel like every dwl user needs to add patch for basic functionalities, so adding custom patches is harder and take more effort to maintain (more conflicts...).

I feel like I should patch dwl not to make apps work, but to customize my workflow. Adding more wayland protocols and dropping the sloc limit sounds like a good direction to me, even tho I don't know much about maintaining dwl.

I totally agree with this

> I feel dropping SLOC limit will in turn promote hackability. This might sound weird at first, but I feel like every dwl user needs to add patch for basic functionalities, so adding custom patches is harder and take more effort to maintain (more conflicts...). > > I feel like I should patch dwl not to make apps work, but to customize my workflow. Adding more wayland protocols and dropping the sloc limit sounds like a good direction to me, even tho I don't know much about maintaining dwl. I totally agree with this

dimkr commented

2023-11-25 16:07:16 +01:00

Member

Another candidate for upstreaming if the SLOC limit is dropped: output-power-management (#525).

sevz commented

2023-12-07 21:55:38 +01:00

Posting in both GH and Codeberg to make sure nobody misses this.

I'll merge this in a month (2024-01-08), so if anyone has something against this please add a comment (in Codeberg)

@djpohly I tried to answer your concerns but you didn't reply, I also asked you if you would disappear again, it has been two months since that and of course you disappeared again. I'm removing you from the Codeberg organization, thank you for creating dwl, but at this point I can no longer consider you a dwl developer.

> _Posting in both GH and Codeberg to make sure nobody misses this._ I'll merge this in a month (2024-01-08), so if anyone has something against this please add a comment (in [Codeberg](https://codeberg.org/dwl/dwl/pulls/497)) @djpohly I tried to answer your concerns but you didn't reply, I also asked you if you would disappear again, it has been two months since that and of course you disappeared __again__. I'm removing you from the Codeberg organization, thank you for creating dwl, but at this point I can no longer consider you a dwl developer.

👍 5

sevz manually merged commit a73afc66ab into main

2024-01-11 04:42:37 +01:00

Rows
Columns

drop SLOC limit #497