Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

[Alistair Grant]

On Sun, Apr 16, 2017 at 11:55:27PM +0200, Luke Gorrie wrote:
> I have the VM building under nix from the master branch now. The build is 
> based
> loosely on the linux.64x64 mvm script so it's building a 64-bit x86-64 VM. The
> pharo-vm commit I am testing is 1c38b03f (from wednesday.)
> 
> I have tried opening both Pharo-60465.image and Pharo-50771.image and both 
> give
> this error:
> 
> 
> This interpreter (vers. 68021) cannot read image file (vers. 6521).
> 
> 
> How come? Is this because I built a 64-bit VM? If I want to use those images
> then should I build a 32-bit image instead? (Or none of the above?)

Yes, 32 bit VM will only work with 32 bit images, and 64 bit VM with 64
bit images.



> Then I found Pharo64-60465.image and this does open and display a window but
> it's frozen and prints these messages:
> 
> 
> pthread_setschedparam failed: Operation not permitted
> This VM uses a separate heartbeat thread to update its internal clock
> and handle events.  For best operation, this thread should run at a
> higher priority, however the VM was unable to change the priority.  The
> effect is that heavily loaded systems may experience some latency
> issues.  If this occurs, please create the appropriate configuration
> file in /etc/security/limits.d/ as shown below:
> 
> cat < *  hardrtprio  2
> *  softrtprio  2
> END
> 
> and report to the squeak mailing list whether this improves behaviour.
> 
> You will need to log out and log back in for the limits to take effect.
> For more information please see
> https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux

As this says, for best operation you should enable higher priority
threads.  Have you tried creating the file as described?

That said, the message is only a warning, the system should be basically
working.


> 'Your VM is too old for this image. Please download the latest VM.'
> Error: Can't find the requested origin
>   
>  
>  
> UnixResolver(PlatformResolver)>>cantFindOriginError
> [ self cantFindOriginError ] in UnixResolver(PlatformResolver)>>
> directoryFromEnvVariableNamed: in Block: [ self cantFindOriginError ]
> [ ^ aBlock value ] in UnixResolver(PlatformResolver)>>
> directoryFromEnvVariableNamed:or: in Block: [ ^ aBlock value ]
> BlockClosure>>cull:
> Context>>evaluateSignal:
> Context>>handleSignal:
> Error(Exception)>>signal
> Error(Exception)>>signal:
> ExternalLibraryFunction(Object)>>error:
> ExternalLibraryFunction(Object)>>externalCallFailed
> ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
> UnixEnvironment(OSEnvironment)>>getEnv:
> UnixEnvironment(OSEnvironment)>>at:ifAbsent:
> [ Smalltalk os environment at: aString ifAbsent: [ nil ] ] in UnixResolver
> (PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block: [ 
> Smalltalk
> os environment at: aString ifAbse\
> nt: [...etc...
> BlockClosure>>on:do:
> UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or:
> UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:
> UnixResolver>>home
> [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self
> home / '.config' ]
> [ ^ aBlock value ] in UnixResolver(PlatformResolver)>>
> directoryFromEnvVariableNamed:or: in Block: [ ^ aBlock value ]
> BlockClosure>>cull:
> Context>>evaluateSignal:
> Context>>handleSignal:
> Error(Exception)>>signal
> Error(Exception)>>signal:
> ExternalLibraryFunction(Object)>>error:
> ExternalLibraryFunction(Object)>>externalCallFailed
> ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
> UnixEnvironment(OSEnvironment)>>getEnv:
> FFICalloutAPI>>function:module:
> 
> 
> Googling around it sounds like this "origin error" is caused by not finding 
> the
> Sources file but I have provided the PharoV50.sources and strace suggests that
> it is opened okay:
> 
> 
> open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/
> PharoV50.sources", O_RDONLY) = 3
> open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/
> PharoV50.sources", O_RDONLY) = 6

If I'm reading the stack correctly, it looks like your HOME environment
variable isn't set (or the VM isn't able to access it).


> So maybe the problem is that I need a different source file? Or maybe that I
> should switch to a 32-bit VM? Or something else entirely...?

The 32 bit VM is more stable than the 64 bit one at the moment.  If you
are still getting the build system stabilised, it might be easier to
stick with 32 bits for now.  Switching to 64 bits later should be
straightforward (certainly easier than switching from building Pharo 5
to Pharo 6).

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

[K K Subbu]

Luke,

I don't see this in the latest binary and I have not adjusted the rtprio 
figures at all. I can try running some simple tests if you send them to me.


$ curl get.pharo.org/64/60+vmLatest | bash


file Pharo.image
Pharo.image: Smalltalk image Spur 64b +C+NF+Tag (68021)

$ prlimit --rtprio
RESOURCE DESCRIPTIONSOFT HARD UNITS
RTPRIO   max real-time priority00

$ pharo-vm/lib/pharo/5.0-201704120850/pharo --version
5.0-201704120850  Wed Apr 12 09:13:59 UTC 2017 gcc 4.6.3 [Production 
Spur 64-bit ITHB VM]
CoInterpreter VMMaker.oscog-eem.2188 uuid: 
ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2188 uuid: 
ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017
VM: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ 
Date: Wed Apr 12 10:50:48 2017 +0200 $
Plugins: 201704120850 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Linux testing-gce-504e47eb-4202-4e16-92e1-3d42dab82e2f 
3.13.0-103-generic #150~precise1-Ubuntu SMP Thu Nov 24 11:05:34 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
plugin path: 
/opt/share/downloads/pharo/64/pharo-vm/lib/pharo/5.0-201704120850/ 
[default: 
/opt/share/downloads/pharo/64/pharo-vm/lib/pharo/5.0-201704120850/]


$ ./pharo Pharo.image eval 0 tinyBenchmarks
'923354373 bytecodes/sec; 82191014 sends/sec'

Regards .. Subbu

On Monday 17 April 2017 03:25 AM, Luke Gorrie wrote:

I have the VM building under nix from the master branch now. The build
is based loosely on the linux.64x64 mvm script so it's building a 64-bit
x86-64 VM. The pharo-vm commit I am testing is 1c38b03f (from wednesday.)

I have tried opening both Pharo-60465.image and Pharo-50771.image and
both give this error:

This interpreter (vers. 68021) cannot read image file (vers. 6521).


How come? Is this because I built a 64-bit VM? If I want to use those
images then should I build a 32-bit image instead? (Or none of the above?)

Then I found Pharo64-60465.image and this does open and display a window
but it's frozen and prints these messages:

pthread_setschedparam failed: Operation not permitted
This VM uses a separate heartbeat thread to update its internal clock
and handle events.  For best operation, this thread should run at a
higher priority, however the VM was unable to change the priority.  The
effect is that heavily loaded systems may experience some latency
issues.  If this occurs, please create the appropriate configuration
file in /etc/security/limits.d/ as shown below:

cat >cantFindOriginError
[ self cantFindOriginError ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in
Block: [ self cantFindOriginError ]
[ ^ aBlock value ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in
Block: [ ^ aBlock value ]
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
Error(Exception)>>signal
Error(Exception)>>signal:
ExternalLibraryFunction(Object)>>error:
ExternalLibraryFunction(Object)>>externalCallFailed
ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
UnixEnvironment(OSEnvironment)>>getEnv:
UnixEnvironment(OSEnvironment)>>at:ifAbsent:
[ Smalltalk os environment at: aString ifAbsent: [ nil ] ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in
Block: [ Smalltalk os environment at: aString ifAbse\
nt: [...etc...
BlockClosure>>on:do:
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or:
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:
UnixResolver>>home
[ self home / '.config' ] in UnixResolver>>preferences in Block: [
self home / '.config' ]
[ ^ aBlock value ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in
Block: [ ^ aBlock value ]
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
Error(Exception)>>signal
Error(Exception)>>signal:
ExternalLibraryFunction(Object)>>error:
ExternalLibraryFunction(Object)>>externalCallFailed
ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
UnixEnvironment(OSEnvironment)>>getEnv:
FFICalloutAPI>>function:module:


Googling around it sounds like this "origin error" is caused by not
finding the Sources file but I have provided the PharoV50.sources and
strace suggests that it is opened okay:


open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources",
O_RDONLY) = 3

open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources",
O_RDONLY) = 6

So maybe the problem is that I need a different source file? Or maybe
that I should switch to a 32-bit 

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Dimitris Chloupis]

Ephestos is my project that is a single configuration that unites all my
other projects under one roof. Ephestos loads 1) Nireas 2) ChronosManager
3) SmaCC (not mine) 4) Atlas 5) CPP 6) Octopus 7) BPY 8) Orpheas . Each one
of them a separate git repo with its own baseline. Some of them depend on
each other. Also each of those repos has its own configuration in case I
want to install it separately. So this way I can build my own image with a
single click.
https://github.com/kilon/Ephestos/blob/master/BaselineOfEphestos.package/BaselineOfEphestos.class/instance/baseline..st

So yeah I would like for Package Browser to stay, it works great for me and
I have not even used the convenience of git tags, branches, github releases
and git modules yet that would easily allow me to build insanely complex
images with a single click.
On Mon, 17 Apr 2017 at 00:25, Stephan Eggermont  wrote:

> On 16/04/17 16:14, Dimitris Chloupis wrote:
> > Just for the record the easiest way to load packages in the image the
> > Package Browser relies solely on configurations . Is there a plan to
> > migrate because as much I am vocal supporter of Pharo moving to git it
> > will be a big lose if Package Browser is not ported .
>
> Which browser do you mean? Catalog? That generally does not work well
> because it cannot deal with combinations of configurations.
>
> Stephan
>
>
>
>

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

[Luke Gorrie]

I have the VM building under nix from the master branch now. The build is
based loosely on the linux.64x64 mvm script so it's building a 64-bit
x86-64 VM. The pharo-vm commit I am testing is 1c38b03f (from wednesday.)

I have tried opening both Pharo-60465.image and Pharo-50771.image and both
give this error:

This interpreter (vers. 68021) cannot read image file (vers. 6521).


How come? Is this because I built a 64-bit VM? If I want to use those
images then should I build a 32-bit image instead? (Or none of the above?)

Then I found Pharo64-60465.image and this does open and display a window
but it's frozen and prints these messages:

pthread_setschedparam failed: Operation not permitted
This VM uses a separate heartbeat thread to update its internal clock
and handle events.  For best operation, this thread should run at a
higher priority, however the VM was unable to change the priority.  The
effect is that heavily loaded systems may experience some latency
issues.  If this occurs, please create the appropriate configuration
file in /etc/security/limits.d/ as shown below:

cat >cantFindOriginError
[ self cantFindOriginError ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in Block: [
self cantFindOriginError ]
[ ^ aBlock value ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block:
[ ^ aBlock value ]
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
Error(Exception)>>signal
Error(Exception)>>signal:
ExternalLibraryFunction(Object)>>error:
ExternalLibraryFunction(Object)>>externalCallFailed
ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
UnixEnvironment(OSEnvironment)>>getEnv:
UnixEnvironment(OSEnvironment)>>at:ifAbsent:
[ Smalltalk os environment at: aString ifAbsent: [ nil ] ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block:
[ Smalltalk os environment at: aString ifAbse\
nt: [...etc...
BlockClosure>>on:do:
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or:
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:
UnixResolver>>home
[ self home / '.config' ] in UnixResolver>>preferences in Block: [ self
home / '.config' ]
[ ^ aBlock value ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block:
[ ^ aBlock value ]
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
Error(Exception)>>signal
Error(Exception)>>signal:
ExternalLibraryFunction(Object)>>error:
ExternalLibraryFunction(Object)>>externalCallFailed
ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
UnixEnvironment(OSEnvironment)>>getEnv:
FFICalloutAPI>>function:module:


Googling around it sounds like this "origin error" is caused by not finding
the Sources file but I have provided the PharoV50.sources and strace
suggests that it is opened okay:

open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources",
O_RDONLY) = 3
open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources",
O_RDONLY) = 6

So maybe the problem is that I need a different source file? Or maybe that
I should switch to a 32-bit VM? Or something else entirely...?

Any help appreciated :)
-Luke

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 16/04/17 23:27, Cyril Ferlicot D. wrote:

On 16/04/2017 23:13, Stephan Eggermont wrote:

We do not break things a week before the release. We break them a week
after the release. Otherwise, why bother.

Stephan



As I asked in my previous mail, what is broken?


There are 214 instances of the text 'Color white' and 210 of
'Color black' in a 60450 image. Moose images have 1.5 to 2 as many

Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Cyril Ferlicot D.]

On 16/04/2017 23:13, Stephan Eggermont wrote:
> We do not break things a week before the release. We break them a week
> after the release. Otherwise, why bother.
> 
> Stephan
> 

As I asked in my previous mail, what is broken?

In Pharo 4 there is broken things. In Pharo 6 I don't see what is
broken. Maybe that if we see that there is indeed things broken that you
can list it will wait P7.

For now I see 0 issue on dark theme on fogbugz.

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Stephan Eggermont]

On 16/04/17 16:14, Dimitris Chloupis wrote:

Just for the record the easiest way to load packages in the image the
Package Browser relies solely on configurations . Is there a plan to
migrate because as much I am vocal supporter of Pharo moving to git it
will be a big lose if Package Browser is not ported .


Which browser do you mean? Catalog? That generally does not work well 
because it cannot deal with combinations of configurations.


Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 16/04/17 20:53, Cyril Ferlicot D. wrote:

Also, I use the dark theme since almost two years and I don't remember
having problems. Do you have examples?


Within two minutes I found a non-themed visualization in Moose.
The switching works a lot better than last time I looked at dark theme.

Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 16/04/17 20:53, Cyril Ferlicot D. wrote:

And last, when a new version of a programming language is out, we do not
expect all applications to be up to date with the language at the time
of the release.


We do not break things a week before the release. We break them a week 
after the release. Otherwise, why bother.


Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Dimitris Chloupis]

Yes it's actually more than that.

It's called Nireas and I think it's the only theme that comes with its own
GUI that allows to customize its colors , so it's very flexible.

It's available at Package Browser
On Sun, 16 Apr 2017 at 21:53, Stephane Ducasse 
wrote:

> did you publish the blue theme as an autonomous package?
>
> On Sun, Apr 16, 2017 at 2:18 PM, Dimitris Chloupis 
> wrote:
>
>> Me too, even my blue theme is nothing more than a customization of dark
>> theme. Plus dark theme is based on darcula dark theme which is by far the
>> most popular dark theme out there.
>> On Sun, 16 Apr 2017 at 14:27, Stephane Ducasse 
>> wrote:
>>
>>> clement esteban is using the dark theme since several years
>>> phil too.
>>> No new code!
>>>
>>> On Sun, Apr 16, 2017 at 12:35 AM, Clément Bera 
>>> wrote:
>>>
 Isn't a couple days before release a bit late to change the default
 theme ? Aren't we in feature freeze mode ?

 If for marketing it makes sense to switch to the dark theme, then let's
 switch to dark theme. But why not switching for Pharo 7 instead ?
 Instability is bad for marketing anyway, isn't it ?

 I don't mind for myself, I will always switch back with user settings
 to the light theme it's more about the general perception of Pharo
 stability.

 On Sat, Apr 15, 2017 at 11:31 AM, p...@highoctane.be <
 p...@highoctane.be> wrote:

> Bah, I made GTSpotter dark theme work with SublimishTheme and got the
> "yeah, for Pharo7".
>
> It is pissing me off but what can I say, just follow what is released.
>
> Compare Pharo 1 and Pharo 6. Worlds apart. I hope this continues.
>
> Phil
>
> On Sat, Apr 15, 2017 at 4:48 PM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
>> I vote for a voting system for these kind of changes. I cannot say it
>> more clearly, and I don't know why is asking for a voting system 
>> negative?
>>
>> We all have problems. In the meantime you will make all the changes
>> you like to do, and I will continue working on my own way, until I find
>> there is more voice for the "small minority".
>>
>> 2017-04-15 9:30 GMT-03:00 Stephane Ducasse :
>>
>>> Hi Hernan
>>>
>>> Why are you always so negative? Do you think that this is easy?
>>>
>>> Inria paid Denis to build a remote tool suite for ***research
>>> purpose*** and we discovered that a new remote invocation framework was
>>> needed and that they were far too many discussions between the model and
>>> the view.
>>> Denis proposed to build a new browser (and it was not in our plans)
>>> and we decided that we cannot do it otherwise.
>>> We could keep this tool for us but we share it with the community.
>>>
>>> Do you want another example?
>>> I asked christopher to build versionner and he discovered that he
>>> cannot script well enough the model. And versionner was made
>>> for everybody. Now with git we will have to revise it.
>>>
>>> Do you want another example?
>>> Iceberg we payed nicolas passerini to analyse the situation and to
>>> build a system that other people
>>> can use it.
>>>
>>> Do you want another example?
>>> Esteban got in his face the FFI problem: you see Spur arrives and
>>> FFI nabive boost does not so what do we do?
>>> He worked like a mad (and it was not planned because we thought that
>>> igor would adpta NB to spur then to 64 bits).
>>> And the FFI is for everbody.
>>>
>>> Do you want another example?
>>> We spent one year with pavel, guillermo and christophe to make sure
>>> that we can make sure that the three yars
>>> effort of the phd of guillermo on bootstrap are not lost.
>>>
>>> Do you want more?
>>> All my books are open-source? Do you know how much time I take to
>>> write a book?
>>>
>>> I spent 8 months designing a mooc and do you know how much I earned
>>> doing it: 3000 Euros ( so I will make the computation to know how much 
>>> per
>>> hour I lost) and the mooc is free.
>>>
>>> May be all these examples have no value for you. But for me they
>>> have.
>>>
>>> So you see you can piss on us if it makes you feeling better, and
>>> you can rant in your corner.
>>> But this is not the vision I have about a community because we are
>>> sharing all the things that we are doing.
>>>
>>> Stef
>>>
>>>
>>>
>>>
>>> On Sat, Apr 15, 2017 at 9:05 AM, Hernán Morales Durand <
>>> hernan.mora...@gmail.com> wrote:
>>>

 2017-04-14 8:44 GMT-03:00 Denis Kudriashov :

>
> 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano 
> :

Re: [Pharo-dev] changing default theme to DarkTheme

[Cyril Ferlicot D.]

On 16/04/2017 20:31, Stephan Eggermont wrote:
> Sorry, but that does not make sense to me. I've only heard complaints
> about dependent projects not honoring theme color settings, and I've
> never been able to switch themes actually work without leaving artifacts
> behind. I agree it makes sense to fix that, and I'm all in favor of
> temporarily switching default to black in 7. I strongly oppose switching
> themes now.
> 
> Stephan
> 
> 
> 

Hi,

There is still some glitches on theme change but most of them have been
corrected in Pharo 6.

Also, I use the dark theme since almost two years and I don't remember
having problems. Do you have examples?

And last, when a new version of a programming language is out, we do not
expect all applications to be up to date with the language at the time
of the release.

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephane Ducasse]

did you publish the blue theme as an autonomous package?

On Sun, Apr 16, 2017 at 2:18 PM, Dimitris Chloupis 
wrote:

> Me too, even my blue theme is nothing more than a customization of dark
> theme. Plus dark theme is based on darcula dark theme which is by far the
> most popular dark theme out there.
> On Sun, 16 Apr 2017 at 14:27, Stephane Ducasse 
> wrote:
>
>> clement esteban is using the dark theme since several years
>> phil too.
>> No new code!
>>
>> On Sun, Apr 16, 2017 at 12:35 AM, Clément Bera 
>> wrote:
>>
>>> Isn't a couple days before release a bit late to change the default
>>> theme ? Aren't we in feature freeze mode ?
>>>
>>> If for marketing it makes sense to switch to the dark theme, then let's
>>> switch to dark theme. But why not switching for Pharo 7 instead ?
>>> Instability is bad for marketing anyway, isn't it ?
>>>
>>> I don't mind for myself, I will always switch back with user settings to
>>> the light theme it's more about the general perception of Pharo stability.
>>>
>>> On Sat, Apr 15, 2017 at 11:31 AM, p...@highoctane.be >> > wrote:
>>>
 Bah, I made GTSpotter dark theme work with SublimishTheme and got the
 "yeah, for Pharo7".

 It is pissing me off but what can I say, just follow what is released.

 Compare Pharo 1 and Pharo 6. Worlds apart. I hope this continues.

 Phil

 On Sat, Apr 15, 2017 at 4:48 PM, Hernán Morales Durand <
 hernan.mora...@gmail.com> wrote:

> I vote for a voting system for these kind of changes. I cannot say it
> more clearly, and I don't know why is asking for a voting system negative?
>
> We all have problems. In the meantime you will make all the changes
> you like to do, and I will continue working on my own way, until I find
> there is more voice for the "small minority".
>
> 2017-04-15 9:30 GMT-03:00 Stephane Ducasse :
>
>> Hi Hernan
>>
>> Why are you always so negative? Do you think that this is easy?
>>
>> Inria paid Denis to build a remote tool suite for ***research
>> purpose*** and we discovered that a new remote invocation framework was
>> needed and that they were far too many discussions between the model and
>> the view.
>> Denis proposed to build a new browser (and it was not in our plans)
>> and we decided that we cannot do it otherwise.
>> We could keep this tool for us but we share it with the community.
>>
>> Do you want another example?
>> I asked christopher to build versionner and he discovered that he
>> cannot script well enough the model. And versionner was made
>> for everybody. Now with git we will have to revise it.
>>
>> Do you want another example?
>> Iceberg we payed nicolas passerini to analyse the situation and to
>> build a system that other people
>> can use it.
>>
>> Do you want another example?
>> Esteban got in his face the FFI problem: you see Spur arrives and FFI
>> nabive boost does not so what do we do?
>> He worked like a mad (and it was not planned because we thought that
>> igor would adpta NB to spur then to 64 bits).
>> And the FFI is for everbody.
>>
>> Do you want another example?
>> We spent one year with pavel, guillermo and christophe to make sure
>> that we can make sure that the three yars
>> effort of the phd of guillermo on bootstrap are not lost.
>>
>> Do you want more?
>> All my books are open-source? Do you know how much time I take to
>> write a book?
>>
>> I spent 8 months designing a mooc and do you know how much I earned
>> doing it: 3000 Euros ( so I will make the computation to know how much 
>> per
>> hour I lost) and the mooc is free.
>>
>> May be all these examples have no value for you. But for me they
>> have.
>>
>> So you see you can piss on us if it makes you feeling better, and you
>> can rant in your corner.
>> But this is not the vision I have about a community because we are
>> sharing all the things that we are doing.
>>
>> Stef
>>
>>
>>
>>
>> On Sat, Apr 15, 2017 at 9:05 AM, Hernán Morales Durand <
>> hernan.mora...@gmail.com> wrote:
>>
>>>
>>> 2017-04-14 8:44 GMT-03:00 Denis Kudriashov :
>>>

 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano :

> Also I am really wondering that this decision was not publicly
> discussed. We should vote for such kind of changes.
>
>
> no, this is not how it works.
>

 yes, it is how it could work :)

 Current approach is not bad for technical choices because it is
 difficult to make everybody evolved in particular technical topic.
 But 

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Cyril Ferlicot D.]

On 16/04/2017 08:54, Tudor Girba wrote:
> However, Configurations are useful in offering people a way to understand how 
> the code is organized. For example, in Moose we have the inspector extension 
> that shows the dependencies and it is very valuable.
> 
> The only thing we need is to Metacello to be able to load new versions of the 
> configuration/baseline.
> 

Hi,

This is already possible via the method #get.

But, IMO, the user should not have to do that with a fresh Pharo image.


> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> “The smaller and more pervasive the hardware becomes, the more physical the 
> software gets."
> 
> 


-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] changing default theme to DarkTheme

[Hernán Morales Durand]

Hi Norbert,

2017-04-16 13:28 GMT-03:00 Norbert Hartl :

> I wonder why voting is considered something good. To me voting is rather a
> last resort strategy.
> Voting is taking power without the need for having an opinion nor any
> reason. To me the sense of voting is to make most people feel
> empowered/comfortable. And the outcome is often poor or even contradictory.
>
>
On the contrary, voting is a good measure of the wisdom and education of
the community.
Voting is a way to get people who seek absolute power and tyrants out of
the road.
Because a man without a vote is a man without protection.
Because voting and prevents the cult of ignorance promoted by the
Open-Source lemma of the "benevolent dictatorship".

That post-modern notion of benevolent dictatorship will solve things is
terrible.


Hernán



my 2 cents,
>
> Norbert
>
>
> Am 16.04.2017 um 17:49 schrieb Ben Coman :
>
>
>
> On Sat, Apr 15, 2017 at 8:01 PM, Cyril Ferlicot D. <
> cyril.ferli...@gmail.com> wrote:
>
>> Can people just explain to my why we have so many big threads each time
>> a default settings is changed?
>>
>
> Law of triviality.  https://en.wikipedia.org/wiki/Law_of_triviality
> Because its natural to have personal preferences/opinions and easy
> to bike-shed about those. I'm as guilty as the next guy.
>
> btw, I'm in favour of the board making these sorts of executive decisions
> rather than voting.
> Sure if a vote was 90% against the dark theme it would seem strange to go
> against it,
> but what if it was only 51%.  I don't imagine that result really smoothing
> community sentiment.
> Now what about 55% or 60%? Where you draw the line now becomes an
> executive decision.
>
> So sometimes its more efficient to just move than have continuous
> discussions.  Also there may
> be a bigger picture to bring in more users/money (aka marketting) which we
> don't hear
> the details of.  But people do need an opportunity to vent so the board
> are not blind
> to community sentiment. So just roll with it.
>
> cheers -ben
>
>
>>
>> I understand that some settings need a certain default value when it
>> come for discover-ability of a feature. But why so many noise for
>> feature that are totally taste dependent? The principle of settings is
>> that some people will like the default one and some will not like it.
>> That's the point.
>>
>> Why are people so afraid of settings? I have the impression that Pharo
>> has no setting system each time I see those threads.
>>
>> Neverless, I agree that we should have a way at the first launch of
>> Pharo on a computer to let the user define some common settings as
>> Squeak does. It's a really cool feature of most IDEs (like Intellij for
>> example). Probably too late for Pharo 6, but not for Pharo 7.
>>
>> I am just a little tired to see this many noise for things like that.
>>
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>>
>> http://www.synectique.eu
>> 2 rue Jacques Prévert 01,
>> 59650 Villeneuve d'ascq France
>>
>>
>

Re: [Pharo-dev] changing default theme to DarkTheme

[Norbert Hartl]

I wonder why voting is considered something good. To me voting is rather a last 
resort strategy. 
Voting is taking power without the need for having an opinion nor any reason. 
To me the sense of voting is to make most people feel empowered/comfortable. 
And the outcome is often poor or even contradictory.

my 2 cents,

Norbert


> Am 16.04.2017 um 17:49 schrieb Ben Coman :
> 
> 
> 
>> On Sat, Apr 15, 2017 at 8:01 PM, Cyril Ferlicot D. 
>>  wrote:
>> Can people just explain to my why we have so many big threads each time
>> a default settings is changed?
> 
> Law of triviality.  https://en.wikipedia.org/wiki/Law_of_triviality  
> Because its natural to have personal preferences/opinions and easy 
> to bike-shed about those. I'm as guilty as the next guy.
> 
> btw, I'm in favour of the board making these sorts of executive decisions 
> rather than voting.
> Sure if a vote was 90% against the dark theme it would seem strange to go 
> against it,
> but what if it was only 51%.  I don't imagine that result really smoothing 
> community sentiment.
> Now what about 55% or 60%? Where you draw the line now becomes an executive 
> decision.
> 
> So sometimes its more efficient to just move than have continuous 
> discussions.  Also there may
> be a bigger picture to bring in more users/money (aka marketting) which we 
> don't hear 
> the details of.  But people do need an opportunity to vent so the board are 
> not blind 
> to community sentiment. So just roll with it.
> 
> cheers -ben
>  
>> 
>> I understand that some settings need a certain default value when it
>> come for discover-ability of a feature. But why so many noise for
>> feature that are totally taste dependent? The principle of settings is
>> that some people will like the default one and some will not like it.
>> That's the point.
>> 
>> Why are people so afraid of settings? I have the impression that Pharo
>> has no setting system each time I see those threads.
>> 
>> Neverless, I agree that we should have a way at the first launch of
>> Pharo on a computer to let the user define some common settings as
>> Squeak does. It's a really cool feature of most IDEs (like Intellij for
>> example). Probably too late for Pharo 6, but not for Pharo 7.
>> 
>> I am just a little tired to see this many noise for things like that.
>> 
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>> 
>> http://www.synectique.eu
>> 2 rue Jacques Prévert 01,
>> 59650 Villeneuve d'ascq France
>> 
> 

Re: [Pharo-dev] changing default theme to DarkTheme

[Ben Coman]

On Sat, Apr 15, 2017 at 8:01 PM, Cyril Ferlicot D.  wrote:

> Can people just explain to my why we have so many big threads each time
> a default settings is changed?
>

Law of triviality.  https://en.wikipedia.org/wiki/Law_of_triviality
Because its natural to have personal preferences/opinions and easy
to bike-shed about those. I'm as guilty as the next guy.

btw, I'm in favour of the board making these sorts of executive decisions
rather than voting.
Sure if a vote was 90% against the dark theme it would seem strange to go
against it,
but what if it was only 51%.  I don't imagine that result really smoothing
community sentiment.
Now what about 55% or 60%? Where you draw the line now becomes an executive
decision.

So sometimes its more efficient to just move than have continuous
discussions.  Also there may
be a bigger picture to bring in more users/money (aka marketting) which we
don't hear
the details of.  But people do need an opportunity to vent so the board are
not blind
to community sentiment. So just roll with it.

cheers -ben


>
> I understand that some settings need a certain default value when it
> come for discover-ability of a feature. But why so many noise for
> feature that are totally taste dependent? The principle of settings is
> that some people will like the default one and some will not like it.
> That's the point.
>
> Why are people so afraid of settings? I have the impression that Pharo
> has no setting system each time I see those threads.
>
> Neverless, I agree that we should have a way at the first launch of
> Pharo on a computer to let the user define some common settings as
> Squeak does. It's a really cool feature of most IDEs (like Intellij for
> example). Probably too late for Pharo 6, but not for Pharo 7.
>
> I am just a little tired to see this many noise for things like that.
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>
>

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

[Ben Coman]

On Sun, Apr 16, 2017 at 10:50 PM, Alistair Grant  wrote:
> Hi Ben,
>
> On Sun, Apr 16, 2017 at 10:42:42PM +0800, Ben Coman wrote:
>> On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie  wrote:
>> > On 15 April 2017 at 10:08, Alistair Grant 
>> > wrote:
>> >
>> > Grabbing the source directly from Git is attractive if (a) I know
>> > that I am choosing a good version and (b) I am able to build it in a
>> > good way.
>> >
>> > Seems like a workable solution to (a) is to periodically check for a
>> > new binary release, work out which commit it is based off, and build
>> > that. This seems fairly reasonable and is probably also possible to
>> > automate. (I suppose you got the commit-id from --version or from
>> > checking Jenkins.)
>> >
>> > I see (b) as problematic though. The source tarball releases have a
>> > simple build procedure ("make") while the Git checkouts require a
>> > more involved one (bootstrapping the VM from an existing Pharo
>> > image.)
>>
>> A historical perspective...
>>
>> Prior to this coming Release 6, Pharo had diverged from the parent
>> build system used by OpenSmalltalk (nee Squeak-VM) such that (IIUC) it
>> was driven from the Image generating the generated-C-sources plus the
>> Cmake configuration.  I guess this is what you describe as
>> "bootstrap".
>>
>> However for Release 6 onwards, Pharo has returned to the fold and is
>> directly using the OpenSmalltalk build system. The OpenSmalltalk build
>> system does not require a build to invoke a Smalltalk image, and I
>> notice elsewhere you've seen the ./ mvm script.  Eliot currently
>> manually updates the checked-in generated-C-sources at times he
>> considers them stably generated from VMMaker-Image, although I think I
>> saw recently some mention of doing CI on each VMMaker check-in..
>
> Do you know how the linux zero conf scripts are / will be built?
>
> My assumption has been that they are part of the image build.

I'm not familiar with the zero-conf implementation.
You might learn something here...
https://github.com/pharo-project/pharo-zeroconf

cheers -ben

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

[Alistair Grant]

Hi Ben,

On Sun, Apr 16, 2017 at 10:42:42PM +0800, Ben Coman wrote:
> On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie  wrote:
> > On 15 April 2017 at 10:08, Alistair Grant 
> > wrote:
> >
> > Grabbing the source directly from Git is attractive if (a) I know
> > that I am choosing a good version and (b) I am able to build it in a
> > good way.
> >
> > Seems like a workable solution to (a) is to periodically check for a
> > new binary release, work out which commit it is based off, and build
> > that. This seems fairly reasonable and is probably also possible to
> > automate. (I suppose you got the commit-id from --version or from
> > checking Jenkins.)
> >
> > I see (b) as problematic though. The source tarball releases have a
> > simple build procedure ("make") while the Git checkouts require a
> > more involved one (bootstrapping the VM from an existing Pharo
> > image.)
> 
> A historical perspective...
> 
> Prior to this coming Release 6, Pharo had diverged from the parent
> build system used by OpenSmalltalk (nee Squeak-VM) such that (IIUC) it
> was driven from the Image generating the generated-C-sources plus the
> Cmake configuration.  I guess this is what you describe as
> "bootstrap".  
> 
> However for Release 6 onwards, Pharo has returned to the fold and is
> directly using the OpenSmalltalk build system. The OpenSmalltalk build
> system does not require a build to invoke a Smalltalk image, and I
> notice elsewhere you've seen the ./ mvm script.  Eliot currently
> manually updates the checked-in generated-C-sources at times he
> considers them stably generated from VMMaker-Image, although I think I
> saw recently some mention of doing CI on each VMMaker check-in..   

Do you know how the linux zero conf scripts are / will be built?

My assumption has been that they are part of the image build.

Thanks,
Alistair

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

[Ben Coman]

On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie  wrote:
> On 15 April 2017 at 10:08, Alistair Grant  wrote:
>
> Grabbing the source directly from Git is attractive if (a) I know that I
am
> choosing a good version and (b) I am able to build it in a good way.
>
> Seems like a workable solution to (a) is to periodically check for a new
> binary release, work out which commit it is based off, and build that.
This
> seems fairly reasonable and is probably also possible to automate. (I
> suppose you got the commit-id from --version or from checking Jenkins.)
>
> I see (b) as problematic though. The source tarball releases have a simple
> build procedure ("make") while the Git checkouts require a more involved
one
> (bootstrapping the VM from an existing Pharo image.)

A historical perspective...

Prior to this coming Release 6, Pharo had diverged from the parent build
system
used by OpenSmalltalk (nee Squeak-VM) such that (IIUC) it was driven from
the
Image generating the generated-C-sources
plus the Cmake configuration.  I guess this is what you describe as
"bootstrap".

However for Release 6 onwards, Pharo has returned to the fold and is
directly using
the OpenSmalltalk build system. The OpenSmalltalk build system does not
require
a build to invoke a Smalltalk image, and I notice elsewhere you've seen the
./mvm script.
Eliot currently manually updates the checked-in generated-C-sources at
times he
considers them stably generated from VMMaker-Image, although I think I saw
recently some mention of doing CI on each VMMaker check-in..

So the Pharo 5 in-Image CMake generation system is deprecated, and
I guess there will not be much further development on the Pharo 5 VM.
So I would consider *not* including the bootstrap as part of the nix process
and manually perform the bootstrap per steps 1 to 3 here...
* https://github.com/pharo-project/pharo-vm/tree/5.0-stable
then archive those folders to create your own source-distribution

Now it would be good to hear if Pharo might get a Pharo-5-stable-VM
deployed from OpenSmalltalk?

cheers -ben



> So I would need to
> revise the nix build scripts quite a bit if I want to build from Git
instead
> of the tarballs. However, it seems that on the master branch last week the
> VM build procedure has been reworked so that it is _not_ necessary to run
> the bootstrapping procedure anymore, which sounds great to me, except
that I
> understand this new build procedure to be quite bleeding edge and not yet
> documented or used for a binary release (it's not included in the commit
> that you cite above.)
>
> So what to make of all that? Just right now I see only bad alternatives:
> sticking with the source release means not supporting Pharo 5.0, updating
> the build scripts to do bootstrapping takes effort and is already
obsoleted
> by changes on the VM master branch, and shipping the VM master branch
means
> making a pseudo-release without any QA and potentially causing problems
for
> people downstream (there are lots of commits landing on that branch and I
> have no idea which ones are important/stable.)
>
> So the most reasonable course of action from my point of view seems to be
to
> sit and wait for a better solution to come along e.g. a new source release
> of the VM or a "blessed" Git commit ID that includes the updated build
> scripts. The downside is that meanwhile NixOS users can't run the 5.0
image.
> Could be that Pharo 6.0 will resolve this and that is fine for me -- but
of
> course I'd take a solution sooner if there is a simple one.
>
>

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Dimitris Chloupis]

Just for the record the easiest way to load packages in the image the
Package Browser relies solely on configurations . Is there a plan to
migrate because as much I am vocal supporter of Pharo moving to git it will
be a big lose if Package Browser is not ported .
On Sun, 16 Apr 2017 at 09:55, Tudor Girba  wrote:

> However, Configurations are useful in offering people a way to understand
> how the code is organized. For example, in Moose we have the inspector
> extension that shows the dependencies and it is very valuable.
>
> The only thing we need is to Metacello to be able to load new versions of
> the configuration/baseline.
>
> Cheers,
> Doru
>
>
> > On Apr 16, 2017, at 8:36 AM, Tudor Girba  wrote:
> >
> > Hi,
> >
> > For the record, the way we load the latest version of Moose is to
> explicitly load the configurations we know about as being in the base Pharo
> image. Like this:
> >
> > ./pharo $JOB_NAME.image eval "Gofer new smalltalkhubUser: 'Moose'
> project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new
> smalltalkhubUser: 'Moose' project: 'GToolkit'; package:
> 'ConfigurationOfGTInspector'; package: 'ConfigurationOfGTInspectorCore';
> package: 'ConfigurationOfGTSpotter'; package:
> 'ConfigurationOfGTPlayground'; package: 'ConfigurationOfGTPlaygroundCore';
> package: 'ConfigurationOfGToolkit'; package: 'ConfigurationOfGToolkitCore';
> package: 'ConfigurationOfGTEventRecorder'; load. Smalltalk snapshot: true
> andQuit: true."
> >
> > This is a horrible hack, and like any hack it backfires in time. It
> backfired now because we forgot about MooseAlgos being in the base Pharo
> image :).
> >
> > Cheers,
> > Doru
> >
> >
> >> On Apr 15, 2017, at 11:23 PM, Cyril Ferlicot D. <
> cyril.ferli...@gmail.com> wrote:
> >>
> >> On 15/04/2017 23:16, Tudor Girba wrote:
> >>> Hi,
> >>>
> >>> Ok, that is a better reason.
> >>>
> >>> As far as I can tell, the baseline situation is not much better, is it?
> >>>
> >>> Cheers,
> >>> Doru
> >>>
> >>
> >> Yes.
> >>
> >> If the process would have been the same for Pharo 7 than for Pharo 6 I
> >> would have suggest to unload the configurations after every update of a
> >> project using configuration.
> >>
> >> Here, since the process will change I wait to see how the new process
> >> will look like. But I would like the configurations/baselines to be
> >> unload of Pharo to avoid this.
> >>
> >> I would like to unload all the configurations of the image of Pharo 6 to
> >> remove a potential bug source of Pharo 6 for future users who would need
> >> an update of GlamourCore, a GT tool, Ston, UFFI or any other project
> >> having his configuration in the image.
> >>
> >> --
> >> Cyril Ferlicot
> >> https://ferlicot.fr
> >>
> >> http://www.synectique.eu
> >> 2 rue Jacques Prévert 01,
> >> 59650 Villeneuve d'ascq France
> >>
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Problem solving should be focused on describing
> > the problem in a way that makes the solution obvious."
> >
> >
> >
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> “The smaller and more pervasive the hardware becomes, the more physical
> the software gets."
>
>
>

Re: [Pharo-dev] Epicea should ask before recovering

[Denis Kudriashov]

2017-04-16 12:09 GMT+02:00 Peter Uhnak :

> Of course if I am the only person that uses images in such a way then I
> can just work around it myself. (because having endless lists of config
> options is also nightmare)


Me too

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

[Ben Coman]

Whoops, now copied to pharo-dev to continue discussion there.

On Sun, Apr 16, 2017 at 9:13 PM, Ben Coman  wrote:
> On Sat, Apr 15, 2017 at 12:43 PM, Luke Gorrie  wrote:
>>
>> On 14 April 2017 at 22:20, Stephane Ducasse  wrote:
>>>
>>> This is what we always have when we release and we freeze it.
>>> The vm 60 will be compatible with latest pharo 60 image.
>>
>>
>> It is possible that I have misunderstood the whole situation and there is no 
>> problem at all. That would be awesome. Let's check :-) here is my 
>> understanding of the state of the world right now:
>>
>> The latest stable image release is Pharo-50771.image.
>> The latest stable VM source release is pharo-vm-2016.02.18.
>> These two releases are not compatible: This interpreter (vers. 6505) cannot 
>> read image file (vers. 6521).
>>
>> So the problem is that if a distribution packages the latest VM source 
>> release then the users won't be able to run the Pharo 5 VM that they 
>> download from pharo.org or via the pharo-launcher image.
>>
>> Is that correct? If so that's fine and hopefully we can fix it for Pharo 
>> 6.0. But if I am misunderstanding and a fix is available today that would 
>> also be good to know.
>>
>> I am looking for the "latest VM source release" in 
>> http://files.pharo.org/vm/src/vm-unix-sources/
>
>> and assuming that non-spur is the stable option for pre-6.0 images.
>
> That is not correct.  Pharo 5 used a Spur-VM since build 50496 circa 
> 2015-12-14.
>   * http://files.pharo.org/image/50-preSpur/
>   * http://files.pharo.org/image/50/
>
> cheers -ben

Re: [Pharo-dev] changing default theme to DarkTheme

[Dimitris Chloupis]

Me too, even my blue theme is nothing more than a customization of dark
theme. Plus dark theme is based on darcula dark theme which is by far the
most popular dark theme out there.
On Sun, 16 Apr 2017 at 14:27, Stephane Ducasse 
wrote:

> clement esteban is using the dark theme since several years
> phil too.
> No new code!
>
> On Sun, Apr 16, 2017 at 12:35 AM, Clément Bera 
> wrote:
>
>> Isn't a couple days before release a bit late to change the default theme
>> ? Aren't we in feature freeze mode ?
>>
>> If for marketing it makes sense to switch to the dark theme, then let's
>> switch to dark theme. But why not switching for Pharo 7 instead ?
>> Instability is bad for marketing anyway, isn't it ?
>>
>> I don't mind for myself, I will always switch back with user settings to
>> the light theme it's more about the general perception of Pharo stability.
>>
>> On Sat, Apr 15, 2017 at 11:31 AM, p...@highoctane.be 
>> wrote:
>>
>>> Bah, I made GTSpotter dark theme work with SublimishTheme and got the
>>> "yeah, for Pharo7".
>>>
>>> It is pissing me off but what can I say, just follow what is released.
>>>
>>> Compare Pharo 1 and Pharo 6. Worlds apart. I hope this continues.
>>>
>>> Phil
>>>
>>> On Sat, Apr 15, 2017 at 4:48 PM, Hernán Morales Durand <
>>> hernan.mora...@gmail.com> wrote:
>>>
 I vote for a voting system for these kind of changes. I cannot say it
 more clearly, and I don't know why is asking for a voting system negative?

 We all have problems. In the meantime you will make all the changes you
 like to do, and I will continue working on my own way, until I find there
 is more voice for the "small minority".

 2017-04-15 9:30 GMT-03:00 Stephane Ducasse :

> Hi Hernan
>
> Why are you always so negative? Do you think that this is easy?
>
> Inria paid Denis to build a remote tool suite for ***research
> purpose*** and we discovered that a new remote invocation framework was
> needed and that they were far too many discussions between the model and
> the view.
> Denis proposed to build a new browser (and it was not in our plans)
> and we decided that we cannot do it otherwise.
> We could keep this tool for us but we share it with the community.
>
> Do you want another example?
> I asked christopher to build versionner and he discovered that he
> cannot script well enough the model. And versionner was made
> for everybody. Now with git we will have to revise it.
>
> Do you want another example?
> Iceberg we payed nicolas passerini to analyse the situation and to
> build a system that other people
> can use it.
>
> Do you want another example?
> Esteban got in his face the FFI problem: you see Spur arrives and FFI
> nabive boost does not so what do we do?
> He worked like a mad (and it was not planned because we thought that
> igor would adpta NB to spur then to 64 bits).
> And the FFI is for everbody.
>
> Do you want another example?
> We spent one year with pavel, guillermo and christophe to make sure
> that we can make sure that the three yars
> effort of the phd of guillermo on bootstrap are not lost.
>
> Do you want more?
> All my books are open-source? Do you know how much time I take to
> write a book?
>
> I spent 8 months designing a mooc and do you know how much I earned
> doing it: 3000 Euros ( so I will make the computation to know how much per
> hour I lost) and the mooc is free.
>
> May be all these examples have no value for you. But for me they have.
>
> So you see you can piss on us if it makes you feeling better, and you
> can rant in your corner.
> But this is not the vision I have about a community because we are
> sharing all the things that we are doing.
>
> Stef
>
>
>
>
> On Sat, Apr 15, 2017 at 9:05 AM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
>>
>> 2017-04-14 8:44 GMT-03:00 Denis Kudriashov :
>>
>>>
>>> 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano :
>>>
 Also I am really wondering that this decision was not publicly
 discussed. We should vote for such kind of changes.


 no, this is not how it works.

>>>
>>> yes, it is how it could work :)
>>>
>>> Current approach is not bad for technical choices because it is
>>> difficult to make everybody evolved in particular technical topic.
>>> But look is different. You just open Pharo and have impression
>>> is it looks good or not. Voting can work here.
>>>
>>
>> I would forget about it. I stopped waiting for votes long time ago in
>> this community. Also I decided to stop contributing to external 

Re: [Pharo-dev] Help currency review

[Stephane Ducasse]

tx ben
indeed this is nice to update this text
s.

On Sat, Apr 8, 2017 at 4:25 AM, Ben Coman  wrote:

> At this late stage of Pharo 6 development, it might be good to do a pass
> at...
> World > Help > Help Browser content
>
> Epicea >Browsers - mentions two separate browser windows
>
> GT Debugger >> Actions - TODO
>
> GT Playground >> Overview - http://gt.moosetechnology.org redirects to
> http://gtoolkit.org/
> and same for several GT entries
>
> Welcome > Getting Help says...
> - The "Pharo Users" mailing list: http://lists.pharo.org/
> mailman/listinfo/pharo-users_lists.pharo.org
> - The "Pharo Slack Team": http://slack4pharo.trentosur.com/
> - The "Pharo IRC Channel": irc.freenode.net, #pharo channel
> - http://pharo.org/community
>
> So we should change from Slack to Discord.
> I can take care of this one but a couple questions...
>
> 1. I propose a Discord #Help channel to record here in the help browser.
>
> 2. I bumped into an interesting tip
> https://www.reddit.com/r/discordapp/comments/3yu1bh/
> server_vs_channel_invites/
>
> Thus I propose we have a #Welcome channel providing info like what the bot
> has been providing.
> Later it could be good to have a bot just in that channel, but not off
> someone's home server :)
> I would expect that channel to not need anyone lurking in it.  Newcomers
> will jump immediately
> from there #Help or #General
>
> 3. How active is the IRC channel?  Should we remove it from the help
> browser?
> The mention at http://pharo.org/community could be sufficient.
>
> 4. Should we backport this help info update to Pharo 5?
>
> cheers -ben
>
>

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephane Ducasse]

clement esteban is using the dark theme since several years
phil too.
No new code!

On Sun, Apr 16, 2017 at 12:35 AM, Clément Bera 
wrote:

> Isn't a couple days before release a bit late to change the default theme
> ? Aren't we in feature freeze mode ?
>
> If for marketing it makes sense to switch to the dark theme, then let's
> switch to dark theme. But why not switching for Pharo 7 instead ?
> Instability is bad for marketing anyway, isn't it ?
>
> I don't mind for myself, I will always switch back with user settings to
> the light theme it's more about the general perception of Pharo stability.
>
> On Sat, Apr 15, 2017 at 11:31 AM, p...@highoctane.be 
> wrote:
>
>> Bah, I made GTSpotter dark theme work with SublimishTheme and got the
>> "yeah, for Pharo7".
>>
>> It is pissing me off but what can I say, just follow what is released.
>>
>> Compare Pharo 1 and Pharo 6. Worlds apart. I hope this continues.
>>
>> Phil
>>
>> On Sat, Apr 15, 2017 at 4:48 PM, Hernán Morales Durand <
>> hernan.mora...@gmail.com> wrote:
>>
>>> I vote for a voting system for these kind of changes. I cannot say it
>>> more clearly, and I don't know why is asking for a voting system negative?
>>>
>>> We all have problems. In the meantime you will make all the changes you
>>> like to do, and I will continue working on my own way, until I find there
>>> is more voice for the "small minority".
>>>
>>> 2017-04-15 9:30 GMT-03:00 Stephane Ducasse :
>>>
 Hi Hernan

 Why are you always so negative? Do you think that this is easy?

 Inria paid Denis to build a remote tool suite for ***research
 purpose*** and we discovered that a new remote invocation framework was
 needed and that they were far too many discussions between the model and
 the view.
 Denis proposed to build a new browser (and it was not in our plans) and
 we decided that we cannot do it otherwise.
 We could keep this tool for us but we share it with the community.

 Do you want another example?
 I asked christopher to build versionner and he discovered that he
 cannot script well enough the model. And versionner was made
 for everybody. Now with git we will have to revise it.

 Do you want another example?
 Iceberg we payed nicolas passerini to analyse the situation and to
 build a system that other people
 can use it.

 Do you want another example?
 Esteban got in his face the FFI problem: you see Spur arrives and FFI
 nabive boost does not so what do we do?
 He worked like a mad (and it was not planned because we thought that
 igor would adpta NB to spur then to 64 bits).
 And the FFI is for everbody.

 Do you want another example?
 We spent one year with pavel, guillermo and christophe to make sure
 that we can make sure that the three yars
 effort of the phd of guillermo on bootstrap are not lost.

 Do you want more?
 All my books are open-source? Do you know how much time I take to write
 a book?

 I spent 8 months designing a mooc and do you know how much I earned
 doing it: 3000 Euros ( so I will make the computation to know how much per
 hour I lost) and the mooc is free.

 May be all these examples have no value for you. But for me they have.

 So you see you can piss on us if it makes you feeling better, and you
 can rant in your corner.
 But this is not the vision I have about a community because we are
 sharing all the things that we are doing.

 Stef




 On Sat, Apr 15, 2017 at 9:05 AM, Hernán Morales Durand <
 hernan.mora...@gmail.com> wrote:

>
> 2017-04-14 8:44 GMT-03:00 Denis Kudriashov :
>
>>
>> 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano :
>>
>>> Also I am really wondering that this decision was not publicly
>>> discussed. We should vote for such kind of changes.
>>>
>>>
>>> no, this is not how it works.
>>>
>>
>> yes, it is how it could work :)
>>
>> Current approach is not bad for technical choices because it is
>> difficult to make everybody evolved in particular technical topic.
>> But look is different. You just open Pharo and have impression
>> is it looks good or not. Voting can work here.
>>
>
> I would forget about it. I stopped waiting for votes long time ago in
> this community. Also I decided to stop contributing to external projects
> (including reporting bugs) because who knows which tool (browser, morphic,
> etc) the board would like to add/remove tomorrow. I will not invest my 
> time
> fixing tools who knows what's the plan on them.
>
> The best you can do is to work in the dark and adapt your stuff with
> each new Pharo version.
> Of course anyone with enough time/money could 

[Pharo-dev] Pharo VM build for nix, was: Re: [Pharo-users] Pharo 6 snap install

[Luke Gorrie]

I made a pull request from the work-in-progress branch where I am tweaking
things to build the latest VM under nix:

https://github.com/pharo-project/pharo-vm/pull/129

The tricky bit that I haven't confronted properly yet is the overlap
between nix and mvm/zeroconf i.e. each one wants to be in charge of
managing the shared library dependencies.

I'd ideally like to handle the dependencies on the nix side and have a
sufficient test suite to check that the VM+libs that I provide works with
the popular images too. Is such a test suite available perhaps?

But maybe I will need to build the exact same libraries as mvm does or even
fall back to packaging binary releases of the VM instead of building them
myself. (mvm script is not directly usable for reasons sketched in the PR.)



On Sat, 15 Apr 2017 at 14:46, Esteban Lorenzano  wrote:

> this belongs to pharo-dev, please continue there :)
>
>
> On 15 Apr 2017, at 14:25, Alistair Grant  wrote:
>
> On Sat, Apr 15, 2017 at 02:14:26PM +0200, Luke Gorrie wrote:
>
> On 15 April 2017 at 11:53, Alistair Grant  wrote:
>
>(actually, I'm not sure why you're bothering since 6 should
>be out before the end of the month, but that's your choice :-)).
>
>
> I just want something stable and reasonably modern for running existing
> applications and building new ones.
>
> If that means waiting for Pharo 6.0 release then that is okay with me.
>
>
>The (V6) linux install relies on a number of bash scripts to launch
> pharo
>(bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo).  How are you producing
>these, or are you doing something else?
>
>
> Here is where those scripts are generated in the existing pharo-vm
> packaging:
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/pharo/vm/
> build-vm.nix#L50-L70
>
>
> Ahh, so Nix is doing its own thing, not using the ZeroConf scripts.
>
>
> (I didn't write the nix packaging code but I have volunteered to maintain
> it so
> if it's out of date then I should fix that.)
>
>
> It will be for V6.  Esteban has changed the scripts to ensure that Pharo
> versions of libraries are loaded (from memory)(this is also partly why I
> would like to use the full build process).
>
>
>git clone https://github.com/pharo-project/pharo-vm.git
>git checkout 
>cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build
>./mvm
>--
>
>BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my
>experience is that it is significantly less stable than the latest
>binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb
>
>
> This is really the bleeding edge :-) both of those commits were pushed
> within
> the past three days!
>
>
> Yep, V6 is still in testing. :-)
>
> Cheers,
> Alistair
>
>
>

[Pharo-dev] Iceberg and git repository management

[Peter Uhnak]

Hi,

is Iceberg (or its git subsytem) capable of more than just Pharo code 
management?

More specifically, would it be possible with Iceberg to commit e.g. a change to 
a README.md or .travis.yml file in the repository?

Thanks,
Peter

[Pharo-dev] Epicea should ask before recovering

[Peter Uhnak]

Hi,

can we modify epicea before asking for recovery?
Because right now when I close image to intentionally throw away changes 
(because I managed to break the image or whatever), Epicea will freeze the 
image on startup for 10-15 seconds for even a mere 6-method change.

(I also had it freeze for (couple) minutes on a rather big changeset...)

Closing image and reopening is a very convenient way to get back to usable 
state of the image, so maybe a configuration option that would first prompt me 
"Epicea has detected lost changes, do you want to review them?  " 
would be nice.

Of course if I am the only person that uses images in such a way then I can 
just work around it myself. (because having endless lists of config options is 
also nightmare)

Peter

[Pharo-dev] Parser for mongodb queries in javascript notations

[chrismihaylyk]

Hello!

I'm creating MongoDBBrowser that have all CRUD operations and I need a
parser that translates javascript queries in MongoDB to the queries, for
making selects, inserts etc. using Mongo class.
For example, I have query 

db.SomeCollection.find( {$or: [ { name: { $regex: /test/i } }, {
description: { $regex: /test/i } } ] } )

that is manually rewriting into 
someCollection select: { 
'$or' -> { 
{ 'name' -> { 
'$regex' -> 'test' . 
'$options' -> 'i' } asDictionary } asDictionary.
{ 'description' -> { 
'$regex' -> 'test' . 
'$options' -> 'i' } asDictionary } asDictionary
} 
} asDictionary

But I need to have a parser that will do it automatically.

Maybe there are already exist one? If not, how to write my own?
Please help.

Thanks a lot, Khrystyna=)



--
View this message in context: 
http://forum.world.st/Parser-for-mongodb-queries-in-javascript-notations-tp4942280.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Please, test our 64bits builds

[Alistair Grant]

Hi Esteban,

On Fri, Apr 14, 2017 at 08:06:05AM +, Alistair Grant wrote:
> 
> I've basically moved my personal environment to 64 bits, which means all
> of the following have been loaded and most have had some adhoc testing:
> 
> Iceberg
> OSProcess

If I try this with any of the VMs I built, OSProcess causes the image to 
lock up as soon as a process is forked  (there aren't any error messages 
on the console and Ctrl-. doesn't work).  Also the grimReaper process 
fails regularly.

I haven't tried every recent commit, but it appears that the only VM 
I have that works with OSProcess is:

$ ./pharo --version
5.0-201704120850  Wed Apr 12 09:11:51 UTC 2017 gcc 4.6.3 [Production Spur 
64-bit VM]
CoInterpreter VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 
Apr 12 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2188 uuid: 
ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017
VM: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: 
Wed Apr 12 10:50:48 2017 +0200 $
Plugins: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Linux testing-gce-05737cd5-38bf-479c-9575-20f53c3bf93b 3.13.0-103-generic 
#150~precise1-Ubuntu SMP Thu Nov 24 11:05:34 UTC 2016 x86_64 x86_64 x86_64 
GNU/Linux
plugin path: /dev/shm/pharo64/pharo-vm/lib/pharo/5.0-201704120850 [default: 
/dev/shm/pharo64/pharo-vm/lib/pharo/5.0-201704120850/]

Note: I'm building from https://github.com/pharo-project/pharo-vm.git

Should I open an issue in fogbugz for this (with code to reproduce and
more details on the grim reaper process)?

P.S. I think Pharo 5 included in the commit id in the version 
information.  It would be nice for that to reappear in V6.

Thanks!
Alistair

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Tudor Girba]

However, Configurations are useful in offering people a way to understand how 
the code is organized. For example, in Moose we have the inspector extension 
that shows the dependencies and it is very valuable.

The only thing we need is to Metacello to be able to load new versions of the 
configuration/baseline.

Cheers,
Doru


> On Apr 16, 2017, at 8:36 AM, Tudor Girba  wrote:
> 
> Hi,
> 
> For the record, the way we load the latest version of Moose is to explicitly 
> load the configurations we know about as being in the base Pharo image. Like 
> this:
> 
> ./pharo $JOB_NAME.image eval "Gofer new smalltalkhubUser: 'Moose' project: 
> 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new 
> smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 
> 'ConfigurationOfGTInspector'; package: 'ConfigurationOfGTInspectorCore'; 
> package: 'ConfigurationOfGTSpotter'; package: 'ConfigurationOfGTPlayground'; 
> package: 'ConfigurationOfGTPlaygroundCore'; package: 
> 'ConfigurationOfGToolkit'; package: 'ConfigurationOfGToolkitCore'; package: 
> 'ConfigurationOfGTEventRecorder'; load. Smalltalk snapshot: true andQuit: 
> true."
> 
> This is a horrible hack, and like any hack it backfires in time. It backfired 
> now because we forgot about MooseAlgos being in the base Pharo image :).
> 
> Cheers,
> Doru
> 
> 
>> On Apr 15, 2017, at 11:23 PM, Cyril Ferlicot D.  
>> wrote:
>> 
>> On 15/04/2017 23:16, Tudor Girba wrote:
>>> Hi,
>>> 
>>> Ok, that is a better reason.
>>> 
>>> As far as I can tell, the baseline situation is not much better, is it?
>>> 
>>> Cheers,
>>> Doru
>>> 
>> 
>> Yes.
>> 
>> If the process would have been the same for Pharo 7 than for Pharo 6 I
>> would have suggest to unload the configurations after every update of a
>> project using configuration.
>> 
>> Here, since the process will change I wait to see how the new process
>> will look like. But I would like the configurations/baselines to be
>> unload of Pharo to avoid this.
>> 
>> I would like to unload all the configurations of the image of Pharo 6 to
>> remove a potential bug source of Pharo 6 for future users who would need
>> an update of GlamourCore, a GT tool, Ston, UFFI or any other project
>> having his configuration in the image.
>> 
>> -- 
>> Cyril Ferlicot
>> https://ferlicot.fr
>> 
>> http://www.synectique.eu
>> 2 rue Jacques Prévert 01,
>> 59650 Villeneuve d'ascq France
>> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Problem solving should be focused on describing
> the problem in a way that makes the solution obvious."
> 
> 
> 
> 
> 

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

“The smaller and more pervasive the hardware becomes, the more physical the 
software gets."

Re: [Pharo-dev] [Pharo-users] why is adding instance variables so slow?

[Tudor Girba]

Hi,

Please let’s move this discussion on pharo-dev. And keep going :)

Cheers,
Doru




> On Apr 14, 2017, at 12:09 PM, Denis Kudriashov  wrote:
> 
> 
> 2017-04-14 11:09 GMT+02:00 teso...@gmail.com :
> Hi, I think the problem was not clearly explained. This is the scenario that 
> is problematic. 
> This scenario does not happen in the new Spur implementation of forwarding, 
> but I think is happening in the old one.
> 
> 1. You have, let's say 3 instances of ClassA.
> 2. You add a new instance variable to ClassA. It produces
>2a. A new ClassAv2 is created with the instances variables of ClassA and 
> the newone
>2b. 3 Instances of ClassAv2 are created
>2c. The values of the instance variables of ClassA are copied to the ones 
> in ClassAv2 (the ones missing are left in nil).
>2d. The 3 instances of ClassA are becomed forward to the 3 instances of 
> ClassAv2
>2e. The ClassA is becomed forward ClassAv2
> 
> I still not see why my example not reflects all these steps. I checked also 
> scenario with class becoming:
> 
> c1 := Class1 new.
> c2 := Class2 new.
> c1 becomeForward: c2.
> Class1 becomeForward: Class2.
> Class2 allInstances "=>#(aClass2)"
> 
> It also works in Cog

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

"What we can governs what we wish."

Re: [Pharo-dev] changing default theme to DarkTheme

[Hilaire]

Life can be very UNFAIR but I don't see how it is related to the
previously expressed opinions about what people fell.

Le 15/04/2017 à 17:07, Stephane Ducasse a écrit :
> behavior. I'm just thinking that it is UNFAIR

-- 
Dr. Geo
http://drgeo.eu