May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [QUESTION] For Dark Theme users

by Andrei Chis

On Mon, May 4, 2015 at 11:31 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > @esteban, as you are working on dark theme, can you take a look at this > issue > 14923 <https://pharo.fogbugz.com/default.asp?14923> > TextAdornment: take account of current theme background color > > I am not sure what is the right way to solve this for rubric, and even if > I would know it, > I can not commit to rubrics repository :) > Rubric repo is now under the Pharo team (Pharo/Rubric) Cheers, Andrei > > > > 2015-05-02 10:24 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On 02 May 2015, at 04:10, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> >> wrote: >> >> This is maybe a little 'too' dark. >> Maybe we can do a setting to choose if we want it more or less dark. >> >> >> yes, but we also need a good default, because most people will not tune >> their system until they are used to it :) >> So, I think we need to restore the âpreference theme settingsâ options >> (another brick in the wallâ¦ I mean another todo entry in my list) >> And in the mean time I will chose something between current and my >> proposal (because Iâm convinced current one does not offer good contrast). >> >> Esteban >> >> >> An other think that would be good with the dark theme is to change the >> color of the Test Runner because the fluo green attack the eyes when we're >> on the dark theme x_x. >> >> Since we talk about the dark theme, is that normal than the background of >> the RubScrolledTextMorph stay white ? Or should I use an other Rub text >> morph ? >> >> On 1 May 2015 at 13:52, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> >>> Dawn Theme is lighter actually. >>> >>> As long as it is not black ... >>> >>> Phil >>> Le 1 mai 2015 12:34, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : >>> >>>> I suppose "Down Themeâ users (cough, cough, Phil) too. >>>> >>>> I want to change the background color for something even darker: >>>> >>>> <Screen Shot 2015-05-01 at 12.33.48.png> >>>> >>>> >>>> >>>> I think it look betterâ¦ what do you think? >>>> >>>> (Alsoâ¦ I need to refactor this theme thingyâ¦ is really ugly :P) >>>> >>>> Esteban >>>> >>> >> >> >> -- >> Cheers >> Cyril Ferlicot >> >> >> >

May 4, 2015

watcher window ?

by Nicolai Hess

What is a watcher window ? (UITheme>>#watcherWindowActiveFillStyleFor: aWindow) The only sender is GLMWatcherWindow, but the theme setting is in package Polymorph-Widgets, not in a glamour extension.

May 4, 2015

Re: [Pharo-dev] [QUESTION] For Dark Theme users

by Nicolai Hess

@esteban, as you are working on dark theme, can you take a look at this issue 14923 <https://pharo.fogbugz.com/default.asp?14923> TextAdornment: take account of current theme background color I am not sure what is the right way to solve this for rubric, and even if I would know it, I can not commit to rubrics repository :) 2015-05-02 10:24 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 02 May 2015, at 04:10, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > This is maybe a little 'too' dark. > Maybe we can do a setting to choose if we want it more or less dark. > > > yes, but we also need a good default, because most people will not tune > their system until they are used to it :) > So, I think we need to restore the âpreference theme settingsâ options > (another brick in the wallâ¦ I mean another todo entry in my list) > And in the mean time I will chose something between current and my > proposal (because Iâm convinced current one does not offer good contrast). > > Esteban > > > An other think that would be good with the dark theme is to change the > color of the Test Runner because the fluo green attack the eyes when we're > on the dark theme x_x. > > Since we talk about the dark theme, is that normal than the background of > the RubScrolledTextMorph stay white ? Or should I use an other Rub text > morph ? > > On 1 May 2015 at 13:52, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > >> Dawn Theme is lighter actually. >> >> As long as it is not black ... >> >> Phil >> Le 1 mai 2015 12:34, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : >> >>> I suppose "Down Themeâ users (cough, cough, Phil) too. >>> >>> I want to change the background color for something even darker: >>> >>> <Screen Shot 2015-05-01 at 12.33.48.png> >>> >>> >>> >>> I think it look betterâ¦ what do you think? >>> >>> (Alsoâ¦ I need to refactor this theme thingyâ¦ is really ugly :P) >>> >>> Esteban >>> >> > > > -- > Cheers > Cyril Ferlicot > > >

May 4, 2015

Re: [Pharo-dev] build pharo vm on windows (old mingw package)

by Nicolai Hess

FINALLY! Got it working. I took another mingw distribution from http://tdm-gcc.tdragon.net/ (installer version tdm-gcc-4.7.1-2.exe) With mingwsys from my previos mingw installation. The gcc version this distribution uses: Using built-in specs. COLLECT_GCC=c:\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.1/lto-wrapper.exe Target: mingw32 Configured with: ../../src/gcc-4.7.1/configure --build=mingw32 --enable-languages=c,c++,ada,fortran,objc,obj-c++ --enable-threads=win32 --enable-libgomp --enable-lto --enable-fully-dynamic-string --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gnu-ld --disable-nls --disable-win32-registry --disable-symvers --disable-build-poststage1-with-cxx --disable-werror --prefix=/mingw32tdm --with-local-prefix=/mingw32tdm --enable-cxx-flags='-fno-function-sections -fno-data-sections' --with-pkgversion=tdm-1 --enable-sjlj-exceptions --with-bugurl=http://tdm-gcc.tdragon.net/bugs Thread model: win32 gcc version 4.7.1 (tdm-1) All is working now, no crash on startup, no missing dependencies to the mingw runtime. 2015-05-04 0:06 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > Or what is the output of > depends libfreetype-6.dll > > 2015-05-03 23:47 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> No SDL2? >> >> This is want depends shows for me. >> (but it is the same output as for the vm from the build server - and that >> one >> works). There is a dependency on libgcc_s_dw2-1.dll, only for some >> modules that are >> loaded at runtime. Can you rename your mingw installation directory and >> start pharo (and look that >> freetype/cairo/SDL are loadable? >> >> thank you for your help :) >> >> >> 2015-05-03 22:56 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >>> [image: Inline image 1] >>> >>> >>> Pharo.exe - 5 363 606 bytes >>> >>> Phil >>> >>> >>> On Sun, May 3, 2015 at 1:17 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>>> >>>> >>>> 2015-05-01 23:05 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>> >>>>> Did you tried this ? >>>>> >>>>> https://github.com/pharo-project/pharo-vm/blob/master/README-Win32.md >>>>> >>>>> (I wrote that thing a while ago). >>>>> >>>>> >>>>> http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/m… >>>>> was where I got the env from. >>>>> >>>>> I've got a PharoVM built with gcc 4.8.1 >>>>> >>>> >>>> Can you check that this vm does not depend on the mingw runtime. >>>> (I managed to create a vm that opens, but if I start this without the >>>> mingw installation directory in my path, >>>> I get the following error: >>>> libgcc_s_dw2-1.dll is missing ) >>>> >>>> The vm from the build server works even without a local mingw >>>> installation. >>>> >>>> >>>>> >>>>> Uploading the thing in dropbox. >>>>> >>>>> Will send a link when done. >>>>> >>>>> Phil >>>>> >>>>> >>>>> On Fri, May 1, 2015 at 9:04 PM, Nicolai Hess <nicolaihess(a)web.de> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> 2015-04-30 11:33 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>> >>>>>>> arenât you able to install an older version of gcc in your newer >>>>>>> version of mingw? >>>>>>> >>>>>> >>>>>> hm, downgrading the compiler was suprisingly easy. But I have still >>>>>> the same error. >>>>>> This is the gcc version information: >>>>>> >>>>>> Using built-in specs. >>>>>> COLLECT_GCC=c:\MinGW\bin\gcc.exe >>>>>> >>>>>> COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe >>>>>> Target: mingw32 >>>>>> Configured with: ../gcc-4.6.2/configure >>>>>> --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions >>>>>> --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry >>>>>> --enable-libstdcxx-debug --enable-version-specific-runtime-libs >>>>>> --build=mingw32 --prefix=/mingw >>>>>> Thread model: win32 >>>>>> gcc version 4.6.2 (GCC) >>>>>> >>>>>> >>>>>> Anyone knows what could be the problem ? Stacktrace from the crash, >>>>>> this happens >>>>>> directly after the start: >>>>>> >>>>>> #0 0x772359dd in ntdll!RtlpNtMakeTemporaryKey () >>>>>> from C:\Windows\system32\ntdll.dll >>>>>> #1 0x77201d8f in ntdll!EtwSetMark () from >>>>>> C:\Windows\system32\ntdll.dll >>>>>> #2 0x77236a37 in ntdll!RtlpNtMakeTemporaryKey () >>>>>> from C:\Windows\system32\ntdll.dll >>>>>> #3 0x771fa3ef in ntdll!EtwSetMark () from >>>>>> C:\Windows\system32\ntdll.dll >>>>>> #4 0x771c6766 in wcsnicmp () from C:\Windows\system32\ntdll.dll >>>>>> #5 0x76cdc484 in KERNEL32!HeapFree () from >>>>>> C:\Windows\system32\kernel32.dll >>>>>> #6 0x6c24c4d7 in free () from C:\Windows\system32\crtdll.dll >>>>>> #7 0x00850000 in ?? () >>>>>> #8 0x00542065 in glob_match () >>>>>> #9 0x00542604 in __mingw_glob () >>>>>> #10 0x00540f17 in _setargv () >>>>>> #11 0x004011ca in __mingw_CRTStartup () >>>>>> #12 0x004012d5 in WinMainCRTStartup () >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> nicolai >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I do not have time right now to update the build into a new >>>>>>> compiler, sorry (also, that is not always trivial/desired, he) >>>>>>> >>>>>>> Esteban >>>>>>> >>>>>>> > On 30 Apr 2015, at 08:38, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>>>>> > >>>>>>> > I managed to trash my mingw build environment >>>>>>> > -> uninstalled /removed mingw/mingsys >>>>>>> > -> reinstall from current mingw-installer >>>>>>> > -> bad idea >>>>>>> > >>>>>>> > I can build a pharo windows vm but it immediately crashes on >>>>>>> startup. I suspect >>>>>>> > some changes between gcc 4.6 (old environment) gcc 4.8 (new >>>>>>> environment). >>>>>>> > (I think there are some changes related to file globbing (I >>>>>>> managed to get >>>>>>> > the vm somehow working to not crash on startup but on shutdown >>>>>>> instead - with >>>>>>> > _CRT_glob = 0. And gcc-4.8 uses dfferent (dwarf vs. sjlj ) >>>>>>> exception handling, don't know if this is >>>>>>> > related). >>>>>>> > >>>>>>> > I tried to find a ming-installer for the old version but could not >>>>>>> find anything and >>>>>>> > I tried to manually setup a ming installation from the old >>>>>>> packages (dozen of packages >>>>>>> > for mingw / core-utils / bintutils /msys from different places (no >>>>>>> fun)). >>>>>>> > >>>>>>> > 1) did anyone get a windows vm from mingws current version (with >>>>>>> gcc 4.8) working? >>>>>>> > >>>>>>> > 2) can someone package/zip and upload an old mingw installation >>>>>>> (maybe that one that >>>>>>> > is used on the build server? >>>>>>> > >>>>>>> > >>>>>>> > regards >>>>>>> > nicolai >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >> >

May 4, 2015

Re: [Pharo-dev] Roassal3D and Woden process handling

by Alexandre Bergel

Hi Yuriy! I gave a try to fix the problem. Now, if the rendered is left untouched, there is no unnecessary refresh. The problem now is that the keystrokes are not properly handledâ¦ Can you give you try please? Does this solve your problem? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On May 4, 2015, at 12:09 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Sadly, Iâm not very experienced in that topic. I just looked at CodeCity running on my colleagueâs matching and syntax highlighting working. The view is also subclassing GLViewportMorph, but other than that I canât tell why CodeCity is not blocking the other processes. > > Uko > >> On 04 May 2015, at 16:47, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: >> >> >> >> On Mon, May 4, 2015 at 4:16 PM, Ronie Salgado <roniesalg(a)gmail.com <mailto:roniesalg@gmail.com>> wrote: >> Hi Yuriy, >> >> Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk green threads, for the following reasons: >> - Operating system Thread Local Storage is not respected. The current OpenGL is a thread local variable. >> - No completely preemptive. >> >> Making Woden and Woden-Roassal to have a lower priority is a problem, because of reduced performance in Woden. When using OpenGL, the functions glFinish or SwapBuffers has to be called to force the execution of commands an display the rendered image in the screen. SwapBuffers usually calls glFlush. And if, v-sync is enabled, it blocks, which does not get well Pharo. >> >> With OSWindow, OpenGL can also be used to render the main Pharo window via SDL2. Because of this, I had to introduce a rendering process in OSWindow, which I am using to serialize all the OpenGL commands. And I guess that it also produces a reduction in performance. This thread is located OSWindowRenderThread. >> >> Perhaps you can fix the problem somewhere in OSWindowRenderThread. >> >> >> Not having had a look, I suppose that this is a green thread in Pharo. >> >> Why not having a real OS thread doing the glFinish/SwapBuffers instead? >> and some OpenGL ThreadLocal interface? >> >> >> I am facing a kind of similar situation for another project. >> >> My current line of thought is that the best stable/fast thing is to have the 3D engine as a separate process (as in a true OS process) to which I do send high level commands. >> >> Of course, this makes it necessary to have a DSL to talk with and that extending the 3D engine is somewhat of a pain when in need of new commands. >> >> But it allows to do whatever I want in Pharo without blocking the rendering loop. >> >> What would be the design you'd like to see for Woden, Ronie? >> >> Phil >> >> >> Best regards, >> Ronie >> >> >> 2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: >> Hi! >> >> This is an excellent question. Ronie? >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> Hi guys, >>> >>> Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes? >>> >>> Uko >> >> >> >> >> >> -- >> >> >

May 4, 2015

FreeType fonts and underline/strikethrough emphasis

by Nicolai Hess

Some questions: - Did this ever work ? - We have some code for drawing the underline/strikethrough, but it is only used for tree and listrenderer (and AFAIK only checks the first text entry element for the used emphasis) - setting the emphasis on LogicalFont is only propagated to the realfont if emphasis is bold or italic, others like underline and strikethrough are ignored with the comment: "we only handle bold and italic here since underline/strikeout are drawn separately" I don't want to move this display underline/strikethrough code into LogicalFont if it was removed on purpose. other ideas how to handle this? (see issue 15362 <https://pharo.fogbugz.com/default.asp?15362> No "underline" or "stroke out" emphasis on FT fonts) nicolai

May 4, 2015

Re: [Pharo-dev] [SURVEY] Code Critics Usage

by Alexandre Bergel

Done! -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On May 4, 2015, at 12:41 PM, Jigyasa Grover <grover.jigyasa1(a)gmail.com> wrote: > > Done ! > > On Mon, May 4, 2015 at 9:47 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Dear Pharo developers, > > I kindly ask you to participate in the Code Critics mini-survey: https://www.esurveycreator.com/s/8af18d8 <https://www.esurveycreator.com/s/8af18d8>. > It will take only a coupe minutes of your time (or less), and will give us the better understanding of how Code Critics are currently used and how to improve them. > > Cheers! > Yuriy >

May 4, 2015

Re: [Pharo-dev] [SURVEY] Code Critics Usage

by Jigyasa Grover

Done ! On Mon, May 4, 2015 at 9:47 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Dear Pharo developers, > > I kindly ask you to participate in the Code Critics mini-survey: > https://www.esurveycreator.com/s/8af18d8. > It will take only a coupe minutes of your time (or less), and will give us > the better understanding of how Code Critics are currently used and how to > improve them. > > Cheers! > Yuriy >

May 4, 2015

Package comments

by Kasper Osterbye

In the Nautilus browser I have been working a bit on allowing Pillar for class comments. When browsing that part of Nautilus, I notice that there are some hooks for package comments in the getComments and addComments methods. Is there a history of "package comments" somewhere in the system? I was not able to find anything like that. Also it does not seem like there are any fields in the hierarchy of MBInfo that has anything to do with documentation. Is that the case? -- View this message in context: http://forum.world.st/Package-comments-tp4824353.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 4, 2015

Re: [Pharo-dev] Roassal3D and Woden process handling

by Alexandre Bergel

Hi Phil, There are different efforts going on here: - Woden, as far as I understand, is about having a fast platform to make game. This is a very valuable effort, however it takes time to reach this. And indeed, green threads seems to have its limitations. - Roassal3d, which is about visualizing data in 3d. We are slowly getting back to Roassal 3d (now that the Roassal 2d front is more quite, due to the stability of it). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On May 4, 2015, at 10:47 AM, phil(a)highoctane.be wrote: > > > > On Mon, May 4, 2015 at 4:16 PM, Ronie Salgado <roniesalg(a)gmail.com <mailto:roniesalg@gmail.com>> wrote: > Hi Yuriy, > > Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk green threads, for the following reasons: > - Operating system Thread Local Storage is not respected. The current OpenGL is a thread local variable. > - No completely preemptive. > > Making Woden and Woden-Roassal to have a lower priority is a problem, because of reduced performance in Woden. When using OpenGL, the functions glFinish or SwapBuffers has to be called to force the execution of commands an display the rendered image in the screen. SwapBuffers usually calls glFlush. And if, v-sync is enabled, it blocks, which does not get well Pharo. > > With OSWindow, OpenGL can also be used to render the main Pharo window via SDL2. Because of this, I had to introduce a rendering process in OSWindow, which I am using to serialize all the OpenGL commands. And I guess that it also produces a reduction in performance. This thread is located OSWindowRenderThread. > > Perhaps you can fix the problem somewhere in OSWindowRenderThread. > > > Not having had a look, I suppose that this is a green thread in Pharo. > > Why not having a real OS thread doing the glFinish/SwapBuffers instead? > and some OpenGL ThreadLocal interface? > > > I am facing a kind of similar situation for another project. > > My current line of thought is that the best stable/fast thing is to have the 3D engine as a separate process (as in a true OS process) to which I do send high level commands. > > Of course, this makes it necessary to have a DSL to talk with and that extending the 3D engine is somewhat of a pain when in need of new commands. > > But it allows to do whatever I want in Pharo without blocking the rendering loop. > > What would be the design you'd like to see for Woden, Ronie? > > Phil > > > Best regards, > Ronie > > > 2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: > Hi! > > This is an excellent question. Ronie? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> Hi guys, >> >> Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes? >> >> Uko > > > > > > -- > >

May 4, 2015