Сергей Оленда́ренко GooRoo

Спасибо заранее! Буду ждать.

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

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

1. Каково состояние языка и отрасли сейчас? Компиляторы/интерпретаторы, диалекты, как часто выходят новые версии и т.д. (читайте — «живое» ли оно ещё).
2. Рекомендуемые книги, курсы? Насколько они свежие и соответствуют текущим реалиям?
3. Есть ли конкретные опенсорс-проекты, в которых пролог используется? Думаю, может быть полезно, если захочется подсмотреть best practices.
4. Всё остальное, что может помочь в изучении.

Считайте это реквестом :)

Потому что некоторые операторы чарджат за эту услугу отдельно.

Что значит «накладные расходы равны нулю»? Если шлётся что-то дополнительное, значит, есть дополнительные накладные расходы.

Даю идеи бесплатно:

1. Зачем было писать какой-то сайт-лоадер? Движок QML и так поддерживает network transparency и может грузить файлы прямо из сети.
2. По-хорошему, конечно, нужно как минимум сделать свой фреймворк вместо Qt Quick и для начала запретить импортировать что-либо, кроме него.
3. Нет никакого смысла держать два браузера. И пытаться встроить движок QML в существующие тоже. Вместо этого нужно делать наоборот: если урла указывает на QML, то грузить его, если же HTML, то можно этот HTML показывать в том же браузере через qml-ный WebView.

Интерфейс гонять вместе с данными нет никакого смысла. Данные постоянно обновляются, а интерфейс нет.

Qt Quick — для создания UI. QML — декларативный язык для чего угодно.

На производительности?

Можно по пунктам?

Было бы круто ещё в шапку вставлять ссылки на предыдущие подборки. Just saying.

(Пока что) ещё есть Qbs.

У вас точно не она, судя по цвету кейса и наушников. Просто с этими наушниками не всем везёт почему-то: кто-то жалуется, а кто-то доволен.

У меня тоже Dash Pro, и всё в порядке с качеством воспроизведения с телефона, как и с качеством подключения блютус. Лично у меня описанные проблемы были с кикстартеровской версией Dash.

Это статья про QML, алоэ.

Скажите это XSLT :)

Из всех умных чайников, что я нашёл, пока самым достойным на мой взгляд кажется AppKettle https://www.myappkettle.com

Ещё вроде Redmond делает какие-то под названием SkyKettle, но что там — хз.

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

Могу порекомендовать Home Assistant https://home-assistant.io
Использую его в основе своего «умного» дома, в частности с Xiaomi Hub (но без чайника).

Вверх — расширение выделения, вниз — наоборот.

Ctrl+↑/↓

Пользоваться им и правда не всегда удобно. Только это проблема не MPS, а устаревших прочих инструментов.

На самом деле я просто хотел убедиться, что семантика Qt/QML в вашем PureQML сохранена. Но потом увидел вот это:

// ...
setPos(long, lat): {
    // ...
}
// ...

Для Qt/QML это в принципе невалидная запись, что меня и заинтересовало.

На мой взгляд разница между одной записью и другой всё же есть. Если я правильно понял, то для вас эти две записи эквивалентны:

function foo() { }

и

foo: { }

С одной стороны вторая запись слишком похожа на binding какого-то выражения к свойству foo. Окей, допустим, вы не стали делать различия между свойствами и методами (мемберы и есть мемберы, почему бы и нет). Но в Qt/QML есть другая штука. Вот эти две записи с его точки зрения эквивалентны:

propName: jsExpression

и

propName: { return jsExpression; }

Таким образом, если мы хотим забиндить ("забайндить" не звучит, так что буду называть это забиндить) на свойство не результат выполнения блока кода, а сам этот блок кода, то в Qt/QML мы пишем как-то так:

property var foo
// ...
foo: function() {
    // ...
}

или даже

foo: {
    return function() { /* ... */ };
}

В общем, немного сложно понять, что происходит.

С другой стороны вы, возможно, не стали делать различия между методами и обработчиками сигналов. Окей, тоже почему бы и нет. Фактически, единственное, что их у вас отличает, это наличие префикса on. На мой взгляд, это различие недостаточно явное. Например, предположим, у нас есть компонент Foo, описанный в Foo.qml следующим образом:

Item {
    foo: { 
        console.log("inner"); 
    }
}

Потом мы его используем как-то так:

Item {
    Foo {
        id: _foo

        foo: {  // переопределение метода, объявленного внутри
             console.log("outer");
        }
    }

    onSomeEvent: {
        _foo.foo() // выводит только "outer"
    }
}

В случае же с сигналами всё работает немного иначе. Допустим, Bar выглядит так:

Item {
    signal bar()
    onBar: { 
        console.log("inner"); 
    }
}

Потом мы его используем как-то так:

Item {
    Bar {
        id: _bar

        onBar: {  // пишем свой обработчик сигнала
             console.log("outer");
        }
    }

    onSomeEvent: {
        _bar.bar() // выводит сначала "inner", потом "outer"
    }
}

Другими словами, если бы вы позволяли объявить таким же образом метод, начинающийся с on, то была бы вообще полная неразбериха. А так только наполовину, на мой взгляд. Странно всё это :)

Но мне кажется будущее всё же за github.com/nylas/N1 типа приложениями (технологии Electron, React, Flux). Кросс-платформенное, код на CoffeeScript, покрытие кода тестами.

удобный файловый менеджер, адекватный шелл