LINUX.ORG.RU

Удалить символ конца строки в CL


0

4

Здравствуйте, всё никак не могу при считывании CSV файла в Хэш-таблицу, символ перевода строки.

вот код:

(defun парсер-CSV (file Хэш-таблица)
;Обнуление строк и столбцов
  (setf Строка 0
		Столбец 0)
;Открытие файла
  (with-open-file (Поток file :direction :input)
;итерирование по потоку из файла
    (loop
       for Строка-потока = (read-line Поток nil)
	   ;если строка не равна nil
       while Строка-потока
	   do(progn(incf Строка);увеличение строки на одну еденицу
	   (setf Столбец 0);Сброс значения столбца до нуля
	   (loop for var in (cl-ppcre:split ";" Строка-потока);итерирование строки по столбцам
	   do(progn (incf Столбец);увеличение строки на еденицу
	   (setf(gethash (Format nil "~a,~a" Строка Столбец) Хэш-таблица)var)))))))

Просто записывается в хэш вместе с символом и потом если эта ячейка вставляется в середину строки то каретка переводится на следующую строку. Как я пробовал решить проблему могу написать если нужно. В емаксе этот символ непечатаемый отображается как «^M» но в инспекторе «Return». Простое сравнение на eql не работает....

Ответ на: комментарий от anonymous

> Не надо ее после каждого запроса изменять.

после получения запроса перед запуском лямбды

устанавливается контекст



Раскройте же секрет использования это чудной техники в контексте CL, каким образом можно установить контекст вычислений для лямбды? Грэхэм говорит про хэш-таблицу с кусками кода, а в ссылке просто указывался ключ. Т.е. если «установка контексте для лямбды» и возможно с помощью какого-нибудь грубого хака и изменения оригинального кода реализации (хотя я о таком ничего не слышал), то в любом случае Грэхэм использовал другой подход.

Другими словами, сделать масштабируемое решение из viaweb никаким

переписыванием не было возможно, если оно таковым не было изначально.



Как так? Любое веб-приложение можно переписать полностью так, что пользователь этого даже не заменит. Взять и написать заново точно так же выглядящее для пользователя приложения можно множеством различных способов.

archimag ★★★
()
Ответ на: комментарий от anonymous

> Во-вторых, в поддержку этой гипотезы у тебя только один аргумент

- «продолжения масштабируемыми быть не могут»


Вы вообще о чём в конце то концов?

Мы эту тему уже обсуждали и тогда остановились на том, что серилизация продолжений и передача их через куки имеют ограниченную область применения, а другие варианты ещё хуже. Если у вас было что сказать на эту тему, то надо было говорить там. Повторять то обсуждения у меня желания нет.

Но вы опять выпали из контекста обсуждения и при этом ещё и мои фразы стараетесь вырвать из контекста.

archimag ★★★
()
Ответ на: комментарий от archimag

Раскройте же секрет использования это чудной техники в контексте CL, каким образом можно установить контекст вычислений для лямбды?

(defvar *x*)
(defun f () (print x))

(setq *x* 20) ;установили контекст
(f) ;вызвали лямбду

или

(eval `(f)) ;вызвали лямбду
если там именно кусок кода хранился. Ваистену совершенно нетривиальная метода. Тупой Грэхем бы никогда, ну никогда до такого додуматься бы не смог. Вопрос тут в единственном - устанавливал ли Грехэм контекст или сохранял с лямбдой? Если он хранил куски кода, то контекст он устанавливал. Если саму лямбду - мог сохранять с лямбдой. Во втором случае, действительно, выходит немасштабируемое решение. Но оно легко переделывается в явную передачу контекста через запрос. Ах, постой, там же был CGI? Ну тогда он сохранял код и сериализовал контекст, других вариантов нет. Вопрос - сохранял ли он контекст на сервере, но даже если да, тут уж вообще требуется минимум изменений для сериализации в запросе, фактически, надо переписать функции (де)сереализации контекста и все.

anonymous
()
Ответ на: комментарий от archimag

> зять и написать заново точно так же выглядящее для пользователя приложения можно множеством различных способов.

Множеством различных - но не каким угодно. Если состояние где-то сохранялось, то оно так и должно где-то сохраняться, иначе логика работы _в чем-то_ но будет изменена. И тут собственно один вариант - если раньше состояние хранилось на сервере, то теперь его надо передавать к/от юзеру, что при желании можно увидеть. И в любом случае проще было тут слегка изменить CL-вариант, чем пидорасить все с нуля на цепепе.

anonymous
()
Ответ на: комментарий от archimag

> Вы вообще о чём в конце то концов?

Я о причине переписывания виавеба. А ты о чем?

Мы эту тему уже обсуждали и тогда остановились на том, что серилизация продолжений и передача их через куки имеют ограниченную область применения

1. в общем удобнее через строку запроса чем через куки 2. чем она ограничена?

Ты опять фантазируешь, меня это начинает утомлять.

Если у вас было что сказать на эту тему, то надо было говорить там.

Тему зачем-то перенесли в talks. Я даже зарегался, но там стоит ограничение на минимальное количество постов.

anonymous
()

Ура! Продолжение про продолжения. Подписался.

anonymous
()
Ответ на: комментарий от anonymous

> (defvar *x*)

Зашибись, вы предлагаете конвертировать лексические переменные в динамические? Тогда вообще о каких лексических замыканиях идёт речь? При таком подходе ни замыканя, ни продолжения вообще нах не нужны. Прям ELisp какой-то.

archimag ★★★
()
Ответ на: комментарий от anonymous

> 1. в общем удобнее через строку запроса чем через куки

2. чем она ограничена?


Тем, что о таких вариантах вменяемым веб-разработчикам вообще должно быть стыдно даже говорить.

archimag ★★★
()
Ответ на: комментарий от archimag

> При таком подходе ни замыканя, ни продолжения вообще нах не нужны.

Ну так Грэхем и пишет, что у него там «типа» замыкания и продолжения, а на самом деле сохранялись куски кода, выдираемые макросом.

Зашибись, вы предлагаете конвертировать лексические переменные в динамические? Тогда вообще о каких лексических замыканиях идёт речь?

На самом деле я предлагаю конвертировать локальные переменные в глобальные, потому что локальный контекст вызванного продолжения де-факто глобален. А вообще - ты знаешь другой способ протащить контекст в случае использования CGI? То есть у тебя лямбда - это просто `(lambda () (print x)), например, ясно же, что перед тем, как делать ее eval тебе надо установить значение х. Какая разница будет эта х лексической или динамической в данном случае? Сама лямбда этого даже «не заметит».

anonymous
()
Ответ на: комментарий от archimag

> Тем, что о таких вариантах вменяемым веб-разработчикам вообще должно быть стыдно даже говорить.

Сможет, ты все-таки ответишь, чем ограничена? Просто мне непонятно - все время веб-разработчики передавали информацию о состоянии через строку запроса и с этим не было никаких проблем. И ничего стыдного. Но вот только попытайся передать _ту же самую_ информацию в контексте вызова продолжения - все, уже стыдно. Где тут логика?

anonymous
()
Ответ на: комментарий от anonymous

> И еще раз повторю - решение на с++/perl по определению имело те же недостатки, что и оригинал.

Переходи с химии на что-нибудь растительное иначе быстро и плохо кончишь.

LamerOk ★★★★★
()
Ответ на: комментарий от anonymous

Давай я лучше тебе помогу это сделать:

решение на whatever по определению имело те же недостатки, что и оригинал.

решение на whatever по определению имело те же недостатки


whatever по определению имело те же недостатки


whatever по определению имело те же


по определению имело те же


по определению те же


по определению

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

А теперь обрати внимание на то, что там не просто решение на whatever, а решение на whatever, которое эмулировало логику работу оригинала.

anonymous
()
Ответ на: комментарий от anonymous

> которое эмулировало логику работу оригинала.

А теперь объясни, с чего ты наполнил смысл слова «эмулировало» смыслом слова «копировало»?

Твой тезис лего расширяется до совершенно абсурдного «решение на одном языке по определению имеет те же недостатки, что и на любом другом».


Архимаг совершенно правильно тебе сказал, что у веб-приложения начинку можно поменять совершенно произвольно. Если тебе не очевидны такие вещи, это значит только то, что ты (правильного) понятия не имеешь, как работает стек веб-технологий.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> Архимаг совершенно правильно тебе сказал, что у веб-приложения начинку можно поменять совершенно произвольно.

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

anonymous
()
Ответ на: комментарий от anonymous

> нам надо менять не произвольно а так, чтобы логика работы оставалась той же. В частности - надо сохранять состояние.

Это ты с какого потолка взял такие требования? В общем случае к изменению начинки веб-софта требования только одно - шоп пользователь ничего не заметил. Унутрях можно менять что угодно как угодно. Можно менять файлы на сикль или наоборот, можно менять cgi на выделенного демона и т.д. Нет никакой причины, чтобы делая заново логику виавеба, повторять все те косяки, что были сделаны грэхемом.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> шоп пользователь ничего не заметил.

вообще-то это более строго требование, чем «сохранение логики работы». Можно сохранить логику работы, так что ты льешь воду на мою мельницу.

Можно менять файлы на сикль или наоборот, можно менять cgi на выделенного демона и т.д.

Поменять файлы на сикль - это изменение логики работы приложения? У нормальных людей это легкий рефакторинг двух ф-й.

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

Ну, во-первых, Грэхем говорит, что косяки они повторили (т.к. по сути написали интерпретатор на сях для старого лиспокода). Допустим, это не так. Тогда, во-вторых, ты, видимо, меня прослушал - речь вообще исключительно о передаче состояния. Если состояние было и где-то хранилось, то это состояние и в переделанной версии тоже будет существовать, и оно должно будет где-нибудь храниться. Вопрос тут - где? Допустим, в Грэхемовской версии оно хранилось на сервере, а его переложили в те же куки. И тут мы подходим к следующему. Итак, в-третьих. Разговор шел вообще о чем? О том, зачем виавеб был переписан. Если прав Архимаг - то есть дело в хранении состояния на сервере (предположим у Грэхема хранилось на сервере) - то зачем переписывать виавеб целиком? Можно было переписать те несколько ф-й, которые отвечали за де/сереализацию, загрузку и сохранение состояния так, чтобы состояние хранилось как в новой версии. Это было бы на порядок проще, чем переписывать с нуля, велосипедить руками интерпретатор для части лиспо-кода, который не удалось заменить, и отказываться от части фич. Если же Архимаг не прав - то есть были другиче причины для того, чтобы переписать - то тогда действительно, можно предположить, что в решении Грэхема и впрямь были указанные Архимагом недочеты. но это уже не важно - ведь переписывали все равно по другйо причине. А недочеты убрали просто походя - ну реально, раз переписываем, то почему бы сразу и не пофиксить досадные мелочи?

anonymous
()
Ответ на: комментарий от anonymous

> вообще-то это более строго требование

Поменять файлы на сикль - это изменение логики работы приложения?


У тебя какое-то своеобразное понимание логики _работы_ приложения.

речь вообще исключительно о передаче состояния. Если состояние было и где-то хранилось, то это состояние и в переделанной версии тоже будет существовать,


В общем случае, это ложное утверждение. Если менять логику работы (хотя ты вряд ли понимаешь смысл этого слова), вместо этого состояния можно получить либо комбинации других состояний, либо вообще его убрать.

Можно было переписать те несколько ф-й, которые отвечали за де/сереализацию, загрузку и сохранение состояния так, чтобы состояние хранилось как в новой версии.


Это бессмысленное утверждение, проистекающее из твоего непонимания понятия «логика работы». Может перевод на слова «реализация»/«имплементация» как-то поможет тебе понять, о чём была речь.

Если прав Архимаг - то есть дело в хранении состояния на сервере


Читай тред еще раз. Архимаг не про какое-то вшивенькое «хранение состояний» говорил, а про само технологическое решение. Впрочем, раз ты не понимаешь, что такое «логика работы», то понятие «решение» для тебя заведомо пусто.

Прости, мой друг, но мы оперируем понятиями из слишком разных уровней.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> У тебя какое-то своеобразное понимание логики _работы_ приложения.

Логика работы - это, например «сохранить данные», «загрузить данные», а куда и как мы их будем сохранять/загружать - это уже не логика. Это детали реализации, которые не принципиальны.

В общем случае, это ложное утверждение.

Нет.

вместо этого состояния можно получить либо комбинации других состояний

Это софистика. До этого сохраняли состояние, теперь сохраняем состояние, которое является комбинацией других состояний. ничего не изменилось - просто назвали другими словами. Один черт то, что мы сохраняли, то нам сохранять и придется, как это ни называй.

либо вообще его убрать.

Не получится. Если состояние убрать - логика работы изменится. Во всяком случае достаточно сильно для того, чтобы пользователь это сразу заметил.

Это бессмысленное утверждение, проистекающее из твоего непонимания понятия «логика работы». Может перевод на слова «реализация»/«имплементация» как-то поможет тебе понять, о чём была речь.

«логика работы» и «реализация» - это как раз ортогональные понятия. Так вот, когда переписывали виавеб, то должны были сохранить логику работы (тот факт, что есть некоторое состояние и оно где-то хранится). Но могли поменять реализацию - то есть те самые упомянутые выше ф-и. и это было заведомо проще (причем намного) чем переписывать все с нуля.

Архимаг не про какое-то вшивенькое «хранение состояний» говорил

Именно про это он и говорил. Будь внимательнее. Архимаг сказал, что решение немасштабируемо, потом что оно использует континуации, для которых следует хранить состояние. Если не понимаешь о чем разговор - не лезь. Хотя какие тебе континуации, если ты даже логику от реализации отличить не способен.

anonymous
()
Ответ на: комментарий от anonymous

> Логика работы - это, например «сохранить данные», «загрузить данные», а куда и как мы их будем сохранять/загружать - это уже не логика. Это детали реализации, которые не принципиальны.

В этом твоя ошибка. Данные не существуют сами по себе. Данные - способ реализации логики. Разная логика - разные данные.

Если состояние убрать - логика работы изменится.


Правильно.

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


Не правильно. Кто тебе сказал, что речь идёт о данных, видимых пользователю?

«логика работы» и «реализация» - это как раз ортогональные понятия.


Я и говорю, ты придаешь понятиям, которыми оперируешь, какой-то свой особый уличный смысл.

Архимаг сказал, что решение немасштабируемо, потом что оно использует континуации, для которых следует хранить состояние.


Это ты будь внимательнее. Вот о чём шла речь:

http://www.linux.org.ru/jump-message.jsp?msgid=6064943&cid=6080576

«Хранение состояний» лишь один косяков всего решения. Ты возбух, что без кода виавеб - это всё туфта. Тебе привели пруфы. Теперь ты юлишь, и пытаешься выехать на совершенно смешном тезисе, что те, кто переделывал систему должны были «повторить логику реализации». Я, насколько мог, постарался тебе объяснить бредовость этого тезиса. Если ты не можешь этого понять - это уж не моя вина.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> Данные не существуют сами по себе. Данные - способ реализации логики. Разная логика - разные данные.

конечно. Но если требуется, чтобы пользователь не заметил разницы - то часть данных всегда будет совпадать (та часть, которую собственно видит пользователь). И состояние - это как раз та часть (потому что пользователь видит состояние).

Не правильно. Кто тебе сказал, что речь идёт о данных, видимых пользователю?

А кто тебе сказал, что нет? Я смотрю на слова Грехэма - он использовал продолжения, чтобы сохранять данные о состоянии программы (собственно продолжения по определению именно состояние и сохраняют). Это как раз тот вид данных, который пользователь всегда видит.

Я и говорю, ты придаешь понятиям, которыми оперируешь, какой-то свой особый уличный смысл.

Я придаю им тот смысл, который общепринят. Если ты его не понимаешь - займись самообразованием.

«Хранение состояний» лишь один косяков всего решения.

Ну так ты читай внимательно то, что сам цитируешь. Архимаг называет единственный косяк - хранение состояния (если ты невнимательно читал дискуссию поясняю - Архимаг уверен, что приложения, основанные на продолжениях, не могут быть масштабируемы, т.к. продолжения сохраняют состояние на сервере. это, конечно, не верно (можно сохранять и не на сервере), но до Архимага сей факт никак не дойдет, он рогом уперся и все). Пункт 3 смешон - кто мешает заменить одну из реализаций CL другой реализацией? Аналогично пункт 2 - чтобы отвязатьсяо т cgi нужен минимум изменений.

Ты возбух, что без кода виавеб - это всё туфта. Тебе привели пруфы.

В том и дело, что мне не привели ни одного пруфа. Все утверждения Архимага основываются на том, что МОЖЕТ БЫТЬ виавеб перестал выдерживать нагрузки, из-за того, что МОЖЕТ БЫТЬ Грехем использовал немасштабируемый вариант продолжений (Грехэм - идиот раз), что МОЖЕТ БЫТЬ Грехэм не знал ничего о декомпозиции (Грэхем - идиот дважды) в результате чего сериализирующий состояния код был размазан по всему приложению, что МОЖЕТ БЫТЬ Грэхем нагло пиздит, когда называет совершенно другие причины переписывания виавеба. Другими словами, Грэхем - дважды идиот и пиздабол. Ни одного не то что пруфа - а хотя бы затхлого аргумента, который подтвердил бы его точку зрения, Архимаг не привел за все время. Все основывается на том, что МОЖЕТ БЫТЬ это было так. Но почему это должно быть именно так, как хочется Архимагу, если все факты (слова Грэхема, особенности использованных технологий, очевидность ряда решений) против? С какой стати следует верить Архимагу, который не знает ничего о том, как работал виавеб, а не Грэхему, который уж точно знает как и явно больше знает о причинах переписывания - не как Архимаг, производя нереальные цепочки того, что МОГЛО БЫ БЫТЬ, а основываясь на информации из первых рук?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.