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 VisualLisp#'i Mi Duyuracak?
FZ
10 Ağustos 2005, 2 dakika okuma süresi

Bill Clementson, blog'undaki son girdide şöyle yazmış:

Don Box, XOM, XML ve SOAP üzerine yaptığı çalışmalardan ötürü Microsoft'a geçmeden önce de bir hayli tanınan bir isimdi. Epey akıllı bir adamdır ve blogunu düzenli olarak takip ederim. Ancak son yazılarından birinde "Lisp/Scheme Jobs" başlıklı bir şey görünce şok geçirdim:

Common Lisp ve Bir Optimizasyon Tekniği: Memoization
FZ
15 Eylül 2005, 15 dakika okuma süresi

"Memoization" tabiri bilgisayar bilimlerinde ilk kez Donald Michie'nin 1968 yılında Nature dergisinde yayımlanan Memo functions and machine learning (Memo fonksiyonları ve makina öğrenimi) makalesi ile gündeme gelmiştir.

Memoization tekniği bir fonksiyonu hesaplarken önceden hesaplanmış değerleri hesaplamadan kullanmak, dolayısı ile işlemi hızlandırmak olarak tarif edilebilir. Sözcük olarak "memorization"ı yani "ezberleme" eylemini çağrıştırmakla birlikte daha genel bir anlamı kapsamaktadır.

Programlama dilinden bağımsız olmakla birlikte, bu yazıda "memoization" tekniğinin Common Lisp'te nasıl kullanılacağına bakacağız. Bunun için Peter Norvig'in PAIP kitabı ana eksenimizi oluşturacak.

ECLM '08 ve ELS '08'in Ardından
FZ
27 Temmuz 2008, 1 dakika okuma süresi

ECLM 2008 (European Common Lisp Meeting) ve ELS 2008 (European Lisp Symposium) tamamlandı. ECLM 2008'deki konuşmalardan birkaç örnek vermek gerekirse:
  • Marc Battyani, Lisp-based supercomputing
  • Juan José García-Ripoll, ECL - more than an Embeddable Common Lisp
  • Jeremy Jones, InspireData - how it was written in Lisp
  • Kristoffer Kvello, House Designer - using Knowledge Based Engineering and Lisp to automatically design buildings
  • Nicolas Neuss, Femlisp - solving partial differential equations with Common Lisp
  • Stefan Richter, Using Common Lisp for large Internet systems
  • Kilian Sprotte, PWGL - an environment for sound synthesis and computer aided composition

Gelin Hep Birlikte Kodlayalım Çağrısı
FZ
17 Aralık 2007, 5 dakika okuma süresi

Aycan İrican'ın cs-lisp e-posta listesine attığı bir e-postaya dikkat çekelim:

Selam,

Nasıl anlatabilirim bilmiyorum ama, bu listede common lisp programlama yapmak isteyen var mı acaba? Bir grup kütüphane ve buna bağlı bir web sunucu yazdık biz.

Common Lisp ile Internet Programlamaya Giriş Kılavuzu
FZ
30 Temmuz 2005, 23 dakika okuma süresi

Beklenen an geldi. Common Lisp kullanarak web programlamaya dair ilk makalemizi yayınlıyoruz. Giriş seviyesindeki bu makalede en temel bilgiler aktarılmış ve Lisp heveslilerinin gerekli araçları nasıl kuracakları ve ayarları nasıl yapacakları gösterilmiş, ilk bebek adımlarını atmaları amaçlanmıştır.

Makale, İstanbul Bilgi Üniversitesi, Bilgisayar Bilimleri Bölümü öğrencilerinden Haldun Bayhantopçu tarafından yazılmış ve Emre "FZ" Sevinç tarafından son düzenlemeleri yapılmıştır. Teknik konular ve teknik üslup konusunda eleştirilerini esirgemeyen Bülent Murtezaoğlu'na teşekkür ederiz.

Afiyet olsun...