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

Re: [Pharo-project] serial port support?

by Bill Schwab

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

Oct. 30, 2008

Re: [Pharo-project] RBParser

by StÃ©phane Ducasse

:) Thanks! Stef On Oct 30, 2008, at 1:40 PM, Gwenael Casaccio wrote: > Published :) > > On 10/30/08 1:20 PM, StÃ©phane Ducasse wrote: >>> >>>> gwenael what lukas is implying is that this is important that you >>>> publish your work in a place >>>> where other people can read it. >>> >>> Off course I'll publish it ! >> >> I know. What lukas is implying is that if you publish in the RB >> repository then he will have less problems to merge >> >>> I've just asked him about these modifications with the tokens >>> hierarchy. >>> >>> By the way I've made a stupid benchmark between the Parser and >>> RBParser on the entire image and RBParser is 5 sec slower than >>> Parser >>> (122 sec for the RBParser and 117 sec for the Parser) >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 30, 2008

Re: [Pharo-project] RBParser

by Gwenael Casaccio

Published :) On 10/30/08 1:20 PM, StÃ©phane Ducasse wrote: >> >>> gwenael what lukas is implying is that this is important that you >>> publish your work in a place >>> where other people can read it. >> >> Off course I'll publish it ! > > I know. What lukas is implying is that if you publish in the RB > repository then he will have less problems to merge > >> I've just asked him about these modifications with the tokens hierarchy. >> >> By the way I've made a stupid benchmark between the Parser and >> RBParser on the entire image and RBParser is 5 sec slower than Parser >> (122 sec for the RBParser and 117 sec for the Parser) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 30, 2008

Re: [Pharo-project] RBParser

by StÃ©phane Ducasse

> >> gwenael what lukas is implying is that this is important that you >> publish your work in a place >> where other people can read it. > > Off course I'll publish it ! I know. What lukas is implying is that if you publish in the RB repository then he will have less problems to merge > I've just asked him about these modifications with the tokens > hierarchy. > > By the way I've made a stupid benchmark between the Parser and > RBParser on the entire image and RBParser is 5 sec slower than > Parser (122 sec for the RBParser and 117 sec for the Parser)

Oct. 30, 2008

Re: [Pharo-project] RBParser

by Gwenael Casaccio

On 10/30/08 12:58 PM, StÃ©phane Ducasse wrote: > gwenael what lukas is implying is that this is important that you > publish your work in a place > where other people can read it. Off course I'll publish it ! I've just asked him about these modifications with the tokens hierarchy. By the way I've made a stupid benchmark between the Parser and RBParser on the entire image and RBParser is 5 sec slower than Parser (122 sec for the RBParser and 117 sec for the Parser) > > Stef > > On Oct 30, 2008, at 10:49 AM, Gwenael Casaccio wrote: > >> On 10/29/08 6:21 PM, Lukas Renggli wrote: >>>> As I've said to you Marcus, I've worked on the RBParser/RBScanner. I've >>>> fixed these classes and now you can parse the entire image. At this >>>> moment >>>> the refactoring is not yet finished but I've made some good progress. >>> >>> Good news. >>> >>> I was not aware that you were working on RBParser. Stef told me that >>> you also improved the refactorings. I think you should commit and work >>> on the public repository to get more attention. I guess there were >>> many other changes going on in RB codebase in the meantime. >>> >>> Cheers, >>> Lukas >>> >> >> I've also discused with stef and marcus and I would like to have only >> RBToken. I don't know what do you think ? >> >> >> Cheers, >> Gwenael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 30, 2008

Re: [Pharo-project] RBParser

by StÃ©phane Ducasse

gwenael what lukas is implying is that this is important that you publish your work in a place where other people can read it. Stef On Oct 30, 2008, at 10:49 AM, Gwenael Casaccio wrote: > On 10/29/08 6:21 PM, Lukas Renggli wrote: >>> As I've said to you Marcus, I've worked on the RBParser/RBScanner. >>> I've >>> fixed these classes and now you can parse the entire image. At >>> this moment >>> the refactoring is not yet finished but I've made some good >>> progress. >> >> Good news. >> >> I was not aware that you were working on RBParser. Stef told me that >> you also improved the refactorings. I think you should commit and >> work >> on the public repository to get more attention. I guess there were >> many other changes going on in RB codebase in the meantime. >> >> Cheers, >> Lukas >> > > I've also discused with stef and marcus and I would like to have > only RBToken. I don't know what do you think ? > > > Cheers, > Gwenael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 30, 2008

Re: [Pharo-project] other odds & ends to drop

by StÃ©phane Ducasse

thanks we will fix that! Stef On Oct 30, 2008, at 8:38 AM, Damien Cassou wrote: > On Thu, Oct 30, 2008 at 8:27 AM, John M McIntosh > <johnmci(a)smalltalkconsulting.com> wrote: >> 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 > > Issue 303 > > >> I noticed a SmalltalkImage>>licenseString >> and a SystemDictionary>>copyright >> and a Utilities (class)>>copyrightNotice >> >> I'd guess someone should consolidate those into one place? > > > Issue 304. > > Thank you > > -- > 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) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 30, 2008

Re: [Pharo-project] RBParser

by Gwenael Casaccio

On 10/29/08 6:21 PM, Lukas Renggli wrote: >> As I've said to you Marcus, I've worked on the RBParser/RBScanner. I've >> fixed these classes and now you can parse the entire image. At this moment >> the refactoring is not yet finished but I've made some good progress. > > Good news. > > I was not aware that you were working on RBParser. Stef told me that > you also improved the refactorings. I think you should commit and work > on the public repository to get more attention. I guess there were > many other changes going on in RB codebase in the meantime. > > Cheers, > Lukas > I've also discused with stef and marcus and I would like to have only RBToken. I don't know what do you think ? Cheers, Gwenael

Oct. 30, 2008

[Pharo-project] How to load OmniBrowser into Pharo

by David RÃ¶thlisberger

Hi, during the recent days we worked hard on OmniBrowser to extend, improve and stabilize it. We also improved the loading process of all required packages to run OmniBrowser (system and package browser). In the latest version of ScriptLoader you will find three load methods for OB: #loadOB loads the latest stable version linked in Universe. Use this to be on the safe side #loadOBAlpha loads the latest development version of all required packages stored in source.wiresong.ca/ob. Use this if you want to be on the cutting edge. ;) #loadSuperOB does the same as #loadOBAlpha, but also loads additional packages, for instance to get visualizations directly in OB. You use this to get everything. ;) Cheers, David

Oct. 30, 2008

Re: [Pharo-project] setGCParameters & setGCBiasToGrowGCLimit

by Damien Cassou

On Thu, Oct 30, 2008 at 8:29 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > In setGCParameters > if we do > Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. > Smalltalk setGCBiasToGrow: 1. > > Then we'll avoid some nasty GC edge cases. Issue 305. Thank you -- 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)

Oct. 30, 2008