cc65-devel Mailing List for cc65
cc65 - a freeware C compiler for 6502 based systems
Brought to you by:
gpz
Menu
▾
▴
cc65-devel — cc65 Development
You can subscribe to this list here.
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(75) |
Jun
(146) |
Jul
(34) |
Aug
(44) |
Sep
(44) |
Oct
(15) |
Nov
(15) |
Dec
(41) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2014 |
Jan
(5) |
Feb
(14) |
Mar
(335) |
Apr
(101) |
May
(28) |
Jun
(4) |
Jul
|
Aug
(7) |
Sep
(41) |
Oct
(27) |
Nov
(17) |
Dec
(6) |
| 2015 |
Jan
(21) |
Feb
(9) |
Mar
(12) |
Apr
(14) |
May
(58) |
Jun
(48) |
Jul
(26) |
Aug
(16) |
Sep
(16) |
Oct
|
Nov
(27) |
Dec
(1) |
| 2016 |
Jan
(39) |
Feb
(9) |
Mar
(4) |
Apr
(17) |
May
(53) |
Jun
(46) |
Jul
(12) |
Aug
(9) |
Sep
(6) |
Oct
(4) |
Nov
|
Dec
(5) |
| 2017 |
Jan
(26) |
Feb
(24) |
Mar
(57) |
Apr
(19) |
May
(91) |
Jun
(110) |
Jul
(21) |
Aug
(21) |
Sep
(11) |
Oct
(13) |
Nov
(37) |
Dec
(15) |
| 2018 |
Jan
(2) |
Feb
(21) |
Mar
(14) |
Apr
(4) |
May
|
Jun
(2) |
Jul
(17) |
Aug
(35) |
Sep
(56) |
Oct
(4) |
Nov
(5) |
Dec
(3) |
| 2019 |
Jan
(9) |
Feb
|
Mar
(14) |
Apr
(12) |
May
(46) |
Jun
(42) |
Jul
(25) |
Aug
|
Sep
(2) |
Oct
(27) |
Nov
(8) |
Dec
|
| 2020 |
Jan
(5) |
Feb
(15) |
Mar
(4) |
Apr
(13) |
May
(8) |
Jun
(15) |
Jul
(82) |
Aug
(8) |
Sep
(5) |
Oct
(9) |
Nov
(22) |
Dec
(23) |
| 2021 |
Jan
(2) |
Feb
(58) |
Mar
(20) |
Apr
(30) |
May
(19) |
Jun
(2) |
Jul
|
Aug
(11) |
Sep
(2) |
Oct
(5) |
Nov
(4) |
Dec
|
| 2022 |
Jan
(15) |
Feb
|
Mar
(13) |
Apr
(22) |
May
(9) |
Jun
(7) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
|
Nov
(23) |
Dec
|
| 2023 |
Jan
(17) |
Feb
|
Mar
(4) |
Apr
(5) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(12) |
Dec
(2) |
| 2024 |
Jan
(21) |
Feb
(14) |
Mar
(15) |
Apr
(1) |
May
|
Jun
(23) |
Jul
(17) |
Aug
(3) |
Sep
(2) |
Oct
(2) |
Nov
(1) |
Dec
(2) |
| 2025 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(15) |
Jun
|
Jul
(11) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2026 |
Jan
(3) |
Feb
(6) |
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Janne J. <ice...@gm...> - 2026-04-20 06:23:17
|
> I used cc65 to write a small 1541 disk speed benchmark. I noticed that while using cbm_open() + cbm_write(), the writing speed is almost ~10x higher than reading via cbm_open() + cbm_read(). The test method is testing sequential read / write speed. I configured a 16KB buffer w/ 0 then write to disk to test the writing speed. I tested on VICE and C64U, got the same result. Here's a code snippet I implemented: https://github.com/meow-watermelon/c64/blob/master/diskspeed/diskspeed.c#L57-L85 > Could anyone show me some hints? Thanks in advance. Without even knowing, my guess is that your writes are (at least in part) benchmarking filling up the buffer, and not writing (the last sector) to disk. For reads, that is of course not possible, so you get truer numbers from it. A possible improvement would be to printf() after the close, might help, or worst case, ask for a small read after the write and see how long it takes until that finishes, since it will have to flush the writes presumably in order to get a new read in. -- May the most significant bit of your life be positive. |
|
From: Eric L. <hom...@gm...> - 2026-04-19 01:49:53
|
Hi, I used cc65 to write a small 1541 disk speed benchmark. I noticed that while using cbm_open() + cbm_write(), the writing speed is almost ~10x higher than reading via cbm_open() + cbm_read(). The test method is testing sequential read / write speed. I configured a 16KB buffer w/ 0 then write to disk to test the writing speed. I tested on VICE and C64U, got the same result. Here's a code snippet I implemented: https://github.com/meow-watermelon/c64/blob/master/diskspeed/diskspeed.c#L57-L85 Could anyone show me some hints? Thanks in advance. Eric |
|
From: Oliver S. <ol...@we...> - 2026-02-12 00:11:58
|
Hi,
Yes, indeed. It was fixed by acqn years ago IIRC (and it only "worked" by
> chance for some specific situations before).
Thanks for pointing out :-)
I'd write something like
>
> char *display[3] = {"Wait", "Load", "Paus"};
>
> myself (because incomplete types look wrong to me in any case)
Thanks for your input!
Regards,
Oliver
|
|
From: <gr...@gm...> - 2026-02-11 20:51:30
|
Yes, indeed. It was fixed by acqn years ago IIRC (and it only "worked" by
chance for some specific situations before).
I'd write something like
char *display[3] = {"Wait", "Load", "Paus"};
myself (because incomplete types look wrong to me in any case)
Am Mittwoch, 11. Februar 2026, 20:37:18 Mitteleuropäische Normalzeit schrieb
Mark J. Reed:
> > char display[][] = {"Wait", "Load", "Paus"};
>
> AFAIK that's never been legal in C. If cc65 used to allow it, I'd say that
> was a bug that has now been fixed?
>
> On Wed, Feb 11, 2026 at 12:28 PM Oliver Schmidt via cc65-devel <
>
> cc6...@li...> wrote:
> > Hi,
> >
> > Does really nobody have anything to say about my question(s) below?
> >
> > Wondering,
> > Oliver
> >
> > On Tue, Jan 27, 2026 at 1:18 AM Oliver Schmidt <ol...@we...> wrote:
> >> Hi,
> >>
> >> the line
> >>
> >> char display[][] = {"Wait", "Load", "Paus"};
> >>
> >> used to compile. Now I get
> >>
> >> Array of incomplete element type 'char[]'
> >>
> >> I'd like to verify if this change in behavior is intended. If yes, is
> >>
> >> char display[][5] = {"Wait", "Load", "Paus"};
> >>
> >> the expected fix? Or is there another, more elegant way?
> >>
> >> Thanks in advance,
> >> Oliver
> >
> > _______________________________________________________
> > cc6...@li...
> > https://lists.sourceforge.net/lists/listinfo/cc65-devel
--
http://hitmen.eu http://rr.pokefinder.org
http://vice-emu.sourceforge.net http://magicdisk.untergrund.net
"Virtual" means never knowing where your next byte is coming from.
|
|
From: Mark J. R. <mar...@gm...> - 2026-02-11 19:37:44
|
> char display[][] = {"Wait", "Load", "Paus"};
AFAIK that's never been legal in C. If cc65 used to allow it, I'd say that
was a bug that has now been fixed?
On Wed, Feb 11, 2026 at 12:28 PM Oliver Schmidt via cc65-devel <
cc6...@li...> wrote:
> Hi,
>
> Does really nobody have anything to say about my question(s) below?
>
> Wondering,
> Oliver
>
>
> On Tue, Jan 27, 2026 at 1:18 AM Oliver Schmidt <ol...@we...> wrote:
>
>> Hi,
>>
>> the line
>>
>> char display[][] = {"Wait", "Load", "Paus"};
>>
>> used to compile. Now I get
>>
>> Array of incomplete element type 'char[]'
>>
>> I'd like to verify if this change in behavior is intended. If yes, is
>>
>> char display[][5] = {"Wait", "Load", "Paus"};
>>
>> the expected fix? Or is there another, more elegant way?
>>
>> Thanks in advance,
>> Oliver
>>
> _______________________________________________________
> cc6...@li...
> https://lists.sourceforge.net/lists/listinfo/cc65-devel
>
--
Mark J. Reed <mar...@gm...>
|
|
From: Oliver S. <ol...@we...> - 2026-02-11 17:28:15
|
Hi,
Does really nobody have anything to say about my question(s) below?
Wondering,
Oliver
On Tue, Jan 27, 2026 at 1:18 AM Oliver Schmidt <ol...@we...> wrote:
> Hi,
>
> the line
>
> char display[][] = {"Wait", "Load", "Paus"};
>
> used to compile. Now I get
>
> Array of incomplete element type 'char[]'
>
> I'd like to verify if this change in behavior is intended. If yes, is
>
> char display[][5] = {"Wait", "Load", "Paus"};
>
> the expected fix? Or is there another, more elegant way?
>
> Thanks in advance,
> Oliver
>
|
|
From: <gr...@gm...> - 2026-02-11 17:24:18
|
Am Mittwoch, 11. Februar 2026, 17:59:00 Mitteleuropäische Normalzeit schrieb Physiker via cc65-devel: > How can I use this include file if it contains duplicates? E.g OPC_NOP_abx Well, you can't - the dupes need to be commented out of course (like other dupes already are). I guess "6502X" isn't used in the tests, so noone noticed this before :) (It would be great if you could fix that file accordingly and make a PR) -- http://hitmen.eu http://rr.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net When animal-rights activists and right-to-life protesters are marching outside your laboratory, then you know you've definitely made progress in your artificial life research. <Donald A. Smith> |
|
From: Physiker <vor...@gm...> - 2026-02-11 16:59:12
|
How can I use this include file if it contains duplicates? E.g OPC_NOP_abx |
|
From: Oliver S. <ol...@we...> - 2026-01-27 00:19:01
|
Hi,
the line
char display[][] = {"Wait", "Load", "Paus"};
used to compile. Now I get
Array of incomplete element type 'char[]'
I'd like to verify if this change in behavior is intended. If yes, is
char display[][5] = {"Wait", "Load", "Paus"};
the expected fix? Or is there another, more elegant way?
Thanks in advance,
Oliver
|
|
From: <gr...@gm...> - 2026-01-24 14:03:46
|
Am Samstag, 24. Januar 2026, 11:22:56 Mitteleuropäische Normalzeit schrieb
Physiker via cc65-devel:
> Die Fehlermeldung verschwindet, wenn ich den Aufruf über den function ptr
> auskommentiere.
>
> Bsp.:
>
> typedef int fnc_t(int);
> void myfunc(fnc_t *func){
> ...
> (*func)(10);
> ...
> }
Please make a ticket on github
--
http://hitmen.eu http://rr.pokefinder.org
http://vice-emu.sourceforge.net http://magicdisk.untergrund.net
When Im working I code in whatever language is required, Ive even had to code
on a Mac.
<radiantx>
|
|
From: Physiker <vor...@gm...> - 2026-01-24 10:23:13
|
Die Fehlermeldung verschwindet, wenn ich den Aufruf über den function ptr auskommentiere.
Bsp.:
typedef int fnc_t(int);
void myfunc(fnc_t *func){
...
(*func)(10);
...
}
|
|
From: Vorsichtphysiker <vor...@gm...> - 2025-09-29 19:11:49
|
I just want to tell that I will open an issue, soon. I found out several things. In short: The CA65 assembler does not distinguish between parentheses in the macro parameter list and parentheses as part of expressions. The white space between the macro name and replace expression does not terminate an eventual parameter list. The assembler just takes the first pair of parentheses as the start/end of the macro parameters. This is broken at least since january 2022. Macros containing a parameter list did not show the issue, because then the assembler considers eventual following parentheses as part of the replace expression and not part of the parameter list. This enabled a simple workaroundm so that one could define macros with parentheses in the expression part, anyway. If you just put an empty pair of parenthesis directly after the macro name, the following parentheses were also considered as part of the replace expression and not part of the parameter list like in the case above. Due to a code change in july this year, the workaround is not working anymore. This is the reason I just realized the problem now and not already some years ago. I will provide a bisect log, my testcode and my conclusion. However, it needs a little time to write all that down into the ticket. So I beg for a little patience. This is a typical example of the manifestation of a long existing bug due to some apparently unrelated code change. Yours Monte Am 28.09.25 um 13:17 schrieb Physiker via cc65-devel: > I would like to tell the last version I know which worked, but the > hash before the pull scrolled out of my terminal buffer. So I realized > too late to give you that info. Hope I can add later on. > > 28.09.2025 13:04:13 groepaz--- via cc65-devel > <cc6...@li...>: > > Am Sonntag, 28. September 2025, 12:11:00 Mitteleuropäische > Sommerzeit schrieb > Stefan via cc65-devel: > > I recently pulled my cc65 checkout, recompiled, installed and > then realized > that some CA65 macros I use for years don't work anymore. > Version: cc65 > V2.19 - Git 93c1b659e > > > It seems that parentheses in arguments are not avaluated > correctly, anymore. > However, parentheses in parameter definitions seem to work but > not the same > as before. > Here is an isolated testcase: > > (1) .define foo 100 > (2) .define bar foo+200 > (3) .define baz (foo+200) > (4) .define x1() foo+200 > (5) .define x2() (foo+200) > (6) .define x3(par) foo+par > > (1), (2) are unproblematic, (6) also. > I can understand that (4) and (5) are conercases, anyway they > worked before. > (3) does not work too. > > Here is the assembler output: > > ca65 define_test.s > Assembling include file #3 > define_test.s:11: Error: Expected a parameter name but found > ‘100’ > define_test.s:9: Note: Expanded from macro here > define_test.s:11: Error: Expected ‘)’ but found ‘100’ > define_test.s:9: Note: Expanded from macro here > define_test.s:12: Error: Expected a parameter name but found ‘)’ > define_test.s:13: Error: Expected a parameter name but found ‘)’ > > > Please open a bug ticket - and provide a complete test case for > each :) > Without one its not really possible to tell what is happening, and > why. > > -- > > http://hitmen.eu http://rr.pokefinder.org > http://vice-emu.sourceforge.net http://magicdisk.untergrund.net > > Digital files cannot be made uncopyable, any more than water can > be made not > wet. > > > > > > > _______________________________________________________ > cc6...@li... > https://lists.sourceforge.net/lists/listinfo/cc65-devel > > > > _______________________________________________________ > cc6...@li... > https://lists.sourceforge.net/lists/listinfo/cc65-devel |
|
From: Physiker <vor...@gm...> - 2025-09-28 11:17:58
|
I would like to tell the last version I know which worked, but the hash before the pull scrolled out of my terminal buffer. So I realized too late to give you that info. Hope I can add later on. 28.09.2025 13:04:13 groepaz--- via cc65-devel <cc6...@li...>: > Am Sonntag, 28. September 2025, 12:11:00 Mitteleuropäische Sommerzeit schrieb > Stefan via cc65-devel: >> I recently pulled my cc65 checkout, recompiled, installed and then realized >> that some CA65 macros I use for years don't work anymore. Version: cc65 >> V2.19 - Git 93c1b659e >> >> >> It seems that parentheses in arguments are not avaluated correctly, anymore. >> However, parentheses in parameter definitions seem to work but not the same >> as before. >> Here is an isolated testcase: >> >> (1) .define foo 100 >> (2) .define bar foo+200 >> (3) .define baz (foo+200) >> (4) .define x1() foo+200 >> (5) .define x2() (foo+200) >> (6) .define x3(par) foo+par >> >> (1), (2) are unproblematic, (6) also. >> I can understand that (4) and (5) are conercases, anyway they worked before. >> (3) does not work too. >> >> Here is the assembler output: >> >> ca65 define_test.s >> Assembling include file #3 >> define_test.s:11: Error: Expected a parameter name but found ‘100’ >> define_test.s:9: Note: Expanded from macro here >> define_test.s:11: Error: Expected ‘)’ but found ‘100’ >> define_test.s:9: Note: Expanded from macro here >> define_test.s:12: Error: Expected a parameter name but found ‘)’ >> define_test.s:13: Error: Expected a parameter name but found ‘)’ > > Please open a bug ticket - and provide a complete test case for each :) > Without one its not really possible to tell what is happening, and why. > > -- > > http://hitmen.eu http://rr.pokefinder.org > http://vice-emu.sourceforge.net http://magicdisk.untergrund.net > > Digital files cannot be made uncopyable, any more than water can be made not > wet. > > > > > > > _______________________________________________________ > cc6...@li... > https://lists.sourceforge.net/lists/listinfo/cc65-devel |
|
From: <gr...@gm...> - 2025-09-28 11:03:25
|
Am Sonntag, 28. September 2025, 12:11:00 Mitteleuropäische Sommerzeit schrieb Stefan via cc65-devel: > I recently pulled my cc65 checkout, recompiled, installed and then realized > that some CA65 macros I use for years don't work anymore. Version: cc65 > V2.19 - Git 93c1b659e > > > It seems that parentheses in arguments are not avaluated correctly, anymore. > However, parentheses in parameter definitions seem to work but not the same > as before. > Here is an isolated testcase: > > (1) .define foo 100 > (2) .define bar foo+200 > (3) .define baz (foo+200) > (4) .define x1() foo+200 > (5) .define x2() (foo+200) > (6) .define x3(par) foo+par > > (1), (2) are unproblematic, (6) also. > I can understand that (4) and (5) are conercases, anyway they worked before. > (3) does not work too. > > Here is the assembler output: > > ca65 define_test.s > Assembling include file #3 > define_test.s:11: Error: Expected a parameter name but found ‘100’ > define_test.s:9: Note: Expanded from macro here > define_test.s:11: Error: Expected ‘)’ but found ‘100’ > define_test.s:9: Note: Expanded from macro here > define_test.s:12: Error: Expected a parameter name but found ‘)’ > define_test.s:13: Error: Expected a parameter name but found ‘)’ Please open a bug ticket - and provide a complete test case for each :) Without one its not really possible to tell what is happening, and why. -- http://hitmen.eu http://rr.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net Digital files cannot be made uncopyable, any more than water can be made not wet. |
|
From: Stefan <vor...@gm...> - 2025-09-28 10:11:14
|
<div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">I recently pulled my cc65 checkout, recompiled, installed and then realized that some CA65 macros I use for years don't work anymore. Version: cc65 V2.19 - Git 93c1b659e<br></span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);"> </span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">It seems that parentheses in arguments are not avaluated correctly, anymore.</span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">However, parentheses in parameter definitions seem to work but not the same as before.</span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);"> </span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">Here is an isolated testcase:</span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);"> </span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">(1) .define foo 100<br>(2) .define bar foo+200<br>(3) .define baz (foo+200)<br>(4) .define x1() foo+200<br>(5) .define x2() (foo+200)<br>(6) .define x3(par) foo+par</span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);"> </span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">(1), (2) are unproblematic, (6) also.</span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">I can understand that (4) and (5) are conercases, anyway they worked before.</span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">(3) does not work too.</span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);"> </span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">Here is the assembler output:</span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);"> </span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">ca65 define_test.s <br>Assembling include file #3<br>define_test.s:11: Error: Expected a parameter name but found ‘100’<br>define_test.s:9: Note: Expanded from macro here<br>define_test.s:11: Error: Expected ‘)’ but found ‘100’<br>define_test.s:9: Note: Expanded from macro here<br>define_test.s:12: Error: Expected a parameter name but found ‘)’<br>define_test.s:13: Error: Expected a parameter name but found ‘)’<br></span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);"> </span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);">Greetings Monte</span></div> <div style="font-family: verdana;font-size: 12.0px;color: rgb(0,0,0);"><span style="background-color: rgb(255,255,255);"> </span></div> |
|
From: <gr...@gm...> - 2025-07-03 07:01:22
|
Am Mittwoch, 2. Juli 2025, 22:31:02 Mitteleuropäische Sommerzeit schrieb groepaz--- via cc65-devel: > Am Mittwoch, 2. Juli 2025, 22:22:40 Mitteleuropäische Sommerzeit schrieb > Paul > Moore: > > Was there some really nasty stuff on a few threads. I must have missed it > > If you roam around recent PRs and Issues, you will find it. > > I have already deleted one or two comments already and warned again for that > matter - so the next time it will be a ban (if someone knows if/how i can > "mute" someone instead of complete ban, please tell - i couldnt find such > option) So well, yfi - there is no way to "mute". But he couldnt stop and so i had to try BAN - and it works. (What sucks is that you cant edit the posts anymore to remove the bickering - you have to unblock to do that. kinda weird) -- http://hitmen.eu http://rr.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net Don't force it --- get a bigger hammer. |
|
From: Janne J. <ice...@gm...> - 2025-07-03 06:34:39
|
> https://github.com/colinleroy/a2tools/?tab=coc-ov-file#readme > > I have read through it and wouldn't mind just using that. Its basically how we > handle things :) > I'd like to hear some other opinions (and if someone wants to suggest another > wording - go ahead) Those looked ok, would not mind if cc65 would follow those or similar CoC. -- May the most significant bit of your life be positive. |
|
From: <gr...@gm...> - 2025-07-02 21:58:44
|
Am Mittwoch, 2. Juli 2025, 22:32:01 Mitteleuropäische Sommerzeit schrieb groepaz--- via cc65-devel: > Am Mittwoch, 2. Juli 2025, 22:04:47 Mitteleuropäische Sommerzeit schrieb > > groepaz--- via cc65-devel: > > I'm tweaking that text a bit right now, and will make a PR with that > > version. > > https://github.com/cc65/cc65/pull/2766 > > very slightly tweaked I have also already comitted templates for PRs and Issues. They might be a bit too verbose right now - we can easily tweak that of course (feel free to make a PR) -- http://hitmen.eu http://rr.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net Gut gesoffen und null gecodet ist besser als schlecht gecodet und null gesoffen. <TheRyk/Mayday> |
|
From: Paul M. <pau...@ho...> - 2025-07-02 20:55:19
|
Was there some really nasty stuff on a few threads. I must have missed it ________________________________ From: groepaz--- via cc65-devel <cc6...@li...> Sent: Wednesday, July 2, 2025 1:04:47 PM To: cc65-devel <cc6...@li...> Cc: gr...@gm... <gr...@gm...> Subject: Re: [cc65-devel] Code of conduct? Am Mittwoch, 2. Juli 2025, 21:33:41 Mitteleuropäische Sommerzeit schrieb Stefan Wessels via cc65-devel: > * What is achieved by a CoC in practice? If someone is not nice, will a > written piece somewhere actually change their behavior? In my experience, > people who act poorly don’t care about guidelines. Correct. For the people who are acting up, this makes little to no difference. Its mostly a way to explictly express that we care and will act if needed - ie the CoC is for the nice people, not for the idiots (they dont care). > * Who decides or > arbitrates whether something is in breach of the CoC? I think that can be a > slippery slope. Ultimatively its the Maintainer (me). And i can take some beating - so don't worry. I like to think that social control mechanisms will work with this too. > * What about enforceability? Will someone in breach be banned? Do > you need a CoC to justify banning someone from contributing? Personally, I > feel a bit uneasy about blanket CoCs because they can feel like a > preemptive finger-wag to everyone, when the majority of people are acting > in good faith. That said, if someone maintaining the project feels a CoC is > necessary and helpful, I respect that. Either way, if a contributor crosses > a line, I’d fully support the maintainer telling them: “I won’t tolerate > this behavior—cut it out or be banned” (from making PRs or whatever is > appropriate). Look at the recent events. When the maintainer tells someone to do this and that and its NOT written somehwere, it only ends up in silly discussions. It just makes the life of the maintainers easier, by being able to point at the file "look you knew it before". I'm tweaking that text a bit right now, and will make a PR with that version. -- https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhitmen.eu%2F&data=05%7C02%7C%7C0b21d38893604cc610f508ddb9a3c309%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638870835234463381%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vJn9f5NOX779qZ3uCmPXTBpMMbAdoc8oOwrMGXV1cVc%3D&reserved=0<http://hitmen.eu/> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frr.pokefinder.org%2F&data=05%7C02%7C%7C0b21d38893604cc610f508ddb9a3c309%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638870835234490088%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ahPjPQTZU%2F7t1775N3TGIKg%2B1V5Do3Qa09hDwI5uXhQ%3D&reserved=0<http://rr.pokefinder.org/> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvice-emu.sourceforge.net%2F&data=05%7C02%7C%7C0b21d38893604cc610f508ddb9a3c309%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638870835234503335%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aRhjzhzhszT1Ku1lWyf9mSdUiCQzW5JjMex1vrdtOzI%3D&reserved=0<http://vice-emu.sourceforge.net/> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmagicdisk.untergrund.net%2F&data=05%7C02%7C%7C0b21d38893604cc610f508ddb9a3c309%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638870835234516581%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UgbZ%2FlAtmys%2BxC0NLnG7v0ObUmYPzgBKrRoNZEOW9mg%3D&reserved=0<http://magicdisk.untergrund.net/> last time I tried the c64-test on a date she fell asleep after just 4 hours of demos. That was when I knew she wasnt right for me. i mean.. falling asleep after just a few hours of c64 demos? We have a word for that stuff on the scene. L A M E. (: <Jucke/G*P> _______________________________________________________ cc6...@li... https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fcc65-devel&data=05%7C02%7C%7C0b21d38893604cc610f508ddb9a3c309%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638870835234529205%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=U68iV8v1wRXfRob9aYOq9QVb3yjY8aj3M0uFiBylPTs%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/cc65-devel> |
|
From: <gr...@gm...> - 2025-07-02 20:32:14
|
Am Mittwoch, 2. Juli 2025, 22:04:47 Mitteleuropäische Sommerzeit schrieb groepaz--- via cc65-devel: > I'm tweaking that text a bit right now, and will make a PR with that > version. https://github.com/cc65/cc65/pull/2766 very slightly tweaked -- http://hitmen.eu http://rr.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net Ach, lass mich doch mit deinen Argumenten in Ruhe. Ich habe schon eine Meinung! |
|
From: <gr...@gm...> - 2025-07-02 20:31:10
|
Am Mittwoch, 2. Juli 2025, 22:22:40 Mitteleuropäische Sommerzeit schrieb Paul Moore: > Was there some really nasty stuff on a few threads. I must have missed it If you roam around recent PRs and Issues, you will find it. I have already deleted one or two comments already and warned again for that matter - so the next time it will be a ban (if someone knows if/how i can "mute" someone instead of complete ban, please tell - i couldnt find such option) -- http://hitmen.eu http://rr.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net I thought I wanted a careerer, but it turns out, I just wanted a paycheck. |
|
From: <gr...@gm...> - 2025-07-02 20:04:55
|
Am Mittwoch, 2. Juli 2025, 21:33:41 Mitteleuropäische Sommerzeit schrieb Stefan Wessels via cc65-devel: > * What is achieved by a CoC in practice? If someone is not nice, will a > written piece somewhere actually change their behavior? In my experience, > people who act poorly don’t care about guidelines. Correct. For the people who are acting up, this makes little to no difference. Its mostly a way to explictly express that we care and will act if needed - ie the CoC is for the nice people, not for the idiots (they dont care). > * Who decides or > arbitrates whether something is in breach of the CoC? I think that can be a > slippery slope. Ultimatively its the Maintainer (me). And i can take some beating - so don't worry. I like to think that social control mechanisms will work with this too. > * What about enforceability? Will someone in breach be banned? Do > you need a CoC to justify banning someone from contributing? Personally, I > feel a bit uneasy about blanket CoCs because they can feel like a > preemptive finger-wag to everyone, when the majority of people are acting > in good faith. That said, if someone maintaining the project feels a CoC is > necessary and helpful, I respect that. Either way, if a contributor crosses > a line, I’d fully support the maintainer telling them: “I won’t tolerate > this behavior—cut it out or be banned” (from making PRs or whatever is > appropriate). Look at the recent events. When the maintainer tells someone to do this and that and its NOT written somehwere, it only ends up in silly discussions. It just makes the life of the maintainers easier, by being able to point at the file "look you knew it before". I'm tweaking that text a bit right now, and will make a PR with that version. -- http://hitmen.eu http://rr.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net last time I tried the c64-test on a date she fell asleep after just 4 hours of demos. That was when I knew she wasnt right for me. i mean.. falling asleep after just a few hours of c64 demos? We have a word for that stuff on the scene. L A M E. (: <Jucke/G*P> |
|
From: Stefan W. <swe...@em...> - 2025-07-02 19:46:56
|
Hi, I have some questions, mainly out of curiosity and not opposition. * What is achieved by a CoC in practice? If someone is not nice, will a written piece somewhere actually change their behavior? In my experience, people who act poorly don’t care about guidelines. * Who decides or arbitrates whether something is in breach of the CoC? I think that can be a slippery slope. For example, is: "CoC are an SJW thing": I have a hard time figuring how social justice is a bad thing, and the state of the world, IMHO, tend to show that the alternative is by far worst. not in breach of trolling, insulting or derogatory comments, and personal or political attacks? I’m not taking a position on the statement itself—just pointing out that any perspective can be read as having a bias, and someone may take offense. * What about enforceability? Will someone in breach be banned? Do you need a CoC to justify banning someone from contributing? Personally, I feel a bit uneasy about blanket CoCs because they can feel like a preemptive finger-wag to everyone, when the majority of people are acting in good faith. That said, if someone maintaining the project feels a CoC is necessary and helpful, I respect that. Either way, if a contributor crosses a line, I’d fully support the maintainer telling them: “I won’t tolerate this behavior—cut it out or be banned” (from making PRs or whatever is appropriate). I’m completely open to being shown how my thinking here is off base. And honestly, I don’t need a reply—I’m very grateful to everyone who maintains and moderates, and I appreciate the work you do. The rest is just noise, but this is (currently ;) my perspective. All the best, Stefan On 7/2/2025 10:11:40 AM, groepaz--- via cc65-devel <cc6...@li...> wrote: Am Mittwoch, 2. Juli 2025, 09:41:04 Mitteleuropäische Sommerzeit schrieb Colin Leroy-Mira via cc65-devel: > Hi everyone, > > I made a little tour of the open and recently closed PRs this morning, and > have noticed there are a few new ones by a recent contributor with a very > unusual style of communication (to put it mildly). > > I am aware that not everybody is a fan of codes of conduct, but thought I'd > suggest the idea here anyway. [...] I used to be (very) anti CoC - _I_ don't need them, i can deal with those individuals quite well, i have a relatively high tolerance against flaming and swear words and personal attacks (and i have been moderating web forums for a long time - i have seen it all, those ppl are not new to me) And if needed, i can also switch into full berzerk troll mode (*) BUT i learned that this is not the case for everyone, and you can not expect everyone to be the same. Some people will just drop the ball and flee - and rightly so. https://github.com/colinleroy/a2tools/?tab=coc-ov-file#readme I have read through it and wouldn't mind just using that. Its basically how we handle things :) I'd like to hear some other opinions (and if someone wants to suggest another wording - go ahead) (*) i freely admit i was (hopefully) one of those people - those who know me a bit longer surely remember that. -- http://hitmen.eu http://rr.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net Some electronic components are now so small that more time is spent looking for them than using them. _______________________________________________________ cc6...@li... https://lists.sourceforge.net/lists/listinfo/cc65-devel [89a672ea-a7bf-422c-b847-03641f0909d0] |
|
From: <gr...@gm...> - 2025-07-02 17:11:25
|
Am Mittwoch, 2. Juli 2025, 09:41:04 Mitteleuropäische Sommerzeit schrieb Colin Leroy-Mira via cc65-devel: > Hi everyone, > > I made a little tour of the open and recently closed PRs this morning, and > have noticed there are a few new ones by a recent contributor with a very > unusual style of communication (to put it mildly). > > I am aware that not everybody is a fan of codes of conduct, but thought I'd > suggest the idea here anyway. [...] I used to be (very) anti CoC - _I_ don't need them, i can deal with those individuals quite well, i have a relatively high tolerance against flaming and swear words and personal attacks (and i have been moderating web forums for a long time - i have seen it all, those ppl are not new to me) And if needed, i can also switch into full berzerk troll mode (*) BUT i learned that this is not the case for everyone, and you can not expect everyone to be the same. Some people will just drop the ball and flee - and rightly so. https://github.com/colinleroy/a2tools/?tab=coc-ov-file#readme I have read through it and wouldn't mind just using that. Its basically how we handle things :) I'd like to hear some other opinions (and if someone wants to suggest another wording - go ahead) (*) i freely admit i was (hopefully) one of those people - those who know me a bit longer surely remember that. -- http://hitmen.eu http://rr.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net Some electronic components are now so small that more time is spent looking for them than using them. <Arthur C. Clarke> |
|
From: Mike F. <mik...@pr...> - 2025-07-02 14:52:42
|
I for one am not a fan; I realize my say means next to nothing, as I'm little more than a user, and haven't contributed anything super-meaningful to the project, but I've seen too much misuse and abuse. Don't get me wrong; I've seen some good ones (my favorite being SQLite's, which is kind of ridiculous despite the fact that I agree with it). I think most of what is in those codes of conduct is stuff that we all should have learned in grade school. Don't be a bully, or a liar, or a jerk. Be considerate of others. Basic stuff like that. But when those types of basic guidelines get treated like laws, these "codes" end up getting people kicked out of projects who shouldn't be. Then projects go from focusing on creating great software to political stuff that's unrelated, and bickering over petty stuff that doesn't affect the project and so on. And then, because it's open source, people who disagree always end up forking the project. Look at Gimp/Glimpse, and more recently the Wayland/X11/X-libre mess. It would be sad IMO to see cc65 go down that road. On the other hand, I was on a forum once where the guy running it had a code of conduct of simply, "be excellent to each other" (apparently taken from an 80s TV show I didn't see - I was too busy playing Nintendo or watching Ninja Turtles back then lol). I think if cc65 has to have one, it should be something like that. Simple, straightforward, not easily used to turn members on each other or single out groups of people for their politics or whatever. Anyway, I realize I'm not a core maintainer or even a minor contributor (yet - I would like to ask about that in a separate e-mail chain) so feel free to ignore me. :-D Sent with Proton Mail secure email. On Wednesday, July 2nd, 2025 at 3:41 AM, Colin Leroy-Mira via cc65-devel <cc6...@li...> wrote: > Hi everyone, > > I made a little tour of the open and recently closed PRs this morning, and have noticed there are a few new ones by a recent contributor with a very unusual style of communication (to put it mildly). > > I am aware that not everybody is a fan of codes of conduct, but thought I'd suggest the idea here anyway. As a relatively new contributor and not core maintainer, I won't argue for days on the subject if you folks are against it, but I'd still like to make a few points in favor of them. > > - they're specifically made to have a static reference of what is and what isn't acceptable from contributors, making it easier to get rid of toxic contributors without decisions seeming arbitrary > - they often discourage the most toxic people from even trying to crap all over the maintainers' work > - on the contrary, they tend to attract people with whom it is a pleasure to interact > - toxic contributors' contributions end up being net negative, putting more work on maintainers, be it having to constantly reply to nitpicking, gaslighting and refusal to understand simple things, mopping around behind subpar work (as already happened at least twice if I count correctly), or simply draining the fun out of the thing that is supposed to be fun to work on. > > As an aside, > - "CoC are an SJW thing": I have a hard time figuring how social justice is a bad thing, and the state of the world, IMHO, tend to show that the alternative is by far worst. > > On my own projects, I use one derived from https://www.contributor-covenant.org/ : > > https://github.com/colinleroy/a2tools/?tab=coc-ov-file#readme > > Here are a few more examples from large projects: > - https://www.mozilla.org/en-US/about/governance/policies/participation/ > - https://docs.kernel.org/process/code-of-conduct.html > - https://gcc.gnu.org/conduct.html > > And of course it would be totally possible to just roll our own. > > Have a nice day, and please know that I admire your patience in the recent PRs! :-) > > -- > Colin > > > _______________________________________________________ > cc6...@li... > https://lists.sourceforge.net/lists/listinfo/cc65-devel |
12 messages has been excluded from this view by a project administrator.
