Re: [Pharo-dev] PharoSpur32Vm

2017-03-17 Thread Nicolai Hess 
2017-03-17 23:41 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:

>
>
> 2017-03-17 23:40 GMT+01:00 Nicolas Cellier  gmail.com>:
>
>>
>>
>> 2017-03-17 23:32 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2017-03-16 21:51 GMT+01:00 Nicolas Cellier <
>>> nicolas.cellier.aka.n...@gmail.com>:
>>>


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

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

>>>
>>> what hack from Igor ? I thought the pharo build just downloads a tar.gz
>>> archive from cairo and starts the configure/build ?
>>>
>>>
>>
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f7d
>> 3c98eaa001d2d07c1f2b75cad00fa16f86a73
>>
>>
> and https://lists.cairographics.org/archives/cairo/2012-
> October/023675.html
>


Ok :)

Re: [Pharo-dev] PharoSpur32Vm

2017-03-17 Thread Nicolas Cellier 
2017-03-17 23:40 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:

>
>
> 2017-03-17 23:32 GMT+01:00 Nicolai Hess :
>
>>
>>
>> 2017-03-16 21:51 GMT+01:00 Nicolas Cellier > l.com>:
>>
>>>
>>>
>>> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier <
>>> nicolas.cellier.aka.n...@gmail.com>:
>>>


 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)?
>>>
>>
>> what hack from Igor ? I thought the pharo build just downloads a tar.gz
>> archive from cairo and starts the configure/build ?
>>
>>
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/
> f7d3c98eaa001d2d07c1f2b75cad00fa16f86a73
>
>
and https://lists.cairographics.org/archives/cairo/2012-October/023675.html

Re: [Pharo-dev] PharoSpur32Vm

2017-03-17 Thread Nicolas Cellier 
2017-03-17 23:32 GMT+01:00 Nicolai Hess :

>
>
> 2017-03-16 21:51 GMT+01:00 Nicolas Cellier  gmail.com>:
>
>>
>>
>> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier > l.com>:
>>
>>>
>>>
>>> 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)?
>>
>
> what hack from Igor ? I thought the pharo build just downloads a tar.gz
> archive from cairo and starts the configure/build ?
>
>

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f7d3c98eaa001d2d07c1f2b75cad00fa16f86a73

Re: [Pharo-dev] PharoSpur32Vm

2017-03-17 Thread Nicolai Hess 
2017-03-16 21:51 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:

>
>
> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier  gmail.com>:
>
>>
>>
>> 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)?
>

what hack from Igor ? I thought the pharo build just downloads a tar.gz
archive from cairo and starts the configure/build ?


>
> 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 <
>>> 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  i...@gmail.com>:
>
>>
>>
>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier > i...@gmail.com>:
>>
>>>
>>>
>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess :
>>>


 2017-03-11 10:01 GMT+01:00 Nicolas Cellier >>> i...@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
>

Re: [Pharo-dev] Pharo7 Inspector feature idea - cherry-pick collection items

2017-03-17 Thread Alistair Grant 
On 17 March 2017 at 12:40, Ben Coman  wrote:
>
>
> On Fri, Mar 17, 2017 at 5:02 PM, Tudor Girba  wrote:
>>
>> Hi,
>>
>> That list is multi-selection. On Mac, you can press Cmd while clicking and
>> you get the collection to the right.
>>
>>
>
> I now see that Shift-click multi-selects and works just like I imagined it
> would.
> However Ctrl-click doesn't do anything, which was the only thing I tested
> before.
> I presume that is a bug?  Can anyone confirm this on Linux?
>
> I'm... 32-bit Debian 8 Jessie.
> Pharo 60447 & Unix VM built on Mar  3 2017 21:07:26 Compiler: 4.6.3
> VMMaker versionString VM: 201703031554
> https://github.com/pharo-project/pharo-vm.git $ Date: Fri Mar 3 16:54:16
> 2017 +0100 $ Plugins: 201703031554
> https://github.com/pharo-project/pharo-vm.git $
> CoInterpreter * VMMaker.oscog-eem.2143 uuid:
> fe064b6b-e530-4766-837d-799ffe1e8dcd Mar  3 2017
> StackToRegisterMappingCogit * VMMaker.oscog-eem.2143 uuid:
> fe064b6b-e530-4766-837d-799ffe1e8dcd Mar  3 2017

I have the same behaviour (can't multi-select using Ctrl-click on linux):

Ubuntu 16.04

Pharo 6.0
Latest update: #60438

5.0-201702221539  Wed Feb 22 15:46:29 UTC 2017 gcc 4.6.3 [Production
Spur ITHB VM]
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 $
Linux testing-docker-9b911eb3-3e93-4fc4-acb7-571482555639
4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016
i686 i686 i386 GNU/Linux
plugin path: /snap/pharo/x1/usr/bin/pharo-vm/ [default:
/snap/pharo/x1/usr/bin/pharo-vm/]

Cheers,
Alistair

Re: [Pharo-dev] Script to download Pharo 4 vm for Mac os sierra

2017-03-17 Thread stepharong 

Nice to see on this list after all these years :)
This is important for synectiquers to use the power of the open-source :)




Hello,

We have a jenkins job, running on a linux machine, that is responsible  
for building and outputing a Pharo 4 development image + vm ready to be  
used on mac machines.


We  use this command line to download the VM and archived it as output  
of the job:


curl -O http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-latest.zip

On my mac (10.12.1), when i open the pharo image with this vm , I am  
facing what seem to be some known issues for Mac OS sierra:


Pharo[13048:431565] *** -[NSPathStore2 stringByAppendingPathExtension:]:  
cannot append extension 'bundle/Contents/MacOS/' to path ...  
Now, when I try to download a Pharo 4  vm directly from my mac sierra  
machine,

with a zeroconf script (get.pharo.org/vm40),
It works: I am able to open the pharo image with this vm.

Is there a script that allows to download a pharo 4 vm working for mac  
os sierra, from a linux machine ?


--Cyrille Delaunay




--
Using Opera's mail client: http://www.opera.com/mail/

[Pharo-dev] xsd to pharo?

2017-03-17 Thread stepharong 

Hi

we are looking for a xsd to pharo class generator?

Stef

--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Fogbugz feedback - "Image Version"

2017-03-17 Thread Ben Coman 
On Fri, Mar 17, 2017 at 7:47 PM, Sven Van Caekenberghe  wrote:

> I understand why it is useful to you, but it is a PIA for all the rest of
> us.
>
> Consider:
>
> $ java -version
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
>
> $ python --version
> Python 2.7.10
>
> $ ruby --version
> ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]
>
> At the image level Pharo has:
>
> $ pharo Pharo.image printVersion
> [version] 4.0 #40620
>
> Clean, simple, precise.
>
> And then when the rest of the world wants to communicate about the VM
> version they are using, you get:
>
> $ ../bin/pharo --version
> 3.9-7 #1 Thu Apr  2 00:51:45 CEST 2015 gcc 4.6.3 [Production ITHB VM]
> NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid:
> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  2 2015
> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid:
> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr  2 2015
> https://github.com/pharo-project/pharo-vm.git Commit:
> 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100
> By: Esteban Lorenzano  Jenkins build #14904
> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45
> UTC 2012 i686 i686 i386 GNU/Linux
> plugin path: /home/audio359/pharo/bin/pharo-vm/ [default:
> /home/audio359/pharo/bin/pharo-vm/]
>
> This is way too technical.
>

This just needs to be --versionVerbose or --versionAll.

cheers -ben


> On the other hand, I understand that this is also a vetting problem: who
> builds the VM, validates it, assigns it version/build numbers.
>
> BTW, is there no open source convention of using xx-config to return all
> this detailed (build) info ?
>
> > On 17 Mar 2017, at 11:36, Eliot Miranda  wrote:
> >
> > Hi Ben,
> >
> >> On Mar 16, 2017, at 8:32 PM, Ben Coman  wrote:
> >>
> >> 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?
> >
> > Perhaps we should start by enumerating use cares.  I originally wrote
> that bulky version info so that vm maintainers could identify the exact
> version of a VM.  The use case here is to locate or obtain the build date,
> c compiler and exact C and VMMaker source for the vm in order to locate the
> exact vm, attach a debugger, recompile a matching debug vm, etc.  At the
> time the version info was
> >
> > a) the commit to the subversion Cog repository of the vm sources
> >
> > b)  the commit to the subversion squeakvm repository of the vm support
> files shared between Cog and squeakvm
> >
> > c) the VMMaker version of the StackInterpreter or CoInterpreter in the
> vm (including the "*" dirty mark if so)
> >
> > d) the VMMaker version of the Cogit in the vm (including the "*" dirty
> mark if so)
> >
> > With opensmalltalk-vm we can collapse a) and b), or rather, b) is no
> longer separate and hence obsolete, but the triad a), c) & d) are still
> most relevant to me.  Condensing these to a summary means having to index
> (e.g. lookup the VMMaker info in opensmalltalk-vm by checking out a
> particular commit) and that's time consuming.
> >
> > So for me, while the info is poorly formatted and hard to read it is
> informative and saves me time.  I'm happy to see it paired down by dropping
> b), and doing whatever we can to make it more readable but I'd still like
> to see people cite it in full when reporting a potential vm problem or
> reporting their vm version.
> >
> > What other use cases are there for this version info?  (and that's not a
> rhetorical question).
> >
> >>
> >> -
> >> Finally, do we want these version fields to:
> >> * remain static for the version initially

Re: [Pharo-dev] 60445, empty version info stamps

2017-03-17 Thread Pavel Krivanek 
Not sure with the date but we will store a hash of the commit from which
the image will be bootstrapped.

-- Pavel

2017-03-17 12:43 GMT+01:00 Ben Coman :

> btw, will same user/date for multiple revisions remain available in
> a Versions window?
>
> cheers -ben
>
>
> On Fri, Mar 17, 2017 at 7:02 PM, Pavel Krivanek 
> wrote:
>
>> Pharo 7 will be bootstrapped from the metadata-less filetree where
>> timestamps are ignored completely. So the question is if we should put
>> energy into this...
>>
>> -- Pavel
>>
>> 2017-03-17 11:57 GMT+01:00 Ben Coman :
>>
>>>
>>>
>>> On Fri, Mar 17, 2017 at 5:30 PM, Ben Coman  wrote:
>>>


 On Fri, Mar 17, 2017 at 5:22 PM, Ben Coman  wrote:

> In 60445, browse the implementors of #cacheAt:for:ifAbsentPut:
> and the view the Versions of each.
> Curiously some of them have a blank user/date.
>
> There are others...
> errors := OrderedCollection new.
> versions := (CompiledMethod allInstances) flatCollect: [:cm|
> [VersionBrowser new setRGMethodFrom: cm asRingDefinition;
> buildChangeList]
> on: Error do:[:ex| errors add: (cm -> ex). #()] ].
> versions size.
> "112131"
> emptyStamps := versions select: [:rgm| rgm stamp = ''].
> emptyStamps size.
> "9264"
> or 8%
>
> Maybe some are historic, but I'd guess this one at least is not so
> old...
> GLMFastListDataSource>>cacheAt:for:ifAbsentPut:
>
> What reasonable action do we need to take?
>
> cheers -ben
>

 P.S.
 the errors were all "UTF8InvalidText: Invalid utf8 input detected" for
 these methods...
   QuotedPrintableMimeConverter >> #decode:
   StringTest >> #UTF8InvalidText:
   EpEnabledIntegrationTest >> #setUp
   SingleCodeCriticResultList >> #diffTextForChange:



>>> Further analysis...
>>> 6versions=93482   emptyStamps=8964
>>> 60050versions=95654   (+2172)emptyStamps=9214  (+250)
>>> 60100versions=96112   (+458)  emptyStamps=9212  (-2)
>>> 60150versions=97335   (+1223)emptyStamps=9211  (-1)
>>> 60200versions=98030   (+695)  emptyStamps=9169  (-42)
>>> 60250versions=99779   (+1749)emptyStamps=9282  (113)
>>> 60300versions=109440 (+9661)emptyStamps=9153  (-129)
>>> 60350versions=109586 (+146)  emptyStamps=9173  (+20)
>>> 60400versions=110278 (+692)  emptyStamps=9185  (+12)
>>> 60455versions=112131 (+1853)emptyStamps=9264  (+79)
>>>
>>> cheers -ben
>>>
>>
>>
>

Re: [Pharo-dev] 60445, empty version info stamps

2017-03-17 Thread Ben Coman 
btw, will same user/date for multiple revisions remain available in
a Versions window?

cheers -ben

On Fri, Mar 17, 2017 at 7:02 PM, Pavel Krivanek 
wrote:

> Pharo 7 will be bootstrapped from the metadata-less filetree where
> timestamps are ignored completely. So the question is if we should put
> energy into this...
>
> -- Pavel
>
> 2017-03-17 11:57 GMT+01:00 Ben Coman :
>
>>
>>
>> On Fri, Mar 17, 2017 at 5:30 PM, Ben Coman  wrote:
>>
>>>
>>>
>>> On Fri, Mar 17, 2017 at 5:22 PM, Ben Coman  wrote:
>>>
 In 60445, browse the implementors of #cacheAt:for:ifAbsentPut:
 and the view the Versions of each.
 Curiously some of them have a blank user/date.

 There are others...
 errors := OrderedCollection new.
 versions := (CompiledMethod allInstances) flatCollect: [:cm|
 [VersionBrowser new setRGMethodFrom: cm asRingDefinition;
 buildChangeList]
 on: Error do:[:ex| errors add: (cm -> ex). #()] ].
 versions size.
 "112131"
 emptyStamps := versions select: [:rgm| rgm stamp = ''].
 emptyStamps size.
 "9264"
 or 8%

 Maybe some are historic, but I'd guess this one at least is not so
 old...
 GLMFastListDataSource>>cacheAt:for:ifAbsentPut:

 What reasonable action do we need to take?

 cheers -ben

>>>
>>> P.S.
>>> the errors were all "UTF8InvalidText: Invalid utf8 input detected" for
>>> these methods...
>>>   QuotedPrintableMimeConverter >> #decode:
>>>   StringTest >> #UTF8InvalidText:
>>>   EpEnabledIntegrationTest >> #setUp
>>>   SingleCodeCriticResultList >> #diffTextForChange:
>>>
>>>
>>>
>> Further analysis...
>> 6versions=93482   emptyStamps=8964
>> 60050versions=95654   (+2172)emptyStamps=9214  (+250)
>> 60100versions=96112   (+458)  emptyStamps=9212  (-2)
>> 60150versions=97335   (+1223)emptyStamps=9211  (-1)
>> 60200versions=98030   (+695)  emptyStamps=9169  (-42)
>> 60250versions=99779   (+1749)emptyStamps=9282  (113)
>> 60300versions=109440 (+9661)emptyStamps=9153  (-129)
>> 60350versions=109586 (+146)  emptyStamps=9173  (+20)
>> 60400versions=110278 (+692)  emptyStamps=9185  (+12)
>> 60455versions=112131 (+1853)emptyStamps=9264  (+79)
>>
>> cheers -ben
>>
>
>

Re: [Pharo-dev] Pharo7 Inspector feature idea - cherry-pick collection items

2017-03-17 Thread Ben Coman 
On Fri, Mar 17, 2017 at 5:02 PM, Tudor Girba  wrote:

> Hi,
>
> That list is multi-selection. On Mac, you can press Cmd while clicking and
> you get the collection to the right.
>
>
>
I now see that Shift-click multi-selects and works just like I imagined it
would.
However Ctrl-click doesn't do anything, which was the only thing I tested
before.
I presume that is a bug?  Can anyone confirm this on Linux?

I'm... 32-bit Debian 8 Jessie.
Pharo 60447 & Unix VM built on Mar  3 2017 21:07:26 Compiler: 4.6.3
VMMaker versionString VM: 201703031554
https://github.com/pharo-project/pharo-vm.git $ Date: Fri Mar 3 16:54:16
2017 +0100 $ Plugins: 201703031554
https://github.com/pharo-project/pharo-vm.git $
CoInterpreter * VMMaker.oscog-eem.2143 uuid:
fe064b6b-e530-4766-837d-799ffe1e8dcd Mar  3 2017
StackToRegisterMappingCogit * VMMaker.oscog-eem.2143 uuid:
fe064b6b-e530-4766-837d-799ffe1e8dcd Mar  3 2017

cheers -ben


> Cheers,
> Doru
>
>
> On Mar 17, 2017, at 8:14 AM, Ben Coman  > wrote:
>
> Sometimes when exploring a large data set in inspector,
> I'd like to cherry pick a few items to act on as a collection.
>
> This would need to be valdiated/tested, but It could be useful to be
> able to multi-select items and have the next pane to the right be the
> collection containing the list of picked items.
>
> For the moment I can get by with...   "self first: 5".
>
> cheers -ben
> .
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "What we can governs what we wish."
>
>
>
>
>

Re: [Pharo-dev] changing pharo packaging in linux

2017-03-17 Thread Ben Coman 
On Fri, Mar 17, 2017 at 3:47 PM, Esteban Lorenzano 
wrote:

>
> On 17 Mar 2017, at 04:46, Ben Coman  wrote:
>
> On Thu, Mar 16, 2017 at 6:11 PM, Esteban Lorenzano 
> wrote:
>
>
> Hi,
>
> Last weeks I was fighting with library dependency problems on linux
> distributions and at the end I came to the conclusion that the only way to
> guarantee that our own dependencies will be found first than OS versions
> (which can have problems for us when we choose to distribute a library by
> our own) is to add library directory to LD_LIBRARY_PATH before the
> execution.
>
> Now, I added that  to zeroconf and that’s working fine, but now we have
> the problem of the “non zeroconf” distributions.
>
> I checked how to add this and well, turns out that “old way” of
> distributions, from the standard builds of os-vm (we changed it like 5
> years ago) already have something like that. The osvm for linux has this
> structure:
>
> ./pharo
> ./lib
> ./lib/5.0-201703221605
> ./lib/5.0-201703221605/* //All binaries and libraries here
> ./bin
> ./bin/pharo
>
> thing is: here ./pharo is an script who mades all we need.
>
> So, instead reinventing the wheel I want to go back to this structure… I
> do not think it will imply anything to anyone, but I wanted to let you know
> :)
>
> cheers,
> Esteban
>
>
>
> Can you consider this for our startup script...
>  Generalise determination of LD_LIBRARY_PATH in squeak run script
>  https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/15
>
>
> this is already merged, isn’t?
>

in osvm, yes.


> then is already in “my script” (what I was proposing is to use the osvm
> script) :)
>

cool, just checking.
Not too long ago it was missing from the Squeak download.
cheers -ben

btw, I just checked Squeak again and actually its script is now completely
different,
not setting LD_LIBRARY_PATH at all.



>
>
> Last time I downloaded Squeak this hadn't filtered through to their
> packaging
> and their startup script bombed on my 32-bit Debian 8 Jessie.
>
> cheers -ben
>
>
> P.S if time permits, could you also action out this..
>  Download PharoXXX.sources if its not found in the usual location.
>  https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/79
>
>
>

Re: [Pharo-dev] Pharo7 Inspector feature idea - cherry-pick collection items

2017-03-17 Thread Tudor Girba 
Yes, the order is given by the order in which I click on the items.

Doru


> On Mar 17, 2017, at 9:26 AM, Denis Kudriashov  wrote:
> 
> 
> 2017-03-17 10:18 GMT+01:00 Norbert Hartl :
> Is there a reason why the order is reversed?
> 
> I think it related to FastTable. Selected indexes are in order from last 
> selected to first selected. New selected row is always added as first.

--
www.tudorgirba.com
www.feenk.com

"If you can't say why something is relevant, 
it probably isn't."

Re: [Pharo-dev] 60445, empty version info stamps

2017-03-17 Thread Pavel Krivanek 
Pharo 7 will be bootstrapped from the metadata-less filetree where
timestamps are ignored completely. So the question is if we should put
energy into this...

-- Pavel

2017-03-17 11:57 GMT+01:00 Ben Coman :

>
>
> On Fri, Mar 17, 2017 at 5:30 PM, Ben Coman  wrote:
>
>>
>>
>> On Fri, Mar 17, 2017 at 5:22 PM, Ben Coman  wrote:
>>
>>> In 60445, browse the implementors of #cacheAt:for:ifAbsentPut:
>>> and the view the Versions of each.
>>> Curiously some of them have a blank user/date.
>>>
>>> There are others...
>>> errors := OrderedCollection new.
>>> versions := (CompiledMethod allInstances) flatCollect: [:cm|
>>> [VersionBrowser new setRGMethodFrom: cm asRingDefinition;
>>> buildChangeList]
>>> on: Error do:[:ex| errors add: (cm -> ex). #()] ].
>>> versions size.
>>> "112131"
>>> emptyStamps := versions select: [:rgm| rgm stamp = ''].
>>> emptyStamps size.
>>> "9264"
>>> or 8%
>>>
>>> Maybe some are historic, but I'd guess this one at least is not so
>>> old...
>>> GLMFastListDataSource>>cacheAt:for:ifAbsentPut:
>>>
>>> What reasonable action do we need to take?
>>>
>>> cheers -ben
>>>
>>
>> P.S.
>> the errors were all "UTF8InvalidText: Invalid utf8 input detected" for
>> these methods...
>>   QuotedPrintableMimeConverter >> #decode:
>>   StringTest >> #UTF8InvalidText:
>>   EpEnabledIntegrationTest >> #setUp
>>   SingleCodeCriticResultList >> #diffTextForChange:
>>
>>
>>
> Further analysis...
> 6versions=93482   emptyStamps=8964
> 60050versions=95654   (+2172)emptyStamps=9214  (+250)
> 60100versions=96112   (+458)  emptyStamps=9212  (-2)
> 60150versions=97335   (+1223)emptyStamps=9211  (-1)
> 60200versions=98030   (+695)  emptyStamps=9169  (-42)
> 60250versions=99779   (+1749)emptyStamps=9282  (113)
> 60300versions=109440 (+9661)emptyStamps=9153  (-129)
> 60350versions=109586 (+146)  emptyStamps=9173  (+20)
> 60400versions=110278 (+692)  emptyStamps=9185  (+12)
> 60455versions=112131 (+1853)emptyStamps=9264  (+79)
>
> cheers -ben
>

Re: [Pharo-dev] 60445, empty version info stamps

2017-03-17 Thread Ben Coman 
On Fri, Mar 17, 2017 at 5:30 PM, Ben Coman  wrote:

>
>
> On Fri, Mar 17, 2017 at 5:22 PM, Ben Coman  wrote:
>
>> In 60445, browse the implementors of #cacheAt:for:ifAbsentPut:
>> and the view the Versions of each.
>> Curiously some of them have a blank user/date.
>>
>> There are others...
>> errors := OrderedCollection new.
>> versions := (CompiledMethod allInstances) flatCollect: [:cm|
>> [VersionBrowser new setRGMethodFrom: cm asRingDefinition;
>> buildChangeList]
>> on: Error do:[:ex| errors add: (cm -> ex). #()] ].
>> versions size.
>> "112131"
>> emptyStamps := versions select: [:rgm| rgm stamp = ''].
>> emptyStamps size.
>> "9264"
>> or 8%
>>
>> Maybe some are historic, but I'd guess this one at least is not so old...
>> GLMFastListDataSource>>cacheAt:for:ifAbsentPut:
>>
>> What reasonable action do we need to take?
>>
>> cheers -ben
>>
>
> P.S.
> the errors were all "UTF8InvalidText: Invalid utf8 input detected" for
> these methods...
>   QuotedPrintableMimeConverter >> #decode:
>   StringTest >> #UTF8InvalidText:
>   EpEnabledIntegrationTest >> #setUp
>   SingleCodeCriticResultList >> #diffTextForChange:
>
>
>
Further analysis...
6versions=93482   emptyStamps=8964
60050versions=95654   (+2172)emptyStamps=9214  (+250)
60100versions=96112   (+458)  emptyStamps=9212  (-2)
60150versions=97335   (+1223)emptyStamps=9211  (-1)
60200versions=98030   (+695)  emptyStamps=9169  (-42)
60250versions=99779   (+1749)emptyStamps=9282  (113)
60300versions=109440 (+9661)emptyStamps=9153  (-129)
60350versions=109586 (+146)  emptyStamps=9173  (+20)
60400versions=110278 (+692)  emptyStamps=9185  (+12)
60455versions=112131 (+1853)emptyStamps=9264  (+79)

cheers -ben

[Pharo-dev] [pharo-project/pharo-core]

2017-03-17 Thread GitHub 
  Branch: refs/tags/60447
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 3cb2c0: 60447

2017-03-17 Thread GitHub 
  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 3cb2c06250cbf8e5de24b9eeebbd30b0f0e4b2a8
  
https://github.com/pharo-project/pharo-core/commit/3cb2c06250cbf8e5de24b9eeebbd30b0f0e4b2a8
  Author: Jenkins Build Server 
  Date:   2017-03-17 (Fri, 17 Mar 2017)

  Changed paths:
M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - 
before/testBeforeMethodPrimitive.st
A Reflectivity-Tests.package/ReflectivityTest.class/README.md
A Reflectivity-Tests.package/ReflectivityTest.class/definition.st
A 
Reflectivity-Tests.package/ReflectivityTest.class/instance/running/tearDown.st
A 
Reflectivity-Tests.package/ReflectivityTest.class/instance/tagging/increase.st
A 
Reflectivity-Tests.package/ReflectivityTest.class/instance/tagging/tagExec.st
A 
Reflectivity-Tests.package/ReflectivityTest.class/instance/tagging/tagExec_.st
A 
Reflectivity-Tests.package/ReflectivityTest.class/instance/tests/testTwoLinksUnstallOne.st
M 
Reflectivity.package/ReflectiveMethod.class/instance/invalidate/removeLink_.st
M Reflectivity.package/extension/CompiledMethod/instance/installLink_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60446.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60447.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60446.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60447.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60447
19847 removeLink: needs to invalidate
https://pharo.fogbugz.com/f/cases/19847

http://files.pharo.org/image/60/60447.zip

Re: [Pharo-dev] Pharo7 Inspector feature idea - cherry-pick collection items

2017-03-17 Thread Denis Kudriashov 
2017-03-17 10:18 GMT+01:00 Norbert Hartl :

> Is there a reason why the order is reversed?


I think it related to FastTable. Selected indexes are in order from last
selected to first selected. New selected row is always added as first.

[Pharo-dev] 60445, empty version info stamps

2017-03-17 Thread Ben Coman 
In 60445, browse the implementors of #cacheAt:for:ifAbsentPut:
and the view the Versions of each.
Curiously some of them have a blank user/date.

There are others...
errors := OrderedCollection new.
versions := (CompiledMethod allInstances) flatCollect: [:cm|
[VersionBrowser new setRGMethodFrom: cm asRingDefinition; buildChangeList]
on: Error do:[:ex| errors add: (cm -> ex). #()] ].
versions size.
"112131"
emptyStamps := versions select: [:rgm| rgm stamp = ''].
emptyStamps size.
"9264"
or 8%

Maybe some are historic, but I'd guess this one at least is not so old...
GLMFastListDataSource>>cacheAt:for:ifAbsentPut:

What reasonable action do we need to take?

cheers -ben

Re: [Pharo-dev] Pharo7 Inspector feature idea - cherry-pick collection items

2017-03-17 Thread Norbert Hartl 
Is there a reason why the order is reversed?

Norbert

> Am 17.03.2017 um 10:02 schrieb Tudor Girba :
> 
> Hi,
> 
> That list is multi-selection. On Mac, you can press Cmd while clicking and 
> you get the collection to the right.
> 
> 
> Cheers,
> Doru
> 
> 
>> On Mar 17, 2017, at 8:14 AM, Ben Coman > > wrote:
>> 
>> Sometimes when exploring a large data set in inspector,
>> I'd like to cherry pick a few items to act on as a collection.
>> 
>> This would need to be valdiated/tested, but It could be useful to be
>> able to multi-select items and have the next pane to the right be the
>> collection containing the list of picked items.
>> 
>> For the moment I can get by with...   "self first: 5".
>> 
>> cheers -ben
>> .
>> 
> 
> --
> www.tudorgirba.com 
> www.feenk.com
> 
> "What we can governs what we wish."
> 
> 
> 
>

Re: [Pharo-dev] Pharo7 Inspector feature idea - cherry-pick collection items

2017-03-17 Thread Tudor Girba 
Hi,

That list is multi-selection. On Mac, you can press Cmd while clicking and you 
get the collection to the right.


Cheers,
Doru


> On Mar 17, 2017, at 8:14 AM, Ben Coman  wrote:
> 
> Sometimes when exploring a large data set in inspector,
> I'd like to cherry pick a few items to act on as a collection.
> 
> This would need to be valdiated/tested, but It could be useful to be
> able to multi-select items and have the next pane to the right be the
> collection containing the list of picked items.
> 
> For the moment I can get by with...   "self first: 5".
> 
> cheers -ben
> .
> 

--
www.tudorgirba.com
www.feenk.com

"What we can governs what we wish."

Re: [Pharo-dev] Fogbugz feedback - "Image Version"

2017-03-17 Thread denker 
> On 17 Mar 2017, at 04:32, Ben Coman  wrote:
> 
> 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.
> 

Yes, and we ask to tell information about version used, platform etc in the 
issue description.

These things tend to change, too.

As a first step I think we should remove the Image Version 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.

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

2017-03-17 Thread Esteban Lorenzano 
ouch! 
I’m sorry :)
anyway I’m reverting that change because I’m transmitting that configuration to 
general script (by using osvm script). 

Esteban

> On 17 Mar 2017, at 04:35, Ben Coman  wrote:
> 
> Thanks for the report Tomo.
> cheers -ben
> 
> On Fri, Mar 17, 2017 at 10:22 AM, Tomohiro Oda  > 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
> 
>

[Pharo-dev] Pharo7 Inspector feature idea - cherry-pick collection items

2017-03-17 Thread Ben Coman 
Sometimes when exploring a large data set in inspector,
I'd like to cherry pick a few items to act on as a collection.

This would need to be valdiated/tested, but It could be useful to be
able to multi-select items and have the next pane to the right be the
collection containing the list of picked items.

For the moment I can get by with...   "self first: 5".

cheers -ben
.

Re: [Pharo-dev] Script to download Pharo 4 vm for Mac os sierra

2017-03-17 Thread Cyrille Delaunay 
Thank you Christophe, seems to work fine

2017-03-16 16:42 GMT+01:00 Christophe Demarey :

> http://files.pharo.org/get-files/40/pharo-mac-stable.zip
>
> Le 16 mars 2017 à 15:41, Cyrille Delaunay  a écrit
> :
>
> Hello,
>
> We have a jenkins job, running on a linux machine, that is responsible for
> building and outputing a Pharo 4 development image + vm ready to be used on
> mac machines.
>
> We  use this command line to download the VM and archived it as output of
> the job:
>
> curl -O http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-latest.zip
>
> On my mac (10.12.1), when i open the pharo image with this vm , I am
> facing what seem to be some known issues for Mac OS sierra:
>
> Pharo[13048:431565] *** -[NSPathStore2 stringByAppendingPathExtension:]:
> cannot append extension 'bundle/Contents/MacOS/' to path ...
>
> Now, when I try to download a Pharo 4  vm directly from my mac sierra
> machine,
> with a zeroconf script (get.pharo.org/vm40),
> It works: I am able to open the pharo image with this vm.
>
> Is there a script that allows to download a pharo 4 vm working for mac os
> sierra, from a linux machine ?
>
> --
> Cyrille Delaunay
>
>
>


-- 
Cyrille Delaunay

Re: [Pharo-dev] PharoSpur32Vm

2017-03-17 Thread p...@highoctane.be 
Definitely interested in this!

On Thu, Mar 16, 2017 at 9:51 PM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

>
>
> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier  gmail.com>:
>
>>
>>
>> 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 <
>>> 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  i...@gmail.com>:
>
>>
>>
>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier > i...@gmail.com>:
>>
>>>
>>>
>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess :
>>>


 2017-03-11 10:01 GMT+01:00 Nicolas Cellier >>> i...@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.
>