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
Rig
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
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
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/#!/~ToddBla
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 s
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,
H
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 o
> 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.
>>
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 i
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
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 Mo
11 matches
Mail list logo
