- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 3ad5e4: 40280

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3ad5e446a607564ae9c5a653681812e861b32240 https://github.com/pharo-project/pharo-core/commit/3ad5e446a607564ae9c5a653… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-03 (Fri, 03 Oct 2014) Changed paths: A ConfigurationOfGTInspector.package/ConfigurationOfGTInspector.class/instance/versions/version104_.st A ConfigurationOfGTPlayground.package/ConfigurationOfGTPlayground.class/instance/versions/version104_.st A ConfigurationOfGlamour.package/ConfigurationOfGlamour.class/instance/versions/version273_.st R GT-InspectorExtensions-Core.package/extension/CollectionValueHolder/instance/announcer.st R GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtDisplayOn_.st R Glamour-Helpers.package/extension/Boolean/instance/glamourValueWithArgs_.st M Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/private/glamorousThickBorderFor_.st A Glamour-Tests-Rubric.package/GLMRubricTextMorphicTest.class/instance/as yet unclassified/expectedFailures.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script280.st M ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40279.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40280.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40280 14145 GTools version 1.0.4 https://pharo.fogbugz.com/f/cases/14145 http://files.pharo.org/image/40/40280.zip

Oct. 3, 2014

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

by Tudor Girba

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

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

by phil＠highoctane.be

On Fri, Oct 3, 2014 at 3:23 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-10-03 8:44 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > 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. > > It is a matter of tolerance and patience. > > You keep doing your great job, but accept that we, outside of the > internal, core, revolutionary research being made, might have mundane > necessities. That on the daily basis have more importance than a > futuristic 128bit manycore vm that kicks JVM's ass :D > Same boat here. > > > So, I refuse to believe that we cannot be a cool and helpful community. > > We are. > We are indeed. > Email sometimes is counterproductive to the health of the > communication. It's like a fence between us. > And as the saying, transliterated, goes: "We're like dogs barking at > both sides of the fence that when together they smell at each other > and waggle their tails." :) > We should Hangout more. > > > In conclusion: not helping does not help :) > > Please consider than USING Pharo is a way to contribute to it. > Even if you had infinite manpower but no one uses it, it would be > worthless. > +1 > > > Esteban, still grateful of belonging to this community > ditto :) > ditto :) > > Regards! > > Peace, Phil

Oct. 3, 2014

Re: [Pharo-dev] ZnEasy and post:data:

by Benjamin Pollack

On Thu, Oct 2, 2014, at 01:28 AM, Sven Van Caekenberghe wrote: > ZnClient is your friend (it is a builder) : > > ZnClient new > url: 'http://some/thing'; > formAt: #foo put: #bar; > formAt: 'baz' put: 'quux'; > post. > Ah, that's indeed perfect. I think I discounted ZnClient initially because I was thinking of it being primarily useful for pipelined operations, but your proposal is *way* cleaner, even if I throw beOneShot in there. Thanks for the pointer. --Benjamin

Oct. 3, 2014

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

by Sven Van Caekenberghe

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"

Oct. 3, 2014

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

by Esteban A. Maringolo

2014-10-03 8:44 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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. It is a matter of tolerance and patience. You keep doing your great job, but accept that we, outside of the internal, core, revolutionary research being made, might have mundane necessities. That on the daily basis have more importance than a futuristic 128bit manycore vm that kicks JVM's ass :D > So, I refuse to believe that we cannot be a cool and helpful community. We are. Email sometimes is counterproductive to the health of the communication. It's like a fence between us. And as the saying, transliterated, goes: "We're like dogs barking at both sides of the fence that when together they smell at each other and waggle their tails." :) > In conclusion: not helping does not help :) Please consider than USING Pharo is a way to contribute to it. Even if you had infinite manpower but no one uses it, it would be worthless. > Esteban, still grateful of belonging to this community ditto :) Regards!

Oct. 3, 2014

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

by Tudor Girba

Great. I checked it quickly and it looks great. I added you to the Moose team. Could you please commit directly in the repo? 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"

Oct. 3, 2014

First additions to GT-Inspector

by Sven Van Caekenberghe

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 ?

Oct. 3, 2014

Re: [Pharo-dev] blogging about Pharo stuff? send me your link!

by HernÃ¡n Morales Durand

Thank you. HernÃ¡n 2014-10-03 9:47 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > missed in the pile, sorry. > added now. > > > On 03 Oct 2014, at 14:41, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > I have sent you the link to my Pharo blog by private message five days > ago, but never got replied. So here it is again > > http://80738163270632.blogspot.com.ar/ > > And this is my BioSmalltalk blog > > http://biosmalltalk.blogspot.com > > Cheers, > > HernÃ¡n > > > 2014-08-05 10:06 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> I know, there are several concentrator pages like >> http://planet.smalltalk.org, etc. >> but I want to put your blog here: >> >> http://pharo.org/blogs >> >> So, please send me (in private, to not pollute this list) your Pharo >> related blog :) >> >> Esteban >> > > >

Oct. 3, 2014

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

by J.F. Rick

Hi Esteban, seconding your points, it is important to acknowledge why a solid Pharo core is important and worth striving towards even if it can be painful. First, read Bret Victor's reflection on Doug Englebart: http://worrydream.com/#!/Engelbart He makes the case that the vision that drove Englebart was important to how he realized things, giving the specific example of how his video conferencing system was fundamentally different than today's screen sharing technology. Today's screen sharing is basically a nice hack onto an existing single user system. Simply doing what Englebart did would require a lot of restructuring at the foundation. With Pharo, we have the possibility to really build / refactor from the ground up, building a fundamentally better foundation, ultimately making cool things possible. For my own work, I'm excited about the possibility of building a new multi-touch implementation from the ground up. That said, the current Pharo foundations have a number of problems for me: (1) Graphics are still based on BitBlt, which is slow and ugly. Moving over to Athens will address this. While I have successfully used Athens graphics, I still get VM crashes (which are probably due to Athens as I did not get the crashes beforehand). (2) Sound does not really work. On 64-bit linux, I can't simply play a recorded file as the sound plug-ins really only work for a 32-bit system. (3) Event handling does not get touch events. I've hacked this so far but a sustainable solution would be great. (4) Packages do not facilitate transfer of resources. For my purposes, I need to add images and sound to a package. This is not really possible right now. I am willing to help on these problems for the community but sometimes I need support, especially when C code is necessary, rather than Pharo code. For instance, if I could get a VM that gives me raw touch events into Pharo, I could take (3) from there. I'd also be willing to work on (4) but I could use some help. One intimidating part is that there are so many package managers for Pharo. It might be nice if we simplified down to one: the right one. Anyway, you can count me in for some contribution back to Pharo core but I might need some support from Pharo central and it won't happen for at least another month as I'm just getting set up in the new location (e.g., no access to a multi-touch device). Cheers, Jeff On Fri, Oct 3, 2014 at 7:44 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 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 > > > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Oct. 3, 2014