Re: [Pharo-project] Debugger not closed issue ?
Laurent, I have 4 remaining in a long running 1.1 image. Sven On 06 Dec 2010, at 07:57, laurent laffont wrote: Hi, can you check this please ? Take an image you work on (not a fresh one), and evaluate: Debugger closeAllDebuggers. Smalltalk garbageCollect. Debugger allInstances size. On a lot of my images 1 or 2 Debugger instances remains. It's a problem for Autotest, but it also may be a side effect of Autotest, so I want to check. Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/
Re: [Pharo-project] Debugger not closed issue ?
Thanks Sven. So it's a bug ? Laurent On Mon, Dec 6, 2010 at 9:16 AM, Sven Van Caekenberghe s...@beta9.be wrote: Laurent, I have 4 remaining in a long running 1.1 image. Sven On 06 Dec 2010, at 07:57, laurent laffont wrote: Hi, can you check this please ? Take an image you work on (not a fresh one), and evaluate: Debugger closeAllDebuggers. Smalltalk garbageCollect. Debugger allInstances size. On a lot of my images 1 or 2 Debugger instances remains. It's a problem for Autotest, but it also may be a side effect of Autotest, so I want to check. Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/
[Pharo-project] RPackage
Hello, Recently I made some improvements about RPackage. What I mainly did, is to implement the 'SystemAnnounncements listening', to update the organizer when the system change. With that I implemented a set of tests that should all be green now (in RPackageMCSynchronisationTest (I should change the name)). You can load RPackage by evaluating: Gofer new squeaksource: 'PharoInbox'; package: 'ConfigurationOfRPackage'; load. (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. (I think it should work, but squeaksource is down for now, so I was not able to test it). In those tests I started to write some about traits, but after few, I realized that the events emitted when a trait change are the same that the one used for classes ? Then if you have some ideas about what is still missing in RPackage, tell me, I can add it to my task list :)
Re: [Pharo-project] Issue 3335 in pharo: [Kernel Dependencies] Number@
Updates: Status: Fixed Comment #2 on issue 3335 by Benjamin.VanRyseghem.Pharo: [Kernel Dependencies] Number@ http://code.google.com/p/pharo/issues/detail?id=3335 fix Attachments: Issue3335NumberRemoveDependenceToGraphicsPrimitive.1.cs 1.4 KB
Re: [Pharo-project] RPackage
Good work, Cyrille! For people that might not know what RPackage is, this project aims to replace PackageInfo with a faster and cleaner implementation. At the moment, all categories are mapped one-to-one and in the end, we would like to remove class categories altogether. This infrastructure is also targeted to code browsers. Doru On 6 Dec 2010, at 09:58, Cyrille Delaunay wrote: Hello, Recently I made some improvements about RPackage. What I mainly did, is to implement the 'SystemAnnounncements listening', to update the organizer when the system change. With that I implemented a set of tests that should all be green now (in RPackageMCSynchronisationTest (I should change the name)). You can load RPackage by evaluating: Gofer new squeaksource: 'PharoInbox'; package: 'ConfigurationOfRPackage'; load. (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. (I think it should work, but squeaksource is down for now, so I was not able to test it). In those tests I started to write some about traits, but after few, I realized that the events emitted when a trait change are the same that the one used for classes ? Then if you have some ideas about what is still missing in RPackage, tell me, I can add it to my task list :) -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal.
Re: [Pharo-project] Issue 3334 in pharo: [Kernel Dependencies] Model#patchworkUIThemeColor
Updates: Status: Fixed Comment #1 on issue 3334 by Benjamin.VanRyseghem.Pharo: [Kernel Dependencies] Model#patchworkUIThemeColor http://code.google.com/p/pharo/issues/detail?id=3334 fix Attachments: Issue3334ModelRemoveDependenceToColor.1.cs 1.2 KB
Re: [Pharo-project] Debugger not closed issue ?
I don't know why nor when, but someone once suggest me to always do 3 timesRepeat: [Smalltalk garbageCollect]. Can you check: Debugger closeAllDebuggers. 3 timesRepeat: [Smalltalk garbageCollect]. Debugger allInstances size. If this works, then it would be nice to have someone that explains to us haha On Mon, Dec 6, 2010 at 9:41 AM, laurent laffont laurent.laff...@gmail.comwrote: Thanks Sven. So it's a bug ? Laurent On Mon, Dec 6, 2010 at 9:16 AM, Sven Van Caekenberghe s...@beta9.bewrote: Laurent, I have 4 remaining in a long running 1.1 image. Sven On 06 Dec 2010, at 07:57, laurent laffont wrote: Hi, can you check this please ? Take an image you work on (not a fresh one), and evaluate: Debugger closeAllDebuggers. Smalltalk garbageCollect. Debugger allInstances size. On a lot of my images 1 or 2 Debugger instances remains. It's a problem for Autotest, but it also may be a side effect of Autotest, so I want to check. Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/
Re: [Pharo-project] Debugger not closed issue ?
Does not change anything... Laurent On Mon, Dec 6, 2010 at 10:26 AM, Mariano Martinez Peck marianop...@gmail.com wrote: I don't know why nor when, but someone once suggest me to always do 3 timesRepeat: [Smalltalk garbageCollect]. Can you check: Debugger closeAllDebuggers. 3 timesRepeat: [Smalltalk garbageCollect]. Debugger allInstances size. If this works, then it would be nice to have someone that explains to us haha On Mon, Dec 6, 2010 at 9:41 AM, laurent laffont laurent.laff...@gmail.com wrote: Thanks Sven. So it's a bug ? Laurent On Mon, Dec 6, 2010 at 9:16 AM, Sven Van Caekenberghe s...@beta9.bewrote: Laurent, I have 4 remaining in a long running 1.1 image. Sven On 06 Dec 2010, at 07:57, laurent laffont wrote: Hi, can you check this please ? Take an image you work on (not a fresh one), and evaluate: Debugger closeAllDebuggers. Smalltalk garbageCollect. Debugger allInstances size. On a lot of my images 1 or 2 Debugger instances remains. It's a problem for Autotest, but it also may be a side effect of Autotest, so I want to check. Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/
[Pharo-project] Image freeze because handleTimerEvent and Seaside process gone?!
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 0x03e8 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 BlockClosurenewProcess $3 = -1755344892 (gdb) call (int) printAllStacks() Process -1719969228 idleProcess -1719969320 startUp -1740134028 BlockClosurenewProcess Process -1740113860 finalizationProcess -1740113952 restartFinalizationProcess -1740113532 BlockClosurenewProcess Process -1740134424 SmalltalkImagelowSpaceWatcher -1740134516 SmalltalkImageinstallLowSpaceWatcher -1740134300 BlockClosurenewProcess Process -1719451488 Delaywait -1719451580 BlockClosureifCurtailed: -1719451704 Delaywait -1719451796 InputEventPollingFetcherwaitForInput -1740126940 InputEventFetchereventLoop -1740127032 InputEventFetcherinstallEventLoop -1740126816 BlockClosurenewProcess Process -1719557780 UnixOSProcessAccessorgrimReaperProcess -1740113624 BlockClosurerepeat -1740113716 UnixOSProcessAccessorgrimReaperProcess -1740117340 BlockClosurenewProcess [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
Re: [Pharo-project] Debugger not closed issue ?
On Mon, 6 Dec 2010, laurent laffont wrote: Hi, can you check this please ? Take an image you work on (not a fresh one), and evaluate: Debugger closeAllDebuggers. Smalltalk garbageCollect. Debugger allInstances size. On a lot of my images 1 or 2 Debugger instances remains. It's a problem for Autotest, but it also may be a side effect of Autotest, so I want to check. We recently fixed a bug in OCompletion (load OCompletion-klub.84 for the fix), that resulted in hanging debugger instances. To reproduce the issue: - open a debugger - type something to the inspector in the lower right panel and make sure you've triggered OCompletion. After closing the debugger it won't be garbage collected. Levente Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/
Re: [Pharo-project] Debugger not closed issue ?
I have 6 of them :( By chasing pointers, it seems to be related to ObjectExplorerWrapper... hth, Cédrick On Mon, Dec 6, 2010 at 9:41 AM, laurent laffont laurent.laff...@gmail.com wrote: Thanks Sven. So it's a bug ? Laurent On Mon, Dec 6, 2010 at 9:16 AM, Sven Van Caekenberghe s...@beta9.be wrote: Laurent, I have 4 remaining in a long running 1.1 image. Sven On 06 Dec 2010, at 07:57, laurent laffont wrote: Hi, can you check this please ? Take an image you work on (not a fresh one), and evaluate: Debugger closeAllDebuggers. Smalltalk garbageCollect. Debugger allInstances size. On a lot of my images 1 or 2 Debugger instances remains. It's a problem for Autotest, but it also may be a side effect of Autotest, so I want to check. Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/
Re: [Pharo-project] Debugger not closed issue ?
We recently fixed a bug in OCompletion (load OCompletion-klub.84 for the fix), that resulted in hanging debugger instances. To reproduce the issue: - open a debugger - type something to the inspector in the lower right panel and make sure you've triggered OCompletion. After closing the debugger it won't be garbage collected. Thank you Levente. How can I check that my immortal debuggers are the consequence of this bug ? Laurent. Levente Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/
Re: [Pharo-project] Popularity or not of smalltalk?
JAjajaja, It's not that Indexes are not trustable... They are measured in a way Smalltalk will never be recognized as popular: - searches in yahoo - open source projects in some webs - people asking for job The only one that surprized me is the book's one. But 1) the data is not taken from amazon and I don't know this Powell's Books library :P. 2) It's true that there is a stupid amount of java, c#, c++ books... Maybe we can think a not so stupid index. Cheers On Mon, Dec 6, 2010 at 4:12 AM, laurent laffont laurent.laff...@gmail.comwrote: And I've just seen the bottom of the message :), it seems http://langpop.com/ agree with TIOBE. On Mon, Dec 6, 2010 at 8:09 AM, laurent laffont laurent.laff...@gmail.com wrote: On Mon, Dec 6, 2010 at 6:51 AM, James Ladd james_l...@hotmail.comwrote: 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? According to TIOBE, Smalltalk is as popular as Erlang and more popular than Scala http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html But that's only numbers and I don't trust it :) May be your developer from a popular IDE company should define what popular means... Laurent 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/
Re: [Pharo-project] Popularity or not of smalltalk?
On 6 December 2010 13:38, Guillermo Polito guillermopol...@gmail.com wrote: JAjajaja, It's not that Indexes are not trustable... They are measured in a way Smalltalk will never be recognized as popular: - searches in yahoo - open source projects in some webs - people asking for job The only one that surprized me is the book's one. But 1) the data is not taken from amazon and I don't know this Powell's Books library :P. 2) It's true that there is a stupid amount of java, c#, c++ books... i think there is a lot of books because they are very complex ones :) for a smalltalk, you need just one book, and .. whooop .. you know it after few days of study. For C++ or Java it takes couple of months to learn all this stuff.. Maybe we can think a not so stupid index. Cheers On Mon, Dec 6, 2010 at 4:12 AM, laurent laffont laurent.laff...@gmail.com wrote: And I've just seen the bottom of the message :), it seems http://langpop.com/ agree with TIOBE. On Mon, Dec 6, 2010 at 8:09 AM, laurent laffont laurent.laff...@gmail.com wrote: On Mon, Dec 6, 2010 at 6:51 AM, James Ladd james_l...@hotmail.com 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? According to TIOBE, Smalltalk is as popular as Erlang and more popular than Scala http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html But that's only numbers and I don't trust it :) May be your developer from a popular IDE company should define what popular means... Laurent 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/ -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Debugger not closed issue ?
On Mon, 6 Dec 2010, laurent laffont wrote: We recently fixed a bug in OCompletion (load OCompletion-klub.84 for the fix), that resulted in hanging debugger instances. To reproduce the issue: - open a debugger - type something to the inspector in the lower right panel and make sure you've triggered OCompletion. After closing the debugger it won't be garbage collected. Thank you Levente. How can I check that my immortal debuggers are the consequence of this bug ? If there are more than one instances (or sub-instances) of ECController in your image after closing all windows, then it's very probable that this is the cause of the problem. If you load OCompletion-klub.84 (which is the last version of OCompletion that's compatible with Pharo 1.1) and evaluate this: ECController allSubInstancesDo: [ :each | each editor ]. Smalltalk garbageCollect. Then the debuggers should be gone. Levente Laurent. Levente Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/
Re: [Pharo-project] Debugger not closed issue ?
Just out of curiosity, I went directly to Debugger allInstances size and got zero :) This is in a far from fresh 1.1.1 image. I do not use eCompletion or AutoTest. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianop...@gmail.com] Sent: Monday, December 06, 2010 4:26 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Debugger not closed issue ? I don't know why nor when, but someone once suggest me to always do 3 timesRepeat: [Smalltalk garbageCollect]. Can you check: Debugger closeAllDebuggers. 3 timesRepeat: [Smalltalk garbageCollect]. Debugger allInstances size. If this works, then it would be nice to have someone that explains to us haha
Re: [Pharo-project] Debugger not closed issue ?
On Mon, Dec 6, 2010 at 2:02 PM, Levente Uzonyi le...@elte.hu wrote: On Mon, 6 Dec 2010, laurent laffont wrote: We recently fixed a bug in OCompletion (load OCompletion-klub.84 for the fix), that resulted in hanging debugger instances. To reproduce the issue: - open a debugger - type something to the inspector in the lower right panel and make sure you've triggered OCompletion. After closing the debugger it won't be garbage collected. Thank you Levente. How can I check that my immortal debuggers are the consequence of this bug ? If there are more than one instances (or sub-instances) of ECController in your image after closing all windows, then it's very probable that this is the cause of the problem. I have no instance. If you load OCompletion-klub.84 (which is the last version of OCompletion that's compatible with Pharo 1.1) and evaluate this: ECController allSubInstancesDo: [ :each | each editor ]. Smalltalk garbageCollect. Then the debuggers should be gone. I've tried but they are still here. So it's another issue (maybe Autotest. I will work without Autotest to see if I can reproduce the problem). Laurent. Levente Laurent. Levente Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/
[Pharo-project] Category Renaming under Monticello
Hi, When I rename a category, Monticello does not seem to pick up the necessary (class definition) changes, even when I manually accept each class definition. I was hoping to use category renaming to move some classes out of an MC package and into a seperate new one. I also wanted to rename a category, but that would give the same issue I guess. I am sure this is worth a FAQ entry, but I could find anything. Anyone any idea ? Thx, Sven
Re: [Pharo-project] Category Renaming under Monticello
On Dec 6, 2010, at 3:38 22PM, Sven Van Caekenberghe wrote: Hi, When I rename a category, Monticello does not seem to pick up the necessary (class definition) changes, even when I manually accept each class definition. I was hoping to use category renaming to move some classes out of an MC package and into a seperate new one. I also wanted to rename a category, but that would give the same issue I guess. I am sure this is worth a FAQ entry, but I could find anything. Anyone any idea ? Thx, Sven IIRC, Monticello does not automatically create new packages (or delete empty ones) based on recategorization. If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place. Cheers, Henry
Re: [Pharo-project] Category Renaming under Monticello
On 06 Dec 2010, at 15:42, Henrik Johansen wrote: If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place. OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ? And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ? Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ? Anyway, thanks for the reply. Sven
Re: [Pharo-project] Category Renaming under Monticello
On Dec 6, 2010, at 3:52 08PM, Sven Van Caekenberghe wrote: On 06 Dec 2010, at 15:42, Henrik Johansen wrote: If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place. OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ? And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ? Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ? Anyway, thanks for the reply. Sven IIRC, (big if), the package corresponding to the category that was renamed will not contain any code if you browse it, but neither is it marked as dirty. So by default, you probably wouldn't publish the new, empty version of the package unless you looked for it specifically. New packages created before or after renaming an existing category will not be marked dirty as a consequence of the category rename either. If you change the category of a single class however, both old and new package will be marked dirty. (Except if you create the new package after performing the rename) TLDR; The packages will contain the correct code, if you publish them. Marking packages as dirty does not work for category renames, but do work for single class renaming done by recompiling class definition. Cheers, Henry
Re: [Pharo-project] Comments or no integration: a simple choice for you
Mariano,
Precisely due the size of the problem as you estimated that Stef's plan is a
Good Idea®.
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 .01...
--
Cesar Rabak
Em 05/12/2010 20:07, Mariano Martinez Peck marianop...@gmail.com escreveu:
On Sun, Dec 5, 2010 at 9:52 PM, Stéphane Ducasse stephane.duca...@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
x.']) 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
Re: [Pharo-project] Popularity or not of smalltalk?
James, The point of your post will surely be answered by other, and I'm sure you'll find good stuff in STIC and ESUG websites. However, the purpose of yours surprises me: why do you think that having a popular and great IDE company supporting Smalltalk is of any help? Decoupling the Smalltalk environment from the IDE will make a Frankenstein which will make the acronym 'IDE' look like an oxymoron... Regards, -- Cesar Rabak Em 06/12/2010 03:51, James Ladd james_l...@hotmail.com escreveu: 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/
Re: [Pharo-project] RPackage
I think this small thread is an excellent example of the need we have to implement simpler practice: When we announce a package or project, it would nice if the first paragraph[s] could be a short description of what it's all about! We could even open another thread and agree upon a format for it, and look, we could even have the same text in some specific attribute in the package which could be collected, selected, etc.!! -- Cesar Rabak Em 06/12/2010 07:08, Tudor Girba tudor.gi...@gmail.com escreveu: Good work, Cyrille! For people that might not know what RPackage is, this project aims to replace PackageInfo with a faster and cleaner implementation. At the moment, all categories are mapped one-to-one and in the end, we would like to remove class categories altogether. This infrastructure is also targeted to code browsers. Doru On 6 Dec 2010, at 09:58, Cyrille Delaunay wrote: Hello, Recently I made some improvements about RPackage. What I mainly did, is to implement the 'SystemAnnounncements listening', to update the organizer when the system change. With that I implemented a set of tests that should all be green now (in RPackageMCSynchronisationTest (I should change the name)). You can load RPackage by evaluating: Gofer new squeaksource: 'PharoInbox'; package: 'ConfigurationOfRPackage'; load. (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. (I think it should work, but squeaksource is down for now, so I was not able to test it). In those tests I started to write some about traits, but after few, I realized that the events emitted when a trait change are the same that the one used for classes ? Then if you have some ideas about what is still missing in RPackage, tell me, I can add it to my task list :) -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal.
Re: [Pharo-project] Issue 3383 in pharo: [FIX] make String #subStrings: do less allocation
Updates: Status: closed Comment #2 on issue 3383 by stephane.ducasse: [FIX] make String #subStrings: do less allocation http://code.google.com/p/pharo/issues/detail?id=3383 in 12271
[Pharo-project] Bad characters in update package names
Seems didn't get sent... Regards, Gary - Original Message - From: Gary Chambers To: Pharo Development Sent: Friday, December 03, 2010 4:02 PM Subject: Bad characters in update package names It seems that having $: in the package name for certain updates is causing the save to local package cache to error on Windows (unsurprisingly). Perhaps worth having a sanity check before the package name is accepted since it eventually gets to the filesystem. Regards, Gary
Re: [Pharo-project] Bad characters in update package names
As a possible workaround, an offending package might load on a Mac or Linux system. Some time back, I encountered a package (an older version of RIO) that was broken on Windows, but I was able to install it on Linux, fix the Windows code there, and then it worked. It's better to fix the real problem, but it can nice to be able to continue working. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzagu...@btinternet.com] Sent: Monday, December 06, 2010 11:02 AM To: Pharo Development Subject: [Pharo-project] Bad characters in update package names Seems didn't get sent... Regards, Gary - Original Message - From: Gary Chambersmailto:gazzagu...@btinternet.com To: Pharo Developmentmailto:pharo-project@lists.gforge.inria.fr Sent: Friday, December 03, 2010 4:02 PM Subject: Bad characters in update package names It seems that having $: in the package name for certain updates is causing the save to local package cache to error on Windows (unsurprisingly). Perhaps worth having a sanity check before the package name is accepted since it eventually gets to the filesystem. Regards, Gary
Re: [Pharo-project] Bad characters in update package names
Currntly I'm doing the workaround by changing the package name in the debugger ;-) Regards, Gary - Original Message - From: Schwab,Wilhelm K bsch...@anest.ufl.edu To: Pharo-project@lists.gforge.inria.fr Sent: Monday, December 06, 2010 4:22 PM Subject: Re: [Pharo-project] Bad characters in update package names As a possible workaround, an offending package might load on a Mac or Linux system. Some time back, I encountered a package (an older version of RIO) that was broken on Windows, but I was able to install it on Linux, fix the Windows code there, and then it worked. It's better to fix the real problem, but it can nice to be able to continue working. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzagu...@btinternet.com] Sent: Monday, December 06, 2010 11:02 AM To: Pharo Development Subject: [Pharo-project] Bad characters in update package names Seems didn't get sent... Regards, Gary - Original Message - From: Gary Chambersmailto:gazzagu...@btinternet.com To: Pharo Developmentmailto:pharo-project@lists.gforge.inria.fr Sent: Friday, December 03, 2010 4:02 PM Subject: Bad characters in update package names It seems that having $: in the package name for certain updates is causing the save to local package cache to error on Windows (unsurprisingly). Perhaps worth having a sanity check before the package name is accepted since it eventually gets to the filesystem. Regards, Gary
Re: [Pharo-project] Popularity or not of smalltalk?
Guillermo, While all the criticisms of yours are correct, they do not change the reality. If you take some other sources like the inventory of systems benchmarked by companies specializing in this kind of job¹, or government inventories or even the ISBSG database, you'll find Smalltalk use (which relates to 'popularity') is residual in any realm. In fact, Gartner issued some years ago a research note² and classified languages according to a A Life-Cycle Maturity Matrix. Recently James Robertson from Cimcon managed to have Gartner to write (in a blog, however, no Research) flattering things about Smalltalk in a context of dynamic languages. Regards, -- Cesar Rabak [1] Not so blatant advice: I used to work for Gartner and now I represent SPR. [2] TU-05-1942 Life-Cycle Strategies for Legacy Languages, J. Duggan, Gartner, Stamford, CT, 1998. Em 06/12/2010 10:38, Guillermo Polito guillermopol...@gmail.com escreveu: JAjajaja, It's not that Indexes are not trustable... They are measured in a way Smalltalk will never be recognized as popular: - searches in yahoo - open source projects in some webs - people asking for job The only one that surprized me is the book's one. But 1) the data is not taken from amazon and I don't know this Powell's Books library :P. 2) It's true that there is a stupid amount of java, c#, c++ books... Maybe we can think a not so stupid index. Cheers On Mon, Dec 6, 2010 at 4:12 AM, laurent laffont laurent.laff...@gmail.com wrote: And I've just seen the bottom of the message :), it seems http://langpop.com/ agree with TIOBE. On Mon, Dec 6, 2010 at 8:09 AM, laurent laffont laurent.laff...@gmail.com wrote: On Mon, Dec 6, 2010 at 6:51 AM, James Ladd james_l...@hotmail.com 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? According to TIOBE, Smalltalk is as popular as Erlang and more popular than Scala http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html But that's only numbers and I don't trust it :) May be your developer from a popular IDE company should define what popular means... Laurent 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/
Re: [Pharo-project] Popularity or not of smalltalk?
Igor, My perceived experience in project we used freshmen from a University to work in Smalltalk for the Spatmas platform, was a little different. The persons needed about the same than the Java colleagues (which worked in a complimentary part of the project) to become proficient and productive in Smalltalk. We Smalltalkers take sometimes at face value certain things that clash in real world: the famous simplicity of the syntax (which Stef's famous postcard example) of Smalltalk is completely flared by the overwhelming complexity of the class libraries. Contrary to current belief, out of the core libraries (specially the Collection hierarchy) most of the remaining packages are not that elegant or orthogonal enough to preclude the need for digging and learning from experience, which takes as much time as any other language. As soon we get at the need to build production grade systems, we find Smalltalks advantages are not enough to make us stand out of the crowd. my 0.01... -- Cesar Rabak Em 06/12/2010 10:44, Igor Stasenko siguc...@gmail.com escreveu: On 6 December 2010 13:38, Guillermo Polito wrote: JAjajaja, It's not that Indexes are not trustable... They are measured in a way Smalltalk will never be recognized as popular: - searches in yahoo - open source projects in some webs - people asking for job The only one that surprized me is the book's one. But 1) the data is not taken from amazon and I don't know this Powell's Books library :P. 2) It's true that there is a stupid amount of java, c#, c++ books... i think there is a lot of books because they are very complex ones :) for a smalltalk, you need just one book, and .. whooop .. you know it after few days of study. For C++ or Java it takes couple of months to learn all this stuff.. Maybe we can think a not so stupid index. Cheers On Mon, Dec 6, 2010 at 4:12 AM, laurent laffont wrote: And I've just seen the bottom of the message :), it seems http://langpop.com/ agree with TIOBE. On Mon, Dec 6, 2010 at 8:09 AM, laurent laffont wrote: On Mon, 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? According to TIOBE, Smalltalk is as popular as Erlang and more popular than Scala http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html But that's only numbers and I don't trust it :) May be your developer from a popular IDE company should define what popular means... Laurent 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/ -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Popularity or not of smalltalk?
To add a little of data to anecdote, let me put two complimentary pointers: Talks about the The US Department of Defense has decided to discontinue the development, maintenance, and –use- of JAS (nee JWARS) by year end. JAS is a joint campaign model, (one that represents all the services), consisting of over 1.1 million lines of Smalltalk that has been developed over the last 15 years at a cost to the taxpayers north of $110 million. Further details: http://groups.google.com/groups/profile?enc_user=gNSEzw8AAADszNgJiajay96Y7oEQONQG About Gartner's affirmations (ten years old!) http://groups.google.com/group/ibm.software.vasmalltalk/browse_thread/thread/6260484c776e83b5/23712440b7edae4d?lnk=gstq=migration+VASmalltalk# And a case study of a company that decided _not_ switch from Smalltalk after tried to go java: http://www.nycsmalltalk.org/2009/11/return-to-smalltalk/ HTH to enlighten our discussions on these matters. -- Cesar Rabak Em 06/12/2010 14:27, csra...@bol.com.br escreveu: Guillermo, While all the criticisms of yours are correct, they do not change the reality. If you take some other sources like the inventory of systems benchmarked by companies specializing in this kind of job¹, or government inventories or even the ISBSG database, you'll find Smalltalk use (which relates to 'popularity') is residual in any realm. In fact, Gartner issued some years ago a research note² and classified languages according to a A Life-Cycle Maturity Matrix. Recently James Robertson from Cimcon managed to have Gartner to write (in a blog, however, no Research) flattering things about Smalltalk in a context of dynamic languages. Regards, -- Cesar Rabak [1] Not so blatant advice: I used to work for Gartner and now I represent SPR. [2] TU-05-1942 Life-Cycle Strategies for Legacy Languages, J. Duggan, Gartner, Stamford, CT, 1998. Em 06/12/2010 10:38, Guillermo Polito guillermopol...@gmail.com escreveu: JAjajaja, It's not that Indexes are not trustable... They are measured in a way Smalltalk will never be recognized as popular: - searches in yahoo - open source projects in some webs - people asking for job The only one that surprized me is the book's one. But 1) the data is not taken from amazon and I don't know this Powell's Books library :P. 2) It's true that there is a stupid amount of java, c#, c++ books... Maybe we can think a not so stupid index. Cheers On Mon, Dec 6, 2010 at 4:12 AM, laurent laffont wrote: And I've just seen the bottom of the message :), it seems http://langpop.com/ agree with TIOBE. On Mon, Dec 6, 2010 at 8:09 AM, laurent laffont wrote: On Mon, 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? According to TIOBE, Smalltalk is as popular as Erlang and more popular than Scala http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html But that's only numbers and I don't trust it :) May be your developer from a popular IDE company should define what popular means... Laurent 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/
Re: [Pharo-project] Comments or no integration: a simple choice for you
On Mon, Dec 6, 2010 at 4:32 PM, csra...@bol.com.br wrote:
Mariano,
Precisely due the size of the problem as you estimated that Stef's plan is
a Good Idea®.
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.
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 .01...
--
Cesar Rabak
Em 05/12/2010 20:07, Mariano Martinez Peck marianop...@gmail.com
escreveu:
On Sun, Dec 5, 2010 at 9:52 PM, Stéphane Ducasse
stephane.duca...@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
x.']) 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
[Pharo-project] [ticket #104592] j'ai l'impression que la mailing-list de pharo ne marche plus
Bonjour, S'agit-il bien de la liste pharo-project ? Si oui, le dernier message est daté du Last message date: Mon Dec 6 19:11:38 CET 2010. En parcourant l'archive par thread, il y a effectivement des messages du 6 décembre, fin d'après-midi. Pourriez-vous peut-être préciser les éléments qui vous laissent à penser à une panne de la liste ? Cordialement, -- BD / ET-INRIA_GForge On Fri Dec 03 22:12:07 2010, sducasse wrote: pouvez-vous verifier? merci
Re: [Pharo-project] Comments or no integration: a simple choice for you
laurent laffont wrote: IMHO, before we take such a stance, we should have a package comment pane and encourage its use. A complex package is probably best documented with a good high-level description and some type of example(s), which can take the form of do-its in a package comment. HelpSystem does this and is included in PharoCore. See http://www.pharocasts.com/2010/09/document-with-helpsystem.html What if the source pane in the browser showed the first page of the package's help when only a package name was selected? And there could be a shortcut/cataegory-list-menu-option to open the help browser on the package's help from the browser! Sean -- View this message in context: http://forum.world.st/Comments-or-no-integration-a-simple-choice-for-you-tp3073643p3075057.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Comments or no integration: a simple choice for you
I love this idea! Mariano Martinez Peck 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. It seemed to me this plan is being suggested precisely because push and promote has not produced results. In face, I would say this grand challenge is a pretty good push ;-) Plus, it's more fun than trying to put more comments before the next release. Fortune favors the bold! Sean -- View this message in context: http://forum.world.st/Comments-or-no-integration-a-simple-choice-for-you-tp3073643p3075065.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] Pharo Wishlist (was Native Windows in Pharo)
There was a ( hijacked ;-) ) thread on the user list about a feature wishlist. Although I think the Benevolent Dictator model is better suited for this stage of Pharo's evolution, it would be cool for the dictators (since they are benevolent and the opin-ers will not disappear) to see what the community is passionate about. The reference was to the http://uservoice.com/ online app, which I've enjoyed using for PersonalBrain (http://www.thebrain.com/) Sean See relevant quotes below from http://forum.world.st/Native-Windows-in-Pharo-td3071794.html: Andres Fortier-2 wrote: Ok, I see. Is there a wishlist associated with Pharo? Something like http://feedback.assembla.com/? thanks! Andrés Mariano Martinez Peck wrote: There are some related pages in http://code.google.com/p/pharo/w/list For exampple: http://code.google.com/p/pharo/wiki/IdeasToImplement cheers mariano Andres Fortier-2 wrote: Thanks Mariano! I was looking for something more formal, to let user's vote for features and a commitment of the dev team to include N of the most voted per release (of course N depends on the release cycle and the feature complexity). Thanks! Andrés -- View this message in context: http://forum.world.st/Pharo-Wishlist-was-Native-Windows-in-Pharo-tp3075089p3075089.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Global shortcut keys in Pharo
Yes Yes Yes!!! I'll push on that! :D Let's join forces, it's better than be alone in the dark :). On Sun, Dec 5, 2010 at 9:48 PM, Tony Fleig tony.fl...@gmail.com wrote: Sean, what is the URL of your SqS projects page? TF On Sun, Dec 5, 2010 at 6:59 AM, Sean P. DeNigris s...@clipperadams.com wrote: Mariano Martinez Peck wrote: I remember... Sean working on KeyMapping, KeyBindings or something like that. Yes, I ported KeyMapping to Pharo because it seemed like the model people liked best. IIRC KeyBindings probably wouldn't be too hard to port. Both are on SqueakSource, but if I didn't have write access, check my SqS projects page for updated versions. Cheers, Sean -- View this message in context: http://forum.world.st/Global-shortcut-keys-in-Pharo-tp3072091p3073313.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Global shortcut keys in Pharo
Downloading Keymapping from sqs... Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: '1.0') load :) On Mon, Dec 6, 2010 at 4:01 PM, Guillermo Polito guillermopol...@gmail.comwrote: Yes Yes Yes!!! I'll push on that! :D Let's join forces, it's better than be alone in the dark :). On Sun, Dec 5, 2010 at 9:48 PM, Tony Fleig tony.fl...@gmail.com wrote: Sean, what is the URL of your SqS projects page? TF On Sun, Dec 5, 2010 at 6:59 AM, Sean P. DeNigris s...@clipperadams.com wrote: Mariano Martinez Peck wrote: I remember... Sean working on KeyMapping, KeyBindings or something like that. Yes, I ported KeyMapping to Pharo because it seemed like the model people liked best. IIRC KeyBindings probably wouldn't be too hard to port. Both are on SqueakSource, but if I didn't have write access, check my SqS projects page for updated versions. Cheers, Sean -- View this message in context: http://forum.world.st/Global-shortcut-keys-in-Pharo-tp3072091p3073313.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Global shortcut keys in Pharo
Ok, I've uploaded version 1.1 of the configuration with some little fixes. On Mon, Dec 6, 2010 at 4:07 PM, Guillermo Polito guillermopol...@gmail.comwrote: Downloading Keymapping from sqs... Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: '1.0') load :) On Mon, Dec 6, 2010 at 4:01 PM, Guillermo Polito guillermopol...@gmail.com wrote: Yes Yes Yes!!! I'll push on that! :D Let's join forces, it's better than be alone in the dark :). On Sun, Dec 5, 2010 at 9:48 PM, Tony Fleig tony.fl...@gmail.com wrote: Sean, what is the URL of your SqS projects page? TF On Sun, Dec 5, 2010 at 6:59 AM, Sean P. DeNigris s...@clipperadams.com wrote: Mariano Martinez Peck wrote: I remember... Sean working on KeyMapping, KeyBindings or something like that. Yes, I ported KeyMapping to Pharo because it seemed like the model people liked best. IIRC KeyBindings probably wouldn't be too hard to port. Both are on SqueakSource, but if I didn't have write access, check my SqS projects page for updated versions. Cheers, Sean -- View this message in context: http://forum.world.st/Global-shortcut-keys-in-Pharo-tp3072091p3073313.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Popularity or not of smalltalk?
csrabak wrote: The persons needed about the same than the Java colleagues (which worked in a complimentary part of the project) to become proficient and productive in Smalltalk. But by the time I was proficient and productive in Smalltalk, I had mastered the equivalent of an OS! From threading, to windows, the main event loop - all things that were magically behind the scenes in C, C++, and even Ruby to an extent (which at the outer GUI level was down in the same mess). Whereas, it really did take only one reading to grok the syntax. csrabak wrote: We Smalltalkers take sometimes at face value certain things that clash in real world: the famous simplicity of the syntax (which Stef's famous postcard example) of Smalltalk is completely flared by the overwhelming complexity of the class libraries. The fact that mastering anything takes time - is orthogonal to the book issue. The majority of books I came across in C++ (and needed copies of in every office I worked, to the point where I got a $50 a month Safari books subscription) were related to the language, not the libraries - full of tips, gotchas, and other advice to not trip over the complexities of the language itself - before even considering the first library! The ease of use of a library is a function of the design skill of the library developers. But I bet you it was much easier to *write* that library than it would have been in a static language in a non-live environment ;-) Sean -- View this message in context: http://forum.world.st/Popularity-or-not-of-smalltalk-tp3073990p3075155.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Global shortcut keys in Pharo
tfleig wrote: Sean, what is the URL of your SqS projects page? MCHttpRepository location: 'http://www.squeaksource.com/SPDProjectUpdates' user: '' password: '' -- View this message in context: http://forum.world.st/Global-shortcut-keys-in-Pharo-tp3072091p3075175.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Pharo integration in enterprise feedback
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% 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 :) Cheers, Doru On 2 Dec 2010, at 03:49, csra...@bol.com.br wrote: Em 01/12/2010 18:50, Tudor Girba tudor.gi...@gmail.com escreveu: Hi, I think I understand your point of view, but I do not agree with it :). Fair enough! During a debate automatic agreement would not lead to an enriched vision of the problem and more often than not would diverge from the truth :-) Moose is a valuable platform exactly because it is built in Smalltalk. I understand this is the sentiment about Smalltalk. Also, giving the project is 13+ years old makes me assume it has started in a different dialect of Smalltalk than Pharo. Developers understand the power of Smalltalk in the context of Moose quite quickly after they do a couple of tutorials. The key here, I think, is in the context of Moose. In my opinion the litmus test for this would be evaluating how many projects _not_ related to Moose are started in Smalltalk after this exposition occurred. The result is that they end up wanting to learn Smalltalk. Which per se is an interesting achievement. However, we need it go beyond the wanting to learn to the opportunity to be the implementation language of some new projects in their realms. In fact, I argued for quite a while that vendors should use Moose to promote Smalltalk. The cool thing about it is that it addresses directly programmers that develop in all sorts of languages (especially Java). This gives us a nice back door. I think again this is a variation of theme I mentioned in the earlier post. The same has been said about Seaside, or other projects which I perceive as successful as Moose (and written in Smalltalk, of course)! I'm afraid we're missing something essential on this: what problem Pharo (or more generally Smalltalk) addresses better in the enterprise than other technologies? If we arrive at some compelling answers to this, then I believe it would be easy to 'sell' Smalltalk. The examples on the successful projects then would serve to reduce the perceived risk of embarking in an imature technology. my 0.01... Regards, -- Cesar Rabak Cheers, Doru On 28 Nov 2010, at 18:48, csra...@bol.com.br wrote: Tudor, This kind of report shows that Moose is a useful piece of software. The interest in Pharo became contingent on the Moose technology such as ABAP is 'widespread' in the industry because of SAP ERP. I think it says a lot about Moose, but is not enough to be a sales argument for Pharo. This leads to a common fallacy used in marketing: use X as all successful people use X as well... -- www.tudorgirba.com Reasonable is what we are accustomed with.
Re: [Pharo-project] Popularity or not of smalltalk?
This kind of view is nice as a joke, but I also think it tends to be counter productive. We should not kid ourselves. There are so many books because there is a market large enough to consume them. Cheers, Doru On 6 Dec 2010, at 13:44, Igor Stasenko wrote: On 6 December 2010 13:38, Guillermo Polito guillermopol...@gmail.com wrote: JAjajaja, It's not that Indexes are not trustable... They are measured in a way Smalltalk will never be recognized as popular: - searches in yahoo - open source projects in some webs - people asking for job The only one that surprized me is the book's one. But 1) the data is not taken from amazon and I don't know this Powell's Books library :P. 2) It's true that there is a stupid amount of java, c#, c++ books... i think there is a lot of books because they are very complex ones :) for a smalltalk, you need just one book, and .. whooop .. you know it after few days of study. For C++ or Java it takes couple of months to learn all this stuff.. Maybe we can think a not so stupid index. Cheers On Mon, Dec 6, 2010 at 4:12 AM, laurent laffont laurent.laff...@gmail.com wrote: And I've just seen the bottom of the message :), it seems http://langpop.com/ agree with TIOBE. On Mon, Dec 6, 2010 at 8:09 AM, laurent laffont laurent.laff...@gmail.com wrote: On Mon, Dec 6, 2010 at 6:51 AM, James Ladd james_l...@hotmail.com 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? According to TIOBE, Smalltalk is as popular as Erlang and more popular than Scala http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html But that's only numbers and I don't trust it :) May be your developer from a popular IDE company should define what popular means... Laurent 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/ -- Best regards, Igor Stasenko AKA sig. -- www.tudorgirba.com Presenting is storytelling.
[Pharo-project] Smalltalk in small steps ?
Hi All, As some of you may know I am writing a Smalltalk for the Java Virtual Machine and it is coming along well. http://redline.st with source on http://github.com Recently I came across a series of blog posts by Peter Michaux on Scheme from scratch and I wondered: Would it be worth while for the Smalltalk community, and language enthusiasts if I were to do the same with Redline Smalltalk, that is, make each features implementation part of a blog post and a 'work along' ? Would you like to see this and or work along with Redline ? Rgs, James.
Re: [Pharo-project] Pharo Wishlist (was Native Windows in Pharo)
On Mon, Dec 6, 2010 at 7:58 PM, Sean P. DeNigris s...@clipperadams.comwrote: There was a ( hijacked ;-) ) thread on the user list about a feature wishlist. Although I think the Benevolent Dictator model is better suited for this stage of Pharo's evolution, it would be cool for the dictators (since they are benevolent and the opin-ers will not disappear) to see what the community is passionate about. The reference was to the http://uservoice.com/ online app, which I've enjoyed using for PersonalBrain (http://www.thebrain.com/) I guess that if someone can give it a try (create the survey, etc), pharaoers will vote. Sean See relevant quotes below from http://forum.world.st/Native-Windows-in-Pharo-td3071794.html: Andres Fortier-2 wrote: Ok, I see. Is there a wishlist associated with Pharo? Something like http://feedback.assembla.com/? thanks! Andrés Mariano Martinez Peck wrote: There are some related pages in http://code.google.com/p/pharo/w/list For exampple: http://code.google.com/p/pharo/wiki/IdeasToImplement cheers mariano Andres Fortier-2 wrote: Thanks Mariano! I was looking for something more formal, to let user's vote for features and a commitment of the dev team to include N of the most voted per release (of course N depends on the release cycle and the feature complexity). Thanks! Andrés -- View this message in context: http://forum.world.st/Pharo-Wishlist-was-Native-Windows-in-Pharo-tp3075089p3075089.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Problem updating Pharo Core
On Dec 6, 2010, at 7:59 PM, Guillermo Polito wrote: I have the last prebuild pharo core (12261), and clicking on update stops in version 12266 with a DNU: nil does not understand binary It has something to do with the monticello a version with this info: 'Issue 3191:SparseLargeArray-MarcusDenker.2.mcz' Did someone had this same issue? the build server seems to have no problem: https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/ -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Issue 1594 in pharo: refactor to use #ifNil:
In a VM mail Andreas said: 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. I don't know if this is related to this issue. cheers mariano On Thu, Dec 2, 2010 at 10:50 PM, Peter van Rooijen pe...@vanrooijen.comwrote: On Thu, 02 Dec 2010 12:32:02 +0100, Levente Uzonyi le...@elte.hu wrote: On Thu, 2 Dec 2010, Peter van Rooijen wrote: I agree, If you want to know if a object is the same object as that designated by the expression nil, you use the message #== (this message had guaranteed semantics since it can not be redefined). If you want to know if the message ifNil: aBlock sent to the object evaluates the block argument, you use the message #ifNil: (which could do anything it has been defined to do - at least, I would hope so!). Those two uses are distinct and mean something different. In theory yes, but the compiler also inlines #ifNil:, #ifNil:ifNotNil:, #ifNotNil: and #ifNotNil:ifNil: if the arguments are literal blocks. So in that case, they are equivalent with == nil ifTrue:/ifFalse:. Thanks for explaining, I wasn't aware of that. Seems like a really ugly hack to me. Deciding semantics based on an argument type, before the receiver type is known...extremely fishy. Now, if the compiler inlined [...] ifNil: something that would be a different matter, since the receiver class is known at compile time, and it's not such a big deal to require those semantics to be fixed. Cheers, Peter Levente
Re: [Pharo-project] Problem updating Pharo Core
Oh, can I download the last core from there? :D On Mon, Dec 6, 2010 at 6:11 PM, Marcus Denker marcus.den...@inria.frwrote: On Dec 6, 2010, at 7:59 PM, Guillermo Polito wrote: I have the last prebuild pharo core (12261), and clicking on update stops in version 12266 with a DNU: *nil does not understand binary* It has something to do with the monticello a version with this info: 'Issue 3191:SparseLargeArray-MarcusDenker.2.mcz' Did someone had this same issue? the build server seems to have no problem: https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/ -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Popularity or not of smalltalk?
On 6 December 2010 21:22, Tudor Girba tudor.gi...@gmail.com wrote: This kind of view is nice as a joke, but I also think it tends to be counter productive. We should not kid ourselves. There are so many books because there is a market large enough to consume them. No, but you know, books about Java or C++ dedicating a full chapters explaining classes, visibility rules, constructors, destructors, virtual functions, templates or generics and all things related to that. A lot of wasted paper (where the Green Peace looking? ;)) And now take the smalltalk at the other side. What we have? Just classes and methods. Simple rules. End. So, at the day when one student finish learning the basics of java or C++, a student who decided to learn smalltalk will finish learning a standard class library basics, and will be ready to go with first coding attempts. While Java/C++ student will still be 2 or 3 chapters away from finishing with basic language concepts and rules. It is a lot of time for reading, not mentioned about how much time it takes to comprehend and understand all the concepts and remember them. Yes, maybe its a bigger market. But i know a good way to learn something: write a description (book) of it. So it looks like many people wanting to learn C++ or Java so bad, that they start writing a books about it. Good for them. Good for readers. Bad for Green Peace :) Cheers, Doru -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Smalltalk in small steps ?
On 6 December 2010 21:50, James Ladd james_l...@hotmail.com wrote: Hi All, As some of you may know I am writing a Smalltalk for the Java Virtual Machine and it is coming along well. http://redline.st with source on http://github.com Recently I came across a series of blog posts by Peter Michaux on Scheme from scratch and I wondered: Would it be worth while for the Smalltalk community, and language enthusiasts if I were to do the same with Redline Smalltalk, that is, make each features implementation part of a blog post and a 'work along' ? It is good for readers like me. Since you can describe the choices you made along the road and explain why you go that direction rather than another one. It is always interesting reading about such things. So, please do :) Would you like to see this and or work along with Redline ? Rgs, James. -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Popularity or not of smalltalk?
Hi James, a good list of enterprise projects is here http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=successes. The high-lights are JP Morgan, and Texas Instruments/Adventa. But also try and dig up stuff on OOCL's ISIS 2 shipping app and Deutche Bahn's schduling application (computes schedules for the entire German railway system). If you dig you'll find lots of enterprise applications written in Smalltalk. When I started working for ParcPlace Systems companies like JPMorgan didn't allow us to name then since using Smalltalk was such an important competitive advantage. That shot a lot of feet, indiscriminately amongst both corporate user and vendo aliker. On Sun, Dec 5, 2010 at 9:51 PM, James Ladd james_l...@hotmail.com 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/
Re: [Pharo-project] Popularity or not of smalltalk?
On 6 December 2010 23:22, Eliot Miranda eliot.mira...@gmail.com wrote: Hi James, a good list of enterprise projects is here http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=successes. The high-lights are JP Morgan, and Texas Instruments/Adventa. But also try and dig up stuff on OOCL's ISIS 2 shipping app and Deutche Bahn's schduling application (computes schedules for the entire German railway system). If you dig you'll find lots of enterprise applications written in Smalltalk. When I started working for ParcPlace Systems companies like JPMorgan didn't allow us to name then since using Smalltalk was such an important competitive advantage. That shot a lot of feet, indiscriminately amongst both corporate user and vendo aliker. That's kind of fun. It reminds me the fisherman, who i met once on the lake, and when i said that i came here just for one day as a guest of my really far relatives, then he smiled and started saying everything about fishing, and saying that at his place, a fish catching goes like on conveyor, but for all people who passed by, he was making a bored face and saying that , ohhh.. no fish damn it.. no fish.. bad place, reaallyy bad one :) -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Popularity or not of smalltalk?
On Mon, Dec 6, 2010 at 2:38 PM, Igor Stasenko siguc...@gmail.com wrote: On 6 December 2010 23:22, Eliot Miranda eliot.mira...@gmail.com wrote: Hi James, a good list of enterprise projects is here http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=successes . The high-lights are JP Morgan, and Texas Instruments/Adventa. But also try and dig up stuff on OOCL's ISIS 2 shipping app and Deutche Bahn's schduling application (computes schedules for the entire German railway system). If you dig you'll find lots of enterprise applications written in Smalltalk. When I started working for ParcPlace Systems companies like JPMorgan didn't allow us to name then since using Smalltalk was such an important competitive advantage. That shot a lot of feet, indiscriminately amongst both corporate user and vendo aliker. That's kind of fun. It reminds me the fisherman, who i met once on the lake, and when i said that i came here just for one day as a guest of my really far relatives, then he smiled and started saying everything about fishing, and saying that at his place, a fish catching goes like on conveyor, but for all people who passed by, he was making a bored face and saying that , ohhh.. no fish damn it.. no fish.. bad place, reaallyy bad one :) it's great for the fisherman, but really bad for the bait shop... :) :( :/ best Eliot -- Best regards, Igor Stasenko AKA sig.
[Pharo-project] Teleplace is hiring...
Hi All, Are you eager to work on cutting-edge business communications technology? Are you passionate about UI design? Do you have significant experience implementing innovative user interfaces in Smalltalk? Do you and your peers consider yourself a strong Smalltalk programmer? If so, Teleplace is hiring and looking for someone just like you. Please send resumes to Stephen Ceplenski st...@teleplace.com, Andreas Raab andreas.r...@teleplace.com or myself, Eliot Miranda el...@teleplace.com. best Eliot
Re: [Pharo-project] Popularity or not of smalltalk?
Sorry if I'm late on this thread, only wanted to say that lot of times in similar discussions I said that fortunately Smalltalk is not very popular (In terms that not tons of people and companies are using it). Each one can make its own interpretation :) Just my 0,02. 2010/12/6 Eliot Miranda eliot.mira...@gmail.com: On Mon, Dec 6, 2010 at 2:38 PM, Igor Stasenko siguc...@gmail.com wrote: On 6 December 2010 23:22, Eliot Miranda eliot.mira...@gmail.com wrote: Hi James, a good list of enterprise projects is here http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=successes. The high-lights are JP Morgan, and Texas Instruments/Adventa. But also try and dig up stuff on OOCL's ISIS 2 shipping app and Deutche Bahn's schduling application (computes schedules for the entire German railway system). If you dig you'll find lots of enterprise applications written in Smalltalk. When I started working for ParcPlace Systems companies like JPMorgan didn't allow us to name then since using Smalltalk was such an important competitive advantage. That shot a lot of feet, indiscriminately amongst both corporate user and vendo aliker. That's kind of fun. It reminds me the fisherman, who i met once on the lake, and when i said that i came here just for one day as a guest of my really far relatives, then he smiled and started saying everything about fishing, and saying that at his place, a fish catching goes like on conveyor, but for all people who passed by, he was making a bored face and saying that , ohhh.. no fish damn it.. no fish.. bad place, reaallyy bad one :) it's great for the fisherman, but really bad for the bait shop... :) :( :/ best Eliot -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent
On Sun, 05 Dec 2010 12:44:46 -0800 jaayer wrote Is anyone else bother[ed] by this inconsistency? Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait).
Re: [Pharo-project] Category Renaming under Monticello
Hendrik, Thanks for all the help. It seems that changing the category programmatically like this works: ((SystemOrganization listAtCategoryNamed: 'Zinc-HTTP-New-Client-Server') collect: [ :className | Smalltalk globals at: className ]) do: [ :each | each category: 'Zinc-HTTP-Client-Server' ] Now MC did pick up the changes. Sven On 06 Dec 2010, at 16:07, Henrik Johansen wrote: On Dec 6, 2010, at 3:52 08PM, Sven Van Caekenberghe wrote: On 06 Dec 2010, at 15:42, Henrik Johansen wrote: If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place. OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ? And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ? Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ? Anyway, thanks for the reply. Sven IIRC, (big if), the package corresponding to the category that was renamed will not contain any code if you browse it, but neither is it marked as dirty. So by default, you probably wouldn't publish the new, empty version of the package unless you looked for it specifically. New packages created before or after renaming an existing category will not be marked dirty as a consequence of the category rename either. If you change the category of a single class however, both old and new package will be marked dirty. (Except if you create the new package after performing the rename) TLDR; The packages will contain the correct code, if you publish them. Marking packages as dirty does not work for category renames, but do work for single class renaming done by recompiling class definition. Cheers, Henry
Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent
On 6 December 2010 23:52, jaayer jaa...@zoho.com wrote: On Sun, 05 Dec 2010 12:44:46 -0800 jaayer wrote Is anyone else bother[ed] by this inconsistency? Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait). 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. One might argue, that its more userful to make it same as #removeKey:, other one could point that its should be symmetrical to #add: , 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 :) -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Teleplace is hiring...
Great news to hear that there *are* Smalltalk jobs out there after all! :-) But, still none in Sweden (yet) :-( Good luck finding the right person (or persons)! -- Cheers, Peter On Mon, Dec 6, 2010 at 11:51 PM, Eliot Miranda eliot.mira...@gmail.comwrote: Hi All, Are you eager to work on cutting-edge business communications technology? Are you passionate about UI design? Do you have significant experience implementing innovative user interfaces in Smalltalk? Do you and your peers consider yourself a strong Smalltalk programmer? If so, Teleplace is hiring and looking for someone just like you. Please send resumes to Stephen Ceplenski st...@teleplace.com, Andreas Raab andreas.r...@teleplace.com or myself, Eliot Miranda el...@teleplace.com. best Eliot
Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent
On Mon, 06 Dec 2010 15:07:34 -0800 Igor Stasenko wrote On 6 December 2010 23:52, jaayer wrote: On Sun, 05 Dec 2010 12:44:46 -0800 jaayer wrote Is anyone else bother[ed] by this inconsistency? Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait). 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. 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? -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] [squeak-dev] Teleplace is hiring...
Indeed, very very good news to Smalltalk community. 2010/12/6 Eliot Miranda eliot.mira...@gmail.com: Hi All, Are you eager to work on cutting-edge business communications technology? Are you passionate about UI design? Do you have significant experience implementing innovative user interfaces in Smalltalk? Do you and your peers consider yourself a strong Smalltalk programmer? If so, Teleplace is hiring and looking for someone just like you. Please send resumes to Stephen Ceplenski st...@teleplace.com, Andreas Raab andreas.r...@teleplace.com or myself, Eliot Miranda el...@teleplace.com. best Eliot
Re: [Pharo-project] Teleplace is hiring...
On Mon, Dec 6, 2010 at 2:51 PM, Eliot Miranda eliot.mira...@gmail.comwrote: Hi All, Are you eager to work on cutting-edge business communications technology? Are you passionate about UI design? Do you have significant experience implementing innovative user interfaces in Smalltalk? Do you and your peers consider yourself a strong Smalltalk programmer? If so, Teleplace is hiring and looking for someone just like you. Please send resumes to Stephen Ceplenski st...@teleplace.com, Andreas Raab andreas.r...@teleplace.com or myself, Eliot Miranda el...@teleplace.com. best Eliot P.S. A lot of you are asking abut location and whether telecommuting would be possible. Essentially we're flexible. For an exceptional candidate we would try to work with them but ideally the person would be either in or able to relocate to the San Francisco Bay Area. Finding your feet in Teleplace's technology will be a challenge; this is not a straight-forward Smalltalk application, using tea-time, tweak, lots of server-side work and so on. So to find one's feet being in the office will really help. Best that you send in your resumes if you're interested, stating your residency requirements, and let us see where things go from there. best Eliot
Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent
On 7 December 2010 00:18, jaayer jaa...@zoho.com wrote: On Mon, 06 Dec 2010 15:07:34 -0800 Igor Stasenko wrote On 6 December 2010 23:52, jaayer wrote: On Sun, 05 Dec 2010 12:44:46 -0800 jaayer wrote Is anyone else bother[ed] by this inconsistency? Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait). 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. 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 think that most sane developers trying to avoid using inconsistent methods with dictionaries , which inherited from Collection protocol. So, instead of #do:, they using #valuesDo: , dict values select: instead of dict select: and so on. Because otherwise, what is the point of introducting #valuesDo:, which completely duplicating #do: behavior? I see nothing, except an attempt to introduce an explicit and more appropriate protocol for Dictionary. And then ban Collection methods, with questionable behavior (depending on who is questioning ;) ). -- Best regards, Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Comments or no integration: a simple choice for you
Otherwise we can find out how small the dev image can really be. . . ;-) Em 06/12/2010 16:46, Sean P. DeNigris s...@clipperadams.com escreveu: I love this idea! Mariano Martinez Peck 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. It seemed to me this plan is being suggested precisely because push and promote has not produced results. In face, I would say this grand challenge is a pretty good push ;-) Plus, it's more fun than trying to put more comments before the next release. Fortune favors the bold! Sean -- View this message in context: http://forum.world.st/Comments-or-no-integration-a-simple-choice-for-you-tp3073643p3075065.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Popularity or not of smalltalk?
Em 06/12/2010 17:35, Sean P. DeNigris s...@clipperadams.com escreveu: csrabak wrote: e persons needed about the same than the Java colleagues (which worked a complimentary part of the project) to become proficient and productive in Smalltalk. by the time I was proficient and productive in Smalltalk, I had ered the equivalent of an OS! From threading, to windows, the main t loop - all things that were magically behind the scenes in C, C++, and Ruby to an extent (which at the outer GUI level was down in the same ). Whereas, it really did take only one reading to grok the syntax. Well, comparing C, even C++ which normally hasn't automatic garbage collection, is somewhat stretching the argument... but; even with those idiosyncrasies as soon the size of the application grows up, these perks of Smalltalk quickly become less noticeable, while on the other hand the fact Smalltalk being dynamic dispatched takes its toll in the needing of programmers attention to avoid the attribution of wrong objects to instance variables as there is no type checking... csrabak wrote: Smalltalkers take sometimes at face value certain things that clash in al world: the famous simplicity of the syntax (which Stef's famous stcard example) of Smalltalk is mpletely flared by the overwhelming complexity of the class libraries. fact that mastering anything takes time - is orthogonal to the book e. The majority of books I came across in C++ (and needed copies of in y office I worked, to the point where I got a $50 a month Safari books cription) were related to the language, not the libraries - full of , gotchas, and other advice to not trip over the complexities of the uage itself - before even considering the first library! Sean, once you really get to metal subtleties and other nuances on the language and syntax appear to bug your team. Have you ever heard of John McSweeney's Smalltalk ‘Traps’ piece¹? ease of use of a library is a function of the design skill of the ary developers. But I bet you it was much easier to *write* that ary than it would have been in a static language in a non-live ronment ;-) While the libraries are for 'endogenous' use, yes, as soon we need to have functionality to put our apps in the same stand as the other technologies are right now, the issues start to become all the same... And them the advantages of Smalltalk as platform vanishes against ones more coupled to present technology. Have you tried to automate an Office application with any flavor of Smalltalk lately? Did you see the thread Is there a good example of an app using SqueakDBX to output data? All the simplicity of Smalltalk is lost as soon you need to fit the square peg in the round hole... :-| my 0.01... -- Cesar Rabak [1] http://www.jmcsweeney.co.uk/computing/m206/traps.doc
Re: [Pharo-project] Pharo integration in enterprise feedback
Em 06/12/2010 18:21, Tudor Girba tudor.gi...@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
Re: [Pharo-project] Smalltalk in small steps ?
Em 06/12/2010 18:50, James Ladd james_l...@hotmail.com escreveu: Hi All, James, As some of you may know I am writing a Smalltalk for the Java Virtual Machine and it is coming along well. http://redline.st with source on http://github.com Recently I came across a series of blog posts by Peter Michaux on Scheme from scratch and I wondered: Would it be worth while for the Smalltalk community, and language enthusiasts if I were to do the same with Redline Smalltalk, that is, make each features implementation part of a blog post and a 'work along' ? If you follow the same line than Michaux's I have to say it will be an expenditure of resources for a very small audience indeed. If you pay attention to the Prerequisites quote This exploration is not for novice programmers. It is a tutorial introduction for novice language implementor and enthusiasts from the perspective of a novice language implementor and enthusiast. /quote Would you like to see this and or work along with Redline ? It is interesting to see how issues of an implementation are being solved. You may get some ideas and suggestions from readers of your blog. HTH -- Cesar Rabak
Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent
On Mon, 06 Dec 2010 15:42:01 -0800 Igor Stasenko wrote On 7 December 2010 00:18, jaayer wrote: On Mon, 06 Dec 2010 15:07:34 -0800 Igor Stasenko wrote On 6 December 2010 23:52, jaayer wrote: On Sun, 05 Dec 2010 12:44:46 -0800 jaayer wrote Is anyone else bother[ed] by this inconsistency? Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait). 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. 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 protocol. It is, however, part of the ANSI 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 think that most sane developers trying to avoid using inconsistent methods with dictionaries , which inherited from Collection protocol. So, instead of #do:, they using #valuesDo: , dict values select: instead of dict select: and so on. Because otherwise, what is the point of introducting #valuesDo:, which completely duplicating #do: behavior? I see nothing, except an attempt to introduce an explicit and more appropriate protocol for Dictionary. And then ban Collection methods, with questionable behavior (depending on who is questioning ;) ). I am not sure if you realize this or not, but dict values select: and dict select: do two different things. The former selects the values of dict into a new collection, as one would expect, while the latter actually creates a new dictionary by filtering the associations from dict based on the values of those associations. Another datum, assuming you were unaware of the difference, for the unintuitiveness and relative uselessness of the enumeration protocol of Dictionary. When have you ever really needed something like what Dictionaryselect: or Dictionarycollect: provides? How often are you interested only in the values of a dictionary and not their corresponding keys? It may be ANSI, but it was poorly thought out, and it stinks. A Dictionary is an unordered collection of associations. That means #add:, #do:, #select:, #size, #includes: and other messages belonging to the basic protocol Dictionary inherits from Collection should operate on associations and not association values. At least, I suspect that's how it would be done if it could be done anew, without any concern for existing standards or backwards compatibility. -- Best regards, Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent
On Mon, 06 Dec 2010 14:52:53 -0800 jaayer wrote On Sun, 05 Dec 2010 12:44:46 -0800 jaayer wrote Is anyone else bother[ed] by this inconsistency? Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value Regardless of what comes of those packages I uploaded, SmallDictionaryremove: and SmallDictionaryremove:ifAbsent: returning two different values is clearly a bug. Looking at it again, I was wrong about SmallDictionaryremove:ifAbsent: returning the key; it does return the removed association. Which means at a minimum, SmallDictionaryremove: only needs to have a ^ inserted at its beginning to fix the discrepancy. - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait).
Re: [Pharo-project] Pharo integration in enterprise feedback
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, csra...@bol.com.br wrote:
Em 06/12/2010 18:21, Tudor Girba tudor.gi...@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
[Pharo-project] Creating a Dev Image
Well I've gone very far by now :). I created a configuration that at least loads :P. There are two problems so far: 1) ECompletion + TextEditor. ECompletion sends #model to TextEditor and It does not understands it. It is easily fixed adding the accessor. 2) Opening an omnibrowser throws a MessageNotUnderstood: TextMorphForShoutEditorfindText. Which I will have a look tomorrow. The version of ConfigurationOfPharo is 1.2-beta2 I've to sleep now :). Tomorrow I'll open an issue for 1) if everyone agrees. With whom should I talk to get 2) fixed? Lukas, Alain? Cheers!
Re: [Pharo-project] Pharo integration in enterprise feedback
Tudor, You cannot convince someone which have already choosen an option. Cheers 2010/12/6 Tudor Girba tudor.gi...@gmail.com: 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% 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 :) Cheers, Doru -- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
Re: [Pharo-project] Popularity or not of smalltalk?
2010/12/7 csra...@bol.com.br Sean, once you really get to metal subtleties and other nuances on the language and syntax appear to bug your team. Have you ever heard of John McSweeney's Smalltalk ‘Traps’ piece¹? Just to compare: http://www.javapuzzlers.com/contents.html :) -- Dennis Schetinin
Re: [Pharo-project] Comments or no integration: a simple choice for you
Hi Stef, To me class comments are not *that* useful. Most of the time I search explanations for contexts of use, which usually involves many classes and methods everywhere. I would remove packages which doesn't include at least some brief or general comments of the main classes or methods, this is less effort for a developer to remember and to document. Or it could be a start. Hernán 2010/12/5 Stéphane Ducasse stephane.duca...@inria.fr: 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'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 -- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
Re: [Pharo-project] Creating a Dev Image
Le 07/12/2010 07:04, Guillermo Polito a écrit : Well I've gone very far by now :). I created a configuration that at least loads :P. There are two problems so far: 1) ECompletion + TextEditor. ECompletion sends #model to TextEditor and It does not understands it. It is easily fixed adding the accessor. 2) Opening an omnibrowser throws a MessageNotUnderstood: TextMorphForShoutEditorfindText. Which I will have a look tomorrow. See issue 3288, there is a .cs for that I guess. 3288 http://code.google.com/p/pharo/issues/detail?id=3288 Cheers Alain The version of ConfigurationOfPharo is 1.2-beta2 I've to sleep now :). Tomorrow I'll open an issue for 1) if everyone agrees. With whom should I talk to get 2) fixed? Lukas, Alain? Cheers!
Re: [Pharo-project] Pharo integration in enterprise feedback
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?
Fun :)
Laurent
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
Re: [Pharo-project] Pharo integration in enterprise feedback
Okay ... I've got another little rant...
Smalltalk improves developer productivity ... pure and simple ... the reason
that developing in Smalltalk is fun is that there is very little that gets in
between the developer and the solution of a problem ... the debugger, inspector
and all of the tools mean that a developer can focus on the problem at hand ...
the dynamic nature of Smalltalk means that I can add instance variables and
change interfaces without having to fight the compiler or the tools ... or lose
track of what I am doing
With that said (here comes the rant:) ... the _enterprise_ is not necessarily
interested in developer productivity...productive developers is way down the
list for the enterprise ... just look at the waste (not just in software) in a
typical corporation ... (end of rant) ...
Smaller companies (not at the enterprise level) _are_ interested in developer
productivity, so that should be the sweet spot for Smalltalk and there is work
to be done to make Smalltalk more attractive to those Smaller companies and it
seems that Pharo is headed in the right direction to become more attractive ...
Note that many development groups within the enterprise operate like smaller
companies, it's just that a CTO of a Fortune 500 company isn't going to
wholesale switch his company from using Java to using Smalltalk (at least not
this year:)...
Oh and GemStone also has enterprise customers who don't necessarily advertise
their Smalltalk success stories.
Dale
On Dec 6, 2010, at 11:00 PM, laurent laffont wrote:
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?
Fun :)
Laurent
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
