Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- 1 participants
- 144619 messages
[Pharo-project] gettext change set
by Hilaire Fernandes
So far,
In the archive the change set of classes (may be there are more)
extracted from Etoys for Gettext support.
They should install fine in Pharo 1.1, however there are incompatibility
issues, look like related to MethodReference protocole (in
TranslatedReceiverFind>>findWordsWith:in: )
Probably more to discover after this one.
To use the gettext protocol doc
http://community.ofset.org/index.php/OLPC#How_can_I_export_the_.pot_file_fo…
I use to install DrGeoII package then, try the gettext into it:
TextDomainManager registerCategoryPrefix: 'DrGeoII' domain: 'DrGeoII'.
ok
GetTextExporter2 exportTemplate.
fail
If someone is interested by a pair hacking session in IRC, drop me a line.
Hilaire
April 29, 2010
Re: [Pharo-project] Legitimate syntax for # ... foo
by Stéphane Ducasse
I would really like to get rid of that.
It makes everything looking so brittle.
Stef
On Apr 29, 2010, at 9:50 PM, Nicolas Cellier wrote:
> I don't think any other st dialect would accept that syntax but Squeak.
> It's just how the parser/scanner works now, but It wouldn't break much
> code IMO if we stop supporting these weirdnesses.
>
> Nicolas
>
> 2010/4/29 Lukas Renggli <renggli(a)gmail.com>:
>> Actually I didn't have all the latest code loaded in the open image.
>> There is more, hold your breath:
>>
>> testSymbolNumbers
>> #(('#1' 1) ('#12' 12) ('#12.3' 12.3) ('# 1' 1) ('##1' 1) ('#"bar"1'
>> 1)) do: [ :pair |
>> tree := RBParser parseExpression: pair first.
>> self assert: tree value = pair second.
>> self assert: tree start > 1.
>> self assert: tree stop = pair first size ]
>>
>> On 29 April 2010 21:12, Lukas Renggli <renggli(a)gmail.com> wrote:
>>>> # "helllooo" foo
>>>>
>>>> prints
>>>> #foo
>>>>
>>>> is this correct?
>>>
>>> Probably not, but the standard compiler accepts it. So I had to patch
>>> the parser of the refactoring engine to accept a whole series of
>>> degraded constructs. Below a small collection of tests documenting
>>> some of these strange things:
>>>
>>> testSymbolLiteral
>>> | tree |
>>> #(('# foo' #foo) ('#"bar"foo' #foo) ('##foo' #foo) ('###foo' #foo)
>>> ('#foo:' #foo:) ('#foo::' #'foo::') ('#foo::bar' #'foo::bar')
>>> ('#foo::bar:' #'foo::bar:') ('#foo::bar::' #'foo::bar::')) do: [ :pair
>>> |
>>> tree := RBParser parseExpression: pair first.
>>> self assert: tree value = pair second.
>>> self assert: tree start = 1.
>>> self assert: tree stop = pair first size ]
>>>
>>> testStatements
>>> | tree |
>>> #(('' 0 0) ('.' 0 1) ('| bar |' 0 0) ('| bar | .' 0 1) ('| bar | ..'
>>> 0 2) ('foo. bar' 2 1) ('foo. bar.' 2 2) ('foo. bar. .' 2 3) ('. foo.
>>> bar' 2 2)) do: [ :each |
>>> tree := RBParser parseExpression: each first.
>>> self assert: tree statements size = each second.
>>> self assert: tree periods size = each last ]
>>>
>>> testNumberParsing
>>> | numbers node |
>>> numbers := #(('1' 1) ('-1' -1) ('123' 123) ('123' 123) ('-123' -123)
>>> ('1.1' 1.1) ('-1.1' -1.1) ('1.23' 1.23) ('-1.23' -1.23) ('1e3' 1e3)
>>> ('1d3' 1d3) ('1q3' 1q3) ('-1e3' -1e3) ('1e-3' 1e-3) ('-1e-3' -1e-3)
>>> ('2r1e8' 2r1e8) ('-2r1e8' -2r1e8) ('2r1e-8' 2r1e-8) ('-2r1e-8'
>>> -2r1e-8) ('0.50s2' 0.50s2) ('0.500s3' 0.500s3) ('0.050s3' 0.050s3)).
>>> numbers do: [ :spec |
>>> node := RBParser parseExpression: spec first.
>>> self assert: node token source = spec first.
>>> self assert: node value = spec second ]
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>>
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
April 29, 2010
Re: [Pharo-project] Legitimate syntax for # ... foo
by Nicolas Cellier
I don't think any other st dialect would accept that syntax but Squeak.
It's just how the parser/scanner works now, but It wouldn't break much
code IMO if we stop supporting these weirdnesses.
Nicolas
2010/4/29 Lukas Renggli <renggli(a)gmail.com>:
> Actually I didn't have all the latest code loaded in the open image.
> There is more, hold your breath:
>
> testSymbolNumbers
> Â Â Â Â #(('#1' 1) ('#12' 12) ('#12.3' 12.3) ('# 1' 1) ('##1' 1) ('#"bar"1'
> 1)) do: [ :pair |
> Â Â Â Â Â Â Â Â tree := RBParser parseExpression: pair first.
> Â Â Â Â Â Â Â Â self assert: tree value = pair second.
> Â Â Â Â Â Â Â Â self assert: tree start > 1.
> Â Â Â Â Â Â Â Â self assert: tree stop = pair first size ]
>
> On 29 April 2010 21:12, Lukas Renggli <renggli(a)gmail.com> wrote:
>>> # "helllooo" foo
>>>
>>> prints
>>> #foo
>>>
>>> is this correct?
>>
>> Probably not, but the standard compiler accepts it. So I had to patch
>> the parser of the refactoring engine to accept a whole series of
>> degraded constructs. Below a small collection of tests documenting
>> some of these strange things:
>>
>> testSymbolLiteral
>> Â Â Â Â | tree |
>> Â Â Â Â #(('# foo' #foo) ('#"bar"foo' #foo) ('##foo' #foo) ('###foo' #foo)
>> ('#foo:' #foo:) ('#foo::' #'foo::') ('#foo::bar' #'foo::bar')
>> ('#foo::bar:' #'foo::bar:') ('#foo::bar::' #'foo::bar::')) do: [ :pair
>> |
>> Â Â Â Â Â Â Â Â tree := RBParser parseExpression: pair first.
>> Â Â Â Â Â Â Â Â self assert: tree value = pair second.
>> Â Â Â Â Â Â Â Â self assert: tree start = 1.
>> Â Â Â Â Â Â Â Â self assert: tree stop = pair first size ]
>>
>> testStatements
>> Â Â Â Â | tree |
>> Â Â Â Â #(('' 0 0) ('.' 0 1) ('| bar |' 0 0) ('| bar | .' 0 1) ('| bar | ..'
>> 0 2) ('foo. bar' 2 1) ('foo. bar.' 2 2) ('foo. bar. .' 2 3) ('. foo.
>> bar' 2 2)) do: [ :each |
>> Â Â Â Â Â Â Â Â tree := RBParser parseExpression: each first.
>> Â Â Â Â Â Â Â Â self assert: tree statements size = each second.
>> Â Â Â Â Â Â Â Â self assert: tree periods size = each last ]
>>
>> testNumberParsing
>> Â Â Â Â | numbers node |
>> Â Â Â Â numbers := #(('1' 1) ('-1' -1) ('123' 123) ('123' 123) ('-123' -123)
>> ('1.1' 1.1) ('-1.1' -1.1) ('1.23' 1.23) ('-1.23' -1.23) ('1e3' 1e3)
>> ('1d3' 1d3) ('1q3' 1q3) ('-1e3' -1e3) ('1e-3' 1e-3) ('-1e-3' -1e-3)
>> ('2r1e8' Â 2r1e8) ('-2r1e8' -2r1e8) ('2r1e-8' 2r1e-8) ('-2r1e-8'
>> -2r1e-8) ('0.50s2' 0.50s2) ('0.500s3' 0.500s3) ('0.050s3' 0.050s3)).
>> Â Â Â Â numbers do: [ :spec |
>> Â Â Â Â Â Â Â Â node := RBParser parseExpression: spec first.
>> Â Â Â Â Â Â Â Â self assert: node token source = spec first.
>> Â Â Â Â Â Â Â Â self assert: node value = spec second ]
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
April 29, 2010
Re: [Pharo-project] Legitimate syntax for # ... foo
by Stéphane Ducasse
arghhhhhhhhhhhhhhhhhhhhhhh
may be one day we should clean that too.
> testSymbolLiteral
> | tree |
> #(('# foo' #foo) ('#"bar"foo' #foo) ('##foo' #foo) ('###foo' #foo)
> ('#foo:' #foo:) ('#foo::' #'foo::') ('#foo::bar' #'foo::bar')
> ('#foo::bar:' #'foo::bar:') ('#foo::bar::' #'foo::bar::')) do: [ :pair
> |
> tree := RBParser parseExpression: pair first.
> self assert: tree value = pair second.
> self assert: tree start = 1.
> self assert: tree stop = pair first size ]
the string and symbols mixture is not good.
#'hkjh 3' is ok and all the rest looks ugly to me.
> testStatements
> | tree |
> #(('' 0 0) ('.' 0 1) ('| bar |' 0 0) ('| bar | .' 0 1) ('| bar | ..'
> 0 2) ('foo. bar' 2 1) ('foo. bar.' 2 2) ('foo. bar. .' 2 3) ('. foo.
> bar' 2 2)) do: [ :each |
> tree := RBParser parseExpression: each first.
> self assert: tree statements size = each second.
> self assert: tree periods size = each last ]
>
> testNumberParsing
> | numbers node |
> numbers := #(('1' 1) ('-1' -1) ('123' 123) ('123' 123) ('-123' -123)
> ('1.1' 1.1) ('-1.1' -1.1) ('1.23' 1.23) ('-1.23' -1.23) ('1e3' 1e3)
> ('1d3' 1d3) ('1q3' 1q3) ('-1e3' -1e3) ('1e-3' 1e-3) ('-1e-3' -1e-3)
> ('2r1e8' 2r1e8) ('-2r1e8' -2r1e8) ('2r1e-8' 2r1e-8) ('-2r1e-8'
> -2r1e-8) ('0.50s2' 0.50s2) ('0.500s3' 0.500s3) ('0.050s3' 0.050s3)).
> numbers do: [ :spec |
> node := RBParser parseExpression: spec first.
> self assert: node token source = spec first.
> self assert: node value = spec second ]
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
April 29, 2010
Re: [Pharo-project] [squeak-dev] Re: Menu Registries
by Stéphane Ducasse
>
>
> is so much more "complicated" than
>
> -------------------
> Editor class>>blinkingCursor
> <preference: 'Blinking Text Cursor'
> category: 'Morphic'
> description: 'When true, the text cursor will blink.'
> type: #Boolean>
> ^ BlinkingCursor ifNil: [ true ]
> -------------------
>
> Well the former is executable and must be executable. The latter is not necessarily executable (but its good if it is, because one can locate the code that processes the specification) . So they're the same on that level. But the former can only be executable and isn't separated from the processing code, whereas the latter is separated.
Yes this is clear we got that discussion long time ago and we are aware of the pros and the cons. At least as a language designer expert this is obvious to me.
Now I do not want to argue again. The goal of setting is to have settings totally out of the code and only make sense in presence of an interpreter of them.
So...
> The former also only works in context (aBuilder) whereas the latter stands alone, and this ability to stand alone, as a specification, loosely coupled to the settings maintennance system is one thing that makes it simpler. It also clearly states the default value which the former doesn't. So I find the latter significantly easier to understand, and given I understand the method annotation system I find the mechanics not that much more complicated than the former's. We all understand perform: right?
Yes now the key dimension is whether your vocabulary is fixed or not.
When you have a fixed vocabulary then this is clear that the declarative syntax is the winner and the other one does not make sense.
But for preferences it does not work. or you should have a much more lengthly key and interpret the arguments.
> You prefer UI+domain mixing, we prefer UI separated from domain.
>
> I see the opposite. I see good separation in the latter example but I don't see the separation in the former. And BTW this is me trying to think critically, trying to keep happy feet in both the Pharo and Squeak (and eToys and Cuis and ....) camps, not trying to be tribal. Apologies in advance if expressing a contradictory view is taken as offensive.
I will not add more. I think that we should favor declarative syntax as much as we can but not more.
Stef
April 29, 2010
Re: [Pharo-project] Legitimate syntax for # ... foo
by Lukas Renggli
Actually I didn't have all the latest code loaded in the open image.
There is more, hold your breath:
testSymbolNumbers
#(('#1' 1) ('#12' 12) ('#12.3' 12.3) ('# 1' 1) ('##1' 1) ('#"bar"1'
1)) do: [ :pair |
tree := RBParser parseExpression: pair first.
self assert: tree value = pair second.
self assert: tree start > 1.
self assert: tree stop = pair first size ]
On 29 April 2010 21:12, Lukas Renggli <renggli(a)gmail.com> wrote:
>> # "helllooo" foo
>>
>> prints
>> #foo
>>
>> is this correct?
>
> Probably not, but the standard compiler accepts it. So I had to patch
> the parser of the refactoring engine to accept a whole series of
> degraded constructs. Below a small collection of tests documenting
> some of these strange things:
>
> testSymbolLiteral
> Â Â Â Â | tree |
> Â Â Â Â #(('# foo' #foo) ('#"bar"foo' #foo) ('##foo' #foo) ('###foo' #foo)
> ('#foo:' #foo:) ('#foo::' #'foo::') ('#foo::bar' #'foo::bar')
> ('#foo::bar:' #'foo::bar:') ('#foo::bar::' #'foo::bar::')) do: [ :pair
> |
> Â Â Â Â Â Â Â Â tree := RBParser parseExpression: pair first.
> Â Â Â Â Â Â Â Â self assert: tree value = pair second.
> Â Â Â Â Â Â Â Â self assert: tree start = 1.
> Â Â Â Â Â Â Â Â self assert: tree stop = pair first size ]
>
> testStatements
> Â Â Â Â | tree |
> Â Â Â Â #(('' 0 0) ('.' 0 1) ('| bar |' 0 0) ('| bar | .' 0 1) ('| bar | ..'
> 0 2) ('foo. bar' 2 1) ('foo. bar.' 2 2) ('foo. bar. .' 2 3) ('. foo.
> bar' 2 2)) do: [ :each |
> Â Â Â Â Â Â Â Â tree := RBParser parseExpression: each first.
> Â Â Â Â Â Â Â Â self assert: tree statements size = each second.
> Â Â Â Â Â Â Â Â self assert: tree periods size = each last ]
>
> testNumberParsing
> Â Â Â Â | numbers node |
> Â Â Â Â numbers := #(('1' 1) ('-1' -1) ('123' 123) ('123' 123) ('-123' -123)
> ('1.1' 1.1) ('-1.1' -1.1) ('1.23' 1.23) ('-1.23' -1.23) ('1e3' 1e3)
> ('1d3' 1d3) ('1q3' 1q3) ('-1e3' -1e3) ('1e-3' 1e-3) ('-1e-3' -1e-3)
> ('2r1e8' Â 2r1e8) ('-2r1e8' -2r1e8) ('2r1e-8' 2r1e-8) ('-2r1e-8'
> -2r1e-8) ('0.50s2' 0.50s2) ('0.500s3' 0.500s3) ('0.050s3' 0.050s3)).
> Â Â Â Â numbers do: [ :spec |
> Â Â Â Â Â Â Â Â node := RBParser parseExpression: spec first.
> Â Â Â Â Â Â Â Â self assert: node token source = spec first.
> Â Â Â Â Â Â Â Â self assert: node value = spec second ]
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
--
Lukas Renggli
www.lukas-renggli.ch
April 29, 2010
Re: [Pharo-project] Legitimate syntax for # ... foo
by Lukas Renggli
> # "helllooo" foo
>
> prints
> #foo
>
> is this correct?
Probably not, but the standard compiler accepts it. So I had to patch
the parser of the refactoring engine to accept a whole series of
degraded constructs. Below a small collection of tests documenting
some of these strange things:
testSymbolLiteral
| tree |
#(('# foo' #foo) ('#"bar"foo' #foo) ('##foo' #foo) ('###foo' #foo)
('#foo:' #foo:) ('#foo::' #'foo::') ('#foo::bar' #'foo::bar')
('#foo::bar:' #'foo::bar:') ('#foo::bar::' #'foo::bar::')) do: [ :pair
|
tree := RBParser parseExpression: pair first.
self assert: tree value = pair second.
self assert: tree start = 1.
self assert: tree stop = pair first size ]
testStatements
| tree |
#(('' 0 0) ('.' 0 1) ('| bar |' 0 0) ('| bar | .' 0 1) ('| bar | ..'
0 2) ('foo. bar' 2 1) ('foo. bar.' 2 2) ('foo. bar. .' 2 3) ('. foo.
bar' 2 2)) do: [ :each |
tree := RBParser parseExpression: each first.
self assert: tree statements size = each second.
self assert: tree periods size = each last ]
testNumberParsing
| numbers node |
numbers := #(('1' 1) ('-1' -1) ('123' 123) ('123' 123) ('-123' -123)
('1.1' 1.1) ('-1.1' -1.1) ('1.23' 1.23) ('-1.23' -1.23) ('1e3' 1e3)
('1d3' 1d3) ('1q3' 1q3) ('-1e3' -1e3) ('1e-3' 1e-3) ('-1e-3' -1e-3)
('2r1e8' 2r1e8) ('-2r1e8' -2r1e8) ('2r1e-8' 2r1e-8) ('-2r1e-8'
-2r1e-8) ('0.50s2' 0.50s2) ('0.500s3' 0.500s3) ('0.050s3' 0.050s3)).
numbers do: [ :spec |
node := RBParser parseExpression: spec first.
self assert: node token source = spec first.
self assert: node value = spec second ]
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
April 29, 2010
Re: [Pharo-project] [squeak-dev] Re: [Vm-dev] Fwd: is it possible to know the memory occupation (bytes) of an object?
by Mariano Martinez Peck
On Thu, Apr 29, 2010 at 6:00 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote:
> On 4/29/2010 6:22 AM, Mariano Martinez Peck wrote:
>
>> and then I call it like this for example:
>>
>> oop := self firstAccessibleObject.
>> [oop = nil] whileFalse: [
>> (self isIntegerObject: oop)
>> ifFalse: [
>> size := self internalByteSize: oop.
>> ......]
>> oop := self accessibleObjectAfter: oop.
>> ].
>>
>
> Do you realize that this simple computes the used memory which is
> information that's directly accessible via the vm parameters? I don't recall
> which one but you might want to look at these to see if they already have
> what you need.
>
Thanks Andreas. I guess I should have explained my situation. Basically,
what I was trying to do (and I did at the end) is to use the last free bit
of the object header to use it to detect used and unused objects. I modified
the VM so that when an object receives a message, it enables such bit. I
also have primitives to mark and unmark all objects.
I am not sure what I will do then with the unused objects, but for the
moment, I just wanted to get numbers. Statistics. So, for example I wanted
to know how many objects were with the bit on and how many with the bit off.
Also the amount of memory those objects represents.
The method is:
primitiveGetStadistics
| oop usedCount unusedCount results usedMemory unusedMemory usedCountOop
unusedCountOop usedMemoryOop unusedMemoryOop |
usedCount := unusedCount := 0.
usedMemory := unusedMemory := 0.
self print: 'Start to check objects'; cr.
oop := self firstAccessibleObject.
[oop = nil] whileFalse: [
(self isIntegerObject: oop)
ifFalse: [
(self internalIsUsed: oop)
ifTrue: [
usedCount := usedCount +1.
usedMemory := usedMemory + (self internalByteSize:
oop). ]
ifFalse: [
unusedCount := unusedCount +1.
unusedMemory := unusedMemory + (self
internalByteSize: oop). ].
].
oop := self accessibleObjectAfter: oop.
].
self print: 'Finish to check objects'; cr.
self print: 'Push stadistics'; cr.
self pushRemappableOop:
(self instantiateClass: (self classArray) indexableSize: 4).
self pushRemappableOop:
(self positive64BitIntegerFor: usedCount).
self pushRemappableOop:
(self positive64BitIntegerFor: usedMemory).
self pushRemappableOop:
(self positive64BitIntegerFor: unusedCount).
self pushRemappableOop:
(self positive64BitIntegerFor: unusedMemory).
self print: 'Pop stadistics'; cr.
unusedMemoryOop := self popRemappableOop.
unusedCountOop := self popRemappableOop.
usedMemoryOop := self popRemappableOop.
usedCountOop := self popRemappableOop.
results := self popRemappableOop.
self print: 'Write stadistics in array'; cr.
self storePointer: 0 ofObject: results withValue: usedCountOop.
self storePointer: 1 ofObject: results withValue: unusedCountOop.
self storePointer: 2 ofObject: results withValue: usedMemoryOop.
self storePointer: 3 ofObject: results withValue: unusedMemoryOop.
self print: 'Push result array in stadistics'; cr.
self pop: 1 thenPush: results.
And as you may guess,
internalIsUsed: oop
self inline: true.
^((self baseHeader: oop) bitAnd: UsedObjectBit) ~= 0
So then, from the image side, I can get statistics at certain point, and get
something like the attached screenshot.
Thanks.
Mariano
>
> Cheers,
> - Andreas
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
April 29, 2010
Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser
by Alexandre Bergel
Ok, I will check.
Alexandre
On 29 Apr 2010, at 14:08, Dale Henrichs wrote:
> Mariano and Alexandre,
>
> Sorry for the late reply ... I've been off-line with a cold for the
> last several days ...
>
> I have seen the behavior that you describe while working with GLASS
> 1.0-beta.8 and have fixed the problem in Metacello 1.0-beta.26.1 ...
> 1.0-beta.26.1 is still in development, but if you want to give it a
> try, preload 1.0-beta.26.1 and rerun your test ... if the problem
> still persists, let me know and I will dive into it.
>
> Dale
> ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote:
>
> | On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel <
> | alexandre.bergel(a)inria.fr> wrote:
> |
> | > It is a bit more subtle than that.
> | >
> | > If I take a Core 1.1, and doit: ConfigurationOfPharo project
> | lastVersion
> | > load
> | > Then I get a warning coming from OBSearchBrowser class related to
> | the world
> | > menu registration.
> | >
> | >
> | Yes, I noticed that.
> |
> |
> | > At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are
> | loaded.
> | >
> | > Doing twice a proceed resume the loading.
> | > It then blocks on SHWorkspace, for the very same reason.
> | >
> | >
> | yes..
> |
> |
> | > After having manually fixed the Nile problem (isInMemory), Pharo
> | loads
> | > well. ProfStef is open.
> | >
> | >
> | I did the same...
> |
> |
> | > OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means
> | that
> | > OmniBrowser is loaded twice. Is this the intended behavior?
> | >
> | >
> | I saw directly the final versions: 469 and 116. I didn't notice it
> was
> | first
> | trying to load 458 and 112.
> | I know that in such conflict, Metacello will load the last one,
> but I
> | didnt
> | know that it actually LOADS also the previous versions. I thought
> that
> | it
> | only loads the final version, not both of them. In such case, I
> think
> | it is
> | a metacello bug.
> |
> | See this link:
> | http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b…
> |
> | Dale, can you help us?
> |
> | Thanks
> |
> | Mariano
> |
> | > Alexandre
> | >
> | >
> | >
> | > On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote:
> | >
> | >
> | >>
> | >> On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel
> | <alexandre(a)bergel.eu>
> | >> wrote:
> | >> Hi!
> | >>
> | >> I am now trying to make ConfigurationOfPharo load the last
> version
> | of
> | >> OmniBrowser.
> | >> If I do in a fresh core: ConfigurationOfPharo project lastVersion
> | load
> | >>
> | >> Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded.
> | >>
> | >>
> | >> No. If you take a PharoCore 1.0 OR 1.1 and evaluate
> | ConfigurationOfPharo
> | >> project lastVersion load
> | >>
> | >> It installs OmniBrowser-lr.469 and OB-Morphic-lr.116
> | >> which are correct as those are defined in
> | ConfigurationOfOmniBrowser
> | >> version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB.
> | >>
> | >>
> | >> The loading blocks on the deprecated warning (yes, the
> registration
> | in the
> | >> World menu).
> | >> In ConfigurationOfPharo>>version11: I have
> | >>
> | >> spec
> | >> project: 'PharoNonCorePackages'
> | with:
> | >> '1.1.0';
> | >> project: 'NewInspector' with:
> '1.1';
> | >> project: 'Shout' with: '1.0';
> | >> project: 'Shout Tests' with: '1.0';
> | >> project: 'OCompletion' with: '1.1';
> | >> project: 'OCompletion Tests' with:
> | '1.1';
> | >> project: 'OB Dev' with: '1.1.3';
> | >> project: 'OB Dev Tests' with:
> | '1.1.3';
> | >> ...
> | >>
> | >> I therefore assume that the version 1.1.3 of OmniBrowser is
> | loaded.
> | >> 1.1.3 is indeed the last version specified in
> | ConfigurationOfOmniBrowser:
> | >> ConfigurationOfOmniBrowser project lastVersion
> | >> => ~1.1.3 [ConfigurationOfOmniBrowser]
> | >>
> | >> But I evaluate: ConfigurationOfOmniBrowser project lastVersion
> | load
> | >> Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and
> | >> OmniBrowser-lr.469 are loaded.
> | >>
> | >>
> | >> Exactly. And that's correct. Those are the versions that are
> | defined in
> | >> ConfigurationOfOmnibrowser 1.1.3
> | >>
> | >> I find it is very hard to keep track of what is actually loaded.
> | >>
> | >>
> | >> I don't understand your problem. Everything seems to work as
> | exepected.
> | >>
> | >>
> | >> I haven't closely followed the evolution of Metacello, but
> there is
> | not a
> | >> way to say:
> | >> spec project: 'OB Dev' with: 'lastestVersion'
> | >>
> | >> Yes. Don't put any version. If you don't define a version,
> | metacallo will
> | >> load the last one.
> | >>
> | >> project: 'OB Dev';
> | >>
> | >> or even remove that line from the version method. Even more, if
> | you want
> | >> ALL the last, you can load the baseline instead of the version.
> In
> | such
> | >> case, as you don't specify any version, it will download all the
> | last ones.
> | >>
> | >> Cheers
> | >>
> | >> Mariano
> | >>
> | >>
> | >> Or Something?
> | >>
> | >> Cheers,
> | >> Alexandre
> | >> --
> | >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> | >> Alexandre Bergel http://www.bergel.eu
> | >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> | >>
> | >>
> | >>
> | >>
> | >>
> | >>
> | >> _______________________________________________
> | >> Pharo-project mailing list
> | >> Pharo-project(a)lists.gforge.inria.fr
> | >>
> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> | >>
> | >> _______________________________________________
> | >> Pharo-project mailing list
> | >> Pharo-project(a)lists.gforge.inria.fr
> | >>
> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> | >>
> | >
> | >
> | > _______________________________________________
> | > Pharo-project mailing list
> | > Pharo-project(a)lists.gforge.inria.fr
> | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
> project
> | >
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
April 29, 2010
Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser
by Dale Henrichs
Mariano and Alexandre,
Sorry for the late reply ... I've been off-line with a cold for the last several days ...
I have seen the behavior that you describe while working with GLASS 1.0-beta.8 and have fixed the problem in Metacello 1.0-beta.26.1 ... 1.0-beta.26.1 is still in development, but if you want to give it a try, preload 1.0-beta.26.1 and rerun your test ... if the problem still persists, let me know and I will dive into it.
Dale
----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote:
| On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel <
| alexandre.bergel(a)inria.fr> wrote:
|
| > It is a bit more subtle than that.
| >
| > If I take a Core 1.1, and doit: ConfigurationOfPharo project
| lastVersion
| > load
| > Then I get a warning coming from OBSearchBrowser class related to
| the world
| > menu registration.
| >
| >
| Yes, I noticed that.
|
|
| > At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are
| loaded.
| >
| > Doing twice a proceed resume the loading.
| > It then blocks on SHWorkspace, for the very same reason.
| >
| >
| yes..
|
|
| > After having manually fixed the Nile problem (isInMemory), Pharo
| loads
| > well. ProfStef is open.
| >
| >
| I did the same...
|
|
| > OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means
| that
| > OmniBrowser is loaded twice. Is this the intended behavior?
| >
| >
| I saw directly the final versions: 469 and 116. I didn't notice it was
| first
| trying to load 458 and 112.
| I know that in such conflict, Metacello will load the last one, but I
| didnt
| know that it actually LOADS also the previous versions. I thought that
| it
| only loads the final version, not both of them. In such case, I think
| it is
| a metacello bug.
|
| See this link:
| http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b…
|
| Dale, can you help us?
|
| Thanks
|
| Mariano
|
| > Alexandre
| >
| >
| >
| > On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote:
| >
| >
| >>
| >> On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel
| <alexandre(a)bergel.eu>
| >> wrote:
| >> Hi!
| >>
| >> I am now trying to make ConfigurationOfPharo load the last version
| of
| >> OmniBrowser.
| >> If I do in a fresh core: ConfigurationOfPharo project lastVersion
| load
| >>
| >> Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded.
| >>
| >>
| >> No. If you take a PharoCore 1.0 OR 1.1 and evaluate
| ConfigurationOfPharo
| >> project lastVersion load
| >>
| >> It installs OmniBrowser-lr.469 and OB-Morphic-lr.116
| >> which are correct as those are defined in
| ConfigurationOfOmniBrowser
| >> version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB.
| >>
| >>
| >> The loading blocks on the deprecated warning (yes, the registration
| in the
| >> World menu).
| >> In ConfigurationOfPharo>>version11: I have
| >>
| >> spec
| >> project: 'PharoNonCorePackages'
| with:
| >> '1.1.0';
| >> project: 'NewInspector' with: '1.1';
| >> project: 'Shout' with: '1.0';
| >> project: 'Shout Tests' with: '1.0';
| >> project: 'OCompletion' with: '1.1';
| >> project: 'OCompletion Tests' with:
| '1.1';
| >> project: 'OB Dev' with: '1.1.3';
| >> project: 'OB Dev Tests' with:
| '1.1.3';
| >> ...
| >>
| >> I therefore assume that the version 1.1.3 of OmniBrowser is
| loaded.
| >> 1.1.3 is indeed the last version specified in
| ConfigurationOfOmniBrowser:
| >> ConfigurationOfOmniBrowser project lastVersion
| >> => ~1.1.3 [ConfigurationOfOmniBrowser]
| >>
| >> But I evaluate: ConfigurationOfOmniBrowser project lastVersion
| load
| >> Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and
| >> OmniBrowser-lr.469 are loaded.
| >>
| >>
| >> Exactly. And that's correct. Those are the versions that are
| defined in
| >> ConfigurationOfOmnibrowser 1.1.3
| >>
| >> I find it is very hard to keep track of what is actually loaded.
| >>
| >>
| >> I don't understand your problem. Everything seems to work as
| exepected.
| >>
| >>
| >> I haven't closely followed the evolution of Metacello, but there is
| not a
| >> way to say:
| >> spec project: 'OB Dev' with: 'lastestVersion'
| >>
| >> Yes. Don't put any version. If you don't define a version,
| metacallo will
| >> load the last one.
| >>
| >> project: 'OB Dev';
| >>
| >> or even remove that line from the version method. Even more, if
| you want
| >> ALL the last, you can load the baseline instead of the version. In
| such
| >> case, as you don't specify any version, it will download all the
| last ones.
| >>
| >> Cheers
| >>
| >> Mariano
| >>
| >>
| >> Or Something?
| >>
| >> Cheers,
| >> Alexandre
| >> --
| >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
| >> Alexandre Bergel http://www.bergel.eu
| >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
| >>
| >>
| >>
| >>
| >>
| >>
| >> _______________________________________________
| >> Pharo-project mailing list
| >> Pharo-project(a)lists.gforge.inria.fr
| >>
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| >>
| >> _______________________________________________
| >> Pharo-project mailing list
| >> Pharo-project(a)lists.gforge.inria.fr
| >>
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| >>
| >
| >
| > _______________________________________________
| > Pharo-project mailing list
| > Pharo-project(a)lists.gforge.inria.fr
| > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| >
April 29, 2010