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

[Pharo-project] Fwd: [squeak-dev] All tests running green
by StÃ©phane Ducasse July 7, 2008

July 7, 2008

>> Damien Cassou wrote: >>> On Mon, Jul 7, 2008 at 10:56 AM, laurent laffont >>> <laurent.laffont(a)gmail.com> wrote: >>> >>>>> I think the information we need looks like >>>>> http://speedy.cs.uiuc.edu/~johnson/testResults/3.10alpha.7105-none.html >>>>> . >>>>> Ralph Johnson wrote a tool to generate these reports but I don't >>>>> know >>>>> more than that. You can ask him. >>>>> >>>> Done. >>>> >>>> I think the way to do it is to periodically download last dev >>>> image, >>>> run the tests, output the results to a file and upload it to a >>>> webserver. I think we can do this with a simple bash script and a >>>> cron >>>> task. Is it possible to run all the Squeak tests from the command >>>> line ? >>>> >>> >>> Yes. First create a text file which contains the Smalltalk >>> instructions to run the tests you want. You might want to look at >>> classes TestCase and TestRunner to find what to write in this file. >>> >>> Then, you have to pass the full path of that file as the last >>> parameter to Squeak >>> >> There is a version of TestRunner in 'SUnit-improved' (however some >> needed code needs to be retrieved from the history) that takes >> parameters from the command line using Installer-Launcher (part of >> LPF) to invoke them. >> >> TestRunner can be configured to report its results using >> TestReporter generating results to files, which when served by an >> appropriately configured web server (apache + some icons) give you >> both a progress status and red/green/yellow pass indication in your >> web browser and a script to load into a fileList and re-run tests >> via doIts. >> >> TestReporter can be run standalone without TestRunner which runs >> the tests without an in image UI. >> >> This will all be a standard part of Sake/Bob, an auto image build/ >> testing tool built upon Sake. (Bob version 1 was written in ruby, >> so the ideas have been tested, we just await the smalltalk version. >> There is also a server ready to be put to work on this) >> >> regards >> >> Keith >> >> > > > >

1 0

[Pharo-project] WideStringTest>>testSubstrings
by Norbert Hartl July 7, 2008

July 7, 2008

Stef, you propably missed my comment on the last SLICE. You need to do a String initialize to cope the changes. After that the test will succeed. Norbert

3 4

[Pharo-project] About Morph cleaning and new infrastructure
by StÃ©phane Ducasse July 7, 2008

July 7, 2008

Hi guys Here is the summary of the discussion we got with mike today. In the context of the ESUG sponsored effort mike and john will work on making the - VM sleeping correctly, - using a semaphore do avoid event polling and all the rest related to that. - fixing the event handling. Now the point is that mike will not change Morph, just clean what is needed so that the event system and the polling gets cleaned. The idea is that Morph cannot be cleaned. In parallel mike has been working on ySqueak and in this context he worked on a new morphic model. Now we should learn from squeak and make sure that we have an infrastructure that allows one to plug difference UI frameworks (no "Smalltalk isMorphic" in the future). In addition we want to make sure: - that we can plug different UIFrameworks (Miro, Morphic30, YSqueak or something else) - kernel class do not depend on UI. So mike based on his sophie experience designed a new event model based on Announcement which support well multiple input devices, different platform key, different windowing bindings for future native support. So the idea is the following: - let make Morphic smaller and cleaner but acknowledge that Morphic is not the long term future. - mike will produce a new event model, that the other UI frameworks could use and extend. He will ask fro feedback. - Agree that we use announcement as an infrastructural foundation. - make sure (with your help and feedback) that we can plug another UI framework (in particular in the event loop handler should support a registration mechanism. - It would be nice to see how miro can use the new event model and be plug in pharo as well as the ySqueak new model. I would like to lower the frustration of people. The point is not to chose a framework against another one but to make sure that we can load and plug different frameworks. So please comment. Stef

4 6

[Pharo-project] Pharo Logo
by Lukas Renggli July 7, 2008

July 7, 2008

Where do I find the Pharo logo (that is now included in the latest images) as a PDF? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

2 3

[Pharo-project] tests
by StÃ©phane Ducasse July 6, 2008

July 6, 2008

this is a test... stef

1 0

Re: {Spam?} RE: [Pharo-project] Re: Pharo Smalltalk
by Bill Schwab July 4, 2008

July 4, 2008

Steph, The only chopping-block item mentioned below which I might want to rescue is Alice. Actually, Alice isn't all that great; I have used it for a poor-man's 3D CAD system on a few projects, and found it useful. What I am really asking for us to consider is (when other stuff is done and we're getting bored) a retained-mode 3D graphic system. The 3D objects from Croquet might be the answer, but of course, on top of Pharo vs. Squeak. If we do this well enough, Croquet might come to us :) 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) 846-1285 FAX: (352) 392-7029 >>> ramon.leon(a)allresnet.com 07/04/08 11:44 AM >>> > - 1 we need freedom. We do not want to maintain: etoy, > nebraska, alice > and the like. It's about time that stuff got dumped. > in 3.9 we harvested 625 bugs fixed but apparently this was not > valuable. We think that 3.9 was a positive experience > even if marcus got sick and burnt out. 3.9 was the best release I've used yet. I'm glad someone is thinking about a *serious* open source Smalltalk instead of arguing about how they miss that stupid mouse or whining about eToys. > - 7 The squeak model is flawed. We do not want a model were > consumers can put exigences on producers. > Even if good customers are important and this is why we want to have > Aida/Seaside and a lot of cool projects > to run on pharo. The image is looking very nice so far, I loved it when I opened a menu and all the crap I never use was finally gone. I excited to see where you take Pharo, but it's off to a good start. > Because we do not want to have complain all the times. We want to be > able to invent the future, rethink design > decision, apply good practices but not maintain the cool but old > features and experiments of others. Sorry but we > did that and now this is over. > We are also sorry but we do not believe in big bang changes and we > waited too much after spoon. So may be we are > wrong, probably but again we had to do something for ourselves. You're not wrong. Make Pharo into a serious clean open source Smalltalk kernel that can run Seaside and when the masses come for Seaside they'll choose Pharo over Squeak and Pharo could easily become the larger community. All that legacy stuff in Squeak is holding it back and stopping the mainstream from giving it a chance. Squeak is ugly, cluttered, unfocused, full of garbage that most developers will never need or use, and apparently stagnant because part of the community resists any and all change. Maybe Squeak 4.0 will fix that, maybe it won't, but so far Pharo is starting to look like the best distro for the future. > We tried to really make a better Squeak and got sick, burnt > and more. So now if I do not want to destroy the > little flame we have for Smalltalk we **must** do pharo, > because this is like new dry wood that you put on the fire place. > It brings exciting future. > > Stef You did make a better Squeak, and I look forward to seeing Pharo burn the diskpacks a bit and throw out all the crap bogging Squeak down. Keep up the good work, some of us do appreciate it. Ramon Leon http://onsmalltalk.com _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] Streams head start
by Bill Schwab July 4, 2008

July 4, 2008

Adrian, First, please understand that the primary security hole is ME, not Seaside :) With that said, there are a few things I would like to see: (1) users must be challenged for username and password before they are allowed to do anything; I have accomplished this via tasks. I have no need to allow users to register themselves - the site should say "GO AWAY!" to all but approved users - medical stuff. (2) SSL/https, ideally with an idiot-proof selection between being proxied behind Apache and Comanche running over SSL courtesy of the cryptography team. (3) brain-dead simple Apache setup My problem is that I cannot afford to make a mistake with most data that I protect. The current project needs some security, but a spill would not make AP wires, so it is a great place to start while I figure out how lock everything down. 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) 846-1285 FAX: (352) 392-7029 >>> adi(a)netstyle.ch 07/04/08 10:28 AM >>> Hi Bill, On Jul 4, 2008, at 16:11 , Bill Schwab wrote: > I found a good starting Seaside project. It requires only minimal > security to start, and while a little clumsy, it will actually be > useful > to me, and will be a good demo piece for "selling" future Seaside > projects that will have to be very secure. Long story. Can you elaborate on the kind of security? Is this Seaside security in general or are you talking about applications that allow users to execute code in a sandbox? Or something else? I'd be interested to hear more... Adrian _______________________________________________ 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] Streams head start
by Bill Schwab July 4, 2008

July 4, 2008

Damien, I found a good starting Seaside project. It requires only minimal security to start, and while a little clumsy, it will actually be useful to me, and will be a good demo piece for "selling" future Seaside projects that will have to be very secure. Long story. The good news is that it has me chipping away at the daunting task of porting lots of infrastructure code, and as a confessed streams junkie, I ran directly into the problems we have discussed. Since I "can't wait" for, nor do I expect a robust solution[*] to the silent errors problems of #next and friends, I will simply deprecate them for my own use. Toward that end, #nextOne, #nextMany:, and #nextAvailable: exist in a change set. I will no doubt discover the need to provide additional overrides. Some of my implementations are little more than checked versions of what lurks in the image; hopefully we can do better with Nile, or any and all are welcome to do better tomorrow (today for that matter<g>). It is probably a little premature, but you are welcome to review what I have, and I would very much like to discuss file stream semantics. I will add some Dolphin-influenced entry points, but some changes/additions are going to be necessary. If nothing else, file name manipulation will change for the benefit of Linux. I understand that streams are set for milestone 3, so feel free to stick to that. At the risk of appearing to want to rewrite the schedule, I'm stuck until I have at least a temporary solution, and hopefully one that provides semantics that I can map onto whatever we ultimately create. Your input would be welcome. Let me know whether and how you would like to proceed. Bill [*] if we had Cincom's backing, I would be more optimistic, but with them clinging to backward compatibility, adding selectors seems the best approach to get moving. 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) 846-1285 FAX: (352) 392-7029

2 1

July 3, 2008

Begin forwarded message: > From: Matthew Fulmer <tapplek(a)gmail.com> > Date: July 3, 2008 8:38:24 PM CEDT > To: stephane ducasse <stephane.ducasse(a)free.fr> > Cc: Matthew Fulmer <tapplek(a)gmail.com>, Keith Hodges <keith_hodges(a)yahoo.co.uk > > > Subject: Re: I'm interesting in knowing more on your atomic loading > > On Thu, Jul 03, 2008 at 07:21:21PM +0200, stephane ducasse wrote: >> Hi matthew >> >> how can i learn about your atomic loading? >> >> Stef > > ===== History ===== > > Atomic loading is a feature Colin Putney implemented for MC2, > then released as a separate, quite unstable library: > SystemEditor > > http://www.squeaksource.com/SystemEditor/ > > Goran and I picked up this library as a core component of > DeltaStreams, and we fixed many bugs it had with loading > different combinations of things, due to not being tested in > production. In the meantime, Keith Hodges wrote a new package > loader for Monticello 1.5 that hooked into SystemEditor to take > advantage of it's atomic loading property. It hardly worked at > all, but the principle was there. See the class MCPackageLoader2 > in Monticello 1.5: > > http://www.squeaksource.com/mc/ > > I have since stopped working on DeltaStreams and started working > heavily with Keith in improving the basic tools in the image and > making new ones. Since I was already familiar with SystemEditor > due to my work on DeltaStreams, I volunteered to work on package > loader 2. I fixed a dozen or so bugs in both package loader 2 > and SystemEditor, and now it is able to load quite a few > packages. It is still beta phase though. It is not yet able to > cope with the following: > > Byte/Word/Weak classes > Traits > Tweak classes > > I'm fixing those inadequacies in the order listed. Once they are > fixed, we will release PackageLoader2 as the default in > Monticello, and increment the version number of Monticello to > 1.6. > > ===== How it works ==== > > SystemEditor has a set of classes (editor classes) that respond > to the same protocol as Class, Metaclass, MethodDictionary, > ClassOrganizer, SystemDictionary, and other related core > classes. Each one acts as an "editor" on an existing object in > the system. These editors respond to the same protocol as the > object they edit, but maintain changes internally, usually as a > list of additions/removals. When the time comes to commit the > changes (See SystemEditor>>commit), all these editors are passed > a MigrationTransaction object, and are asked to submit the old > and new copy of the object they are editing, which will be > swapped at commit time. When all objects have done this, > MigrationTransaction builds two arrays: one of old objects, and > one of new, and invokes the primitive > Array>>exchangeElementIdentityWith: , which does a bulk identity > swap (see MigrationTransaction>>commit). Everything that needs > to change is swapped: Recompiled classes, instances of those > classes, new methodDictionaries for classes that don't need > recompiling, Smalltalk, the SystemDictionary instance, > ClassOrganization instances, and so on, all during one > primitive. > > ===== Status ===== > > I'm fairly confident in Monticello1.6-beta, as it currently > exists. I use it as my default loader in all of my images, > except when I am dealing with Tweak in my croquet images. > > To try it out, do the following: > HTTPSocket httpFileIn: 'installer.pbwiki.com/f/LPF.st'. > Installer install: 'Monticello16-Beta' > > This loads LevelPlayingField (= Installer and MC1.5) and then > runs my script to load SystemEditor and activate PackageLoader2. > > Pages you may want to read: > > LevelPlayingField: a script to load Installer and MC1.5 into > most any image in use: > http://installer.pbwiki.org/LevelPlayingField > > The script that loads MC1.5: > http://installer.pbwiki.org/LevelPlayingField-Monticello15 > > The script that activates MCPackageLoader2 (it is under > "Contributed Scripts" in the sidebar) > http://installer.pbwiki.org/Monticello16-Beta > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ >

1 0

July 3, 2008

Hi guys With mike we also discussed about URI and the way sophie people used to abstract away from the file system. The idea (may be I'm summarizing a bit wrong), is to use URI consistently even to access local file. He told me that with this practice they got away from platform dependent code in Sophie. Mike also rewrote and clean a large part of the network-package. We got some trouble to load it in pharo since this was not made to be loaded in pharo. Mike will work on a loadable version. Stef

2 2