- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: going over and integrating Kernel-Extensions
by StÃ©phane Ducasse Aug. 22, 2008

Aug. 22, 2008

> From: stÃ©phane ducasse <ducasse(a)iam.unibe.ch> > Date: August 22, 2008 9:46:46 AM CEDT > To: An open mailing list to discuss any topics related to an open- > source Smalltalk <Pharo-project(a)lists.gforge.inria.fr> > Subject: going over and integrating Kernel-Extensions > > > Hello pharoers > > it would be nice if we could go over the items (especially the > extensions proposed in > Squeak3.11 Contributions/Kernel-Extensions) on squeaksource and see > what can be integrated into > pharo. > > stef > > >

1 0

Re: [Pharo-project] About milestone
by Bill Schwab Aug. 21, 2008

Aug. 21, 2008

Bryce, That is an interesting thought, but a quick check in gedit and Pharo shows that there is a difference - gedit behaves much more as I would expect than does Pharo. That is with with both defaults under Ubuntu's keyboard options, and with a couple of tweaks that looked promising. There is a shift/numeric option that makes shift-control-arrow work though, so there still could be options that would explain everything, especially if you have something set that forces numbers. Which distribution do you use? Take your time; let me know when you are ready to fiddle with it. Thanks! 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 >>> bryce(a)kampjes.demon.co.uk 08/20/08 4:38 PM >>> Bill Schwab writes: > Bryce, > > Any and all efforts on the Linux VM are greatly appreciated. Better support for virtual keys would be great. I frequently use the numeric keypad with num-lock off, and the keys are largely ignored on Linux; the win32 VM works as expected. It is not my intention to dump work on you, but if you are hacking the vm anyway... Please let me know if I can help out with running down keycodes, etc. > Thanks, first let me finish the current task in Exupery, then once I've got that stabilised, I'll look at compiling the Freetype support. After that we'll see how much more time is available. I'm already maintaining an Linux VM for Exupery, so adding a few features for Pharo shouldn't be too much extra work. Bryce P.S. I just tested. Here the numeric keys work as numeric keys with the num-lock selected or not. So I suspect it's configurable via X without needing a VM modification. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] New pharo-dev based on latest version
by Damien Cassou Aug. 21, 2008

Aug. 21, 2008

I've just published a new pharo-dev version on: http://code.google.com/p/pharo/wiki/Downloads?tm=2. It is based on version 10061. -- 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)

5 13

Re: [Pharo-project] New pharo-dev based on latest version
by Bill Schwab Aug. 21, 2008

Aug. 21, 2008

Stef, Thanks for the pointer. It could use some work though. One of my favorite mantras for GUI design is "never punish the user." I have been roundly scolded :) It seems I was confused over what would be used for search string, and was thus forced to wait a fairly long time for results having little to do with my intended search. If I may mix features a little, Dolphin sometimes populates prompters with either text on the clipboard, and perhaps current line/selected text, allowing one to accept/cancel an action w/o risk of assuming a search the user did not intend to do. Dolphin's find-methods-containing-text is also MUCH faster than Pharo's. It might just be the relative speeds of the two systems (I hope not), lack of important primitives, or perhaps code that can be greatly improved. The latter reminds me of DSDN, which I wrote for Dolphin, getting it to (reliably) CRAWL through searches across documentation, newsgroup archives, and the image itself. Ian Bartholomew promptly made it FLY by comparison (measured in orders of magnitude, as I recall). Hopefully a similar coding style could buy us a big boost here. Somewhat related, Dolphin's search for references to either the selected method or to text that can be entered in a prompter. The non-prompting search is available from a context menu in the method pane, so it tends to "just work." 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 >>> stephane.ducasse(a)inria.fr 08/20/08 5:51 PM >>> You bring the menu on the method pane then more.... then source code with .... it will scan all the methods for the string you pass On Aug 20, 2008, at 10:09 PM, laurent laffont wrote: > Thank you. > > I have another super newbie question. I want to disable the warning > that SqueakV39.sources is not found when we load an image. I found > the preference and the message Preferences>>warnIfNoSourcesFile but > this is not called on startup (I've put a halt in it to check) > > I try to find a tool to search for the string "Squeak cannot find > the sources file named ..." to know which code popup the dialog. > > I want to disable this dialog and the "Enter your initials" one by > code in my squeakci script, as it prevent me from drinking my coffee > or taking a nap while all tests runs without any human intervention. > > Laurent > _______________________________________________ > 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

3 2

Re: [Pharo-project] A note
by Bill Schwab Aug. 21, 2008

Aug. 21, 2008

Stef, This sounds great. At the risk of being the self-appointed exception pedant, I agree that exceptions beat unexpected (even ambiguous) return values, but there should be a way to provide an error block to avoid the overhead. I will also confess to skepticism about default return values - IMHO, they defeat much of the purpose of the exception. However, in the case of the compiler, I can see the other side of the argument (translation, I won't squawk much if it ends up with default actions). Bill >>> stephane.ducasse(a)inria.fr 8/20/2008 2:22 AM >>> Hi guys it occurred to me that this may be important to stress the following point. The point of pharo is not to go to a minimal kernel for the sake of it but to get nice abstractions into play. (of course we will remove etoy, remove the extra fat of morphic and reorganize package structures and more....). But let me take an example: with marcus we worked yesterday on making sure that the newcompiler can be compiled and installed as a second compiler so that compiler freaks can use this second compiler as a fallback when they hack the compiler. The point is that we can in the future remove the old compiler and replace it with the new one. What this example illustrates is that we are looking for the smallest compiler but one that is good and have a good interface (use of exception, instead of [^ nil]). Now ideally we would like to have a smallkernel PLUS a set of packages that composes a pharo-core distribution. What we do not want is to fall into the trap of - smaller better - and have packages that are not touched by refactoring. So we would like to have a smallkernel but not smaller plus the ability to load automatically packages so that when we refactor the system we can work on a coherent set of packages. If you have feedback please let us know. Stef _______________________________________________ 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] About milestone
by Bill Schwab Aug. 20, 2008

Aug. 20, 2008

Bryce, Any and all efforts on the Linux VM are greatly appreciated. Better support for virtual keys would be great. I frequently use the numeric keypad with num-lock off, and the keys are largely ignored on Linux; the win32 VM works as expected. It is not my intention to dump work on you, but if you are hacking the vm anyway... Please let me know if I can help out with running down keycodes, etc. 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 >>> bryce(a)kampjes.demon.co.uk 8/18/2008 4:37:55 PM >>> StÃ©phane Ducasse writes: > Hi all > > I would really like to have soon a first official release. > So what do we want to get in/out and before the release: > - better look for sure > - tests green. > > I think that this is important to release 0.1 > Since I would really like to use the NewCompiler by default and remove > the old one. I can try to build a Linux VM with true-type font support in the next few months. Bryce P.S. I'd like to see closure support, a couple of primitives should make the closure compiler Matheu and Marcus have been working on performant. I doubt that it needs to wait for an image format change. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] Bigger than Squeak?
by Damien Cassou Aug. 20, 2008

Aug. 20, 2008

Hi, according to stats I did about Squeak and Pharo (http://damiencassou.dabbledb.com/publish/dev-imagesdownloads) Pharo images are always bigger than Squeak images. This does not seem to be related to the dev-images themselves because the latest base Pharo image is bigger (8.79 MB) than Squeak 3.10.2 (7.1MB) and Squeak 3.9.1 (also 7.1MB). Is there any method to call to clean the image? Would be interesting to systematically clean the releases you build. Bye -- 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)

3 6

Aug. 20, 2008

Hi I checked and between 10050 and 10055 we introduce a bug LargePositiveInteger new: 4 Stef

3 3

Aug. 20, 2008

Begin forwarded message: > From: nicolas cellier <ncellier(a)ifrance.com> > Date: August 20, 2008 2:56:22 PM CEDT > To: stephane ducasse <stephane.ducasse(a)free.fr> > Subject: Re: besoin d'un peu d'aide > > stephane ducasse a Ã©crit : >> bonjour nicolas >> >> dans pharo on a un probleme avec un le print de largepositiveInteger. >> Si tu pouvais jeter un oeil cela nous aiderait. >> http://code.google.com/p/pharo/wiki/Downloads?tm=2 >> + update >> >> - LargePositiveInteger new: 4 >> + printString => boum >> >> merci par avance. >> >> Stef >> > Salut Stef, > La version Integer-fastPrint-M6887-nice.8.cs ( http://bugs.squeak.org/file_download.php?file_id=3430&type=bug > ) corrige ce cas avec les deux lignes suivantes au dÃ©but de > LargePositiveInteger>>#printOn:base: > > "Don't engage any arithmetic if not normalized" > (self digitLength = 0 or: [(self digitAt: self digitLength) = 0]) > ifTrue: [^self normalize printOn: aStream base: b]. > > Le script d'installation a Ã©tÃ© mis Ã jour le 21 juillet Ã http://bugs.squeak.org/view.php?id=6887 > > > J'ai aussi proposÃ© une version .9.cs qui remplace le test par plus > explicite: > > "Don't engage any arithmetic if not normalized" > self isNormalized ifFalse: [^self normalize printOn: aStream base: > b]. > > Mais ma version de #isNormalized bien que suffisante pour cette > utilisation, n'est pas complÃ¨te: elle ne teste pas si le nombre peut > Ãªtre rÃ©duit en SmallInteger... > Il faudrait la complÃ©ter, ce qui a peu d'intÃ©rÃªt tant qu'il y a un > seul sender. > Je recommande donc plutÃ´t la version .8.cs > A toi de voir. > > Bon courage pour la suite > >

1 0

Aug. 20, 2008

hi guys There is a new update.... removing a lot of duplicated code and some fixes. We also set the preference not to server mode. Have fun. Stef PS: we added some new issues. So feel free to help.

3 6