MIT LispM Kaynak Kodunu Kamuya Açıyor

MIT, LispM kaynak kodunu BSD tarzı bir lisans ile kamuya açıyor. Bu şu demek: Lisp Machines sistemlerinin temel bileşeni artık özgür. BSD lisansı sayesinde de insanlar bundan istedikleri gibi faydalanabilirler.

LispM tarihine aşina olmayanlar için: CONS, MIT'de geliştirilmiş ilk Lisp Makinası idi. Tasarıma 1973 yılında başlanmış ve 1976'da ortaya ilk ürün çıkmıştı. 1978 yılında geliştirilen CADR ise daha gelişmiş bir modeldi. MIT'de sadece 25 CADR üretilmişti ancak bu makina ilk ticari LispM'lerin atasıydı ve hem LMI hem de Symbolics bunu temel almış, MIT'den hackerlerı bünyelerinde toplamışlardır. Her ne kadar pek çok MIT hackerı ticari LispM şirketlerinde çalışmak için MIT'yi terk ettilerse de Richard Stallman okulda kalmayı tercih etmiş ve ticari ürünlerdeki hemen her özelliği MIT'deki Lisp Makinaları'nda yeniden, büyük başarı ve inat ile kodlamıştı. Her ne kadar MIT'nin LispM sistemleri ticari sistemleri birebir yansıtmasa olağanüstü bir yazılım geliştirme ortamı olduğu su götürmez. Aslında, en hacker dostu (hacker friendly) geliştirme ortamı olduğu söylenebilir. Son zamanlarda J2EE ve .NET ortamında yazılım geliştirenler için LispM OS bir tür cennete kısa bir bakış sayılabilir.

Kaynak: http://bc.tech.coop/blog/051002.html

Görüşler

darkhunter
18 yıl önce

Lisp OS özgün halinde x86 tabanlı sistemlerde çalışmıyordu galiba. O yüzden kaynak açmanın son kullanıcıya ne derece avantaj getireceğini (en azından kısa vadede) kestirmek zor.

Ama eninde sonunda olacaktı bu, bir OpenLispOS projesi gelişir, hatta bakarsınız Linux entegrasyonu falan yapılır, hep beraber Emacs leri uçurumdan atarız :-p

Seviyorum emacs i ama arada bir feci falde sinirlerimi bozuyor... Devel listelerine öyle sorular sormak durumunda kalıyorum ki bazen; "takma kafana herşeyin mantıklı bir nedenin olmasına gerek yok" gibilerinden cevap alıyorum... :)

FZ
18 yıl önce

Lisp OS özgün halinde x86 tabanlı sistemlerde çalışmıyordu galiba. O yüzden kaynak açmanın son kullanıcıya ne derece avantaj getireceğini (en azından kısa vadede) kestirmek zor.

Son kullanıcı???

Evet, o zamanlar ortada IBM PC, Intel 8086 filan yoktu, onlar olduğunda da zaten Lisp Makinaları ile insanlar birçok şey yapıyorlardı (daha sonra rekabeti getiren ise IBM değil Sun Microsystems idi).

Ama eninde sonunda olacaktı bu, bir OpenLispOS projesi gelişir, hatta bakarsınız Linux entegrasyonu falan yapılır, hep beraber Emacs leri uçurumdan atarız :-p

Tek seçeneğin GNU/Linux olduğunu sanmıyorum. Başka seçeneklerde vardır mutlaka. Emacs'a gelince, uzunca bir süre daha PC üzerinde alternatifi olacağını sanmıyorum Emacs ya da XEmacs'ın.

Seviyorum emacs i ama arada bir feci falde sinirlerimi bozuyor...

Neden?

Devel listelerine öyle sorular sormak durumunda kalıyorum ki bazen; "takma kafana herşeyin mantıklı bir nedenin olmasına gerek yok" gibilerinden cevap alıyorum... :)

GNU Emacs geliştirme e-posta listesinde mi? Ne tür sıkıntılarınız var? Neyi çözmeye çalıştınız da çözemediniz? Yazarsanız belki birlikte bir çare arayabiliriz.

darkhunter
18 yıl önce

Valla kendimden korkmaya başladım artık :) 11:45:41 :D

Bu da problemimin geyiği :

Under a window system, Emacs frames want to be resized in certain increments. The window manager usually respects this, so an Emacs frame is usually w * W pixels wide and h * H pixels tall, where w and h are integers and W and H represent the character width and height, respectively. This usually results in each Emacs frame displaying a whole number of lines of text. But I've got my `mode-line' face set to make it draw a two-pixel border around the mode line. This means that my Emacs frames are not displaying a whole number of lines of text. Assuming plain-text buffers, I always see only part of the bottom-most line of the bottom-most window of each frame. This in itself doesn't bother me. What does bother me is what happens when Emacs is forced to be a certain height. If an Emacs frame that is displaying a partial line immediately above the mode line is forced to be a single pixel taller, that one pixel goes to waste. This screenshot demonstrates the phenomenon: Notice the dead space at the very bottom of the frame. Those ca. 10 pixels could be put to better use by extending the main window height by 10 pixels, so that the dead space would be eliminated. The same thing happens for the frame width (in the above screenshot, I believe there are two pixels of dead space to the far right), but that doesn't bother me as much. You can reproduce this easily by bringing up a buffer with large headings, such as the Info system, and then maximizing the Emacs frame in, e.g., GNOME. Unless you are very lucky and the pixels add up just right, you should be able to observe the partial line and dead space. I have been strolling through the source code trying to figure out how difficult this would be to fix, but I'm not sufficiently familiar with the code so I have to give up. I'd appreciate it if someone who knows this code better could evaluate the difficulty of fixing the problem. Please let me know if any part of the problem is unclear.

Valla, bekleyip dua etmek dışında yapacak pek birşey yok anladığım kadarıyla...

FZ
18 yıl önce

Ben şimdi o IRC logunu tam anlamadım, yani kim kimdir, birisi darkhunter mıdır? Arada CLHS'de defstruct'tan bahsetmiyor, CLOS öğrenmek için AMOP okuyorum gibi enteresan laflar gördüm.

Emacs ile ilgili meseleye gelince, orada yazan problemi de, ne kadar büyük bir sıkıntı olduğunu da tam anlamadım (ekran görütüsü olsa belki anlardım). Yine de aklıma gelen ilk şey aynı durumun XEmacs'ta da oluşup oluşmadığı sorusu oldu.

darkhunter
18 yıl önce

Evet problem xemacs de oluşuyor, çok hayati bir sorun yok orda ama seni temin ederim can sıkmak için yeterli bir saçmalık...

IRC loguna gelince orada darkhunter yok, FZ var ; Tam da şu satırda ilgimi çeken bir durum oldu, paylaşmak istedim :

11:45:43 <FZ> (dofile (line "/home/fz/programming/Lisp/darkhunter.lisp") (princ line))

Galiba, senin yaptığın bir konuşma (8-)

FZ
18 yıl önce

Hehe :) FM Forum'da Lisp ile ilgili bir şeyler mi ne yazıştıydık, tam o sırada ben de Emacs'ta farklı bir dosya açayım da orada deneme yapayım demiştim diye hatırlıyorum, oradan kalma darkhunter.lisp :) (Kardeşim her şeyin de logu tutulmaz ki, biri bizi gözetliyo mu ne, töbe töbe :-P

Ben Emacs problemini hala anlamadım yani hafif anlar gibi oldum ama tam anlamadım, bu akşam bakarım bir ara, GNOME olması şart mı? Yani başka ortamlarda da oluyor mu? Fonta filan bağlı mı? İşletim sisteminden bağımsız mı (Win?) Bir ekran çıktısı olsa ona baksam tabii daha kolay anlarım, hatta etrafına kırmızı bir elips çizilse, bir ok çıkarılsa, bak burada sorun var, bak bu da başka editör bunda böyle bir şey yok dense (yani Emacs developerlar anlamıştır belki, onlar için demiyorum, kendim için diyorum :).

Bu arada hazır konu açılmışken, Emacs kullanarak C programlayan arkadaşlar biraz Emacs ortamlarından, Emacs'ı nasıl bir tümleşik geliştirme ortamı olarak kullandıklarından bahsederler mi, yani işte Emacs içinden tek tuşla derle, çıkan hatanın üstüne git, çat diye ilgili yere zıpla, fonksiyonun üzerine gel, onun tanımlandığı yere zıpla, bir kombinasyon ile sistem fonksiyonunun dokümantasyonuna git, vs. Yok kendim için sormuyorum, genç bir arkadaşımız bana e-posta yazmış, bir iki şey dedim, bir iki faydalı link verdim ama belki Emacs ile yoğun C kodlayan insanlar burada kullanım şekillerinden bahsederlerse faydalı bilgi aktarmış olabilirler.

darkhunter
18 yıl önce

Anladığım kadarıyla xemacs kullanan her ortamda yaşanıyor. Ben unstable için derlenmiş paketlerle az önce kde ile denedim yine saçmaladı. Herhalde bir patch beklemek gerekecek. Font bağımlılığından pek emin değilim, config dosyalarıyla oynadım ama değişen birşey olmadı. Win üzerinde hiç uzun soluklu emacs kullanmadım, benzer bir sorun var mı bilemiyorum... Emacs'in bu durumla ilgili bir log vermediğini belirtmem gerek, konuyu underground yapanda bu zaten. Ben messages, user ... falan da taradım ama doğrudan buraya bağlanabilecek birşey yakalayamadım. Bu yüzden grafiklerle anlatamıyorum konuyu :)

Emacs ve C için çok fazla birşey söyleyemem ben genelde C için anjuta ve kdevelop ile takılıyorum. Bir özeleştiri yapmak gerekirse bu güvende hissetme durumunun uzun süre win üzerindeki "ide"lerI KULLANMıŞ olmakla bir ilgisi olduğunu düşünüyorum... Emacs bir yana, nano ile C yazan arkadaşlarım var, onları anlamakta cidden zorlanıyorum 8-D

darkhunter
18 yıl önce

"Son zamanlarda J2EE ve .NET ortamında yazılım geliştirenler için LispM OS bir tür cennete kısa bir bakış sayılabilir."

Evet, bu yorumu "bir fincan kahvenin kırk yıl 'header'ı var" isimli güzide programa paslamayı düşünebiliriz...

FZ
18 yıl önce

Bill Clementson'un o lafını çevirsem mi diye epey düşündüm. Kendisi aynı zamanda sağlam bir Java programcısı, J2EE ile filan epey iş güç yapmış biri. Ama çekindim yine de çünkü burada ne zaman Lisp desek birileri çıkıyor "hah, Java ile yapılamayacak ne var ki Lisp ile yapılabilen, hep Lisp diyorsunuz biraz da Java desenize, hem bakın Eclipse gibi, JBuilder gibi mükemmel IDE var bizde, siz dinozorlar tarih öncesi Emacs kullanın, yazık size, hem tüm diller birbirlerine Turing-tamlık bakımından denktir, üstelik Java'da daha az parantez var" gibi şeyler diyorlar.

Programa paslamaya gelince açıkçası her iki dili doğru dürüst kıyaslayabilecek babayiğit çok fazla yok ortalıkta. O programda da olduğunu sanmıyorum. Bir bakıyorsunuz biri tutmuş Emacs'ın içindeki elisp'ten yola çıkıp "hmm, Lisp böyle bir şeymiş demek" diye yorum yazıyor (sonra tabii gidip yok güzel kardeşim biz Common Lisp diyoruz, o başka bu bambaşka diye izah etmekte güçlük çekiyorsunuz), bir başkası Common Lisp matematik için iyidir (bu ne demekse) başka alanlarda olmaz diyor, bir diğeri "nesneye yönelik programlama dediğin..." diye konuya giriyor. Açıkçası eğer illa bir Lisp versus Java daha doğrusu Common Lisp vs. Java kıyaslaması yapılacaksa hakikaten iki dili de iyi bilen Pascal Costanza, Bill Clementson gibi insanların bu kıyaslamayı yapmasında fayda var.

Görüş belirtmek için giriş yapın...

İlgili Yazılar

Diyelim Ki Elimizde Nesneye Yönelimli Bir Dil Yok - Alice Nesneler Diyarında

FZ
16 Ekim 2005, 10 dakika okuma süresi

Elinizdeki programlama dilinde nesneye yönelimli (OO - Object Oriented) programlama imkanı olmasa idi ne yapardınız? İki seçenekten biri gelirdi aklınıza herhalde:

OO desteği veren bir dil kullanmaya başlamak.
Elinizdeki dile OO desteği katmak için uğraşmak.

Bu kısa yazıda Peter Norvig'in PAIP (Paradigms of Artificial Intelligence Programming Case Studies in Common Lisp) kitabının 13. bölümündeki birkaç kısa örnekten yola çıkarak "eğer Common Lisp dilinde CLOS (Common Lisp Object System) gibi bir şey olmasaydı bunu nasıl gerçekleştirebilirdik?" sorusunun cevabının ilk bölümüne göz atacağız.

minifesto: mini mini 'animated' manifesto

FZ
20 Aralık 2005, 1 dakika okuma süresi

Zach Beane yine yapacağını yapmış. minifesto sitesine gidip, istediğiniz metni yazıp bunu yakışıklı bir siyah kutu içinde, karizmatik yeşil yazılarla, daktilo efekti şeklinde görebileceğiniz bir "animated GIF" olarak elde edebiliyorsunuz.

Bir örneğini de Brian Mastenbrook'un blog'unda PI filminden meşhur bir alıntı şeklinde görmek mümkün.

Acaba bu şirinlik hangi programlama dili ile yapılmış? Tabii ki programlamayı tekrar eğlenceli kılan dille.

Nasıl Bir Emacs?

FZ
19 Kasım 2005, 1 dakika okuma süresi

Daha önce özgür yazılım etkinliklerindeki seminerleri ile tanıdığımız COR3 ekibinden Aycan İrican, cs-lisp e-posta listesinde paylaştığı bir mesajla Common Lisp ile ilgilenmeye başladıklarını ve bununla ilgili belge oluşturma çabasına giriştiklerini belirtti.

İlk çıkan belgelerden biri Nasıl Bir Emacs başlıklı bir tür Emacs kılavuzu. Diğeri ise Emacs yapılandırma dosyası (.emacs) ile ilgili güzel ipuçları içeren .emacs belgesi.

eXtreme Programming ve Bir Başarı Öyküsü

FZ
22 Ekim 2005, 1 dakika okuma süresi

Bill Clementson son blog girdilerinden birinde birkaç gün önce gerçekleştirdikleri etkinlikte sunum yapan ve bir başarı öyküsü aktaran Ken Dickey'e yer vermiş.

Avustralya kökenli başarılı bir start-up olan Memetrics'in öyküsünü çarpıcı bir dille anlatan Dickey, eXtreme Programming metodolojisi ve Common Lisp'ten faydalanarak geliştirdikleri sistemi anlatan güzel bir sunum hazırlamış.

Keskin rekabetten ve gizli silahların gücünden hoşlananlar için incelenesi bir örnek. Afiyet olsun.

newLISP

bk
9 Temmuz 2006, 1 dakika okuma süresi

Bu kadar Lispçinin gözünden kaçmış olabilir mi bilemiyorum ama ben bulamadım: newLISP for BSDs, GNU/LINUX, MacOS X, Solaris, Win32.

newLISP, yapay zekâ ve istatistik gerektiren alanlarda web uygulamaları ve diğer türden yazılımlar için geliştirilmiş genel amaçlı bir betik dilidir. FAQ belgesi ve Common Lisp ile Scheme'den farklılıkları daha detaylı bilgi vermektedir.