Re: [Pharo-dev] PharoSpur32Vm

[Hernán Morales Durand]

2017-07-22 10:03 GMT-03:00 Nicolai Hess :
>
> 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 :
>>
>>
>>
>> 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be 
>> :
>>>
>>> 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"  a écrit :



 2017-03-14 22:22 GMT+01:00 Nicolas Cellier 
 :
>
>
>
> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier 
> :
>>
>>
>>
>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess :
>>>
>>>
>>>
>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier 
>>> :

 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.
>>
>>
>

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-07-22 20:26 GMT+02:00 Eliot Miranda :

> Hi Nicolai,
>
>
> On Jul 22, 2017, at 6:03 AM, Nicolai Hess  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 :
>
>>
>>
>> 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be <
>> philippe.b...@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"  a écrit :
>>>


 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <
 nicolas.cellier.aka.n...@gmail.com>:

>
>
> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com>:
>
>>
>>
>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <
>>> nicolas.cellier.aka.n...@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 a

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-07-23 19:42 GMT+02:00 Hernán Morales Durand :

> 2017-07-22 10:03 GMT-03:00 Nicolai Hess :
> >
> > 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 :
> >>
> >>
> >>
> >> 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be <
> philippe.b...@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"  a écrit
> :
> 
> 
> 
>  2017-03-14 22:22 GMT+01:00 Nicolas Cellier  gmail.com>:
> >
> >
> >
> > 2017-03-14 9:30 GMT+01:00 Nicolas Cellier  gmail.com>:
> >>
> >>
> >>
> >> 2017-03-14 8:58 GMT+01:00 Nicolai Hess :
> >>>
> >>>
> >>>
> >>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <
> nicolas.cellier.aka.n...@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.
> >>>
> >>>
>

Re: [Pharo-dev] PharoSpur32Vm

[Nicolas Cellier]

2017-07-23 19:56 GMT+02:00 Nicolai Hess :

>
>
> 2017-07-23 19:42 GMT+02:00 Hernán Morales Durand  >:
>
>> 2017-07-22 10:03 GMT-03:00 Nicolai Hess :
>> >
>> > 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 :
>> >>
>> >>
>> >>
>> >> 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be <
>> philippe.b...@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"  a
>> écrit :
>> 
>> 
>> 
>>  2017-03-14 22:22 GMT+01:00 Nicolas Cellier <
>> nicolas.cellier.aka.n...@gmail.com>:
>> >
>> >
>> >
>> > 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <
>> nicolas.cellier.aka.n...@gmail.com>:
>> >>

Re: [Pharo-dev] PharoSpur32Vm

[Nicolai Hess]

2017-07-23 22:38 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:

>
>
> 2017-07-23 19:56 GMT+02:00 Nicolai Hess :
>
>>
>>
>> 2017-07-23 19:42 GMT+02:00 Hernán Morales Durand <
>> hernan.mora...@gmail.com>:
>>
>>> 2017-07-22 10:03 GMT-03:00 Nicolai Hess :
>>> >
>>> > 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
> Nicolas
>
>
>>> Hernán
>>>
>>> >
>>> > nicolai
>>> >
>>> >
>>> >
>>> > 2017-03-15 10:11 GMT+01:00 Nicolai Hess :
>>> >>
>>> >>
>>> >>
>>> >> 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be <
>>> philippe.b...@gmail.com>:
>>> >>>
>>> >>> I 

Re: [Pharo-dev] Epicea applying multiple changes

[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
>> ;
>>
>> 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.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Epicea feedback

[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-changes
> https://pharo.fogbugz.com/f/cases/20225/Epicea-would-be-nice-is-to-have-some-menus-on-the-sessions-items
> 
> 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.

Re: [Pharo-dev] Epicea applying multiple changes

[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  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
>>> ;
>>> 
>>> 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.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

[Pharo-dev] New Launcher not working (Windows)

[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   

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.

[Pharo-dev] Esteban's ChangeLog week of 17 July 2017

[estebanlm]

Hello!

This is my weekly ChangeLog, from 17 July 2017 to 23 July 2017.
You can see it in a better format by going here: 
http://log.smallworks.eu/web/search?from=17/7/2017&to=23/7/2017

ChangeLog
=

20 July 2017:
-

*I'm fixing the Pharo7 build process to finally get to the point where we 
can use easily the Iceberg-based 
process. We have two remaining problems: 


. Since we use plain filetree on the bootstrap process, we do not have 
version information of packages.
. Also because of that (and because Iceberg uses metadataless format), we 
do not have correct timestamps. 

So, today (last two days, in fact), I fixed point 1, by adding a Pharo 
+hidden+ repository to iceberg and 
setting the package ancestors with correct version info. This way, all 
comparissons are fine :)

Process is kind of complex to explain here, but basically we replace the 
+cypress.1+ info with a correct
version with a commit reference.


19 July 2017:
-

*I released [Iceberg 
v0.5.3](https://github.com/pharo-vcs/iceberg/releases/tag/v0.5.3)

I needed this because the load/merge/pull times for large projects were 
innaceptable, mainly 
because after doing the pull into the local workingcopy, it was scanning 
all packages to see 
what changed and load them. This naive approach was ok for most of the 
projects, but those with
many packages (like Pharo itself) were taking ages to perform a merge. 

Now we do it as the sync: we figure out packages that changed between your 
installed version and 
the upcoming version and we merge just that. 

Also, I fixed some other important issues: 

* +#isAncestorOf:+ was scanning all commits. 

Again, this worked for small projects. Big ones (as Pharo) were not scaling.

* I created "system repository" concept. 

This is because Pharo7 will be dispatched with a Pharo repository but no 
local checkout. Then you 
will see an invalid project in iceberg window. This is not good because 
most of the times users 
will not care about it, but it will be annoying :)

Now, if you are a Pharo developer, you can add to your startup actions this 
script: 


Iceberg showSystemRepositories: true.
IceRepository registry 
detect: [ :each | each name = 'pharo' ]
ifFound: [ :each | each location: 
'/path/to/your/location/of/pharo-project/pharo' asFileReference ].


with this, you will have always access to your Pharo repository.


17 July 2017:
-

*I just cameback from a week off. I released a patch version of [Iceberg 
(0.5.2)](https://github.com/pharo-vcs/iceberg/tree/v0.5.2),
mostly to fix an override problem, but incorporating some other 
contributions.


cheers! 
Esteban