October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] playground size

by Ben Coman

Tudor Girba 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 Why not use spotlight, allowing Cmd-d to work. Or would you want a bit more space? Maybe if you need a second line you could use Alt-<Enter> ? -ben > > On Fri, Oct 3, 2014 at 10:38 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@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 <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. >> >> >> > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 3, 2014

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

by Ben Coman

Tudor Girba wrote: > Yes, I like "Raw". Thanks for the ping:). > > Anyone against "Raw"? > > Cheers, > Doru > > Raw is good.

Oct. 3, 2014

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

by Thierry Goubier

Le 03/10/2014 21:48, stepharo a Ã©crit : > > On 3/10/14 17:07, Thierry Goubier 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...). > > Same here :) >> 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) > Why Athens would be unstable? > or nativeBoost? NativeBoost is not unstable for me, but why libcgit is on a bleeding edge NativeBoost version then? Athens is stable for me, but I believe that TxText requires a bleeding edge Athens. >> on top of an already unstable version (4.0), and I'm really not >> impressed by the software development process. > > what should it be? > You know Igor will not be paid in a month from now, JB should find a job > and esteban has two years to prove that the consortium flies. > So if we do not clean the event and windowing systems, rick and thales > will be in trouble. So we are fighting against time. Thales is not an easy customer :) I know; apart from parser know-how, there is nothing that I can sell outside (projects, etc..) about Pharo. And if I'm not successfull, then its no more Pharo for me. >> The end result is, when I see a bug, I'm already at least two versions >> behind you guys... > > Why. I do not get why Pharo 3 would be unstable and that far from Pharo 20. I'm on Pharo 3. Some of the stuff I'm interested is on Pharo 4 + bleeding edge version of core Pharo subsystem... two versions off from 3 for me. Libcgit is like that: its Pharo 4 + Bleeding edge native boost not yet in Pharo 4 + libcgit (and from ESUG, I get that it will require an entire refactoring of Monticello and a complete new on disk format). It's really shaping up like a long, long term target. >> 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. > > Thierry, > I do not have the impression that we go fast. > You see we started Athens more than two years ago. It is a success for > external tools like moose and Roassal but > without TxText Athens will just be a nice package not change the face of > Pharo and we will get there. I believe you're right about those; but I'd say that the way it's being done is a bit worrying. Why? Because for me, TxText is already more advanced than the current text editor: the ability to change the cursor, probably a better layout, etc... Should already been integrated, then, if its already better. But you still have the font bug that Alexandre complained about... how many months ago? So, as long as its not resolved, TxText can't be integrated (and additionally, I'm sure that there is aliasing issues on my machines: fonts in Roassal don't look as nice as in Morphic). And now, to make integration easier, we pile more stuff on top of the existing, bound to be removed, infrastructure: Glamour, Rubric, etc... And both Glamour and Spec don't make it easy to solve Morphic bugs. I value your ambition a lot :) But I also feel that it stresses the Rmod team, and it leaks over the community. > Writing the chapter and maintaining Smacc is already a nice tribute to > the community. Just continue that and we will be happy :) Thanks. John gave me plenty of fixes and I'm preparing a new version of SmaCC, and adding GUI tools (thinking of Guillaume needs and my needs as well). I certainly hope I'll be able to contribute on other things, still :) Thierry

Oct. 3, 2014

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