October 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] Problem with initials
by Damien Cassou Oct. 31, 2008

Oct. 31, 2008

Hi, I've already seen a ".ducasse" in two commits by two different people: System-al.ducasse.174.mcz System-GwenaelCasaccio.ducasse.178.mcz And also: CollectionsTests-stephane_ducasse.ducasse.98.mcz I don't know what happens, but you should take care of this. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

2 1

Re: [Pharo-project] serial port support?
by Bill Schwab Oct. 30, 2008

Oct. 30, 2008

Lukas, all, Serial ports are a must for me. Whether or not that means they need to be in the base is another question; I vote yes. USB would be of more use if the consortium would spend less time telling us what they are not, and focus on telling us what they are and how to do what we want. Plug-n-play is "simple" until it becomes unpredictable, which is my experience w/ USB in embedded devices. It is wonderful for hooking up printers and flash drives, and is TERRIBLE for configurations that need to "just work" for weeks/months at a time. My Canadian friends (www.connecttech.com) make various cards that add serial ports to machines; their hardware and drivers are basically bullet proof. The notable exception is their USB-serial product, which works, but suffers from USB grumpiness. Please think of serial ports as being alive and well. They are very commonly used in the embedded systems world. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> renggli(a)gmail.com 10/30/2008 1:53 AM >>> On Thu, Oct 30, 2008 at 7:44 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > I was glancing thru the source code and noticed we have the serial port & > midi classes. > Do we need those in the base Pharo? I don't think so. The serial port seems to be rarely used nowadays. It would be more interesting to have access to the USB ports. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] other odds & ends to drop
by John M McIntosh Oct. 30, 2008

Oct. 30, 2008

These methods on SmalltalkImage can be deleted startProfiling stopProfiling clearProfile dumpProfile These are no longer implemented in any VM created in the last 10 years http://isqueak.org/clearProfile I noticed a SmalltalkImage>>licenseString and a SystemDictionary>>copyright and a Utilities (class)>>copyrightNotice I'd guess someone should consolidate those into one place? what's SystemDictionary>>nihongoVersion for? -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

3 2

[Pharo-project] setGCParameters & setGCBiasToGrowGCLimit
by John M McIntosh Oct. 30, 2008

Oct. 30, 2008

In setGCParameters if we do Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. Smalltalk setGCBiasToGrow: 1. Then we'll avoid some nasty GC edge cases. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

2 1

[Pharo-project] serial port support?
by John M McIntosh Oct. 30, 2008

Oct. 30, 2008

I was glancing thru the source code and noticed we have the serial port & midi classes. Do we need those in the base Pharo? -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

3 2

[Pharo-project] less than 10
by Norbert Hartl Oct. 30, 2008

Oct. 30, 2008

Hi guys, not much time to scan email. But I did an update right now and saw that the image dropped below 10 MB. It does not mean anything but to me it is a magical border. Things are moving real fast. I'm sad not able to have time to join. But I wanted to note that you all are doing an incredible job. Go go go!! regards, Norbert

3 2

[Pharo-project] please do not update.
by StÃ©phane Ducasse Oct. 29, 2008

Oct. 29, 2008

I will have to cancel 10120 and may 10119 because of a huge mess. Stef

2 2

[Pharo-project] ToolSet
by Pavel Krivanek Oct. 29, 2008

Oct. 29, 2008

Hi, we should decide how we will manipulate with tools. A lot of tools classes are referenced directly - that is wrong because you cannot then use different set of tools (for example a dummy toolset for no tools at all). In the KernelImage I added a registration mechanism for tools so they were called for example ToolSet default browser. There were no ToolSet subclasses and there was only a test if the default ToolSet is not nil. That was not optimal solution. The current philosophy of ToolSet class supposess that you will send messages directly to ToolSet class and you will not get real tools classes at all. However the set of this messages would be very long and Squeak wants sometimes directly the class (for comparison etc.) The default tools are: browser changeList changeSorter changedMessageSet classCommentVersionsBrowser classListBrowser debugger dualChangeSorter hierarchyBrowser instanceBrowser lexicon messageNames messageSet packagePaneBrowser pointerFinder protocolBrowser versionsBrowser Cheers, -- Pavel

8 12

Oct. 29, 2008

what is a scriptingSystem in morphic. To me it looks like a object knowing some stuff about the environment and mostly used by etoys. Stef

2 2

[Pharo-project] ToolSet -> ToolRegistry
by Igor Stasenko Oct. 29, 2008

Oct. 29, 2008

I'm implemented a new ToolRegistry class, which can work as replacement of ToolSet. It would require a 'bit' refactoring, to replace all references to 'ToolSet' with 'Smalltalk tools'. What i discovered during implementation, if we migrate to new class, a lot of stuff can be cleaned up. For instance, Smalltalk tools inspectorTypes holds a dictionary of Class name -> inspector class name so, one could simply register own inspector by including a line: Smalltalk tools inspectorTypes at: #MySpecialClass put: #MySpecialInspector in package/class initialization method, instead of overriding #inspect method. Also, during copying a StandartToolSet convenience methods implementation i discovered a lot of tools which support different protocols. It would be nice to at least make them all respond to same message, like #open. Because currently, if you take a look at different #openXXXXX methods in ToolRegistry, its using many different/weird selectors to do the simplest possible thing - open a new window! In attachments you can find the actual class, and a small changeset which is required to make magic 'Smalltalk tools' working. I decided to put default tools/inspectors types in Preferences class. See Preferences class>>registerPreferredTools method in changeset. -- Best regards, Igor Stasenko AKA sig.

2 2