- Pharo-dev - lists.pharo.org

Athens and ellipse drawing (again)

by Nicolai Hess

background: forum.world.st/Athens-and-ellipse-drawing-td4754256.html drawing an ellipse by drawing a non-uniform-scaled circle works, but the border is scaled as well. in Roassal2, ellipse shapes always use a small 1px border (https://code.google.com/p/moose-technology/issues/detail?id=1097) As described in the above 2 threads, it is possible to draw an ellipse with uniform border with cairo, and it is possible to do this with athens, although athens does not provide this as a public api. A much easier solution than the one I suggested in https://code.google.com/p/moose-technology/issues/detail?id=1097 is to use athens "paintTransform". We need to add AthensCairoCanvas>>setPaintMatrix (similiar to setPathMatrix) and call this in AthensCairoStrokePaint>>#athensFillPath:on: self prepareForDrawingOn: aCanvas. aCanvas newPath; loadPath: aPath; setPaintMatrix; "< --- new" stroke what do you think? Nicolai

Dec. 3, 2014

[pharo-project/pharo-core]

by GitHub

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

Dec. 3, 2014

[pharo-project/pharo-core] 4035b4: 40397

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 4035b411d8b30af9d9482d9ccad7532a91afd714 https://github.com/pharo-project/pharo-core/commit/4035b411d8b30af9d9482d9c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-03 (Wed, 03 Dec 2014) Changed paths: M AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitsmnemonic_operand1_operand2_operand3_.st A OpalTools.package/extension/LiteralVariable/instance/gtInspectorUsersIn_.st A OpalTools.package/extension/Slot/instance/gtInspectorUsersIn_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script397.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40397.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Slot.package/GlobalVariable.class/instance/as yet unclassified/definingClass.st A Slot.package/GlobalVariable.class/instance/queries/definingClass.st Log Message: ----------- 40397 14033 Failing test: AJx64AssemblerTests>#testStringOps64Mnemonics https://pharo.fogbugz.com/f/cases/14033 14562 add a Users tab to GTInspector for Slots and LiteralVariables https://pharo.fogbugz.com/f/cases/14562 http://files.pharo.org/image/40/40397.zip

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Esteban Lorenzano

> On 03 Dec 2014, at 04:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata. What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do. why is better? I need more than an opinion there, because my own opinion is that is the contrary :) Esteban

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Esteban Lorenzano

> On 03 Dec 2014, at 08:21, stepharo <stepharo(a)free.fr> wrote: > > > Le 2/12/14 21:02, kilon alios a Ã©crit : >> I think its great that we have this discussion we need at least people to report any problems they have with the git integration , real problems not theoretical problems so as a community we can coordinate effort. There is no reason to speculate about the future of Pharo with git since the integration is in a very early stage and we have still a long way to go . I am following the discussion with great interest. >> >> What fascinates me about git is that is made around the idea of modular community. Its architecture makes it flexible to send code around and create a community of commits that bounce without a need for centralisation. You could say that each pull request is a message and I feel that git architecture could fit like a glove for Pharo because they speak the same language. > > Monticello is like that too. > A decentralized version management system yes, but is a decentralised management system in a way that does not scales in team work (not a problem of monticello, all cms of the time had same problem). They are ok with centralised ways of work (even if decentralised systems): all responsibility is in contributor, so you end having to centralise access rights (this is ok for lots of people, but welllâ¦ not in open source models that wants to grow from âjust some contributorsâ). The real advantage of git is the model it allows: you have a repository that everybody can fork and when ready, they can do a pull requestâ¦ then responsible can choose to merge or not, or cherry pick, or whatever. In summary: is a lot more dynamic and allows a lot more people contribution. monticello is cool, but is not good for that. and if we put also in the table that we need to spend a lot of time improving *external tools* (like smalltalkhub) just to have something that is way far from what is âstate of the artâ, then the equation starts to be less and less in our favor. Also, the proposal so far is not to drop what we have, but to adapt it to be able to use what is aroundâ¦ would be the best of two worlds if you want (even if I believe at the end we will converge in just one). Esteban > >> >> Obviously there is still a long road ahead of us but I am excited and believe that slowly people will contribute and in the future we will look back and wonder what tooks us so long to embrace git :D > >

Dec. 3, 2014

Re: [Pharo-dev] GetOpt

by phil＠highoctane.be

On Wed, Dec 3, 2014 at 9:51 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Phil, > > On Dec 2, 2014, at 2:18 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > > Well, after looking at the command line handlers in the image for the way > options are handled, I was of opinion that I wanted something like getopt. > > So, I looked around and found that implementation of Ian that I plugged > into the CommandLineArguments in my activate methods. > > I like the dictionary + block approach > > I have quite a couple commands (like --create-user -u xxx -p xxx -e xxx -n > xxx -g xxx) and it was a pain to write the options parsing. > > So, something like this in my XXToolsCommandLineHandler > > activate > ... > self activateCreateUser > ... > > activateCreateUser > > GetOpt new at: $u put: [ :opt :arg | userName := arg ]; at: $p put: [ :opt > :arg | ... ]; at: $e put: [ :opt :arg | ... ]; at: $n put: [ :opt :arg | > ... ]. > at: $g put: [ :opt :arg | ... ]; > parse: self arguments. > "wrapped in some error handling" > XXTools makeUserNames: userName ... > > No more need to dig into a number of isXXXX methods and optionAt:... > > I think we should make this work with more integration etc but I have > other fish to fry at the moment and this works well for me. > > We need more doc on the CommandLineHandlers but it is a fantastic piece of > Pharo! > > Combined with a small image, it would be a terrific tool. > > I am investing some time on those CLI things as I need them for servers > and even if Bash is cool for some things, Pharo is better in terms of > cleanliness. > > One factor is the time taken for loading the image. > > > I bet that if you measure it you'll find that the load time is very small > and the bulk of the time is in unnecessary or insane activities. One if > these, which Ben Coman's recent changes above my 64-bit microsecond clock > should have fixed is a spin loop of up to a second to synchronize the > second and millisecond clocks. Another is a GC to start the new weakness > facilities. > > I found these either by profiling (clock sync; I can give you a change > set that allows profiling across a snapshot, quit, resume) or using the VM > simulator (GC to check for finalization facilities). > Nice to know! Yeah, send me the .cs, I am eager to try. The sim is not working for my Pharo. I admit that I've let that on the backburner when Clement told me he was using your image for that. (little depressing moment). I've used strace a bit to see what the VM was doing as well as instrumenting some plugins on a custom VM build. There is the dtrace enabled VM possibility (Ardian's thing) and this should be explored too for instrumentation. > > Maybe should we look into something like a pharod, a daemon that would > just run scripts and a lightweight CLI tool that would pass the scripts to > it. > > > IMO all that needs to be fine is to take a careful look at start-up and > eliminate costly but unnecessary activities. You should easily be able to > get startup times down to tens if milliseconds on modem hardware. > Yes it is fast when starting stuff. But when repeated a ton of times, it becomes long. It will be nice to get things super fast indeed. That would be a great bonus. Phil > > Something like: > http://www.martiansoftware.com/nailgun/ > > I think we could steal their C client right away/ > > Phil > > > > > > > On Tue, Dec 2, 2014 at 10:17 AM, stepharo <stepharo(a)free.fr> wrote: > >> Can you just tell me a bit more :) >> >> Le 2/12/14 08:45, phil(a)highoctane.be a Ã©crit : >> >>> I have made Ian Piumarta's GST GetOpt work in Pharo 3.0 >>> >>> See: >>> >>> http://www.smalltalkhub.com/#!/~philippeback/GetOpt < >>> http://www.smalltalkhub.com/#%21/%7Ephilippeback/GetOpt> >>> >>> Nice tool even if we have some other support in CommandLineHandlers. >>> But for a quick parameters setting in your own CommandLineHandler, it is >>> fast to use and easy to debug. >>> >>> Phil >>> >>> >>> >>> >> >> >

Dec. 3, 2014

Re: [Pharo-dev] Glamour-core maybe missing from Pharo40/main

by Marcus Denker

Yes, seemingly we lost again the repos of external packages... this is a bug, something in the integraton process resets the reopsitories. On Sat, Nov 29, 2014 at 7:53 AM, Ben Coman <btc(a)openinworld.com> wrote: > > Sometimes when I am hacking around the system, I use Monticello to review > just what I've changed. > > In build 40390, I did a <Changes> > of Glamour-Core (BernardoContreras.286) against Pharo40/main and got > _lots_ of changes. Then it seems that this package is not in > Pharo40/main. Should it be? > > Maybe this is because its an external package - but then its repository is > not listed? > > cheers -ben > >

Dec. 3, 2014

Re: [Pharo-dev] Glamour-core maybe missing from Pharo40/main

by Marcus Denker

> On 29 Nov 2014, at 07:53, Ben Coman <btc(a)openInWorld.com> wrote: > > > 2014-11-27 10:02 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > >> >> The fact that Athens are part of Pharo distribution don't means, that its repository should be abandoned and all updates should come directly to Pharo. That would be a huge mistake. >> >> That's how I've done it recently. >> >> I'll merge the changes from pharo -> athens repository. > > Thanks for doing that! > > Hm, actually I don't know how to do that :) > Whats the common way for merging this changes back? > Do I just > open Monticello Browser, > select the Athens packages (Athens-Balloon/Athens-Cairo/Athens-Core ..) > and just save them in the 'http://smalltalkhub.com/mc/Pharo/Athens/main <http://smalltalkhub.com/mc/Pharo/Athens/main>' - repository ? > I would say -> merge with the repo (if there are changes) -> commit back to the repo -> sync with maintainer -> Maintainer should give OK and make a new Config Then we should make sure to have the same in the image as in the repo. Marcus

Dec. 3, 2014

Re: [Pharo-dev] GetOpt

by Eliot Miranda

Hi Phil, On Dec 2, 2014, at 2:18 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Well, after looking at the command line handlers in the image for the way options are handled, I was of opinion that I wanted something like getopt. > > So, I looked around and found that implementation of Ian that I plugged into the CommandLineArguments in my activate methods. > > I like the dictionary + block approach > > I have quite a couple commands (like --create-user -u xxx -p xxx -e xxx -n xxx -g xxx) and it was a pain to write the options parsing. > > So, something like this in my XXToolsCommandLineHandler > > activate > ... > self activateCreateUser > > ... > > activateCreateUser > > GetOpt new > at: $u put: [ :opt :arg | userName := arg ]; > at: $p put: [ :opt :arg | ... ]; > at: $e put: [ :opt :arg | ... ]; > at: $n put: [ :opt :arg | ... ]. > at: $g put: [ :opt :arg | ... ]; > parse: self arguments. > > "wrapped in some error handling" > XXTools makeUserNames: userName ... > > No more need to dig into a number of isXXXX methods and optionAt:... > > I think we should make this work with more integration etc but I have other fish to fry at the moment and this works well for me. > > We need more doc on the CommandLineHandlers but it is a fantastic piece of Pharo! > > Combined with a small image, it would be a terrific tool. > > I am investing some time on those CLI things as I need them for servers and even if Bash is cool for some things, Pharo is better in terms of cleanliness. > > One factor is the time taken for loading the image. I bet that if you measure it you'll find that the load time is very small and the bulk of the time is in unnecessary or insane activities. One if these, which Ben Coman's recent changes above my 64-bit microsecond clock should have fixed is a spin loop of up to a second to synchronize the second and millisecond clocks. Another is a GC to start the new weakness facilities. I found these either by profiling (clock sync; I can give you a change set that allows profiling across a snapshot, quit, resume) or using the VM simulator (GC to check for finalization facilities). > Maybe should we look into something like a pharod, a daemon that would just run scripts and a lightweight CLI tool that would pass the scripts to it. IMO all that needs to be fine is to take a careful look at start-up and eliminate costly but unnecessary activities. You should easily be able to get startup times down to tens if milliseconds on modem hardware. > > Something like: > http://www.martiansoftware.com/nailgun/ > > I think we could steal their C client right away/ > > Phil > > > > > > > On Tue, Dec 2, 2014 at 10:17 AM, stepharo <stepharo(a)free.fr> wrote: >> Can you just tell me a bit more :) >> >> Le 2/12/14 08:45, phil(a)highoctane.be a Ã©crit : >>> I have made Ian Piumarta's GST GetOpt work in Pharo 3.0 >>> >>> See: >>> >>> http://www.smalltalkhub.com/#!/~philippeback/GetOpt <http://www.smalltalkhub.com/#%21/%7Ephilippeback/GetOpt> >>> >>> Nice tool even if we have some other support in CommandLineHandlers. >>> But for a quick parameters setting in your own CommandLineHandler, it is fast to use and easy to debug. >>> >>> Phil >

Dec. 3, 2014

Re: [Pharo-dev] class variable slots?

by Marcus Denker

>> > > One we did for Pharo4 is to use the Associations of Globals to model these variables as meta-objects (in the same spirit as the Slot objects). > > Thos means that > -> there is an Api to get them > -> they have an API to read /write > > This is just âsugarâ on what the associations did already: > > global := SmalltalkImage classVariableNamed: #CompilerClass. > global read. > global class > ==> ClassVariable > Having objects for concepts like this allows of course to leverage the power of the toolsâ¦ e.g. this adds an inspect pane that shows all users of variables: 14562 add a Users tab to GTInspector for Slots and LiteralVariables https://pharo.fogbugz.com/f/cases/14562

Dec. 3, 2014