[Csnd-dev] messaging system is a mess

[Csnd-dev] messaging system is a mess

Date	2022-03-01 12:14
From	Eduardo Moguillansky
Subject	[Csnd-dev] messaging system is a mess
	Hi, it should be possible to set the messaging flag (-m) in a state where: * no spurious messages are sent to stdout/stderr (version number, libsndfile messages, buffers size, etc) * any printing made by the user is actually being printed * errors and warnings, like compile errors, are also printed, since these are vital for the user At the moment there is no flag configuration that can achieve this. -m0 comes close but still prints the following --Csound version 6.17 (double samples) Feb 25 2022 [commit: f5b4258794a82c99f7d85f1807c6638f2e80ccac] libsndfile-1.0.31 sr = 44100.0, kr = 689.062, ksmps = 64 0dBFS level = 1.0, A4 tuning = 442.0 audio buffered in 256 sample-frame blocks reading 1024-byte blks of shorts from adc:system:capture (RAW) writing 1024 sample blks of 64-bit floats to dac:system:playback SECTION 1: -m16 suppresses everything, even the user print opcodes. -m4 (which should only print warnings) enables lots of other unwanted messages Would it be possible to make -m0 not print the above information?

Date	2022-03-01 12:46
From	Rory Walsh
Subject	Re: [Csnd-dev] messaging system is a mess
	Would it be possible to make -m0 not print the above information? This was implemented (by Victor), but after some discussion was reverted. The issue was that it had a knock on effect on existing systems that were using -m0 in its old form. The change meant that these systems no longer behaved as they used to, which in a way was breaking backward compatibility. I don't think most agree that the current messaging system is a mess, but changing the behaviour of a long standing command line flag was causing other issues. A new command line flag was suggested, but I'm not sure where we are with that. Btw, I'm merely acting as a messenger here. I've never looked at that code.

Date	2022-03-01 13:02
From	Eduardo Moguillansky
Subject	Re: [Csnd-dev] messaging system is a mess
	The problem with the last "fix" was that -m0 would disable everything, even error messages. This was in fact very confusing since a compile error or any critical message would get lost. Regarding backward compatibility, the previous behaviour was not what documented, so there was a defacto behaviour and a documented one: which should have priority? I don't think that removing the mentioned "header" from -m0 would brake any backwards compatibility and would look much less confusing for any project using csound as a library. In such a case a user might not even be aware of a csound process being run so the "information" being printed adds a lot of noise. On the other hand, errors are in fact needed since these would help the user report an error with the needed information. The added flag, "-m16" is not usable for this situation, since it suppresses everything: errors and even output generated in an orchestra itself via the print opcodes. I can send a PR, but I would like to know first if it would be accepted. On 01.03.22 13:46, Rory Walsh wrote: Would it be possible to make -m0 not print the above information? This was implemented (by Victor), but after some discussion was reverted. The issue was that it had a knock on effect on existing systems that were using -m0 in its old form. The change meant that these systems no longer behaved as they used to, which in a way was breaking backward compatibility. I don't think most agree that the current messaging system is a mess, but changing the behaviour of a long standing command line flag was causing other issues. A new command line flag was suggested, but I'm not sure where we are with that. Btw, I'm merely acting as a messenger here. I've never looked at that code.

Date	2022-03-01 13:16
From	Victor Lazzarini
Subject	Re: [Csnd-dev] [EXTERNAL] Re: [Csnd-dev] messaging system is a mess
	First, I don't agree it is in a mess. I put a lot if work to bring it to a more rational state. I also implemented user-facing changes but in the meeting we had, it was decided to reverse these as other people did not think certain messages were spurious. Then I found that I could add -m16 to suppress all messages, which is an important feature. Since Csound 6.x is in bugfix mode, any changes are to be directed to Csound 7. If someone wants to propose a new design for please go ahead. The code should be in a more manageable state to introduce modifications. Prof. Victor Lazzarini Maynooth University Ireland On 1 Mar 2022, at 12:46, Rory Walsh <rorywalsh@ear.ie> wrote: Warning This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. Would it be possible to make -m0 not print the above information? This was implemented (by Victor), but after some discussion was reverted. The issue was that it had a knock on effect on existing systems that were using -m0 in its old form. The change meant that these systems no longer behaved as they used to, which in a way was breaking backward compatibility. I don't think most agree that the current messaging system is a mess, but changing the behaviour of a long standing command line flag was causing other issues. A new command line flag was suggested, but I'm not sure where we are with that. Btw, I'm merely acting as a messenger here. I've never looked at that code.

Date	2022-03-01 13:26
From	Victor Lazzarini
Subject	Re: [Csnd-dev] [EXTERNAL] Re: [Csnd-dev] messaging system is a mess
	First, I am against a PR to Csound 6.x, we are not developing it any more. Second, if a design is proposed for Csound 7, it needs to be discussed here first. Steven was very adamant that changes were breaking backwards compatibility. The -m0 changes with error messages added back on were considered not to be backwards compatible. The problem I am finding is that this discussion keeps resurfacing every couple of months like in a circle. Prof. Victor Lazzarini Maynooth University Ireland On 1 Mar 2022, at 13:02, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote: Warning This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. The problem with the last "fix" was that -m0 would disable everything, even error messages. This was in fact very confusing since a compile error or any critical message would get lost. Regarding backward compatibility, the previous behaviour was not what documented, so there was a defacto behaviour and a documented one: which should have priority? I don't think that removing the mentioned "header" from -m0 would brake any backwards compatibility and would look much less confusing for any project using csound as a library. In such a case a user might not even be aware of a csound process being run so the "information" being printed adds a lot of noise. On the other hand, errors are in fact needed since these would help the user report an error with the needed information. The added flag, "-m16" is not usable for this situation, since it suppresses everything: errors and even output generated in an orchestra itself via the print opcodes. I can send a PR, but I would like to know first if it would be accepted. On 01.03.22 13:46, Rory Walsh wrote: Would it be possible to make -m0 not print the above information? This was implemented (by Victor), but after some discussion was reverted. The issue was that it had a knock on effect on existing systems that were using -m0 in its old form. The change meant that these systems no longer behaved as they used to, which in a way was breaking backward compatibility. I don't think most agree that the current messaging system is a mess, but changing the behaviour of a long standing command line flag was causing other issues. A new command line flag was suggested, but I'm not sure where we are with that. Btw, I'm merely acting as a messenger here. I've never looked at that code.

Date	2022-03-01 13:55
From	Rory Walsh
Subject	Re: [Csnd-dev] [EXTERNAL] Re: [Csnd-dev] messaging system is a mess
	My bad, I thought everything was reverted back to the 'mess' it was in. On Tue 1 Mar 2022, 1:26 p.m. Victor Lazzarini, <Victor.Lazzarini@mu.ie> wrote: First, I am against a PR to Csound 6.x, we are not developing it any more. Second, if a design is proposed for Csound 7, it needs to be discussed here first. Steven was very adamant that changes were breaking backwards compatibility. The -m0 changes with error messages added back on were considered not to be backwards compatible. The problem I am finding is that this discussion keeps resurfacing every couple of months like in a circle. Prof. Victor Lazzarini Maynooth University Ireland On 1 Mar 2022, at 13:02, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote: Warning This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. The problem with the last "fix" was that -m0 would disable everything, even error messages. This was in fact very confusing since a compile error or any critical message would get lost. Regarding backward compatibility, the previous behaviour was not what documented, so there was a defacto behaviour and a documented one: which should have priority? I don't think that removing the mentioned "header" from -m0 would brake any backwards compatibility and would look much less confusing for any project using csound as a library. In such a case a user might not even be aware of a csound process being run so the "information" being printed adds a lot of noise. On the other hand, errors are in fact needed since these would help the user report an error with the needed information. The added flag, "-m16" is not usable for this situation, since it suppresses everything: errors and even output generated in an orchestra itself via the print opcodes. I can send a PR, but I would like to know first if it would be accepted. On 01.03.22 13:46, Rory Walsh wrote: Would it be possible to make -m0 not print the above information? This was implemented (by Victor), but after some discussion was reverted. The issue was that it had a knock on effect on existing systems that were using -m0 in its old form. The change meant that these systems no longer behaved as they used to, which in a way was breaking backward compatibility. I don't think most agree that the current messaging system is a mess, but changing the behaviour of a long standing command line flag was causing other issues. A new command line flag was suggested, but I'm not sure where we are with that. Btw, I'm merely acting as a messenger here. I've never looked at that code.