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

[Pharo-project] Issue 3415 in pharo: Failing tests for SUNit
by pharo＠googlecode.com Dec. 19, 2010

Dec. 19, 2010

Status: Accepted Owner: marcus.denker Labels: Milestone-1.2 New issue 3415 by marcus.denker: Failing tests for SUNit http://code.google.com/p/pharo/issues/detail?id=3415 >>> SUnit.Tests.SUnitTest.testExpectedFailure 0.0 50 >>> SUnit.Tests.SUnitTest.testExpectedFailureDetection 0.0 50 >>> SUnit.Tests.SUnitTest.testExpectedFailurePass 0.0 50 These are testsing the expected failures defined by pragmas that we removed because of performance. Tests should be fixed to use oldstyle expected failure definition

1 2

[Pharo-project] preamble in ChangeSet and ChangeRecord
by Max Leske Dec. 19, 2010

Dec. 19, 2010

Hi folks What exactly is the purpose of the preamble in ChangeSet and ChangeRecord? I believe they are not the same for both objects but I haven't been able to figure out what the content of a preamble might actually be. My guess would be that it contains either a comment or a doIt that can check prerequisites. Maybe you could give me an example of how the respective preambles would be used. Thanks, Max

2 2

[Pharo-project] Issue 3451 in pharo: All the packages should have pharo as homw package folder
by pharo＠googlecode.com Dec. 19, 2010

Dec. 19, 2010

Status: Fixed Owner: stephane.ducasse Labels: Milestone-1.2 New issue 3451 by stephane.ducasse: All the packages should have pharo as homw package folder http://code.google.com/p/pharo/issues/detail?id=3451 Else we will have problem to merge. ScriptLoader new cleanRepositories

1 1

[Pharo-project] Issue 3456 in pharo: ENH SUnit ClassFactoryForTestCase
by pharo＠googlecode.com Dec. 19, 2010

Dec. 19, 2010

Status: New Owner: ---- New issue 3456 by bouraqadi: ENH SUnit ClassFactoryForTestCase http://code.google.com/p/pharo/issues/detail?id=3456 The default superclass is put in a dedicated method so it can be redefined in subclasses

1 4

[Pharo-project] [Progress Report] Zinc HTTP Components
by Sven Van Caekenberghe Dec. 19, 2010

Dec. 19, 2010

I am pleased to report another milestone was reached in the Zn project. The default implementation for an HTTP Server is now a multi-threaded (forking) keep-alive implementation called ZnMultiThreadedServer. It passes my initial concurrent load tests. ZnServer is now a facade. This means that all features (test server, static file server, monticello server, seaside adaptor, as well as all unit tests) are now using the new code. In addition, several useful features were added to the servers, including logging and lastRequest/lastResponse debugging hooks. Extra handlers were added to ZnDefaultServerDelegate (favicon, benchmark, random) which double as examples. Next up will be some benchmarking and optimalization. As always, users/testers are most welcome. For more details: http://www.squeaksource.com/ZincHTTPComponents.html http://homepage.mac.com/svc/Zinc-HTTP-Components/index.html http://homepage.mac.com/svc/Zinc-HTTP-Components/getting-started.html Sven

4 16

[Pharo-project] Calling Cli programs
by flebber Dec. 19, 2010

Dec. 19, 2010

Hi easy question, but google isn't seeming to give me the right search results for this. What do I need to read up on when trying to run an external cli program from within smalltalk. For example I wanted to take a file and pass it to X264 on the command line. Command Such as; x264 [options] -o outfile infile [widthxheight] -- View this message in context: http://forum.world.st/Calling-Cli-programs-tp3094384p3094384.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 1

[Pharo-project] A pass on bugs of 1.2 and 1.2-Dev
by Luc Fabresse Dec. 19, 2010

Dec. 19, 2010

Hi all, I made a pass on failing tests. I fixed some: #3415 #3455 #3456 I report #3454 in 1.2-dev : DNU when looking for implementors in OBrowser #Luc

1 0

[Pharo-project] funny
by Hilaire Fernandes Dec. 19, 2010

Dec. 19, 2010

Funny :) http://hiddenjobmarketsecrets.com/new-video-why-small-talk-matters-in-your-…

2 1

[Pharo-project] Dear Santa ...
by Torsten Bergmann Dec. 19, 2010

Dec. 19, 2010

>Only that? :) Sorry ... forgot the "theming" thing (so I Santa should sent us a good designer that reworks the icons, GUI, ... and anything marketing related to be so consistent that people say: 'ah ... that must be Pharo") >I was really a nice boy and I want more :) I thought I wait with the "Smalltalk take over the world" until next year when we all were nice boys and girls ;) >But I have the impression that santa is busy and we will have to >do it ourselves. At least the wishlists can help us to see what people would like to have. And if Santa really exists he may at least help us to find good souls to make progress here ... Thx T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

2 1

[Pharo-project] Automated VM build server
by Igor Stasenko Dec. 19, 2010

Dec. 19, 2010

In our nearest plans is make an automated (Hudson based) build setup for Cog and Squeak VMs. All files, which used for building an artifacts should be included in source code repository. So, most probably i will add the 'hudson-build' dir at same level as 'platforms', where scripts and configs will be stored. Some changes which i going to do: - all generated code will be removed from version controlled tree. Instead of it i will add an information, which will be enough to reproduce the generated code by taking 3 separate config file(s) a) image version (or its URL(s) for download) b) script for loading VMMaker (of concrete version) + all addons like FFI , FT2 etc etc into image c) script for generating the source code using VMMaker image .. z) tell me if i miss anything here With removing generated source code from repo we now can make sure that any changes in VMMaker (including code generation itself) can be tested and can be reproduced by build server at any snapshot version. Also, we could test & see if VMMaker loads well and can generate code using different base images. So, we will instantly know if any changes in compiler, or other layers of system is breaking VMMaker. Because having a years old image where VMMaker works 100%, but at same time have 100% chances that it couldn't be loaded (or even if loaded, but can't run correctly) in latest image is not what i think good practice for keeping your house clean. So, by getting rid any intermediate artifacts from build chain we will be able to make sure that: - VMMaker loads w/o problems in latest/multiple image(s) - VMMaker works well and can generate code That's means that for any newcomer, loading and building VM will be much less tedious process, and for 99% of cases it can be fully automated error free process. And let me remind our motto: we're not trying to produce perfect system/setup from first lucky shot. We slowly but steady crawling towards improved state of art. Any comments, ideas and suggestions are welcome. -- Best regards, Igor Stasenko AKA sig.

10 17