под raspberry pi на скале писали, чтоб электропоездом управлять

разбери сложно назвать ограниченным) я тут офигеваю от http://store.steampowered.com/app/504210/ где у тебя 1-2 регистра и 10 строк кода)

разбери сложно назвать ограниченным) я тут офигеваю от http://store.steampowered.com/app/504210/ где у тебя 1-2 регистра и 10 строк кода)

о, норм игрушка?

о, норм игрушка?

отличная. Дико ломает мозг после фривольности с явой.

О, я спейс чем вроде прошел полностью (давно было, не помню) И тис себе купил, поиграл - надоело, скучноватый местами, простой http://store.steampowered.com/app/370360/

какая хрен разница в какой поезд и на чем садиться)) главное чтобы оно ехало))

О, я спейс чем вроде прошел полностью (давно было, не помню) И тис себе купил, поиграл - надоело, скучноватый местами, простой http://store.steampowered.com/app/370360/

в это стоит играть?)

О, я спейс чем вроде прошел полностью (давно было, не помню) И тис себе купил, поиграл - надоело, скучноватый местами, простой http://store.steampowered.com/app/370360/

Паша же заставил)

в это стоит играть?)

Да, он самый)

Три левела всего то

Там их больше было

для кода, которому критично не умереть внезапно от хз чего

Для этого эрланг заточен. Поток умер? Отлично, стартанем новый. Ну и функциональщина опять же.

Для этого эрланг заточен. Поток умер? Отлично, стартанем новый. Ну и функциональщина опять же.

все хочу потыкать его (с аккой более-менее знаком)

also, стрим не закроется если будет эксепшон

в это стоит играть?)

мне screeps еще понравились

все хочу потыкать его (с аккой более-менее знаком)

жаль, вакансий мало

мне screeps еще понравились

когда там говоришь скидки то?))

когда там говоришь скидки то?))

были неделю назад)

вот дерьмо)

в это стоит играть?)

codingame мультиплеер ботов писать забавно тоже. особенно в стратегии играться

игра для программистов, напрограммировать игру))))

игра для программистов, напрограммировать игру))))

игру про то как быть программистом и играть в игру где надо напрограммировать игру

задротство) это вы еще https://www.factorio.com/ не видели

задротство) это вы еще https://www.factorio.com/ не видели

выглядит охуенно

выглядит охуенно

на самом деле все круче чем выглядит) ну на любителя

на самом деле все круче чем выглядит) ну на любителя

"ну" или "но" на любителя?

"ну" или "но" на любителя?

http://store.steampowered.com/app/427520/ по отзывам любителей очень много)

чото в темпах щас посмотрел лежат файлы типа таких: 4-http∺∯∯wscont1.apps.microsoft.com∯winstore∯1x∯dabb54f2-d634-4cf1-acef∯AppTile.1.428664.1.dat

хуйня какаято

∯

∺

нормальный такой реплейс ))

also, стрим не закроется если будет эксепшон

Про какой стрим ты говришь?

Про какой стрим ты говришь?

Аа, понял, что за стрим.

Про какой стрим ты говришь?

про все, ни один из них не закроется по эксепшону, будет залоканый файл, до ребута

какоеж ява и ей подобные языки говно, в плюсах такой хуйни нет

почему нет нормальных деструкторов, кто объяснит?

Наброс детектед.

почему нет нормальных деструкторов, кто объяснит?

Потому что мы не заботимся о этом, у нас это делает рантайм.

дык не делает

про все, ни один из них не закроется по эксепшону, будет залоканый файл, до ребута

Я уже поправил. Счас проблема в том, что я неправильно серелизую. Посмотрел в дебагере и увидел, что мой спикер становися нулом на этапе записи.

файл открыл - надо не забыть закрыть

почему нет нормальных деструкторов, кто объяснит?

а нахуй они нужны?

файл открыл - надо не забыть закрыть

Try with resources

а нахуй они нужны?

вот чтобы всё закрывалось корректно по эксепшону

файл открыл - надо не забыть закрыть

всё худшее в яве пришло туда из плюсов: работа со стримами - типичный пример

стрим должен закрываться и открываться без эксепшонов

try with - костыль от убогости деструкторов

stream.open() try{}catch(IOException) stream.close() но в яве сделали как в плюсах и получилось говно

stream.open() try{}catch(IOException) stream.close() но в яве сделали как в плюсах и получилось говно

А ты уверен что стрим открылся?

да, если он не открылся там вывалит IO (внутри трая)

На самом деле там еще пара строчек и несколько проверок на null

да, если он не открылся там вывалит IO (внутри трая)

Котрый ты не ловишь

И закрывать лучше в finally

Котрый ты не ловишь

внутри трая

И закрывать лучше в finally

тогда будет nullpointer

try with - костыль от убогости деструкторов

костыль - это addSuppressed(), try-with-resources - это только синтаксический сахар

ага, segmentation fault(core dumped) - вот он идеальный язык

просто напишите обёртку для стримов, и работайте с ней по схеме: stream.open() try{}catch(IOException) stream.close()

и всё будет заебись

просто напишите обёртку для стримов, и работайте с ней по схеме: stream.open() try{}catch(IOException) stream.close()

мб в finally лучше?

ага, segmentation fault(core dumped) - вот он идеальный язык

ну да, деструктор (в случае жабы - AutoCloseable.close()) не должен порождать эксепшн в raii (try-with-resources)

мб в finally лучше?

нет, finally будет валить nullpointer и весь твой сервак

ага, segmentation fault(core dumped) - вот он идеальный язык

я говорю про деструкторы, которые, по непонятным мне причинам, такие убогие

я говорю про деструкторы, которые, по непонятным мне причинам, такие убогие

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

почему нельзя в момент, когда счётчик использования становится 0 - звать finalize?

ERROR: S client not available

почему нельзя в момент, когда счётчик использования становится 0 - звать finalize?

так и делается

просто почти никогда не бывает чтоб счётчик был 0

так и делается

нет же, он зовётся, когда его GC начнет освобождать

почему нельзя в момент, когда счётчик использования становится 0 - звать finalize?

циклические ссылки?

а может и не позваться, если объект переиспользуется

нет же, он зовётся, когда его GC начнет освобождать

не вижу противоречий

циклические ссылки?

ну ладно, не счетчик, а остов графа, на который снаружи ссылок нет

ну так и делается, пришел gc и вызвал finalize

только когда он пришел, никто не знает

нет же, он зовётся, когда его GC начнет освобождать

да еще и перекладывает такие объекты в отдельную finalization queue (т.е. хочешь тормоза - реализуй метод finalize)

не вижу противоречий

Если ява разрабатывалась с учетом того, что программист не должен париться с освобождением ресурсов - есть для этого GC, то почему я должен файлы закрывать? Вот где противоречие

ну ладно, не счетчик, а остов графа, на который снаружи ссылок нет

с неба спустится ангел и сообщит GC, что снаружи ссылок нет?

с неба спустится ангел и сообщит GC, что снаружи ссылок нет?

гц так и работает, иначе бы двойные связанные списки жили бы вечно

я говорю про деструкторы, которые, по непонятным мне причинам, такие убогие

я говорю про язык, который любое неосторожное действие карает полным падением без объяснения причин

я говорю про язык, который любое неосторожное действие карает полным падением без объяснения причин

С этим я не спорю - это плохо.

Если ява разрабатывалась с учетом того, что программист не должен париться с освобождением ресурсов - есть для этого GC, то почему я должен файлы закрывать? Вот где противоречие

файлы это не объекты языка жава, а внешний стейт системы, который находится за пределами жава машины

гц так и работает, иначе бы двойные связанные списки жили бы вечно

давайте Вы, уважаемый, Марат, 5 минут подумаете, а потом напишете о результатах

В общем, в яве убогие деструкторы и причины, по которой они такие убогие не видно, как-бы в таком виде они вообще не нужны. Странно, что когда с плюсов яву копировали поступили так.

В общем, в яве убогие деструкторы и причины, по которой они такие убогие не видно, как-бы в таком виде они вообще не нужны. Странно, что когда с плюсов яву копировали поступили так.

Спасибо, Владислав, за ваше заключение.

нет, finally будет валить nullpointer и весь твой сервак

Откуда NPE?

А в жаве всё попрежнему заебись.

Откуда NPE?

потому что эксепшон валит конструктор стрима. никогда не валите эксепшоны из конструкторов.

давайте Вы, уважаемый, Марат, 5 минут подумаете, а потом напишете о результатах

собираем локальные переменные со всех стек-фреймов, собираем this со всех методов в стеках, собираем все статические поля классов, рекурсивно пытаемся дотянуться до остальных объектов от этих начальных точек. Все, до чего не дотянулись - и будет остовами графов, на которые снаружи ссылок нет. Их можно почистить. Никакой счетчик ссылок не нужен.

собираем локальные переменные со всех стек-фреймов, собираем this со всех методов в стеках, собираем все статические поля классов, рекурсивно пытаемся дотянуться до остальных объектов от этих начальных точек. Все, до чего не дотянулись - и будет остовами графов, на которые снаружи ссылок нет. Их можно почистить. Никакой счетчик ссылок не нужен.

это то что GC и делает

потом он зовёт finalize

это то что GC и делает

а вы говорите что нужен ангел, который сообщит гц, что ссылок нет

а вы говорите что нужен ангел, который сообщит гц, что ссылок нет

ну тыж там выше хотел, чтоб GC сразу звал finalize

Вот не помню как finalize реализован, но что будет если туда вставить while(true) или бросить исключение?

ну тыж там выше хотел, чтоб GC сразу звал finalize

ну если бы jvm в онлайне следила за графом, то finalize можно и сразу вызвать. Но так никто не делает

Вот не помню как finalize реализован, но что будет если туда вставить while(true) или бросить исключение?

исключение он проглотит

a while(true) - протестируй сам, думаю зависнет

потому что эксепшон валит конструктор стрима. никогда не валите эксепшоны из конструкторов.

Так откуда NPE возьмется при закрытии стрима, если перед этим проверить ссылку на null? Причем здесь конструктор?