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

Re: [Pharo-dev] Stopping Zinc

by Sebastian Sastre

Did a test now and looks good. But using closeAndDestroy: 0 when stopping the websocket handler collects things a lot sooner thanks for the tip Sven! 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

Re: [Pharo-dev] Stopping Zinc

by Sven Van Caekenberghe

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

Re: [Pharo-dev] Stopping Zinc

by Sebastian Sastre

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 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

[pharo-project/pharo-core]

by GitHub

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

Nov. 29, 2013

[pharo-project/pharo-core] 4777ec: 30608

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 4777eca70d1404fec29ef0334a7fe1b362bd8c83 https://github.com/pharo-project/pharo-core/commit/4777eca70d1404fec29ef033… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-29 (Fri, 29 Nov 2013) Changed paths: M Network-Kernel.package/Socket.class/class/utilities/nameForWellKnownTCPPort_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script263.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30608.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-Network.package/NetworkSystemSettings.class/class/settings/isHttpProxyException_.st M Spec-Debugger.package/SpecPreDebugWindow.class/instance/building widgets/rebuildWidget.st M Spec-Debugger.package/SpecPreDebugWindow.class/instance/initialization/initialize.st Log Message: ----------- 30608 12271 Add keyboard focus on PreDebuggerWindow https://pharo.fogbugz.com/f/cases/12271 12277 Cleanup some Network methods https://pharo.fogbugz.com/f/cases/12277 http://files.pharo.org/image/30/30608.zip

Nov. 29, 2013

[pharo-project/pharo-core] d3315d: 30607

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: d3315d2c92d27d87ac3a8dc84c38db32607f02d4 https://github.com/pharo-project/pharo-core/commit/d3315d2c92d27d87ac3a8dc8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-29 (Fri, 29 Nov 2013) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/displaying/buildSecondColumn_.st M Nautilus.package/NautilusUI.class/instance/displaying/buildColumns_height_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/displaying/buildFirstColumn_.st M Regex-Core.package/RxsCharSet.class/instance/testing/isEnumerable.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script262.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30607.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Spec-MorphicAdapters.package/DefaultSpecTreeNode.class/README.md R Spec-MorphicAdapters.package/DefaultSpecTreeNode.class/definition.st R Spec-MorphicAdapters.package/DefaultSpecTreeNode.class/instance/accessing/childrenItems.st R Spec-MorphicAdapters.package/DefaultSpecTreeNode.class/instance/filtering/matchTokenFilter_.st R Spec-MorphicAdapters.package/FilteringTreeNode.class/README.md R Spec-MorphicAdapters.package/FilteringTreeNode.class/definition.st R Spec-MorphicAdapters.package/FilteringTreeNode.class/instance/as yet unclassified/contents.st R Spec-MorphicAdapters.package/FilteringTreeNode.class/instance/filtering/matchTokenFilter_.st R Spec-MorphicAdapters.package/FilteringTreeNode.class/instance/testing/isEmpty.st R Spec-MorphicAdapters.package/FilteringTreeNode.class/instance/updating/updateAccordingTo_.st A Spec-MorphicAdapters.package/MorphicContainerAdapter.class/instance/spec protocol/centerWidget_.st A Spec-MorphicAdapters.package/MorphicWindowAdapter.class/instance/protocol/centered.st A Spec-MorphicAdapters.package/MorphicWindowAdapter.class/instance/protocol/centeredRelativeTo_.st R Spec-MorphicAdapters.package/NameFilteringTreeNode.class/README.md R Spec-MorphicAdapters.package/NameFilteringTreeNode.class/definition.st R Spec-MorphicAdapters.package/NameFilteringTreeNode.class/instance/filtering/matchTokenFilter_.st Log Message: ----------- 30607 12269 Add support for easily centering a window https://pharo.fogbugz.com/f/cases/12269 12270 Remove unused TreeNode classes https://pharo.fogbugz.com/f/cases/12270 12275 RxsCharSet>>isEnumerable must be using anySatisfy https://pharo.fogbugz.com/f/cases/12275 12267 Nautilus Search Bar should not resize https://pharo.fogbugz.com/f/cases/12267 http://files.pharo.org/image/30/30607.zip

Nov. 29, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 29, 2013

Re: [Pharo-dev] Coordinates problem with Athens and Morphic while coding Hyperion

by Igor Stasenko

On 29 November 2013 09:42, kilon alios <kilon.alios(a)gmail.com> wrote: > please note that the button for inserting an image is different to the > button for attaching an image. Strange that it does not let you attach > files, maybe if you zip, but in any case why dont you make smalltalkhub > repo and publish the code there and give me the link to it ? > > because i don't publish every bit of experimental code i did , only less experimental :) another try, sent you files privately by normal attachment. > > On Fri, Nov 29, 2013 at 6:36 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 28 November 2013 22:49, kilon alios <kilon.alios(a)gmail.com> wrote: >> >>> well I could ask you to give me access to those files , that would be a >>> good start ;) >>> >>> I am so new to this google drive thing >>> >>> hehe.. me too.. apperently it doesn't wants to just attach files, >> and need multiple more clicks to enable weird sharing, like sending a >> copy is not >> good enough :) >> >> >>> >>> On Thu, Nov 28, 2013 at 10:08 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> >>>> BezierMorph.st.gz<https://docs.google.com/file/d/0B7dd-52sqS20SW9JMUxZREh1ZkJEc1UwZkNiYy1jbnZ…> >>>> >>>> Morphic-BezierCurve.st<https://docs.google.com/file/d/0B7dd-52sqS20LW5XV2NwaFpPeEJudFFGZ3ZsZFBxZC0…> >>>> >>>> On 28 November 2013 16:54, kilon alios <kilon.alios(a)gmail.com> wrote: >>>> >>>>> absolutely, more code mean deeper understanding how to be more >>>>> dangerous as a coder >>>>> >>>> >>>> here it is.. it took me some effort to find it, buried under piles of >>>> other things. >>>> i don't know which one is latest/working, and don't ask me how it works >>>> .. it was long ago i was young and sky was blue :) >>>> >>>> >>>> On Thu, Nov 28, 2013 at 4:16 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>> >>>>> >>>>> >>>>> >>>>> On 28 November 2013 13:52, kilon alios <kilon.alios(a)gmail.com> wrote: >>>>> >>>>>> thats all I got I am afraid right now. A simple editing of a straight >>>>>> line, but I am learning athens, roassal, morphic so it takes time. Its my >>>>>> first with everything and my very first project with pharo. I am not aiming >>>>>> for something super sophisticated, bezier lines, gradients, bitmaps etc >>>>>> simple stuff but I am having so much fun with this project I wont give up >>>>>> until I have it finished. :) >>>>>> >>>>>> >>>>> btw, if you want, i got somewhere code for Bezier curve editing (in >>>>> morphic).. >>>>> it is not fully working, but at least something you can look at: >>>>> - if i remember you can add control points and move them around. >>>>> >>>>> >>>>> >>>>>> >>>>>> On Thu, Nov 28, 2013 at 2:30 PM, Alexandre Bergel < >>>>>> alexandre.bergel(a)me.com> wrote: >>>>>> >>>>>>> Do you have more screenshots of Hyperion? >>>>>>> >>>>>>> Alexandre >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Nov 28, 2013, at 7:49 AM, kilon alios <kilon.alios(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> > Ok I have verified and indeed its not an Athens problem. My bad. >>>>>>> The position of the morph is reported at 5@30 and the not the >>>>>>> correct 0@0. So it looks like Morphic for some strange reason it >>>>>>> offsets it. >>>>>>> > >>>>>>> > I knew about translateBy but I did not know about restoreAfter. so >>>>>>> thank you. >>>>>>> > >>>>>>> > I prefer my version of the code because it makes clearer what I am >>>>>>> trying to do. However ideally because I am drawing a box inside another box >>>>>>> the best way would be to follow your approach and scale the second box >>>>>>> using one shape instead of two I am currently doing. But thats the price I >>>>>>> am paying from not knowing exactly how to do this. >>>>>>> > >>>>>>> > Also trying to painstakingly find the correct transform and scale >>>>>>> values requires A LOT of testing . This is why I find a vector editor for >>>>>>> Athens and Pharo absolutely essential. No coding can beat designing via >>>>>>> mouse. >>>>>>> > >>>>>>> > On the other hand I could use Inkscape and import the svg to >>>>>>> Athens , which what I am about to research. Designing all GUI elements by >>>>>>> code is a very bad idea, but no less a learning experience. >>>>>>> > >>>>>>> > I will most probably move to Roassal too. >>>>>>> > >>>>>>> > As always thanks for the help. >>>>>>> > >>>>>>> > >>>>>>> > On Thu, Nov 28, 2013 at 12:29 PM, Igor Stasenko < >>>>>>> siguctua(a)gmail.com> wrote: >>>>>>> > well, by default the athens canvas coordinate system matches >>>>>>> morphic one.. >>>>>>> > but you know, it always hard to be sure, especially if you perform >>>>>>> any local coordinate transformations before that morph has any chance to >>>>>>> draw itself.. >>>>>>> > >>>>>>> > You can figure this out easily: draw something at 0@0 and see >>>>>>> where it is. >>>>>>> > then draw something at morph's x@y position and see it too. >>>>>>> > >>>>>>> > btw, you know you don't have to create same paths over and over. >>>>>>> > you can easily put static parts out of regularly (and costly) >>>>>>> evaluated code: >>>>>>> > >>>>>>> > shape := canvas cacheAt: self "morph" ifAbsentPut: [ >>>>>>> > aCanvas createPath: [:path | >>>>>>> > path relative. >>>>>>> > " no move-to here *** path moveTo: ((self position x )+5)@(self >>>>>>> position y);" >>>>>>> > lineTo: 20@0; >>>>>>> > cwArcTo: 5@5 angle: 45; >>>>>>> > lineTo: 0@20; >>>>>>> > cwArcTo: (-5)@5 angle: 45; >>>>>>> > lineTo: (-20)@0; >>>>>>> > cwArcTo: (-5)@(-5) angle: 45; >>>>>>> > lineTo: 0@(-20); >>>>>>> > cwArcTo: 5@(-5) angle: 45. >>>>>>> > ]. >>>>>>> > ]. >>>>>>> > >>>>>>> > "and here we're using coordinate transform to translate origin >>>>>>> point to >>>>>>> > given position, so it will be the starting point (0@0) of our >>>>>>> shape" >>>>>>> > >>>>>>> > canvas pathTransform restoreAfter: [ >>>>>>> > canvas pathTransform translateBy:((self position x )+5)@(self >>>>>>> position y). >>>>>>> > canvas drawShape: shape. >>>>>>> > ] >>>>>>> > >>>>>>> > by analogy you can cache all static pieces, just do something: >>>>>>> > >>>>>>> > shapes := canvas cacheAt: self ifAbsentPut: [ self >>>>>>> constructStaticShapesOn: aCanvas ] >>>>>>> > >>>>>>> > where #constructStaticShapesOn: must answer an array of them. >>>>>>> > >>>>>>> > >>>>>>> > On 28 November 2013 11:12, kilon alios <kilon.alios(a)gmail.com> >>>>>>> wrote: >>>>>>> > wow you guys are fast at replying :) >>>>>>> > >>>>>>> > I did >>>>>>> > >>>>>>> > >>>>>>> > self changeProportionalLayout. >>>>>>> > editButton := HypEditButton new . >>>>>>> > editButton position: 0@0. >>>>>>> > self addMorph: editButton fullFrame: #(0 0 0 0 0 0 100 100). >>>>>>> > >>>>>>> > I am afraid Igor I still see no change with your code. >>>>>>> > >>>>>>> > I like to note here, that when I first created the editButton as >>>>>>> morph , it indeed placed it in correct place. A 0@0 placed it in >>>>>>> top left corner as expected. But I did overide its DrawOn: with an empty >>>>>>> method and used my own method to render it with Athens. So it looks like >>>>>>> the problem is Athens related and not Morphic related or maybe a >>>>>>> disagreement between Morphic and Athens. >>>>>>> > >>>>>>> > just for the record here is the code I use to render the >>>>>>> HypEditButton morph >>>>>>> > >>>>>>> > render:aCanvas >>>>>>> > |shape1 shape2 shape3 editButtonColor | >>>>>>> > shape1 := aCanvas createPath: [:path | >>>>>>> > path relative . >>>>>>> > >>>>>>> > path moveTo: ((self position x )+5)@(self position >>>>>>> y); >>>>>>> > lineTo: 20@0; >>>>>>> > cwArcTo: 5@5 angle: 45; >>>>>>> > lineTo: 0@20; >>>>>>> > cwArcTo: (-5)@5 angle: 45; >>>>>>> > lineTo: (-20)@0; >>>>>>> > cwArcTo: (-5)@(-5) angle: 45; >>>>>>> > lineTo: 0@(-20); >>>>>>> > cwArcTo: 5@(-5) angle: 45. >>>>>>> > ]. >>>>>>> > >>>>>>> > shape2 := aCanvas createPath: [:path | >>>>>>> > path relative . >>>>>>> > >>>>>>> > path moveTo: ((self position x +7))@((self position >>>>>>> y +3)); >>>>>>> > lineTo: 18@0; >>>>>>> > cwArcTo: 2@2 angle: 45; >>>>>>> > lineTo: 0@20; >>>>>>> > cwArcTo: (-2)@2 angle: 45; >>>>>>> > lineTo: (-20)@0; >>>>>>> > cwArcTo: (-2)@(-2) angle: 45; >>>>>>> > lineTo: 0@(-20); >>>>>>> > cwArcTo: 4@(-2) angle: 45. >>>>>>> > ]. >>>>>>> > shape3 := aCanvas createPath: [:path | >>>>>>> > path relative . >>>>>>> > >>>>>>> > path moveTo: ((self position x +15))@((self position >>>>>>> y +10)); >>>>>>> > >>>>>>> > cwArcTo: 5@5 angle: 90; >>>>>>> > cwArcTo: (-5)@5 angle: 90; >>>>>>> > cwArcTo: (-5)@(-5) angle: 90; >>>>>>> > cwArcTo: 5@(-5) angle: 90. >>>>>>> > >>>>>>> > >>>>>>> > ]. >>>>>>> > >>>>>>> > ( editMode = true) ifTrue: [ editButtonColor := Color green] >>>>>>> ifFalse: [ editButtonColor := Color red ]. >>>>>>> > (aCanvas setStrokePaint: editButtonColor) width: 1. >>>>>>> > >>>>>>> > aCanvas drawShape: shape1 . >>>>>>> > aCanvas drawShape: shape2. >>>>>>> > aCanvas setPaint: (editButtonColor alpha: 0.3 ). >>>>>>> > aCanvas drawShape: shape3. >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On Thu, Nov 28, 2013 at 12:03 PM, Igor Stasenko < >>>>>>> siguctua(a)gmail.com> wrote: >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On 28 November 2013 10:59, kilon alios <kilon.alios(a)gmail.com> >>>>>>> wrote: >>>>>>> > just tried it, I see no change >>>>>>> > >>>>>>> > try: >>>>>>> > self changeProportionalLayout >>>>>>> > >>>>>>> > editButton := HypEditButton new . >>>>>>> > self addMorph: editButton fullFrame: #(0 0 0 0 0 0 100 100). >>>>>>> > >>>>>>> > >>>>>>> > On Thu, Nov 28, 2013 at 11:54 AM, Benjamin < >>>>>>> Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >>>>>>> > Can you try to do something like >>>>>>> > >>>>>>> > self changeProportionalLayout >>>>>>> > before adding the morph ? >>>>>>> > >>>>>>> > Ben >>>>>>> > >>>>>>> > On 28 Nov 2013, at 10:51, kilon alios <kilon.alios(a)gmail.com> >>>>>>> wrote: >>>>>>> > >>>>>>> >> So I have found some strange problems with my vector editor , >>>>>>> Hyperion. >>>>>>> >> >>>>>>> >> Hyperion is a Morph openInWindow. Code can be found in the class >>>>>>> side of Hyperion>>open. >>>>>>> >> >>>>>>> >> The coordinate system when detecting events (mouseOver, mouseUp >>>>>>> and mouseDown events of the Hyperion instance) looks like it takes to >>>>>>> account also beyond the morph as coordinates as a result events happening >>>>>>> at the top right edge of the morph where Hyperion is rendered is 6@30( >>>>>>> which is the size of the window's title bar plus its borders). Thats ok, I >>>>>>> have taken these offsets to account when computing the position of the >>>>>>> mouse. I guess it uses the global coordinated and not the local coordinates >>>>>>> of the morph. >>>>>>> >> >>>>>>> >> I am adding a button to control the edit mode of a line, when in >>>>>>> edit mode handles for line's control points are shown and those handles can >>>>>>> be dragged around to control the shape of the line , when off edit mode, >>>>>>> the line will be able to be drag around (not implemented yet). >>>>>>> >> >>>>>>> >> My problem is that when I add that button as morph to the >>>>>>> existing morph of Hyperion in 0@0 , it actually appears in 0@30 in >>>>>>> local coordinated of the Hyperion moprh which in global coordinates it 6@60( 0@0+ 6@30+ 0@30= 6@60). >>>>>>> Why is that ? >>>>>>> >> >>>>>>> >> I have no clue why I am getting an offset of 0@30 in local >>>>>>> coordinates of the Hyperion morph. >>>>>>> >> >>>>>>> >> here is the picture showing a) how it looks like b) the code that >>>>>>> set the position c) transcript showing mouse coordinates when clicked in >>>>>>> the top left corner of Hyperion morph >>>>>>> >> Hyperion coordinates problem.JPG >>>>>>> >> >>>>>>> >> if anyone wants to try the code himself the repo is here >>>>>>> >> >>>>>>> >> http://www.smalltalkhub.com/#!/~kilon/Hyperion >>>>>>> >> >>>>>>> >> To sum up, to place that button on top left, I will have to >>>>>>> position it 0@(-30) which for me makes no sense at all. >>>>>>> >> >>>>>>> >> Please note that everything is rendered with Athens. >>>>>>> >> >>>>>>> >> Maybe I have messed up the code myself somewhere but I have >>>>>>> looked it again and again I cant find a problem with my code. >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Best regards, >>>>>>> > Igor Stasenko. >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Best regards, >>>>>>> > Igor Stasenko. >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Nov. 29, 2013

Re: [Pharo-dev] Bug font windows

by Igor Stasenko

On 29 November 2013 07:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Thanks igor. > What is strange is that it worked the first time. > > maybe because it was not initialized before. > 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. > > Another thought, it could be that > newFaceFromExternalMemory:index: > fails somehow .. (maybe freetype plugin unavail?) > > > > -- > Best regards, > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Nov. 29, 2013

Re: [Pharo-dev] Added shop page

by phil＠highoctane.be

Thanks. One problem I do have is how the hell can I change some look and feel pieces. That's more a general thing for the presentation framework than the content. My main "surprise" was that I needed blocks for everything. And that doing italics was hard, when I wanted to do a citation. Or is it another way? As I am a Tiki Wiki CMS Groupware team member, this is indeed a different way to look at things (https://tiki.org/Communications+Team) But I guess the codebase there is 100% non Pharo. And most of you on this list would, well, run away :-) But the community is quite working well. Check https://tiki.org/Monthly+Team+Meetings The Pharo site looks somewhat dated by today's standards (Have a look at the AngularJS site to see what I mean http://angularjs.org/, ). Next week, I have a meeting w/ a young designer who will be proposing me new looks, we'll see if we get traction with the community and if yes, get a new look on. Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Fri, Nov 29, 2013 at 11:19 AM, Christoph Wysseier <c.wysseier(a)netstyle.ch > wrote: > Am 28.11.13 11:51, schrieb phil(a)highoctane.be: > >> I am getting used to the CMSBox UI. >> > > And if you have an unsolvable problem once or feedback concerning the user > interface we are always available for your comfort and support: > mail(a)cmsbox.com > > Cheers, > > Chris > > -- > > Christoph Wysseier > netstyle.ch GmbH & Cmsbox GmbH, CEO > >

Nov. 29, 2013