December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Popularity or not of smalltalk?

by StÃ©phane Ducasse

jimmie I agree :)

Dec. 8, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by Gary Chambers

Fortunately not the case here at Pinesoft ;-) Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, December 08, 2010 3:50 PM Subject: Re: [Pharo-project] Popularity or not of smalltalk? > On 8 December 2010 03:16, David T. Lewis <lewis(a)mail.msen.com> wrote: >> Bravo, well and truly stated. >> >> (I can't help but wonder how many folks who talk about this stuff have >> actually encountered an "Enterprise" in real life, and if so why they >> are still so eager to impress these people, much less go to work for >> them.) >> > > Yeah.. It is familiar attitude towards big companies, which i don't > sharing. > > It is starting from first small things, like "i am so proud that i > working in huge company" , > which immediately rings the bell in my head with a thought: "so, maybe > you should start paying this company for being an employee of it?" > > All this shit: thinking BIG , we are big, we are many.. the common > enterprise-level indoctrination , which have nothing to do with > a) productivity > b) efficiency > c) quality of products/services > and could even have a reverse effect. > > So, that's why i DON'T care what enterprise-level people doing and > what they thinking about smalltalk. I KNOW that whatever they do, they > doing it wrong :) > > >> Thanks Jimmy, you have captured a lot of positive energy in a few words. >> >> Dave >> >>> Jimmie >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Dec. 8, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by Igor Stasenko

On 8 December 2010 03:16, David T. Lewis <lewis(a)mail.msen.com> wrote: > Bravo, well and truly stated. > > (I can't help but wonder how many folks who talk about this stuff have > actually encountered an "Enterprise" in real life, and if so why they > are still so eager to impress these people, much less go to work for them.) > Yeah.. It is familiar attitude towards big companies, which i don't sharing. It is starting from first small things, like "i am so proud that i working in huge company" , which immediately rings the bell in my head with a thought: "so, maybe you should start paying this company for being an employee of it?" All this shit: thinking BIG , we are big, we are many.. the common enterprise-level indoctrination , which have nothing to do with a) productivity b) efficiency c) quality of products/services and could even have a reverse effect. So, that's why i DON'T care what enterprise-level people doing and what they thinking about smalltalk. I KNOW that whatever they do, they doing it wrong :) > Thanks Jimmy, you have captured a lot of positive energy in a few words. > > Dave > >> Jimmie > > -- Best regards, Igor Stasenko AKA sig.

Dec. 8, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by StÃ©phane Ducasse

James can you create separated thread? Stef On Dec 6, 2010, at 6:51 AM, James Ladd wrote: > While pleading for Smalltalk support with a developer from a popular and great IDE company, I got the > following response (below) > > Is there anything I can do/show to prove or disprove the popularity of Smalltalk? > > Rgs, James. > > >>Hello James. > >>About Smalltalk plugin. Weel, Iâm not sure Smalltalk has a big audience now. Iâve never heard about commercial products based on Smalltalk. > >>Here, some statistics http://langpop.com/

Dec. 8, 2010

Re: [Pharo-project] Beta

by StÃ©phane Ducasse

marcus will deal with that. On Dec 8, 2010, at 3:53 PM, Stanislav Paskalev wrote: > Does the hudson build for Pharo 1.2 works now ? Please schedule it if > so and you'll have at least 1 tester :) > > Stanislav Paskalev (solar_sea) > > > > On Wed, Dec 8, 2010 at 4:39 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> I fixed the bad package name and we are now beta. >> :) >> >> So we should kill the tests and the pending issues. >> >> Stef >> >> >

Dec. 8, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by StÃ©phane Ducasse

On Dec 8, 2010, at 10:48 AM, Lukas Renggli wrote: > Very cool framework, I like it a lot! I definitely vote to eventually > replace HTTPSocket with Zinc HTTP Components. I would love that. We plan to open 1.3 Unstable 1 of january :) So if you have code for that let me know :) > > I wonder why ZnFixedClient is not a subclass of ZnHttpClient? I think > it would be cool to be able to use them polymorphic. > > Lukas > > > On 8 December 2010 09:26, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> Norbert, >> >> Thanks for you interest. >> >> On 07 Dec 2010, at 21:14, Norbert Hartl wrote: >> >>> I scanned the code a few days ago. I tried an initial port to gemstone. There are quite a few things to do. After discovering that there are really big changes from version to version and the existence of classes with suffixes Old and New made me stop the effort. I'm really missing a usable http client in gemstone but it seemed to be very hard to keep up with the port. >> >> This should be much better now: the whole confusion is now gone (the 'Old' categories and classes were moved into a separate MC package that should not be loaded unless you want to do historical research; the 'New' has been removed from existing categories). Please have another look. >> >> I assume that you have read the overview and getting started pages (http://homepage.mac.com/svc/Zinc-HTTP-Components) >> >> The category 'Zinc-HTTP-Core' contains a object model of the key building blocks of the HTTP protocol. Except for learning and teaching, this is not useful on itself. Building on top of the core are the classes in 'Zinc-HTTP-Server' for various clients and servers. The category 'Zinc-HTTP-Support' contains helpers for the implementation, many of which can be considered portability enablers (much like Seaside has them). >> >> Now, why is there not just one good client, why are there 4 different ones ? >> >> Because different users have different requirements, because each of them has different features, complexity and above all, a different interface. Part of this is also a search for the ideal API. >> >> ZnClient is the simplest one: some class methods to fire off one shot requests. >> >> ZnFixedClient is useful to connect to a single server and reuse the connection for multiple requests, like with a web services API. >> >> ZnHttpClient is a builder like interface (think of Gofer), it also has some extra features. >> >> ZnHTTPSocketFacade is a replacement for the current Pharo/Squeak HTTPSocket API. In my development images, this is active, which means that all HTTP functionality (for MC for example) is handled by Zinc HTTP - a case of eating my own dog food. >> >> On the server side there is ZnServer which can be customized with a delegate and authorizer. A static web file server, a Monticello server as well as a Seaside adaptor are available. >> >>> Do you port an existing library to smalltalk or do you figure out how it should be done right now? And what do you think about going towards cross-platform? This would need a decision if you are willing to integrate grease/sport in your client. I can imagine that this is not wanted per se because it introduces dependencies. It will be just very hard to do it cross-platform if you do not. >> >> The first goal of Zinc HTTP is to be useful for Pharo, to replace existing HTTP functionality in the image. Hence portability is not high on the list. Like you said, building on top of a portability layer would mean external dependencies that would most probably conflict with the first goal. But I am not against portability (most of the code except for some obvious missing crypto stuff still runs on Squeak as well). We can always try to find a solution. >> >> Regards, >> >> Sven >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Dec. 8, 2010

[Pharo-project] Issue 3387 in pharo: Package name should not contain crptic characters

by pharo＠googlecode.com

Status: Accepted Owner: stephane.ducasse Labels: Milestone-1.3 Difficulty-Easy New issue 3387 by stephane.ducasse: Package name should not contain crptic characters http://code.google.com/p/pharo/issues/detail?id=3387 We should make sure that we cannot write package with cryptic characters.

Dec. 8, 2010

Re: [Pharo-project] Beta

by Stanislav Paskalev

Does the hudson build for Pharo 1.2 works now ? Please schedule it if so and you'll have at least 1 tester :) Stanislav Paskalev (solar_sea) On Wed, Dec 8, 2010 at 4:39 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I fixed the bad package name and we are now beta. > :) > > So we should kill the tests and the pending issues. > > Stef > >

Dec. 8, 2010

[Pharo-project] Issue 3386 in pharo: DosFileDirectory>> checkName: aFileName fixErrors: fixing

by pharo＠googlecode.com

Status: Accepted Owner: stephane.ducasse Labels: Milestone-1.2 New issue 3386 by stephane.ducasse: DosFileDirectory>> checkName: aFileName fixErrors: fixing http://code.google.com/p/pharo/issues/detail?id=3386 DosFileDirectory>> checkName: aFileName fixErrors: fixing "Check if the file name contains any invalid characters" | fName badChars hasBadChars | fName := super checkName: aFileName fixErrors: fixing. badChars := (#( $: $< $> $| $/ $\ $? $* $"), ((0 to: 31) collect: [:n | n asCharacter])) asSet. hasBadChars := fName includesAnyOf: badChars. (hasBadChars and:[fixing not]) ifTrue:[^self error:'Invalid file name']. hasBadChars ifFalse:[^ fName]. ^ fName collect: [:char | (badChars includes: char) ifTrue:[$#] ifFalse:[char]]

Dec. 8, 2010

Re: [Pharo-project] Comments or no integration: a simple choice foryou

by StÃ©phane Ducasse

Yes good script. Stef On Dec 7, 2010, at 4:35 PM, Alexandre Bergel wrote: > Indeed. We could also refine it further by identifying the most used classes for a representative sample of the Pharo ecosystem. > It still says StandardFonts, SystemChangeNotifier, FreeTypeSettings, MCPackage, ... have to be commented > > Alexandre > > > On 7 Dec 2010, at 12:29, Gary Chambers wrote: > >> Naturally, every method of a class references its own class as a literal... >> Also, class-side methods not accounted for. >> >> Easy enough to change the script to higlight only external references: >> >> d := Dictionary new. >> Smalltalk allClasses, (Smalltalk allClasses collect: [:cls | cls class]) do: [ :cls | >> cls methods do: [:cm | (cm literals select: [:l | l isKindOf: Association ]) >> do: [:assoc | >> (assoc value isBehavior and: [assoc value ~~ cls]) >> ifTrue: [d at: assoc value put: (d at: assoc value ifAbsentPut: [0] ) + 1]]]]. >> associations := d associations asSortedCollection: [:a1 :a2 | a2 value < a1 value]. >> associations select: [:ass | ass key comment isNil or: [ass key comment isEmpty or: [ass key comment asString includesSubString: 'xxxxxx']]] >> >> Regards, Gary >> >> ----- Original Message ----- From: "Alexandre Bergel" <alexandre(a)bergel.eu> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, December 07, 2010 2:53 PM >> Subject: Re: [Pharo-project] Comments or no integration: a simple choice foryou >> >> >> A small script that gives the most referenced classes that are not commented: >> I run the test in an image with Moose and Spy. >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> "Get the number of references per class" >> d := Dictionary new. >> Smalltalk allClasses do: [ :cls | cls methods do: [:cm | (cm literals select: [:l | l isKindOf: Association ]) >> do: [:assoc | >> (assoc value isBehavior) >> ifTrue: [d at: assoc value put: (d at: assoc value ifAbsentPut: [0] ) + 1]]]]. >> associations := d associations asSortedCollection: [:a1 :a2 | a2 value < a1 value]. >> >> "Get the classes that are not commented" >> associations select: [:ass | ass key comment isNil or: [ass key comment isEmpty or: [ass key comment asString includesSubString: 'xxxxxx']]] >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> The first 30 entries: >> SortedCollectionTest->307 >> HeapTest->304 >> IntervalTest->250 >> DictionaryTest->192 >> BagTest->167 >> RxMatcherTest->166 >> PluggableTextMorph->149 >> MooseModel->144 >> UIThemeWatery2->132 >> SystemChangeNotifier->132 >> PPSmalltalkParserTests->129 >> FAMIXClassNavigationTest->128 >> PPJavaSyntax->128 >> PPSmalltalkGrammarTests->128 >> RBRefactoryTestDataApp->123 >> NSFileStream->118 >> NSRWBinaryOrTextStream->109 >> LogicalFont->109 >> NSMultiByteBinaryOrTextStream->108 >> UIThemeW2K->103 >> MCWorkingCopy->101 >> BrowserEnvironment->97 >> DemoSettingStyle->94 >> PPJavaLexiconTests->94 >> MCClassDefinition->93 >> NSAbstractInflateStream->92 >> MCWorkingCopyBrowser->91 >> NSCollectionStreamTest->91 >> GMMetaObject->91 >> ExceptionTester->90 >> >> >> Cheers, >> Alexandre >> >> >> On 7 Dec 2010, at 10:48, StÃ©phane Ducasse wrote: >> >>>> The good idae is to push and promote people to put class comments, but not to remove not commented classes from Dev, bacause otherise, you will need to remove 80% of the classes. >>> >>> >>> So this is simple to start fixing some of them. >>> I think that without such objectives we will never make any progress and we should. >>> >>> so what are the first 5% of packages that are not documented. >>> >>> Stef >>> >>>> The next step would be a Pareto classification, as it can be accepted (I hope) that SUnit has more history (and it is documented elsewhere, like PBE book) than other classes which even the name of it or its methods may be insufficient to arrive at for what is the class. >>>> >>>> We should create IRC meetings, sprints, etc. specially targeted to document these classes. >>>> >>>> my .019999... >>>> >>>> -- >>>> Cesar Rabak >>>> >>>> >>>> Em 05/12/2010 20:07, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: >>>> >>>> On Sun, Dec 5, 2010 at 9:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> Hi guys >>>> >>>> I decided that I will not integrate any code that is not documented in Pharo. >>>> >>>> I strongly suggest to remove from Pharo-dev packages whose classes are not commented. >>>> >>>> >>>> I think this is not a good idea...look this approx: >>>> >>>> >>>> >>>> | pharoCorePackages packagesDev nonCommentedClasses totalClasses | >>>> pharoCorePackages := #('MultilingualTests' 'Morphic' 'ToolBuilder-Kernel' 'PackageInfo' 'Polymorph-ToolBuilder' 'Network-Kernel' 'Network-Protocols' 'Compiler' 'System-Finalization' 'Settings-Graphics' 'Collections' 'Network-RemoteDirectory' 'Traits' 'Network-URI' 'Settings-Display' 'Collections-Abstract' 'Settings-Compiler' 'MonticelloMocks' 'ScriptLoader11' 'System-Digital Signatures' 'System-Localization' 'MenuRegistration' 'Polymorph-TaskbarIcons' 'Monticello' 'ToolBuilder-Morphic' 'MCDirtyPackage' 'Collections-Weak' 'Settings-Polymorph' 'Tests' 'HelpSystem-Core-Utilities' 'SUnit' 'Collections-Text' 'Compression' 'Morphic-MorphTreeWidget' 'HelpSystem-Core' 'ToolsTest' 'Gofer-Core' 'Gofer-Tests' 'Collections-Stack' 'FreeType' 'MonticelloConfigurations' 'Polymorph-Geometry' 'Collections-Support' 'SUnitGUI' 'HelpSystem-Core-Model' 'Tests-VM' 'System-Change Notification' 'System' 'Tests-ObjectsAsMethods' 'HostMenus' 'Network-MIME' 'Network-RFC822' 'VB-Regex' 'TrueType' 'Depr >>>> ecatedPreferences' 'System-Clipboard' 'System-Settings' 'MorphicTests' 'System-Serial Port' 'NetworkTests' 'Collections-Unordered' 'System-Changes' 'System-Object Storage' 'Collections-Traits' 'System-Platforms' 'Tests-PrimCallController' 'Morphic-TrueType' 'Multilingual' 'Graphics' 'Collections-Strings' 'KernelTests' 'System-FileRegistry' 'Tests-Bugs' 'ToolBuilder-SUnit' 'Tests-Release' 'Morphic-Balloon' 'Settings-Network' 'System-Applications' 'Polymorph-Tools-Diff' 'Settings-Tools' 'ScriptLoader' 'ST80' 'FreeTypeSubPixelAntiAliasing' 'Settings-Kernel' 'Settings-System' 'CompilerTests' 'System-Tools' 'System-Hashing' 'System-Download' 'Collections-Streams' 'Tests-SystemChangeNotification' 'GraphicsTests' 'Polymorph-Widgets' 'Kernel' 'Tools' 'Settings-FreeType' 'FreeTypeTests' 'Settings-Monticello' 'HelpSystem-Tests' 'Polymorph-EventEnhancements' 'System-Support' 'MonticelloGUI' 'System-FilePackage' 'System-Object Events' 'Announcements' 'System-Text' 'Exceptions' 'Network- >>>> UUID' 'System-Pools' 'FixUnderscores' 'HelpSystem-Core-UI' 'GraphicsResources' 'Files' 'Gofer' 'Network-MailSending' 'Collections-Arrayed' 'CollectionsTests' 'Balloon' 'Network-Url' 'Collections-Sequenceable' ). >>>> packagesDev := (PackageInfo allPackages >>>> collect: [:each | each packageName]) >>>> difference: pharoCorePackages. >>>> nonCommentedClasses := packagesDev >>>> inject: 0 >>>> into: [:sum :each | sum + (((PackageInfo named: each) classes >>>> select: [:aClass | aClass comment asString includesSubString: 'is xxxxxxxxx.']) size)]. >>>> Transcript show: 'nonCommentedClasses: ', nonCommentedClasses asString. >>>> >>>> totalClasses := packagesDev inject: 0 into: [:sum :each | sum + (PackageInfo named: each) classes size ]. >>>> Transcript show: 'totalClasses: ', totalClasses asString. >>>> >>>> >>>> >>>> Shows: >>>> >>>> nonCommentedClasses: 1116 >>>> totalClasses: 1369 >>>> >>>> >>>> I'm not sure that I will look at code or answer question to code that is not commented. >>>> We should change our mindset and it seems that we do not care, so we should take radical decisions: >>>> less changes, less progress, more comments. >>>> >>>> And for once I will not bash the past. Smalltalk was always with methods fully documented. >>>> We are just plain lazy and this is a shame. >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Dec. 8, 2010