Squeak-dev May 2014

squeak-dev@lists.squeakfoundation.org

43 participants
219 discussions

MCPackageTest>>testUnload fails
by Nicolas Cellier 25 May '14

25 May '14

It fails because after unloading the package there is still a subclass of MCMock named #MCMockClassA. There is still a subclass named #MCMockClassA because there are two such subclasses, one is not removed. There are two such subclasses probably because MCEnvironmentLoadTest does not tearDown properly. MCMock subclasses select:[:e | e environment ~~ Smalltalk environment]

1 0

Resolving MCSerializationTest>>testMcdSerialization a little rant
by Nicolas Cellier 25 May '14

25 May '14

The test relies on mockDiffyVersion | repos workingCopy base next | repos := MCDictionaryRepository new. workingCopy := MCWorkingCopy forPackage: self mockPackage. workingCopy repositoryGroup addRepository: repos. MCRepositoryGroup default removeRepository: repos. base := self mockVersion. repos storeVersion: base. self change: #a toReturn: 'a2'. next := self mockVersionWithAncestor: base. ^ next asDiffAgainst: base As I said in another thread, this test is not working as intended. Despite the intention to change #a toReturn: 'a2', and thus have a diff, the base version and next version share the same snapshot. Thus there is no change detected. Thus there is a [Warning signal: 'About to serialize an empty package.']. The first reason why this is not working is because #mockVersion and #mockVersionWithAncestor both send #mockSnapshot. But #mockSnapshot is not dynamic, it's rather a fixed ressource (see MCSnaphsotResource>>snapshot, setUp, takeSnapshot). So the first thing is to change mockVersionWithAncestor: to use (self mockPackage snapshot instead) of (self mockSnapshot) - oh yeah that's too obvious, isn't it? But that's not enough... What is exactly the state retained in MCSnaphsotResource? Apparently #a already returns 'a2' in the snapshot, probably because this is what is stored in the Tests package. And this is what is stored in Tests package probably because MCSerializationTest never invoke #restoreMocks. Some SUnit do this in the tearDown, but it looks like random to me... So we have many tests messing with a global state... This global state creates many interactions. As someone who did not write these tests, I'd say it's impossible to get a clear picture ot all those interactions, even after a few hours of browsing and debugging. So who should send restoreMocks? There is not a comment anywhere explaining what the responsibilities and the contracts are. It's very good to have self explaining code, but here, having no guideline for such a complex beast, I personnally see it as self fooling code.

1 0

Re: [squeak-dev] The Trunk: Collections-nice.570.mcz
by Nicolas Cellier 25 May '14

25 May '14

Once again, I pushed this un-essential 3 years old change to trigger another CI build... If the build fails, don't worry, there are many other un-essential changes I did. Why do you think I keep my images and use the update stream? 2014-05-25 0:38 GMT+02:00 <commits(a)source.squeak.org>: > Nicolas Cellier uploaded a new version of Collections to project The Trunk: > http://source.squeak.org/trunk/Collections-nice.570.mcz > > ==================== Summary ==================== > > Name: Collections-nice.570 > Author: nice > Time: 25 May 2014, 12:37:21.454 am > UUID: 1069cfcc-6bd7-4d7d-87fb-0a0a546f8a0c > Ancestors: Collections-nice.569 > > Let's optimize a bit LinkedList>>at:ifAbsent: by scanning the list only > once, unlike super. > > =============== Diff against Collections-nice.569 =============== > > Item was added: > + ----- Method: LinkedList>>at:ifAbsent: (in category 'accessing') ----- > + at: index ifAbsent: exceptionBlock > + "Optimized to scan the list once, super would twice." > + | i | > + index < 1 ifTrue: [^exceptionBlock value]. > + i := 0. > + self do: [:link | > + (i := i + 1) = index ifTrue: [^ link]]. > + ^exceptionBlock value! > > >

3 2

Daily Commit Log
by commits＠source.squeak.org 25 May '14

25 May '14

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2014-May/007056.html Name: Compression-nice.42 Ancestors: Compression-eem.41 Cosmetic refactoring: (aCollection anySatisfy: aBlock) not -> (aCollection noneSatisfy: aBloc) ============================================= http://lists.squeakfoundation.org/pipermail/packages/2014-May/007057.html Name: Environments-nice.47 Ancestors: Environments-ul.46 Rename EnvironmentRequest to CurrentEnvironment and use it to implement Environment class>>current. Or more exactly, replace with rather than rename (and don't remove EnvironmentRequest yet, otherwise the update-stream which is using EnvironmentRequest via Monticello will fail) ============================================= http://lists.squeakfoundation.org/pipermail/packages/2014-May/007058.html Name: Collections-nice.570 Ancestors: Collections-nice.569 Let's optimize a bit LinkedList>>at:ifAbsent: by scanning the list only once, unlike super. =============================================

1 0

The Trunk: Collections-nice.570.mcz
by commits＠source.squeak.org 25 May '14

25 May '14

Nicolas Cellier uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-nice.570.mcz ==================== Summary ==================== Name: Collections-nice.570 Author: nice Time: 25 May 2014, 12:37:21.454 am UUID: 1069cfcc-6bd7-4d7d-87fb-0a0a546f8a0c Ancestors: Collections-nice.569 Let's optimize a bit LinkedList>>at:ifAbsent: by scanning the list only once, unlike super. =============== Diff against Collections-nice.569 =============== Item was added: + ----- Method: LinkedList>>at:ifAbsent: (in category 'accessing') ----- + at: index ifAbsent: exceptionBlock + "Optimized to scan the list once, super would twice." + | i | + index < 1 ifTrue: [^exceptionBlock value]. + i := 0. + self do: [:link | + (i := i + 1) = index ifTrue: [^ link]]. + ^exceptionBlock value!

1 0

The Trunk: Environments-nice.47.mcz
by commits＠source.squeak.org 25 May '14

25 May '14

Nicolas Cellier uploaded a new version of Environments to project The Trunk: http://source.squeak.org/trunk/Environments-nice.47.mcz ==================== Summary ==================== Name: Environments-nice.47 Author: nice Time: 25 May 2014, 12:22:16.232 am UUID: 83f41a4a-d652-4246-8c98-587bf994a91a Ancestors: Environments-ul.46 Rename EnvironmentRequest to CurrentEnvironment and use it to implement Environment class>>current. Or more exactly, replace with rather than rename (and don't remove EnvironmentRequest yet, otherwise the update-stream which is using EnvironmentRequest via Monticello will fail) =============== Diff against Environments-ul.46 =============== Item was added: + Notification subclass: #CurrentEnvironment + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'Environments-Loading'! Item was added: + ----- Method: Environment class>>current (in category 'accessing') ----- + current + ^ CurrentEnvironment signal ifNil: [self default]! Item was changed: ----- Method: EnvironmentLoader>>evaluate: (in category 'as yet unclassified') ----- evaluate: chunk ^ [Compiler evaluate: chunk environment: environment] + on: CurrentEnvironment - on: EnvironmentRequest do: [:req | req resume: environment]! Item was changed: ----- Method: EnvironmentLoader>>evaluate:logged: (in category 'as yet unclassified') ----- evaluate: chunk logged: aBoolean ^ [Compiler evaluate: chunk environment: environment logged: aBoolean] + on: CurrentEnvironment - on: EnvironmentRequest do: [:req | req resume: environment]!

1 0

The Trunk: Compression-nice.42.mcz
by commits＠source.squeak.org 24 May '14

24 May '14

Nicolas Cellier uploaded a new version of Compression to project The Trunk: http://source.squeak.org/trunk/Compression-nice.42.mcz ==================== Summary ==================== Name: Compression-nice.42 Author: nice Time: 24 May 2014, 11:24:05.218 pm UUID: c9c66aed-c87d-4c7f-8518-fda5842f46c2 Ancestors: Compression-eem.41 Cosmetic refactoring: (aCollection anySatisfy: aBlock) not -> (aCollection noneSatisfy: aBloc) =============== Diff against Compression-eem.41 =============== Item was changed: ----- Method: Archive>>canWriteToFileNamed: (in category 'archive operations') ----- canWriteToFileNamed: aFileName "Catch attempts to overwrite existing zip file" + ^members noneSatisfy: [ :ea | ea usesFileNamed: aFileName ]. - ^(members anySatisfy: [ :ea | ea usesFileNamed: aFileName ]) not. !

1 0

Re: [Pharo-dev] What is your seaside application?
by Chris Muller 24 May '14

24 May '14

Hi Leonardo, > > I am interested in events you can trigger in web pages. For example: a > user clicks on a button and the script code associated causes a state > change in the Document Object Model (DOM) and sends a XHR request > (XMLHttpRequest) to the server. The server eventually answers this request, > closing the sequence of events. I want to trace these sequences of events > from a running application. > You might be interested in checking out Michael Perscheids recently announced "Path Tools" framework for Squeak. It performs incremental, dynamic analysis of an application under observation. The framework is designed to analyze the running TestCases of an application, which is perfect for TDD. https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki… One of the demonstration videos showcases its "Test-driven fault navigation" capability, where a bug is purposefully introduced into Seaside itself and shown how the system employs its lightweight, "back-in-time debugging" feature to identify it. Amazing stuff! >> So, a simple and quick-to-answer question, what is your Seaside application and how to access the code of it? > > > > many of web app are private because business oriented. > > I understand, but it would be nice to have some examples of web > applications using script languages, even if I don't have access to all > source code. > Path Tools is MIT-licensed so everything is visible. In fact at the bottom of that page is a pre-configured image available for download which provides an interactive tutorial.

1 0

A smooth interface to the old world so we don't end up sharing a grave with smalltalk
by karl ramberg 24 May '14

24 May '14

I read this article on Light Table blog http://www.lighttable.com/2014/05/16/pain-we-forgot/ Pain here is pain from using dev environments, dev tools et al. He details plans for solving these problems in future dev tools. Most of these development environment problems are touched on and mostly solved in Smalltalk environments. And the author seems to agree and finishes his to do list with: "The key parts of our plan for Aurora are: ... - a smooth interface to the old world so we don't end up sharing a grave with smalltalk " Cheers, Karl

5 6

Re: [Pharo-dev] Advice for a newb
by Eliot Miranda 24 May '14

24 May '14

On Fri, May 23, 2014 at 12:47 PM, stepharo <stepharo(a)free.fr> wrote: > > On 20/5/14 04:41, Rick Kitts wrote: > > Hello. I was wondering if anyone could point me to or otherwise suggest > some best practices for working on Kernel code. I’m futzing about with the > Duration class (in the interest of fixing 13215) > > Thanks! > > and have discovered that it’s really easy to crash Pharo if I break that > class. I assume there are other classes that would exhibit the same > behavior. > > Yes like Array or OrderedCollection. > > We are working on a bootstrap of pharo and it could help for brain surgery > (but in that case the system may simply not build at all). > So the suggestion of Ron to use ChangeSet is a good one. > But it is also possible to do it with Monticello, using "updates", which are really baseline versions of a package. The idea is to make the necessary changes that support your next, potentially suicidal step, commit a baseline for that support, and then commit the change that depends on the support. The Monticello update scheme ensures that the baseline is loaded before your second commit. This process can be repeated as many times as necessary to make a sequence of interdependent changes happen in order. For example, I've just added multiple bytecode support to Squeak trunk. That needed some code on Squeak's BytecodeEncoder and subclasses, which are in the Compiler package, *before* loading the Kernel code that depended on that BytecodeEncoder support. If things don't happen in the right order the compiler, debugger, and tool facilities such as references & assignments would break. By all means use the change list for crash recovery, or even change sets. But unlike change sets, Monticello's updates provide support for any number of steps. Typically with a change set you have to manually reorder things. I've used change sets a lot in the past to pull off a number of "adventurous" system changes. But now I'm familiar with Monticello it feels like its by far the best way. > > Now once I got change that crash (just a tight endless loop) as soon as > you change anything and there you have to rollback and turn around the self > referencing aspect. > > > I suppose I could just be really cautious and save my image after every > change but that seems so error prone that I’m hoping that there are > idiomatic ways of working on kernel code (beyond just save ones image early > and often) so I don’t lose work. I’m asking because the naive solution > (copy the original class, modify it to suit, delete the original and rename > the new class to the original) of course doesn’t work. > > TIA for any suggestions or assistance and apologies in advance if this > is RTFM, I didn’t see anything (didn’t look very hard either though). > > —Rick > > > -- best, Eliot

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
22
Older →

Jump to page: