- Pharo-dev - lists.pharo.org

[Pharo-project] Slides for a talk on "Why I Still Use Smalltalk" for comments
by Stephen Travis Pope Jan. 6, 2013

Jan. 6, 2013

Hello all, I've put together a set of slides for a 90-minute lecture/demo on "Why I Still Use Smalltalk" to be given to a colloquium of graduate media arts and technology students at UCSB (where I taught from 1996-2010). I up-loaded the slides for your comments; there's a 19-page PDF file (6 slides per page) at, http://HeavenEverywhere.com/STP_ST80_Talk_Slides.pdf Your comments/questions are welcome... (The demo at the start will be using VisualWorks to build the canonical up/down counter.) (Slide 12 is me and the head of the composition department at UCSB, both in 1984, for context.) stp -- Stephen Travis Pope Santa Barbara, California, USA http://HeavenEverywhere.com Begin forwarded message: > From: Stephen Travis Pope <stephen(a)heaveneverywhere.com> > Date: October 26, 2012 12:47:55 PM PDT > To: vwnc <vwnc(a)cs.uiuc.edu> > Cc: Stephen Travis Pope <stephen(a)heaveneverywhere.com> > Subject: Outline of a talk on "Why I Still Use Smalltalk" for comments > > > Hello all, > > I'm planning to give a colloquium called "Why I Still Use Smalltalk" for the graduate students at UCSB, and wanted to solicit your comments on the outline. > > stp > > -------------------- > > Why I Still Use Smalltalk > > Graduate Colloquium > UCSB Graduate Program in Media Arts and Technology > November, 2012 > Stephen Travis Pope, stephen(a)FASTLabInc.com > > -------------------- > > Proposal > > Title: Why I Still Use Smalltalk > > Abstract > > The Smalltalk-80 programming system is celebrating its 30th birthday this year (Smalltalk-80 version 2 was released and documented in a series of books in 1982). The system was the first popular software development tool that incorporated a number of features we take for granted today, including an object-oriented programming language, a comprehensive open-source class library, an integrated window-based development environment, and a cross-platform virtual-machine-based delivery system. Nevertheless, Smalltalk has nowhere near the installed base or the mindshare of lesser peers such as C++ or Java, or more modern descendants such as Python or Ruby. This talk will introduce the Smalltalk system's language, libraries and tools, outline its history, and discuss the reasons why it is not more widely used. Several aspects of the Smalltalk system make it especially good for developing multimedia applications, and these will be introduced with examples from the last 30 years. The presenter was among the very first to use Smalltalk for real-world applications, and worked on the Smalltalk team at Xerox PARC and their spin-off ParcPlace Systems from 1986-94. He still uses Smalltalk (now available in both commercial and free versions) for his day-to-day work. > > Presenter > > Stephen Travis Pope is a software engineer and composer based in Santa Barbara. He taught at UCSB (in the departments of Music and Computer Science, and the Graduate Program in Media Arts and Technology) from 1996-2010, and is now known as FASTLabInc.com (for multimedia software) and HeavenEverywhere.com (for music and film). > > ---------------------------- > > Outline > Introduction > Demo > What Is Smalltalk? > The Language > The Libraries > The Environment > A Brief History > Smalltalk Leaves PARC > C++, ObjectiveC and Java > Smalltalk Today > Why I Still Use Smalltalk > > Introduction > Overview > My background in 1981 > > Demo > Counter Example with GUI > > What Is Smalltalk? > Language > Libraries > Tools, IDE > Methodology > Note: "OO is not Enough!" > > The Language > Terse, expressive, readable > Everything is an Object (really, everything) > All activity is message-passing > Trivial syntax, no reserved words > true, false, nil, self, super, thisContext > Control structures written in Smalltalk > Messages to Booleans, Blocks, etc. > Means they're extensible (!) > aCollection do: [ :item | Transcript show: item printString] > Keyword syntax - messages with > 1 argument alternate keyword/argumentâ¦ > anArray at: 1 (getter) > anArray at: 1 put: 'hello' (setter) > r := Rectangle top: 1 left: 1 width: 10 height: 10 > Fully Reflective > (isKindOf:, understands:, â¦) > Compiles to a virtual machine language (normally) > > The Libraries > Everything is an Object > Polymorphism (heavily used) > E.g., many implementations of at:put: or + > OO Design Patterns > Composite, Adaptor, Singleton, MVC, Visitor, â¦ > Magnitudes, Collections and Streams > Graphics and Windows > All classes are extensible (!) > Example: aString asPath: sepChar > Try this in C++ or ObjC... > > The Methodology > OO A/D Methods (OBA) > OO Design Patterns > Domain-specific Languages > > The Tools > Window-based GUI and Tools > Multi-desktop (Projects) > Browsers, Inspectors and Editors > Rules of Reuse (Programmer as Reader project) > Pluggable look-and-feel > Code-sharing tools: change-lists, Envy > Open-source Tools (!!) > > Tool Demo > Browsers > Code in DB package, class, category, method > Compile 1 method at a time > "Programmer as Reader" facilities > Senders, implementors, class/variable references > Flavors of browsers: protocol, hierarchy, namespace, etc. > Debugger > Just like the browser(!!!) > Fix and continue > CASE Tools > Change lists, packages, projects > > The Environment > VI/VM Architecture > VI like APL workspaces, LISP core files > Snapshot/restart (relation to BOSS files) > VM - "cheat but don't get caught" > Thinks it's an operating system > "The OS is only there for all the things you forgot to put in the language" > Scheduler, file system, network drivers, etc. in Smalltalk > Light-weight processes and scheduler in Smalltalk > Simple VM: Byte-code interpreter > High-performance VM: JIT Optimizing > Native code caches > Polymorphic inline caches > > Other Novel Aspects > Other languages in Smalltalk (Lisp, Prolog, etc.) > Compiler frameworks > Smalltalk-as-OS (running on naked hardware) > OOP and AI > Frames/objects, rules, logic, etc. > Early "block diagram compilers" > > Smalltalk and Multimedia > Early Computer Graphics > BitBLT pixel graphics > SPIM and graphics contexts > Music with Smalltalk > Real-time FM on the Alto > Real-time scheduling for MIDI > Music notations in Smalltalk > > Early (1980s) Applications > ThingLab > ThinkerToy > Graphical programming > Analyst > AI, Multimedia, Graphical Programming > Chinese Temple Design ToolKit > Models of process > MOBY, DoubleTalk > Petri Nets > ObjectWorks/C++ > ST-like IDE for C++ > > Early (1980s) Music Applications > HyperScore ToolKit/MODE > Music composition and notations > SoundKit > Music signal processing > Kyma > Cross-compilation for a DSP > Harmonic Analysis Tool > Chord/Harmony analysis expert system > Smoke > Flexible music representation language > > The Risks > Breaking the system (really easy) > Also easy to recover > VI Bloat > Strippers, Whittlers > Incompatible changes > Tools for merging packages > > A Brief History > Flex and Smalltalk-72 > Simula, Sketchpad, Augment and other precursors > PARC Learning Research Group > Smalltalk-76 and the Xerox Alto > Mostly ASCII > Personal Dynamic Media Paper in "Computer" 3/1977 > Smalltalk-78 > Browser, NoteTaker project > Smalltalk-80 V1 > 3rd complete rewrite before they had an installed user base > LRG now Systems Concepts Lab > 1981 Byte Magazine Special Issue > Context: Xerox Alto, MIT LISP Machines > Smalltalk-80 V2 > Incorporated feedback from first-round users > MVC used for all GUIs > Late-80s changes > Exceptions and I/O > Host window system interface > DLLCC > Compiler Framework > Namespaces, Packages > ANSI Smalltalk (1993-98) > > Smalltalk Leaves PARC > Getting Smalltalk to Users > (Porting to non-Xerox hardware) > Early licensees: Apple, H-P, Tektronix > Tex 44404 demo - http://www.youtube.com/watch?v=8yxCJfayW-8 > Berkeley SOAR and SPARC design > XSIS and the Analyst > ParcPlace Systems (spun off in 1988) > Digitalk's Smalltalk/V on early PCs (1984) > These merge in 1995 > GNU Smalltalk (free) > > C++, ObjectiveC and Java > C with Classes - hybrid language; class is like a struct > ObjectiveC - C + Smalltalk in 1 program > Java ("what a shame they didn't copy everything.") > > Why it failed (in the 1990s) > Price (relative to what?) > Perception of compute demands (requires graphics and mouse, lots of RAM, â¦) > Performance Issues > VM performance and optimization > GC overhead and generation scavenging > Performance much better on Xerox machines > VM in microcode > Tagged architecture > Not upward compatible with anything > "Everything you know is wrong" > C hybrids appeared to get you most of the way thereâ¦ > > Smalltalk Implementations > Cincom Smalltalk (commercial) > ObjectStudio (commercial) > Squeak (free, based on Apple V1) > Pharo (stripped Squeak) > > Coral (for scripting) > Amber (runs on JavaScript VM) > Bistro (runs on JavaScript VM) > S# (runs with .NET) > > Smalltalk/X > VisualAge > Dolphin > > Smalltalk Today > DLLCC and Slang > Seaside (for web apps) > Gemstone (scalable OODB) > > STIC/ESUG > Smalltalk.org > Squeak community > > Relatives/Derivatives > ObjectiveC > Self (no classes, VM advances) > Lively (JavaScript libraries and tools) > F-Script > Strongtalk > SuperCollider > > Reasons Why I Still Use Smalltalk > 3 top reasons: Productivity, productivity and productivity > Language features > Simplicity, scalability, stability > Keyword syntax (!!) > Library features > Comprehensive, consistent, stable, extensible (!!) > All source close at hand > Pluggable L&F > Development Environment > Open tools (!!!) > Integrated, cross-platform > Fix/restart in debugger (!!!) > VI/VM architecture > Code lives in DB, easy change management, publication, crash recovery, etc. (!) > > Why I complain about other languages > "Object-Oriented is not Enough" (Goldberg & Pope 1989 article) > âThe Computer Revolution Hasnât Happened Yetâ (A Kay quote) > Issues center on libraries and tools rather than the languages themselves > Lively for JavaScript > ?? for Python > > What I do use (other than Smalltalk) > C++ > Standard, fast > XCode > Python > Hybrid language > Good libraries (inconsistent, non-OO) > Poor tools > Good integration with C/C++ via ctypes > Curse of version 3 > Octave/MATLAB > Terse, good matrix support > Extensive code base > > -- > > Stephen Travis Pope Santa Barbara, California, USA http://HeavenEverywhere.com > >

1 0

[Pharo-project] broken builds
by Camillo Bruni Jan. 4, 2013

Jan. 4, 2013

looks like the latest image/vm combination makes the command-line fail... On the Ci server I cannot run any command-line tools anymore with the latest.zips :/ On the Mac: - latest stack VM fails to open latest 20 image - latest cog VM fails to open latest 20 image - latest pharo VM fails to open latest 20 image with an older cog VM I can open the image without issues: Smalltalk vm version 'CoInterpreter VMMaker-oscog-IgorStasenko.162 uuid: e4554f9a-cc90-4826-a807-ac282b782fe4 Jul 26 2012 saving the image with the old VM immediately makes it work with the latest vms :?

1 0

Re: [Pharo-project] NativeBoost design and deployment
by Igor Stasenko Jan. 4, 2013

Jan. 4, 2013

On 4 January 2013 09:51, Torsten Bergmann <astares(a)gmx.de> wrote: >> yes it needs sources (indirectly) to bind method's argument names >> during code generation. > > Sad. So this is currently a showstopper in using NB > in deployments where one would not like to give the > sources away. > > If we want (commercial) developers to write applications > in Pharo there should be a fix for that. > Yes. I don't like it either. It needs only the arg names (and their order) and for that, it involves a compiler to parse source and generate AST. Which can be completely avoided if temp names is stored somewhere after compilation. > Thanks > T. -- Best regards, Igor Stasenko.

2 1

[Pharo-project] NativeBoost design and deployment
by Torsten Bergmann Jan. 4, 2013

Jan. 4, 2013

When one deploys an image one usually requires ONLY the image - not the source or changes file. An "image locker" code would look like this: SmalltalkImage checkSourcesFileAvailability: false. SmalltalkImage checkChangesFileAvailability: false do disable acording warnings when source/changefile is removed. If one uses NativeBoost in such a deployment scenario, for instance the NBWin32Shell shellBrowse: 'http://www.google.de' functionality the internal code (due to missing source) now looks like this shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5 <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll' Hence the t1 ... t5 parameters. NativeBoost is in this situation not able to match the FFI parameters and throws an error "Could not find accessor for variable ..." Try yourself without a changes and source file. This makes NativeBoost not very deployment friendly and unusable in such a "minimal deployment" scenario ... Any comments? Thanks T.

1 0

Re: [Pharo-project] [squeak-dev] Mine-able ideas?
by David T. Lewis Jan. 3, 2013

Jan. 3, 2013

On Wed, Jan 02, 2013 at 05:26:25PM -0800, tim Rowledge wrote: > > On 02-01-2013, at 4:15 PM, "David T. Lewis" <lewis(a)mail.msen.com> wrote: > > > > Do you have a reference to the sensible compiled method format? I think > > I recall some discussions on that topic, but I don't recall when or by > > whom. > > I was thinking of the now-ancient 'NewCompiledMethod', going back to about 1997. The last I heard on the subject was about 5 years ago. Ah, right, it's all coming back to me now. Thanks. > But.. > > > > But really, what are we missing? We have CompiledMethodTrailer that appears to > > provide an infinitely extensible mechanism for inventing new kinds of source > > pointers. > > ? it reads as if that might provide the same result. Namely having the source pointer for each method be a proper oop, with all the obvious advantages over a weirdly encrypted 24bit number hidden within some bytes at the end of a byte array > In principle, I think yes. Igor Stasenko created the CompiledMethodTrailer, which has provided a really nice way to keep the existing formats working while allowing all sorts of extensions. I'm not sure if he had in mind to implement source pointers as first class objects, but it seems like it would be a straightforward extension. Cross posting to pharo in order to lure Igor back into the discussion ;-) Dave

2 1

[Pharo-project] Extracting a ZipArchive in 2.0
by Vanessa PeÃ±a Araya Jan. 3, 2013

Jan. 3, 2013

Hi, I want to extract a ZipArchive in Pharo 2.0, as the title says. I'm trying to do it with this: zipArchive extractAllTo: aDirectory informing: bar overwrite: false I'm trying the new file system but my problem is that ZipArchiveMember calls a method called "assureExistence", which does not exist... anywhere. Has anyone experience something like this? Thanks, Vanessa.

3 4

Re: [Pharo-project] [squeak-dev] Mine-able ideas?
by Frank Shearar Jan. 2, 2013

Jan. 2, 2013

On 2 January 2013 22:17, Colin Putney <colin(a)wiresong.com> wrote: > > > > On Wed, Jan 2, 2013 at 4:18 PM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: >> >> http://blog.datomic.com/2012/10/codeq.html >> >> Executive summary: >> * Git gives version control over files >> * Clojure code typically has lots of functions or other chunks of code >> in one file >> * This means you can't ask for the version of a single unit of code >> * Static analyses over the files as they vary through time, dumped >> into a database, yields interesting stuff >> >> What they're calling "codeqs" ("code quantum") filetree folks would >> call a file, because filetree already splits everything (I think?) >> into bits, and versions everything at the "codeq" level by virtue of >> storing each bit in its own file: class definition, comment, method >> definition, etc. >> >> So we already have most of this stuff already - I couldn't live >> without my in-image method versions - but I'm wondering if anyone else >> can spot anything worth copying? > > > Nah. They're basically figuring out how to extract the semantic changes from > git, since git just treats the source code as opaque text. That gets them to > what Monticello has now. I guess there's a bit of "imagine what you could do > then!" that's unspecified. That was pretty much what I was thinking. And filetree preserves this fine-grained "code quantum"-sized version control. The only advantage I still see of lots-of-stuff-inna-file is that you can very quickly hop around a bunch of code. Our tools just don't work that way. They _could_. Noone's just ever hurt enough to display code in this fashion. It's easy enough: what's not so easy is to make that big blob of text efficiently editable such that you still keep track of the, for example, individual methods. (I'll leave aside the lack of syntax around method definition. That's not a big problem.) For instance: parse the entire file, find the method definitions, update the image by compiling them. (Handwave around the imperative hacks one could do.) > Which is not to say that it's a bad idea. I'd love to create a huge database > of, say, the update stream going back to the beginning, or the entire > contents of squeaksource. But... then what? > > Things that spring to mind immediately: > > - universal senders and implementors > - metrics like message sends per method or methods per class > - detection of package dependencies This would be a massive win. I took a bash a while ago at extending DependencyBrowser to work over one's package-cache to do this. I didn't get terribly far, probably largely to me being pretty ignorant about just about everything I needed to know. I have the half-completed work lying around. Maybe I should publish it somewhere! frank > - analysis of how long-lived packages change over time > - analysis of contribution and collaboration between coders > > and so on. > > But, what good is it? Might be interesting, maybe there's some research > papers to be written, but would it do us any good as a community? Would > there be useful tools that came out of it? Would it be worth the effort? > Hard to say. > > Colin > > >

1 0

[Pharo-project] Mine-able ideas?
by Frank Shearar Jan. 2, 2013

Jan. 2, 2013

http://blog.datomic.com/2012/10/codeq.html Executive summary: * Git gives version control over files * Clojure code typically has lots of functions or other chunks of code in one file * This means you can't ask for the version of a single unit of code * Static analyses over the files as they vary through time, dumped into a database, yields interesting stuff What they're calling "codeqs" ("code quantum") filetree folks would call a file, because filetree already splits everything (I think?) into bits, and versions everything at the "codeq" level by virtue of storing each bit in its own file: class definition, comment, method definition, etc. So we already have most of this stuff already - I couldn't live without my in-image method versions - but I'm wondering if anyone else can spot anything worth copying? frank

2 1

[Pharo-project] [ENH]: MCHttpRepository Authentication (Issue 6449)
by Sean P. DeNigris Jan. 2, 2013

Jan. 2, 2013

http://code.google.com/p/pharo/issues/detail?id=6449 We should be able to say, "MCHttpRepository logInto: serverUrl as: username withPassword: passwordString" Is there any use case for not using the server credentials with a particular repo i.e. myserver/ss has credentials, but myserver/ss/myrepo uses different/no credentials? If we assume that all repos with a given prefix will use the same credentials, the implementation will be much simpler... Conversation-starter in the inbox. Please take a look and comment, but do not integrate. Name: SLICE-Issue-6449-ENH-MCHttpRepository-Authentication-SeanDeNigris.1 Hack together an implementation to start the conversation. ***This should NOT be integrated*** -- View this message in context: http://forum.world.st/ENH-MCHttpRepository-Authentication-Issue-6449-tp4641… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 4

[Pharo-project] corrupt images on gforge
by Camillo Bruni Jan. 2, 2013

Jan. 2, 2013

see http://code.google.com/p/pharo/issues/detail?id=7196 I suggest someone other than me fixes it ;) to - add missing documentation - see how complicated everything is

3 2