- Pharo-dev - lists.pharo.org

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

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 7, 2010

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

by StÃ©phane Ducasse

> 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 > > > > > >

Dec. 7, 2010

Re: [Pharo-project] IRC monthly meeting + project description

by StÃ©phane Ducasse

Ok so at 20h00 we get our first IRC meeting. See U there. > > I suggest that we start also a monthly IRC chat > the first/second tuesday of the month. I propose tuesday 7 at 18h00 or 20h00 Paris time so that > other people can join. > > Le me know what you think about it. > > Stef

Dec. 7, 2010

Re: [Pharo-project] Native Windows in Pharo

by StÃ©phane Ducasse

On Dec 7, 2010, at 2:13 PM, Geert Claes wrote: > > Hi Andres, Ideas and suggestions are very welcome in the Pharo community and > they are mainly discussed here rather than in a UserVoice or GetSatisfaction > environment. Idea voting is an excellent way to engage customers and users > to improve products. The only thing Stef and Doru are saying (at least > thats how I read it) is that Pharo doesn't necessarily have a shortage of > ideas or lack of direction, but simply not enough people to do all the work. :) indeed well rephrased :) > So yes, ideas and feature requests are great and please do continue to post > them here as there are many enthusiastic skilled Smalltalkers that can help, > advice and guide you. When you find something is missing or can be > improved, you are more encouraged to contribute towards the solution rather > than just vote. > > Getting back to your original post though, congrats getting your in-house > project! How about a rich Seaside, AIDAWeb or Iliad browser based app? > > Cheers, Geert > > > > Andres Fortier-2 wrote: >> >> Stef, Doru: >> >> first of all I was *asking if* such a model exists, not demanding one. >> Having just entered the Pharo world I wanted to know how you guys handle >> the feature requests. I see now. >> >> On the other hand if you really want to discuss the question of "who has >> the rights for asking for X" in the open source model I'm open, but just >> to be sure I will first ask: Is it ok to open such a thread? Or should I >> first contribute to Pharo before asking? >> >> AndrÃ©s >> > > -- > View this message in context: http://forum.world.st/Native-Windows-in-Pharo-tp3071794p3076336.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 7, 2010

[Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

by Sven Van Caekenberghe

Related to the Matrix CSV input/output optimalization quest, I was puzzled why writing seemed so much slower than reading. Here is a simple example: [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :stream | 100000 timesRepeat: [ stream print: 100 atRandom; space ] ] ] timeToRun. 1558 [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :stream | 100000 timesRepeat: [ Integer readFrom: stream. stream peekFor: $ ] ] ] timeToRun. 183 [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :stream | 100000 timesRepeat: [ stream nextPut: ($a to: $z) atRandom; space ] ] ] timeToRun. 1705 [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :stream | 100000 timesRepeat: [ stream next. stream peekFor: $ ] ] ] timeToRun. 47 Clearly, the writing is close to an order of magnitude slower than reading. This was on Pharo 1.1 with Cog, but I double-checked with Pharo 1.2 and Squeak 4.1. On my machine (Mac Book Pro), this is what another dynamic language does: > (time (with-output-to-file (out "/tmp/numbers.txt") (loop repeat 100000 do (format out "~d " (random 100))))) Timing the evaluation of (WITH-OUTPUT-TO-FILE (OUT "/tmp/numbers.txt") (LOOP REPEAT 100000 DO (FORMAT OUT "~d " (RANDOM 100)))) User time = 0.413 System time = 0.002 Elapsed time = 0.401 Allocation = 2502320 bytes 0 Page faults Calls to %EVAL 1700063 NIL > (time (with-open-file (in "/tmp/numbers.txt") (loop repeat 100000 do (read in)))) Timing the evaluation of (WITH-OPEN-FILE (IN "/tmp/numbers.txt") (LOOP REPEAT 100000 DO (READ IN))) User time = 0.328 System time = 0.001 Elapsed time = 0.315 Allocation = 2500764 bytes 0 Page faults Calls to %EVAL 1400056 NIL So Pharo Smalltalk clearly matches the read/parse speed, which is great, but fails at simple writing. Maybe I am doing something wrong here (I know these are MultiByteFileSteams), but I fail to see what. Something with buffering/flushing ? Anybody any idea ? Sven

Dec. 7, 2010

Re: [Pharo-project] Fwd: [Vm-dev] Image freeze because handleTimerEvent and Seaside process gone?!

by David T. Lewis

The symptoms that I see are intermittent, and it's hard for me to say what the root cause might be. It might be worthwhile to see if you can reproduce my results. If so, it might get you closer to a reproducible test case. What I did was take a Pharo core 1.1, 1.1.1, and 1.2 image, and in each image, I loaded these two packages (ignoring the MVC warnings in CommandShell): http://squeaksource.com/OSProcess/OSProcess-dtl.59.mcz http://squeaksource.com/OSProcess/CommandShell-dtl.49.mcz On Pharo 1.1, I get intermittent failures and errors in the CommandShell and OSProcess tests, but the problems seem to be resolved in 1.1.1 and 1.2. These tests are timing and machine dependent to some extent, so I am not sure if you will see the same symptoms. HTH, Dave On Tue, Dec 07, 2010 at 12:38:54PM +0100, Adrian Lienhard wrote: > The changes between 1.1 and 1.1.1 are the issues in [1]. None seems related... did I miss something? > > One change that I don't understand, although it probably is unrelated, is in [2]: > > LargePositiveInteger removeSelector: #=! > LargePositiveInteger removeSelector: #bitAnd:! > LargePositiveInteger removeSelector: #bitOr:! > LargePositiveInteger removeSelector: #bitShift:! > LargePositiveInteger removeSelector: #bitXor:! > LargePositiveInteger removeSelector: #'~='! > > Why would one want to remove these primitive calls from large integers? > > Cheers, > Adrian > > [1] http://code.google.com/p/pharo/issues/list?can=1&q=Milestone%3D1.1.1&colspe… > [2] http://code.google.com/p/pharo/issues/attachmentText?id=2912&aid=-244293168… > > > On Dec 7, 2010, at 09:52 , Mariano Martinez Peck wrote: > > > ---------- Forwarded message ---------- > > From: David T. Lewis <lewis(a)mail.msen.com> > > Date: Tue, Dec 7, 2010 at 2:06 AM > > Subject: Re: [Vm-dev] Image freeze because handleTimerEvent and Seaside > > process gone?! > > To: Squeak Virtual Machine Development Discussion < > > vm-dev(a)lists.squeakfoundation.org>, adi(a)netstyle.ch > > > > > > > > On Mon, Dec 06, 2010 at 12:33:59PM -0800, Andreas Raab wrote: > >> > >> At a guess, I'd say it's either one of two issues: > >> > >> 1) Your STOP/CONT handling. This sounds suspicious and it could affect > >> the timer handling. I'm assuming that the issue happens after receiving > >> the CONT signal, no? If you can, you might want to a) make sure that you > >> only get the STOP signal when the VM is in ioRelinquish() and not (for > >> example) currently executing the delay process and b) consider to dump > >> the call stacks whenever the VM gets the CONT signal to see what the > >> status is. > >> > >> 2) Some set of incomplete process/delay/semaphore changes in Pharo. One > >> of the problems with processes and delays is that this part of the > >> system reacts very badly to random "cleaning". I.e., changing "foo == > >> nil" to "foo isNil" can have dramatic effects (since it introduces a > >> suspension point) with just the kind of weird issue you're seeing. > > > > Actually #2 does seem like a likely culprit. I found a Pharo 1.1 image > > and loaded the CommandShell and OSProcess test suites. The CommandShell > > tests put a heavy load on process switching, and are rather timing > > dependent. On Pharo 1.1 I get intermittent and non-reproducible errors > > and test failures, and I can't get a clean run of the test suite. The > > errors seem to be different each time. > > > > On Pharo 1.1.1 and 1.2 I can get clean runs of the CommandShell/OSProcess > > tests, so I think there must be some issues in Pharo 1.1. If you are > > using PharoCore 1.1 now and have the option of moving to Pharo 1.1.1 > > or 1.2, I suspect you may see the problems go away. > > > > Dave > > > > > >> > >> With regards to these processes not being printed, that's a side effect > >> of how printAllStacks gathers the processes - it will not print > >> suspended processes which explains why the UI process doesn't print and > >> most likely handleTimerEvent is suspended in a debugger. > >> > >> Depending on how important this issue is you can also try to dissect the > >> object memory itself. If you call writeImageFile (or is it > >> writeImageFileIO?) from gdb it will dump the .image file and you can use > >> the simulator to look at it more closely. Most likely you'll be able to > >> find the processes and look at their stacks. > >> > >> Cheers, > >> - Andreas > >> > >> On 12/6/2010 2:55 AM, Adrian Lienhard wrote: > >>> > >>> Hi all, > >>> > >>> We've been experiencing an "interesting" problem: the image freezes and > >>> does not response to HTTP requests anymore after it has been running for > >>> days. > >>> > >>> Here some basic information about our setup: > >>> > >>> Squeak VM 4.0.3-2202 compiled with gcc 4.3.2 > >>> PharoCore 1.1 > >>> OS Debian Lenny amd64 (CPUs are 4 Intel Xeon E5530 2.40GHz) > >>> > >>> - We have never seen the problem with the Squeak VM 3.9-9 and Squeak 3.9 > >>> on the identical machine and with the same application source (modulo > > some > >>> adaptations to make it run on Pharo). > >>> - We run the VM with -mmap 512m -vm-sound-null -vm-display-null, and the > >>> UI process is suspended (Project uiProcess suspend) > >>> - VM does not hog the CPU and memory usage is normal > >>> - The meantime between failure is several weeks and we haven't managed to > >>> reproduce the problem > >>> - The application mainly serves HTTP requests. When the image does not > >>> receive requests for some time we send it a STOP signal, when a request > >>> comes in it is sent a CONT signal. > >>> - lsof shows > >>> TCP *:9093 (LISTEN) > >>> TCP server:9093->server:46930 (CLOSE_WAIT) > >>> > >>> Below is a GDB backtrace and the Smalltalk stacks from an image that was > >>> frozen (the VM had been running for almost 100 hours): > >>> > >>> ============================================================= > >>> (gdb) bt > >>> #0 0x08072020 in ?? () > >>> #1<signal handler called> > >>> #2 0xb766f5e0 in malloc () from /lib/libc.so.6 > >>> #3<function called from gdb> > >>> #4 0xb76c50c8 in select () from /lib/libc.so.6 > >>> #5 0x08071063 in aioPoll () > >>> #6 0xb778bb8d in ?? () from > > /usr/lib/squeak/4.0.3-2202//so.vm-display-null > >>> #7 0x000003e8 in ?? () > >>> #8 0x997b5a34 in ?? () > >>> #9 0xbfe7cb28 in ?? () > >>> #10 0x08074575 in ioRelinquishProcessorForMicroseconds () > >>> Backtrace stopped: frame did not save the PC > >>> > >>> (gdb) call printCallStack() > >>> -1719969228>idleProcess > >>> -1719969320>startUp > >>> -1740134028 BlockClosure>newProcess > >>> $3 = -1755344892 > >>> > >>> (gdb) call (int) printAllStacks() > >>> Process > >>> -1719969228>idleProcess > >>> -1719969320>startUp > >>> -1740134028 BlockClosure>newProcess > >>> > >>> Process > >>> -1740113860>finalizationProcess > >>> -1740113952>restartFinalizationProcess > >>> -1740113532 BlockClosure>newProcess > >>> > >>> Process > >>> -1740134424 SmalltalkImage>lowSpaceWatcher > >>> -1740134516 SmalltalkImage>installLowSpaceWatcher > >>> -1740134300 BlockClosure>newProcess > >>> > >>> Process > >>> -1719451488 Delay>wait > >>> -1719451580 BlockClosure>ifCurtailed: > >>> -1719451704 Delay>wait > >>> -1719451796 InputEventPollingFetcher>waitForInput > >>> -1740126940 InputEventFetcher>eventLoop > >>> -1740127032 InputEventFetcher>installEventLoop > >>> -1740126816 BlockClosure>newProcess > >>> > >>> Process > >>> -1719557780 UnixOSProcessAccessor>grimReaperProcess > >>> -1740113624 BlockClosure>repeat > >>> -1740113716 UnixOSProcessAccessor>grimReaperProcess > >>> -1740117340 BlockClosure>newProcess > >>> > >>> [omitted many newlines between output above] > >>> ============================================================= > >>> > >>> What is striking from the above process listing is that two processes are > >>> missing: the handleTimerEvent process and the Seaside process (that is, > >>> the TCP listener loop). How comes these processes vanished? > >>> > >>> This may be related to Pharo or to the Squeak VM. > >>> > >>> Has anybody else seen this problem? Any idea how to debug/fix this issue > >>> is very much appreciated! > >>> > >>> Cheers, > >>> Adrian > >>> > >>> > >>> CCed to pharo-dev since this may be related to Pharo; please respond on > >>> the squeak-vm list > >>> > >>> > >>> >

Dec. 7, 2010

Re: [Pharo-project] Native Windows in Pharo

by Igor Stasenko

On 7 December 2010 14:13, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > > Hi Andres, Ideas and suggestions are very welcome in the Pharo community and > they are mainly discussed here rather than in a UserVoice or GetSatisfaction > environment. Â Idea voting is an excellent way to engage customers and users > to improve products. Â The only thing Stef and Doru are saying (at least > thats how I read it) is that Pharo doesn't necessarily have a shortage of > ideas or lack of direction, but simply not enough people to do all the work. > So yes, ideas and feature requests are great and please do continue to post > them here as there are many enthusiastic skilled Smalltalkers that can help, > advice and guide you. Â When you find something is missing or can be > improved, you are more encouraged to contribute towards the solution rather > than just vote. > That's exactly what i said about this before. We simply lacking manhours to do everything we want. I want to do a lot of cool stuff. But it requires a lot of time. > Getting back to your original post though, congrats getting your in-house > project! Â How about a rich Seaside, AIDAWeb or Iliad browser based app? > > Cheers, Geert > > > > Andres Fortier-2 wrote: >> >> Stef, Doru: >> >> first of all I was *asking if* such a model exists, not demanding one. >> Having just entered the Pharo world I wanted to know how you guys handle >> the feature requests. I see now. >> >> On the other hand if you really want to discuss the question of "who has >> the rights for asking for X" in the open source model I'm open, but just >> to be sure I will first ask: Is it ok to open such a thread? Or should I >> first contribute to Pharo before asking? >> >> AndrÃ©s >> > > -- > View this message in context: http://forum.world.st/Native-Windows-in-Pharo-tp3071794p3076336.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

Dec. 7, 2010

Re: [Pharo-project] Native Windows in Pharo

by Geert Claes

Hi Andres, Ideas and suggestions are very welcome in the Pharo community and they are mainly discussed here rather than in a UserVoice or GetSatisfaction environment. Idea voting is an excellent way to engage customers and users to improve products. The only thing Stef and Doru are saying (at least thats how I read it) is that Pharo doesn't necessarily have a shortage of ideas or lack of direction, but simply not enough people to do all the work. So yes, ideas and feature requests are great and please do continue to post them here as there are many enthusiastic skilled Smalltalkers that can help, advice and guide you. When you find something is missing or can be improved, you are more encouraged to contribute towards the solution rather than just vote. Getting back to your original post though, congrats getting your in-house project! How about a rich Seaside, AIDAWeb or Iliad browser based app? Cheers, Geert Andres Fortier-2 wrote: > > Stef, Doru: > > first of all I was *asking if* such a model exists, not demanding one. > Having just entered the Pharo world I wanted to know how you guys handle > the feature requests. I see now. > > On the other hand if you really want to discuss the question of "who has > the rights for asking for X" in the open source model I'm open, but just > to be sure I will first ask: Is it ok to open such a thread? Or should I > first contribute to Pharo before asking? > > AndrÃ©s > -- View this message in context: http://forum.world.st/Native-Windows-in-Pharo-tp3071794p3076336.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2010

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by Igor Stasenko

On 7 December 2010 12:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> Hello, jaayer. >>> >>> The point about Dictionary inconsistency was raised multiple times before. >>> I was among ones of those who did that couple of years ago. >>> What can i say? >>> While it is much better to have consistency, >>> in fact it doesn't really changes much. I don't think that #remove: in >>> a form you proposed will be any userful. >>> I would really keep it simply #shouldNotImplement , because it is >>> unclear what is a least surprising behavior of this method for >>> Dictionary. > > Igor why? > > why remove: does not take the same argument than add: and does what it should? > because with collection you can do: collection copy do: [:xx | collection remove: xx ]. or collection removeAll: (collection select: [:each | each isOdd ] ) but not with dictionary. So i don't see much reason fixing #remove: because we never going to fix #do: anyways, which makes all beautiful manipulations with collections useless for dictionary. >>> One might argue, that its more userful to make it same as #removeKey:, >>> other one could point that its should be symmetrical to #add: , >> >> #add: is not part of the ANSI <abstractDictionary> protocol. It is, however, part of the ANSI <extensibleCollection> protocol: >> add: >> addAll: >> remove: >> remove:ifAbsent: >> removeAll: >> >> One could make the argument that if Dictionary elects to implement part of it, it might as well implement the rest too. >> >>> but hey, then #do: should be also symmetrical to #add: , isnt? And so >>> it should iterate over associations , not just values. So, it is a can >>> of worms, once you open it , you can never finish the endless >>> discussions :) >>> It is just works in a way how we like (defined). It is like an >>> imaginary numbers in math where sqrt(-1) == i and basta :) >> >> Right... I wasn't planning on going there, but are we basically stuck with #do:, #select: #collect:, #includes: and other such messages operating on the Dictionary's values rather than its associations, forever? > > I hope not. > > > > -- Best regards, Igor Stasenko AKA sig.

Dec. 7, 2010

Re: [Pharo-project] Pharo integration in enterprise feedback

by Diogenes Moreira

Well sow sow, Very offen, then choice makers, looking for, "security" (talking about people, policy and technology) . "I'm select java because PWC recommend it for this solution'".."Cover your ass" Puaj..Puaj In the second place the choice makers select the technologies, defending he's budget. Not select the cheaper o better solutios.. Fight for manteing or increse, the IT budget.. "More budget..More power.. Say the CIOs (Common Idiot Officer) . Other fact, (at least in Argentine)the CIO don't have real weight in the organization and denpends of Operation or Financials. I don't know where come from the stupid idea that the IT area can be manage for a non-tech people.. I can guess from Accountants..or Lawyers :). In 3th place, the choice makers looking for fame. nobody was selected as InfomationWeek's CIO of Year for select Smaltalk as Core Technology. (The mainstream software houses are sponsor of this cain of publications). In last place the choice makers select the technologies for it's capabilities and "state of art" that he has in your organization. Actually the average programmers don't know the true OOP. I think, Pharo goes in good way..but the finishline is a far far a way. We must continue teaching in the universities..and why not.. The companies.. For free.... Only for introduce the technollogy in the market We must support projects such Seaside, Reef, Glorp, SqueakDBX or Mars (and it's futures version for linux and windows). This cain of projects are the bridge from the mainstream world to smalltalk.. Rigth now, in the mind of traditonal choice maker, a solution without a relational DB(Oracle or something like that) is only "a beatyfull toy". are year a mean. Traditional pieces of software give "Security". We must make deal's with the traditional software companies.. And don't be scare for sign a contract where the project have webservices and java, php or .net front-end. although the solution is not neededâ¬.(Obviously if you don't will be the architect :) ) We need make the peace with commercial people and the technology publications.. At last and over all, when any one from this group, have the chance, one chance, to have a CIO position, take it, and make the difference. This one, please don't think as traditional CIO, think different. Sorry for the large mail and my english Best. 2010/12/7, Guillermo Polito <guillermopolito(a)gmail.com>: > Do we have marketing people? We need someone selling smalltalk to business > people. :P > > In most cases (at least here in Argentina), the technology is decided by non > technical people (like managers or customers) because they heard something > called java and someone recommended it to them... > > Sad. > > On Mon, Dec 6, 2010 at 10:43 PM, <csrabak(a)bol.com.br> wrote: > >> Em 06/12/2010 18:21, Tudor Girba < tudor.girba(a)gmail.com > escreveu: >> >> > Hi, >> > I believe Smalltalk is perceived in the following way: >> > 1. Smalltalk is cool: 0.01% >> > 2. What is Smalltalk?: 19,99% >> > 3. Smalltalk is dead: 80% >> >> I think your assessment is not that far from reality... :-( >> >> > It is hard to convince the 2nd category to look at something >> > new. Why should they? But, if it's hard to convince someone of >> > something new, you need a miracle to convince someone that something >> > is not dead. But, I think that a miracle like this can be >> > administrated in the form of cool and kicking creatures and then >> > tell them that they kick because of Smalltalk :) >> >> I agree on the feeling, I only think we all miss a very important >> tactical point here: in what realm is Smalltalk superior to other >> technologies? While we cannot answer this without hesitation and >> without half escuses on why this 'superiority' don't show itself, >> we're stuck to feelings and trying to present cherry picked 'examples' >> of the qualities of our pet language/technology. >> >> The issue some cool and kicking creatures could have been done is not >> enough, we need also to be certain we can get newcomers and have them >> quickly up to speed in doing so. _That_ has lead other ('younger') >> languages to their present status. >> >> -- >> Cesar Rabak >> >> > -- Enviado desde mi dispositivo mÃ³vil

Dec. 7, 2010