Тайм-коды: Система контроля версий, Git, Событийно-ориентированное программирование 0:24 система контроля версий 4:25 diff утилита. Для отображения изменений 12:00 репозиторий. Слияние соединений в общий код (Merge) 12:17 reverse commit. Коммит-отмена 22:21 Распределенная система контроля версий. Git 26:18 bare (origin) repository. Центральный репозиторий 27:14 ручное слияние в случае конфликта версий 35:20 merge commit. Авто-слияние 36:50 команды Git: clone(склонировать), status(статус), diff (изменения), add(добавить), 42:20 commit(вклад), pull(подтянуть), push(запушить) 47:15 stash (спрятать), stash pop (достать) 50:53 head (голова ветки), rebase (на другую ветку) 52:22 fork (ответвиться), pull request (отправка на проверку) 52:46 Событийное или Событийно-ориентированное программирование - это про логику программы 54:57 иллюстрация программы с точки зрения времени её жизни и CPU 57:47 инициализация 58:03 Событие 59:49 Объект события (event). Очередь событий на обработку 1:03:15 непрерывный процесс 1:07:51 команды гита, код 1:09:28 Диспетчеризация, код пример 1:12:06 Обработчик событий. key_down_handler(event) 1:12:59 global глобальные переменные 1:13:58 команды гита, код 1:24:24 git for windows гит для винды
Тимофей Фёдорович, извините, за публичную критику -- я не смог нагуглить Вашу почту. Поэтому вынужден написать здесь. Команда git status "работает" в рабочем директории и индексируемой области (cache). Она не затрагивает то, что находится на удалённом репозитории (иначе ей тогда пришлось бы обращаться к нему). Не смотря на то, что я программист со стажем (предпенсионер уже), я с большим удовольствием смотрю Ваши видеоролики. Наверно даже не столько в качестве пособия для обучения самого себя, сколько для получения опыта при общении с теми, кто идёт в след за нами. Огромное Вам спасибо за Ваш труд! Вы делаете большой важности дело. Спасибо!
@Тимофей Хирьянов , насчёт переносов строк. TLDR: их не надо фиксить. 1. Пайчарм, редактируя файл, ставит те концы строк, которые указаны в его настройках: Editor > Code Style > Line separation. 2. ... но это не имеет значения, т.к. гит, если настроен правильно, автоматом при комитте их конвертирует. По умолчанию - он правильно настроен. Чтоб принудительно переводить все строки в линуксовые при pull и оставлять их таковыми при push, в gitconfig должно быть: [core] eol = lf autocrlf = input 3. ... но лучше - прям совсем принудительно, в каждом репозитории явно. Чтоб независимо от того, какие там настройки у юзера - в репозиторий всегда попадало с линуксовыми line-ending'ами, даже при комиттах из-под винды, даже с кривой настройкой гита. Для этого в .gitattributes репозитория в самом верху: # force auto-detection binary/text and always use unix line endings * text=auto eol=lf
По поводу команды git diff -- на времени лекции 1:20:14. Команда выводит строки у файлов, которые отличаются в рабочем директории и в индексной области. При этом команда ВЫДЕЛЯЕТ!!! окончания строк, которые выполнены на манер Виндовс (иначе говоря, используется окончание CRLF вместо LF). Это лечится. Для того чтобы отключить эти ВЫДЕЛЕНИЯ нужно чуть-чуть поправить файл конфигурации Гита. Это можно сделать в любом конфигурационном файле -- хоть в системном (который для всех юзеров, кто имеет учётную запись на компе), хоть в глобальном (который для конкретного юзера), хоть в локальном (который для конкретного локального репозитория). В конфигурационном файле нужно найти секцию [core] и записать в неё параметр: [core] whitespace = cr-at-eol Мне проще (да я и люблю это дело) править конфиги ручками. Но, в прочем, это можно выполнить командой самого Гита: $ git config --global core.whitespace = cr-at-eol Соответственно, вместо --global нужно указать --system или --local, в зависимости от того на каком уровне хотите поправить ВЫДЕЛЕНИЯ. Кроме того, можно попробовать поиграться с параметром autocrlf в этой же секции. Тимофей Фёдорович, я сейчас озвучу очень известную истину. Мы про неё периодически забываем, а потом комплексуем. А напрасно! -- Технологии в современном мире развиваются с огромной скоростью. И чтобы быть компетентны во многих и многих вопросах нужно уделять чрезвычайно много времени. Но у всех на всё про всё 24 часа в сутках. Поэтому не удивительно, что мы (специалисты) порой чего-то не знаем. И это -- нормальное явление для современного динамичного мира. Плохо не "не знать", плохо -- не хотеть знать! С уважением Жевак Александр Антонович
Ой-ой! Я извиняюсь! Уважаемую общественность я ввёл в заблуждение. В команде: $ git config --global core.whitespace = cr-at-eol знак "равно" не нужен. Это я что-то ступил и сразу не заметил. Правильная команда такая: $ git config --global core.whitespace cr-at-eol (Ну я ж говорю, что конфиги править ручками и быстрее, и полезнее.) А вообще, там (в секции core) есть и другие полезные настройки. Здесь уже товарищи отписались, как они называются. В принципе, это всё при желании легко гуглится.
в Виндовом гите по умолчанию символы завершения строки cr+lf . посмотрите настройки гита, там есть возможность переключить на unix-подобный формат завершения строк.
Вы к сожалению не поняли , что учиться надо этому на линуксе, а использовать vim вместо ide. Система созданная программистами для программистов. А так по желанию же. 1 лекция вроде затронут вопрос.
Подскажите, почему зависает программа при большом числе итераций (у меня доходит до 140к, потом минут за десять дошла до 150к, а 160к не дождался, хотя первые 10к выполняются за секунду-две). Процессор i3 8100, 16 ОЗУ from tkinter import * windowSizeWidth = 1919 windowSizeHeight = 1079 root = Tk() c=Canvas(root, width=windowSizeWidth, height=windowSizeHeight) c.pack() text = c.create_text(100, 100, text=0, justify=CENTER, font="Verdana 20") a = [[0, 1000], [950, 0], [1900, 1000], [950, 1000]] import random random.seed() i = 0 while i < 1000000: rnd = (random.randint(1, 3)) if rnd == 1: a[3][0] = (a[0][0] + a[3][0])/2 a[3][1] = (a[0][1] + a[3][1])/2 elif rnd == 2: a[3][0]=(a[1][0] + a[3][0])/2 a[3][1]=(a[1][1] + a[3][1])/2 elif rnd == 3: a[3][0] = (a[2][0] + a[3][0])/2 a[3][1] = (a[2][1] + a[3][1])/2 c.create_line(a[3][0], a[3][1], a[3][0]+1, a[3][1]) i += 1 if i % 10000 == 0: c.delete(text) text = c.create_text(100, 100, text=i, justify=CENTER, font="Verdana 20") root.update() root.mainloop()
Не имея полной картины -- сложно сказать, что там у Вас не так. Есть предположение, что, возможно, происходит происходит быстрое расход памяти. Я запускал Вашу прогу, но пришлось внести в неё изменения. У меня комп слабее Вашего (CoreDuo 2.4 GHz, 4 GB), монитор тоже слабее Вашего (1280х1024), поэтому я уменьшил канву в четыре раза и, соответственно, уменьшились объёмы вычислений. windowSizeWidth = 1000 windowSizeHeight = 600 ... a = [[0, 500], [425, 0], [950, 500], [425, 500]] У меня прога досчитала до 760К за минут пять. Потом я прервал выполнение, не захотел ждать -- понятно, что за 10-15 минут она дойдёт до конца. Перед тем как запустить свою прогу, запустите в консоли утилиту top (или лучше -- htop). Картина происходящего на компе сразу станет ясной. (Если у Вас Винда -- там тоже есть какая-то программа для просмотра загрузки проца и расхода памяти, но я не помню как она называется.) Кромке того, я бы Вам посоветовал отказаться от цикла while и использовать for: for i in range(1000000):
@@zhevak Заменил while на for, не помогло. 150к и зависает. create_line - это же объект? Если да, то у меня создано 150к объектов, и это не предел, так как у вас создано 760к таких объектов и разрешение здесь не имеет никакого значения. Свободной памяти 30%, процессор загружен на 40%.
@@SergeyKorotun Не-не, Сергей! Замена while на for -- это из другой "оперы". Это про то, что на Питоне нужно писать по -Питоняьи, а не по-Паскалески или по-Сишному. Это просто стиль "художника" -- как он пишет свои картины. К зависанию программы это не имеет никакого отношения. А теперь по зависанию проги. Вы посмотрели расход памяти, загруженность процессора? Чудес-то не бывает. У Вас какая ОСь? Версия Питона? Вы, в общем-то, правильно мыслите -- про создание объектов. Но, вот, смотрите, какой есть нюанс -- в программе на каждой итерации создаются объекты. Вновь созданные объекты связываются с именем, которое использовалось на предыдущей итерации. Иначе говоря, то же самое имя (переменной) будет ссылаться на новый объект, а, вот, старый объект окажется условно говоря "осиротевшим" -- не него не будет ни одной ссылки в программе. Этот момент Т.Ф. хорошо объяснил. А вот дальше -- интереснее. Сборщик мусора -- это очень своенравный хмырь, лодырь и тунеядец. Он не сорвётся очищать память, когда в программе появится один, десять или даже 10000 "осиротевших" объектов. Его пинать "надо", чтобы он начал чистить память. Вообще, на сколько я знаю, он и сам может поднять свою жо, когда в системе памяти станет мало. Но это лучше уточнять, версий Питона для разных платформ достаточно много. И мне так кажется, что они не обязаны быть абсолютно одинаковыми в реализации алгоритмов очистки мусора. Я бы Вам порекомендовал самостоятельно "прокачаться" по этому вопросу. Мне думается, что Ваш гарбидж коллектор (gc == garbage collector) уж совсем какой-то ленивый оказался. А может и наоборот -- зависание программы происходит как раз из-за того, что товарищ чистит память. Для си-шных программ освободить память ни чуть не проще, чем аллокировать (allocate).А в отношении Питона, это наверно даже ещё более сложно -- ведь удаляемые объекты могут содержать в себе ссылки на другие объекты. В общем, я бы всё-таки начал с того, что посмотрел бы -- а что у меня твориться с оперативной памятью. Тот факт, что у Вас 16 Гигов оператиdы -- это ни о чём не говорит. У Вас на компе могут быть подгружены какие-нибудь программы, которые весьма и весьма требовательные к памяти. Ну, например -- тот же PyCharm. Сама по себе эта IDE-шка не плохая. Ну у меня дохлый комп, поэтому я пользуюсь обычным текстовым редактором. (Ну, жить-то как-то надо! Не у всех же доходы одинаковые) Короче, у меня на компе оперативной памяти хватает для запуска Вашей проги, у Вас -- ситуация совершенно иная -- вполне может быть, что Вы исчерпали всю память. Надо смотреть.
@@zhevak< А теперь по зависанию проги. Вы посмотрели расход памяти, загруженность процессора? Чудес-то не бывает. У Вас какая ОСь? Версия Питона?> В предыдущем посте я писал, что свободная память есть (30%), процессор также не перегружен (40%). win10x64 python 3.8x32 Если запустить сборщик мусора и он очистит память от "осиротевших" объектов, то и точек на экране не станет, т.е. останется одна последняя, еще неуспевшая стать сиротой?
просто объясните мне пожалуйсто, вот у меня есть проект, в нем файл с настройками доступа к бд. пока я пилю его на локалке, в нем настройки локальной бд. далее я его заливаю на специальный хостинг (хероку). у хероку свои настройки своей бд, значит мне надо изменить и запушить этот файл с настройками бд для хероку, потом добавить этот файл в гит игнор, потом изменить этот файл для работы локальной бд, чтобы потом можно было просто пушить весь проект целиком, а этот файл с настройками бд оставался без изменений.... почему же это не работает?!))) зы. после git add . он просто стирает файл с настройками в удаленном репо и приложение крашится. На данный момент у меня наверное один вопрос, где должен храниться файл гитигнор, на локальном репозитории, или его надо пушить на bare?
Гит игнор хранится локально, чтобы при добавлении файлов в коммите гит их не инициализировал - то есть для удобства программиста или чтобы скрыть файлы, которые используются только локально. Что касается хероку - если у вас бесплатная версия, то никакого функционала с БД априори нет, и приложение перезапускается раз в сутки.
@@sergeyf7459 Спасибо за развернутый ответ, проблему решил уже давно) А что вы имеете ввиду насчет функционала БД на хероку? Там же есть встроенный postgres, работает вроде неплохо, даже управление через pgadmin есть...ограничение правда на бесплатке 20 тыщ строк
@@user-vu8pl8zl7h ого, вот насчёт БД сорри - не знал, самому просто нужна была такая штука, но что то в своё время не нагуглил насчёт базы и пришлось все хранить в csv файле там. Надо посмотреть как там БД прикрутить, и Вам спасибо за инфо)
"Короче, забьем для ясности!" (с) Тимофей Хирьянов
фраза доставила, за лекции огромный респект и благодарность!
Тайм-коды: Система контроля версий, Git, Событийно-ориентированное программирование
0:24 система контроля версий
4:25 diff утилита. Для отображения изменений
12:00 репозиторий. Слияние соединений в общий код (Merge)
12:17 reverse commit. Коммит-отмена
22:21 Распределенная система контроля версий. Git
26:18 bare (origin) repository. Центральный репозиторий
27:14 ручное слияние в случае конфликта версий
35:20 merge commit. Авто-слияние
36:50 команды Git: clone(склонировать), status(статус), diff (изменения), add(добавить),
42:20 commit(вклад), pull(подтянуть), push(запушить)
47:15 stash (спрятать), stash pop (достать)
50:53 head (голова ветки), rebase (на другую ветку)
52:22 fork (ответвиться), pull request (отправка на проверку)
52:46 Событийное или Событийно-ориентированное программирование - это про логику программы
54:57 иллюстрация программы с точки зрения времени её жизни и CPU
57:47 инициализация
58:03 Событие
59:49 Объект события (event). Очередь событий на обработку
1:03:15 непрерывный процесс
1:07:51 команды гита, код
1:09:28 Диспетчеризация, код пример
1:12:06 Обработчик событий. key_down_handler(event)
1:12:59 global глобальные переменные
1:13:58 команды гита, код
1:24:24 git for windows гит для винды
Тимофей Федорович, закрепить.
@@user-zj4ub3cx3z да, и в предыдущих не помешало бы, от этого автора тоже)
@@samuileldi или поднимем пост лайками ;)
Благодарю!
Большое человеческое Вам спасибо.
Смотрю на эти лекции и понимаю, что студенчество может быть не только веселым, но и полезным&интересным! Спасибо вам!!!
"Короче, забьем для ясности!" (с) Тимофей Хирьянов Наш человек!!!
Кому интересно где это 1:20:38
Да, это конечно, самое ценное.
Тимофей Фёдорович, извините, за публичную критику -- я не смог нагуглить Вашу почту. Поэтому вынужден написать здесь. Команда git status "работает" в рабочем директории и индексируемой области (cache). Она не затрагивает то, что находится на удалённом репозитории (иначе ей тогда пришлось бы обращаться к нему).
Не смотря на то, что я программист со стажем (предпенсионер уже), я с большим удовольствием смотрю Ваши видеоролики. Наверно даже не столько в качестве пособия для обучения самого себя, сколько для получения опыта при общении с теми, кто идёт в след за нами. Огромное Вам спасибо за Ваш труд! Вы делаете большой важности дело. Спасибо!
Бро спасибо за уточнение данной информации.
Имхо: это не критика.
есть и полезная критика, например, данная)
$ git fetch && git status
Thank you for your amazing software development lections. I am enjoying them a lot.
Очень признателен вам, Тимофей, за ваш труд и старания! 👍
@Тимофей Хирьянов , насчёт переносов строк.
TLDR: их не надо фиксить.
1. Пайчарм, редактируя файл, ставит те концы строк, которые указаны в его настройках: Editor > Code Style > Line separation.
2. ... но это не имеет значения, т.к. гит, если настроен правильно, автоматом при комитте их конвертирует. По умолчанию - он правильно настроен. Чтоб принудительно переводить все строки в линуксовые при pull и оставлять их таковыми при push, в gitconfig должно быть:
[core]
eol = lf
autocrlf = input
3. ... но лучше - прям совсем принудительно, в каждом репозитории явно. Чтоб независимо от того, какие там настройки у юзера - в репозиторий всегда попадало с линуксовыми line-ending'ами, даже при комиттах из-под винды, даже с кривой настройкой гита.
Для этого в .gitattributes репозитория в самом верху:
# force auto-detection binary/text and always use unix line endings
* text=auto eol=lf
Огромная благодарность Вам, за бесценные лекции!
Огромное спасибо и благодарность за такую подачу материала
Вы супер! Дай бог вам здоровья
Спасибо Вам за очень хорошую работу !
Очень интересно слушать) Класс!
Спасибо за хорошую лекцию.
Благодарю за лекцию.
Спасибо за отличный урок
Лучше учитель в мире!!!
Просто спасибо!
спасибо за урок, многое понял
«...когда люди, программисты, если они люди...» 😆😂🤣
Большое спасибо ❤
По поводу команды git diff -- на времени лекции 1:20:14.
Команда выводит строки у файлов, которые отличаются в рабочем директории и в индексной области. При этом команда ВЫДЕЛЯЕТ!!! окончания строк, которые выполнены на манер Виндовс (иначе говоря, используется окончание CRLF вместо LF).
Это лечится. Для того чтобы отключить эти ВЫДЕЛЕНИЯ нужно чуть-чуть поправить файл конфигурации Гита. Это можно сделать в любом конфигурационном файле -- хоть в системном (который для всех юзеров, кто имеет учётную запись на компе), хоть в глобальном (который для конкретного юзера), хоть в локальном (который для конкретного локального репозитория).
В конфигурационном файле нужно найти секцию [core] и записать в неё параметр:
[core]
whitespace = cr-at-eol
Мне проще (да я и люблю это дело) править конфиги ручками. Но, в прочем, это можно выполнить командой самого Гита:
$ git config --global core.whitespace = cr-at-eol
Соответственно, вместо --global нужно указать --system или --local, в зависимости от того на каком уровне хотите поправить ВЫДЕЛЕНИЯ.
Кроме того, можно попробовать поиграться с параметром autocrlf в этой же секции.
Тимофей Фёдорович, я сейчас озвучу очень известную истину. Мы про неё периодически забываем, а потом комплексуем. А напрасно!
-- Технологии в современном мире развиваются с огромной скоростью. И чтобы быть компетентны во многих и многих вопросах нужно уделять чрезвычайно много времени. Но у всех на всё про всё 24 часа в сутках. Поэтому не удивительно, что мы (специалисты) порой чего-то не знаем. И это -- нормальное явление для современного динамичного мира. Плохо не "не знать", плохо -- не хотеть знать!
С уважением
Жевак Александр Антонович
Ой-ой! Я извиняюсь!
Уважаемую общественность я ввёл в заблуждение.
В команде:
$ git config --global core.whitespace = cr-at-eol
знак "равно" не нужен. Это я что-то ступил и сразу не заметил.
Правильная команда такая:
$ git config --global core.whitespace cr-at-eol
(Ну я ж говорю, что конфиги править ручками и быстрее, и полезнее.)
А вообще, там (в секции core) есть и другие полезные настройки. Здесь уже товарищи отписались, как они называются. В принципе, это всё при желании легко гуглится.
Спасибо.
1:19:37 В Pycharm ( внизу на панеле ) выставлен виндовый перевод строки CRLF (
) соответственно отсюда ^M в Linux среде. По идее должен быть LF (
).
В нижней панели PyCharm - кнопка CRLF
Спасибо.
в Виндовом гите по умолчанию символы завершения строки cr+lf . посмотрите настройки гита, там есть возможность переключить на unix-подобный формат завершения строк.
Ага. Так точно! У нас на работе один товарисчь-вендузятник именно так и гадит в общий репозиторий.
@@zhevak ответил отдельным комментом рядом, как защититься от такого виндузятника.
Скоро посмотрю
Красавчик
@@pavelgushchin2223 посмотрел
Видео не отражено в списке канала. Ремарка по оформлению на случай если будет желание поправить.
👍
Лайк! =)
можете посоветовать книгу по изучению английского, просто и компьютерного
вот все хорошо, только я конспектирую сижу, все пишу и тут поворот:
"но это было раньше"
"можно сделать лучше"
"так не желательно делать"
🤯😖🤦♂
А почему часть лекции показывается в командной строке на операционной системе линукс ? Это удобней, чем PyCharm?
Вы к сожалению не поняли , что учиться надо этому на линуксе, а использовать vim вместо ide. Система созданная программистами для программистов. А так по желанию же. 1 лекция вроде затронут вопрос.
Спасибо много слышал про git, но никак работает50 !
Тимофей, включите же, пожалуйста, рекламу в видео! :)
Ваши лекции уже не хилая такая благотворительность ведь ;)
WinMerge -- аналог утилиты diff под Windows.
P.S. Отдельная программа.
27
вот в гите с русским в некторых версиях с русским непонятки, обновился - швах с русским кирдык
Подскажите, почему зависает программа при большом числе итераций (у меня доходит до 140к, потом минут за десять дошла до 150к, а 160к не дождался, хотя первые 10к выполняются за секунду-две). Процессор i3 8100, 16 ОЗУ
from tkinter import *
windowSizeWidth = 1919
windowSizeHeight = 1079
root = Tk()
c=Canvas(root, width=windowSizeWidth, height=windowSizeHeight)
c.pack()
text = c.create_text(100, 100, text=0, justify=CENTER, font="Verdana 20")
a = [[0, 1000], [950, 0], [1900, 1000], [950, 1000]]
import random
random.seed()
i = 0
while i < 1000000:
rnd = (random.randint(1, 3))
if rnd == 1:
a[3][0] = (a[0][0] + a[3][0])/2
a[3][1] = (a[0][1] + a[3][1])/2
elif rnd == 2:
a[3][0]=(a[1][0] + a[3][0])/2
a[3][1]=(a[1][1] + a[3][1])/2
elif rnd == 3:
a[3][0] = (a[2][0] + a[3][0])/2
a[3][1] = (a[2][1] + a[3][1])/2
c.create_line(a[3][0], a[3][1], a[3][0]+1, a[3][1])
i += 1
if i % 10000 == 0:
c.delete(text)
text = c.create_text(100, 100, text=i, justify=CENTER, font="Verdana 20")
root.update()
root.mainloop()
Не имея полной картины -- сложно сказать, что там у Вас не так. Есть предположение, что, возможно, происходит происходит быстрое расход памяти.
Я запускал Вашу прогу, но пришлось внести в неё изменения. У меня комп слабее Вашего (CoreDuo 2.4 GHz, 4 GB), монитор тоже слабее Вашего (1280х1024), поэтому я уменьшил канву в четыре раза и, соответственно, уменьшились объёмы вычислений.
windowSizeWidth = 1000
windowSizeHeight = 600
...
a = [[0, 500], [425, 0], [950, 500], [425, 500]]
У меня прога досчитала до 760К за минут пять. Потом я прервал выполнение, не захотел ждать -- понятно, что за 10-15 минут она дойдёт до конца.
Перед тем как запустить свою прогу, запустите в консоли утилиту top (или лучше -- htop). Картина происходящего на компе сразу станет ясной. (Если у Вас Винда -- там тоже есть какая-то программа для просмотра загрузки проца и расхода памяти, но я не помню как она называется.)
Кромке того, я бы Вам посоветовал отказаться от цикла while и использовать for:
for i in range(1000000):
@@zhevak
Заменил while на for, не помогло. 150к и зависает.
create_line - это же объект? Если да, то у меня создано 150к объектов, и это не предел, так как у вас создано 760к таких объектов и разрешение здесь не имеет никакого значения.
Свободной памяти 30%, процессор загружен на 40%.
@@SergeyKorotun
Не-не, Сергей! Замена while на for -- это из другой "оперы". Это про то, что на Питоне нужно писать по -Питоняьи, а не по-Паскалески или по-Сишному. Это просто стиль "художника" -- как он пишет свои картины. К зависанию программы это не имеет никакого отношения.
А теперь по зависанию проги. Вы посмотрели расход памяти, загруженность процессора? Чудес-то не бывает. У Вас какая ОСь? Версия Питона?
Вы, в общем-то, правильно мыслите -- про создание объектов. Но, вот, смотрите, какой есть нюанс -- в программе на каждой итерации создаются объекты. Вновь созданные объекты связываются с именем, которое использовалось на предыдущей итерации. Иначе говоря, то же самое имя (переменной) будет ссылаться на новый объект, а, вот, старый объект окажется условно говоря "осиротевшим" -- не него не будет ни одной ссылки в программе. Этот момент Т.Ф. хорошо объяснил. А вот дальше -- интереснее.
Сборщик мусора -- это очень своенравный хмырь, лодырь и тунеядец. Он не сорвётся очищать память, когда в программе появится один, десять или даже 10000 "осиротевших" объектов. Его пинать "надо", чтобы он начал чистить память. Вообще, на сколько я знаю, он и сам может поднять свою жо, когда в системе памяти станет мало. Но это лучше уточнять, версий Питона для разных платформ достаточно много. И мне так кажется, что они не обязаны быть абсолютно одинаковыми в реализации алгоритмов очистки мусора.
Я бы Вам порекомендовал самостоятельно "прокачаться" по этому вопросу. Мне думается, что Ваш гарбидж коллектор (gc == garbage collector) уж совсем какой-то ленивый оказался. А может и наоборот -- зависание программы происходит как раз из-за того, что товарищ чистит память. Для си-шных программ освободить память ни чуть не проще, чем аллокировать (allocate).А в отношении Питона, это наверно даже ещё более сложно -- ведь удаляемые объекты могут содержать в себе ссылки на другие объекты.
В общем, я бы всё-таки начал с того, что посмотрел бы -- а что у меня твориться с оперативной памятью. Тот факт, что у Вас 16 Гигов оператиdы -- это ни о чём не говорит. У Вас на компе могут быть подгружены какие-нибудь программы, которые весьма и весьма требовательные к памяти. Ну, например -- тот же PyCharm. Сама по себе эта IDE-шка не плохая. Ну у меня дохлый комп, поэтому я пользуюсь обычным текстовым редактором. (Ну, жить-то как-то надо! Не у всех же доходы одинаковые) Короче, у меня на компе оперативной памяти хватает для запуска Вашей проги, у Вас -- ситуация совершенно иная -- вполне может быть, что Вы исчерпали всю память. Надо смотреть.
@@zhevak< А теперь по зависанию проги. Вы посмотрели расход памяти, загруженность процессора? Чудес-то не бывает. У Вас какая ОСь? Версия Питона?>
В предыдущем посте я писал, что свободная память есть (30%), процессор также не перегружен (40%).
win10x64 python 3.8x32
Если запустить сборщик мусора и он очистит память от "осиротевших" объектов, то и точек на экране не станет, т.е. останется одна последняя, еще неуспевшая стать сиротой?
просто объясните мне пожалуйсто, вот у меня есть проект, в нем файл с настройками доступа к бд. пока я пилю его на локалке, в нем настройки локальной бд. далее я его заливаю на специальный хостинг (хероку). у хероку свои настройки своей бд, значит мне надо изменить и запушить этот файл с настройками бд для хероку, потом добавить этот файл в гит игнор, потом изменить этот файл для работы локальной бд, чтобы потом можно было просто пушить весь проект целиком, а этот файл с настройками бд оставался без изменений.... почему же это не работает?!)))
зы. после git add . он просто стирает файл с настройками в удаленном репо и приложение крашится. На данный момент у меня наверное один вопрос, где должен храниться файл гитигнор, на локальном репозитории, или его надо пушить на bare?
Гит игнор хранится локально, чтобы при добавлении файлов в коммите гит их не инициализировал - то есть для удобства программиста или чтобы скрыть файлы, которые используются только локально. Что касается хероку - если у вас бесплатная версия, то никакого функционала с БД априори нет, и приложение перезапускается раз в сутки.
@@sergeyf7459 Спасибо за развернутый ответ, проблему решил уже давно) А что вы имеете ввиду насчет функционала БД на хероку? Там же есть встроенный postgres, работает вроде неплохо, даже управление через pgadmin есть...ограничение правда на бесплатке 20 тыщ строк
@@user-vu8pl8zl7h ого, вот насчёт БД сорри - не знал, самому просто нужна была такая штука, но что то в своё время не нагуглил насчёт базы и пришлось все хранить в csv файле там. Надо посмотреть как там БД прикрутить, и Вам спасибо за инфо)
git rebase; git push -- force origin master;
На скорости 1,75 самое то) Спасибо за материал
Lectures, не lections!
запушить и закомитить это одно и тоже ?
А я и не знал, что Валерий Карпин в МФТИ преподает...
:-)))
Программирование на доске, это супер, знаю ещё одного, он программирует в пэинте.
ну в офисах компаний тоже доски есть и там что-то пишут)))
Чот я нифига не понял :( старею, наверное :(
много пауз, кстати.