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

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by Serge Stinckwich

On Wed, Mar 31, 2010 at 1:23 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Mar 30, 2010, at 9:34 AM, laurent laffont wrote: > >> The problem with this option is we can't package it on Linux distros ... as open source software, I prefer that the VM downloadable on pharo website is a GCC (or other OSS compiler) compiled one. > > > Why? to run on linux you have to be compiled with GCC? > Or it is again a license problem? A version compiled with the Intel C compiler could be available on the Pharo website, but linux distro will never use it. They will prefer to recompile from scratch with gcc. What kind of boost performance is expected with the Intel compiler ? -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

March 31, 2010

Re: [Pharo-project] The Pharo Linux Vm [WAS] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by StÃ©phane Ducasse

John it is really important that 1.0 is working very well so we can start pushing 5.0 for 1.1. Now who is using 5.0 ? what are the problem left? I got some glitches like not been able to open two images but this was at the beginning. Now I thought that 5.0 was not officially out. Stef On Mar 29, 2010, at 9:47 PM, John M McIntosh wrote: > Frankly in all of this perhaps we should consider the use of the Version 5. 0 macintosh cocoa VM running in 32bit mode?

March 31, 2010

Re: [Pharo-project] The Pharo Linux Vm [WAS] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by StÃ©phane Ducasse

would be nice to have a **new** and separate package with clean code for your scenario adrian. Stef On Mar 30, 2010, at 8:48 AM, Adrian Lienhard wrote: > > On Mar 29, 2010, at 22:23 , Mariano Martinez Peck wrote: > >> On Mon, Mar 29, 2010 at 5:12 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> >>> >>> On Mar 29, 2010, at 21:52 , Mariano Martinez Peck wrote: >>> >>>> 2010/3/29 John M McIntosh <johnmci(a)smalltalkconsulting.com> >>>> >>>>> Also this week I will ship a 4.2.4b1 VM which is the result of some >>> Squeak >>>>> 4.0 base VM merge processing and contains the fix to enable the loading >>> of >>>>> old image segments used I guess by squeakmap? >>>>> >>>>> >>>> >>>> I am not sure. ImageSegment is a full of c...and maybe it will be even >>>> removed. It was not working since a lot of time and nobody says anything. >>> >>> Mariano, I know you know image segments, but I think this is may be >>> confusing for others. So I like to say something ;) >>> >>> Image segments work very well; both from a reliability and performance >>> point of view. We are using them for hundreds of customers. DabbleDB uses >>> images segments as well AFAIK. >>> >>> There are two parts, the primitives implemented by the VM in C and the >>> image-side code. The code in the image consists of support code to load and >>> store a segment and on top of this there is code for swapping in/out >>> classes, projects etc. Especially the latter is a mess and we already >>> started cleaning it. As images segments are not used by core code we also >>> consider moving it into a separate, external package (of course, the >>> primitives should stay in the VM). >>> >>> >> Thanks for the remark Adrian :) I know you know more for ImageSegments >> than all of us. >> >> As you said, it works pretty well for a piece of the domain. For example, in >> your case, you just export the segment, but did you try to swap them out >> (but letting the segment inside) and load it again ? it was broken. >> Exporting a segment, and bring them back again but where classes were >> modified or removed in the image, was broken also. If you load segments from >> older versions, it was broken too (this was what they fixed now). The >> symbols, you explained me that problem. In your case it works perfect >> because, as you say, almost only use the primitives, no more. But that's a >> very limited piece of ImageSegment. That piece, in that way, it works. > > Yes, exactly. And I think that's the most important piece and the one valuable to maintain. We just create a segment, write it to disc, and read it back from there into a fresh image. The only problem we had was with the symbols you mentioned above. We do migrations with scripts inside the image so that the segment's instances are always in sync with the code of the image we load them into. > >> For big segments, I am not sure if it works well neither. The segment >> allocates more than 2 times what needed. In DabbleDB I read they had that >> problem. The segments were too big, that having to allocate 2 or 3 times, >> crash everything. > > Depends on what you think is big. Most of our segments are smaller than 50MB but I have seen larger ones that worked too. > > Cheers, > Adrian > > >> Cheers >> >> Mariano >> >> >> >>>> We >>>> even started to remove part of it in Pharo. And SqueakMap was completely >>>> removed. >>> >>> Yes, SqueakMap is not relevant anymore for Pharo. Hence, this VM fix is not >>> critical for us. >>> >>> Cheers, >>> Adrian >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 31, 2010

[Pharo-project] Registering a tool in the world menu

by HernÃ¡n Morales Durand

Hi list, I'm using PharoCore 1.1 #11301. Now I want to adapt some tools to use the new menu registration mechanism. When I evaluate: menuCommandOn: aBuilder <worldMenu> (aBuilder item: #'Dependency Browser') parent: #Tools; action:[self open]; icon: UITheme current windowMenuForm. the world menu is modified including only the Dependency Browser item and all remaining items were removed. Did I miss something? Cheers, HernÃ¡n

March 31, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by StÃ©phane Ducasse

On Mar 30, 2010, at 9:34 AM, laurent laffont wrote: > The problem with this option is we can't package it on Linux distros ... as open source software, I prefer that the VM downloadable on pharo website is a GCC (or other OSS compiler) compiled one. Why? to run on linux you have to be compiled with GCC? Or it is again a license problem?

March 31, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by StÃ©phane Ducasse

Two points - how can we join forces to get the largest range of VM and the process to build Concentration of knowledge in small open-source movement is dangerous. - We will buy an academic license of the compiler. I ordered it today. Stef On Mar 30, 2010, at 9:02 AM, John M McIntosh wrote: > > On 2010-03-29, at 11:39 PM, Adrian Lienhard wrote: >> >> What's the yearly costs for the Intel Compiler license? >> >> Adrian > > non-academic it's $599 & then $240 > > academic license is $160 > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 31, 2010

Re: [Pharo-project] [Pharo-users] Are there Chi-Square, Power, Normal, Binomial, Uniform, Student's-T etc distributions ?

by Lukas Renggli

> Is there a standard library access and make calculations from the > distributions mentioned in the subject of this email? I'm interested > in random draws from those distributions. I haven't found anything > looking in the image or on squeaksource. Thanks Have a look in the "Chapter 21: Probability Distributions" of "Smalltalk-80: The Language and its Implementation By Adele Goldberg and DavidRobson; Xerox Palo Alto Research Center ISBN 0-201-11371-6. 344 pp. 1983" (http://stephane.ducasse.free.fr/FreeBooks.html) I am sure that you can find a file-out of the code described in the book with Google. I remember having it packaged up with Monticello some time ago, but can't find it right now. Lukas PS: Please configure your reply-to address to go to the mailing list. -- Lukas Renggli http://www.lukas-renggli.ch

March 31, 2010

[Pharo-project] Mac Carbon VM 4.2.3b1 sound recording busted

by John M McIntosh

>Mac Carbon VM 4.2.3b1 sound recording busted Must always remember to test (lot more) things after applying VMMaker changes. I'll have a 4.2.4b1 VM in a few days after some dust settles. But for now if you hit the SoundRecorder record button in your squeak.image it will crash. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 31, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by Levente Uzonyi

On Tue, 30 Mar 2010, Bryce Kampjes wrote: > On Tue, 2010-03-30 at 14:01 -0700, John M McIntosh wrote: >> On 2010-03-30, at 11:43 AM, Levente Uzonyi wrote: >> >>> That's probably because Laurent built almost every plugin as external. These include those which are responsible for displaying stuff on the screen. >> >> Um, mmmm >> Once we find and load the plugin we cache the entry point so later references don't incur much of a cost. Maybe there is no compiler optimization in the compile for the external plugin? > > I'd be surprised if building plugins as external is the cause of the > problem as that's standard practice for Unix VMs. Ian does it for his > and I followed his lead with the Exupery VMs. Building most plugins external is a good idea, but I doubt that building plugins which are loaded all the time have any benefits. I used to build at least these as internal, the others are usually external: BitBltPlugin, FilePlugin, FloatArrayPlugin, FloatMathPlugin, LargeIntegers, LocalePlugin, Martix2x3Plugin, MiscPrimitivePlugin, SecurityPlugin, SocketPlugin. I guess all but SocketPlugin, will be loaded during startup. And I'm not saying that building plugins as external cause the low values for tinyBenchmarks, but they may be responsible for the sluggish UI. Levente > > Bryce > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 31, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by Bryce Kampjes

On Tue, 2010-03-30 at 14:01 -0700, John M McIntosh wrote: > On 2010-03-30, at 11:43 AM, Levente Uzonyi wrote: > > > That's probably because Laurent built almost every plugin as external. These include those which are responsible for displaying stuff on the screen. > > Um, mmmm > Once we find and load the plugin we cache the entry point so later references don't incur much of a cost. Maybe there is no compiler optimization in the compile for the external plugin? I'd be surprised if building plugins as external is the cause of the problem as that's standard practice for Unix VMs. Ian does it for his and I followed his lead with the Exupery VMs. Bryce

March 30, 2010