7
添加--log-new（指定后）将恢复为file.ID.log每次运行创建单独日志文件的原始行为。添加--log-append（指定时）以附加模式打开日志文件。
Q
[ggerganov/llama.cpp]log.h：使生成单独的日志文件成为可选。
A
回答
1
我不能对代码说太多，但我 100% 同意添加此功能。我讨厌目前很难预测日志文件的实际名称。（当我有机会时我会测试一下。）
顺便说一句，如果--log-disable在没有日志记录的情况下编译时没有出现错误，那就太好了。
8
这听起来是个好主意，它可以更轻松地在具有相同命令行参数的构建之间进行切换。
我将在单独的 PR 中做到这一点，这个已经准备好了，我不想让它复杂化。
5
不想这么说，但我认为这可能会破坏某些东西。LOG_TEE似乎没有产生输出--log-disable。像个混蛋一样，在合并之前我没有抽出时间来测试它，但现在我在这里发牢骚！
7
@KerfuffleV2除非我错过了一些东西，否则就是以前的样子，是的，这是我最初忽略的一个有点奇怪的行为，但没有人抱怨，并且它使输出在禁用日志的情况下变得更加干净，所以我就这样保留了它。
仅在禁用日志的情况下进行编译，将 LOG_TEE 转换为正常的 fprintfs，以模拟日志实现之前的行为。
原因就在这里，打印到日志和打印到屏幕都会检查 LOG_TARGET 是否被禁用： https://github.com/ggerganov/llama.cpp/blob/d6069051de7165a4e06662c89257f5d2905bb156/common/log.h#L263-L272
一个简单的修复方法是LOG_TARGET != nullptr从第二个中删除if
但一切都取决于这是否被视为错误。
编辑：
是否需要--log-disable帮助--log-disable-file（禁用所有日志打印，与仅禁用打印到文件）？
6
除非我错过了什么，以前就是这样
我不知道...你可能是对的。我讨厌说一些负面的话，特别是因为我除了与你进行积极的互动之外什么也没有，但是……我有点讨厌日志系统。每次我在禁用它的情况下停止编译时都会遇到问题。
会
--log-disable和--log-disable-file
啊，不是真的。我想查看日志消息，我只是不想自动创建随机文件。
实际上，这些最新的问题是由于尝试在我的东西中使用它而产生的simple-inference。我的想法是，这是为 llama.cpp 提供的日志记录/输出工具，我可能应该在我的 llama.cpp 示例中使用它。printf如果存在的话，只使用所有原始数据似乎很奇怪。
我认为问题在于它并不像其他日志系统那样工作。对于大多数日志系统，您有各种级别，例如：DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL。您生成具有关联级别的日志消息，然后有消费者，例如文件输出、控制台输出等，您可以在其中设置您想要查看的级别。因此，如果我打开日志记录到文件，我可能会将级别设置为DEBUG，以便在我试图确定问题时记录所有内容。另一方面，对于控制台输出，我可能想将其设置为INFO或NOTICE。
printf然后应用程序可以生成日志消息，它们以相对良好的方式呈现，适合它们要去的地方，例如级别颜色或控制台的其他内容等。然后您基本上永远不必在应用程序中使用，只需依靠日志设施来做合理的事情。
但在这里，我并没有真正看到使用该系统的方法。LOG只是根本不去控制台。LOG_TEE有时只进入控制台。闲逛了这么久（抱歉，大脑已经睡着了）我猜你的意思是添加一个新--log-disable-file选项，使日志记录只转到控制台？我想这是可行的，但我觉得最合理的行为（没有重大变化）--log-disable与仅使用LLAMA_DISABLE_LOGS. 呵呵，这是不喜欢 cmake 选项的另一个原因：甚至无法禁用日志！
3
@KerfuffleV2，我实际上尝试将日志重写为更“现代”和通用的东西，但我被范围蠕变淹没了，我永远无法判断功能是否会真正最终被使用或会变得不必要的膨胀，所以我从未完成它。这是在#3219。
您应该能够在编译时禁用日志，仅举个例子，通过在包含“common”之前定义 LOG_DISABLE_LOGS
这将使您的示例（并且只有您的示例）始终像使用 LLAMA_DISABLE_LOGS 一样进行编译，而无需为 make 或 cmake 设置标志。
#define LOG_DISABLE_LOGS
#include "common.h"
7
@staviq 我很抱歉，我真的不应该写那篇文章。我想我大脑中防止我成为混蛋的过滤部分已经进入了睡眠状态。你可能会说我对此有点沮丧，但我通常不会写这样的东西。
但我对范围蔓延感到不知所措
我绝对知道那种感觉。我不认为它真的必须非常复杂或范围很大。我不知道它是否有帮助，但我可以告诉你我认为它的外观和范围：
只是允许使用我提到的级别进行日志记录。级别可以是一个枚举，因此它们是有序的，允许诸如if (level >= LOG_ERROR)匹配ERROR和之类的内容CRITICAL。对于控制台，>= WARNING可能会转到stderr或同等内容。debug.log我不认为添加多个文件目标真的会让事情变得更加困难（并且它对于将所有内容发送到、将普通消息发送到之类的事情很有用blah.log），但这可能并不是真正的关键功能。
在我看来，程序想要打印的任何内容都将是一行文本 - 因此末尾有换行符将通过日志设施。有一些例外情况，例如在生成令牌时打印出令牌或打印用户输入提示。
使用它的 API 通常看起来像是LOG(level, format_or_message)带有一些方便的别名，例如LOG_INFO(format_or_message)just doLOG(LOG_LEVEL_INFO, format_or_message)等。
如果你真的想变得更花哨，你也可以有一种记录方式，但仅限于非控制台目的地。因此，就像提示用户输入的情况一样，Prompting user for input除了正常提示之外，还可能存在不显示的日志消息。像这样的花里胡哨的东西或者能够指定额外的日志目的地是很好的，但与基本功能相比并不那么重要。
我并不是想告诉您要做什么或做任何事情，只是分享我对它的外观的看法，以防它在某种程度上对您有帮助。
我想我可能已经看到了，但从描述来看，它听起来像是内部的东西。不幸的是，我一直没有时间去尝试。
这将使您的示例（并且只有您的示例）始终编译，就像
printf如果我这样做的话，我还不如直接使用。:) 我不喜欢一般的日志记录或类似的想法。
6
很多人都有“这个”，而且凭直觉就明白。我会告诉你不要太担心它，但“这个”的具体细节通常会让你无论如何都会担心:)
你的想法非常有帮助，我会在某个时候回来记录 PR 的改进，特别是项目的其他部分开始使用日志，并且现在已经建立了某种用例基线。
我关于改进日志的最初想法已经与您的建议重叠，无论哪种方式，我们都非常感激。