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

Re: [Pharo-dev] 32 bits and 64 bits VM

by Eliot Miranda

On Wed, May 14, 2014 at 12:08 PM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits > machine. I could not get it working, 32 bits compatibility package to > run 32bits application on 64bits system is gone, you have to find out > manually the needed 32 bits libs and install it. > > Now I don't want to face this situation anymore, I want to provide with > DrGeo a VM for each word size, compiled with not recent libc et al. and > a working keypad. It is the bare minimum to not look ridiculous. > By the way, the situation would have been equally ridiculous showing > Pharo3. > > Now, I wonder, how is deal the 32bits/64bits situation on Windows and > Mac OSX? > Mac OS X handles the situation. 32-bits requires no special installation or support. They use their "fat binary" scheme to provide both 32-bit and 64-bit versions of libraries in the same file: McStalker.image$ file /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa: Mach-O universal binary with 3 architectures /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa (for architecture i386): Mach-O dynamically linked shared library i386 /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa (for architecture ppc7400): Mach-O dynamically linked shared library ppc > > Hilaire > > > -- > Dr. Geo http://drgeo.eu > > > -- best, Eliot

May 14, 2014

Re: [Pharo-dev] 32 bits and 64 bits VM

by Norbert Hartl

Hilaire, Am 14.05.2014 um 21:08 schrieb Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits > machine. I could not get it working, 32 bits compatibility package to > run 32bits application on 64bits system is gone, you have to find out > manually the needed 32 bits libs and install it. > ubuntu 14.04 changed to way catalogs are loaded. i386 is not included by default. Please try sudo dpkg --add-architecture i386 and then apt-get update and then try to install again. I noticed that a few weeks before, told it Damien and he immediately put it on the website to prevent exactly your situation. Please reconsider looking at http://www.pharo-project.org/pharo-download/ubuntu and tell me if it is working. Norbert > Now I don't want to face this situation anymore, I want to provide with > DrGeo a VM for each word size, compiled with not recent libc et al. and > a working keypad. It is the bare minimum to not look ridiculous. > By the way, the situation would have been equally ridiculous showing Pharo3. > > Now, I wonder, how is deal the 32bits/64bits situation on Windows and > Mac OSX? > > Hilaire > > > -- > Dr. Geo http://drgeo.eu > >

May 14, 2014

Re: [Pharo-dev] 32 bits and 64 bits VM

by phil＠highoctane.be

On Wed, May 14, 2014 at 9:43 PM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > Hello, > > The work to port Pharo to 64 bits has started. > > The new memory manager Spur will be ported to Pharo 4 alpha next week and > it supports 64 bits (this is fresh news, it has been decided 3 hours ago). > This was one of the main issue for the 64 bits port. > > Now the status is to finish to port the memory manager and to compile the > VM for 64 bits. There is a bit a debugging to do as even if the 64bits Spur > memory manager is implemented it has never been debugged. In addition, some > plugins are 32 bits dependent and that needs to be fixed. > > At this point, which should be in the late summer if Esteban and Eliot are > very productive, we should have a 64 bits stack VM. > > Then there are 2 remaining points, one is to port the JIT to support > x86_64 bits and the other is to add faster floating pointer in 64 bits. > Adding fast floating pointer is important as 64bits images are typically > 30% slower than 32bits ones due to Pharo computation being mainly pointers > computation, and that manipulating 64 bits is more expensive than 32 bits. > > At this point, which is probably around christmas if everything goes well, > we should have a 64bits Cog VM. > > Now this is the optimistic planning. It may be that we have the 64 bits > Stack VM for Christmas and the 64 bits Cog VM in a year. It depends if you > prefer the optimistic or the pessimistic planning. > > > > Right now, people have issue with 64bits vs 32bits in Linux (I saw several > reports on the mailing list) but it seems it is not a problem in Windows > and Mac. Microsoft and Apple may be providing better support for 32 bits. I > don't know. > Keypad works on my linux build. There was a lost commit somewhere and I fwded the file to Esteban for integration. Phil > > > I don't know about the working keypad. Perhaps someone more aware could > help. > > > 2014-05-14 21:08 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com> > : > >> Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits >> machine. I could not get it working, 32 bits compatibility package to >> run 32bits application on 64bits system is gone, you have to find out >> manually the needed 32 bits libs and install it. >> >> Now I don't want to face this situation anymore, I want to provide with >> DrGeo a VM for each word size, compiled with not recent libc et al. and >> a working keypad. It is the bare minimum to not look ridiculous. >> By the way, the situation would have been equally ridiculous showing >> Pharo3. >> >> Now, I wonder, how is deal the 32bits/64bits situation on Windows and >> Mac OSX? >> >> Hilaire >> >> >> -- >> Dr. Geo http://drgeo.eu >> >> >> >

May 14, 2014

Re: [Pharo-dev] New screenshots of Roassal3d

by Yuriy Tymchuk

On 14 May 2014, at 21:47, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > 2014-05-14 14:29 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > You are missing a very important feature that is available in Code City. A 2d option :) > > Cheers. > Uko > > A screenshot is not enough ? Itâs more of a joke. The thing is that in modern code city when you put your camera in a top-most point all structures are rendered flat. This is made to improve your experience, as some times you want to see things in just 2d and in 3d everything is a bit distorted because of perspective. Now main idea is that it was like that at the beginning of presentation, and then BOOM it becomes 3d. So Iâm joking that Roassalâs stuff is messing cool 2d transition. Uko > > > On 14 May 2014, at 14:22, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > Currently no, but we will work on that. > > Roassal 3d will be announce and heavily demonstrated at esug > > > > Alexandre > > > > > >> On 11 May 2014, at 09:07, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> > >> abergel wrote > >>> we have posted some new picture of Roassal3d. > >> > >> Cool! What would be really great would be screencasts showing how to make > >> these cool things for ourselves. Do any exist? > >> > >> > >> > >> ----- > >> Cheers, > >> Sean > >> -- > >> View this message in context: http://forum.world.st/New-screenshots-of-Roassal3d-tp4758397p4758667.html > >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >> > > > > >

May 14, 2014

Pharo 30 post release and Pharo40 brainstorming

by stepharo

Hi guys today we got a meeting at lille to think about 30 and how we should improve and also brainstorm about Pharo40. We will send a report on possible actions for Pharo40 and contact also the consortium members to show the feature list prioritize get some feedback and (help) discuss and dream with you. Stef

May 14, 2014

Re: [Pharo-dev] 32 bits and 64 bits VM

by Yuriy Tymchuk

For me this are good news. Thank you for your work. Cheers. Uko On 14 May 2014, at 21:43, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > The work to port Pharo to 64 bits has started. > > The new memory manager Spur will be ported to Pharo 4 alpha next week and it supports 64 bits (this is fresh news, it has been decided 3 hours ago). This was one of the main issue for the 64 bits port. > > Now the status is to finish to port the memory manager and to compile the VM for 64 bits. There is a bit a debugging to do as even if the 64bits Spur memory manager is implemented it has never been debugged. In addition, some plugins are 32 bits dependent and that needs to be fixed. > > At this point, which should be in the late summer if Esteban and Eliot are very productive, we should have a 64 bits stack VM. > > Then there are 2 remaining points, one is to port the JIT to support x86_64 bits and the other is to add faster floating pointer in 64 bits. Adding fast floating pointer is important as 64bits images are typically 30% slower than 32bits ones due to Pharo computation being mainly pointers computation, and that manipulating 64 bits is more expensive than 32 bits. > > At this point, which is probably around christmas if everything goes well, we should have a 64bits Cog VM. > > Now this is the optimistic planning. It may be that we have the 64 bits Stack VM for Christmas and the 64 bits Cog VM in a year. It depends if you prefer the optimistic or the pessimistic planning. > > > > Right now, people have issue with 64bits vs 32bits in Linux (I saw several reports on the mailing list) but it seems it is not a problem in Windows and Mac. Microsoft and Apple may be providing better support for 32 bits. I don't know. > > > > I don't know about the working keypad. Perhaps someone more aware could help. > > > 2014-05-14 21:08 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits > machine. I could not get it working, 32 bits compatibility package to > run 32bits application on 64bits system is gone, you have to find out > manually the needed 32 bits libs and install it. > > Now I don't want to face this situation anymore, I want to provide with > DrGeo a VM for each word size, compiled with not recent libc et al. and > a working keypad. It is the bare minimum to not look ridiculous. > By the way, the situation would have been equally ridiculous showing Pharo3. > > Now, I wonder, how is deal the 32bits/64bits situation on Windows and > Mac OSX? > > Hilaire > > > -- > Dr. Geo http://drgeo.eu > > >

May 14, 2014

Re: [Pharo-dev] New screenshots of Roassal3d

by ClÃ©ment Bera

2014-05-14 14:29 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > You are missing a very important feature that is available in Code City. A > 2d option :) > > Cheers. > Uko > A screenshot is not enough ? > > On 14 May 2014, at 14:22, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > Currently no, but we will work on that. > > Roassal 3d will be announce and heavily demonstrated at esug > > > > Alexandre > > > > > >> On 11 May 2014, at 09:07, "Sean P. DeNigris" <sean(a)clipperadams.com> > wrote: > >> > >> abergel wrote > >>> we have posted some new picture of Roassal3d. > >> > >> Cool! What would be really great would be screencasts showing how to > make > >> these cool things for ourselves. Do any exist? > >> > >> > >> > >> ----- > >> Cheers, > >> Sean > >> -- > >> View this message in context: > http://forum.world.st/New-screenshots-of-Roassal3d-tp4758397p4758667.html > >> Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >> > > > > >

May 14, 2014

Re: [Pharo-dev] 32 bits and 64 bits VM

by ClÃ©ment Bera

Hello, The work to port Pharo to 64 bits has started. The new memory manager Spur will be ported to Pharo 4 alpha next week and it supports 64 bits (this is fresh news, it has been decided 3 hours ago). This was one of the main issue for the 64 bits port. Now the status is to finish to port the memory manager and to compile the VM for 64 bits. There is a bit a debugging to do as even if the 64bits Spur memory manager is implemented it has never been debugged. In addition, some plugins are 32 bits dependent and that needs to be fixed. At this point, which should be in the late summer if Esteban and Eliot are very productive, we should have a 64 bits stack VM. Then there are 2 remaining points, one is to port the JIT to support x86_64 bits and the other is to add faster floating pointer in 64 bits. Adding fast floating pointer is important as 64bits images are typically 30% slower than 32bits ones due to Pharo computation being mainly pointers computation, and that manipulating 64 bits is more expensive than 32 bits. At this point, which is probably around christmas if everything goes well, we should have a 64bits Cog VM. Now this is the optimistic planning. It may be that we have the 64 bits Stack VM for Christmas and the 64 bits Cog VM in a year. It depends if you prefer the optimistic or the pessimistic planning. Right now, people have issue with 64bits vs 32bits in Linux (I saw several reports on the mailing list) but it seems it is not a problem in Windows and Mac. Microsoft and Apple may be providing better support for 32 bits. I don't know. I don't know about the working keypad. Perhaps someone more aware could help. 2014-05-14 21:08 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits > machine. I could not get it working, 32 bits compatibility package to > run 32bits application on 64bits system is gone, you have to find out > manually the needed 32 bits libs and install it. > > Now I don't want to face this situation anymore, I want to provide with > DrGeo a VM for each word size, compiled with not recent libc et al. and > a working keypad. It is the bare minimum to not look ridiculous. > By the way, the situation would have been equally ridiculous showing > Pharo3. > > Now, I wonder, how is deal the 32bits/64bits situation on Windows and > Mac OSX? > > Hilaire > > > -- > Dr. Geo http://drgeo.eu > > >

May 14, 2014

32 bits and 64 bits VM

by Hilaire Fernandes

Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working, 32 bits compatibility package to run 32bits application on 64bits system is gone, you have to find out manually the needed 32 bits libs and install it. Now I don't want to face this situation anymore, I want to provide with DrGeo a VM for each word size, compiled with not recent libc et al. and a working keypad. It is the bare minimum to not look ridiculous. By the way, the situation would have been equally ridiculous showing Pharo3. Now, I wonder, how is deal the 32bits/64bits situation on Windows and Mac OSX? Hilaire -- Dr. Geo http://drgeo.eu

May 14, 2014

Re: [Pharo-dev] I love the Pharo 3 Dark Theme

by Esteban Lorenzano

On 14 May 2014, at 17:33, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 14 May 2014, at 15:22, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> Maybe it is not such bad idea to have it as default theme for Pharo 4, at least at the start. It's the best way to force people to report bugs in theming ;-) > > thatâs the idea (and in part they are already). Problem is that there is an annoying bug around that prevent us to take them into account :) > but yes, for Pharo4 they will be there. oopsâ¦ I misread (the problems of multitasking): I thought you were talking about the fonts (they will be there). So far, not the theme or the fonts are meant to be defaults, just to be available. Esteban > > Esteban > >> >> -- Pavel >> >> >> 2014-05-14 15:01 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> thanks for the nice comments. >> yes, Iâm working on making it something better that a hack (I will probably finish it next week). Then, we think on including it in a future update on Pharo 3. >> nowâ¦ it will be available, but I do not think it will be the default theme. But it will be there for choosing it. Also, I think theme it-self still need some care, let me know your findings and I will fix it as soon as possible :) >> >> for programatically, I have added a fonts.st fonts to the autoconfiguration of pharo >> >> StartupLoader default executeAtomicItems: { >> StartupAction >> name: 'Fonts 3.0' >> code: [ >> | pointSize fontName codeFontName | >> >> FreeTypeSystemSettings loadFt2Library: true. >> FreeTypeFontProvider current updateFromSystem. >> >> pointSize := 10. >> fontName := 'Source Sans Pro'. >> codeFontName := 'Source Code Pro'. >> StandardFonts >> setAllStandardFontsTo: (LogicalFont familyName: fontName pointSize: pointSize); >> haloFont: (LogicalFont familyName: fontName pointSize: pointSize - 1); >> balloonFont: (LogicalFont familyName: fontName pointSize: pointSize - 1); >> windowTitleFont: (LogicalFont familyName: fontName pointSize: pointSize + 1); >> listFont: (LogicalFont familyName: fontName pointSize: pointSize); >> menuFont: (LogicalFont familyName: fontName pointSize: pointSize); >> codeFont: (LogicalFont familyName: codeFontName pointSize: pointSize) >> ] >> runOnce: true. >> }. >> >> this is usually in: >> >> OSX: ~/Library/Preferences/pharo/3.0 >> Linux: ~/.config/pharo/3.0 (Iâm not sure, but somewhere there) >> Windows: no idea :) >> >> cheers, >> Esteban >> >> >> On 14 May 2014, at 14:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> >>> >>> Le 14/05/2014 14:36, Esteban A. Maringolo a Ã©crit : >>>> 2014-05-14 5:39 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>> Hi, >>>>> >>>>> I have been using the new Pharo 3 Dark Theme since it was announced on May 1st. In my specific case, I am using the FreeType fonts Open Sans Regular 11 and Source Code Pro Regular 11 on a MacBookAir, both on the 13 inch 1440x900 built in screen and on a 23 inch 1920x1024 external monitor. >>>>> >>>>> Every day there is a moment that I think: this looks so nice, this is so pleasant to use. Really Esteban, I don't know how you did it, but the color palette is really well chosen, plain beautiful. Let's make this either a permanent part of Pharo or an easy to load extension, real soon. >>>> >>>> I want to say thanks too. >>>> >>>> I'm using it since day one, it's easier for my eyes. >>>> >>>> And even got somebody attention, who asked me what I was using... >>>> >>>> I vote to make it permanent. >>>> >>>> Regards! >>>> >>>> ps: I'm using the default "DejaVu" fonts, how do you set the TTF font >>>> programatically? >>> >>> I do it in the settings... and export them; However, when I rebuilt an image, I need to execute: >>> >>> FreeTypeFontProvider current updateFromSystem >>> >>> For the settings to apply. >>> >>> Thierry >>> >>>> Esteban A. Maringolo >>>> >>>> >>>> >>> >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> >

May 14, 2014