Pegjs: Bagaimana cara menentukan aturan untuk dicocokkan dengan pola beberapa kali di PEG.js?

Silakan baca tata bahasa contoh pasak. Tidak ada bug di sini. Pelacak masalah tidak dimaksudkan untuk permintaan bantuan. Salah satu contoh tata bahasa adalah persis apa yang Anda minta.

Tempat yang tepat untuk permintaan bantuan adalah StackOverflow. Pelacak masalah adalah apa yang digunakan pengembang untuk melacak apa yang rusak, dan apa yang digunakan repositori paket untuk mengukur kualitas proyek.

Document
  = ClassRow+

ClassID
  = "G04"

ClassTitle
  = title:[^\n]+ { return title.join(''); }

ClassRow = 
  id:ClassID title:ClassTitle '\n'? { return { id, title }; }

Setelah Anda melihat ini, harap tutup masalah ini. Terima kasih.

Kuncinya adalah belajar membaca tata bahasa PEG. Yang mengatakan:

1. " Document adalah satu atau lebih ClassRow s."
2. " ClassID adalah string tetap "G04" ."
3. " ClassTitle adalah teks apa pun hingga, tetapi tidak termasuk, baris baru berikutnya. Anda akan menyebutnya "judul". Kembalikan judul sebagai string, bukan larik karakter."
4. " ClassRow adalah ClassID diikuti oleh ClassRow .

Karena ClassRow berakhir di baris baru, baris baru secara efektif memulai baris baru.

Saya akan menggunakan StackOverflow untuk pertanyaan saya selanjutnya, terima kasih atas jawaban dan penjelasannya.

Namun, ada beberapa hal yang ingin saya ungkapkan:

1. Bagian "Jenis masalah: Pertanyaan: [ya/tidak]" sedikit menyesatkan sehubungan dengan arahan yang Anda sebutkan. Saya menafsirkan bagian itu sebagai "Pelacak masalah adalah tempat yang tepat untuk mengajukan pertanyaan"
2. "contoh": Saya dapat melihat 4 contoh tata bahasa di folder examples/ . Namun, IMHO, tidak satupun dari mereka yang cocok (cukup sederhana) untuk pemula (seperti saya, atau untuk saya) kecuali untuk "arithmetics.pegjs". Saya mengerti bahwa PEG.js sedang dalam pengembangan (berat?), jadi cukup dimengerti bahwa Anda mungkin lebih fokus pada masalah/skenario dunia nyata yang kompleks. Saya hanya mengharapkan contoh langkah demi langkah dari tata bahasa yang sederhana hingga yang kompleks.

Harap pertimbangkan itu sebagai umpan balik pendatang baru.

Bagian "Jenis masalah: Pertanyaan: [ya/tidak]" sedikit menyesatkan sehubungan dengan arahan yang Anda sebutkan. Saya menafsirkan bagian itu sebagai "Pelacak masalah adalah tempat yang tepat untuk mengajukan pertanyaan"

Saya setuju. Saya ingin menghapus teks itu, dan memintanya pada tahun 2017.

Alasan adanya teks adalah karena David, yang tidak lagi menjalankan perpustakaan ini, bosan dengan orang yang mengatakan "ini adalah bug" tanpa melihat masalah dan menemukan orang lain yang mengira ada bug, dan ternyata tidak ada

Masalah ini, misalnya, memiliki setengah lusin klon

.

"Contoh": Saya dapat melihat 4 contoh tata bahasa di folder contoh/. Namun, IMHO, tidak satupun dari mereka yang cocok (cukup sederhana) untuk pemula (seperti saya, atau untuk saya) kecuali untuk "arithmetics.pegjs".

Saya setuju. Saya ingin menulis banyak dari mereka.

.

Saya mengerti bahwa PEG.js sedang dalam pengembangan (berat?)

Ini pasti tidak.

Penulis asli telah membiarkannya menganggur selama setahun, jadi dia meminta pengelola baru.

Pengelola baru yang mengambil alih pada Mei 2017 belum merilis satu byte kode pun ke cabang master.

Saya telah memulai proses agitasi untuk pengambilalihan, karena penggunaan perpustakaan menurun, perpustakaan tidak mendukung javascript dari 2014, tidak ada readme di NPM selama hampir tiga tahun, perbaikan AST karakter tunggal adalah tidak dibalas selama satu tahun dalam masalah, dan pengelola baru telah memutuskan untuk membuang 2,5 tahun cabang fitur yang dia tandai sebagai menutup banyak masalah, dan mengganti seluruh perpustakaan dengan sesuatu yang baru yang dia tulis sendiri dalam bahasa yang berbeda

.

cukup dapat dimengerti bahwa Anda mungkin lebih fokus pada masalah/skenario dunia nyata yang kompleks. Saya hanya mengharapkan contoh langkah demi langkah dari tata bahasa yang sederhana hingga yang kompleks.

Saya percaya bahwa orientasi pengguna mungkin merupakan satu-satunya masalah dunia nyata yang paling penting saat ini setelah membuat perpustakaan ini sehat kembali

Untuk kejelasan, saya bukan penulis asli. @dmajda adalah.

Untuk kejelasan, saya bukan pengelola. Tidak ada pemelihara.

Bagian "Jenis masalah: Pertanyaan: [ya/tidak]" sedikit menyesatkan sehubungan dengan arahan yang Anda sebutkan. Saya menafsirkan bagian itu sebagai "Pelacak masalah adalah tempat yang tepat untuk mengajukan pertanyaan"

@ceremcem , Anda melakukan segalanya dengan benar (selain apa yang tidak Anda lihat pada deskripsi PEG di wikipedia dan tidak mencoba menguraikan tata bahasa Anda secara manual, setelah itu pertanyaan Anda, IMHO, akan diselesaikan). Anda tidak dapat mengetahui bahwa pertanyaan Anda hanyalah pertanyaan atau deskripsi bug di perpustakaan. Ini hanya dapat diputuskan oleh pengembang. Oleh karena itu, tidak ada aturan GitHub hanya untuk bug . Masalah adalah masalah bahkan di Afrika

secara umum pelacak masalah dimaksudkan untuk masalah, bukan pertanyaan

ceremcem akan mendapatkan jawaban dalam hitungan jam di stackoverflow. di sini, dia menunggu sembilan hari, dan jika saya tidak angkat bicara, saya pikir dia tidak akan mendapat jawaban.

banyak pertanyaan serupa seperti ini tidak terjawab di sini setelah satu tahun atau lebih. ada setengah lusin yang berusia delapan tahun.

.

Anda tidak dapat mengetahui bahwa pertanyaan Anda hanyalah pertanyaan atau deskripsi bug di perpustakaan.

Ya dia bisa. Dia bertanya "bagaimana saya melakukan ini?"

Kecuali dia yakin parser tidak bisa melakukan ini, itu bukan bug.

Ini pada dasarnya adalah hal yang paling sederhana dalam pengurai, dan saya percaya bahwa peg masih merupakan pengurai javascript yang paling banyak digunakan, meskipun itu dengan cepat berhenti menjadi kenyataan, dan ia tampaknya cerdas, jadi saya tidak berpikir dia percaya bahwa generator parser tidak dapat menggunakan aturan lebih dari sekali

Demi kepentingan terbaiknya, sangat ideal untuk mengarahkannya ke sumber daya yang dirancang untuk pertanyaan, daripada perbaikan perpustakaan, terutama jika sumber pertanyaan adalah sumber yang sangat aktif, dan sumber daya perbaikan perpustakaan baru saja mengumumkan bahwa itu akan menunda pekerjaan selama tiga tahun dan umumnya mengabaikan pertanyaan seperti ini

Bukan kebetulan bahwa ini tidak terjawab sampai saya mulai menandai orang, seperti halnya setengah lusin masalah lainnya sejauh ini

Tidak ada keputusan yang dibuat. Aku memberinya nasihat.

Juga, saya menjawab pertanyaannya .

Saya biasanya mendapatkan jawaban dalam beberapa jam di StackOverflow, jadi saya adalah pengguna tetapnya. Namun, tidak ada kegiatan pada pertanyaan SO saya , jadi saya datang dan bertanya ke sini. Pada dasarnya, waktu respons hampir identik.

Saya telah melihat setiap kombinasi penggunaan pelacak masalah:

• Hanya untuk laporan bug, jika forum atau grup email terpisah disediakan (PaperJS, misalnya),
• Untuk pertanyaan dan laporan bug (RactiveJS <3, FreeCAD_Assembly3 <3)
• Untuk sesuatu yang sebenarnya tidak saya dapatkan, bersama dengan forum terpisah, di mana tersangka biasa mengambil alih dan berbicara atas nama pemilik proyek, yang menyebabkan lebih banyak frustrasi daripada yang lainnya (seperti KiCAD (grrr))
• Untuk apa-apa (Espruino, AFAIR). Setiap masalah segera ditutup dan Anda dipaksa untuk membuka utas yang sesuai di forum mereka.

Tidak ada satu pilihan terbaik untuk itu (tidak ada yang cocok untuk setiap kasus), tetapi saya suka menggunakan pelacak masalah untuk semuanya.

Anda tidak dapat mengetahui bahwa pertanyaan Anda hanyalah pertanyaan atau deskripsi bug di perpustakaan.

Kami telah melihat ini berkali-kali di perpustakaan FreeCAD_Assembly3. Banyak pertanyaan saya yang sederhana dan bodoh mengungkapkan satu atau lebih bug. Ini terjadi, saya melihat.

Saya setuju. Saya ingin menulis banyak dari mereka.

Saya suka pendekatan Anda ke perpustakaan ini. Anda tampaknya sangat peduli.

jadi saya tidak berpikir dia percaya bahwa generator parser tidak dapat menggunakan aturan lebih dari sekali

Benar. Niat saya bukan laporan bug. Saya hanya tidak menemukan jalan keluar untuk menggunakan kembali aturan yang sama untuk beberapa baris.

Namun, tidak ada aktivitas pada pertanyaan SO saya, jadi saya datang dan bertanya ke sini.

Gan, komunitas pasak disana udah mati juga?

Sedih banget ️

Oke, jika Anda sudah membuat posting SO, maka pada saat itu Anda 100% benar untuk datang ke sini

.

Saya telah melihat setiap kombinasi penggunaan pelacak masalah:

Ya, orang selalu melanggar norma masyarakat

.

Saya setuju. Saya ingin menulis banyak dari mereka.

Saya suka pendekatan Anda ke perpustakaan ini. Anda tampaknya sangat peduli.

Sangat banyak. Saya ingin terlibat dalam transisi kepemilikan 2017, tetapi seseorang memberikan rencana dengan 17 rilis utama, dan pemilik lama mempercayainya

Orang itu menyerah pada pembebasan kecil pertama mereka tiga tahun kemudian.

Yang benar adalah perangkat lunak publik sangat sulit untuk ditulis. Hampir semua orang yang saya kenal, termasuk saya, memiliki kecenderungan untuk mengatakan "rilis ini belum siap sampai X, Y, dan Z selesai."

Dan kemudian saat Y selesai, Anda menyadari bahwa Anda juga membutuhkan V dan W.

Dan kemudian saat Z selesai, Anda menyadari bahwa Anda juga membutuhkan S, T, dan U.

Dan kemudian saat V selesai ...

Begitulah cara 0.11.0 memulai dengan setengah lusin fitur pada tahun 2017, dan mati dengan seratus penggabungan yang salah ditandai ditutup di pelacak pada tahun 2020

Bagian dari disiplin perangkat lunak publik adalah rilis kecil yang sering. Itu selalu menjadi masalah dengan pasak, tetapi kualitas perangkat lunaknya sangat tinggi sehingga kami tetap bertahan.

Kemudian dmajda pergi, dan semuanya terhenti begitu saja.

Dan kami menunggu, dengan sabar, untuk waktu yang lama.

Tetapi orang baru itu sekarang menyebut ini sebagai proyek hobinya, dan mengatakan bahwa dia membatalkan semuanya demi sesuatu yang baru dan tidak sesuai yang dia tulis. Dan bahkan jika itu memiliki AST yang sama dan kumpulan fitur yang sama dan lebih banyak lagi, itu tidak akan memiliki sepuluh tahun debugging komunitas di belakangnya, dan saya tidak akan dapat beralih

Dan Anda tahu, jika dia ingin menulis parser PEG baru yang lebih kuat, bagus, bagus, silakan.

Tapi dia tidak bisa membunuh yang satu ini dengan berpura-pura menjadi pengelola kemudian tidak pernah memelihara, kemudian mengambil alih komunitas dan posisi perpustakaan yang satu ini, dan menempatkan perangkat lunaknya sendiri yang tidak akan pernah dirilis sebagai gantinya.

Saatnya proses yang sehat untuk mengambil alih kembali. Pengelola baru membangun komunitas mikro pengembang junior, dan mereka sebenarnya menganjurkan untuk menjaga perpustakaan tetap mati daripada menyimpannya

Jelas bahwa perubahan sangat dibutuhkan

.

Saya hanya tidak menemukan jalan keluar untuk menggunakan kembali aturan yang sama untuk beberapa baris.

Jika Anda kesulitan menemukan jawaban lagi, jangan ragu untuk menandai saya secara pribadi

Yang mengatakan, umumnya saya google untuk contoh, dan karena perpustakaan ini pernah sangat populer dan banyak digunakan (dan bisa lagi jika pembunuh perpustakaan saat ini hanya akan memberikan ruang di bangku untuk orang lain untuk membantu,) ada lebih dari cukup contoh di luar sana untuk menutupi hal-hal yang perlu Anda temukan

Namun, secara umum, apa yang saya harap seseorang telah memberi tahu saya ketika saya masih baru adalah hal yang saya katakan di bawah komentar yang dimulai "Kuncinya adalah belajar membaca tata bahasa PEG"

Setelah Anda belajar membaca tata bahasa PEG dalam bentuk diskusi itu, Anda juga akan sangat mudah untuk memikirkannya, dan pada saat itu mereka tiba-tiba menjadi sangat mudah untuk ditulis.

Ini seperti saklar lampu. Tidak ada jalan. Langsung dari tidak mungkin ke mudah

Ini seperti saklar lampu. Tidak ada jalan. Langsung dari tidak mungkin ke mudah

Anda mendorong saya! :) Jadi saya seharusnya tidak merasa begitu bodoh ketika saya hanya bisa melihat beberapa set aturan "omong kosong" :)

Jika Anda kesulitan menemukan jawaban lagi, jangan ragu untuk menandai saya secara pribadi

Saya tidak ingin menyalahgunakan ini, jadi akan sulit menelepon setiap kali apakah itu layak untuk ditanyakan atau haruskah saya mencari di internet lagi. Ini adalah tawaran yang murah hati, terima kasih.

Jelas bahwa perubahan sangat dibutuhkan

Saya melihat bahwa Anda mengaktifkan bagian "masalah" di garpu Anda. Itu selalu merupakan pertanda baik untuk mencoba menerbangkan pesawat dengan bergegas ke kokpit saat Anda hanya seorang penumpang. Itu hal yang bagus.

Jika ada sumber air hidup, ia akan selalu menemukan jalannya untuk mengalir, tidak peduli apa pun yang Anda lewati. Jika tidak ada aliran karena sumbernya terkuras, tidak ada yang bisa dilakukan. Sumber adalah permintaan. Sikap Anda menunjukkan bahwa sumber air itu sangat hidup.

Jadi saya penasaran, kenapa tidak Anda ambil alih saja? Itulah yang saya lakukan untuk perpustakaan bilah pemuatan . Saya menyadari bahwa pengembangan terhenti, jadi saya mengambil alih dengan menangani masalah mulai dari masalah saya sendiri dan membuat permintaan tarik untuk setiap cabang. Beberapa waktu kemudian, penulis asli memutuskan untuk melanjutkan karyanya, dan kami siap melakukannya. Apakah menurut Anda ini adalah solusi yang layak?

Anda mendorong saya! :)

Saya senang.

.

Ini seperti saklar lampu. Tidak ada jalan. Langsung dari tidak mungkin ke mudah

Jadi saya seharusnya tidak merasa begitu bodoh ketika saya hanya bisa melihat beberapa set aturan "omong kosong" :)

Tidak. Parser adalah kasus ekstrim dari "itu hanya konyol dan kemudian tiba-tiba itu mudah".

Inilah kickernya - secara komparatif, pasak cukup mudah. Yang lain seringkali hanya brutal.

Ada empat masalah besar menurut saya dalam belajar pasak.

1. Tidak ada materi pengantar yang terstruktur dengan baik
2. Ada banyak contoh tingkat menengah di luar sana tetapi Anda harus pandai di google untuk menemukannya
3. Ada juga contoh buruk di sana dan butuh pengalaman untuk bisa mengidentifikasinya
4. Anda harus bisa "berpikir seperti ini", dan itu tidak langsung terjadi

Saya telah mempertimbangkan untuk membuat beberapa video tutorial. Mereka akan membuat _far_ ini lebih mudah dimengerti, saya percaya.

.

Saya tidak ingin menyalahgunakan ini, jadi akan sulit menelepon setiap saat jika layak untuk ditanyakan

Sekali seminggu baik-baik saja. Pahami bahwa saya terkadang lambat merespons

.

Saya melihat bahwa Anda mengaktifkan bagian "masalah" di garpu Anda. Itu selalu merupakan pertanda baik untuk mencoba menerbangkan pesawat dengan bergegas ke kokpit saat Anda hanya seorang penumpang. Itu hal yang bagus.

Saya baru saja memulai. Pertama saya ingin melihat apakah repo asli dapat diselamatkan

Melakukan ini dari garpu akan jauh lebih sulit. Saya akan kehilangan semua PR dan semua referensi silang, dan semua materi tertutup yang tidak digabung atau dihapus, beberapa di antaranya sangat berharga

.

Jadi saya penasaran, kenapa tidak Anda ambil alih saja?

Aku mau sih.

Saat ini, kata sandi dan otentikasi yang relevan ada di tangan satu orang, dan mereka belum merespons.

Kita lihat saja nanti.

.

Saya menyadari bahwa pengembangan terhenti, jadi saya mengambil alih dengan menangani masalah mulai dari masalah saya sendiri dan membuat permintaan tarik untuk setiap cabang

Ini adalah kasus khusus

Yang diterbitkan adalah 0.10.0

Pengelola baru mengizinkan cabang 0.11.0 tumbuh tanpa batas selama tiga tahun, kemudian memutuskan itu dibatalkan, demi 0.12.0 yang dia tulis dari awal dalam isolasi

Tidak ada yang bisa dijadikan PR. Apa yang ada di npm berasal dari 2017, dan apa yang ada di github di bawah pengelola baru dibatalkan setelah tiga tahun tanpa pernah dipublikasikan

.

Beberapa waktu kemudian, penulis asli memutuskan untuk melanjutkan karyanya, dan kami siap melakukannya. Apakah menurut Anda ini adalah solusi yang layak?

Jika pengelola pengganti bersedia mengizinkannya, kira-kira inilah yang saya inginkan.

Saya agak ragu David akan kembali, tetapi jika dia melakukannya, itu akan luar biasa

Karena itu saya ingin mengubah ini menjadi proyek open source standar lagi

Apa 3 isu terpenting di sini, menurut Anda?

Saya pikir mengatakan apa masalah yang paling penting bagi saya sedikit berbahaya, karena ada cukup banyak orang di sini dengan lebih banyak pengalaman daripada yang saya miliki di peg , dan jika mereka mengatakan "sebenarnya ini adalah hal lain, "Saya kemungkinan besar akan mendengarkan.

Untuk itu, saya ingin mengingatkan bahwa meskipun saya senang berkembang di sini, minat saya di sini adalah sebagai pengelola .

Ini, menurut saya, sesuatu yang banyak orang tidak mengerti: pengkodean pengembangan dan pemeliharaan benar-benar berbeda.

• Development coding menginginkan ide-ide baru yang besar, fitur-fitur baru, ide-ide baru yang mencolok.
• Maintenance coding ingin memperbaiki masalah kecil sebelum mereka mengumpulkan dan membuat sesuatu yang baik tidak dapat digunakan.

Saya senang melakukan beberapa pengkodean pengembangan - bahkan mungkin menantikan beberapa - tetapi ada orang lain di sini yang lebih cocok untuk itu. Dan, jadi, saya ingin memperjelas: tujuan saya yang sebenarnya adalah membuat ini agar mereka dapat menyumbangkan PR lagi, seperti dulu.

Yang mengatakan, untuk menunjukkan apa sudut pandang pribadi saya:

1. Mendapatkan kembali irama rilis reguler

peg.js tidak boleh memiliki cabang ajaib lagi. Ini seperti One Ring sialan. Kedengarannya hebat dan kuat, tetapi itu tidak berhasil, dan pada akhirnya, Anda adalah Gollum. Ini bukan svn . Dalam suara Steve Ballmer, feature branches , feature branches , feature branches , feature branches .

Sebuah versi harus merupakan hasil dari fitur, bukan titik pengumpulan untuk rencana fitur. Kami bukan perusahaan tahun 1980-an dan kami tidak boleh merencanakan seperti itu.

Satu-satunya waktu lebih dari satu fitur harus masuk pada saat yang sama adalah ketika itu tidak dapat dihindari, seperti sebagai hasil dari menambal fitur untuk mengatasi peningkatan eksternal, atau hal-hal yang benar-benar tidak dapat dilakukan secara terpisah. Oh, menurutmu itu terkait dengan fitur lain? Bagus, masukkan 2.31.0 , kita perlu mengeluarkan 2.29.0 dan hal lain di sana kemungkinan besar adalah 30 .

Orang-orang telah memperlakukan anak di bawah umur seperti mereka yang utama. Itu sebabnya minor tidak pernah keluar: itu tergantung pada perangkap perilaku yang sama yang menggantung mayor. Hanya Jangan Sialan Lakukan Itu ™.

Untuk lebih spesifik,

• Orang-orang, saya yakin, sebagian besar telah kehilangan kepercayaan bahwa perpustakaan ini ada lagi.
• Tiga bulan rilis mingguan akan membuat orang memberikannya kesempatan lagi.
  
  
  
  • Tiga bulan rilis mingguan sebenarnya akan sangat mudah dicapai
  
  
• Jika kami tidak hanya mengeluarkan 0.12.0 , tetapi juga 0.13.0 - dan perhatikan saya tidak mengatakan apa yang ada di dalamnya, dan saya pikir itu tidak masalah - maka kami akan memiliki kesempatan nyata di 1.0.0
• Hanya melalui PR terbuka dan tertutup yang tidak digabungkan di sini, ada sejumlah besar kekuatan dan keindahan, dengan komentar dari tahun 2015 atau lebih seperti "Saya akan memeriksanya nanti." Menjadi orang yang murah hati dan menemukan ruang untuk berbagi otoritas akan membantu peg tidak hanya menjadi hidup, tetapi juga berkembang
• Untuk itu, saya tidak ingin menjadi artis. Saya ingin menjadi kurator.

2. Mendapatkan dokumentasi dan pengujian ke tempat yang dapat diterima

Semua orang membicarakan hal ini, tetapi mesin keadaan terbatas hobi saya saat ini memiliki 3500 unit test dan cakupan dokumentasi 100%, jadi, anggap saya lebih serius.

Saya sangat percaya pada pengujian.

Ada perpustakaan lain yang saya tulis yang ukurannya setengah dan kompleksitasnya jauh lebih rendah daripada mesin negara. Jauh lebih mudah untuk membuat perubahan bahasa menyeluruh ke mesin negara daripada perubahan kecil pada pengendali jaringan, karena pengendali jaringan diuji dengan buruk, dan Anda harus berusaha keras untuk memastikan ada sesuatu yang benar.

FSM? Nah, tesnya bagus, mereka akan menangkapmu

Kontras khusus ini mengingatkan saya dengan sangat jelas setiap kali saya menyentuh salah satu dari mereka betapa pentingnya pengujian sebenarnya untuk sesuatu yang, setidaknya bagi saya, dapat dipercaya.

Saya pikir sebagian besar masalah dengan mengerjakan peg.js adalah bahwa pengujian dan dokumentasi berantakan. Saya pikir sudah waktunya untuk itu berubah.

3. Menghapus omong kosong hipster.

• Saya bukan orang Ruby, tetapi, orang Ruby benar-benar paham tentang konfigurasi berdasarkan konvensi. Saya sama sekali bukan Ruby, tetapi saya masih bisa duduk dan mengetahui cara kerja sebuah proyek, karena begitulah cara kerja mereka semua, dan jika saya tidak mendapatkan sesuatu, saya dapat bertanya kepada seseorang, dan mereka tidak memerlukan akses, karena begitulah cara mereka semua bekerja
• peg menghadapi empat masalah dalam hal ini
  
  
  
  1. peg adalah perpustakaan javascript 3$#$ yang sangat awal, dan membuat banyak pilihan dasar sebelum norma komunitas ada. sebenarnya, beberapa norma masyarakat adalah karena david; sebelum mematok banyak orang berpikir multipackaging itu sulit, jadi sekarang salah satu pelopor dalam hal itu bermasalah di belakang dalam hal yang sama, itu agak memilukan. Yang mengatakan, selain hal-hal brilian yang david dapatkan sebelumnya, beberapa hal yang salah, dan beberapa hal yang benar saat itu tidak lagi. Banyak perubahan kecil akan menghasilkan perubahan radikal pada pengalaman pengembang.
  
  
  2. Norma masyarakat harus ditegakkan kembali.
     
     
     
     
     
     1. Hanya ada cara tertentu proyek node seharusnya bekerja. Itu termasuk menghasilkan keluaran yang ditargetkan browser, dan dengan demikian, proyek simpul jelas merupakan cara modern yang tepat untuk bekerja
     
     
     
     2. Ini masih merupakan proyek browser dengan otomatisasi buatan tangan. Itu harus berubah
     
     
     
     3. Merupakan tantangan pembelajaran yang signifikan untuk mendapatkan posisi mengedit README dengan benar. Setelah tiga tahun, pengelola saat ini masih belum melakukannya (!), dan begitu juga dengan pengembang asli dalam dua versi terakhir
        
        
        
        
        
        
        
        • Ini asin. Potongan proyek yang seharusnya sepele rusak karena tidak dilakukan dengan cara normal yang sederhana. Mereka harus dilakukan dengan cara normal yang sederhana, tetapi itu membutuhkan seseorang yang tahu simpul dan siap untuk melakukan pekerjaan yang membosankan.
        
        
        
        
     
     
     
  
  
  3. peg adalah penerima dan korban dari otomatisasi ekstrim.
     
     
     
     
     
     • Tampaknya dmajda tidak akan bisa sejauh yang dia lakukan tanpanya. Saya pasti tidak bisa pada barang-barang saya.
     
     
     
     • Namun, ini adalah otomatisasi 2011, bukan otomatisasi 2020
     
     
     
     • Ini juga otomatisasi 2013, 2014, 2016, dan 2018. Hal-hal ini tersebar di zeit, sekarang, halaman github, akun pribadi yahoo, gitlab, beberapa layanan pelacakan dan penyebaran otomatis yang aneh, dan mungkin banyak hal yang belum saya temukan
     
     
     
     • Ini hanya alat yang meronta-ronta untuk bertahan dari kehancuran atau bermain dengan hal baru yang panas. Pemilihan alat yang hati-hati mengarah pada keabadian berdasarkan desain. repl yang sebenarnya hampir sepuluh tahun tahan lama sekarang. Segala sesuatu yang lain juga bisa, jika "ooh mengkilap" diperlakukan sebagai bendera merah.
     
     
     
     • Ini harus dipindahkan ke gh pages dan gh actions , yang dipahami semua orang, dan dibiarkan sendiri selamanya
     
     
     
  
  
  4. Pengelola baru memilih untuk menyelam jauh ke dalam alat yang tidak biasa dan strategi yang terpinggirkan. Akibatnya Anda harus menginstal manajer paket baru untuk berkontribusi perbaikan bug, dan mempelajari tata letak sumber yang tidak umum yang hidup berdampingan, dengan cara yang membingungkan, dengan serangkaian sumber yang tidak terkait yang tampaknya merupakan produk nyata, dalam tata letak sumber biasa.
     
     
     
     
     
     • Ketika pihak ketiga memberikan kontribusi perbaikan yang memungkinkan manajer paket bahasa standar juga berfungsi, dia menolaknya.
     
     
     
     • Perilaku semacam ini, sejujurnya, tidak dapat diterima dalam proyek komunitas. Itu membuat perpustakaan jauh lebih sulit untuk berkontribusi.
     
     
     
     • Beberapa dari alat-alat ekstremis ini telah digantikan oleh alat-alat ekstremis lainnya, jadi dia tidak mengejar hal-hal yang dia tahu; dia mencoba banyak hal. Sementara itu, kami menunggu hal-hal mendasar, seperti kesalahan ejaan di AST, seperti memperbaiki readme pada npm , atau menggabungkan es6 modules , selama tiga tahun sekaligus.
     
     
     
     • Terus terang, dalam rebake 0.12.0 , hal-hal seperti module di module yarn stuff akan keluar begitu saja. Barang-barang build David telah bekerja sejak 2011. Barang-barang baru dari 2018 sudah rusak pada tahun 2020. Tidak ada lagi teknologi yang dilettante.
     
     
     
  
  
• DAN BISAKAH SAYA MENDAPATKAN EKSPOR ES6

tetapi Anda akan melihat tidak ada yang benar-benar tentang perangkat lunak itu sendiri

Saya tidak berpikir perangkat lunak di sini adalah masalahnya

saya pikir prosesnya, dan pada tingkat yang lebih rendah, proyek

itu yang akan saya perbaiki, jika @futagoza mengizinkannya

perpustakaan ini dapat hidup kembali dalam 30 hari jika kita menelan harga diri kita dan memilih kebutuhan komunitas besar perpustakaan daripada kepentingan proyek hobi kita

biarkan hobi menulis ulang menjadi garpu

biarkan seorang pengelola mulai memelihara

@StoneCypher Saya suka energi Anda :-) Saya dulu menggunakan pegjs di masa lalu (di masa dmajda) dan saya sangat menyukainya.

Hanya garpu dan jangan melawan. Hal-hal dapat dan akan menetap nanti. Jika komunitas mengikuti Anda maka Anda tidak perlu peduli dengan "pemegang kunci" yang ada atau semacamnya. Membangun reputasi membutuhkan waktu tetapi perlu. Jangan buang waktu untuk berdebat lagi.

Delapan garpu Anda akan membuatnya "kembali ke asalnya" di beberapa titik di masa depan atau akan memiliki kehidupannya sendiri. Kedua opsi tersebut valid dan IMO baik-baik saja.

Tolong hentikan dengan omong kosong "buat garpu". Ada empat dari mereka dan Anda tidak tahu apa itu. Garpu tidak akan menyelamatkan konsumen hilir yang ada, tidak akan menghemat PR, tidak akan menyelamatkan masalah, tidak akan membawa komunitas, dan tidak akan terlihat.

Orang-orang telah mencobanya selama tiga tahun. TIDAK BEKERJA.

Jangan terus menawarkan nasihat ini.

@futagoza - semua orang telah menyerah pada Anda melakukan hal yang benar. Lima orang menyuruhku untuk membayar perpustakaan itu, karena mereka mengharapkanmu menolak untuk mengizinkan perbaikan, dan untuk tetap mengendalikan perpustakaan yang kamu bunuh.

Saya yakin alasan mereka mengharapkan ini adalah karena saya menemukan lebih dari selusin orang menawarkan bantuan kepada Anda untuk melakukan hal yang Anda janjikan dan tidak pernah Anda lakukan, dan setiap kali Anda berkata "tidak, saya akan segera melakukannya. "

Lakukan apa yang seharusnya Anda lakukan pada tahun 2018, dan berikan pemeliharaan kepada seseorang yang benar-benar akan memelihara proyek tersebut. Berhenti membunuh perpustakaan ini, berhenti membunuh komunitas ini, dan menyingkir.

@StoneCypher John, ketika saya menyarankan untuk membuat garpu, saya benar-benar bersungguh-sungguh. Forking sebuah proyek adalah pilihan yang bagus yang diberikan open source kepada Anda terutama jika Anda merasa perlu perubahan atau sedang sekarat. Dan tidak, saya tidak punya masalah, Anda tidak perlu menulis saya DM hanya untuk menanyakan pertanyaan ini kepada saya.

Ketika saya mengatakan "jangan berikan nasihat ini lagi", saya juga sungguh-sungguh.

Saya suka percakapan ini.

@StoneCypher Saya harus tidak setuju dengan Anda di sini, karena saya melihat yang sebaliknya:

1. Saya memutuskan untuk mulai belajar FreeCAD. Namun, ada masalah: "Modul perakitan"-nya tidak lengkap, jadi kami hampir tidak dapat membuat rakitan kompleks yang membuatnya tidak berguna untuk pekerjaan profesional.
2. Seorang pria, realthunder memutuskan untuk memecahkan masalah ini. Dia perlu mengubah beberapa properti inti untuk mencapai tujuan, yang pada gilirannya membuat garpunya tidak sesuai dengan cabang utama. Dia kehilangan semua pengguna, hampir semua komunitas. Kecuali beberapa orang, dia tidak punya pendukung (itu yang saya lihat). Dia juga tidak memiliki pengguna aktif, sejauh yang saya mengerti.
3. Saya memeriksa dokumentasinya dan meskipun tahun pengembangannya terhenti (itulah yang saya lihat saat itu) saya membuat matematika (matematika yang menarik) dan memutuskan untuk mencobanya.
4. Saya mengajukan banyak pertanyaan dan dia menjawabnya dengan sabar. Sementara itu saya mencatat apa yang saya pelajari , sehingga menjadi bahan pengantar yang baik.
5. Orang-orang tidak menyarankan untuk menggunakan cabangnya dengan mengklaim bahwa dia adalah penulis dan pengelola yang kesepian dan karyanya tidak boleh dipercaya dalam hal keberlanjutan. Aku hanya mengabaikan mereka.
6. Permintaan tariknya belum digabungkan untuk waktu yang lama (sekitar satu tahun atau lebih).

Belakangan ini PR-nya mulai direview. Sejumlah besar pekerjaan telah dilakukan dan akhirnya cabangnya dan arus utama menjadi kompatibel. Dalam rilis berikutnya, saya yakin cabangnya akan digabung menjadi arus utama.

Sementara itu, ada masalah keuangan yang serius. Dia adalah satu-satunya pengelola dan sumbangan dari beberapa pengguna tidak dapat membuatnya bertahan. Saya memutuskan untuk mengajar FreeCAD/Assembly3 di sini, Turki, dan menjual dukungan untuk mendukung keuangan. Saya melamarnya dan ini diterima. Saya membuat semua aplikasi yang diperlukan untuk menjadi pelatih di yayasan yang sangat terkenal, yang diterima baru-baru ini.

Terkadang 1 orang cukup untuk menyalakan api.

dan menyingkirlah

Tidak setuju. Biarkan mereka tetap di jalan. Motivasi yang baik akan selalu menemukan jalan keluarnya. Jika tidak bisa, itu karena tidak terlalu bagus.

Saya secara eksplisit dan jelas tidak mengumpulkan saran tentang topik ini.

Perpustakaan ini perlu dibangkitkan. Saya minta maaf jika saya tidak menjelaskannya dengan cukup, tetapi tanggapan yang saya terima gagal untuk mengatasi salah satu masalah praktis yang diajukan.

Kehidupan dan pekerjaan orang-orang bergantung pada ini.