- Pharo-dev - lists.pharo.org

[Pharo-project] Recovering lost changes
by Schwab,Wilhelm K March 29, 2010

March 29, 2010

Hello all, I had some type of melt-down today and ended up with an image that won't load. I have a backup from a few days ago, but a lot has happened since then. Recent change logs seem to be readable, but the "Recover lost changes" GUI has not been terribly helpful. Is there a way to filter to things like most recent versions of a any given methods, and/or sort on the types of chunks? One surprising weakness I noted was that many do-it chunks involve things that were in context in the debugger, are "now" nil and ended up breaking the file-in command. I put an error handler around the evaluatations which helped, but things are still somewhat slow thanks to other do-its that do a LOT of work. I might start chipping away from the most recent chunks until it recovers enough that I can cut my loses. Ian Bartholomew's Chunk Browser for Dolphin would be an ideal tool to emulate. With what we have now, any workarounds for the things above would be greatly appreciated. Is there a way to do extended selection (e.g. shift-select to select a range of chunks)? Bill

2 4

[Pharo-project] Issue 2227: unused selectors and instance variables from UTF8TextConverter
by StÃ©phane Ducasse March 29, 2010

March 29, 2010

Hi levente do you have some advices for us to do the same in pharo? http://code.google.com/p/pharo/issues/detail?id=2227 Stef

2 3

[Pharo-project] Pharo 1.0 fixing tests
by Adrian Lienhard March 29, 2010

March 29, 2010

Hi all, What results do you get when running all tests in Pharo and PharoCore 1.0 on Mac/Windows/Linux? Lukas has MCPackageTest>>#testUnload failing on Hudson (a Linux server, I assume). When running the tests locally on the Mac, the test BlockContextTest>>#testTrace fails. But only the first time. Apparently ContextPart>>#trace: is broken [1]. When I run all tests in Pharo1.0 on a Mac VM 4.2.3beta1U the first time I get no failures. When running the second time I get following failures: MCInitializationTest>>testWorkingCopy MCSnapshotTest>>testInstanceReuse ProcessspecificTest>>testDynamicVariable ProcessspecificTest>>testLocalVariable ReleaseTest>>testObsoleteClasses If I then run only the above, they all pass. So there is certainly something fishy with the tests or how they are run. I would like to have a reliable, green test suite for Pharo 1.0. Can you report the results you get including the VM/platform? Any idea why the results are not stable? Thanks, Adrian [1] http://code.google.com/p/pharo/issues/detail?id=2210

4 6

[Pharo-project] [update] #10516
by Marcus Denker March 29, 2010

March 29, 2010

10516 ----- Issue 2215: testFontFullName recursively deletes all files in the image directory -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Inspecting an ExternalData
by Schwab,Wilhelm K March 29, 2010

March 29, 2010

Hello all, At least in RC1, I am unable to inspect instances of ExternalData; #inspectorClassOf: is returning nil (Standard tool set). Any ideas? I am getting the external data instances from funtions returning void pointers. Exploring the instances might be working, but I'm not sure what to expect just yet. Bill

2 1

[Pharo-project] A little quizzzzzzz : find the problem :)
by StÃ©phane Ducasse March 28, 2010

March 28, 2010

fileStream "Answer the file stream with position set at the beginning of my string. Answer a read only copy to avoid syntax errors when accessed via multiple processes." | theFile | (sourceFileNumber == nil or: [(SourceFiles at: sourceFileNumber) == nil]) ifTrue: [^ nil]. theFile := (SourceFiles at: sourceFileNumber) readOnlyCopy. theFile position: filePositionHi. ^ theFile string "Answer the receiver's string if remote files are enabled. Use a read only copy to avoid syntax errors when accessed via multiple processes." | theFile | (sourceFileNumber == nil or: [(SourceFiles at: sourceFileNumber) == nil]) ifTrue: [^'']. theFile := (SourceFiles at: sourceFileNumber) readOnlyCopy. ^[theFile position: filePositionHi. theFile nextChunk] ensure: [theFile close] text "Answer the receiver's string asText if remote files are enabled. Use a read only copy to avoid syntax errors when accessed via multiple processes." | theFile | (sourceFileNumber == nil or: [(SourceFiles at: sourceFileNumber) == nil]) ifTrue: [^ nil]. theFile := (SourceFiles at: sourceFileNumber) readOnlyCopy. ^[theFile position: filePositionHi. theFile position > theFile size ifTrue: [ self error: 'RemoteString past end of file' ]. theFile nextChunkText] ensure: [theFile close] I imagine a good soul could fix that and nicely published in the inbox :) Stef Did I say something negative about the past :)

3 3

[Pharo-project] Help system question / monticello
by Michael Roberts March 28, 2010

March 28, 2010

Hi, based on Lukas' recent blog post about Monticello merging, I created some help system classes for this content. What is the best way to integrate this? We have our own version of Monticello in the Pharo repository. Which package, would we add it to? Or do we want to add it upstream somewhere? Also, has anyone thought or spiked some simple formatting? that would be really nice. thanks, Mike

4 7

Re: [Pharo-project] [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
by Eliot Miranda March 28, 2010

March 28, 2010

On Sun, Mar 7, 2010 at 3:24 PM, Gilad Bracha <gbracha(a)gmail.com> wrote: > I'm all for it, and hope that John or Eliot can mentor. I would like to mentor something in this area, but I think the basic goal of a cross-platform system is not achievable in GSoC this summer. A specification of a non-blocking architecture and a reference implementation may be possible. Cross-platform is too big for a summer project and will require input from dialects and vendors. What affects my thinking is the following: 1. I designed and implemented the VisualWorks THAPI system, a threaded extension to the VisualWorks FFI. 2. I have a functional prototype of a multi-threaded FFI for the Cog VM based on David Simmons' VMs. 1's architecture is poor, being complex, slow and not very general (allows only FFI calls to be threaded). 2's architecture is rather simple, rather fast and very general (allows threading to be much more widely used, e.g. calls within plugins can be made threaded by surrounding them with two calls, disownVM and ownVM). 3. I have looked at marshalling semantics in the context of the VW FFI, Andreas' Squeak FFI & Alien, and am still of the opinion, one shared by David, - that the generation of marshalling stubs has to be lifted up into Smalltalk based on simple ABI compilers that somehow (e.g. through RTL) communicate down to a JIT that generates and caches marshalling code (i.e. that VM attempts to interpret simplified call specs, as happens in the VM and Squeak FFIs are in general doomed to poor performance and bugs) - that type coercion code also has to be lifted (e.g. character conversions on strings, null termination, type coercion) - that one be able to depend on a pinning garbage collector to deal with the issues of passing objects through the FFI (although there are workaround hacks that can serve temporarily) I don't see the point of spending a GSoC trying to implement an obsolete (unthreaded, lowest-common-denominator) cross-platform FFI; it won't get used. I do see benefit in an open-source reference implementation that provides some of the above (at least threading/non-blocking). If people agree that an open-source reference implementation is worth pursuing, then I will happily mentor. What the starting point is will depend on to what extent Cog has been open sourced (Teleplace may choose to open source single-threaded Cog initially, keeping back the threaded FFI for a while, it may not open source Cog at all; we'll see :) ). There are other starting points (current Squeak VMs, GST, Newspeak). But the outline above is a move towards better cross-platform commonality, not less, because it's an architecture in which the image does more (type coercion, compiling call signatures to RTL sequences) and the VM (except for the threading ;) ) does less. And so this direction does lead towards better cross-platform facilities. best Eliot

9 12

March 27, 2010

11299 ----- - Issue 2222: Form dimmed - Issue 2209: Form conversion ligther/darker and other cool methods - Issue 2220: CombinedChar>>#add: - Issue 2217: fontFullName fixes - Issue 2219: redirect locations fix and tests - Issue 2221: primitiveFailed better feedback Stef

1 0

[Pharo-project] Issue 2219: redirect locations fix
by stephane ducasse March 27, 2010

March 27, 2010

Hi network aware guy can you have a look at that? http://code.google.com/p/pharo/issues/detail?id=2219 I'm planning to integrate it in pharo but some incentive from you would help :) Stef

1 0