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

Re: [Pharo-project] Issue 2360 in pharo: nil out locals in a block if readBeforeWritten

by pharo＠googlecode.com

Comment #6 on issue 2360 by marcus.denker: nil out locals in a block if readBeforeWritten http://code.google.com/p/pharo/issues/detail?id=2360 Next action: - take the code here and make a .cs or Slice out of it

Dec. 15, 2010

Re: [Pharo-project] access to the serial interface?

by Schwab,Wilhelm K

Friedrich, I am having some success, but named ports are broken. The attached is a fileout of my current SerialPort class. Give it a try and let me know how it goes. On Windows, you should find that COM1, COM2, etc. will work. Expect problems with COM10 and up; you will likely need to use something like \\.COMnn. On Linux, /dev/ttySnn works IF you fix the named ports. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Friedrich Dominicus [frido(a)q-software-solutions.de] Sent: Wednesday, December 15, 2010 12:59 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] access to the serial interface? I'm wondering how to I access the serial interface on the diverse Platforms with Pharo. On Unix I assume I just can open the "/dev/ttyX" as Stream? What about access to COM: stuff in Windows. Just open it and see what will happen? Regards Friedrich

Dec. 15, 2010

[Pharo-project] TextLint question

by Alexandre Bergel

hi! I am now using TextLint over my submissions. Each time I modify the text, the rest of the errors have a wrong text index. It makes it difficult to use. I do an accept, to save my .tex and run the rules again, but it takes time... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 15, 2010

Re: [Pharo-project] New SqueakSource (was good news of the year)

by Henrik Johansen

<yetAnotherJoke> Then why not under.world.st ? </yetAnotherjoke> Den 15.12.2010 11:55, skrev Luc Fabresse: > <joke> > graveyard.world.st <http://graveyard.world.st> > > just because once on disk, objects are just dead ;-) > </joke> > > #Luc > > > 2010/12/15 Nicolas Petton <petton.nicolas(a)gmail.com > <mailto:petton.nicolas@gmail.com>> > > Le mardi 14 dÃ©cembre 2010 Ã 13:42 +0100, StÃ©phane Ducasse a Ã©crit : > > Smalltalksource is nice. > > I like it too. > > Nicolas > > >

Dec. 15, 2010

Re: [Pharo-project] [squeak-dev] Gofer versus Installer

by Janko MivÅ¡ek

Hi guys, Cross posted to Squeak and Pharo. On 14. 12. 2010 22:56, Ken G. Brown wrote: >> Lukas maintains Gofer >> and there are reasons to use it: closer relationship with Pharo, contemporary MC integration (Metacello). > > I can accept using Gofer in trunk, for things that require it like reading it's own scripts. > But I don't want to see Installer go away... because of all the things Installer does that Gofer doesn't. What if someone: 1. adds to Gofer loading from SqueakMap and other 2. then Lukas is kindly asked to rename it to the Installer. That way we will have a maintained installer with a meaningful name and everyone will be happy. Because we really need one and only one installer for both Squeak and Pharo. Best regards Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 15, 2010

Re: [Pharo-project] New SqueakSource (was good news of the year)

by Sean P. DeNigris

Janko MivÅ¡ek wrote: > > http://code.world.st > +1 - intuitive for noobies without making us think about evil files ;-) -- View this message in context: http://forum.world.st/good-news-of-the-year-tp3083142p3089083.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 15, 2010

Re: [Pharo-project] Issue 3382 in pharo: BUG: Class variable creation behavior Inconsistent/incorrect

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.3 Comment #2 on issue 3382 by marcus.denker: BUG: Class variable creation behavior Inconsistent/incorrect http://code.google.com/p/pharo/issues/detail?id=3382 (No comment was entered for this change.)

Dec. 15, 2010

Re: [Pharo-project] Issue 3417 in pharo: BehaviorTest>>#testAllLocalCallsOn fails

by pharo＠googlecode.com

Comment #2 on issue 3417 by rydier: BehaviorTest>>#testAllLocalCallsOn fails http://code.google.com/p/pharo/issues/detail?id=3417 SourcedMethodReference also lacks an implementation of hash that corresponds to its = method.

Dec. 15, 2010

Re: [Pharo-project] Issue 3417 in pharo: BehaviorTest>>#testAllLocalCallsOn fails

by pharo＠googlecode.com

Updates: Cc: Benjamin.VanRyseghem.Pharo Comment #1 on issue 3417 by luc.fabresse: BehaviorTest>>#testAllLocalCallsOn fails http://code.google.com/p/pharo/issues/detail?id=3417 yes it is the problem! maybe the test could be changed to use SourcedMethodReference instead? Benjamin, can you have a look at this?

Dec. 15, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Peter van Rooijen

On Fri, 10 Dec 2010 21:11:47 +0100, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: Note that not writing source to the changes file has ancilliary benefits; change recovery is now not polluted with package loads and the changes file does not grow as packages are added, only as one's changes are made. Unloading a package doesn't leave garbage in the changes files. There are downsides. Deploying a development image means deploying all the associated parcel source files as well, and for this a platform-independent Filename abstraction really helps. >> Thanks for the explanation. I wonder how the previous versions of a >> method can be found using parcels. > I hacked a dreadful implementation of overrides in vw3.0 and I don't > think things are much better now. But in > http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg17714.ht… > I sketched how I think it should be done: > Maintain a global package load order (a stack of loaded packages, removing interior elements on unload). > Maintain a dictionary from method reference to set of package/method > pairs for each method that is overridden. > When a package is removed search overrides and compute the overridden > methods to be reinstalled, computing the uppermost method depending on > the new package order. > So to answer your question, one finds the previous versions directly in the overrides dictionary, and sorts the results according to the current package load order. Wasn't Levente asking about "regular" replacing of methods? I thought his question was about that; if the source is not in the changes file but in a parcel source file, then when I save a new version of a method and want to look for the old one, that will not be in the changes file. When I build up a new image from parcels, the load script copies all the sources to the changes file, so I have easy access to the history. Just wondering... Peter > best > Eliot >> Levente >>> best >>> Eliot >>>> Levente

Dec. 15, 2010