MIT LispM Kaynak Kodunu Kamuya Açıyor

0
FZ
FZ
3 Ekim 2005 , 1 dakika okuma süresi
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
Lisp
9
Linkedin Facebook Twitter Google plus

Görüşler

darkhunter
0
darkhunter
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
0
FZ
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
0
darkhunter
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
0
FZ
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
0
darkhunter
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
0
FZ
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
0
darkhunter
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
0
darkhunter
"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
0
FZ
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

Microsoft ve Lisp: Ya da .NET CLR Garbage Collector Hangi Dilde Yazıldı?
FZ
27 Şubat 2005, 1 dakika okuma süresi

USENET comp.lang.lisp forumundaki eğlenceli bir mesaj dikkatimi çekti paylaşmak istedim.

Meğer meşhur .NET platformunun ana bileşenlerinden biri olan CLR (Common Language Runtime) sisteminin çöp toplayıcısı (garbage collector) Lisp ile yazılmış.

Sağlam Lisp "hacker"larından olan ve bir süredir MS için çalışan, CLR'nin baş mimarlığını yapan Patrick Dussud'un yazdığı Lisp kodu daha sonra bir Lisp'ten C'ye dönüştürücü ile C'ye dönüştürülmüş ve bu kod da MS'deki bir stajyer programcı tarafından "temizlenip" derlenip piyasaya sürülmüş.

Lisp ve .NET konusu açılmışken: Her iki dünyadan da vazgeçmek istemeyenler için enteresan projeler çıkmaya başladı: L Sharp .NET (C#'tan çok daha eğlenceli ;-), RDNZL ve FOIL.

3D Model Tasarımı ve Mirai
FZ
16 Ekim 2005, 1 dakika okuma süresi

Rainer Joswig, 1999 yılında Mirai ile bir model tasarlayan Bay Raitt'in çalışma seansını yansıtan bir video sunuyor.

Mirai, 3D grafik tasarımı için kullanılan bir yazılım. Common Lisp ile yazılmış ve Allegro Common Lisp üstünde çalışıyor. Yazılımın temelleri daha önceki Symbolics Graphics süitine dayanıyor.

Videoyu buradan indirebilirsiniz.

Kaynak: Planet Lisp

Core Uygulama Sunucusu Kurulumu
anonim
10 Haziran 2007, 1 dakika okuma süresi

Common Lisp tabanlı uygulama sunucumuzu ücretsiz olarak deneyebilirsiniz. Bunun için yapmanız gerekenlerin anlatıldığı belgeye göz atabilirsiniz.

Günümüzde üretilen yazılımların çoğu web uygulamaları şeklinde ya da web servisleri olarak hizmet vermektedir. Web uygulamaları, erişilebilir, birden fazla kişinin kullanımına elverişli ve merkezi olarak güncellenebilir servislerdir.

Gelecekte oldukça fazla web uygulaması ve web servisi yazacağımız düşünüldüğünde bu konuda bize yardımcı olacak araçlar üretmek iyi bir yatırım olacaktır. Bu nedenle yazımda sizlere Common Lisp dili ile yazılmış bir web uygulama sunucusu olan Kor Web Uygulama Sunucusu'nu tanıtacağım.

More Lisp—For Free ve Birkaç Lisp Makalesi
FZ
30 Kasım 2005, 1 dakika okuma süresi

O'Reilly her ne kadar Lisp kitabı basmak istemese de O'Reilly yazarları Lisp'ten daha sık bahsetmeye başladı. En son Christopher Roach, More Lisp—For Free başlıklı bir yazı yazmış.

Lisp ile ilgili bir başka makale: Generating HTML with Lisp - a tutorial for new programmers. Gene Michael Stover'ın diğer Lisp makaleleri de okunmaya değer.

Common Lisp ile Oyun Programlama
FZ
15 Şubat 2005, 1 dakika okuma süresi

Frank Buss, Common Lisp kullanarak Aqueaduct isimli bir mantık bulmaca oyunu (puzzle) geliştirmiş.

Bir grafik kullanıcı arayüzü de olan oyun MS Windows, GNU/Linux ve Mac OS X ortamlarında (kodda bir değişiklik gerektirmeden) çalışabiliyor. Kaynak kodu meraklısı için öğretici olabilir.