January 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20484

by Marcus Denker

Jan. 23, 2013

Re: [Pharo-project] about the VM and Pharo

by Esteban Lorenzano

and is already there... I just forgot to mention it :P he, I was writing by memory... I probably miss a lot of the work we did last year ;) On Jan 23, 2013, at 5:13 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 23 Jan 2013, at 17:03, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On Jan 23, 2013, at 4:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 23 January 2013 16:40, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> Hi, >>>> >>>> Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins. >>>> >>>> Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. >>>> But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. >>>> What are those things? Well, a small list: >>>> >>>> - the adaptation of interpreter to run NativeBoost >>>> - external semaphores enhancement to grow easily over 250. >>>> - ephemerons support. >>>> >>> >>>> in the plugins area, this year we improved some of the existing ones: >>>> - FilePlugin, now can retrieve file permissions and knows if file is a symlink >>>> - SerialPlugin, now works in Macs (it was never implemented) > > The SSL Plugin is also very important ;-) > >>> you forgot: >>> >>> - OSProcess (VMs should include it default, so then we can use it instead >>> of writing bash scripts) >> yup >> >>> >>> - Freetype (this is already default) >> yup >> >>> >>> - .. and bundling Cairo library >> afaik, thats for 3.0 :) >> >>> >>> >>>> in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now). >>>> >>>> So, for Pharo 2.0 now we are working on this twi issues: >>>> >>>> - Stability! We need a stable VM, and as I already said it, we still have some problems there. >>>> - Improve the build process, to make it easier. >>>> - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :) >>>> >>>> Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. >>>> >>> >>> >>>> For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time. >>>> >>> sounds like a lot of work for me :) >> yes it is... well... we'll see :) >> >> >>> >>>> Cheers, >>>> Esteban >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > >

Jan. 23, 2013

Re: [Pharo-project] about the VM and Pharo

by Sven Van Caekenberghe

On 23 Jan 2013, at 17:03, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Jan 23, 2013, at 4:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 23 January 2013 16:40, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> Hi, >>> >>> Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins. >>> >>> Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. >>> But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. >>> What are those things? Well, a small list: >>> >>> - the adaptation of interpreter to run NativeBoost >>> - external semaphores enhancement to grow easily over 250. >>> - ephemerons support. >>> >> >>> in the plugins area, this year we improved some of the existing ones: >>> - FilePlugin, now can retrieve file permissions and knows if file is a symlink >>> - SerialPlugin, now works in Macs (it was never implemented) The SSL Plugin is also very important ;-) >> you forgot: >> >> - OSProcess (VMs should include it default, so then we can use it instead >> of writing bash scripts) > yup > >> >> - Freetype (this is already default) > yup > >> >> - .. and bundling Cairo library > afaik, thats for 3.0 :) > >> >> >>> in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now). >>> >>> So, for Pharo 2.0 now we are working on this twi issues: >>> >>> - Stability! We need a stable VM, and as I already said it, we still have some problems there. >>> - Improve the build process, to make it easier. >>> - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :) >>> >>> Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. >>> >> >> >>> For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time. >>> >> sounds like a lot of work for me :) > yes it is... well... we'll see :) > > >> >>> Cheers, >>> Esteban >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Jan. 23, 2013

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

by David T. Lewis

On Wed, Jan 23, 2013 at 03:08:57PM +0100, Marcus Denker wrote: > > On Jan 23, 2013, at 7:28 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >>>> > >>> > >>> Could you capture for deprecation of OSPlatform osVersion, and resend the > >>> other method (Smalltalk osVersion current osVersion)? Or, trap for > >>> Deprecation and resume it (ignore deprecation - once it is removed, you'll > >>> automatically fail-over to the new code). > >> > >> No, Pharo 2.0 is writing console output whenever an exception occurs, so > >> catching the exception is not good. But not raising the exception in the > >> first place works just fine ;) > >> > > I will un-deprecate the osVersion methods in 2.0 and mark it as compatibility. > > > Ok, this should end up in the image by tomorrow: > > Issue 7306: un-deprecate OSPlatform osVersion for compatibility > http://code.google.com/p/pharo/issues/detail?id=7306 > Thank you :)) Dave

Jan. 23, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Stefan Marr

Hi Mariano: On 23 Jan 2013, at 16:59, Mariano Martinez Peck wrote: > Maybe the lib needs to be 32 bits? can you check if the lib you are trying is compiled for 32 or 64? Yes, it needs to be 32bit, but that's not the problem: smarr@minerva ~/tmp/libgit/libgit2$ file /Developer/usr/clang-ide/lib/libclang.dylib /Developer/usr/clang-ide/lib/libclang.dylib: Mach-O universal binary with 2 architectures /Developer/usr/clang-ide/lib/libclang.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /Developer/usr/clang-ide/lib/libclang.dylib (for architecture i386): Mach-O dynamically linked shared library i386 smarr@minerva ~/tmp/libgit/libgit2$ file /opt/local/libexec/llvm-3.1/lib/libclang.dylib /opt/local/libexec/llvm-3.1/lib/libclang.dylib: Mach-O universal binary with 2 architectures /opt/local/libexec/llvm-3.1/lib/libclang.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /opt/local/libexec/llvm-3.1/lib/libclang.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 Both version I have are universal binaries. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 23, 2013

Re: [Pharo-project] about the VM and Pharo

by Esteban Lorenzano

On Jan 23, 2013, at 4:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 January 2013 16:40, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi, >> >> Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins. >> >> Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. >> But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. >> What are those things? Well, a small list: >> >> - the adaptation of interpreter to run NativeBoost >> - external semaphores enhancement to grow easily over 250. >> - ephemerons support. >> > >> in the plugins area, this year we improved some of the existing ones: >> - FilePlugin, now can retrieve file permissions and knows if file is a symlink >> - SerialPlugin, now works in Macs (it was never implemented) >> > > you forgot: > > - OSProcess (VMs should include it default, so then we can use it instead > of writing bash scripts) yup > > - Freetype (this is already default) yup > > - .. and bundling Cairo library afaik, thats for 3.0 :) > > >> in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now). >> >> So, for Pharo 2.0 now we are working on this twi issues: >> >> - Stability! We need a stable VM, and as I already said it, we still have some problems there. >> - Improve the build process, to make it easier. >> - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :) >> >> Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. >> > > >> For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time. >> > sounds like a lot of work for me :) yes it is... well... we'll see :) > >> Cheers, >> Esteban > > > > -- > Best regards, > Igor Stasenko. >

Jan. 23, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Mariano Martinez Peck

On Wed, Jan 23, 2013 at 11:51 AM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi: > > On 23 Jan 2013, at 15:28, Stefan Marr wrote: > > > On 06 Jan 2013, at 17:22, Ciprian Teodorov wrote: > >> The project is released under MIT license, and you can find it on the > smalltalkhub site. > >> http://smalltalkhub.com/#!/~CipT/TalkFFI > > > > I was trying to play with TalkFFI, but it looks like libclang3.1 is not > compiled correctly or something. > > > > How do you build it? In your code I see you are also targeting OSX, so > that doesn't seem to be the problem. > > > > I was trying to use the MacPorts version of libclang3.1 without having > set any special compiler flags. > > So, I am not entirely sure whether it is build correctly. > > I searched a bit more and found the libclang of Xcode > (/Developer/usr/clang-ide/lib/libclang.dylib). > > With that lib it crashes the VM on a callout to parse the header file > (clang_createTranslationUnitFromSourceFile). > The MacPorts version already stopped way earlier when trying to use > clang_createIndex. > > So, still not a lot of luck. > Maybe the lib needs to be 32 bits? can you check if the lib you are trying is compiled for 32 or 64? > > I am on a OSX 10.6 with the latest NBCog, downloaded today ( > http://pharo.gforge.inria.fr/ci/vm/nbcog/mac/NBCog-mac-latest.zip) > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- Mariano http://marianopeck.wordpress.com

Jan. 23, 2013

Re: [Pharo-project] about the VM and Pharo

by Igor Stasenko

On 23 January 2013 16:40, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins. > > Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. > But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. > What are those things? Well, a small list: > > - the adaptation of interpreter to run NativeBoost > - external semaphores enhancement to grow easily over 250. > - ephemerons support. > > in the plugins area, this year we improved some of the existing ones: > - FilePlugin, now can retrieve file permissions and knows if file is a symlink > - SerialPlugin, now works in Macs (it was never implemented) > you forgot: - OSProcess (VMs should include it default, so then we can use it instead of writing bash scripts) - Freetype (this is already default) - .. and bundling Cairo library > in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now). > > So, for Pharo 2.0 now we are working on this twi issues: > > - Stability! We need a stable VM, and as I already said it, we still have some problems there. > - Improve the build process, to make it easier. > - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :) > > Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. > > For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time. > sounds like a lot of work for me :) > Cheers, > Esteban -- Best regards, Igor Stasenko.

Jan. 23, 2013

[Pharo-project] about the VM and Pharo

by Esteban Lorenzano

Hi, Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins. Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. What are those things? Well, a small list: - the adaptation of interpreter to run NativeBoost - external semaphores enhancement to grow easily over 250. - ephemerons support. in the plugins area, this year we improved some of the existing ones: - FilePlugin, now can retrieve file permissions and knows if file is a symlink - SerialPlugin, now works in Macs (it was never implemented) in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now). So, for Pharo 2.0 now we are working on this twi issues: - Stability! We need a stable VM, and as I already said it, we still have some problems there. - Improve the build process, to make it easier. - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :) Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time. Cheers, Esteban

Jan. 23, 2013

Re: [Pharo-project] zero conf build

by Frank Shearar

On 23 January 2013 15:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Do we want to act upon this issue? Can I do anything? > > Fortunately, the VM from Eliot works fine, so I can use that for the moment. It does, on 32 bit machines, or 64 bit machines where you can install ia32-libs. I'm only familiar with the glibc thing because I've been trying to get something running on a 64 bit machine with glibc 2.11 and _no_ 32 bit libraries. frank > Cheers, > Doru > > > > On Wed, Jan 23, 2013 at 3:35 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 23 January 2013 15:24, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> > On 23 January 2013 14:05, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 23 January 2013 11:08, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> so yeah, looks like the linux VMs won't run anymore under ubuntu 10 >> >>> >> >> The software upgrade hit us back. >> >> Should we install ubuntu 10 slave to build VMs on it? >> > >> > At the risk of sounding foolish, is it possible to write the Makefile >> > to use a particular (and configurable) glibc, rather than the glibc >> > that just happens to be on a machine? >> > >> >> This is not sounds foolish.. >> >> > That way one could use whatever machine, and say "use glibc 2.11". >> > >> >> The last time i faced problem(s) with glibc i found it very >> non-trivial to have two >> different versions of it on a system, and i remember i failed back >> then, trying to convince >> compiler to use proper version of it.. and then linker and etc.. >> and i ended up in having so much mess, that at the end i just decided >> to reinstall a system. :) >> >> But it was long ago.. don't know maybe i was doing something foolish >> and solution is easy (at least today). >> >> > frank >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 23, 2013