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

Re: [Pharo-dev] [pharo-project/pharo-core] ba3c45: 30606

by Sean P. DeNigris

GitHub wrote > [snip] > Changed paths: > A Komitter.package/BigCogInitialState.class/README.md > A Komitter.package/BigCogInitialState.class/class/private/imageData.st > A Komitter.package/BigCogInitialState.class/class/private/size.st > [reaaaaaaaaaally long snip] > > Log Message: > ----------- > 30606 > 12209 RPackage initialization dependent on Monticello > https://pharo.fogbugz.com/f/cases/12209 > ... Are these messages configurable? If so, where is the code? I'd like the log message to be at the top, and think the links should be Penelope links to make them useful to non-core-developers... ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-ba3c45-30606-tp4725955p47262… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 29, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 29, 2013

[pharo-project/pharo-core] 132647: 30611

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 1326478be99209005a27e7daf8ee586c724c8811 https://github.com/pharo-project/pharo-core/commit/1326478be99209005a27e7da… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-29 (Fri, 29 Nov 2013) Changed paths: A Nautilus.package/PackageTreeGroupSelection.class/instance/testing/isReadOnly.st A Nautilus.package/PackageTreeGroupSelection.class/instance/testing/removable.st M Nautilus.package/PackageTreeModel.class/instance/drag and drop/acceptDroppingMorph_event_inMorph_.st M NautilusCommon.package/extension/CompiledMethod/instance/isTestMethod.st M NautilusCommon.package/extension/RGMethodDefinition/instance/isTestMethod.st A NautilusCommon.package/extension/RGMethodDefinition/instance/numArgs.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script266.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30611.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30611 12288 groups menu in PackageTree is broken https://pharo.fogbugz.com/f/cases/12288 12283 drag&drop with PackageTree is not working fine https://pharo.fogbugz.com/f/cases/12283 12280 Nautilus treats should: messages as tests and tries to run them https://pharo.fogbugz.com/f/cases/12280 http://files.pharo.org/image/30/30611.zip

Nov. 29, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 29, 2013

[pharo-project/pharo-core] 92e0c6: 30610

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 92e0c6ff83cad3e57ce0c2ead6f10430c8b14a65 https://github.com/pharo-project/pharo-core/commit/92e0c6ff83cad3e57ce0c2ea… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-29 (Fri, 29 Nov 2013) Changed paths: M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/visitor/visitSequenceNode_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script265.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30610.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/TreeModel.class/instance/protocol/menu_shifted_.st M Spec-MorphicAdapters.package/MorphicTreeAdapter.class/instance/widget API/menu_shifted_.st Log Message: ----------- 30610 12276 Remove not needed ifNotNil: check in OCASTSemanticAnalyzer>>visitSequenceNode: https://pharo.fogbugz.com/f/cases/12276 12286 TreeInspector menus do not work https://pharo.fogbugz.com/f/cases/12286 http://files.pharo.org/image/30/30610.zip

Nov. 29, 2013

Re: [Pharo-dev] Bug font windows

by Tudor Girba

Hi, On Thu, Nov 28, 2013 at 11:15 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 27 November 2013 21:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > >> >> On Nov 27, 2013, at 9:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> That is what I wanted to ask: How you built the image. Ok. I will try to >> open a Pharo image built on Mac on a Windows machine and see what happens. >> >> >> I gave to the guys a image of moose with the lucene case study loaded and >> it opened well the first time. >> After saving on windows (often they use moose from their USB) then we >> could not reopen it. >> >> Stef >> >> According to stack trace, it uses in-image font.. so it should be not > related to > local filesystem change.. and need to rescan fonts. > Exactly, it should not be related to fonts in the Moose image given that the fonts are in the image. Another thought, it could be that > newFaceFromExternalMemory:index: > fails somehow .. (maybe freetype plugin unavail?) > I tried to reproduce the problem locally, but I cannot. So, my feeling also goes towards the VM. Could they try with the latest Win VM? Cheers, Doru > > > -- > Best regards, > Igor Stasenko. > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 29, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 29, 2013

[pharo-project/pharo-core] 727a4b: 30609

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 727a4b0a9f1ee6b9ea453e67e9e035c8020f41d0 https://github.com/pharo-project/pharo-core/commit/727a4b0a9f1ee6b9ea453e67… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-29 (Fri, 29 Nov 2013) Changed paths: A RPackage-Core.package/RPackageTag.class/instance/testing/includesMethodCategory_ofClass_.st A RPackage-Core.package/RPackageTag.class/instance/testing/includesSelector_ofClass_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script264.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30609.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeTreeInspector.class/instance/accessing/selectedElement.st M System-Settings.package/SettingNode.class/instance/accessing/inputMorphFor_.st Log Message: ----------- 30609 12266 EyeTreeInspector inspect element opens on TreeNodeModel https://pharo.fogbugz.com/f/cases/12266 12185 Settings Browser does not show proper top-level help text https://pharo.fogbugz.com/f/cases/12185 12282 scoped browsing broken with new PackageTree https://pharo.fogbugz.com/f/cases/12282 http://files.pharo.org/image/30/30609.zip

Nov. 29, 2013

Stepping through with GLORP Proxies

by Esteban A. Maringolo

Does anybody else have issues while stepping through GLORP Proxy objects (collections in this case)? I simply can't use this feature unless the proxied collection was already materialized. I can't reproduce it right now, but it bites me everytime is step through blocks, because stepping into is really annoying :) Does anybody else have the same issue? This is Pharo 2. Esteban A. Maringolo

Nov. 29, 2013

Re: [Pharo-dev] Stopping Zinc

by Sven Van Caekenberghe

On 29 Nov 2013, at 14:25, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Did a test now and looks good. OK > But using closeAndDestroy: 0 when stopping the websocket handler collects things a lot sooner It is called a graceful shutdown and is apparently the default for SocketStream>>#close since 2005. But I agree that it might make sense to think about doing it a lot faster ;-) Maybe we can rephrase the question: why is there such a long timeout there ? Anyone ? > thanks for the tip Sven! Youâre welcome. > On Nov 29, 2013, at 10:37 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 29 Nov 2013, at 13:31, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> >>> I've just find out that closing chrome before stopping Zinc leaves everything clean. >>> >>> The funny thing is that Zinc is closing the sockets on stop.. >>> >>> I mean, if they are properly killed, one wouldn't expect them to cause the hold of any thread even if web browser tries to keep open connections. >>> >>> mmm >> >> Did you try waiting 20 or 30 seconds ? >> >> SocketStream>>#close ends up doing a Socket>>#closeAndDestroy: with argument 30 seconds, while ZdcSocketStream>>#close ends up doing a Socket>>#closeAndDestroy: with argument 20 seconds. Before that timeout, they only close their end and are waiting for the other end to close. After the timeout, there is a hard destroy. >> >>> On Nov 28, 2013, at 3:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>> On 28 Nov 2013, at 17:35, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>>> >>>>> This is how I start Zinc >>>>> >>>>> (ZnServer startDefaultOn: self port) >>>>> delegate: self makeDispatcher; >>>>> register; >>>>> yourself >>>> >>>> the #register is too much (the default server is registered automatically), the server will be added twice to #managedServers which leads to the same instance being stopped/started twice, which probably does no harm, but it should not be done. >>>> >>>>> and that screenshot was taken after >>>>> 1. starting Zinc >>>> >>>> OK, see remark above. >>>> >>>>> 2. using a little the app (which has a custom dispatcher that has a couple of handlers, one is a websocket handler) >>>> >>>> There might of course be some error in your code ;-) >>>> A repeatable bug report requires no use of custom code. >>>> >>>>> 3. stopping with the code you see in the workspace >>>> >>>> If you start like you do above, just ZnServer stopDefault is enough. >>>> >>>>> 4. also this: 5 timesRepeat:[Smalltalk garbageCollect]. >>>> >>>> Yeah, that is a good idea, typically you should also wait at least the connection time out time (30s by default). >>>> >>>>> so I typically have to go manually to cmd-t those processes hanging there >>>> >>>> Please try to say #logToTranscript to your server, it will report many details of connections opening/closing, with a special tag to identify each thread. >>>> >>>>> <Screen Shot 2013-11-28 at 2.29.31 PM.png> >>>> >>>> I see you are on the latest Mac OS X 10.9, using #20625, this definitively should work. >>>> >>>> If I have time later tonight, I will try to run a similar scenario. >>>> >>>> Note that running the unit tests creates many, many servers and afterwards everything cleans up. >>>> >>>>> On Nov 28, 2013, at 2:21 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>>> >>>>>> On 28 Nov 2013, at 17:13, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>>>>> >>>>>>> sure.. >>>>>>> >>>>>>> Of course the inconvenience is not in saving the image with processes hanging around but in opening it in an unusable state >>>>>>> >>>>>>> Building fresh ones for production is great but for development is too impractical >>>>>>> >>>>>>> =/ >>>>>> >>>>>> If your server is managed (by being the default one, or being registered explicitly) it will be stopped on image save and started again when the image comes up. If that should fail, please try to give a repeatable bug report, using a standard image only. >>>>>> >>>>>> Alternatively, stopping the servers manually should work as well. If that should fail, that is a bug too. >>>>>> >>>>>> What platform are you on, what Pharo version, latest Zinc ? >>>>>> >>>>>>> On Nov 28, 2013, at 12:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>> >>>>>>>> Hi Sebastian, >>>>>>>> >>>>>>>> CC-ing to the mailing list because this is generally useful. >>>>>>>> >>>>>>>> On 28 Nov 2013, at 14:11, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>>>>>>> >>>>>>>>> Hi Sven, >>>>>>>>> >>>>>>>>> how are you? all good over there? >>>>>>>>> >>>>>>>>> quick question: >>>>>>>>> >>>>>>>>> should this be enough to stop Zinc? >>>>>>>>> >>>>>>>>> ZnServer managedServers do:[:e| e stop]. >>>>>>>>> >>>>>>>>> ZnServer default ifNotNil:[ >>>>>>>>> ZnServer default delegate stop]. >>>>>>>>> >>>>>>>>> ZnServer stopDefault. >>>>>>>>> >>>>>>>>> I ask because after using it for a while the image still have processes ZnManagingMultiThreadedServer related >>>>>>>>> >>>>>>>>> Do you have some kind of best practice to shut it down? >>>>>>>>> >>>>>>>>> sebastian >>>>>>>>> >>>>>>>>> o/ >>>>>>>>> >>>>>>>>> PS: The typical case is that you are developing and you make some changes and want to save the image clean (without anything but the default processes) >>>>>>>>> >>>>>>>>> Now I'm manually terminating some after stopping all (using that code up there) because if I don't do that I have ~50% chances to save an image that will open absolutely frozen (forcing me to go back one commit and reload some packages) >>>>>>>> >>>>>>>> Once you get started with Zinc there is no stopping it ;-) >>>>>>>> >>>>>>>> The default server (#startDefaultOn: and #defaultOn:) gets registered automatically. Registered servers get stopped on image shutdown and get restarted on image startup. There can only be one default server. >>>>>>>> >>>>>>>> Servers created otherwise (#on: #startOn:) do not get registered automatically. You have to do that explicitly using #register. Then theyâll get the behaviour described above. >>>>>>>> >>>>>>>> The default server class is ZnManagingMultiThreadedServer which will close its open connections when stopping. However, the HTTP worker processes (one per open connection) do not get terminated explicitly. This will happen when their main loop notices the connection is gone (by receiving an error, typically a ConnectionTimedOut or PrimitiveFailure on reading the next incoming request), after which they will clean up and terminate naturally. >>>>>>>> >>>>>>>> This is the theory, there are some platform differences (Mac, Windows, Linux). On Mac I never have trouble with managed server hanging in my development image, but YMMV. >>>>>>>> >>>>>>>> Now, my best practice advice for deployment is to use cleanly built images (very easy to do using the ZeroConf âconfig' handler that loads your Metacello Configuration) and then start your servers in your startup script (where you can do all other configurations, like setting ports, username/passwords, other hosts). Then use some monitoring tool like monit to check on the server(s) and kill/restart when needed. >>>>>>>> >>>>>>>> HTH, >>>>>>>> >>>>>>>> Sven >>>>>>>> >>>>>>>> PS: The following introduction article explains the deploy mechanism that I prefer (in simple terms): http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/ >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

Nov. 29, 2013