Terima kasih banyak atas ulasan Anda!

Hal pertama yang harus diperhatikan adalah, bahwa kodenya sangat bertele-tele. Sementara token seperti ELEKTRA_TAG_LCDEXEC_ADDRESS mudah dipahami pada pandangan pertama, saya menemukan bahwa mereka membuat kode lebih sulit untuk dibaca jika Anda memiliki banyak baris ini.

Saya pikir itu adalah default yang baik untuk memiliki nama yang aman dari tabrakan. Apakah Anda ingin LCDproc LCDEXEC_ADDRESS saja?

Selanjutnya Anda tampaknya menyukai tipe data buram.

Ya, saya menyukainya karena kami ingin memberikan pengalaman peningkatan yang mulus kepada API. Dalam kasus konkret getter, kita bisa membuat pengecualian (kita sudah melakukannya di pembuatan kode C++). Tapi saya melihat ini sebagai optimasi yang hanya harus dilakukan jika kita melihatnya relevan untuk LCDproc. ( @kodebach akan membandingkan ini.) Dari pengalaman saya, ini hanya relevan jika getter dipanggil sangat sering dalam loop ketat. Jika getter hanya digunakan beberapa kali dalam prosedur startup, itu tidak masalah.

Saya melihat bahwa Anda menyediakan versi tipe data dasar Anda sendiri seperti long. Masalah apa yang Anda coba selesaikan dengan itu?

Jenis seperti "int" memiliki ukuran yang berbeda pada platform yang berbeda tetapi kita perlu tahu apa yang kita izinkan di file konfigurasi.

Pegangan kesalahan itu adalah struktur data malloc()ed agak mengejutkan.

Ya, kami berdiskusi panjang tentang ini. @domhof sangat yakin bahwa itu jauh lebih baik untuk kegunaan API. Jika Anda tidak meneruskan objek kesalahan, panggilan API akan keluar, yang membuatnya sangat sulit untuk digunakan secara salah. Saya tidak yakin apakah ini sepenuhnya diterapkan sekarang. (@kodebach?)

Sekarang Anda menggunakan malloc dalam konteks di mana Anda jelas harus memperlakukannya sebagai gagal aman.

Itu juga yang kami panggil mallocs lain ketika kesalahan terjadi. Konsep API akan gagal aman: Jika malloc untuk objek kesalahan gagal, pointer nol akan diteruskan ke API dan kemudian Elektra akan keluar jika gagal. Tapi ini belum teruji. Apakah ini penting agar berhasil?

Dugaan saya adalah sampai elektraClose() dipanggil, tetapi tidak jelas.

Poin bagus, dokumen API harus sangat jelas tentang itu, saya membuat #2774.

Saya pikir itu adalah default yang baik untuk memiliki nama yang aman dari tabrakan.

Tentu, tetapi selama kompiler mendeteksinya, tidak ada hal buruk yang bisa terjadi.

Apakah Anda menginginkan LCDproc LCDEXEC_ADDRESS saja?

LCDEXEC_ADDRESS atau CONF_ADDRESS keduanya tampak masuk akal bagi saya.

Tapi saya melihat ini sebagai optimasi yang hanya harus dilakukan jika kita melihatnya relevan untuk LCDproc.

Ini sebagian besar merupakan komentar umum. Saya tidak merasa lcdproc terpengaruh lebih buruk dari yang lain.

Dari pengalaman saya, ini hanya relevan jika getter dipanggil sangat sering dalam loop ketat. Jika getter hanya digunakan beberapa kali dalam prosedur startup, itu tidak masalah.

Pengalaman saya justru sebaliknya: Dalam lingkaran yang ketat, ketika semuanya ada dalam cache, beberapa instruksi tambahan tidak masalah - bahkan pada CPU ARM yang kebanyakan saya gunakan. Ini memuat kode ke dalam cache di tempat pertama, itu adalah operasi yang sebenarnya mahal. Tentu saja untuk kode inisialisasi, itu juga bukan masalah. Dalam konteks ini saya hanya peduli tentang ukuran binari yang dihasilkan: Pengoptimalan kompiler dapat melakukan banyak hal, tetapi tidak dapat mengatasi API.

Menggunakan struktur data buram membutuhkan biaya sekitar 20 byte per akses anggota melalui kasing transparan. Biaya RAM yang harus dibayar meskipun akses berada di beberapa jalur kesalahan yang jarang digunakan dan biaya flash yang harus dibayar meskipun kode tidak berjalan sama sekali. Kalikan ini dengan jumlah akses dalam aplikasi biasa dan jumlah sistem tempat aplikasi berjalan, dan Anda dengan mudah mendapatkan angka yang agak besar. Tentu saja ada kasus di mana pengeluaran sumber daya tersebut untuk fleksibilitas ekstra masuk akal. Tetapi dalam banyak kasus lain tidak dan hanya terjadi karena kebiasaan.

Saya melihat bahwa Anda menyediakan versi Anda sendiri dari tipe data dasar seperti long. Masalah apa yang Anda coba selesaikan dengan itu?
Jenis seperti "int" memiliki ukuran yang berbeda pada platform yang berbeda tetapi kita perlu tahu apa yang kita izinkan di file konfigurasi.

Ya, "int" buruk untuk data yang disimpan. Tetapi AFAIK tipe lain seperti "panjang" tidak memiliki masalah yang sama. Dan yang lebih penting, sudah ada jenis dari "stdint.h" dengan ukuran eksplisit, yang dikenal luas. Saya akan merekomendasikan Anda menggunakan itu. Menciptakan sendiri hanya membuat kode lebih sulit dibaca untuk semua orang.

Jika malloc untuk objek kesalahan gagal, pointer nol akan diteruskan ke API dan kemudian Elektra akan keluar jika gagal. Tapi ini belum teruji. Apakah ini penting agar berhasil?

Tentu saja tidak, saya masih menganjurkan untuk memperlakukan malloc() dari struktur data kecil yang gagal aman. Saya tidak akan mengomentari ini, jika bukan karena diskusi tahun lalu.

Tentu, tetapi selama kompiler mendeteksinya, tidak ada hal buruk yang bisa terjadi.

Ya, sekarang Anda mendapatkan pesan kesalahan yang cukup bagus bahkan dengan makro. Beberapa tahun yang lalu kesalahan kompiler tidak menunjukkan bagaimana makro memanipulasi sesuatu: Kemudian terkadang diperlukan banyak waktu untuk mengetahui bahwa makro terlibat.

Ini sebagian besar merupakan komentar umum. Saya tidak merasa lcdproc terpengaruh lebih buruk dari yang lain.

Ada perbedaan besar jika API digunakan untuk setiap akses konfigurasi dibandingkan jika aplikasi menyalin data konfigurasi ke dalam struct. Akan terpengaruh sebagian besar aplikasi yang tidak menyalin. Dan tidak menyalin sebenarnya disarankan jika Anda ingin pembaruan konfigurasi saat ini.

Pengoptimalan kompiler dapat melakukan banyak hal, tetapi tidak dapat mengatasi API.

Tepat, jadi saya bertanya-tanya mengapa pengalaman Anda bertentangan? Jika pengambil kami akan mengembalikan beberapa anggota struct dan dapat digariskan, tidak akan ada biaya API. Jika Anda hanya membayar biaya API dalam jumlah kasus yang konstan, ini sangat berbeda dengan aplikasi di mana jumlah panggilan API yang tidak terbatas dapat dilakukan (yang tidak disalin).

Ya, "int" buruk untuk data yang disimpan. Tetapi AFAIK tipe lain seperti "panjang" tidak memiliki masalah yang sama. Dan yang lebih penting, sudah ada jenis dari "stdint.h" dengan ukuran eksplisit, yang dikenal luas. Saya sarankan Anda menggunakan itu. Menciptakan sendiri hanya membuat kode lebih sulit dibaca untuk semua orang.

Untuk C99 atau jika stdint.h tersedia, kami mengetikkannya. Jadi kami dapat menggunakan tipe berukuran tetap ini jika Anda hanya mendukung sistem yang memiliki C99 atau stdint.h.

Saya harap, saya membahas semuanya ...

Hal-hal yang sebenarnya bisa diubah

(tanpa mendesain ulang sebagian besar API)

Sementara token seperti ELEKTRA_TAG_LCDEXEC_ADDRESS mudah dipahami pada pandangan pertama, saya menemukan bahwa mereka membuat kode lebih sulit untuk dibaca jika Anda memiliki banyak baris ini.

Saya pikir itu adalah default yang baik untuk memiliki nama yang aman dari tabrakan.

Tentu, tetapi selama kompiler mendeteksinya, tidak ada hal buruk yang bisa terjadi.

Saya setuju, tag saat ini sangat panjang. Sayangnya karena C tidak mendukung segala jenis ruang nama, sulit untuk menghindari nama yang panjang dan pada saat yang sama menghindari tabrakan nama secara umum. Saya akan menambahkan beberapa opsi untuk memanipulasi tag yang dihasilkan. Saat ini mereka dibuat menggunakan awalan ELEKTRA_TAG_ dan kemudian versi nama kunci yang diadaptasi. Jadi ELEKTRA_TAG_LCDEXEC_ADDRESS adalah singkatan dari kunci lcdexec/address .

Anda juga tidak harus menggunakan tag sama sekali. Jika Anda melihat bagaimana tag diselesaikan, Anda dapat menemukan beberapa alternatif yang menyelesaikan fungsi inline yang sama. Beberapa alternatif ini mungkin lebih pendek. Ini juga harus cukup aman untuk langsung menggunakan fungsi inline (misalnya elektraGetLcdexecAddress ).

Secara khusus saya tidak suka, bahwa Anda juga menggunakan tipe data elektra dalam struktur data LCDproc yang tidak terkait langsung dengan konfigurasi.

Kita mungkin bisa menggunakan tipe stdint.h yang setara. Meskipun belum tentu 100% kompatibel, jika Anda menggunakan compiler yang tidak sesuai dengan C99. (lihat di bawah untuk detailnya)

Mungkin ini sudah dijawab di beberapa dokumen, tetapi saya tidak menemukannya dengan cepat: Ketika elektraGet() mengembalikan string (atau penunjuk lain ke struktur data), apa ruang lingkup di mana objek itu valid? Dugaan saya adalah sampai elektraClose() dipanggil, tetapi tidak jelas. Juga apa kebijakan yang baik untuk menjaga pegangan Elektra terkait dengan penggunaan sumber daya (dan pertimbangan lainnya)?

Ini sebenarnya cukup rumit. Lihat jawaban saya di #2774.

Mengenai desain API

Selanjutnya Anda sepertinya menyukai tipe data buram.

Saya juga bukan penggemar bagaimana Elektra menggunakan struct. Namun, saya tidak memiliki pengaruh pada keputusan ini. Saya memang mencoba meminimalkan dampak kinerja (dan ukuran biner) dari API pembuatan kode. Itulah mengapa semua fungsi pengakses yang dihasilkan adalah static inline . AFAIK dengan cara itu kompiler harus sebaris bila memungkinkan dan karena statis, semua yang tidak digunakan harus dihapus.

Dalam kasus konkret getter, kita bisa membuat pengecualian (kita sudah melakukannya di pembuatan kode C++). Tapi saya melihat ini sebagai optimasi yang hanya harus dilakukan jika kita melihatnya relevan untuk LCDproc. ( @kodebach akan membandingkan ini.)

Apa sebenarnya maksud Anda? Mohon jelaskan apa sebenarnya yang Anda maksud dengan "membuat pengecualian".

Saya melihat bahwa Anda menyediakan versi Anda sendiri dari tipe data dasar seperti long. Masalah apa yang Anda coba selesaikan dengan itu? IMO sebagian besar membuat kode lebih sulit dibaca.

Saya sangat setuju. AFAIK masalah yang kami coba selesaikan adalah bahwa C tidak menentukan ukuran tetap untuk tipe datanya. Standar C hanya mendefinisikan batas bawah.

Mengapa nama verbose berdasarkan tipe CORBA digunakan, saya tidak tahu. Keputusan ini sebelum waktu saya dan saya sama sekali tidak tahu, bagaimana kesimpulan ini dicapai. Saya mengerti bahwa dengan menggunakan tipe kami sendiri, kami mempertahankan beberapa kompatibilitas C89 (walaupun saya cukup yakin kami tidak sepenuhnya kompatibel dengan C89, API yang dihasilkan kode tentu saja tidak), tetapi itu bukan argumen yang cukup baik untuk menentang penggunaan stdint.h IMHO.

Namun: Seperti yang dinyatakan di atas, jika C99+ digunakan semua jenis fallback $# kdb_ stdint.h yang setara.

jika Anda hanya mendukung sistem yang memiliki C99

API pembuatan kode kurang lebih membutuhkan C99. Kami menggunakan hal-hal seperti for (int i = 0; ...) { ... } jadi kami jelas tidak sesuai dengan C89 (GNU89 mungkin berfungsi).

Pegangan kesalahan itu adalah struktur data malloc()ed agak mengejutkan.

Penanganan kesalahan juga diputuskan sebelum waktu saya. Saya juga tidak akan melakukannya dengan cara ini. Namun, saya yakin bahwa dalam kebanyakan kasus kita dapat memperlakukan malloc() sebagai bukti gagal. Juga menangani kesalahan pada tumpukan sulit dilakukan di sini, karena mungkin ada banyak peringatan. Untuk menangani semua yang ada di tumpukan, kita perlu mengalokasikan ruang untuk jumlah maksimum peringatan (saya kira 1000) di tumpukan.

Saat ini juga ada refactoring utama dari penanganan kesalahan tingkat rendah yang sedang berlangsung, sehingga beberapa penanganan kesalahan tingkat tinggi akan berubah. Ini juga mengapa saat ini satu-satunya properti kesalahan yang dapat diakses publik adalah deskripsi.

Kesalahpahaman

Jika Anda tidak meneruskan objek kesalahan, panggilan API akan keluar, yang membuatnya sangat sulit untuk digunakan secara salah. Saya tidak yakin apakah ini sepenuhnya diterapkan sekarang. (@kodebach?)

Anda tidak harus melewati objek kesalahan. Anda hanya melewati ElektraError ** . Kami menyebabkan kesalahan fatal, jika pointer ini NULL. Kesalahan fatal secara default memanggil exit() . Dalam C murni ini mungkin juga satu-satunya cara untuk menangani kesalahan fatal. Namun, jika API digunakan dari mis. C++, penangan kesalahan fatal juga dapat melempar pengecualian.

Ada perbedaan besar jika API digunakan untuk setiap akses konfigurasi dibandingkan jika aplikasi menyalin data konfigurasi ke dalam struct.

Ya, tidak menyalin jauh lebih boros. (Lihat di bawah)

Dan tidak menyalin sebenarnya disarankan jika Anda ingin pembaruan konfigurasi saat ini.

Pembaruan saat itu juga (seperti dalam API notifikasi) tidak didukung dengan cara apa pun oleh API tingkat tinggi. Saat ini kami hanya memperbarui KeySet internal di elektraOpen , elektraEnsure (akan digabungkan menjadi elektraOpen ) dan panggilan elektraSet* (yang menghasilkan elektraSet cukup mahal). Kami mungkin mendukung pembaruan saat ini di masa mendatang, tetapi saya sangat menyarankan untuk tidak memanggil elektraGet* setiap kali Anda membutuhkan nilai konfigurasi Anda.

Saya sebenarnya merekomendasikan memanggil elektraGet* hanya sekali untuk setiap nilai konfigurasi, kecuali jika Anda cukup yakin itu akan mengembalikan nilai baru. Ini karena cara kerja sistem tipe Elektras. Setiap panggilan elektraGet* mengonversi nilai konfigurasi dari sebuah string.

Masalah Pengoptimalan

Sayangnya pengalaman saya adalah bahwa Elektra dioptimalkan dengan sangat buruk dan jika Anda benar-benar peduli dengan kinerja, Anda tidak boleh menggunakannya (belum). IMO Elektra menggunakan malloc() terlalu banyak dan banyak operasi yang tampaknya murah sebenarnya tidak (°). Saya mengerti bahwa kdb* adalah operasi yang mahal ( kdbOpen masih lebih mahal dari yang Anda kira), tetapi juga banyak hal manipulasi Kunci yang mahal. Contoh yang bagus adalah keySetMeta . Tampaknya itu harus cukup lurus ke depan. Jika Anda tahu bahwa metadata disimpan dalam KeySet internal (°°), Anda akan berpikir bahwa keySetMeta kurang lebih sama dengan keyNew + ksAppendKey . Namun, ada ksLookup dan terkadang elektraStrDup (°°°) di sana.

Penggunaan RAM juga tidak cocok dengan Elektra. Misalnya setiap Key menyimpan nama kunci lengkap dua kali. Sekali lolos dan sekali dalam bentuk tidak lolos. Ini juga membuat file mmap-cache jauh lebih besar dari yang diharapkan.

(°) Ini mungkin karena fakta bahwa banyak orang telah bekerja di Elektra. Sebagian besar mungkin tidak terlalu peduli dengan kinerja.

(°°) Memiliki KeySet tersembunyi di dalam setiap Key adalah hal lain yang tidak saya sukai. Sebagian besar fungsionalitas KeySet dan Key tidak diperlukan untuk menyimpan metadata.

(°°°) Saya kira kita harus memiliki elektraStrDup dan elektraStrNDup untuk memastikan mereka menggunakan elektraMalloc (juga bukan penggemar itu), tetapi saya cukup yakin dengan tidak menggunakan strdup atau strndup kami merusak beberapa pengoptimalan kompiler. Juga mengapa elektraStrLen adalah sesuatu, saya tidak akan pernah mengerti. Dikatakan unicode dan multibyte aman, tapi saya tidak mengerti caranya. Jelas itu tidak akan melaporkan panjang yang benar untuk ASCII yang disandikan UTF-16.

Sepertinya github memakan balasan saya melalui email kemarin. Tempel di sini lagi:

Terima kasih atas petunjuk Anda. Saya sebenarnya mengkompilasi elektra dan lcdproc
malam ini. Berikut adalah hasil saya, saya akan menjawab percakapan besok.

Setelah kompilasi, saya membandingkan ukuran biner dengan dan tanpa modifikasi Anda
(melakukan f0cb7bb1 vs. 7973efc3) dan memperhatikan bahwa semua binari meningkat
banyak. Sebagai contoh:

harald<strong i="11">@debian</strong>:~$ ls -l lcdproc*/clients/lcdexec/lcdexec
33852 Jun 11 17:39 lcdproc-0.5base/clients/lcdexec/lcdexec
73520 Jun 11 17:56 lcdproc/clients/lcdexec/lcdexec

Dalam beberapa hal hasil yang mengecewakan. Terutama mengingat bahwa
versi dasar memiliki pengurai konfigurasi yang terhubung secara statis sementara versi
versi baru secara dinamis terkait dengan libelektra.

Penyebab utamanya tampaknya adalah kode di dalam elektragen.c, tetapi kebanyakan lainnya
file objek telah meningkat dalam ukuran juga.

Saya juga mencoba mengambil beberapa pengaturan waktu, tetapi klien mana pun segera melakukan kesalahan.
Ini ada di buster armhf. ( kdb ls / berfungsi dengan baik.)

Saya belum memeriksanya, tapi saya kira segfault akan cukup
mudah diperbaiki. Masalah ukuran OTOH sangat mengganggu saya.

Inilah yang dikatakan gdb tentang segfault:

Reading symbols from lcdproc/clients/lcdproc/lcdproc...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/harald/lcdproc/clients/lcdproc/lcdproc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xb6745ed0 in getPluginPlacementList (plugin=0x0)
    at /home/harald/libelektra/src/plugins/list/list.c:496
496             Key * pluginInfo = keyNew ("system/elektra/modules/", KEY_END);

Sepertinya github memakan balasan saya melalui email kemarin.

Itu berakhir di sini https://github.com/ElektraInitiative/libelektra/issues/2748#issuecomment -501032010.

semua binari meningkat banyak.

Bagian dari itu adalah spesifikasi yang dikompilasi ke dalam biner. Namun masih ada beberapa redudansi. Aku akan melihat ke dalamnya.

Tetapi jika Anda ingin menjaga ukuran biner tetap kecil, Anda akan selalu lebih baik dengan solusi khusus Anda sendiri. Sebenarnya, tidak ada gunanya membandingkan ukuran biner saja, karena Anda juga harus menginstal pustaka Elektra. Itu saja lebih besar dari klien LCDproc lama. Anda hanya perlu membuat keputusan di sini: Apakah Anda menginginkan semua fitur Elektra atau Anda ingin binari kecil?

awalan ELEKTRA_TAG

Sebenarnya, kita hanya membutuhkan awalan yang dipilih pengguna, dan di LCDproc kita akan memilih untuk tidak memiliki awalan.

Apa sebenarnya maksud Anda? Mohon jelaskan apa sebenarnya yang Anda maksud dengan "membuat pengecualian".

Kita dapat membuat pengecualian bahwa elektraGet tidak membuat panggilan API.

Mengapa nama verbose berdasarkan tipe CORBA digunakan, saya tidak tahu. Keputusan ini sebelum waktu saya dan saya sama sekali tidak tahu, bagaimana kesimpulan ini dicapai.

Itu didokumentasikan di #1324.

Ini karena cara kerja sistem tipe Elektras. Setiap panggilan elektraGet* mengonversi nilai konfigurasi dari sebuah string.

Ini karena cara kerja implementasinya, bukan karena tipe sistemnya. Kode yang dihasilkan C++ sudah menunjukkan bahwa itu bisa berbeda. Tapi saya khawatir ini akan menjadi implementasi ulang elektraGet dan beberapa bagian dari pembuatan kode.

Optimalisasinya tidak begitu sepele (terutama di C, di mana Anda perlu membuat struct).

Bagian dari itu adalah spesifikasi yang dikompilasi ke dalam biner. Namun masih ada beberapa redudansi. Aku akan melihat ke dalamnya.

Mungkin kita harus mempertimbangkan kembali kompilasi-dalam spesifikasi jika ukuran biner sangat penting. (Dan gagal jika tidak ada spesifikasi)?

Atau memiliki sakelar kompilasi untuk mengompilasinya?

@haraldg Bagaimana menurutmu?

Anda hanya perlu membuat keputusan di sini: Apakah Anda menginginkan semua fitur Elektra atau Anda ingin binari kecil?

Sebagian besar fitur Elektra seharusnya tidak mempengaruhi ukuran biner aplikasi sama sekali. Spesifikasi yang dikompilasi, yang menyediakan fitur yang juga dapat dijalankan oleh aplikasi tanpa diinstal, merupakan pengecualian dan bukan aturan.

Ini karena cara kerja sistem tipe Elektras. Setiap panggilan elektraGet* mengonversi nilai konfigurasi dari sebuah string.

Ini karena cara kerja implementasi, bukan karena tipe sistemnya.

Sistem tipe (seperti tipe yang tersedia) tidak relevan ya. Tapi "cara kerja sistem tipe Elektras" tidak. Yang saya maksud adalah inti dari Elektra tidak memiliki sistem tipe. Semuanya adalah string. Mengapa harus memeriksa jenis melalui plugin type . Tetapi kami hanya menyimpan string, karena Kunci tidak memiliki gagasan tentang tipe.

Optimalisasinya tidak begitu sepele (terutama di C, di mana Anda perlu membuat struct).

Kita hanya perlu menyimpan nilai yang dikonversi di dalam struct Key setelah pengecekan tipe. Tetapi tidak ada cara untuk melakukan itu sekarang. Bahkan melalui metadata, IMO mana yang akan menjadi solusi yang salah.

Mungkin kita harus mempertimbangkan kembali kompilasi-dalam spesifikasi jika ukuran biner sangat penting. (Dan gagal jika tidak ada spesifikasi)? Atau memiliki sakelar kompilasi untuk mengompilasinya?

Saya akan menambahkan opsi ke pembuatan kode untuk menonaktifkannya. Tetapi pada titik tertentu kita harus mendefinisikan apa tujuan kita. Elektra tidak dapat memenuhi semua kasus penggunaan. Ukuran biner, penggunaan RAM, dan kinerja adalah semua metrik di mana solusi khusus yang terbatas pada kebutuhan tepat aplikasi akan selalu mengungguli solusi umum seperti Elektra.

Hal lain yang mungkin meningkatkan ukuran biner adalah fakta bahwa kami juga menghasilkan setter untuk semuanya. Saya akan menambahkan opsi untuk menonaktifkan setter, jika kompiler Anda tidak menghapus fungsi yang tidak digunakan ini.

Sistem tipe (seperti tipe yang tersedia) tidak relevan ya. Tapi "cara kerja sistem tipe Elektras" tidak. Yang saya maksud adalah inti dari Elektra tidak memiliki sistem tipe. Semuanya adalah string. Mengapa harus memeriksa tipe melalui plugin tipe. Tetapi kami hanya menyimpan string, karena Kunci tidak memiliki gagasan tentang tipe.

Ya, ini adalah cara kerja implementasi Anda. Tapi Anda sudah bisa mengubah lebih awal dan hanya mengembalikan nilai di elektraGet.

Kami hanya perlu menyimpan nilai yang dikonversi di dalam struct Kunci setelah pemeriksaan tipe. Tetapi tidak ada cara untuk melakukannya sekarang. Bahkan melalui metadata, IMO mana yang akan menjadi solusi yang salah.

Jika Anda membutuhkan ksLookup, Anda tetap terlalu lambat. Jika Anda menginginkannya dengan sangat cepat, Anda perlu membuat struct, mengisinya di elektraOpen, dan di elektraGet adalah fungsi inline statis yang mengembalikan anggota struct. (Maka Anda secara sepele juga memiliki semua jaminan.)

Saya akan menambahkan opsi ke pembuatan kode untuk menonaktifkannya.

@kodebach Lebih baik menunggu jawaban dari Harald. Dan pertama-tama kita perlu mencari tahu apa penyebab dari biner besar itu, mungkin bukan hanya speknya saja.

Saya sebenarnya sangat menyukai ide Anda tentang spesifikasi yang dikompilasi dengan specload. Jadi saya juga berpikir bahwa kami dapat memampatkan spesifikasi tetapi ini akan menjadi terlalu banyak untuk tesis Anda sekarang.

Hal lain yang mungkin meningkatkan ukuran biner adalah fakta bahwa kami juga menghasilkan setter untuk semuanya. Saya akan menambahkan opsi untuk menonaktifkan setter, jika kompiler Anda tidak menghapus fungsi yang tidak digunakan ini.

@kodebach Apakah Anda dapat mereproduksi ukuran biner yang besar? Harap selalu terlebih dahulu mencoba menemukan penyebabnya sebelum Anda mengoptimalkan.

Hai, karena saya terlambat ke pesta dan Anda sudah banyak berdiskusi, saya tidak akan menanggapi semuanya lagi. Jika Anda merasa Anda melewatkan jawaban atas sesuatu dari saya, silakan angkat masalah ini lagi.

Dari mana peningkatan ukuran berasal:

Ya, string adalah bagian besar. Namun bagian teks jauh lebih besar daripada bagian ro-data. Saya kira mendorong semua argumen ke banyak panggilan keyNew() ke tumpukan sebenarnya membutuhkan lebih banyak ruang daripada argumen itu sendiri.

Saya baru saja menggunakan CFLAGS default lcdproc, tidak yakin pengoptimalan mana yang mereka pilih - mungkin tidak ada. Namun saya tidak berpikir bahwa setter atau kode lain yang tidak digunakan adalah masalah: Ukuran sebagian besar objek hanya tumbuh moderat - mungkin hanya karena argumen fungsi tambahan dan perubahan kecil lainnya.

Saya mengkompilasi elektragen.c secara manual dengan optimasi -O dan file objek yang dihasilkan sedikit lebih kecil, tetapi tidak ada yang dramatis. Saya kira lebih banyak eksperimen dapat dilakukan, tetapi ini sepertinya bukan solusi sendiri.

Tentang metrik dan pengoptimalan

Kami tidak benar-benar mengoptimalkan lcdproc untuk apa pun, tetapi cobalah untuk tidak menggunakan sumber daya secara sia-sia. Jelas tidak ada batas ukuran yang kuat. Namun saya peduli tentang mendukung sistem tertanam, lagipula saya adalah pengelola paket OpenWRT dari elektra.

Memang benar peningkatan ukurannya masih kecil dibandingkan dengan ukuran elektra itu sendiri. Mungkin akan menjadi gila untuk menggunakan elektra di lcdproc, jika itu adalah satu-satunya pengguna pada sistem tipikal di mana lcdproc diinstal. Saya judi elektra akhirnya lepas landas dan dipasang secara luas pula, jadi ukuran elektra sendiri tidak dihitung secara langsung. Namun, jika tren ukuran aplikasi yang diinstal hampir dua kali lipat terus berlanjut dan elektra meningkat, saya akan membutuhkan laptop baru hanya karena itu. Saya tidak menyukainya.

Saya juga merasa seperti ukuran elektra dibenarkan, karena menyediakan banyak fitur bagus. Tetapi peningkatan ukuran besar dalam binari aplikasi kurang dibenarkan: Saat ini kami membutuhkan dua kali ukuran di lcdproc untuk melakukan cukup banyak apa yang kami lakukan sebelumnya. (Ya, kami tidak terlalu peduli dengan bagian spesifikasi elektra.)

Metrik yang saya gunakan adalah: ukuran terpasang, ukuran biner, jejak memori, (baris cache diisi secara berkala), (instruksi dijalankan.) Dua yang terakhir tidak relevan di sini, karena kode terkait elektra tidak akan dieksekusi berulang kali.

Dari tiga ukuran biner lainnya adalah jenis yang paling tidak penting: Bagian biner terpetakan yang tidak digunakan secara teratur hanya akan dihapus dari RAM dan tidak menggunakan sumber daya secara permanen. ukuran biner sebagian besar berguna karena sangat mudah diukur dan dibandingkan. ukuran terpasang jelas membutuhkan ruang pada chip flash dan memori apa pun yang tidak dipetakan dari sistem file (yaitu struktur data malloc()ed) harus disimpan dalam RAM (kecuali jika Anda memiliki ruang swap, yang sebagian besar sistem tidak) selamanya.

Secara pribadi, saya kebanyakan menghabiskan upaya pengoptimalan pada masalah terkait cache. Tetapi selain dari pertimbangan API umum, itu tidak relevan untuk elektra.

Kemungkinan peningkatan dan solusi

Saya kekurangan banyak konteks keputusan desain di balik elektra, jadi saya mungkin tidak dapat berkontribusi banyak pada bagian diskusi ini. Beberapa ide, yang melayang di benak saya:

Beberapa waktu yang lalu Markus dan saya membahas kemungkinan untuk menggunakan pembuatan kode dengan beberapa jenis mode tertanam: Pada sistem tertanam biasanya tidak ada yang melakukan perubahan konfigurasi sama sekali. Semua string (bantuan) yang ditargetkan untuk pengguna dan banyak pemeriksaan tidak berguna. Mungkin ini mengarah ke arah yang sama dengan "sakelar kompilasi" yang disarankan di atas?

Mungkin spesifikasi dapat disimpan dalam format yang lebih efisien daripada membangunnya secara terprogram. (Saya mendengar Anda sudah mengeluh tentang masalah stabilitas ABI, tetapi setidaknya perlu dipertimbangkan.)

Sebenarnya, seluruh bisnis menyimpan spesifikasi dalam biner (biner mana bahkan dalam kasus aplikasi modular?) dan kemudian mencetaknya di stdout sesuai permintaan tampaknya agak berputar-putar bagi saya. Anda dapat menyimpannya di perpustakaan elf dan menautkannya secara dinamis (dan dl_open() dari kdb) atau bahkan menyimpannya dalam format lain yang sesuai dan efisien dan memuatnya di konstruktor elf. (Dengan asumsi sebenarnya ada alasan untuk tidak memuatnya selama elektraOpen(), yang mungkin akan saya lakukan.)

Pada akhirnya, saya tidak memiliki gambaran yang jelas tentang pengorbanannya, jadi saya tidak dapat memberikan saran yang serius. Itu adalah sesuatu yang hanya bisa dikembangkan selama diskusi.

Jawaban untuk @markus2330

Tapi Anda sudah bisa mengubah lebih awal dan hanya mengembalikan nilai di elektraGet.

Dan di mana nilai akan disimpan antara transformasi dan elektraGet ? Juga kapan transformasi itu terjadi? Apakah Anda akan mengubah semua kunci dalam elektraOpen ? Itu akan sangat boros, jika hanya sejumlah kecil kunci yang diakses. Kami tentu saja dapat mengubah selama pengambilan pertama dan kemudian hanya mengembalikan nilainya. Tetapi kemudian masih ada pertanyaan tentang bagaimana menyimpan nilai-nilai yang ditransformasikan. Jika kita memodifikasi Kunci di KeySet internal, kita harus "membatalkan modifikasi" mereka untuk setiap elektraSet jika tidak kdbSet tidak bekerja dengan benar. Jadi kita harus memiliki jenis cache KeySet yang terpisah, tetapi kemudian kita memerlukan beberapa pencarian selama elektraGet dan kita membuang-buang RAM. Jadi pada akhirnya solusi saat ini mungkin yang terbaik yang bisa kita lakukan, tanpa memodifikasi struct Key .

Jika Anda membutuhkan ksLookup, Anda tetap terlalu lambat.

Jika ksLookup terlalu lambat, semua Elektra terlalu lambat. ksLookup adalah salah satu operasi Elektra yang paling optimal.

Jika Anda menginginkannya dengan sangat cepat, Anda perlu membuat struct, mengisinya di elektraOpen, dan di elektraGet adalah fungsi inline statis yang mengembalikan anggota struct. (Maka Anda secara sepele juga memiliki semua jaminan.)

Anda sudah dapat membuat struct dengan API pembuatan kode. Sebenarnya ini sudah banyak digunakan di seluruh LCDproc. (Ini sedikit berbeda, karena ada elektraGet / elektraFillStruct khusus yang mengembalikan seluruh struct.) Kita bisa menyembunyikan struct seperti itu secara internal, tapi itu berarti API tingkat tinggi tidak ' t bekerja tanpa pembuatan kode lagi.

Apakah Anda dapat mereproduksi ukuran biner yang besar? Harap selalu terlebih dahulu mencoba menemukan penyebabnya sebelum Anda mengoptimalkan.

Opsi untuk menonaktifkan pembuatan setter mungkin juga berguna untuk hal lain, misalnya jika Anda dengan sengaja ingin melarang aplikasi menyetel kunci. Tentu saja menonaktifkan generasi tidak benar-benar melarang aplikasi untuk menetapkan nilai (ada cara lain), tetapi saya mengurangi kemungkinan kesalahan.

Menonaktifkan pembuatan barang specload juga masuk akal, jika digunakan dengan benar. Lihat di bawah untuk contoh.

Jawaban untuk @haraldg

Saya baru saja menggunakan CFLAGS default lcdproc, tidak yakin pengoptimalan mana yang mereka pilih

AFAIK jika debugging tidak diaktifkan, -O3 digunakan. Yang menurut artikel ini sebenarnya dapat meningkatkan penggunaan memori demi kecepatan eksekusi. Untuk mengoptimalkan ukuran kode -Os harus digunakan.

Saya secara manual mengkompilasi elektragen.c dengan optimasi -O dan file objek yang dihasilkan sedikit lebih kecil, tetapi tidak ada yang dramatis.

Saya jelas bukan ahli kompiler atau pengoptimalan, tetapi file objek AFAIK akan selalu berisi semua kode. Hanya ketika menautkan fungsi yang tidak digunakan yang dapat dieksekusi dapat dihapus.

Mungkin spesifikasi dapat disimpan dalam format yang lebih efisien daripada membangunnya secara terprogram.

Format penyimpanan yang lebih efisien akan mengakibatkan hilangnya kecepatan eksekusi.

Sebenarnya, seluruh bisnis menyimpan spesifikasi dalam biner dan kemudian mencetaknya di stdout sesuai permintaan tampaknya agak berputar-putar bagi saya.

Idenya adalah bahwa spesifikasi disematkan ke dalam executable yang menggunakannya. Dengan begitu spesifikasi selalu persis seperti yang diharapkan oleh executable. Itu tidak dapat dimodifikasi tanpa juga mengkompilasi ulang yang dapat dieksekusi (atau peretasan yang intens).

Anda bisa menyimpannya di perpustakaan elf dan menautkannya secara dinamis

Saya memikirkannya, tetapi ada dua kelemahan:
1) semua aplikasi harus mengirimkan perpustakaan objek yang dapat dieksekusi dan dibagikan
2) aplikasi dan perpustakaan mungkin dimodifikasi secara terpisah dan menjadi tidak sinkron

Elektra juga memiliki versi statis, jika dl_open tidak tersedia atau tidak disarankan karena alasan lain. Menggunakan .so tidak akan kompatibel dengan versi ini.

biner mana bahkan dalam kasus aplikasi modular?

Saat ini API pembuatan kode mengharapkan tepat satu yang dapat dieksekusi per spesifikasi, jadi pertanyaannya sepele. Namun, tidak ada yang menghentikan Anda untuk tidak menggunakan fungsi doSpecloadCheck (dapat diubah namanya) yang dihasilkan. Anda harus memasang spesifikasi menggunakan specload secara manual. Secara teori Anda dapat dengan mudah memasang aplikasi yang berbeda atau bahkan hanya skrip bash sederhana yang mencetak spesifikasi ke stdout. Jika Anda menyimpan spesifikasi sebagai file quickdump Elektra yang di-gzip /somewhere/spec.eqd.gz Anda bahkan dapat memasangnya melalui

sudo kdb mount -R noresolver spec.eqd "spec/sw/lcdproc/lcdproc/#0/current" specload "app=/usr/bin/zcat" "app/args=#0" "app/args/#0=/somewhere/spec.eqd.gz"

atau bahkan menyimpannya dalam format lain yang sesuai dan efisien dan memuatnya di konstruktor elf

Tidak yakin bagaimana seluruh hal konstruktor ELF bekerja. Itu di luar pengetahuan saya tentang C.

Dengan asumsi sebenarnya ada alasan untuk tidak hanya memuatnya selama elektraOpen(), yang mungkin akan saya lakukan.

Satu hal yang perlu Anda pertimbangkan, adalah spesifikasi harus dapat diakses oleh kdb serta aplikasi pengguna. Jika tidak, kdb set tidak dapat menjalankan validasi.

Pengamatan saya

Saya melakukan beberapa tes juga dan meskipun saya tidak menggunakan chip ARM, saya dapat mereproduksi peningkatan ukuran yang serupa pada x86-64. Dalam kasus saya, peningkatannya tidak terlalu ekstrem tetapi masih ~ 1,8x untuk lcdexec.

Saya kemudian hanya mengomentari semua baris keyNew (jelas executable tidak akan berjalan dengan benar, tetapi ukurannya dapat dibandingkan), dan peningkatan ukuran turun menjadi hanya ~1,3x. Bagian .text dan .rodata dipengaruhi secara signifikan oleh baris ini. Saya akan memikirkan cara yang lebih efisien untuk menyimpan spesifikasi.

Jika kita kemudian menggunakan -flto dan -fuse-linker-plugin untuk mengaktifkan penghapusan kode mati selama penautan, peningkatan ukuran berkurang menjadi hanya ~ 1,02x. (Catatan: versi lama pada dasarnya tidak terpengaruh oleh opsi ini; perbedaan ukuran <0,5%). Jadi kita mungkin harus mengaktifkan opsi ini secara default (untuk build non-debug).

Semua tes ini dilakukan dengan lcdexec . Untuk lcdvc kita beralih dari ~ 1.18x ke ~1.02x. Untuk lcdproc ini hanya mendapatkan perbedaan dari ~1.6x ke ~ 1.25x (di sini -flto -fuse-linker-plugin memiliki lebih banyak efek pada versi lama selain beberapa hal yang mencegah pointer inline).

TL; DR Saya pikir peningkatan ukuran dapat dikurangi melalui opsi kompiler dan beberapa perubahan pada bagaimana spesifikasi disimpan. Sayangnya tampaknya, ukuran biner masih akan meningkat, meskipun tidak menggunakan pengurai konfigurasi yang terhubung secara statis.

@haraldg menulis:

tolong angkat masalah lagi.

Jika diperlukan bahwa biner harus dapat memulai tanpa instalasi belum dijawab. Saya memulai masalah untuk memprioritaskan fitur di #2779.

Namun, jika tren ukuran aplikasi yang diinstal hampir dua kali lipat terus berlanjut dan elektra meningkat, saya akan membutuhkan laptop baru hanya karena itu. Saya tidak menyukainya.

Saya juga tidak menyukainya. Itu mengejutkan bagi saya bahwa itu terjadi. @kodebach Saya sangat tertarik dengan hasil Anda bagaimana API tingkat rendah dibandingkan dengan API tingkat tinggi.

Mungkin ini mengarah ke arah yang sama dengan "saklar kompilasi" yang disarankan di atas?

Ya, ini mengarah ke sini (terutama saran @kodebach untuk tidak menghasilkan setter). Jika Anda tidak menentang "sakelar kompilasi" seperti itu, kita dapat mendiskusikan kemungkinan lebih lanjut untuk mengurangi ukuran biner.

Sebenarnya, seluruh bisnis menyimpan spesifikasi dalam biner (biner mana bahkan dalam kasus aplikasi modular?) dan kemudian mencetaknya di stdout sesuai permintaan tampaknya agak berputar-putar bagi saya. Anda dapat menyimpannya di perpustakaan elf dan menautkannya secara dinamis (dan dl_open() dari kdb) atau bahkan menyimpannya dalam format lain yang sesuai dan efisien dan memuatnya di konstruktor elf. (Dengan asumsi sebenarnya ada alasan untuk tidak memuatnya selama elektraOpen(), yang mungkin akan saya lakukan.)

Tentu saja kami juga mendukung untuk memuatnya di elektraOpen() tetapi kemudian hanya berfungsi jika aplikasi sudah diinstal (spesifikasi perlu diinstal dan dipasang). Agar bagian dari biner selalu berfungsi, yang sangat berguna untuk pengembangan (Anda dapat menjalankan biner dari direktori build). Di masa depan yang lebih jauh, sesuatu seperti "strip" mungkin menghapus spesifikasi selama instalasi (seperti untuk binari yang diinstal mungkin tidak diperlukan). Namun, untuk menulis utilitas "strip" seperti itu, juga akan di luar jangkauan untuk @kodebach.

@kodebach menulis:

kita harus "membatalkan modifikasi" mereka untuk setiap elektraSet jika tidak kdbSet tidak bekerja dengan benar.

Tentu saja, elektraSet akan lebih mahal. Itu selalu perlu memperbarui KeySet dan cache (struct).

Jika ksLookup terlalu lambat, semua Elektra terlalu lambat. ksLookup adalah salah satu operasi Elektra yang paling optimal.

Jika Anda menganggap API yang dihasilkan kode juga merupakan bagian dari Elektra, maka API ini tidak terlalu lambat. Mereka bisa secepat akses ke variabel.

elektraFillStruct yang mengembalikan seluruh struct

Ahh, ok, sekarang aku lebih mengerti apa yang ingin kamu lakukan. Jadi pada dasarnya ide kami sama: Saya hanya akan menyembunyikan struct dari pengguna sehingga mereka tidak dapat melakukan perubahan pada struct (yang akan menghancurkan sinkronisasi ke KeySet).

Satu hal yang perlu Anda perhitungkan, adalah spesifikasi harus dapat diakses oleh kdb serta aplikasi pengguna. Jika tidak, set kdb tidak dapat menjalankan validasi.

Dan kami juga akan kehilangan introspeksi, akses ke default, ... dan segala sesuatu yang membuat hidup admin lebih mudah. Validasi hanya sebagian kecil dari ini.

Tentu saja kami juga mendukung untuk memuatnya di elektraOpen() tetapi kemudian hanya berfungsi jika aplikasi sudah diinstal (spesifikasi perlu diinstal dan dipasang). Agar bagian dari biner selalu berfungsi, yang sangat berguna untuk pengembangan (Anda dapat menjalankan biner dari direktori build).

Tampaknya ada kesalahpahaman besar di sini. Saat ini aplikasi yang menggunakan API pembuatan kode secara mutlak dan tanpa pengecualian memerlukan eksekusi panggilan kdb mount sebelum menjalankan aplikasi. Jika tidak, aplikasi akan berfungsi sampai batas tertentu, tetapi tidak akan memiliki semua fungsionalitas. Alasannya sederhana. Kami tidak memiliki cara untuk "menyuntikkan" barang ke kdbGet dengan cara yang diteruskan ke plugin.

Saya jelas bukan ahli kompiler atau pengoptimalan, tetapi file objek AFAIK akan selalu berisi semua kode. Hanya ketika menautkan fungsi yang tidak digunakan yang dapat dieksekusi dapat dihapus.

IIRC saat menggunakan setidaknya -O kompilator menjatuhkan simbol statis yang tidak digunakan. Linker mungkin menjatuhkan simbol eksternal tergantung pada flag.

Format penyimpanan yang lebih efisien akan mengakibatkan hilangnya kecepatan eksekusi.

Tentu saja ada pengorbanan. Namun ini tidak benar secara umum.

Dengan asumsi sebenarnya ada alasan untuk tidak hanya memuatnya selama elektraOpen(), yang mungkin akan saya lakukan.

Saya telah ceroboh. Yang saya maksud adalah sesuatu seperti: Baca selama loadConfiguration() dari file eksternal.

Satu hal yang perlu Anda perhitungkan, adalah spesifikasi harus dapat diakses oleh kdb serta aplikasi pengguna.

Ya, itulah salah satu alasan mengapa spec-is-in-the-binary ini berputar-putar. Memiliki spesifikasi dalam file terpisah akan membuat segalanya lebih sederhana. Dan mungkin juga mendukung aplikasi modular dengan baik.

aplikasi dan [spec] mungkin dimodifikasi secara terpisah dan menjadi tidak sinkron

Harus mudah untuk mencegah kecelakaan dengan menghasilkan nama file yang unik. Anda bahkan dapat menggunakan checksum untuk sedikit menjaga dari temper, tetapi saya tidak merekomendasikannya.

Jika kita kemudian menggunakan -flto dan -fuse-linker-plugin untuk mengaktifkan penghapusan kode mati selama penautan, peningkatan ukuran berkurang menjadi hanya ~ 1,02x. (Catatan: versi lama pada dasarnya tidak terpengaruh oleh opsi ini; perbedaan ukuran <0,5%). Jadi kita mungkin harus mengaktifkan opsi ini secara default (untuk build non-debug).

Itu menarik - saya harus memeriksa berapa banyak ukuran yang dibutuhkan parser konfigurasi lama, untuk mendapatkan ide yang lebih baik di mana kita berdiri. Namun perlu diingat, bahwa ini adalah fitur pengoptimalan khusus gcc dan juga (sama sekali bukan masalah lcdproc) menggunakan pengoptimalan ini mungkin tidak layak untuk menautkan aplikasi besar. (Saya tidak tahu apa-apa tentang topik ini, tetapi melakukan pengoptimalan secara global alih-alih per file sepertinya sesuatu, yang mungkin berskala buruk.)

Jika diperlukan bahwa biner harus dapat memulai tanpa instalasi belum dijawab.

Pada akhirnya, itu akan menyenangkan untuk dimiliki. Tapi saya sarankan pertama-tama kita fokus bagaimana seharusnya pada sistem produksi dan ABI umum untuk akses spesifikasi. Fitur pengembangan dan spesifikasi lcdproc harus datang kemudian.

Jika Anda tidak menentang "sakelar kompilasi" seperti itu, kita dapat mendiskusikan kemungkinan lebih lanjut untuk mengurangi ukuran biner.

Ya, idealnya kita akan memilih dengan configure jika ini adalah build untuk debugging, produksi, target yang disematkan, dll. configure akan mengatur semuanya agar pembuat kode melakukan hal yang benar. Saya tidak memiliki pendapat yang kuat tentang detailnya. Saya pikir kita setuju pada ide umum?

Tentu saja kami juga mendukung untuk memuatnya di elektraOpen() tetapi kemudian hanya berfungsi jika aplikasi sudah diinstal (spesifikasi perlu diinstal dan dipasang). Agar bagian dari biner selalu berfungsi, yang sangat berguna untuk pengembangan (Anda dapat menjalankan biner dari direktori build).

Anda juga bisa menyematkan nama file fallback alih-alih seluruh spesifikasi di dalam biner.

Di masa depan yang lebih jauh, sesuatu seperti "strip" mungkin menghapus spesifikasi selama instalasi (seperti untuk binari yang diinstal mungkin tidak diperlukan).

Ini tampaknya tidak praktis. Jauh lebih mudah untuk melakukan hal yang benar selama pembuatan kode.

Untuk mengeksplorasi pendekatan yang mungkin sedikit dan untuk kepentingan saya mendapatkan gambaran yang jelas tentang pengorbanan: Apakah saya memahami ini dengan benar, bahwa, jika kita tidak memiliki spesifikasi yang tersedia, aplikasi akan (atau setidaknya bisa) masih berjalan, tetapi akan crash (melalui panggilan balik kesalahan fatal) ketika kita mengakses nilai yang hilang dalam konfigurasi? Perilaku ini mungkin baik untuk sistem tertanam yang tidak dijaga. kdb akan digunakan untuk menggabungkan konfigurasi default dan konfigurasi kustom selama membangun firmware dan memvalidasi semuanya.

Sistem lain mungkin tidak terlalu peduli dengan validasi, tetapi masih ingin memiliki default untuk item konfigurasi yang hilang. Itu dapat dengan mudah didukung oleh varian dari elektraGet API: Sesuatu seperti elektraGetLongDefault("key", default_value) dalam banyak kasus hanya membutuhkan satu instruksi tambahan untuk meneruskan default_value - yaitu hanya ruang minimal yang diperlukan untuk menyimpan nilai . Saya tidak tahu apakah ini akan mengembalikan nilai default atau crash pada kesalahan percakapan, tapi jangan terganggu oleh detail. Pada waktu pembuatan kode, kami akan memilih antara ini dan mode spesifikasi penuh. Ini mungkin yang akan saya gunakan untuk paket OpenWRT LCDproc.

Untuk sistem non-embedded, kami jelas menginginkan spesifikasi lengkap. Jika menguraikan spesifikasi dari format hemat ruang dianggap terlalu mahal, Anda dapat menyimpan versi yang divalidasi dan hanya memvalidasi ulang jika cap waktu berubah. Tapi ini tidak relevan saat ini selain untuk menunjukkan bahwa kita tidak _harus_ mengambil kompromi yang buruk antara ukuran dan kecepatan.

Apakah saya mengerti ini dengan benar, bahwa, jika kita tidak memiliki spesifikasi yang tersedia, aplikasi akan (atau setidaknya bisa) tetap berjalan, tetapi akan macet (melalui panggilan balik kesalahan fatal) ketika kita mengakses nilai yang hilang dalam konfigurasi ?

Ada dua bagian untuk ini. KeySet dengan nilai default yang diteruskan ke elektraOpen dan spesifikasi lengkap yang harus dipasang dalam beberapa cara. Default yang diteruskan ke elektraOpen mencegah panggilan ke elektraGet gagal jika Kunci tidak ada. Namun mereka tidak mencegah kegagalan karena masalah konversi tipe. Untuk mencegah kegagalan tersebut, spesifikasi harus dipasang. Dengan spesifikasi yang dipasang elektraGet , panggilan tidak boleh gagal. Jika ada masalah elektraOpen akan gagal sebagai gantinya.

Sesuatu seperti elektraGetLongDefault("key", default_value) dalam banyak kasus hanya membutuhkan satu instruksi tambahan untuk meneruskan default_value - yaitu hanya ruang minimal yang diperlukan untuk menyimpan nilai.

Seperti yang dinyatakan di atas, Anda dapat meneruskan nilai default ke elektraOpen . Saat menggunakan pembuatan kode, KeySet ini dibuat dan default Anda akan selalu sesuai dengan spesifikasi Anda. Mungkin ada alasan lain juga mengapa API ini tidak digunakan, tetapi sudah diputuskan sebelum waktu saya.

Jika saya memahami semua masalah dengan benar, semuanya harus kurang lebih tercakup oleh tiga mode ini:

1. Spesifikasi dan default yang disematkan. Mirip dengan apa yang kita miliki sekarang. Menyematkan spesifikasi memastikannya tidak sinkron dengan aplikasi dan memungkinkan aplikasi file tunggal.
2. Spec dalam file eksternal, tidak ada default. Tidak ada KeySets dalam biner memastikan ukuran biner minimal. Aplikasi hanya akan berjalan, jika spec sudah terpasang. loadConfiguration memeriksa bahwa spesifikasi sudah terpasang. File eksternal juga dapat menyimpan KeySet dengan lebih efisien. kdb gen akan menghasilkan file quickdump. Bagaimana itu dipasang terserah pengguna (langsung, melalui cat dengan specload, gzip melalui gzip dengan specload, dll.).
3. Tidak ada spesifikasi, tidak ada default. Seperti 2, tetapi loadConfiguration tidak memeriksa spesifikasi. Oleh karena itu aplikasi akan berjalan, asalkan konfigurasinya benar. Ditujukan untuk kasus penggunaan di mana konfigurasi telah divalidasi sebelumnya dan tidak akan berubah.

@haraldg menulis:

Ya, itulah salah satu alasan mengapa spec-is-in-the-binary ini berputar-putar. Memiliki spesifikasi dalam file terpisah akan membuat segalanya lebih sederhana. Dan mungkin juga mendukung aplikasi modular dengan baik.

Elektra dirancang untuk spesifikasi eksternal dan ini juga merupakan cara normal di Elektra. Dalam diskusi tentang -c satu hasil bagi saya adalah bahwa pengembang ingin mengeksekusi LCDproc tanpa menginstalnya, yang tidak mungkin jika spesifikasinya eksternal. Jadi @kodebach menemukan cara agar spesifikasi dapat internal, dan masih dapat digunakan secara eksternal (specload). Tentu saja kita tidak perlu menggunakan ini secara default atau sama sekali, itu hanya satu kemungkinan lebih lanjut yang disediakan Elektra. (Terima kasih kepada @kodebach)

Harus mudah untuk mencegah kecelakaan dengan menghasilkan nama file yang unik. Anda bahkan dapat menggunakan checksum untuk melindungi dari tempering, tetapi saya tidak merekomendasikannya.

Kami juga mendukung tanda tangan file konfigurasi. Tetapi spesifikasi bawaan adalah cara paling mudah dan aman untuk tidak pernah memiliki spesifikasi yang tidak sinkron. Tentu saja itu meningkatkan ukuran biner (lebih dari yang kami kira).

Saya harus memeriksa berapa banyak ukuran yang dibutuhkan parser konfigurasi lama

Saya juga tertarik. Sayangnya, parser YAML cukup besar dan membutuhkan perpustakaan eksternal (yamlcpp). Ini juga merupakan keputusan lebih lanjut untuk Anda buat (format file konfigurasi mana yang Anda inginkan secara default).

Pada akhirnya, itu akan menyenangkan untuk dimiliki. Tapi saya sarankan pertama-tama kita fokus bagaimana seharusnya pada sistem produksi dan ABI umum untuk akses spesifikasi. Fitur pengembangan dan spesifikasi lcdproc harus datang kemudian.

Ya, Anda memiliki perasaan yang lebih baik tentang apa yang diinginkan orang-orang LCDproc.

Ya, idealnya kita akan memilih dengan configure jika ini adalah build untuk debugging, produksi, target yang disematkan, dll. configure akan mengatur semuanya agar pembuat kode melakukan hal yang benar. Saya tidak memiliki pendapat yang kuat tentang detailnya. Saya pikir kita setuju pada ide umum?

Oke, haruskah opsinya disebut --works-as-standalone atau --minimize-binary-size? Atau ditanya secara berbeda: apakah Anda memiliki rencana untuk menggunakan kembali opsi ini juga untuk beberapa pengoptimalan lainnya?

Anda juga bisa menyematkan nama file fallback alih-alih seluruh spesifikasi di dalam biner.

Ini tidak membantu jika tidak diinstal. Dan jika spesifikasinya diinstal, itu tetap berfungsi.

Apakah saya mengerti ini dengan benar, bahwa, jika kita tidak memiliki spesifikasi yang tersedia, aplikasi akan (atau setidaknya bisa) tetap berjalan, tetapi akan macet (melalui panggilan balik kesalahan fatal) ketika kita mengakses nilai yang hilang dalam konfigurasi ?

Tepat. Itu tidak akan memiliki default, tidak ada validasi, tidak ada deskripsi konfigurasi, ....

Itu dapat dengan mudah didukung oleh varian dari elektraGet API: Sesuatu seperti elektraGetLongDefault("key", default_value)

Kita harus mempertimbangkan di sini:

1. API sudah memiliki banyak varian, ini lagi-lagi akan menduplikasi 1/3 dari API
2. API ini tidak disarankan untuk digunakan dalam kasus pembuatan non-kode karena default yang didokumentasikan dapat berbeda dari default yang digunakan atau bahkan lebih buruk: opsi konfigurasi yang sama dapat memiliki default yang berbeda di jalur kode yang berbeda.

@kodebach menulis:

Mungkin ada alasan lain juga mengapa API ini tidak digunakan, tetapi sudah diputuskan sebelum waktu saya.

Lihat di atas.

Jika saya memahami semua masalah dengan benar, semuanya harus kurang lebih tercakup oleh tiga mode ini:

@haraldg bisa tolong prioritaskan ketiga mode ini?

Bagaimana itu dipasang terserah pengguna

Saya berasumsi untuk LCDproc kita harus menyiapkan beberapa skrip instalasi?

Seperti 2, tetapi loadConfiguration tidak memeriksa spesifikasi.

Bagaimana dengan beberapa opsi run-time untuk memberi tahu aplikasi bahwa itu tidak boleh gagal karena kesalahan dalam spesifikasi (seperti tanpa spesifikasi)? Maka kita hanya akan memiliki dua mode kompilasi (baik spesifikasi disertakan atau tidak).

@kodebach Apakah Anda sudah mencoba mengompres spesifikasi?

Dalam diskusi tentang -c satu hasil bagi saya adalah pengembang ingin mengeksekusi LCDproc tanpa menginstalnya, yang tidak mungkin jika spesifikasinya eksternal. Jadi @kodebach menemukan cara agar spesifikasi dapat internal, dan masih dapat digunakan secara eksternal (specload).

Tujuan dari specload adalah untuk menautkan versi yang dapat dieksekusi ke spesifikasi. Pemasangan masih diperlukan. Itu tidak mempengaruhi apakah aplikasi dapat dijalankan segera setelah kompilasi atau tidak.

Namun yang dapat Anda lakukan adalah mengkompilasi aplikasi dan memasang executable lokal ini melalui specload (°). Kemudian Anda dapat menjalankan executable lokal. Sekarang Anda cukup mengkompilasi ulang dan menjalankannya lagi (tanpa prosedur pemasangan lain) dan akan tetap memiliki spesifikasi yang benar (bahkan jika Anda mengubahnya sebelum mengompilasi).

(°) Jika Anda memiliki versi terinstal dari executable Anda, Anda perlu meng-unmount spec-nya dan kemudian me-mount dengan specload. Atau Anda dapat secara manual mengubah konfigurasi plugin specload untuk mountpoint Anda untuk menggunakan jalur eksekusi yang berbeda. Sayangnya tidak ada alat kdb untuk mengubah konfigurasi plugin yang terpasang.

Tepat. Itu tidak akan memiliki default, tidak ada validasi, tidak ada deskripsi konfigurasi, ....

Tolong jangan memposting informasi yang bertentangan. Seperti yang saya nyatakan di atas, default dapat diberikan secara terpisah dari spec.

@haraldg bisa tolong prioritaskan ketiga mode ini?

Masing-masing dari 3 mode melayani tujuan yang sama sekali berbeda dan penerapan mode ini tidak terlalu rumit sehingga prioritas tidak terlalu diperlukan. Akan lebih baik untuk mengetahui apakah mode ini mencakup semuanya atau jika kita mungkin memerlukan mode tambahan.

@kodebach Apakah Anda sudah mencoba mengompres spesifikasi?

Pertama-tama: Saat ini kami menggunakan KeySets terpisah untuk default dan spesifikasi. Saya pasti akan membuat perubahan yang diperlukan, sehingga kita dapat menggunakan yang sama untuk keduanya. Ini seharusnya sudah cukup mengurangi ukuran biner. Di luar itu ada beberapa kemungkinan.

Jika kita ingin membangun spesifikasi yang disematkan menggunakan C API (ksNew, keyNew), sepertinya tidak banyak yang bisa kita lakukan dengan mudah. Sejauh yang saya tunjukkan beberapa eksperimen singkat, menggunakan API yang berbeda (tanpa varargs, banyak panggilan fungsi; keyNew API yang berbeda, dll.) tidak akan banyak membantu. (Mengabaikan betapa rumitnya implementasinya) keyCopyMeta mungkin juga tidak akan membantu, karena string yang sama harus dideduplikasi oleh kompiler. (setidaknya untuk ukuran biner, tentu saja akan mengurangi penggunaan RAM).

Pilihan lain adalah menyematkan string tunggal (atau array byte) yang mengkodekan seluruh KeySet dan menggunakan plugin untuk menggunakannya. Karena kita harus mengirim KeySet dalam format quickdump untuk specload, format quickdump akan menawarkan dirinya untuk embedding. Namun, sekarang quickdump tampaknya sedikit lebih besar dari kode C (setidaknya dalam kasus lcdexec ). Lihat #2788 untuk lebih lanjut.

Untuk spesifikasi non-embedded Anda cukup mengambil file quickdump kompres dengan gzip dan mount file yang dihasilkan /path/x.eqd.gz dengan:

sudo kdb mount -R noresolver spec.eqd "spec/mountpoint" specload "app=/usr/bin/zcat" "app/args=#0" "app/args/#0=/path/x.eqd.gz" 

Anda juga dapat menggunakan metode lain untuk mengompresi data quickdump selama ada file yang dapat dieksekusi yang dapat mencetak file yang tidak terkompresi ke stdout.

Tolong jangan memposting informasi yang bertentangan.

Saya tidak dapat menemukan dokumentasi tentang ini, dapatkah Anda mengarahkan saya ke sana? Saya hanya tahu satu argumen di elektraOpen yang menerima spesifikasi dan saya berasumsi API yang dihasilkan kode akan melewati spesifikasi menggunakan parameter ini dan bahwa aplikasi yang dipanggil dengan --elektra-spec akan mengembalikan persis seperti ini.

Seperti yang saya nyatakan di atas, default dapat diberikan secara terpisah dari spec.

Mengapa Anda melakukan ini?

Saya pasti akan membuat perubahan yang diperlukan, sehingga kita dapat menggunakan yang sama untuk keduanya.

Terima kasih.

Pertama-tama saya harus menunjukkan, bahwa saya tidak cukup akrab dengan jargon Elektra, untuk sepenuhnya memahami semua komentar Anda. Mungkin ada kesalahpahaman dalam apa yang saya tulis. Saya akan mencoba untuk menyadari batas pemahaman saya, tetapi mungkin melewatkan sesuatu.

Ketika Anda mengatakan "memasang spesifikasi": Apakah saya benar bahwa ini pada dasarnya berarti memiliki entri dalam file seperti /etc/elektra.conf menunjuk ke file tempat spesifikasi disimpan kecuali untuk kasus di mana spesifikasi disematkan dalam aplikasi dan Anda melakukan beberapa hal di loadConfiguration(), yang memiliki efek yang sama tanpa benar-benar menyentuh file persisten?

Jika saya memahami semua masalah dengan benar, semuanya harus lebih atau kurang tercakup oleh tiga mode ini: [1, 2, 3]

Pada dasarnya ya. Saya masih berpikir mode 2.5 (API default murah) layak untuk dijelajahi, tetapi lihat di bawah. Juga demi kelengkapan, mungkin ada

1. Gunakan beberapa konfigurasi sampel (tidak harus default) dan gunakan nilai secara langsung di elektragen.c tanpa menautkan ke libelektra sama sekali. Mode ini jelas tidak berguna untuk lcdproc sama sekali (apa dengan semua plugin, dll.) tetapi secara teori mungkin berguna untuk aplikasi lain dalam konteks tertanam yang dalam. Ini jelas merupakan prioritas yang sangat rendah, tetapi karena Anda sudah memiliki pembuat kode yang bagus, Anda mungkin benar-benar ingin memamerkannya sedikit. Juga akan memberikan tolok ukur yang sangat bagus untuk dibandingkan. Mungkin data ini tidak menarik untuk tesis kodebach, tetapi saya dapat melihat ini sebagai hal yang sangat bagus untuk menulis beberapa makalah. (Dan jika mode ini tersedia, saya pasti akan menggunakannya sedikit untuk benchmark lcdproc.)

2. Berikan spesifikasi (dengan cara apa pun) tetapi hapus semua string yang hanya ditujukan untuk manusia tetapi tidak relevan secara terprogram. (Mungkin ini bukan tugas untuk pembuat kode tetapi beberapa alat lain. Saya tidak tahu - hanya menjelajahi ruang ide.)

Namun, saya juga harus menunjukkan, bahwa saya tidak mengerti perbedaan antara (1) dan (2): Ini akan berperilaku dengan cara yang sama, hanya dengan spesifikasi yang disimpan berbeda?

Elektra dirancang untuk spesifikasi eksternal dan ini juga merupakan cara normal di Elektra. Dalam diskusi tentang -c satu hasil bagi saya adalah pengembang ingin mengeksekusi LCDproc tanpa menginstalnya, yang tidak mungkin jika spesifikasinya eksternal.

Saya tidak melihat ini. Anda dapat pada waktu kompilasi (waktu pembuatan kode) menyimpan spesifikasi saat ini dalam file dengan nama unik dan menyematkan nama (tentu saja jalur absolut) dalam file yang dapat dieksekusi. Jika spesifikasi tidak dipasang, executable akan kembali ke lokasi yang disimpan. Tidak?

Jadi @kodebach menemukan cara agar spesifikasi dapat internal, dan masih dapat digunakan secara eksternal (specload). Tentu saja kita tidak perlu menggunakan ini secara default atau sama sekali, itu hanya satu kemungkinan lebih lanjut yang disediakan Elektra. (Terima kasih kepada @kodebach)

Kami benar-benar harus berdiskusi lebih awal, jika ini hasilnya. Tetapi jika ini hanya fitur pengembangan, saya sebenarnya tidak terlalu peduli dengan ukuran. Saya mendapat kesan, bahwa bangunan produksi akan memiliki ukuran yang sama.

Jika ini hanya fitur pengembangan, maka saya tidak mengerti mengapa Anda repot-repot membuang spesifikasi untuk pengguna eksternal?

Ini juga merupakan keputusan lebih lanjut untuk Anda buat (format file konfigurasi mana yang Anda inginkan secara default).

Saya tidak punya pendapat yang kuat. Kecuali ada yang salah dengan ini, saya akan tetap menggunakannya.

Oke, haruskah opsinya disebut --works-as-standalone atau --minimize-binary-size? Atau ditanya secara berbeda: apakah Anda memiliki rencana untuk menggunakan kembali opsi ini juga untuk beberapa pengoptimalan lainnya?

Saya tidak percaya saya memiliki gambaran lengkapnya, jadi tidak bisa mengatakannya. Saya juga percaya seseorang mungkin menambahkan lebih banyak mode ke pembuat kode di masa mendatang. Jadi mungkin --mode={full-spec,no-spec,...} atau mungkin --spec={include,check,ignore} atau semacamnya?

API sudah memiliki banyak varian, ini lagi-lagi akan menduplikasi 1/3 dari API

Saya berasumsi ini akan murah untuk diterapkan dalam hal fungsi yang sudah ada untuk mendukung API yang ada. Jika ini tidak benar, maka idenya kurang menarik.

API ini tidak disarankan untuk digunakan dalam kasus pembuatan non-kode

Tepat. Mungkin kecuali untuk kasus di mana orang menggunakan API, tetapi memutuskan untuk tidak menggunakan spesifikasi sama sekali.

atau bahkan lebih buruk: opsi konfigurasi yang sama dapat memiliki default yang berbeda di jalur kode yang berbeda.

Seseorang yang melakukan pekerjaan ceroboh seperti itu mungkin juga mengakses kunci yang salah sejak awal. ;)

Saya berasumsi untuk LCDproc kita harus menyiapkan beberapa skrip instalasi?

make install kemungkinan besar akan menghasilkan sistem yang tetap bekerja meskipun direktori, tempat lcdproc dikompilasi, telah dihapus seluruhnya.

Bagaimana dengan beberapa opsi run-time untuk memberi tahu aplikasi bahwa itu tidak boleh gagal karena kesalahan dalam spesifikasi (seperti tanpa spesifikasi)? Maka kita hanya akan memiliki dua mode kompilasi (baik spesifikasi disertakan atau tidak).

Saya pikir saya tidak benar-benar mengerti di mana Anda mendapatkan ini. Saya tidak melihat kasus penggunaan untuk mengabaikan kesalahan yang sebenarnya berhasil kami deteksi?

(°) Jika Anda memiliki versi terinstal dari executable Anda, Anda perlu meng-unmount spec-nya dan kemudian me-mount dengan specload. Atau Anda dapat secara manual mengubah konfigurasi plugin specload untuk mountpoint Anda untuk menggunakan jalur eksekusi yang berbeda.

Saya telah menghabiskan berjam-jam membaca berbagai hal dan berdiskusi dengan Anda berdua dan saya masih tidak begitu mengerti apa artinya ini. Bahkan Markus terkadang bingung. Saya mendukung apa yang saya katakan sebelumnya: Konsep ini tampaknya sangat berputar-putar bagi saya. Bagaimana Anda bisa berharap untuk mendokumentasikan ini sedemikian rupa sehingga rata-rata pengguna akan memahaminya?

Saat Anda mengatakan "memasang spesifikasi":

Pemasangan di Elektra selalu konsep yang sama karena spesifikasi juga disimpan seperti konfigurasi. Mounting adalah mekanisme untuk menggambarkan bagaimana Elektra dapat menemukan konfigurasi di bawah beberapa nama kunci.

Apakah saya benar bahwa ini pada dasarnya berarti memiliki entri dalam file seperti titik /etc/elektra.conf

Ya, file yang berisi mountpoints disebut /etc/kdb/elektra.ecf secara default. kdb file system/elektra memberi Anda nama file yang sebenarnya.

ke file tempat spesifikasi disimpan kecuali untuk kasus di mana spesifikasi disematkan dalam aplikasi dan Anda melakukan beberapa hal di loadConfiguration(), yang memiliki efek yang sama tanpa benar-benar menyentuh file persisten?

Biasanya pemasangan mengacu pada file pada sistem file tetapi tidak perlu seperti ini. Anda juga dapat memasang "file" dari git, jaringan, dan keluaran yang dapat dieksekusi.

Ini jelas merupakan prioritas yang sangat rendah, tetapi karena Anda sudah memiliki pembuat kode yang bagus, Anda mungkin benar-benar ingin memamerkannya sedikit.

Saya lebih suka hanya memiliki fungsionalitas yang diperlukan tetapi fungsionalitas yang dibutuhkan bekerja dengan sangat baik. Elektra sudah memiliki lebih dari cukup fitur untuk "pamer", yang cenderung membuat orang takut karena tidak semuanya berjalan seperti yang diharapkan.

Secara khusus, Elektra sudah memiliki fitur untuk membuat nilai konfigurasi hanya-baca. Memiliki banyak cara untuk melakukan hal yang sama membutuhkan pembenaran yang sangat baik. Peningkatan kinerja bisa menjadi pembenaran tetapi saat ini kami belum tahu apa-apa tentang run-time di LCDproc.

Berikan spesifikasi (dengan cara apa pun) tetapi hapus semua string yang hanya ditujukan untuk manusia tetapi tidak relevan secara terprogram.

Anda juga harus mempertimbangkan, bahwa meledakkan sistem build dengan terlalu banyak opsi menimbulkan kerumitan. Tapi ya, opsi untuk hanya menyertakan apa yang diperlukan untuk jaminan (tipe+default) masuk akal.

Anda dapat pada waktu kompilasi (waktu pembuatan kode) menyimpan spesifikasi saat ini dalam file dengan nama unik dan menyematkan nama (tentu saja jalur absolut) dalam file yang dapat dieksekusi. Jika spesifikasi tidak dipasang, executable akan kembali ke lokasi yang disimpan. Tidak?

Tentu saja Anda dapat melakukan ini tetapi selama LCDproc tidak diinstal, file spesifikasi tidak akan berada di jalur absolut ini dan LCDproc akan gagal menemukan file tersebut. Selain itu, memiliki nama file absolut di dalam yang dapat dieksekusi memiliki kelemahan lain (biner tidak akan dapat dipindahkan lagi).

Jika ini hanya fitur pengembangan, maka saya tidak mengerti mengapa Anda repot-repot membuang spesifikasi untuk pengguna eksternal?

Memiliki spesifikasi aplikasi yang tersedia dalam Elektra adalah salah satu tujuan utama Elektra: Hanya dengan demikian Anda dapat menanyakan nilai mana yang akan diperoleh aplikasi, menyediakan alat yang bagus, dan seterusnya dan seterusnya.

Saya tidak punya pendapat yang kuat. Kecuali ada yang salah dengan ini, saya akan tetap menggunakannya.

Pengurai INI yang disebut "ini" adalah yang memiliki sebagian besar fitur tetapi juga dengan sebagian besar bug.

Tepat. Mungkin kecuali untuk kasus di mana orang menggunakan API, tetapi memutuskan untuk tidak menggunakan spesifikasi sama sekali.

Dalam beberapa diskusi awal, kami juga mengatakan bahwa API harus mendorong orang dengan lembut ke cara yang lebih modern dan kuat tentang cara mengakses konfigurasi. Memiliki spek adalah hal yang harus dimiliki karena berbagai alasan. Hanya dalam sistem yang sangat terbatas seseorang harus mempertimbangkan untuk tidak memiliki spesifikasi sama sekali: dalam kasus di mana Anda tidak menginginkan konfigurasi run-time sama sekali.

Saya pikir saya tidak benar-benar mengerti di mana Anda mendapatkan ini. Saya tidak melihat kasus penggunaan untuk mengabaikan kesalahan yang sebenarnya berhasil kami deteksi?

Ini akan menjadi fitur pengembang untuk memungkinkan pengembang memulai LCDproc tanpa spesifikasi. Idenya di sini adalah kami mengurangi jumlah varian kompilasi menjadi dua: spesifikasi yang dikompilasi dan spesifikasi eksternal.

Bagaimana Anda bisa berharap untuk mendokumentasikan ini sedemikian rupa sehingga rata-rata pengguna akan memahaminya?

API tingkat tinggi sudah memiliki dokumentasi yang bagus: https://www.libelektra.org/tutorials/high-level-api

Tetapi seperti yang Anda perhatikan, fitur terbaru dari pembuatan kode saat ini tidak memiliki dokumentasi seperti itu dan terkadang juga bekerja secara berbeda dari yang saya harapkan. Jadi saya mendesak untuk sejumlah kecil kasus penggunaan dan mengimplementasikan dan mendokumentasikan dengan tepat 2 atau 3 kasus ini.

Apakah ini ringkasan yang benar dari deskripsi pemasangan Anda konfigurasi itu?
sumber (file, apa pun) dapat dipasang baik secara global dari elektra.ecf
atau proses-lokal dari dalam loadConfiguration()?

Tentu saja Anda dapat melakukan ini tetapi selama LCDproc tidak diinstal, file spesifikasi tidak akan berada di jalur absolut ini dan LCDproc akan gagal menemukan file tersebut.

Saya sebenarnya menyarankan untuk menyimpan jalur lokasi yang tidak diinstal. yaitu
jalur di direktori build.

Selain itu, memiliki nama file absolut di dalam yang dapat dieksekusi memiliki kelemahan lain (biner tidak akan dapat dipindahkan lagi).

Ya, ini hanya akan menjadi fitur pengembangan, untuk dapat menjalankan yang tidak diinstal
versi aplikasi. Pembuatan produksi mungkin tidak boleh menyertakan
jalan ini sama sekali atau setidaknya dengan senang hati mengabaikannya.

Jika ini hanya fitur pengembangan, maka saya tidak mengerti mengapa Anda repot-repot membuang spesifikasi untuk pengguna eksternal?

Memiliki spesifikasi aplikasi yang tersedia dalam Elektra adalah salah satu tujuan utama Elektra: Hanya dengan demikian Anda dapat menanyakan nilai mana yang akan diperoleh aplikasi, menyediakan alat yang bagus, dan seterusnya dan seterusnya.

Saya gagal melihat bagaimana mereferensikan executable yang tidak diinstal yang benar dalam apa pun
alat yang Anda pikirkan lebih mudah daripada referensi yang benar
spesifikasi tidak terpasang.

Saya tidak punya pendapat yang kuat. Kecuali ada yang salah dengan ini, saya akan tetap menggunakannya.

Pengurai INI yang disebut "ini" adalah yang memiliki sebagian besar fitur tetapi juga dengan sebagian besar bug.

Saya tidak tahu parser INI mana yang tersedia. Satu-satunya pernyataan saya adalah tentang
bertahan dengan INI tampaknya masuk akal. Tapi saya curiga kebanyakan orang tidak akan peduli
banyak tentang format yang dapat dibaca manusia yang digunakan.

Saya pikir saya tidak benar-benar mengerti di mana Anda mendapatkan ini. Saya tidak melihat kasus penggunaan untuk mengabaikan kesalahan yang sebenarnya berhasil kami deteksi?

Ini akan menjadi fitur pengembang untuk memungkinkan pengembang memulai LCDproc tanpa spesifikasi. Idenya di sini adalah kami mengurangi jumlah varian kompilasi menjadi dua: spesifikasi yang dikompilasi dan spesifikasi eksternal.

Jadi pada dasarnya ini berarti kita harus selalu menjalankan aplikasi yang dialiri listrik
di openwrt dengan beberapa sakelar baris perintah, yang tidak digunakan siapa pun di non-embedded
sistem? Orang-orang akan lebih sering melupakan ini dalam skrip mereka daripada mereka
membuat kesalahan dalam konfigurasi mereka. Sepertinya tradeoff yang buruk.

Apakah ini ringkasan yang benar dari deskripsi pemasangan Anda konfigurasi itu?
sumber (file, apa pun) dapat dipasang baik secara global dari elektra.ecf
atau proses-lokal dari dalam loadConfiguration()?

Ada beberapa fungsionalitas pemasangan di API (kdbEnsure) tetapi tidak digunakan untuk memasang file konfigurasi tetapi hanya konfigurasi proses-lokal seperti argumen baris perintah. Alasan untuk tidak menggunakannya, bahwa pemasangan non-global apa pun akan merusak tampilan alat yang benar.

Saya sebenarnya menyarankan untuk menyimpan jalur lokasi yang tidak diinstal. yaitu
jalur di direktori build.

Ini kemudian hanya akan menarik bagi pengembang di mana kami dapat menambahkan seluruh spesifikasi.

Saya gagal melihat bagaimana mereferensikan executable yang tidak diinstal yang benar dalam alat apa pun yang Anda pikirkan lebih mudah daripada merujuk spesifikasi yang tidak diinstal yang benar.

Saya berbicara tentang alat Elektra (kdb, qt-gui, web-ui, ...). Tentu saja pengembang juga dapat memasang file direktori build mereka. Sayangnya, Anda harus menjadi root untuk pemasangan karena pemasangan menulis ke /etc/kdb/elektra.ecf. Lihat #1074 untuk proposal untuk mengubah ini.

Jadi pada dasarnya ini berarti kita harus selalu menjalankan aplikasi yang dialiri listrik
di openwrt dengan beberapa sakelar baris perintah, yang tidak digunakan siapa pun di non-embedded
sistem? Orang-orang akan lebih sering melupakan ini dalam skrip mereka daripada mereka
membuat kesalahan dalam konfigurasi mereka. Sepertinya tradeoff yang buruk.

Tidak, sebaliknya: pengembang perlu menambahkan sakelar ketika mereka mendapatkan kesalahan bahwa spesifikasi tidak ada.

Tapi mari kita fokus pada kasus penggunaan yang perlu kita dukung, dan kemudian memutuskan bagaimana mengimplementasikannya.

Ok ada banyak untuk membongkar di sini.

Saat Anda mengatakan "memasang spesifikasi"

Pemasangan di Elektra sangat mirip dengan pemasangan sistem file di UNIX. Elektra memiliki konfigurasi titik mount yang luas. Titik mount ini hanyalah kunci yang menentukan bahwa semua yang ada di bawah kunci ini (dan bukan di bawah titik mount lain) dimuat menggunakan plugin penyimpanan untuk titik mount ini.

Jadi misalnya Anda dapat memasang kunci user/test/my/key dengan plugin ini . Ini hanya berarti bahwa jika seseorang mengakses kunci di bawah user/test/my/key (misalnya user/test/my/key/hello ), kami memanggil plugin ini , yang kemudian memuat beberapa file (file mana yang dimuat sedikit lebih banyak rumit tetapi tidak terlalu relevan di sini).

UNIX memiliki sistem file sintetis seperti /proc atau /sys . Demikian pula Elektra sebenarnya tidak mengharuskan plugin dimuat dari file. Ada plugin untuk memuat dari git atau melalui curl atau dengan menjalankan beberapa proses (seperti yang dilakukan specload).

Jadi, jika Anda "memasang spesifikasi", Anda akan memodifikasi konfigurasi titik pemasangan di seluruh sistem untuk memberi tahu Elektra cara mengambil spesifikasi Anda. Ini tidak dapat dilakukan di dalam loadConfiguration() , karena alat seperti kdb tidak akan berfungsi, karena hanya aplikasi Anda yang tahu tentang spesifikasinya.
(Dimungkinkan untuk memasang secara otomatis pada startup pertama, tetapi karena pemasangan memerlukan akses root, saya tidak akan merekomendasikannya.)

Gunakan beberapa konfigurasi sampel (tidak harus default) dan gunakan nilai secara langsung di elektragen.c tanpa menautkan ke libelektra sama sekali.

Saya juga memikirkan ini sebagai kemungkinan di masa depan. Ini bisa berguna untuk sistem tertanam tanpa pengawasan yang Anda sebutkan sebelumnya. Pada dasarnya orang bisa bermain-main dengan spesifikasi dan konfigurasi yang berbeda. Setelah konfigurasi akhir ditemukan, elektragen.c dummy yang selalu mengembalikan nilai yang sama (dan karena itu harus sepenuhnya digarisbawahi oleh kompiler), dapat dibuat dan digunakan untuk membuat citra firmware.

Berikan spesifikasi (dengan cara apa pun) tetapi hapus semua string yang hanya ditujukan untuk manusia tetapi tidak relevan secara terprogram.

Ya, saya akan mengatakan itu harus dilakukan melalui alat yang berbeda. Alat akan melakukan pra-proses spesifikasi sebelum diteruskan ke generator.

Saya tidak mengerti perbedaan antara (1) dan (2): Ini akan berperilaku dengan cara yang sama, hanya dengan spesifikasi yang disimpan secara berbeda?

Ya, biner akan lebih kecil. Spesifikasi eksternal juga dapat dikompres dengan cara lain, kemudian dengan mudah dimungkinkan di dalam biner. Selain itu, Anda dapat menyimpan biner dan spesifikasi di tempat yang berbeda. Misalnya biner dapat dikompilasi menjadi gambar firmware, sedangkan spesifikasi disimpan pada beberapa chip flash lain yang lebih besar yang tidak dimaksudkan untuk kode yang dapat dieksekusi. Tidak tahu, jika perangkat seperti itu ada. Pada dasarnya (2) sedikit lebih fleksibel. Sementara (1) menjamin bahwa biner dan spek selalu kompatibel.

Saya berasumsi ini akan murah untuk diterapkan dalam hal fungsi yang sudah ada untuk mendukung API yang ada. Jika ini tidak benar, maka idenya kurang menarik.

Tentu saja itu hanya sedikit copy/paste. Tapi begitu ada pilihan yang berbeda untuk melakukan sesuatu, Anda harus sangat eksplisit tentang trade-off antara pilihan yang berbeda, jika tidak orang akan menjadi bingung dan mungkin terhalang untuk menggunakan Elektra. Salah satu tujuan API tingkat tinggi adalah untuk memudahkan pemula menggunakan Elektra, karena API tingkat rendah cukup kompleks dan terkadang tidak intuitif.

Tepat. Mungkin kecuali untuk kasus di mana orang menggunakan API, tetapi memutuskan untuk tidak menggunakan spesifikasi sama sekali.

Seperti yang saya katakan di atas, sudah dimungkinkan untuk menggunakan API tingkat tinggi tanpa spesifikasi lengkap. Parameter defaults dari elektraOpen akan berisi type s dan default yang diharapkan untuk semua nama kunci yang diketahui. Ini adalah jenis spesifikasi yang ringan. Idenya adalah bahwa tidak ada yang bisa menyisipkan baris elektraGetLong ("/some/key") tanpa ada yang mengetahui bahwa opsi konfigurasi ini ada. (Saya menemukan beberapa driver di LCDproc di mana tidak semua kunci konfigurasi yang digunakan dalam kode didokumentasikan).

Saya gagal melihat bagaimana mereferensikan executable yang tidak diinstal yang benar dalam apa pun
alat yang Anda pikirkan lebih mudah daripada referensi yang benar
spesifikasi tidak terpasang.

Ini benar-benar tidak. Sekali lagi (saat ini) satu-satunya manfaat nyata menggunakan specload adalah biner dan spesifikasi selalu kompatibel (karena keduanya adalah file yang sama). Terlepas dari ini, ide utama di balik specload (walaupun ini belum diterapkan, karena memerlukan perubahan yang lebih luas), adalah dapat memungkinkan pengguna untuk memodifikasi spesifikasi dengan cara yang aman, sambil mencegah perubahan yang tidak aman. Misalnya, selalu aman untuk mengubah metadata description , karena tidak dimaksudkan untuk pemrosesan mesin. Demikian pula, akan aman untuk membatasi nilai yang diizinkan untuk port yang digunakan LCDd .

@haraldg Anda mungkin dapat mengabaikan hal-hal di bawah ini, itu akan berisi banyak terminologi Elektra dan pada dasarnya berbicara tentang detail implementasi

Tolong jangan memposting informasi yang bertentangan.

Saya tidak dapat menemukan dokumentasi tentang ini, dapatkah Anda mengarahkan saya ke sana? Saya hanya tahu satu argumen di elektraOpen yang menerima spesifikasi dan saya berasumsi API yang dihasilkan kode akan melewati spesifikasi menggunakan parameter ini dan bahwa aplikasi yang dipanggil dengan --elektra-spec akan mengembalikan persis seperti ini.

Seperti yang saya nyatakan di atas, default dapat diberikan secara terpisah dari spec.

Mengapa Anda melakukan ini?

Tidak ada dokumentasi nyata, tetapi melihat file yang dibuat oleh pembuat kode mungkin bisa membantu.

Seperti yang Anda katakan ada defaults KeySet yang diteruskan ke elektraOpen dan ada KeySet yang dicetak ke stdout dalam mode specload ( --elektra-spec ). Keduanya berada di lokasi yang berbeda dalam kode dan sekarang, keduanya dibuat oleh pernyataan ksNew yang terpisah. Ini karena elektraOpen membutuhkan kunci tanpa kunci induk (mis /lcdexec/address ) sedangkan mode specload membutuhkan kunci ruang nama spec penuh (mis spec/sw/lcdproc/lcdexec/#0/current/lcdexec/address ). Saya sedang mengerjakan perbaikan untuk ini, sehingga kami dapat menggunakan KeySet yang sama untuk keduanya.

Masih benar, bahwa defaults KeySet diteruskan ke elektraOpen dan spesifikasi (dipasang melalui specload atau lainnya) secara teknis independen dan bahkan dapat bertentangan (°). Kode-generator (dan sampai batas tertentu specload) ada untuk mencegah hal ini. Anda benar, kode yang dihasilkan kurang lebih meneruskan salinan spesifikasi ke elektraOpen . Dan seperti yang saya katakan di masa depan itu akan menjadi KeySet yang sama persis seperti yang digunakan oleh mode specload.

Namun, defaults KeySet tidak harus berisi spesifikasi lengkap. Pertama-tama, jika Anda yakin ada spesifikasi yang terpasang, Anda tidak perlu melewatkan defaults sama sekali. Jika Anda lulus defaults , satu-satunya persyaratan (belum diperiksa di elektraOpen ) adalah bahwa setiap kunci memiliki type dan default . Salinan defaults (dengan kunci induk ditambahkan ke setiap kunci) digunakan sebagai KeySet yang diteruskan ke kdbGet . Ini berfungsi, karena Kunci yang kita buat di elektraOpen sama dengan yang akan dibuat oleh plugin spec dan oleh karena itu digunakan sebagai cadangan dalam pencarian berjenjang.

Dan akhirnya, hanya untuk memperjelas ini sekali dan untuk semua, specload sama sekali tidak membantu menjalankan executable yang tidak diinstal. Anda masih harus memasang spesifikasi agar specload berfungsi. Anda hanya memasang dengan cara yang berbeda. defaults KeySet sampai batas tertentu memungkinkan untuk menjalankan binari tanpa pemasangan, tetapi ini bukan pengganti penuh untuk spesifikasi yang dipasang. Alasannya sederhana, Kunci dalam defaults hanya diproses oleh plugin global (mungkin tidak termasuk plugin postgetstorage , saya perlu memeriksanya). Ini karena kuncinya bukan milik mountpoint mana pun. Untuk mengurangi ini salah satu dari dua hal yang harus terjadi: 1) kita perlu memperhitungkan kunci cascading di splitAppoint atau 2) kdbEnsure harus mendukung pembuatan mountpoints. Opsi 1) masih memerlukan titik mount di mana kunci berjenjang dapat diletakkan dan yang memiliki plugin yang diperlukan, jadi bukan solusi yang sebenarnya. Dengan Opsi 2) kita bisa menjalankan kdbEnsure untuk membuat mountpoint spesifikasi di elektraOpen dan menghapusnya lagi di elektraClose .

PS. Saya tidak tahu, bagaimana cache baru memainkan ini. Mungkin saja berhasil atau mungkin merusak segalanya. (Saya menduga yang terakhir.) Membuat dan menghapus mountpoints di kdbEnsure mungkin akan menyebabkan masalah dengan kasing, karena kdbEnsure hanya memodifikasi pegangan KDB , bukan konfigurasi aktual pada disk . Saya kira itu hanya akan menyebabkan cachemiss pertama kali. Namun, saya tidak tahu apakah kami kemudian akan membuat cache dari pseudo-mountpoint ini dan apa artinya saat aplikasi dijalankan berikutnya.

(°) AFAIK plugin spec menimpa apa yang diteruskan sebagai defaults sehingga tidak akan ada konflik apa pun. Tetapi mengubah defaults tanpa mengubah spesifikasi, mungkin tidak akan berpengaruh.

Terima kasih atas jawaban terperinci!

Tidak tahu, jika perangkat seperti itu ada. Pada dasarnya (2) sedikit lebih fleksibel. Sementara (1) menjamin bahwa biner dan spek selalu kompatibel.

Lebih baik hanya mendukung (1)?

Tidak ada dokumentasi nyata, tetapi melihat file yang dibuat oleh pembuat kode mungkin bisa membantu.

Ini tentu menjadi hal yang penting untuk diubah. Apakah Anda menganggap bahwa kode yang dihasilkan API terlihat identik dengan non-kode yang dihasilkan API? Ini akan menghilangkan duplikasi banyak dokumentasi. Idealnya, kami hanya akan menjelaskan satu cara untuk menggunakan API tingkat tinggi dan tanpa pembuatan kode, Anda cukup menyertakan file elektra.h yang berbeda (tidak dibuat).

Dan seperti yang saya katakan di masa depan itu akan menjadi KeySet yang sama persis seperti yang digunakan oleh mode specload.

Sempurna.

KeySet default sampai batas tertentu memungkinkan untuk menjalankan binari tanpa pemasangan, tetapi ini bukan pengganti penuh untuk spesifikasi yang dipasang. Alasannya sederhana, Kunci secara default hanya diproses oleh plugin global (mungkin tidak termasuk plugin postgetstorage, saya perlu melihat ke dalamnya).

Bisakah Anda membuat masalah/proposal tentang masalah ini? Bagi saya, perilaku yang diharapkan adalah plugin spesifikasi menyalin metadata sehingga tersedia untuk semua plugin. Idealnya, kunci yang diteruskan ke kdbGet identik dengan kunci yang diambil. (Jelas bukan untuk cache hit atau NO_UPDATE di mana kdbGet pada dasarnya adalah no-op.)

Apakah Anda menganggap bahwa kode yang dihasilkan API terlihat identik dengan non-kode yang dihasilkan API?

Dengan cara apa? Saya tidak melihat bagian yang benar-benar identik. Banyak yang serupa, karena yang satu didasarkan pada yang lain, tetapi tidak ada yang benar-benar identik.

Bisakah Anda membuat masalah/proposal tentang masalah ini?

Setelah saya tahu apa yang saya usulkan, saya bisa melakukan itu ...

Bagi saya, perilaku yang diharapkan adalah plugin spesifikasi menyalin metadata sehingga tersedia untuk semua plugin.

Itulah yang terjadi, tidak ada plugin lain, jika tidak ada mountpoint.

Idealnya, kunci yang diteruskan ke kdbGet identik dengan kunci yang diambil. (Jelas bukan untuk cache hit atau NO_UPDATE di mana kdbGet pada dasarnya adalah no-op.)

Tidak yakin apa yang Anda maksud dengan itu. Dokumentasi untuk kdbGet cukup jelas menyatakan bahwa returned KeySet mungkin berisi Kunci arbitrer dan bahwa kunci yang diambil ditambahkan dengan ksAppendKey dan oleh karena itu akan menggantikan yang sudah ada.

Dengan cara apa? Saya tidak melihat bagian yang benar-benar identik. Banyak yang serupa, karena yang satu didasarkan pada yang lain, tetapi tidak ada yang benar-benar identik.

Terutama dalam hal API, misalnya memiliki elektraOpen dan tidak memuat Konfigurasi. Parameter "default" tidak akan digunakan atau bahkan bisa berupa KeySet lain yang ditambahkan.

Apakah ada perbedaan lain dalam API yang dihasilkan vs. yang tidak dibuat? (Kecuali jaminan tambahan di API yang dihasilkan.)

@kodebach : Terima kasih atas penjelasan detailnya. Ini sangat membantu, juga menimbulkan banyak pertanyaan baru "Mengapa kalian melakukan hal-hal seperti yang kalian lakukan?" pertanyaan. Mereka mungkin tidak berguna saat ini, jadi saya pikir saya hanya punya satu pertanyaan tersisa:

Apakah benar untuk mengatakan, bahwa (1) memastikan bahwa aplikasi memvalidasi konfigurasinya sendiri terhadap spesifikasi yang benar bahkan jika salah atau tidak ada spesifikasi yang dipasang?

Apakah benar untuk mengatakan, bahwa (1) memastikan bahwa aplikasi memvalidasi konfigurasinya sendiri terhadap spesifikasi yang benar bahkan jika salah atau tidak ada spesifikasi yang dipasang?

Tidak ada jaminan 100%, karena kami masih menggunakan apa yang Elektra berikan kepada kami. Jika semuanya diatur dengan benar, spesifikasi yang disediakan Elektra (via kdbGet ) akan datang dari aplikasi itu sendiri (via specload ). Tapi spesifikasinya masih harus dipasang, jadi kami tidak tahu persis dari mana.

Untuk memastikan 100% bahwa dengan mengeksekusi misalnya lcdproc kita akan menggunakan spesifikasi yang disematkan di lcdproc , kita memerlukan beberapa perubahan. Pada dasarnya kita harus memeriksa entah bagaimana apakah executable yang akan dipanggil specload sama dengan yang sedang berjalan. Satu-satunya cara untuk itu (yang dapat saya pikirkan sekarang) melibatkan jalur absolut ke executable saat ini. Sayangnya tidak ada cara portabel untuk mengakses jalur itu, kita harus bergantung pada hal-hal seperti /proc atau panggilan sistem WIN32 dan OSX.

Mengapa Anda tidak membandingkan spesifikasi apa yang dikirimkan dan apa yang ada di dalamnya (dan gagal karena ketidakcocokan)?

Akan sangat baik untuk menulis sekarang ringkasan mode mana yang akan kita dukung.

Mengapa Anda tidak membandingkan spesifikasi apa yang dikirimkan dan apa yang ada di dalamnya (dan gagal karena ketidakcocokan)?

Membandingkan dua KeySet yang berpotensi sangat besar akan cukup mahal, saya ingin menghindarinya jika memungkinkan. Juga karena KeySet yang kami terima dari kdbGet sudah melewati berbagai plugin, itu tidak akan sama persis dengan apa yang kami kirim ke specload . Tapi aku punya beberapa ide lain, aku akan melihat ke dalam.

Akan sangat baik untuk menulis sekarang ringkasan mode mana yang akan kita dukung.

Saya akan menerapkan 3 opsi ke pembuat kode:

• specLocation=( embed | external ) : Ini mengubah bagaimana spesifikasi yang diproses dihasilkan. embed (default) menyematkannya ke dalam biner, external menghasilkan file terpisah.
• defaultsHandling=( embed | speconly ) : Ini mengubah cara default s ditangani. embed (default) meneruskan defaults KeySet ke elektraOpen (KeySet adalah spesifikasi yang disematkan, jika ada, ini adalah KeySet minimum yang diperlukan, yaitu metadata yang lebih sedikit daripada spesifikasi). speconly meneruskan NULL sebagai defaults ke elektraOpen dan oleh karena itu elektraGet* akan gagal tanpa spesifikasi yang dipasang.
• specValidation=( none | minimal | full ) : Ini mengubah validasi spesifikasi yang dilakukan. none bukan validasi, minimal (default) memeriksa apakah kunci induk spesifikasi ada dan kunci pertama dalam spesifikasi dapat diambil (untuk memastikan spec-mount dieksekusi) . full tidak akan diimplementasikan untuk saat ini, itu akan melakukan validasi penuh seperti yang Anda sarankan.

Kombinasi opsi ini dapat digunakan untuk membuat ulang mode yang saya sarankan. Ada beberapa kombinasi lain juga. Saya pikir opsi ini jauh lebih transparan bagi pengguna, dan implementasinya juga harus lebih bersih.

Maaf, jika saya sedang bertele-tele sekarang, tapi ini masih membingungkan saya.

Tapi spesifikasinya masih harus dipasang, jadi kami tidak tahu persis dari mana.

Tetapi Anda meneruskan spesifikasi bawaan ke kdbEnsure(), jadi apa yang terjadi dengan itu?

Saya juga pikir itu disebutkan di suatu tempat, bahwa kdbEnsure() ada di sana untuk "menimpa" kunci konfigurasi dengan nilai dari baris perintah. Jadi, bukankah kdbEnsure() akan menimpa spesifikasi yang dipasang dengan spesifikasi yang disediakan?

Saya kira saya mengerti sekarang, mengapa Anda tidak menyukai proposal nama file unik saya: Itu tidak membantu karena setelah pemasangan kami tidak tahu file mana yang digunakan.

Sebagai seseorang yang terbiasa dengan linux dan manajer paket hampir sepanjang hidup saya, semakin saya mengerti apa yang Anda lakukan, semakin sedikit saya memahami kasus penggunaan Anda. Tapi saya kira orang masih memindahkan binari secara manual di sistem lain.

Saya pikir satu alasan, mengapa ini sangat membingungkan, adalah, bahwa elektra mencoba membuat lingkaran persegi di sini: Di ​​satu sisi Anda ingin ada satu database global mengikuti spesifikasi yang satu dan benar sejauh Anda memasang spesifikasi ke dalam basis data. Di sisi lain, Anda mengizinkan aplikasi untuk mengembangkan spesifikasinya dan mencoba untuk mengatasi bahwa tidak ada spesifikasi yang sebenarnya.

Saya percaya pada akhirnya hanya ada dua cara untuk menyelesaikan ini:
a) Berpura-pura bahwa ada spesifikasi yang sebenarnya dan berhenti mengkhawatirkan tentang menjaga aplikasi dan spesifikasi tetap sinkron dan berharap pengembang aplikasi melakukan uji tuntas saat memperbarui spesifikasi mereka dan menjalankan skrip instalasi yang tepat dan mungkin melakukan semacam deteksi versi.
b) Tidak benar-benar memasang spesifikasi itu sendiri. Alih-alih ciptakan abstraksi lain yang didasarkan pada gagasan integrasi aplikasi: Karena elektra besar dalam integrasi aplikasi, Anda mungkin sudah memikirkan spesifikasi yang tumpang tindih meskipun saya tidak tahu apa solusi Anda. Akui bahwa beberapa versi dari spesifikasi yang sama (aplikasi yang sama) sebenarnya hanyalah kasus khusus dari integrasi aplikasi dan sediakan mekanisme untuk membuatnya hidup berdampingan dalam namespace yang sama. (Mungkin banyak pekerjaan, tidak yakin apakah itu sepadan.)

Perasaan saya adalah untuk pergi dengan (a), tetapi mari kita juga menjelajahi (b) berdasarkan pengetahuan saya yang sangat buruk tentang apa yang Anda lakukan. Mekanisme baru akan memiliki properti berikut:

1. Setiap spesifikasi memiliki bidang versi, berisi satu (atau mungkin lebih?) versi yang diimplementasikannya dan mungkin beberapa ID lain, checksum, atau apa pun.
2. Setiap aplikasi yang menggunakan validasi penuh dan ketat memiliki nilai kompatibilitas, yang dapat diuji terhadap bidang versi dari (1).
3. Setiap spesifikasi harus benar-benar menentukan semua kunci yang mungkin diakses aplikasi, bahkan jika mereka berada di luar namespace nominalnya. (Tidak yakin bagaimana menangani akses kunci tidak langsung, di mana kunci diakses karena nilai kunci lain.)
4. spesifikasi tidak dipasang lagi. Sebut saja mekanisme baru "instalasi". Ketika spesifikasi baru (versi dari spesifikasi) diinstal, itu akan diperiksa terhadap spesifikasi yang sudah diinstal dan instalasi gagal jika ada ketidakcocokan. (Pengguna harus mencopot pemasangan spesifikasi lain terlebih dahulu.)
   Juga database divalidasi terhadap spesifikasi baru dan pengguna diharuskan untuk memperbaiki konflik apa pun, sebelum instalasi dapat diselesaikan.
5. Dari semua spesifikasi yang diinstal, spesifikasi sebenarnya dihitung dengan menggabungkan semua batasan dan menggabungkan semua bidang versi.
6. Spesifikasi sebenarnya mungkin dipasang ke database global. Saya tidak yakin saya merekomendasikan itu, tetapi untuk alasan kompatibilitas Anda mungkin ingin melakukannya.
7. Untuk aplikasi, tidak masalah jika konfigurasi divalidasi terhadap spesifikasi sebenarnya atau hanya fragmennya sendiri. Satu-satunya hal yang penting adalah bahwa bidang yang kompatibel memvalidasi terhadap bidang versi.

Selain (b) banyak pekerjaan untuk mengimplementasikannya juga menambah banyak kerumitan. Saya tidak yakin apakah misalnya pengelola debian akan menyukai Anda atau membenci Anda, jika Anda melakukannya. Mungkin keduanya. Pokoknya itu pasti di luar ruang lingkup tesis kodebach.

Kesimpulan saya adalah, bahwa dalam jangka pendek kita terjebak dengan (a) dan kasus penggunaan untuk spesifikasi bawaan tampaknya agak tipis dan itu menyebabkan banyak kebingungan dan tidak dieksplorasi dengan baik. Oleh karena itu saya menyarankan untuk berusaha sesedikit mungkin ke dalam mode bawaan dan tidak menggunakannya secara default.

oleh karena itu elektraGet* akan gagal tanpa spesifikasi yang dipasang.

"akan gagal" atau "akan gagal jika database tidak lengkap"?

Maaf, jika saya sedang bertele-tele sekarang, tapi ini masih membingungkan saya.

Tidak apa-apa, saya butuh beberapa waktu untuk memahami cara kerja Elektra juga. Kadang-kadang bisa sangat rumit.

Tetapi Anda meneruskan spesifikasi bawaan ke kdbEnsure(), jadi apa yang terjadi dengan itu? Saya juga pikir itu disebutkan di suatu tempat, bahwa kdbEnsure() ada di sana untuk "menimpa" kunci konfigurasi dengan nilai dari baris perintah. Jadi, bukankah kdbEnsure() akan menimpa spesifikasi yang dipasang dengan spesifikasi yang disediakan?

Kami tidak meneruskan spesifikasi ke kdbEnsure . kdbEnsure ada untuk memodifikasi pegangan KDB dengan cara yang tidak persisten. Ini digunakan untuk mengaktifkan plugin yang memproses opsi baris perintah. Karena beberapa keterbatasan kdbEnsure sekarang tidak dapat menambahkan mountpoints. Tetapi bahkan jika bisa, tetap tidak bijaksana untuk memasukkan spesifikasi dengan cara ini. Menggunakan kdbEnsure hanya akan mempengaruhi proses kita saat ini (sebenarnya hanya handle KDB saat ini). Jika kita menyuntikkan spesifikasi dengan cara ini, alat baris perintah kdb tidak akan mengetahuinya dan mengizinkan modifikasi yang tidak sesuai dengan spesifikasi.

Kesimpulan saya adalah, bahwa dalam jangka pendek kita terjebak dengan (a) dan kasus penggunaan untuk spesifikasi bawaan tampaknya agak tipis dan itu menyebabkan banyak kebingungan dan tidak dieksplorasi dengan baik. Oleh karena itu saya menyarankan untuk berusaha sesedikit mungkin ke dalam mode bawaan dan tidak menggunakannya secara default.

Saya pikir kita harus memikirkan spesifikasi yang disematkan sebagai cara berbeda untuk menyimpan spesifikasi. Kita mungkin harus menggambarkannya sebagai opsi kenyamanan, karena memungkinkan untuk mengemas aplikasi ke dalam satu file. Itu bisa berguna untuk aplikasi kecil, selama spesifikasi tidak terlalu meningkatkan ukuran biner.

Jika Anda mengemas aplikasi Anda sebagai misalnya .deb atau .rpm , saya akan merekomendasikan menggunakan opsi specLocation=external dan defaultsHandling=speconly untuk build rilis.

"akan gagal" atau "akan gagal jika database tidak lengkap"?

Akan gagal jika database tidak lengkap. Tentu saja masih berfungsi, jika Anda menambahkan kunci secara manual dengan jenis yang benar.

Kami tidak meneruskan spesifikasi ke kdbEnsure.

Hm, maka saya perlu membaca ulang kode yang dihasilkan. Aku pasti tersesat di suatu tempat.

Menggunakan kdbEnsure hanya akan mempengaruhi proses kita saat ini (sebenarnya hanya handle KDB saat ini). Jika kita menyuntikkan spesifikasi dengan cara ini, alat baris perintah kdb tidak akan mengetahuinya dan mengizinkan modifikasi yang tidak sesuai dengan spesifikasi.

Saya telah berpikir inilah intinya: Untuk mendeteksi kesalahan konfigurasi dengan memvalidasi terhadap spesifikasi yang diketahui benar jika kdb karena alasan tertentu memiliki gagasan yang salah tentang spesifikasi tersebut dan oleh karena itu modifikasi yang tidak sesuai dengan spesifikasi telah menyelinap masuk.

Tentu saja, bahkan jika Anda melakukannya seperti di atas, Anda masih ingin memasang spesifikasi secara global juga.

Bagaimanapun, saya pikir sudah jelas sekarang dan mode (1) tidak memiliki usecase untuk orang yang menggunakan manajer paket atau membangun lcdproc secara lokal. Mungkin ini berguna untuk orang yang memindahkan binari di sekitar USB-stick, meskipun mereka perlu tahu banyak tentang elekra untuk benar-benar membuatnya berfungsi.

Membandingkan dua KeySet yang berpotensi sangat besar akan cukup mahal, saya ingin menghindarinya jika memungkinkan.

Apakah Anda membandingkannya?

Saya akan menerapkan 3 opsi ke pembuat kode:

Saya pikir Anda terlalu bersemangat di sini. Pertama-tama mari kita sepakati kasus penggunaan dan kemudian tentang cara mengimplementasikannya.

specLocation=( embed | external ): Ini mengubah bagaimana spesifikasi yang diproses adalah output. embed (default) menyematkannya ke dalam biner, eksternal menghasilkan file terpisah.

Setuju, jika kita memiliki satu hasil, itu akan menjadi itu. Mungkin menulis ulang: embedSpec: penuh, minimal?

defaultsHandling=( embed | speconly ): Ini mengubah cara penanganan default. embed (default) meneruskan KeySet default ke elektraOpen (KeySet adalah spesifikasi yang disematkan, jika ada, itu adalah KeySet minimum yang diperlukan, yaitu lebih sedikit metadata daripada spesifikasi). speconly meneruskan NULL sebagai default ke elektraOpen dan oleh karena itu elektraGet* akan gagal tanpa spesifikasi yang dipasang.

Bisa tolong jelaskan? Mengapa Anda tidak meneruskan semuanya ke default apa yang telah kami sematkan?

specValidation=( none | minimal | full ): Ini mengubah validasi spesifikasi yang dilakukan. none is no validasi, minimal (default) memeriksa apakah kunci induk spesifikasi ada dan kunci pertama dalam spesifikasi dapat diambil (untuk memastikan pemasangan spesifikasi dijalankan). full tidak akan diimplementasikan untuk saat ini, itu akan melakukan validasi penuh seperti yang Anda sarankan.

Lihat di atas.

Bagaimanapun, saya pikir sudah jelas sekarang dan mode (1) tidak memiliki usecase untuk orang yang menggunakan manajer paket atau membangun lcdproc secara lokal. Mungkin ini berguna untuk orang yang memindahkan binari di sekitar USB-stick, meskipun mereka perlu tahu banyak tentang elekra untuk benar-benar membuatnya berfungsi.

Ya, saya pikir tujuan kami sekarang adalah menemukan jumlah minimum kasus penggunaan yang benar-benar dapat kami dokumentasikan dan dukung. @haraldg dapatkah Anda membantu dengan itu?

Apakah Anda membandingkannya?

Apakah saya perlu? Membandingkan dua KeySet dengan ukuran yang sama jelas O(m + n) ( m jumlah total metakey, n jumlah total kunci). Untuk ukuran yang berbeda akan menjadi O(1) . Jika kita menggunakan keyCompare semuanya pada dasarnya akan berjumlah 2*(m+n) strcmp s dan n memcmp s.

Kami juga membutuhkan data dunia nyata, karena jumlah rata-rata metakeys per kunci dapat membuat perbedaan.

Saya melakukan uji coba cepat pada mesin saya membandingkan dua KeySets dengan 1,000.001 kunci masing-masing, di mana setiap kunci memiliki 1 metakey dan semuanya sama, kecuali untuk metakey terakhir. Pengerjaan penuh memakan waktu sekitar 4,5 detik, di mana 3 di antaranya dihabiskan untuk membangun KeySet.

Saya pikir Anda terlalu bersemangat di sini.

Saya minta maaf tapi, waktu saya tidak terbatas.

Bisa tolong jelaskan? Mengapa Anda tidak meneruskan semuanya ke default apa yang telah kami sematkan?

Jika specLocation=external digunakan, tidak ada spesifikasi yang disematkan. Dalam hal ini defaultsHandling=embed akan menggunakan KeySet dengan hanya nilai kunci dan metadata type untuk menghemat ruang biner.

Namun, kombinasi ini agak aneh. Saya tidak akan merekomendasikannya kecuali ada kebutuhan yang sangat spesifik untuk itu. Dalam dokumentasi saya akan merekomendasikan menggunakan defaultsHandling=speconly untuk specLocation=external .

Lihat di atas.

Tidak yakin yang "di atas" yang Anda maksud, tetapi saya akan mencoba menjelaskan kasus penggunaan untuk specValidation .

• none berguna untuk sistem di mana spesifikasi dijamin untuk dipasang dan dijamin tidak akan dihapus. Misalnya sistem tertanam di mana semuanya dikompilasi menjadi gambar firmware yang hanya dapat dibaca.
• minimal atau jika diterapkan full adalah pengaturan yang disarankan dan default. full hanya dapat digunakan dengan specLocation=embed , karena jika tidak, spesifikasi lengkap tidak akan disematkan dan tidak dapat digunakan untuk validasi. Satu-satunya perbedaan lain di antara mereka adalah kinerja.

jumlah minimum kasus penggunaan yang sebenarnya dapat kami dokumentasikan dan dukung

Kita seharusnya tidak mendokumentasikan kasus penggunaan sama sekali. Kita harus mendokumentasikan opsi yang tersedia di pembuat kode. Bagaimana orang menggunakan opsi ini terserah mereka. Tentu saja kita harus memberikan rekomendasi dan contoh, tetapi mengapa dengan sengaja membatasi apa yang dapat dilakukan orang dengan alat kita? Selama kami dengan jelas menyatakan potensi kelemahan menggunakan opsi yang berbeda, saya tidak melihat masalah.

Kami juga membutuhkan data dunia nyata

Kami memiliki data dunia nyata: spesifikasi LCDproc.

Pengerjaan penuh memakan waktu sekitar 4,5 detik, di mana 3 di antaranya dihabiskan untuk membangun KeySet.

Terima kasih untuk tolok ukurnya! Jadi membandingkan jauh lebih cepat daripada membuat KeySets. Tapi mungkin kita tidak membutuhkannya: lihat kasus penggunaan di bawah ini.

Saya minta maaf tapi, waktu saya tidak terbatas.

Tentu saja, justru karena itu saya menyarankan Anda untuk mengurangi jumlah varian yang Anda terapkan. Dokumentasi dan pengujian semua yang Anda sarankan akan memakan waktu terlalu lama.

Prioritas tertinggi Anda sekarang adalah membuat PR yang berfungsi minimal (untuk satu klien) dengan dokumen yang baik untuk satu kasus penggunaan (saya akan menyarankan 1. kasus di bawah) sehingga kami akhirnya mendapatkan umpan balik publik.

Kita seharusnya tidak mendokumentasikan kasus penggunaan sama sekali. Kita harus mendokumentasikan opsi yang tersedia di pembuat kode. Bagaimana orang menggunakan opsi ini terserah mereka. Tentu saja kita harus memberikan rekomendasi dan contoh, tetapi mengapa dengan sengaja membatasi apa yang dapat dilakukan orang dengan alat kita? Selama kami dengan jelas menyatakan potensi kelemahan menggunakan opsi yang berbeda, saya tidak melihat masalah.

Ada masalah besar: Beban kognitif yang kita berikan pada orang. Mereka perlu memahami banyak detail Elektra dan bahkan jika mereka melakukannya, mereka dapat dengan mudah mengacaukan dan memilih satu kombinasi dari varian 2 2 3=12 yang tetap tidak berfungsi.

Berdasarkan apa yang diterapkan, apa tujuan Elektra dan waktu yang tersisa, saya pikir kita harus memiliki 3 kasus penggunaan:

1. (default) spesifikasi lengkap tertanam, tidak ada yang dipasang: untuk pengembang yang hanya ingin menjalankan LCDproc dari direktori build.
2. varian terinstal 1: skrip selama make install memasang spesifikasi dalam biner dengan specload. Kasus penggunaan ini adalah untuk bermain-main dengan konfigurasi dan spesifikasi (setelah specload mendukung pengeditan simpan spesifikasi. Untuk saat ini, perubahan minimal yang kami izinkan sudah cukup).
3. ukuran biner minimal untuk sistem yang disematkan: Kami berasumsi bahwa spesifikasi dipasang melalui ni (dan juga menyediakan skrip yang memasang ni + spesifikasi, yang dijalankan selama make install ). Dalam mode ini, biner tidak dapat dieksekusi selama tidak diinstal. Tetapi kami berasumsi bahwa spesifikasinya benar karena alasan kinerja.

Apakah Anda berdua baik-baik saja dengan ini? @kodebach : apa yang akan menjadi set minimal varian dalam generator kode dan sistem build LCDproc untuk mendukung ini?

Saya pikir usulan kodebach ini cukup masuk akal. Tidak yakin bantuan apa yang bisa saya berikan selain itu.

Beban mental berasal dari pemahaman konsep seperti pemasangan, spesifikasi dll, yang harus diinvestasikan tidak peduli bagaimana opsi yang tersedia disajikan kepada pengguna. Saya pikir kebingungan terbesar berasal dari "spesifikasi sudah terpasang tetapi tidak digunakan tanpa pemasangan global", tetapi tampaknya Anda berdua cukup menjual hal itu. Saya tidak melihat banyak hal lain untuk dijatuhkan, itu akan membuat segalanya lebih mudah untuk dipahami.

mereka dapat dengan mudah mengacaukan dan memilih satu kombinasi dari 223=12 varian yang tetap tidak berfungsi.

Saya pikir mungkin ada perbedaan antara opsi untuk pembuat kode dan opsi untuk mengonfigurasi. Generator kode digunakan oleh pengembang (atau lebih tepatnya pengembang yang mengerjakan sistem pembangunan), sementara konfigurasi harus dapat dimengerti oleh semua orang. Saya mungkin hanya mengekspos opsi pembuat kode melalui konfigurasi, tetapi memberikan default yang baik, sehingga pengguna tidak perlu memikirkannya sama sekali.

(default) spesifikasi lengkap tertanam, tidak ada yang dipasang: untuk pengembang yang hanya ingin menjalankan LCDproc dari direktori build.

Saya pikir itu adalah kesimpulan dari beberapa hari diskusi terakhir, bahwa skenario ini tidak ada di atas meja karena specload tidak berfungsi seperti itu dan perubahan pada internal seperti kdbEnsure() harus tetap terjadi untuk mengimplementasikannya?

Juga agar ini berguna untuk menjalankan LCDd dari pohon build, beberapa opsi setara dengan -c perlu bekerja, karena pengaturan default yang lengkap hanya akan bekerja untuk driver yang sangat sedikit. Saya kira salah satu cara untuk membuat ini berfungsi adalah dengan memiliki beberapa cara untuk memberi tahu elektra untuk menggunakan $BUILD_DIR/elektra.ini alih-alih /etc/kdb/elektra.ecf - tetapi tidak tahu betapa sulitnya itu dan itu adalah yang lain gangguan, jadi mari kita tidak mengeksplorasi itu sekarang.

Jika Anda masih ingin tahu apa set minimal varian untuk LCDproc, maka menurut saya dalam hal opsi kodebach adalah:

specLocation=eksternal, defaultsHandling=speconly, specValidation=( none | minimal )

Jadi ya, itu bisa dipreteli menjadi satu opsi.

Saya pikir salah satu pertanyaan terbuka adalah, apa yang sebenarnya akan dilakukan specValidation´, ketika spesifikasi tidak ada: gagal? mengeluarkan peringatan, tetapi coba lanjutkan? Saya kira apa pun yang kami putuskan di sini, beberapa pengembang lain dari beberapa aplikasi lain akan menginginkan sesuatu yang lain. Mungkin ruang tindakan yang mungkin bahkan tidak dapat diungkapkan dengan opsi, tetapi hanya dengan kode. Yaitu mengizinkan untuk menentukan beberapa panggilan balik jika terjadi kesalahan validasi. Tapi sekali lagi, saya pikir ini bukan sesuatu yang harus diputuskan sekarang selama apa yang kita lakukan sekarang tidak benar-benar mempersulit implementasi di masa depan.

Saya pikir kebingungan terbesar berasal dari "spesifikasi sudah terpasang tetapi tidak digunakan tanpa pemasangan global", tetapi tampaknya Anda berdua cukup menjual hal itu.

Ini adalah opsi yang sudah tersedia, jadi mengapa menjatuhkannya? Saya akan berhati-hati bagaimana saya mendokumentasikan spesifikasi built-in dan akan secara eksplisit menyatakan bahwa hanya cara yang berbeda untuk menyimpan spesifikasi, tetapi tidak benar-benar memiliki keuntungan lain.

Saya pikir itu adalah kesimpulan dari diskusi beberapa hari terakhir, bahwa skenario ini tidak ada di atas meja karena specload tidak bekerja seperti itu

Dengan spesifikasi lengkap yang disematkan dan tidak ada yang dipasang, Anda dapat mengeksekusi dari direktori build, tetapi tidak ada validasi atau konversi yang akan terjadi, karena tidak ada plugin yang berjalan tanpa penyiapan tambahan.

Juga agar ini berguna untuk menjalankan LCDd dari pohon build, beberapa setara dengan opsi -c harus berfungsi
Saya kira salah satu cara untuk membuat ini berfungsi adalah dengan memiliki beberapa cara untuk memberi tahu elektra untuk menggunakan $BUILD_DIR/elektra.ini alih-alih /etc/kdb/elektra.ecf

Kita sudah memiliki ruang nama dir . Anda dapat memasang konfigurasi di sana dan itu akan menjadi lokal ke direktori kerja Anda. Sayangnya namespace dir sangat aneh, karena konfigurasinya luas sistem. Lihat juga #1074.

Saya pikir salah satu pertanyaan terbuka adalah, apa yang sebenarnya akan dilakukan specValidation´, ketika spesifikasi tidak ada: gagal? mengeluarkan peringatan, tetapi coba lanjutkan?

loadConfiguration sudah dapat mengembalikan kesalahan yang harus ditangani oleh aplikasi. Validasi spesifikasi yang gagal hanya akan menjadi jenis kesalahan lain. Jika kami melihat kebutuhan untuk itu, kami juga dapat menyediakan cara untuk melanjutkan meskipun validasi spesifikasi gagal (tidak akan merekomendasikannya).

Beban mental berasal dari pemahaman konsep seperti pemasangan, spesifikasi dll, yang harus diinvestasikan tidak peduli bagaimana opsi yang tersedia disajikan kepada pengguna.

Ini belum tentu benar: ada banyak konsep dalam Elektra yang tidak perlu Anda pahami selama Anda tidak dihadapkan dengannya. Dalam kasus penggunaan 1. Anda tidak akan dihadapkan dengan pemasangan dan spesifikasi sama sekali.

Secara umum Elektra dirancang dengan hati-hati sehingga distribusi sudah dapat memutuskan banyak hal untuk pengguna (misalnya memasang semua file dalam beberapa format konfigurasi). Kemudian pengguna dapat menggunakan distribusi dengan cara yang sangat mirip daripada yang mereka gunakan sekarang (hanya konfigurasi yang disatukan). Namun, mereka tidak perlu memahami pemasangan. (Itu juga alasan mengapa pemasangan hanya dimungkinkan untuk root: fitur ini dimaksudkan untuk distribusi atau make install , bukan untuk pengguna akhir.)

Saya pikir kebingungan terbesar berasal dari "spesifikasi sudah terpasang tetapi tidak digunakan tanpa pemasangan global", tetapi tampaknya Anda berdua cukup menjual hal itu. Saya tidak melihat banyak hal lain untuk dijatuhkan, itu akan membuat segalanya lebih mudah untuk dipahami.

Jika Anda melihat kami seharusnya tidak mendukung/mendokumentasikannya, kami akan dengan senang hati melakukannya. Ini berarti bahwa menginstal LCDproc akan diperlukan untuk memulainya. Saya akan menemukan itu sangat menjengkelkan.

Saya pikir itu adalah kesimpulan dari beberapa hari diskusi terakhir, bahwa skenario ini tidak ada di atas meja karena specload tidak berfungsi seperti itu dan perubahan pada internal seperti kdbEnsure() harus tetap terjadi untuk mengimplementasikannya?

specload dan kdbEnsure tidak akan digunakan di sini. Kami hanya akan kehilangan sebagian besar jaminan, karena tidak ada validasi yang akan terjadi. Ini hanya untuk mengembangkan LCDproc tanpa mengubah spesifikasi atau conf. Tapi imho ini juga merupakan kasus penggunaan yang valid. Jika Anda tidak berpikir demikian, kami tidak akan mendukungnya.

tetapi berikan default yang baik, sehingga pengguna tidak perlu memikirkannya sama sekali.

Tentu saja ini selalu menjadi mimpi tetapi kenyataannya sering kali jika Anda mengacaukan desain konfigurasi, pengguna akan menemukan banyak cara untuk membuat kesalahan. Dan mengekspos keputusan yang bisa dilakukan oleh pengembang adalah desain konfigurasi yang sangat bau.

Jadi ya, itu bisa dipreteli menjadi satu opsi.

Maka kita harus melakukannya.

Ini adalah opsi yang sudah tersedia, jadi mengapa menjatuhkannya? Saya akan berhati-hati bagaimana saya mendokumentasikan spesifikasi built-in dan akan secara eksplisit menyatakan bahwa hanya cara yang berbeda untuk menyimpan spesifikasi, tetapi tidak benar-benar memiliki keuntungan lain.

Anda berasumsi bahwa semua orang membaca dan memahami dokumen tersebut. Sebenarnya hanya orang-orang yang terlibat secara mendalam seperti kita sekarang, yang benar-benar dapat memutuskan cara menyimpan spesifikasi yang lebih baik. Jadi adalah tanggung jawab kita untuk memutuskannya dengan benar. Mendorong keputusan ini kepada pengguna bukanlah cara untuk melakukannya.

loadConfiguration sudah dapat mengembalikan kesalahan yang harus ditangani oleh aplikasi. Validasi spesifikasi yang gagal hanya akan menjadi jenis kesalahan lain. Jika kami melihat kebutuhan untuk itu, kami juga dapat menyediakan cara untuk melanjutkan meskipun validasi spesifikasi gagal (tidak akan merekomendasikannya).

Ya, saya juga tidak merekomendasikan untuk melakukannya dengan cara itu. Tetapi peretas akan mencari tahu dan menggunakan trik ini secara lokal. Semoga @haraldg tidak menggabungkan peretasan ini :smile:

Dalam kasus penggunaan 1. Anda tidak akan dihadapkan dengan pemasangan dan spesifikasi sama sekali.

Pengguna akhir (misalnya orang yang menggunakan LCDproc) tidak boleh dihadapkan dengan pemasangan, sepenuhnya independen dari mode pembuatan kode. Pemasangan harus selalu otomatis dalam proses pemasangan.

Pengembang (misalnya orang yang bekerja pada LCDproc) selalu harus memahami pemasangan, kecuali jika ada perubahan serius pada cara kerja Elektra. Anda tidak dapat mengembangkan aplikasi menggunakan API pembuatan kode tanpa mengetahui tentang pemasangan, hanya karena Anda harus membuat skrip pemasangan yang bertanggung jawab untuk pemasangan dan kemungkinan harus dipasang secara manual selama pengembangan.

Ini berarti bahwa menginstal LCDproc akan diperlukan untuk memulainya.

Menjatuhkan spesifikasi bawaan hanya membutuhkan cara pemasangan yang berbeda. Anda masih dapat menjalankan LCDproc dari direktori mana pun dan spesifikasi terpasang yang valid diperlukan dalam kedua kasus.

Anda berasumsi bahwa semua orang membaca dan memahami dokumen tersebut.

Itulah mengapa kita perlu memutuskan default yang baik, bukan mengapa kita tidak memiliki pilihan. Juga jika pengembang menggunakan API tanpa mempelajari dokumentasi dengan benar, mereka seharusnya tidak berharap untuk mendapatkan hasil terbaik.

Karena seluruh diskusi ini tidak membawa kita ke mana-mana, sekarang saya akan memulai implementasinya. Setelah saya memiliki beberapa kode yang dapat Anda coba, kita masih dapat memutuskan apa yang harus dipertahankan, apa yang harus diubah, dan apa yang ditambahkan.

Saya sebagian besar setuju dengan @kodebach dalam diskusi di atas.

Jika Anda melihat kami seharusnya tidak mendukung/mendokumentasikannya, kami akan dengan senang hati melakukannya. Ini berarti bahwa menginstal LCDproc akan diperlukan untuk memulainya. Saya akan menemukan itu sangat menjengkelkan.

Ya, itu sangat menjengkelkan, tetapi tampaknya berada di luar jangkauan apa yang dilakukan @kodebach , jadi kami harus menerimanya. Juga tampaknya merobek dasar elektra untuk mengizinkan konfigurasi non-global seperti apa yang dilakukan opsi -c , sama sekali, jadi kita pasti harus membuka masalah baru untuk "mode root palsu" ini, jika kita mau untuk bekerja di atasnya.

Ini hanya untuk mengembangkan LCDproc tanpa mengubah spesifikasi atau conf. Tapi imho ini juga merupakan kasus penggunaan yang valid. Jika Anda tidak berpikir demikian, kami tidak akan mendukungnya.

Saya tidak ingat pernah menjalankan program apa pun dari LCDproc dengan konfigurasi default yang lengkap. Mungkin saya melakukannya pada beberapa kesempatan untuk beberapa pengujian yang sangat sepele, namun saya memiliki 5 varian berbeda von LCDd.conf (dirancang untuk menguji aspek yang berbeda) di direktori build saya, yang sering saya gunakan dengan -c . Jadi menjalankan LCDd dari direktori build tetapi tanpa "mengubah conf" sepertinya merupakan kasus yang sangat sulit bagi saya.

Ya, saya juga tidak merekomendasikan untuk melakukannya dengan cara itu. Tetapi peretas akan mencari tahu dan menggunakan trik ini secara lokal. Semoga @haraldg tidak menggabungkan peretasan ini

Apa yang digabungkan sangat tergantung pada orang yang menjelaskan kasus penggunaan mereka dan meyakinkan saya, bahwa itu lebih baik daripada bahaya. Jika orang terkadang perlu menjalankan aplikasi tanpa spesifikasi (katakanlah itu pada sistem file, yang tidak selalu dipasang), tetapi masih menginginkan peringatan ketika spesifikasi tidak tersedia, maka saya mungkin tidak boleh memberi tahu mereka untuk melakukannya "gunakan saja mode OpenWRT, di mana spesifikasi tidak pernah dicentang" tetapi izinkan mereka, untuk menambahkan sakelar ke sistem build, yang membuat spesifikasi yang hilang tidak terlalu fatal.

yang sering saya gunakan dengan -c

Jika -c hanya digunakan untuk pengembangan, Anda dapat kdb mount LCDd.ini dir/sw/lcdproc/lcdd/#0/current . Kemudian setiap kali Anda menjalankan LCDd itu harus menggunakan $PWD/.dir/LCDd.ini , jika ada. Kemudian Anda dapat menjalankan LCDd dari direktori yang berbeda untuk menggunakan konfigurasi yang berbeda, atau Anda cukup menukar file .dir/LCDd.ini kapan pun Anda ingin mengubah konfigurasi. Seperti yang saya katakan, ini adalah pengaturan yang sangat aneh dan #1074 pasti harus diterapkan (IMO titik mount dir harus khusus untuk satu direktori bukan untuk seluruh sistem), tetapi ini adalah solusi untuk saat ini.

Jika orang terkadang perlu menjalankan aplikasi tanpa spesifikasi [...] tetapi mengizinkan mereka, untuk menambahkan sakelar ke sistem pembangunan, itu membuat spesifikasi yang hilang tidak terlalu fatal.

Saya beralih dalam sistem build akan menjadi solusi yang dapat diterima (saklar itu hanya dapat menonaktifkan pemeriksaan). Apa yang menurut saya tidak boleh kita terapkan (kecuali jika ada kebutuhan mutlak untuk itu), adalah membuat cek, tetapi kemudian mengizinkan aplikasi untuk melanjutkan bahkan jika cek gagal. IMO jika cek dibuat, itu harus berhasil agar aplikasi berfungsi.

[ dir titik mount ]

Ya, saya yakin semua orang akan menemukan solusi yang dapat diterima oleh mereka.

IMO jika cek dibuat, itu harus berhasil agar aplikasi berfungsi.

Jadi menurut Anda peringatan lebih buruk daripada tidak ada pemeriksaan sama sekali? (BTW cabang diskusi ini bukan tentang apa yang harus Anda terapkan, tetapi apa yang mungkin membuat saya tergoda untuk bergabung, jika seseorang mengusulkannya untuk LCDproc.)

Anda tidak dapat mengembangkan aplikasi menggunakan API pembuatan kode tanpa mengetahui tentang pemasangan, hanya karena Anda harus membuat skrip pemasangan yang bertanggung jawab untuk pemasangan dan kemungkinan harus dipasang secara manual selama pengembangan.

Kami membuat skrip sekarang untuk LCDproc. Dan menambahkan beberapa elektraGet dalam modul/driver semoga dapat dilakukan tanpa memahami pemasangan.

Itulah mengapa kita perlu memutuskan default yang baik, bukan mengapa kita tidak memiliki pilihan.

Ini adalah kesalahpahaman umum: tidak mungkin membuat konfigurasi waras hanya dengan memberikan default yang baik. Saat Anda perlu mengubah sesuatu, Anda dihadapkan pada kerumitan konfigurasi. Karena itu, Anda harus selalu waspada terhadap dua hal:

1. jaga agar desain konfigurasi tetap sederhana
2. memiliki default yang bagus

Juga jika pengembang menggunakan API tanpa mempelajari dokumentasi dengan benar, mereka seharusnya tidak berharap untuk mendapatkan hasil terbaik.

Ya, API adalah contoh yang bagus! Apakah Anda ingin memiliki API tempat Anda memiliki panggilan yang memutuskan tentang beberapa internal yang tidak Anda ketahui?

Karena seluruh diskusi ini tidak membawa kita ke mana-mana, sekarang saya akan memulai implementasinya. Setelah saya memiliki beberapa kode yang dapat Anda coba, kita masih dapat memutuskan apa yang harus dipertahankan, apa yang harus diubah, dan apa yang ditambahkan.

Ya, seperti yang telah diinginkan beberapa kali: lakukan perbaikan yang diperlukan agar klien berhasil memulai, buat PR di repo LCDproc dan kemudian tulis ke milis.

Mode generator kode lebih lanjut dan optimalisasi ukuran biner harus dilakukan setelah kami mendapatkan umpan balik lebih lanjut.

Jadi menurut Anda peringatan lebih buruk daripada tidak ada pemeriksaan sama sekali? (BTW cabang diskusi ini bukan tentang apa yang harus Anda terapkan, tetapi apa yang mungkin membuat saya tergoda untuk bergabung, jika seseorang mengusulkannya untuk LCDproc.)

Masalah dengan kelanjutan pada kesalahan spesifikasi adalah bahwa mungkin juga ada kesalahan lain yang tidak dilaporkan (kami selalu melaporkan hanya satu kesalahan).

Anda tidak dapat mengembangkan aplikasi menggunakan API pembuatan kode tanpa mengetahui tentang pemasangan, hanya karena Anda harus membuat skrip pemasangan yang bertanggung jawab untuk pemasangan dan kemungkinan harus dipasang secara manual selama pengembangan.

Kami membuat skrip sekarang untuk LCDproc. Dan menambahkan beberapa elektraGet dalam modul/driver semoga dapat dilakukan tanpa memahami pemasangan.

Anda melewatkan intinya. Untuk mengembangkan aplikasi menggunakan API pembuatan kode, Anda perlu tahu tentang pemasangan. Lebih khusus lagi, orang yang bertanggung jawab untuk membuat skrip instalasi yang melakukan pemasangan harus tahu tentang konsep pemasangan. Dalam kasus LCDproc orang ini adalah saya. Saya tahu tentang pemasangan, tetapi saya tidak akan menulis skrip untuk semua proyek yang ingin menggunakan API pembuatan kode.

Poin utamanya adalah Anda meninggalkan kesan bahwa ada solusi di mana kami sepenuhnya mengabstraksikan konsep pemasangan. Ini bukan kasusnya.

Karena itu, Anda harus selalu waspada terhadap dua hal:

1. jaga agar desain konfigurasi tetap sederhana
2. memiliki default yang bagus

Tentu saja kesederhanaan juga penting. Tetapi jika Anda terlalu fokus pada kesederhanaan, Anda kehilangan fleksibilitas. Pada titik tertentu Anda harus mengorbankan kesederhanaan, jika Anda ingin memberikan solusi umum. Elektra ingin memberikan solusi umum, jadi harus ada beberapa kerumitan.

Apakah Anda ingin memiliki API tempat Anda memiliki panggilan yang memutuskan tentang beberapa internal yang tidak Anda ketahui?

Bukankah itu inti dari memiliki API tingkat tinggi, atau API apa pun dalam hal ini? Ini menyembunyikan bagian dalam dari level yang lebih rendah, sehingga Anda tidak perlu tahu tentang semua hal yang rumit.

Juga hal ini bertentangan dengan pernyataan Anda sebelumnya. Jika API tidak memutuskan untuk saya, itu harus mengekspos semua opsi. Oleh karena itu tidak bisa sederhana. Jadi apakah Anda ingin sederhana atau Anda ingin pilihan?

Ya, seperti yang sudah diinginkan beberapa kali: harap lakukan perbaikan yang diperlukan agar klien berhasil memulai

Saya sudah menyatakan beberapa kali, bahwa klien (dan juga server) seharusnya sudah mulai berhasil. Saya juga memberikan instruksi di https://github.com/ElektraInitiative/libelektra/issues/2748#issuecomment -500158389. Jika tidak berhasil untuk Anda, beri tahu saya.

Poin utamanya adalah Anda meninggalkan kesan bahwa ada solusi di mana kami sepenuhnya mengabstraksikan konsep pemasangan. Ini bukan kasusnya.

Belum tetapi mungkin Anda menemukan cara untuk menulis skrip instalasi yang dapat digunakan kembali? Sesuatu seperti:

magic.sh path-to-spec-file aplikasi-root-key-name

Apa dua argumen itu, pengembang jelas perlu tahu.

Tentu saja kesederhanaan juga penting. Tetapi jika Anda terlalu fokus pada kesederhanaan, Anda kehilangan fleksibilitas. Pada titik tertentu Anda harus mengorbankan kesederhanaan, jika Anda ingin memberikan solusi umum. Elektra ingin memberikan solusi umum, jadi harus ada beberapa kerumitan.

Jika seseorang menginginkan beberapa fitur, maka dia tentu saja perlu menyelami beberapa kompleksitas, misalnya membaca tentang beberapa konsep atau plugin (dan kami bersedia menyediakan juga fitur yang kompleks). Dan Anda melakukan pekerjaan yang luar biasa untuk banyak fitur berbeda.

Tetapi konsep dan plugin ini harus sesederhana mungkin dan hanya melakukan apa yang diperlukan. Kami sudah memiliki cukup monster (:wave: ini, spec, daftar plugin; generator kode lama). Kita harus menyingkirkan monster-monster ini dan tidak memperkenalkan yang baru. Dengan demikian Elektra memiliki tujuan kualitas yang sangat jelas: Lebih menyukai kesederhanaan daripada kekokohan dan ekstensibilitas (fleksibilitas). Ini dinyatakan dengan sangat jelas di GOALS.md .

Dan kami juga menjalani ini: masih mungkin (dan akan selalu) untuk mendapatkan/menetapkan nilai di Elektra tanpa menggunakan salah satu dari konsep yang kami bicarakan di sini.

Harald bertanya tentang 5 mode berbeda (yang sudah saya temukan berlebihan, tapi ok, dia adalah pelanggannya) tetapi kami tidak boleh memperkenalkan 12 yang tidak diminta oleh siapa pun. Secara khusus, saya masih tidak mengerti apa yang harus dilakukan pengguna dengan opsi "defaultsHandling". Bagi saya itu adalah tipikal "Saya membutuhkan if dalam kode sumber, jadi mari kita tambahkan opsi". Ini jelas bukan bagaimana desain konfigurasi harus dilakukan. Kita harus selalu berasumsi bahwa orang melihat kita bagaimana melakukan desain konfigurasi yang tepat. Misalnya spesifikasi atau daftar plugin sangat memalukan dan kita harus menyingkirkan ini secepatnya. Anda sudah banyak membantu dengan plugin spesifikasi tetapi ada lebih banyak hal yang harus dihapus di sana. Tentu saja saya tidak meminta Anda karena Anda sudah melakukan begitu banyak pekerjaan yang di luar keinginan Anda semula.

Saya sudah menyatakan beberapa kali, bahwa klien (dan juga server) seharusnya sudah mulai berhasil. Saya juga memberikan instruksi di #2748 (komentar). Jika tidak berhasil untuk Anda, beri tahu saya.

@haraldg sudah mengujinya (lihat beberapa komentar di bawah tautan Anda) dan dia berkata:

Saya juga mencoba mengambil beberapa pengaturan waktu, tetapi klien mana pun segera melakukan kesalahan.

Selanjutnya, instruksi tidak boleh disembunyikan dalam beberapa diskusi. Harap selesaikan semuanya dan buat PR yang tepat untuk repo LCDproc utama yang juga menyertakan tutorial (untuk instruksi). Terima kasih!

Perbarui kemajuan di #2805

@haraldg sudah mengujinya (lihat beberapa komentar di bawah tautan Anda) dan dia berkata:

Saya juga mencoba mengambil beberapa pengaturan waktu, tetapi klien mana pun segera melakukan kesalahan.

Saya tidak memiliki akses ke perangkat armhf , jadi saya tidak dapat mereproduksi ini. Dari sedikit informasi yang diberikan dalam komentar asli, saya menduga bahwa plugin gopts tidak ditemukan.

Secara khusus, saya masih tidak mengerti apa yang harus dilakukan pengguna dengan opsi "defaultsHandling".

Opsi specValidation agak independen dari dua lainnya. defaultsHandling (DH) dan specLocation (SL) selalu harus dikoordinasikan sampai tingkat tertentu.

Untuk DH dan SL saat ini defaultnya adalah embed , karena memungkinkan fleksibilitas yang paling besar.

Untuk mengurangi ukuran biner, tetapi tetap mengizinkan menjalankan aplikasi tanpa memerlukan kdb mount Anda dapat menyetel SL ke speconly (dan membiarkan DH apa adanya). Dalam versi ini biner tidak mengandung spesifikasi lengkap. Sebagai gantinya kami menyematkan KeySet yang hanya memiliki nama kunci, default, dan jenis metadata. Ini semua yang kita butuhkan untuk API tingkat tinggi.

Jika Anda ingin ukuran biner minimal Anda harus mengatur SL ke external dan DH ke speconly . Dalam hal ini tidak ada spesifikasi yang akan dimuat dalam biner. Ini juga menghemat waktu selama startup, yang akan diperlukan untuk membangun KeySet(s) (walaupun dampaknya harus minimal).

Kombinasi terakhir specLocation=embed dan defaultsHandling=speconly tidak banyak digunakan. Satu-satunya keuntungan yang dapat saya lihat di sini adalah, Anda menghemat sedikit waktu dengan tidak membuat KeySet dengan default untuk elektraOpen, dan tidak memprosesnya di elektraOpen. Pengaturan ini hanyalah konsekuensi dari memiliki dua opsi terpisah.

Selanjutnya, instruksi tidak boleh disembunyikan dalam beberapa diskusi.

Saya belum memberikan instruksi yang tepat, karena mereka mungkin telah berubah secara besar-besaran setelah diskusi ini. Sekarang saya akan mulai mengerjakan dokumentasi juga.

buat PR yang tepat untuk repo LCDproc utama

Setelah menambahkan mode yang berbeda dan beberapa pengujian dan eksperimen minggu ini, saya sekarang dengan tegas berpendapat bahwa ini bukan ide yang baik. Tentu saja umpan baliknya akan bagus, tetapi saya tidak melihat cara PR ini akan digabungkan dalam waktu dekat (= musim panas ini). Semakin dekat saya untuk menyelesaikan pekerjaan saya, semakin banyak masalah di bagian lain dari Elektra temukan.

Banyak dari masalah ini bersifat sistemik dan jelas muncul dari fakta bahwa banyak fitur Elektras adalah peretasan. Peretasan berarti bagian yang menggunakan inti dengan cara yang tidak pernah dirancang untuknya. Yang paling menonjol adalah plugin spec dan type . Juga saat menggunakan tombol cascading, banyak hal yang rusak karena alasan yang tidak dapat dijelaskan.

Misalnya hari ini saya menemukan masalah ini. Saya tidak tahu, mengapa itu tidak muncul sampai sekarang, atau mengapa itu menjadi masalah, tetapi inilah kami:

kdb set -N user /sw/lcdproc/lcdproc/#0/current/lcdproc/foreground true
#> Using name user/sw/lcdproc/lcdproc/#0/current/lcdproc/foreground
#> Set string to "true"

kdb get /sw/lcdproc/lcdproc/#0/current/lcdproc/foreground
#> Sorry, module type issued the error 52:
#> error in the type plugin: The key user/sw/lcdproc/lcdproc/#0/current/lcdproc/foreground was already normalized by a different plugin! Please ensure that there is only one plugin active that will normalize this key.

kdb get user/sw/lcdproc/lcdproc/#0/current/lcdproc/foreground
#> 1

Untuk konteks, plugin tipe adalah satu-satunya yang dipasang di mountpoint ini yang melakukan normalisasi. Itu juga bukan masalah dengan kdb , karena saya awalnya melihat kesalahan dengan lcdproc itu sendiri. Jadi itu harus menjadi masalah di kdbGet itu sendiri. Untuk beberapa alasan sepertinya type dipanggil dua kali dengan kunci yang sama.

Untuk masalah lain lihat #2806.

Pada titik ini, satu-satunya jalan ke depan yang saya lihat adalah saya membuat versi LCDproc yang cukup dapat digunakan untuk melakukan benchmark untuk tesis saya. Setelah itu saya pikir kita perlu setidaknya menunggu sistem plugin baru (toh diperlukan untuk implementasi server yang tepat tanpa solusi).

kodebach menulis:

Saya tidak memiliki akses ke perangkat armhf , jadi saya tidak dapat mereproduksi ini. Dari sedikit informasi yang diberikan dalam komentar asli, saya menduga bahwa plugin gopts tidak ditemukan.

Saya kira saya setidaknya harus memasukkan BT lengkap untuk segfault.

Bagaimanapun, saya pikir sangat tidak mungkin, bahwa masalahnya khusus untuk armhf.
(Terutama karena kdb berfungsi dengan baik.) Bug kompiler adalah suatu kemungkinan, tetapi
kemungkinan besar, Anda hanya memiliki beberapa perubahan yang tidak dikomit di
copy pekerjaan Anda, yang sebenarnya diperlukan agar segala sesuatunya berfungsi.

Itu asumsi saya. Jika saya bisa melakukan apa saja untuk mengumpulkan informasi,
yang membantu Anda menemukan masalahnya, lalu beri tahu saya.

Anda hanya memiliki beberapa perubahan yang tidak dikomit dalam copy pekerjaan Anda [...] Jika saya dapat melakukan apa saja untuk mengumpulkan informasi, yang membantu Anda menemukan masalahnya, beri tahu saya.

Tidak sepertinya. Anda dapat mencoba lagi dengan kode dari #2805. Saya baru saja mencoba dengan versi itu dan memulai dan menghubungkan klien berhasil.

Anda juga dapat memeriksa output CMake untuk pesan apa pun tentang gopts . Dan periksa apakah [prefix]/lib/elektra/libelektra-gopts.so ada (di mana [prefix] adalah CMAKE_INSTALL_PREFIX Anda, yang defaultnya adalah /usr/local ) setelah menginstal.

Jika Anda mendapatkan sefault lagi, backtrace penuh juga akan membantu.

Terutama karena kdb berfungsi dengan baik.

kdb tidak menggunakan plugin gopts sekarang.

Opsi specValidation agak independen dari dua lainnya. defaultsHandling (DH) dan specLocation (SL) selalu harus dikoordinasikan sampai tingkat tertentu.

Satu alasan lagi untuk tidak mengekspor antarmuka ini ke pengguna.

Kombinasi terakhir specLocation=embed dan defaultsHandling=speconly tidak banyak digunakan.

Alasan lain.

Saya tidak tahu mengapa Anda begitu enggan membuat antarmuka ini lebih mudah digunakan. Jika itu karena Anda sudah menerapkan semuanya, maka Anda cukup mengekspos hanya satu opsi (misalkan spesifikasiStrategy) dan dari opsi ini Anda mendapatkan 3 opsi lainnya.

Setelah menambahkan mode yang berbeda dan beberapa pengujian dan eksperimen minggu ini, saya sekarang dengan tegas berpendapat bahwa ini bukan ide yang baik. Tentu saja umpan baliknya akan menyenangkan,

Umpan balik tidak bagus tapi penting untuk keberhasilan elektrifikasi LCDproc.

tapi saya tidak melihat cara PR ini akan digabungkan dalam waktu dekat (= musim panas ini).

Ini adalah masalah yang sama sekali berbeda yang tidak dikendalikan oleh Anda.

Semakin dekat saya untuk menyelesaikan pekerjaan saya, semakin banyak masalah di bagian lain dari Elektra temukan.

Bagus, tolong buat masalah.

Misalnya hari ini saya menemukan masalah ini.

Harap laporkan masalah ini (meskipun Anda belum dapat mereproduksinya). Untuk LCDproc masalah ini tidak relevan karena kami memutuskan bahwa kami tidak akan peduli dengan validasi. Setiap upaya untuk menyetel boolean ke sesuatu selain "1" atau "0" tidak didukung. Saya tidak berpikir bahwa orang LCDproc akan memiliki masalah dalam memahami "1" atau "0".

Pada titik ini, satu-satunya jalan ke depan yang saya lihat adalah saya membuat versi LCDproc yang cukup dapat digunakan untuk melakukan benchmark untuk tesis saya.

Tidak, satu-satunya cara untuk maju adalah mengurangi ke set yang berfungsi. Kami telah memutuskan untuk mengecualikan validasi dan sebagai langkah selanjutnya kami dapat mengecualikan mmap. Saya harap itu tidak perlu karena kami memiliki seseorang yang aktif mengerjakan mmap. Mari kita lihat di #2806.

Setelah itu saya pikir kita perlu setidaknya menunggu sistem plugin baru (toh diperlukan untuk implementasi server yang tepat tanpa solusi).

Perubahan pada sistem plugin hanya terkait dengan jumlah maksimum plugin. Ini tidak akan secara ajaib memperbaiki bug.

Satu alasan lagi untuk tidak mengekspor antarmuka ini ke pengguna.

Pengguna sebagai pengguna pembuat kode atau pengguna sebagai pengguna aplikasi (misalnya pengguna LCDproc)?

Itu hanya akan diekspor ke yang pertama bukan yang terakhir. Dan tidak mengekspornya ke yang pertama berarti membatasi kasus penggunaan pembuat kode secara tidak perlu.

maka Anda cukup mengekspos hanya satu opsi (misalkan spesifikasiStrategi) dan dari opsi ini Anda mendapatkan 3 opsi lainnya.

Itulah tepatnya yang tidak ingin saya lakukan, karena ini tidak terlalu transparan. Itu juga bukan bukti masa depan. Jika kita menggunakan spesifikasi untuk hal-hal baru, apakah kita menambahkan lebih banyak strategi? Apakah semua strategi lama memiliki perilaku yang sama atau tidak? Dengan opsi terpisah, kami tidak perlu memikirkan semua ini. Sangat jelas apa yang dilakukan 3 opsi. Pengembang harus memutuskan apa yang terbaik untuk kasus penggunaan khusus mereka.

Bagus, tolong buat masalah.

Saya minta maaf tapi itu tidak baik. Ini adalah bencana. Saya sudah membuat cukup banyak masalah untuk diketahui, mereka tidak akan diperbaiki dalam waktu dekat, kecuali saya melakukannya sendiri atau seseorang sudah secara aktif mengerjakan bagian yang rusak.

Setiap upaya untuk menyetel boolean ke sesuatu selain "1" atau "0" tidak didukung.

Itu masalah lain, karena "tidak didukung" sebenarnya berarti "Anda tidak boleh melakukannya, meskipun berhasil" dalam hal ini. Saya tidak bisa mengatakan sekarang bagaimana atau kapan tepatnya, tetapi pasti ada kasus di mana kdb set -N user ... berhasil, bahkan jika plugin type gagal.

Saya tidak berpikir bahwa orang LCDproc akan memiliki masalah dalam memahami "1" atau "0".

Tidak, tetapi mereka pasti tidak akan menyukai versi yang menggunakan kerangka kerja konfigurasi yang sebenarnya tidak dapat melakukan apa yang dapat dilakukan oleh parser tulisan tangan minimalis yang lama. Mereka juga tidak akan menyukai bahwa semua angka (bahkan yang tidak masuk akal dalam desimal seperti ID Vendor USB) harus dalam desimal, karena hexnumber dinonaktifkan karena satu plugin terlalu banyak.

Umpan balik tidak bagus tapi penting untuk keberhasilan elektrifikasi LCDproc.

Tetapi umpan balik tidak membantu untuk masalah di dalam Elektra itu sendiri.

Tidak, satu-satunya cara untuk maju adalah mengurangi ke set yang berfungsi. Kami sudah memutuskan untuk mengecualikan validasi

Diputuskan bahwa validasi tidak diperlukan oleh orang-orang LCDproc.

Tetapi menghapus validasi dan konversi bukanlah ide yang baik. Saya tahu @haraldg mengatakan dia tidak peduli tentang itu. Tetapi (dengan asumsi validasi Elektra benar-benar berfungsi) memiliki spesifikasi sebenarnya sangat menyederhanakan kode yang membaca konfigurasi. Misalnya dengan membatasi rentang bilangan bulat dalam spesifikasi, Anda dapat menghilangkan if s yang memeriksa nilainya setelah membacanya.

Jika kita menyerah pada validasi melalui Elektra, saya harus memasukkan semua kode kembali.

Selain itu poin utama saya adalah: Membuat PR di repo LCDproc dan menggunakan versi yang dapat digabung/digabung dalam tesis saya, berarti melibatkan lebih banyak orang ke dalam diskusi ini. Dan itu berarti lebih banyak penundaan sampai saya memiliki versi yang dapat saya gunakan untuk melakukan benchmark.

Itu hanya akan diekspor ke yang pertama bukan yang terakhir. Dan tidak mengekspornya ke yang pertama berarti membatasi kasus penggunaan pembuat kode secara tidak perlu.

Jelas tidak sia-sia: kami menemukan bahwa banyak (kebanyakan?) kombinasi tidak masuk akal. Sangat diperlukan untuk membatasi konfigurasi seperti itu.

Itulah tepatnya yang tidak ingin saya lakukan, karena ini tidak terlalu transparan.

Sangat transparan jika Anda mendokumentasikan strategi. Dan ini akan dibutuhkan pula.

Itu juga bukan bukti masa depan. Jika kita menggunakan spesifikasi untuk hal-hal baru, apakah kita menambahkan lebih banyak strategi?

Tidak mungkin ada orang yang menginginkan strategi lebih lanjut dalam waktu dekat. Harald pada dasarnya sudah menginginkan semuanya masuk akal. Jauh lebih mungkin, bahwa beberapa strategi akan jarang dibutuhkan dan menyebabkan sakit kepala pemeliharaan.

Apakah semua strategi lama memiliki perilaku yang sama atau tidak? Dengan opsi terpisah, kami tidak perlu memikirkan semua ini. Sangat jelas apa yang dilakukan 3 opsi. Pengembang harus memutuskan apa yang terbaik untuk kasus penggunaan khusus mereka.

Jadi Anda menyarankan: mari kita serahkan tanggung jawab kepada orang lain?

Saya sangat senang dengan dua strategi: yang Anda terapkan hingga sekarang dan satu lagi untuk membuat Harald senang (minimalkan ukuran biner).

Saya tidak senang dengan pemikiran "ohh, kami sangat fleksibel, jadi itu pasti kesalahan pengguna ketika ada sesuatu yang kacau".

Saya minta maaf tapi itu tidak baik. Ini adalah bencana. Saya sudah membuat cukup banyak masalah untuk diketahui, mereka tidak akan diperbaiki dalam waktu dekat, kecuali saya melakukannya sendiri atau seseorang sudah secara aktif mengerjakan bagian yang rusak.

Tentu saja bagus jika Anda menemukannya. Ini akan diperbaiki oleh orang yang mengimplementasikan validasi (tidak ada yang mengerjakan ini sekarang). Validasi tidak ada tujuan sekarang. Anda dapat yakin itu adalah tujuan jangka panjang bagi saya.

Itu masalah lain, karena "tidak didukung" sebenarnya berarti "Anda tidak boleh melakukannya, meskipun berhasil" dalam hal ini.

Tentu saja, itu adalah status quo dari hampir semua aplikasi FLOSS di luar sana. Jika Anda mengacaukan konfigurasi, itu mungkin tidak berfungsi, mungkin macet, mungkin memformat hard drive. Elektra ada untuk mengubah itu tetapi selangkah demi selangkah. Kami setidaknya menjamin bahwa kami tidak crash atau memformat hard drive. Kami dapat memberikan pesan kesalahan yang lebih baik, jadi laporkan bug tersebut.

Tidak, tetapi mereka pasti tidak akan menyukai versi yang menggunakan kerangka kerja konfigurasi yang sebenarnya tidak dapat melakukan apa yang dapat dilakukan oleh parser tulisan tangan minimalis yang lama. Mereka juga tidak akan menyukai bahwa semua angka (bahkan yang tidak masuk akal dalam desimal seperti ID Vendor USB) harus dalam desimal, karena hexnumber dinonaktifkan karena akan menjadi satu plugin terlalu banyak.

Ini adalah pendapat Anda, yang sangat saya hargai. Dan Anda melakukan yang terbaik bahwa semuanya bekerja sangat baik menurut Anda. Tapi kami juga tertarik dengan pendapat orang-orang LCDproc. Saat ini kami tidak menanyakan apa yang sebenarnya mereka butuhkan, yang bukan situasi yang baik.

Tetapi umpan balik tidak membantu untuk masalah di dalam Elektra itu sendiri.

Tentu saja itu membantu: kita akan melihat bahwa Elektra berevolusi. Tetapi tanpa umpan balik, kita mungkin mengalami arah yang salah. Terutama masalah validasi dan transformasi sangat spesifik domain.

Tetapi (dengan asumsi validasi Elektra benar-benar berfungsi) memiliki spesifikasi sebenarnya sangat menyederhanakan kode yang membaca konfigurasi. Misalnya dengan membatasi rentang bilangan bulat dalam spesifikasi, Anda dapat menghilangkan ifs yang memeriksa nilainya setelah membacanya.

Tepat!

Jika kita menyerah pada validasi melalui Elektra, saya harus memasukkan semua kode kembali.

Tidak, kami hanya menganggap semuanya divalidasi untuk saat ini sehingga Anda dapat menyelesaikan tesis Anda. Dalam pekerjaan nanti kami tentu saja akan memperbaiki masalah.

Selain itu poin utama saya adalah: Membuat PR di repo LCDproc dan menggunakan versi yang dapat digabung/digabung dalam tesis saya, berarti melibatkan lebih banyak orang ke dalam diskusi ini.

Oke, ini masalahnya: Jangan khawatir tentang itu. Nilai Anda pada tesis Anda pasti tidak akan tergantung pada apakah orang-orang LCDproc menyukainya atau tidak. Saya suka pekerjaan Anda kecuali ketika saya mengatakan saya tidak suka.

Dan itu berarti lebih banyak penundaan sampai saya memiliki versi yang dapat saya gunakan untuk melakukan benchmark.

Untuk tesis Anda, Anda dapat memilih versi apa pun yang Anda suka. Ini bukan versi terbaru, ini tidak pernah berhasil jadi jangan coba-coba melakukannya. Beberapa otomatisasi untuk benchmarking mungkin berguna, kadang-kadang perlu untuk mengulang semuanya, bahkan tanpa perubahan kode.

kami menemukan bahwa banyak (kebanyakan?) kombinasi tidak masuk akal

1 dari 4 tidak banyak atau kebanyakan.

Sangat diperlukan untuk membatasi konfigurasi seperti itu.

Mengapa? Apa manfaat dari tidak mengizinkan konfigurasi tertentu? Jika seseorang memiliki kasus penggunaan, kami tidak memikirkan mengapa melarangnya?

Jauh lebih mungkin, bahwa beberapa strategi akan jarang dibutuhkan dan menyebabkan sakit kepala pemeliharaan.

Tepatnya mengapa strategi adalah ide yang buruk. Opsi terpisah jauh lebih mudah untuk dipelihara, karena masing-masing opsi tersebut tidak terlalu memengaruhi kode. Itulah prinsip dasar "pemisahan urusan".

dan satu lagi untuk membuat Harald bahagia

Jadi jika X datang dan menginginkan versi kinerja yang dioptimalkan, kami menambahkan strategi lain? Dan jika Y menginginkan versi lain, kami juga menambahkannya?

ohh, kami sangat fleksibel, jadi itu pasti kesalahan pengguna ketika ada sesuatu yang kacau

Tentu saja tidak. Tetapi versi Anda pada dasarnya adalah "jika Anda ingin, kami mengatakan itu berfungsi; jika itu tidak sesuai dengan kasus penggunaan Anda, itu bukan kesalahan kami". Juga saya tidak bisa melihat bagaimana sesuatu bisa kacau di sini sama sekali. Ada prasyarat yang berbeda untuk kombinasi yang berbeda untuk bekerja, tetapi itu masih terjadi jika semuanya dikendalikan oleh satu opsi dan kemungkinannya lebih kecil. Kami sudah mengatakan bahwa tidak ada solusi ajaib yang berhasil.

Mengapa? Apa manfaat dari tidak mengizinkan konfigurasi tertentu? Jika seseorang memiliki kasus penggunaan, kami tidak memikirkan mengapa melarangnya?

https://cseweb.ucsd.edu/~tixu/papers/fse15.pdf

Tepatnya mengapa strategi adalah ide yang buruk. Opsi yang terpisah jauh lebih mudah untuk dipelihara, karena masing-masing opsi tersebut tidak terlalu memengaruhi kode. Itulah prinsip dasar "pemisahan urusan".

https://en.wikipedia.org/wiki/Separation_of_concerns

Petunjuk: istilahnya tentang kode dan bukan (konfigurasi) data.

Jadi jika X datang dan menginginkan versi kinerja yang dioptimalkan, kami menambahkan strategi lain? Dan jika Y menginginkan versi lain, kami juga menambahkannya?

Beginilah cara kerja pengembangan perangkat lunak. Anda menambahkan dukungan untuk kasus penggunaan lain yang awalnya tidak Anda pikirkan jika seseorang membutuhkannya . Maka masuk akal untuk membuatnya dapat dikonfigurasi sehingga untuk orang lain, pengaturan lama mereka masih berfungsi (jadi dalam hal ini: menambahkan strategi lain). Seperti yang Anda ketahui, pengembangan perangkat lunak bukanlah: "biarkan kami menambahkan hal-hal acak jika seseorang mungkin membutuhkannya". Sayangnya, saat ini tidak diketahui secara luas bahwa hal yang sama juga berlaku untuk konfigurasi.

https://cseweb.ucsd.edu/~tixu/papers/fse15.pdf

Makalah ini berbicara tentang aplikasi dengan ratusan opsi. Kita berbicara tentang perbedaan antara memiliki satu parameter dengan 2-3 nilai dan dua parameter dengan masing-masing 2 nilai.

Saya tidak ingin membahas lebih jauh (IMO makalah ini setidaknya mendukung versi saya dan Anda), jadi strategi apa yang Anda usulkan?

Saya pikir kita setidaknya perlu

1. Spec eksternal, default tertanam: memungkinkan memulai tanpa pemasangan
2. Spesifikasi eksternal, default tidak disematkan: meminimalkan ukuran biner

Mungkin juga:

1. Spesifikasi tertanam, default tertanam: memungkinkan memulai tanpa pemasangan, semuanya terkandung dalam satu file -> konflik versi lebih sulit

Dan pada saat itu tidak masalah bahwa ada pengaturan keempat, jika itu membuat dokumentasi lebih mudah dipahami. Pada akhirnya, hal terpenting adalah pengguna pembuat kode memahami opsi.

Mungkin ini hanya saya, tetapi jika setiap opsi hanya mengontrol satu hal (satu untuk spesifikasi, satu untuk default) itu lebih mudah daripada satu opsi mengendalikan keduanya.

istilahnya tentang kode dan bukan (konfigurasi) data.

Ya dan cara kerja pembuat kode adalah tentang kode juga. Ini tidak ada hubungannya dengan konfigurasi atau data.

Beginilah cara kerja pengembangan perangkat lunak. [...]

Ini tentang keseimbangan antara memenuhi kasus penggunaan yang Anda miliki saat ini dan membuat perangkat lunak yang berguna secara umum. Elektra ingin berguna secara umum bukan untuk satu kasus tertentu (misalnya sistem tertanam, atau sistem server). Oleh karena itu kita harus memiliki fleksibilitas sejak awal. Lebih penting lagi, perangkat lunak harus selalu dirancang dengan cara yang terbukti di masa depan. Terlalu banyak batasan dan perubahan di masa mendatang dapat menjadi sangat sulit (misalnya batasan Elektra pada jumlah plugin, begitu mendarah daging dalam Elektra sehingga sulit untuk diubah sekarang).

Makalah ini berbicara tentang aplikasi dengan ratusan opsi.

Total Elektra memiliki ratusan pilihan.

jadi apa strategi yang Anda usulkan?

Saya setuju dengan semua strategi:

• bahwa kami memiliki kasus penggunaan yang baik untuk
• sedang diuji
• didokumentasikan

Pada akhirnya, hal terpenting adalah pengguna pembuat kode memahami opsi.

Ini bukan satu-satunya poin, lihat di atas. Misalnya lihat spec, daftar atau csvstorage. Mereka hanya memiliki opsi yang dapat dimengerti tetapi tetap saja mereka hampir tidak dapat digunakan karena sangat mudah untuk membuat opsi ini salah karena sebagian besar opsi biasanya tidak diperlukan dan bergantung satu sama lain dengan cara yang mengejutkan.

Batas Elektra pada jumlah plugin, begitu mendarah daging di Elektra yang sulit diubah sekarang

Ya, salah membatasi jumlah plugin.

Ya, mengaktifkan gopts di cmake dan mengkompilasi ulang libelektra memperbaiki segfault. Terima kasih atas bantuan Anda. Tidak akan mengetahuinya sendiri dengan mudah.

Tetapi menghapus validasi dan konversi bukanlah ide yang baik. Saya tahu @haraldg mengatakan dia tidak peduli tentang itu. Tetapi (dengan asumsi validasi Elektra benar-benar berfungsi) memiliki spesifikasi sebenarnya sangat menyederhanakan kode yang membaca konfigurasi. Misalnya dengan membatasi rentang bilangan bulat dalam spesifikasi, Anda dapat menghilangkan ifs yang memeriksa nilainya setelah membacanya.

Ya, jumlah baris yang dihapus dari LCDproc adalah salah satu tolok ukur yang kami putuskan. Namun saat ini LCDproc sangat tidak konsisten dengan cara memeriksa atau gagal ketika ada kesalahan konfigurasi. Kami tidak terlalu memikirkannya, ergo itu tidak penting.

Jika kita menyerah pada validasi melalui Elektra, saya harus memasukkan semua kode kembali.

Tidak, tolong jangan. Seperti yang dikatakan Markus: Anggap saja libelektra akan diperbaiki pada waktunya. Saya tidak dapat menggabungkan apa pun sebelum itu terjadi.

Selain itu poin utama saya adalah: Membuat PR di repo LCDproc dan menggunakan versi yang dapat digabung/digabung dalam tesis saya, berarti melibatkan lebih banyak orang ke dalam diskusi ini.

Saya ragu orang akan menambahkan banyak diskusi kecuali mereka memiliki pendapat yang sangat kuat tentang sesuatu. OTOH Saya percaya ini akan banyak membantu untuk penerimaan elektra pada akhirnya, jika orang merasa sedikit terlibat. Dan mendapatkan umpan balik semacam "ini tidak akan pernah berhasil untuk kasus penggunaan saya" adalah sesuatu yang sangat ingin kami dapatkan lebih awal, jika ada.

Namun jika Anda merasa keadaan saat ini terlalu memalukan untuk ditunjukkan kepada publik, maka ini adalah panggilan Anda. Saya menghargai itu. Tapi saya masih berharap bahwa masalah dengan jumlah plugin dll sebagian besar mempengaruhi LCDd dan kami dapat menunjukkan setidaknya beberapa klien yang bekerja dengan baik segera.

Itu tidak perlu PR penuh dan bahkan tidak perlu di repo LCDproc (meskipun mengapa tidak?). Tetapi memiliki beberapa cabang libelektra dan beberapa cabang garpu LCDproc Anda, yang dikonfirmasi bekerja bersama dan tidak akan diubah selama pekerjaan pengembangan Anda yang sedang berlangsung, akan banyak membantu pihak yang berkepentingan.

Dan itu berarti lebih banyak penundaan sampai saya memiliki versi yang dapat saya gunakan untuk melakukan benchmark.

Karena penasaran: Apa tolok ukur yang ingin Anda lakukan?

Tentang seluruh diskusi "cara untuk menyajikan opsi pembuat kode kepada pengguna" ini: Saya pikir ini adalah masalah UI yang sangat kecil, yang sebenarnya tidak penting. Apa pun yang Anda putuskan akan jauh lebih tidak mengganggu bagi pengembang biasa, kemudian hal-hal lain seperti Elektra menciptakan tipe datanya sendiri misalnya.

Secara pribadi saya akan memperlakukan ini seperti gcc memperlakukan opsi pengoptimalan: Semua dunia tahu bahwa mereka dapat memilih antara Og, Os, O2 dan O3, tetapi semua pengoptimalan masih didokumentasikan secara individual dan dapat dipilih pada baris perintah jika Anda benar-benar ingin . Ini tampaknya merupakan kompromi yang baik antara kegunaan, spesifikasi perilaku yang tepat, dan stabilitas antarmuka - tidak ada yang mengharapkan semua fitur pengoptimalan tetap stabil di antara rilis gcc, tetapi tentu saja seluruh dunia bergantung pada arti Os dan seterusnya tetap sama.

Jadi mungkin memang harus ada semua opsi teknis, yang diinginkan @kodebach , tetapi juga opsi stategy seperti @markus2330 percaya lebih dapat digunakan dan sebenarnya akan menjadi antarmuka yang stabil.

Ya, mengaktifkan gopts di cmake dan mengkompilasi ulang libelektra memperbaiki segfault. Terima kasih atas bantuan Anda. Tidak akan mengetahuinya sendiri dengan mudah.

Bagus bahwa ini sudah diperbaiki. Apakah Anda entah bagaimana dikompilasi dalam keadaan tidak bersih atau apakah ini sesuatu yang perlu kami perbaiki? Bagaimanapun, itu harus segfault tetapi melaporkan bahwa beberapa perpustakaan tidak hilang, bukan?

Saya ragu orang akan menambahkan banyak diskusi kecuali mereka memiliki pendapat yang sangat kuat tentang sesuatu.

Tepat. Dan format konfigurasi sering kali adalah sesuatu, orang memiliki pendapat yang sangat kuat tentang.

OTOH Saya percaya ini akan banyak membantu untuk penerimaan elektra pada akhirnya, jika orang merasa sedikit terlibat.

Aku pikir juga begitu. Ini juga sangat jelas dari email sebelumnya tentang Elektra ke milis.

Tentang seluruh diskusi "cara untuk menyajikan opsi pembuat kode kepada pengguna" ini: Saya pikir ini adalah masalah UI yang sangat kecil, yang sebenarnya tidak penting.

Tentu saja setiap opsi yang tidak perlu tidak penting, tetapi begitu Anda memiliki ratusan, itu menjadi masalah besar.

Apa pun yang Anda putuskan akan jauh lebih tidak mengganggu bagi pengembang biasa, kemudian hal-hal lain seperti Elektra menciptakan tipe datanya sendiri misalnya.

Dari sudut pandang teori tipe, Elektra tidak menemukan tipe baru. (Dalam C struct membuat tipe baru tetapi typedef hanya alias untuk tipe yang ada). Secara praktis, typedefs bisa mengganggu. Jika Anda mau, kami dapat mengganti nama semua tipe di LCDproc menjadi tipe C99. (Mungkin di tahap selanjutnya.) Seperti pada platform C99, kami berharap selalu memilih tipe C99 (jika tidak berarti bug).

Ini tampaknya kompromi yang baik antara kegunaan

Jika Anda memerlukan opsi tingkat rendah untuk bermain-main dengan pengoptimalan, tentu saja kami dapat menawarkannya. Tetapi peringatan besar: seperti yang saya pahami, mereka tidak hanya menyesuaikan kinerja tetapi juga mengorbankan kebenaran atau memperkenalkan perilaku yang berbeda, sesuatu yang tidak dilakukan oleh sebagian besar opsi pengoptimalan gcc.

markus2330 menulis:

Bagus bahwa ini sudah diperbaiki. Apakah Anda entah bagaimana dikompilasi dalam keadaan tidak bersih atau apakah ini sesuatu yang perlu kami perbaiki?

Saya mengkompilasi elektra dari git clone baru beberapa jam sebelum @kodebach
menulis instruksinya. Jadi alih-alih menyalin baris perintahnya, saya hanya
melakukan cmake pesawat ...; membuat; membuat urutan instalasi.

Tampaknya gopts belum dibangun secara default. Apakah ini disengaja atau
kesalahan terserah Anda.

Secara praktis, typedefs bisa mengganggu.

Mereka membuat kode lebih sulit dibaca untuk pengguna biasa elektra.

Jika Anda mau, kami dapat mengganti nama semua tipe di LCDproc menjadi tipe C99.

Ya, saya lebih suka bahwa typedef non-standar bocor ke kode LCDproc sedikit
mungkin.

Dalam kasus khusus ini kapal mungkin sudah berlayar, tapi aku
percaya menggunakan tipe non-standar di Elektra API adalah pilihan yang buruk
juga: Itu hanya membingungkan orang.

Jika Anda memerlukan opsi tingkat rendah untuk bermain-main dengan pengoptimalan, tentu saja kami dapat menawarkannya. Tetapi peringatan besar: seperti yang saya pahami, mereka tidak hanya menyesuaikan kinerja tetapi juga mengorbankan kebenaran atau memperkenalkan perilaku yang berbeda, sesuatu yang tidak dilakukan oleh sebagian besar opsi pengoptimalan gcc.

Saya tentu saja tidak membutuhkannya, tetapi saya mungkin menganggapnya menyenangkan untuk dimainkan.
Namun poin utama saya adalah: Poin yang diangkat oleh Anda dan @kodebach keduanya
memiliki kelebihannya, jadi mungkin masuk akal untuk mengikuti keduanya: Anda mendapatkan
antarmuka yang stabil dan @kodebach mendapatkan opsinya dengan jelas
perilaku.

Ya, opsi pembuat kode itu akan menghasilkan perilaku yang berbeda (di
setidaknya di jalur kesalahan) jelas. opsi gcc hanyalah analog, bukan
sepenuhnya setara.

Tampaknya gopts belum dibangun secara default. Apakah ini disengaja atau kesalahan terserah Anda.

Ini akan disertakan secara default setelah tidak eksperimental lagi.

Mereka membuat kode lebih sulit dibaca untuk pengguna biasa elektra.

Ya saya setuju. Apakah boleh jika Anda memiliki sesuatu seperti int32_t x = elektraGetLong(... .

menggunakan tipe non-standar di Elektra API juga merupakan pilihan yang buruk: Itu hanya membingungkan orang.

Di API tingkat rendah kami tidak memiliki masalah ini, karena pengguna API perlu melakukan konversi.

Di API pemberitahuan internal, kami sebenarnya memiliki: tipe C dan API untuk typedefs kami.

Jika kita beralih ke tipe C99, kita harus melakukan ini secara konsisten baik di internal-notification maupun highlevel. Akan cukup sulit tetapi itu bisa dilakukan tanpa merusak kompatibilitas (karena typedefs adalah nama yang berbeda untuk hal yang sama dan karena itu mereka harus kompatibel).

Pertanyaan lain adalah apakah API tingkat tinggi (dan pemberitahuan internal) hanya C atau juga untuk bahasa lain. Iirc @kodebach juga memikirkan bahwa API tingkat tinggi harus mudah untuk menulis binding.

Tidak apa-apa bagi Anda untuk memiliki sesuatu seperti int32_t x = elektraGetLong(... .

Tentu. Selama jelas pada pandangan pertama apa yang terjadi, tidak apa-apa.

Apakah boleh jika Anda memiliki sesuatu seperti int32_t x = elektraGetLong(... .

Tentu. Selama jelas pada pandangan pertama apa yang terjadi, tidak apa-apa.

Beralih dari tipe kdb_*_t ke tipe C99 seharusnya hanya berupa serangkaian penggantian regex.

Jika kita beralih ke tipe C99, kita harus melakukan ini secara konsisten baik di internal-notification maupun highlevel. [...]

Di bawah C99+ perubahannya seharusnya cukup sederhana, tetapi setidaknya sebagian dari Elektra berfungsi tanpa C99 penuh juga. Itulah mengapa kdbtypes.h sangat rumit sejak awal.

Jika kita membutuhkan C99+ untuk semua Elektra, kita juga harus beralih menggunakan IMO tipe C99.

Pertanyaan lain adalah apakah API tingkat tinggi (dan pemberitahuan internal) hanya C atau juga untuk bahasa lain. Iirc @kodebach juga memikirkan bahwa API tingkat tinggi harus mudah untuk menulis binding.

Binding tidak benar-benar berperan di sini. Bahasa lain memiliki jenis yang berbeda pula. Jika ada ikatan akan menjadi poin yang mendukung penggunaan tipe C99, karena itu mungkin secara otomatis dipetakan ke tipe bahasa standar.

Itulah mengapa kdbtypes.h sangat rumit sejak awal.

Ya.

@kodebach Apakah Anda mencoba jika itu benar-benar berfungsi? (Dengan kompiler yang tidak memiliki pemahaman tentang C99 seperti VisualC++?)

Jika tidak berhasil, kita harus menyingkirkan semua komplikasi di sana dan cukup menggunakan (hanya) tipe C99.

Di bawah C99+ perubahannya seharusnya cukup sederhana, tetapi setidaknya sebagian dari Elektra berfungsi tanpa C99 penuh juga.

Ya, kompilasi Elektra membutuhkan C99 untuk waktu yang lama tetapi Perangkat Lunak kompilasi menggunakan Elektra (saat ini) mungkin masih berfungsi dengan pra-C99 (jika semua #ifs benar-benar berfungsi untuk sistem Anda).

Dari sudut pandang komunikasi, kita pasti harus mulai mengatakan "panjang" adalah bilangan bulat 32 bit yang ditandatangani dan berhenti menunjuk ke standar CORBA (itu hanya membuat orang takut).

Setidaknya secara internal, "src/include/kdbtypes.h" tetap masuk akal (untuk memeriksa ketersediaan dan untuk menentukan penentu printf). Tetapi saya melihat bahwa aplikasi tidak ingin menggunakan file ini.

Omong-omong. Kami sudah memiliki masalah terbuka tentang penyatuan sistem tipe: #1092

Terima kasih atas diskusinya, silakan buka masalah baru untuk diskusi lebih lanjut.