April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Monticello/ftp stopped working for me

by David T. Lewis

On Thu, Apr 30, 2009 at 11:48:52PM +0200, Nicolas Cellier wrote: > Very strange... > After a while on linux, I have an error in MCHttpRepository>>#allFileNames > > 'Could not resolve the server named: source.lukas-renggli.ch' > > while executing: > > instClass lukas > install: 'OB-Regex'; > > the 6 opened fd turned into many ... all pointing to the change file > Pharo0.1Core-10281cl.changes Well that's a bug for sure. Somebody is opening new file streams on the changes file, probably by accident. And not closing the one they opened last time. The bug in changes file handling could easily appear to be a socket problem, because the per-process limit on open descriptors would be shared between files and sockets (and pipes and ...). So find out why the changes file is being accidentally reopened, and the "socket problem" will probably go away. Dave

April 30, 2009

Re: [Pharo-project] run all tests from superClass

by Hernan Wilkinson

My mind keep thinking about this and I realized that the problem with reusing sunit test cases is more a tool related problem. I mean, nothing stop us from doing something like this:------- TestCase subclass: #EnumerationTest instanceVariableNames: 'collection' etc. EnumerationTest>>testDo collection do: [ :x | self assert: what ever has to be tested.... ]. EnumerationTest>>testSelect collection select: [ what ever has to be tested ... ] EnumerationTest>>collection: aCollection collection := aCollection. ----- Then if you want to run it with an array, we can do something like this: EnumerationTest buildSuite tests do: [ :aTest | aTest collection: #(1 2 3) ]; run. or with a OrderedCollection EnumerationTest buildSuite tests do: [ :aTest | aTest collection: (OrderedCollection with: 1 ....) ]; run. etc. The problem with this is that the test runner assumes that test cases are made up from subclasses of TestCase, a really bad coupling... so, if we want to keep running test from the test runner, we can: 1) Create a test case per collection type and create a test method per test method in EnumerationTest... TestCase subclass: #ArrayTest ArrayTest>> testDo (EnumerationTest selector: #testDo) collection: #(1 2 3); run. etc. a really ugly thing 2) Redefine testSelectors in ArrayTest, OrderedCollectionTest to do something like this: testSelectors ^EnumerationTest testSelectors buildSuiteFromLocalSelectors ^(super buildSuiteFromLocalSelectors) tests do: [ :aTest | aTest collection: ... ] 3) Or just open the test runner with a suite... something like: TestRunner open runSuite; ( EnumerationTest buildSuite tests do: [ :aTest | aTest collection: #(1 2 3) ]; yourself) Anyway, I think the problem of reusing tests with SUnit is more related with the tools we use to run the tests and not with the TestCase hierarchy, although it is not straightforward to reuse tests with it. Bye, Hernan On Thu, Apr 30, 2009 at 9:56 AM, Hernan Wilkinson < hernan.wilkinson(a)gmail.com> wrote: > > What I read here indicates you prefer maintaining many duplicates of the >> test. >> And when you realize that one of the test was buggy (not the method >> that is tested, but the test itself), you certainly prefer to track >> all the copies and probably leave a buggy one here and there... > > > nop nop... that was not my intention. If there is "duplicate code", then it > should be reified. > Traits is an option and we did that with Acciaressi and Butarelli thesis > (same problem). > Another option is just normal delegation. > > Bye, > Hernan > > >> >> >> Rethorical debates are fine, but it would be more enlightning to >> discuss around some chosen examples. >> >> Nicolas >> >> 2009/4/30 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com>: >> > Hernan Wilkinson wrote: >> >> I don't think it is a good idea to have hierarchies with test cases... >> >> depending on how you are doing it, it could couple the test hierarchy >> >> with the model hierarchy and I don't think that is a good idea... >> >> It also introduces some complexity, for example the number of tests are >> >> not only the test methods but for each concrete test class, the test >> >> methods on it plus the test methods of the abstract superclasses... >> hmmm >> >> I don't know, it is not natural at least for me too user inheritance >> >> with tests... >> > >> > +1 >> > Besides, one of the goals of the testing is to test "external behavior" >> > of the classes. >> > This means, to me, that the test cases must test the classes without >> > knowing if B inherits from A o if both B and C are subclasses of A. >> > This way, when you for some reason must refactor or reorganize your >> > classes, the test will not break as long as the external behavior of >> > them remains unchanged. >> > >> > Summary, the inheritance of the classes tested is just an implementation >> > detail, not something the test cases must care of. >> > >> > Cheers, >> > Miguel CobÃ¡ >> >> >> >> On Wed, Apr 29, 2009 at 4:46 PM, StÃ©phane Ducasse >> >> <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >> >> >> >> HI guys >> >> >> >> I was coding this afternoon with Cyrille who is working a lot to >> >> improve the test coverage of collections. >> >> And we found a bit strange that when a testcase inherits from >> another >> >> one the tests of the superclass are not run. >> >> I checked a bit SUnit code and superclass testmethods are only run >> is >> >> the superclass is abstract or if there are not testmethods. >> >> Imagine >> >> BagTest >> >> IdentityBagTest >> >> >> >> >> >> We could redefine buildSuite on BagTest to invoke allSelectors >> >> but this means in essence that we could do it on a lot of potential >> >> testcase classes that may be subclasses. >> >> >> >> Or we could redefine buildSuite on IdentyBagTest but this means >> that >> >> the subclasses should specify it. >> >> May be this solution is the best but I wanted to get your thoughts. >> >> >> >> Of course this idea of inheriting test case make sense when >> superclass >> >> setup can be reused in subclasses one. >> >> So the default behavior of buildSuite always invoking all >> testmethods >> >> may not be so good but then >> >> via subclassing from BagTest if this is not to reuse it. >> >> >> >> Stef >> >> >> >> >> >> On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: >> >> >> >> > A change have been saved in 'PharoInBox' for class TestCase in >> >> > package SUnit >> >> > so that suite are now built from allSelectors. >> >> > This makes sense when you have testcase classes which inherits >> from >> >> > each other and have parametrized (hook-based) setup. >> >> > >> >> > >> >> > _______________________________________________ >> >> > Pharo-project mailing list >> >> > Pharo-project(a)lists.gforge.inria.fr >> >> <mailto:Pharo-project@lists.gforge.inria.fr> >> >> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> <mailto:Pharo-project@lists.gforge.inria.fr> >> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

April 30, 2009

Re: [Pharo-project] [ANN] A new scheduler + VM changes alpha-release

by Igor Stasenko

2009/4/30 Igor Stasenko <siguctua(a)gmail.com>: > Here the Pharo benchs > > 100 "processes" benchSwitch: 5. "seconds" > > 1) "No changes to Processor" > '2,520,509 switches/sec' > '2,520,590 switches/sec' > '2,413,224 switches/sec' > > 2) "After changes to Processor, but using old VM primitives" > '1,106,806 switches/sec' > '1,110,870 switches/sec' > '1,116,981 switches/sec' > '1,204,289 switches/sec' > > "After installing new Processor" > > '152,779 switches/sec' > '150,913 switches/sec' > '152,608 switches/sec' > '153,844 switches/sec' > > Its interesting that transition from 1) to 2) > which just increasing a send chain to get to primitive, like: > What's even more interesting that i added a bench: AdvancedProcessorScheduler>>bench: seconds | proc count | count := 0. proc := [ [ Processor interruptWith: [count := count + 1] ] repeat ] forkAt: Processor activePriority -1. (Delay forSeconds: seconds) wait. proc terminate. ^(count value // seconds) asStringWithCommas, ' switches/sec' And it shows following results: Processor bench: 5 '1,039,398 switches/sec' '1,060,727 switches/sec' '1,083,370 switches/sec' As you can see, a scheduler loop alone is quite performant and nearly matching the speed of VM based scheduler. Which makes me wonder why semaphore signal/wait causes so much speed degradation... Looks like it does looping where it shouldn't. Need to inspect it more closely. :) > Semaphore>>wait >> primitive > Semaphore>>wait >> > Processor>>waitForSemaphore:>>Semaphore>>primitiveWait>>primitive > > downgrades a bench numbers by more than a 2x factor. > > 2009/4/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: -- Best regards, Igor Stasenko AKA sig.

April 30, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Nicolas Cellier

With a simpler command, I reproduced the MC failure, but not the bunch of opened change log: 1) ScriptLoader new installingInstaller 2) Installer lukas install: 'OB-Regex'. I get this interesting message on the XTerm console: getaddrinfo: Name or service not known 2009/4/30 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Very strange... > After a while on linux, I have an error in MCHttpRepository>>#allFileNames > > 'Could not resolve the server named: source.lukas-renggli.ch' > > while executing: > > instClass lukas > install: 'OB-Regex'; > > the 6 opened fd turned into many ... all pointing to the change file > Pharo0.1Core-10281cl.changes > > ls -l /proc/7932/fd | wc -l > 577 > > ls -l /proc/7932/fd | sort -n -k 8 | head -20 | grep -v '^total' > lrwx------ 1 nicolas parents 64 2009-04-30 23:03 0 -> /dev/pts/3 > lrwx------ 1 nicolas parents 64 2009-04-30 23:03 1 -> /dev/pts/3 > lrwx------ 1 nicolas parents 64 2009-04-30 23:03 2 -> /dev/pts/3 > lrwx------ 1 nicolas parents 64 2009-04-30 23:03 3 -> socket:[19987] > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 4 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/package-cache/ > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 5 -> > /windata/Smalltalk/Squeak/SqueakV39.sources* > lrwx------ 1 nicolas parents 64 2009-04-30 23:03 6 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 7 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 8 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 9 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 10 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 11 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 12 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 13 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 14 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 15 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 16 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 17 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > lr-x------ 1 nicolas parents 64 2009-04-30 23:03 18 -> > /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* > etc... > > Trying to restart, i have > serverAdress 84.75.162.243(84-75-162-243.dclient.hispeed.ch),0(0) > which I cannot ping outside squeak... > So maybe squeak has correct diagnostic, but why all these opened change logs ? > > Nicolas > > 2009/4/30 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >> So is that in the exception block before you get the walkback on the >> socket allocation failure? >> >> On 30-Apr-09, at 8:45 AM, Cameron Sanders wrote: >> >>> Well, "Socket allInstances size inspect" is giving me numbers like 8, >>> 6, or 2 from the "ScriptLoader loadOBAlpha" do-it. When I look at the >>> process on the Mac (with the activity monitor), it says I have "Ports: >>> 91". A look at "open files and ports" shows a lengthy list of >>> filenames/devices that are open, but only about 35 show up. There are >>> a few surprises (to me) in the open files list: >>> >> >> -- >> = >> = >> = >> ======================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> ======================================================================== >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

April 30, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Nicolas Cellier

Very strange... After a while on linux, I have an error in MCHttpRepository>>#allFileNames 'Could not resolve the server named: source.lukas-renggli.ch' while executing: instClass lukas install: 'OB-Regex'; the 6 opened fd turned into many ... all pointing to the change file Pharo0.1Core-10281cl.changes ls -l /proc/7932/fd | wc -l 577 ls -l /proc/7932/fd | sort -n -k 8 | head -20 | grep -v '^total' lrwx------ 1 nicolas parents 64 2009-04-30 23:03 0 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 1 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 2 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 3 -> socket:[19987] lr-x------ 1 nicolas parents 64 2009-04-30 23:03 4 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/package-cache/ lr-x------ 1 nicolas parents 64 2009-04-30 23:03 5 -> /windata/Smalltalk/Squeak/SqueakV39.sources* lrwx------ 1 nicolas parents 64 2009-04-30 23:03 6 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 7 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 8 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 9 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 10 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 11 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 12 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 13 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 14 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 15 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 16 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 17 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 18 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* etc... Trying to restart, i have serverAdress 84.75.162.243(84-75-162-243.dclient.hispeed.ch),0(0) which I cannot ping outside squeak... So maybe squeak has correct diagnostic, but why all these opened change logs ? Nicolas 2009/4/30 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > So is that in the exception block before you get the walkback on the > socket allocation failure? > > On 30-Apr-09, at 8:45 AM, Cameron Sanders wrote: > >> Well, "Socket allInstances size inspect" is giving me numbers like 8, >> 6, or 2 from the "ScriptLoader loadOBAlpha" do-it. When I look at the >> process on the Mac (with the activity monitor), it says I have "Ports: >> 91". A look at "open files and ports" shows a lengthy list of >> filenames/devices that are open, but only about 35 show up. There are >> a few surprises (to me) in the open files list: >> > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 30, 2009

Re: [Pharo-project] Loading VMMaker into latest Pharo

by Igor Stasenko

2009/4/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > >> There are multiple issues, when loading VMMaker into closure-aware >> image (10292). >> >> two #needsToRegenerateInterpreterFile methods >> storing into block args. Fix is easy and quick. >> >> But what to do with this?? >> >> Compiler reporting 'stack including temps is too deep'. >> >> GeniePlugin>>primSameClassAbsoluteStrokeDistanceMyPoints: myPointsOop >> otherPoints: otherPointsOop myVectors: myVectorsOop otherVectors: >> otherVectorsOop mySquaredLengths: mySquaredLengthsOop >> otherSquaredLengths: otherSquaredLengthsOop myAngles: myAnglesOop >> otherAngles: otherAnglesOop maxSizeAndReferenceFlag: maxSizeAndRefFlag >> rowBase: rowBaseOop rowInsertRemove: rowInsertRemoveOop >> rowInsertRemoveCount: rowInsertRemoveCountOop > > indeed you really see why nathanael turned it into a primitive :) > i value my brain cells too much, to avoid attempt to understand what it does :) > >> (yes, this is a method's message pattern) :) >> >> i stopped trying to load VMMaker at this method. >> >> It would be nice to have VMMaker loaded in image+closures running >> under VM+closures :) > > yes >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 30, 2009

Re: [Pharo-project] [ANN] A new scheduler + VM changes alpha-release

by Igor Stasenko

Here the Pharo benchs 100 "processes" benchSwitch: 5. "seconds" 1) "No changes to Processor" '2,520,509 switches/sec' '2,520,590 switches/sec' '2,413,224 switches/sec' 2) "After changes to Processor, but using old VM primitives" '1,106,806 switches/sec' '1,110,870 switches/sec' '1,116,981 switches/sec' '1,204,289 switches/sec' "After installing new Processor" '152,779 switches/sec' '150,913 switches/sec' '152,608 switches/sec' '153,844 switches/sec' Its interesting that transition from 1) to 2) which just increasing a send chain to get to primitive, like: Semaphore>>wait >> primitive Semaphore>>wait >> Processor>>waitForSemaphore:>>Semaphore>>primitiveWait>>primitive downgrades a bench numbers by more than a 2x factor. 2009/4/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I think that this is a good idea to see how such parts of Ssqueak/ > pharo can be improved in the future. > > > On Apr 30, 2009, at 4:15 PM, Igor Stasenko wrote: > >> A quick comparion for Delays: >> >> Â Â Â delay := Delay forMilliseconds: 1. >> Â Â Â bag := Bag new. >> Â Â Â 1000 timesRepeat:[bag add: [delay wait] timeToRun]. >> Â Â Â bag sortedCounts >> >> on my 4-core box it yields: >> >> - with AdvancedProcessorScheduler install >> Â a SortedCollection(951->2 49->1) >> >> - with Processor fallbackToOldScheduler >> a SortedCollection(953->2 47->1) >> >> - with old VM >> Â a SortedCollection(952->2 47->1 1->3) >> >> not much overhead huh? :) >> >> But Delay's code now can be refactored, which will simplify it >> seriously, because it could run in interrupt process and take no care >> for concurrency issues. >> >> >> >> 2009/4/30 Igor Stasenko <siguctua(a)gmail.com>: >>> i added a new changeset in mantis which deals with callbackEnter: >>> code. >>> Unfortunately, a callback handling , to work correctly needs an >>> image-side changes as well. >>> >>> P.S. Having fun to watch how scheduler handling signals, by >>> inspecting >>> Process and selecting its 'signals' ivar :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 30, 2009

Re: [Pharo-project] Loading VMMaker into latest Pharo

by StÃ©phane Ducasse

> There are multiple issues, when loading VMMaker into closure-aware > image (10292). > > two #needsToRegenerateInterpreterFile methods > storing into block args. Fix is easy and quick. > > But what to do with this?? > > Compiler reporting 'stack including temps is too deep'. > > GeniePlugin>>primSameClassAbsoluteStrokeDistanceMyPoints: myPointsOop > otherPoints: otherPointsOop myVectors: myVectorsOop otherVectors: > otherVectorsOop mySquaredLengths: mySquaredLengthsOop > otherSquaredLengths: otherSquaredLengthsOop myAngles: myAnglesOop > otherAngles: otherAnglesOop maxSizeAndReferenceFlag: maxSizeAndRefFlag > rowBase: rowBaseOop rowInsertRemove: rowInsertRemoveOop > rowInsertRemoveCount: rowInsertRemoveCountOop indeed you really see why nathanael turned it into a primitive :) > (yes, this is a method's message pattern) :) > > i stopped trying to load VMMaker at this method. > > It would be nice to have VMMaker loaded in image+closures running > under VM+closures :) yes > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 30, 2009

Re: [Pharo-project] [ANN] A new scheduler + VM changes alpha-release

by StÃ©phane Ducasse

I think that this is a good idea to see how such parts of Ssqueak/ pharo can be improved in the future. On Apr 30, 2009, at 4:15 PM, Igor Stasenko wrote: > A quick comparion for Delays: > > delay := Delay forMilliseconds: 1. > bag := Bag new. > 1000 timesRepeat:[bag add: [delay wait] timeToRun]. > bag sortedCounts > > on my 4-core box it yields: > > - with AdvancedProcessorScheduler install > a SortedCollection(951->2 49->1) > > - with Processor fallbackToOldScheduler > a SortedCollection(953->2 47->1) > > - with old VM > a SortedCollection(952->2 47->1 1->3) > > not much overhead huh? :) > > But Delay's code now can be refactored, which will simplify it > seriously, because it could run in interrupt process and take no care > for concurrency issues. > > > > 2009/4/30 Igor Stasenko <siguctua(a)gmail.com>: >> i added a new changeset in mantis which deals with callbackEnter: >> code. >> Unfortunately, a callback handling , to work correctly needs an >> image-side changes as well. >> >> P.S. Having fun to watch how scheduler handling signals, by >> inspecting >> Process and selecting its 'signals' ivar :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 30, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by John M McIntosh

So is that in the exception block before you get the walkback on the socket allocation failure? On 30-Apr-09, at 8:45 AM, Cameron Sanders wrote: > Well, "Socket allInstances size inspect" is giving me numbers like 8, > 6, or 2 from the "ScriptLoader loadOBAlpha" do-it. When I look at the > process on the Mac (with the activity monitor), it says I have "Ports: > 91". A look at "open files and ports" shows a lengthy list of > filenames/devices that are open, but only about 35 show up. There are > a few surprises (to me) in the open files list: > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 30, 2009