- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Issue tracker] Help for reviewing needed

by Marcus Denker

On 05 Dec 2013, at 14:50, btc(a)openinworld.com wrote: > Marcus Denker wrote: >> Hello, >> >> Many people submit lots of nice things, which is greatâ¦ but not many people look at the issues. >> >> https://pharo.fogbugz.com/f/filters/45/Review >> >> Help would be appreciated. >> >> Marcus >> >> > Strangely, for me, that URL bounces to > > https://pharo.fogbugz.com/default.asp > > which shows the last filter that I was using. > Hmmâ¦ so then I will stop to send urls of fogbugz. Itâs a shared filterâ¦ Marcus

Dec. 5, 2013

Re: [Pharo-dev] [Issue tracker] Help for reviewing needed

by Benjamin

I think it depends if you use the new version of the website or not Use this link if the first one do not work https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=45 Ben On 05 Dec 2013, at 14:49, btc(a)openinworld.com wrote: > Marcus Denker wrote: >> Hello, >> >> Many people submit lots of nice things, which is greatâ¦ but not many people look at the issues. >> >> https://pharo.fogbugz.com/f/filters/45/Review >> >> Help would be appreciated. >> >> Marcus >> >> > Strangely, for me, that URL bounces to > > https://pharo.fogbugz.com/default.asp > > which shows the last filter that I was using. > > cheers -ben > >

Dec. 5, 2013

Re: [Pharo-dev] [Issue tracker] Help for reviewing needed

by btc＠openinworld.com

Marcus Denker wrote: > Hello, > > Many people submit lots of nice things, which is greatâ¦ but not many people look at the issues. > > https://pharo.fogbugz.com/f/filters/45/Review > > Help would be appreciated. > > Marcus > > Strangely, for me, that URL bounces to https://pharo.fogbugz.com/default.asp which shows the last filter that I was using. cheers -ben

Dec. 5, 2013

Referencing other cases in Fogbugz

by btc＠openinworld.com

Torsten, I see that you commented on [1] to refer to another case. Thanks for that. btw, if you type "case 12121" rather than "issue 12121" it will: * create a hot-link to the target case * add the target case in the sidebar. * add a back-link in the sidebar of the target case I've updated [1] as an example. [1] https://pharo.fogbugz.com/default.asp?11562 cheers -ben

Dec. 5, 2013

Referencing other cases in Fogbugz

by btc＠openinworld.com

Torsten, I see that you commented on [1] to refer to another Case. Thanks for that. btw, if you type "case 12121" rather than "issue 12121" it will create a hot-link, and also add the case in the sidebar. cheers -ben

Dec. 5, 2013

Re: [Pharo-dev] Open vs Closed issues visualised

by kilon alios

2000 issues were closed ? wow I find that hard to believe , but if you say its true then its true 2000 issues , oh boy !!! Unbelievable !!! Looks like Pharo is way more active than I thought it is. Great news. On Thu, Dec 5, 2013 at 12:23 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 05 Dec 2013, at 10:50, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > Does that mean we closed around 2000 issues since May ? > yes. > > > And all the time there were around 100 issues opened ? > > > yes, and all of that difference was moving the issues from the unused cog > issue tracker > (which have seen 0 activity sinceâ¦). > > Else we would have less open issues than in May. > > Marcus >

Dec. 5, 2013

Re: [Pharo-dev] Open vs Closed issues visualised

by Marcus Denker

On 05 Dec 2013, at 10:50, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Does that mean we closed around 2000 issues since May ? yes. > And all the time there were around 100 issues opened ? > yes, and all of that difference was moving the issues from the unused cog issue tracker (which have seen 0 activity sinceâ¦). Else we would have less open issues than in May. Marcus

Dec. 5, 2013

Re: [Pharo-dev] Open vs Closed issues visualised

by ClÃ©ment Bera

Does that mean we closed around 2000 issues since May ? And all the time there were around 100 issues opened ? 2013/12/5 Marcus Denker <marcus.denker(a)inria.fr> > start is may this year... >

Dec. 5, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Max Leske

On 05.12.2013, at 10:12, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 05 Dec 2013, at 7:48 , Max Leske <maxleske(a)gmail.com> wrote: > >> Thanks for the input. >> >> The problem with ReadStream and WriteStream is that they (at least in 2.0 and 3.0) never supported switching in the first place. #binary and #ascii simply answer self. That means the collection the stream operates on predetermines the output. Iâve noticed a couple of different approaches to solving this problem in the way that streams are used throughout the image and I want to make a list of those to see if thereâs some kind of pattern that maybe leads to an acceptable version with little changes as opposed to an optimal version where we have to change a lot of the implemenation details of streams. >> >> Cheers, >> Max > > In my experience, the legacy solution for swapping binary/ascii writing to in-memory collections is using a (MultiByte)BinaryOrTextStream instead of a standard ReadWriteStream. Youâre right. I had thought about simply using RWBinaryOrTextStream instead of ReadStream in MemoryFileSystem but that felt like committing a crimeâ¦ :) > > Cheers, > Henry > > P.S. In fact, that class is pretty much the ultimate example of why the XTreams approach is superior. > It *looks* like itâs interchangeable with (MultiByte)FileStream, but the implementations are completely independent, and thus a subtle set of differences are bound to exist. (and do, but I canât remember exactly which atm) > Maintaining and bug fixing either is a nightmare, and introducing further divergence bugs in the long run is pretty much inevitable. > > Much better to composite singly implemented, single purpose wrappers streams on top of dumb terminals for each destination type to achieve desired input -> output transformations. > >

Dec. 5, 2013

Open vs Closed issues visualised

by Marcus Denker

start is may this year...

Dec. 5, 2013