Хотел было забрать блог difrex, но:

$ curl https://dynamic.lessmore.pw/idec/u/e/difrex.blog
difrex.blog
error: Internal error

Хм. Это я сломал что-то в базовом протоколе :).

Работает только со смещением сейчас

curl https://dynamic.lessmore.pw/idec/u/e/difrex.blog/-250:250
difrex.blog
2fDZ67P8JkchA9Rh4If4
2NszlFTgvhakzz7dIfvc
ML8cpSyzyOKaFA6Lx1NF
8TtPHu5T7oo3GSXdDYc5
U6ZYZxgYz2sq01L96zZz
igt9lCsui5qE9AICtdgP
mTWsJXVOAljita3sgDOK
V0hj3Z0QjFxpluaaiKvI
b91aGfRgRLJWfB1q60bg
pNfzXBddGbSy7AW7slpz
4fmEizz5kjk4UcQf7VIJ
OxdmEiQJIZqrqjCUNp2i
ojRAXNp7wzVIF9GBetZn
z5UV57mUeyhAmFsaMUq0

Спасибо, поправлю.

Fixed

> Fixed
Теперь есть другая проблема. Возможно, с моим фетчером.
В выводе у тебя нет последнего перевода строки. То-есть, на запрос -1:1, к примеру, приходит MsgId без \n. Как к этому относиться? Нужно ли мне переделывать?

> Хм, вот про newline в конце интересно. Это у нас нигде не описано, но и проблем ни у кого не возникало

Нужно решение комитета. )
Мне не сложно подправить, но это именно будет хак. Дополнительный блок условный. Заметил только благодаря адаптивному фетчу, который делает пробы по 1 id. Так бы просто последнее сообщение бы не взял и всё.

> Мне не сложно подправить, но это именно будет хак. Дополнительный блок условный.
А почему так? Я код не хочу ща читать - лень, но ты разве не разбираешь ответ в слайс? Типа,

messages := make(map[string][]string)
echoList := strings.Split(getBody(resp.Body))
var currentEcho string
for i := range echoList {
  if echoList[i] == "" {
    continue
  }
  if isEcho(echoList[i]) {
    currentEcho = echoList[i]
  }
  if isMessage(echoList[i]) {
    messages[currentEcho] = append(messages[currentEcho], echoList[i])
  }
}

> А почему так? Я код не хочу ща читать - лень, но ты разве не разбираешь ответ в слайс? Типа,

Почему так, вопрос, который я тоже могу задать: "Разве ты не делаешь просто Printf каждого из id? Зачем вырезать последний \n?

Дело в том, что я старался писать строго. Строка с переводом строки - это однозаначность. Например, пустая строка - это тоже пустая строка и \n.

В системе, когда у нас последняя строка не содержит \n, мы не можем отличить ситуацию, прочиталась ли строка целиком?

Например, вот функция, которая используется везде при работе с сетью:

func http_req_lines(url string, fn func(string) bool) error {
	resp, err := http.Get(url)
	if err != nil {
		return err
	}
	defer resp.Body.Close()
	reader := bufio.NewReader(resp.Body)
	for {
		line, err := reader.ReadString('\n')
		if err != nil && err != io.EOF {
			return err
		}
		line = strings.TrimSuffix(line, "\n")
		if err == io.EOF {
			break
		}
		if !fn(line) {
			break
		}
	}
	return nil
}

Обрати внимание, что if err === io.EOF стоит ПЕРЕД fn(line).

А вот правка, чтоб сработало с твоей нодой:

                if err == io.EOF {

			if line != "" { /* no eol in last line? broken node? */
				fn(line)
			}
                        break
                 }

Если же я перенесу fn(line) перед err == io.EOF, то fn(line) будет вызываться для последнего \n у других нод, которые делают \n в каждой строке.

Я лично считаю, что \n быть должен, но в как бы мы не решили, это должно быть прописано в стандарте, кмк.

Ну, в общем давай подождем остальных, что скажут. По мне так '\n' в конце списка эх необязателен, т.к. не относится к данным.

Т.е. я считаю, что "\n" - это разделитель списка и если в конец вносить его, то получится, что последний элемент списка - это всегда пустая строка.

Но в случае чего, я могу добавить перенос строки.

> В системе, когда у нас последняя строка не содержит \n, мы не можем отличить ситуацию, прочиталась ли строка целиком?
Это справедливо только для имен эх, а вот id сообщения всегда можно понять прочитался ли он полностью.

> Т.е. я считаю, что "\n" - это разделитель списка и если в конец вносить его, то получится, что последний элемент списка - это всегда пустая строка.

Мой довод, в основном, будет таким.

В UNIX все текстовые файлы традиционно заканчиваются на \n.

https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline

Стандарт POSIX определяет строку так:

> 3.206 Line
> A sequence of zero or more non- <newline> characters plus a terminating <newline> character.

Зафиксируем это и не ошибёмся. :)

Difrex> Ну, в общем давай подождем остальных, что скажут. По мне так '\n' в конце списка эх необязателен, т.к. не относится к данным.

'\n' в конце это однозначное и ожидаемое поведение. Мне кажется, что делать стоит единообразно. У меня даже emacs в файлах в конце '\n' ставит :)

Difrex> Т.е. я считаю, что "\n" - это разделитель списка и если в конец вносить его, то получится, что последний элемент списка - это всегда пустая строка.

В стандарте вроде про newline ничего не сказано, поэтому предусматривается, что "\n" - это лишь разделитель списка, и в конце он необязателен

В нодах и клиентах принято использовать логику, по которой принимают и то, и другое. Но, думаю, для лучшей совместимости с unix-утилитами стоит явно закрепить в стандарте, чтобы newline в конце присутствовал

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

> У меня даже emacs в файлах в конце '\n' ставит :)
У меня тоже. Но это все таки данные не совсем для человека.

Ты же не будешь править тело сообщения поинта если оно пришло без \n в конце, а просто запишешь в базу.

// Newline в конце добавлю, но фетчер у меня умеет и так и так.

> У меня тоже. Но это все таки данные не совсем для человека.

Ну как, curl можно автоматизировать. Я так и делал, когда переносил данные с ноды, генерировал скриптом запросы, парсил вывод. Удобнее с \n это делать.

> Ты же не будешь править тело сообщения поинта если оно пришло без \n в конце, а просто запишешь в базу.

Лучше я промолчу о том, что я делаю с сообщением поинта, а то вы меня тут заклюёте =)

> // Newline в конце добавлю, но фетчер у меня умеет и так и так.

Угу, отпишись тогда, я от тебя хочу взять fetch difrex.blog (ну и назад забирай тогда её у меня =)

Сделал исправление тоже, поставил на тебя фетч (blog.difrex). Ожидаю взаимного фетча. ;)

Пофиксил, фетчу тебя :)