Pharo-dev

By thread

pharo-dev@lists.pharo.org

July 2017

398 messages

Re: [Pharo-dev] Epicea applying multiple changes

by Tim Mackinnon

In retrospect, this is the problem I also had - But I put it down to the UI being a bit confusing about what you were loading. I will give some constructive feedback on the UI as like others, I think the underlying idea is very good. Tim Sent from my iPhone > On 23 Jul 2017, at 22:10, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > > Hello > > Might it be related to a problem I described over here? > http://forum.world.st/Epicea-feedback-td4952661.html > > In short, I think that when I select multiple changes, epicea applies them > in wrong order, so, if for example a single method is changed two times, > Epicea first creates newer content and then replaces it by older content. It > seems to be solvable by filtering just latest changes, but I am not sure > whether it might not have other unwanted consequences. > > Jan > > > tinchodias wrote >> I'll check the bug, it's important. >> >> However, Tim and others, I'm interested in your experience with the UI. If >> you want to send me more details... >> >> Maybe I can remark: Epicea has work and feedback accumulated during my >> phd. >> Now that phd finished and Epicea comes with Pharo 6.0, the project is open >> to much more developers to collaborate with their work and feedback. So >> you >> are welcome. The project belongs to the community now even though I'm >> still >> responsible to maintain it, of course. >> >> Cheers, MartÃn >> >> On Thu, Jul 20, 2017 at 5:18 AM, Denis Kudriashov < > >> dionisiydk@ > >> > >> wrote: >> >>> It is issue 20223 >>> <https://pharo.fogbugz.com/f/cases/20223/Epicea-applying-collection-of-same-method-changes-uses-wrong-order> >>> >>> 2017-07-19 9:41 GMT+02:00 Tudor Girba < > >> tudor@ > >> >: >>> >>>> Hi, >>>> >>>> I experienced the same issues. It seems somehow related that when we >>>> have >>>> multiple changes to the same method, not all changes are applied and we >>>> do >>>> not get back the latest version. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Jul 18, 2017, at 10:48 AM, Andrei Chis < > >> chisvasileandrei@ > >> > >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Is there some known bug in Epicea when applying multiple changes at >>>> once in Pharo 6? >>>>> >>>>> I had a few crashes lately and each time when recovering the changes >>>> by >>>> selecting multiple changes at once some changes are skipped. If I apply >>>> manually each change it works. >>>>> >>>>> Cheers, >>>>> Andrei >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Things happen when they happen, >>>> not when you talk about them happening." >>>> >>>> >>>> >>> > > > > > > -- > View this message in context: http://forum.world.st/Epicea-applying-multiple-changes-tp4955502p4956482.ht… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 23, 2017

New Launcher not working (Windows)

by Jan BlizniÄenko

Hello It seems I am not able to open an image via new Launcher for Windows. I have downloaded new build of Pharo Launcher for Windows from https://ci.inria.fr/pharo/job/Launcher-Win/ ( pharo_installer-0.2.13.exe ) and it starts ok, downloads image ok, but I am unable to open it, although opening images works fine in older launcher ( pharo_installer-0.2.11.exe from 28. 2. 2017). First time I tried opening the image (double clicking on it in the list), loading bar "Determining Image version" showed up and remained frozen like that without any progress shown in the bar. I gave it 10 minutes, but no change, still stuck like that. UI was not responding, so I terminated it via alt+. Second time I tried opening the image via the Launcher, that "Determining" bar was there only for a second and then it was replaced by "Fetching VM to run Pharo 60 images" which seemed to be really fetching something, but after another second or two, it got stuck in the middle of the process and got an error "KeyNotFound: key '60' not found in Dictionary". Well, it seemed like I got further, so third time is a charm. This time, instead of previous error, I got "FileExists: File @C:\Users\User\Documents\Pharo\vms\60.zip", which is quite understandable since previous process did not successfully cleaned up after itself. I tried it repeatedly, tried it with both old (already existing) and new images (downloaded in new Launcher) and I tried removing whole Pharo folder in Documents, but every time I get stuck with one of those problems above. There is a PharoDebug.log with logs of interrput and errors mentioned above: PharoDebug.log <http://forum.world.st/file/n4956495/PharoDebug.log> Note that I can open those images just fine by opening them directly from Windows file explorer or via old Launcher, just not in the new Launcher. Windows 10 Pro v1703 64bit. Thank you Jan -- View this message in context: http://forum.world.st/New-Launcher-not-working-Windows-tp4956495.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 23, 2017

Re: [Pharo-dev] Epicea feedback

by Jan BlizniÄenko

Thank you for that, since I did not managed to register those at the time. Jan tinchodias wrote > Thanks I still didn't invest time to fix them but I registered both in > fogbugz as: > > https://pharo.fogbugz.com/f/cases/20223/Epicea-check-usability-bug-to-apply… > https://pharo.fogbugz.com/f/cases/20225/Epicea-would-be-nice-is-to-have-som… > > cheers, > Martin > > On Sat, Jul 1, 2017 at 5:24 AM, Stephane Ducasse < > stepharo.self@ > > > wrote: > >> Thanks martin for your excellent support. >> What would be nice is to have some menus on the sessions items >> because often I try to click on them so see what I can do with them. >> >> Stef >> >> On Tue, Jun 27, 2017 at 4:17 PM, Martin Dias < > tinchodias@ > > wrote: >> > Hello Jan, thanks for your feedback. I will have a look asap. Feel free >> to >> > report it in fogbugz. >> > >> > MartÃn >> > >> > On Tue, Jun 27, 2017 at 8:26 AM, Jan BlizniÄenko < > bliznjan@.cvut > > >> > wrote: >> >> >> >> Hello >> >> >> >> I'd like to thank you for creating the Epicea. It is way more >> >> user-friendly >> >> and dependable than previous change-handling tool. Browsing, applying >> and >> >> reverting changes is way easier. >> >> >> >> Just one note: >> >> It is not exactly clear from first look how to properly reapply >> changes >> >> after an image has been closed without saving. If I select all changes >> I >> >> want to apply without using any filter, those changes are reapplied in >> >> wrong >> >> order (if I changed a method two times, first the new version is >> applied >> >> and >> >> then the old one). As far as I understood, I have to use filter to >> show >> >> only >> >> latest changes, but I think it could be clearer in the UI that I need >> to >> >> do >> >> so (or something completely different?) for applying changes. >> >> >> >> Thank you >> >> Jan >> >> >> >> >> >> >> >> -- >> >> View this message in context: >> >> http://forum.world.st/Epicea-feedback-tp4952661.html >> >> Sent from the Pharo Smalltalk Developers mailing list archive at >> >> Nabble.com. >> >> >> > >> >> -- View this message in context: http://forum.world.st/Epicea-feedback-tp4952661p4956491.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 23, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolai Hess

2017-07-23 22:38 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-07-23 19:56 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2017-07-23 19:42 GMT+02:00 HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com>: >> >>> 2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> > >>> > Hm, I tried to create the build environment used for the >>> > windows vm build from opensmalltalk. >>> > >>> > I setup a cygwin environment with the same install commands as from >>> > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/. >>> appveyor.yml >>> > >>> > My problems, first it is missing make and wget, I can add make and >>> wget to the install command line for cygwin, but I am >>> > curious why it is working on the build server ? >>> > >>> > Anyway, after I got this working, the build stops and building the >>> pkg-config package. >>> > The log says it can not find a gcc, I know that the build process with >>> cygwin uses >>> > i686-w64-mingw32-gcc >>> > or >>> > x86_64-w64-mingw32-gcc >>> > >>> > But I don't understand where is the missing step to tell the configure >>> scripts to use the >>> > >>> > i686-w64-mingw32-gcc command instead of "gcc", >>> > >>> > again, this seems to work on the appveyor build but not locally on my >>> machine. >>> > >>> > Any idea what I had missed? >>> > >>> >>> I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in >>> your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and >>> the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the >>> line: >>> >>> MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" >>> >>> to >>> >>> MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/bi >>> n:/usr/bin:/bin" >>> >>> And finally >>> >>> source /etc/profile >>> >>> Cheers, >>> >> >> I always had problems using mingw in the past. I got a working mingw >> environment some years ago, and a newer mingw version >> did not work well (some changes on the debug and exception format). >> But now, the build process for pharo did change. (The build instructions >> on github/pharo-vm are old and do not work anymore. >> >> And I hoped to get a more automatic and more reliable build process by >> using the same commands used by the build server for >> the opensmalltalk pharo vm sources. >> >> And I thought the compiler used to build the latest pharo-vm for windows >> is from cygwin ? >> >> >> > Hi Nicolai, > more exactly we cross compile from a cygwin environment for a mingw target. > The main reason for switching to cygwin are: > - this is required for the 64 bit vm > - the other flavours on opensmallalk (squeak/newspeak) were also built > with cygwin, so it's more simple to maintain a single way of doing things > > Cygwin is required for the 64bits vm because of directx. > Indeed cygwin still provides support for the legacy directx version used > by the VM, while recent mingw does not. > Until we port to a newer API, mingw thus depends on the MS directx include > and library files that we redistribute for 32 bits only (and we should not > without permission, I plan to remove these files). That does not work at > all for 64 bits. > > The 64bits VM does not work either with gcc and requires clang currently. > installing clang in mingw is tedious, while it's a prebuilt package in > cygwin. > > You now know why we use cygwin, not how, maybe it does not terribly helps, > but it's important in order to avoid regression, or to be aware of what > need to be done before changing the building environment again... > Could you detail what you tried exactly? > Setup cygwin: CYG_MIRROR=http://cygwin.mirror.constant.com CYG_ROOT='c:\cygwin' CYG_SETUP=setup-x86.exe MINGW_ARCH=i686 $CYG_SETUP -dgnqNO -R $CYG_ROOT -s "$CYG_MIRROR" -l "$CYG_ROOT"/var/cache/setup -P mingw64-$MINGW_ARCH-gcc-core,mingw64-$MINGW_ARCH-gcc-g++,mingw64-$MINGW_ARCH-headers,mingw64-$MINGW_ARCH-runtime,zip,mingw64-$MINGW_ARCH-clang,libiconv-devel,libglib2.0-devel,perl,mingw64-$MINGW_ARCH-zlib,cmake,mingw64-$MINGW_ARCH-win-iconv,make,wget (taken from the appveyor.xml, I needed to add make and wget, don't know why, from the appveyor log I see that make and wget is installed, even without this option...) Run the build (from an "empty" environment, that is, no other msys or mingw in the path environment variable) set FLAVOR=pharo.cog.spur set ARCH=win32x86 set MINGW_ARCH=i686 set CYG_ROOT=c:\cygwin set TRAVIS_OS_NAME=windows set PATH=%CYG_ROOT%\bin;p:\git\bin;%PATH%; git config --system core.autocrlf input git clone -q --depth=5 --branch=Cog https://github.com/OpenSmalltalk/opensmalltalk-vm.git C:\projects\vm SET APPVEYOR_BUILD_FOLDER=c:\projects\vm git checkout -qf 88c4c56245f3308e711b38467bb7636864886d16 %CYG_ROOT%\bin\bash -lc "cd $APPVEYOR_BUILD_FOLDER;exec 0</dev/null;exec ./.travis_build.sh" > > Nicolas > > >>> HernÃ¡n >>> >>> > >>> > nicolai >>> > >>> > >>> > >>> > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >> >>> >> >>> >> >>> >> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be < >>> philippe.back(a)gmail.com>: >>> >>> >>> >>> I made my own build here. >>> >>> Not up to date with latest stuff but should work for the build >>> process. >>> >>> >>> >>> https://ci.appveyor.com/project/philippeback/pharo-vm >>> >>> >>> >>> It uses my forked repo and provided you set your own bintray env >>> vars for API keys will publish there. >>> >>> >>> >>> Check all of the output of env vars and where/which in the appveyor >>> console to see what gets used when when it comes to compilers and so on as >>> there were various compiler versions involved at one point. >>> >>> >>> >>> Third party cache part is also worth checking. >>> >>> >>> >>> Still not able to build on my local box at the moment due to some >>> tools discrepancies happening. >>> >>> >>> >>> My build artifacts are embarking too much at this point but allow >>> you ro get the release, debug, and assert vms for windows. This helps when >>> debugging as backtraces and so on are much more meaningful and one can use >>> gdb more effectively to understand what is going on. >>> >>> >>> >>> Just keep the dlls and exes and you'll be fine. >>> >> >>> >> >>> >> Ah good, thank you. >>> >> >>> >> >>> >>> >>> >>> >>> >>> HTH >>> >>> >>> >>> Phil >>> >>> >>> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a >>> Ã©crit : >>> >>>> >>> >>>> >>> >>>> >>> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>>>>>> >>> >>>>>>>> Hi Nicolai, >>> >>>>>>>> >>> >>>>>>>> If you look at appveyor.yml configuration on >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, >>> you will see that the pharo brand is not yet in the matrix. >>> >>>>>>>> >>> >>>>>>>> It's because builds are based on cygwin, but as I understood, >>> some library used by some plugin required by pharo refuse to compile with >>> cygwin. They appear to work with mingw32. >>> >>>>>>>> Cygwin provides headers for legacy directx, some distribution >>> of mingw32 did in the past, but it does not seem the case anymore. >>> >>>>>>>> Using the directx headers from Microsoft SDK is a problem. They >>> are not redistributable and can't be found anymore on the net (too old). We >>> cannot seriously base the builds on something so fragile (both technically >>> and legally) in the long term. >>> >>>>>>>> >>> >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't >>> have anything available as a 64bits Microsoft SDK... So pharo has to fix >>> that too. >>> >>>>>>>> >>> >>>>>>>> In the interim, you should look at >>> https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml and >>> follow the scripts there. >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> Ok, thank you. >>> >>>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> I gave it a shot on sunday, because it was particularly rainy in >>> Nantes, and I almost succeeded in compiling all the dependencies with >>> cygwin. >>> >>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely >>> forget a few other niceties that some not so well informed programmers >>> committed with the faith that it would make their life "easier". It >>> certainly does not make mine simpler... >>> >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: >>> it seems that the workaround of Igor does not work anymore. >>> >>>>>> ssize_t, WTF??? >>> >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case >>> I'll publish the branch to see how far appveyor goes. >>> >>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> So I solved the ssize_t problem by removing the hack from Igor >>> which is not necessary anymore... >>> >>>>> But got another problem soon after while building the tests... >>> >>>>> There are trailing lines generated at end of >>> tests/cairo-test-constructors.c that make the compilation fail: >>> >>>>> >>> >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff >>> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src >>> -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opens >>> malltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16 >>> -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration >>> -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum >>> -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 >>> -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers >>> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline >>> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 >>> -Wno-unused-but-set-variable -D_REENTRANT -m32 >>> -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensm >>> alltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c -o >>> cairo_test_suite-cairo-test-constructors.o `test -f >>> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>> >>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de >>> donnÃ©es n'a pas de type ni de classe de stockage >>> >>>>> oning (); >>> >>>>> ^ >>> >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to >>> âintâ in declaration of âoningâ [-Wimplicit-int] >>> >>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de >>> donnÃ©es n'a pas de type ni de classe de stockage >>> >>>>> _register_ft_show_glyphs_table (); >>> >>>>> ^ >>> >>>>> >>> >>>>> And the file looks like it has obviously been overwritten, but not >>> truncated !!! >>> >>>>> >>> >>>>> ... >>> >>>>> extern void _register_multi_page (void); >>> >>>>> extern void _register_fallback_resolution (void); >>> >>>>> >>> >>>>> void >>> >>>>> _cairo_test_runner_register_tests (void) >>> >>>>> { >>> >>>>> _register_a1_bug (); >>> >>>>> _register_a1_clip_paint (); >>> >>>>> ... >>> >>>>> _register_multi_page (); >>> >>>>> _register_fallback_resolution (); >>> >>>>> } >>> >>>>> oning (); >>> >>>>> _register_ft_show_glyphs_table (); >>> >>>>> _register_ft_text_vertical_layout_type1 (); >>> >>>>> _register_ft_text_vertical_layout_type3 (); >>> >>>>> _register_ft_text_antialias_none (); >>> >>>>> _register_ps_eps (); >>> >>>>> _register_ps_features (); >>> >>>>> _register_ps_surface_source (); >>> >>>>> _register_svg_surface (); >>> >>>>> _register_svg_clip (); >>> >>>>> _register_svg_surface_source (); >>> >>>>> _register_multi_page (); >>> >>>>> _register_fallback_resolution (); >>> >>>>> } >>> >>>>> >>> >>>>> This file is generated by a shell script >>> test/make-cairo-test-constructors.sh >>> >>>>> I can't find any reference of the bug, and upgrade to version >>> 1.14.8 does not solve the issue. >>> >>>>> So it will wait until tomorrow... >>> >>>> >>> >>>> >>> >>>> >>> >>>> I got the build for windows with mingw nearly working. (it can not >>> build some plugins, like SqueakSSL for windows, because the used wincrypt.h >>> is different in the mingw distrubtion). >>> >>>> >>> >>>> I still have the problem, that there seems to be a preprocessing >>> step , that should put the vm-version (and source timestamp) in the >>> sqSCCSVersion.h >>> >>>> I got this working by running .travis_build.sh (with the options >>> for arch/flavor/platform) But how is this done normally when you build a vm >>> locally? >>> >>>> And how is this done for the pharo-vm we currently use? >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> Nicolas >>> >>>>> >>> >>>>>>>> >>> >>>>>>>> I hope that Esteban will find time to resolve all these >>> problems and have pharo brand back on opensmalltalk-vm. I guess that any >>> form of help is welcome. >>> >>>>>>>> >>> >>>>>>>> Nicolas >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >>>>>>>>> >>> >>>>>>>>> I still have problems building a vm on windows. >>> >>>>>>>>> can you give me some hints how to start ? >>> >>>>>>>>> I cloned the recent pharo-vm project, >>> >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>> >>>>>>>>> run >>> >>>>>>>>> mvm >>> >>>>>>>>> >>> >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not >>> found, I had to adjust the include path for finding directx header, missing >>> variable replacement for git-versions). >>> >>>>>>>>> So I may miss some important steps. >>> >>>>>>>>> Is there a repository where I can clone the mingw environment >>> used to build the win32-pharo-vm, the environment used on the build-server ? >>> >>>>>>>>> >>> >>>>>>>>> Thanks >>> >>>>>>>>> Nicolai >>> >>>>>>>>> >>> >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com >>> >: >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com >>> >: >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano < >>> estebanlm(a)gmail.com>: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess < >>> nicolaihess(a)gmail.com> wrote: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera < >>> bera.clement(a)gmail.com>: >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Hi, >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> I believe they're built from >>> https://github.com/OpenSmalltalk/vm using travis and appveyor. On the >>> gitbhub readme there are relevant links. All built artifacts are also kept >>> on bintray for history. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Thank you! >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> no, they arenât :) >>> >>>>>>>>>>>> instead, they are built here: >>> https://github.com/pharo-project/pharo-vm >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> (README still not updated) >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> what did changed ? I am not able to build the vm on windows >>> anymore (something wrong with generating the generator.image, I'll now >>> reset my local pharo-vm build directory and see if it works afterwards). >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> see attached the stderr log : >>> >>>>>>>>>> >>> >>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\Loa >>> dVMMaker.st' >>> >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>> >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>> >>>>>>>>>> BaseSoundSystem class>>initialize >>> >>>>>>>>>> MCMethodDefinition>>postloadOver: >>> >>>>>>>>>> >>> >>>>>>>>>> .... >>> >>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> Are we still working with branch spur-64, or are we back on >>> master ? >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Esteban >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess < >>> nicolaihess(a)gmail.com> wrote: >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >>> >>>>>>>>>>>>>> I don't see them on the build server, only the >>> buildresults at >>> >>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> The latest builds on the buildserver are from the last >>> year only. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> nicolai >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>> >>> >>>> >>> >> >>> > >>> >>> >> >

July 23, 2017

Re: [Pharo-dev] Epicea applying multiple changes

by Jan BlizniÄenko

Hello Might it be related to a problem I described over here? http://forum.world.st/Epicea-feedback-td4952661.html In short, I think that when I select multiple changes, epicea applies them in wrong order, so, if for example a single method is changed two times, Epicea first creates newer content and then replaces it by older content. It seems to be solvable by filtering just latest changes, but I am not sure whether it might not have other unwanted consequences. Jan tinchodias wrote > I'll check the bug, it's important. > > However, Tim and others, I'm interested in your experience with the UI. If > you want to send me more details... > > Maybe I can remark: Epicea has work and feedback accumulated during my > phd. > Now that phd finished and Epicea comes with Pharo 6.0, the project is open > to much more developers to collaborate with their work and feedback. So > you > are welcome. The project belongs to the community now even though I'm > still > responsible to maintain it, of course. > > Cheers, MartÃn > > On Thu, Jul 20, 2017 at 5:18 AM, Denis Kudriashov < > dionisiydk@ > > > wrote: > >> It is issue 20223 >> <https://pharo.fogbugz.com/f/cases/20223/Epicea-applying-collection-of-same-method-changes-uses-wrong-order> >> >> 2017-07-19 9:41 GMT+02:00 Tudor Girba < > tudor@ > >: >> >>> Hi, >>> >>> I experienced the same issues. It seems somehow related that when we >>> have >>> multiple changes to the same method, not all changes are applied and we >>> do >>> not get back the latest version. >>> >>> Cheers, >>> Doru >>> >>> >>> > On Jul 18, 2017, at 10:48 AM, Andrei Chis < > chisvasileandrei@ > > >>> wrote: >>> > >>> > Hi, >>> > >>> > Is there some known bug in Epicea when applying multiple changes at >>> once in Pharo 6? >>> > >>> > I had a few crashes lately and each time when recovering the changes >>> by >>> selecting multiple changes at once some changes are skipped. If I apply >>> manually each change it works. >>> > >>> > Cheers, >>> > Andrei >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Things happen when they happen, >>> not when you talk about them happening." >>> >>> >>> >> -- View this message in context: http://forum.world.st/Epicea-applying-multiple-changes-tp4955502p4956482.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 23, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolas Cellier

2017-07-23 19:56 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-07-23 19:42 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com > >: > >> 2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> > >> > Hm, I tried to create the build environment used for the >> > windows vm build from opensmalltalk. >> > >> > I setup a cygwin environment with the same install commands as from >> > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/. >> appveyor.yml >> > >> > My problems, first it is missing make and wget, I can add make and wget >> to the install command line for cygwin, but I am >> > curious why it is working on the build server ? >> > >> > Anyway, after I got this working, the build stops and building the >> pkg-config package. >> > The log says it can not find a gcc, I know that the build process with >> cygwin uses >> > i686-w64-mingw32-gcc >> > or >> > x86_64-w64-mingw32-gcc >> > >> > But I don't understand where is the missing step to tell the configure >> scripts to use the >> > >> > i686-w64-mingw32-gcc command instead of "gcc", >> > >> > again, this seems to work on the appveyor build but not locally on my >> machine. >> > >> > Any idea what I had missed? >> > >> >> I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in >> your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and >> the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the >> line: >> >> MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" >> >> to >> >> MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/bi >> n:/usr/bin:/bin" >> >> And finally >> >> source /etc/profile >> >> Cheers, >> > > I always had problems using mingw in the past. I got a working mingw > environment some years ago, and a newer mingw version > did not work well (some changes on the debug and exception format). > But now, the build process for pharo did change. (The build instructions > on github/pharo-vm are old and do not work anymore. > > And I hoped to get a more automatic and more reliable build process by > using the same commands used by the build server for > the opensmalltalk pharo vm sources. > > And I thought the compiler used to build the latest pharo-vm for windows > is from cygwin ? > > > Hi Nicolai, more exactly we cross compile from a cygwin environment for a mingw target. The main reason for switching to cygwin are: - this is required for the 64 bit vm - the other flavours on opensmallalk (squeak/newspeak) were also built with cygwin, so it's more simple to maintain a single way of doing things Cygwin is required for the 64bits vm because of directx. Indeed cygwin still provides support for the legacy directx version used by the VM, while recent mingw does not. Until we port to a newer API, mingw thus depends on the MS directx include and library files that we redistribute for 32 bits only (and we should not without permission, I plan to remove these files). That does not work at all for 64 bits. The 64bits VM does not work either with gcc and requires clang currently. installing clang in mingw is tedious, while it's a prebuilt package in cygwin. You now know why we use cygwin, not how, maybe it does not terribly helps, but it's important in order to avoid regression, or to be aware of what need to be done before changing the building environment again... Could you detail what you tried exactly? Nicolas >> HernÃ¡n >> >> > >> > nicolai >> > >> > >> > >> > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >> >> >> >> >> >> >> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be < >> philippe.back(a)gmail.com>: >> >>> >> >>> I made my own build here. >> >>> Not up to date with latest stuff but should work for the build >> process. >> >>> >> >>> https://ci.appveyor.com/project/philippeback/pharo-vm >> >>> >> >>> It uses my forked repo and provided you set your own bintray env vars >> for API keys will publish there. >> >>> >> >>> Check all of the output of env vars and where/which in the appveyor >> console to see what gets used when when it comes to compilers and so on as >> there were various compiler versions involved at one point. >> >>> >> >>> Third party cache part is also worth checking. >> >>> >> >>> Still not able to build on my local box at the moment due to some >> tools discrepancies happening. >> >>> >> >>> My build artifacts are embarking too much at this point but allow you >> ro get the release, debug, and assert vms for windows. This helps when >> debugging as backtraces and so on are much more meaningful and one can use >> gdb more effectively to understand what is going on. >> >>> >> >>> Just keep the dlls and exes and you'll be fine. >> >> >> >> >> >> Ah good, thank you. >> >> >> >> >> >>> >> >>> >> >>> HTH >> >>> >> >>> Phil >> >>> >> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a >> Ã©crit : >> >>>> >> >>>> >> >>>> >> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com>: >> >>>>> >> >>>>> >> >>>>> >> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com>: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com>: >> >>>>>>>> >> >>>>>>>> Hi Nicolai, >> >>>>>>>> >> >>>>>>>> If you look at appveyor.yml configuration on >> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, >> you will see that the pharo brand is not yet in the matrix. >> >>>>>>>> >> >>>>>>>> It's because builds are based on cygwin, but as I understood, >> some library used by some plugin required by pharo refuse to compile with >> cygwin. They appear to work with mingw32. >> >>>>>>>> Cygwin provides headers for legacy directx, some distribution of >> mingw32 did in the past, but it does not seem the case anymore. >> >>>>>>>> Using the directx headers from Microsoft SDK is a problem. They >> are not redistributable and can't be found anymore on the net (too old). We >> cannot seriously base the builds on something so fragile (both technically >> and legally) in the long term. >> >>>>>>>> >> >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't >> have anything available as a 64bits Microsoft SDK... So pharo has to fix >> that too. >> >>>>>>>> >> >>>>>>>> In the interim, you should look at >> https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml and >> follow the scripts there. >> >>>>>>> >> >>>>>>> >> >>>>>>> Ok, thank you. >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I gave it a shot on sunday, because it was particularly rainy in >> Nantes, and I almost succeeded in compiling all the dependencies with >> cygwin. >> >>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely >> forget a few other niceties that some not so well informed programmers >> committed with the faith that it would make their life "easier". It >> certainly does not make mine simpler... >> >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it >> seems that the workaround of Igor does not work anymore. >> >>>>>> ssize_t, WTF??? >> >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case >> I'll publish the branch to see how far appveyor goes. >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>>> So I solved the ssize_t problem by removing the hack from Igor >> which is not necessary anymore... >> >>>>> But got another problem soon after while building the tests... >> >>>>> There are trailing lines generated at end of >> tests/cairo-test-constructors.c that make the compilation fail: >> >>>>> >> >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff >> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src >> -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opens >> malltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16 >> -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration >> -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum >> -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 >> -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers >> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline >> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 >> -Wno-unused-but-set-variable -D_REENTRANT -m32 >> -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensm >> alltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c -o >> cairo_test_suite-cairo-test-constructors.o `test -f >> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >> >>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de >> donnÃ©es n'a pas de type ni de classe de stockage >> >>>>> oning (); >> >>>>> ^ >> >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to >> âintâ in declaration of âoningâ [-Wimplicit-int] >> >>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de >> donnÃ©es n'a pas de type ni de classe de stockage >> >>>>> _register_ft_show_glyphs_table (); >> >>>>> ^ >> >>>>> >> >>>>> And the file looks like it has obviously been overwritten, but not >> truncated !!! >> >>>>> >> >>>>> ... >> >>>>> extern void _register_multi_page (void); >> >>>>> extern void _register_fallback_resolution (void); >> >>>>> >> >>>>> void >> >>>>> _cairo_test_runner_register_tests (void) >> >>>>> { >> >>>>> _register_a1_bug (); >> >>>>> _register_a1_clip_paint (); >> >>>>> ... >> >>>>> _register_multi_page (); >> >>>>> _register_fallback_resolution (); >> >>>>> } >> >>>>> oning (); >> >>>>> _register_ft_show_glyphs_table (); >> >>>>> _register_ft_text_vertical_layout_type1 (); >> >>>>> _register_ft_text_vertical_layout_type3 (); >> >>>>> _register_ft_text_antialias_none (); >> >>>>> _register_ps_eps (); >> >>>>> _register_ps_features (); >> >>>>> _register_ps_surface_source (); >> >>>>> _register_svg_surface (); >> >>>>> _register_svg_clip (); >> >>>>> _register_svg_surface_source (); >> >>>>> _register_multi_page (); >> >>>>> _register_fallback_resolution (); >> >>>>> } >> >>>>> >> >>>>> This file is generated by a shell script >> test/make-cairo-test-constructors.sh >> >>>>> I can't find any reference of the bug, and upgrade to version >> 1.14.8 does not solve the issue. >> >>>>> So it will wait until tomorrow... >> >>>> >> >>>> >> >>>> >> >>>> I got the build for windows with mingw nearly working. (it can not >> build some plugins, like SqueakSSL for windows, because the used wincrypt.h >> is different in the mingw distrubtion). >> >>>> >> >>>> I still have the problem, that there seems to be a preprocessing >> step , that should put the vm-version (and source timestamp) in the >> sqSCCSVersion.h >> >>>> I got this working by running .travis_build.sh (with the options >> for arch/flavor/platform) But how is this done normally when you build a vm >> locally? >> >>>> And how is this done for the pharo-vm we currently use? >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> Nicolas >> >>>>> >> >>>>>>>> >> >>>>>>>> I hope that Esteban will find time to resolve all these problems >> and have pharo brand back on opensmalltalk-vm. I guess that any form of >> help is welcome. >> >>>>>>>> >> >>>>>>>> Nicolas >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>>>>>>>> >> >>>>>>>>> I still have problems building a vm on windows. >> >>>>>>>>> can you give me some hints how to start ? >> >>>>>>>>> I cloned the recent pharo-vm project, >> >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >> >>>>>>>>> run >> >>>>>>>>> mvm >> >>>>>>>>> >> >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not >> found, I had to adjust the include path for finding directx header, missing >> variable replacement for git-versions). >> >>>>>>>>> So I may miss some important steps. >> >>>>>>>>> Is there a repository where I can clone the mingw environment >> used to build the win32-pharo-vm, the environment used on the build-server ? >> >>>>>>>>> >> >>>>>>>>> Thanks >> >>>>>>>>> Nicolai >> >>>>>>>>> >> >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com >> >: >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano < >> estebanlm(a)gmail.com>: >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess < >> nicolaihess(a)gmail.com> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera < >> bera.clement(a)gmail.com>: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Hi, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I believe they're built from https://github.com/OpenSmallta >> lk/vm using travis and appveyor. On the gitbhub readme there are >> relevant links. All built artifacts are also kept on bintray for history. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Thank you! >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> no, they arenât :) >> >>>>>>>>>>>> instead, they are built here: https://github.com/pharo-proje >> ct/pharo-vm >> >>>>>>>>>>>> >> >>>>>>>>>>>> (README still not updated) >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> what did changed ? I am not able to build the vm on windows >> anymore (something wrong with generating the generator.image, I'll now >> reset my local pharo-vm build directory and see if it works afterwards). >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> see attached the stderr log : >> >>>>>>>>>> >> >>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\Loa >> dVMMaker.st' >> >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >> >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >> >>>>>>>>>> BaseSoundSystem class>>initialize >> >>>>>>>>>> MCMethodDefinition>>postloadOver: >> >>>>>>>>>> >> >>>>>>>>>> .... >> >>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> Are we still working with branch spur-64, or are we back on >> master ? >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Esteban >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess < >> nicolaihess(a)gmail.com> wrote: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >> >>>>>>>>>>>>>> I don't see them on the build server, only the >> buildresults at >> >>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> The latest builds on the buildserver are from the last >> year only. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> nicolai >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >> >> > >> >> >

July 23, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolai Hess

2017-07-23 19:42 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > 2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > Hm, I tried to create the build environment used for the > > windows vm build from opensmalltalk. > > > > I setup a cygwin environment with the same install commands as from > > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml > > > > My problems, first it is missing make and wget, I can add make and wget > to the install command line for cygwin, but I am > > curious why it is working on the build server ? > > > > Anyway, after I got this working, the build stops and building the > pkg-config package. > > The log says it can not find a gcc, I know that the build process with > cygwin uses > > i686-w64-mingw32-gcc > > or > > x86_64-w64-mingw32-gcc > > > > But I don't understand where is the missing step to tell the configure > scripts to use the > > > > i686-w64-mingw32-gcc command instead of "gcc", > > > > again, this seems to work on the appveyor build but not locally on my > machine. > > > > Any idea what I had missed? > > > > I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in > your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and > the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the > line: > > MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" > > to > > MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/ > bin:/usr/bin:/bin" > > And finally > > source /etc/profile > > Cheers, > I always had problems using mingw in the past. I got a working mingw environment some years ago, and a newer mingw version did not work well (some changes on the debug and exception format). But now, the build process for pharo did change. (The build instructions on github/pharo-vm are old and do not work anymore. And I hoped to get a more automatic and more reliable build process by using the same commands used by the build server for the opensmalltalk pharo vm sources. And I thought the compiler used to build the latest pharo-vm for windows is from cygwin ? > > HernÃ¡n > > > > > nicolai > > > > > > > > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> > >> > >> > >> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be < > philippe.back(a)gmail.com>: > >>> > >>> I made my own build here. > >>> Not up to date with latest stuff but should work for the build process. > >>> > >>> https://ci.appveyor.com/project/philippeback/pharo-vm > >>> > >>> It uses my forked repo and provided you set your own bintray env vars > for API keys will publish there. > >>> > >>> Check all of the output of env vars and where/which in the appveyor > console to see what gets used when when it comes to compilers and so on as > there were various compiler versions involved at one point. > >>> > >>> Third party cache part is also worth checking. > >>> > >>> Still not able to build on my local box at the moment due to some > tools discrepancies happening. > >>> > >>> My build artifacts are embarking too much at this point but allow you > ro get the release, debug, and assert vms for windows. This helps when > debugging as backtraces and so on are much more meaningful and one can use > gdb more effectively to understand what is going on. > >>> > >>> Just keep the dlls and exes and you'll be fine. > >> > >> > >> Ah good, thank you. > >> > >> > >>> > >>> > >>> HTH > >>> > >>> Phil > >>> > >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit > : > >>>> > >>>> > >>>> > >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >>>>> > >>>>> > >>>>> > >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > >>>>>>>> > >>>>>>>> Hi Nicolai, > >>>>>>>> > >>>>>>>> If you look at appveyor.yml configuration on https://github.com/ > OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, you will see that > the pharo brand is not yet in the matrix. > >>>>>>>> > >>>>>>>> It's because builds are based on cygwin, but as I understood, > some library used by some plugin required by pharo refuse to compile with > cygwin. They appear to work with mingw32. > >>>>>>>> Cygwin provides headers for legacy directx, some distribution of > mingw32 did in the past, but it does not seem the case anymore. > >>>>>>>> Using the directx headers from Microsoft SDK is a problem. They > are not redistributable and can't be found anymore on the net (too old). We > cannot seriously base the builds on something so fragile (both technically > and legally) in the long term. > >>>>>>>> > >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't have > anything available as a 64bits Microsoft SDK... So pharo has to fix that > too. > >>>>>>>> > >>>>>>>> In the interim, you should look at https://github.com/pharo- > project/pharo-vm/blob/master/.appveyor.yml and follow the scripts there. > >>>>>>> > >>>>>>> > >>>>>>> Ok, thank you. > >>>>>>> > >>>>>> > >>>>>> > >>>>>> I gave it a shot on sunday, because it was particularly rainy in > Nantes, and I almost succeeded in compiling all the dependencies with > cygwin. > >>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely > forget a few other niceties that some not so well informed programmers > committed with the faith that it would make their life "easier". It > certainly does not make mine simpler... > >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it > seems that the workaround of Igor does not work anymore. > >>>>>> ssize_t, WTF??? > >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case > I'll publish the branch to see how far appveyor goes. > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> So I solved the ssize_t problem by removing the hack from Igor which > is not necessary anymore... > >>>>> But got another problem soon after while building the tests... > >>>>> There are trailing lines generated at end of > tests/cairo-test-constructors.c that make the compilation fail: > >>>>> > >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff > -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src > -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/ > opensmalltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 > -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty- > cache/windows/i386/include/libpng16 -Wall -Wextra > -Wmissing-declarations -Werror-implicit-function-declaration > -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum > -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 > -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers > -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline > -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 > -Wno-unused-but-set-variable -D_REENTRANT -m32 > -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/ > opensmalltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 > -c -o cairo_test_suite-cairo-test-constructors.o `test -f > 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c > >>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de > donnÃ©es n'a pas de type ni de classe de stockage > >>>>> oning (); > >>>>> ^ > >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to > âintâ in declaration of âoningâ [-Wimplicit-int] > >>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de > donnÃ©es n'a pas de type ni de classe de stockage > >>>>> _register_ft_show_glyphs_table (); > >>>>> ^ > >>>>> > >>>>> And the file looks like it has obviously been overwritten, but not > truncated !!! > >>>>> > >>>>> ... > >>>>> extern void _register_multi_page (void); > >>>>> extern void _register_fallback_resolution (void); > >>>>> > >>>>> void > >>>>> _cairo_test_runner_register_tests (void) > >>>>> { > >>>>> _register_a1_bug (); > >>>>> _register_a1_clip_paint (); > >>>>> ... > >>>>> _register_multi_page (); > >>>>> _register_fallback_resolution (); > >>>>> } > >>>>> oning (); > >>>>> _register_ft_show_glyphs_table (); > >>>>> _register_ft_text_vertical_layout_type1 (); > >>>>> _register_ft_text_vertical_layout_type3 (); > >>>>> _register_ft_text_antialias_none (); > >>>>> _register_ps_eps (); > >>>>> _register_ps_features (); > >>>>> _register_ps_surface_source (); > >>>>> _register_svg_surface (); > >>>>> _register_svg_clip (); > >>>>> _register_svg_surface_source (); > >>>>> _register_multi_page (); > >>>>> _register_fallback_resolution (); > >>>>> } > >>>>> > >>>>> This file is generated by a shell script test/make-cairo-test- > constructors.sh > >>>>> I can't find any reference of the bug, and upgrade to version 1.14.8 > does not solve the issue. > >>>>> So it will wait until tomorrow... > >>>> > >>>> > >>>> > >>>> I got the build for windows with mingw nearly working. (it can not > build some plugins, like SqueakSSL for windows, because the used wincrypt.h > is different in the mingw distrubtion). > >>>> > >>>> I still have the problem, that there seems to be a preprocessing step > , that should put the vm-version (and source timestamp) in the > sqSCCSVersion.h > >>>> I got this working by running .travis_build.sh (with the options for > arch/flavor/platform) But how is this done normally when you build a vm > locally? > >>>> And how is this done for the pharo-vm we currently use? > >>>> > >>>> > >>>>> > >>>>> > >>>>> Nicolas > >>>>> > >>>>>>>> > >>>>>>>> I hope that Esteban will find time to resolve all these problems > and have pharo brand back on opensmalltalk-vm. I guess that any form of > help is welcome. > >>>>>>>> > >>>>>>>> Nicolas > >>>>>>>> > >>>>>>>> > >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >>>>>>>>> > >>>>>>>>> I still have problems building a vm on windows. > >>>>>>>>> can you give me some hints how to start ? > >>>>>>>>> I cloned the recent pharo-vm project, > >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ > >>>>>>>>> run > >>>>>>>>> mvm > >>>>>>>>> > >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not > found, I had to adjust the include path for finding directx header, missing > variable replacement for git-versions). > >>>>>>>>> So I may miss some important steps. > >>>>>>>>> Is there a repository where I can clone the mingw environment > used to build the win32-pharo-vm, the environment used on the build-server ? > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> Nicolai > >>>>>>>>> > >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano < > estebanlm(a)gmail.com>: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera < > bera.clement(a)gmail.com>: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I believe they're built from https://github.com/ > OpenSmalltalk/vm using travis and appveyor. On the gitbhub readme there > are relevant links. All built artifacts are also kept on bintray for > history. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you! > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> no, they arenât :) > >>>>>>>>>>>> instead, they are built here: https://github.com/pharo- > project/pharo-vm > >>>>>>>>>>>> > >>>>>>>>>>>> (README still not updated) > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> what did changed ? I am not able to build the vm on windows > anymore (something wrong with generating the generator.image, I'll now > reset my local pharo-vm build directory and see if it works afterwards). > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> see attached the stderr log : > >>>>>>>>>> > >>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\ > LoadVMMaker.st' > >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil > >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: > >>>>>>>>>> BaseSoundSystem class>>initialize > >>>>>>>>>> MCMethodDefinition>>postloadOver: > >>>>>>>>>> > >>>>>>>>>> .... > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Are we still working with branch spur-64, or are we back on > master ? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Esteban > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess < > nicolaihess(a)gmail.com> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? > >>>>>>>>>>>>>> I don't see them on the build server, only the buildresults > at > >>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The latest builds on the buildserver are from the last year > only. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> nicolai > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > > > >

July 23, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolai Hess

2017-07-22 20:26 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > > On Jul 22, 2017, at 6:03 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Hm, I tried to create the build environment used for the > windows vm build from opensmalltalk. > > I setup a cygwin environment with the same install commands as from > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml > > My problems, first it is missing make and wget, I can add make and wget to > the install command line for cygwin, but I am > curious why it is working on the build server ? > > Anyway, after I got this working, the build stops and building the > pkg-config package. > The log says it can not find a gcc, I know that the build process with > cygwin uses > i686-w64-mingw32-gcc > or > x86_64-w64-mingw32-gcc > > But I don't understand where is the missing step to tell the configure > scripts to use the > > i686-w64-mingw32-gcc command instead of "gcc", > > > There isn't a configure script. The choice of which compiler to make, > flags to use etc is made in > build.win32x86/common/Makefile.rules > build.win32x86/common/Makefile.tools > and should be able to be overridden by editing > build.win32x86/pharo.cog.spur/Makefile > The configure script is used by third party libs (for pharo only (pk-config)). > > > again, this seems to work on the appveyor build but not locally on my > machine. > > Any idea what I had missed? > > > nicolai > > > > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be < >> philippe.back(a)gmail.com>: >> >>> I made my own build here. >>> Not up to date with latest stuff but should work for the build process. >>> >>> https://ci.appveyor.com/project/philippeback/pharo-vm >>> >>> It uses my forked repo and provided you set your own bintray env vars >>> for API keys will publish there. >>> >>> Check all of the output of env vars and where/which in the appveyor >>> console to see what gets used when when it comes to compilers and so on as >>> there were various compiler versions involved at one point. >>> >>> Third party cache part is also worth checking. >>> >>> Still not able to build on my local box at the moment due to some tools >>> discrepancies happening. >>> >>> My build artifacts are embarking too much at this point but allow you ro >>> get the release, debug, and assert vms for windows. This helps when >>> debugging as backtraces and so on are much more meaningful and one can use >>> gdb more effectively to understand what is going on. >>> >>> Just keep the dlls and exes and you'll be fine. >>> >> >> Ah good, thank you. >> >> >> >>> >>> HTH >>> >>> Phil >>> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit : >>> >>>> >>>> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>>> >>>>> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier < >>>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier < >>>>>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>>>>> >>>>>>>> Hi Nicolai, >>>>>>>> >>>>>>>> If you look at appveyor.yml configuration on >>>>>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/. >>>>>>>> appveyor.yml, you will see that the pharo brand is not yet in the >>>>>>>> matrix. >>>>>>>> >>>>>>>> It's because builds are based on cygwin, but as I understood, some >>>>>>>> library used by some plugin required by pharo refuse to compile with >>>>>>>> cygwin. They appear to work with mingw32. >>>>>>>> Cygwin provides headers for legacy directx, some distribution of >>>>>>>> mingw32 did in the past, but it does not seem the case anymore. >>>>>>>> Using the directx headers from Microsoft SDK is a problem. They are >>>>>>>> not redistributable and can't be found anymore on the net (too old). We >>>>>>>> cannot seriously base the builds on something so fragile (both technically >>>>>>>> and legally) in the long term. >>>>>>>> >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't have >>>>>>>> anything available as a 64bits Microsoft SDK... So pharo has to fix that >>>>>>>> too. >>>>>>>> >>>>>>>> In the interim, you should look at https://github.com/pharo-proje >>>>>>>> ct/pharo-vm/blob/master/.appveyor.yml and follow the scripts there. >>>>>>>> >>>>>>> >>>>>>> Ok, thank you. >>>>>>> >>>>>>> >>>>>> >>>>>> I gave it a shot on sunday, because it was particularly rainy in >>>>>> Nantes, and I almost succeeded in compiling all the dependencies with >>>>>> cygwin. >>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely >>>>>> forget a few other niceties that some not so well informed programmers >>>>>> committed with the faith that it would make their life "easier". It >>>>>> certainly does not make mine simpler... >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it >>>>>> seems that the workaround of Igor does not work anymore. >>>>>> ssize_t, WTF??? >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case I'll >>>>>> publish the branch to see how far appveyor goes. >>>>>> >>>>>> >>>>>> >>>>> >>>>> So I solved the ssize_t problem by removing the hack from Igor which >>>>> is not necessary anymore... >>>>> But got another problem soon after while building the tests... >>>>> There are trailing lines generated at end of >>>>> tests/cairo-test-constructors.c that make the compilation fail: >>>>> >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff >>>>> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src >>>>> -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opensm >>>>> alltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >>>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/w >>>>> indows/i386/include/libpng16 -Wall -Wextra -Wmissing-declarations >>>>> -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings >>>>> -Wsign-compare -Wpacked -Wswitch-enum -Wmissing-format-attribute >>>>> -Wvolatile-register-var -Wstrict-aliasing=2 -Winit-self >>>>> -Wunsafe-loop-optimizations -Wno-missing-field-initializers >>>>> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline >>>>> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 >>>>> -Wno-unused-but-set-variable -D_REENTRANT -m32 >>>>> -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensm >>>>> alltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c >>>>> -o cairo_test_suite-cairo-test-constructors.o `test -f >>>>> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de >>>>> donnÃ©es n'a pas de type ni de classe de stockage >>>>> oning (); >>>>> ^ >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to âintâ >>>>> in declaration of âoningâ [-Wimplicit-int] >>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de >>>>> donnÃ©es n'a pas de type ni de classe de stockage >>>>> _register_ft_show_glyphs_table (); >>>>> ^ >>>>> >>>>> And the file looks like it has obviously been overwritten, but not >>>>> truncated !!! >>>>> >>>>> ... >>>>> extern void _register_multi_page (void); >>>>> extern void _register_fallback_resolution (void); >>>>> >>>>> void >>>>> _cairo_test_runner_register_tests (void) >>>>> { >>>>> _register_a1_bug (); >>>>> _register_a1_clip_paint (); >>>>> ... >>>>> _register_multi_page (); >>>>> _register_fallback_resolution (); >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *oning (); _register_ft_show_glyphs_table (); >>>>> _register_ft_text_vertical_layout_type1 (); >>>>> _register_ft_text_vertical_layout_type3 (); >>>>> _register_ft_text_antialias_none (); _register_ps_eps (); >>>>> _register_ps_features (); _register_ps_surface_source (); >>>>> _register_svg_surface (); _register_svg_clip (); >>>>> _register_svg_surface_source (); _register_multi_page (); >>>>> _register_fallback_resolution ();}* >>>>> >>>>> This file is generated by a shell script test/make-cairo-test-construct >>>>> ors.sh >>>>> I can't find any reference of the bug, and upgrade to version 1.14.8 >>>>> does not solve the issue. >>>>> So it will wait until tomorrow... >>>>> >>>> >>>> >>>> I got the build for windows with mingw nearly working. (it can not >>>> build some plugins, like SqueakSSL for windows, because the used wincrypt.h >>>> is different in the mingw distrubtion). >>>> >>>> I still have the problem, that there seems to be a preprocessing step , >>>> that should put the vm-version (and source timestamp) in the >>>> *sqSCCSVersion.h* >>>> I got this working by running .travis_build.sh (with the options for >>>> arch/flavor/platform) But how is this done normally when you build a vm >>>> locally? >>>> And how is this done for the pharo-vm we currently use? >>>> >>>> >>>> >>>>> >>>>> Nicolas >>>>> >>>>> >>>>>>>> I hope that Esteban will find time to resolve all these problems >>>>>>>> and have pharo brand back on opensmalltalk-vm. I guess that any form of >>>>>>>> help is welcome. >>>>>>>> >>>>>>>> Nicolas >>>>>>>> >>>>>>>> >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>> >>>>>>>>> I still have problems building a vm on windows. >>>>>>>>> can you give me some hints how to start ? >>>>>>>>> I cloned the recent pharo-vm project, >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>>>>>>>> run >>>>>>>>> mvm >>>>>>>>> >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not >>>>>>>>> found, I had to adjust the include path for finding directx header, missing >>>>>>>>> variable replacement for git-versions). >>>>>>>>> So I may miss some important steps. >>>>>>>>> Is there a repository where I can clone the mingw environment used >>>>>>>>> to build the win32-pharo-vm, the environment used on the build-server ? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Nicolai >>>>>>>>> >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com >>>>>>>>>>> >: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess(a)gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com >>>>>>>>>>>> >: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I believe they're built from* https://github.com/OpenSmalltalk/vm >>>>>>>>>>>>> <https://github.com/OpenSmalltalk/vm>* using travis and >>>>>>>>>>>>> appveyor. On the gitbhub readme there are relevant links. All built >>>>>>>>>>>>> artifacts are also kept on bintray for history. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Thank you! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> no, they arenât :) >>>>>>>>>>>> instead, they are built here: https://github.com/pharo >>>>>>>>>>>> -project/pharo-vm >>>>>>>>>>>> >>>>>>>>>>>> (README still not updated) >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> what did changed ? I am not able to build the vm on windows >>>>>>>>>>> anymore (something wrong with generating the generator.image, I'll now >>>>>>>>>>> reset my local pharo-vm build directory and see if it works afterwards). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> see attached the stderr log : >>>>>>>>>> >>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\Loa >>>>>>>>>> dVMMaker.st' >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>>>>>>>>> BaseSoundSystem class>>initialize >>>>>>>>>> MCMethodDefinition>>postloadOver: >>>>>>>>>> >>>>>>>>>> .... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Are we still working with branch spur-64, or are we back on >>>>>>>>>>> master ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Esteban >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess < >>>>>>>>>>>>> nicolaihess(a)gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >>>>>>>>>>>>>> I don't see them on the build server, only the buildresults at >>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> The latest builds on the buildserver are from the last year >>>>>>>>>>>>>> only. >>>>>>>>>>>>>> >>>>>>>>>>>>>> nicolai >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >

July 23, 2017

Re: [Pharo-dev] PharoSpur32Vm

by HernÃ¡n Morales Durand

2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > Hm, I tried to create the build environment used for the > windows vm build from opensmalltalk. > > I setup a cygwin environment with the same install commands as from > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml > > My problems, first it is missing make and wget, I can add make and wget to the install command line for cygwin, but I am > curious why it is working on the build server ? > > Anyway, after I got this working, the build stops and building the pkg-config package. > The log says it can not find a gcc, I know that the build process with cygwin uses > i686-w64-mingw32-gcc > or > x86_64-w64-mingw32-gcc > > But I don't understand where is the missing step to tell the configure scripts to use the > > i686-w64-mingw32-gcc command instead of "gcc", > > again, this seems to work on the appveyor build but not locally on my machine. > > Any idea what I had missed? > I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the line: MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" to MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/bin:/usr/bin:/bin" And finally source /etc/profile Cheers, HernÃ¡n > > nicolai > > > > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >> >> >> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be <philippe.back(a)gmail.com>: >>> >>> I made my own build here. >>> Not up to date with latest stuff but should work for the build process. >>> >>> https://ci.appveyor.com/project/philippeback/pharo-vm >>> >>> It uses my forked repo and provided you set your own bintray env vars for API keys will publish there. >>> >>> Check all of the output of env vars and where/which in the appveyor console to see what gets used when when it comes to compilers and so on as there were various compiler versions involved at one point. >>> >>> Third party cache part is also worth checking. >>> >>> Still not able to build on my local box at the moment due to some tools discrepancies happening. >>> >>> My build artifacts are embarking too much at this point but allow you ro get the release, debug, and assert vms for windows. This helps when debugging as backtraces and so on are much more meaningful and one can use gdb more effectively to understand what is going on. >>> >>> Just keep the dlls and exes and you'll be fine. >> >> >> Ah good, thank you. >> >> >>> >>> >>> HTH >>> >>> Phil >>> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit : >>>> >>>> >>>> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>> >>>>> >>>>> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>> >>>>>> >>>>>> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>>>> >>>>>>>> Hi Nicolai, >>>>>>>> >>>>>>>> If you look at appveyor.yml configuration on https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, you will see that the pharo brand is not yet in the matrix. >>>>>>>> >>>>>>>> It's because builds are based on cygwin, but as I understood, some library used by some plugin required by pharo refuse to compile with cygwin. They appear to work with mingw32. >>>>>>>> Cygwin provides headers for legacy directx, some distribution of mingw32 did in the past, but it does not seem the case anymore. >>>>>>>> Using the directx headers from Microsoft SDK is a problem. They are not redistributable and can't be found anymore on the net (too old). We cannot seriously base the builds on something so fragile (both technically and legally) in the long term. >>>>>>>> >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't have anything available as a 64bits Microsoft SDK... So pharo has to fix that too. >>>>>>>> >>>>>>>> In the interim, you should look at https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml and follow the scripts there. >>>>>>> >>>>>>> >>>>>>> Ok, thank you. >>>>>>> >>>>>> >>>>>> >>>>>> I gave it a shot on sunday, because it was particularly rainy in Nantes, and I almost succeeded in compiling all the dependencies with cygwin. >>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely forget a few other niceties that some not so well informed programmers committed with the faith that it would make their life "easier". It certainly does not make mine simpler... >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it seems that the workaround of Igor does not work anymore. >>>>>> ssize_t, WTF??? >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case I'll publish the branch to see how far appveyor goes. >>>>>> >>>>>> >>>>> >>>>> >>>>> So I solved the ssize_t problem by removing the hack from Igor which is not necessary anymore... >>>>> But got another problem soon after while building the tests... >>>>> There are trailing lines generated at end of tests/cairo-test-constructors.c that make the compilation fail: >>>>> >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16 -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 -Wno-unused-but-set-variable -D_REENTRANT -m32 -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c -o cairo_test_suite-cairo-test-constructors.o `test -f 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de donnÃ©es n'a pas de type ni de classe de stockage >>>>> oning (); >>>>> ^ >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to âintâ in declaration of âoningâ [-Wimplicit-int] >>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de donnÃ©es n'a pas de type ni de classe de stockage >>>>> _register_ft_show_glyphs_table (); >>>>> ^ >>>>> >>>>> And the file looks like it has obviously been overwritten, but not truncated !!! >>>>> >>>>> ... >>>>> extern void _register_multi_page (void); >>>>> extern void _register_fallback_resolution (void); >>>>> >>>>> void >>>>> _cairo_test_runner_register_tests (void) >>>>> { >>>>> _register_a1_bug (); >>>>> _register_a1_clip_paint (); >>>>> ... >>>>> _register_multi_page (); >>>>> _register_fallback_resolution (); >>>>> } >>>>> oning (); >>>>> _register_ft_show_glyphs_table (); >>>>> _register_ft_text_vertical_layout_type1 (); >>>>> _register_ft_text_vertical_layout_type3 (); >>>>> _register_ft_text_antialias_none (); >>>>> _register_ps_eps (); >>>>> _register_ps_features (); >>>>> _register_ps_surface_source (); >>>>> _register_svg_surface (); >>>>> _register_svg_clip (); >>>>> _register_svg_surface_source (); >>>>> _register_multi_page (); >>>>> _register_fallback_resolution (); >>>>> } >>>>> >>>>> This file is generated by a shell script test/make-cairo-test-constructors.sh >>>>> I can't find any reference of the bug, and upgrade to version 1.14.8 does not solve the issue. >>>>> So it will wait until tomorrow... >>>> >>>> >>>> >>>> I got the build for windows with mingw nearly working. (it can not build some plugins, like SqueakSSL for windows, because the used wincrypt.h is different in the mingw distrubtion). >>>> >>>> I still have the problem, that there seems to be a preprocessing step , that should put the vm-version (and source timestamp) in the sqSCCSVersion.h >>>> I got this working by running .travis_build.sh (with the options for arch/flavor/platform) But how is this done normally when you build a vm locally? >>>> And how is this done for the pharo-vm we currently use? >>>> >>>> >>>>> >>>>> >>>>> Nicolas >>>>> >>>>>>>> >>>>>>>> I hope that Esteban will find time to resolve all these problems and have pharo brand back on opensmalltalk-vm. I guess that any form of help is welcome. >>>>>>>> >>>>>>>> Nicolas >>>>>>>> >>>>>>>> >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>> >>>>>>>>> I still have problems building a vm on windows. >>>>>>>>> can you give me some hints how to start ? >>>>>>>>> I cloned the recent pharo-vm project, >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>>>>>>>> run >>>>>>>>> mvm >>>>>>>>> >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not found, I had to adjust the include path for finding directx header, missing variable replacement for git-versions). >>>>>>>>> So I may miss some important steps. >>>>>>>>> Is there a repository where I can clone the mingw environment used to build the win32-pharo-vm, the environment used on the build-server ? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Nicolai >>>>>>>>> >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I believe they're built from https://github.com/OpenSmalltalk/vm using travis and appveyor. On the gitbhub readme there are relevant links. All built artifacts are also kept on bintray for history. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thank you! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> no, they arenât :) >>>>>>>>>>>> instead, they are built here: https://github.com/pharo-project/pharo-vm >>>>>>>>>>>> >>>>>>>>>>>> (README still not updated) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> what did changed ? I am not able to build the vm on windows anymore (something wrong with generating the generator.image, I'll now reset my local pharo-vm build directory and see if it works afterwards). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> see attached the stderr log : >>>>>>>>>> >>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\LoadVMMaker.st' >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>>>>>>>>> BaseSoundSystem class>>initialize >>>>>>>>>> MCMethodDefinition>>postloadOver: >>>>>>>>>> >>>>>>>>>> .... >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Are we still working with branch spur-64, or are we back on master ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Esteban >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >>>>>>>>>>>>>> I don't see them on the build server, only the buildresults at >>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> The latest builds on the buildserver are from the last year only. >>>>>>>>>>>>>> >>>>>>>>>>>>>> nicolai >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >

July 23, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Stephane Ducasse

+ 1 I'm curious to know the libraries that are making more trouble. (I'm thinking about FreeType) because we should throw away. Stef On Fri, Mar 17, 2017 at 12:54 AM, Ben Coman <btc(a)openinworld.com> wrote: > Great to hear this news. > Thanks for your efforts Nicolas. > cheers -ben > > On Fri, Mar 17, 2017 at 4:51 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> >> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com>: >>> >>> >>> >>> 2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> >>>> sorry for coming late to this threadâ¦ hard week :) >>>> why we are trying to compile with cygwin? >>>> is there a problem with the mingw distro? >>>> >>>> I didnât have the time to update the README, sadly. But wellâ¦ following >>>> appveyor configuration should give you all you need to reproduce the build >>>> (thatâs what I did last time I built an environment). >>>> >>>> Esteban >>>> >>>> >>> Hi Esteban, >>> How did you solve the directx problem? >>> >> >> >> Hurrah, I succeeded in compiling Win32 Pharo VM from cygwin by using >> cross-compiler i686-w64-mingw32 >> (cygwin64 here but it could be cygwin32). >> >> This is good news, because it means that: >> - we don't have to rely anymore on non-redistributable legacy directx SDK >> - we can compile with clang if we want too (well, for all the 3rd party >> dependencies, that's a bit more work) >> - it opens the door to win64 version >> >> Some details remain: I have to pick the right libgcc and libwindpthread as >> weel as iconv.dll and copy them to the pharo build directory to satisfy the >> SDL2 dependencies. >> Maybe there's a better option for compiling SDL2 with more static stuff? >> -static-libgcc or something... >> >> cairo required another dirty hack, not the one of Igor which must be >> eliminated for cygwin compilation, but one for working around the files that >> are not truncated when overwritten... >> I wonder where this bug comes from? make? cygwin itself? VirtualBox >> (unlikely)? >> >> If I find the energy to rebase -i and clean a bit my non linear attempts >> (squash/reorder/...) then I'll push the branch on opensmalltalk-vm and see >> how appveyor like it. >> >> >> >>>> >>>> On 15 Mar 2017, at 10:11, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> >>>> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be >>>> <philippe.back(a)gmail.com>: >>>>> >>>>> I made my own build here. >>>>> Not up to date with latest stuff but should work for the build process. >>>>> >>>>> https://ci.appveyor.com/project/philippeback/pharo-vm >>>>> >>>>> It uses my forked repo and provided you set your own bintray env vars >>>>> for API keys will publish there. >>>>> >>>>> Check all of the output of env vars and where/which in the appveyor >>>>> console to see what gets used when when it comes to compilers and so on as >>>>> there were various compiler versions involved at one point. >>>>> >>>>> Third party cache part is also worth checking. >>>>> >>>>> Still not able to build on my local box at the moment due to some tools >>>>> discrepancies happening. >>>>> >>>>> My build artifacts are embarking too much at this point but allow you >>>>> ro get the release, debug, and assert vms for windows. This helps when >>>>> debugging as backtraces and so on are much more meaningful and one can use >>>>> gdb more effectively to understand what is going on. >>>>> >>>>> Just keep the dlls and exes and you'll be fine. >>>> >>>> >>>> Ah good, thank you. >>>> >>>> >>>>> >>>>> >>>>> HTH >>>>> >>>>> Phil >>>>> >>>>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit : >>>>>> >>>>>> >>>>>> >>>>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier >>>>>> <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier >>>>>>> <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier >>>>>>>>> <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>>>>>> >>>>>>>>>> Hi Nicolai, >>>>>>>>>> >>>>>>>>>> If you look at appveyor.yml configuration on >>>>>>>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, >>>>>>>>>> you will see that the pharo brand is not yet in the matrix. >>>>>>>>>> >>>>>>>>>> It's because builds are based on cygwin, but as I understood, some >>>>>>>>>> library used by some plugin required by pharo refuse to compile with cygwin. >>>>>>>>>> They appear to work with mingw32. >>>>>>>>>> Cygwin provides headers for legacy directx, some distribution of >>>>>>>>>> mingw32 did in the past, but it does not seem the case anymore. >>>>>>>>>> Using the directx headers from Microsoft SDK is a problem. They >>>>>>>>>> are not redistributable and can't be found anymore on the net (too old). We >>>>>>>>>> cannot seriously base the builds on something so fragile (both technically >>>>>>>>>> and legally) in the long term. >>>>>>>>>> >>>>>>>>>> Also, the 64 bits VM does only work with clang, and we don't have >>>>>>>>>> anything available as a 64bits Microsoft SDK... So pharo has to fix that >>>>>>>>>> too. >>>>>>>>>> >>>>>>>>>> In the interim, you should look at >>>>>>>>>> https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml and >>>>>>>>>> follow the scripts there. >>>>>>>>> >>>>>>>>> >>>>>>>>> Ok, thank you. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I gave it a shot on sunday, because it was particularly rainy in >>>>>>>> Nantes, and I almost succeeded in compiling all the dependencies with >>>>>>>> cygwin. >>>>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely >>>>>>>> forget a few other niceties that some not so well informed programmers >>>>>>>> committed with the faith that it would make their life "easier". It >>>>>>>> certainly does not make mine simpler... >>>>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it >>>>>>>> seems that the workaround of Igor does not work anymore. >>>>>>>> ssize_t, WTF??? >>>>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case >>>>>>>> I'll publish the branch to see how far appveyor goes. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> So I solved the ssize_t problem by removing the hack from Igor which >>>>>>> is not necessary anymore... >>>>>>> But got another problem soon after while building the tests... >>>>>>> There are trailing lines generated at end of >>>>>>> tests/cairo-test-constructors.c that make the compilation fail: >>>>>>> >>>>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff >>>>>>> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src >>>>>>> -I../src -D_REENTRANT >>>>>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >>>>>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16 >>>>>>> -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration >>>>>>> -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum >>>>>>> -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 >>>>>>> -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers >>>>>>> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline >>>>>>> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 >>>>>>> -Wno-unused-but-set-variable -D_REENTRANT -m32 >>>>>>> -static-libgcc -static-libstdc++ >>>>>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include >>>>>>> -march=pentium4 -c -o cairo_test_suite-cairo-test-constructors.o `test -f >>>>>>> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>>>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de >>>>>>> donnÃ©es n'a pas de type ni de classe de stockage >>>>>>> oning (); >>>>>>> ^ >>>>>>> cairo-test-constructors.c:1118:1: attention : type defaults to âintâ >>>>>>> in declaration of âoningâ [-Wimplicit-int] >>>>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de >>>>>>> donnÃ©es n'a pas de type ni de classe de stockage >>>>>>> _register_ft_show_glyphs_table (); >>>>>>> ^ >>>>>>> >>>>>>> And the file looks like it has obviously been overwritten, but not >>>>>>> truncated !!! >>>>>>> >>>>>>> ... >>>>>>> extern void _register_multi_page (void); >>>>>>> extern void _register_fallback_resolution (void); >>>>>>> >>>>>>> void >>>>>>> _cairo_test_runner_register_tests (void) >>>>>>> { >>>>>>> _register_a1_bug (); >>>>>>> _register_a1_clip_paint (); >>>>>>> ... >>>>>>> _register_multi_page (); >>>>>>> _register_fallback_resolution (); >>>>>>> } >>>>>>> oning (); >>>>>>> _register_ft_show_glyphs_table (); >>>>>>> _register_ft_text_vertical_layout_type1 (); >>>>>>> _register_ft_text_vertical_layout_type3 (); >>>>>>> _register_ft_text_antialias_none (); >>>>>>> _register_ps_eps (); >>>>>>> _register_ps_features (); >>>>>>> _register_ps_surface_source (); >>>>>>> _register_svg_surface (); >>>>>>> _register_svg_clip (); >>>>>>> _register_svg_surface_source (); >>>>>>> _register_multi_page (); >>>>>>> _register_fallback_resolution (); >>>>>>> } >>>>>>> >>>>>>> This file is generated by a shell script >>>>>>> test/make-cairo-test-constructors.sh >>>>>>> I can't find any reference of the bug, and upgrade to version 1.14.8 >>>>>>> does not solve the issue. >>>>>>> So it will wait until tomorrow... >>>>>> >>>>>> >>>>>> >>>>>> I got the build for windows with mingw nearly working. (it can not >>>>>> build some plugins, like SqueakSSL for windows, because the used wincrypt.h >>>>>> is different in the mingw distrubtion). >>>>>> >>>>>> I still have the problem, that there seems to be a preprocessing step >>>>>> , that should put the vm-version (and source timestamp) in the >>>>>> sqSCCSVersion.h >>>>>> I got this working by running .travis_build.sh (with the options for >>>>>> arch/flavor/platform) But how is this done normally when you build a vm >>>>>> locally? >>>>>> And how is this done for the pharo-vm we currently use? >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Nicolas >>>>>>> >>>>>>>>>> >>>>>>>>>> I hope that Esteban will find time to resolve all these problems >>>>>>>>>> and have pharo brand back on opensmalltalk-vm. I guess that any form of help >>>>>>>>>> is welcome. >>>>>>>>>> >>>>>>>>>> Nicolas >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>>> >>>>>>>>>>> I still have problems building a vm on windows. >>>>>>>>>>> can you give me some hints how to start ? >>>>>>>>>>> I cloned the recent pharo-vm project, >>>>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>>>>>>>>>> run >>>>>>>>>>> mvm >>>>>>>>>>> >>>>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not >>>>>>>>>>> found, I had to adjust the include path for finding directx header, missing >>>>>>>>>>> variable replacement for git-versions). >>>>>>>>>>> So I may miss some important steps. >>>>>>>>>>> Is there a repository where I can clone the mingw environment >>>>>>>>>>> used to build the win32-pharo-vm, the environment used on the build-server ? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Nicolai >>>>>>>>>>> >>>>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano >>>>>>>>>>>>> <estebanlm(a)gmail.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess(a)gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera >>>>>>>>>>>>>> <bera.clement(a)gmail.com>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I believe they're built from >>>>>>>>>>>>>>> https://github.com/OpenSmalltalk/vm using travis and appveyor. On the >>>>>>>>>>>>>>> gitbhub readme there are relevant links. All built artifacts are also kept >>>>>>>>>>>>>>> on bintray for history. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you! >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> no, they arenât :) >>>>>>>>>>>>>> instead, they are built here: >>>>>>>>>>>>>> https://github.com/pharo-project/pharo-vm >>>>>>>>>>>>>> >>>>>>>>>>>>>> (README still not updated) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> what did changed ? I am not able to build the vm on windows >>>>>>>>>>>>> anymore (something wrong with generating the generator.image, I'll now reset >>>>>>>>>>>>> my local pharo-vm build directory and see if it works afterwards). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> see attached the stderr log : >>>>>>>>>>>> >>>>>>>>>>>> 'Errors in script loaded from >>>>>>>>>>>> u:\github\pharo-vm\scripts\LoadVMMaker.st' >>>>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>>>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>>>>>>>>>>> BaseSoundSystem class>>initialize >>>>>>>>>>>> MCMethodDefinition>>postloadOver: >>>>>>>>>>>> >>>>>>>>>>>> .... >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Are we still working with branch spur-64, or are we back on >>>>>>>>>>>>> master ? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Esteban >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess >>>>>>>>>>>>>>> <nicolaihess(a)gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >>>>>>>>>>>>>>>> I don't see them on the build server, only the buildresults >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The latest builds on the buildserver are from the last year >>>>>>>>>>>>>>>> only. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> nicolai >>>> >>>> >>> >> >

July 22, 2017

← Newer
1
...
10
11
12
13
14
15
16
...
40
Older →

Jump to page: