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

[Ronie Salgado]

Hi Alex,

I gave the following script:

Smalltalk compiler evaluate: '
> | surface |
> surface := AthensCairoSurface extent: 640@480.
> surface drawDuring: [ :canvas |
> surface clear: Color blue.
> ].
>
> surface asForm asMorph openInWindow
> '
>

Notice that I am wrapping the script in a string that I am passing to the
compiler, so that the workspace cannot retain any reference to the surface.

Best regards,
Ronie

2017-03-14 16:12 GMT-03:00 Alexandre Bergel :

> Hi Ronie,
>
> Below you said:
>
> The problem with asForm, is that the form returned can be used after the
> cairo surface which holds the pixels is garbage collected.
>
>
> I cannot reproduce this case. You gave a script:
>
> surface := AthensCairoSurface extent: 640@480.
> surface drawDuring: [ :canvas |
> surface clear: Color blue.
> ].
>
> surface asForm asMorph openInWindow
>
>
> I see a blue window.
>
> Cheers,
> Alexandre
>
>
> How about changing AthensCairoSurface >> asForm into the following
> definition?:
> asForm
>
> "create a form and copy an image data there"
> | form |
> self checkSession.
>
> self flush.
> form := Form extent: (self width@self height) depth: 32.
> form unhibernate.
> LibC memCopy: self getDataPtr to: form bits size: self width*self
> height*4.
> ^ form
>
> This involves a whole copy, but it removes completely the dependency on
> the surface plugin.
>
> If we want to keep using the surface plugin with Cairo, the old definition
> of asForm still has a bug, which can be reproduced with the following
> snippet:
>
> Smalltalk compiler evaluate: '
> | surface |
> surface := AthensCairoSurface extent: 640@480.
> surface drawDuring: [ :canvas |
> surface clear: Color blue.
> ].
>
> surface asForm asMorph openInWindow
> '
>
> The problem with asForm, is that the form returned can be used after the
> cairo surface which holds the pixels is garbage collected.
>
>
>

[Pharo-dev] Type Inference tools

[Gus]

Hi, 
I am working on a project of type inference, and i have the following doubt
Are there currently any tools in pharo that use this information (perhaps in
any library)?
For example: a better autocomplete where you can chose different types, or
tool that show you the type of a variable.
I've already downloaded Roel Typer but i couldn't find any of those tools.
Any help would be appreciated.
Thanks



--
View this message in context: 
http://forum.world.st/Type-Inference-tools-tp4938677.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] PharoSpur32Vm

[Nicolas Cellier]

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 > l.com>:
>>
>>> Hi Nicolai,
>>>
>>> If you look at appveyor.yml configuration on
>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml,
>>> you will see that the pharo brand is not yet in the matrix.
>>>
>>> It's because builds are based on cygwin, but as I understood, some
>>> library used by some plugin required by pharo refuse to compile with
>>> cygwin. They appear to work with mingw32.
>>> Cygwin provides headers for legacy directx, some distribution of mingw32
>>> did in the past, but it does not seem the case anymore.
>>> Using the directx headers from Microsoft SDK is a problem. They are not
>>> redistributable and can't be found anymore on the net (too old). We cannot
>>> seriously base the builds on something so fragile (both technically and
>>> legally) in the long term.
>>>
>>> Also, the 64 bits VM does only work with clang, and we don't have
>>> anything available as a 64bits Microsoft SDK... So pharo has to fix that
>>> too.
>>>
>>> In the interim, you should look at https://github.com/pharo-proje
>>> ct/pharo-vm/blob/master/.appveyor.yml and follow the scripts there.
>>>
>>
>> Ok, thank you.
>>
>>
>
> I gave it a shot on sunday, because it was particularly rainy in Nantes,
> and I almost succeeded in compiling all the dependencies with cygwin.
> Well, I mean with autotools cmake libtool pkg-config and I surely forget a
> few other niceties that some not so well informed programmers committed
> with the faith that it would make their life "easier". It certainly does
> not make mine simpler...
> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it seems
> that the workaround of Igor does not work anymore.
> ssize_t, WTF???
> Maybe I'll be able to fix it tonight. Or tomorrow. In which case I'll
> publish the branch to see how far appveyor goes.
>
>
>

So I solved the ssize_t problem by removing the hack from Igor which is not
necessary anymore...
But got another problem soon after while building the tests...
There are trailing lines generated at end of
tests/cairo-test-constructors.c that make the compilation fail:

i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I..  -I. -I./pdiff
-I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src
-I../src -D_REENTRANT
-I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1
-I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16
-Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration
-Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum
-Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2
-Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers
-Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline
-fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2
-Wno-unused-but-set-variable  -D_REENTRANT  -m32
-static-libgcc -static-libstdc++
-I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include
-march=pentium4 -c -o cairo_test_suite-cairo-test-constructors.o `test -f
'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c
cairo-test-constructors.c:1118:1: attention : la définition de données n'a
pas de type ni de classe de stockage
 oning ();
 ^
cairo-test-constructors.c:1118:1: attention : type defaults to ‘int’ in
declaration of ‘oning’ [-Wimplicit-int]
cairo-test-constructors.c:1119:5: attention : la définition de données n'a
pas de type ni de classe de stockage
 _register_ft_show_glyphs_table ();
 ^

And the file looks like it has obviously been overwritten, but not
truncated !!!

...
extern void _register_multi_page (void);
extern void _register_fallback_resolution (void);

void
_cairo_test_runner_register_tests (void)
{
_register_a1_bug ();
_register_a1_clip_paint ();
...
_register_multi_page ();
_register_fallback_resolution ();
}













*oning ();_register_ft_show_glyphs_table ();
_register_ft_text_vertical_layout_type1 ();
_register_ft_text_vertical_layout_type3 ();
_register_ft_text_antialias_none ();_register_ps_eps ();
_register_ps_features ();_register_ps_surface_source ();
_register_svg_surface ();_register_svg_clip ();
_register_svg_surface_source ();_register_multi_page ();
_register_fallback_resolution ();}*

This file is generated by a shell script
test/make-cairo-test-constructors.sh
I can't find any reference of the bug, and upgrade to version 1.14.8 does
not solve the issue.
So it will wait until tomorrow...

Nicolas


>>> I hope that Esteban will find time to resolve all these problems and
>>> have pharo brand back on opensmalltalk-vm. I guess that any form of help is
>>> welcome.
>>>
>>> Nicolas
>>>
>>>
>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess :
>>>
 I still have pro

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

[Alexandre Bergel]

Hi Ronie,

Below you said:
> The problem with asForm, is that the form returned can be used after the 
> cairo surface which holds the pixels is garbage collected.

I cannot reproduce this case. You gave a script:

> surface := AthensCairoSurface extent: 640@480.
> surface drawDuring: [ :canvas |
> surface clear: Color blue.
> ].
> 
> surface asForm asMorph openInWindow


I see a blue window.

Cheers,
Alexandre


> How about changing AthensCairoSurface >> asForm into the following 
> definition?:
> asForm
> 
> "create a form and copy an image data there"
> | form |
> self checkSession.
> 
> self flush.
> form := Form extent: (self width@self height) depth: 32.
> form unhibernate.
> LibC memCopy: self getDataPtr to: form bits size: self width*self 
> height*4.
> ^ form
> 
> This involves a whole copy, but it removes completely the dependency on the 
> surface plugin.
> 
> If we want to keep using the surface plugin with Cairo, the old definition of 
> asForm still has a bug, which can be reproduced with the following snippet:
> 
> Smalltalk compiler evaluate: '
> | surface |
> surface := AthensCairoSurface extent: 640@480.
> surface drawDuring: [ :canvas |
> surface clear: Color blue.
> ].
> 
> surface asForm asMorph openInWindow
> '
> 
> The problem with asForm, is that the form returned can be used after the 
> cairo surface which holds the pixels is garbage collected.

Re: [Pharo-dev] How to listen for microsoft os windows messages (WM_MESSAGE's)?

[Esteban Lorenzano]

you cannot use QT out of the box because is C++

I have some experiments with GTK3 that were working but event loop was kinda 
failing (no time to go back to it soon). 
It would be very interesting to have native windows support, I may take a look 
eventually :)

Esteban

> On 14 Mar 2017, at 13:37, Dimitris Chloupis  wrote:
> 
> 
> 
> There are other cross platform APIs e.g. wxWidgets and Gtk
> 
> There used to be a version of squeak with wx bindings wxSqueak but the
> code seems not to be on line now.
> 
> 
> GTK is not a very good choice, it works well on Linux but on MacOS and 
> Windows has many issues and a lot less developers bug fixing.
> 
> wxWidgets is a nice GUI API but again it does not come remotely close to the 
> feature set and stability of QT. Some of its areas also are abandoned or very 
> much lagging behind. In my case a big turn off was the outdated python 
> wrappers which sent me directly back to QT.
> 
> When it comes to guis No1 is Native GUIs , No2 is QT. 
> 
> But QT needs a commercial license for developing pro applications. Its free 
> license is GLP which limits the usage on commercial projects.
> 
> It does however offer a free LGPL version with more limited features. LGPL 
> allows to close code as long as the code is distributed via dynamically 
> linked libraries. 
> 
> Still it may be tricky to balance on the LGPL without falling down. Which is 
> why many like us prefer MIT over LGPL. 
> 
> There are a ton of open source GUI APIs out there, but most of them are 
> immature, limited or plain abandoned. So you have plenty of choice, but I 
> think you will have little reason to prefer something that is not QT, 
> especially if we are talking about commercial projects that need to run on 
> many platforms.   

[Pharo-dev] [pharo-project/pharo-core] 1c5d63: 60441

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 1c5d63f507942e5be41af0c31d02a5064f56bb7f
  
https://github.com/pharo-project/pharo-core/commit/1c5d63f507942e5be41af0c31d02a5064f56bb7f
  Author: Jenkins Build Server 
  Date:   2017-03-14 (Tue, 14 Mar 2017)

  Changed paths:
M 
Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateStartIndexWhenShowing_.st
M Nautilus.package/NautilusUI.class/instance/accessing/showHierarchy_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60440.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60441.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60440.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60441.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60441
19826 Off by one error in 
FTTableContainerMorph>>#calculateStartIndexWhenShowing:
https://pharo.fogbugz.com/f/cases/19826

19828 Class side methods + hierarchy selection eats the selected class. 
https://pharo.fogbugz.com/f/cases/19828

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

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

[GitHub]

  Branch: refs/tags/60441
  Home:   https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] How to listen for microsoft os windows messages (WM_MESSAGE's)?

[Dimitris Chloupis]

>
> There are other cross platform APIs e.g. wxWidgets and Gtk
>
> There used to be a version of squeak with wx bindings wxSqueak but the
> code seems not to be on line now.
>
>
GTK is not a very good choice, it works well on Linux but on MacOS and
Windows has many issues and a lot less developers bug fixing.

wxWidgets is a nice GUI API but again it does not come remotely close to
the feature set and stability of QT. Some of its areas also are abandoned
or very much lagging behind. In my case a big turn off was the outdated
python wrappers which sent me directly back to QT.

When it comes to guis No1 is Native GUIs , No2 is QT.

But QT needs a commercial license for developing pro applications. Its free
license is GLP which limits the usage on commercial projects.

It does however offer a free LGPL version with more limited features. LGPL
allows to close code as long as the code is distributed via dynamically
linked libraries.

Still it may be tricky to balance on the LGPL without falling down. Which
is why many like us prefer MIT over LGPL.

There are a ton of open source GUI APIs out there, but most of them are
immature, limited or plain abandoned. So you have plenty of choice, but I
think you will have little reason to prefer something that is not QT,
especially if we are talking about commercial projects that need to run on
many platforms.

Re: [Pharo-dev] Mini Pharo -> JavaScript translator?

[Dimitris Chloupis]

A potential solution would be Pharo -> Slang -> C -> Javascript
Slang converts pharo code to C and Emacscripten converts C to Javascript.
This approach also should produce minimal JS code but it wont be readable.

This C to Js approach also has the advantage of being able to utilize
webassembly and asm.js to provide high performance JS code something that
other approaches that go directly from Pharo to JS will struggle with.

The reason being that tools that support these approaches tend to more
heavily optimize the generated JS code.

The catch here is that you will have to understand both C and JS to iron
out potential issues. So this means this is definitely not a "simple way to
translate Pharo code into JS" as you requested.

Re: [Pharo-dev] Pharo6 supported syntax regression

[Nicolai Hess]

2017-03-13 16:47 GMT+01:00 Peter Uhnak :

> Hi,
>
> apparently in Pharo 6 pragma attributes can no longer be symbols without
> hash?
>
> In Pharo5 I could do
>
> method
> 
>
> and it would compile it as symbol
>
> In Pharo6 this is syntax error.
>
> I am not asking for resolution either direction (although I guess
> #Something should be canonical), it is just odd to me that the syntax would
> change (and maybe some code where people like me forgot to add hash sign
> will break).
>

Actually, I think the behavior in Pharo5 was broken, it should not compile,
and we fixed it for Pharo 6.



>
> Peter
>
>

Re: [Pharo-dev] [ANN] Fog - Ethereum driver

[Santiago Bragagnolo]

You are welcome :). We are doing some experiments for looking some research
branches on it.
So, writing some Dapps but not really productive. or not yet.
Any way, we still using solidity as language for the contracts.

Santiago



On Mon, 13 Mar 2017 at 19:44 Esteban A. Maringolo 
wrote:

> Very Nice! Thank you for building it.
>
> I started a similar project for the Bitcoin blockchain, but then I
> drifted away and never got back to it.
>
> Are you writing DAPPs?
>
> Best regards,
>
> Esteban A. Maringolo
>
>
> 2017-03-13 12:00 GMT-03:00 Santiago Bragagnolo <
> santiagobragagn...@gmail.com>:
> > Hi all. Im happy to announce a pre release of the Fog ethereum driver
> that
> > we develop in the space of an Inria project.
> >
> > It still not complete but is already usable for some experiments and
> simple
> > projects.
> >
> > You can downloadit from
> > https://github.com/sbragagnolo/Fog/
> > (https://github.com/sbragagnolo/Fog/releases/tag/v0.1.1.1)
> >
> > Dependencies
> >
> > RHash
> >
> >  sudo apt-get install rhash
> >
> > Solidity
> >
> >  npm install solc
> >
> > Download code
> >
> > Iceberg / Baseline
> >
> > Metacello
> > new
> > baseline: 'Fog';
> > repository:  'github://sbragagnolo/Fog:v0.1.1.1/src';
> > load.
> >
> > By hand
> >
> > You may want to use this version for having access to some scripts and
> > contracts samples.
> >
> > git checkout g...@github.com:sbragagnolo/Fog.git
> >
> > git checkout v0.1.1.1
> >
> > Metacello
> > new
> > baseline: 'Fog';
> > repository: 'filetree:///path/to/git-repository/Fog/src';;
> > load.
> >
> >
> > It's based on the standar API for javascript
> > (https://github.com/ethereum/wiki/wiki/JavaScript-API) .
> >
> > It provides interaction with remote contracts, it do as well provides a
> way
> > for navigating the architecture objects: blocks, transactions, accounts
> and
> > contracts.
> >
> > I hope you find it useful.
> >
> > Feel free to fill the github issue tracker with anything you find :).
> >
> >
> > I will come to you with some new exciting news about ethereum soon :)
> >
> > Santiago.
> >
> >
> >
> >
> >
> >
>
>

[Pharo-dev] [pharo-project/pharo-core] c5a89d: 60440

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: c5a89df18cc0e39d613a3855daa1e0c57a4b396e
  
https://github.com/pharo-project/pharo-core/commit/c5a89df18cc0e39d613a3855daa1e0c57a4b396e
  Author: Jenkins Build Server 
  Date:   2017-03-14 (Tue, 14 Mar 2017)

  Changed paths:
M 
MonticelloFileTree-Core.package/MCFileTreeStCypressWriter.class/instance/private/fileNameMapFor_.st
M MonticelloGUI.package/MCFileRepositoryInspector.class/instance/morphic 
ui/packageSelection.st
M Polymorph-Widgets.package/UITheme.class/instance/morph 
creation/scrollBarDownButtonBoundsFor_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60439.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60440.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60439.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60440.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Tool-Catalog.package/CatalogProvider.class/instance/actions/reset.st
M 
Tool-Catalog.package/CatalogProvider.class/instance/private/loadProjects.st

  Log Message:
  ---
  60440
19834 Error in horizontal scrollbar
https://pharo.fogbugz.com/f/cases/19834

19831 catalog refresh retrieves an empty collection
https://pharo.fogbugz.com/f/cases/19831

19823 exported source of the package MonticelloFileTree-Core in pharo-core 
repository contains strange extension
https://pharo.fogbugz.com/f/cases/19823

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

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

[GitHub]

  Branch: refs/tags/60440
  Home:   https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] PharoSpur32Vm

[Nicolas Cellier]

2017-03-14 8:58 GMT+01:00 Nicolai Hess :

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



>
>> I hope that Esteban will find time to resolve all these problems and have
>> pharo brand back on opensmalltalk-vm. I guess that any form of help is
>> welcome.
>>
>> Nicolas
>>
>>
>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess :
>>
>>> I still have problems building a vm on windows.
>>> can you give me some hints how to start ?
>>> I cloned the recent pharo-vm project,
>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\
>>> run
>>> mvm
>>>
>>> But I got a couple of problems (mingw-32 compiler commands not found, I
>>> had to adjust the include path for finding directx header, missing variable
>>> replacement for git-versions).
>>> So I may miss some important steps.
>>> Is there a repository where I can clone the mingw environment used to
>>> build the win32-pharo-vm, the environment used on the build-server ?
>>>
>>> Thanks
>>> Nicolai
>>>
>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess :
>>>


 2017-02-04 1:44 GMT+01:00 Nicolai Hess :

>
>
> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano :
>
>>
>> On 22 Jan 2017, at 13:19, Nicolai Hess  wrote:
>>
>>
>>
>> 2017-01-22 10:21 GMT+01:00 Clément Bera :
>>
>>> Hi,
>>>
>>> I believe they're built from* https://github.com/OpenSmalltalk/vm
>>> * using travis and appveyor.
>>> On the gitbhub readme there are relevant links. All built artifacts are
>>> also kept on bintray for history.
>>>
>>>
>>>
>> Thank you!
>>
>>
>> no, they aren’t :)
>> instead, they are built here: https://github.com/pharo
>> -project/pharo-vm
>>
>> (README still not updated)
>>
>
> what did changed ? I am not able to build the vm on windows anymore
> (something wrong with generating the generator.image, I'll now reset my
> local pharo-vm build directory and see if it works afterwards).
>

 see attached the stderr log :

 'Errors in script loaded from u:\github\pharo-vm\scripts\Loa
 dVMMaker.st'
 [31mMessageNotUnderstood: receiver of "default:" is nil
 [0mUndefinedObject(Object)>>doesNotUnderstand: #default:
 BaseSoundSystem class>>initialize
 MCMethodDefinition>>postloadOver:

 


> Are we still working with branch spur-64, or are we back on master ?
>
>
>
>>
>> Esteban
>>
>>
>>
>>>
>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess >> > wrote:
>>>
 Where are the latest Pharo-spur-vms (32bit) are built?
 I don't see them on the build server, only the buildresults at
 http://files.pharo.org/vm/pharo-spur32/linux/

 The latest builds on the buildserver are from the last year only.

 nicolai

>>>
>>>
>>
>>
>

>>>
>>
>

Re: [Pharo-dev] PharoSpur32Vm

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

Ok, thank you.


>
> I hope that Esteban will find time to resolve all these problems and have
> pharo brand back on opensmalltalk-vm. I guess that any form of help is
> welcome.
>
> Nicolas
>
>
> 2017-03-11 8:33 GMT+01:00 Nicolai Hess :
>
>> I still have problems building a vm on windows.
>> can you give me some hints how to start ?
>> I cloned the recent pharo-vm project,
>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\
>> run
>> mvm
>>
>> But I got a couple of problems (mingw-32 compiler commands not found, I
>> had to adjust the include path for finding directx header, missing variable
>> replacement for git-versions).
>> So I may miss some important steps.
>> Is there a repository where I can clone the mingw environment used to
>> build the win32-pharo-vm, the environment used on the build-server ?
>>
>> Thanks
>> Nicolai
>>
>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess :
>>>


 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano :

>
> On 22 Jan 2017, at 13:19, Nicolai Hess  wrote:
>
>
>
> 2017-01-22 10:21 GMT+01:00 Clément Bera :
>
>> Hi,
>>
>> I believe they're built from* https://github.com/OpenSmalltalk/vm
>> * using travis and appveyor. On
>> the gitbhub readme there are relevant links. All built artifacts are also
>> kept on bintray for history.
>>
>>
>>
> Thank you!
>
>
> no, they aren’t :)
> instead, they are built here: https://github.com/pharo
> -project/pharo-vm
>
> (README still not updated)
>

 what did changed ? I am not able to build the vm on windows anymore
 (something wrong with generating the generator.image, I'll now reset my
 local pharo-vm build directory and see if it works afterwards).

>>>
>>> see attached the stderr log :
>>>
>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\LoadVMMaker.st'
>>> [31mMessageNotUnderstood: receiver of "default:" is nil
>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default:
>>> BaseSoundSystem class>>initialize
>>> MCMethodDefinition>>postloadOver:
>>>
>>> 
>>>
>>>
 Are we still working with branch spur-64, or are we back on master ?



>
> Esteban
>
>
>
>>
>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess 
>> wrote:
>>
>>> Where are the latest Pharo-spur-vms (32bit) are built?
>>> I don't see them on the build server, only the buildresults at
>>> http://files.pharo.org/vm/pharo-spur32/linux/
>>>
>>> The latest builds on the buildserver are from the last year only.
>>>
>>> nicolai
>>>
>>
>>
>
>

>>>
>>
>