- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] [Inspiration] Toward a better programming

by Tudor Girba

Exactly. And it is of critical importance to have these tools directly supported by the IDE :) Doru On Tue, Apr 1, 2014 at 10:57 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Go go go! > Roassal2 (with Athens) can change the face of Pharo. > > Stef > > > > I cannot resist to jump on this. Indeed, we have the moral obligation to > promote what we have crafted over the year. > > Producing a high-quality video has been on my todo list for quite some > times already. As you probably know, we did some intent already (videos > about Roassal, GraphET, and other tools), but we were too young maybe. > > > > Within the next few weeks we will work on a cool video to promote > Roassal2, and our goal is to reach users beyond the Smalltalk boundary. We > have everything so far. The moose distribution is a wonderful toolbox that > can literally blow away any example shown in this video. > > > > As you may have seen, we have worked on Roassal2 which includes a new > geographical map builder, tabular table importer, GraphET2, fancy curves, > html and amber exporter. A video carefully orchestrated has the potential > to kick away Aurora, Light Table, Wolfram and all their friends. > > > > We will soon get there... > > > > Alexandre > > > > > > On Mar 29, 2014, at 2:20 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > >> Beautiful demo. This should be our game, yet others are playing it :(. > >> > >> Doru > >> > >> > >> On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> > >> On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >>> This is a nice write down: > >>> > >>> http://www.chris-granger.com/2014/03/27/toward-a-better-programming/ > >>> > >>> with a nice demo of a prototype: > >>> > >>> https://www.youtube.com/watch?v=L6iUm_Cqx2s > >>> > >>> Luckily, the horrible C++ code computing standard deviation in the > article can be written quite elegantly and directly in Pharo: > >>> > >>> | input | > >>> input := #(2 4 4 4 5 5 7 9). > >>> (((input - input average) raisedTo: 2) sum / (input size - 1)) sort. > >>> > >>> Sven > >> > >> Damn spelling correction ;-) > >> > >> | input | > >> input := #(2 4 4 4 5 5 7 9). > >> (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt. > >> > >> > >> > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

April 1, 2014

Re: [Pharo-dev] Spec and forms

by Sean P. DeNigris

Sergi Reyner wrote > But MAContainerMorph does not inherit from Morph :) Yes, I always thought that was a mistake because it is confusing, and leads to wrong expectations like in this case. I meant to rename all like MAMorphicContainer, but haven't gotten around to it ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-and-forms-tp4751908p4752011.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 1, 2014

Re: [Pharo-dev] Font problem identified

by Pharo4Stef

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

April 1, 2014