- Pharo-dev - lists.pharo.org

Re: [Pharo-project] The future of Squeak & Pharo

by Janko MivÅ¡ek

Ian Trudel pravi: > GÃ¶ran Krampe: >> Not sure what you mean there. > > Squeak is hardly approachable to newcomers (either seasoned > programmers or simple new ones). Gaining popularity explicitly means > to have newcomers. It's not possible if they can't understand what's > going on. > >> Personally I like the colors. I also don't equal "normal" with >> "professional". But such is taste! > > We could certainly debate on tastes but it's perfectly fine that you > like the current colour scheme. However, you're not alone using Squeak > and we have to consider other tastes. > I just mean something approachable (normal look-and-feel), where > people will feel comfortable from the day they start using Squeak > through every other following days. > A professional look-and-feel is probably more about simplicity and > usability. It doesn't need to have colours by truck load. Something > that one can spend countless hours looking at without eyes popping out > of their sockets. And it's about everything... for example, Squeak has > these childish window buttons and so on... it's NOT that cool, far > from being trendy. Why would we get stubborn to keep such things? It > looks like a toy, Squeak sometimes feels like a toy. When I squeeze > Squeak, it squeaks. Just saying... =) I completely agree with Ian here. If Squeak wants to be considered for serious development, but also to attract developers from other communities and newcomers, it must have the look&feel which is close to theirs. This not mean that it must be the same, no, just that it follows the established look&feel standards elsewhere. Current Squeak is far away from that, while Pharo is marching well into a more standard look&feel direction. This is actually one of main reasons I'm attracted to Pharo. Also because they listen to such proposals! But this don't mean that EToys can stay more colorful, no, let it be on top of that more "traditionally professional" base. Why to mix two so different audiences into one image? Janko > And, unless some of us are graphic designers, why not just focus on > something simple, usable and approachable? That's definitively not out > of reach. > >> Note that talking about what we "need" and what other people "want" is not >> really that fruitful. We get what we *do*, or in other words - if someone >> feels it is important enough to spend time on it - it will get done. Noone >> works on something because *someone else* told him to. > > It seems to me that we are crying for direction as a community. Squeak > seems to be lost. Consequently, need, want, do, etc... it's just not > happening. Don't get me wrong, but it's just that you make it sounds > like everything can be done without a plan. And some of the things we > could want requires a lot of work hours and man power. It's not going > to happen overnight. > >>> requirements of my distributors, which makes it overly challenging for >>> me to consider Squeak as our platform of development. >> Elaborate? > > Please, Igor and I have talked a little bit about this. He will > certainly bring that on board's table. Anyway, GÃ¶ran, I hope to be > able to share a complete list at later time. I am not done reviewing > the requirements. It's also challenging to know the status of projects > in Squeak and what has to be done. > > >>> Squeak doesn't need a killer app. It needs to be spruced up and put >>> back on track. Honey moon is over, it's time to get real. >> Hehe, I really don't agree. :) >> >> Squeak *is* real. We already have our killer app (Seaside). We do need to >> clean shit up though (and I am not talking about UI primarily) and get the >> improvement process working. Currently Squeak.org is getting smashed (again, >> I don't have hard numbers, but I think I am right) by Pharo when it comes to >> hard, concrete, nitty gritt work getting done. > > Squeak has a killer app named Seaside. > Ruby has a killer app named Ruby On Rails. > Both are web frameworks, which kills which? > > It doesn't really matter. It's not even about merits. Ruby is still > more approachable language and better documented. And I find it almost > amusing to have a killer app for the web, when one of the strength of > Squeak is multimedia. No, no, I am not trying to flame war here... > just trying to expose few things in order that we can openly discuss > about them. > > Whether you agree or not, Squeak doesn't seem to gain in popularity > and people are flocking out to other forks. That means Squeak is doing > something wrong. Wrong enough to overcome all the "done right". =) > > Regards, > Ian > -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

June 28, 2009

Re: [Pharo-project] Pharo image crashes the VM

by Igor Stasenko

2009/6/28 Lukas Renggli <renggli(a)gmail.com>: > Somebody reported on the Seaside bug tracker about a Seaside One-Click > image (based on a recent Pharo image) that crashes when trying to open > it. > > Â http://code.google.com/p/seaside/issues/detail?id=393 > > I reproduced the problem on my machine and got the crash-log below. > Seems to be somehow related to 'primitiveSetPixelSizes' in > 'FT2Plugin'. Anybody has an idea what that could be? And how that > could be solved? > Hmm , very strange. I directly used this primitive - nothing bad happens. It could be that something weird happens if you pass wrong arguments to it. > Cheers, > Lukas > > ===================================== > > Process: Â Â Â Â Squeak VM Opt [2368] > Path: Â Â Â Â Â Â /Applications/Squeak/Squeak > 4.1.1beta2U-2.app/Contents/MacOS/Squeak VM Opt > Identifier: Â Â Â org.squeak.Squeak > Version: Â Â Â Â Squeak VM 4.1.1b2 (4.1.1b2) > Code Type: Â Â Â X86 (Native) > Parent Process: Â launchd [129] > > Date/Time: Â Â Â 2009-06-28 11:39:58.825 +0200 > OS Version: Â Â Â Mac OS X 10.5.7 (9J61) > Report Version: Â 6 > Anonymous UUID: Â 29E322B2-1485-4CD8-8566-727E56F50F71 > > Exception Type: Â EXC_BAD_ACCESS (SIGBUS) > Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000014 > Crashed Thread: Â 0 > > Thread 0 Crashed: > 0 Â de.impara.FT2Plugin Â Â Â Â Â Â Â Â 0x15299ffb FT_Request_Size + 47 > (ftobjs.c:2352) > 1 Â de.impara.FT2Plugin Â Â Â Â Â Â Â Â 0x1529a13c FT_Set_Pixel_Sizes + 90 > (ftobjs.c:2448) > 2 Â de.impara.FT2Plugin Â Â Â Â Â Â Â Â 0x1529510c primitiveSetPixelSizes + > 172 (FT2Plugin.c:1653) > > Thread 1: > 0 Â libSystem.B.dylib Â Â Â Â Â Â Â Â Â 0x910642e6 > semaphore_timedwait_signal_trap + 10 > 1 Â libSystem.B.dylib Â Â Â Â Â Â Â Â Â 0x910962af _pthread_cond_wait + 1244 > 2 Â libSystem.B.dylib Â Â Â Â Â Â Â Â Â 0x91097b33 > pthread_cond_timedwait_relative_np + 47 > 3 Â ...ple.CoreServices.CarbonCore Â Â Â 0x93817d96 > TSWaitOnConditionTimedRelative + 246 > 4 Â ...ple.CoreServices.CarbonCore Â Â Â 0x93817b76 TSWaitOnSemaphoreCommon + 422 > 5 Â ...ple.CoreServices.CarbonCore Â Â Â 0x938489ac TimerThread + 74 > 6 Â libSystem.B.dylib Â Â Â Â Â Â Â Â Â 0x91095155 _pthread_start + 321 > 7 Â libSystem.B.dylib Â Â Â Â Â Â Â Â Â 0x91095012 thread_start + 34 > > Thread 0 crashed with X86 Thread State (32-bit): > Â eax: 0x00000000 Â ebx: 0x1529506c Â ecx: 0x00000340 Â edx: 0xbfffe6dc > Â edi: 0x000db0f0 Â esi: 0x0085e800 Â ebp: 0xbfffe6b8 Â esp: 0xbfffe690 > Â ss: 0x0000001f Â efl: 0x00010297 Â eip: 0x15299ffb Â cs: 0x00000017 > Â ds: 0x0000001f Â es: 0x0000001f Â fs: 0x00000000 Â gs: 0x00000037 > Â cr2: 0x00000014 > > Binary Images: > Â Â 0x1000 - Â 0x11dfe7 +org.squeak.Squeak Squeak VM 4.1.1b2 (4.1.1b2) > <32d82d42f52666d1933dd0072ca15de2> /Applications/Squeak/Squeak > 4.1.1beta2U-2.app/Contents/MacOS/Squeak VM Opt > 0x15279000 - 0x15279ff0 +com.google.GearsEnabler ??? (1.0) > <20412f1ba06afbcd2c45b57bb0af5e68> > /Library/InputManagers/GearsEnabler/GearsEnabler.bundle/Contents/MacOS/GearsEnabler > 0x1527e000 - 0x1527effe +org.xlife.InquisitorLoader 3.2 (58) > <e4877ee4582562d98c95d447c8f77397> > /Library/InputManagers/Inquisitor/Inquisitor.bundle/Contents/MacOS/Inquisitor > 0x15283000 - 0x15285fff +net.culater.SIMBL 0.8.2 (8) > /Library/InputManagers/SIMBL/SIMBL.bundle/Contents/MacOS/SIMBL > 0x15291000 - 0x152eefd3 +de.impara.FT2Plugin 2.2.2c52 (2.2.2c52) > /Applications/Squeak/Squeak > 4.1.1beta2U-2.app/Contents/Resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin > 0x8fe00000 - 0x8fe2db43 Â dyld 97.1 (???) > <100d362e03410f181a34e04e94189ae5> /usr/lib/dyld > 0x90003000 - 0x90003ffd Â com.apple.Accelerate.vecLib 3.4.2 (vecLib > 3.4.2) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib > 0x90004000 - 0x90137fef Â com.apple.CoreFoundation 6.5.6 (476.18) > <2d52bab73660117571bd6486dc318f8e> > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > 0x90440000 - 0x9046ffe3 Â com.apple.AE 402.3 (402.3) > <b13bfda0ad9314922ee37c0d018d7de9> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE > 0x90d2b000 - 0x90d58feb Â libvDSP.dylib ??? (???) > <4daafed78a471133ec30b3ae634b6d3e> > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib > 0x90d59000 - 0x90e13fe3 Â com.apple.CoreServices.OSServices 227 (227) > <30cebcb68b1b571df7d77474e0c31556> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices > 0x90e14000 - 0x90e22ffd Â libz.1.dylib ??? (???) > <a98b3b221a72b54faf73ded3dd7000e5> /usr/lib/libz.1.dylib > 0x90e23000 - 0x90e23ff8 Â com.apple.Cocoa 6.5 (???) > <a1bc9247cf65c20f1a44d0973cbe649c> > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > 0x90e24000 - 0x90e5efe7 Â com.apple.coreui 1.2 (62) > /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI > 0x90e5f000 - 0x90e6fffc Â com.apple.LangAnalysis 1.6.4 (1.6.4) > <bc7eb703ddc37bf85adf93e35efd3947> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis > 0x90e70000 - 0x90e80fff Â com.apple.speech.synthesis.framework 3.7.1 > (3.7.1) <273d96ff861dc68be659c07ef56f599a> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis > 0x90ee0000 - 0x90fc1ff7 Â libxml2.2.dylib ??? (???) > <2f6b294896866822330a8888b7f53b75> /usr/lib/libxml2.2.dylib > 0x90fc2000 - 0x90fceff9 Â com.apple.helpdata 1.0.1 (14.2) > /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData > 0x91002000 - 0x9101aff7 Â com.apple.CoreVideo 1.6.0 (20.0) > <dd60118bac9aefaf88d9ab44558f05c4> > /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo > 0x9101b000 - 0x9101bfff Â com.apple.Carbon 136 (136) > <4177916bbf70e0ddc446f94001d54c95> > /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon > 0x9101c000 - 0x9105afff Â libGLImage.dylib ??? (???) > <a6425aeb77f4da13212ac75df57b056d> > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib > 0x9105b000 - 0x91062fff Â com.apple.agl 3.0.9 (AGL-3.0.9) > <2f39c480cfcee9358a23d61b20a6aa56> > /System/Library/Frameworks/AGL.framework/Versions/A/AGL > 0x91063000 - 0x911caff3 Â libSystem.B.dylib ??? (???) > <b47c8e6e45aef620730710a732bf1930> /usr/lib/libSystem.B.dylib > 0x911cb000 - 0x911e3fff Â com.apple.openscripting 1.2.8 (???) > <0129d2f750f5ddcb92f4acf8a3541952> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting > 0x9134d000 - 0x913a9ff7 Â com.apple.htmlrendering 68 (1.1.3) > <1c5c0c417891b920dfe139385fc6c155> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering > 0x913c8000 - 0x913defff Â com.apple.DictionaryServices 1.0.0 (1.0.0) > <7d20b8d1fb238c3e71d0fa6fda18c4f7> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices > 0x91481000 - 0x91b21fe3 Â com.apple.CoreGraphics 1.409.3 (???) > <25dceb14af3455b768f56e8765ecf3ca> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics > 0x91b55000 - 0x91b55ffa Â com.apple.CoreServices 32 (32) > <373d6a888f9204641f313bc6070ae065> > /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices > 0x91c05000 - 0x91fc3fea Â libLAPACK.dylib ??? (???) > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib > 0x91ff9000 - 0x924cafbe Â libGLProgrammability.dylib ??? (???) > <7f18294a7bd0b6afe4319f29187fc70d> > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib > 0x9251c000 - 0x925a3ff7 Â libsqlite3.0.dylib ??? (???) > <3334ea5af7a911637413334154bb4100> /usr/lib/libsqlite3.0.dylib > 0x925a4000 - 0x929b4fef Â libBLAS.dylib ??? (???) > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib > 0x929ba000 - 0x92d57fef Â com.apple.QuartzCore 1.5.8 (1.5.8) > <a28fa54346a9f9d5b3bef076a1ee0fcf> > /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore > 0x92d58000 - 0x92dfcfec Â com.apple.CFNetwork 438.10 (438.12) > <fde64bbb20532794396fb21911ccaa98> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork > 0x92dfd000 - 0x92ea4feb Â com.apple.QD 3.11.56 (???) > <a94d0f5438b730e88e5efdb233295c52> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD > 0x92f22000 - 0x92f2ffe7 Â com.apple.opengl 1.5.10 (1.5.10) > <5a2813f80c9441170cc1ab8a3dac5038> > /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL > 0x93025000 - 0x93027fff Â com.apple.securityhi 3.0 (30817) > <40562b85d99118354c974e76c32fa6fb> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI > 0x93028000 - 0x930a5feb Â com.apple.audio.CoreAudio 3.1.2 (3.1.2) > <5a4e6329f8dbca5dcd70924525afd24a> > /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio > 0x930a6000 - 0x930f7ff7 Â com.apple.HIServices 1.7.0 (???) > <01b690d1f376e400ac873105533e39eb> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices > 0x931c2000 - 0x93308ff7 Â com.apple.ImageIO.framework 2.0.4 (2.0.4) > <b407f06ff9b6893899e2e399cb65c953> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO > 0x9333c000 - 0x9333cffd Â com.apple.vecLib 3.4.2 (vecLib 3.4.2) > /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib > 0x93351000 - 0x93403ffb Â libcrypto.0.9.7.dylib ??? (???) > <9d714c92872a93dd127ea8556b2c8945> /usr/lib/libcrypto.0.9.7.dylib > 0x93436000 - 0x934b5ff5 Â com.apple.SearchKit 1.2.1 (1.2.1) > <f28f8dd0f155a6453411a0c9b5702764> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit > 0x934b6000 - 0x934bffff Â com.apple.speech.recognition.framework 3.7.24 > (3.7.24) <da2d8411921a3fd8bc898dc753b7f3ee> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition > 0x934c0000 - 0x9373cfe7 Â com.apple.Foundation 6.5.8 (677.24) > <aa84b0383891378c348ffa4a94853082> > /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation > 0x9373d000 - 0x937edfff Â edu.mit.Kerberos 6.0.13 (6.0.13) > <804bd1b3f08fb57396781f012006367c> > /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos > 0x937ee000 - 0x93ac8ff3 Â com.apple.CoreServices.CarbonCore 786.11 > (786.13) <9e2d85d52e5e2951aa4dd53c48ccc52f> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore > 0x93ac9000 - 0x93bb1ff3 Â com.apple.CoreData 100.2 (186.1) > <8fb61e1714a4b8d587ce97605ad32547> > /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData > 0x93be9000 - 0x93c32fef Â com.apple.Metadata 10.5.2 (398.25) > <e0572f20350523116f23000676122a8d> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata > 0x93c33000 - 0x93d13fff Â libobjc.A.dylib ??? (???) > <400e943f9e8a678eea22a1d1205490ee> /usr/lib/libobjc.A.dylib > 0x93d14000 - 0x93d14ffd Â com.apple.Accelerate 1.4.2 (Accelerate 1.4.2) > /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate > 0x93d15000 - 0x93d2affb Â com.apple.ImageCapture 5.0.2 (5.0.2) > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture > 0x93d2b000 - 0x93e64ff7 Â libicucore.A.dylib ??? (???) > <cac059ebdac7d9a63ee0f7a648c9f6cf> /usr/lib/libicucore.A.dylib > 0x93e65000 - 0x93ebeff7 Â libGLU.dylib ??? (???) > <a3b9be30100a25a6cd3ad109892f52b7> > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib > 0x93edc000 - 0x93f07fe7 Â libauto.dylib ??? (???) > <2e44c523b851e8e25f05d13a48070a58> /usr/lib/libauto.dylib > 0x93f08000 - 0x93f27ffa Â libJPEG.dylib ??? (???) > <b822342bcc764c83d4557a8b67fa0c1c> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib > 0x93f28000 - 0x93f28ffc Â com.apple.audio.units.AudioUnit 1.5 (1.5) > /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit > 0x93f29000 - 0x94727fef Â com.apple.AppKit 6.5.7 (949.46) > <a80f8cb62f6bdcb3bed3c8675d55881d> > /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit > 0x94728000 - 0x947b2fe3 Â com.apple.DesktopServices 1.4.8 (1.4.8) > <3065de6531ce839c7cb5b6dd70e03f4f> > /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv > 0x947b3000 - 0x94846ff3 Â com.apple.ApplicationServices.ATS 3.7 (???) > <a535fc4982d3acff6530ec25c402e679> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS > 0x94847000 - 0x94b4ffff Â com.apple.HIToolbox 1.5.5 (???) > <b17766e3d8800a73f534c41f624f5ac4> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox > 0x94f0a000 - 0x94f4bfe7 Â libRIP.A.dylib ??? (???) > <69bd09fcd8d8b235cee7a405290d6818> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib > 0x94f4c000 - 0x94f58ffe Â libGL.dylib ??? (???) > /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib > 0x9503b000 - 0x95056ffb Â libPng.dylib ??? (???) > <0d6b991afc831ea06f2958e5933d33dd> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib > 0x95057000 - 0x95057ffb Â com.apple.installserver.framework 1.0 (8) > /System/Library/PrivateFrameworks/InstallServer.framework/Versions/A/InstallServer > 0x95110000 - 0x95117fe9 Â libgcc_s.1.dylib ??? (???) > <e280ddf3f5fb3049e674edcb109f389a> /usr/lib/libgcc_s.1.dylib > 0x95118000 - 0x95195fef Â libvMisc.dylib ??? (???) > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib > 0x95270000 - 0x95270ff8 Â com.apple.ApplicationServices 34 (34) > <ee7bdf593da050bb30c7a1fc446eb8a6> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices > 0x95271000 - 0x95597fe2 Â com.apple.QuickTime 7.6.2 (1327) > <3754e41d846b7948f96c9ec4c690b520> > /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime > 0x95598000 - 0x9565fff2 Â com.apple.vImage 3.0 (3.0) > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage > 0x95660000 - 0x95664fff Â libGIF.dylib ??? (???) > <7714ae24eb64b48fa719fb99bcbe34f3> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib > 0x956a7000 - 0x956e9fef Â com.apple.NavigationServices 3.5.2 (163) > <72cdc9d21f6690837870923e7b8ca358> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices > 0x956ea000 - 0x956f1ffe Â libbsm.dylib ??? (???) > <fa7ae5f1a621d9b69e7e18747c9405fb> /usr/lib/libbsm.dylib > 0x956f2000 - 0x956f3ffc Â libffi.dylib ??? (???) > <eaf10b99a3fbc4920b175809407466c0> /usr/lib/libffi.dylib > 0x95719000 - 0x95723feb Â com.apple.audio.SoundManager 3.9.2 (3.9.2) > <df077a8048afc3075c6f2d9e7780e78e> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound > 0x95724000 - 0x9574cff7 Â com.apple.shortcut 1.0.1 (1.0) > <131202e7766e327d02d55c0f5fc44ad7> > /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut > 0x9574d000 - 0x95771fff Â libxslt.1.dylib ??? (???) > <0a9778d6368ae668826f446878deb99b> /usr/lib/libxslt.1.dylib > 0x95772000 - 0x95805fff Â com.apple.ink.framework 101.3 (86) > <d4c85b5cafa8027fff042b84a8be71dc> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink > 0x95806000 - 0x95811fe7 Â libCSync.A.dylib ??? (???) > <9e3544fe087bb4dc760b7afe0850dd6c> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib > 0x95812000 - 0x9586cff7 Â com.apple.CoreText 2.0.4 (???) > <f0b6c1d4f40bd21505097f0255abfead> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText > 0x9586d000 - 0x958caffb Â libstdc++.6.dylib ??? (???) > <f75e5133d72769de5ce6c06153fc65f6> /usr/lib/libstdc++.6.dylib > 0x958cb000 - 0x958cefff Â com.apple.help 1.1 (36) > <1a25a8fbb49a830efb31d5c0a52939cd> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help > 0x958cf000 - 0x958d7fff Â com.apple.DiskArbitration 2.2.1 (2.2.1) > <2664eeb3a4d0c95a21c089892a0ae8d0> > /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration > 0x958f0000 - 0x95927fff Â com.apple.SystemConfiguration 1.9.2 (1.9.2) > <eab546255ac099b9616df999c9359d0e> > /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration > 0x95928000 - 0x95af9ffb Â com.apple.security 5.0.5 (36371) > <c13e0bb1acfdcf94be4d3ee118ef190e> > /System/Library/Frameworks/Security.framework/Versions/A/Security > 0x95b17000 - 0x95b40fff Â libcups.2.dylib ??? (???) > <1b0435164b9dc6c773d0b1f24701e554> /usr/lib/libcups.2.dylib > 0x95c36000 - 0x95c54fff Â libresolv.9.dylib ??? (???) > <9ed809256ce8913cddc3269c2e364654> /usr/lib/libresolv.9.dylib > 0x96c31000 - 0x96c33ff5 Â libRadiance.dylib ??? (???) > <82d606c49f5dc77231f9d0e2be9ed6ab> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib > 0x96cf2000 - 0x96cf9ff7 Â libCGATS.A.dylib ??? (???) > <211348279493364e9920adc86484cedd> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib > 0x96cfd000 - 0x96d3cfef Â libTIFF.dylib ??? (???) > <d4bcc9b9c508e53849d2d46bb6900922> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib > 0x96d3d000 - 0x96d43fff Â com.apple.print.framework.Print 218.0.3 > (220.2) <5b7f4ef7c2df36aff9605377775781e4> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print > 0x96f02000 - 0x96f07fff Â com.apple.CommonPanels 1.2.4 (85) > <c135f02edd6b2e2864311e0b9d08a98d> > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels > 0x96f08000 - 0x96fd3fff Â com.apple.ColorSync 4.5.1 (4.5.1) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync > 0x96fde000 - 0x97130ff3 Â com.apple.audio.toolbox.AudioToolbox 1.5.2 > (1.5.2) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox > 0x971a4000 - 0x9721eff8 Â com.apple.print.framework.PrintCore 5.5.4 > (245.6) <03d0585059c20cb0bde5e000438c49e1> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore > 0x973af000 - 0x973b3fff Â libmathCommon.A.dylib ??? (???) > /usr/lib/system/libmathCommon.A.dylib > 0x973b4000 - 0x97440ff7 Â com.apple.LaunchServices 290.3 (290.6) > <bdba267184df88bd5b8e2116ea903872> > /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices > 0x97441000 - 0x974cdff7 Â com.apple.framework.IOKit 1.5.2 (???) > <97b9f9d584f48891377f0481b9104434> > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > 0xfffe8000 - 0xfffebfff Â libobjc.A.dylib ??? (???) /usr/lib/libobjc.A.dylib > 0xffff0000 - 0xffff1780 Â libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib > > ===================================== > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

June 28, 2009

Re: [Pharo-project] [squeak-dev] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by StÃ©phane Ducasse

On Jun 28, 2009, at 5:21 PM, Schwab,Wilhelm K wrote: > A partial reply on the topic of education: in the spirit of Alan's > "The Computer Revolution Hasn't Happened Yet" talk, it will likely > be a while (perhaps decades) before before people start to figure > out how to make real progress in education through computers. > > However and whenever it happens, I will go out on the following > limb: it will be adults who enable it. There is nothing wrong with > Pharo's focus on "grown-up software," We do not focus per se on grown-up software. We focus on robust, agile, flexible... software on top of which people can build what they want. Here is a nice example: in the past there was a Sq00 syntax: an alternate syntax for newbie. This was a cool idea. Now it was implemented by patching the AST printOn: methods with mode = #SQ00 ifTrue: ... then I wonder how they could try alternate design :). They probably found the right syntax directly. Another solution is a visitor with which you can also try 3 design without polluting the default AST printOn: method. > and that should actually be encouraged. Toys can easily be built on > top of such a subtrate, but a toy is unlikely to be a good > foundation for tools. Since we have uses for tools and toys, the > sound approach is to start with the tools and build the toys on top > of the same foundation that Pinesoft and others use to serve paying > customers. Yeap. even if Etoys is far from a tool indee having a good infrastructure to prototype new ideas is really needed. When I designed BotsInc I wanted to capture the error message so I thought: no problem I capture the SyntaxError message .... well .... no SyntaxError inherited from String. So I had to patch like hell the system. > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of GÃ¶ran Krampe > Sent: Sunday, June 28, 2009 5:24 AM > To: The general-purpose Squeak developers list > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [squeak-dev] The future of Squeak & > Pharo (was Re: [ANN] Pharo MIT license clean) > > Hi! > > (still cross posting, hope you don't mind) > > Gary Dunn wrote: >> I am new here and not really qualified to comment on this issue. >> Please take my input as having good intentions. Specifically, I do >> not >> want to start a flame war over the pros and cons of various projects. > > Nah, we don't do flame wars in the Squeak community. Well, not bad > ones at least :) > >> There is much to learn from the history of the BSD community. >> (Disclaimer: I am a huge fan of FreeBSD.) The FreeBSD project began >> with the goal of creating an open-source OS for Intel i386 hardware >> that was as faithful as possible to BSD Unix. In time the developers >> were going in three directions. One group wanted high performance, a >> second wanted portability to every possible platform, and a third >> wanted high reliability and security. There were also the usual >> personality conflicts and differing opinions on how to manage the >> project. >> Eventually it forked, twice, giving us FreeBSD, OpenBSD, and NetBSD. >> Each has its own personality, its own strengths. The good news is >> they >> cross-pollinate each other. > > Yeah, that would be a positive future. And I have in fact earlier > strongly advocated the fact that we need to "live with forks" > because we already have several of them (like Croquet, OLPC etc). > > But see below... > > [SNIP] >> It looks to me like Pharo is a Smalltalk for building grown-up apps. >> Very much like the Smalltalk I began with, which produced apps with >> the look and feel of the host Microsoft Windows. I think there is a >> need for that. I take it Pharo is new, and as such it has been luring >> developers away from Squeak. The potential for good in this outweighs >> whatever the negative consequences may be, because, like the BSDs, >> the >> Squeak developers can always pull in what they like from Pharo. > > In a "perfect world", yes. I even started the DeltaStreams project > with these cross pollination scenarios in my head. > >> Do not confuse a fork with a divorce. Think of it as mitosis. The >> more >> the merrier. > > Yes, that is also the way I have argued about it. See: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.h… > >> I believe that the impact of Squeak on education has yet to be >> realized. >> The necessary hardware -- the visionary Dynabook -- is just >> appearing. >> It will be years before there are enough skilled teachers for the >> critical mass required for the paradigm shift to occur. And there is >> the culture change, so difficult in a field as institutionalized as >> modern education. What we have been seeing are the Smalltalk >> explorers >> and trail blazers, the pioneers to whom we will someday owe an >> enormous debt of gratitude. > > Possibly true, but Smalltalk, Squeak, Etoys and even Croquet have > been around for quite some time now - and we haven't seen any real > explosion yet. Croquet was meant to "explode" but hasn't. So I am > not holding my breath for "the day Squeak gets popular" :) > >> I am in no position to recommend anything here, but I will just the >> same. Please forgive me. I recommend that Squeak not be killed off, >> or >> merged. Let the fork live on. > > Nothing to forgive, I want to hear lots of opinions in order for me > to personally form an opinion about the idea. The "view" you present > above is a positive one of a forked world. The reality can be harsher: > > Take XFree86 vs XOrg for example. The history there is complicated > but the fact remains - XOrg started, added lots of "cool features" > quickly while XFree86 stood still, then when the developers started > heavily voting with their feet the distros also switched and XFree86 > was dead before it even hit the floor. > > There are mainly two aspects here that tells me that the above "bad > future of XFree86" is more likely to happen than the "good future of > Open/Net/FreeBSD": > > - Pharo may "sound" like it has a different agenda than Squeak.org > but IMO the large majority of Squeak.org developers share the Pharo > agenda. > Thus the differentiation is not there. Most people will just pick > the one with the most momentum, and that is Pharo. > > - Squeak.org is standing still. Sure, there are things being done by > some people, no doubt about that. But perception is *everything* and > from the outside it seems to be standing still. Even the squeak-dev > list is quieting down and that is a bad sign. > > > So although I share your basic view of cross pollinating forks being > a "Good Thing" and something we should embrace (see OLPC, > Squeakland, Croquet etc etc) such forks need to have a specific goal. > > IMHO Pharo is not such a fork, Pharo is still very much "generic" as > is Squeak.org. Pharo is more like "Squeak.org going agile" or > "Smalltalk, with less talk" :). And thus it resembles XOrg much, > much more than OpenBSD. > >> I cannot close without saying that "Phreak" would be a very bad name >> :-) > > Again, I wasn't even advocating a name change - although a name > change may be a good thing if we would merge. Also, I hate to say > it, but "Pharo" sucks pretty bad too I think, and you guys STILL > have attracted lots of developers :) :) > > Oh, and a final note: > > But what if Squeak.org is abandoned and everyone moves to Pharo, > what is so bad about letting that happen? It is NOT bad. But I think > we could do it in a smoother way and actually turn this into > something *positive*. > The merge could be turned into a real BOOST to Squeak/Pharo. > > regards, GÃ¶ran > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 28, 2009

Re: [Pharo-project] [squeak-dev] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by GÃ¶ran Krampe

Hi! Casimiro de Almeida Barreto wrote: > Em 28-06-2009 07:23, GÃ¶ran Krampe escreveu: >> (...) >> Possibly true, but Smalltalk, Squeak, Etoys and even Croquet have been >> around for quite some time now - and we haven't seen any real >> explosion yet. Croquet was meant to "explode" but hasn't. So I am not >> holding my breath for "the day Squeak gets popular" :) >> > I guess there are several issues when "explosion" (in the sense of wide > acceptance & popularity) is a target for a project. I'll enumerate some > of them that came to my mind: Note that *I* don't really care for any "explosion". I was merely saying that waiting for it to happen in order to gain something from it - is probably foolish :) [SNIP of 1-5] Note: I don't agree with that list, but I get your point. > IMHO Squeak.org "stillness" is happening because a point was reached > when boring work is necessary. IMHO the board should be looking for Nah, how come Pharo is doing all those things then?? I don't agree. > corporate support in order to have resources to support the "boring > work". As an example: some years ago there was momentum for the use of I generally do not agree with those that think "corporate support" or "paid work" is the solution. Sorry, I just don't. I just want a Squeak that I can use and help improve and that has a reasonable commit process, some nice goals and a reasonable leadership. :) I don't want a company deciding what happens with Squeak. Definitely not. > Again, a key issue is that perhaps there is just not enough people to > support splitting projects. Again, IMHO that is one the issues that > complicated the life of croquet. Not to mention that much of croquet > related to 3D optimization and acceleration in cross platform > environment... That I can agree with - we are quite few. >> Oh, and a final note: >> >> But what if Squeak.org is abandoned and everyone moves to Pharo, what >> is so bad about letting that happen? It is NOT bad. But I think we >> could do it in a smoother way and actually turn this into something >> *positive*. The merge could be turned into a real BOOST to Squeak/Pharo. > If everybody goes to Pharo it won't necessarily be a problem. The > problem will be if key people stand in one side or the other. Right... So I didn't disagree with *everything* you wrote :) regards, GÃ¶ran

June 28, 2009

Re: [Pharo-project] [squeak-dev] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by Schwab,Wilhelm K

GÃ¶ran, "Noone works on something because *someone else* told him to." - That is at best context-dependent, and untrue in general. Not meaning to give you a hard time, but people often do what other people tell/ask/convince them to do. "Personally I like the colors. I also don't equal "normal" with "professional". But such is taste!" - as I have said for years now, it has not been the look that Squeak has had (pardon me) so horribly wrong, it has been the feel. Meeting the expectations of one's customers is part of professionalism. Exceeding expectations can be even better. There is a room for leadership, but no place for active contempt for the user; IMHO, Squeak has long been held back by the latter. You seem to be saying that Pharo is getting a lot of stuff right, so let's merge now. Pharo is getting a lot of stuff right precisely because it has forked, giving us the freedom to change things. That needs to go on for a while. The result will be a lean well-factored system that can be the basis for any tools or toys anyone wants to create. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of GÃ¶ran Krampe Sent: Sunday, June 28, 2009 10:55 AM To: The general-purpose Squeak developers list Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean) Hi! Ian Trudel wrote: > 2009/6/28 GÃ¶ran Krampe <goran(a)krampe.se>: >> Possibly true, but Smalltalk, Squeak, Etoys and even Croquet have >> been around for quite some time now - and we haven't seen any real explosion yet. >> Croquet was meant to "explode" but hasn't. So I am not holding my >> breath for "the day Squeak gets popular" :) > > Sometimes being popular means doing normal things. Smalltalk is an > unusual programming language (in the sense of mainstream) with an > overly eccentric environment in Squeak. Then there are Croquet, Etoys, > and so on. It's hardly a break through if it's only "more" eccentric > than eccentric. Don't you think? Not sure what you mean there. > The look-and-feel is designed for children. It's colourful, joyful, it > bleeps and blink. How many professional developers are children? How > many children are on this list? Enough with that already! Can we have > a normal look-and-feel? A professional look-and-feel. =) Personally I like the colors. I also don't equal "normal" with "professional". But such is taste! > Squeak is stuck in some time warp, where the surrounding world is on > stand still. It should however consider that we are living in 2009 and > have needs of 2009. We need a different usability, developer tools and > we have different goals. Note that talking about what we "need" and what other people "want" is not really that fruitful. We get what we *do*, or in other words - if someone feels it is important enough to spend time on it - it will get done. Noone works on something because *someone else* told him to. > For example, Squeak hardly support the > requirements of my distributors, which makes it overly challenging for > me to consider Squeak as our platform of development. Elaborate? > Squeak doesn't need a killer app. It needs to be spruced up and put > back on track. Honey moon is over, it's time to get real. Hehe, I really don't agree. :) Squeak *is* real. We already have our killer app (Seaside). We do need to clean shit up though (and I am not talking about UI primarily) and get the improvement process working. Currently Squeak.org is getting smashed (again, I don't have hard numbers, but I think I am right) by Pharo when it comes to hard, concrete, nitty gritt work getting done. regards, GÃ¶ran _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 28, 2009

Re: [Pharo-project] [squeak-dev] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by GÃ¶ran Krampe

Hi! Ian Trudel wrote: > 2009/6/28 GÃ¶ran Krampe <goran(a)krampe.se>: >> Possibly true, but Smalltalk, Squeak, Etoys and even Croquet have been >> around for quite some time now - and we haven't seen any real explosion yet. >> Croquet was meant to "explode" but hasn't. So I am not holding my breath for >> "the day Squeak gets popular" :) > > Sometimes being popular means doing normal things. Smalltalk is an > unusual programming language (in the sense of mainstream) with an > overly eccentric environment in Squeak. Then there are Croquet, Etoys, > and so on. It's hardly a break through if it's only "more" eccentric > than eccentric. Don't you think? Not sure what you mean there. > The look-and-feel is designed for children. It's colourful, joyful, it > bleeps and blink. How many professional developers are children? How > many children are on this list? Enough with that already! Can we have > a normal look-and-feel? A professional look-and-feel. =) Personally I like the colors. I also don't equal "normal" with "professional". But such is taste! > Squeak is stuck in some time warp, where the surrounding world is on > stand still. It should however consider that we are living in 2009 and > have needs of 2009. We need a different usability, developer tools and > we have different goals. Note that talking about what we "need" and what other people "want" is not really that fruitful. We get what we *do*, or in other words - if someone feels it is important enough to spend time on it - it will get done. Noone works on something because *someone else* told him to. > For example, Squeak hardly support the > requirements of my distributors, which makes it overly challenging for > me to consider Squeak as our platform of development. Elaborate? > Squeak doesn't need a killer app. It needs to be spruced up and put > back on track. Honey moon is over, it's time to get real. Hehe, I really don't agree. :) Squeak *is* real. We already have our killer app (Seaside). We do need to clean shit up though (and I am not talking about UI primarily) and get the improvement process working. Currently Squeak.org is getting smashed (again, I don't have hard numbers, but I think I am right) by Pharo when it comes to hard, concrete, nitty gritt work getting done. regards, GÃ¶ran

June 28, 2009

Re: [Pharo-project] [squeak-dev] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by GÃ¶ran Krampe

Hi! StÃ©phane Rollandin wrote: > My point of view: > > Pharo people weren't happy with the way Squeak was developed, so they > started their own project and now its development goes well: good for > them. It seems like a lot of people are actually interested and working > in Pharo; again: good for them. "Them" is the wrong word. It is rather "a lot of us". And "good for us". > Now I do like Squeak better, so I stayed here (beside, it would be a > hell of a work to port my code to Pharo, with all the "cleaning up" that > happened there). There is always work in porting over to new versions of Squeak. If we cross pollinate then you will end up facing the exact same issue. And also, you can always "lag" a release or two - quite common for larger projects. > Why should I even consider letting Squeak die, or > merging it into Pharo? Because if the "trend" I am perceiving (I may be wrong) continues then there will be very few of us left working on the Squeak 3.10 lineage under the Squeak.org flag. And the fewer there are the more likely they will jump over too. > Of course cross-pollination between the two > project is something worth reaching for, but I can't see how Squeak > doing harakiri is an adequate response to this challenge. Well, if you consider a merge to be harakiri - then I agree it sounds frightening :) > Squeak development slowed down quite a bit. So what ? That's something > we can discuss here in squeak-dev. No urge to surrender to Pharo IMHO. IMHO this kind of phrasing and thinking - "urge to surrender" etc, is the wrong way of looking at it. It is not some kind of war! Remember that before Pharo was started all those developers were working on Squeak. We are ALL Squeakers. We ALL want Squeak in the large sense to move on and improve. We all want a good solid base to do our work in, and a nice community to share. We all want fast turnaround on bug fixes and contributions etc. I just want us to do the *smart* thing here. regards, GÃ¶ran

June 28, 2009

Re: [Pharo-project] [squeak-dev] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by Schwab,Wilhelm K

A partial reply on the topic of education: in the spirit of Alan's "The Computer Revolution Hasn't Happened Yet" talk, it will likely be a while (perhaps decades) before before people start to figure out how to make real progress in education through computers. However and whenever it happens, I will go out on the following limb: it will be adults who enable it. There is nothing wrong with Pharo's focus on "grown-up software," and that should actually be encouraged. Toys can easily be built on top of such a subtrate, but a toy is unlikely to be a good foundation for tools. Since we have uses for tools and toys, the sound approach is to start with the tools and build the toys on top of the same foundation that Pinesoft and others use to serve paying customers. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of GÃ¶ran Krampe Sent: Sunday, June 28, 2009 5:24 AM To: The general-purpose Squeak developers list Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean) Hi! (still cross posting, hope you don't mind) Gary Dunn wrote: > I am new here and not really qualified to comment on this issue. > Please take my input as having good intentions. Specifically, I do not > want to start a flame war over the pros and cons of various projects. Nah, we don't do flame wars in the Squeak community. Well, not bad ones at least :) > There is much to learn from the history of the BSD community. > (Disclaimer: I am a huge fan of FreeBSD.) The FreeBSD project began > with the goal of creating an open-source OS for Intel i386 hardware > that was as faithful as possible to BSD Unix. In time the developers > were going in three directions. One group wanted high performance, a > second wanted portability to every possible platform, and a third > wanted high reliability and security. There were also the usual > personality conflicts and differing opinions on how to manage the project. > Eventually it forked, twice, giving us FreeBSD, OpenBSD, and NetBSD. > Each has its own personality, its own strengths. The good news is they > cross-pollinate each other. Yeah, that would be a positive future. And I have in fact earlier strongly advocated the fact that we need to "live with forks" because we already have several of them (like Croquet, OLPC etc). But see below... [SNIP] > It looks to me like Pharo is a Smalltalk for building grown-up apps. > Very much like the Smalltalk I began with, which produced apps with > the look and feel of the host Microsoft Windows. I think there is a > need for that. I take it Pharo is new, and as such it has been luring > developers away from Squeak. The potential for good in this outweighs > whatever the negative consequences may be, because, like the BSDs, the > Squeak developers can always pull in what they like from Pharo. In a "perfect world", yes. I even started the DeltaStreams project with these cross pollination scenarios in my head. > Do not confuse a fork with a divorce. Think of it as mitosis. The more > the merrier. Yes, that is also the way I have argued about it. See: http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.h… > I believe that the impact of Squeak on education has yet to be realized. > The necessary hardware -- the visionary Dynabook -- is just appearing. > It will be years before there are enough skilled teachers for the > critical mass required for the paradigm shift to occur. And there is > the culture change, so difficult in a field as institutionalized as > modern education. What we have been seeing are the Smalltalk explorers > and trail blazers, the pioneers to whom we will someday owe an > enormous debt of gratitude. Possibly true, but Smalltalk, Squeak, Etoys and even Croquet have been around for quite some time now - and we haven't seen any real explosion yet. Croquet was meant to "explode" but hasn't. So I am not holding my breath for "the day Squeak gets popular" :) > I am in no position to recommend anything here, but I will just the > same. Please forgive me. I recommend that Squeak not be killed off, or > merged. Let the fork live on. Nothing to forgive, I want to hear lots of opinions in order for me to personally form an opinion about the idea. The "view" you present above is a positive one of a forked world. The reality can be harsher: Take XFree86 vs XOrg for example. The history there is complicated but the fact remains - XOrg started, added lots of "cool features" quickly while XFree86 stood still, then when the developers started heavily voting with their feet the distros also switched and XFree86 was dead before it even hit the floor. There are mainly two aspects here that tells me that the above "bad future of XFree86" is more likely to happen than the "good future of Open/Net/FreeBSD": - Pharo may "sound" like it has a different agenda than Squeak.org but IMO the large majority of Squeak.org developers share the Pharo agenda. Thus the differentiation is not there. Most people will just pick the one with the most momentum, and that is Pharo. - Squeak.org is standing still. Sure, there are things being done by some people, no doubt about that. But perception is *everything* and from the outside it seems to be standing still. Even the squeak-dev list is quieting down and that is a bad sign. So although I share your basic view of cross pollinating forks being a "Good Thing" and something we should embrace (see OLPC, Squeakland, Croquet etc etc) such forks need to have a specific goal. IMHO Pharo is not such a fork, Pharo is still very much "generic" as is Squeak.org. Pharo is more like "Squeak.org going agile" or "Smalltalk, with less talk" :). And thus it resembles XOrg much, much more than OpenBSD. > I cannot close without saying that "Phreak" would be a very bad name > :-) Again, I wasn't even advocating a name change - although a name change may be a good thing if we would merge. Also, I hate to say it, but "Pharo" sucks pretty bad too I think, and you guys STILL have attracted lots of developers :) :) Oh, and a final note: But what if Squeak.org is abandoned and everyone moves to Pharo, what is so bad about letting that happen? It is NOT bad. But I think we could do it in a smoother way and actually turn this into something *positive*. The merge could be turned into a real BOOST to Squeak/Pharo. regards, GÃ¶ran _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 28, 2009

Re: [Pharo-project] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by StÃ©phane Ducasse

> > Sure, that is an aspect of it all of course. On the other hand - new > fresh work is always done at the "frontier" so for me as a developer > wondering where my time is best spent it is still a valid question I > need to ask myself: > > Where do I put my effort? In latest Squeak.org or latest Pharo? I have the answer :) But if you want to find your answer: take your preconditions take pharo goals do the same with squeak and check. > I agree that as a *user* I might still deploy/develop in a good old > and > tried image - say 3.10.2 or whatever. No not whatever. The ones were people put responsibility to produce. > Tonight I just spent time trying/testing my Blackfoot package in the > Seaside Pharo image. (Works fine btw!) This is time I am spending in > order to make my work (in this case Blackfoot) available to Pharo > people. And thus the question about where these two projects are going > is highly relevant to me. Pharo path is stated on the wiki: - clean - lean - better for the better - changing if necessary We want to make sure that we get agile again to invent new STUFF any new stuff. So if you come with URI working and tests, with network improvements, cruft removal..... we will integrate (modulo the license). Stef > > regards, GÃ¶ran > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 28, 2009

Re: [Pharo-project] The future of Squeak & Pharo (was Re: [ANN] Pharo MIT license clean)

by StÃ©phane Ducasse

Igor I think that this is too early. Let us deliver something first and see. I want to see what we can really do. Can we create a community of doers? Can we create wealth and a cool community? Then some people can see how we can merge and if this makes sense Stef >>> >> 2. Take some decisive action and "merge" the two in some *smart* way >> beneficial to both. Impossible? I hope not. >> >> 3. Just kill off squeak.org. A mercy kill :). Then people could move >> over to Pharo without having to think about it - there is no other >> "Squeak". >> >> Eh, well, my analysis is probably full of silly holes here. Looking >> at >> the above, 1 and 3 feels less nice. So how could a "merge" look that >> would be attractive to *both* camps? I call the theoretical merged >> project Phreak below (but I am not proposing name changes etc, but I >> need a name to use in the text). >> >> Pharo characteristics: >> >> - A small "benevolent dictator" board. Lots of action, less talk. >> - Has a very clear stated "direction". >> - Has a website using CMSBox. >> - Uses Google code for issue tracker and wiki. >> - Has Mailman mailinglists and downloads at gforge.inria.fr (I think) >> >> Squeak.org org characteristics: >> >> - Has an elected SOB, an election process and a Team model. The >> jury is >> still out I think, we seem to have lots of trouble "getting shit >> done". >> - Has very little stated "direction" at the moment. >> - Has a website using Swazoo. >> - Uses Mantis, Swiki, file archive and Mailman on a community paid >> Hetzner server. >> >> Now... why would Squeak.org want to merge with Pharo? >> >> Pros: Get momentum back. 1 + 1 = 2. A revitalization. Very important! >> >> Cons: The SOB & Team model would probably have to be dropped. The >> work >> made since Pharo forked may or may not be a "lost cause", that >> depends >> on if Phreak is interested in utilizing that work. Other cons? >> >> ...and Pharo? >> >> Pros: An influx of developers. A much stronger position as Phreak >> would >> be Squeak + Pharo. No "compatibility" to worry about, Squeak is out >> of >> the picture. >> >> Cons: Some people in Pharo may perceive such a merge as dangerous >> since >> they might be afraid that certain aspects of Squeak.org (that Pharo >> was >> created in order to escape from) is coming back "knocking on the >> door". >> >> I personally don't think there is such a danger if Phreak simply >> adopts >> the simple organisation of Pharo (with board and all) BUT... since it >> would make the Pharo community much *larger* the effects of that >> growth >> need to be taken into account. But Pharo should not fear growth, >> because >> that would be an odd position. >> >> How could a merge be done practically? I really don't know :). And I >> must stop typing now, this post is waaaaay to long anyway and I have >> probably stepped on too many toes already. >> > > Hello Goran. > You are definitely didn't stepped on any of my toes/toys. And i would > certainly sacrifice my SOB membership (if this is a sacrifice), to see > things moving & progressing as fast as they do in Pharo. > As many others, i eagier to see the squeak/pharo/phreak shining - make > it cool & modern software. The rest of things is barely bothering me. > > What i like in Pharo, that they make decisions on strictly technical > basis - no politics. If code is good - it candidate to be included. If > code stinks - its a candidate to be excluded. Simple concept :) > > For anyone, interested in my opinion: > i would put a huge +1 for a merge on a Pharoer's conditions. > >> regards, GÃ¶ran >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 28, 2009