May 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] compiled VM with Alien for JNIPort

by laurent laffont

So following Mariano's blog and pharocasts I've built Cog with IA32ABIPlugin (works, cool !) When starting the JVM following JNIPort instructions on SqueakSource wiki, the VM crashes. GDB bt gives: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x000d267a in primCallOutIntegralReturn () at /Users/laurentlaffont/dev/pharo/vm/blessed/src/plugins/IA32ABI/IA32ABI.c:500 #2 0x00023a3e in interpret () at /Users/laurentlaffont/dev/pharo/vm/blessed/src/vm/gcc3x-cointerpmt.c:2037 #3 0x962ede02 in __CFRunLoopDoObservers () #4 0x962a9d8d in __CFRunLoopRun () #5 0x962a9464 in CFRunLoopRunSpecific () #6 0x962a9291 in CFRunLoopRunInMode () #7 0x934dce04 in RunCurrentEventLoopInMode () #8 0x934dcaf5 in ReceiveNextEventCommon () #9 0x934dca3e in BlockUntilNextEventMatchingListInMode () #10 0x9644778d in _DPSNextEvent () #11 0x96446fce in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #12 0x96409247 in -[NSApplication run] () #13 0x964012d9 in NSApplicationMain () #14 0x00078247 in main (argc=1, argv=0xbffff680, envp=0xbffff688) at /Users/laurentlaffont/dev/pharo/vm/blessed/platforms/iOS/vm/Common/main.m:52 (gdb) Any idea ? Laurent. On Tue, May 10, 2011 at 12:37 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Mon, May 9, 2011 at 1:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 9 May 2011 21:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Mon, May 9, 2011 at 11:27 AM, laurent laffont < >> laurent.laffont(a)gmail.com> >> > wrote: >> >> >> >> On Mon, May 9, 2011 at 4:02 PM, laurent laffont >> >> <laurent.laffont(a)gmail.com> wrote: >> >>> >> >>> Hi, >> >>> >> >>> is there a compiled VM available with Alien for OSX ? I want to use >> >>> JNIPort. >> >> >> >> >> >> Second question, if I need to compile the VM, which one should I use >> for >> >> Alien ? Cog is OK ? >> > >> > Yes. Cog is OK. >> >> And what plugin? NewsqueakIA32ABIPlugin, right? >> > > No, just IA32ABIPlugin. The difference between the two is only > that NewsqueakIA32ABIPlugin implements immutability checks. > > >> >> > >> >> >> >> Laurent >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> >

May 10, 2011

[Pharo-project] [update 1.3] #13188

by StÃ©phane Ducasse

13188 ----- - Issue 4177: New TranscriptWindow and several fixes to the (new) Transcript adoption. Thanks a lot Fernando Olivero. 3112: ThreadSafeTranscript >> #endEntry is Morphic dependent. 3948: Transcript and ThreadedTranscript needs to be merged. 4023: Transcript clear prints Transcript after clearing prior text. 4039: To open ThreadSafeTranscript . 4067: Transcript does not work with system fonts (Win XP) (TranscriptModel>>displayOn: aForm uses StandardFonts now) 4093: alt_t (fixed by loading the post load: send initializeDesktopCommandSelectors for the worlds) 4116: minimizing, then output to transcript: redraw problems. Big thanks to fernando *** APPLAUS *** You see guys trust works :) Stef

May 10, 2011

Re: [Pharo-project] Cog doesn't load anymore in PharoCore1.3 because of the removal of AbstractLauncher

by Mariano Martinez Peck

sooo.. opinions? On Sun, Apr 24, 2011 at 8:11 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > If Cog really needs it we should create a separate repostiroy like > PharoCogSupport and put the class there and add it as a dependency of Cog in > ConfigurationOfCog. > Another hacky way is to add a #preLoadDoit: in ConfigurationOfCog that > does a #compile: of AbstractLauncher > > Cheers > > Mariano > > > > On Sun, Apr 24, 2011 at 7:37 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> AbstractLauncher was removed in: >> http://code.google.com/p/pharo/issues/detail?id=4002 >> >> Cog has a subclass from AbstractLauncher called CommandLineLauncher, >> hence, it cannot be loaded anymore >> >> CommandLineLauncher has no class comment and no sender. So I have no idea >> what it does, nor if it can be removed from cog, nor how to solve this >> problem in Pharo. >> >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

May 10, 2011

Re: [Pharo-project] add temp does not add the temp in 1.3 13179

by Mariano Martinez Peck

Thanks Lukas. I put your code in a slice and it works. http://code.google.com/p/pharo/issues/detail?id=4153 On Tue, May 3, 2011 at 8:38 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I can reproduce it everywhere, in Pharo 1.2 and 1.3. I don't think it > has anything to do with Shout or eCompletion. It looks like the > problem is that the new text editor that doesn't consequently reuse > the same Text object but instead creates new ones. The method > #compile:classified:withStamp:notifying:logSource: depends on the fact > that this is always the same Text instance, even after editing. > Luckily we can fix that easily, but there might be other subtle bugs > lingering around: > > TClassAndTraitDescription>>compile: text classified: category > withStamp: changeStamp notifying: requestor logSource: logSource > | methodAndNode | > methodAndNode := self compile: text asString classified: category > notifying: requestor > trailer: self defaultMethodTrailer ifFail: [^nil]. > logSource ifTrue: [ > " replace 'text' with 'methodAndNode node sourceText' " > self logMethodSource: methodAndNode node sourceText > forMethodWithNode: methodAndNode > inCategory: category withStamp: changeStamp > notifying: requestor. > ]. > self addAndClassifySelector: methodAndNode selector withMethod: > methodAndNode > method inProtocol: category notifying: requestor. > self instanceSide noteCompilationOf: methodAndNode selector meta: > self isClassSide. > ^ methodAndNode selector > > On 3 May 2011 17:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > it does not work in OB in 1.3 nor in the plain default browser. > > Now in plain 1.3-core it is working in the default browser. So this is > probably linked with a package loaded in the dev image. I was thinking OC? > > > > Stef > > > > > > On May 3, 2011, at 2:30 PM, Johan Brichau wrote: > > > >> > >> On 03 May 2011, at 10:14, Mariano Martinez Peck wrote: > >> > >>> aha.... I didn't try that ;) > >>> So...in 1.2.1 adding from a browser does work, but not from the > debugger? > >>> And in 1.3 none of them? > >> > >> > >> I don't know about 1.3 but it's one of the things I started to notice > about 1.2.1 this week. > >> In the browser, it works fine. > > > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Mariano http://marianopeck.wordpress.com

May 10, 2011

[Pharo-project] [COTDC] 62 - MIMEType

by laurent laffont

Today: MIMEType Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

May 10, 2011

Re: [Pharo-project] [COTDC] 61 - InternetConfiguration

by laurent laffont

On Mon, May 9, 2011 at 8:34 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: InternetConfiguration > I read several parameters related to the OS network preferences, through the InternetConfigPlugin VM module. For example, to get the default path where downloaded files should be placed: InternetConfiguration getDownloadPath (That said, it's not used in the image). Laurent. > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

May 10, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Mariano Martinez Peck

On Tue, May 10, 2011 at 1:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > The fix in > http://code.google.com/p/pharo/issues/detail?id=4186 > > now one thing left: > we need to get rid of hanging methods with corrupted trailers. > > And we do it like this: > > (CompiledMethod allInstances select: [:m | > m isInstalled not and: [ m trailer kind = #VarLengthSourcePointer ]] > ) do: [:each | > each at: each size put: 0 ] > > This will replace a corrupted trailer with empty one. > > Excellent!!! that worked :) Thanks Igor. Now...it is supposed that when this issue fix is integrated the new generated image should now have these weird CMs so that script should not be necessary. I will test it when such image is build by hudson :) -- Mariano http://marianopeck.wordpress.com

May 10, 2011

[Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

by Sven Van Caekenberghe

SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations HTTP client and server functionality has become an essential part of any Smalltalk implementation. There exist various open source solutions delivering this functionality. Users quickly find out that HTTPS is not as readily available as HTTP. Although a solution exists in the form of SqueakSSL, it is not easily portable to Pharo and certainly not to other Smalltalk implementations. Furthermore, SqueakSSL is incomplete and more a working proof of concept than a high quality, high performance, maintainable piece of code, partially because of its dependence on the internals of SocketStream. Hence, some people wanting HTTPS on Pharo as well as one organisation have come foreword with a bounty to force a solution. Here are the requirements, a plan of action and a number of steps to build such a solution. First of all, it would be stupid not to start from the work already done for SqueakSSL. Any new solution should start from the existing plugin, from the existing set of primitives and from the current implementation of these primitives for the Windows, Mac OS X and Linux platforms. The Smalltalk part of the solution should be as platform independent as possible. We therefor need a new, clean implementation of SocketStream, with proper internal buffering and optimised versions of the bulk input and output primitives. The code should be time and space efficient. At first, only binary I/O is needed. Encoding/decoding is best done by wrapping the stream. Maybe a bivalent stream could be an option. The current ASCII support in quite limited. Next a SecureSocketStream can be implemented using this clean base combined with the SSLSession primitives. Here too, time and space efficiency are important although SSL will by definition be less efficient. Eventually, HTTP frameworks can then use this SecureSocketStream to actually implement HTTPS. Although the primary requirement is client functionality, server functionality should be provided as well. Next the existing issues with certificates need to be resolved, on all 3 platforms. Finally, the C code of the plugin for each of the 3 platforms needs to be cleaned up and improved where necessary. This requires contributions from developers who know and understand a platform as well as how SSL is supposed to work. Furthermore they have to understand and be motivated to work on Smalltalk plugins. Up to 3 different developers might be needed. The current implementation on Mac OS X does not seem to (directly) use the standard OpenSSL library from Linux although this library exists on Mac OS X. This could be an opportunity to reduce the number of implementations of the plugin to 2 API's. Needless to say the whole implementation should be open source licensed (MIT), be documented and have a number of units tests to cover it's main functionality as well edge cases encountered in the field. Friendly cooperation with other open source projects in the Smalltalk world is a plus. This project should benefit the whole community. The bounty should be split in different parts. The first part is setting up the new project, delivering the new SocketStream, SSLSession and SecureSocketStream, including the HTTPS client proof of concept. Traction within the community has to be developed. Next the issues with the plugin have to be identified. Then the work on the plugin code for each platform has to be defined and 3 more bounties could be offered. The goal should be to include the plugin in VM's by default. With a proper solution to the plugin issues, SSL server functionality should be no problem. I offer to take on part one and help manage the coordination of this project. So is there anyone capable and willing to help out on the plugin on on one or more platforms for part of the bounty ? Are there others who wish to raise the bounty ? We will need a couple of good beta testers who understand this field as well. Sven

May 10, 2011

Re: [Pharo-project] Additional Test for Shared Queue (s)

by StÃ©phane Ducasse

tx! I want more of such tests. :) On May 8, 2011, at 12:59 AM, pharo-project-owner(a)lists.gforge.inria.fr wrote: > > While trying to track down a bug, I started thinking that there was a problem with SharedQueue. There isn't, but there were no tests that convinced me of that. So I wrote one that actually has two processes reading and writing many times to a Q. > > The same tests works for NSSharedQueue (except that the class under test is hard coded). I suggest that putting these tests in the appropriate packages/core would be a good idea. > > Tests attached. > > <NSSharedQueueTest-testCounting.st><SharedQueue2Test-testCounting.st> > > >

May 10, 2011

Re: [Pharo-project] Which are the limitations of MessageTally?? Re: new Cog VMs uploaded

by Eliot Miranda

On Sun, May 8, 2011 at 5:07 AM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > What approach do you suggest should I take? >>> >> >> I have no idea. You could try and break down the various activities and >> benchmark them separately I suppose. You could look at the profiles you're >> already generating in higher resolution to see where the time is going. You >> could also try and extract the SystemProfiler from OpenQwaq, which will run >> on Cog, and is better than MessageTally. Andreas wrote it to get around >> some of MessageTally's limitations. It should hopefully show primitives >> quite accurately. >> >> > Hi. I have already read this several times. From you now, from Alexandre > Bergel, from Henrik Johansen, etc. But no one (or maybe I didn't see it) > give a list of the real existent MessageTally limitations or problems. So > far, the only thing I read is what Eliot says here: "show primitives quite > accurately" > > So...which are the rest and what is solved by the SystemProfiler from > OpenQwaq ?? > MessageTally works by using delays to cause a high-priority process to interrupt the process being profiled. So the sample is taken only at a suspension point. The SystemProfiler support in the VM takes a sample either after a primitive has run or when the VM is checking for events, so it takes more accurate samples. Further, the SystemProfiler's VM support also samples the active process when collecting the sampled method, so it more accurately ascribes profiles to processes. MessageTally only profiles a single process. Both suffer from a bug my colleague Yaron Kashai observed this week at Cadence, which is that if GC pauses are long then both profilers will under-measure the GC costs because they both take a single sample before measurement. So e.g. if a GC pause lasts five times longer than the poll time only one sample will be takem. Ideally the SystemProfiler would be extended to maintain a list of sampled methods and processes. best, Eliot > Thanks in advance, > > > Mariano > > > > > >> HTH >> Eliot >> >> >>> >>> Cheers >>> Philippe >>> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

May 10, 2011