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

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

by Benjamin

On 01 Apr 2014, at 14:01, Stephan Eggermont <stephan(a)stack.nl> wrote: > Ah, thatâs easy. > Putting them into a plugin is left as an exercise for the reader. As well as implementing the support for plugin on sides and not only top/middle/bottom Remind me a lot of lectures I had: âToday we will see how to go on the Moon. â¦ This was how to fill up the tank, the rest is left as an exerciseâ Ben

April 1, 2014

Re: [Pharo-dev] PharoVM on Windows & Code::Blocks for debugging

by phil＠highoctane.be

Ok. I was working from my fork. Needs to pull on some new stuff. Phil Le 1 avr. 2014 14:35, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : > Hi, > > in last version of sources you have a > > #generateForDebug who prepares the sources for debugging. > Check in the PharoVMBuilder. > > Esteban > > > On 01 Apr 2014, at 09:02, phil(a)highoctane.be wrote: > > On Tue, Apr 1, 2014 at 1:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> Hi, >> >> I use CDT regularly (bah, its been like 6 months that I don't, but I use >> it when I need it :) ) >> It is not a problem with the current configuration (and debug flags), but >> is a bit of work for adding the source paths. >> >> I do not know if it can be done easier... would be cool, but I don't know >> how feasible :) >> >> Esteban >> > > Now, I managed to get GDB to work with my build. > > I had to change the compile options a bit (-g -O0) in the code generation > and add a couple of source folders in the .gdbinit file to get the sources > to show: > > directory > C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/src/plugins > directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/src/vm > directory > C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/win32 > directory > C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/Cross > directory > C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/Cross/vm > directory > C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/Cross/plugins > directory > C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/win32/vm > directory > C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/win32/plugins > break sqMain > > Now it works. > > But that's not really funny to work like that, so, back to the UI > integration. > > Esteban, do you debug with CDT with the current flags? > > compilerFlagsRelease > "Define NDEBUG for production to exclude asserts " > ^ '-g0 -O2 -march=pentium4 -momit-leaf-frame-pointer > -maccumulate-outgoing-args -funroll-loops ', > '-DNDEBUG -DDEBUGVM=0' > > > for debugging I've set things to: > > compilerFlagsDebug > "Define NDEBUG for production to exclude asserts " > ^ '-g -O0 -march=pentium4 ', > '-DNDEBUG -DDEBUGVM=0' > > and > > compilerFlags > "depends on config ..." > ^ self commonCompilerFlags, ' ' , self compilerFlagsDebug "was Release" > > I've checked that the flags were right with building with > > make VERBOSE=1 > > in the build.sh > > I am interested in looking at the startup process for the VM and getting a > real windows headless system. > The current one isn't working at the moment. Also, the pharo as a service > should work again (is now with -DNO_SERVICE in the compilation) > > I've noticed that the OSX Version supports debug options, but not Windows. > Am I right? > > Phil > > >> >> On 01 Apr 2014, at 03:56, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> >> I'd like to know if someone managed to get Code::Blocks to work with >> the >> >> MinGW configuration. >> > >> > No - but I think it would be good if there would be a preconfigured >> project >> > for easy debugging with Eclipse CDT (C/C++ Development Tooling). >> > >> > Thx >> > T. >> > >> > >> >> >> > <DBG01-04-14 13-16-17.png> > > >

April 1, 2014

Re: [Pharo-dev] Font problem identified

by Igor Stasenko

On 1 April 2014 14:56, Ben Coman <btc(a)openinworld.com> wrote: > I only did the simplest thing that I could think of. I now notice it > has the downside of dirtying the package. I'll have a go at pragma > solution. What would you suggest to name the pragma? <embeddedFont> ? > > <embeddedFontS> or <extraFontS> and method should take an argument - the font manager instance, so the method's implementor can control the way how to register fonts.. else if it will be <embeddedFont> then it will imply that method will have to answer a single instance of single font... which will mean, you'll have to implement a method per each font.. which is not always a good way, in case if you want a centralized control over registering a bunch of fonts at once, instead of duplicating same code over may methods. > cheers -ben > > -- Best regards, Igor Stasenko.

April 1, 2014

Re: [Pharo-dev] Font problem identified

by Ben Coman

April 1, 2014

Re: [Pharo-dev] Font problem identified

by Igor Stasenko

On 1 April 2014 11:34, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I reviewed the changes of Ben, and he implemented a registration mechanism > based on subclassing an abstract font class. I would prefer a registration > mechanism based on pragmas that is similar to the settings one. > > yeah, could be something like: myFonts: fontManager <embeddedFonts> ^ fontManager addFonts: { A. B. C. } > Doru > > > On Tue, Apr 1, 2014 at 11:01 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > >> Thanks I will have a look. >> I was thinking to put in place a registration mechanism. >> >> Stef >> >> On 30 Mar 2014, at 19:56, Ben Coman <btc(a)openInWorld.com> wrote: >> >> > Pharo4Stef wrote: >> >> >> >> Thanks for you suggestion I will check how to implement a registration >> mechanism. >> >> I was wondering if I missed the obvious. >> >> >> >> Stef >> >> >> >> >> >>> i'd like to point out, that there is of course easy brute-force >> solution to this problem >> >>> (simply put dirty patch to force re-loading fonts).. >> >>> >> >>> however, i think we should wisely consider, how to deal with it in >> graceful manner by providing a font-registration mechanism for any >> potential 3-rd party package(s). >> >>> Like that, we will solve the problem for longer time period than just >> the single next day. >> >>> >> >>> -- >> >>> Best regards, >> >>> Igor Stasenko. >> >>> >> >> >> >> >> >> >> >> >> > I've uploaded a possible solution. I learnt something new today. That >> is very cool to be able to embed fonts in the image like that. >> > cheers -ben >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Best regards, Igor Stasenko.

April 1, 2014

Re: [Pharo-dev] PharoVM on Windows & Code::Blocks for debugging

by Esteban Lorenzano

Hi, in last version of sources you have a #generateForDebug who prepares the sources for debugging. Check in the PharoVMBuilder. Esteban On 01 Apr 2014, at 09:02, phil(a)highoctane.be wrote: > On Tue, Apr 1, 2014 at 1:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I use CDT regularly (bah, its been like 6 months that I donât, but I use it when I need it :) ) > It is not a problem with the current configuration (and debug flags), but is a bit of work for adding the source paths. > > I do not know if it can be done easierâ¦ would be cool, but I donât know how feasible :) > > Esteban > > Now, I managed to get GDB to work with my build. > > I had to change the compile options a bit (-g -O0) in the code generation and add a couple of source folders in the .gdbinit file to get the sources to show: > > directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/src/plugins > directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/src/vm > directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/win32 > directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/Cross > directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/Cross/vm > directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/Cross/plugins > directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/win32/vm > directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/win32/plugins > break sqMain > > Now it works. > > But that's not really funny to work like that, so, back to the UI integration. > > Esteban, do you debug with CDT with the current flags? > > compilerFlagsRelease > "Define NDEBUG for production to exclude asserts " > ^ '-g0 -O2 -march=pentium4 -momit-leaf-frame-pointer -maccumulate-outgoing-args -funroll-loops ', > '-DNDEBUG -DDEBUGVM=0' > > > for debugging I've set things to: > > compilerFlagsDebug > "Define NDEBUG for production to exclude asserts " > ^ '-g -O0 -march=pentium4 ', > '-DNDEBUG -DDEBUGVM=0' > > and > > compilerFlags > "depends on config ..." > ^ self commonCompilerFlags, ' ' , self compilerFlagsDebug "was Release" > > I've checked that the flags were right with building with > > make VERBOSE=1 > > in the build.sh > > I am interested in looking at the startup process for the VM and getting a real windows headless system. > The current one isn't working at the moment. Also, the pharo as a service should work again (is now with -DNO_SERVICE in the compilation) > > I've noticed that the OSX Version supports debug options, but not Windows. Am I right? > > Phil > > > On 01 Apr 2014, at 03:56, Torsten Bergmann <astares(a)gmx.de> wrote: > > >> I'd like to know if someone managed to get Code::Blocks to work with the > >> MinGW configuration. > > > > No - but I think it would be good if there would be a preconfigured project > > for easy debugging with Eclipse CDT (C/C++ Development Tooling). > > > > Thx > > T. > > > > > > > > <DBG01-04-14 13-16-17.png>

April 1, 2014

Re: [Pharo-dev] PharoVM on Windows & Code::Blocks for debugging

by phil＠highoctane.be

On Tue, Apr 1, 2014 at 1:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi, > > I use CDT regularly (bah, its been like 6 months that I don't, but I use > it when I need it :) ) > It is not a problem with the current configuration (and debug flags), but > is a bit of work for adding the source paths. > > I do not know if it can be done easier... would be cool, but I don't know > how feasible :) > > Esteban > Now, I managed to get GDB to work with my build. I had to change the compile options a bit (-g -O0) in the code generation and add a couple of source folders in the .gdbinit file to get the sources to show: directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/src/plugins directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/src/vm directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/win32 directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/Cross directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/Cross/vm directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/Cross/plugins directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/win32/vm directory C:/MinGW/msys/1.0/home/User/PharoVmHeadlessWin/pharo-vm/platforms/win32/plugins break sqMain Now it works. But that's not really funny to work like that, so, back to the UI integration. Esteban, do you debug with CDT with the current flags? compilerFlagsRelease "Define NDEBUG for production to exclude asserts " ^ '-g0 -O2 -march=pentium4 -momit-leaf-frame-pointer -maccumulate-outgoing-args -funroll-loops ', '-DNDEBUG -DDEBUGVM=0' for debugging I've set things to: compilerFlagsDebug "Define NDEBUG for production to exclude asserts " ^ '-g -O0 -march=pentium4 ', '-DNDEBUG -DDEBUGVM=0' and compilerFlags "depends on config ..." ^ self commonCompilerFlags, ' ' , self compilerFlagsDebug "was Release" I've checked that the flags were right with building with make VERBOSE=1 in the build.sh I am interested in looking at the startup process for the VM and getting a real windows headless system. The current one isn't working at the moment. Also, the pharo as a service should work again (is now with -DNO_SERVICE in the compilation) I've noticed that the OSX Version supports debug options, but not Windows. Am I right? Phil > > On 01 Apr 2014, at 03:56, Torsten Bergmann <astares(a)gmx.de> wrote: > > >> I'd like to know if someone managed to get Code::Blocks to work with the > >> MinGW configuration. > > > > No - but I think it would be good if there would be a preconfigured > project > > for easy debugging with Eclipse CDT (C/C++ Development Tooling). > > > > Thx > > T. > > > > > > >

April 1, 2014

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

by Stephan Eggermont

FranÃ§ois wrote: > I don't really care what they look like but if there is a way to exend this area with a plugin or completely remove it from the layout, the one posting how to do it will get a beer/coffee in Cambridge this summer. Ah, thatâs easy. There is only one sender of buildTextAreaButtonsColumn: so, if you do { sourceCodePanel. "self buildTextAreaButtonsColumn: aWindow"} reverse do: [:each | sourceCodeContainer addMorph: each]. in NautilusUI>addAll: instead of { sourceCodePanel. self buildTextAreaButtonsColumn: aWindow} reverse do: [:each | sourceCodeContainer addMorph: each]. they are gone. Putting them into a plugin is left as an exercise for the reader. Stephan

April 1, 2014

Re: [Pharo-dev] PharoVM on Windows & Code::Blocks for debugging

by Esteban Lorenzano

Hi, I use CDT regularly (bah, its been like 6 months that I donât, but I use it when I need it :) ) It is not a problem with the current configuration (and debug flags), but is a bit of work for adding the source paths. I do not know if it can be done easierâ¦ would be cool, but I donât know how feasible :) Esteban On 01 Apr 2014, at 03:56, Torsten Bergmann <astares(a)gmx.de> wrote: >> I'd like to know if someone managed to get Code::Blocks to work with the >> MinGW configuration. > > No - but I think it would be good if there would be a preconfigured project > for easy debugging with Eclipse CDT (C/C++ Development Tooling). > > Thx > T. > >

April 1, 2014

Re: [Pharo-dev] Font problem identified

by Tudor Girba

I reviewed the changes of Ben, and he implemented a registration mechanism based on subclassing an abstract font class. I would prefer a registration mechanism based on pragmas that is similar to the settings one. Doru On Tue, Apr 1, 2014 at 11:01 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Thanks I will have a look. > I was thinking to put in place a registration mechanism. > > Stef > > On 30 Mar 2014, at 19:56, Ben Coman <btc(a)openInWorld.com> wrote: > > > Pharo4Stef wrote: > >> > >> Thanks for you suggestion I will check how to implement a registration > mechanism. > >> I was wondering if I missed the obvious. > >> > >> Stef > >> > >> > >>> i'd like to point out, that there is of course easy brute-force > solution to this problem > >>> (simply put dirty patch to force re-loading fonts).. > >>> > >>> however, i think we should wisely consider, how to deal with it in > graceful manner by providing a font-registration mechanism for any > potential 3-rd party package(s). > >>> Like that, we will solve the problem for longer time period than just > the single next day. > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko. > >>> > >> > >> > >> > >> > > I've uploaded a possible solution. I learnt something new today. That > is very cool to be able to embed fonts in the image like that. > > cheers -ben > > > -- www.tudorgirba.com "Every thing has its own flow"

April 1, 2014