Re: [Pharo-dev] Color yzw

[Denis Kudriashov]

And it is in 50556

2016-01-29 13:39 GMT+01:00 Nicolai Hess :

>
>
> 2016-01-29 13:10 GMT+01:00 Denis Kudriashov :
>
>> Hi Nicolai.
>> Now your proposals in slice 17496
>> 
>> .
>> We change it a little bit: we make SelectorsTable lazy. And code
>> completion uses it too.
>>
>
> +1,
>
> Let's see if it works :)
> Thanks
>
>
>
>>
>> 2016-01-16 22:17 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2016-01-16 13:46 GMT+01:00 Marcus Denker :
>>>

 On 16 Jan 2016, at 13:26, Nicolai Hess  wrote:



 2016-01-16 10:11 GMT+01:00 Marcus Denker :

>
> anyone an idea?
>
> I'm trying to think.
> Looks like it would be good to be able to make a distinction between
> symbols and selectors (selectors installed
> in method dictionaries)
>
>
> yes, this would improve code completion a bit, too, as there are more
> symbols than symbols that are actually names
> of methods.
>
> The data could be created per environment (Smalltalk globals) the
> first time and then cached till shutdown.
> (it would be an array of size 46451, pointing to existing symbols).
>
> The environment could cache sent selectors, too… pablo did an
> experiment with that.
>
> Marcus
>
>
 How about a new SymbolTable "SelectorTable" that gets new entries on
 every method compilation ?


 maybe better when a method is added to a Method Dictionary? This way
 even adding things the strange
 way would work...

>>>
>>> I tried some methods from TBehavior basicAddSelector:withMethod:
>>> but for example Nautilus, directly modifies method dict
>>>
>>>


 I hacked a simple experimental version.
 But I don't yet understand the workflow for initialisation of the
 Symbol class (with rehash, interned, and compacting).


 If we hook into adding methods, then compactSymbolTable and rehash
 could just reset the SelectorTable and fill it after by going over all
 methods…

>>>
>>>
>>> see attached changesets.
>>>
>>> load with:
>>>
>>> DangerousClassNotifier disableDuring:[
>>> String subclass: #Symbol
>>> instanceVariableNames: ''
>>> classVariableNames: 'NewSymbols OneCharacterSymbols SymbolTable
>>> SelectorTable'
>>> package: 'Collections-Strings'
>>> ].
>>>
>>> DangerousClassNotifier disableDuring:[
>>> 'selectortable.1.cs'
>>> asFileReference fileIn.
>>> ].
>>> Symbol initSelectorTable.
>>> 'use_selector_table.cs' asFileReference fileIn.
>>>
>>> what do you think ?
>>>
>>> (selectortable.cs defines SelectorTable and some methods in Symbol and
>>> String)
>>> (use_selector_table adds selectors as internedSelectorSymbol if this
>>> selector is set as a selector on CompiledMethod
>>> and uses findInternedSelector  in RubStyler visitMessageNode)
>>>
>>>


 Marcus


>>>
>>
>

[Pharo-dev] [pharo-project/pharo-core] c99e24: 50558

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: c99e24992162ba83eaacf95176c92ec9338c70c6
  
https://github.com/pharo-project/pharo-core/commit/c99e24992162ba83eaacf95176c92ec9338c70c6
  Author: Jenkins Build Server 
  Date:   2016-01-29 (Fri, 29 Jan 2016)

  Changed paths:
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50557.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50558.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50557.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50558.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50558
16735 Replace Startup/Shutdown list with SessionManager
https://pharo.fogbugz.com/f/cases/16735

http://files.pharo.org/image/50/50558.zip

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 6456a3: 50555

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 6456a3f5d3400e8efce6941a99ea425f7c3da45a
  
https://github.com/pharo-project/pharo-core/commit/6456a3f5d3400e8efce6941a99ea425f7c3da45a
  Author: Jenkins Build Server 
  Date:   2016-01-29 (Fri, 29 Jan 2016)

  Changed paths:
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50554.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50555.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50554.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50555.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50555
16735 Replace Startup/Shutdown list with SessionManager
https://pharo.fogbugz.com/f/cases/16735

http://files.pharo.org/image/50/50555.zip

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 0def64: 50557

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 0def643003d9b5298ee0a5c4f06a3e6f4f8daa18
  
https://github.com/pharo-project/pharo-core/commit/0def643003d9b5298ee0a5c4f06a3e6f4f8daa18
  Author: Jenkins Build Server 
  Date:   2016-01-29 (Fri, 29 Jan 2016)

  Changed paths:
M 
SUnit-UI.package/CommandLineTestRunner.class/instance/helper/printError_of_.st
M 
SUnit-UI.package/CommandLineTestRunner.class/instance/helper/printFailure_of_.st
A 
SUnit-UI.package/CommandLineTestRunner.class/instance/helper/shortStackDescriptionFor_.st
M SUnit-UI.package/VTermTestRunner.class/instance/helper/print_short_of_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50556.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50557.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50556.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50557.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50557
17490 Command Line Handler test runner should print a small stack for failures 
and errors
https://pharo.fogbugz.com/f/cases/17490

http://files.pharo.org/image/50/50557.zip

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

[GitHub]

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

Re: [Pharo-dev] Nitpick: Launcher Colors

[Sean P. DeNigris]

CyrilFerlicot wrote
> When the launcher is in full screen and the label of the image/template
> is short, it allow to click on the right row where there is nothing.
> In Windows it happen a lot that the window is in full screen.

Got it! Thanks for the explanation. I retract my suggestion :)



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Nitpick-Launcher-Colors-tp4874592p4874719.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Color yzw

[Nicolai Hess]

2016-01-29 13:10 GMT+01:00 Denis Kudriashov :

> Hi Nicolai.
> Now your proposals in slice 17496
> 
> .
> We change it a little bit: we make SelectorsTable lazy. And code
> completion uses it too.
>

+1,

Let's see if it works :)
Thanks



>
> 2016-01-16 22:17 GMT+01:00 Nicolai Hess :
>
>>
>>
>> 2016-01-16 13:46 GMT+01:00 Marcus Denker :
>>
>>>
>>> On 16 Jan 2016, at 13:26, Nicolai Hess  wrote:
>>>
>>>
>>>
>>> 2016-01-16 10:11 GMT+01:00 Marcus Denker :
>>>

 anyone an idea?

 I'm trying to think.
 Looks like it would be good to be able to make a distinction between
 symbols and selectors (selectors installed
 in method dictionaries)


 yes, this would improve code completion a bit, too, as there are more
 symbols than symbols that are actually names
 of methods.

 The data could be created per environment (Smalltalk globals) the first
 time and then cached till shutdown.
 (it would be an array of size 46451, pointing to existing symbols).

 The environment could cache sent selectors, too… pablo did an
 experiment with that.

 Marcus


>>> How about a new SymbolTable "SelectorTable" that gets new entries on
>>> every method compilation ?
>>>
>>>
>>> maybe better when a method is added to a Method Dictionary? This way
>>> even adding things the strange
>>> way would work...
>>>
>>
>> I tried some methods from TBehavior basicAddSelector:withMethod:
>> but for example Nautilus, directly modifies method dict
>>
>>
>>>
>>>
>>> I hacked a simple experimental version.
>>> But I don't yet understand the workflow for initialisation of the Symbol
>>> class (with rehash, interned, and compacting).
>>>
>>>
>>> If we hook into adding methods, then compactSymbolTable and rehash could
>>> just reset the SelectorTable and fill it after by going over all methods…
>>>
>>
>>
>> see attached changesets.
>>
>> load with:
>>
>> DangerousClassNotifier disableDuring:[
>> String subclass: #Symbol
>> instanceVariableNames: ''
>> classVariableNames: 'NewSymbols OneCharacterSymbols SymbolTable
>> SelectorTable'
>> package: 'Collections-Strings'
>> ].
>>
>> DangerousClassNotifier disableDuring:[
>> 'selectortable.1.cs'
>> asFileReference fileIn.
>> ].
>> Symbol initSelectorTable.
>> 'use_selector_table.cs' asFileReference fileIn.
>>
>> what do you think ?
>>
>> (selectortable.cs defines SelectorTable and some methods in Symbol and
>> String)
>> (use_selector_table adds selectors as internedSelectorSymbol if this
>> selector is set as a selector on CompiledMethod
>> and uses findInternedSelector  in RubStyler visitMessageNode)
>>
>>
>>>
>>>
>>> Marcus
>>>
>>>
>>
>

Re: [Pharo-dev] Color yzw

[Denis Kudriashov]

Hi Nicolai.
Now your proposals in slice 17496

.
We change it a little bit: we make SelectorsTable lazy. And code completion
uses it too.

2016-01-16 22:17 GMT+01:00 Nicolai Hess :

>
>
> 2016-01-16 13:46 GMT+01:00 Marcus Denker :
>
>>
>> On 16 Jan 2016, at 13:26, Nicolai Hess  wrote:
>>
>>
>>
>> 2016-01-16 10:11 GMT+01:00 Marcus Denker :
>>
>>>
>>> anyone an idea?
>>>
>>> I'm trying to think.
>>> Looks like it would be good to be able to make a distinction between
>>> symbols and selectors (selectors installed
>>> in method dictionaries)
>>>
>>>
>>> yes, this would improve code completion a bit, too, as there are more
>>> symbols than symbols that are actually names
>>> of methods.
>>>
>>> The data could be created per environment (Smalltalk globals) the first
>>> time and then cached till shutdown.
>>> (it would be an array of size 46451, pointing to existing symbols).
>>>
>>> The environment could cache sent selectors, too… pablo did an experiment
>>> with that.
>>>
>>> Marcus
>>>
>>>
>> How about a new SymbolTable "SelectorTable" that gets new entries on
>> every method compilation ?
>>
>>
>> maybe better when a method is added to a Method Dictionary? This way even
>> adding things the strange
>> way would work...
>>
>
> I tried some methods from TBehavior basicAddSelector:withMethod:
> but for example Nautilus, directly modifies method dict
>
>
>>
>>
>> I hacked a simple experimental version.
>> But I don't yet understand the workflow for initialisation of the Symbol
>> class (with rehash, interned, and compacting).
>>
>>
>> If we hook into adding methods, then compactSymbolTable and rehash could
>> just reset the SelectorTable and fill it after by going over all methods…
>>
>
>
> see attached changesets.
>
> load with:
>
> DangerousClassNotifier disableDuring:[
> String subclass: #Symbol
> instanceVariableNames: ''
> classVariableNames: 'NewSymbols OneCharacterSymbols SymbolTable
> SelectorTable'
> package: 'Collections-Strings'
> ].
>
> DangerousClassNotifier disableDuring:[
> 'selectortable.1.cs'
> asFileReference fileIn.
> ].
> Symbol initSelectorTable.
> 'use_selector_table.cs' asFileReference fileIn.
>
> what do you think ?
>
> (selectortable.cs defines SelectorTable and some methods in Symbol and
> String)
> (use_selector_table adds selectors as internedSelectorSymbol if this
> selector is set as a selector on CompiledMethod
> and uses findInternedSelector  in RubStyler visitMessageNode)
>
>
>>
>>
>> Marcus
>>
>>
>

Re: [Pharo-dev] [pharo-project/pharo-core] 6456a3: 50555

[Esteban Lorenzano]

this is, again, not true… integrator is seriously broken… looking at it now. 
 
> On 29 Jan 2016, at 12:28, GitHub  wrote:
> 
>  Branch: refs/heads/5.0
>  Home:   https://github.com/pharo-project/pharo-core
>  Commit: 6456a3f5d3400e8efce6941a99ea425f7c3da45a
>  
> https://github.com/pharo-project/pharo-core/commit/6456a3f5d3400e8efce6941a99ea425f7c3da45a
>  Author: Jenkins Build Server 
>  Date:   2016-01-29 (Fri, 29 Jan 2016)
> 
>  Changed paths:
>R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
> scripts/script50554.st
>A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
> scripts/script50555.st
>R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
> updates/update50554.st
>A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
> updates/update50555.st
>M 
> ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
> 
>  Log Message:
>  ---
>  50555
> 16735 Replace Startup/Shutdown list with SessionManager
>   https://pharo.fogbugz.com/f/cases/16735
> 
> http://files.pharo.org/image/50/50555.zip
> 
> 

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 885c7e: 50556

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 885c7e53d4beeb012d4bdeb6212400b8d5a36e4c
  
https://github.com/pharo-project/pharo-core/commit/885c7e53d4beeb012d4bdeb6212400b8d5a36e4c
  Author: Jenkins Build Server 
  Date:   2016-01-29 (Fri, 29 Jan 2016)

  Changed paths:
A Collections-Strings.package/Symbol.class/class/access/allSymbols.st
A 
Collections-Strings.package/Symbol.class/class/access/selectorsContaining_.st
A 
Collections-Strings.package/Symbol.class/class/access/thatStartsCaseSensitive_skipping_.st
A 
Collections-Strings.package/Symbol.class/class/access/thatStarts_skipping_.st
R Collections-Strings.package/Symbol.class/class/accessing/allSymbols.st
A 
Collections-Strings.package/Symbol.class/class/accessing/selectorThatStartsCaseSensitive_skipping_.st
R 
Collections-Strings.package/Symbol.class/class/accessing/selectorsContaining_.st
R 
Collections-Strings.package/Symbol.class/class/accessing/thatStartsCaseSensitive_skipping_.st
R 
Collections-Strings.package/Symbol.class/class/accessing/thatStarts_skipping_.st
A Collections-Strings.package/Symbol.class/class/as yet 
unclassified/release.st
R 
Collections-Strings.package/Symbol.class/class/cleanup/compactSymbolTable.st
A 
Collections-Strings.package/Symbol.class/class/initialization/allSymbolTablesDo_.st
A 
Collections-Strings.package/Symbol.class/class/initialization/allSymbolTablesDo_after_.st
A 
Collections-Strings.package/Symbol.class/class/initialization/compactSymbolTable.st
A 
Collections-Strings.package/Symbol.class/class/initialization/initialize.st
R 
Collections-Strings.package/Symbol.class/class/initialize-release/initialize.st
R 
Collections-Strings.package/Symbol.class/class/initialize-release/release.st
A Collections-Strings.package/Symbol.class/class/instance 
creation/findInternedSelector_.st
A Collections-Strings.package/Symbol.class/class/instance 
creation/internSelector_.st
R 
Collections-Strings.package/Symbol.class/class/iterating/allSymbolTablesDo_.st
R 
Collections-Strings.package/Symbol.class/class/iterating/allSymbolTablesDo_after_.st
A 
Collections-Strings.package/Symbol.class/class/private/initSelectorTable.st
M Collections-Strings.package/Symbol.class/class/private/rehash.st
A 
Collections-Strings.package/Symbol.class/class/private/resetSelectorTable.st
A Collections-Strings.package/Symbol.class/class/private/selectorTable.st
A Collections-Strings.package/Symbol.class/class/private/shutDown_.st
R Collections-Strings.package/Symbol.class/class/system startup/shutDown_.st
M Collections-Strings.package/Symbol.class/definition.st
A 
Collections-Strings.package/Symbol.class/instance/testing/isSelectorSymbol.st
M Kernel.package/CompiledMethod.class/instance/accessing/selector_.st
M 
NECompletion.package/NECSymbols.class/class/private/interestingSymbolsDo_.st
M Rubric.package/RubSHTextStylerST80.class/instance/visiting rb 
nodes/visitMessageNode_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50555.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50556.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50555.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50556.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50556
17496 add table for all defined method selectors and use it in code completion 
and syntax highlighting
https://pharo.fogbugz.com/f/cases/17496

http://files.pharo.org/image/50/50556.zip

Re: [Pharo-dev] Disable assertions (design by contract)

[Clément Bera]

I tried to experiment with such behavior a while ago.

I added an opal compiler extension here:
http://smalltalkhub.com/mc/ClementBera/NeoCompiler/main . One needs to
recompile the package after it is loaded as it uses a compiler extension.

The idea was to introduce [ "some code" ] Cvalue, with Cvalue a message
evaluated at compilation time depending on a class-side setting.

I put examples in the package. This method:

example
^ [ Smalltalk vm class ] Cvalue

is compiled, depending on a class side setting, to:

example
^ VirtualMachine

or

example
   ^ Smalltalk vm class

I could have added similar things for assert: and maybe add the C++ IFDEF
macro, but in the end I don't think this is a good idea in a Smalltalk
system. The code becomes hard to read or you have to extend a lot Smalltalk
(extend the syntax, etc.).

If one really wants to do that, he can write it in his own DSL that
compiles to Smalltalk. It is way easier and does not pollute the base
Smalltalk. The user-designed compilation could happen with RB AST
transformations, and honestly this is not very difficult and a good
developer could do it without too many troubles.



2016-01-29 2:12 GMT+01:00 Eliot Miranda :

> Hi Richard,
>
> > On Jan 28, 2016, at 2:15 PM, Richard Sargent <
> richard.sarg...@gemtalksystems.com> wrote:
> >
> > Aliaksei Syrel wrote
> >> Hi
> >>
> >> Assertions play an important role in design by contract. It is great to
> >> have assertions in Pharo out of box (Object>>#assert:). However in
> >> projects
> >> with many post- and precondition as also class invariants heavy usage of
> >> assertions decreases performance...
> >>
> >> Would it be possible to have a compiler setting (in setting browser) to
> >> enable/disable assertions and not compile them to bytecode? Compiler
> >> should
> >> ignore the whole assertion statement with removed condition. For
> example:
> >>
> >>> self assert: self hugeInvariant.
> >>
> >> with disabled assertion hugeInvariant must not be sent.
> >>
> >> Thanks,
> >> Alex
> >
> > My concern with this is that this proposal requires certain selectors to
> > become /reserved/. Most SUnit variations that I have seen entail several
> > dozen methods for asserting and denying behaviours, block evaluation
> versus
> > inline expressions, descriptive explanations, and so on.
> >
> > It seems to me that you would be better off sending messages to a global.
> > Instead of:
> >> self assert: self hugeInvariant.
> > have something like:
> >> Assert that: self hugeInvariant.
> >
> > If the global Assert is bound to a stub the message is sent and ignored.
> If
> > bound to a real assertion mechanism, it gets evaluated. Use blocks when
> the
> > argument evaluation is expensive or expensive enough.
> >> Assert evaluationOf: [self hugeInvariant].
> >
> > None of the names should be taken as suggestions. Just the concept.
>
> It's a good concept, and is the object-oriented approach.  It's just that
> in practice the costs of creating blocks as assert: arguments, while
> typically much cheaper than evaluating the assert and discarding its
> result, are still significant
>
> Hence I'm open to a compiler hack that elides the assert: or deny: and
> it's send altogether from the code.  Open but not happy; it's something I
> hold my nose to do.  But this is a style I've been using for twenty odd
> years and it is really nice to be able to write assert-laden code but not
> have to pay in production.
>
> There is a ray of hope.  The Sista adaptive optimiser /will/ be able to
> elide all the cost of the block form:
>
> ...
> self assert: [self expr].
> ...
>
> Foo methods for assertions
> assert: aBlockOrBoolean
>^self
>
> because there are obviously no side effects.  Whereas it will only be able
> to elide the entire thing depending on expr in the non-block form:
>
> ...
> self assert: self expr.
> ...
>
> But I wonder how any people would have the discipline or insight to use
> the block form.  It looks unnecessarily verbose yes?
>
> > This also offers the benefit that assertions are practical everywhere,
> not
> > just under a TestCase hierarchy.
>
> Whether asserts are practicable everywhere IME depend on how useful they
> are in ongoing development.  The fact that they cost a /lot/ and slow down
> the VM simulator for Cog doesn't change the fact that it would be much much
> slower to modify the code base.
>
> In another thread I was proposing to Gulle to use the VM simulator instead
> of a custom VM for his Pharo bootstrap.  But in that case one would /have/
> to find a way of eliding asserts.  One approach would be a package-level
> rewrite tool that could produce a copy of a package in which asserts have
> been eliminated.  One would always do development in the assert-laden
> version, but could make the assert-less version available to clients who
> treat the package as a black box, can therefore assume that no asserts ever
> fail (because the 

[Pharo-dev] Smalltalkhub scheduled maintenance next monday (February, 1st)

[Christophe Demarey]

Hello,

Smalltalk will be down next monday (february, 1st) from 12:30 to 13:30 (french 
local time).
IT will add storage to the root partition.

Regards,
Christophe

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

[GitHub]

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

Re: [Pharo-dev] Contributing to Pharo

[Dale Henrichs]

On 01/29/2016 09:02 AM, Bernhard Pieber wrote:

Hi Dale,

I am trying to understand this a little better. If a package containing 
metadata would be changed using a dialect which cannot interpret the metadata, 
wouldn’t or at least couldn’t it be broken or lost afterwards for a dialect 
which tries to interpret the metadata? At least if my assumption is correct 
that the metadata is related to the code in some way?


Bernhard,

Very good question.

You are absolutely correct, the act of writing a new version of a 
package using a different dialect would indeed destroy the 
platform-specific meta data.


However, it is NOT expected that two different dialects (with different 
disk formats)  share the same commit.


If dialect A has committed a package, then dialect B is expected to be 
able to read the package written by dialect A. Being able to read the 
package means that all of the information that is common between the two 
dialects will be preserved ... in FileTree, this means that:


  - all of the class and instance method source is readable and shared
  - the method category is readable and shared
  - the name, superclass, instance variables, class instance variables,
pools, class category, and class vars for classes is readable and 
shared


This is an awful lot common data  things like traits or namespaces 
are dialect specific and are ignored by dialects that don't have them 
when reading the package ...


When dialect B has read, loaded/compiled and tested the code in the 
package, the developer has a couple of choices to be made when writing 
out a new package with her changes:


  - use the current branch
  - use a new branch

I think that using a new branch is the cleanest option. When I port a 
project like Zinc[1] to GemStone[2], the master branch is preserved for 
the Pharo-specific code. I create a gs_master branch where the GemStone 
code goes. When Sven commits new code in his repo, I merge the changes 
from the his new master branch into my gs_master and resolve conflicts 
if any, run tests and I'm done.


The vast mjority of the code base is shared between GemStone and Pharo 
and only the places where I made changes in porting Zinc to GemStone 
have the potential for conflicts. Running the tests should highlight 
any  impacts not covered by direct conflicts and if there were some 
Pharo-specific meta data that I deleted on my branch that causes a test 
to fail then that is up to me to research and fix.


When I have changes to feed back to Sven, I make those changes on a 
separate "topic branch"[3] that is merged into gs_master for my use. I 
then cherry-pick[4] the topic branch commit into a separate topic branch 
off of the master branch (this picks up only the changes I made on the 
topic branch) and open a pull request[5] against Svens repository ... if 
Sven were using travis-ci, tests would be run automatically against a 
merge of my changes into his master branch ... if the tests are green 
and the code passes Sven's scrutiny in a code review he merges my 
proposed changes into his master branch...


GemStone and Pharo share a common disk format (not 100% common), but 
since git only merges the deltas for a commit, it is relatively easy to 
keep the meta data differences isolated while still sharing the vast 
bulk of the code and classes 


Dale

[1] https://github.com/svenvc/zinc
[2] https://github.com/GsDevKit/zinc
[3] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
[4] 
http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html

[5] https://help.github.com/articles/using-pull-requests/

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

[Mariano Martinez Peck]

BTW, Esteban Maringolo asked me if the Travis scripts were "sharable".
Well, Esteban Lorenzano shared them with me and I improved them a bit for
my needs, so of course they are shareable!  And all my projects listed as
MIT, they are all MIT all the way down.

Cheers,

On Fri, Jan 29, 2016 at 3:36 AM, Sven Van Caekenberghe  wrote:

> Nice !
>
> > On 29 Jan 2016, at 01:03, Mariano Martinez Peck 
> wrote:
> >
> > Hi guys,
> >
> > This is just to let you know that with the help of Esteban and between
> some work together [1] [2] I was able to have Travis CI integrated with
> OSSubprocess and FFICHeaderExtractor [3] [4] . Both projects are built and
> tested under Linux and OSX. Note also that one of the projects does a lot
> of FFI calls to system libs like libc and the other even generates C
> programs, compiles them and run it. Even the OS dependencies (like
> installing the compiler) are resolved correctly :)
> >
> > If someone wants to know how it's done, simply check the .travis.yml and
> the scripts/run-test.sh of each project [5] [6].
> >
> > [1] https://pharo.fogbugz.com/f/cases/17488
> > [2] https://pharo.fogbugz.com/f/cases/17490
> > [3] https://travis-ci.org/marianopeck/OSSubprocess
> > [4] https://travis-ci.org/marianopeck/FFICHeaderExtractor
> > [5] https://github.com/marianopeck/OSSubprocess
> > [6] https://github.com/marianopeck/FFICHeaderExtractor
> >
> >
> > Cheers,
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

[Pharo-dev] [pharo-project/pharo-core] 03f485: 50559

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 03f48517e360f34d4c97b75a5f3a77f32988a4de
  
https://github.com/pharo-project/pharo-core/commit/03f48517e360f34d4c97b75a5f3a77f32988a4de
  Author: Jenkins Build Server 
  Date:   2016-01-29 (Fri, 29 Jan 2016)

  Changed paths:
R 
DebuggerActions.package/PeelToFirstDebugAction.class/instance/testing/appliesToDebugger_.st
R 
DebuggerActions.package/RestartDebugAction.class/instance/testing/appliesToDebugger_.st
R 
DebuggerActions.package/ResumeDebugAction.class/instance/testing/appliesToDebugger_.st
R 
DebuggerActions.package/ReturnValueDebugAction.class/instance/testing/appliesToDebugger_.st
R 
DebuggerActions.package/RunToSelectionDebugAction.class/instance/testing/appliesToDebugger_.st
R 
DebuggerActions.package/StepIntoDebugAction.class/instance/testing/appliesToDebugger_.st
R 
DebuggerActions.package/StepOverDebugAction.class/instance/testing/appliesToDebugger_.st
R 
DebuggerActions.package/StepThroughDebugAction.class/instance/testing/appliesToDebugger_.st
R 
DebuggerModel.package/DebugSession.class/instance/testing/isInterruptedContextPostMortem.st
R 
GT-BytecodeDebugger.package/GTStepToBytecodeDebugAction.class/instance/testing/appliesToDebugger_.st
R 
Glamour-Tests-Morphic.package/GLMMorphicExamplesTest.class/instance/tests/testSmoke.st
M Nautilus.package/Nautilus.class/instance/accessing/selectedPackage_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50558.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50559.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50558.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50559.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50559
17489 remove testSmoke
https://pharo.fogbugz.com/f/cases/17489

17463 NautilusUI>>#updatePackages MessageNotUnderstood: RPackage>>item
https://pharo.fogbugz.com/f/cases/17463

17459 #isInterruptedContextPostMortem should not be used
https://pharo.fogbugz.com/f/cases/17459

http://files.pharo.org/image/50/50559.zip

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

[Esteban Lorenzano]

Cobrale! Cobrale! ;)

> On 29 Jan 2016, at 18:28, Mariano Martinez Peck  wrote:
> 
> BTW, Esteban Maringolo asked me if the Travis scripts were "sharable". Well, 
> Esteban Lorenzano shared them with me and I improved them a bit for my needs, 
> so of course they are shareable!  And all my projects listed as MIT, they are 
> all MIT all the way down.
> 
> Cheers,
> 
>> On Fri, Jan 29, 2016 at 3:36 AM, Sven Van Caekenberghe  wrote:
>> Nice !
>> 
>> > On 29 Jan 2016, at 01:03, Mariano Martinez Peck  
>> > wrote:
>> >
>> > Hi guys,
>> >
>> > This is just to let you know that with the help of Esteban and between 
>> > some work together [1] [2] I was able to have Travis CI integrated with 
>> > OSSubprocess and FFICHeaderExtractor [3] [4] . Both projects are built and 
>> > tested under Linux and OSX. Note also that one of the projects does a lot 
>> > of FFI calls to system libs like libc and the other even generates C 
>> > programs, compiles them and run it. Even the OS dependencies (like 
>> > installing the compiler) are resolved correctly :)
>> >
>> > If someone wants to know how it's done, simply check the .travis.yml and 
>> > the scripts/run-test.sh of each project [5] [6].
>> >
>> > [1] https://pharo.fogbugz.com/f/cases/17488
>> > [2] https://pharo.fogbugz.com/f/cases/17490
>> > [3] https://travis-ci.org/marianopeck/OSSubprocess
>> > [4] https://travis-ci.org/marianopeck/FFICHeaderExtractor
>> > [5] https://github.com/marianopeck/OSSubprocess
>> > [6] https://github.com/marianopeck/FFICHeaderExtractor
>> >
>> >
>> > Cheers,
>> >
>> >
>> > --
>> > Mariano
>> > http://marianopeck.wordpress.com
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

Re: [Pharo-dev] Contributing to Pharo

[Bernhard Pieber]

Hi Dale,

I am trying to understand this a little better. If a package containing 
metadata would be changed using a dialect which cannot interpret the metadata, 
wouldn’t or at least couldn’t it be broken or lost afterwards for a dialect 
which tries to interpret the metadata? At least if my assumption is correct 
that the metadata is related to the code in some way?

Bernhard

> Am 28.01.2016 um 21:28 schrieb Dale Henrichs 
> :
> On 01/28/2016 12:55 AM, Christophe Demarey wrote:
>> Le 28 janv. 2016 à 09:34, Sven Van Caekenberghe a écrit :
>> By the way, we can add the storage format: there are already different 
>> versions of the filetree format (with metadata, without, one file per 
>> method, one file per class). At some point, we need to handle this point of 
>> variability.
> On this point I think that we will always want to support multiple disk 
> formats  in a perfect world, there is no reason not to have one file per 
> method and no Monticello meta data ... but perfection does not exist.
> 
> Monticello meta data was included in FileTree because it was needed over the 
> last 4 years so that developers could dip there toes into using git without 
> completely abandoning Monticello  Now that we are gaining a critical mass 
> of users and the tool support is starting to show up, dropping the meta data 
> is a practical thing to do ... but there is code committed on github that 
> hasn't been updated in years that is still being used and Monticello meta 
> data is still present, so it is necessary to "support the older formats".
> 
> The one file per method was chosen for two reasons.
> 
> The first reason has to do with the fact that disk based SCMs are designed 
> manage files as atomic units and in Smalltalk the method is the atomic unit 
> for source code ... it is very convenient to be able to leverage native SCN 
> files for a) versioning files and b) maintaining version history for a method 
> as it moves from class to class ...
> 
> The second reason has to do with the fact that there is no cross platform 
> fileout format for Smalltalk. Chunk format comes is "common" but chunk format 
> also relies on executing Smalltalk code to define classes and there hasn't 
> been a standard class creation method since the second Smalltalk 
> implementation showed up on the planet ... Technically, class and method 
> definitions can be derived from a file per class approach, but without a 
> standardized file format you end up with each dialect isolating itself from 
> the others and this is not desirable nor necessary ... It just takes more 
> work to come up with a file format that can accommodate the different needs 
> of the different dialects  the one method per file and a generic 
> properties file for class definitions[1] and the provision for allowing 
> additional platform specific property files and directories (like monticello 
> meta data) simplified the whole process ...
> 
> So I would like changing the disk format for sharing source code to be a 
> multi-platform effort - which means that format that is chosen is flexible 
> enough to allow dialects to include the meta data that they need ... It is 
> important to note that there has never been a guarantees that all platforms 
> would PRESERVE and WRITE foreign meta data ... the only provision that exists 
> is that ALL platforms can READ the format while ignoring anything it doesn't 
> recognize 
> 
> Dale
> 
> [1] 
> https://raw.githubusercontent.com/CampSmalltalk/Cypress/master/img/CypressStructure-STIC2012.png

Re: [Pharo-dev] Contributing to Pharo

[Eliot Miranda]

Hi David,

> On Jan 29, 2016, at 2:45 PM, David Allouche  wrote:
> 
> Thanks Dale for all the explanations.
> 
> How Monticello and version control relate in the big picture is starting to 
> make sense for me.
> 
> Now, I better understand why filetree ended up uses a file-per-method format, 
> even though that is relatively hostile to git user interfaces optimised for 
> other languages. There is really a need for a file-per-class exchange format, 
> because that would works a lot better with the existing VCS ecosystem.

I agree so strongly.  Class file outs which are eg sorted by selector make much 
more sense.  They won't hit the file name length limit.  They make it trivial 
to maintain method and class comment time stamps.  They're easier to construct 
into snapshots because it's easier to decode the file name.

And then it's easy to add files for package load/unload scripts and for the 
history.  And then one is much more decoupled from the specific back end.  It 
could be mercurial just as easily as git.

> I think more package-based user interfaces would indeed be a very good idea, 
> for browsing and for source code management.
> 
> Stef, I have the impression you think that git is popular because it is a new 
> shiny toy. I disagree with this idea. Git is a typical worse-is-better tool. 
> It's good enough for most people, but it still has many shortcomings. It is 
> popular in spite of its shortcomings. It became popular as destination for 
> projects shifting from CVS and Subversion. So it is unlikely to be displaced 
> by a newer, incrementally shinier tools. Anything that will displace it will 
> have to provide an improvement of a similar magnitude as the jump between 
> centralised and distributed version control.

This is a good analysis.  What's valuable to the Pharo community is not 
displacing an already functional dvcs (Monticello) with an ill-suited one 
(git), but in being able to function in ecosystems like github where people can 
display their identity and where infrastructure for bug reports etc exist.

> Still, I think it's a good idea not to restrict high level models to what git 
> provides if that's a less than ideal fit to the image model.

Absolutely.  Dale's talk of ditching Monticello metadata fills me with 
repulsion and makes me want to ask is he trying to sabotage or what?  It seems 
entirely destructive.  We have a functional package manager which currently 
supports interchange between Pharo, Squeak and Cuis, something that I think is 
very important and valuable.  We should have the confidence to improve on it 
and work on exchanging improvements between the dialects.  For example Bert 
Freudenburg recently extended the commit dialog with the ability to mark 
changes to ignore, which are then /not/ committed, which makes it possible to 
maintain a few of one's favorite image mods without the tedium of reverting 
them (or whatever other Sisyphean means) to commit from ones work image.

> I have a lot of ideas to improve browsing and source code management in 
> Pharo. I can make no promises, but I would like to produce something there.

Good luck in your efforts.


_,,,^..^,,,_ (phone)
Best, Eliot 

Re: [Pharo-dev] Use cases for methods with optional parameters

[Damien Pollet]

On 23 January 2016 at 16:12, stepharo  wrote:

> If you have
>>mother1 := foo:(bar:zork:fork)
>>mother2 := foo:bar:(zork:bork:)
>>
> I'm not sure that this is allows in the same class. We should check that
> in Python or ruby.
>

In Ruby:

def m(x=42, y=51)
→ calling m(3) gets x=3, y=51 (the given arguments are passed into the
leftmost parameters first)

def m(options)
→ calling m( { x: 3, y: 4 } ) or m( x: 3, y: 4 ) gets options = { x: 3, y:
4 }
So, a dictionary magically created because you passed something that either
was already a dictionary, or used the syntax of dictionary key/value pairs.
If you need default values for known keys, you take a default dictionary
and override its contents using
http://www.rubydoc.info/stdlib/core/Hash%3Aupdate

In Python I think it's more like the first Ruby alternative, except
arguments can be named (so those bypass the left-to-right assignment order)

-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

[Pharo-dev] QualityAssistant feedback

[Ben Coman]

I've just noticed for "Temporary variables not read AND written" that
the offending variable in the temporary variable definition is
highlighted.  Is this new? Its very nice to have this visual
indication.

cheers -ben

Re: [Pharo-dev] Disable assertions (design by contract)

[Richard Sargent]

Eliot Miranda-2 wrote
> Hi Richard,
> 
>> On Jan 28, 2016, at 2:15 PM, Richard Sargent 

> richard.sargent@

>  wrote:
>> 
>> Aliaksei Syrel wrote
>>> Hi
>>> 
>>> Assertions play an important role in design by contract. It is great to
>>> have assertions in Pharo out of box (Object>>#assert:). However in
>>> projects
>>> with many post- and precondition as also class invariants heavy usage of
>>> assertions decreases performance...
>>> 
>>> Would it be possible to have a compiler setting (in setting browser) to
>>> enable/disable assertions and not compile them to bytecode? Compiler
>>> should
>>> ignore the whole assertion statement with removed condition. For
>>> example:
>>> 
 self assert: self hugeInvariant.
>>> 
>>> with disabled assertion hugeInvariant must not be sent.
>>> 
>>> Thanks,
>>> Alex
>> 
>> My concern with this is that this proposal requires certain selectors to
>> become /reserved/. Most SUnit variations that I have seen entail several
>> dozen methods for asserting and denying behaviours, block evaluation
>> versus
>> inline expressions, descriptive explanations, and so on. 
>> 
>> It seems to me that you would be better off sending messages to a global.
>> Instead of:
>>> self assert: self hugeInvariant.
>> have something like:
>>> Assert that: self hugeInvariant.
>> 
>> If the global Assert is bound to a stub the message is sent and ignored.
>> If
>> bound to a real assertion mechanism, it gets evaluated. Use blocks when
>> the
>> argument evaluation is expensive or expensive enough.
>>> Assert evaluationOf: [self hugeInvariant].
>> 
>> None of the names should be taken as suggestions. Just the concept.
> 
> It's a good concept, and is the object-oriented approach.  It's just that
> in practice the costs of creating blocks as assert: arguments, while
> typically much cheaper than evaluating the assert and discarding its
> result, are still significant
> 
> Hence I'm open to a compiler hack that elides the assert: or deny: and
> it's send altogether from the code.  Open but not happy; it's something I
> hold my nose to do.  But this is a style I've been using for twenty odd
> years and it is really nice to be able to write assert-laden code but not
> have to pay in production.

Thanks for the feedback, Eliot. It's appreciated.

If we have to hack, I would rather see the hack done differently. One of my
goals would be the ability to restore a production database into a test
environment without having to recompile all the methods. (Some of our
customers have systems with 30-40,000 classes!)

To that end, I was wondering about hacking the compiler to test the
association with the reference I've named Assert (but probably in a general
approach for any name). The code generator would send a specific message to
the currently bound value (one would require it to be implemented by all
objects bound to the name, just for honesty and clarity), to ask whether the
code generator should emit code to test the named receiver and skip the
whole statement if it answers true. The code would be generated in all
cases, but it would not be evaluated when the stub mechanism is associated
with Assert, since it would answer true to the skip question. Likewise, the
real assertion mechanism would answer false and the whole statement would be
evaluated.

That preceding paragraph glosses over a lot, but I hope the gist is
sufficiently clear.



> There is a ray of hope.  The Sista adaptive optimiser /will/ be able to
> elide all the cost of the block form:
> 
> ...
> self assert: [self expr].
> ...
> 
> Foo methods for assertions
> assert: aBlockOrBoolean
>^self
> 
> because there are obviously no side effects.  Whereas it will only be able
> to elide the entire thing depending on expr in the non-block form:
> 
> ...
> self assert: self expr.
> ...
> 
> But I wonder how any people would have the discipline or insight to use
> the block form.  It looks unnecessarily verbose yes?
> 
>> This also offers the benefit that assertions are practical everywhere,
>> not
>> just under a TestCase hierarchy.
> 
> Whether asserts are practicable everywhere IME depend on how useful they
> are in ongoing development.  The fact that they cost a /lot/ and slow down
> the VM simulator for Cog doesn't change the fact that it would be much
> much slower to modify the code base.
> 
> In another thread I was proposing to Gulle to use the VM simulator instead
> of a custom VM for his Pharo bootstrap.  But in that case one would /have/
> to find a way of eliding asserts.  One approach would be a package-level
> rewrite tool that could produce a copy of a package in which asserts have
> been eliminated.  One would always do development in the assert-laden
> version, but could make the assert-less version available to clients who
> treat the package as a black box, can therefore assume that no asserts
> ever fail (because the asserts prove they don't) and use as
> high-performance a version of the 

Re: [Pharo-dev] Contributing to Pharo

[David Allouche]

Thanks Dale for all the explanations.

How Monticello and version control relate in the big picture is starting to 
make sense for me.

Now, I better understand why filetree ended up uses a file-per-method format, 
even though that is relatively hostile to git user interfaces optimised for 
other languages. There is really a need for a file-per-class exchange format, 
because that would works a lot better with the existing VCS ecosystem.

I think more package-based user interfaces would indeed be a very good idea, 
for browsing and for source code management.

Stef, I have the impression you think that git is popular because it is a new 
shiny toy. I disagree with this idea. Git is a typical worse-is-better tool. 
It's good enough for most people, but it still has many shortcomings. It is 
popular in spite of its shortcomings. It became popular as destination for 
projects shifting from CVS and Subversion. So it is unlikely to be displaced by 
a newer, incrementally shinier tools. Anything that will displace it will have 
to provide an improvement of a similar magnitude as the jump between 
centralised and distributed version control.

Still, I think it's a good idea not to restrict high level models to what git 
provides if that's a less than ideal fit to the image model.

I have a lot of ideas to improve browsing and source code management in Pharo. 
I can make no promises, but I would like to produce something there.

Re: [Pharo-dev] Disable assertions (design by contract)

[Ben Coman]

On Sat, Jan 30, 2016 at 9:34 AM, Richard Sargent
 wrote:
> To that end, I was wondering about hacking the compiler to test the
> association with the reference I've named Assert (but probably in a general
> approach for any name). The code generator would send a specific message to
> the currently bound value (one would require it to be implemented by all
> objects bound to the name, just for honesty and clarity), to ask whether the
> code generator should emit code to test the named receiver and skip the
> whole statement if it answers true. The code would be generated in all
> cases, but it would not be evaluated when the stub mechanism is associated
> with Assert, since it would answer true to the skip question. Likewise, the
> real assertion mechanism would answer false and the whole statement would be
> evaluated.

I wonder (in ignorance) if MetaLinks could be applied here?
cheers -ben

[Pharo-dev] GTDebugger feedback - Setup/TearDown tabs for test cases

[Ben Coman]

I really like the SetUp/TearDown tabs when debugging a failed test,
however it seems a waste to devote a whole half of window to them
causing lines in the Source tab to wrap unnecessarily.  Could they be
moved adjacent to the Source tab?  I guess the Browse button would
equally apply to #setUp and #tearDown methods.

Also, you can edit the SetUp code but changes don't seem to be saved
through. So can this either be fixed (including when the method
doesn't exist) or there be some hint it can't be saved:
* tab says [SetUp (read-only)]
* in an fake comment above its code put "This method is read only"
(maybe in light grey)
* Instead of the yellow/orange "modified" triangle appearing in the
top-right of the pane, make it another colour - maybe black to mean
you can't save - I think red is reserved for meaning the pane was
edited elsewhere?

cheers -ben

P.S. I'd like to add my voice to those commenting that the stepping
buttons are too far away.  Glancing back and forth between them and
the code I feel like I'm watching a tennis game.

P.P.S The icons on those buttons are real nice.

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

[serge . stinckwich]

For building Pharo, Squeak or GemStone projects on travis there is also the 
SmalltalkCI project: 
https://github.com/hpi-swa/smalltalkCI/blob/master/README.md

Smalltalk language is supported by travis ;-)

Sent from my iPhone

> On 29 janv. 2016, at 18:28, Mariano Martinez Peck  
> wrote:
> 
> BTW, Esteban Maringolo asked me if the Travis scripts were "sharable". Well, 
> Esteban Lorenzano shared them with me and I improved them a bit for my needs, 
> so of course they are shareable!  And all my projects listed as MIT, they are 
> all MIT all the way down.
> 
> Cheers,
> 
>> On Fri, Jan 29, 2016 at 3:36 AM, Sven Van Caekenberghe  wrote:
>> Nice !
>> 
>> > On 29 Jan 2016, at 01:03, Mariano Martinez Peck  
>> > wrote:
>> >
>> > Hi guys,
>> >
>> > This is just to let you know that with the help of Esteban and between 
>> > some work together [1] [2] I was able to have Travis CI integrated with 
>> > OSSubprocess and FFICHeaderExtractor [3] [4] . Both projects are built and 
>> > tested under Linux and OSX. Note also that one of the projects does a lot 
>> > of FFI calls to system libs like libc and the other even generates C 
>> > programs, compiles them and run it. Even the OS dependencies (like 
>> > installing the compiler) are resolved correctly :)
>> >
>> > If someone wants to know how it's done, simply check the .travis.yml and 
>> > the scripts/run-test.sh of each project [5] [6].
>> >
>> > [1] https://pharo.fogbugz.com/f/cases/17488
>> > [2] https://pharo.fogbugz.com/f/cases/17490
>> > [3] https://travis-ci.org/marianopeck/OSSubprocess
>> > [4] https://travis-ci.org/marianopeck/FFICHeaderExtractor
>> > [5] https://github.com/marianopeck/OSSubprocess
>> > [6] https://github.com/marianopeck/FFICHeaderExtractor
>> >
>> >
>> > Cheers,
>> >
>> >
>> > --
>> > Mariano
>> > http://marianopeck.wordpress.com
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

Re: [Pharo-dev] [pharo-project/pharo-core] 075ec6: 50550

[Cyril Ferlicot Delbecque]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 27/01/2016 16:07, GitHub wrote:
> Branch: refs/heads/5.0 Home:
> https://github.com/pharo-project/pharo-core Commit:
> 075ec66df6ea08e7be71d5275b08ca095432aa2b 
> https://github.com/pharo-project/pharo-core/commit/075ec66df6ea08e7be7
1d5275b08ca095432aa2b
>
> 
Author: Jenkins Build Server 
> Date:   2016-01-27 (Wed, 27 Jan 2016)
> 
> Changed paths: M Alien.package/Alien.class/class/class
> initialization/ensureInSpecialObjectsArray.st M
> Alien.package/Alien.class/class/class initialization/initialize.st 
> M Alien.package/Alien.class/class/examples/libcName.st M
> Alien.package/Alien.class/class/instance creation/atAddress_.st M
> Alien.package/Alien.class/class/instance
> creation/atAddress_dataSize_.st M
> Alien.package/Alien.class/class/instance creation/forPointer_.st M
> Alien.package/Alien.class/class/instance creation/newC_.st M
> Alien.package/Alien.class/class/instance creation/newGC_.st M
> Alien.package/Alien.class/class/instance creation/new_.st M
> Alien.package/Alien.class/class/instance creation/rawNewC_.st M
> Alien.package/Alien.class/class/system startup/startUp_.st M
> Alien.package/Alien.class/definition.st R
> Alien.package/Alien.class/instance/as yet
> unclassified/isPointer.st M
> Alien.package/Alien.class/instance/printing/storeOn_.st A
> Alien.package/Alien.class/instance/testing/isPointer.st M
> Alien.package/AlienSunit.class/instance/testing/testLongLong.st R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/README.md R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/accessing/pr
oject.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/catalog/catalo
gContactInfo.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/catalog/cata
logDescription.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/catalog/catalo
gKeywords.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/loading/load
.st
>
> 
R ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/metacello
tool support/isMetacelloConfig.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/metacello
> tool support/lastMetacelloVersionLoad.st R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/metacello
> tool support/metacelloVersion_loads_.st R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/private/boot
strapPackage_from_.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/class/private/ensure
Metacello.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/definition.st R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/accessing
/project.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/baselines/b
aseline10_.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/baselines
/baseline12_.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/baselines/b
aseline13_.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/baselines
/baseline14_.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/baselines/b
aseline15_.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/doits/ffi
ExampleInitialization10.st
>
> 
R ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/symbolic
versions/development_.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/symbolic
> versions/stable_.st R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/
version1%5F10%5F1_.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve
rsion1%5F10_.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/
version1%5F9%5F1_.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve
rsion10_.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/
version11_.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve
rsion12_.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/
version13_.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve
rsion14_.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/
version15_.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve
rsion16_.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/
version17_.st
>
> 
R
ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/ve
rsion18_.st
> R
> ConfigurationOfFFI.package/ConfigurationOfFFI.class/instance/versions/
version19_.st
>
> 
R ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/README.m
d
> R
> ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/ac
cessing/project.st
>
> 
R
ConfigurationOfOldAlien.package/ConfigurationOfOldAlien.class/class/cata
log/catalogContactInfo.st
> R
>