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

Re: [Pharo-project] Alien + Cog VM

by Eliot Miranda

Hi Ken, On Wed, Nov 10, 2010 at 10:20 AM, Ken Treis <ken(a)miriamtech.com> wrote: > What's the status of Alien in the new Cog VM? I was able to load Alien into > Pharo 1.1.1 running Cog, and some simple callouts worked (e.g. `CRLibrary > libraryVersionString` in CairoGraphics. But every callout with arguments > failed in primFFICallResult:. > > Alien works perfectly for me in Pharo 1.1 using JMM's VMs when I load the > Pharo 1.1 version from ConfigurationOfAlien, but I admit I haven't tried > 1.1.1 in this arrangement. > > Is there something that's changed in Cog's Alien primitive implementation? > IIRC, the Alien callout code is written assuming stacks grow up (in MethodContext instances) whereas in the Cog Stack and JIT VMs stacks grow down. So the glue in platforms/Cross/plugins/IA32ABI/dabusiness.h needs rewriting. Specifically the second loop over the arguments at line 45 needs to mimic the code at line 17. (I know, insane; why have two different loops in the first place? counting down towards zero can generate slightly faster code than counting up towards a limit; you need one less register). But I'm hoping that the ALien callouts will die the death soon. I have Alien callbacks integrated with the FFI and of course the ALien data manipulation code works fine. So if you're eager to have Alien callouts work see whether the above change fixes things, in which case I can integrate the fix. But if you're not so eager you could wait for me to push out the FFI changes, but that could take a few weeks. HTH Eliot > > -- > Ken Treis > Miriam Technologies, Inc. > > >

Nov. 11, 2010

Re: [Pharo-project] Weird OB accept behavior

by Schwab,Wilhelm K

Lukas, That explains it, but the very fact that I ran across this suggests that there is a reason to compile code as-is, so perhaps the check should be removed. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] Sent: Wednesday, November 10, 2010 1:51 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Weird OB accept behavior > (1) select #plotFrom:to:using:keepGoing:plots: and accept the code; no errors are reported; fair enough (or is it?). The editor does not trigger the accept event if the text is not dirty. Lukas -- Lukas Renggli www.lukas-renggli.ch

Nov. 11, 2010

[Pharo-project] Finding Family-tree of images

by HwaJong Oh

I have a hibbit of saving new version of images when i feed unsecure about something. So i end up a lot of disk space taken by them. I felt it is time for me to clean up the redundance in my disk. I wanted to have a sense of family tree of the images. l := (FileStream fileNamed:'Squeak4.0-basic-pocketcube-morphic.changes') contents lines. s := l select: [:each| each beginsWith: '----SNAPSHOT----']. i := OrderedCollection new. (s collect: [:ea| ea substrings at: 7 ]) do: [:e| (i includes: e) ifFalse: [i addLast: e.]. ]. i Now i have images names in time order. But still i need to run this code on every images not listed in evaluated result. How do you handle this problem? Best regards HwaJong Oh -- View this message in context: http://forum.world.st/Finding-Family-tree-of-images-tp3037106p3037106.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 11, 2010

Re: [Pharo-project] #& in Socket >> #waitForSendDoneFor:

by Levente Uzonyi

On Thu, 11 Nov 2010, Levente Uzonyi wrote: > On Tue, 9 Nov 2010, Philippe Marschall wrote: > >> On 09.11.2010 07:58, Schwab,Wilhelm K wrote: >>> What does your patch do? >> >> It replaces the #& with and #and: swaps receiver and argument to >> preserve the same semantics. That saves a primitive call if the data is >> already sent. It's basically the same as posted by Levente. >> >>> At a minimum, it deserves a little attention. Things that come to mind >>> are that one version does less work due to some type of optimization (and >>> runs faster as a result) or that one is too quick to detect a loss of >>> connection and sends less data per opportunity, appearing to run slower as >>> a result. >>> >>> Can you elaborate on "I'm able to push about 1 Mbyte/s more"? I guess I'm >>> asking how that manifests itself? Are there a bunch of connections that >>> form, send and fail? Do they each get a little farther or do they go >>> faster? >> >> Throughput outgoing from the Pharo image was about 1 Mbyte/s higher. Now > > 1MB/s throughput sounds pretty low. On windows I could transfer 160MB/s using > two processes in the same image by directly using the Socket primitives in 4k > chunks. With high level methods (#sendData: #receiveData:) it went down to > 110MB/s. With a two image setup (client-server) I got 66MB/s (one CPU/image). Looks like I missed the word "higher" in your mail. Anyway, I'm interested in your absolute numbers too. Levente > > Though our machines are different (yours is probably faster), still > Machine/OS differences + concurrent access + ab + apache + AJP + Seaside > caused 66x slowdown. That's more than acceptable IMHO. > > > Levente > >

Nov. 10, 2010

Re: [Pharo-project] VM Plugins that are important for performance?

by Levente Uzonyi

On Wed, 10 Nov 2010, Stefan Marr wrote: > Hi all: > > From your experience, what are the important VM plugins to gain a snappy and responsive Pharo image. > > Stef mentioned the Font plugin, but will this improve the user experience or is it just nice to have to support different kinds of fonts? > > The reason for my question is the 'performance hit' I have to take with the RoarVM for the moment. I doubt any plugin changes the performance of #tinyBenchmarks. But the following plugins make a huge difference in other benchmarks and GUI performance: - MiscPrimitivePlugin - LargeIntegers - FloatMathPlugin - FloatArrayPlugin - Matrix2x3Plugin - B2DPlugin Levente > So, if there are things typically done in plugins which now running in Smalltalk on the RoarVM, then I guess I could benefit by including those plugins. > > Thanks > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > >

Nov. 10, 2010

Re: [Pharo-project] VM Plugins that are important for performance?

by Stefan Marr

Hi Philippe: On 10 Nov 2010, at 22:00, Philippe Marschall wrote: > On 10.11.2010 14:36, Stefan Marr wrote: >> Hi all: >> >> From your experience, what are the important VM plugins to gain a snappy and responsive Pharo image. >> >> Stef mentioned the Font plugin, but will this improve the user experience or is it just nice to have to support different kinds of fonts? >> >> The reason for my question is the 'performance hit' I have to take with the RoarVM for the moment. >> So, if there are things typically done in plugins which now running in Smalltalk on the RoarVM, then I guess I could benefit by including those plugins. > > Do you have the MiscPrimitivePlugin? Yes, the current list of plugins is: B2DPlugin B3DAcceleratorPlugin BitBltPlugin FilePlugin FloatArrayPlugin LargeIntegers Matrix2x3Plugin MiscPrimitivePlugin RePlugin SocketPlugin SoundPlugin UnixOSProcessPlugin Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 10, 2010

Re: [Pharo-project] #& in Socket >> #waitForSendDoneFor:

by Levente Uzonyi

On Tue, 9 Nov 2010, Philippe Marschall wrote: > On 09.11.2010 07:58, Schwab,Wilhelm K wrote: >> What does your patch do? > > It replaces the #& with and #and: swaps receiver and argument to > preserve the same semantics. That saves a primitive call if the data is > already sent. It's basically the same as posted by Levente. > >> At a minimum, it deserves a little attention. Things that come to mind are that one version does less work due to some type of optimization (and runs faster as a result) or that one is too quick to detect a loss of connection and sends less data per opportunity, appearing to run slower as a result. >> >> Can you elaborate on "I'm able to push about 1 Mbyte/s more"? I guess I'm asking how that manifests itself? Are there a bunch of connections that form, send and fail? Do they each get a little farther or do they go faster? > > Throughput outgoing from the Pharo image was about 1 Mbyte/s higher. Now 1MB/s throughput sounds pretty low. On windows I could transfer 160MB/s using two processes in the same image by directly using the Socket primitives in 4k chunks. With high level methods (#sendData: #receiveData:) it went down to 110MB/s. With a two image setup (client-server) I got 66MB/s (one CPU/image). Though our machines are different (yours is probably faster), still Machine/OS differences + concurrent access + ab + apache + AJP + Seaside caused 66x slowdown. That's more than acceptable IMHO. Levente

Nov. 10, 2010

Re: [Pharo-project] deprecated message #sortBy: in Metacello

by Hilaire Fernandes

Ok Hil Le 10/11/2010 23:03, Dale Henrichs a Ã©crit : > Hilaire, > > It means that I need to push another version out that doesn't use > sortBy: ...:) > > Dale

Nov. 10, 2010

Re: [Pharo-project] deprecated message #sortBy: in Metacello

by Dale Henrichs

Hilaire, It means that I need to push another version out that doesn't use sortBy: ...:) Dale On 11/10/2010 01:58 PM, Hilaire Fernandes wrote: > When using the ConfigurationOfDrGeo to load DrGeo code and dependencies > in latest 1.2 pharo core image, I get a Metacello first load, then > I got a deprecated message error on the message sortBy: > > MetacelloMCProject>>versions > ^self map values asArray sortBy: [:a :b | a<= b ] > > Does it mean the wrong Metacello is bootstrapped in the image? Or > something else? > > Hilaire >

Nov. 10, 2010

[Pharo-project] deprecated message #sortBy: in Metacello

by Hilaire Fernandes

When using the ConfigurationOfDrGeo to load DrGeo code and dependencies in latest 1.2 pharo core image, I get a Metacello first load, then I got a deprecated message error on the message sortBy: MetacelloMCProject>>versions ^self map values asArray sortBy: [:a :b | a <= b ] Does it mean the wrong Metacello is bootstrapped in the image? Or something else? Hilaire -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo

Nov. 10, 2010