Pegjs: Tambahkan dukungan untuk parser tambahan

Saya berasumsi Anda menginginkan dukungan untuk penguraian dari indeks selain 0, ya?

Sebenarnya tidak, hanya dukungan untuk memodifikasi lokasi yang dilaporkan di objek location().

Parser yang saya tulis, mem-parsing sepotong data sekaligus (yaitu node stream) dan mem-parsing sebanyak mungkin.

jadi diberikan dokumen berikut

<akar>
<anak> teks</anak>
</root>

dan misalkan itu datang dalam dua bagian

1:
<akar>
<anak> te

2:
xt</anak>
</root>

selama penguraian pertama itu akan diuraikan

<akar>
dan
<anak>
dan itu akan membuang "te"

tetapi penguraian berikutnya akan diuraikan
"teks"
</anak>
</root>

Selama penguraian kedua saya ingin itu mencerminkan lokasi di dokumen asli bukan potongan yang telah disajikan.

Maaf, hanya mencoba memahami apa yang Anda inginkan di sini

Pada dasarnya Anda ingin data lokasi mencerminkan apa yang diteruskan melalui opsi daripada dari indeks awal yang digunakan oleh fungsi parser internal? Bukankah ini akan mengembalikan data lokasi yang salah untuk apa yang diuraikan dalam penguraian pertama (yaitu "te" dari "teks")?

Karena Anda mem-parsing potongan data sekaligus, bukankah lebih optimal untuk mengembalikan rentang:

function range() {

    return [ peg$savedPos, peg$currPos ];
    /* or */
    //return { start: peg$savedPos, end: peg$currPos };

}

Pengurai tidak pernah memiliki akses ke seluruh dokumen sekaligus, hanya satu potongan pada satu waktu, karena tidak memiliki akses ke seluruh dokumen, fungsi location() sebagaimana adanya tidak memberikan informasi yang sangat relevan.

dalam contoh sebelumnya potongan pertama, akan memiliki info lokasi yang benar, potongan kedua akan sangat salah. string "te" akan ditambahkan ke potongan kedua dan akan dikenali sebagai "teks" string penuh. Tanpa perubahan pada fungsi lokasi, awal string "teks" akan dikenali sebagai offset 0, baris 1, kolom 1, alih-alih nilai offset 13 yang benar, baris 2 kolom 8

Ini juga akan berguna jika Anda hanya ingin mengurai bagian dari dokumen.

dalam contoh sebelumnya potongan pertama, akan memiliki info lokasi yang benar, potongan kedua akan sangat salah. string "te" akan ditambahkan ke potongan kedua dan akan dikenali sebagai "teks" string penuh. Tanpa perubahan pada fungsi lokasi, awal string "teks" akan dikenali sebagai offset 0, baris 1, kolom 1, alih-alih nilai offset 13 yang benar, baris 2 kolom 8

Seperti yang saya tanyakan di atas, pada dasarnya Anda ingin data lokasi mencerminkan apa yang diteruskan melalui opsi daripada dari indeks awal yang digunakan oleh fungsi parser internal, yang seperti yang Anda tunjukkan di atas, dapat dicapai dengan menimpa _peg$posDetailsCache_ dan _peg$computeLocation_.

Saat ini pengurai yang dihasilkan oleh PEG.js tidak mempertahankan statusnya di antara sesi penguraian yang berbeda, jadi tidak ada cara untuk melakukan apa yang Anda inginkan secara otomatis, jadi timpa _peg$posDetailsCache_ dan _peg$computeLocation_ secara manual adalah satu-satunya cara.

Ini juga akan berguna jika Anda hanya ingin mengurai bagian dari dokumen.

Ini bisa menjadi masalah yang berbeda tergantung pada input sumber yang diberikan ke parser yang dihasilkan:

1) Jika menggunakan aliran, metode yang Anda gunakan saat ini adalah yang terbaik
2) Jika mem-parsing seluruh dokumen, maka secara manual mengatur nilai untuk _peg$savedPos_ dan _peg$currPos_ mungkin berhasil, tetapi sejujurnya saya belum pernah mencoba ini, meskipun telah mempertimbangkan apakah akan menerapkan ini sebagai fitur atau tidak .

Telah memutuskan untuk mengimplementasikan ini sebelum v1, tetapi perlu memikirkan arah yang konkret untuk diambil berdasarkan permintaan OP dan posting saya di atas.

Ini pada dasarnya tidak mungkin. Sayangnya pengelola saat ini sedang meneliti janji-janji yang mustahil alih-alih memperbaiki hal-hal mudah yang sebenarnya dibutuhkan pengguna.

Cara kerja parser packrat adalah parsing yang setara dengan A* - ia men-cache upaya pencocokan yang lama. Alasan mengapa ia dapat mencocokkan dengan sangat bebas adalah karena ia memiliki semua batang ke depan, yang sebelum caching tampak kinerjanya tidak realistis. Itu juga mengapa begitu cepat.

Masalahnya adalah, untuk melakukan penguraian tambahan, Anda memerlukan salinan cache lama, yang biasanya berukuran ribuan hingga ratusan ribu kali ukuran dokumen, atau menyimpan bagian depan dokumen lama dan hanya menguraikannya kembali.

Masalah ini harus ditutup karena tidak mungkin. Ini bukan cara kerja packrat. (Juga, mereka cukup cepat sehingga saya tidak dapat memikirkan alasan mengapa ini diperlukan atau diinginkan. Saya biasanya dapat mengurai ~ 10 mc dokumen di bawah satu bingkai layar.)

Kemungkinan besar lebih cepat untuk mengurai ulang dari awal daripada memuat batang lama dari disk

Cukup lacak lokasi Anda di parse pertama dan cari kembali di parse kedua, dengan XPath yang unik. XML tidak memiliki penghapusan. Dijamin posisi stream yang kamu tuju masih ada.

Ada sesuatu yang disebut pengurai paket tambahan, dan bahkan ada implementasi javascript yang tersedia secara terbuka oleh orang-orang Ohm

Tetapi jika Anda masuk ke seluk beluk dan melihat, Anda akan menyadari bahwa mereka terkait seperti hashmap dan vektor (karena array jarang dan array padat, dan satu-satunya hal yang benar-benar mereka bagikan adalah kata-kata dalam judul)

Masalah ini harus ditutup karena tidak mungkin.

Saya tidak berpikir begitu. Ya, ada tata bahasa yang penguraian inkrementalnya tidak memberikan apa-apa, tetapi ada juga yang bisa dilakukan. Masalahnya adalah membagi kelas-kelas ini dan melaporkannya pada tahap kompilasi agar tidak menghasilkan kode yang tidak berfungsi

Anda tahu perangkat lunak ini lebih baik daripada saya, dan saya bisa saja salah, dan jika Anda yakin saya akan tutup mulut, tapi

Apakah Anda benar-benar percaya bahwa peg.js dapat dibuat secara praktis untuk melakukan ini tanpa perbaikan yang serius?

Seperti, pendekatan orang ohm membutuhkan semacam memoisasi malas yang tidak ada di peg sama sekali sejauh yang saya tahu, dan saya tidak melihat cara memasukkannya (mungkin saya saya ketinggalan perahu; itu kadang terjadi)

Apakah Anda benar-benar percaya bahwa peg.js dapat dibuat secara praktis untuk melakukan ini tanpa perbaikan yang serius?

Saya memiliki beberapa ide di masa lalu, tetapi karena proyek sudah mati, saya tidak pernah mengimplementasikannya... Ini hanya sebuah tantangan, tetapi pada titik ini saya tidak memerlukan fungsionalitas itu, tetapi untuk melakukan sesuatu yang tidak dibutuhkan siapa pun -- membosankan

Proyek ini tidak mati. Ini memiliki 200.000 unduhan seminggu.

Itu hanya membutuhkan pemelihara yang peduli. Saya ingin menghidupkan kembali ini dan mulai memperbaiki masalah. Saya hanya akan membahas worklog yang ada, cherry pick, menambahkan tes, dan merilis.

Saya memperbaiki tata bahasa pasak saya dengan skrip bash.

Tidak ada alasan proyek ini harus mati. Ini adalah parser JS terbaik di luar sana.

Saya mengerti. Mungkin pilihan terbaik untuk membuat garpu dan mengembangkannya sesuai dengan kebutuhan Anda

Saya melakukan itu tiga tahun lalu.

Tidak, saya tidak akan memotong perpustakaan untuk mengambilnya dari pengelolanya saat ini, dan menghidupkannya kembali. Itu bukan garpu, atau cara kerjanya.

Tujuan eksplisit saya adalah untuk menghapus tim yang menghabiskan tiga tahun menghasilkan 0.11.0 lalu membuangnya dan berkata "kami akan menulis perpustakaan baru dari awal, dan Anda tidak dapat berkontribusi atau melihat yang baru , dan sekarang ini adalah proyek hobi pribadi saya."

Seperti yang saya pahami, tim itu adalah ryuu.

Ini adalah perpustakaan yang sangat penting yang banyak digunakan oleh banyak paket di seluruh sistem. Saatnya seseorang mengembalikannya ke status sehat.

Forking itu tidak akan mencapai tujuan itu.

Tujuan saya adalah melakukan fork 0.10.0 dan mulai mem-porting kembali 0.11.0 bergabung menjadi 0.12.0 , tetapi meningkatkan pengujian saat saya melanjutkan, dan benar- benar merilis perpustakaan

Ada enam masalah berbeda dalam repo ini yang mengatakan "Saya sudah menyerah pada pasak karena belum dirilis selama bertahun-tahun," atau "karena belum dirilis sejak David pergi."

Tidak ada yang peduli dengan garpu saya. Jika saya memotongnya, tidak ada yang akan diselamatkan.

Aku akan menyelamatkan yang asli sekarang, jika David mengizinkanku.

Saya minta maaf karena Anda ingin saya membiarkan yang asli mati, tetapi saya tidak mau melakukannya. Saya juga tidak tahu mengapa Anda menginginkan itu. PR Anda sekarat dengan 0.11.0 . Saya akan mempertahankan mereka.

Bagaimanapun, saya tidak meminta nasihat. Saya sudah memberi tahu David apa yang saya inginkan, dan saya masih menginginkannya bahkan jika Anda ingin saya menarik Ryuu, dan memulai dari awal dalam repo berbeda yang tidak dapat dilihat atau dipedulikan oleh siapa pun, dan terus membiarkan pengguna terdampar.

Tujuan saya bukan untuk menyelamatkan diri. Tujuan saya adalah untuk menyelamatkan perpustakaan.

Sudah waktunya bagi pengembang saat ini untuk membiarkan seseorang dengan pengalaman perpustakaan masuk dan membuat proses pengembangan dan rilis yang sehat, dan menyimpan perpustakaan.

Pendapat Anda tentang keinginan saya dicatat.

Saya masih ingin David membiarkan saya membatalkan tiga tahun kerusakan yang telah dilakukan sejak dia pergi, oleh kelompok yang menerima tanggung jawab pemeliharaan, kemudian tidak pernah benar-benar melakukannya.

Pengelola saat ini benar-benar tidak pernah memelihara perpustakaan satu kali pun , dan setiap janji yang dia buat kepada David pada tahun 2017 untuk memperoleh repo ini salah.

Saatnya melepaskan di 2018

Saya ingin David membiarkan saya memperbaiki ini. Peg adalah pengurai terbaik di sekitar

Pengembangnya sendiri ( Anda ) mengatakan "Saya menyerah pada proyek ini, sudah mati"

Mengapa Anda juga ingin saya tidak menyimpannya dan bekerja di garpu pribadi saya sendiri, ketika semua pengembang telah menyerah pada proyek sebagai proyek mati, di luar jangkauan saya

Maaf Anda telah menyerah pada peg.js

Aku belum.

Saya akan mempertahankan mereka.

Saya baru saja meninggalkan mereka di garpu saya. Mereka tidak mati sepenuhnya, Anda masih bisa membangkitkan mereka. Aku hanya tidak tertarik melakukan itu.

Tidak ada yang peduli dengan garpu saya. Jika saya memotongnya, tidak ada yang akan diselamatkan.

Saya telah menyesuaikan penerapan rentang selama 5 tahun untuk semua persyaratan pemformatan yang berubah, menambahkan 3 fitur baru selama pengembangan PR awal (pembatas, batas variabel, batas fungsi), tetapi hal itu bahkan tidak terlihat oleh siapa pun di komunitas. Ini menunjukkan bahwa sebenarnya tidak ada komunitas. Padahal, di luar muka saya dikatakan bahwa saya bukan komunitas dan pendapat saya tidak penting, meskipun tidak ada yang lain.

Jadi saya pikir "komunitas" akan cukup mahal tanpa pengorbanan Anda :(

Tujuan saya bukan untuk menyelamatkan diri. Tujuan saya adalah untuk menyelamatkan perpustakaan.

Hanya garpu, IMHO. Sedih, tapi benar. Mungkin contoh io.js akan mengajarkan sesuatu.

bekerja di garpu pribadi saya sendiri

Mengapa pribadi? Buat garpu publik, lakukan hal-hal baik dan komunitas (jika ada) akan menemukan Anda

Mengapa pribadi? Buat garpu publik

Saya di sini untuk menyelamatkan perpustakaan, bukan membuat yang baru.

Tolong berhenti meminta saya untuk ini sekarang. Saya sudah jelas bahwa jawabannya adalah tidak.

.

Saya telah menyesuaikan implementasi rentang selama 5 tahun

Aku tahu. Jika saya menjadi pengelola, rentang akan masuk menggunakan kode Anda pada tahun 2020.

Masalah-masalah ini berasal dari kurangnya pengelola. Forking tidak akan memperbaikinya; itu akan membuat mereka lebih buruk.

.

Ini menunjukkan bahwa sebenarnya tidak ada komunitas.

Dulu ada. Bisa ada lagi.

Saya mulai mengajukan tiket kurang dari 24 jam yang lalu dan saya sudah melakukan percakapan dengan sembilan orang.

Berhenti menjadi fatalis. Ini mudah diperbaiki. Semua yang perlu terjadi adalah kunci harus diletakkan di tangan seorang pengelola berpengalaman yang memiliki fokus pada rilis.

.

Jadi saya pikir "komunitas" akan cukup mahal tanpa pengorbanan Anda :(

Saya tidak membuat pengorbanan di sini.

.

itu bahkan tidak terlihat oleh siapa pun di komunitas

Saya melihatnya untuk pertama kalinya kemarin malam, ketika saya mulai membaca pelacak masalah. (Saya akan membaca semuanya, terbuka dan tertutup.)

Saya juga melihat #209.

Saya bersimpati pada kedua posisi di sini.

Di satu sisi, ini adalah fitur yang benar-benar harus digunakan, yang diinginkan banyak orang, yang didukung oleh perpustakaan lain, dan bahwa alat yang mendasarinya siap untuk didukung.

Di sisi lain, percakapan itu sebenarnya belum selesai.

Jika saya diizinkan menjadi pengelola, inilah yang akan saya lakukan:

1. Saya akan membuat tiket baru dan menandai semua orang yang saya pikir pernah terlibat di masa lalu. Saya juga akan meminta mereka untuk menandai siapa pun yang mereka tahu saya lewatkan.
2. Saya akan mengatakan "hei, bisakah kita membicarakan ini dan membuat keputusan? Saya biasanya menyukai kode Mingun, dan saya ingin mengetahui apakah kita dapat menggabungkannya, atau sedikit memodifikasinya untuk membuatnya dapat digabungkan."
3. Jika diskusinya tidak singkat dan padat, katakanlah tiga atau empat hari, saya akan mengatakan "oke, perpustakaan ini mencoba mengarah ke kemajuan baru, jadi saya ingin menyetel pengatur waktu satu minggu mulai hari ini," dan kembali tag semua orang
4. Saya juga akan memiliki standar pengujian yang cukup tinggi
5. Kemudian, dalam bahasa sehari-hari, saatnya untuk bergabung. Ini adalah fitur yang bagus dan, dengan lebih banyak pengujian, ini juga merupakan implementasi yang baik.
   
   
   
   1. Saya ingin komunitas dapat mendiskusikan karakter mana yang terbaik untuk sigil, tetapi lima tahun adalah omong kosong, dan inilah saatnya untuk menarik pelatuknya.
   
   

.

Tujuanku

MENURUT OPINI SAYA.

Hai, Anda telah mendorong pendapat itu empat kali sekarang, dan saya selalu mengatakan tidak.

Berhentilah memberi tahu saya pendapat Anda tentang tujuan saya. Tujuan saya tidak berubah.

.

Mengapa pribadi?

Karena saya melakukannya tiga tahun lalu, ketika ini masih perpustakaan yang sehat, dan perubahan yang saya lakukan adalah hal-hal yang tidak boleh dilakukan oleh @dmajda .

Jadi saya pikir saya akan memperbaikinya secara lokal, dan ketika komunitas memperbaikinya dengan benar, saya akan mengubah tata bahasa saya.

Tiga tahun kemudian, para pengembang telah menyerah pada proyek ini sebagai mati, tetapi juga berusaha sekuat tenaga untuk membuat saya tidak memperbaikinya bahkan setelah saya dengan jelas menyuruh mereka untuk berhenti, yang membingungkan dan tidak pantas .

Jika Anda membuat komentar lagi tentang kebutuhan saya untuk membuat garpu, saya akan berhenti merespons. Saya tidak tertarik dengan harapan Anda untuk membuat peg.js mati.

Jawabannya adalah tidak sulit. Jika Anda ingin peg 0.10.0 , sematkan paket Anda. peg 0.12.0 perlu terjadi, dan saya tidak begitu mengerti atau peduli mengapa Anda ingin menghalangi itu.

Semua yang Anda gabungkan menjadi 0.11.0 hilang sekarang. Ryuu bilang semuanya dibuang. Jika Anda pikir Anda akan mempertahankan pekerjaan gabungan Anda, pahami bahwa pemeliharaan saya akan menyelesaikannya, dan Ryuu telah secara eksplisit menyatakan bahwa dia memulai kembali dari basis kode khusus dari awal.

Ryuu juga telah memulai tiga kompiler PEG lainnya sejak dia mengambil alih pemeliharaan

Perpustakaan ini hanya mati karena

1. Pengelola baru tidak akan memelihara, dan
2. Pengembang baru tidak marah

Hai, saya salah satu pengembang lama, dan saya marah

Jika Anda tidak bersedia membantu menyelamatkan perpustakaan ini, setidaknya berhentilah memberi tahu saya untuk tidak .

Perpustakaan ini perlu dipelihara. Ini adalah bagian penting dari infrastruktur. Garpu bukanlah perawatan. Garpu tidak menyelesaikan masalah apa pun.

.

Mungkin contoh io.js akan mengajarkan sesuatu.

io.js gagal, meskipun ada persetujuan dari pencipta bahasa asli dan kelima dari lima kontributor terbesarnya, dan ketika mereka membuangnya, satu-satunya alasan mereka berpura-pura itu bukan kerugian total adalah untuk dapat untuk mempekerjakan kembali dua dari lima orang itu

Ya, io.js memang mengajari saya sesuatu. Yaitu, "garpu tidak berfungsi, dan masalah tidak ada yang diperbaiki sampai simpul diperbarui nanti."

Saya tidak mencoba untuk mencegah Anda. Jika Anda melakukannya, saya hanya akan senang dan bahkan mungkin menyelesaikan beberapa eksperimen saya dan membawanya ke keadaan yang dapat digabungkan. Hanya melihat di masa lalu, entah bagaimana aku tidak percaya.

Kekritisan sangat dilebih-lebihkan. Jika seperti yang Anda katakan, seseorang pasti sudah membuat garpu dan mengembangkannya. Atau perpustakaan ini dikembangkan daripada dibekukan dalam pengembangan selama 5 tahun.

Jika Anda melakukannya, saya hanya akan senang dan bahkan mungkin menyelesaikan beberapa eksperimen saya dan membawanya ke keadaan yang dapat digabungkan.

Itu akan fantastis. Banyak PR Anda tampak sangat kuat bagi saya, dan dengan beberapa pengujian tambahan, bagi saya sepertinya mereka harus digabungkan

.

Kekritisan sangat dilebih-lebihkan. Jika seperti yang Anda katakan, seseorang pasti sudah membuat garpu dan mengembangkannya.

Pengelola saat ini sendiri telah membuat tiga atau empat garpu berbeda (pegx, epeg, meg; bisa dibilang pegjs-dev, karena ia melakukannya sendiri sebelum menjadi pengelola) serta garpu openpeg. Pada titik ini saya berpendapat bahwa 0.11.0 juga merupakan garpu, karena dia menyatakan itu tidak pernah digabungkan.

Dalam 48 jam terakhir saya, saya telah berbicara dengan sekitar sepuluh orang di sini. Setengah dari mereka memiliki garpu.

polkovnikov-ph memiliki seluruh pasak meta yang menempatkan pasak ke pasak lain.

Saya sendiri memiliki dua garpu, satu yang tidak muncul dalam daftar garpu - yang berlawanan yang telah saya pertahankan selama bertahun-tahun, dan yang baru saya buat beberapa hari yang lalu, sebelum saya mengetahui bahwa 0.11.0 sudah mati, di upaya untuk menerapkan perbaikan untuk densifikasi #638, modul es6 #627, dan modul TypeScript #597 .

Dua teman saya yang sejauh yang saya tahu belum pernah dalam pelacak masalah ini memiliki garpu

Bahwa orang-orang terus mengerjakan 0.11.0 selama tiga tahun meskipun tidak ada rilisan yang memberi tahu saya semua yang perlu saya ketahui tentang betapa pentingnya hal ini.

.

Atau perpustakaan ini dikembangkan daripada dibekukan dalam pengembangan selama 5 tahun.

Library ini sebenarnya aktif dikembangkan hingga Mei 2017, saat terjadi pergantian pengelola.

Hari itu adalah hari di mana perpustakaan membeku.

Itu sebabnya saya percaya perubahan pengelola baru dapat membatalkannya.

Ini adalah gambar yang lebih relevan.

Library ini sebenarnya aktif dikembangkan hingga Mei 2017

Saya akan mengatakan bahwa sampai saat itu ada pengocokan kode, tetapi tidak ada fitur baru yang diterapkan. Mungkin beberapa bug diperbaiki, dan itu, mereka harus dilawan. Perkembangan aktual membeku jauh lebih awal dari yang tersisa @dmajda

Anda tahu apa yang saya lihat di sana?

Saya melihat perpustakaan yang tidak terawat selama tiga tahun dan masih memiliki enam cabang aktif selama beberapa bulan terakhir.

Pokoknya, lihat, cat garis di mana pun Anda inginkan di pasir. Mungkin ada tempat yang lebih baik untuk menggambarnya; Saya belum melakukan penggalian arkeologi.

Intinya, itu masih garis di pasir. Mari kita gunakan kaki kita untuk menidurkan pasir sekarang.

0.12.0 sangat mungkin jika kita bisa membuat orang berkata "hei, ayo kita lakukan."

Ini adalah parser terbaik di luar sana setelah setengah dekade tidak aktif.

Apakah Anda menyadari betapa hebatnya jika itu menjadi proyek yang dapat diakses sumber terbuka?

Mari kita buat 0.12.0 yang bersih lalu mulailah memetik ceri dari 0.11.0 yang dapat dipercaya. Setelah itu, kita bisa membersihkan, dan mulai memperbaiki sisanya.

Banyak dari ini yang sangat sulit, tentu saja

Tapi banyak dari mereka tidak. Saya mendapatkan dukungan modul ES6 dari skrip bash satu baris. Itu konyol dan mudah diperbaiki

Gerakan ke depan tidak harus sempurna; itu hanya harus non-sepele

Bantu saya membuat David bergabung? Silahkan

Seperti serius.

Bayangkan apa yang akan terjadi jika 0.12.0 keluar, dan selain memperbaiki README dan beberapa hal sepele lainnya, itu hanya 0.10.0 .

Lalu bagaimana jika minggu depan, dukungan modul es keluar?

Dan bagaimana jika minggu berikutnya, halaman web mendapat pembaruan besar?

Dan bagaimana jika minggu berikutnya, kami merilis dukungan TypeScript sederhana

Itu semua sudah saya lakukan. Itu semua seperti pekerjaan dua jam. Itu irama yang santai dan mudah

Tapi itu sangat berbeda dari yang biasa digunakan pengguna sehingga jelas bahwa ada sesuatu yang berubah

Saya cukup yakin bahwa perpustakaan ini memiliki komunitas pengguna dan basis cacat untuk mendapatkan rilis sub-bulanan yang berarti, dan saya cukup yakin bahwa saya dapat mewujudkannya

Saya juga punya garpu sendiri, satu file, implementasi nol ketergantungan berdasarkan makalah akademis asli. Saya awalnya mencoba menggunakan basis kode 0.10.0, tetapi bahkan itu terlalu membengkak untuk selera saya.

Perasaan saya adalah bahwa siapa pun yang menjadi sasaran misi kritis telah bercabang karena berurusan dengan drama "sumber terbuka" lebih menguras tenaga daripada menghabiskan beberapa akhir pekan untuk mempelajari dan menerapkan solusi untuk kebutuhan spesifik seseorang. Serius, kertasnya mudah dibaca dan dalam <100 jam saya bisa mendapatkan parser yang 4x lebih cepat dan 100x lebih kecil.

Selalu ada tradeoff mendasar antara ingin menggunakan solusi yang ada dan memiliki pasangan yang cocok untuk masalah Anda sendiri. Komunitas pengurai berada di lembah yang sulit di mana begitu seseorang telah cukup belajar untuk menggunakan alat pengurai secara efektif, itu hanya sedikit pekerjaan tambahan untuk menulis seluruh pengurai mereka sendiri.

Biaya peluang terbesar dari open source adalah spiritual.

Namaste :doa:

PS Jangan salah paham, saya sangat menikmati utas ini, ini hiburan yang luar biasa! Saya hanya tidak berharap banyak nilai produktif dari komunitas GH atau JS hari ini.

Ini adalah sudut pandang yang bisa dimengerti.

Mengingat status saat ini, saya berharap saya bisa membuat orang berkata "baiklah, biarkan sebuah percobaan terjadi dan mari kita lihat"

@StoneCypher Saya suka energi Anda yang tampaknya ingin Anda masukkan ke dalam lib ini dan saya setuju dengan ide-ide umum Anda (dan saya sudah akan melakukannya setelah pertama kali Anda menulisnya - tidak perlu mengatakan hal yang sama lima kali :grin :) . Saya juga tidak terlalu suka garpu, tapi itu berarti kita bergantung pada satu orang - futagoza. Bagaimana jika dia tidak merespon? Kemudian kita terjebak, tidak ada yang bisa kita lakukan tentang itu. dmajda sudah mengatakan dia tidak punya hak lagi, jadi dia juga tidak bisa berbuat apa-apa.

Inilah hal yang saya tidak setujui: "dalam repo berbeda yang tidak dapat dilihat atau tidak akan pernah diperhatikan oleh siapa pun" karena itu memiliki solusi sederhana: buka edisi baru dalam huruf besar dengan mengatakan sesuatu seperti "PROJECT MATI - LANJUTKAN DI SINI" dan kemudian tulis semua informasi yang diperlukan di sana. Saya akan menjadi orang pertama yang mengalihkan proyek saya, dan saya yakin banyak orang lain akan melakukannya. Dan ini bukan proyek pertama yang terjadi, saya telah mengikuti beberapa proyek lain di rute itu. Bukan masalah besar, hanya beralih. Sebagai pengguna, saya tidak terlalu peduli dari mana saya mendapatkan kode saya selama itu adalah tempat yang dipedulikan orang.

Jadi saya akan memberi @futagoza beberapa minggu lagi untuk melihat apakah dia merespons dan apa pendapatnya. Jika tidak ada tanda-tanda kehidupan dan tidak ada tanggapan, lanjutkan dan buat ulang proyek ini dengan benar.

Sebenarnya, saya baru saja melihat bahwa @michel-kraemer juga anggota pegjs, jadi mungkin ada lebih banyak harapan :nyengir:

@michael-brade - Garpu tidak berfungsi. Saya akan sangat langsung: Saya tidak ingin Anda menyuruh saya melakukan sesuatu yang berbeda lagi

Sudah ada empat garpu yang mencoba menyimpan repo ini. Anda tidak tahu apa itu mereka. Anda tidak mencari mereka ketika mengatakan "perbaiki seperti itu."

Tidak masalah. Sebuah garpu tidak akan memperbaiki apa pun. Konsumen hilir yang ada tidak menerima perbaikan bug di fork. PR hilang dalam garpu. Masalah hilang dalam garpu.

Jawabannya adalah tidak sulit.

@futagoza harus segera berhenti memblokir pasak.

Perpustakaan ini tidak akan mati karena seseorang berjanji untuk menjadi pengelola, menolak untuk memelihara, dan memutuskan untuk menyimpannya sendiri.

Secara moral, @futagoza tidak berhak berjanji menjadi pengelola, lalu merusak perpustakaan.

Sudah ada empat garpu yang mencoba menyimpan repo ini .

Bagaimana Anda tahu bahwa mereka? Apakah Anda memiliki link? Satu-satunya jenis garpu aktif yang saya lihat adalah meisl/pegjs, tidak ada yang aktif sama sekali. Dan bahkan garpu meisl tidak terlihat seperti upaya untuk menyimpan repo ini.

Anda tidak mencari mereka ketika mengatakan "perbaiki seperti itu."

Mungkin Anda tidak membaca saran saya: jika garpu itu memang berniat untuk menyimpan repo ini, maka mereka salah melakukannya karena mereka tidak membuat masalah yang jelas memberi tahu komunitas ke mana harus pergi. Saya setuju dengan semua yang Anda katakan sampai penanda ini dibuat. Kemudian aturan berubah.

@futagoza harus segera berhenti memblokir pasak.

Benar. Dan bagaimana Anda berniat untuk menegakkan itu?

Bagaimana Anda tahu bahwa mereka?

Karena saya mencari perbaikan bug, bertahun-tahun yang lalu.

.

Apakah Anda memiliki link?

Ya. Namun, jika garpu bekerja, saya tidak perlu memberikannya; Anda akan memilikinya juga. Ini adalah penjelasan saya tentang mengapa saya tidak akan mempertimbangkan garpu, atau menghibur waktu yang terbuang lebih jauh untuk mengomel pengelola palsu

.

jika garpu itu memang berniat untuk menyimpan repo ini, maka mereka salah melakukannya karena mereka tidak membuat masalah yang jelas untuk memberi tahu komunitas ke mana harus pergi.

Sebenarnya, mereka melakukannya. Itu telah dihapus.

Di satu sisi, Anda benar: mereka melakukannya dengan salah, dengan membuat garpu.

Kebanyakan orang mendapatkan perpustakaan dari npm , di mana perpustakaan ini bahkan tidak memiliki readme. Mereka tidak akan pernah melihat masalahnya.

Saya menjadi sangat jelas ketika saya mengatakan "Saya tidak ingin berdiskusi lebih lanjut tentang garpu."

Upaya lebih lanjut untuk membahas hal ini akan diabaikan.

.

Saya setuju dengan semua yang Anda katakan sampai penanda ini dibuat.

Sudah, beberapa kali.

jika garpu itu memang berniat untuk menyimpan repo ini, maka mereka salah melakukannya karena mereka tidak membuat masalah yang jelas untuk memberi tahu komunitas ke mana harus pergi.

Sebenarnya, mereka melakukannya. Itu telah dihapus.

Oke, saya tidak punya cara untuk memeriksa ini. Tetapi dengan asumsi Anda benar, maka harus jelas bagi Anda bahwa orang yang menghapus masalah ini tidak memiliki niat untuk menyerahkan kekuasaan atas repo ini. Dalam keadaan seperti itu, bagaimana Anda pikir Anda dapat mengubah apa pun tanpa garpu?

Yang bisa saya katakan adalah saya berharap Anda beruntung. Dan itu akan saya ikuti ke mana pun perkembangan aktif berlangsung.

bagaimana Anda pikir Anda dapat mengubah apa pun tanpa garpu?

Karena pada akhirnya futagoza akan kembali, dan dia harus membuat keputusan ini lagi.

Itu terjadi pada tahun 2018. Ini tahun 2020. Dia memulai setidaknya empat parser PEG yang sama sekali berbeda sejak itu, satu dalam bahasa dasar yang berbeda, serta dua bahasa pemrograman.

Saat itu, dia tidak membuang tiga tahun pekerjaan karena tidak dapat dipercaya. Sekarang dia punya.

Saat itu, dia baru enam bulan menjalaninya. Itu masih garis waktu "beri saya kesempatan", hampir tidak. Sekarang sudah tiga tahun.

Saat itu, dia masih bisa mengatakan dia berkomitmen untuk ini, dan ini adalah fokusnya.

Hal-hal telah berubah.