November 2014 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 27bfd3: 40351

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 27bfd36879b17e6012f9eeffd702073842607d7b https://github.com/pharo-project/pharo-core/commit/27bfd36879b17e6012f9eeff… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-03 (Mon, 03 Nov 2014) Changed paths: M Kernel.package/CompiledMethod.class/instance/comparing/sameLiteralsAs_.st M Manifest-Tests.package/SmalllintManifestCheckerTest.class/instance/running/tearDown.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script351.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40351.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/AbstractApiSetter.class/instance/initialize/setValueTo_.st M Spec-Tools.package/AbstractApiSetter.class/instance/protocol/updateWith_.st M Spec-Tools.package/ChangeSorterApplication.class/instance/menu/changeSetMenu_shifted_.st M Spec-Tools.package/ChangeSorterApplication.class/instance/menu/classMenu_shifted_.st M Spec-Tools.package/ChangeSorterApplication.class/instance/menu/messageMenu_shifted_.st M Spec-Tools.package/ConfigurationGenerator.class/instance/metacello/addMetacelloBaseline.st M Spec-Tools.package/ConfigurationGenerator.class/instance/metacello/createVersionForBlessing_.st M Spec-Tools.package/ConfigurationGenerator.class/instance/metacello/dependentPackages.st M Spec-Tools.package/DiffChangeRecordConverter.class/definition.st M Spec-Tools.package/DiffChangeRecordConverter.class/instance/private/priorVersionOfAMethod_.st M Spec-Tools.package/DiffMorphChangeRecordConverter.class/definition.st M Spec-Tools.package/DualChangeSorterApplication.class/instance/event/refeshedChangeSet_.st M Spec-Tools.package/DualChangeSorterApplication.class/instance/menu - change set/checkThatSidesDiffer_.st M Spec-Tools.package/DualChangeSorterApplication.class/instance/menu - class/moveClassFrom_to_.st M Spec-Tools.package/DualChangeSorterApplication.class/instance/menu/changesMenu_shifted_from_to_.st M Spec-Tools.package/MessageBrowser.class/definition.st M Spec-Tools.package/MessageBrowser.class/instance/initialization/initialize.st R Spec-Tools.package/MessageBrowser.class/instance/protocol/title_.st M Spec-Tools.package/MessageBrowser.class/instance/testing/sortClassesInCachedHierarchy_b_.st M Spec-Tools.package/MessageBrowser.class/instance/text selection/searchedString_in_.st M Spec-Tools.package/NewVersionBrowser.class/definition.st M Spec-Tools.package/NewVersionBrowser.class/instance/menu/compareToOtherVersion.st M Spec-Tools.package/WorkingCopyToolBar.class/definition.st R Spec-Tools.package/WorkingCopyToolBar.class/instance/initialization/initialize.st M Spec-Tools.package/WorkingCopyToolBar.class/instance/initialize/createPackage.st M Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/instance/running/tearDown.st Log Message: ----------- 40351 14246 CompiledMethod>>hash can produce clashes https://pharo.fogbugz.com/f/cases/14246 14379 Code critique pass Spec-Tools https://pharo.fogbugz.com/f/cases/14379 14375 Random #obsoleteClasses test failures https://pharo.fogbugz.com/f/cases/14375 http://files.pharo.org/image/40/40351.zip

Nov. 3, 2014

Re: [Pharo-dev] ImageCleaner interaction with Delay

by Marcus Denker

> On 02 Nov 2014, at 19:19, Ben Coman <btc(a)openInWorld.com> wrote: > > > ImageCleaner>>cleanUpForRelease calls >>cleanUpMethods which calls > Delay class>>startTimerEventLoop. I thought this would have started with a clean/empty suspended delays heap, but it carries forward > the old SuspendedDelays. > > So if there happened to be a suspended delay expiring in a month's time, > that would not be affected by ImageCleaner and would end up in the release. > > I believe the correct behaviour would be for ImageCleaner to produce a clean/empty suspended delays, and so that no waiting processing get stuck, signal any remaining suspended delays when the timer event loop is stopped by Delay class>>stopTimerEventLoop. > > Any objections? > No, sounds good. #cleanUpMethods is supposed to re-start all methods that hold on to existing blocks, so that the compiled methods they hold on to get GCed. (e.g. very important when compiler changes are done to not have old methods around). At some point I added it to the #cleanUpForRelease as it does not hurtâ¦ (and #cleanUpForRelease we all after every update as the final goal is to have the CI build be the release artefact unchannged) Marcus

Nov. 3, 2014

Re: [Pharo-dev] Failing #obsoleteClasses test

by Marcus Denker

> On 02 Nov 2014, at 19:39, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 02.11.2014, at 18:28, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Max, >> >> could the cache be reimplemented using WeakArray? Stuff like this is a drag. eg in Squeak the Windows menu holds onto all the windows that were open when last the menu was opened. So to get a window reclaimed after being closed if you opened the Windows menu you have to open it again. I must fix that. > > No idea. I really didnât look at what it does, I just tracked pointers ;) > > But yes, maybe that would be a good idea. Adding âASTCache reset.â all over the place is not really a good strategy. > > Iâll send a copy of this message to Marcus and ClÃ©ment; I suspect they might know more about the AST stuff. > Yesâ¦ I am not happy with the AST cache as it is now. for one, yes, it might hold on to things. And it can get large. So we definitely need to have a look. (I am actually amazed how well it works till nowâ¦ ;-) ). Marcus

Nov. 3, 2014

Re: [Pharo-dev] VersionnerRepositoriesManager - Why clear okAction?

by Sean P. DeNigris

demarey wrote > Maybe what you need is RemotesManager. I extracted this component from > Komitter. Thanks for the reply! Yes, I ended up using RemotesManager. ----- Cheers, Sean -- View this message in context: http://forum.world.st/VersionnerRepositoriesManager-Why-clear-okAction-tp47… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 3, 2014

Re: [Pharo-dev] [Vm-dev] Re: Super fast delay

by Ben Coman

Eliot Miranda wrote: > > Hi Ben, > > On Nov 2, 2014, at 6:06 AM, Ben Coman <btc(a)openInWorld.com> wrote: > >> Eliot Miranda wrote: >>> On Wed, Oct 29, 2014 at 12:14 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> Holger Hans Peter Freyther wrote: >>> On Wed, Oct 29, 2014 at 06:54:57PM +0100, Holger Hans Peter >>> Freyther wrote: >>> On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote: >>> Good Evening, >>> Hi again, >>> I don't know how you debug startUp issues. I just added an >>> OrderedCollection >>> into the systemdictionary and use it as a log.. >>> time ./bin/pharo --nodisplay ./TimerTest3.image eval "(Delay >>> forSeconds: 3) wait. (Smalltalk at: #Foo) do: [:each | >>> FileStream stderr nextPutAll: each printString; cr].1" >>> ... old events from saving the image... >>> {#handleTimerEvent->7147} >>> {#handleTimerEvent->7167} >>> {#resumptionTime->7187} >>> {#handleTimerEvent->7167} >>> {#handleTimerEvent->7187} >>> {#start->true} >>> {#start->393102159} >>> {#start->393102159} >>> {#resumptionTime->3279} >>> {#handleTimerEvent->279} >>> {#adjustResum->-393098880} >>> {#restoreWithActiveDelay->266} >>> {#adjustResum->-393098601} >>> 1 >>> real 0m0.294s >>> user 0m0.244s >>> sys 0m0.048s >>> So what happens is Delay class>>#startU is called. and >>> ActiveDelayStartTime is being set to 393102159. Then the >>> delay is being created and resumptionTime is set to 3279. >>> At the first time handleTimerEvent runs the milliSecondClock >>> jumped backwards from 393102159 to 3279 which leads to >>> an adjustment of the time. >>> a.) Why does the time jump backwards like this during the >>> resumption of the image? "3279" is not the old time nor >>> the new starting time. >>> b.) So even if that is a "wrap" around. Why does it go >>> wrong? Are there unit tests for the clock wraps around? >>> There are no unit tests, I guess since its all done using class >>> variables its too hard test without disturbing the system. >>> Now I have spent the last week refactoring this out to the >>> instance-side of a new class "DelayScheduler" which should help with >>> getting unit tests. Its ready for review [1], maybe you could take >>> a look. >>> [1] https://pharo.fogbugz.com/__default.asp?14261 >>> <https://pharo.fogbugz.com/default.asp?14261> >>> Maybe it is the same reason delays just don't work after >>> image resumption? >>> The "first" issue appears that when start is being executed >>> that the clock is still wrong. At the same the clock is >>> being considered wrapped the resumption time was actually >>> already "correct' (3279 instead of 393102159+3279). >>> Does this ring a bell? >>> holger >>> btw, its too late in the night for me to try something, but I have >>> been wondering, should the check for clock roll-over occur >>> immediately after >>> TimingSemaphore wait >>> wakes up. That is, before the Schedule and Finish requests are >>> handled ??? >>> The check for rollover should be thrown away and the system implemented over the VM's support for 64-bit microseconds since 1901. It's in the VM, it isn't susceptible to rollover for ~ 50,000 years, and doesn't require the millisecond clock to be synced to the second clock, because all times can be derived from the one 64-bit microsecond clock. >>> -- >>> best, >>> Eliot >> The performance of the Delay timer event loop is noted in the code to be critical, however... >> >> "Time millisecondClockValue" returns a SmallInteger, which is an immediate object while "Time microsecondClockValue" returns a LargePositiveInteger, which is not. >> >> So theoretically will calculations and comparisons based on the second be slower ? Actually my performance testing so far hasn't found it to be slower, but I am interested in the general case. > > That comment was written when the context interpreter VM was the standard. Cog is much faster. That should more than make up for the small amount of large integer arithmetic the use of 64-bit microseconds involves. And once we switch to 64-bit Spur the 64-bit microsecond clock will once again be a SmalInteger. And if your measurements show you there isn't an issue then there isn't an issue. > Cool. Thanks for the info.

Nov. 3, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40350 Home: https://github.com/pharo-project/pharo-core

Nov. 3, 2014

[pharo-project/pharo-core] c5ed9d: 40350

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: c5ed9d14cec80d2fc6531709abdcd7ec442b887f https://github.com/pharo-project/pharo-core/commit/c5ed9d14cec80d2fc6531709… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-03 (Mon, 03 Nov 2014) Changed paths: M Kernel.package/ClassOrganization.class/instance/backward compatibility - file in%2Fout/putCommentOnFile_numbered_moveSource_forClass_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script350.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40350.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Changes.package/ChangeSet.class/class/current changeset/newChanges_withOld_.st M System-Support.package/ChangesLog.class/instance/event-listening/registerToAnnouncements.st Log Message: ----------- 40350 14373 Replace Announcer>>#on:send:to:s senders in System-Support https://pharo.fogbugz.com/f/cases/14373 14372 Replace Announcer>>#on:send:to:s senders in System-Changes https://pharo.fogbugz.com/f/cases/14372 14377 FileOut creates invalid comment entries for classes with class side methods https://pharo.fogbugz.com/f/cases/14377 http://files.pharo.org/image/40/40350.zip

Nov. 3, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

Oh, I see, I will try later, have to go for now. Thank you so much :) Le 03/11/2014 02:12, Igor Stasenko a Ã©crit : > NBExternalArray instances cannot be passed directly to functions > expecting pointers. > > use 'myarray address' for arguments. > > On 3 November 2014 00:20, Alain Rastoul > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> wrote: > > Hi, > > I have a problem with a nativeboost call, but I don't see what I do > wrong. > > library function prototype is: > int zmq_getsockopt (void *socket, int option_name, void > *option_value, size_t *option_len); > > my calling method in pharo is: > zmq_getsockopt: socket option_name: option_name option_value: > option_value option_len: option_len > <primitive: #primitiveNativeCall module: #NativeBoostPlugin > error: errorCode> > ^self nbCall: #(int zmq_getsockopt (void *socket, int > option_name, void * option_value, size_t* option_len) ) > > when I call it with > ... > optionValue := (NBExternalArray ofType: 'int') externalNew: 1. > optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1. > [ optionValue at: 1 put: 0 . > optionLen at: 1 put: (NBExternalType sizeOf: 'int') . > rc := self zmq_getsockopt: socket option_name: option_name > option_value: optionValue > option_len: optionLen . > value := optionValue at: 1 . > ] ensure: [ optionValue free. > optionLen free ]. > ... > I allways get an exception: "error during FFI call : nil" > > > After stepping in NBFFICallout generation, I found something > strange, the code > generation seems not to be called because lastError stays at nil ? > > handleFailureIn: aContext nativeCode: aBlock > lastError := self getErrorFrom: aContext lastError: > NativeBoost lastError. > > >>getErrorFrom: aContext lastError: errorCode > ... checks pragmas etc > >>getErrorFrom: aContext lastError: errorCode > ... lastError := aContext tempAt: method numTemps. > => lastError = nil ??? shouldn't be > ErrNoNativeCodeInMethod ? > "install native code and retry the send" > lastError = ErrNoNativeCodeInMethod > ifTrue: [ ^ self generateCode: aBlock andRetry: > aContext ]. > never gets called ... > > "ok, we're out of options, signal an error here" > ^ self signalError: lastError > > Could it be because I use this image on windows and unix ? > Or because I had an exception at prototype parsing the first time > because I forgot a ; at the end of the prototype ? > > Is my prototype correct or is it the origin of the error ? > Is there a way to reset the lastError (aContext tempAt: method > numTemps) ? > I will try to reset it in debugger but may be there is a cleaner way ? > would it be ok to change the test in handleFailure to > (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ? > (I can open a bug in this case ) > > Any idea or comment is welcome > Thanks in advance > > Alain > > > > > > -- > Best regards, > Igor Stasenko.

Nov. 3, 2014

New Cog VMs available

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3121/. CogVM binaries as per VMMaker.oscog-eem.918/r3121 This is for Spur: Fix bad bug in callPrimitiveBytecode. Old code skipped past next bytecode. This broke code depending on ContextPart>>restart, such as Exception>>retry. -- best, Eliot

Nov. 3, 2014

WhatsUp from: 2014-11-03 until: 2014-11-16

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-11-16 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Nov. 3, 2014