Re: [Pharo-users] Programmatically changing settings values

[Ben Coman]

Or to teach you how to fish rather than just feeding you :)
Right click on the option and select "Display export action string".

Actually, that has some StartupAction scaffolding probably not relevant is
such cases, and it would be good to  have an option for that.
I'd like to change it from
  Right-click on setting
  > Display export action string

to this...
  Right-click on setting
  > Set programatically
 > Display Workspace string
 > Display StartupAction string
any objections?


On Sat, Jan 10, 2015 at 5:30 AM, Marcus Denker 
wrote:

>
> > On 09 Jan 2015, at 18:27, Pablo Herrero  wrote:
> >
> > Hey everyone,
> >
> > I would like to change some of the environment settings by code,
> > specifically I would like to change the default compiler, from the
> > menu you would do: World Menu >> System >> Settings  >> Compiler >>
> > Default Compiler , and then set you preference there. How can you do
> > that programmatically?
>
> Yes!
>
> The gobal compiler can be changed by
>
> SmalltalkImage compilerClass: Compiler
>
> Marcus
>
>

Re: [Pharo-users] [ANN] OS Project with initial support for Ubuntu and Unix

[stepharo]

this is cool
What I would love is to have the possibility as in Ruby to invoke shell 
and the rest from Pharo!


Stef
Le 9/1/15 11:27, Torsten Bergmann a écrit :

Hi,

beside the existing "OS-Windows" support for Windows operating system
the "Pharo OS project" (http://smalltalkhub.com/#!/~OS) now also has
new subprojects for "OS-Unix" and "OS-Linux-Ubuntu" with some initial
support for these native platforms as well.

You can load it from the config browser in Pharo 4.0. I guess the
attached screenshot will explain it all...

Bye
T.

Re: [Pharo-users] Extending GTSpotter

[Tudor Girba]

It is not duplicated.

The logic is different:
- GTSpotterCandidatesProcessor>>is:matching: works as a filter on a given
collection.
- GTSpotter>>spotterImplementorsFor: is an iterator that tries to match as
it runs.

Anyway, this part of Spotter will be reworked soon.

Doru

On Fri, Jan 9, 2015 at 4:41 PM, Damien Pollet  wrote:

> Both GTSpotter>>spotterImplementorsFor: and
> GTSpotterCandidatesProcessor>>is:matching: do substring matching, so
> I'm wondering if the matching logic is duplicated/distributed in
> several places.
>
> On 9 January 2015 at 15:55, Tudor Girba  wrote:
> > I am not sure I understand the question. A duplication of what?
> >
> > Doru
> >
> > On Fri, Jan 9, 2015 at 3:48 PM, Damien Pollet
> >  wrote:
> >>
> >> I've seen #includesSubstring: in
> >> GTSpotterCandidatesProcessor>>is:matching: as well… is it duplication
> >> or a legitimately different use? (just trying to understand the
> >> architecture)
> >>
> >> On 9 January 2015 at 14:46, Tudor Girba  wrote:
> >> > The includesSubstring: is the simplest thing we could do to get some
> >> > value
> >> > out of the interface. More is definitely required in this direction.
> >> >
> >> > To build a custom search logic, you should use "processor filter:
> >> > [...]".
> >> >
> >> > For an example, look at GTSpotter>>spotterImplementorsFor: aStep.
> >> >
> >> > This is still too complicated and we need to simplify it.
> >> >
> >> > Cheers,
> >> > Doru
> >> >
> >> >
> >> >
> >> > On Fri, Jan 9, 2015 at 2:19 PM, Damien Pollet
> >> >  wrote:
> >> >>
> >> >> Back to this thread!
> >> >>
> >> >> I'm not completely fond of the way GTSpotter matches candidates using
> >> >> just #includesSubstring:
> >> >> Are there provisions already to rank candidates instead of binary
> >> >> matching/rejecting them? I'd like to try one of the fuzzy matching
> >> >> algorithms that other quick-selection tools have.
> >> >>
> >> >> On 24 December 2014 at 02:36, Offray Vladimir Luna Cárdenas
> >> >>  wrote:
> >> >> > Hi,
> >> >> >
> >> >> > Sorry I don't want to "kidnap" the thread, but just inspecting
> >> >> > "KMRepository
> >> >> > default" and selecting an empty row brings and error. In an other
> >> >> > thread
> >> >> > today I talked about this error still being present, so is not just
> >> >> > about my
> >> >> > project, but a way to select empty places on GT objects (trees,
> >> >> > tables,
> >> >> > etc)
> >> >> > and when there is noting there, raising no error and keeping the
> >> >> > state
> >> >> > of
> >> >> > the visualization (in the table resulting from inspecting
> >> >> > KMRepository
> >> >> > default closing the error brings you back to the table, with my
> >> >> > outliner,
> >> >> > the tree gets empty).
> >> >> >
> >> >> > Just trying to make the connection... surely I'm loosing something.
> >> >> >
> >> >> > Cheers,
> >> >> >
> >> >> > Offray
> >> >> >
> >> >> > El 13/12/14 a las 04:23, Edward Povazan escribió:
> >> >> >
> >> >> >> Doru’s blog has some neat things. One led me to the following:
> >> >> >> Inspect:
> >> >> >> KMRepository default.
> >> >> >>
> >> >> >> With GTools installed, you can see all the shortcuts nicely
> >> >> >> formatted.
> >> >> >> I
> >> >> >> finally found a ‘scope selection’ (Cmd+Sh+P) which makes me a very
> >> >> >> happy
> >> >> >> user (it’s my primary selection method in IntelliJ/AppCode).
> >> >> >>
> >> >> >> -Ed
> >> >> >>
> >> >> >> On Dec 11, 2014, at 8:59 AM, Johan Fabry 
> >> >> >> wrote:
> >> >> >>
> >> >> >>>
> >> >> >>> A big +1 on Damien’s comment. Discoverability of useful things is
> >> >> >>> too
> >> >> >>> low. For example, I did not know about Shift-enter for searching
> >> >> >>> until
> >> >> >>> somebody showed it to me inadvertently when he was demoing
> >> >> >>> something
> >> >> >>> else
> >> >> >>> :-/
> >> >> >>>
> >> >> >>> That being said, I don’t have a good solution to the problem
> either
> >> >> >>> :-(
> >> >> >>> Maybe have the standard image have a second workspace open that
> >> >> >>> lists
> >> >> >>> useful
> >> >> >>> tools and their shortcuts? Plus put new tools and their shortcuts
> >> >> >>> prominent
> >> >> >>> in the release notes for each new release? (cause us old timers
> >> >> >>> don’t
> >> >> >>> look
> >> >> >>> at those workspaces anymore ;-) ).
> >> >> >>>
> >> >>  On Dec 11, 2014, at 13:25, Damien Pollet
> >> >>  
> >> >>  wrote:
> >> >> 
> >> >> > Cmd+Enter: ‘Package'
> >> >> 
> >> >> 
> >> >>  Doru, your blog post does not mention this piece of information:
> >> >>  how
> >> >>  to invoke GTSpotter
> >> >>  It does not seem to be mentioned in your announcement email
> >> >>  either; I
> >> >>  found it here after going through threads talking about
> GTSpotter.
> >> >> 
> >> >>  Nobody else asked for it, so I'm guessing it was well-known
> before
> >> >>  and
> >> >>  I'm the only one who failed to get addicted to whatever the
> >> >>  shortcut
> >> >>  was doing be

[Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

[PBKResearch]

Hello

 

I have run into a problem in moving some existing work from earlier versions
of Pharo/Moose. I have found a work around, but I wonder if there is a
tidier way of handling it.

 

I make frequent use of Todd Blanchard's HTML parser and validator, HTMCSS
(http://smalltalkhub.com/#!/~ToddBlanchard/HTMCSSValidatingParser), which
was originally written for Squeak but has performed without trouble on
earlier versions of Pharo. When I try to use it on Moose 5.0, I get frequent
warning messages about Url being deprecated. I have made the problem go away
by commenting out the deprecation warning in Url class>>new, but I wonder
what should be done on a more permanent basis.

 

The problem arises because HTMCSS does not just parse the original HTML
file; it also loads and parses any referenced CSS files. (This is a function
I could do without, but I don't fancy trying surgery on a complex package
where I only partly understand the workings!) It constructs the full address
of the CSS file by combining the root address of the HTML with the relative
address of the CSS, using Url class>>combine:withRelative:, and in the
course of this it invokes Url class>>new; hence the deprecation message. 

 

The deprecation message says Url has been replaced by ZnUrl, but this is
clearly  not a simple replacement of one message by an equivalent; there is
no ZnUrl class>>combine:withRelative:, for instance. The tidiest solution
would no doubt be to find an equivalent method in Zinc, which I am sure
exists, and then modify the HTMCSS code to use it. I have tried to find an
equivalent, but Zinc is a large and complex system and I rapidly got lost.

 

I wonder more broadly about the strategy of deprecating functions which are
required by legacy packages, as in this case. Should there at least be a way
of overriding deprecations? (I suppose that is what I have done by
commenting it out, but it seems crude.)

 

Thanks in advance for any help or suggestions.

 

Peter Kenny

Re: [Pharo-users] issue with and/or inlining

[Evan Donahue]

Hmm, so that works when I annotate my test class, but I probably shouldn't be
exporting pragma concerns to my end users. Was your other suggestion about
dealing with the warning itself something I could do, or were you referring
to a change to pharo itself? In case it's relevant, the warning also seems
to cause an issue where I can't deselect a new class in the system browser
and have to re-open the browser.

Thanks,
Evan



--
View this message in context: 
http://forum.world.st/issue-with-and-or-inlining-tp4798622p4798769.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

[stepharo]

Le 10/1/15 11:41, PBKResearch a écrit :


Hello

I have run into a problem in moving some existing work from earlier 
versions of Pharo/Moose. I have found a work around, but I wonder if 
there is a tidier way of handling it.


I make frequent use of Todd Blanchard’s HTML parser and validator, 
HTMCSS 
(http://smalltalkhub.com/#!/~ToddBlanchard/HTMCSSValidatingParser), 
which was originally written for Squeak but has performed without 
trouble on earlier versions of Pharo. When I try to use it on Moose 
5.0, I get frequent warning messages about Url being deprecated. I 
have made the problem go away by commenting out the deprecation 
warning in Url class>>new, but I wonder what should be done on a more 
permanent basis.



Yes change the code of the Parser not to use old code.



The problem arises because HTMCSS does not just parse the original 
HTML file; it also loads and parses any referenced CSS files. (This is 
a function I could do without, but I don’t fancy trying surgery on a 
complex package where I only partly understand the workings!) It 
constructs the full address of the CSS file by combining the root 
address of the HTML with the relative address of the CSS, using Url 
class>>combine:withRelative:, and in the course of this it invokes Url 
class>>new; hence the deprecation message.




use ZnURL



The deprecation message says Url has been replaced by ZnUrl, but this 
is clearly  not a simple replacement of one message by an equivalent; 
there is no ZnUrl class>>combine:withRelative:, for instance.


Sven will certainly comment but I guess that there is certainly the same 
behavior.


The tidiest solution would no doubt be to find an equivalent method in 
Zinc, which I am sure exists, and then modify the HTMCSS code to use 
it. I have tried to find an equivalent, but Zinc is a large and 
complex system and I rapidly got lost.



It should be in ZnURL

is it not addPathSegment:?


from class comment

  ZnUrl new
scheme: #https;
host: 'encrypted.google.com';
addPathSegment: 'search';
queryAt: 'q' put: 'Smalltalk';
yourself.

host: looks like the root
addPathSegment: looks like https://encrypted.google.com/search

I wonder more broadly about the strategy of deprecating functions 
which are required by legacy packages, as in this case. Should there 
at least be a way of overriding deprecations? (I suppose that is what 
I have done by commenting it out, but it seems crude.)


Thanks in advance for any help or suggestions.

Peter Kenny

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

[Dale Henrichs]

Usman,

Thanks for supplying the image ... with that I could diagnose the 
problem. In the final analysis, the onDowngrade: feature just does not 
work[1]. I haven't had a `downgrade` use case in my own work flow, so I 
did not notice that it wasn't working and the test cases that I do have 
are obviously faulty.


Along the way, I discovered that in the Moose image, there is a custom 
MetacelloPlatform class installed (GTMetacelloPlatform) that is not 
compatible with the Scripting API. With that class installed, the 
scripting API will not work. I was able to install the proper platform 
class myself, but it requires manual intervention ...


Also, it turns out the PetitParser 1.10 is the version that is installed 
and your new version 1.51 is not technically a downgrade ... I think 
that the version needs to be named 1.5.1 to be a downgrade ... I changed 
that as well and that's when I was able determine that onDowngrade: 
wasn't functioning correctly.


Basically, the code said "go ahead and downgrade" but when it came time 
to actually load the packages, Metacello went ahead with it's standard 
algorithm of only loading newer versions of each package.


I plan to take a crack at fixing this bug this weekend ... and will let 
you when I have a fix.


Dale

[1] https://github.com/dalehenrich/metacello-work/issues/317

On 1/8/15 12:32 AM, Usman Bhatti wrote:



On Wed, Jan 7, 2015 at 8:25 PM, Dale Henrichs 
> wrote:


Usman,

No, I appreciate your patience:) If creating your own
configuration works for you then that is a good route to go...


Sharing your image will make it much easier for me to get the
bottom of this (on my own schedule:), so please send me a link for
accessing your image and I'll dig into this in more detail when I
have time ...


Here is the image.
https://dl.dropboxusercontent.com/u/11804892/downgrade-with-metacello.zip

You just need to execute the script in the workspace/playground to 
reproduce the problem (i.e. launching the directive to load PP 1.51 
and that not happening).



If you find yourself stuck and needing the `downgrade directive`
again, I'll bump up the priority ...


I can still wait till next week. If you could have a look by then, 
it'll be great.

tx.
Usman



Dale


On 01/07/2015 09:19 AM, Usman Bhatti wrote:



On Tue, Jan 6, 2015 at 6:56 PM, Dale Henrichs
mailto:dale.henri...@gemtalksystems.com>> wrote:


On 1/6/15 7:16 AM, Usman Bhatti wrote:

Dale,

I couldn't make it work with the upgraded Metacello and the
script you provided.

Steps I did:

1. Download moose image:
https://ci.inria.fr/moose/job/moose-5.0/

2. Update my Metacello to the 'full' version:
Metacello new
  baseline: 'Metacello';
  repository:
'github://dalehenrich/metacello-work:master/repository';
  get.
Metacello new
  baseline: 'Metacello';
  repository:
'github://dalehenrich/metacello-work:master/repository';
  onConflict: [:ex | ex allow];
  load

3. File in the ConfigurationOfDummyParser (see the first
message in the thread).

4.  Run this script to downgrade to PetitParser version 1.51

Metacello new
configuration: 'DummyParser';
version: '1.0';
repository: '???';
onDowngradeUseIncoming: #('PetitParser');
load.

The desired version is still not loaded, am I missing
something here?

Good question, I don't have a lot of time today to spend time
trying to reproduce your problem, but if you send me a copy
of the Transcript produced while doing the load I might be
able to spot the problem ...


It looks to me that the downgrade command is not working.
Whenever I point to the version preceding the one loaded, the
packages are not fetched.

I am attaching here two files.

The first (Transcript-PP151) is the output of the transcript as
you asked. You can see that PetitParser packages as defined by
the version 1.51 are not fetched. All that is loaded is Glamour
because the version 1.51 of PetitParser loads the latest packages
of Glamour. The load works because it is an upgrade from the
current version of Glamour which is a stable.

When I saw that only Glamour packages are loaded, I thought of
testing Glamour downgrade too to see if the problem is specific
to PetitParser. You can see the result in the second file
(Transcript-downgrade-glamour). No packages of Glamour are
fetched because the configuration tries to downgrade it (stable
is more recent than 3.0.0 which I try to load).

In my opinion, downgrade is not working as required. If you want
I can share my image thru dropbox so that you can have a look to
see what might be wrong.




regards,

   

Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

[Sven Van Caekenberghe]

> On 10 Jan 2015, at 16:45, stepharo  wrote:
> 
> 
> Le 10/1/15 11:41, PBKResearch a écrit :
>> Hello
>>  
>> I have run into a problem in moving some existing work from earlier versions 
>> of Pharo/Moose. I have found a work around, but I wonder if there is a 
>> tidier way of handling it.
>>  
>> I make frequent use of Todd Blanchard’s HTML parser and validator, HTMCSS 
>> (http://smalltalkhub.com/#!/~ToddBlanchard/HTMCSSValidatingParser), which 
>> was originally written for Squeak but has performed without trouble on 
>> earlier versions of Pharo. When I try to use it on Moose 5.0, I get frequent 
>> warning messages about Url being deprecated. I have made the problem go away 
>> by commenting out the deprecation warning in Url class>>new, but I wonder 
>> what should be done on a more permanent basis.
> Yes change the code of the Parser not to use old code. 
>> 
>> The problem arises because HTMCSS does not just parse the original HTML 
>> file; it also loads and parses any referenced CSS files. (This is a function 
>> I could do without, but I don’t fancy trying surgery on a complex package 
>> where I only partly understand the workings!) It constructs the full address 
>> of the CSS file by combining the root address of the HTML with the relative 
>> address of the CSS, using Url class>>combine:withRelative:, and in the 
>> course of this it invokes Url class>>new; hence the deprecation message. 
> 
> use ZnURL
>> 
>> The deprecation message says Url has been replaced by ZnUrl, but this is 
>> clearly  not a simple replacement of one message by an equivalent; there is 
>> no ZnUrl class>>combine:withRelative:, for instance. 
> Sven will certainly comment but I guess that there is certainly the same 
> behavior. 

ZnUrl>>#inContextOf: is the selector you are looking for, but path merging is 
not supported (yet).

'readme.txt' asZnUrl inContextOf: 'http://www.host.com:8080' asZnUrl.

Maybe we should add path merging, I'll think about it.

>> The tidiest solution would no doubt be to find an equivalent method in Zinc, 
>> which I am sure exists, and then modify the HTMCSS code to use it. I have 
>> tried to find an equivalent, but Zinc is a large and complex system and I 
>> rapidly got lost.
> It should be in ZnURL 
> 
> is it not addPathSegment:? 
> 
> 
> from class comment
> 
>   ZnUrl new 
> scheme: #https; 
> host: 'encrypted.google.com'; 
> addPathSegment: 'search'; 
> queryAt: 'q' put: 'Smalltalk'; 
> yourself.
>   
> host: looks like the root
> addPathSegment: looks like https://encrypted.google.com/search
> 
>>  
>> I wonder more broadly about the strategy of deprecating functions which are 
>> required by legacy packages, as in this case. Should there at least be a way 
>> of overriding deprecations? (I suppose that is what I have done by 
>> commenting it out, but it seems crude.)

This is how you can work around Deprecation warnings:

[ Url combine: 'http://www.foo.com/one/two/' withRelative: 'bar/readme.txt' ]
  on: Deprecation do: [ :exception | exception resume ]

but that is a temporary hack.

>> Thanks in advance for any help or suggestions.
>>  
>> Peter Kenny
> 

Sven

[Pharo-users] How to subclass Float class

[Hilaire]

It looks like when I want to create a subclass of Float, I have this odd
class creation message. Moreoever, I can add instance variable to this
new class: when compiling there are wipe out: argument
instanceVariableNames: '' remain empty.

If I change Float to Object, all get back to normal.

Why is it like this ?


Float variableWordSubclass: #MyClass
instanceVariableNames: ''
classVariableNames: ''
category: 'Cofigest-Financial'


Thanks

Hilaire

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

Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

[PBKResearch]

Sven: Thanks for the suggestions. I have tried ZnUrl>>#inContextOf:, but it
does not produce the correct address; evidently I shall have to wait until
you have full path merging implemented. Meanwhile, I have used your
'temporary hack' to ignore the deprecation; it is at least not as hackish as
my approach.
Stepharo:
> Yes change the code of the Parser not to use old code.
As I pointed out, the Parser is a large and complex package, and I am not
the author, so this is easier said than done. It seems a bit odd to dismiss
code which worked OK in Moose 4.9, but not in Moose 5.0, as 'old code.'  It
is code which has no functional equivalent in the new code, as Sven has
confirmed.

Thanks again

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
Sven Van Caekenberghe
Sent: 10 January 2015 16:36
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Problem due to deprecation of class Url in Pharo
3 and Moose 5.0


> On 10 Jan 2015, at 16:45, stepharo  wrote:
> 
> 
> Le 10/1/15 11:41, PBKResearch a écrit :
>> Hello
>>  
>> I have run into a problem in moving some existing work from earlier
versions of Pharo/Moose. I have found a work around, but I wonder if there
is a tidier way of handling it.
>>  
>> I make frequent use of Todd Blanchard’s HTML parser and validator, HTMCSS
(http://smalltalkhub.com/#!/~ToddBlanchard/HTMCSSValidatingParser), which
was originally written for Squeak but has performed without trouble on
earlier versions of Pharo. When I try to use it on Moose 5.0, I get frequent
warning messages about Url being deprecated. I have made the problem go away
by commenting out the deprecation warning in Url class>>new, but I wonder
what should be done on a more permanent basis.
> Yes change the code of the Parser not to use old code. 
>> 
>> The problem arises because HTMCSS does not just parse the original HTML
file; it also loads and parses any referenced CSS files. (This is a function
I could do without, but I don’t fancy trying surgery on a complex package
where I only partly understand the workings!) It constructs the full address
of the CSS file by combining the root address of the HTML with the relative
address of the CSS, using Url class>>combine:withRelative:, and in the
course of this it invokes Url class>>new; hence the deprecation message. 
> 
> use ZnURL
>> 
>> The deprecation message says Url has been replaced by ZnUrl, but this is
clearly  not a simple replacement of one message by an equivalent; there is
no ZnUrl class>>combine:withRelative:, for instance. 
> Sven will certainly comment but I guess that there is certainly the same
behavior. 

ZnUrl>>#inContextOf: is the selector you are looking for, but path merging
is not supported (yet).

'readme.txt' asZnUrl inContextOf: 'http://www.host.com:8080' asZnUrl.

Maybe we should add path merging, I'll think about it.

>> The tidiest solution would no doubt be to find an equivalent method in
Zinc, which I am sure exists, and then modify the HTMCSS code to use it. I
have tried to find an equivalent, but Zinc is a large and complex system and
I rapidly got lost.
> It should be in ZnURL 
> 
> is it not addPathSegment:? 
> 
> 
> from class comment
> 
>   ZnUrl new 
> scheme: #https; 
> host: 'encrypted.google.com'; 
> addPathSegment: 'search'; 
> queryAt: 'q' put: 'Smalltalk'; 
> yourself.
>   
> host: looks like the root
> addPathSegment: looks like https://encrypted.google.com/search
> 
>>  
>> I wonder more broadly about the strategy of deprecating functions which
are required by legacy packages, as in this case. Should there at least be a
way of overriding deprecations? (I suppose that is what I have done by
commenting it out, but it seems crude.)

This is how you can work around Deprecation warnings:

[ Url combine: 'http://www.foo.com/one/two/' withRelative: 'bar/readme.txt'
]
  on: Deprecation do: [ :exception | exception resume ]

but that is a temporary hack.

>> Thanks in advance for any help or suggestions.
>>  
>> Peter Kenny
> 

Sven

Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

[Sven Van Caekenberghe]

Peter,

> On 10 Jan 2015, at 23:30, PBKResearch  wrote:
> 
>> Yes change the code of the Parser not to use old code.
> As I pointed out, the Parser is a large and complex package, and I am not
> the author, so this is easier said than done. It seems a bit odd to dismiss
> code which worked OK in Moose 4.9, but not in Moose 5.0, as 'old code.'  It
> is code which has no functional equivalent in the new code, as Sven has
> confirmed.

Could you explain what arguments were given to the combine and what the 
expected output was/should be ? How does it use path merging ?

Thx,

Sven