How to execute code

Hi,

Need some orientation here.

How to write the code to execute a piece of code in code presenter?

Thanks

Hilaire

/* frustration on

Ok, it is very frustrating learning from Pharo now. Since when Pharo is
not anymore discoverable?

I try to find from context menu how to code some sort of action. Here
how to execute a piece of code from a workspace.

I look in Playground contextual menu, then in Spec code presenter menu.
Both implement some sort of different way of doing this. Yes, why doing
think simple when you can just duplicate it.

But the worst I can not make sense of what I read, totally lost in the
level of abstraction.

my productivity == 0

frustration off*/

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

Thanks to Squeak, it tooks me 5 min to discover this simple things from
its workspace menu:

Compiler evaluate: ...

Oh, it does not work on Pharo. Ah, I remember I read something about a
new compiler named Opal. I tried prefixing it with Opal. Yes,
OpalCompiler evaluate:...

But why prefixing with Opal, it makes it impossible to discover, again !

Hum, I should have know how to do this simple thing really (and I did
know but forget), but for me it illustrates how complex Pharo is
becoming, and so more and more unpleasant to code with sometime. But I
am clear I have no hope it will ever change though.

Hilaire

Le 11/04/2020 à 11:37, Hilaire a écrit :
>
> How to write the code to execute a piece of code in code presenter?

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

That’s circumstances but I found that just yesterday so as to store scripts:

"info1 - webservice"
covidScript := 'ZnClient new
  "contentReader: [ :entity | NeoJSONReader fromString: entity contents ];"
        forJsonREST;
  get: ''https://www.data.gouv.fr/fr/datasets/r/58aee810-ddd2-4359-85eb-5cfd899cd1ce''.'.

covidFRUntilToday := OpalCompiler new
                source: covidScript;
                logged: false;
                evaluate.

 (I looked for #evaluate)

Hth,

Cédrick

Ps: btw I wonder how log can go now :)
               

Hmmm ...

Shift-Return (Spotter) type 'Compiler', first hit is AbstractCompiler which has a nice public API, it has only one concrete subclass that is being used: OpalCompiler

Same for evaluate:

Once you know it is obvious :)

Nevertheless, It took me about one hour to discover it, and only with
Squeak I can discover it.

My observations regarding the complexity of Pharo remain valid, though.


Le 11/04/2020 à 13:05, Sven Van Caekenberghe a écrit :
> Hmmm ...
>
> Shift-Return (Spotter) type 'Compiler', first hit is AbstractCompiler which has a nice public API, it has only one concrete subclass that is being used: OpalCompiler
>
> Same for evaluate:

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

I have to disagree a bit ;-)

Sometimes things are hard to find. Not everything can be easy. It also depends on what you already know, what your field of expertise is, what your experiences are.

What I meant is: doing a couple of searches for class or selector names is always the first step.

I guess you are more a UI person and started by disassembling something. *That* is harder.

Ah ah, so true.

Our brain is biased by the context. I was looking for an identical
behavior to playground, so my context was "how does playground implement
do-it?", so let's take a look. Then I hit a wall of abstractions and
duplication, unseen in Squeak, in that specific context.

I am pretty sure if I was looking at executing code, in another context,
for example some code fetched from a file, I will have search for
keyword as your described it.

That's why, often, when your brain hit a wall and is stuck, you need to
take a night break to escape the context you were stuck on.

Nevertheless, my point regarding the walls of complexity in Pharo
remains true.

Le 11/04/2020 à 16:02, Sven Van Caekenberghe a écrit :
> Sometimes things are hard to find. Not everything can be easy. It also depends on what you already know, what your field of expertise is, what your experiences are.
>
> What I meant is: doing a couple of searches for class or selector names is always the first step.
>
> I guess you are more a UI person and started by disassembling something.*That*  is harder.

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

I ran into a similar situation a short while back.  I was introducing someone
to Pharo, and suggested they run through ProfStef.  I was familiar with the
reaction of others to the "Print it" behavior, which evaluates and inserts
the resulting string into the window: It tends to confuse new learners,
because inserting the results creates a syntax error with the following
statements in the ProfStef window.  (This is not a bad thing, per se, as
there are instances where this behavior is useful -- just not in the context
of ProfStef.)

But I am also well aware that the behavior in the Playground window is
different: a "Print it" does *not* insert the result into the window; it
displays it in a morph, which disappears when you click elsewhere.  So I was
curious...  Exactly where does this occur, and why is it different for the
two windows?  And could ProfStef be modified to act more like the
Playground?

Investigating this was very educational...  I was able to track down the
class, method, and code that each was using -- they're quite different!
Totally different class hierarchies.. enough so that modifying ProfStef is
probably a significant undertaking.  (Which made me reflect on the job done
to make the Playground from GT library objects.  It seems like it must have
been a full rewrite of Workspace.)

I also tried to understand how Pharo Launcher works -- to get an
understanding of how to make a standalone double-clickable application using
Pharo.  It's also very complex internally!  (I'm awed by the skill &
knowledge of those who wrote it & maintain it.  How long until I could do
something similar??)

Pharo *is* a wall of complexity, internally.  I suppose that calls for good
documentation at the outer layers, to minimize the need to browse deeply in
the foundational classes.  I understand why it isn't there yet, and I've
donated some of my free time to helping write/improve documentation for
Pharo (and plan to continue doing so).

Even though parts of Pharo are complex, it's still intriguing as a
development environment.  I tell myself that these more complex parts are
like "being able to look into the guts of a C/C++ compiler while writing an
application in those languages" -- it would likely be just as daunting.  But
you can't (easily, anyway); you can only use the "surface parts" and the
rest "is black magic".  Pharo is cool because you can open it up and peel
back layer after layer to "see how it does it" -- and even modify how it
does it.  There's nothing like that!  So, of course there will be many parts
that "make my brain hurt".  I like it anyway...



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html