- Pharo-dev - lists.pharo.org

Failing FuelMetalevel tests

by Max Leske

FYI: the failing tests in FuelMetalevel are due to this bug: https://pharo.fogbugz.com/f/cases/14081/Removing-a-trait-usage-raises-an-ex… <https://pharo.fogbugz.com/f/cases/14081/Removing-a-trait-usage-raises-an-ex…>

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 11:03 PM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Le 03/10/2014 22:10, stepharo a Ã©crit : > > Hi Stef, > > I like your metaphor , and yes, I really hope to share my personal soup > with Pharo community asap. A soup about databases, json, streaming/map > reduce stuff I've been thinking (and still thinking) for a while now. All > of that still in an alpha or infancy step now, but I'm working hard on that > (big problem for me is time - I'm greedy on that, plus lot of stress at > work). > btw, I'm confident about Pharo technology, spur and 64 bits, and it is a > great move forward :). > May be I'll fail -it would not be the first time- but anyway, if I can > contribute with Pharo (bugs, doc or whatever is accessible to me), I will. > Just because I prefer Pharo over dotNet or Java > :) > I've stopped doing Java and made a decision to do Pharo. It is a business bet, we'll see how it unfolds. (Not going bad at the moment, it pays all of the bills for a couple months). Phil > > Regards, > > Alain > > > Thanks alain. >> >> Here is my metaphor: I help myself and share my "soup of stones" with >> people that want to improve our soup of stones. >> At the end our soup may be great. >> >> Another way to present my metaphor is: "focus on what you need and >> change the system (and send us fixes/enhancements) on what you need. >> Because if you do not do it, then why a guy not needing it would need to >> spend time." >> ah to grow the market.... well Spur, 64 bits, better FFI, decent events, >> automated build for VM and many many other things are already in the >> pipeline and >> (none of them is about research :) you can trust me on that >> >> Stef >> >> > > >

Oct. 3, 2014

Re: [Pharo-dev] playground size

by phil＠highoctane.be

Well, my Spotlight looks like this: [image: Inline image 1] You'll notice the $<expr> to execute commands. Works well. Code is here: http://www.smalltalkhub.com/#!/~philippeback/HOExtras/packages/Tools Tools is an hefty package. Always interesting to dig in there. Looks like there is SourceWebBrowser subclassing Workspace and a UserManager. Never heard of those. It feels like an open world game. It is really nice to be able to dig as deep as one wants in those areas. Phil On Fri, Oct 3, 2014 at 10:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > This is indeed a relevant use case, and we are already thinking about this > issue for quite a while. The playground or even the workspace are not > appropriate for things that need to live for a short time only. > > I would like to have an interface that comes, let's me enter my command > and then vanishes. Similar to the spotlight interface. And once we will be > on this, we will also make it a search interface... remember that Pharo4 is > about tooling so now is the time to dream and do :). > > Doru > > On Fri, Oct 3, 2014 at 10:38 PM, stepharo <stepharo(a)free.fr> wrote: > >> Yes your use case make a lot of sense. >> >> 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. >>> >>> >>> >> >> > > > -- > 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 Tudor Girba

Great :) Doru On Fri, Oct 3, 2014 at 11:03 PM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Le 03/10/2014 22:10, stepharo a Ã©crit : > > Hi Stef, > > I like your metaphor , and yes, I really hope to share my personal soup > with Pharo community asap. A soup about databases, json, streaming/map > reduce stuff I've been thinking (and still thinking) for a while now. All > of that still in an alpha or infancy step now, but I'm working hard on that > (big problem for me is time - I'm greedy on that, plus lot of stress at > work). > btw, I'm confident about Pharo technology, spur and 64 bits, and it is a > great move forward :). > May be I'll fail -it would not be the first time- but anyway, if I can > contribute with Pharo (bugs, doc or whatever is accessible to me), I will. > Just because I prefer Pharo over dotNet or Java > :) > > Regards, > > Alain > > > > Thanks alain. >> >> Here is my metaphor: I help myself and share my "soup of stones" with >> people that want to improve our soup of stones. >> At the end our soup may be great. >> >> Another way to present my metaphor is: "focus on what you need and >> change the system (and send us fixes/enhancements) on what you need. >> Because if you do not do it, then why a guy not needing it would need to >> spend time." >> ah to grow the market.... well Spur, 64 bits, better FFI, decent events, >> automated build for VM and many many other things are already in the >> pipeline and >> (none of them is about research :) you can trust me on that >> >> Stef >> >> > > > -- 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 Alain Rastoul

Le 03/10/2014 22:10, stepharo a Ã©crit : Hi Stef, I like your metaphor , and yes, I really hope to share my personal soup with Pharo community asap. A soup about databases, json, streaming/map reduce stuff I've been thinking (and still thinking) for a while now. All of that still in an alpha or infancy step now, but I'm working hard on that (big problem for me is time - I'm greedy on that, plus lot of stress at work). btw, I'm confident about Pharo technology, spur and 64 bits, and it is a great move forward :). May be I'll fail -it would not be the first time- but anyway, if I can contribute with Pharo (bugs, doc or whatever is accessible to me), I will. Just because I prefer Pharo over dotNet or Java :) Regards, Alain > Thanks alain. > > Here is my metaphor: I help myself and share my "soup of stones" with > people that want to improve our soup of stones. > At the end our soup may be great. > > Another way to present my metaphor is: "focus on what you need and > change the system (and send us fixes/enhancements) on what you need. > Because if you do not do it, then why a guy not needing it would need to > spend time." > ah to grow the market.... well Spur, 64 bits, better FFI, decent events, > automated build for VM and many many other things are already in the > pipeline and > (none of them is about research :) you can trust me on that > > Stef >

Oct. 3, 2014

Re: [Pharo-dev] For a DBMS roadmap

by Esteban A. Maringolo

2014-10-03 17:35 GMT-03:00 stepharo <stepharo(a)free.fr>: > so a question: could we have a clear evaluation of the situation? > What should be done? > Who could write a clear roadmap on DBMS so that we can discuss internally > and see what we can do in the next 6 months > - Glorp? should be updated? It certainly should be updated. But we first should know when the departure from the main trunk took place. We don't even know how much outdated are we (both in terms of code and releases). GLORP is developed in VW and AFAIK only actively maintained in VAST. If the maintenance of a Pharo version is too difficult in terms of coordination, the other option is to depart (fork) forever from the main trunk, as Pharo did from Squeak. There is a lot of valuable code in GLORP. > - posgres drivers? The newer, faster, featureful, the better. I have no particular needs for the latest version, but after seeing Stephan Eggermont's description of V3 driver, it comes loaded with a lot of beatiful, useful, features. > - DBXTalk (is is useful or should it not be better to focus on native > drivers. IMO OpenDBX is a failed project. It had good intentions of becoming an ODBC-like layer for Linux. But it's adoption was really small. The issue tracker is not active at all. The mailing list had 5 emails in the last 6 months, 2 of which were written by our fellow Peck. All of the mails were related to connecting to MSSQL databases. I would go native. For which there are already some drivers (PgSQL, ODBC). Having an abstraction layer at the image level would be nice, but it would be costly, both in terms of development and performance. Regards, -- Esteban.

Oct. 3, 2014

Re: [Pharo-dev] playground size

by Tudor Girba

This is indeed a relevant use case, and we are already thinking about this issue for quite a while. The playground or even the workspace are not appropriate for things that need to live for a short time only. I would like to have an interface that comes, let's me enter my command and then vanishes. Similar to the spotlight interface. And once we will be on this, we will also make it a search interface... remember that Pharo4 is about tooling so now is the time to dream and do :). Doru On Fri, Oct 3, 2014 at 10:38 PM, stepharo <stepharo(a)free.fr> wrote: > Yes your use case make a lot of sense. > > 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. >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 3, 2014

Re: [Pharo-dev] Playground

by Tudor Girba

Hi, Indeed, "Code" was the first choice, but that does not work well in object like a CompiledMethod. So, when you inspect a method object you want to see its code, but at the same time you want to see the CompiledMethod class code as well. That is why we chose something that is more neutral like "Meta" to make it as distinct as possible. Now, the other thing we can consider is to offer an icon instead of the text for the Meta (and Raw?) presentation. Cheers, Doru On Fri, Oct 3, 2014 at 6:19 PM, Ben Coman <btc(a)openinworld.com> wrote: > 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 > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 3, 2014

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

by Tudor Girba

Yes, I like "Raw". Thanks for the ping:). Anyone against "Raw"? Cheers, Doru On Fri, Oct 3, 2014 at 10:36 PM, stepharo <stepharo(a)free.fr> wrote: > Would it be possible to have 'raw' instead of state? > > Stef > > > 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" >> > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 3, 2014

Re: [Pharo-dev] playground size

by stepharo

Yes your use case make a lot of sense. > 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 > <mailto:sven@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 <mailto:Christophe.Demarey@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