CIDER ругается на nRepl после обновления пакетов в Emacs

#package #emacs #clojure #cider

                    
    ; CIDER 0.11.0snapshot (package: 20160125.741) (Java 1.8.0_72, Clojure 1.7.0,
nREPL 0.2.10)
WARNING: CIDER requires nREPL 0.2.12 (or newer) to work properly
WARNING: The following required nREPL ops are not supported: 
  apropos classpath complete eldoc format-code format-edn info inspect-pop inspect-push
inspect-refresh macroexpand ns-list ns-vars ns-path refresh resource stacktrace toggle-trace-var
toggle-trace-ns undef
  Please, install (or update) cider-nrepl 0.11.0-SNAPSHOT and restart CIDER
WARNING: CIDER's version (0.11.0-snapshot) does not match cider-nrepl's version (not
installed). Things will break!
user> 




Как устранить конфликты в пакетах?

project.clj:

    (defproject lesson-rpg1 "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.7.0"]]
  :main ^:skip-aot lesson-rpg1.core
  :target-path "target/%s"
  :profiles {:uberjar {:aot :all}})


lein deps :tree

D:\CODE\Clojure\lesson-rpg1>lein deps :tree
 [clojure-complete "0.2.3" :exclusions [[org.clojure/clojure]]]
 [org.clojure/clojure "1.7.0"]
 [org.clojure/tools.nrepl "0.2.10" :exclusions [[org.clojure/clojure]]]
D:\CODE\Clojure\lesson-rpg1>


lein version:

D:\CODE\Clojure\lesson-rpg1>lein version
Leiningen 2.5.2 on Java 1.8.0_72 Java HotSpot(TM) 64-Bit Server VM
D:\CODE\Clojure\lesson-rpg1>

    

Ответы

Ответ 1

Сложилась неприятная ситуация

...в самом Leiningen будет указана старая версия tools.nrepl до следующего релиза.
Поэтому нужно указать версию явно в проекте или профиле (см. далее):

[org.clojure/tools.nrepl "0.2.12" :exclusions [[org.clojure/clojure]]]


...и так, чтобы при этом не приклеивалась зависимость от конкретной версии Clojure.
И ещё, похоже, потребуется это:

[cider/cider-nrepl "0.11.0-SNAPSHOT"]




Что происходит

Если проект не указывает версию org.clojure/tools.nrepl явно, то используется та,
что распространяется с Leiningen, в вашем случае это оказалась старая версия 0.2.10.

Можно действовать любым из следующих способов:


указать её явно прямо в проекте в списке зависимостей
добавить в профиль по умолчанию (~/.lein/profiles.clj)


это зависимость, поэтому подлежит записи под ключом :dependencies.

обновить Leiningen и получить новую встроенную версию tools.nrepl


на данный момент неактуально, ждём очередного релиза Leiningen.



Поскольку речь о совместимости проекта с вашей собственной средой разработки (а код
самого проекта не зависит от этого), первый вариант плохо подходит, а второй скорее
"заплатка".

Решение строкового математического выражения

#java #строки #package

Есть ли в java нативный метод для такого рода вещей, чтобы самому не писать?
Вроде  

String expr = "1 + 2 * 3";
Double result = WonderClass.wonderMethod(expr);
System.out.println(result);




7.0

    

Ответы

Ответ 1

Да, можно использовать Java Scripting API

Вполне подойдет JavaScript (его движок входит в состав JDK):

ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine engine = scriptEngineManager.getEngineByName("JavaScript");
String expr = "1 + 2 * 3";
System.out.println(engine.eval(expr));

как получить все классы в пакете javaapplication7?

#java #рефлексия #package

Есть пакет javaapplication7, в нем 3 простых класса A,B,C, затрудняюсь получить их.
    

Ответы

Ответ 1

Вот пример класса, который сканирует пакет, и возвращает список его классов

вpublic class ClassFinder {

private static final char PKG_SEPARATOR = '.';

private static final char DIR_SEPARATOR = '/';

private static final String CLASS_FILE_SUFFIX = ".class";

private static final String BAD_PACKAGE_ERROR = "Unable to get resources from path
'%s'. Are you sure the package '%s' exists?";

/**
 * Возвращает список классов в пакете
 */
public static List> find(String scannedPackage) {
    String scannedPath = scannedPackage.replace(PKG_SEPARATOR, DIR_SEPARATOR);
    URL scannedUrl = Thread.currentThread().getContextClassLoader().getResource(scannedPath);
    if (scannedUrl == null) {
        throw new IllegalArgumentException(String.format(BAD_PACKAGE_ERROR, scannedPath,
scannedPackage));
    }
    File scannedDir = new File(scannedUrl.getFile());
    List> classes = new ArrayList<>();
    for (File file : scannedDir.listFiles()) {
        classes.addAll(find(file, scannedPackage));
    }
    return classes;
}

private static List> find(File file, String scannedPackage) {
    List> classes = new ArrayList<>();
    String resource = scannedPackage + PKG_SEPARATOR + file.getName();
    if (file.isDirectory()) {
        for (File child : file.listFiles()) {
            classes.addAll(find(child, resource));
        }
    } else if (resource.endsWith(CLASS_FILE_SUFFIX)) {
        int endIndex = resource.length() - CLASS_FILE_SUFFIX.length();
        String className = resource.substring(0, endIndex);
        try {
            classes.add(Class.forName(className));
        } catch (ClassNotFoundException ignore) {
        }
    }
    return classes;
}


}

Пример вызова

List> classes = ClassFinder.find("examples.concurrency");


Ответ 2

Можете воспользоваться библиотекой: Class graph Maven Central

Пример: 

try (ScanResult scanResult = new ClassGraph()
        .whitelistPackages("javax.persistence")      // Сканирует пакет javax.persistence
и все его подпакеты
        .scan()) {
    for (ClassInfo classInfo : scanResult.getAllClasses()) {
        System.out.println(classInfo.getName());
    }
}


Ответ 3

Могу предложить библиотеку Reflections. С ее помощью можно легко получить информацию
о классах для заданного пакета:

private static List> getAllClassesFrom(String packageName) {
    return new Reflections(packageName, new SubTypesScanner(false))
            .getAllTypes()
            .stream()
            .map(name -> {
                try {
                    return Class.forName(name);
                } catch (ClassNotFoundException e) {
                    return null;
                }
            })
            .filter(Objects::nonNull)
            .collect(Collectors.toList());
}


Зависимость:


        org.reflections
        reflections
        0.9.10

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

#java #package

Написав это import java.awt.*; я не получу, содержимое этого import java.awt.event.*;
 Хотя казалось бы должен получить, если учитывать, что существует иерархия пакетов.
Вроде всё расфасовано по пакетам, в одном пакете, есть еще вложенные пакеты. Но получив
доступ к пакету в котором, есть вложенные, я не получаю содержимого вложенных пакетов.
 Хочется понять, это получается из-за какого-то особого подхода к структурированию
пакетов или же они действительно находятся в иерархической расположенности, но система
не дает доступа к вложенным пакетам, если запрошен главный пакет? 
import java.awt.*; даст мне содержимое import java.awt.event;(заметьте звездочки
нет во втором импорте) ? 
Или же event это тоже пакет, а import java.awt.*; даст мне все классы на этом уровне,
но не пакеты?
Выходит как в виндовс: применил, что то к папке, а там вопрос : применить к вложенным
папкам? Вроде бы иерархия есть, но влияние на неё контролируется.
    

Ответы

Ответ 1

Java рассматривает каждый пакет как независимый. Например, локальные пакеты не распространяются
на любые «под»пакеты. Я подозреваю, что использование иерархии значимым образом было
бы ценным, но дизайн Java должен был сделать все максимально простым.

Java не рассматривает пакеты как действительно подклассифицирующие друг друга; в
то время как java.util и java.util.concurrency могут выглядеть так, как будто вторая
часть является частью первой, однако они рассматриваются как полностью независимые,
а точка в основном используется для аккуратности.

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



Согласно спецификации JLS, Section 7.5, возможны только 4 способа произвести импорт:


  A single-type-import declaration (§7.5.1) imports a single named type,
  by mentioning its canonical name (§6.7).


Одиночный импорт по его «каноническому» имени.

Например: import java.util.List;


  A type-import-on-demand declaration (§7.5.2) imports all the
  accessible types (§6.6) of a named type or named package as needed, by
  mentioning the canonical name of a type or package.


Импорт всех доступных типов или пакетов по их «каноническому» имени.
Это подразумевает, что будут импортированы все имена дочерних пакетов, но не их содержимое.

Например: import java.awt.*;


  A single-static-import declaration (§7.5.3) imports all accessible
  static members with a given name from a type, by giving its canonical
  name.


Одиночный статический импорт, который импортирует все статические члены пакета.

Например: import static org.junit.Assert.assertEquals;


  A static-import-on-demand declaration (§7.5.4) imports all accessible
  static members of a named type as needed, by mentioning the canonical
  name of a type.


Импорт всех статических членов пакета.

Например: import static org.junit.Assert.*;

Пакеты позволяют дать одинаковое имя разным классам. Если бы была возможность импортировать
с помощью * всю суб-иерархию пакетов, была бы неразбериха в ваших локальных именах классов.



Ассоциация: why doesn't Java have “deep” wildcard import?, Java import all from all


Ответ 2

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

Раздел Apparent Hierarchies of Packages в первоисточнике:


  At first, packages appear to be hierarchical, but they are not. For
  example, the Java API includes a java.awt package, a java.awt.color
  package, a java.awt.font package, and many others that begin with
  java.awt. However, the java.awt.color package, the java.awt.font
  package, and other java.awt.xxxx packages are not included in the
  java.awt package. The prefix java.awt (the Java Abstract Window
  Toolkit) is used for a number of related packages to make the
  relationship evident, but not to show inclusion.


Перевод: 


  На первый взгляд кажется, что пакеты иерархичны, но это не так.
  Например, Java API включает пакеты java.awt, java.awt.color,
  java.awt.font и много других, которые начинаются с java.awt. Но ни
  java.awt.color, ни java.awt.font, ни любой другой пакет java.awt.xxx
  не входит в пакет java.awt. Префикс java.awt (Java Abstract Window
  Toolkit) используется для ряда пакетов, чтобы показать, что они
  связаны между собой (областью применения), но не для того, чтобы показать вложенность.

Как можно переименовать package?

#android #java #package

Имя пакета com.example.level.namis. Мне нужно теперь поменять example. В студио выбираю
Refactor -> Rename, но она позволяет переименовать только level на другое имя, а нужно
поменять example. Не переименовывать же каждый файл  и папку тоже вручную.
    

Ответы

Ответ 1

Ставишь галочку Compact Empty Middle Packeges и рефакторишь пакет. Вообще можно еще
менять packageId в build.gradle.


Ответ 2

Совершенно верно и толково. Но у меня получилось надо снять галочку Compact Empty
Middle Packeges и потом поменять обязательно в ручную applicationID в build.gradle(Module: app)

Как найти информацию про установленный пакет на Linux?

#linux #debian #apt_get #package #install

Доброго времени суток.

Вопрос довольно глобального характера. Я не могу понять саму концепцию.

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

На данный момент я представляю себе поиск информации так:


Поиск на форумах и сайтах статей и вопросов от тех, кто уже делал похожий проект
и устанавливал данные пакеты (оттуда и знание о существовании самого пакета)
Stackoverflow
Git репозиторий проекта и его Вики
apt-cache show [пакет] - обычно лишь общие слова о работе пакета, которые я уже знаю
man [пакет] - не работает, потому что нужно знать название методов данного пакета


В результате я получаю отрывки информации, нет полной картины. Я использую методы,
какие озвучены, но не знаю о существовании других. Часто никакого Вики вообще нету..

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

Для примера: установил я пакеты sudo apt install zbar-tools python-zbar python-qrtools
- для распознавания qr кода на изображении или же sudo apt-get install bluetooth bluez
blueman (это для работы с bluetooth на Raspberry Pi). Я знаю о существовании мифического
файла blescan.py с примером работы, но не могу найти его расположения.

Буду признателен за объяснения и разжёвывание общих принципов.
    

Ответы

Ответ 1

начинать можно с просмотра файлов, входящих в пакет:

$ dpkg -L имя.пакета




например, рассмотрим пакет bluez.

исполняемые файлы обычно располагаются в каталогах, содержащих в пути строку bin:

$ dpkg -L bluez | grep bin
/bin
/bin/hciconfig
/usr/sbin
/usr/bin
/usr/bin/bluetoothctl
/usr/bin/bccmd
/usr/bin/btmon
/usr/bin/rctest
/usr/bin/hciattach
/usr/bin/hcitool
/usr/bin/sdptool
/usr/bin/ciptool
/usr/bin/l2ping
/usr/bin/l2test
/usr/bin/rfcomm
/usr/bin/gatttool
/usr/sbin/bluetoothd


видим ряд исполняемых файлов, начиная с hciconfig и заканчивая bluetoothd.

man-страницы обычно располагаются в каталогах, содержащих в пути строку man:

$ dpkg -L bluez | grep man
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/bluetoothd.8.gz
/usr/share/man/man1
/usr/share/man/man1/bluetoothctl.1.gz
/usr/share/man/man1/btmon.1.gz
/usr/share/man/man1/l2test.1.gz
/usr/share/man/man1/hid2hci.1.gz
/usr/share/man/man1/l2ping.1.gz
/usr/share/man/man1/rctest.1.gz
/usr/share/man/man1/rfcomm.1.gz
/usr/share/man/man1/ciptool.1.gz
/usr/share/man/man1/hcitool.1.gz
/usr/share/man/man1/hciconfig.1.gz
/usr/share/man/man1/hciattach.1.gz
/usr/share/man/man1/bccmd.1.gz
/usr/share/man/man1/sdptool.1.gz


видим ряд man-страниц, начиная с bluetoothd и заканчивая sdptool. просмотреть их
можно командами man bluetoothd, ..., man sdptool.

документацию (иногда содержащую примеры) можно отобрать по признаку «содержит строку
doc в пути»:

$ dpkg -L bluez | grep doc
/usr/share/doc
/usr/share/doc/bluez
/usr/share/doc/bluez/README.Debian.gz
/usr/share/doc/bluez/changelog.Debian.gz
/usr/share/doc/bluez/changelog.Debian.amd64.gz
/usr/share/doc/bluez/NEWS.Debian.gz
/usr/share/doc/bluez/changelog.gz
/usr/share/doc/bluez/copyright


нередко, если документации много, её выделют в отдельный пакет, имя которого заканчивается
суффиксом -doc (а иногда ещё и с дополнительным разбиением на языки, с добавлением
суффикса -язык). например, документация к пакету aptitude содержится в таких пакетах:

$ apt-cache search aptitude doc
aptitude-doc-cs - Czech manual for aptitude, a terminal-based package manager
aptitude-doc-en - English manual for aptitude, a terminal-based package manager
aptitude-doc-es - Spanish manual for aptitude, a terminal-based package manager
aptitude-doc-fi - Finnish manual for aptitude, a terminal-based package manager
aptitude-doc-fr - French manual for aptitude, a terminal-based package manager
aptitude-doc-it - Italian manual for aptitude, a terminal-based package manager
aptitude-doc-ja - Japanese manual for aptitude, a terminal-based package manager
aptitude-doc-ru - Russian manual for aptitude, a terminal-based package manager

Запрет доступа файлам одного пакета к файлам другого пакета

#android #access #package

Здравствуйте, в ходе разработки приложения под андроид возникла следующая проблема:

имеются java файлы которые предназначены для реализации логики для подключения к
устройству типа1 они лежат в package Device1 (внутри этого пакета находятся также подпакеты),
другие java файлы лежат в package Device2.

В каждом пакете (Device1, Device2) имеются java файлы с одинаковым названием например
Func. Пакеты Device1, Device2 должны работать не зависимо друг от друга. Т.е. файлы
пакета Device1 не могут ссылаться на Func из пакета Device2 и наоборот.

Также есть еще пакет CommonConnection, который реализует первоначальное подключение
к пакетам Device1, Device2. В этом случае пакет CommonConnection должен иметь доступ
ко все остальным пакетам и Device1 и Device2. 

Можно ли как-то запретить файлам из пакета Device1 ссылаться на файлы из пакета Device2
и наоборот, чтобы по ошибке при вводе автодополнения не ввести файл из чужого пакета,
при этом чтобы общий пакет CommonConnection имел доступ и к файлам пакета Device1 и
к файлам Device2 ?

Заранее благодарю всех за ответы.



Создал модули Device1, Device2, CommonConnection.
В build.gradle для CommonConnection ввел зависимости  для
Device1, Device2 в итоге получил ошибку.





Резюмирую здесь решение моей задачи, возможно кому-то пригодиться в будущем:

1) Создаем 3 моудля CommonConnection, Device1, Device2. Нам необходимо, чтобы файлы
в CommonConnection имели доступ в Device1, Device2. А Device1, Device2 были изолированы
друг от друга, т.е. файл из Device1 не мог иметь доступ в Device2.
2) После создания модулей необходимо зайти в gradle для Device1 и внести следующие
изменения:

    **apply plugin: 'com.android.application'** 


изменить на
         apply plugin: 'com.android.library' 

И в defaultConfig убрать строку 
        applicationId "com.bignerdranch.android.Device1"



3) Для Device2 нужно сделать тоже самое. 
4) В gradle файле для CommonConnection нужно добавить строку
compile project(':Device1')



5) Далее нужно явно указать что нужно запускать первоначально именно активити модуля
CommonConnection. Нажимаем на Select Run/Debug Configuration и выбираем модуль CommonConnection.
Далее еще раз нажимаем на Select Run/Debug Configuration -> EditConfigurations.. **
в меню **Launch Options в строке Activity жмем на ... и выбираем активити для CommonConnection
в частности MainActivityCommonConnection.



6) Теперь можно запустить проект и проверить.
    

Ответы

Ответ 1

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

Для чего нужен package-lock.json?

#javascript #nodejs #frontend #npm #package

Доброе время суток.
Я почитал документацию к NPM, почитал форумы, но всё равно до конца не совсем понимаю,
смысловую нагрузку этого файла.

Вот то что описано на npm документации:


  Этот файл предназначен для фиксации в исходных хранилищах и
  предназначен для различных целей:
  
  1) Описывает единственное представление дерева зависимостей, чтобы товарищи
  по команде, разворачивая проект гарантированно
  установил одинаковые зависимости.
  
  2) Предоставьте пользователям возможность «путешествовать во времени» к
  предыдущим состояниям node_modules без фиксации самого каталога.
  
  3) Для облегчения большей видимости изменений в дереве с помощью читаемых
  исходных текстов контроля.
  
  4) И оптимизировать процесс установки, позволяя npm пропускать
  повторяющиеся установленные пакеты.


Вопрос сразу по 1 пункту, ибо у меня package.json и package-lock.json не в гит игноре!
Они комитятся.
И как написано в той же документашке, когда мы делаем npm i, пакетный менеджер устанавливает
зависимости, которые описаны в файле package.json.
И скачав очередную библиотеку мы идем внутрь неё и устанавливаем её зависимости (и
так рекурсивно).
На данном этапе в package-lock.json просто выводится информация какие внутренние
зависимости основных библиотек мы скачали.
Как оно помогает "гарантированно установил одинаковые зависимости" ?

И это всё полностью вытекает из 3 пункта.

Ну и согласен с 4 пунктом, по факту если в node_modules уже есть такой пакет (с той
же версией и хешем), то его устанавливать не будут. НО, опять же эту инфу можно смотреть
не по package-lock.json, а в зависимостях основного пакета, ибо почти у каждой либы
есть внутренний package.json. Т.е нам не нужен промежуточный файл получается.

Верно ли я все понимаю? Пожалуйста, поправьте!
    

Ответы

Ответ 1

Помимо зависимостей, package.json используется так же для определения свойств проекта,
описания, информации об авторе и лицензии, сценариев, в то время как package-lock.json
используется исключительно для блокировки зависимостей от определенного номера версии.

Наличие package-lock.json в проекте не обязательно.
Так же для отключение автоматического создания этого файла ты можешь в .npmrc прописать
package-lock=false

Почему пакеты в java принято называть в обратную сторону доменного имени?

То что это делать надо именно так, везде написано. Но почему люди договорились называть именно так? Может быть в этом есть какое-то неочевидное удобство?
    

Ответы

Ответ 1

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

Java Language Specification (JLS):


  The suggested convention for generating unique package names is merely a way t
piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for package names.


Представь, что у тебя есть например четыре важных пакета и ты напишешь их так:

 package controller.mysite.org;
 package model.mysite.org;
 package service.mysite.org;
 package dao.mysite.org;


Это означает, что существует основной пакет, подраздел которого относится к твое
компании (имя твоего ресурса), а подраздел этого пакета называется пакетом org, который ты фактически используешь и он есть уникальный. 
Но если написать так:

 package org.mysite.controller;
 package org.mysite.model;
 package org.mysite.service;
 package org.mysite.dao;


Эта запись имеет больший смысл. Из всех пакетов из организаций (org) ты, смотриш
на имя своей компании, и у нее есть четыре подпакета: controller, model, service, dao.


Ответ 2

Есть, хотя и довольно очевидное, оно неплохо изложено в документации к Java:


  Компании используют в начале имён своих пакетов своё развёрнутое доменное имя
например com.example.mypackage, означающий пакет mypackage, созданный программистом из example.com.
  
  Коллизии между пакетами в пределах одной компании должны разрешаться внутри само
компании, например добавлением к доменному имени компании региона или названия проекта, на манер com.example.region.mypackage.


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

Разумеется, никто не заставляет этим конвенциям следовать. Но сами разработчики в первую очередь заинтересованы в том, чтобы их пакеты не конфликтовали с чужими.


Ответ 3

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

То есть, корневая папка объеденяет общий домен, в которой "сложены" компании, в папке каждой компании - ее проекты ... это наиболее логичная структура

CIDER ругается на nRepl после обновления пакетов в Emacs

; CIDER 0.11.0snapshot (package: 20160125.741) (Java 1.8.0_72, Clojure 1.7.0, nREPL 0.2.10) WARNING: CIDER requires nREPL 0.2.12 (or newer) to work properly WARNING: The following required nREPL ops are not supported: apropos classpath complete eldoc format-code format-edn info inspect-pop inspect-push inspect-refresh macroexpand ns-list ns-vars ns-path refresh resource stacktrace toggle-trace-var toggle-trace-ns undef Please, install (or update) cider-nrepl 0.11.0-SNAPSHOT and restart CIDER WARNING: CIDER's version (0.11.0-snapshot) does not match cider-nrepl's version (not installed). Things will break! user>

Как устранить конфликты в пакетах?
project.clj:
(defproject lesson-rpg1 "0.1.0-SNAPSHOT" :description "FIXME: write description" :url "http://example.com/FIXME" :license {:name "Eclipse Public License" :url "http://www.eclipse.org/legal/epl-v10.html"} :dependencies [[org.clojure/clojure "1.7.0"]] :main ^:skip-aot lesson-rpg1.core :target-path "target/%s" :profiles {:uberjar {:aot :all}})
lein deps :tree
D:\CODE\Clojure\lesson-rpg1>lein deps :tree [clojure-complete "0.2.3" :exclusions [[org.clojure/clojure]]] [org.clojure/clojure "1.7.0"] [org.clojure/tools.nrepl "0.2.10" :exclusions [[org.clojure/clojure]]] D:\CODE\Clojure\lesson-rpg1>
lein version:
D:\CODE\Clojure\lesson-rpg1>lein version Leiningen 2.5.2 on Java 1.8.0_72 Java HotSpot(TM) 64-Bit Server VM D:\CODE\Clojure\lesson-rpg1>

Ответ

Сложилась неприятная ситуация
...в самом Leiningen будет указана старая версия tools.nrepl до следующего релиза. Поэтому нужно указать версию явно в проекте или профиле (см. далее):
[org.clojure/tools.nrepl "0.2.12" :exclusions [[org.clojure/clojure]]]
...и так, чтобы при этом не приклеивалась зависимость от конкретной версии Clojure. И ещё, похоже, потребуется это:
[cider/cider-nrepl "0.11.0-SNAPSHOT"]

Что происходит
Если проект не указывает версию org.clojure/tools.nrepl явно, то используется та, что распространяется с Leiningen, в вашем случае это оказалась старая версия 0.2.10
Можно действовать любым из следующих способов:
указать её явно прямо в проекте в списке зависимостей добавить в профиль по умолчанию (~/.lein/profiles.clj)
это зависимость, поэтому подлежит записи под ключом :dependencies обновить Leiningen и получить новую встроенную версию tools.nrepl
на данный момент неактуально, ждём очередного релиза Leiningen.
Поскольку речь о совместимости проекта с вашей собственной средой разработки (а код самого проекта не зависит от этого), первый вариант плохо подходит, а второй скорее "заплатка".

Куда обратится для исправления пакета?

Пол часа мучался с OpenDKIM(пакет именнуется в нижнем регистре) с репозитория Debian sid Он не в какую не хотел слушать свой дефолтный tcp порт, указывал его в конфиге, а он всё ровно слушает unix сокет. В htop я заметил что демон запускается с опцией -p local:/var/run/opendkim/opendkim.sock, я заглянул в его systemd юнит и действительно обнаружил там в ExecStart опцию -p local:/var/run/opendkim/opendkim.sock, как не сложно догадатся эта опция указует что слушать нужно указанный unix сокет, мне это кажется не правильным, это ломает совместимость со старыми версиями и не соответствует даже инструкции на wiki.debian.org, инструкция уж не как не древняя я считаю https://wiki.debian.org/opendkim В связи с эти есть несколько вопросов: 1. Куда обратится? В описании пакета есть email мейнтейнера, нужно ему на email писать? 2. Есть ли где описание каждого изменения в пакете, то есть могу ли я найти комментарий обьясняющий для чего был добавлен этот аргумент в unit скрипт? 3. Стоит ли сообщать о этом "баге"? Ведь добавлял этот аргумент наверняка лучше разберающийся человек чем я и мне не хотелось бы с ним спорить, а темболее через google translate

Ответ

Как оказалось я ошибся на счет бага, там unit генерируется динамически и слушающий сокет считуется с /etc/default/opendkim, у меня почему-то не считался и сгенерировался unit с дефолтным unix сокетом, а с файла конфигурации сокет вообще не должен считыватся, точнее он перекрывается передачей опции -p <сокет считаный с файла /etc/default/opendkim>, после полной переустановки пакета всё наладилось.
А теперь последовательность действий которую я бы посоветовал желающим отправить багрепорт касающийся какого либо пакета: 1. Попробуйте для начала переустановить полностю пакет и проверить воспроизводится ли баг после этого. 2. Проверте тщательно, действительно ли это баг, а не вы не правильно что-то делаете. 3. Проанализируйте баг чтоб можно было его нормально описать. 4. Ознакомтесь с информацией по данной ссылке https://wiki.debian.org/reportbug (Спасибо @alexander barakin ). 5. Установите пакет reportbug, введите reportbug <имя пакета с багом> и следуйте дальнейшим инструкциям.

Как можно переименовать package?

Имя пакета com.example.level.namis. Мне нужно теперь поменять example. В студио выбираю Refactor -> Rename, но она позволяет переименовать только level на другое имя, а нужно поменять example. Не переименовывать же каждый файл и папку тоже вручную.

Ответ

Ставишь галочку Compact Empty Middle Packeges и рефакторишь пакет. Вообще можно еще менять packageId в build.gradle.

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

Написав это import java.awt.*; я не получу, содержимое этого import java.awt.event.*; Хотя казалось бы должен получить, если учитывать, что существует иерархия пакетов. Вроде всё расфасовано по пакетам, в одном пакете, есть еще вложенные пакеты. Но получив доступ к пакету в котором, есть вложенные, я не получаю содержимого вложенных пакетов. Хочется понять, это получается из-за какого-то особого подхода к структурированию пакетов или же они действительно находятся в иерархической расположенности, но система не дает доступа к вложенным пакетам, если запрошен главный пакет? import java.awt.*; даст мне содержимое import java.awt.event;(заметьте звездочки нет во втором импорте) ? Или же event это тоже пакет, а import java.awt.*; даст мне все классы на этом уровне, но не пакеты? Выходит как в виндовс: применил, что то к папке, а там вопрос : применить к вложенным папкам? Вроде бы иерархия есть, но влияние на неё контролируется.

Ответ

Java рассматривает каждый пакет как независимый. Например, локальные пакеты не распространяются на любые «под»пакеты. Я подозреваю, что использование иерархии значимым образом было бы ценным, но дизайн Java должен был сделать все максимально простым.
Java не рассматривает пакеты как действительно подклассифицирующие друг друга; в то время как java.util и java.util.concurrency могут выглядеть так, как будто вторая часть является частью первой, однако они рассматриваются как полностью независимые, а точка в основном используется для аккуратности.
Причины этого решения, скорее всего, проистекают из общей тенденции Java к простоте. Лучшая практика часто никогда не использовать подстановочные символы импорта вообще.

Согласно спецификации JLS, Section 7.5, возможны только 4 способа произвести импорт:
A single-type-import declaration (§7.5.1) imports a single named type, by mentioning its canonical name (§6.7).
Одиночный импорт по его «каноническому» имени.
Например: import java.util.List;
A type-import-on-demand declaration (§7.5.2) imports all the accessible types (§6.6) of a named type or named package as needed, by mentioning the canonical name of a type or package.
Импорт всех доступных типов или пакетов по их «каноническому» имени. Это подразумевает, что будут импортированы все имена дочерних пакетов, но не их содержимое.
Например: import java.awt.*;
A single-static-import declaration (§7.5.3) imports all accessible static members with a given name from a type, by giving its canonical name.
Одиночный статический импорт, который импортирует все статические члены пакета.
Например: import static org.junit.Assert.assertEquals;
A static-import-on-demand declaration (§7.5.4) imports all accessible static members of a named type as needed, by mentioning the canonical name of a type.
Импорт всех статических членов пакета.
Например: import static org.junit.Assert.*;
Пакеты позволяют дать одинаковое имя разным классам. Если бы была возможность импортировать с помощью * всю суб-иерархию пакетов, была бы неразбериха в ваших локальных именах классов.

Ассоциация: why doesn't Java have “deep” wildcard import?, Java import all from all

Как найти информацию про установленный пакет на Linux?

Доброго времени суток.
Вопрос довольно глобального характера. Я не могу понять саму концепцию.
Как найти информацию по работе установленного пакета? Где найти примеры использования? Где расположены в системе файлы, файлы с примерами, мануалы? Какие методы использует этот пакет, чтобы к нему обратиться?
На данный момент я представляю себе поиск информации так:
Поиск на форумах и сайтах статей и вопросов от тех, кто уже делал похожий проект и устанавливал данные пакеты (оттуда и знание о существовании самого пакета) Stackoverflow Git репозиторий проекта и его Вики apt-cache show [пакет] - обычно лишь общие слова о работе пакета, которые я уже знаю man [пакет] - не работает, потому что нужно знать название методов данного пакета
В результате я получаю отрывки информации, нет полной картины. Я использую методы, какие озвучены, но не знаю о существовании других. Часто никакого Вики вообще нету..
А хотелось бы получить хотя бы название методов, чтобы дальше уже копать по ним, примеры использования. В идеале структурированную информацию о пакете
Для примера: установил я пакеты sudo apt install zbar-tools python-zbar python-qrtools - для распознавания qr кода на изображении или же sudo apt-get install bluetooth bluez blueman (это для работы с bluetooth на Raspberry Pi). Я знаю о существовании мифического файла blescan.py с примером работы, но не могу найти его расположения.
Буду признателен за объяснения и разжёвывание общих принципов.

Ответ

начинать можно с просмотра файлов, входящих в пакет:
$ dpkg -L имя.пакета

например, рассмотрим пакет bluez
исполняемые файлы обычно располагаются в каталогах, содержащих в пути строку bin
$ dpkg -L bluez | grep bin /bin /bin/hciconfig /usr/sbin /usr/bin /usr/bin/bluetoothctl /usr/bin/bccmd /usr/bin/btmon /usr/bin/rctest /usr/bin/hciattach /usr/bin/hcitool /usr/bin/sdptool /usr/bin/ciptool /usr/bin/l2ping /usr/bin/l2test /usr/bin/rfcomm /usr/bin/gatttool /usr/sbin/bluetoothd
видим ряд исполняемых файлов, начиная с hciconfig и заканчивая bluetoothd
man-страницы обычно располагаются в каталогах, содержащих в пути строку man
$ dpkg -L bluez | grep man /usr/share/man /usr/share/man/man8 /usr/share/man/man8/bluetoothd.8.gz /usr/share/man/man1 /usr/share/man/man1/bluetoothctl.1.gz /usr/share/man/man1/btmon.1.gz /usr/share/man/man1/l2test.1.gz /usr/share/man/man1/hid2hci.1.gz /usr/share/man/man1/l2ping.1.gz /usr/share/man/man1/rctest.1.gz /usr/share/man/man1/rfcomm.1.gz /usr/share/man/man1/ciptool.1.gz /usr/share/man/man1/hcitool.1.gz /usr/share/man/man1/hciconfig.1.gz /usr/share/man/man1/hciattach.1.gz /usr/share/man/man1/bccmd.1.gz /usr/share/man/man1/sdptool.1.gz
видим ряд man-страниц, начиная с bluetoothd и заканчивая sdptool. просмотреть их можно командами man bluetoothd, ..., man sdptool
документацию (иногда содержащую примеры) можно отобрать по признаку «содержит строку doc в пути»:
$ dpkg -L bluez | grep doc /usr/share/doc /usr/share/doc/bluez /usr/share/doc/bluez/README.Debian.gz /usr/share/doc/bluez/changelog.Debian.gz /usr/share/doc/bluez/changelog.Debian.amd64.gz /usr/share/doc/bluez/NEWS.Debian.gz /usr/share/doc/bluez/changelog.gz /usr/share/doc/bluez/copyright
нередко, если документации много, её выделют в отдельный пакет, имя которого заканчивается суффиксом -doc (а иногда ещё и с дополнительным разбиением на языки, с добавлением суффикса -язык). например, документация к пакету aptitude содержится в таких пакетах:
$ apt-cache search aptitude doc aptitude-doc-cs - Czech manual for aptitude, a terminal-based package manager aptitude-doc-en - English manual for aptitude, a terminal-based package manager aptitude-doc-es - Spanish manual for aptitude, a terminal-based package manager aptitude-doc-fi - Finnish manual for aptitude, a terminal-based package manager aptitude-doc-fr - French manual for aptitude, a terminal-based package manager aptitude-doc-it - Italian manual for aptitude, a terminal-based package manager aptitude-doc-ja - Japanese manual for aptitude, a terminal-based package manager aptitude-doc-ru - Russian manual for aptitude, a terminal-based package manager

Запрет доступа файлам одного пакета к файлам другого пакета

Здравствуйте, в ходе разработки приложения под андроид возникла следующая проблема:
имеются java файлы которые предназначены для реализации логики для подключения к устройству типа1 они лежат в package Device1 (внутри этого пакета находятся также подпакеты), другие java файлы лежат в package Device2
В каждом пакете (Device1, Device2) имеются java файлы с одинаковым названием например Func. Пакеты Device1, Device2 должны работать не зависимо друг от друга. Т.е. файлы пакета Device1 не могут ссылаться на Func из пакета Device2 и наоборот.
Также есть еще пакет CommonConnection, который реализует первоначальное подключение к пакетам Device1, Device2. В этом случае пакет CommonConnection должен иметь доступ ко все остальным пакетам и Device1 и Device2.
Можно ли как-то запретить файлам из пакета Device1 ссылаться на файлы из пакета Device2 и наоборот, чтобы по ошибке при вводе автодополнения не ввести файл из чужого пакета, при этом чтобы общий пакет CommonConnection имел доступ и к файлам пакета Device1 и к файлам Device2 ?
Заранее благодарю всех за ответы.

Создал модули Device1, Device2, CommonConnection. В build.gradle для CommonConnection ввел зависимости для Device1, Device2 в итоге получил ошибку.


Резюмирую здесь решение моей задачи, возможно кому-то пригодиться в будущем:
1) Создаем 3 моудля CommonConnection, Device1, Device2. Нам необходимо, чтобы файлы в CommonConnection имели доступ в Device1, Device2. А Device1, Device2 были изолированы друг от друга, т.е. файл из Device1 не мог иметь доступ в Device2. 2) После создания модулей необходимо зайти в gradle для Device1 и внести следующие изменения:
**apply plugin: 'com.android.application'**
изменить на apply plugin: 'com.android.library'
И в defaultConfig убрать строку applicationId "com.bignerdranch.android.Device1"

3) Для Device2 нужно сделать тоже самое. 4) В gradle файле для CommonConnection нужно добавить строку compile project(':Device1')

5) Далее нужно явно указать что нужно запускать первоначально именно активити модуля CommonConnection. Нажимаем на Select Run/Debug Configuration и выбираем модуль CommonConnection. Далее еще раз нажимаем на Select Run/Debug Configuration -> EditConfigurations.. ** в меню **Launch Options в строке Activity жмем на ... и выбираем активити для CommonConnection в частности MainActivityCommonConnection

6) Теперь можно запустить проект и проверить.

Ответ

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

Почему пакеты в java принято называть в обратную сторону доменного имени?

То что это делать надо именно так, везде написано. Но почему люди договорились называть именно так? Может быть в этом есть какое-то неочевидное удобство?

Ответ

Уникальные имена в глобальном масштабе исключают конфликты имен между библиотеками из разных источников. Вместо создания новой центральной базы данных глобальных имен используется реестр доменных имен.
Java Language Specification (JLS):
The suggested convention for generating unique package names is merely a way to piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for package names.
Представь, что у тебя есть например четыре важных пакета и ты напишешь их так:
package controller.mysite.org; package model.mysite.org; package service.mysite.org; package dao.mysite.org;
Это означает, что существует основной пакет, подраздел которого относится к твоей компании (имя твоего ресурса), а подраздел этого пакета называется пакетом org, который ты фактически используешь и он есть уникальный. Но если написать так:
package org.mysite.controller; package org.mysite.model; package org.mysite.service; package org.mysite.dao;
Эта запись имеет больший смысл. Из всех пакетов из организаций (org) ты, смотришь на имя своей компании, и у нее есть четыре подпакета: controller, model, service, dao

Почему пакеты в java принято называть в обратную сторону доменного имени?

То что это делать надо именно так, везде написано. Но почему люди договорились называть именно так? Может быть в этом есть какое-то неочевидное удобство?

Ответ

Уникальные имена в глобальном масштабе исключают конфликты имен между библиотеками из разных источников. Вместо создания новой центральной базы данных глобальных имен используется реестр доменных имен.
Java Language Specification (JLS):
The suggested convention for generating unique package names is merely a way to piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for package names.
Представь, что у тебя есть например четыре важных пакета и ты напишешь их так:
package controller.mysite.org; package model.mysite.org; package service.mysite.org; package dao.mysite.org;
Это означает, что существует основной пакет, подраздел которого относится к твоей компании (имя твоего ресурса), а подраздел этого пакета называется пакетом org, который ты фактически используешь и он есть уникальный. Но если написать так:
package org.mysite.controller; package org.mysite.model; package org.mysite.service; package org.mysite.dao;
Эта запись имеет больший смысл. Из всех пакетов из организаций (org) ты, смотришь на имя своей компании, и у нее есть четыре подпакета: controller, model, service, dao