February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Status Updates for Hot New Libraries?

by Nicolai Hess

Am 16.02.2016 7:27 vorm. schrieb "ClÃ©ment Bera" <bera.clement(a)gmail.com>: > > I have been using SDL for a while now. It works fine with the latest pre-spur VM. I think Esteban made the Spur migration right now so it should work fine. > > It is really a game changer. You can start Pharo in headless, open a SDL window, use Cairo to render things on it and have it catch user events. It is very nice :-) In Windows too? The last time I tried, the keyboard input stopped working. I provided a fix for the vm, that is now away again. This was some month ago. And it is exhausting how slow we move forward and testing, debugging and reviewing must be die again and again. > > 2016-02-15 21:07 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>> >>> Did I miss any? >> >> >> libgit2? > >

Feb. 16, 2016

Re: [Pharo-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

by Eliot Miranda

Hi ClÃ©ment, > On Feb 15, 2016, at 10:28 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hey Eliot, > > the Pharo builds you have integrated, they have the exact same plugin as existing Pharo VM ? I am thinking of libgit, Cairo or SDL2 for example. No, but I hope that people who know the Pharo VM can modify the build to make it the same. Another thing that needs to be done is to merge in HPI's statically-linked SqueakSSL plugin build. > I am so happy to be able to build Pharo VM now. That would simplify so many things for me. That's great! I'm sure that in a month or two we will all be sharing a consistent VM build environment. That'll make everyone's life easier. > > 2016-02-16 3:32 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >> Eliot Miranda-2 wrote >> > ... Bug Fixes and Improvements... >> >> Wow that was a long list of improvements, and exciting that 64-bit and one >> unified build process are so near! Thanks and congrats!! >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/New-Cog-VMs-available-as-per-VMMaker-oscog-eem-1679-r… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 16, 2016

Re: [Pharo-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

by Sven Van Caekenberghe

> On 16 Feb 2016, at 03:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Eliot Miranda-2 wrote >> ... Bug Fixes and Improvements... > > Wow that was a long list of improvements, and exciting that 64-bit and one > unified build process are so near! Thanks and congrats!! +100 Yeah! > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/New-Cog-VMs-available-as-per-VMMaker-oscog-eem-1679-r… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 16, 2016

Re: [Pharo-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

by ClÃ©ment Bera

Hey Eliot, the Pharo builds you have integrated, they have the exact same plugin as existing Pharo VM ? I am thinking of libgit, Cairo or SDL2 for example. I am so happy to be able to build Pharo VM now. That would simplify so many things for me. 2016-02-16 3:32 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Eliot Miranda-2 wrote > > ... Bug Fixes and Improvements... > > Wow that was a long list of improvements, and exciting that 64-bit and one > unified build process are so near! Thanks and congrats!! > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/New-Cog-VMs-available-as-per-VMMaker-oscog-eem-1679-r… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Feb. 16, 2016

Re: [Pharo-dev] Status Updates for Hot New Libraries?

by ClÃ©ment Bera

I have been using SDL for a while now. It works fine with the latest pre-spur VM. I think Esteban made the Spur migration right now so it should work fine. It is really a game changer. You can start Pharo in headless, open a SDL window, use Cairo to render things on it and have it catch user events. It is very nice :-) 2016-02-15 21:07 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Did I miss any? >> > > libgit2? >

Feb. 16, 2016

Re: [Pharo-dev] Compiling the unix vm / spur

by Eliot Miranda

On Mon, Feb 15, 2016 at 7:44 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Tue, Feb 16, 2016 at 3:45 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > That's a bug in the CMake code > > (which I hope will be history in a few months). > > Are you indicating using an alternative build system? > yes. In http://www.squeakvm.org/svn/squeak/branches/Cog I have just replaced the Xcode.xcodeproj/project.pbxproj "build system", which offers no procedural abstraction at all, with a small set of Gnu Makefiles. The result is that each of the various VMs: (newspeak | squeak | pharo) x (sista | cog | stack) x (spur x v3) has a small Makefile such as build.macos32x86/pharo.cog.spur/Makefile: ############################################################################## # Makefile for Mac OS X Cog Spur Pharo Cocoa VM using clang and gnu make 3.81 # Do make init to allow make -n to function. # VMSRCDIR:= ../../spursrc/vm VM:=Pharo CFLAGS:=-DPharoVM=1 # Now include the Makefile proper, which is common to all Mac OS builds. # include ../common/Makefile.app build.macos32x86/squeak.stack.spur/Makefile ############################################################################## # Makefile for Mac OS X Stack Spur Squeak Cocoa VM using clang and gnu make 3.81 # Do make init to allow make -n to function. # VMSRCDIR:= ../../spurstacksrc/vm SOURCEFILE:=SqueakV50.sources # Now include the Makefile proper, which is common to all Mac OS builds. # include ../common/Makefile.app instead of over 700k of useless Xcode junk per build. In comparison each of the new build directories takes less than 2k of text (16k bytes on disc in 4 files) and the common makefiles (see e.g. http://www.squeakvm.org/svn/squeak/branches/Cog/build.macos32x86/common) takes less than 24k of text (44k bytes on disc in 8 files). The new build system seems no slower, and it also signs the .app bundle. his is, IMO, a huge improvement over both Xcode and CMake. The makefiles are reasonably easy to modify. They're based on Andreas' makefiles for Win32. I've been able to simplify both and am finally getting some familiarity with gnu Make's set of functions. It's very satisfying to replace of the order of 6 Mb of make junk that requires an entire IDE to edit with less than 300k of stuff. It also means I have more or less the same build system on win32 and Mac OS X. I think I may replace the Unix autoconf scheme with something similar. The only thing that's lacking in my scheme is a CMake or autoconf step to determine the platform's capabilities (to generate a config.h). If I do this right I think autoconf/CMake can be run once to initialize the build system, rather than once for every build. The intuition is that the platform doesn't change and the autoconf/CMake probe of the underlying platform can be done once and shared between all the builds. Then it needs to be redone on major OS upgrades, etc. But it /doesn't/ need to be done on every build. And gnu Make makes it easy to call-out to a common makefile that will run the autoconf/CMake step as required by the first build. $(realpath ...) is one's friend. btw, last week I came across Ninja [1], a static build system designed > to be used higher level generators, which for us could be Smalltalk. > [1] http://jpospisil.com/2014/03/16/replacing-make-with-ninja.html i don't mean to sound negative or arrogant but Ninja doesn't offer enough syntactic abstraction to be worth it. For example the rules given on that page are not much simpler than the rules in http://www.squeakvm.org/svn/squeak/branches/Cog/build.macos32x86/common/Mak…. So IMO the right approach is a per-OS set of gnu Makefiles, all of which share more or less the same architecture, plus an autoconf/CMake step to generate the config.h file that includes all the relevant information about the underlying platform. Here's the kidn of information I mean. This is a subset of the generated config.h file on e.g. linux32x86. Right now generating this for every build takes a substantial fraction of the overall build time, not an issue for a slave, but a real issue for someone doing their own VM builds, and it's unnecessary replcation. #define USE_X11 1 #define USE_X11_GLX 1 /* #undef USE_QUARTZ */ /* #undef USE_QUARTZ_CGL */ /* #undef USE_RFB */ /* libraries */ /* #undef HAVE_LIBX11 */ #define HAVE_LIBXEXT 1 #define HAVE_LIBDL 1 /* #undef HAVE_DYLD */ /* #undef HAVE_LIBFFI */ /* #undef HAVE_ICONV */ /* #undef USE_AUDIO_NONE */ /* #undef USE_AUDIO_SUN */ /* #undef USE_AUDIO_NAS */ /* #undef USE_AUDIO_OSS */ /* #undef USE_AUDIO_MACOSX */ /* #undef OSS_DEVICE */ /* header files */ #define HAVE_UNISTD_H 1 /* #undef NEED_GETHOSTNAME_P */ #define HAVE_DIRENT_H 1 /* #undef HAVE_SYS_NDIR_H */ /* #undef HAVE_SYS_DIR_H */ /* #undef HAVE_NDIR_H */ #define HAVE_DLFCN_H 1 #define HAVE_ICONV_H 1 #define HAVE_SYS_TIME_H 1 #define TIME_WITH_SYS_TIME 1 cheers -ben > _,,,^..^,,,_ best, Eliot

Feb. 16, 2016

Re: [Pharo-dev] Compiling the unix vm / spur

by Ben Coman

On Tue, Feb 16, 2016 at 3:45 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > That's a bug in the CMake code > (which I hope will be history in a few months). Are you indicating using an alternative build system? btw, last week I came across Ninja [1], a static build system designed to be used higher level generators, which for us could be Smalltalk. [1] http://jpospisil.com/2014/03/16/replacing-make-with-ninja.html cheers -ben

Feb. 16, 2016

Re: [Pharo-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

by Sean P. DeNigris

Eliot Miranda-2 wrote > ... Bug Fixes and Improvements... Wow that was a long list of improvements, and exciting that 64-bit and one unified build process are so near! Thanks and congrats!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Cog-VMs-available-as-per-VMMaker-oscog-eem-1679-r… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 16, 2016

Where can I find neweer versions of FFI-Examples?

by Eliot Miranda

I see in http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/swasqueakinbox/FFI-Ex… the following: Name: FFI-Examples-StS.3 Author: StS Time: 06/16/2010, 10:16:20 UUID: 615f2492-5ba1-408f-bbbe-99925ba5bc30 Ancestors: FFI-Examples-StS.2 What repository is this ending up in? _,,,^..^,,,_ best, Eliot

Feb. 16, 2016

Re: [Pharo-dev] [squeak-dev] Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

by Eliot Miranda

On Mon, Feb 15, 2016 at 3:52 PM, Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > Hi Eliot, > > This is great. I couldn't find any 64-bit VMs for non-MacOS. Are they Mac > only? Oops. Bugs in my upload scripts. Adding the 64-bit linux VMs now. Tobias, Marcel we should discuss building on WIN32 and WIN64, and how to build a 64-bit Spur Windows VM. _,,,^..^,,,_ best, Eliot

Feb. 16, 2016