March 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] pharo script doesn't work on paths that contain whitespaces

by Ben Coman

Thanks for the report Tomo. cheers -ben On Fri, Mar 17, 2017 at 10:22 AM, Tomohiro Oda <tomohiro.tomo.oda(a)gmail.com> wrote: > Hello, > > I found my Jenkins jobs with scripts like below fails to start headless > pharo process these couple of nights. > --- > wget --quiet -O - get.pharo.org/50+vm | bash > ./pharo Pharo.image save Pharo5.0 --delete-old > --- > > The problem is in the last line of the downloaded pharo script; > > LD_LIBRARY_PATH=$DIR/pharo-vm:$LD_LIBRARY_PATH $DIR/pharo-vm/pharo > --nodisplay "$@" > > should be quoted lilke > LD_LIBRARY_PATH="$DIR/pharo-vm:$LD_LIBRARY_PATH" "$DIR/pharo-vm/pharo" > --nodisplay "$@" > > It seems the script for Pharo6 also has the same issue. > > Best Regards, > --- > tomo > >

March 17, 2017

Fogbugz feedback - "Image Version"

by Ben Coman

A niggle I've had for a while is that the "Image Version" field seems to me to be useless. It defaults to a particular major version. (that even though only a small thing, is one more thing to maintain) It tends to be superseded by the Milestone field. The limited selection of major version is too broad to add any useful info beyond Milestone to narrow down action. So I wonder Image Version if it might be replaced by a freeform field "Image Version" to enter the value from System > About. ----- As an extension, given the flux of the VMs with the move to 64 bit, and ongoing support for both, it might also be good to have a "VM Version" field. Now actually I often find it awkward to report VM version. The text under System > System Reporter > VM General is quite bulky and its not clear what is the really useful parts for identification. So I usually end up pasting the whole thing, but this is too much for an issue tracker field. Also, there is no indication here of itimer versus threaded heartbeats which is sometimes pertinent. Could suitable minimal VM version info be added to System > About so the info required for the issue tracker is all in one simple place? ----- Finally, do we want these version fields to: * remain static for the version initially reported on, or * be refreshed as confirmed in a later version, or * have separate fields "Confirmed in {Image/VM} Version" to track tests. cheers -ben cheers -ben

March 17, 2017

pharo script doesn't work on paths that contain whitespaces

by Tomohiro Oda

Hello, I found my Jenkins jobs with scripts like below fails to start headless pharo process these couple of nights. --- wget --quiet -O - get.pharo.org/50+vm | bash ./pharo Pharo.image save Pharo5.0 --delete-old --- The problem is in the last line of the downloaded pharo script; LD_LIBRARY_PATH=$DIR/pharo-vm:$LD_LIBRARY_PATH $DIR/pharo-vm/pharo --nodisplay "$@" should be quoted lilke LD_LIBRARY_PATH="$DIR/pharo-vm:$LD_LIBRARY_PATH" "$DIR/pharo-vm/pharo" --nodisplay "$@" It seems the script for Pharo6 also has the same issue. Best Regards, --- tomo

March 17, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Eliot Miranda

On Thu, Mar 16, 2017 at 1:51 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-03-15 18:14 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > 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 > Bravo Nicolas! Are you planning to make this the default build, updating HowToBuild? It would be great to ditch the ancient gcc 3.x build. > > 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.n >>>>> ice(a)gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n >>>>>> ice(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.n >>>>>>>> ice(a)gmail.com>: >>>>>>>> >>>>>>>>> Hi Nicolai, >>>>>>>>> >>>>>>>>> If you look at appveyor.yml configuration on >>>>>>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Co >>>>>>>>> g/.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-pr >>>>>>>>> oject/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-cach >>>>>> e/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 >>>>>>>>>>>>>> <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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >> > -- _,,,^..^,,,_ best, Eliot

March 17, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Ben Coman

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@ > 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.n >>>>> ice(a)gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n >>>>>> ice(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.n >>>>>>>> ice(a)gmail.com>: >>>>>>>> >>>>>>>>> Hi Nicolai, >>>>>>>>> >>>>>>>>> If you look at appveyor.yml configuration on >>>>>>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Co >>>>>>>>> g/.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-pr >>>>>>>>> oject/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-cach >>>>>> e/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 >>>>>>>>>>>>>> <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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >> >

March 16, 2017

Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

by Cyril Ferlicot D.

Le 16/03/2017 Ã 05:11, Martin Dias a Ã©crit : > And it takes >30 minutes to load Roassal2, while takes <1 minyte in > Linux (same notebook). Script: > Do you have an anti-virus? If yes did you excluded the .changes and ombu files from the files to check? If not the anti-virus might analyze your file at each compilation. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

March 16, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolas Cellier

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.n >>>> ice(a)gmail.com>: >>>> >>>>> >>>>> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n >>>>> ice(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.n >>>>>>> ice(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-pr >>>>>>>> oject/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-cach >>>>> e/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-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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >> >

March 16, 2017

Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

by Eliot Miranda

Hi Martin, hopefully the VMProfiler still runs on Windows so you could use it to profile the VM as it loads Rossal2 and I can help you decode the results. Alternatively you could use AndreasSystemProfiler and see which primitives are particularly expensive. But in any case, some kind of profiling would point to why things are so much slower on Windows. On Wed, Mar 15, 2017 at 9:11 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Same here, in #60442. > > Smalltalk vm version ---> > "'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: > 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 > StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: > 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 > VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: > Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 > https://github.com/pharo-project/pharo-vm.git $ > '" > > cmd ver ---> > Microsoft Windows [VersiÃ³n 10.0.14393] > > > > Additionally: > > And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux > (same notebook). Script: > > Gofer new > url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; > package: 'ConfigurationOfRoassal2'; > load. > #ConfigurationOfRoassal2 asClass load. > > > > Martin > > On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> Well, I take that back. >> >> Today I had the same issue (with the latest VM). >> Closing the image and reopening it helped, but clearly there is something >> broken underneath. >> >> Peter >> >> On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote: >> > On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote: >> > > >> > > I got the same problem with the latest vm some weeks ago on Windows 7. >> > > It vanished by downloading a new vm some days after. >> > >> > I've downloaded the latest VM and it works as expected. Thanks! >> > >> > Peter >> >> > -- _,,,^..^,,,_ best, Eliot

March 16, 2017

Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

by Peter Uhnak

I still do see it ocassionally too... sometimes corelated to dual-booting and network interface fuckery (by that I mean that Windows doesn't detect network, or even wireless perhiperhals like mouse... but Windows 10 yay...) for the load time... sometime firewall/AV can fuck it up... but generally it should be always slower than linux, because Windows can't files. (I am using the latest VM usually) Peter On Thu, Mar 16, 2017 at 01:11:03AM -0300, Martin Dias wrote: > Same here, in #60442. > > Smalltalk vm version ---> > "'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: > 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 > StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: > 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 > VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed > Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 > https://github.com/pharo-project/pharo-vm.git $ > '" > > cmd ver ---> > Microsoft Windows [VersiÃ³n 10.0.14393] > > > > Additionally: > > And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux > (same notebook). Script: > > Gofer new > url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; > package: 'ConfigurationOfRoassal2'; > load. > #ConfigurationOfRoassal2 asClass load. > > > > Martin > > On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > Well, I take that back. > > > > Today I had the same issue (with the latest VM). > > Closing the image and reopening it helped, but clearly there is something > > broken underneath. > > > > Peter > > > > On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote: > > > On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote: > > > > > > > > I got the same problem with the latest vm some weeks ago on Windows 7. > > > > It vanished by downloading a new vm some days after. > > > > > > I've downloaded the latest VM and it works as expected. Thanks! > > > > > > Peter > > > >

March 16, 2017

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

by Eliot Miranda

Hi Ronie, On Tue, Mar 14, 2017 at 5:08 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hi Alex, > > I gave the following script: > > Smalltalk compiler evaluate: ' >> | surface | >> surface := AthensCairoSurface extent: 640@480. >> surface drawDuring: [ :canvas | >> surface clear: Color blue. >> ]. >> >> surface asForm asMorph openInWindow >> ' >> > > Notice that I am wrapping the script in a string that I am passing to the > compiler, so that the workspace cannot retain any reference to the surface. > Can you experiment with VMs at or later than VMMaker.oscog-eem.2156? I added a solution to the BitBlt primitives to detect GC occurring in a BitBlt primitive and for the Cairo surface callbacks returning errors. This is orthogonal to the GC issue you raise, but both issues need solutions. Hopefully we have them now. Another thing to note is that in my latest commit of the entire tree I modified the surface plugin to allow defaulting some of the functions (those for ioGetSurfaceFormat, isUnlockSurface & ioShowSurface), this means that one can default the null callbacks created in createShowSurfaceFn & createUnlockSurfaceFn to answer 0 (provided you change the installation code suitably to not send thunk when the argument is 0, not a Callback). This should speed up small Athens blits noticeably. > Best regards, > Ronie > > 2017-03-14 16:12 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > >> Hi Ronie, >> >> Below you said: >> >> The problem with asForm, is that the form returned can be used after the >> cairo surface which holds the pixels is garbage collected. >> >> >> I cannot reproduce this case. You gave a script: >> >> surface := AthensCairoSurface extent: 640@480. >> surface drawDuring: [ :canvas | >> surface clear: Color blue. >> ]. >> >> surface asForm asMorph openInWindow >> >> >> I see a blue window. >> >> Cheers, >> Alexandre >> >> >> How about changing AthensCairoSurface >> asForm into the following >> definition?: >> asForm >> >> "create a form and copy an image data there" >> | form | >> self checkSession. >> >> self flush. >> form := Form extent: (self width@self height) depth: 32. >> form unhibernate. >> LibC memCopy: self getDataPtr to: form bits size: self width*self >> height*4. >> ^ form >> >> This involves a whole copy, but it removes completely the dependency on >> the surface plugin. >> >> If we want to keep using the surface plugin with Cairo, the old >> definition of asForm still has a bug, which can be reproduced with the >> following snippet: >> >> Smalltalk compiler evaluate: ' >> | surface | >> surface := AthensCairoSurface extent: 640@480. >> surface drawDuring: [ :canvas | >> surface clear: Color blue. >> ]. >> >> surface asForm asMorph openInWindow >> ' >> >> The problem with asForm, is that the form returned can be used after the >> cairo surface which holds the pixels is garbage collected. >> >> >> > -- _,,,^..^,,,_ best, Eliot

March 16, 2017