Squeak-dev May 2010

squeak-dev@lists.squeakfoundation.org

101 participants
401 discussions

The Inbox: KernelTests-nice.151.mcz
by commits＠source.squeak.org 28 May '10

28 May '10

A new version of KernelTests was added to project The Inbox: http://source.squeak.org/inbox/KernelTests-nice.151.mcz ==================== Summary ==================== Name: KernelTests-nice.151 Author: nice Time: 28 May 2010, 9:30:59.204 pm UUID: a305c844-71d8-eb4e-85d7-c0bce7b20dc7 Ancestors: KernelTests-ul.150 After recent vwnc post, check whether LargeInteger ln overflows. Same for Fraction with LargeInteger. =============== Diff against KernelTests-ul.150 =============== Item was added: + ----- Method: IntegerTest>>testLn (in category 'tests - mathematical functions') ----- + testLn + self assert: (100 ln closeTo: 10 ln*2). + self assert: ((2 raisedTo: Float emax + 3) ln closeTo: 2 ln*(Float emax + 3)) description: 'Integer>>ln should not overflow'! Item was added: + ----- Method: FractionTest>>testLn (in category 'tests - mathematical functions') ----- + testLn + self assert: ((1/100) ln closeTo: -2/2 ln). + self assert: (((2 raisedTo: Float emax + 11)/3) ln closeTo: (Float emax + 11)*2 ln - 3 ln) description: 'Fraction>>ln should not overflow'. + self assert: ((3/(2 raisedTo: Float precision - Float emin)) ln closeTo: (Float emin - Float precision)*2 ln + 3 ln) description: 'Fraction>>ln should not underflow'!

1 0

All code
by Bert Freudenberg 28 May '10

28 May '10

Possibly, this is interesting for some who do not subscribe to the beginners list ... Begin forwarded message: > From: Bert Freudenberg <bert(a)freudenbergs.de> > Date: 28. Mai 2010 00:43:06 MESZ > To: "A friendly place to get answers to even the most basic questions about Squeak." <beginners(a)lists.squeakfoundation.org> > Subject: Re: [Newbies] How do I diff two images? > Reply-To: "A friendly place to get answers to even the most basic questions about Squeak." <beginners(a)lists.squeakfoundation.org> > > On 27.05.2010, at 16:34, Clinton Blackmore wrote: >> I have heard of Monticello. (I may need to re-read the chapter on it in Squeak By Example). I've used other version control systems, and understand how to use them, but I don't know of any that let you diff source trees that aren't in the same version control system, so I have no reason to expect that Monticello would do that, either. > > You could make a single Monticello package with all code in an image, save that, and compare it to the same package in another image. E.g., install the attached file and save the "All" package, you get an MCZ of about 10 MB. > > Also, having that allows fun queries: > (PackageInfo named: 'All') linesOfCode > > - Bert -

1 0

[ANN] Dan Ingalls at HPI (Fwd: Einladung zum HPI-Kolloquium am 03.06.10, 16:00 Uhr, HS 2)
by Torsten Bergmann 28 May '10

28 May '10

>Dan Ingalls will give a talk on "40 YEARS OF FUN WITH COMPUTERS" >upcoming Thursday at HPI. Hi Robert, will it be available on http://www.tele-task.de later too for those who can not attend? Thx Torsten -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

3 2

The Trunk: Tests-HenrikSperreJohansen.82.mcz
by commits＠source.squeak.org 28 May '10

28 May '10

Andreas Raab uploaded a new version of Tests to project The Trunk: http://source.squeak.org/trunk/Tests-HenrikSperreJohansen.82.mcz ==================== Summary ==================== Name: Tests-HenrikSperreJohansen.82 Author: HenrikSperreJohansen Time: 27 May 2010, 2:20:17.48 pm UUID: bf33877c-d5ae-4b9e-b3bf-753289ae9821 Ancestors: Tests-eem.81 Test for the cases described in Compiler-HenrikSperreJohansen.144 =============== Diff against Tests-eem.81 =============== Item was added: + ----- Method: ClosureCompilerTest>>testBlockDoitDecompilation (in category 'tests') ----- + testBlockDoitDecompilation + "Tests that decompile of a doit block with remote vars executes correcly" + "Tests that decompilation of a Block, when 'method' of block is equivalent to that compiled by a DoIt, preserves the temp names " + + |blockSourceStream methodNode compiledMethod block decompiledBlock| + blockSourceStream := '|x y| [:a :b | x := a. y := b. x + y]' readStream. + methodNode := nil class evaluatorClass new + from: blockSourceStream class: nil class context: nil notifying: nil; + translate: blockSourceStream noPattern: true ifFail: [nil]. + compiledMethod := methodNode generateWithTempNames. + block := nil withArgs: #() executeMethod: compiledMethod. + + self shouldnt: [decompiledBlock := block decompile] raise: Error. + self assert: '{[:a :b | + x := a. + y := b. + x + y]}' equals: decompiledBlock printString + !

1 0

The Trunk: Compiler-ar.145.mcz
by commits＠source.squeak.org 28 May '10

28 May '10

Andreas Raab uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-ar.145.mcz ==================== Summary ==================== Name: Compiler-ar.145 Author: ar Time: 27 May 2010, 9:38:04.277 pm UUID: 932818d3-1aeb-104b-826b-60c5a6f6f6a1 Ancestors: Compiler-HenrikSperreJohansen.144 Merging Compiler-HenrikSperreJohansen.144 Fix for BlockClosure decompilation in Workspace doits. Previously, blocks with remoteTemps would fail to decompile, f.ex: | x y | [:a :b | x := a. y := b] decompile (http://code.google.com/p/pharo/issues/detail?id=767) Also, temp names would not be preserved when inspecting a non-remoteTemps block, say [:x :y | | temp | 1 + x@y. ^temp] decompile printString. Getting the instvar names from MethodTrailer if present in decompileBlock: solves both these issues. (ar: restore formatting and refer to SyntaxErrorNotification directly) =============== Diff against Compiler-ar.143 =============== Item was changed: ----- Method: Decompiler>>decompileBlock: (in category 'public access') ----- decompileBlock: aBlock "Decompile aBlock, returning the result as a BlockNode. Show temp names from source if available." "Decompiler new decompileBlock: [3 + 4]" | startpc end homeClass blockNode methodNode home source | (home := aBlock home) ifNil: [^ nil]. method := home method. (homeClass := home methodClass) == #unknown ifTrue: [^ nil]. constructor := self constructorForMethod: aBlock method. + self withTempNames: (method tempNamesString ifNil:[ method fileIndex ~~ 0 ifTrue: "got any source code?" [source := [method getSourceFromFile] on: Error do: [:ex | ^ nil]. methodNode := [homeClass compilerClass new parse: source in: homeClass notifying: nil] + on: SyntaxErrorNotification - on: (Smalltalk classNamed: 'SyntaxErrorNotification') do: [:ex | ^ nil]. + methodNode schematicTempNamesString]]). - self withTempNames: methodNode schematicTempNamesString]. self initSymbols: homeClass. startpc := aBlock startpc. end := aBlock isClosure ifTrue: [(method at: startpc - 2) * 256 + (method at: startpc - 1) + startpc - 1] ifFalse: [(method at: startpc - 2) \\ 16 - 4 * 256 + (method at: startpc - 1) + startpc - 1]. stack := OrderedCollection new: method frameSize. caseExits := OrderedCollection new. statements := OrderedCollection new: 20. super method: method pc: (aBlock isClosure ifTrue: [startpc - 4] ifFalse: [startpc - 5]). aBlock isClosure ifTrue: [numLocalTemps := #decompileBlock: "Get pushClosureCopy... to hack fake temps for copied values"]. blockNode := self blockTo: end. stack isEmpty ifFalse: [self error: 'stack not empty']. ^blockNode statements first!

1 0

Trying to load ALienOpenGL into 4.1 alpha...
by Lawson English 28 May '10

28 May '10

hi all, was trying to load AlienOpenGL into 4.1 alpha and got the warning: This package depends on the following classes: AlienLibrary Is this deprecated for 4.x or renamed or..? Thanks, Lawson

10 43

New weak finalization support. Implementation
by Igor Stasenko 28 May '10

28 May '10

Hello, i updated the weak finalization classes. I made its behavior/protocol similar to old WeakRegistry, also all weak registry tests on new class is green. First, file in .st then .cs Also, don't forget about special objects array: http://bugs.squeak.org/view.php?id=7525 And sure thing, you will need a VM support for it. But I am unsure, how to introduce a fallback code (and do we really need it)? I thought, that i could just add a simple startUp routine which does GC to see if new finalization supported by VM. Then it could pick either WeakFinalizationRegistry or old WeakRegistry. But then, it will slow down the image startup significantly, not saying that John fought hard to avoid full memory/heap walk during image startup on iPhone. So, maybe introduce an additional prim into VM, which will tell us if it supports new finalization? Or query the VM version? I need your advice. -- Best regards, Igor Stasenko AKA sig.

3 4

Struct with doubles
by Schwab,Wilhelm K 28 May '10

28 May '10

Hello all, I am faced with some win32 software that uses a structure like struct gizmo { double x; y; z; double q[4]; } Would it be legal to treat that as struct gizmo { double x; y; z; double q0; q1; q2; q3; } and then let Pharo define the fields? This is running on 32 bit winxp. A colleague is doing 3D magic with the resulting numbers, but Weird things appear to be happening. I am looking for ways that I might be causing them. It is also possible that the gizmo to which we are interfacing is just plain broken. Bill

2 1

Integrating VMMaker-dtl.175
by Igor Stasenko 27 May '10

27 May '10

Dear all, i would really like to finish an integration of new finalization. But this requires releasing a new VMs for all platforms. If you think, we're done with VM-side part, then lets proceed with releasing new VMs, so we could start using new feature. -- Best regards, Igor Stasenko AKA sig.

3 2

Re: [squeak-dev] Community Supported Packages
by Dale Henrichs 27 May '10

27 May '10

Andreas, The package of Configurations sounds like a very good way to clearly identify (and manage) the set of supported configurations. As I think about, you may want to a use a different naming convention for the configurations so that there is a reduced chance of the supported configuration clashing with the names of configurations loaded from the "wild". Regarding tools, I am trying to stay out of the tool business for Metacello. Not that tools aren't needed but that maintaining Metacello is a big enough chunk to bite off without having to get into the tools business:) With that said I am more than willing to expand the API as needed to support the development of tools ... Dale ----- "Andreas Raab" <andreas.raab(a)gmx.de> wrote: | Folks - | | I've finally gotten some thoughts together for how to address the | 'package issues' in Squeak. This is going to take a while so I | apologize | beforehand for the length of this message :-) | | First, let's talk about the goals. What I'm trying to achieve is | basically to blur the line between what is 'in' the image and what is | | 'out' of the image. What I'm trying to achieve is to enable people who | | write applications and libraries for Squeak to be seen as direct | contributors to Squeak. What I'm trying to achieve is to drastically | grow Squeak by being much more inclusive while at the same time | drastically shrinking it by having many fewer packages 'preloaded'. | | How can we do this? Over the last months I've spent some time looking | at | options for package management. I don't really like any of the | available | options but since I'm not going to write something new, I've | concentrated on the one choice that appears to be actively supported - | | Metacello. It has its weaknesses but contrary to all the other options | | it's the one choice that is being supported and I appreciate that. | | While looking into Metacello I also spent some time at the Pharo | Metacello repository on Squeaksource. There are many interesting | things | to be said about it, both good and bad. Good things about it are that | | it's community maintained. Everyone can update everyone else's | contributions and although that's not generally done, it offers a | community approach to making sure things work. Something that for | example both Universes and Squeakmap lack completely. What's | problematic | about the repository on the other hand is that for one thing one needs | | to unconditionally trust the code even before one has even decided to | | install it (this by far my biggest complaint about Metacello). Also, I | | don't think that a single repository is a feasible option in the long | | term - it seems to me that supporting the cross-product of image and | package versions is going to be problematic before too long. And of | course browsing repositories with several dozen of packages to find | what | you need isn't exactly fun either. | | However, the problems can be turned on their head, and that's actually | | pretty insightful. Here's the basic idea: What if, instead of having a | | single repository for all image versions with separate packages for | each | config, we would instead have a single package simply called | Configurations in the trunk? | | That Configurations package would contain all the "supported" | configurations for Squeak (I'll get to that in a minute). The package | | would be community-maintained, just like any other package in trunk | development process. This addresses the trust issues with Metacello, | since the package has the same level of trust that all the other | packages in a Squeak release have; it has been developed using the | same | principles. | | What that gives us is a mechanism by which we suddenly can include | Omnibrowser, Seaside, Magma, FFI and anything else people can come up | | with in Squeak without having to preload it in the shipping image. | What | it also means is that we can start removing packages from the image, | replacing them with the proper configurations for how to load them | back. | What it means is that somebody with a new application (be that | Stephane's Muo app, Hillaire's Dr. Geo, or Josh's OpenCL demo) can ask | | for the configuration to be part of the next Squeak release, thereby | contributing *directly* to that Squeak version. | | Most importantly, however, is that we as the community can decide what | | we feel we want to support and what not. By being explicit about the | 'house rules' we can make sure that the model is sustainable moving | forward. | | To do that, I'm proposing to create a status of "Community Supported | Package" in Squeak. What is that? A community supported package is a | piece of software where we feel this is an important/interesting/novel | | package that should ship with this Squeak version. A community | supported | package can be loaded in a 'one-click' process directly from within | the | image. A community supported package is a package where we provide | assurance that the package has been tested for this release. | | However, that status does not come for free. In return for achieving | this status, the software needs follow the rules for community | supported | packages, which (at least) should include the following: | | * No conflicts. Neither class names nor -override categories. The | rationale is that all community supported packages can be loaded | together without creating conflicts. | | * Tests mandatory. A community supported package MUST have tests. The | | rationale is that since we provide the guarantee that the package has | | been tested, we need to ensure that testing can be automated to the | maximum extent possible. It doesn't mean 100% coverage but *some* | meaningful set of tests need to be provided or else we can't say if we | | broke it in the latest update. | | There may be some other guidelines that we may want to establish but | I'm | trying to keep things simple and only the above two are truly crucial | - | what they allow is to ensure that during ongoing trunk development we | | will always be able to load all supported packages, run the tests and | | see if we broke something horribly. | | So the goal of the process is that if we do this right, we should be | able to tell how good (or how bad) a shape we're in regarding the | supported packages when we get to ship date. We should be able to | encourage people who write libraries or apps with, for, and in Squeak, | | to contribute directly to the next release by providing a | configuration, | their code, and the tests so that we can keep things running. In | return, | we'll help with porting, provide backwards compatibility as required | etc. | | Code that we want to move out of the default image would be moved into | a | configuration so people can load it if desired, and it remains a part | of | Squeak instead of rotting away. Since the Configuration package is | small | and has no dependencies, there's no problem to include that in | core/basic images and allow people to tailor custom images from | there. | | Concretely, I'm seeing the following steps as necessary: | | 1. Establish the status and the rules for "Community Supported | Packages". | | 2. Create the "Configurations" package and start populating it with | some | examples (Omnibrowser, FFI, Magma ...) to see how that 'feels' like. | | 3. Encourage people to bring their packages up to 'community | standards' | and include them in the Configurations. | | From here, there are a few more things that we should do before we | can | ship the next Squeak version: | | 4. Provide a better installer than these awful doIts for Metacallo. | | 5. Establish a test server to automatically verify the community | standards for supported packages (i.e., load packages randomly, ensure | | no conflicts, run tests, report results). | | At this point, there is another clearly defined way to contribute to | Squeak even if you're not a core developer: Develop your software, | provide a configuration, ensure your software adheres to the community | | standards. That's it. You've just made the next Squeak release a | little | better :-) | | Cheers, | - Andreas

4 10

← Newer
1
2
3
4
5
6
7
...
41
Older →

Jump to page: