- Pharo-dev - lists.pharo.org

[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

[Pharo-project] Fwd: I'm interesting in knowing more on your atomic loading
by StÃ©phane Ducasse July 3, 2008

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

[Pharo-project] About a file abstraction layer
by StÃ©phane Ducasse July 3, 2008

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

[Pharo-project] Re: Pharo Smalltalk
by StÃ©phane Ducasse July 3, 2008

July 3, 2008

> Couldn't you do this on Squeak? but we are doing that starting with squeak 3.9 :) > How much Pharo will differ from Squeak? We do not know but it will. > Do you intend to rebase with a new VM or do you intend to just > improve Smalltalk code? For the moment we do not have the expertise to change the VM and we will reuse the one of Squeak. There will be also a MIT VM with a JIT so :) And also Squeak VM running on ipod :) > What about license issues? I've seen Pharo is MIT. Yes all the code of pharo will be MIT. We will only include MIT code and all the commiters have to sign the agreement. > I've seen many developers and a busy mailing list, I expect more improvements to come when the people interested by software development will join. For the moment we are in warm up mode. > what will be the future of Squeak? I do not know. FunSqueak ;D >> Well what I will have in mind depends on what you reply to the >> above questions :P > > Thanks for your reply.

1 0

July 3, 2008

Hi bruno > I've head about your new project Pharo. Good :) > I'm the author of Smalltalk YX (Syx) http://syx.googlecode.com. I had a look a while back. > Another developer recently developed a VM inspired to Syx and now > we're going to merge the projects, since we have the same vision. Excellent! Join forces :) > This is the post in the mailing list: http://groups.google.com/group/syx-discuss/browse_thread/thread/55507afadab… > > I'd like to know the main purposes of your new implementation, Produce a good Smalltalk with nice, well documented and libraries so that people can develop cool projects and others can learn from the system. We want to remove cruft from the system. > are you interested in a possible collaboration? yes! Tell us what you have in mind. > I haven't seen any source code yet. I think our two projects have > many things in common. The code is available on the ugly pharo web page http://pharo.gforge.inria.fr/ Stef > > > Let me know please. > Best regards, > > - -- > http://syx.googlecode.com - Smalltalk YX > http://lethalman.blogspot.com - Thoughts about computer technologies > http://www.ammazzatecitutti.org - Ammazzateci tutti > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIbXq1w9Qj+8Kak3ERAmZBAJ4ng2GLUD+rVuuhu2kAFjeKozyW5QCeO+WG > /tnA/LYuTonX9bzJDZBu5bs= > =og7s > -----END PGP SIGNATURE-----

1 0

July 3, 2008

hi guys (and marcus in particular) I'm at RMLL and we are discussing with mike about infrastructure for pharo. I will summarize some of the discussions in the following posts. Mike suggested that we really use the NewCompiler for Pharo. Marcus can you comment on that. Stef

3 2

Re: [Pharo-project] UI plans Question
by michael_atkisson＠comcast.net July 3, 2008

July 3, 2008

Perhaps I don't know the right terminology. Anyway I was thinking of a ui environment like the commercial smalltalks. Where when you started up Pharo you would have a main Window, from there any window you opened up such as a browser would be independent from the main window, it would open up outside the bounds of the main window and not be constrained by the main window. -------------- Original message ---------------------- From: "Serge Stinckwich" <serge.stinckwich(a)doesnotunderstand.org> > No i don't think so. What is your idea ? > > 2008/7/2 <michael_atkisson(a)comcast.net>: > > Are there any plans to make it possible to be able to move windows out of > > the main ui environment window. > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > Serge Stinckwich > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://blog.doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

4 3