Re: [Pharo-users] What does RMoD stand for?

[Stephane Ducasse]

It stands for nothing :) just Remodularisation dropping letters and
making sure that they are not thousands of other people in the web
having the same name :).


On Sat, Oct 7, 2017 at 1:27 PM, Sven Van Caekenberghe  wrote:
>
>
>> On 7 Oct 2017, at 13:06, Rene Paul Mages (ramix)  wrote:
>>
>>
>>
>> Le 07/10/2017 à 12:59, horrido a écrit :
>>> It is bizarre. Nowhere on the web can I find any reference to what INRIA's
>>> *RMoD* acronym stands for.
>>
>> Please try this request :
>>
>> https://tinyurl.com/INRIA-Rmod
>
> But it is strange that their main page does not say (AFAICS).
>
> It is something like Research into Modular Systems, but I am just guessing ;-)
>
>> --
>> Amicalement.
>> Rene Paul Mages ( GnuPG_key 1024D/2CC455D9 )
>> http://www.linux-azur.org/ramix
>> http://blog.pharo.fr
>> http://nosoftwarepatents.wikidot.com
>>
>>
>>
>
>

Re: [Pharo-users] Embeddable Smalltalk (was: Re: Behold Pharo: The Modern Smalltalk)

[Stephane Ducasse]

I would love to have pharo embeddable from C. But we are not yet there.
Now we worked and will continue to make sure that Pharo can work in
readonly mode and we will have a tiny core.

Stef

On Sat, Oct 7, 2017 at 2:43 PM, Ben Coman  wrote:
>
>
> On Sat, Oct 7, 2017 at 7:05 PM, Herby Vojčík  wrote:
>>
>> Ben Coman wrote:
>>>
>>> Nice article. I like the way you've structured it and pushed the
>>> "updated" angle.
>>>
>>> I feel a bit too strong a claim is laid on Pharo producing the CogVM.
>>> Much of the Cog + Spur + 64bit VM work was originally done for Squeak
>>> with Pharo riding the coat-tails of that work.  Lately Pharo community
>>> has been involved in improving VM with hotspot optimisation with Sista
>>> and moving towards making Pharo embeddable.. (@Clement, is "hotspot
>>
>>
>> Hi, this made me curious. I always had the problem with Amber (and, all
>> the rest of Smalltalks in similar vein) that it is hard to use to one-off
>> scripting, as it presumes existence of the not really small class library
>> (objects, classes, collections, etc.). This disadvantaged it IMO in the
>> field of "can I just embed it here and script it with a few lines?"
>> scenarios.
>>
>> Did you (the Pharo community that is "moving towards making Pharo
>> embeddable") find some way to work this around?
>
>
> Embeddable here is no so much for one-off scripting, but more becoming an
> integrated part of an application driven by an event loop of a game engine
> rather than the existing VM event loop.  I'd expect much of the class
> library to be available here, so your question is orthogonal.
>
> I've seen discussion of projects for Pharo work from the command line, but I
> don't know their status.
>
> cheers -ben

Re: [Pharo-users] FocusFrog

[Sean P. DeNigris]

Steven R. Baker wrote
> I am not sure how to manage projects, or even how someone goes about
> importing this stuff.

It looks like you've already grasped package management.

The next level up in project management is Metacello, which let's you
declare the dependency relationships between packages and outside projects.
For git repos, one creates a BaselineOf instead of the old ConfigurationOf.
The difference between a baseline and a config is that the latter needs to
have additional metadata because for example, the config itself could be
hosted anywhere (e.g. in a different repo than the project), and it also
needs to specify which package/dependency versions make up a particular
version of your project. For git, the baseline relies on some assumptions to
eliminate some declarations. For example, the baseline gets committed right
with the rest of the project. Thus, if you have the baseline, you already
know the repo, so that is omitted. Also, since git defines a snapshot of
package versions via a particular commit, so you don't need that additional
version info. ATM, you might still create a ConfigurationOf for integration
with some tools, so for example, your project could appear and be loadable
via the Project Catalog tool. But the configuration would be a thin wrapper
which probably just delegates by declaring a baseline from a particular
commit.

Also, it would be good to provide an obvious access point to open the tool.
`FocusFrogMainModel new openWithSpec` is a basic snippet that does the
trick. You might want to document that with a class-side method (if you tag
it with 

[Pharo-users] So how do you use Live Coding ?

[Dimitris Chloupis]

I think this deserves a seperate thread by itself, I was wondering what
tricks , ideas and workflows you guys have come up with using live coding
in Pharo ?

What you like ?
what you dont like ?
What kinda of libraries you have made to enhance your live coding workflow ?
What ideas you have that could enhance live coding workflow , inside and
outside Pharo ?

Any opinion is welcomed whether you just started coding in Pharo or coding
in it for many years , I welcome any kind of brainstorming as long as it is
relevant to live coding itself.

Offray already was kind enough to share his workflow but I am sure other
have something to add as well

Its important to share because I am thinking of making a special mention in
the Pharo wiki about live coding workflows so anything you share will be
copy pasted there to help other people to get deeper into live coding

If you can please offer practical examples , will make it easier for me and
others to understand.

So dont be shy, sharing is caring  ;)

[Pharo-users] FocusFrog

[Steven R. Baker]

Hey all!

Thanks for the help on all of my little issues. I've been plugging away
at FocusFrog, my application for Getting Things Done.  I have pushed the
current code (mostly UI stuff in there just now) to GitLab:
https://gitlab.com/srbaker/FocusFrog

I am not sure how to manage projects, or even how someone goes about
importing this stuff. If anyone of you cares to pull that down and
provide suggestions, I will be more than happy to take them! Currently,
I'm fixing up the view switching when you click the sidebar buttons, and
improving the task item views.

Is there a document somewhere about how you're supposed to publish
things for Pharo? I'd like to make sure this follows the "established
best practices."

Cheers!

-Steven

Re: [Pharo-users] Equals and HashCode Builder

[Sean P. DeNigris]

Noury Bouraqadi-2 wrote
> The code + tests are here 
> http://smalltalkhub.com/#!/~CAR/ReusableBricks/packages/Equals

I forked to https://github.com/seandenigris/Pharo-Equals with a baseline to
make it easier to try out/possibly-integrate.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] FileReference#entries caching?

[Steven R. Baker]

On 07/10/17 14:22, Peter Uhnák wrote:
> On Sat, Oct 7, 2017 at 1:02 PM, Steven R. Baker
> > wrote:
>
> Is it cached or something? How do I guarantee that I'm *definitely*
> getting the current state of the directory on disk? 
>
>
> This looks extremely strange, I've never seen that inspecting
> files/directories would be somehow "out of sync" with the disk,
> because it is always asking the disk.
>
>
>
> Should I not even be using FileReference for this?
>
>
> If you are loading png icons into Pharo, you can consider
> using https://github.com/peteruhnak/IconFactory/ instead (shameless
> self promotion :) )

Will definitely switch to this; I wasn't aware of the pattern, but
obviously I want to follow them where possible. :)

> Peter

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

Indeed if you google "live coding" you get a lot of audio visual related
tools. I have to confess because I am working with graphics, live coding is
pretty much bread and butter of my workflow , cannot imagine myself working
without it.

When you step out of audio visual and other live performance arts you
barely see "live coding" mentioned if not at all. The only exception I know
is RunRev's LiveCode , similar to Pharo in the general idea, used to be
closed source but now there is an open source version and Apple's Swift's
Playgrounds which were inspired by a Smalltalk like demo.

Fragmantation is indeed an issue with all programming languages including
Pharo but on the other hand is a necessarily evil for innovation because my
experience is that where there is unity there is also stagnation of
progress but this enters philosophical ground I rather not venture into.

On Sat, Oct 7, 2017 at 6:18 PM Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> I think that there are some communities that are more receptive of live
> coding, beyond programmers. Scientist, journalists, hacktivists, data
> visualizers, musicians, come to mind and I have a better experience and
> more openness to live coding with them that with the "classical
> programmer/coder". With our recent Data Journalism Handbook, adaptation in
> Grafoscopio [1] and our recurrent Data Week hackathon+workshops[2], we're
> trying to reach new audiences and communities.
> [1] http://mutabit.com/repos.fossil/mapeda/
> [2] http://mutabit.com/dataweek/
>
> Cheers,
>
> Offray
>
>
> On 07/10/17 07:40, Dimitris Chloupis wrote:
>
> Yes I agree with this
>
> Pharo is a live coding BASED enviroment. For Pharo live coding is not just
> an easy to use feature it based its entire mentality around the idea of
> live coding.
>
> Even though Smalltalk borrowed live coding and image format from Lisp we
> are more "pure" in that regard even compared to Lisp.
>
> But one thing to note here is that live coding is not really that useful
> when used always. At least for me I rely a lot on it for debugging and
> experimenting. But when I work based on a plan , or code just works I do
> not care so much about it.
>
> So my workflow in the end is semi-live coding because I dont feel I need
> live coding 24/7 to be super productive.
>
> Of course that creates some barriers in the end when tools are not made to
> work 24/7 on a live coding context. To that extend Pharo is definetly
> superior and a true live coding enviroment.
>
> You are suprised that you can do live coding in C++ but I was trully
> shocked.
>
> My saga to do live coding in C++ started as a joke, something to use to
> mock C++ ugliness and weakness. But oh boy it did slap it back to my face.
>
> The process is again simple, you wrap eveything inside a main loop,and
> call in this loop functions (C has no objects obvious) or methods if you
> use C++ from DLLs. Those DLLs obviously contain 99.9% of your code. Because
> a DLL can be reloaded it allows you not to stop executing and replace code
> on the fly. The main loop is wrapped inside an exception to make sure the
> an error will never crash your application, C/C++ exceptions are more
> powerful than Pharo live coding in that regard because in Pharo if you do
> anything bad with UFFI and crash it , it will crash for sure.
>
> If you keep the DLL small and  you use tons of small dlls your compile
> times will be almost instantenous. You can also with very view lines detect
> date signature change in source file and trigger background compilation.
> Again few lines of code. The last mountain is live state, in this case the
> executable pass a single pointer and instead of the executable handling the
> memory its actually the dlls that handle it but the executable because it
> cannot crash or exit will keep the live state running. You can also use
> memory mapped file to store live state as they perform pure memory dumps.
>
> All in all you will end up with 100 lines of code that can be wrapped into
> a library and reused in the next project with zero setup. Its an one time
> pain.
>
> Will I would recommend C++ over Pharo for live coding  helll no
> C++ obviously misses a hugely important live coding ingredient which is
> reflection. We do live coding because we want to interact with those
> objects ask questions about what is going on and why our code does not work
> as intended
>
> However Python has no such limitation following a very similar design to
> Smalltalk and being much more powerful language than C++. Python follow
> very closely the Smalltalk paradigm even though there is not a single
> mention of Smalltalk , anywhere in the Python community or of live coding.
>
> Live coding in C++ has become a huge deal in game development mainly
> because game development tend to want to change things on the fly and games
> are so big with extremely long compile times. Unreal has made a huge deal
> over its ability to hot reload C++  

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Offray Vladimir Luna Cárdenas]

Ok. Glad to help. In the thread I mentioned some of the specific
difficulties I had implementing Grafoscopio's idea in Python[1] (in one
word: fragmentation, of technologies and computing paradigms)

[1]
http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html

Cheers,

Offray


On 07/10/17 10:17, Dimitris Chloupis wrote:
> Well I was refering to live coding itself, but you are correct, I have
> not tried combining with literate coding hence why I was curious about
> the difficulties you ecountered. I did not know that you focused so
> much Grafoscopio on iterate coding. Thanks for enlighting me. 
>
> I never implied that Python was easier in everything compared to
> Pharo. Afterall kinda misses a huge chunk which is the IDE itself. 
>
> There lies the challange of live coding as I initially said that we
> each use it in a diffirent way. Thanks for the link also very
> enlighting and it is what i wanted, an actual use case. 
>
> On Sat, Oct 7, 2017 at 5:49 PM Offray Vladimir Luna Cárdenas
> > wrote:
>
>
>
> On 06/10/17 21:00, Dimitris Chloupis wrote:
> > Again very generic statements , and I see you refer to tools and
> > libraries instead of OOP. We talking here Pharo vs Python on the
> > language level because Python obviously does not come with an
> IDE. But
> > then Pharo does not come with literate programming tools or
> libraries
> > as well.
>
> No. We were talking about things "that Pharo can do that Python
> can't do
> or is most difficult". And, for me that includes the (community &
> computing) environment provided by Pharo that allow you to go from and
> idea to its implementation. In my case the idea was to provide an
> experience which mix outlining (a la Leo Editor) with literate
> computing
> (a la Jupyter, IPython) [1]. Even if the original pieces where already
> there in Python, mixing them was a nighmare (at least 3 years ago) and
> Pharo was more empowering for going from idea to prototype and now
> Pharo
> has literate *computing* (not literate programming [2]) tools.
> Grafoscopio is one of them. GT Documenter, in alpha now, is promising.
> You can not have a single document for complex books in Jupyter. You
> need to split/storage a single work in a "pile of files" metaphor. You
> can, today, with Grafoscopio put a 300 pages long PDF in a single
> notebook. So yes, there are things that are more complex in one
> technology that in other (of course all computer languages are the
> same
> at enough distance, because all them are Turing complete and all
> that stuff)
>
> [1]
> 
> http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html
> [2]
> http://blog.fperez.org/2013/04/literate-computing-and-computational.html
>
> >
> > I rather not go down the rabbit hole of third party libraries
> because
> > obviously I cannot participate in a discussion about libraries and
> > areas of coding, I know nothing about. Plus Python has countless of
> > libraries which makes a very longer discussion even if I was
> familiar
> > with them and Pharo has much less but still quite a lot of libraries
> > as well.
>
> One of the advantages of being in a community is learning from others
> experiences. You said that in your experience you have not found a
> place
> where Python were more difficult that in Pharo. I have shown that in
> *my* experience there are. And agree, is unwise to discuss about
> places
> where one has no experience, when is better to learn from those
> who have it.
>
> Cheers,
>
> Offray
>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Offray Vladimir Luna Cárdenas]

I think that there are some communities that are more receptive of live
coding, beyond programmers. Scientist, journalists, hacktivists, data
visualizers, musicians, come to mind and I have a better experience and
more openness to live coding with them that with the "classical
programmer/coder". With our recent Data Journalism Handbook, adaptation
in Grafoscopio [1] and our recurrent Data Week hackathon+workshops[2],
we're trying to reach new audiences and communities.

[1] http://mutabit.com/repos.fossil/mapeda/
[2] http://mutabit.com/dataweek/

Cheers,

Offray

On 07/10/17 07:40, Dimitris Chloupis wrote:
> Yes I agree with this
>
> Pharo is a live coding BASED enviroment. For Pharo live coding is not
> just an easy to use feature it based its entire mentality around the
> idea of live coding.
>
> Even though Smalltalk borrowed live coding and image format from Lisp
> we are more "pure" in that regard even compared to Lisp. 
>
> But one thing to note here is that live coding is not really that
> useful when used always. At least for me I rely a lot on it for
> debugging and experimenting. But when I work based on a plan , or code
> just works I do not care so much about it. 
>
> So my workflow in the end is semi-live coding because I dont feel I
> need live coding 24/7 to be super productive. 
>
> Of course that creates some barriers in the end when tools are not
> made to work 24/7 on a live coding context. To that extend Pharo is
> definetly superior and a true live coding enviroment.
>
> You are suprised that you can do live coding in C++ but I was trully
> shocked. 
>
> My saga to do live coding in C++ started as a joke, something to use
> to mock C++ ugliness and weakness. But oh boy it did slap it back to
> my face. 
>
> The process is again simple, you wrap eveything inside a main loop,and
> call in this loop functions (C has no objects obvious) or methods if
> you use C++ from DLLs. Those DLLs obviously contain 99.9% of your
> code. Because a DLL can be reloaded it allows you not to stop
> executing and replace code on the fly. The main loop is wrapped inside
> an exception to make sure the an error will never crash your
> application, C/C++ exceptions are more powerful than Pharo live coding
> in that regard because in Pharo if you do anything bad with UFFI and
> crash it , it will crash for sure. 
>
> If you keep the DLL small and  you use tons of small dlls your compile
> times will be almost instantenous. You can also with very view lines
> detect date signature change in source file and trigger background
> compilation. Again few lines of code. The last mountain is live state,
> in this case the executable pass a single pointer and instead of the
> executable handling the memory its actually the dlls that handle it
> but the executable because it cannot crash or exit will keep the live
> state running. You can also use memory mapped file to store live state
> as they perform pure memory dumps. 
>
> All in all you will end up with 100 lines of code that can be wrapped
> into a library and reused in the next project with zero setup. Its an
> one time pain. 
>
> Will I would recommend C++ over Pharo for live coding  helll
> no C++ obviously misses a hugely important live coding ingredient
> which is reflection. We do live coding because we want to interact
> with those objects ask questions about what is going on and why our
> code does not work as intended
>
> However Python has no such limitation following a very similar design
> to Smalltalk and being much more powerful language than C++. Python
> follow very closely the Smalltalk paradigm even though there is not a
> single mention of Smalltalk , anywhere in the Python community or of
> live coding.
>  
> Live coding in C++ has become a huge deal in game development mainly
> because game development tend to want to change things on the fly and
> games are so big with extremely long compile times. Unreal has made a
> huge deal over its ability to hot reload C++  code in its editor ,
> though I do not like its approach so much.
>
> Bottom line is yes its easy and simple to do live coding in other
> languages, not recommended so much in C++ because of its static
> compiled nature and lack of reflection but for dynamic language like
> Python it can come pretty close and I speak from experience. 
>
> At least I have not found something in Python that made me wish I was
> live  coding in Pharo so far, but then yes I still think its better to
> have a full blown live coding. Also from my limited understanding I
> have figured out that pretty much every language out there allows for
> reloading code which is pretty much a very large requirement for live
> coding. 
>
> So yes you can live code to an extend, lesser in languages like C++ ,
> more so in language like Python, Ruby etc. Can you get the Pharo
> experience ? In a dynamic language with the creation of a live coding
> library you could get pretty close but never exactly the same.
>
> 

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

Well I was refering to live coding itself, but you are correct, I have not
tried combining with literate coding hence why I was curious about the
difficulties you ecountered. I did not know that you focused so much
Grafoscopio on iterate coding. Thanks for enlighting me.

I never implied that Python was easier in everything compared to Pharo.
Afterall kinda misses a huge chunk which is the IDE itself.

There lies the challange of live coding as I initially said that we each
use it in a diffirent way. Thanks for the link also very enlighting and it
is what i wanted, an actual use case.

On Sat, Oct 7, 2017 at 5:49 PM Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

>
>
> On 06/10/17 21:00, Dimitris Chloupis wrote:
> > Again very generic statements , and I see you refer to tools and
> > libraries instead of OOP. We talking here Pharo vs Python on the
> > language level because Python obviously does not come with an IDE. But
> > then Pharo does not come with literate programming tools or libraries
> > as well.
>
> No. We were talking about things "that Pharo can do that Python can't do
> or is most difficult". And, for me that includes the (community &
> computing) environment provided by Pharo that allow you to go from and
> idea to its implementation. In my case the idea was to provide an
> experience which mix outlining (a la Leo Editor) with literate computing
> (a la Jupyter, IPython) [1]. Even if the original pieces where already
> there in Python, mixing them was a nighmare (at least 3 years ago) and
> Pharo was more empowering for going from idea to prototype and now Pharo
> has literate *computing* (not literate programming [2]) tools.
> Grafoscopio is one of them. GT Documenter, in alpha now, is promising.
> You can not have a single document for complex books in Jupyter. You
> need to split/storage a single work in a "pile of files" metaphor. You
> can, today, with Grafoscopio put a 300 pages long PDF in a single
> notebook. So yes, there are things that are more complex in one
> technology that in other (of course all computer languages are the same
> at enough distance, because all them are Turing complete and all that
> stuff)
>
> [1]
>
> http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html
> [2]
> http://blog.fperez.org/2013/04/literate-computing-and-computational.html
>
> >
> > I rather not go down the rabbit hole of third party libraries because
> > obviously I cannot participate in a discussion about libraries and
> > areas of coding, I know nothing about. Plus Python has countless of
> > libraries which makes a very longer discussion even if I was familiar
> > with them and Pharo has much less but still quite a lot of libraries
> > as well.
>
> One of the advantages of being in a community is learning from others
> experiences. You said that in your experience you have not found a place
> where Python were more difficult that in Pharo. I have shown that in
> *my* experience there are. And agree, is unwise to discuss about places
> where one has no experience, when is better to learn from those who have
> it.
>
> Cheers,
>
> Offray
>
>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Offray Vladimir Luna Cárdenas]

On 06/10/17 21:00, Dimitris Chloupis wrote:
> Again very generic statements , and I see you refer to tools and
> libraries instead of OOP. We talking here Pharo vs Python on the
> language level because Python obviously does not come with an IDE. But
> then Pharo does not come with literate programming tools or libraries
> as well.

No. We were talking about things "that Pharo can do that Python can't do
or is most difficult". And, for me that includes the (community &
computing) environment provided by Pharo that allow you to go from and
idea to its implementation. In my case the idea was to provide an
experience which mix outlining (a la Leo Editor) with literate computing
(a la Jupyter, IPython) [1]. Even if the original pieces where already
there in Python, mixing them was a nighmare (at least 3 years ago) and
Pharo was more empowering for going from idea to prototype and now Pharo
has literate *computing* (not literate programming [2]) tools.
Grafoscopio is one of them. GT Documenter, in alpha now, is promising.
You can not have a single document for complex books in Jupyter. You
need to split/storage a single work in a "pile of files" metaphor. You
can, today, with Grafoscopio put a 300 pages long PDF in a single
notebook. So yes, there are things that are more complex in one
technology that in other (of course all computer languages are the same
at enough distance, because all them are Turing complete and all that stuff)

[1]
http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html
[2] http://blog.fperez.org/2013/04/literate-computing-and-computational.html

>
> I rather not go down the rabbit hole of third party libraries because
> obviously I cannot participate in a discussion about libraries and
> areas of coding, I know nothing about. Plus Python has countless of
> libraries which makes a very longer discussion even if I was familiar
> with them and Pharo has much less but still quite a lot of libraries
> as well.

One of the advantages of being in a community is learning from others
experiences. You said that in your experience you have not found a place
where Python were more difficult that in Pharo. I have shown that in
*my* experience there are. And agree, is unwise to discuss about places
where one has no experience, when is better to learn from those who have it.

Cheers,

Offray

Re: [Pharo-users] Embeddable Smalltalk (was: Re: Behold Pharo: The Modern Smalltalk)

[Ben Coman]

On Sat, Oct 7, 2017 at 7:05 PM, Herby Vojčík  wrote:

> Ben Coman wrote:
>
>> Nice article. I like the way you've structured it and pushed the
>> "updated" angle.
>>
>> I feel a bit too strong a claim is laid on Pharo producing the CogVM.
>> Much of the Cog + Spur + 64bit VM work was originally done for Squeak
>> with Pharo riding the coat-tails of that work.  Lately Pharo community
>> has been involved in improving VM with hotspot optimisation with Sista
>> and moving towards making Pharo embeddable.. (@Clement, is "hotspot
>>
>
> Hi, this made me curious. I always had the problem with Amber (and, all
> the rest of Smalltalks in similar vein) that it is hard to use to one-off
> scripting, as it presumes existence of the not really small class library
> (objects, classes, collections, etc.). This disadvantaged it IMO in the
> field of "can I just embed it here and script it with a few lines?"
> scenarios.
>
> Did you (the Pharo community that is "moving towards making Pharo
> embeddable") find some way to work this around?


Embeddable here is no so much for one-off scripting, but more becoming an
integrated part of an application driven by an event loop of a game engine
rather than the existing VM event loop.  I'd expect much of the class
library to be available here, so your question is orthogonal.

I've seen discussion of projects for Pharo work from the command line, but
I don't know their status.

cheers -ben

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

Yes I agree with this

Pharo is a live coding BASED enviroment. For Pharo live coding is not just
an easy to use feature it based its entire mentality around the idea of
live coding.

Even though Smalltalk borrowed live coding and image format from Lisp we
are more "pure" in that regard even compared to Lisp.

But one thing to note here is that live coding is not really that useful
when used always. At least for me I rely a lot on it for debugging and
experimenting. But when I work based on a plan , or code just works I do
not care so much about it.

So my workflow in the end is semi-live coding because I dont feel I need
live coding 24/7 to be super productive.

Of course that creates some barriers in the end when tools are not made to
work 24/7 on a live coding context. To that extend Pharo is definetly
superior and a true live coding enviroment.

You are suprised that you can do live coding in C++ but I was trully
shocked.

My saga to do live coding in C++ started as a joke, something to use to
mock C++ ugliness and weakness. But oh boy it did slap it back to my face.

The process is again simple, you wrap eveything inside a main loop,and call
in this loop functions (C has no objects obvious) or methods if you use C++
from DLLs. Those DLLs obviously contain 99.9% of your code. Because a DLL
can be reloaded it allows you not to stop executing and replace code on the
fly. The main loop is wrapped inside an exception to make sure the an error
will never crash your application, C/C++ exceptions are more powerful than
Pharo live coding in that regard because in Pharo if you do anything bad
with UFFI and crash it , it will crash for sure.

If you keep the DLL small and  you use tons of small dlls your compile
times will be almost instantenous. You can also with very view lines detect
date signature change in source file and trigger background compilation.
Again few lines of code. The last mountain is live state, in this case the
executable pass a single pointer and instead of the executable handling the
memory its actually the dlls that handle it but the executable because it
cannot crash or exit will keep the live state running. You can also use
memory mapped file to store live state as they perform pure memory dumps.

All in all you will end up with 100 lines of code that can be wrapped into
a library and reused in the next project with zero setup. Its an one time
pain.

Will I would recommend C++ over Pharo for live coding  helll no C++
obviously misses a hugely important live coding ingredient which is
reflection. We do live coding because we want to interact with those
objects ask questions about what is going on and why our code does not work
as intended

However Python has no such limitation following a very similar design to
Smalltalk and being much more powerful language than C++. Python follow
very closely the Smalltalk paradigm even though there is not a single
mention of Smalltalk , anywhere in the Python community or of live coding.

Live coding in C++ has become a huge deal in game development mainly
because game development tend to want to change things on the fly and games
are so big with extremely long compile times. Unreal has made a huge deal
over its ability to hot reload C++  code in its editor , though I do not
like its approach so much.

Bottom line is yes its easy and simple to do live coding in other
languages, not recommended so much in C++ because of its static compiled
nature and lack of reflection but for dynamic language like Python it can
come pretty close and I speak from experience.

At least I have not found something in Python that made me wish I was live
coding in Pharo so far, but then yes I still think its better to have a
full blown live coding. Also from my limited understanding I have figured
out that pretty much every language out there allows for reloading code
which is pretty much a very large requirement for live coding.

So yes you can live code to an extend, lesser in languages like C++ , more
so in language like Python, Ruby etc. Can you get the Pharo experience ? In
a dynamic language with the creation of a live coding library you could get
pretty close but never exactly the same.

Pharo still is the undisputed king of live coding.

Why live coding is not a huge thing in coding in general, I am willing to
bet it has more to do with coder mentality than language limitation. When
you are used to "dead  code" workflow it difficult to switch. I struggle a
lot to get use to the live coding workflow of Pharo because I had to rewire
my brain. But in the end you cannot avoid live coding, there will be always
scenarios you would want to change things on the fly, reload code, store
live state etc.

In the end it more a coder flaw than it is a language flaw. I know we love
to blame languages for our mistakes.

But in our back of our head we all know we debate over languages that we
barely use only 0.01% of their true potential. We are too lazy and
sometimes 

Re: [Pharo-users] [Ann] PharoLauncher v1.0.1 released!

[Ben Coman]

On Sat, Oct 7, 2017 at 3:38 PM, Nicolai Hess  wrote:

> Just starting pharolauncher on windows still does not work (if you put it
> into the default "program" folder).
> On start, it tries to create a local direcitory "pharo-local" and does not
> have the permission to do so.
> You need to start it with admin-rights.
>

Why are we making it harder for Windows users in corporate environments by
requiring them to have admin-rights they often won't have, while in Linux
PharoLancher is installed into user folders?

Also there is the UAC Virtualization fiasco that complicates installing
upgrades.
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-January/091645.html

Could we *please* install Windows PharoLauncher into user folders?
What reason is there not to?

cheers -ben


>
>> On Fri, Oct 6, 2017 at 5:35 PM, Christophe Demarey <
>> christophe.dema...@inria.fr> wrote:
>>
>>> Hi Gabriel,
>>>
>>> Le 6 oct. 2017 à 15:48, Gabriel Cotelli  a écrit :
>>>
>>> I've tried it on Linux, and after the download has finished it cannot
>>> launch a Pharo 6.1 image. Find attached the PharoDebug.log
>>>
>>> Seems it's searching for the sources file in a wrong location.
>>> *Pharo cannot locate the sources file named
>>> /home/gcotelli/Pharo/pharo-launcher/bin/lib/pharo/5.0-201707201942/PharoV60.sources.*
>>>
>>> I have wondered for a while if sources files should searched for up the
directory hierarchy looking for a "/sources" folder to minimize the number
of copies needed.

cheers -ben

Re: [Pharo-users] FileReference#entries caching?

[Peter Uhnák]

On Sat, Oct 7, 2017 at 1:02 PM, Steven R. Baker 
wrote:

> Is it cached or something? How do I guarantee that I'm *definitely*
> getting the current state of the directory on disk?


This looks extremely strange, I've never seen that inspecting
files/directories would be somehow "out of sync" with the disk, because it
is always asking the disk.



Should I not even be using FileReference for this?
>

If you are loading png icons into Pharo, you can consider using
https://github.com/peteruhnak/IconFactory/ instead (shameless self
promotion :) )

Peter

[Pharo-users] Futures, in Scale (was: Re: Embeddable Smalltalk (was: Re: Behold Pharo: The Modern Smalltalk))

[Herby Vojčík]

Hi,

I have looked at Scale b/c of different question, and I see it uses futures.

I'd like to ask if those futures are one-off, or is there any consensus 
on how futures should look like in Pharo. The reason I ask is b/c Amber 
already has something like that - Promises, which do not use the native 
JS API directly (though it is inspired), but do have an API of their 
own; and since those concepts seems to be similar (or maybe are the 
same, just called differently), if the API used shouldn't be sort-of 
standardized / used the same way in all occasions.


Herby

P.S.: Including state-of-the-art Promises.st from Amber master branch to 
get a picture:


Smalltalk createPackage: 'Kernel-Promises'!
Object subclass: #Promise
instanceVariableNames: ''
package: 'Kernel-Promises'!

!Promise class methodsFor: 'composites'!

all: aCollection
"Returns a Promise resolved with results of sub-promises."

!

any: aCollection
"Returns a Promise resolved with first result of sub-promises."

! !

!Promise class methodsFor: 'instance creation'!

forBlock: aBlock
"Returns a Promise that is resolved with the value of aBlock,
and rejected if error happens while evaluating aBlock."
^ self new then: aBlock
!

new
"Returns a dumb Promise resolved with nil."

!

new: aBlock
"Returns a Promise that is eventually resolved or rejected.
Pass a block that is called with one argument, model.
You should call model value: ... to resolve the promise
and model signal: ... to reject the promise.
If error happens during run of the block,
promise is rejected with that error as well."

!

signal: anObject
"Returns a Promise rejected with anObject."
Promise.reject(x)})'>

!

value: anObject
"Returns a Promise resolved with anObject."
Promise.resolve(x)})'>

! !

Trait named: #TThenable
package: 'Kernel-Promises'!

!TThenable methodsFor: 'promises'!

catch: aBlock
$core.seamless(function () {

return aBlock._value_(err);
})})'>
!

on: aClass do: aBlock
$core.seamless(function () {

if (err._isKindOf_(aClass)) return aBlock._value_(err);
else throw err;
})})'>
!

on: aClass do: aBlock catch: anotherBlock
^ (self on: aClass do: aBlock) catch: anotherBlock
!

then: aBlockOrArray
"Accepts a block or array of blocks.
Each of blocks in the array or the singleton one is
used in .then call to a promise, to accept a result
and transform it to the result for the next one.
In case a block has more than one argument
and result is an array, first n-1 elements of the array
are put into additional arguments beyond the first.
The first argument always contains the result as-is."
 1 ?
function (result) {return $core.seamless(function () {
if (Array.isArray(result)) {
return 
aBlock._valueWithPossibleArguments_([result].concat(result.slice(0, 
aBlock.length-1)));

} else {
return aBlock._value_(result);
}
})} :
function (result) {return $core.seamless(function () {
return aBlock._value_(result);
})}
);
}, self)'>
!

then: aBlockOrArray catch: anotherBlock
^ (self then: aBlockOrArray) catch: anotherBlock
!

then: aBlockOrArray on: aClass do: aBlock
^ (self then: aBlockOrArray) on: aClass do: aBlock
!

then: aBlockOrArray on: aClass do: aBlock catch: anotherBlock
^ ((self then: aBlockOrArray) on: aClass do: aBlock) catch: anotherBlock
! !

Promise setTraitComposition: {TThenable} asTraitComposition!
! !



p...@highoctane.be wrote:

https://github.com/guillep/Scale  is
quite cool for quick scripts on *nix.

Now for embeddable, yes it would help. Bootstrapping will be helpful but
the current main issue is the VM interpret loop that is in the current VMs.

It is not an intrinsic problem. Telepharo is also a great step to enable
that to exist.

Phil

On Oct 7, 2017 13:05, "Herby Vojčík" > wrote:

Ben Coman wrote:

Nice article. I like the way you've structured it and pushed the
"updated" angle.

I feel a bit too strong a claim is laid on Pharo producing the
CogVM.
Much of the Cog + Spur + 64bit VM work was originally done for
Squeak
with Pharo riding the coat-tails of that work.  Lately Pharo
community
has been involved in improving VM with hotspot optimisation with
Sista
and moving towards making Pharo embeddable.. (@Clement, is "hotspot


Hi, this made me curious. I always had the problem with Amber (and,
all the rest of Smalltalks in similar vein) that it is hard to use
to one-off scripting, as it presumes existence of the not really
small class library (objects, classes, collections, etc.). This
disadvantaged it IMO in the field of "can I just embed it here and
script it with a few lines?" scenarios.

Did you (the Pharo community that is "moving towards making Pharo

Re: [Pharo-users] Deploying on Linux with LibC version < 2.15

[p...@highoctane.be]

I would rather qualify Ubuntu as hell when deploying large setups of
machines that have to be kept in working order for a long while.

We should give top notch support for RHEL if we want to be relevant in
spaces like Hadoop for example as the reference platform is RHEL/CentOS.

Phil


On Oct 6, 2017 16:20, "Andrew Glynn"  wrote:

> There's a reason it's referred to by numerous developers as R-HELL.
>
> Andrew Glynn
>
> -Original Message-
>
> *Date*: Thu, 5 Oct 2017 21:46:20 +0800
> *Subject*: Re: [Pharo-users] Deploying on Linux with LibC version < 2.15
> *To*: bruce.on...@pckswarms.ch, Any question about pharo is welcome <
> pharo-users@lists.pharo.org
> 
> >
> Reply-to: Any question about pharo is welcome  >
> *From*: Holger Freyther  >
>
>
> On 5. Oct 2017, at 18:08, Bruce O'Neel  wrote:
>
> Hi,
>
>
>
> Hi!
>
>
>
>
> Well, our redhat 6.9 systems have 2.12, so, that qualifies.
>
> And yes, we still have RedHat 6, and 6.9 was released only 6 months ago!  It 
> will finish extended support in a mind-blowing 7 more years in 2024.
>
> Redhat 5, still supported for another 3 years till 2020 has glibc 2.5.
>
>
>
>
> for a brief moment you really scared me. I thought you referred to RedHat 
> Linux 6 which was released in 1999 but you are referring to Red Hat 
> Enterprise Linux (RHEL).
>
> As it turns out we have "latest" (as soon as a commit is made to 
> pharo-vm.git) and hand curated "stable" (hand created source tarballs, 
> rebuilt from a git commit of opensmalltalk-vm) for RHEL6 and CentOS 6.
>
> CentOS 6.x:
>
> # Add the repo
> $ yum-config-manager --add-repo 
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/CentOS_6/devel:languages:pharo:latest.repo
>
> OR (for stable):
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/CentOS_6/devel:languages:pharo:stable.repo
>
> # Install 32bit packages (with X11 dependency for *-ui or not)
>
> $ yum install pharo6-32-ui.i686 or pharo6-32.i386
>
> # Install 64bit packages
>
> $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64
>
>
>
>
>
>
>

Re: [Pharo-users] Embeddable Smalltalk (was: Re: Behold Pharo: The Modern Smalltalk)

[p...@highoctane.be]

https://github.com/guillep/Scale is quite cool for quick scripts on *nix.

Now for embeddable, yes it would help. Bootstrapping will be helpful but
the current main issue is the VM interpret loop that is in the current VMs.

It is not an intrinsic problem. Telepharo is also a great step to enable
that to exist.

Phil

On Oct 7, 2017 13:05, "Herby Vojčík"  wrote:

Ben Coman wrote:

> Nice article. I like the way you've structured it and pushed the
> "updated" angle.
>
> I feel a bit too strong a claim is laid on Pharo producing the CogVM.
> Much of the Cog + Spur + 64bit VM work was originally done for Squeak
> with Pharo riding the coat-tails of that work.  Lately Pharo community
> has been involved in improving VM with hotspot optimisation with Sista
> and moving towards making Pharo embeddable.. (@Clement, is "hotspot
>

Hi, this made me curious. I always had the problem with Amber (and, all the
rest of Smalltalks in similar vein) that it is hard to use to one-off
scripting, as it presumes existence of the not really small class library
(objects, classes, collections, etc.). This disadvantaged it IMO in the
field of "can I just embed it here and script it with a few lines?"
scenarios.

Did you (the Pharo community that is "moving towards making Pharo
embeddable") find some way to work this around?

cheers -ben
>

Herby

Re: [Pharo-users] What does RMoD stand for?

[Sven Van Caekenberghe]

> On 7 Oct 2017, at 13:06, Rene Paul Mages (ramix)  wrote:
> 
> 
> 
> Le 07/10/2017 à 12:59, horrido a écrit :
>> It is bizarre. Nowhere on the web can I find any reference to what INRIA's
>> *RMoD* acronym stands for.
> 
> Please try this request :
> 
> https://tinyurl.com/INRIA-Rmod

But it is strange that their main page does not say (AFAICS).

It is something like Research into Modular Systems, but I am just guessing ;-)

> -- 
> Amicalement.
> Rene Paul Mages ( GnuPG_key 1024D/2CC455D9 )
> http://www.linux-azur.org/ramix
> http://blog.pharo.fr
> http://nosoftwarepatents.wikidot.com
> 
> 
> 

Re: [Pharo-users] What does RMoD stand for?

[Rene Paul Mages (ramix)]

Le 07/10/2017 à 12:59, horrido a écrit :
> It is bizarre. Nowhere on the web can I find any reference to what INRIA's
> *RMoD* acronym stands for.

Please try this request :

 https://tinyurl.com/INRIA-Rmod

-- 
Amicalement.
Rene Paul Mages ( GnuPG_key 1024D/2CC455D9 )
http://www.linux-azur.org/ramix
http://blog.pharo.fr
http://nosoftwarepatents.wikidot.com

[Pharo-users] Embeddable Smalltalk (was: Re: Behold Pharo: The Modern Smalltalk)

[Herby Vojčík]

Ben Coman wrote:

Nice article. I like the way you've structured it and pushed the
"updated" angle.

I feel a bit too strong a claim is laid on Pharo producing the CogVM.
Much of the Cog + Spur + 64bit VM work was originally done for Squeak
with Pharo riding the coat-tails of that work.  Lately Pharo community
has been involved in improving VM with hotspot optimisation with Sista
and moving towards making Pharo embeddable.. (@Clement, is "hotspot


Hi, this made me curious. I always had the problem with Amber (and, all 
the rest of Smalltalks in similar vein) that it is hard to use to 
one-off scripting, as it presumes existence of the not really small 
class library (objects, classes, collections, etc.). This disadvantaged 
it IMO in the field of "can I just embed it here and script it with a 
few lines?" scenarios.


Did you (the Pharo community that is "moving towards making Pharo 
embeddable") find some way to work this around?



cheers -ben


Herby

[Pharo-users] FileReference#entries caching?

[Steven R. Baker]

Heya folks,

I'm loading some PNG icons from disk, and I'm noticing some weirdness
with FileReference#entries.

When I inspect: '/home/srbaker/Projects/FocusFrog/icons' asFileReference
entries it gives me an Array of size one, containing the refernce to the
only file there. Then I delete the file, the same thing gives an array
of size zero.

But then when I fill the directory with a bunch of icons (240, to be
exact), and inspect that line again I get zero. Eventually it gets the
right answer.

Is it cached or something? How do I guarantee that I'm *definitely*
getting the current state of the directory on disk? Should I not even be
using FileReference for this?

Thanks!

-Steven

[Pharo-users] What does RMoD stand for?

[horrido]

It is bizarre. Nowhere on the web can I find any reference to what INRIA's
*RMoD* acronym stands for.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Deploying on Linux with LibC version < 2.15

[Dimitris Chloupis]

Why use a special Pharo VM when you can use LibC via UFFI from inside the
image ? UFFI even offers partial wrapper to LibC. We prefer afterall to
move things outside the VM and inside the image as much as we can to offers
us a greater deal of flexibility.

On Sat, Oct 7, 2017 at 12:45 PM Cyril Ferlicot D. 
wrote:

> Le 05/10/2017 à 15:46, Holger Freyther a écrit :
> >
> > Hi!
> >
> >
> > for a brief moment you really scared me. I thought you referred to
> RedHat Linux 6 which was released in 1999 but you are referring to Red Hat
> Enterprise Linux (RHEL).
> >
> > As it turns out we have "latest" (as soon as a commit is made to
> pharo-vm.git) and hand curated "stable" (hand created source tarballs,
> rebuilt from a git commit of opensmalltalk-vm) for RHEL6 and CentOS 6.
> >
> > CentOS 6.x:
> >
> > # Add the repo
> > $ yum-config-manager --add-repo
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/CentOS_6/devel:languages:pharo:latest.repo
> >
> > OR (for stable):
> >
> >
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/CentOS_6/devel:languages:pharo:stable.repo
> >
> > # Install 32bit packages (with X11 dependency for *-ui or not)
> >
> > $ yum install pharo6-32-ui.i686 or pharo6-32.i386
> >
> > # Install 64bit packages
> >
> > $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64
> >
> >
>
> Hi,
>
> Maybe the instructions for CentOS and RHEL could be added to the linux
> download page of pharo.org?
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[horrido]

> My point is that indeed you can do with EASE live coding in a numerous
languages, at least to my experience. I have tried only Python and C/C++.

Until I came upon this thread, I never knew you could do live coding in
Python and C/C++. And I was a professional C/C++ programmer for over 15
years!

It is certainly a well-kept secret. I have found very little information on
the web about doing live coding in these languages (in fact, none). This
leads me to believe that the vast majority of Python and C/C++ developers
don't know about, or don't do, live coding.

Whether it's "easy" is rather subjective. I suspect it's not as easy nor as
convenient as in Pharo. If it were, then live coding ought to be much more
prevalent in the Python and C/C++ communities. After all, what developer
doesn't want to improve their productivity or increase their velocity of
development?

The key differentiator here, I think, is that live coding is baked into
Pharo/Smalltalk, thus making it natural to use. It is not natural for Python
and C/C++ programmers. It would be difficult to convince the IT industry to
adopt live coding en masse.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Equals and HashCode Builder

[Noury Gmail]

Hi,

I have developed few years ago a trait-based solution to make it easy to deal 
with equality.
By default, instances of the same class with equal IVs are equal + have the 
same hash code.
You can customize the list of IVs to compare, which is handy in case of IVs 
that store cache values.
All you have to do is to use the TEquality in your class.

The code + tests are here 
http://smalltalkhub.com/#!/~CAR/ReusableBricks/packages/Equals

This is part of the "ReusableBricks" repo that gather packages we're using it 
in different projects in my team.
And it works fine.
I'd love to have this integrated in Pharo.

Note : I no longer receive mailing-lists emails, because I can't handle all the 
traffic. We can continue the conversation on Discord


Noury
> 
> 
> On 06 Oct 2017, at 18:31, Stephane Ducasse  wrote:
> 
> Contact noury because I do not remember.
> But having a little builder is also nice.
> 
> On Fri, Oct 6, 2017 at 4:15 PM, Vitor Medina Cruz  
> wrote:
>> Stephane
>> 
>> "Vitor why don't you take it as a small project to propose a solution for
>> Pharo."
>> 
>> I will try :) I like the idea of using a Trait.
>> 
>> 
>> Em 6 de out de 2017 05:01, "Stephane Ducasse" 
>> escreveu:
>> 
>> Here is what I extracted from older emails
>> 
>> From David Allouche in Pharo-dev to see if
>> The ==hash== method is used in Pharo to separate objects in
>> bucket-based data structures.
>> 
>> 
>> !! Property
>> 
>> It must have one required property which is required data integrity:
>> 
>>  A.
>> Objects that are equal according to ==\=== must have equal hashes.
>> 
>> 
>> It should have two desirable properties that are required to support
>> the algorithmic assumptions of bucket-based data structures:
>> 
>>  B.
>> Objects that are not equal should have different hashes. Ideally, the
>> probability of hash collision should by 1/N where N is the size of
>> hash value space.
>> 
>>  C. The hash values should spread as much as possible over their
>> value space. For example: ProtoObject>>#identityHash.
>> 
>> 
>> 
>> 
>> How these two desirable properties can be implemented depends on the
>> actual distribution of the values used to compute the hash.
>> 
>> An object can safely use XOR hashing if its instance variables are all
>> different objects that already provide a hash method with these two
>> properties.
>> 
>> @@todo check following sentence because the use of singleton is obscure
>> 
>> For example, an object whose behaviour is defined by several of
>> singleton delegates of different classes that do not override
>> Object>>#hash.
>> 
>> But if the instance variables are not guaranteed to have those
>> properties, it is necessary to more thoroughly "mix the bits". For
>> example the  method ==hash== of ==SequenceableCollection== illustrates
>> this point.
>> 
>> 
>> [[[
>> SequenceableCollection >> hash
>> | hash |
>> hash := self species hash.
>> 1 to: self size do: [:i | hash := (hash + (self at: i) hash) hashMultiply].
>> ^ hash
>> ]]]
>> 
>> 
>> The mixing of the bits is done by the combination of addition and
>> ==hashMultiply==. The value of ==species hash== does not need to be
>> processed by ==hashMultiply==, because it is probably computed by the
>> method =identityHash== of ==ProtoObject==, and that already provides
>> property C.
>> 
>> !!! When we should not use XOR
>> 
>> ==LayoutFrame== is a particularly good example of a data structure
>> that should not use XOR hashing. Its instance variables provide none
>> of the required properties:
>> 
>> - ==SmallInteger>>hash== is just ==^self==.
>> - In addition, common ==LayoutFrame== instances tend to use pairs of
>> identical values in their instance variables. Like ==0@0 corner:
>> 1@1==, or ==Margin fromNumber: 10==.
>> 
>> A good hash function for LayoutFrame needs to:
>> 
>> - Get hashes for each instance variable that provides properties A and B.
>> - Combine them in a way that is order-sensitive (to maintain property
>> B) and that does some extra mixing (to provide property C).
>> 
>> Now, we can assume that common values for the instance variables will
>> be instances of ==SmallInteger==, ==Float==, or ==Fraction==.
>> 
>> You can see in ==Fraction>>hash==, that a comment mentions the
>> assumption that the fraction is already reduced, that is what makes it
>> acceptable to use bitXor.
>> 
>> The hash of ==SmallInteger== does provide properties A and B, but not
>> property C. The hash of ==Float== is harder to understand, but tests
>> show that it provides distinct values for 0.5, 0.25 and 0.125. So it
>> hopefully provides B for the range of values of interest to
>> ==LayoutFrame==.
>> 
>> Another class that has similar hashing constraints to ==LayoutFrame==
>> is ==Point==. Its ==hash== method is:
>> 
>> [[[
>> Point >> hash
>> "Hash is reimplemented because = is implemented."
>> ^(x hash hashMultiply + y hash) hashMultiply
>> ]]]
>> 
>> It does not 

Re: [Pharo-users] [Ann] PharoLauncher v1.0.1 released!

[Christophe Demarey]

Hi Nicolai,

> Le 7 oct. 2017 à 09:38, Nicolai Hess  a écrit :
> 
> Just starting pharolauncher on windows still does not work (if you put it 
> into the default "program" folder).
> On start, it tries to create a local direcitory "pharo-local" and does not 
> have the permission to do so.
> You need to start it with admin-rights.

A Pharo image needs write permission in the image folder to store image 
sessions (epicea) as well as other image data (package cache, play-cache, 
changes file, etc.)
Maybe we should disable Epicea and it could work in a read only environment?

For now, either you can start it with admin rights or you install Pharo 
Launcher in a user folder.

Regards,
Christophe

Re: [Pharo-users] Deploying on Linux with LibC version < 2.15

[Cyril Ferlicot D.]

Le 05/10/2017 à 15:46, Holger Freyther a écrit :
> 
> Hi!
> 
> 
> for a brief moment you really scared me. I thought you referred to RedHat 
> Linux 6 which was released in 1999 but you are referring to Red Hat 
> Enterprise Linux (RHEL).
> 
> As it turns out we have "latest" (as soon as a commit is made to 
> pharo-vm.git) and hand curated "stable" (hand created source tarballs, 
> rebuilt from a git commit of opensmalltalk-vm) for RHEL6 and CentOS 6.
> 
> CentOS 6.x:
> 
> # Add the repo
> $ yum-config-manager --add-repo 
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/CentOS_6/devel:languages:pharo:latest.repo
> 
> OR (for stable):
> 
> http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/CentOS_6/devel:languages:pharo:stable.repo
> 
> # Install 32bit packages (with X11 dependency for *-ui or not)
> 
> $ yum install pharo6-32-ui.i686 or pharo6-32.i386
> 
> # Install 64bit packages
> 
> $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64
> 
> 

Hi,

Maybe the instructions for CentOS and RHEL could be added to the linux
download page of pharo.org?


-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] using mocketry to mock subcall

[Denis Kudriashov]

Hi Peter.

You should stub instance instead of class:
 s := Something new.
 s stub askFor...

7 окт. 2017 г. 9:18 пользователь "Peter Uhnák"  написал:

> Hi,
>
> maybe I am missing something fundamental, because this seems like an
> obvious scenario
>
> I have a class Something with two methods
>
> Something>>askForName
> ^ UIManager default request: 'Name'
>
> Something>>name
> ^ self askForName , ' suffix'
>
> Now I want to mock out askForName, so I can run it automatically in
> tests...
>
> I've tried just stubbing it...
>
> SomethingTest>>testRenameStub
> Something stub askForName willReturn: 'new'.
> Something new name should be: 'new suffix'
>
> however it still opens the window to ask for the name, so the original
> method is being called.
>
> Right now I have to stub it with metalinks, which doesn't play well with
> some tools (hapao)
>
> SomethingTest>>testRenameMeta
> | link newName |
> link := MetaLink new
> metaObject: [ 'new' ];
> control: #instead.
> (Something >> #askForName) ast link: link.
> [ newName := Something new name ]
> ensure: [ link uninstall ].
> self assert: newName equals: 'new suffix'
>
> Thanks,
> Peter
>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

The dicussion is about Pharo's live coding and OOP compared to other
languages.

IF you look at all my threads you will see I ALWAYS mention Python ,
Blender , Unreal for relevant topics. I do not remember hi jackig a thread
with random remarks just for the shake of mentioning those things.

Plus 99% of the times I mention Python is about Atlas , my library for
using Python libraries from inside Pharo.  Atlas is a "trojan horse" for
Pharo to invade Python projects.

Also I have been very clear that I consider C++ an abomination syntax wise
and Python weaker than Smalltalk, language wise.Mainly because of
Smalltalk's minimal syntax and of course offering live coding outside the
box with no special setup from the coder.

My point is that indeed you can do with EASE live coding in a numerous
languages, at least to my experience. I have tried only Python and C/C++.
Is it as easy or as flexible as Pharo ? I do not know because live coding
as you know is about workflow and we dont code all the same way. For
example I was never comfortable with coding solely from inside Pharo
debugger as some of you are doing. I am more a Class Browser guy and I
rarely use Workspace/Playground/REPL as well.

My questions were sincere even though I was sarcastic because I always want
to learn more about live coding and things I do not know about OOP. My
sarcasm was an effort to be funny not to be rude.

I am also certain that many experienced coders coming from other language
will ask the same questions as well. What Pharo can give me OO wise that I
cannot get in my X language ?  What exactly is live coding for Pharo ? Is
doing X things in that Y language live coding or is it something else ?
What's the real purpose of message passing ? How it benefits me compared to
just using method calls ?

I am suprised that there has not been an article about live coding
workflows. I think it could greatly benefit Pharo to demostrate its
uniqueness.

People prefer to be shown that something is better than being told.

Most people also not bother at all coming to the mailing list and ask
questions, they will  ignore things they dont understand and carry on.

So its not important to say that Pharo special but why Pharo is special and
after 5 year I feel will still struggle in this area, not because of the
fault of the community but because live coding and OOP can be an extremely
wide field that you can easily get lost into.

We have also to be fair with othe programming languages, respect them, to
the degree they deserve our respect and not exaggerate our claims because
that harms Pharo reputation.

On Sat, Oct 7, 2017 at 11:50 AM Sven Van Caekenberghe  wrote:

> Your contribution to Pharo are much appreciated. And indeed you did not
> directly say anything negative.
>
> But you have to agree that you often discuss about Python, C++, Blender,
> ... in mailing lists that are not for that purpose. You are absolutely free
> to do whatever you want and to give your opinions freely, but this is not
> the right place.
>
> > On 7 Oct 2017, at 10:42, Dimitris Chloupis 
> wrote:
> >
> > I agree, ignore that crazy dude that he is all talk and non sense
> excluding the fact the original article uses a graphic he made with love
> for Pharo and with over 5 years of active contribution to Pharo
> documentation and libraries. OR the fact that he said nothing negative
> about Pharo in this thread.
> >
> > Or the fact that he said that is enternal greatful for Pharo introducing
> him to the art and fun of live coding. What's more negative than that ,
> right ?
> >
> > On Sat, Oct 7, 2017 at 11:14 AM Stephane Ducasse <
> stepharo.s...@gmail.com> wrote:
> > Hi sven
> >
> > Do the same than me, trash this thread and let us focus on making Pharo
> better.
> > This is far better productive and energy positive.
> >
> > Stef
> >
> > On Sat, Oct 7, 2017 at 12:16 AM, Sven Van Caekenberghe 
> wrote:
> > > Yes, you are right: Pharo/Smalltalk is more or less the same as
> Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding.
> > >
> > > Come on.
> > >
> > >> On 6 Oct 2017, at 23:18, Dimitris Chloupis 
> wrote:
> > >>
> > >> Wise not to mention Ruby and Python and Pick the worst of the worst
> in OOP. Because frankly the competition for Pharo against those two
> behemoths can be quite brutal in the flexibility and power of OOP.
> > >>
> > >> And no , these language can do live coding with ease. I know because
> I currently code live coding style with Python for an app I am making. Sure
> it wont provide you with a live system out of the box, but put in 10 lines
> of code and you already ready to go with hardcore live coding. At least
> Python , Ruby being practically a rip off of Smalltalk language may need
> even less.
> > >>
> > >> iPython which by the way is by far the most popular Python tool is
> the real deal, a full blow live coding enviroment.
> > >>
> > >> To my 

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Sven Van Caekenberghe]

Your contribution to Pharo are much appreciated. And indeed you did not 
directly say anything negative.

But you have to agree that you often discuss about Python, C++, Blender, ... in 
mailing lists that are not for that purpose. You are absolutely free to do 
whatever you want and to give your opinions freely, but this is not the right 
place.

> On 7 Oct 2017, at 10:42, Dimitris Chloupis  wrote:
> 
> I agree, ignore that crazy dude that he is all talk and non sense excluding 
> the fact the original article uses a graphic he made with love for Pharo and 
> with over 5 years of active contribution to Pharo documentation and 
> libraries. OR the fact that he said nothing negative about Pharo in this 
> thread. 
> 
> Or the fact that he said that is enternal greatful for Pharo introducing him 
> to the art and fun of live coding. What's more negative than that , right ? 
> 
> On Sat, Oct 7, 2017 at 11:14 AM Stephane Ducasse  
> wrote:
> Hi sven
> 
> Do the same than me, trash this thread and let us focus on making Pharo 
> better.
> This is far better productive and energy positive.
> 
> Stef
> 
> On Sat, Oct 7, 2017 at 12:16 AM, Sven Van Caekenberghe  wrote:
> > Yes, you are right: Pharo/Smalltalk is more or less the same as 
> > Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding.
> >
> > Come on.
> >
> >> On 6 Oct 2017, at 23:18, Dimitris Chloupis  wrote:
> >>
> >> Wise not to mention Ruby and Python and Pick the worst of the worst in 
> >> OOP. Because frankly the competition for Pharo against those two behemoths 
> >> can be quite brutal in the flexibility and power of OOP.
> >>
> >> And no , these language can do live coding with ease. I know because I 
> >> currently code live coding style with Python for an app I am making. Sure 
> >> it wont provide you with a live system out of the box, but put in 10 lines 
> >> of code and you already ready to go with hardcore live coding. At least 
> >> Python , Ruby being practically a rip off of Smalltalk language may need 
> >> even less.
> >>
> >> iPython which by the way is by far the most popular Python tool is the 
> >> real deal, a full blow live coding enviroment.
> >>
> >> To my suprise its not even hard to do live coding with C/C++ including 
> >> using image format. To my shock live coding is actually supported by both 
> >> the OS and the hardware. Hardware has its own exception system , OS has an 
> >> image flie format called "memory mapped files" used for DLLs and a lot of 
> >> essential functionality.
> >>
> >> For some weird reason however its well hidden and not that much utilised 
> >> by coders. They really love long compile times, dont ask me why.
> >>
> >> But yeah C++ even though it has come a long way with its template system, 
> >> its still the king of ugly. That sytax, oh the horrors of that syntax. 
> >> yiaks !!!
> >>
> >> I am so enternal greatful that Pharo introduced me to live coding and 
> >> opened my eyes to universe of fun and productivity. I cannot imagine 
> >> coding an other way ever again.
> >>
> >> I really hope that we take this further though.
> >>
> >> On Wed, Oct 4, 2017 at 1:31 PM horrido  wrote:
> >> Behold Pharo: The Modern Smalltalk
> >> 
> >>
> >> If you would like to suggest some edits, I'm all ears. Anything to improve
> >> the impact of the article.
> >>
> >> Thanks.
> >>
> >>
> >>
> >> --
> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> >>
> >
> >
> 

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Dimitris Chloupis]

I agree, ignore that crazy dude that he is all talk and non sense excluding
the fact the original article uses a graphic he made with love for Pharo
and with over 5 years of active contribution to Pharo documentation and
libraries. OR the fact that he said nothing negative about Pharo in this
thread.

Or the fact that he said that is enternal greatful for Pharo introducing
him to the art and fun of live coding. What's more negative than that ,
right ?

On Sat, Oct 7, 2017 at 11:14 AM Stephane Ducasse 
wrote:

> Hi sven
>
> Do the same than me, trash this thread and let us focus on making Pharo
> better.
> This is far better productive and energy positive.
>
> Stef
>
> On Sat, Oct 7, 2017 at 12:16 AM, Sven Van Caekenberghe 
> wrote:
> > Yes, you are right: Pharo/Smalltalk is more or less the same as
> Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding.
> >
> > Come on.
> >
> >> On 6 Oct 2017, at 23:18, Dimitris Chloupis 
> wrote:
> >>
> >> Wise not to mention Ruby and Python and Pick the worst of the worst in
> OOP. Because frankly the competition for Pharo against those two behemoths
> can be quite brutal in the flexibility and power of OOP.
> >>
> >> And no , these language can do live coding with ease. I know because I
> currently code live coding style with Python for an app I am making. Sure
> it wont provide you with a live system out of the box, but put in 10 lines
> of code and you already ready to go with hardcore live coding. At least
> Python , Ruby being practically a rip off of Smalltalk language may need
> even less.
> >>
> >> iPython which by the way is by far the most popular Python tool is the
> real deal, a full blow live coding enviroment.
> >>
> >> To my suprise its not even hard to do live coding with C/C++ including
> using image format. To my shock live coding is actually supported by both
> the OS and the hardware. Hardware has its own exception system , OS has an
> image flie format called "memory mapped files" used for DLLs and a lot of
> essential functionality.
> >>
> >> For some weird reason however its well hidden and not that much
> utilised by coders. They really love long compile times, dont ask me why.
> >>
> >> But yeah C++ even though it has come a long way with its template
> system, its still the king of ugly. That sytax, oh the horrors of that
> syntax. yiaks !!!
> >>
> >> I am so enternal greatful that Pharo introduced me to live coding and
> opened my eyes to universe of fun and productivity. I cannot imagine coding
> an other way ever again.
> >>
> >> I really hope that we take this further though.
> >>
> >> On Wed, Oct 4, 2017 at 1:31 PM horrido 
> wrote:
> >> Behold Pharo: The Modern Smalltalk
> >> <
> https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c46053
> >
> >>
> >> If you would like to suggest some edits, I'm all ears. Anything to
> improve
> >> the impact of the article.
> >>
> >> Thanks.
> >>
> >>
> >>
> >> --
> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> >>
> >
> >
>
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Sven Van Caekenberghe]

> On 7 Oct 2017, at 10:15, Stephane Ducasse  wrote:
> 
>> To be honest, I didn't know you could do live coding in Python, Ruby, C/C++.
>> I had only ever heard of "hot swapping" in Java.
> 
> Me neither :)
> Do not worry and let us continue to work on making Pharo better.
> I did not know that a.out and core.dmp where live programming :)

With gdb and assembler you can do live coding & OOP too ;-)

> Stef
> 
>> At any rate, I'd be surprised if live coding in these languages was as easy
>> and convenient as in Pharo/Smalltalk.
> 
> Me too but they are catching up so let us continue to make Pharo super cool.
> 

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Stephane Ducasse]

> To be honest, I didn't know you could do live coding in Python, Ruby, C/C++.
> I had only ever heard of "hot swapping" in Java.

Me neither :)
Do not worry and let us continue to work on making Pharo better.
I did not know that a.out and core.dmp where live programming :)

Stef

> At any rate, I'd be surprised if live coding in these languages was as easy
> and convenient as in Pharo/Smalltalk.

Me too but they are catching up so let us continue to make Pharo super cool.

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Stephane Ducasse]

Hi sven

Do the same than me, trash this thread and let us focus on making Pharo better.
This is far better productive and energy positive.

Stef

On Sat, Oct 7, 2017 at 12:16 AM, Sven Van Caekenberghe  wrote:
> Yes, you are right: Pharo/Smalltalk is more or less the same as 
> Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding.
>
> Come on.
>
>> On 6 Oct 2017, at 23:18, Dimitris Chloupis  wrote:
>>
>> Wise not to mention Ruby and Python and Pick the worst of the worst in OOP. 
>> Because frankly the competition for Pharo against those two behemoths can be 
>> quite brutal in the flexibility and power of OOP.
>>
>> And no , these language can do live coding with ease. I know because I 
>> currently code live coding style with Python for an app I am making. Sure it 
>> wont provide you with a live system out of the box, but put in 10 lines of 
>> code and you already ready to go with hardcore live coding. At least Python 
>> , Ruby being practically a rip off of Smalltalk language may need even less.
>>
>> iPython which by the way is by far the most popular Python tool is the real 
>> deal, a full blow live coding enviroment.
>>
>> To my suprise its not even hard to do live coding with C/C++ including using 
>> image format. To my shock live coding is actually supported by both the OS 
>> and the hardware. Hardware has its own exception system , OS has an image 
>> flie format called "memory mapped files" used for DLLs and a lot of 
>> essential functionality.
>>
>> For some weird reason however its well hidden and not that much utilised by 
>> coders. They really love long compile times, dont ask me why.
>>
>> But yeah C++ even though it has come a long way with its template system, 
>> its still the king of ugly. That sytax, oh the horrors of that syntax. 
>> yiaks !!!
>>
>> I am so enternal greatful that Pharo introduced me to live coding and opened 
>> my eyes to universe of fun and productivity. I cannot imagine coding an 
>> other way ever again.
>>
>> I really hope that we take this further though.
>>
>> On Wed, Oct 4, 2017 at 1:31 PM horrido  wrote:
>> Behold Pharo: The Modern Smalltalk
>> 
>>
>> If you would like to suggest some edits, I'm all ears. Anything to improve
>> the impact of the article.
>>
>> Thanks.
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>
>

Re: [Pharo-users] [Ann] PharoLauncher v1.0.1 released!

[Stephane Ducasse]

+ 1000 :)


On Sat, Oct 7, 2017 at 9:44 AM, Nicolai Hess  wrote:
>
>
> 2017-10-07 9:38 GMT+02:00 Nicolai Hess :
>>
>> Just starting pharolauncher on windows still does not work (if you put it
>> into the default "program" folder).
>> On start, it tries to create a local direcitory "pharo-local" and does not
>> have the permission to do so.
>> You need to start it with admin-rights.
>
>
>
> Starting images for different vms works great.
> No more need to manually fight with downloading vms or source files :)
> Great!
>
>>
>>
>> 2017-10-06 22:43 GMT+02:00 Gabriel Cotelli :
>>>
>>> I've tried running it from the terminal and it works!.
>>>
>>> If I double-click it from the file manager and choose "Run in Terminal"
>>> it gives the previously commented error.
>>>
>>>
>>>
>>> On Fri, Oct 6, 2017 at 5:35 PM, Christophe Demarey
>>>  wrote:

 Hi Gabriel,

 Le 6 oct. 2017 à 15:48, Gabriel Cotelli  a écrit :

 I've tried it on Linux, and after the download has finished it cannot
 launch a Pharo 6.1 image. Find attached the PharoDebug.log

 Seems it's searching for the sources file in a wrong location.
 Pharo cannot locate the sources file named
 /home/gcotelli/Pharo/pharo-launcher/bin/lib/pharo/5.0-201707201942/PharoV60.sources.


 Strange indeed!
 I’m not able to reproduce it on my ubuntu vm.

 It’s surprising that sources file is search in the folder of the VM
 shipped with the launcher. Images are run with VM downloaded in the VM 
 store
 ($HOME/Pharo/vms) and sources file is search in the vm directory.
 Could you tell me if you run the launcher from a terminal? Could you
 send me your environment variables to see if I can find something relevant
 there?
>>>
>>>
>>
>

Re: [Pharo-users] [Ann] PharoLauncher v1.0.1 released!

[Nicolai Hess]

2017-10-07 9:38 GMT+02:00 Nicolai Hess :

> Just starting pharolauncher on windows still does not work (if you put it
> into the default "program" folder).
> On start, it tries to create a local direcitory "pharo-local" and does not
> have the permission to do so.
> You need to start it with admin-rights.
>


Starting images for different vms works great.
No more need to manually fight with downloading vms or source files :)
Great!


>
> 2017-10-06 22:43 GMT+02:00 Gabriel Cotelli :
>
>> I've tried running it from the terminal and it works!.
>>
>> If I double-click it from the file manager and choose "Run in Terminal"
>> it gives the previously commented error.
>>
>>
>>
>> On Fri, Oct 6, 2017 at 5:35 PM, Christophe Demarey <
>> christophe.dema...@inria.fr> wrote:
>>
>>> Hi Gabriel,
>>>
>>> Le 6 oct. 2017 à 15:48, Gabriel Cotelli  a écrit :
>>>
>>> I've tried it on Linux, and after the download has finished it cannot
>>> launch a Pharo 6.1 image. Find attached the PharoDebug.log
>>>
>>> Seems it's searching for the sources file in a wrong location.
>>> *Pharo cannot locate the sources file named
>>> /home/gcotelli/Pharo/pharo-launcher/bin/lib/pharo/5.0-201707201942/PharoV60.sources.*
>>>
>>>
>>> Strange indeed!
>>> I’m not able to reproduce it on my ubuntu vm.
>>>
>>> It’s surprising that sources file is search in the folder of the VM
>>> shipped with the launcher. Images are run with VM downloaded in the VM
>>> store ($HOME/Pharo/vms) and sources file is search in the vm directory.
>>> Could you tell me if you run the launcher from a terminal? Could you
>>> send me your environment variables to see if I can find something relevant
>>> there?
>>>
>>
>>
>

Re: [Pharo-users] [Ann] PharoLauncher v1.0.1 released!

[Nicolai Hess]

Just starting pharolauncher on windows still does not work (if you put it
into the default "program" folder).
On start, it tries to create a local direcitory "pharo-local" and does not
have the permission to do so.
You need to start it with admin-rights.

2017-10-06 22:43 GMT+02:00 Gabriel Cotelli :

> I've tried running it from the terminal and it works!.
>
> If I double-click it from the file manager and choose "Run in Terminal" it
> gives the previously commented error.
>
>
>
> On Fri, Oct 6, 2017 at 5:35 PM, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
>
>> Hi Gabriel,
>>
>> Le 6 oct. 2017 à 15:48, Gabriel Cotelli  a écrit :
>>
>> I've tried it on Linux, and after the download has finished it cannot
>> launch a Pharo 6.1 image. Find attached the PharoDebug.log
>>
>> Seems it's searching for the sources file in a wrong location.
>> *Pharo cannot locate the sources file named
>> /home/gcotelli/Pharo/pharo-launcher/bin/lib/pharo/5.0-201707201942/PharoV60.sources.*
>>
>>
>> Strange indeed!
>> I’m not able to reproduce it on my ubuntu vm.
>>
>> It’s surprising that sources file is search in the folder of the VM
>> shipped with the launcher. Images are run with VM downloaded in the VM
>> store ($HOME/Pharo/vms) and sources file is search in the vm directory.
>> Could you tell me if you run the launcher from a terminal? Could you send
>> me your environment variables to see if I can find something relevant there?
>>
>
>

[Pharo-users] using mocketry to mock subcall

[Peter Uhnák]

Hi,

maybe I am missing something fundamental, because this seems like an
obvious scenario

I have a class Something with two methods

Something>>askForName
^ UIManager default request: 'Name'

Something>>name
^ self askForName , ' suffix'

Now I want to mock out askForName, so I can run it automatically in tests...

I've tried just stubbing it...

SomethingTest>>testRenameStub
Something stub askForName willReturn: 'new'.
Something new name should be: 'new suffix'

however it still opens the window to ask for the name, so the original
method is being called.

Right now I have to stub it with metalinks, which doesn't play well with
some tools (hapao)

SomethingTest>>testRenameMeta
| link newName |
link := MetaLink new
metaObject: [ 'new' ];
control: #instead.
(Something >> #askForName) ast link: link.
[ newName := Something new name ]
ensure: [ link uninstall ].
self assert: newName equals: 'new suffix'

Thanks,
Peter