- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Playground

by Ben Coman

Marcus Denker wrote: > > On 03 Oct 2014, at 12:46, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > >> >> On 03 Oct 2014, at 12:21, phil(a)highoctane.be >> <mailto:phil@highoctane.be> wrote: >> >>> Frankly, I see fogbugz issues closed with some ignore/cannot >>> reproduce status, so, I am not creating any of them anymore. Why >>> bother, except for blocking bugs? It takes time to even look at an issue, the first attempt to reproduce it as a prelude to attacking it. If it cannot be reproduced and is just left open, the second developer comes along later and it consumes their time to do the same, and again later the third developer that comes along. This is "bug bankruptcy" per... http://www.joelonsoftware.com/items/2012/07/09.html Now I looked and see I have 50 tickets open, which shocked myself. It seems I forgot about them and its not taking effort even to revisit my OWN tickets to evaluate if they are still relevant, or can be reproduced - let alone someone else doing this. So perhaps we should consider Fogbugz less a "bug-notification" database but more a "bug-report" database, with good reproducible steps or proposed solutions. Now it is a balancing act, since my natural tendency is to want to make a placeholder to collaborate with others who might experience the same problem, but in practice that doesn't seem to occur a lot. -ben >>> >> Tell me: What is the difference between a bug that it fixed and one >> that can not be reproduced? > > I wonder if people have an idea of the scale of thingsâ¦ > > - We closed 107 issues the last 7 days > - there are 618 open issues > - There where 11268 issues reported for Pharo since we started. > > So when I look at an issue i try to reproduce it. If I can not, I close > it. Else this is not possible to do, sorry. Even if I wanted to: If we keep > all non-reproducible cases open we soon will be paralysed. (And that by > issues that to 99% are fixed). > > Marcus >

Oct. 4, 2014

gt issues

by Tudor Girba

Hi, >From the feedback so far, I could not the following issues: - menus for copy/paste/cut (which I still wonder why they need to exist for a developer, but we will add them) - possibility of save/open - Cmd+g instead of Cmd+o (already fixed) - position of the cursor is sometimes messed up - possibility to change the title of the Playground - possibility to group the windows (this will likely not be fixed in the same way) (did I miss any?) - icons and text background are not ready for the dark theme Did I miss anything? Could the people that want to see any of these issues done open tickets for them? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Oct. 4, 2014

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

by Tudor Girba

Hi Ben, On Sat, Oct 4, 2014 at 7:27 AM, Ben Coman <btc(a)openinworld.com> wrote: > Tudor Girba wrote: > >> Hi, >> >> Indeed, you are right about noting that the situation will look different >> in a couple of months from now. Please, let's discuss these problems again >> in 2 months. >> > > > My point was not to delay discussion, but just not let it get you down and > be tolerant... > * For those sending criticism, of the system being in flux as in > progresses. > * For those receiving criticism, when its comes from those using the > bleeding edge because of their faith in Pharo > * For third parties looking on, be confident that it will come together > for the release. I am not asking for delaying the discussion about the tools. I am simply saying that the situation will be much different in a couple of months after we have a chance of taking the feedback into account (already quite some changes were made and more are under way, like the menu). As a consequence, we should evaluate the need of having them in parallel with other tools at that time not now. > > The classic tools are still around. Furthermore, in the Settings, you >> have a Glamorous Toolkit category which allows you to switch the Inspector >> and the Playground off. >> > > > How hard would it be to run some parts of GToolkit in parallel with > existing tools, rather than on/off? I'd rather it stare me in the face > without boxing me in - to help me adapt in my own time. I tend to forget > about things I need to change a setting for. > It's not hard at all, but I believe it would defeat the purpose of the exercise at this point. First, I believe the problems being reported are actually minor and we should not overreact. Bare in mind that people mostly reacted to missing features, and not bugs (except for the messed up positioning of the cursor during completion) which is quite encouraging given the magnitude of the change. Second, when working on the latest version you want to exercise the new, not the old. The more options you allow to fallback to the old, the less stress will be applied on the new. And especially given that we are a small community, and that only a fraction of us actually works with the latest version, it would be highly unproductive to not focus on the new. Cheers, Doru > -ben > > > Cheers, >> Doru >> >> >> >> On Sat, Oct 4, 2014 at 2:30 AM, Ben Coman <btc(a)openinworld.com <mailto: >> btc(a)openinworld.com>> wrote: >> >> Thierry Goubier wrote: >> >> 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. >> >> >> Remember, this Pharo 4 is alpha status. I think we had similar >> discussions about this time last year with Pharo 3, and it shaped up >> really well for release. >> >> >> >> 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. >> >> >> What are the plans to integrate TxText? By which I mean, what will >> be the staging for refactoring existing tools on top of it? It seems >> the path of Opal where (I think) it was in one Release before it was >> fully enabled worked well. >> >> Now I know that GTools have been used in Moose for a long time, but >> its integration to Pharo REPLACING Workspace has been a cultural >> shock to those that haven't used it before (myself included, though >> I'm lookign forward to adapting). I think there'll be similar >> culture shock when Pharo 4 is released, from those that don't follow >> the bleeding edge. I'd strongly suggest that GTools operate for ONE >> release alongside existing tools, as an additional item in the first >> level World menu next to 'Workspace'. >> >> Indeed, even if Playground is quite stable through long use in >> Moose, it is new to Pharo, and marking its menu entry as >> 'Experimental' for now might provide some benefits. >> >> * This may provide a to stress test new evolving frameworks like >> TxText & Rubric - without affecting existing tools. >> >> * Now Playground has a wider community exposure, feedback from new >> users is likely to be less pressure and less negative if they still >> have access to old tools. >> >> * Feedback may result in changes. >> >> * Reduced culture shock. Builds confidence in a stable system not >> going "too fast" but just "fast enough" (very subjective I know). >> >> -ben >> >> >> 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 >> >> >> >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" >> > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 4, 2014

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

by Ben Coman

Tudor Girba wrote: > Hi, > > Indeed, you are right about noting that the situation will look > different in a couple of months from now. Please, let's discuss these > problems again in 2 months. My point was not to delay discussion, but just not let it get you down and be tolerant... * For those sending criticism, of the system being in flux as in progresses. * For those receiving criticism, when its comes from those using the bleeding edge because of their faith in Pharo * For third parties looking on, be confident that it will come together for the release. > The classic tools are still around. Furthermore, in the Settings, you > have a Glamorous Toolkit category which allows you to switch the > Inspector and the Playground off. How hard would it be to run some parts of GToolkit in parallel with existing tools, rather than on/off? I'd rather it stare me in the face without boxing me in - to help me adapt in my own time. I tend to forget about things I need to change a setting for. -ben > Cheers, > Doru > > > On Sat, Oct 4, 2014 at 2:30 AM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > Thierry Goubier wrote: > > 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. > > > Remember, this Pharo 4 is alpha status. I think we had similar > discussions about this time last year with Pharo 3, and it shaped up > really well for release. > > > > 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. > > > What are the plans to integrate TxText? By which I mean, what will > be the staging for refactoring existing tools on top of it? It seems > the path of Opal where (I think) it was in one Release before it was > fully enabled worked well. > > Now I know that GTools have been used in Moose for a long time, but > its integration to Pharo REPLACING Workspace has been a cultural > shock to those that haven't used it before (myself included, though > I'm lookign forward to adapting). I think there'll be similar > culture shock when Pharo 4 is released, from those that don't follow > the bleeding edge. I'd strongly suggest that GTools operate for ONE > release alongside existing tools, as an additional item in the first > level World menu next to 'Workspace'. > > Indeed, even if Playground is quite stable through long use in > Moose, it is new to Pharo, and marking its menu entry as > 'Experimental' for now might provide some benefits. > > * This may provide a to stress test new evolving frameworks like > TxText & Rubric - without affecting existing tools. > > * Now Playground has a wider community exposure, feedback from new > users is likely to be less pressure and less negative if they still > have access to old tools. > > * Feedback may result in changes. > > * Reduced culture shock. Builds confidence in a stable system not > going "too fast" but just "fast enough" (very subjective I know). > > -ben > > > 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 > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 4, 2014

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

by Tudor Girba

Hi, Indeed, you are right about noting that the situation will look different in a couple of months from now. Please, let's discuss these problems again in 2 months. The classic tools are still around. Furthermore, in the Settings, you have a Glamorous Toolkit category which allows you to switch the Inspector and the Playground off. Cheers, Doru On Sat, Oct 4, 2014 at 2:30 AM, Ben Coman <btc(a)openinworld.com> wrote: > Thierry Goubier wrote: > >> 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. >> > > Remember, this Pharo 4 is alpha status. I think we had similar > discussions about this time last year with Pharo 3, and it shaped up really > well for release. > > > >> 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. >> >> > What are the plans to integrate TxText? By which I mean, what will be the > staging for refactoring existing tools on top of it? It seems the path of > Opal where (I think) it was in one Release before it was fully enabled > worked well. > > Now I know that GTools have been used in Moose for a long time, but its > integration to Pharo REPLACING Workspace has been a cultural shock to those > that haven't used it before (myself included, though I'm lookign forward to > adapting). I think there'll be similar culture shock when Pharo 4 is > released, from those that don't follow the bleeding edge. I'd strongly > suggest that GTools operate for ONE release alongside existing tools, as an > additional item in the first level World menu next to 'Workspace'. > > Indeed, even if Playground is quite stable through long use in Moose, it > is new to Pharo, and marking its menu entry as 'Experimental' for now might > provide some benefits. > > * This may provide a to stress test new evolving frameworks like TxText & > Rubric - without affecting existing tools. > > * Now Playground has a wider community exposure, feedback from new users > is likely to be less pressure and less negative if they still have access > to old tools. > > * Feedback may result in changes. > > * Reduced culture shock. Builds confidence in a stable system not going > "too fast" but just "fast enough" (very subjective I know). > > -ben > > > 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 >> >> >> > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 4, 2014

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

by Ben Coman

Thierry Goubier wrote: > 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. Remember, this Pharo 4 is alpha status. I think we had similar discussions about this time last year with Pharo 3, and it shaped up really well for release. > > 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. > What are the plans to integrate TxText? By which I mean, what will be the staging for refactoring existing tools on top of it? It seems the path of Opal where (I think) it was in one Release before it was fully enabled worked well. Now I know that GTools have been used in Moose for a long time, but its integration to Pharo REPLACING Workspace has been a cultural shock to those that haven't used it before (myself included, though I'm lookign forward to adapting). I think there'll be similar culture shock when Pharo 4 is released, from those that don't follow the bleeding edge. I'd strongly suggest that GTools operate for ONE release alongside existing tools, as an additional item in the first level World menu next to 'Workspace'. Indeed, even if Playground is quite stable through long use in Moose, it is new to Pharo, and marking its menu entry as 'Experimental' for now might provide some benefits. * This may provide a to stress test new evolving frameworks like TxText & Rubric - without affecting existing tools. * Now Playground has a wider community exposure, feedback from new users is likely to be less pressure and less negative if they still have access to old tools. * Feedback may result in changes. * Reduced culture shock. Builds confidence in a stable system not going "too fast" but just "fast enough" (very subjective I know). -ben >> 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. 4, 2014

New Cog VMs available

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r3095/. CogVM binaries as per VMMaker.oscog-eem.890/r3095 Fix line-buffered input in sqFilePluginBasicPrims.c when buffer size > 1. fread cannot be relied upon to answer lines. Fix bug in Cogit>>lookup:for:methodAndErrorSelectorInto: which if cogging a method found through an MNU would set the cog method's selector to the original selector that was not understood instead of #doesNotUnderstand:. Fix the description of the blockonwarn flag (not blockonwarning). Spur: Fix one-way become for classes with and without copyHash, primarily by fixing allInstances. One-way become for classes causes duplicates in the class table (either that or an allInstances scan would be needed as part of the become to change instances referring to the deleted class index, which would be slow). So allInstances must be able to cope with duplicates. Hence split it into a fast path common case when the class in question is not duplicated, and a slower path when it is. Make both the marking phase of GC and allInstances check for and eliminate refereces to duplicate entries at wrong/obsolete class indices. Fix markAndShouldScan: to not scan the pun classes of non-objects on the heap such as implicit receiver caches and Sista counters. Eliminate the classTableBitmap premature optimization. All the information we need is in the cassTable and the class's hashes therein. Change pinObject: to answer 0 on failure and the (possibly moved) object on success. Much easier than having to check and follow forwarding pointer. The changes to platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c in r3092 in a Spur MT VM depend on this. -- best, Eliot

Oct. 4, 2014

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