- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Catch Response 500 error in ZnClient

by Sven Van Caekenberghe

Hi Nicolai, I must have missed that one somehow, I will look into it. OTOMH, I think you need to add an #enforceHttpSuccess:true or #systemPolicy to the ZnClient instance being used. Sven On 03 Oct 2014, at 17:49, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-08-24 13:10 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > How to catch a ZnResponse(500 Internal Server Error) ? > (see fogbugz issue 13905) > > I tried to add a > ifFail:[....] > block but it does not get called on this response. > > > Nicolai > > Anyone ? :)

Oct. 3, 2014

Re: [Pharo-dev] Playground

by Ben Coman

Tudor Girba wrote: > and "Meta" showing the _code_ related to the object. [..] but > maybe we can find a better one. Maybe "code" for instance side methods ?... > "Meta" which will show you the code of the class side of the class, and > "Methods" which show you the methods of the class. ...and "Code" for class side methods ? Or "methods" and "Methods" for instance-side and class-side respectively, or "Code" and "MetaCode" ? -ben

Oct. 3, 2014

Re: [Pharo-dev] Catch Response 500 error in ZnClient

by Nicolai Hess

2014-08-24 13:10 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > How to catch a ZnResponse(500 Internal Server Error) ? > (see fogbugz issue 13905) > > I tried to add a > ifFail:[....] > block but it does not get called on this response. > > > Nicolai > Anyone ? :)

Oct. 3, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by Esteban Lorenzano

wellâ¦ I think everybody is taking it too personal :) My call was to keep a good environment and try to be more positive on our communication. And to try to provide advice with the criticism (and to provide fixes when possible). Iâm completely aware that people has other things to do than Pharoâ¦ but being just in the place of criticise without any positive loop is what I think is not good. Just that, Iâm not blaming anyone, just making a call for keep the good will. Esteban > On 03 Oct 2014, at 17:07, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Esteban, > > I'm not sure my answer will please you or stef, and maybe I shouldn't voice it, staying being a "customer" instead of contributing "the way you want it". Hard words, but yours are hard too. > > I'd say simply that Pharo is successfull, fairly successfull for someone like me. It allows me to engage in complex work, in what I do best and what affords me to be paid and have the freedom to use Pharo. Some of those things suppose that I maintain and extend fairly complex packages on top of Pharo, and deal with permanent, multiple overlapping interruptions (meeting, administrative work, travels, etc...). Pharo is great, it allows me to build a significant activity on top of it. > > Some of the consequences of that success? I'm looking at things that works now, not in Pharo 5, 6, or 7. I'm a bit frightened by grandiose rewritting attempts which will be usable in a version or 2, at best, and leave an unsatisfying "now" situation. I'll carefully evaluate what new stuff is integrated. New stuff I look to see if they are usable (libcgit integration, TxText) and what I see is stuff that builds on unstable core libs extensions (NativeBoost, Athens) on top of an already unstable version (4.0), and I'm really not impressed by the software development process. > > The end result is, when I see a bug, I'm already at least two versions behind you guys... so there's nothing worth reporting. There is some progress on the way things are being done (thanks Marcus for doing the deprecation API backporting on 3.0) and not much on others (and I speak of methodology, not of new features being added on). > > If you have the feeling that I don't contribute the way I should or the way you would like, step back and ask yourself if this is not my "unspoken" way of me saying that I don't find a way to contribute, or that contributing effectively is too costly. > > And look! This is not a matter of resources, but maybe a matter of slowing down a bit, so that the poor community members with limited resources like me that are not full time on Pharo 4.0 development may catch up :) And please, no more rejection of feedback, even negative. It just gives me the feeling you are overstreched, and that Pharo has a problem setting its goals. > > Regards, > > Thierry > > 2014-10-03 13:44 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > Hi, > > Iâm writing this because Iâm sad about what is happening in this list. > Iâm seeing a lot of general negativity and non constructive ways to discuss things. > Iâm also seeing more and more people using Pharo for their particular interests (which is of course a good thing) but less and less people who contribute back to Pharo. > Finally, Iâm seeing more frequently an attitude of âcustomerâ, more than the conviction than this, Pharo, is also yoursâ¦ > > Please people, we (the pharo âcoreâ team) cannot do everything. We do not have the manpower or the resources to hire manpower. We would like, but we just do not have the resources (is already a blessing that we can work on this, for now: INRIA is paying, but what it pays is *research*, not âpharo the languageâ, so this is a collateral advantageâ¦.) > > So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. > It depends on the community not just to fix, but to enlarge the ecosystem in general too. > > So, I refuse to believe that we cannot be a cool and helpful community. > I refuse to believe that general negativity and bad humor can overcome the joy of participating in this collective effort. > > So, here some recommendations for enhance the way we participate: > > - Be positive. Just âthis is a s**tâ does not help. Even if it is. > - Be propositional. Just âthis is a s**tâ, and not telling what you want/prefer does not help. > - Be proactive. Just âthis is a s**tâ, and not report, discuss and (at least time to time) provide a fix/enhancement does not help. > > In conclusion: not helping does not help :) > After all, this is the âpharo-devâ list. I mean, the list of people wanting to participate from this great, community effort. > > cheers, > Esteban, still grateful of belonging to this community > > > >

Oct. 3, 2014

Re: [Pharo-dev] playground size

by phil＠highoctane.be

I am using GT in 3.0 and the inspector is indeed supercool. Now, I've the standard Workspace on Cmd-o Cmd-w and the Playground on Cmd-g. Depending on the task, one or the other is better. I am using Workspaces as a kind of command prompt in Pharo to set some state of the system, reinitializing etc. There is zero need to inspect the result there nor have a large window. Also, the ability to save/load such workspaces is very useful (as well as making them unclosable). All of these abilities are lost with the Playground and the size of the Playground there would be too large. There is a use case for both facilities. Phil On Fri, Oct 3, 2014 at 5:07 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I too feel that GT-Tools in general use up too much screen real estate. It > is as if they were designed for big screens and/or small fonts. But I am > concentrating on functionality (views) first, the look can change later on > I guess. > > On 03 Oct 2014, at 17:05, Christophe Demarey <Christophe.Demarey(a)inria.fr> > wrote: > > > Hi, > > > > First I need to say, I love the new GT tools. It really goes a step > further. > > I just wanted to say that I find the Playground window quite big (at > least 1/4 of the whole Pharo window). > > I understand that the size is bigger than a simple workspace to be able > to display panes after clicking play but if you just need to evaluate > ()do-it, print-it) some code, it is over-sized. > > Would it be possible to have a default window size smaller and resize > automatically if you need to display an inspector pane? > > > > Regards, > > Christophe. > > >

Oct. 3, 2014

Re: [Pharo-dev] playground size

by Sven Van Caekenberghe

I too feel that GT-Tools in general use up too much screen real estate. It is as if they were designed for big screens and/or small fonts. But I am concentrating on functionality (views) first, the look can change later on I guess. On 03 Oct 2014, at 17:05, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Hi, > > First I need to say, I love the new GT tools. It really goes a step further. > I just wanted to say that I find the Playground window quite big (at least 1/4 of the whole Pharo window). > I understand that the size is bigger than a simple workspace to be able to display panes after clicking play but if you just need to evaluate ()do-it, print-it) some code, it is over-sized. > Would it be possible to have a default window size smaller and resize automatically if you need to display an inspector pane? > > Regards, > Christophe.

Oct. 3, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by Thierry Goubier

Hi Esteban, I'm not sure my answer will please you or stef, and maybe I shouldn't voice it, staying being a "customer" instead of contributing "the way you want it". Hard words, but yours are hard too. I'd say simply that Pharo is successfull, fairly successfull for someone like me. It allows me to engage in complex work, in what I do best and what affords me to be paid and have the freedom to use Pharo. Some of those things suppose that I maintain and extend fairly complex packages on top of Pharo, and deal with permanent, multiple overlapping interruptions (meeting, administrative work, travels, etc...). Pharo is great, it allows me to build a significant activity on top of it. Some of the consequences of that success? I'm looking at things that works now, not in Pharo 5, 6, or 7. I'm a bit frightened by grandiose rewritting attempts which will be usable in a version or 2, at best, and leave an unsatisfying "now" situation. I'll carefully evaluate what new stuff is integrated. New stuff I look to see if they are usable (libcgit integration, TxText) and what I see is stuff that builds on unstable core libs extensions (NativeBoost, Athens) on top of an already unstable version (4.0), and I'm really not impressed by the software development process. The end result is, when I see a bug, I'm already at least two versions behind you guys... so there's nothing worth reporting. There is some progress on the way things are being done (thanks Marcus for doing the deprecation API backporting on 3.0) and not much on others (and I speak of methodology, not of new features being added on). If you have the feeling that I don't contribute the way I should or the way you would like, step back and ask yourself if this is not my "unspoken" way of me saying that I don't find a way to contribute, or that contributing effectively is too costly. And look! This is not a matter of resources, but maybe a matter of slowing down a bit, so that the poor community members with limited resources like me that are not full time on Pharo 4.0 development may catch up :) And please, no more rejection of feedback, even negative. It just gives me the feeling you are overstreched, and that Pharo has a problem setting its goals. Regards, Thierry 2014-10-03 13:44 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > I'm writing this because I'm sad about what is happening in this list. > I'm seeing a lot of general negativity and non constructive ways to > discuss things. > I'm also seeing more and more people using Pharo for their particular > interests (which is of course a good thing) but less and less people who > contribute back to Pharo. > Finally, I'm seeing more frequently an attitude of "customer", more than > the conviction than this, Pharo, is also yours... > > Please people, we (the pharo "core" team) cannot do everything. We do not > have the manpower or the resources to hire manpower. We would like, but we > just do not have the resources (is already a blessing that we can work on > this, for now: INRIA is paying, but what it pays is *research*, not "pharo > the language", so this is a collateral advantage....) > > So, having an OPEN SOURCE project, with limited resources means that there > is a lot of things that depend on the community. > It depends on the community not just to fix, but to enlarge the ecosystem > in general too. > > So, I refuse to believe that we cannot be a cool and helpful community. > I refuse to believe that general negativity and bad humor can overcome the > joy of participating in this collective effort. > > So, here some recommendations for enhance the way we participate: > > - Be positive. Just "this is a s**t" does not help. Even if it is. > - Be propositional. Just "this is a s**t", and not telling what you > want/prefer does not help. > - Be proactive. Just "this is a s**t", and not report, discuss and (at > least time to time) provide a fix/enhancement does not help. > > In conclusion: not helping does not help :) > After all, this is the "pharo-dev" list. I mean, the list of people > wanting to participate from this great, community effort. > > cheers, > Esteban, still grateful of belonging to this community > > > >

Oct. 3, 2014

playground size

by Christophe Demarey

Hi, First I need to say, I love the new GT tools. It really goes a step further. I just wanted to say that I find the Playground window quite big (at least 1/4 of the whole Pharo window). I understand that the size is bigger than a simple workspace to be able to display panes after clicking play but if you just need to evaluate ()do-it, print-it) some code, it is over-sized. Would it be possible to have a default window size smaller and resize automatically if you need to display an inspector pane? Regards, Christophe.

Oct. 3, 2014

Re: [Pharo-dev] First additions to GT-Inspector

by Andrei Chis

I'll make a new version to integrate. Cheers, Andrei On Fri, Oct 3, 2014 at 3:52 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Done! > > Doru > > On Fri, Oct 3, 2014 at 3:25 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> On 03 Oct 2014, at 15:23, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> > Great. I checked it quickly and it looks great. I added you to the >> Moose team. Could you please commit directly in the repo? >> >> Done, you'll have to merge my version since it is two commits behind. >> >> > Doru >> > >> > On Fri, Oct 3, 2014 at 3:17 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > I made my first additions/changes to GT-Inspector: >> > >> > === >> > Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.54 >> > Author: SvenVanCaekenberghe >> > Time: 3 October 2014, 3:03:17.252107 pm >> > UUID: 853cfe8d-314c-4eac-ad67-8c6eff2b4f83 >> > Ancestors: GT-InspectorExtensions-Core-TudorGirba.53 >> > >> > Customized GT-Inspector for Integer, Float and Character >> > === >> > >> > MCZ attached: >> > >> > >> > >> > >> > I made it so that 'State' shows slots only (if any) and takes >> precedence. >> > >> > I added an 'Integer' tab to Integer with decimal, hex, octal, binary >> and optional character aspects. >> > >> > I added a 'Float' tab to Float with (binary, base 2) significant and >> exponent (self = significant * (2 ** exponent)) [the old sign field was not >> needed since significant is signed already), while making the 'State' show >> the 2 indexed slots (which is more correct IMHO). >> > >> > I added a 'Character' tab with self, codepoint and unicode aspects. >> > >> > Obviously this has to be iterated upon. I am already very happy that I >> could figure out how to do this. Much more from the old Eye inspectors will >> follow. >> > >> > Sven >> > >> > PS1: Implementing this, I sense that we might need an option so that a >> field can show some label for its value, while clicking further on it would >> continue on something else (obviously related), differently field by field. >> > >> > PS2: Is is necessary/useful for the States fields in >> #gtInspectorVariableValuePairs to be a Set instead of something that >> preserves the order ? >> > >> > >> > >> > -- >> > www.tudorgirba.com >> > >> > "Every thing has its own flow" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 3, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 3, 2014