[Pharo-dev] get.pharo.org/travis+vm failing: Package 'pharo-vm-core:i386' has no installation candidate

[Dale Henrichs]

It looks like the following script started failing within the last 5 
days sometime:


   wget --quiet -O - get.pharo.org/travis+vm | bash

getting this error (on ubunutu12.04):

Fetched 18.5 kB in 4s (4,028 B/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package pharo-vm-core:i386 is not available, but is referred to by 
another package.

This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'pharo-vm-core:i386' has no installation candidate


5 days ago this is what the same log section looked like[1]:

Fetched 15.6 kB in 1s (9,597 B/s)

Reading package lists... Done

Reading package lists... Done

Building dependency tree

Reading state information... Done

The following package was automatically installed and is no longer required:

libgeos-3.2.2

Use 'apt-get autoremove' to remove them.

Suggested packages:

pharo-vm-desktop:i386

The following NEW packages will be installed:

pharo-vm-core:i386

0 upgraded, 1 newly installed, 0 to remove and 174 not upgraded.

Need to get 14.5 MB of archives.


Then 2 days ago, the above error started happening[2]:

Fetched 18.5 kB in 4s (4,214 B/s)

Reading package lists... Done

Reading package lists... Done

Building dependency tree

Reading state information... Done

Package pharo-vm-core:i386 is not available, but is referred to by 
another package.


This may mean that the package is missing, has been obsoleted, or

is only available from another source

E: Package 'pharo-vm-core:i386' has no installation candidate


Presumably something change in the last week to break thingspretty 
much depend upon this working to do much of my testing on travis-ci:(


Dale

[1] https://travis-ci.org/dalehenrich/tode/jobs/49400710
[2] https://travis-ci.org/dalehenrich/tode/jobs/49776435

Re: [Pharo-dev] ||

[Hernán Morales Durand]

2015-02-08 19:46 GMT-03:00 Eliot Miranda :

>
>
> On Sun, Feb 8, 2015 at 1:26 PM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
>> Hi Eliot,
>>
>> 2015-02-08 12:50 GMT-03:00 Eliot Miranda :
>>
>>> Hi Hernan,
>>>
>>>
>>> On Feb 7, 2015, at 12:55 PM, Hernán Morales Durand <
>>> hernan.mora...@gmail.com> wrote:
>>>
>>> Hi Eliot,
>>>
>>> 2015-02-07 14:48 GMT-03:00 Eliot Miranda :
>>>
 Hi Hernan,

 On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand <
 hernan.mora...@gmail.com> wrote:

>
> 2015-02-07 5:59 GMT-03:00 kilon alios :
>
>> Personally I don't like Pragmas, they have not convinced me so far
>> that they fit the style of Smalltalk syntax. I have to confess though I
>> never liked descriptive elements and languages .
>>
>>
> Me neither. Actually the pragma idea is not wrong per se, it is the
> tag syntax to write them which bothers me. Because the world can be
> described with tags if you start that path.
>

 How exactly is the syntax wrong?

>>>
>>> I am not saying syntax is wrong, I just don't like it because:
>>>
>>> 1) Adds another level of representation inside an already reflective
>>> system.
>>>
>>>
>>> What do you mean exactly?  I don't have clear recollection of whether
>>> they were in Squeak in 08 or if I ported then, but at that time
>>> CompiledMethod had a properties object, and pragmas were merged into this.
>>> What I did do was save a lot of space getting rid if the properties object
>>> unless a method needed it.  And IIRC I changed the implementing class from
>>> MethodProperties to AdditionalMethodState.  So there was no additional
>>> level of representation.  a) the syntax was already there fir primitives
>>> and b) the state was already there in methods.
>>>
>>>
>> The place where pragmas are located internally are not an issue for me.
>> The fact that special tags are not following the message pattern template
>> is. It says there is a special collector, parser, validator, etc. a whole
>> mechanism because something is - supposedly - not easily expressible with
>> plain reflective messages.
>>
>
> I don't understand.  Pragmas are literal message patterns, period.  There
> is an exception for the primitive pragma so that the variable name for a
> primitive's error code can be introduced, but that's part of primitive
> parsing, not general pragma parsing.  At least in Squeak here's the code:
>
> Parser>>pragmaSequence
> "Parse a sequence of method pragmas."
>  [
> (self matchToken: #<)
> ifFalse: [ ^ self ].
> self pragmaStatement.
> (self matchToken: #>)
> ifFalse: [ ^ self expected: '>' ] ] repeat
>
> pragmaStatement
> "Read a single pragma statement. Parse all generic pragmas in the form of:
>  and remember them, including primitives."
>  | selector arguments words index keyword |
> (hereType = #keyword or: [ hereType = #word or: [ hereType = #binary ] ])
> ifFalse: [  ^ self expected: 'pragma declaration' ].
>
> " This is a ugly hack into the compiler of the FFI package. FFI should be
> changed to use propre pragmas that can be parsed with the code here. "
> (here = #apicall: or: [ here = #cdecl: ])
> ifTrue: [ ^ self externalFunctionDeclaration ].
>
> selector := String new.
> arguments := OrderedCollection new.
> words := OrderedCollection new.
> [ hereType = #keyword or: [ (hereType = #word or: [ hereType = #binary ])
> and: [ selector isEmpty ] ] ] whileTrue: [
> index := self startOfNextToken + requestorOffset.
> selector := selector , self advance.
> words add: (index to: self endOfLastToken + requestorOffset).
> (selector last = $: or: [ selector first isLetter not ])
> ifTrue: [ arguments add: (self pragmaLiteral: selector) ] ].
> selector numArgs ~= arguments size
> ifTrue: [ ^ self expected: 'pragma argument' ].
> (Symbol hasInterned: selector
> ifTrue: [ :value | keyword := value])
> ifFalse: [
> keyword := self
> correctSelector: selector wordIntervals: words
> exprInterval: (words first first to: words last last)
> ifAbort: [ ^ self fail ] ].
> self addPragma: (Pragma keyword: keyword arguments: arguments asArray).
> ^ true
>
> I can't speak for how its been implemented in Opal but I'd be surprised if
> it is using separate machinery.  The Squeak code above is different from
> the normal message parsing precisely so that it can insist that arguments
> are only literals (pragmaLiteral: above).
>
>
Ok, I will stop here because I see contradictions and no way we can agree
on them.
Amazing code BTW.



>
>> 2) It could be done with plain common message sends.
>>>
>>>
>>> No it can't. Common sends are executable and we don't want pragmas
>>> executed when the method is run, we want the pragma executed when the
>>> method is added, or analysed. That was what was ugly about the use of plain
>>> sends in e.f. VMMaker, that there had to be lots of empty implementations
>>> of the messages used for metadata.
>>>
>>
>>> So using normal sends
>>> - prevents the metadata from being 

Re: [Pharo-dev] ||

[Nicolai Hess]

2015-02-08 22:26 GMT+01:00 Hernán Morales Durand :

>
> It could be broken because I pressed Alt+M in  and
> nothing happens:
>
> gtInspectorActionBrowse
> 
> ^ GLMGenericAction new
> action: [ self browse ];
> icon: GLMUIThemeExtraIcons glamorousBrowse;
> title: 'Browse'
>

selecting the word gtInspectorAction and pressing Alt+n works, it
opens the "Senders or Users" MessageBrowser.

Re: [Pharo-dev] ||

[Eliot Miranda]

On Sun, Feb 8, 2015 at 1:26 PM, Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

> Hi Eliot,
>
> 2015-02-08 12:50 GMT-03:00 Eliot Miranda :
>
>> Hi Hernan,
>>
>>
>> On Feb 7, 2015, at 12:55 PM, Hernán Morales Durand <
>> hernan.mora...@gmail.com> wrote:
>>
>> Hi Eliot,
>>
>> 2015-02-07 14:48 GMT-03:00 Eliot Miranda :
>>
>>> Hi Hernan,
>>>
>>> On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand <
>>> hernan.mora...@gmail.com> wrote:
>>>

 2015-02-07 5:59 GMT-03:00 kilon alios :

> Personally I don't like Pragmas, they have not convinced me so far
> that they fit the style of Smalltalk syntax. I have to confess though I
> never liked descriptive elements and languages .
>
>
 Me neither. Actually the pragma idea is not wrong per se, it is the tag
 syntax to write them which bothers me. Because the world can be described
 with tags if you start that path.

>>>
>>> How exactly is the syntax wrong?
>>>
>>
>> I am not saying syntax is wrong, I just don't like it because:
>>
>> 1) Adds another level of representation inside an already reflective
>> system.
>>
>>
>> What do you mean exactly?  I don't have clear recollection of whether
>> they were in Squeak in 08 or if I ported then, but at that time
>> CompiledMethod had a properties object, and pragmas were merged into this.
>> What I did do was save a lot of space getting rid if the properties object
>> unless a method needed it.  And IIRC I changed the implementing class from
>> MethodProperties to AdditionalMethodState.  So there was no additional
>> level of representation.  a) the syntax was already there fir primitives
>> and b) the state was already there in methods.
>>
>>
> The place where pragmas are located internally are not an issue for me.
> The fact that special tags are not following the message pattern template
> is. It says there is a special collector, parser, validator, etc. a whole
> mechanism because something is - supposedly - not easily expressible with
> plain reflective messages.
>

I don't understand.  Pragmas are literal message patterns, period.  There
is an exception for the primitive pragma so that the variable name for a
primitive's error code can be introduced, but that's part of primitive
parsing, not general pragma parsing.  At least in Squeak here's the code:

Parser>>pragmaSequence
"Parse a sequence of method pragmas."
 [
(self matchToken: #<)
ifFalse: [ ^ self ].
self pragmaStatement.
(self matchToken: #>)
ifFalse: [ ^ self expected: '>' ] ] repeat

pragmaStatement
"Read a single pragma statement. Parse all generic pragmas in the form of:
 and remember them, including primitives."
 | selector arguments words index keyword |
(hereType = #keyword or: [ hereType = #word or: [ hereType = #binary ] ])
ifFalse: [  ^ self expected: 'pragma declaration' ].

" This is a ugly hack into the compiler of the FFI package. FFI should be
changed to use propre pragmas that can be parsed with the code here. "
(here = #apicall: or: [ here = #cdecl: ])
ifTrue: [ ^ self externalFunctionDeclaration ].

selector := String new.
arguments := OrderedCollection new.
words := OrderedCollection new.
[ hereType = #keyword or: [ (hereType = #word or: [ hereType = #binary ])
and: [ selector isEmpty ] ] ] whileTrue: [
index := self startOfNextToken + requestorOffset.
selector := selector , self advance.
words add: (index to: self endOfLastToken + requestorOffset).
(selector last = $: or: [ selector first isLetter not ])
ifTrue: [ arguments add: (self pragmaLiteral: selector) ] ].
selector numArgs ~= arguments size
ifTrue: [ ^ self expected: 'pragma argument' ].
(Symbol hasInterned: selector
ifTrue: [ :value | keyword := value])
ifFalse: [
keyword := self
correctSelector: selector wordIntervals: words
exprInterval: (words first first to: words last last)
ifAbort: [ ^ self fail ] ].
self addPragma: (Pragma keyword: keyword arguments: arguments asArray).
^ true

I can't speak for how its been implemented in Opal but I'd be surprised if
it is using separate machinery.  The Squeak code above is different from
the normal message parsing precisely so that it can insist that arguments
are only literals (pragmaLiteral: above).


> 2) It could be done with plain common message sends.
>>
>>
>> No it can't. Common sends are executable and we don't want pragmas
>> executed when the method is run, we want the pragma executed when the
>> method is added, or analysed. That was what was ugly about the use of plain
>> sends in e.f. VMMaker, that there had to be lots of empty implementations
>> of the messages used for metadata.
>>
>
>> So using normal sends
>> - prevents the metadata from being directly executed because executing
>> them when the method is run is wrong
>> - confuses meta level and normal level, putting them at the same level,
>> and hence...
>> - confusing for the programmer because its not obvious what's metadata
>> and what's a normal send
>> - makes analysis harder for the same reason
>>
>>
> We are

Re: [Pharo-dev] ||

[Hernán Morales Durand]

Hi Eliot,

2015-02-08 12:50 GMT-03:00 Eliot Miranda :

> Hi Hernan,
>
>
> On Feb 7, 2015, at 12:55 PM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
> Hi Eliot,
>
> 2015-02-07 14:48 GMT-03:00 Eliot Miranda :
>
>> Hi Hernan,
>>
>> On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand <
>> hernan.mora...@gmail.com> wrote:
>>
>>>
>>> 2015-02-07 5:59 GMT-03:00 kilon alios :
>>>
 Personally I don't like Pragmas, they have not convinced me so far that
 they fit the style of Smalltalk syntax. I have to confess though I never
 liked descriptive elements and languages .


>>> Me neither. Actually the pragma idea is not wrong per se, it is the tag
>>> syntax to write them which bothers me. Because the world can be described
>>> with tags if you start that path.
>>>
>>
>> How exactly is the syntax wrong?
>>
>
> I am not saying syntax is wrong, I just don't like it because:
>
> 1) Adds another level of representation inside an already reflective
> system.
>
>
> What do you mean exactly?  I don't have clear recollection of whether they
> were in Squeak in 08 or if I ported then, but at that time CompiledMethod
> had a properties object, and pragmas were merged into this.  What I did do
> was save a lot of space getting rid if the properties object unless a
> method needed it.  And IIRC I changed the implementing class from
> MethodProperties to AdditionalMethodState.  So there was no additional
> level of representation.  a) the syntax was already there fir primitives
> and b) the state was already there in methods.
>
>
The place where pragmas are located internally are not an issue for me. The
fact that special tags are not following the message pattern template is.
It says there is a special collector, parser, validator, etc. a whole
mechanism because something is - supposedly - not easily expressible with
plain reflective messages.

2) It could be done with plain common message sends.
>
>
> No it can't. Common sends are executable and we don't want pragmas
> executed when the method is run, we want the pragma executed when the
> method is added, or analysed. That was what was ugly about the use of plain
> sends in e.f. VMMaker, that there had to be lots of empty implementations
> of the messages used for metadata.
>

> So using normal sends
> - prevents the metadata from being directly executed because executing
> them when the method is run is wrong
> - confuses meta level and normal level, putting them at the same level,
> and hence...
> - confusing for the programmer because its not obvious what's metadata and
> what's a normal send
> - makes analysis harder for the same reason
>
>
We are talking about different worlds here.
Theoretically I could mark methods this way:

(Pragma
for: (ASTBlockClosure >> #value:)
selector: #primitive:
arguments: (Array with: 60)) addPragma.

So the annotations could be written with normal message sends.
And they could be tool supported, so no one gets confused.


> 3) Should be (to me) "hidden" from method pane, and displayed by a
> specific tool inside the system browser.
>
>
> I disagree.  I want to see the pragma.  It has essential information that
> shouldn't be hidden.  I want to edit it easily.
>

I want to see and edit the pragma too, when I am really interested. Just
like with the bytecodes.


> And how can you in the one hand say it can be implemented as a normal
> message send a d at the same time want it hidden?  Be consistent :-)
>
>
There is no inconsistency. I am saying they should be hidden from the
method body.

The method pane you see in the browser should be used to send messages to
your modeling domain (which already imposes its own difficulty), not being
exploited to add meta information where meta could belong to
instrumentation analysis (lint, profiling) or UI building (keymap, menu) or
whatever excuse found to add more tags.

I wonder how one could refactor this method:

Greetings>>helloWorld






















^'Hello World'



>
>> The  syntax predates pragmas.  It was used first
>> for numeric primitives in Smalltalk-76 or Smalltalk-80.  Squeak extended it
>> with primitive:module:.  I and others extended it to include arbitrary
>> literal message patterns.  The syntax of a literal message pattern is the
>> syntax of a send with no receiver and only literal arguments.
>>
> The use of this syntax means
>> a) no new syntax
>> b) each pragma is potentially executable
>> c) methods using specific pragmas can be found using "find senders"
>> d) the execution side of a pragma can be found using "find implementors"
>>
>> So what's wrong with that?  How is it wrong to use a common Smalltalk
>> object, a Message, that is well-supported in the system, for method
>> metadata?
>>
>>
> I get that pragmas are messages, but they assume an implicit receiver,
> which actually depends on context. If I understood right with pragmas
> always receiver = des

[Pharo-dev] [pharo-project/pharo-core] fa4a01: 40483

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: fa4a01127f4608de39c1610370e5374c2421b469
  
https://github.com/pharo-project/pharo-core/commit/fa4a01127f4608de39c1610370e5374c2421b469
  Author: Jenkins Build Server 
  Date:   2015-02-08 (Sun, 08 Feb 2015)

  Changed paths:
M Kernel.package/Date.class/instance/deprecated/leap.st
A Kernel.package/Date.class/instance/testing/isLeapYear.st
M KernelTests.package/DateTest.class/instance/tests/testAccessing.st
M KernelTests.package/DateTest.class/instance/tests/testLeap.st
M 
Manifest-CriticBrowser.package/SelectRuleBrowser.class/instance/initialization/initialize.st
M 
Manifest-CriticBrowser.package/SelectRuleBrowser.class/instance/protocol/removeItems.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script483.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40483.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
R 
System-Support.package/SmalltalkImage.class/instance/printing/printElementsOn_.st
M 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/defaults/defaultAvailableRepositories.st
M 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/accessing/repository_.st
A 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/defineAllRepositoriesInMCBrowser.st
A 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/defineRepositoryInMCBrowser.st
A 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/repositoryObjectFromURLString_.st
M 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/menu/configurationListMenu_.st
A 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/private/explicitTitleFromURLString_.st
M 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/instance/initialization/initializeWidgets.st
M 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/instance/initialization/installModel.st
M 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/instance/initialization/loadModel.st

  Log Message:
  ---
  40483
14879 CodeCritics does not allow to remove a critic when selecting the critics 
to be run
https://pharo.fogbugz.com/f/cases/14879

14884 Add a menu to define the metaRepository as repository in MCBrowser
https://pharo.fogbugz.com/f/cases/14884

14871 Date >> leap answer 1 or 0 and we want true or false
https://pharo.fogbugz.com/f/cases/14871

14887 SmalltalkImage>>printOnElements: is dead code
https://pharo.fogbugz.com/f/cases/14887

http://files.pharo.org/image/40/40483.zip

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

[GitHub]

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

Re: [Pharo-dev] ||

[kilon alios]

"I disagree.  I want to see the pragma.  It has essential information that
shouldn't be hidden.  I want to edit it easily.  And how can you in the one
hand say it can be implemented as a normal message send a d at the same
time want it hidden?  Be consistent :-)"

I agree with you Eliot, I definitely would not want for pragmas to be
hidden. They are an important part of the code they should be visible with
the rest of the code. It would lead to confusion otherwise . Opening 10
tools to be able to view code is also not ideal.

Re: [Pharo-dev] ||

[Eliot Miranda]

Hi Hernan,


On Feb 7, 2015, at 12:55 PM, Hernán Morales Durand  
wrote:

> Hi Eliot,
> 
> 2015-02-07 14:48 GMT-03:00 Eliot Miranda :
>> Hi Hernan,
>> 
>> On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand 
>>  wrote:
>>> 
>>> 2015-02-07 5:59 GMT-03:00 kilon alios :
 Personally I don't like Pragmas, they have not convinced me so far that 
 they fit the style of Smalltalk syntax. I have to confess though I never 
 liked descriptive elements and languages . 
>>> 
>>> Me neither. Actually the pragma idea is not wrong per se, it is the tag 
>>> syntax to write them which bothers me. Because the world can be described 
>>> with tags if you start that path.
>> 
>> How exactly is the syntax wrong?
> 
> I am not saying syntax is wrong, I just don't like it because:
> 
> 1) Adds another level of representation inside an already reflective system.

What do you mean exactly?  I don't have clear recollection of whether they were 
in Squeak in 08 or if I ported then, but at that time CompiledMethod had a 
properties object, and pragmas were merged into this.  What I did do was save a 
lot of space getting rid if the properties object unless a method needed it.  
And IIRC I changed the implementing class from MethodProperties to 
AdditionalMethodState.  So there was no additional level of representation.  a) 
the syntax was already there fir primitives and b) the state was already there 
in methods.

> 2) It could be done with plain common message sends.

No it can't.  Common sends are executable and we don't want pragmas executed 
when the method is run, we want the pragma executed when the method is added, 
or analysed.  That was what was ugly about the use of plain sends in e.f. 
VMMaker, that there had to be lots of empty implementations of the messages 
used for metadata.  

So using normal sends
- prevents the metadata from being directly executed because executing them 
when the method is run is wrong 
- confuses meta level and normal level, putting them at the same level, and 
hence...
- confusing for the programmer because its not obvious what's metadata and 
what's a normal send
- makes analysis harder for the same reason

> 3) Should be (to me) "hidden" from method pane, and displayed by a specific 
> tool inside the system browser.

I disagree.  I want to see the pragma.  It has essential information that 
shouldn't be hidden.  I want to edit it easily.  And how can you in the one 
hand say it can be implemented as a normal message send a d at the same time 
want it hidden?  Be consistent :-)

>  
>> The  syntax predates pragmas.  It was used first for 
>> numeric primitives in Smalltalk-76 or Smalltalk-80.  Squeak extended it with 
>> primitive:module:.  I and others extended it to include arbitrary literal 
>> message patterns.  The syntax of a literal message pattern is the syntax of 
>> a send with no receiver and only literal arguments. 
>> The use of this syntax means
>> a) no new syntax
>> b) each pragma is potentially executable
>> c) methods using specific pragmas can be found using "find senders"
>> d) the execution side of a pragma can be found using "find implementors"
>> 
>> So what's wrong with that?  How is it wrong to use a common Smalltalk 
>> object, a Message, that is well-supported in the system, for method metadata?
> 
> I get that pragmas are messages, but they assume an implicit receiver, which 
> actually depends on context. If I understood right with pragmas always 
> receiver = destination?

Not for pragmas that are just labels.  And what's destination?  In the menu 
building example above the destination"is the menu but the receiver is the menu 
builder.  So I think that what the receiver is depends on usage.

>   If you change things in the communication model (receiver, sender, message, 
> etc.), by removing or adding elements, you have a loss in the message because 
> it gets harder to reconstruct the message send.

I don't understand this.  Can you expand?

> 
> Consider
> 
> 
> | eventRegistration |
> { eventRegistration }.
> self eventRegistration.
> 
> which of them "it sounds like" you cannot infer their purpose?

I don't get the example, because of the confusion of meta layers.


says "this is metadata"

| eventRegistration |

says "this is a bug in the method because the variable isn't used, and eg Opal 
will remove it so it won't be there".

{ eventRegistration }.
I guess you mean { #eventRegistration }.  If so this is the same.  An 
optimizing compiler will delete it.

self eventRegistration.
says "send myself eventRegustration".  Which /isn't/ what's wanted.

So for me only the pragma implies "this method is to be registered with the 
event system".  The middle two say "I am a bug, or syntax error".  The last one 
says "I am a normal send".


> 
> To me the first because you need the context MyClass>>methodName
> and you need to browse the pragma to get its purpose.
> 
> 
>>  
>>> There are other ways to add metadata to methods. Without tagging.
>> 
>> H

Re: [Pharo-dev] Howto create a new configuration?

[Juraj Kubelka]

Hi,8. 2. 2015 v 8:26, Nicolai Hess :2015-02-07 13:17 GMT+01:00 Nicolai Hess :2015-02-06 22:02 GMT+01:00 Juraj Kubelka :I have changed two methods of the configuration:-=-=-stable: spec		spec for: #'pharo2.x' version: '2.1'.	"after some modification in NB made it incompatible with 3.0"	spec for: #'pharo3.x' version: '2.3'.	spec for: #'pharo4.x' version: '2.7’.  “<<== added, maybe instead of pharo4.x could be common"-=-=-development: spec		spec for: #'common' version: '2.3-baseline’. “<<== it is likely not necessary"-=-=-I have changed it, because I think there should be two lines in Versioner: one with development label, second with stable label. Then everything works.Let me know if it helps.JurajThank you Juraj, that works  better, but now, commiting the new configurationshows a bunch of "Critical Issues"Critical Warning missing recommend field...Critcal Warning The name of package x does not match file name x.7Critical Warning No Version specified.Not that easy. Maybe, the ConfigurationOfAthens was only written and updated by hand, does not work with Versionner?I think, for now I will try to change the Configuration by hand without versionner.
There three warnings revealed by: (MetacelloToolBox validateConfiguration: ConfigurationOfAthens). It is easy to fix, well I guess. The one is a misspelling, two are about missing #versionString: and I suppose there should be versionString: #’stable’. It is fixed in ConfigurationOfAthens-JurajKubelka.46.mcz.Then I have created by hand version 2.8. The “strange” think is that development do not point to the latest version. Is the 2.8 supposed to be stable or development version? ConfigurationOfAthens-JurajKubelka.46.mcz contains the 2.8 version as development version.Cheers,Juraj

ConfigurationOfAthens-JurajKubelka.46.mcz
Description: Binary data


ConfigurationOfAthens-JurajKubelka.47.mcz
Description: Binary data

[Pharo-dev] [pharo-project/pharo-core] f2a521: 40482

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: f2a521712cf04c935e25f77fd35c8e7c67ff2390
  
https://github.com/pharo-project/pharo-core/commit/f2a521712cf04c935e25f77fd35c8e7c67ff2390
  Author: Jenkins Build Server 
  Date:   2015-02-08 (Sun, 08 Feb 2015)

  Changed paths:
M Nautilus-Tests.package/PackageTreeNautilusTest.class/README.md
M Nautilus-Tests.package/PackageTreeNautilusTest.class/definition.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/accessing/compiledMethod_.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertMethodWidget.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertPackageMorph_.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertPackageWidget.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertSelectedCompiledMethod.st
M 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/running/tearDown.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/setUp.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testFullBrowseLastValueIsNil.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testFullBrowseLastValueNotNil.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testFullBrowseLastValueNotNil2.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testFullBrowseLastValueNotNilSelectedCategoryIsNil.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testFullBrowseOnClass.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpen.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenLastValueIsNil.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenLastValueNotNil.st
M 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenOnMethod.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenOnMethodLastValueIsNil.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenOnMethodLastValueNotNil.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testPackagePatternString.st
A 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testPackagePatternStringRootPackageTag.st
A Nautilus.package/MethodWidget.class/instance/private/methodsList.st
M 
Nautilus.package/Nautilus.class/class/opening/openOnMethod_inEnvironment_.st
M Nautilus.package/NautilusUI.class/instance/displaying/open.st
M Nautilus.package/PackageTreeNautilusUI.class/definition.st
M Nautilus.package/PackageTreeNautilusUI.class/instance/menus 
behavior/fullBrowse.st
M Nautilus.package/PackageTreeNautilusUI.class/instance/package 
filter/packageSearchUpdate_.st
M Nautilus.package/PackageTreeNautilusUI.class/instance/package 
filter/updatePackages.st
A 
Nautilus.package/PackageTreeWidget.class/instance/updating/updateContentsWithPreviouslyExpanded_.st
A Nautilus.package/PackageWidget.class/instance/private/packagesList.st
A Nautilus.package/extension/RPackage/instance/asNautilusItemPath.st
A Nautilus.package/extension/RPackageTag/instance/asNautilusItemPath.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script482.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40482.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
R 
Slot.package/AbstractLayout.class/instance/printing/printSlotDefinitionOn_.st
R 
Slot.package/LayoutAbstractScope.class/instance/printing/printSlotDefinitionOn_.st
R 
Slot.package/LayoutClassScope.class/instance/printing/printSlotDefinitionOn_.st
R 
Slot.package/LayoutEmptyScope.class/instance/printing/printSlotDefinitionOn_.st
R 
Slot.package/PointerLayout.class/instance/printing/printSlotDefinitionOn_.st

  Log Message:
  ---
  40482
14886 remove #printSlotDefinitionOn:
https://pharo.fogbugz.com/f/cases/14886

14865 Browse full command does not display full class definition
https://pharo.fogbugz.com/f/cases/14865

http://files.pharo.org/image/40/40482.zip

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

[GitHub]

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

Re: [Pharo-dev] development workflow for GTools (GToolkitCore)

[Tudor Girba]

Hi Nicolai,



On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess  wrote:

> 14850  Integrate GTools
> #development
> "From this version onwards the development version should be integrated."
>
> Is this a good idea? Does the #development version always include *all*
> the latest
> changes, because after Andrei opened
> 14866  Integrate GTools
> (which got integrated in 40475)
> I uploaded some changes for issue
> 14608 
> ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to Spotter
> methods
> I set the status to "Fix Review needed",
>
but my changes are integrated in 40475 too!
>

I think that in the current situation, it is actually a good idea. And yes,
the integration does include all latest versions of GT-related packages.

Before changing to development, we required a stable release for the
integration. That implied:
1. creating a stable release and
2. integrating it in the Pharo through a separate issue.

Yet, in GT we all work on the very latest version, and creating a "stable"
release is somewhat artificial given the speed at which things are changing
now. Creating the "stable" version also led to delays between a fix in GT
and an integration in Pharo (sometimes measured in weeks). So, in the case
of GT requiring the stable release did not provide any added value, but it
has the negative consequence of delays.

I am not satisfied with the way external packages are handled.
> 1. if there is not one slice/changeset per issue, it is even less likely
> someone will
> review the changes.
> 2. you don't know who works when on a issue. They are solved in a bulk.
> 3. a new configuration might not only includes bugfixes but new features
> as well.
> 4. often we have unbound globals / undeclared references or other test
> failures.
>
> Can we use the build server for those external projects (like
> GToolkitCore, Athens, TxText),
> and that if a project makes a new configuration, it uses the same
> issue validator for loading and testing that configuration?
>

We already have a GToollkitCore job, but it only runs the GT tests. Perhaps
this is not enough?
https://ci.inria.fr/moose/job/gtoolkitcore/

But, could the Monkey not be able to run all tests before an integration of
the development version?

Cheers,
Doru



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Howto create a new configuration?

[Nicolai Hess]

2015-02-07 13:17 GMT+01:00 Nicolai Hess :

>
>
> 2015-02-06 22:02 GMT+01:00 Juraj Kubelka :
>
>> I have changed two methods of the configuration:
>>
>> -=-=-
>> stable: spec
>> 
>>
>> spec for: #'pharo2.x' version: '2.1'.
>> "after some modification in NB made it incompatible with 3.0"
>> spec for: #'pharo3.x' version: '2.3'.
>> *spec for: #'pharo4.x' version: '2.7’.  “<<== added, maybe instead of
>> pharo4.x could be common"*
>> -=-=-
>> development: spec
>> 
>>
>> spec for: #'common' version: '*2.3-baseline*’. “<<== it is likely not
>> necessary"
>> -=-=-
>>
>> I have changed it, because I think there should be two lines in
>> Versioner: one with development label, second with stable label.
>> Then everything works.
>> Let me know if it helps.
>> Juraj
>>
>
> Thank you Juraj,
> that works  better, but now, commiting the new configuration
> shows a bunch of "Critical Issues"
> Critical Warning missing recommend field...
> Critcal Warning The name of package x does not match file name x.7
> Critical Warning No Version specified.
> 
>
> Not that easy. Maybe, the ConfigurationOfAthens was only written and
> updated by hand, does not work with Versionner?
>
>
>

I think, for now I will try to change the Configuration by hand without
versionner.

Re: [Pharo-dev] Pharo 4 & NeoCSV

[stepharo]

Le 7/2/15 18:48, Sven Van Caekenberghe a écrit :

On 07 Feb 2015, at 17:21, stepharo  wrote:

sven I'm adding a menu to the configuration browser to define the corresponding 
repo in MC because I'm tired to add repo manually.

OK.

I always just load a random small thing to get the repo defined ;-)


:)
I don't and imagine normal people do the same so now the UI is better
Stef



Stef

Le 7/2/15 14:19, Sven Van Caekenberghe a écrit :

Hi Andreas,

I added it.

Sven


On 07 Feb 2015, at 13:59, Andreas Wacknitz  wrote:

I miss the configuration of NeoCSV in the configuration browser of Pharo 4. Is 
there any reason for the lack of it?
NeoJSON is available, though…

Regards
Andreas

Re: [Pharo-dev] [Slots] Invisible Slots

[Marcus Denker]

> On 07 Feb 2015, at 21:11, Eliot Miranda  wrote:
> 
> 
> 
> On Sat, Feb 7, 2015 at 9:35 AM, Marcus Denker  > wrote:
> 
>> On 07 Feb 2015, at 18:29, Marcus Denker > > wrote:
>> 
>> 
>> 
>> On Fri, Feb 6, 2015 at 10:13 PM, stepharo > > wrote:
>> I want relationships for certain modeling purposes
>> What I like is that we should arrive to get a collection of useful slots 
>> with optimal implementation instead all of us reinventing the wheel.
>> 
>> I have started to collect the examples in Slots-Examples (in #481).
>> At the start these are artificial (just testing/showing something), but 
>> slowly we will add useful ones, too.
>> 
>> I started to implement PropertySlot, this uses hidden slots, initialisation 
>> (to set the empty dictionary of the base slot), virtual slots
>> (the proper slots), reflectively changing the class both when adding and 
>> removing (to add the base slot and remove it as needed).
>> 
> and custom byte code generation to read and write with just #at: and #at:put 
> on the base slot…
> 
> and remember that the closure bytecodes can access a field without a bounds 
> check
> 
>   140   10001100  Push Temp At  In Temp 
> Vector At: 
>   141   10001101  Store Temp At  In Temp 
> Vector At: 
>   142   10001110  Pop and Store Temp At  
> In Temp Vector At: 

Yes! We can make a Slot that stores in a hidden Array… should be very efficient 
(both space and speed-wise).
(of course with Spur no that needed anymore…)

Marcus