[Pharo-dev] Marquette Camp Smalltalk September 15-18th

[Andres Valloud]

Hi!  Your Camp Smalltalk crew has been at it for a while, and we are
very happy to announce a Camp Smalltalk at Marquette, Michigan, on
September 15-18th.  The event's website is at http://mqt.st.  We are
generously hosted by Northern Michigan University (http://www.nmu.edu),
where John Sarkela teaches Smalltalk courses.  Of course, NMU is also
home to the Modtalk project, https://www.modtalk.org.  You can help us
provide a better experience for everyone by registering here:
https://www.picatic.com/event14606861846650.  Don't miss the date!

Re: [Pharo-dev] Out of ideas...

[Bernardo Ezequiel Contreras]

What about this

| line matcher exps ranges negateRanges result |
line :=
'A política no Brasil está complicada #FAIL porque a corrupção impera
#CRIME. De qualquer forma os #PETRALHAS, que tudo justificam, levam o país
ao #CAOS'.
matcher := '(#\w+)' asRegex.
exps := matcher matchesIn: line.
"i believe you can extend the matcher to give the subexpressions
and ranges at the same time"
ranges := matcher matchingRangesIn: line.
negateRanges := OrderedCollection new.
ranges inject: 1 into: [ :start :interval |
negateRanges add: (Interval from: start to: (interval first - 1)).
interval last + 1  ].
result :=
negateRanges inject: String new into: [ :s :interval |
s, (line copyFrom: interval first to: interval last).
].

Array with: exps
with: ranges
with: negateRanges
with: result


On Tue, Aug 9, 2016 at 12:53 PM, Casimiro - GMAIL <
casimiro.barr...@gmail.com> wrote:

> Em 08-08-2016 19:25, Bernardo Ezequiel Contreras escreveu:
>
> Hi,
>
>   have you try with  (World>>Help>>Help Browser>>Regular Expressions
> Framework>>Usage)
>
> SUBEXPRESSION MATCHES
>
> After a successful match attempt, you can query the specifics of which
> part of the original string has matched which part of the whole
> expression.
>
> (...)
>
> Thanks, but thing is: my need is little more complex than finding
> sequences. I'm looking for expressions in natural language text. The
> expressions must be extracted without ambiguities so I have cases for
> occurrences in the beginning of line (aka '^(#\w+)([\s.,;\:!?]*)') in the
> middle of the line (aka '([\s.,;\:!?]+)(#\w+)([\s.,;\:!?]+)') or at the
> end (which may be simplified to the second case...). So, if I find several
> hashtags in a text like:
>
> 'A política no Brasil está complicada #FAIL porque a corrupção impera
> #CRIME. De qualquer forma os #PETRALHAS, que tudo justificam, levam o país
> ao #CAOS'
>
> I want two things:
>
> 1st and obvious: #( '#FAIL' '#CRIME' '#PETRALHAS' '#CAOS')
> 2nd: the line minus hashtags: 'A política no Brasil está complicada porque
> a corrupção impera. De qualquer forma os, que tudo justificam, levam o país
> ao'
>
> When I use regexps to process the line, for instance:
>
> bfr := line copyWithRegex: '#\w+' matchesReplacedUsing [ :e | '' ].
>
> I can have trouble because it will extract things like #ANOTAÇÃO# which is
> not a hashtag but will match.
>
> And I'm trying to avoid doing the Lex/Yacc thing here :D
>
> Best regards,
>
> CdAB
>
> --
> The information contained in this message is confidential and intended to
> the recipients specified in the headers. If you received this message by
> error, notify the sender immediately. The unauthorized use, disclosure,
> copy or alteration of this message are strictly forbidden and subjected to
> civil and criminal sanctions.
>
> ==
>
> This email may be signed using PGP key *ID: 0x4134A417*
>



-- 
Bernardo E.C.

Sent from a cheap desktop computer in South America.

Re: [Pharo-dev] GT-Spotter dive in shortcut

[Nicolai Hess]

2016-08-09 23:36 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Aug 9, 2016, at 11:31 PM, Nicolai Hess  wrote:
> >
> >
> >
> > 2016-08-09 22:53 GMT+02:00 Tudor Girba :
> > Hi,
> >
> > > On Aug 9, 2016, at 10:48 PM, Nicolai Hess 
> wrote:
> > >
> > >
> > >
> > > 2016-08-09 18:12 GMT+02:00 Tudor Girba :
> > > Hi,
> > >
> > > >
> > > > Hey Doru,
> > > > about what "two issues" are we talking? My only issue for now is,
> > > > what shortcut shold we use for moving the cursor forward/backward
> word. Even if we introduce a new layer, at some point in time you need to
> > > > define: If  the user types the CTRL+LEFT -key, even if we call it
> differently, some action happens, dive-out or move-backward-word ?
> > > > At the moment (on windows) you can use both to move word-by-word:
> > > > ctrl+left/right and alt+left/right, because this is how it is
> defined in rubrics action/cmdaction map.
> > > >
> > > > If we want to clean this up and use the kmdispatcher registration, I
> think we don't want to use both ctr and alt again, right?
> > > > So, someone has to take the decision.
> > > > I myself would prefer
> > > > ctrl+left/right because this is what (all) many other programs are
> using on windows. Fine. But recently Spotter changed its
> > > > dive in / dive out shortcut to use ctrl+left/right.
> > > > Therefor I am asking you, why, and whether we want to keep it or
> not. If we want to keep it, we may
> > > > - just overwrite the binding for the textfield -> not good, I think,
> you wouldn't be able to do word-by-word movements in the textfield anymore
> > > > - overwrite the binding and use another binding for word-by-word
> moving, but just in spotters text field
> > > > Or we revert that change and use the old shortcuts again.
> > > > (And what to use for mac and linux?)
> > > >
> > > > but I am getting really tired of asking, and will do something else
> instead.
> > >
> > > The short answer: we will override the keybinding in the text morph
> for now. This will mean that we cannot move word by word in the text field
> using #control, but it will be consistent with all other platforms. Could
> you open an issue for this, please?
> > >
> > >
> > > consistens on all platforms may not be the expectation for all users.
> Some users only working on a windows platform may want to have consistent
> behavior for all tools (applications).
> >
> > Well, you wanted a decision :).
> >
> >
> > > On top of that, we will externalize all GTSpotter shortcuts through
> settings:
> > > https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-
> should-be-externalized-as-settings
> > >
> > > I really don't know why that.
> >
> > Because we do not have a generic KMDispatcher mechanism :).
> >
> > yes and it does not make much sense as not all shortcuts are handled by
> the kmdispatcher, thats why cleaning this
> > up and I think it would be better to do this instead of implementing yet
> another only-for-this-tool solution.
>
> Ok. What should I do?
>
>
> > > We don't need a way to make Spotter shortcuts configurable, but *all*
> shortcuts.
> > > That is why I try to move all shortcut definitions to the
> kmdispatcher, but it yet again took 2 month just to discuss what shortcut
> to use for cursor movement.
> >
> > I am not sure I understand. Was this me that stalled the discussion? If
> yes, it was not intentional. Is there anything I can do about this subject?
> >
> > The whole discussion, the me: "hey, what shortcut to use?" you:"hey we
> have a great idea, just let us add some new layers" :(
>
> I think I miss something because I do not see how the layers have anything
> to do with the cursor movement. Or do you mean for diving in Spotter? I
> still think that the layers idea is a relevant one and does not conflict
> with anything we talked about here.
>

Ok once again.
ctrl+arrow and meta+arrow both do cursor movements in rubrik, but it is
registered on the action/cmd-map (RubTextEditor>>defaultCommandKeymapping)
ctrl+arrow do dive-in/dive-out in spotter, this is registered on spotters
window, and this takes precedence over rubrics crtrl+Arrow handling because
:

1. kmdispatcher looks in rubrics editor kmregistry -> no action
2. kmdispatcher looks in rubrics morph kmregistry -> no action
 up the morphs owner chain until it reaches spotter
x. kmdispatcher looks in spotters window morph kmregistry -> Action!
Dive-in / Dive-out

Now! If I move ctrl+Arrow shortcut registration for cursor movement from
rubrics action/-cmd-map to its kmdispatcher registration, the following
happens
1. kmdispatcher looks in rubrics editor kmregistry -> Action ! move the
cursor

 -> no spotter dive-in/dive-out anymore :-(

two solutions:
use a different shortcut for cursor movement (that is what I aksed in this
thread, and why I opened issue 18432
)
use a different shortcut for spotter (this is why I started this thread and
asked why this was changed at all)
overwrite spotters sho

Re: [Pharo-dev] GT-Spotter dive in shortcut

[Tudor Girba]

Hi,

> On Aug 9, 2016, at 11:31 PM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-08-09 22:53 GMT+02:00 Tudor Girba :
> Hi,
> 
> > On Aug 9, 2016, at 10:48 PM, Nicolai Hess  wrote:
> >
> >
> >
> > 2016-08-09 18:12 GMT+02:00 Tudor Girba :
> > Hi,
> >
> > >
> > > Hey Doru,
> > > about what "two issues" are we talking? My only issue for now is,
> > > what shortcut shold we use for moving the cursor forward/backward word. 
> > > Even if we introduce a new layer, at some point in time you need to
> > > define: If  the user types the CTRL+LEFT -key, even if we call it 
> > > differently, some action happens, dive-out or move-backward-word ?
> > > At the moment (on windows) you can use both to move word-by-word:
> > > ctrl+left/right and alt+left/right, because this is how it is defined in 
> > > rubrics action/cmdaction map.
> > >
> > > If we want to clean this up and use the kmdispatcher registration, I 
> > > think we don't want to use both ctr and alt again, right?
> > > So, someone has to take the decision.
> > > I myself would prefer
> > > ctrl+left/right because this is what (all) many other programs are using 
> > > on windows. Fine. But recently Spotter changed its
> > > dive in / dive out shortcut to use ctrl+left/right.
> > > Therefor I am asking you, why, and whether we want to keep it or not. If 
> > > we want to keep it, we may
> > > - just overwrite the binding for the textfield -> not good, I think, you 
> > > wouldn't be able to do word-by-word movements in the textfield anymore
> > > - overwrite the binding and use another binding for word-by-word moving, 
> > > but just in spotters text field
> > > Or we revert that change and use the old shortcuts again.
> > > (And what to use for mac and linux?)
> > >
> > > but I am getting really tired of asking, and will do something else 
> > > instead.
> >
> > The short answer: we will override the keybinding in the text morph for 
> > now. This will mean that we cannot move word by word in the text field 
> > using #control, but it will be consistent with all other platforms. Could 
> > you open an issue for this, please?
> >
> >
> > consistens on all platforms may not be the expectation for all users. Some 
> > users only working on a windows platform may want to have consistent 
> > behavior for all tools (applications).
> 
> Well, you wanted a decision :).
> 
> 
> > On top of that, we will externalize all GTSpotter shortcuts through 
> > settings:
> > https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-should-be-externalized-as-settings
> >
> > I really don't know why that.
> 
> Because we do not have a generic KMDispatcher mechanism :).
> 
> yes and it does not make much sense as not all shortcuts are handled by the 
> kmdispatcher, thats why cleaning this
> up and I think it would be better to do this instead of implementing yet 
> another only-for-this-tool solution.

Ok. What should I do?


> > We don't need a way to make Spotter shortcuts configurable, but *all* 
> > shortcuts.
> > That is why I try to move all shortcut definitions to the kmdispatcher, but 
> > it yet again took 2 month just to discuss what shortcut to use for cursor 
> > movement.
> 
> I am not sure I understand. Was this me that stalled the discussion? If yes, 
> it was not intentional. Is there anything I can do about this subject?
> 
> The whole discussion, the me: "hey, what shortcut to use?" you:"hey we have a 
> great idea, just let us add some new layers" :(

I think I miss something because I do not see how the layers have anything to 
do with the cursor movement. Or do you mean for diving in Spotter? I still 
think that the layers idea is a relevant one and does not conflict with 
anything we talked about here.

In any case, I did not mean to confuse anyone. Please take the lead concerning 
the KMDispatcher and I can review if you want.

Doru



> Cheers,
> Doru
> 
> 
> >
> > Long answer: As explained before, the shortcut changed in the process of 
> > making all shortcuts uniform when Guille introduced #meta instead of 
> > #command (like it was before). The thing is that currently:
> > - #command means #alt on Win and #command on Mac, and
> > - #meta means #control on Win and #command on Mac.
> >
> > But, #command should be a low level key, not a portable one. It should not 
> > have a meaning on Windows, because the key does not exist on that platform.
> >
> > Moving to make keybindings uniform is a good thing, but only having #meta 
> > is not enough for situation like the one you mention. That is why I am 
> > proposing to introduce a #secondaryMeta as a platform-independent modifier 
> > that would mean #alt on Win and #control on Mac. We could use that one more 
> > consistently. Is this a better explanation?
> >
> > Cheers,
> > Doru
> >
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Presenting is storytelling."
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "One cannot do more than one can do."

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

"When people car

Re: [Pharo-dev] GT-Spotter dive in shortcut

[Nicolai Hess]

2016-08-09 22:53 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Aug 9, 2016, at 10:48 PM, Nicolai Hess  wrote:
> >
> >
> >
> > 2016-08-09 18:12 GMT+02:00 Tudor Girba :
> > Hi,
> >
> > >
> > > Hey Doru,
> > > about what "two issues" are we talking? My only issue for now is,
> > > what shortcut shold we use for moving the cursor forward/backward
> word. Even if we introduce a new layer, at some point in time you need to
> > > define: If  the user types the CTRL+LEFT -key, even if we call it
> differently, some action happens, dive-out or move-backward-word ?
> > > At the moment (on windows) you can use both to move word-by-word:
> > > ctrl+left/right and alt+left/right, because this is how it is defined
> in rubrics action/cmdaction map.
> > >
> > > If we want to clean this up and use the kmdispatcher registration, I
> think we don't want to use both ctr and alt again, right?
> > > So, someone has to take the decision.
> > > I myself would prefer
> > > ctrl+left/right because this is what (all) many other programs are
> using on windows. Fine. But recently Spotter changed its
> > > dive in / dive out shortcut to use ctrl+left/right.
> > > Therefor I am asking you, why, and whether we want to keep it or not.
> If we want to keep it, we may
> > > - just overwrite the binding for the textfield -> not good, I think,
> you wouldn't be able to do word-by-word movements in the textfield anymore
> > > - overwrite the binding and use another binding for word-by-word
> moving, but just in spotters text field
> > > Or we revert that change and use the old shortcuts again.
> > > (And what to use for mac and linux?)
> > >
> > > but I am getting really tired of asking, and will do something else
> instead.
> >
> > The short answer: we will override the keybinding in the text morph for
> now. This will mean that we cannot move word by word in the text field
> using #control, but it will be consistent with all other platforms. Could
> you open an issue for this, please?
> >
> >
> > consistens on all platforms may not be the expectation for all users.
> Some users only working on a windows platform may want to have consistent
> behavior for all tools (applications).
>
> Well, you wanted a decision :).
>
>
> > On top of that, we will externalize all GTSpotter shortcuts through
> settings:
> > https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-
> should-be-externalized-as-settings
> >
> > I really don't know why that.
>
> Because we do not have a generic KMDispatcher mechanism :).
>

yes and it does not make much sense as not all shortcuts are handled by the
kmdispatcher, thats why cleaning this
up and I think it would be better to do this instead of implementing yet
another only-for-this-tool solution.


>
>
> > We don't need a way to make Spotter shortcuts configurable, but *all*
> shortcuts.
> > That is why I try to move all shortcut definitions to the kmdispatcher,
> but it yet again took 2 month just to discuss what shortcut to use for
> cursor movement.
>
> I am not sure I understand. Was this me that stalled the discussion? If
> yes, it was not intentional. Is there anything I can do about this subject?
>

The whole discussion, the me: "hey, what shortcut to use?" you:"hey we have
a great idea, just let us add some new layers" :(


>
> Cheers,
> Doru
>
>
> >
> > Long answer: As explained before, the shortcut changed in the process of
> making all shortcuts uniform when Guille introduced #meta instead of
> #command (like it was before). The thing is that currently:
> > - #command means #alt on Win and #command on Mac, and
> > - #meta means #control on Win and #command on Mac.
> >
> > But, #command should be a low level key, not a portable one. It should
> not have a meaning on Windows, because the key does not exist on that
> platform.
> >
> > Moving to make keybindings uniform is a good thing, but only having
> #meta is not enough for situation like the one you mention. That is why I
> am proposing to introduce a #secondaryMeta as a platform-independent
> modifier that would mean #alt on Win and #control on Mac. We could use that
> one more consistently. Is this a better explanation?
> >
> > Cheers,
> > Doru
> >
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Presenting is storytelling."
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "One cannot do more than one can do."
>
>
>
>
>
>

Re: [Pharo-dev] GT-Spotter dive in shortcut

[Tudor Girba]

Hi,

> On Aug 9, 2016, at 10:48 PM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-08-09 18:12 GMT+02:00 Tudor Girba :
> Hi,
> 
> >
> > Hey Doru,
> > about what "two issues" are we talking? My only issue for now is,
> > what shortcut shold we use for moving the cursor forward/backward word. 
> > Even if we introduce a new layer, at some point in time you need to
> > define: If  the user types the CTRL+LEFT -key, even if we call it 
> > differently, some action happens, dive-out or move-backward-word ?
> > At the moment (on windows) you can use both to move word-by-word:
> > ctrl+left/right and alt+left/right, because this is how it is defined in 
> > rubrics action/cmdaction map.
> >
> > If we want to clean this up and use the kmdispatcher registration, I think 
> > we don't want to use both ctr and alt again, right?
> > So, someone has to take the decision.
> > I myself would prefer
> > ctrl+left/right because this is what (all) many other programs are using on 
> > windows. Fine. But recently Spotter changed its
> > dive in / dive out shortcut to use ctrl+left/right.
> > Therefor I am asking you, why, and whether we want to keep it or not. If we 
> > want to keep it, we may
> > - just overwrite the binding for the textfield -> not good, I think, you 
> > wouldn't be able to do word-by-word movements in the textfield anymore
> > - overwrite the binding and use another binding for word-by-word moving, 
> > but just in spotters text field
> > Or we revert that change and use the old shortcuts again.
> > (And what to use for mac and linux?)
> >
> > but I am getting really tired of asking, and will do something else instead.
> 
> The short answer: we will override the keybinding in the text morph for now. 
> This will mean that we cannot move word by word in the text field using 
> #control, but it will be consistent with all other platforms. Could you open 
> an issue for this, please?
> 
> 
> consistens on all platforms may not be the expectation for all users. Some 
> users only working on a windows platform may want to have consistent behavior 
> for all tools (applications). 

Well, you wanted a decision :).


> On top of that, we will externalize all GTSpotter shortcuts through settings:
> https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-should-be-externalized-as-settings
> 
> I really don't know why that.

Because we do not have a generic KMDispatcher mechanism :).


> We don't need a way to make Spotter shortcuts configurable, but *all* 
> shortcuts.
> That is why I try to move all shortcut definitions to the kmdispatcher, but 
> it yet again took 2 month just to discuss what shortcut to use for cursor 
> movement.

I am not sure I understand. Was this me that stalled the discussion? If yes, it 
was not intentional. Is there anything I can do about this subject?

Cheers,
Doru


> 
> Long answer: As explained before, the shortcut changed in the process of 
> making all shortcuts uniform when Guille introduced #meta instead of #command 
> (like it was before). The thing is that currently:
> - #command means #alt on Win and #command on Mac, and
> - #meta means #control on Win and #command on Mac.
> 
> But, #command should be a low level key, not a portable one. It should not 
> have a meaning on Windows, because the key does not exist on that platform.
> 
> Moving to make keybindings uniform is a good thing, but only having #meta is 
> not enough for situation like the one you mention. That is why I am proposing 
> to introduce a #secondaryMeta as a platform-independent modifier that would 
> mean #alt on Win and #control on Mac. We could use that one more 
> consistently. Is this a better explanation?
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Presenting is storytelling."

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

"One cannot do more than one can do."

Re: [Pharo-dev] GT-Spotter dive in shortcut

[Nicolai Hess]

2016-08-09 18:12 GMT+02:00 Tudor Girba :

> Hi,
>
> >
> > Hey Doru,
> > about what "two issues" are we talking? My only issue for now is,
> > what shortcut shold we use for moving the cursor forward/backward word.
> Even if we introduce a new layer, at some point in time you need to
> > define: If  the user types the CTRL+LEFT -key, even if we call it
> differently, some action happens, dive-out or move-backward-word ?
> > At the moment (on windows) you can use both to move word-by-word:
> > ctrl+left/right and alt+left/right, because this is how it is defined in
> rubrics action/cmdaction map.
> >
> > If we want to clean this up and use the kmdispatcher registration, I
> think we don't want to use both ctr and alt again, right?
> > So, someone has to take the decision.
> > I myself would prefer
> > ctrl+left/right because this is what (all) many other programs are using
> on windows. Fine. But recently Spotter changed its
> > dive in / dive out shortcut to use ctrl+left/right.
> > Therefor I am asking you, why, and whether we want to keep it or not. If
> we want to keep it, we may
> > - just overwrite the binding for the textfield -> not good, I think, you
> wouldn't be able to do word-by-word movements in the textfield anymore
> > - overwrite the binding and use another binding for word-by-word moving,
> but just in spotters text field
> > Or we revert that change and use the old shortcuts again.
> > (And what to use for mac and linux?)
> >
> > but I am getting really tired of asking, and will do something else
> instead.
>
> The short answer: we will override the keybinding in the text morph for
> now. This will mean that we cannot move word by word in the text field
> using #control, but it will be consistent with all other platforms. Could
> you open an issue for this, please?
>
>
consistens on all platforms may not be the expectation for all users. Some
users only working on a windows platform may want to have consistent
behavior for all tools (applications).


> On top of that, we will externalize all GTSpotter shortcuts through
> settings:
> https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-
> should-be-externalized-as-settings


I really don't know why that. We don't need a way to make Spotter shortcuts
configurable, but *all* shortcuts.
That is why I try to move all shortcut definitions to the kmdispatcher, but
it yet again took 2 month just to discuss what shortcut to use for cursor
movement.


>
>
> Long answer: As explained before, the shortcut changed in the process of
> making all shortcuts uniform when Guille introduced #meta instead of
> #command (like it was before). The thing is that currently:
> - #command means #alt on Win and #command on Mac, and
> - #meta means #control on Win and #command on Mac.
>
> But, #command should be a low level key, not a portable one. It should not
> have a meaning on Windows, because the key does not exist on that platform.
>
> Moving to make keybindings uniform is a good thing, but only having #meta
> is not enough for situation like the one you mention. That is why I am
> proposing to introduce a #secondaryMeta as a platform-independent modifier
> that would mean #alt on Win and #control on Mac. We could use that one more
> consistently. Is this a better explanation?
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Presenting is storytelling."
>
>
>

Re: [Pharo-dev] let's talk about themes (and GLMBrickThemer)

[Tudor Girba]

Hi,

We would definitely benefit from a Palette.

One interesting concepts in Bloc2 is that the concrete values are injected in 
the widget, instead of having the widget ask for it. This is quite powerful 
because it enables a CSS mechanism (or another one), but we also have to see 
how it works with the requirement of changing these values dynamically. This 
will certainly be a next step after the core is stable.

Cheers,
Doru


> On Aug 9, 2016, at 3:03 PM, stepharo  wrote:
> 
> Hi doru
> 
> I think that this is particularly true (having a themer per widget) when the 
> themer is more a skinner (it changes behavior of the widgets), else we could 
> have addressed the problem with a solution close to setting. Two years ago I 
> played with theming and widgets hierarchy and I came to the same conclusion 
> (that your blog entries).
> Do you know how they do it in JavaFX? 
> I agree also that we should extract the Palette. 
> Now I'm really curious to see the CSS of Glenn in Bloc2.
> Stef
> 
> Le 4/8/16 à 12:52, Tudor Girba a écrit :
>> Hi Esteban,
>> 
>> Sorry for the delayed response.
>> 
>> There are two parts in your mail:
>> 1. the decomposition of theme to have one themer per widget
>> 2. a centralized catalog of values
>> 
>> I certainly agree with 2. In fact, when I refactored the theme colors a long 
>> time ago, I introduced a rudimentary reuse mechanism on the class side of 
>> the Theme class. So, now, we should extract those separately.
>> 
>> About 1., I have a different opinion. The hierarchy you mention already 
>> exists in the Theme class as well, only it is hidden, and it is very hard to 
>> see what each methods impacts.
>> 
>> Here is how I reached this conclusion. Take a look at this picture I 
>> produced before we started with Brick (the one from Morphic). The gray 
>> circles are methods in UITheme, and the red circles are typical Morphs (like 
>> TextMorph, ListMorph). The gray lines show self calls inside the UITheme, 
>> and the red lines shod calls from the morph to the UITheme methods. What you 
>> see here is a very strong clustering of the methods around the widgets, and 
>> this indicates that having a theme object per widget is appropriate.
>> 
>> 
>> 
>> 
>> 
>> A further constrain is that we want to be able to change the appearance of a 
>> widget on an instance basis (that is, overriding the default theme setting), 
>> and having a per-widget themer object, we can achieve that as well.
>> 
>> A similar design appears in Bloc as well, and I think it is actually more 
>> scalable then the current UITheme, provided that you indeed have a way to 
>> either centralize the definitions of colors (and other properties), or 
>> inject those properties from the outside.
>> 
>> All in all, let’s go ahead and extract the palette :).
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Aug 1, 2016, at 11:13 AM, Esteban Lorenzano  wrote:
>>> 
>>> Hi, 
>>> 
>>> For one of my side-projects, I made a new theme for Pharo (still no name, I 
>>> was planing to call it “Dark Metal” or something like that. Is a variation 
>>> on the Dark Theme but “our” dark theme is more brown and this one is more 
>>> blue (see attached)… I wanted to publish it to push it but then I arrived 
>>> to an unexpected problem: For Spotter and GTTools in general, theming is 
>>> not done following current theming approach. Instead, they made a full 
>>> hierarchy of objects. 
>>> 
>>> IMO this is plain bad. I understand the attempt to decouple, but now that 
>>> means if I want to create a new theme, I need to create my theme object 
>>> with colors I want and then also I need to create an undetermined number of 
>>> classes (at least one for each tool, but there is also a hierarchy of 
>>> things there)… anyway, this DOES NOT scale. Because each tool will have to 
>>> have a “theme class” for each existing theme…  
>>> How themes (skins, bah) work in all word is to have a color palette and 
>>> then tools takes them (they can “play” a bit with this palette, but need to 
>>> always respect the palette). 
>>> 
>>> Then, I will commit a SLICE modifying the “themer” classes to take colors 
>>> from the current theme (instead of have them hardcoded). 
>>> But of course, how theme work now is not good because they mix “theme” (how 
>>> they display) and “skin” (color palette). I will also extract the palette 
>>> to where should have always been (some kind of a style sheet object)… who 
>>> also should have been editable in settings so people can tweak their 
>>> configuration. 
>>> 
>>> I didn’t wanted to touch this before, because this will supposedly change 
>>> with brick, but honestly this will not be ready for Pharo 6 and this is 
>>> annoying (also, I want to publish my theme and I do not want to add 
>>> overrides all around :P)
>>> 
>>> cheers,
>>> Esteban
>>> 
>>> 
>>> 
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Innovation comes in the least expected form. 
>> That is, if it is expected, it already happened."

Re: [Pharo-dev] request for improvements in GTInspector or debugger

[Tudor Girba]

Hi,

In which presentation are you?

As Sven said, you can browse by clicking on the top right icon of the next 
pane. You can also browse right in place with the Meta presentation from the 
next pane.

Also, if you are in the Raw view, you get the browse menu for an instance 
variable. However, this menu is hardcoded and for other presentations, this 
menu is indeed not available. I think this is a missing feature. In fact, we 
already have that in Moose and it works quite well: an omni-present object 
menu. The idea is that once we declare object actions (those available on the 
top right of an object pane), we could also offer them as a menu, and add them 
throughout the interface. Would this address your issue?

Cheers,
Doru


> On Aug 9, 2016, at 7:44 PM, Sven Van Caekenberghe  wrote:
> 
> You can already do that: click the icon at the top right of the window 
> 'Browse':
> 
> 
>> On 09 Aug 2016, at 19:23, stepharo  wrote:
>> 
>> Here is my scenario.
>> 
>> I have a field that contains aCZWhatever
>> 
>> the inspector shows me a list
>> 
>> 
>> field aCZWhatever
>> 
>> I can edit the aCZWhatever since I can click on it and get an input fiedl 
>> (or what I thought is an input field).
>> 
>> I can select CZWhatever but I cannot do browse on it. So I have to use 
>> Spotter.
>> 
>> 
>> Stef
>> 
>> 
> 

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

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."

Re: [Pharo-dev] request for improvements in GTInspector or debugger

[Sven Van Caekenberghe]

You can already do that: click the icon at the top right of the window 'Browse':


> On 09 Aug 2016, at 19:23, stepharo  wrote:
> 
> Here is my scenario.
> 
> I have a field that contains aCZWhatever
> 
> the inspector shows me a list
> 
> 
> field aCZWhatever
> 
> I can edit the aCZWhatever since I can click on it and get an input fiedl (or 
> what I thought is an input field).
> 
> I can select CZWhatever but I cannot do browse on it. So I have to use 
> Spotter.
> 
> 
> Stef
> 
> 

Re: [Pharo-dev] Epicea redoVisitor does not handle protocol changes

[stepharo]

Ah, you can try:

Metacello new
smalltalkhubUser: 'MartinDias' project: 'Epicea';
configuration: 'Epicea';
version: '7.98';
load.

you should be working in a Pharo 6 that has an old Epicea version.


ah yes I should migrate. I took an old pillar image.
I will change now.

Stef



Martin

On Tue, Aug 9, 2016 at 11:19 AM, Martin Dias > wrote:


Hi,
I'm looking at it. Vincent reported it a couple of weeks ago and I
fixed it (apparently not?!)

Martin

On Tue, Aug 9, 2016 at 8:56 AM, stepharo mailto:steph...@free.fr>> wrote:

Hi

I just tried to replay a change today in Pharo60 and I got an
error in epicea.

EpRedoVisitor>>visitEvent: aChange
^ self error: 'Should not be reached'.

EpRedoVisitor>>visitCodeChange: aChange
"Default behavior for any change."

^ self visitEvent: aChange

EpRedoVisitor>>visitBehaviorChange: aChange
^ self visitCodeChange: aChange

EpRedoVisitor>>visitProtocolChange: aProtocolAddition
^ self visitBehaviorChange: aProtocolAddition.


visitProtocolAddition: aProtocolAddition
^ self visitProtocolChange: aProtocolAddition


Apparently it was a

EpProtocolAddition


And the RedoVisitor does not handle them.

I do not have the time to check further - I just want to
rescue my code for now.


Stef

Re: [Pharo-dev] Epicea redoVisitor does not handle protocol changes

[stepharo]

tx martin.

Stef


Le 9/8/16 à 16:19, Martin Dias a écrit :

Hi,
I'm looking at it. Vincent reported it a couple of weeks ago and I 
fixed it (apparently not?!)


Martin

On Tue, Aug 9, 2016 at 8:56 AM, stepharo > wrote:


Hi

I just tried to replay a change today in Pharo60 and I got an
error in epicea.

EpRedoVisitor>>visitEvent: aChange
^ self error: 'Should not be reached'.

EpRedoVisitor>>visitCodeChange: aChange
"Default behavior for any change."

^ self visitEvent: aChange

EpRedoVisitor>>visitBehaviorChange: aChange
^ self visitCodeChange: aChange

EpRedoVisitor>>visitProtocolChange: aProtocolAddition
^ self visitBehaviorChange: aProtocolAddition.


visitProtocolAddition: aProtocolAddition
^ self visitProtocolChange: aProtocolAddition


Apparently it was a

EpProtocolAddition


And the RedoVisitor does not handle them.

I do not have the time to check further - I just want to rescue my
code for now.


Stef

Re: [Pharo-dev] DNU with GT Debugger

[stepharo]

Good!

I should say that my superpowers to find bugs and glitches is hyper 
frustrating.




Le 9/8/16 à 18:10, Tudor Girba a écrit :

Hi,

Thanks. I could reproduce the problem and I extracted a simpler case:
https://pharo.fogbugz.com/f/cases/18899/Raw-presentation-from-the-debugger-inspector-raises-error-when-the-rawSelection-comes-from-another-presentation

Cheers,
Doru



On Aug 9, 2016, at 2:00 PM, stepharo  wrote:

Hi doru


I sent you a drop box where you just have to click to repeat the problem.

Let me know if this is enough. Else I should send you more scripts and files.

Stef


Le 9/8/16 à 12:07, Tudor Girba a écrit :

Hi,

Thanks for the report. Do you happen to have an image around?

Doru



On Aug 9, 2016, at 11:47 AM, stepharo  wrote:

While trying to debug pillar I got a DNU when clicking on the raw pane (when 
the items was selected)

DNU:

presentation rawSelection is aLinkedList and it does not understand key




'From Pharo 6.0 of 13 May 2016 [Latest update: #60173] on 9 August 2016 at 
11:45:10.355092 am'!

!GTRawObjectVariablesBrowser methodsFor: 'private building' stamp: 'AndreiChis 
4/26/2016 10:37'!
variablesIn: composite
^ composite table
showOnly: 50;
shouldValidate: false;
allowsRecursiveSearch: false;
children: [ :assoc |
assoc key = 'self'
ifTrue: [ #() ]
ifFalse: [ self variableValuePairsFor: assoc value ] ];
icon: [ :assoc | self iconFor: assoc value ];
display: [ :anObject |
self rebuildCacheFor: anObject.
self variableValuePairsFor: anObject ];
column: 'Variable'
evaluated: [:assoc | '  ', (GTObjectPrinter new 
asNonTruncatedTextFrom: assoc key) ];
column: 'Value'
evaluated: [:assoc | GTObjectPrinter new asTruncatedTextFrom: assoc 
value ]
modified: [:newValue :assoc :presentation |
self updateInstanceVariable: assoc key from: presentation 
entity basedOn: newValue.
presentation update ];
morphicSelectionAct: [:list | list selection value browse ]
icon: GLMUIThemeExtraIcons glamorousBrowse
on: $b
entitled: 'Browse';
morphicSelectionAct: [:list | list selection value inspect ]
icon: GLMUIThemeExtraIcons glamorousInspect
on: $i
entitled: 'Inspect';
selectionAct: [:list |
((list selection pointersToExcept: { list selection })
reject: [ :each | each pointsOnlyWeaklyTo: 
list selection ]) inspect ]
on: $t
entitled: 'Open pointers to';
dynamicActionsOnSelection: [ :presentation |
(presentation entity class hasInstVarNamed: presentation 
rawSelection key)

   here



ifTrue: [
{
GLMGenericAction new
action: [:list | self systemNavigation 
browseAllAccessesTo: list rawSelection key from: list entity class ];
title: 'List methods using this variable'.
GLMGenericAction new
action: [:list | self systemNavigation 
browseAllStoresInto: list rawSelection key from: list entity class ];
title: 'List methods storing into this 
variable'.
}
]
ifFalse: [ #() ] ]! !



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

"Reasonable is what we are accustomed with."






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

"Innovation comes in the least expected form.
That is, if it is expected, it already happened."

Re: [Pharo-dev] let's talk about themes (and GLMBrickThemer)

[stepharo]

:)

Stef

[Pharo-dev] request for improvements in GTInspector or debugger

[stepharo]

Here is my scenario.

I have a field that contains aCZWhatever

the inspector shows me a list


field aCZWhatever

I can edit the aCZWhatever since I can click on it and get an input 
fiedl (or what I thought is an input field).


I can select CZWhatever but I cannot do browse on it. So I have to use 
Spotter.



Stef

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 354532: 60176

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 354532ec04aa92b596cfd5e5cd0e097b5f2de945
  
https://github.com/pharo-project/pharo-core/commit/354532ec04aa92b596cfd5e5cd0e097b5f2de945
  Author: Jenkins Build Server 
  Date:   2016-08-09 (Tue, 09 Aug 2016)

  Changed paths:
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60175.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60176.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60175.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60176.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Text-Core.package/extension/VTermOutputDriver/class/printText_.st

  Log Message:
  ---
  60176
18897 Monkey crashing with MessageNotUnderstood: VTermOutputDriver>>color256:
https://pharo.fogbugz.com/f/cases/18897

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

Re: [Pharo-dev] let's talk about themes (and GLMBrickThemer)

[Yuriy Tymchuk]

Sorry, couldn’t help putting this here. Each time I hear that there is a CSS 
usage outside of web I think about this mug:




> On 09 Aug 2016, at 15:03, stepharo  wrote:
> 
> Hi doru
> 
> I think that this is particularly true (having a themer per widget) when the 
> themer is more a skinner (it changes behavior of the widgets), else we could 
> have addressed the problem with a solution close to setting. Two years ago I 
> played with theming and widgets hierarchy and I came to the same conclusion 
> (that your blog entries).
> Do you know how they do it in JavaFX? 
> I agree also that we should extract the Palette. 
> Now I'm really curious to see the CSS of Glenn in Bloc2.
> Stef
> 
> Le 4/8/16 à 12:52, Tudor Girba a écrit :
>> Hi Esteban,
>> 
>> Sorry for the delayed response.
>> 
>> There are two parts in your mail:
>> 1. the decomposition of theme to have one themer per widget
>> 2. a centralized catalog of values
>> 
>> I certainly agree with 2. In fact, when I refactored the theme colors a long 
>> time ago, I introduced a rudimentary reuse mechanism on the class side of 
>> the Theme class. So, now, we should extract those separately.
>> 
>> About 1., I have a different opinion. The hierarchy you mention already 
>> exists in the Theme class as well, only it is hidden, and it is very hard to 
>> see what each methods impacts.
>> 
>> Here is how I reached this conclusion. Take a look at this picture I 
>> produced before we started with Brick (the one from Morphic). The gray 
>> circles are methods in UITheme, and the red circles are typical Morphs (like 
>> TextMorph, ListMorph). The gray lines show self calls inside the UITheme, 
>> and the red lines shod calls from the morph to the UITheme methods. What you 
>> see here is a very strong clustering of the methods around the widgets, and 
>> this indicates that having a theme object per widget is appropriate.
>> 
>> 
>> 
>> 
>> 
>> A further constrain is that we want to be able to change the appearance of a 
>> widget on an instance basis (that is, overriding the default theme setting), 
>> and having a per-widget themer object, we can achieve that as well.
>> 
>> A similar design appears in Bloc as well, and I think it is actually more 
>> scalable then the current UITheme, provided that you indeed have a way to 
>> either centralize the definitions of colors (and other properties), or 
>> inject those properties from the outside.
>> 
>> All in all, let’s go ahead and extract the palette :).
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Aug 1, 2016, at 11:13 AM, Esteban Lorenzano >> > wrote:
>>> 
>>> Hi, 
>>> 
>>> For one of my side-projects, I made a new theme for Pharo (still no name, I 
>>> was planing to call it “Dark Metal” or something like that. Is a variation 
>>> on the Dark Theme but “our” dark theme is more brown and this one is more 
>>> blue (see attached)… I wanted to publish it to push it but then I arrived 
>>> to an unexpected problem: For Spotter and GTTools in general, theming is 
>>> not done following current theming approach. Instead, they made a full 
>>> hierarchy of objects. 
>>> 
>>> IMO this is plain bad. I understand the attempt to decouple, but now that 
>>> means if I want to create a new theme, I need to create my theme object 
>>> with colors I want and then also I need to create an undetermined number of 
>>> classes (at least one for each tool, but there is also a hierarchy of 
>>> things there)… anyway, this DOES NOT scale. Because each tool will have to 
>>> have a “theme class” for each existing theme…  
>>> How themes (skins, bah) work in all word is to have a color palette and 
>>> then tools takes them (they can “play” a bit with this palette, but need to 
>>> always respect the palette). 
>>> 
>>> Then, I will commit a SLICE modifying the “themer” classes to take colors 
>>> from the current theme (instead of have them hardcoded). 
>>> But of course, how theme work now is not good because they mix “theme” (how 
>>> they display) and “skin” (color palette). I will also extract the palette 
>>> to where should have always been (some kind of a style sheet object)… who 
>>> also should have been editable in settings so people can tweak their 
>>> configuration. 
>>> 
>>> I didn’t wanted to touch this before, because this will supposedly change 
>>> with brick, but honestly this will not be ready for Pharo 6 and this is 
>>> annoying (also, I want to publish my theme and I do not want to add 
>>> overrides all around :P)
>>> 
>>> cheers,
>>> Esteban
>>> 
>>> 
>>> 
>> 
>> --
>> www.tudorgirba.com 
>> www.feenk.com 
>> 
>> "Innovation comes in the least expected form. 
>> That is, if it is expected, it already happened."
>> 
> 

Re: [Pharo-dev] GT-Spotter dive in shortcut

[Tudor Girba]

Hi,

> 
> Hey Doru,
> about what "two issues" are we talking? My only issue for now is, 
> what shortcut shold we use for moving the cursor forward/backward word. Even 
> if we introduce a new layer, at some point in time you need to
> define: If  the user types the CTRL+LEFT -key, even if we call it 
> differently, some action happens, dive-out or move-backward-word ?
> At the moment (on windows) you can use both to move word-by-word:
> ctrl+left/right and alt+left/right, because this is how it is defined in 
> rubrics action/cmdaction map.
> 
> If we want to clean this up and use the kmdispatcher registration, I think we 
> don't want to use both ctr and alt again, right?
> So, someone has to take the decision.
> I myself would prefer
> ctrl+left/right because this is what (all) many other programs are using on 
> windows. Fine. But recently Spotter changed its
> dive in / dive out shortcut to use ctrl+left/right. 
> Therefor I am asking you, why, and whether we want to keep it or not. If we 
> want to keep it, we may
> - just overwrite the binding for the textfield -> not good, I think, you 
> wouldn't be able to do word-by-word movements in the textfield anymore
> - overwrite the binding and use another binding for word-by-word moving, but 
> just in spotters text field 
> Or we revert that change and use the old shortcuts again.
> (And what to use for mac and linux?)
> 
> but I am getting really tired of asking, and will do something else instead. 

The short answer: we will override the keybinding in the text morph for now. 
This will mean that we cannot move word by word in the text field using 
#control, but it will be consistent with all other platforms. Could you open an 
issue for this, please?

On top of that, we will externalize all GTSpotter shortcuts through settings:
https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-should-be-externalized-as-settings

Long answer: As explained before, the shortcut changed in the process of making 
all shortcuts uniform when Guille introduced #meta instead of #command (like it 
was before). The thing is that currently:
- #command means #alt on Win and #command on Mac, and
- #meta means #control on Win and #command on Mac.

But, #command should be a low level key, not a portable one. It should not have 
a meaning on Windows, because the key does not exist on that platform.

Moving to make keybindings uniform is a good thing, but only having #meta is 
not enough for situation like the one you mention. That is why I am proposing 
to introduce a #secondaryMeta as a platform-independent modifier that would 
mean #alt on Win and #control on Mac. We could use that one more consistently. 
Is this a better explanation?

Cheers,
Doru


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

"Presenting is storytelling."

Re: [Pharo-dev] DNU with GT Debugger

[Tudor Girba]

Hi,

Thanks. I could reproduce the problem and I extracted a simpler case:
https://pharo.fogbugz.com/f/cases/18899/Raw-presentation-from-the-debugger-inspector-raises-error-when-the-rawSelection-comes-from-another-presentation

Cheers,
Doru


> On Aug 9, 2016, at 2:00 PM, stepharo  wrote:
> 
> Hi doru
> 
> 
> I sent you a drop box where you just have to click to repeat the problem.
> 
> Let me know if this is enough. Else I should send you more scripts and files.
> 
> Stef
> 
> 
> Le 9/8/16 à 12:07, Tudor Girba a écrit :
>> Hi,
>> 
>> Thanks for the report. Do you happen to have an image around?
>> 
>> Doru
>> 
>> 
>>> On Aug 9, 2016, at 11:47 AM, stepharo  wrote:
>>> 
>>> While trying to debug pillar I got a DNU when clicking on the raw pane 
>>> (when the items was selected)
>>> 
>>> DNU:
>>> 
>>> presentation rawSelection is aLinkedList and it does not understand key
>>> 
>>> 
>>> 
>>> 
>>> 'From Pharo 6.0 of 13 May 2016 [Latest update: #60173] on 9 August 2016 at 
>>> 11:45:10.355092 am'!
>>> 
>>> !GTRawObjectVariablesBrowser methodsFor: 'private building' stamp: 
>>> 'AndreiChis 4/26/2016 10:37'!
>>> variablesIn: composite
>>>^ composite table
>>>showOnly: 50;
>>>shouldValidate: false;
>>>allowsRecursiveSearch: false;
>>>children: [ :assoc |
>>>assoc key = 'self'
>>>ifTrue: [ #() ]
>>>ifFalse: [ self variableValuePairsFor: assoc value ] ];
>>>icon: [ :assoc | self iconFor: assoc value ];
>>>display: [ :anObject |
>>>self rebuildCacheFor: anObject.
>>>self variableValuePairsFor: anObject ];
>>>column: 'Variable'
>>>evaluated: [:assoc | '  ', (GTObjectPrinter new 
>>> asNonTruncatedTextFrom: assoc key) ];
>>>column: 'Value'
>>>evaluated: [:assoc | GTObjectPrinter new asTruncatedTextFrom: 
>>> assoc value ]
>>>modified: [:newValue :assoc :presentation |
>>>self updateInstanceVariable: assoc key from: presentation 
>>> entity basedOn: newValue.
>>>presentation update ];
>>>morphicSelectionAct: [:list | list selection value browse ]
>>>icon: GLMUIThemeExtraIcons glamorousBrowse
>>>on: $b
>>>entitled: 'Browse';
>>>morphicSelectionAct: [:list | list selection value inspect ]
>>>icon: GLMUIThemeExtraIcons glamorousInspect
>>>on: $i
>>>entitled: 'Inspect';
>>>selectionAct: [:list |
>>>((list selection pointersToExcept: { list selection })
>>>reject: [ :each | each 
>>> pointsOnlyWeaklyTo: list selection ]) inspect ]
>>>on: $t
>>>entitled: 'Open pointers to';
>>>dynamicActionsOnSelection: [ :presentation |
>>>(presentation entity class hasInstVarNamed: presentation 
>>> rawSelection key)
>>> 
>>>   here
>>> 
>>> 
>>> 
>>>ifTrue: [
>>>{
>>>GLMGenericAction new
>>>action: [:list | self systemNavigation 
>>> browseAllAccessesTo: list rawSelection key from: list entity class ];
>>>title: 'List methods using this variable'.
>>>GLMGenericAction new
>>>action: [:list | self systemNavigation 
>>> browseAllStoresInto: list rawSelection key from: list entity class ];
>>>title: 'List methods storing into this 
>>> variable'.
>>>}
>>>]
>>>ifFalse: [ #() ] ]! !
>>> 
>>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Reasonable is what we are accustomed with."
>> 
>> 
>> 
> 
> 

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

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."

Re: [Pharo-dev] Out of ideas...

[Casimiro - GMAIL]

Em 08-08-2016 19:25, Bernardo Ezequiel Contreras escreveu:
> Hi,
>
>   have you try with  (World>>Help>>Help Browser>>Regular Expressions
> Framework>>Usage)
>
> SUBEXPRESSION MATCHES
>
> After a successful match attempt, you can query the specifics of which
> part of the original string has matched which part of the whole
> expression.
>
> (...)
Thanks, but thing is: my need is little more complex than finding
sequences. I'm looking for expressions in natural language text. The
expressions must be extracted without ambiguities so I have cases for
occurrences in the beginning of line (aka '^(#\w+)([\s.,;\:!?]*)') in
the middle of the line (aka '([\s.,;\:!?]+)(#\w+)([\s.,;\:!?]+)') or at
the end (which may be simplified to the second case...). So, if I find
several hashtags in a text like:

'A política no Brasil está complicada #FAIL porque a corrupção impera
#CRIME. De qualquer forma os #PETRALHAS, que tudo justificam, levam o
país ao #CAOS'

I want two things:

1st and obvious: #( '#FAIL' '#CRIME' '#PETRALHAS' '#CAOS')
2nd: the line minus hashtags: 'A política no Brasil está complicada
porque a corrupção impera. De qualquer forma os, que tudo justificam,
levam o país ao'

When I use regexps to process the line, for instance:

bfr := line copyWithRegex: '#\w+' matchesReplacedUsing [ :e | '' ].

I can have trouble because it will extract things like #ANOTAÇÃO# which
is not a hashtag but will match.

And I'm trying to avoid doing the Lex/Yacc thing here :D

Best regards,

CdAB

-- 
The information contained in this message is confidential and intended
to the recipients specified in the headers. If you received this message
by error, notify the sender immediately. The unauthorized use,
disclosure, copy or alteration of this message are strictly forbidden
and subjected to civil and criminal sanctions.

==

This email may be signed using PGP key *ID: 0x4134A417*


signature.asc
Description: OpenPGP digital signature

[Pharo-dev] [pharo-project/pharo-core] 44801d: 60175

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 44801dd18088fe36485d2b5f19dcfb5754824c53
  
https://github.com/pharo-project/pharo-core/commit/44801dd18088fe36485d2b5f19dcfb5754824c53
  Author: Jenkins Build Server 
  Date:   2016-08-09 (Tue, 09 Aug 2016)

  Changed paths:
M 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F23_.st
M OpalCompiler-Core.package/OpalEncoderForSistaV1.class/README.md
M OpalCompiler-Core.package/OpalEncoderForSistaV1.class/instance/bytecode 
generation/genPushNClosureTemps_.st
M OpalCompiler-Core.package/OpalEncoderForSistaV1.class/instance/extended 
bytecode 
generation/genPushFullClosure_numCopied_receiverOnStack_outerContextNeeded_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60174.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60175.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60174.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60175.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/whenSelectedItemChangesOnListModel.st
M Tools-Test.package/MethodFinderTest.class/instance/test 
examples/testGreaterThanANumber.st
M Tools-Test.package/MethodFinderTest.class/instance/test 
examples/testSearchForOne.st
M 
UnifiedFFI.package/FFIExternalPackedStructure.class/class/private/compileFields_withAccessors_.st
M 
UnifiedFFI.package/FFIExternalStructure.class/class/private/compileFields_withAccessors_.st
M 
UnifiedFFI.package/FFIExternalStructureFieldParser.class/instance/parsing/parseFields_structure_.st
M UnifiedFFI.package/FFIExternalType.class/class/accessing/pointerSize.st
M 
UnifiedFFI.package/FFIExternalUnion.class/class/private/compileFields_withAccessors_.st

  Log Message:
  ---
  60175
18891 MethodFinderTest>>#testGreaterThanANumber is dependent on order
https://pharo.fogbugz.com/f/cases/18891

18889 CriticsBrowser "BlockCannotReturn"
https://pharo.fogbugz.com/f/cases/18889

18896 add support for ignored fields in structures
https://pharo.fogbugz.com/f/cases/18896

18898 Sista Encoder update for release.
https://pharo.fogbugz.com/f/cases/18898

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

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

[GitHub]

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

Re: [Pharo-dev] Epicea redoVisitor does not handle protocol changes

[Martin Dias]

Ah, you can try:

Metacello new
smalltalkhubUser: 'MartinDias' project: 'Epicea';
configuration: 'Epicea';
version: '7.98';
load.

you should be working in a Pharo 6 that has an old Epicea version.

Martin

On Tue, Aug 9, 2016 at 11:19 AM, Martin Dias  wrote:

> Hi,
> I'm looking at it. Vincent reported it a couple of weeks ago and I fixed
> it (apparently not?!)
>
> Martin
>
> On Tue, Aug 9, 2016 at 8:56 AM, stepharo  wrote:
>
>> Hi
>>
>> I just tried to replay a change today in Pharo60 and I got an error in
>> epicea.
>>
>> EpRedoVisitor>>visitEvent: aChange
>> ^ self error: 'Should not be reached'.
>>
>> EpRedoVisitor>>visitCodeChange: aChange
>> "Default behavior for any change."
>>
>> ^ self visitEvent: aChange
>>
>> EpRedoVisitor>>visitBehaviorChange: aChange
>> ^ self visitCodeChange: aChange
>>
>> EpRedoVisitor>>visitProtocolChange: aProtocolAddition
>> ^ self visitBehaviorChange: aProtocolAddition.
>>
>>
>> visitProtocolAddition: aProtocolAddition
>> ^ self visitProtocolChange: aProtocolAddition
>>
>>
>> Apparently it was a
>>
>> EpProtocolAddition
>>
>>
>> And the RedoVisitor does not handle them.
>>
>> I do not have the time to check further - I just want to rescue my code
>> for now.
>>
>>
>> Stef
>>
>>
>>
>

Re: [Pharo-dev] Epicea redoVisitor does not handle protocol changes

[Martin Dias]

Hi,
I'm looking at it. Vincent reported it a couple of weeks ago and I fixed it
(apparently not?!)

Martin

On Tue, Aug 9, 2016 at 8:56 AM, stepharo  wrote:

> Hi
>
> I just tried to replay a change today in Pharo60 and I got an error in
> epicea.
>
> EpRedoVisitor>>visitEvent: aChange
> ^ self error: 'Should not be reached'.
>
> EpRedoVisitor>>visitCodeChange: aChange
> "Default behavior for any change."
>
> ^ self visitEvent: aChange
>
> EpRedoVisitor>>visitBehaviorChange: aChange
> ^ self visitCodeChange: aChange
>
> EpRedoVisitor>>visitProtocolChange: aProtocolAddition
> ^ self visitBehaviorChange: aProtocolAddition.
>
>
> visitProtocolAddition: aProtocolAddition
> ^ self visitProtocolChange: aProtocolAddition
>
>
> Apparently it was a
>
> EpProtocolAddition
>
>
> And the RedoVisitor does not handle them.
>
> I do not have the time to check further - I just want to rescue my code
> for now.
>
>
> Stef
>
>
>

Re: [Pharo-dev] Pharo5 Jenkins build crash

[Cyril Ferlicot Delbecque]

On 09/08/2016 14:01, Yann Dubois wrote:
> Hi,
> 
> Since Sunday, all build launched for Pharo 5 crashed
> 

Hi,

Those are known bugs. It happen on all Jenkins. There is a fogbugs issue
for it.

> 
> I think that the problem is in command line handler but I'm not sure. You can 
> see the complete log, for example, at 
> https://ci.inria.fr/pharo-contribution/job/Pillar/1715/PHARO=50,VERSION=stable,VM=vm/console
> 

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Iceberg in general

[Peter Uhnák]

> I can not tell if it would work on Pharo 5.0.

I using IceBerg on Pharo 5.

On Tue, Aug 9, 2016 at 2:10 PM, Norbert Hartl  wrote:

> I've checked again on pharo6 and get the same error.
>
> - downloaded pharo6
>
> - Metacello new
>  baseline: 'Iceberg';
>  repository: 'github://npasserini/iceberg:stable';
>  load.
>
> - openend UI via tools/Iceberg
>
> - click "Clone new repository"
>
> Same error as in pharo5. Cannot parse URL
>
> I've created an issue
>
> Norbert
>
> Am 09.08.2016 um 14:00 schrieb Nicolas Passerini :
>
> Hi Norbert,
>
> Up to date, Iceberg has only been developed/used/tested on Pharo 6.0,
> please look at the prerrequisites in https://github.com/npasserini/iceberg.
> I can not tell if it would work on Pharo 5.0.
>
> Either way, if you could submit a bug report I will happily pay a look at
> it.
>
> On Tue, Aug 9, 2016 at 1:55 PM, Peter Uhnák  wrote:
>
>>
>>
>> On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl  wrote:
>>
>>> I'm using pharo5 and I wonder we is this version marked as stable
>>
>>
>> The readme states:
>>
>> "This is still a prototype and is not yet ready for production, but you
>> are invited to try it and provide feedback. "
>>
>> Note however that I've successfully started using it for smaller
>> project(s) that are hosted on GitHub. Of course there's a lot of issues
>> https://github.com/npasserini/iceberg/issues , but it can be forced to
>> work if you are willing to live on the edge. :)
>>
>> Regarding your error, it would be best to submit a bug report.
>>
>> Peter
>>
>
>
>

[Pharo-dev] [pharo-project/pharo-core] 3c4689: 60174

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 3c46899a2ee045db8515d52e3e13ed1c340a7e56
  
https://github.com/pharo-project/pharo-core/commit/3c46899a2ee045db8515d52e3e13ed1c340a7e56
  Author: Jenkins Build Server 
  Date:   2016-08-09 (Tue, 09 Aug 2016)

  Changed paths:
M AST-Core.package/RBParser.class/instance/private-parsing/parseBlock.st
A AST-Core.package/RBSequenceNode.class/instance/adding 
nodes/addFaultyNode_.st
M AST-Tests-Core.package/RBParserTest.class/instance/tests 
parsing/testParseUnfinishedBlockWithFaultyBody.st
M 
Monticello-Tests.package/MCStWriterTest.class/instance/data/expectedClassMethodDefinition.st
M 
Monticello-Tests.package/MCStWriterTest.class/instance/data/expectedMethodDefinition.st
M 
Monticello-Tests.package/MCStWriterTest.class/instance/testing/testClassMethodDefinition.st
M 
Monticello-Tests.package/MCStWriterTest.class/instance/testing/testMethodDefinition.st
M OpalCompiler-Core.package/extension/Context/instance/isBlockReturn_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60173.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60174.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60173.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60174.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60174
18890 Parser cant not parse faulty or unfinished blocks with return caret
https://pharo.fogbugz.com/f/cases/18890

18893 MCStWriterTest>>#expectedClassMethodDefinition will always fail on 
bootstrapped image
https://pharo.fogbugz.com/f/cases/18893

18892 simplify isBlockReturn: to use encoder
https://pharo.fogbugz.com/f/cases/18892

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

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

[GitHub]

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

Re: [Pharo-dev] Bloc, Bloc 2 and Brick

[stepharo]

Le 7/8/16 à 17:01, webwarrior a écrit :

stepharo wrote

...

  In June we spent three days to understand if we should merge Bloc2
into Bloc and we decided the inverse because
  his implementation is based on SDL and a separate window) it does
not suffer from the morphic plague. So for example
  the event bubbling is nice and clean. The idea is to be able to use
one window (morphic) to develop
  all the widgets and displayed in the SDL window needed up to the
point where we can remove morphic.

...

Does that mean that Bloc will only work in separate window until Morphic is
fully replaced and removed from the image?

Yes.

That would take many years I guess.

Not really. Once we have nice widgets we can go fast.
Especially since we started to do it by using things like Spec.

And before that, all tools like debugger etc. will open themselves in host
(Morphic) window?

Yes.
I can tell you that it was not an easy solution when I see the pain that
alain got to make Bloc worked within morphic but the pay load was too high.

Stef






--
View this message in context: 
http://forum.world.st/Bloc-Bloc-2-and-Brick-tp4909112p4909861.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Iceberg in general

[Norbert Hartl]

I've checked again on pharo6 and get the same error.

- downloaded pharo6

- Metacello new
 baseline: 'Iceberg';
 repository: 'github://npasserini/iceberg:stable';
 load.

- openend UI via tools/Iceberg

- click "Clone new repository"

Same error as in pharo5. Cannot parse URL

I've created an issue

Norbert
> Am 09.08.2016 um 14:00 schrieb Nicolas Passerini :
> 
> Hi Norbert, 
> 
> Up to date, Iceberg has only been developed/used/tested on Pharo 6.0, please 
> look at the prerrequisites in https://github.com/npasserini/iceberg 
> . I can not tell if it would work on 
> Pharo 5.0.
> 
> Either way, if you could submit a bug report I will happily pay a look at it.
> 
> On Tue, Aug 9, 2016 at 1:55 PM, Peter Uhnák  > wrote:
> 
> 
> On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl  > wrote:
> I'm using pharo5 and I wonder we is this version marked as stable
> 
> The readme states:
> 
> "This is still a prototype and is not yet ready for production, but you are 
> invited to try it and provide feedback. "
> 
> Note however that I've successfully started using it for smaller project(s) 
> that are hosted on GitHub. Of course there's a lot of issues 
> https://github.com/npasserini/iceberg/issues 
>  , but it can be forced to work 
> if you are willing to live on the edge. :)
> 
> Regarding your error, it would be best to submit a bug report.
> 
> Peter
> 

Re: [Pharo-dev] DNU with GT Debugger

[stepharo]

Hi doru


I sent you a drop box where you just have to click to repeat the problem.

Let me know if this is enough. Else I should send you more scripts and 
files.


Stef


Le 9/8/16 à 12:07, Tudor Girba a écrit :

Hi,

Thanks for the report. Do you happen to have an image around?

Doru



On Aug 9, 2016, at 11:47 AM, stepharo  wrote:

While trying to debug pillar I got a DNU when clicking on the raw pane (when 
the items was selected)

DNU:

presentation rawSelection is aLinkedList and it does not understand key




'From Pharo 6.0 of 13 May 2016 [Latest update: #60173] on 9 August 2016 at 
11:45:10.355092 am'!

!GTRawObjectVariablesBrowser methodsFor: 'private building' stamp: 'AndreiChis 
4/26/2016 10:37'!
variablesIn: composite
^ composite table
showOnly: 50;
shouldValidate: false;
allowsRecursiveSearch: false;
children: [ :assoc |
assoc key = 'self'
ifTrue: [ #() ]
ifFalse: [ self variableValuePairsFor: assoc value ] ];
icon: [ :assoc | self iconFor: assoc value ];
display: [ :anObject |
self rebuildCacheFor: anObject.
self variableValuePairsFor: anObject ];
column: 'Variable'
evaluated: [:assoc | '  ', (GTObjectPrinter new 
asNonTruncatedTextFrom: assoc key) ];
column: 'Value'
evaluated: [:assoc | GTObjectPrinter new asTruncatedTextFrom: assoc 
value ]
modified: [:newValue :assoc :presentation |
self updateInstanceVariable: assoc key from: presentation 
entity basedOn: newValue.
presentation update ];
morphicSelectionAct: [:list | list selection value browse ]
icon: GLMUIThemeExtraIcons glamorousBrowse
on: $b
entitled: 'Browse';
morphicSelectionAct: [:list | list selection value inspect ]
icon: GLMUIThemeExtraIcons glamorousInspect
on: $i
entitled: 'Inspect';
selectionAct: [:list |
((list selection pointersToExcept: { list selection })
reject: [ :each | each pointsOnlyWeaklyTo: 
list selection ]) inspect ]
on: $t
entitled: 'Open pointers to';
dynamicActionsOnSelection: [ :presentation |
(presentation entity class hasInstVarNamed: presentation 
rawSelection key)

   here



ifTrue: [
{
GLMGenericAction new
action: [:list | self systemNavigation 
browseAllAccessesTo: list rawSelection key from: list entity class ];
title: 'List methods using this variable'.
GLMGenericAction new
action: [:list | self systemNavigation 
browseAllStoresInto: list rawSelection key from: list entity class ];
title: 'List methods storing into this 
variable'.
}
]
ifFalse: [ #() ] ]! !



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

"Reasonable is what we are accustomed with."

[Pharo-dev] Epicea redoVisitor does not handle protocol changes

[stepharo]

Hi

I just tried to replay a change today in Pharo60 and I got an error in 
epicea.


EpRedoVisitor>>visitEvent: aChange
^ self error: 'Should not be reached'.

EpRedoVisitor>>visitCodeChange: aChange
"Default behavior for any change."

^ self visitEvent: aChange

EpRedoVisitor>>visitBehaviorChange: aChange
^ self visitCodeChange: aChange

EpRedoVisitor>>visitProtocolChange: aProtocolAddition
^ self visitBehaviorChange: aProtocolAddition.


visitProtocolAddition: aProtocolAddition
^ self visitProtocolChange: aProtocolAddition


Apparently it was a

EpProtocolAddition


And the RedoVisitor does not handle them.

I do not have the time to check further - I just want to rescue my code 
for now.



Stef

[Pharo-dev] Pharo5 Jenkins build crash

[Yann Dubois]

Hi,

Since Sunday, all build launched for Pharo 5 crashed

I have this log message :




CollectionIsEmpty: a Set() is emptySet(Collection)>>errorEmptyCollection
Set(Collection)>>emptyCheck
Set(Collection)>>anyOne
Set(Collection)>>sum:
TestCommandLineHandler>>informResults:
TestCommandLineHandler>>runPackages
TestCommandLineHandler>>activate
TestCommandLineHandler class(CommandLineHandler class)>>activateWith:
[ aCommandLinehandler activateWith: commandLine ] in
PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
in Block: [ aCommandLinehandler activateWith: commandLine ]
BlockClosure>>on:do:
PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand
PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument:
[ self
handleArgument:
(self arguments
ifEmpty: [ '' ]
ifNotEmpty: [ :arguments | arguments first ]) ] in
PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [
self...
BlockClosure>>on:do:
PharoCommandLineHandler(BasicCommandLineHandler)>>activate
PharoCommandLineHandler>>activate
PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
[ super activateWith: aCommandLine ] in PharoCommandLineHandler
class>>activateWith: in Block: [ super activateWith: aCommandLine ]
NonInteractiveUIManager(UIManager)>>defer:
PharoCommandLineHandler class>>activateWith:
[ aCommandLinehandler activateWith: commandLine ] in
BasicCommandLineHandler>>activateSubCommand: in Block: [
aCommandLinehandler activateWith: commandLine ]
BlockClosure>>on:do:
BasicCommandLineHandler>>activateSubCommand:
BasicCommandLineHandler>>handleSubcommand
BasicCommandLineHandler>>handleArgument:
[ self
handleArgument:
(self arguments
ifEmpty: [ '' ]
ifNotEmpty: [ :arguments | arguments first ]) ] in
BasicCommandLineHandler>>activate in Block: [ self...
BlockClosure>>on:do:
BasicCommandLineHandler>>activate
[ self new activate ] in BasicCommandLineHandler class>>startUp: in
Block: [ self new activate ]
./pharo $JOB_NAME.image config
http://smalltalkhub.com/mc/NorbertHartl/Mustache/main
ConfigurationOfMustache --install=bleedingEdge
+ ./pharo Pillar.image config
http://smalltalkhub.com/mc/NorbertHartl/Mustache/main
ConfigurationOfMustache --install=bleedingEdge
'Installing ConfigurationOfMustache bleedingEdge'Error:
MessageNotUnderstood: receiver of "finish" is
nilUndefinedObject(Object)>>error:
[ :err :rcvr |
| errCtx errMorph |
errCtx := thisContext.
[ errCtx := errCtx sender.
"Search the sender chain to find the morph causing the problem"
[ errCtx notNil and: [ errCtx receiver isMorph not ] ]
whileTrue: [ errCtx := errCtx sender ].
"If we're at the root of the context chain then we have a fatal drawing problem"
errCtx ifNil: [ ^ self handleFatalDrawingError: err ].
errMorph := errCtx receiver.
"If the morph causing the problem has already the #drawError flag set,
then search for the next morph above in the caller 
chain."
errMorph hasProperty: #errorOnDraw ] whileTrue.
errMorph setProperty: #errorOnDraw toValue: true.
"Install the old error handler, so we can re-raise the error"
rcvr error: err ] in WorldState>>displayWorldSafely: in Block: [ :err
:rcvr | ...
BlockClosure>>cull:cull:
[ :ex | errorHandlerBlock cull: ex description cull: ex receiver ] in
BlockClosure>>ifError: in Block: [ :ex | errorHandlerBlock cull: ex
description cul...etc...
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
MessageNotUnderstood(Exception)>>signal
UndefinedObject(Object)>>doesNotUnderstand: #finish
WorldState>>displayWorld:submorphs:
WorldMorph>>displayWorld
[ aWorld displayWorld ] in WorldState>>displayWorldSafely: in Block: [
aWorld displayWorld ]
BlockClosure>>on:do:
BlockClosure>>ifError:
WorldState>>displayWorldSafely:
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldMorph>>doOneCycle
[ [ World doOneCycle.
Processor yield.
false ] whileFalse: [  ] ] in MorphicUIManager>>spawnNewProcess in
Block: [ [ World doOneCycle
[ self value.
Processor terminateActive ] in BlockClosure>>newProcess in Block: [
self value





I think that the problem is in command line handler but I'm not sure.
You can see the complete log, for example, at
https://ci.inria.fr/pharo-contribution/job/Pillar/1715/PHARO=50,VERSION=stable,VM=vm/console

Re: [Pharo-dev] Iceberg in general

[Nicolas Passerini]

Hi Norbert,

Up to date, Iceberg has only been developed/used/tested on Pharo 6.0,
please look at the prerrequisites in https://github.com/npasserini/iceberg.
I can not tell if it would work on Pharo 5.0.

Either way, if you could submit a bug report I will happily pay a look at
it.

On Tue, Aug 9, 2016 at 1:55 PM, Peter Uhnák  wrote:

>
>
> On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl  wrote:
>
>> I'm using pharo5 and I wonder we is this version marked as stable
>
>
> The readme states:
>
> "This is still a prototype and is not yet ready for production, but you
> are invited to try it and provide feedback. "
>
> Note however that I've successfully started using it for smaller
> project(s) that are hosted on GitHub. Of course there's a lot of issues
> https://github.com/npasserini/iceberg/issues , but it can be forced to
> work if you are willing to live on the edge. :)
>
> Regarding your error, it would be best to submit a bug report.
>
> Peter
>

Re: [Pharo-dev] Iceberg in general

[Peter Uhnák]

On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl  wrote:

> I'm using pharo5 and I wonder we is this version marked as stable


The readme states:

"This is still a prototype and is not yet ready for production, but you are
invited to try it and provide feedback. "

Note however that I've successfully started using it for smaller project(s)
that are hosted on GitHub. Of course there's a lot of issues
https://github.com/npasserini/iceberg/issues , but it can be forced to work
if you are willing to live on the edge. :)

Regarding your error, it would be best to submit a bug report.

Peter

[Pharo-dev] about endless loop handling

[stepharo]

Hi

does it look like a taboo or we will never have decent endless loop 
handling?


Stef

Re: [Pharo-dev] Iceberg in general

[Guille Polito]

I'm using it in Pharo6 without problems. No idea about Pharo5...

 Original Message 

I played a little further with Iceberg and not even creating a local repository 
worked. I'm using pharo5 and I wonder we is this version marked as stable and 
if there is an ETA for a first stable version.

Norbert

[Pharo-dev] Iceberg in general

[Norbert Hartl]

I played a little further with Iceberg and not even creating a local repository 
worked. I'm using pharo5 and I wonder we is this version marked as stable and 
if there is an ETA for a first stable version.

Norbert

Re: [Pharo-dev] Iceberg cannot parse url with dashes

[Esteban Lorenzano]

Hi,
for now, here: 

https://github.com/npasserini/iceberg/issues

(until this stops to be an external project and we integrate it in Pharo… as it 
is planned, once is not alpha anymore)

cheers,
Esteban

> On 09 Aug 2016, at 13:31, Norbert Hartl  wrote:
> 
> Hi,
> 
> I wanted to try Iceberg. So I opened the UI and clicked on "Clone new 
> repository". But adding
> 
> g...@github.com:pharo-nosql/voyage.git
> 
> as URL I got the error 
> 
> Could not parse URL: g...@github.com:pharo-nosql/voyage.git
> 
> Removing the dash worked but the repo isn't there ;)
> 
> Where should I open tickets regarding Iceberg?
> 
> Norbert
> 
> 

[Pharo-dev] Iceberg cannot parse url with dashes

[Norbert Hartl]

Hi,

I wanted to try Iceberg. So I opened the UI and clicked on "Clone new 
repository". But adding

g...@github.com:pharo-nosql/voyage.git

as URL I got the error 

Could not parse URL: g...@github.com:pharo-nosql/voyage.git

Removing the dash worked but the repo isn't there ;)

Where should I open tickets regarding Iceberg?

Norbert

Re: [Pharo-dev] DNU with GT Debugger

[Tudor Girba]

Hi,

Thanks for the report. Do you happen to have an image around?

Doru


> On Aug 9, 2016, at 11:47 AM, stepharo  wrote:
> 
> While trying to debug pillar I got a DNU when clicking on the raw pane (when 
> the items was selected)
> 
> DNU:
> 
> presentation rawSelection is aLinkedList and it does not understand key
> 
> 
> 
> 
> 'From Pharo 6.0 of 13 May 2016 [Latest update: #60173] on 9 August 2016 at 
> 11:45:10.355092 am'!
> 
> !GTRawObjectVariablesBrowser methodsFor: 'private building' stamp: 
> 'AndreiChis 4/26/2016 10:37'!
> variablesIn: composite
>^ composite table
>showOnly: 50;
>shouldValidate: false;
>allowsRecursiveSearch: false;
>children: [ :assoc |
>assoc key = 'self'
>ifTrue: [ #() ]
>ifFalse: [ self variableValuePairsFor: assoc value ] ];
>icon: [ :assoc | self iconFor: assoc value ];
>display: [ :anObject |
>self rebuildCacheFor: anObject.
>self variableValuePairsFor: anObject ];
>column: 'Variable'
>evaluated: [:assoc | '  ', (GTObjectPrinter new 
> asNonTruncatedTextFrom: assoc key) ];
>column: 'Value'
>evaluated: [:assoc | GTObjectPrinter new asTruncatedTextFrom: 
> assoc value ]
>modified: [:newValue :assoc :presentation |
>self updateInstanceVariable: assoc key from: presentation 
> entity basedOn: newValue.
>presentation update ];
>morphicSelectionAct: [:list | list selection value browse ]
>icon: GLMUIThemeExtraIcons glamorousBrowse
>on: $b
>entitled: 'Browse';
>morphicSelectionAct: [:list | list selection value inspect ]
>icon: GLMUIThemeExtraIcons glamorousInspect
>on: $i
>entitled: 'Inspect';
>selectionAct: [:list |
>((list selection pointersToExcept: { list selection })
>reject: [ :each | each pointsOnlyWeaklyTo: 
> list selection ]) inspect ]
>on: $t
>entitled: 'Open pointers to';
>dynamicActionsOnSelection: [ :presentation |
>(presentation entity class hasInstVarNamed: presentation 
> rawSelection key)
> 
>   here
> 
> 
> 
>ifTrue: [
>{
>GLMGenericAction new
>action: [:list | self systemNavigation 
> browseAllAccessesTo: list rawSelection key from: list entity class ];
>title: 'List methods using this variable'.
>GLMGenericAction new
>action: [:list | self systemNavigation 
> browseAllStoresInto: list rawSelection key from: list entity class ];
>title: 'List methods storing into this 
> variable'.
>}
>]
>ifFalse: [ #() ] ]! !
> 
> 

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

"Reasonable is what we are accustomed with."

[Pharo-dev] DNU with GT Debugger

[stepharo]

While trying to debug pillar I got a DNU when clicking on the raw pane 
(when the items was selected)


DNU:

presentation rawSelection is aLinkedList and it does not understand key




'From Pharo 6.0 of 13 May 2016 [Latest update: #60173] on 9 August 2016 
at 11:45:10.355092 am'!


!GTRawObjectVariablesBrowser methodsFor: 'private building' stamp: 
'AndreiChis 4/26/2016 10:37'!

variablesIn: composite
^ composite table
showOnly: 50;
shouldValidate: false;
allowsRecursiveSearch: false;
children: [ :assoc |
assoc key = 'self'
ifTrue: [ #() ]
ifFalse: [ self variableValuePairsFor: assoc value ] ];
icon: [ :assoc | self iconFor: assoc value ];
display: [ :anObject |
self rebuildCacheFor: anObject.
self variableValuePairsFor: anObject ];
column: 'Variable'
evaluated: [:assoc | '  ', (GTObjectPrinter new 
asNonTruncatedTextFrom: assoc key) ];

column: 'Value'
evaluated: [:assoc | GTObjectPrinter new 
asTruncatedTextFrom: assoc value ]

modified: [:newValue :assoc :presentation |
self updateInstanceVariable: assoc key from: 
presentation entity basedOn: newValue.

presentation update ];
morphicSelectionAct: [:list | list selection value browse ]
icon: GLMUIThemeExtraIcons glamorousBrowse
on: $b
entitled: 'Browse';
morphicSelectionAct: [:list | list selection value inspect ]
icon: GLMUIThemeExtraIcons glamorousInspect
on: $i
entitled: 'Inspect';
selectionAct: [:list |
((list selection pointersToExcept: { list selection })
reject: [ :each | each 
pointsOnlyWeaklyTo: list selection ]) inspect ]

on: $t
entitled: 'Open pointers to';
dynamicActionsOnSelection: [ :presentation |
(presentation entity class hasInstVarNamed: presentation 
rawSelection key)


   here



ifTrue: [
{
GLMGenericAction new
action: [:list | self systemNavigation 
browseAllAccessesTo: list rawSelection key from: list entity class ];

title: 'List methods using this variable'.
GLMGenericAction new
action: [:list | self systemNavigation 
browseAllStoresInto: list rawSelection key from: list entity class ];
title: 'List methods storing into this 
variable'.

}
]
ifFalse: [ #() ] ]! !

'From Pharo 6.0 of 13 May 2016 [Latest update: #60173] on 9 August 2016 at 
11:45:10.355092 am'!

!GTRawObjectVariablesBrowser methodsFor: 'private building' stamp: 'AndreiChis 
4/26/2016 10:37'!
variablesIn: composite
^ composite table
showOnly: 50;
shouldValidate: false;
allowsRecursiveSearch: false;
children: [ :assoc | 
assoc key = 'self'
ifTrue: [ #() ]
ifFalse: [ self variableValuePairsFor: assoc 
value ] ];
icon: [ :assoc | self iconFor: assoc value ];
display: [ :anObject | 
self rebuildCacheFor: anObject.
self variableValuePairsFor: anObject ];
column: 'Variable' 
evaluated: [:assoc | '  ', (GTObjectPrinter new 
asNonTruncatedTextFrom: assoc key) ];
column: 'Value' 
evaluated: [:assoc | GTObjectPrinter new 
asTruncatedTextFrom: assoc value ]
modified: [:newValue :assoc :presentation | 
self updateInstanceVariable: assoc key from: 
presentation entity basedOn: newValue.
presentation update ];
morphicSelectionAct: [:list | list selection value browse ] 
icon: GLMUIThemeExtraIcons glamorousBrowse 
on: $b 
entitled: 'Browse';
morphicSelectionAct: [:list | list selection value inspect ] 
icon: GLMUIThemeExtraIcons glamorousInspect 
on: $i 
entitled: 'Inspect';
selectionAct: [:list | 
((list selection pointersToExcept: { list selection })
reject: 
[ :each | each pointsOnlyWeaklyTo: list selection ]) inspect ] 
on: $t
entitled: 'Open pointers to';
dynamicActionsOnSelection: [ :presentation |
 

Re: [Pharo-dev] another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

[stepharo]

Me too I get from time to time a VM crash (sometimes after a 
smalltalkhub hiccups).


Stef


Le 8/8/16 à 15:26, Mariano Martinez Peck a écrit :
For the record, I do also continue to see this crash in Pharo 5.0 with 
it's stable VM.
But as Esteban said, it's too random that I don't have more info to 
share :(



On Mon, Aug 8, 2016 at 6:39 AM, Esteban Lorenzano > wrote:


damn :(
FreeType bug strikes again… :((

to be honest, I’m playing with the idea to completely replace it
with a UFFI version.
I cannot find why/how this happens… in some conditions handle
become invalid and pharo has no idea pointer is not valid any
more… then crash. Double free was what I guess but I do not find
where that happens (the double free). And I’m also open to believe
in some memory handling problem in VM, now :((

Esteban

> On 05 Aug 2016, at 22:55, Dale Henrichs
mailto:dale.henri...@gemtalksystems.com>> wrote:
>
> Attached crash dump file ...
>
> This one occurred after I'd had an image open for several hours
interesting that similar to the other crashes I've seen recently
FreeTypeFace seems to be implicated:
>
> Smalltalk stack dump:
> 0xff7bc02c I [] in FreeTypeFace(FT2Handle)>pvtDestroyHandle
0xcdeae10: a(n) FreeTypeFace
> 0xff7bc04c M BlockClosure>ensure: 0x9edc9b0: a(n) BlockClosure
> 0xff7bc078 I [] in Mutex>critical: 0xadc7960: a(n) Mutex
> 0xff7bc098 M [] in Semaphore>critical: 0xba42d50: a(n) Semaphore
> 0xff7bc0b8 M BlockClosure>ensure: 0x9edcab8: a(n) BlockClosure
> 0xff7bc0d8 M Semaphore>critical: 0xba42d50: a(n) Semaphore
> 0xff7bc100 I Mutex>critical: 0xadc7960: a(n) Mutex
> 0xff7bc124 I FreeTypeFace(FT2Handle)>pvtDestroyHandle 0xcdeae10:
a(n) FreeTypeFace
> 0xff7bc13c M FreeTypeFace(FT2Handle)>finalize 0xcdeae10: a(n)
FreeTypeFace
> 0xff7bc154 M ByteSymbol(Symbol)>value: 0xa3ab850: a(n) ByteSymbol
> 0xff7bc178 M ObjectFinalizerCollection(OrderedCollection)>do:
0xaa62580: a(n) ObjectFinalizerCollection
> 0xff7bc19c I ObjectFinalizerCollection>finalize 0xaa62580: a(n)
ObjectFinalizerCollection
> 0xff7bc1c0 I WeakFinalizerItem>finalizeValues 0xb8cae80: a(n)
WeakFinalizerItem
> 0xff7bc1dc M [] in WeakRegistry>finalizeValues 0xa6dd690: a(n)
WeakRegistry
> 0xff7bc1f4 M BlockClosure>on:do: 0x9edc8a8: a(n) BlockClosure
> 0xff7bc214 M BlockClosure>on:fork: 0x9edc8a8: a(n) BlockClosure
> 0xff7bc234 M [] in WeakRegistry>finalizeValues 0xa6dd690: a(n)
WeakRegistry
> 0xff7bc258 M OrderedCollection>do: 0x9edc450: a(n) OrderedCollection
> 0xff7bc280 M WeakRegistry>finalizeValues 0xa6dd690: a(n)
WeakRegistry
> 0xff7bc29c M [] in WeakArray class>finalizationProcess
0xa5cefc0: a(n) WeakArray class
> 0xff7bc2b4 M BlockClosure>on:do: 0x9edc398: a(n) BlockClosure
> 0xff7bc2d4 M BlockClosure>on:fork: 0x9edc398: a(n) BlockClosure
> 0xff7bc2f4 M [] in WeakArray class>finalizationProcess
0xa5cefc0: a(n) WeakArray class
> 0xff7bc318 M WeakArray(SequenceableCollection)>do: 0xa381328:
a(n) WeakArray
> 0xff7bc33c I [] in WeakArray class>finalizationProcess
0xa5cefc0: a(n) WeakArray class
> 0xff7bc35c M [] in Semaphore>critical: 0xcc147b0: a(n) Semaphore
> 0xff7bc37c M BlockClosure>ensure: 0x9edb760: a(n) BlockClosure
> 0xff7bc39c M Semaphore>critical: 0xcc147b0: a(n) Semaphore
> 0xff7bc3c0 I WeakArray class>finalizationProcess 0xa5cefc0: a(n)
WeakArray class
> 0xbd19fe8 s [] in WeakArray class>restartFinalizationProcess
> 0xce10050 s [] in BlockClosure>newProcess
>
> Looks like pvtDestroyHandle went a little overboard:)
>
> Dale
> 





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

Re: [Pharo-dev] [pharo-project/pharo-core] e91f1f: 60171

[stepharo]

Pay attention that it was on my todo to work on packaging Grid and I 
need to do a pass on the Spec version


because I do not like the design. So I will probably change the Grid 
package.


Then I not sure that the grid should be by default in Pharo.
It was a personal project and I should probably improve it again.

Stef


Le 8/8/16 à 10:34, GitHub a écrit :

  60171
18875 RBRemoveClassRefactoring applicable despite showing a warning
https://pharo.fogbugz.com/f/cases/18875

18793 Add CTGrid
https://pharo.fogbugz.com/f/cases/18793

18876 Rename BinaryFileStream >> setAtEnd -> setToEnd
https://pharo.fogbugz.com/f/cases/18876