Re: [Pharo-dev] PharoSpur32Vm

[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  wrote:
> Great to hear this news.
> Thanks for your efforts Nicolas.
> cheers -ben
>
> On Fri, Mar 17, 2017 at 4:51 AM, Nicolas Cellier
>  wrote:
>>
>>
>>
>> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier
>> :
>>>
>>>
>>>
>>> 2017-03-15 15:03 GMT+01:00 Esteban Lorenzano :

 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  wrote:



 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 

Re: [Pharo-dev] PharoSpur32Vm

[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

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

Re: [Pharo-dev] Epicea applying multiple changes

[Martin Dias]

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 
wrote:

> It is issue 20223
> 
>
> 2017-07-19 9:41 GMT+02:00 Tudor Girba :
>
>> 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 
>> 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."
>>
>>
>>
>

Re: [Pharo-dev] Big claps for Epicea (small request!)

[Martin Dias]

Finally I read it. Mariano, thanks for your words. I created:
https://pharo.fogbugz.com/f/cases/20266/Epicea-add-optional-Pretty-Print-in-the-diff
As Nicolas, I sometimes don't like the output of formatter... but it can be
useful as an option.

cheers! Martín


On Wed, Jul 19, 2017 at 6:18 PM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

>
>
> On Wed, Jul 19, 2017 at 6:16 PM, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
>> format before diff is in the top 5 of my most hated default.
>> As an author, I try to write short methods and adhere to a standard
>> format (Kent Beck like).
>>
>> But I want the freedom to use derogation when the format helps
>> comprehension.
>> If I did the effort of using a special formatting, the last thing that I
>> want is a "smart" tool that undo my work.
>> The best time to format code is when we accept it, and only if there is a
>> quick way to undo/bypass if we don't like it.
>>
>> The formatter is dumb.
>> Let's illustrate it with literals among other things.
>>
>> I might want to write 16rBADA55, but I'm sure i never want to read
>> 12245589, it makes no sense ;)
>> (hey, this is a real example you can find in VMMaker sources, not just
>> the production of my ill brain).
>>
>> And if I make an effort to format a character encoding table on several
>> lines to have it readable
>>#(
>>   line1
>>   line2
>>   ...
>>   lineN ).
>> I'm pretty sure I never want to diff a single line with about 1024
>> columns...
>>
>> So please make this an option (with a default to false)!
>>
>>
>
> Hi Nicolas,
>
> Yes, in all the rest of Pharo it is an option (a checkbox on the top
> right) and it is false by default.
>
> Cheers,
>
>
>> 2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck :
>>
>>> Hi Martin,
>>>
>>> Thank you VERY MUCH for Epicea. I just had a crash and it was way more
>>> comfortable to recover changes.
>>>
>>> One small request would be to allow "Pretty Print" in the diff to the
>>> changes to be applied. Many times I changed formatting etc so for when
>>> viewing changes, viewing with same formatting helps me to see the actual
>>> changes and not formatting changes.
>>>
>>> Thanks!
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-dev] PharoSpur32Vm

[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?


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