- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New Nautilus side bar buttons

by phil＠highoctane.be

I am not a compiler developer but I am interested in bytecodes. The whole set of buttons on that location should be a plugin area IMHO. So that we can easily extend it. NautilusPlugins enhancements would make for a great Pharo4 theme indeed. Phil On Fri, Mar 28, 2014 at 6:24 PM, MartinW <wm(a)fastmail.fm> wrote: > Just out of curiosity (this is not a rhetoric question, i just don't know > it) > - when should i look at the bytecode? > And are there enough use cases to justify such a very prominent place in > the > UI? > Or would a place in the context menu be enough? > Or a plugin, if there are people - like compiler developers - who need > these > buttons on a regular basis? > > > > > -- > View this message in context: > http://forum.world.st/New-Nautilus-side-bar-buttons-tp4751455p4751461.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 28, 2014

Re: [Pharo-dev] New Nautilus side bar buttons

by phil＠highoctane.be

Too bad, we'll have to wait for 4.0 (or 3.1 to get them...) Jokes aside, they are very nice. And I want them. Where is the slice? Phil On Fri, Mar 28, 2014 at 5:57 PM, Benjamin < Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Hello guys, > > since I do not really like the new buttons introduced in Nautilus, > and since the previous one were broken, I propose this new set > of buttons based on the eclipse theme. > > > Tell me what you think about it :) > Ben > >

March 28, 2014

Re: [Pharo-dev] New Nautilus side bar buttons

by MartinW

Just out of curiosity (this is not a rhetoric question, i just don't know it) - when should i look at the bytecode? And are there enough use cases to justify such a very prominent place in the UI? Or would a place in the context menu be enough? Or a plugin, if there are people - like compiler developers - who need these buttons on a regular basis? -- View this message in context: http://forum.world.st/New-Nautilus-side-bar-buttons-tp4751455p4751461.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 28, 2014

New Nautilus side bar buttons

by Benjamin

Hello guys, since I do not really like the new buttons introduced in Nautilus, and since the previous one were broken, I propose this new set of buttons based on the eclipse theme. Tell me what you think about it :) Ben

March 28, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Norbert Hartl

Am 28.03.2014 um 16:56 schrieb phil(a)highoctane.be: > Looks like a lot of people are going to be running patched versions if the release goes without some enhancements. > That is the road to never have a release. > What about a ConfigurationOfPharo30EnhancementsPackThatWereNotIntegratedForSomeSurelyVeryValidReason ? > > (Let's make the name shorter but you get the idea). > It is easy. It is called pharo 3.1 or pharo 4.0. The rule is: Donât change the current release being in freeze. Release it, change then everything you wanted in the next step and make sure you can release the next version pretty soon. IMHO the best solution to this kind of problems is to have small iterations. Norbert > > > > > On Fri, Mar 28, 2014 at 4:02 PM, Johan Brichau <johan(a)inceptive.be> wrote: > Hi all, > > With Sven's fixes loaded, our model unit tests are all running fine. The benchmarks indicate the same speed as in 1.4. This is really great! > I'm still running the entire suite of tests but that will take a while to complete. But essential datetime bugs should have been spotted already. > > Great work Sven! > I think it's worth integrating. If not, we will definitely work with this patched version. > > Johan > > On 28 Mar 2014, at 13:36, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > > Hi johan > > > > Please let us know because I would be in favor of integrating such speed up if your system fully work. > > > > stef > > > > > > On 28 Mar 2014, at 09:17, Johan Brichau <johan(a)inceptive.be> wrote: > > > >> > >> On 28 Mar 2014, at 06:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> > >>> Bugs are errors that prevents the system to run. > >> > >> <nagging> > >> Some performance problems make the system impossible to work with > >> </nagging> > >> > >> Anyway, going to check in Sven's changes today. > >> > >> cheers > >> Johan > >> > > > > > > >

March 28, 2014

Re: [Pharo-dev] Release Mode

by Norbert Hartl

Am 28.03.2014 um 16:17 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 28 Mar 2014, at 16:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 28 Mar 2014, at 15:52, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >>> While I was on holiday, it seems my dear friends have gone feature crazy... >>> almost as bad as me in the run up to the 2.0 release, ha ha. >>> >>> As cool as they are, are: >>> - changing the look of Nautilus buttons >>> - evaluate arbitrary expressions in Spotlight >>> - etc, etc >>> showstopping bugs?! >>> >>> This beta time is reserved specifically for finding the bugs that may >>> inevitably be introduced with these enhancements. We really may be creating >>> a mess, as end users find them in our "stable" release instead. >>> >> >> >> Yes, it was wrongâ¦ maybe we should revert. >> >> Marcus > > Yes, maybe ;-) > > I don't like the red (ish) / orange rectangle around dirty text areas (instead of the orange thing in the corner) - Where did that come from ? Did we discuss about that ? > > <Screen Shot 2014-03-28 at 16.14.56.png> > > PS: I marked the 'evaluate arbitrary expressions in Spotlight' not as a bug, but an enhancement, with would be nice priority, but indeed for 3.0 - but I certainly cannot blame Markus either - and BTW, there was a discussion about it, people tested it and nobody said no - and it is a perfectly safe change ;-) > There is no perfectly safe change. > PS2: I do have a bit of a problem with people being so vocally against changes, unless they are fixing the hard bugs themselves instead. If we all do nothing, the release won't get better, right ? > A release does not get better if you change non-bug related stuff while being in freeze. The only thing that happens is that you will postpone the release indefinite. This is such a basic thing that makes me wonder people are questioning at all. If you change the code the odds are high you break something. Doing that without taking the time to think about will make it worse. If a release is in sight there is emotionally not much time left so no time to think. The result: you break stuff. Just like that. You might then discuss (again) the rules for success or what is important or even more important or most important or more most important. That is subject for discussion and highly subjective. On the other hand there is a hard fact: you break things! Period. Norbert

March 28, 2014

Re: [Pharo-dev] Release Mode

by Benjamin

On 28 Mar 2014, at 17:30, Stephan Eggermont <stephan(a)stack.nl> wrote: > Philippe wrote >> The look of nautilus button isn't "ok to integrate" since there is much more work needed to get this working properly. > > Thatâs two different issues. One is integrated, the other not. > 13137 The SBIC buttons change is ok, afaik. No itâs not ok. It looks really bad, and really far from anything else Ben > 13135 exposes lotâs of issues in the tools. All kinds of off-by-ones in sizes. > > I also prefer the scrollbar fixes (13136) > > Stephan

March 28, 2014

Re: [Pharo-dev] Release Mode

by Stephan Eggermont

Philippe wrote >The look of nautilus button isn't "ok to integrate" since there is much more work needed to get this working properly. Thatâs two different issues. One is integrated, the other not. 13137 The SBIC buttons change is ok, afaik. 13135 exposes lotâs of issues in the tools. All kinds of off-by-ones in sizes. I also prefer the scrollbar fixes (13136) Stephan

March 28, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by Igor Stasenko

https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-diffe… On 28 March 2014 16:42, Igor Stasenko <siguctua(a)gmail.com> wrote: > so, the quick and dirty fix is to put: > > CairoGlyph class>>byteAlignment > > NativeBoost platformId = NativeBoostConstants win32PlatformId ifTrue: > [ ^ 8 ]. > ^ super byteAlignment > > and then: > > CairoGlyph rebuildFieldAccessors > CairoGlyphsArray initialize > > (note you must run this snippet each time your image changes platform).. > > and i need more time to fix it for real, because it is NB issue, to > automatically recalculate the structs size > if it changes platform.. (which also means you cannot store instances of > struct in image which survive the session) > ... damn.. that's going to be complicated. > > --- > > > > On 28 March 2014 16:27, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 28 March 2014 16:01, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> Ookkayy.. >>> so, current status: >>> >>> - finally we got an agreement that big red square because of font >>> loading issues and font rendering artifacts is two separate issues. >>> Thanks! >>> - i am not going to address font-loading issue here and now.. (because >>> we spent time on it earlier today with Stef already and you should have the >>> report on it in separate mail). >>> >>> - we seem to be agreed that it is best to use same (up-to-date version) >>> of software when reporting issues to work on them. Thanks again. :) >>> >>> - while on linux and mac things seem to be working fine, i can confirm >>> that there is rendering artifacts (same as reported by Vincent) on Windows. >>> >>> so i going to explore what causing this problem.. >>> >>> ... and found the cause: >> >> On windows, for unknown reason, the structure (cairo_glyph_t) uses >> different memory space alignment than on mac and linux >> >> fieldsDesc >> ^ #( >> ulong index; >> double x; >> double y; >> ) >> >> on mac and linux , the size of this structure in memory = 4 + 8 + 8 = 20 >> bytes, >> on windows, however, due to 8-byte alignment, it is 4 + 8 + 8 + (4 >> alignment) bytes... >> >> this causing the effect that if you copy array of glyphs in memory, >> it does not copying whole array by slightly less (because it uses wrong >> struct size which is smaller than it is).. >> and because of that, you got weird artefacts at the tail of string, >> replaced by misplaced/invalid characters etc.. >> because it is basically read from uninitialized part of memory with >> random data. >> >> i going to fix structure alignment for windows from default 4 bytes to 8 >> bytes.. >> but this is not very good news.. because this affecting many things... >> (as you can imagine, not only cairo/athens working with external >> structures, which need to be properly aligned). >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

March 28, 2014

Re: [Pharo-dev] Release Mode

by Stephan Eggermont

Sean wrote: >As cool as they are, are: >- changing the look of Nautilus buttons >showstopping bugs?! Yes. Or at least they should be. Releases are for new users. There the first impression is crucial. We are all used to these ugly buttons and know that the functionality is the same. New users donât know that and expect things that look different to behave differently. They are also important for people following new technologies trying to decide which ones to adopt. Not fixing these things essentially says our community is so resource-starved we cannot afford to spend time fixing such obvious mistakes. That is not the message I want to send with a new release. Stephan

March 28, 2014