[Pharo-users] [OT] Reminder about quoting/top-posting

[Esteban A. Maringolo]

Hi,

Please apologize the digression, but these days there were a lot of
interesting threads with LOTS of replies from different members.

Can I ask for more trimming of the quoted text and/or emails replied to?

The follow up of some replies was hard because they were nested deep
into a chain of previous quotes, or in the case of top-posters, they
keep the replied emails accumulating in the bottom, causing a scroll
down to find nothing else was there.

Thanks!


-- 
Esteban A. Maringolo



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] Where do we go now ?

[Richard Sargent]

On Fri, Apr 13, 2018 at 1:11 PM, Hilaire  wrote:

> Sometime Pharo frustrate me a lot, I felt it too in the message from
> Benoit, in the other hand its community is very kind and always helpful. So
> it is not about blaming people.
>
> In my opinion, there are too much things pushed at the same time in Pharo.
> You can't push too much things into the box, then when people complain
> about it to be overfull and bugged request them to fix it, I don't think it
> can work that way, at this scale of changes. In the other, this is not
> really what happen here, I very likely exaggerate this trait but you get
> the idea.
>
> For example, I developed DrGeo for several years on P3. Why sticking to
> P3? It gave me the opportunity to fine craft DrGeo to be stable and
> predictable in the way it behaves to its end users, and a lot of releases
> occurred. When I started to look at porting to newer image last June, I
> realized  DrGeo will become unstable and oversized, so can of turning from
> A+ grade to a D- grade, just by the magic of porting it. My plan was to
> port it during the summer to get it ready end of August to deploy in local
> schools, it does not happen. And I can write it: it is s-u-p-e-r
> f-r-u-s-t-r-a-t-i-n-g. Is it normal when porting code? I don't know, I am a
> casual developer, but it makes developing well crafted and reliable Pharo
> application a bit expensive to my taste. To such a scale that I started to
> evaluate alternative to Pharo as the underneath system, idea I finally gave
> up after several weeks of evaluations. All in all I still have this felling
> Pharo is not developer friendly, I fell DrGeo is not secure there. See when
> porting to newer image, I end up using P7-32bits alpha on Linux because it
> was the most comfortable situation comparing to P5/P6/P6.1, is it not
> strange?
>
> In the other hand this struggle occurs at image change. Ok, may be it is a
> pattern specific to Smalltalk. Is it the case with commercial Smalltalk
> vendors?


Hi Hilaire,

Thanks for articulating this. I've been mostly watching Pharo rather than
using it, so I haven't been affected by the changes between versions. With
respect to commercial products versus Pharo *at the present time*, I think
we have different driving forces shaping things.

In my opinion, VA Smalltalk has been the one most strongly driven by the
importance of backward compatibility and ease of migration to a new
version. VisualWorks has been pretty good about providing a path forward
with minimal pain, although the more major version numbers difference, the
harder it is to transition. Likewise, GemStone/S has a strong emphasis on
keeping our customers' existing applications running with minimal changes.

That being said, I have no doubt that the earliest versions of all these
products had substantial incompatibilities between versions. I am also
pretty sure there is a threshold beyond which the adoption of Pharo in
business applications will compel Pharo development to facilitate migration
to newer versions and to better maintain API compatibility. [And that may
be simply because, as more businesses rely on Pharo, they will be
financially supporting its development.]


A second consideration is the size of the product teams (measured in
full-time staffing). I think the commercial products had a much larger
staffing in their early days than Pharo has even now. And I think the
consequence of that is that the changes between v1 and v2 or between v2 and
v3 of the commercial products *may* have been comparable to the differences
between Pharo v(n) and v(n+3).


Richard


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

Re: [Pharo-users] Where do we go now ?

[Stephane Ducasse]

We know where we go (we have a roadmap) and this is always the same
and we are getting there. Tell me one smalltalk that is bootstrapped.
And only bad OOP programmers count number of classes
Now I will not reply to provocation. So I just trashed this thread
because it goes nowhere.
Sorry constructivism criticisms from people that already commited and
helped is something positive.
But in this thread I only read in inverse and I will let you with it
and keep my good energy for it .

Stef

On Fri, Apr 13, 2018 at 7:53 AM, Benoit St-Jean via Pharo-users
 wrote:
>
>
> -- Forwarded message --
> From: Benoit St-Jean 
> To: pharo-users@lists.pharo.org
> Cc:
> Bcc:
> Date: Fri, 13 Apr 2018 05:53:46 + (UTC)
> Subject: Where do we go now ?
> Hello guys,
>
> Just a quick word to get some things straight because, quite frankly, I 
> really don't know where we're heading.
>
> When Pharo started, the goal was to depart from Squeak and do a *major clean 
> up* of all the code, especially Morphic.  The promise of a new, clean & lean 
> Smalltalk attracted a lot of people.  And then...
>
> I'm looking at the Pharo 7.0 image right now and I just don't get where we're 
> heading.  Every Pharo release gets bigger, and bigger, and bigger.  I don't 
> mind the environment getting bigger if it adds functionalities or new tools 
> but that's not quite the case here. LOTS of stuff is just duplicated.
>
> Do we really need 2 code completion classes (NECController, NOCController) ?  
> Do we really need 2 system browsers (Nautilus, Calypso)? Do we really need 2 
> compilers (OpalCompiler, Compiler) ?  Do we really need 8 delay schedulers 
> (DelayMicrosecondScheduler, DelayMillisecondScheduler, DelayNullScheduler, 
> DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, 
> DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ?  
> Do we really need 2 inspectors (GTInspector, EyeInspector) ?  Do we really 
> need 2 workspaces (GTPlayground, Workspace) ? Et cetera. Et cetera. Et 
> cetera.  I could go on, and on, and on...
>
> Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has 
> 7612 classes.  Can you see a trend?
>
> Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference settings. 
> Pharo 7.0 alpha has 662 preference settings.  Can you see a trend?
>
> Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0 
> alpha has a 47.97 MB image.  Can you see a trend?
>
> Add to that the fact that Pharo is a nightmare when you want to port code.  
> Just with the 7.0 release, 61 classes will be deprecated (and lots more to 
> come if you search for the string "deprecated" into the code, most of the 
> time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess 
> classes).
>
> You have code that deals with sockets, should you use the old Socket classes 
> or convert everything to Zodiac? And why do we keep both "frameworks" in the 
> image ?  Pharo hasn't been backward compatible with "old socket classes" a 
> looong time ago anyway!
>
> You have code that deals with dependencies, should you use the old dependents 
> mechanism or convert everything to announcements?
>
> UI speaking, what framework should anyone use ?  Athens?  Something else?
>
> You have code that deals with streams, should you use the old stream classes 
> or convert everything to Zinc ? And why do we keep both "frameworks" in the 
> image ?  Pharo hasn't been backward compatible with the old stream classes a 
> looong time ago anyway!
>
> So what's the plan?  For instance, should I keep using the Nautilus Browser 
> or I should switch to the Calypso browser and get used to it because Nautilus 
> will be deprecated?  Or should I just don't care because a third system 
> browser will be added in Pharo 8 just because "it's cool, let's add this one 
> too!" ?
>
> Couldn't we just decide on what's "official" and what's a goodie or an 
> external optional tool/package/framework the same way all other Smalltalks 
> do?  If you say Calypso is the official & supported browser, fine!  Then just 
> get Nautilus out of the image, create a nice loadable package for it and if 
> someone prefers Nautilus, they'll just have to load it into the image, the 
> same way VW has a gazillion optional tools/packages/frameworks you can load 
> from a parcel!
>
> Whenever I get asked a simple question by a newbie like "Oh, which system 
> browser should I use?", quite frankly, I don't know what to answer.  Did we 
> include Calypso to deprecate Nautilus later?  Is Calypso just a proof of 
> concept?  Is it just an optional tool?  What about all those delay schedulers?
>
> "I loaded this code from SqueakSource and it just doesn't work".  Should I 
> help the guy to fix it or just tell him to convert all the code to the 
> corresponding framework in Pharo?
>
> Perhaps a little bit of clarity and details 

Re: [Pharo-users] Where do we go now ?

[Hilaire]

Sometime Pharo frustrate me a lot, I felt it too in the message from 
Benoit, in the other hand its community is very kind and always helpful. 
So it is not about blaming people.


In my opinion, there are too much things pushed at the same time in 
Pharo. You can't push too much things into the box, then when people 
complain about it to be overfull and bugged request them to fix it, I 
don't think it can work that way, at this scale of changes. In the 
other, this is not really what happen here, I very likely exaggerate 
this trait but you get the idea.


For example, I developed DrGeo for several years on P3. Why sticking to 
P3? It gave me the opportunity to fine craft DrGeo to be stable and 
predictable in the way it behaves to its end users, and a lot of 
releases occurred. When I started to look at porting to newer image last 
June, I realized  DrGeo will become unstable and oversized, so can of 
turning from A+ grade to a D- grade, just by the magic of porting it. My 
plan was to port it during the summer to get it ready end of August to 
deploy in local schools, it does not happen. And I can write it: it is 
s-u-p-e-r  f-r-u-s-t-r-a-t-i-n-g. Is it normal when porting code? I 
don't know, I am a casual developer, but it makes developing well 
crafted and reliable Pharo application a bit expensive to my taste. To 
such a scale that I started to evaluate alternative to Pharo as the 
underneath system, idea I finally gave up after several weeks of 
evaluations. All in all I still have this felling Pharo is not developer 
friendly, I fell DrGeo is not secure there. See when porting to newer 
image, I end up using P7-32bits alpha on Linux because it was the most 
comfortable situation comparing to P5/P6/P6.1, is it not strange?


In the other hand this struggle occurs at image change. Ok, may be it is 
a pattern specific to Smalltalk. Is it the case with commercial 
Smalltalk vendors?


Hilaire

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

Re: [Pharo-users] [Pharo-dev] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 4:26 PM, Ben Coman  wrote:

>
>
> On 13 April 2018 at 21:14, Marcus Denker  wrote:
>
>>
>>
>> On 13 Apr 2018, at 15:04, Andrei Stebakov  wrote:
>>
>> Can you make the video available online?
>>
>>
>> https://youtu.be/A9H8jsSnBKM
>>
>
> I like the new "New Repo", particularly additional of GitHub alternative
> (not that I use them, but options is good)
> Could you consider adding here a "Pharo Dev Repo" or "Contribute to Pharo"
> entry or similar
> which presets *everything* required to clone the Pharo repo.
>

The thing is that the best way to do it is to clone your own fork... And
each one has her/his one.


>
> Later, here you might even go as far as letting uses entry an Issue and
> pre-create the branch
> that a fix will be submitted on.  But for now... one step at a time.
>

That's already there


>
> cheers -ben
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Where do we go now ?

[Herbert Vojčík]

Herbert Vojčík wrote:

Just a bit of a bikeshedding here:


But I prefer these names:
* Calypso System Browser


Calypso Browser Display


* Calypso Debugger


Calypso Debugger Display
Calypso Debugger Gear


* Iceberg Source Control Management\


Iceberg SCM Display
Iceberg SCM Gear


* Zinc HTTP Client


Zinc Web Client Gear


* Zinc HTTP Server


Zinc Web Server Gear


* Fuel Serialization


Fuel Serialization Gear


* Glamorous Spotter [*]


Spotter Search Display
Spotter Search Gear


* etc.

[*] I particularly dislike "Glamorous" adjective.

In the case of wrapper for libraries I'm hesitant to decide whether to
indicate pharo name in it or not.
I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of
calling "Salty".


NaCl Adapter
Maybe "Salty NaCl Adapter" here, to be consistent with the previous ones 
of "Fancy Merit Type".

Re: [Pharo-users] Where do we go now ?

[Herbert Vojčík]

Esteban A. Maringolo wrote:

On 13/04/2018 10:41, p...@highoctane.be wrote:

A somewhat unique name makes it easier to google for it (like Roassal
Pharo, or DeepTraverser Pharo, or Zinc Pharo).
These will give us hits that are relevant.

Try System Browser, Inspector...


Just a bit of a bikeshedding here:


But I prefer these names:
* Calypso System Browser


Calypso Browser Display


* Calypso Debugger


Calypso Debugger Display
Calypso Debugger Gear


* Iceberg Source Control Management\


Iceberg SCM Display
Iceberg SCM Gear


* Zinc HTTP Client


Zinc Web Client Gear


* Zinc HTTP Server


Zinc Web Server Gear


* Fuel Serialization


Fuel Serialization Gear


* Glamorous Spotter [*]


Spotter Search Display
Spotter Search Gear


* etc.

[*] I particularly dislike "Glamorous" adjective.

In the case of wrapper for libraries I'm hesitant to decide whether to
indicate pharo name in it or not.
I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of
calling "Salty".


NaCl Adapter

Ending with "... Display", "... Gear" and "... Adapter" high-level 
categorization. Question, is separation of UI and underlying machinery 
always possible.



Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too
bland), or SystemBrowserGear (why not), SystemBrowserRig (this one
sounds cool actually)).


Fortunately in the past the lack of namespaces caused the use of
prefixes instead of suffixes.

With time prefixes become invisible.

A suffix, instead, will get into all your names, bothering with other
existing suffixes like `Component`, `Model`, `Collection`, and so on.

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Ben Coman]

On 13 April 2018 at 21:14, Marcus Denker  wrote:

>
>
> On 13 Apr 2018, at 15:04, Andrei Stebakov  wrote:
>
> Can you make the video available online?
>
>
> https://youtu.be/A9H8jsSnBKM
>

I like the new "New Repo", particularly additional of GitHub alternative
(not that I use them, but options is good)
Could you consider adding here a "Pharo Dev Repo" or "Contribute to Pharo"
entry or similar
which presets *everything* required to clone the Pharo repo.

Later, here you might even go as far as letting uses entry an Issue and
pre-create the branch
that a fix will be submitted on.  But for now... one step at a time.

cheers -ben

Re: [Pharo-users] Where do we go now ?

[Esteban A. Maringolo]

On 13/04/2018 11:12, Sean P. DeNigris wrote:
> EstebanLM wrote
>> I dream with even more classes: Selector, Protocol (we already have it,
>> but we need to use it), etc., etc., etc.
>> I will always prefer a class that defines a concept than a non-reified
>> usage of generic classes.

"Objects all the way down".

Most problems surge from the lack of proper abstractions.

-- 
Esteban A. Maringolo

Re: [Pharo-users] Where do we go now ?

[Sean P. DeNigris]

EstebanLM wrote
> I dream with even more classes: Selector, Protocol (we already have it,
> but we need to use it), etc., etc., etc.
> I will always prefer a class that defines a concept than a non-reified
> usage of generic classes.

Yes!!!



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

Re: [Pharo-users] Where do we go now ?

[Esteban A. Maringolo]

On 13/04/2018 10:41, p...@highoctane.be wrote:
> A somewhat unique name makes it easier to google for it (like Roassal
> Pharo, or DeepTraverser Pharo, or Zinc Pharo). 
> These will give us hits that are relevant.
> 
> Try System Browser, Inspector...
> 
> And Apple has worked with NSObject and stuff like that without too much
> trouble (at a much larger scale for whatever XyzKit they released).
> Ah, yes, they used the "Kit" suffix. Maybe can we have something like
> that with Pharo. Like SystemBrowserKit ( nah, too Appleish.


But I prefer these names:
* Calypso System Browser
* Calypso Debugger
* Iceberg Source Control Management
* Zinc HTTP Client
* Zinc HTTP Server
* Fuel Serialization
* Glamorous Spotter [*]
* etc.

[*] I particularly dislike "Glamorous" adjective.

In the case of wrapper for libraries I'm hesitant to decide whether to
indicate pharo name in it or not.
I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of
calling "Salty".


> Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too
> bland), or SystemBrowserGear (why not), SystemBrowserRig (this one
> sounds cool actually)).

Fortunately in the past the lack of namespaces caused the use of
prefixes instead of suffixes.

With time prefixes become invisible.

A suffix, instead, will get into all your names, bothering with other
existing suffixes like `Component`, `Model`, `Collection`, and so on.







-- 
Esteban A. Maringolo

Re: [Pharo-users] Where do we go now ?

[Sean P. DeNigris]

EstebanLM wrote
> I would like to be able to add “tags" to tools, to be able to say: 
> Calypso -> a class browser -> some more info

Yes! That is what I was trying to get at in the other thread [1], but not
explaining very well. The thing is that this should be *the default view* of
the system for new users.

The left browser pane could have at least three views of the system:
- Packages
  - What we have now
  - Least generally important (really only matters for modularity when
you're adding code)
- Projects
  - What's been proposed because many packages could be collected under one
project node
  - Better than the above, but still falls prey to the problems being
mentioned (i.e. WTH is a Seashell/Coral/SandCastle/FishingPole - what are
they *for*)
- Purpose/Category/Tag
  - This was the function of the original System categories and what I think
Esteban is proposing. Of course in the browser and other tools the arrows
would flow differently: 'Browser' -> #(Calypso Nautilus) -> some more info

1.
http://forum.world.st/Why-can-t-we-use-in-protocol-for-package-extension-tp5073597p5073663.html



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

Re: [Pharo-users] Where do we go now ?

[p...@highoctane.be]

A somewhat unique name makes it easier to google for it (like Roassal
Pharo, or DeepTraverser Pharo, or Zinc Pharo).
These will give us hits that are relevant.

Try System Browser, Inspector...

And Apple has worked with NSObject and stuff like that without too much
trouble (at a much larger scale for whatever XyzKit they released).
Ah, yes, they used the "Kit" suffix. Maybe can we have something like that
with Pharo. Like SystemBrowserKit ( nah, too Appleish.

Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too bland),
or SystemBrowserGear (why not), SystemBrowserRig (this one sounds cool
actually)).

Now, I am back to liking the current naming.

Phil

On Fri, Apr 13, 2018 at 2:43 PM, Andrew Glynn  wrote:

> How many subsystems that do pretty much the same thing exist in Java?  Or
> Programmable Hyperlinked Pasta?
>
> Try this:  do a set of Moose queries on a largish Pharo subsystem, say
> GLORP, then do the same on EclipseLink, Toplink or Hibernate, either with
> or without the JPA interfaces.
>
> Even with the tools in Moose the Java frameworks make little to no sense
> compared to GLORP.  Neither do the names mean much other than Hibernate,
> which itself could be taken n different ways.
>
> And JavaScript, well, what can you say about a language with prototypes
> but no types to proto?
>
> Most enterprise software is proof positive the Pastafarians are right -
> I've seen plenty of flying spaghetti monsters.
>
> Andrew
>
> On Sat, 2018-04-14 at 00:31 +1200, Richard O'Keefe wrote:
>
> I was not talking about additional subsystems *for* Pharo,
> but subsystems already *in* Pharo.  For example, when I
> hover the mouse over "Epicea" in the leftmost browser
> panel, there is a pop-up that explains what is otherwise
> a rather opaque word.  But when I hover the mouse over
> "Fuel", nothing happens.  "Grease" => pop-up, "Growl", no.
> Actually there are three possibilities.  The third is that
> there's no pop-up but if you click, there is a package
> comment.
>
>
> On 14 April 2018 at 00:18, Peter Uhnák  wrote:
>
> On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe  wrote:
>
> There are a lot of subsystems in Pharo, and being a bear of
> very little brain, I have a hard time relating Zinc, Calypso,
>   to, well, whatever they are.  I presume there is
> somewhere a list of topic/name/PFX triples for guidance.
> Can some kind soul tell me where it is?
>
>
> Until we have mature package manager (similar to Cargo or npm), you have
> to use google.
> On the bright side, with the move to git(hub), people are much more likely
> to actually describe what their project does, and maybe even a bit of
> documentation. This was almost non-existent with SmalltalkHub.
>
> Peter
>
>
>

Re: [Pharo-users] Where do we go now ?

[p...@highoctane.be]

I am not complaining about these exchanges, which were interesting indeed.

Just that P7 is still in flux and not something I can use in some way for
my projects.

No problem with that, just that I cannot afford using it in projects for
clients, it is too much of a risk. So, I am not testing it as much as I'd
like.
I have found that the real issues show up with cases I face in such
projects.

Phil

On Fri, Apr 13, 2018 at 11:39 AM, Alistair Grant 
wrote:

> On 13 April 2018 at 11:04, Sven Van Caekenberghe  wrote:
> >
> >
> >> On 13 Apr 2018, at 08:43, p...@highoctane.be wrote:
> >>
> >> I consider Pharo 7 as a great piece of kit but unusable for my current
> work. There are many new things to learn in there. When is too much too
> much? Also, simplifications are breaking things in unexpected ways (like
> the #atEnd thing).
> >
> > Phil,
> >
> > Nothing fundamental will break with #atEnd.
> >
> > What you are reading in pharo-dev is a constructive discussion that (for
> me at least) started with the desire to support one very special kind of
> stream (stdin in C terms), something 99.99% of Pharo users have never seen,
> used or heard of.
>
>
> Completely agree (despite one of my later messages to Sven being
> overly grumpy).  I've learnt a lot from this exchange.
>
> Cheers,
> Alistair
>
>
> > Zn streams have worked well and as expected for Pharo versions going
> back to 3, that won't change.
>
>
>

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Marcus Denker]

> On 13 Apr 2018, at 15:04, Andrei Stebakov  wrote:
> 
> Can you make the video available online?

https://youtu.be/A9H8jsSnBKM

> Another question, is there a tutorial on Iceberg?

For the updated UI not yet. From the “how do I commit a PR to Pharo” 
perspective, I will do next week:
-> an update to the description on the website how to commit to PR
-> Do a short video of how to do contribute to Paro7 (as a replacement 
of the video tutorial I did).


Marcus
> 
> On Thu, Apr 12, 2018, 03:10 Marcus Denker  > wrote:
> This is today 
> 
> 5:00 PM - 7:00 PM (UTC+02:00)
> 
> There is a calendar entry to download at: 
> https://association.pharo.org/event-2797068 
> 
> 
> > On 10 Apr 2018, at 16:34, Marcus Denker  > > wrote:
> > 
> > Hi,
> > 
> > There next TechTalk will be April 12: GIT with Iceberg
> > 
> >   https://association.pharo.org/event-2797068 
> > 
> > 
> > 
> > A regular chat about Pharo. Happens on Discord.
> > 
> > The Tech talks are open to both members and non-members! 
> > 
> > Topic:  GIT with Iceberg. Demo of improved UI
> > 
> > We will send an information to all subscribers some hours before the talk 
> > starts.
> > 
> > 
> 
> 

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Sean P. DeNigris]

Andrei Stebakov wrote
> Can you make the video available online?

https://www.youtube.com/watch?v=A9H8jsSnBKM



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

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Andrei Stebakov]

Can you make the video available online? Another question, is there a
tutorial on Iceberg?

On Thu, Apr 12, 2018, 03:10 Marcus Denker  wrote:

> This is today
>
> 5:00 PM - 7:00 PM (UTC+02:00)
>
> There is a calendar entry to download at:
> https://association.pharo.org/event-2797068
>
> > On 10 Apr 2018, at 16:34, Marcus Denker  wrote:
> >
> > Hi,
> >
> > There next TechTalk will be April 12: GIT with Iceberg
> >
> >   https://association.pharo.org/event-2797068
> >
> >
> > A regular chat about Pharo. Happens on Discord.
> >
> > The Tech talks are open to both members and non-members!
> >
> > Topic:  GIT with Iceberg. Demo of improved UI
> >
> > We will send an information to all subscribers some hours before the
> talk starts.
> >
> >
>
>
>

Re: [Pharo-users] Where do we go now ?

[Esteban Lorenzano]

> On 13 Apr 2018, at 14:47, Esteban A. Maringolo  wrote:
> 
> 
> 
> On 13/04/2018 09:39, Esteban Lorenzano wrote:
>> 
>> 
>>> On 13 Apr 2018, at 14:33, Andrew Glynn >> > wrote:
>>> 
>>> I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse
>>> (wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names
>>> relate to what they do?  
>> 
>> yes… but we actually have a problem there.
>> I would like to be able to add “tags" to tools, to be able to say: 
>> 
>> Calypso -> a class browser -> some more info
>> etc.
> 
> 
> But isn't that what the Catalog currently does?

I’m talking about what is *inside* the image.

Esteban

> 
> Of course the catalog is not for a "package" (as in npm, apt, yum, etc).
> 
> Regards,
> 
> --
> Esteban, the other one. :P
> 

Re: [Pharo-users] Where do we go now ?

[Esteban A. Maringolo]

On 13/04/2018 09:39, Esteban Lorenzano wrote:
> 
> 
>> On 13 Apr 2018, at 14:33, Andrew Glynn > > wrote:
>>
>> I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse
>> (wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names
>> relate to what they do?  
> 
> yes… but we actually have a problem there.
> I would like to be able to add “tags" to tools, to be able to say: 
> 
> Calypso -> a class browser -> some more info
> etc.


But isn't that what the Catalog currently does?

Of course the catalog is not for a "package" (as in npm, apt, yum, etc).

Regards,

--
Esteban, the other one. :P

Re: [Pharo-users] Where do we go now ?

[Andrew Glynn]

How many subsystems that do pretty much the same thing exist in Java?
 Or Programmable Hyperlinked Pasta?  
Try this:  do a set of Moose queries on a largish Pharo subsystem, say
GLORP, then do the same on EclipseLink, Toplink or Hibernate, either
with or without the JPA interfaces.  
Even with the tools in Moose the Java frameworks make little to no
sense compared to GLORP.  Neither do the names mean much other than
Hibernate, which itself could be taken n different ways.  
And JavaScript, well, what can you say about a language with prototypes
but no types to proto?
Most enterprise software is proof positive the Pastafarians are right -
I've seen plenty of flying spaghetti monsters.
AndrewOn Sat, 2018-04-14 at 00:31 +1200, Richard O'Keefe wrote:
> I was not talking about additional subsystems *for* Pharo,
> but subsystems already *in* Pharo.  For example, when I
> hover the mouse over "Epicea" in the leftmost browser
> panel, there is a pop-up that explains what is otherwise
> a rather opaque word.  But when I hover the mouse over
> "Fuel", nothing happens.  "Grease" => pop-up, "Growl", no.
> Actually there are three possibilities.  The third is that
> there's no pop-up but if you click, there is a package
> comment.
> 
> 
> On 14 April 2018 at 00:18, Peter Uhnák  wrote:
> > On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe 
> > wrote:
> > > There are a lot of subsystems in Pharo, and being a bear of
> > > very little brain, I have a hard time relating Zinc, Calypso,
> > >   to, well, whatever they are.  I presume there is
> > > somewhere a list of topic/name/PFX triples for guidance.
> > > Can some kind soul tell me where it is?
> > > 
> > Until we have mature package manager (similar to Cargo or npm), you
> > have to use google.
> > On the bright side, with the move to git(hub), people are much more
> > likely to actually describe what their project does, and maybe even
> > a bit of documentation. This was almost non-existent with
> > SmalltalkHub.
> > 
> > Peter
> > 

Re: [Pharo-users] Where do we go now ?

[Esteban Lorenzano]

> On 13 Apr 2018, at 14:33, Andrew Glynn  wrote:
> 
> I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does 
> abt or sst stand for?).  Grunt, Gulp, etc., how do the names relate to what 
> they do?  

yes… but we actually have a problem there.
I would like to be able to add “tags" to tools, to be able to say: 

Calypso -> a class browser -> some more info
etc.

Esteban

> 
> Electron is as obscure as Phobos (although a phobia with web pages turned 
> into desktop apps may be appropriate).
> 
> Andrew
> 
> On Fri, 2018-04-13 at 14:18 +0200, Peter Uhnák wrote:
>> On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe > > wrote:
>>> There are a lot of subsystems in Pharo, and being a bear of
>>> very little brain, I have a hard time relating Zinc, Calypso,
>>>   to, well, whatever they are.  I presume there is
>>> somewhere a list of topic/name/PFX triples for guidance.
>>> Can some kind soul tell me where it is?
>>> 
>> 
>> Until we have mature package manager (similar to Cargo or npm), you have to 
>> use google.
>> On the bright side, with the move to git(hub), people are much more likely 
>> to actually describe what their project does, and maybe even a bit of 
>> documentation. This was almost non-existent with SmalltalkHub.
>> 
>> Peter

Re: [Pharo-users] Where do we go now ?

[Andrew Glynn]

I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse
(wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names
relate to what they do?  
Electron is as obscure as Phobos (although a phobia with web pages
turned into desktop apps may be appropriate).
AndrewOn Fri, 2018-04-13 at 14:18 +0200, Peter Uhnák wrote:
> On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe 
> wrote:
> > There are a lot of subsystems in Pharo, and being a bear of
> > very little brain, I have a hard time relating Zinc, Calypso,
> >   to, well, whatever they are.  I presume there is
> > somewhere a list of topic/name/PFX triples for guidance.
> > Can some kind soul tell me where it is?
> > 
> Until we have mature package manager (similar to Cargo or npm), you
> have to use google.
> On the bright side, with the move to git(hub), people are much more
> likely to actually describe what their project does, and maybe even a
> bit of documentation. This was almost non-existent with SmalltalkHub.
> 
> Peter

[Pharo-users] [ANN] Pharo Sprint Apr 20

[Marcus Denker]

Pharo Sprint Apr 20

https://association.pharo.org/event-2789579

We will organize a Pharo sprint / Moose dojo Apr 20 , starting at
10:00am. (Local Time Paris).

Goals of this sprint:

• Pharo 7 issues

Remote Sprint
Remotely, you can join us on Discord. During the sprint, we synchronize 
local and remote Pharo sprinters:


Known Local Sprint meetings

Lille/France:
It will be at the Inria Lille, Building B, third floor (RMoD offices). 
As the building is not open to the public, please contact us before if you plan 
to come

Re: [Pharo-users] Where do we go now ?

[Esteban A. Maringolo]

On 13/04/2018 09:18, Peter Uhnák wrote:
> On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe  > wrote:
> 
> There are a lot of subsystems in Pharo, and being a bear of
> very little brain, I have a hard time relating Zinc, Calypso,
>   to, well, whatever they are.  I presume there is
> somewhere a list of topic/name/PFX triples for guidance.
> Can some kind soul tell me where it is?


> Until we have mature package manager (similar to Cargo or npm), you have
> to use google.

Yes, there needs to be a package tool that enables discoverability,
Catalog is not enough.

> On the bright side, with the move to git(hub), people are much more
> likely to actually describe what their project does, and maybe even a
> bit of documentation. This was almost non-existent with SmalltalkHub.

True, and it's also giving visibility to Pharo and Smalltalk as active
technologies.

Regards,

-- 
Esteban A. Maringolo

Re: [Pharo-users] Where do we go now ?

[Denis Kudriashov]

2018-04-13 13:01 GMT+02:00 Marcus Denker :

>
>
> > On 13 Apr 2018, at 12:40, Sven Van Caekenberghe  wrote:
> >
> >
> >
> >> On 13 Apr 2018, at 12:19, Joe Shirk  wrote:
> >>
> >> I've been a lurk-fan for a long time but this brings up something that
> distressed me. Richard Eng, Smalltalk Renaissance hero loves to say
> Smalltalk's grammar/syntax fits on a postcard.
> >>
> >> But the vocabulary doesn't. There is nothing English-like about the
> always expanding bewildering   library namespaces.
> >>
>
> The package names that just use the “project name” can be problematic… too
> many words. e.g. “Hiedra”? No idea. (there are ideas of how to improve, I
> will not list them here as this should
> not turn into discussion about this issue).
>
>
At some point we should force rule "All packages have comments". And
indication with icon like we do for classes.
With Calypso the package comment is always available. So it would be easy
to find description.

The way we present packages (and their granularity) is not “right”.
> Namespaces are a problem in addition…
>
> So yes: we have a lot of thing to improve!
> .
> >> GT what? Oh a newbie might eventually figure out it means Glamorous
> Toolkit. These are meaningless brands. In this drive to come up with
> creative names for "just objects" that explain nothing at all, Smalltalk is
> becoming like Java or PHP hell.
> >> Just look at those examples through the eyes of a novice. The purity is
> nowhere to be found.
> >> :(
> >
> > You are right, but in 'the real world' it is no longer possible to
> reserve the nice, simple names for just one variant. The prefixes are a
> poor mans namespace mechanism. You have to read over them.
> >
> > Inspector, EyeInspector, GTInspector, ...
> >
> > I rather have cool alternatives and the development of new ideas than
> 'one ring to rule them all' or no/slow progress. Remember that we develop
> in a live system, changing things while testing them, this is often hard.
> Alternative subsystems help a lot.
>
> It should be clear that what we have is what we managed to do, not what we
> dreamed about… I, too, would like to have this clean, nice, small, amazing
> system… but it is not always easy.
>
> There is a lot we can (and will!) improve!
>
> Marcus
>
>
>

Re: [Pharo-users] Where do we go now ?

[Esteban A. Maringolo]

On 13/04/2018 09:05, Richard O'Keefe wrote:
> There are a lot of subsystems in Pharo, and being a bear of
> very little brain, I have a hard time relating Zinc, Calypso,
>   to, well, whatever they are.  I presume there is
> somewhere a list of topic/name/PFX triples for guidance.
> Can some kind soul tell me where it is?

I think it's not a matter of brain, and unless I also have a bear brain
I find it hard to know what each thing means, in particular when there
is a "flagship" framework (like Seaside) and the related
extensions/libraries are called something different instead of, it is
harder when the names are completely unrelated to the domain.

I've been thinking of collecting the package names, what they do, an
which class prefixes they use. But never had the willingness to actually
do it, maybe now is a good moment.


Regards,

--
Esteban.

Re: [Pharo-users] Where do we go now ?

[Ben Coman]

Unfortunately there probably isn't one list.
Its hard to unlearn what is accumulated
and easy to take for granted what we know is obvious to everyone.
Maybe we need a "Glossary" at
https://github.com/pharo-project/pharo/tree/master/wiki
where newcomers can add items for others to fill in.

cheers -ben

On 13 April 2018 at 20:05, Richard O'Keefe  wrote:

> There are a lot of subsystems in Pharo, and being a bear of
> very little brain, I have a hard time relating Zinc, Calypso,
>   to, well, whatever they are.  I presume there is
> somewhere a list of topic/name/PFX triples for guidance.
> Can some kind soul tell me where it is?
>
>
> On 13 April 2018 at 23:01, Marcus Denker  wrote:
>
>>
>>
>> > On 13 Apr 2018, at 12:40, Sven Van Caekenberghe  wrote:
>> >
>> >
>> >
>> >> On 13 Apr 2018, at 12:19, Joe Shirk  wrote:
>> >>
>> >> I've been a lurk-fan for a long time but this brings up something that
>> distressed me. Richard Eng, Smalltalk Renaissance hero loves to say
>> Smalltalk's grammar/syntax fits on a postcard.
>> >>
>> >> But the vocabulary doesn't. There is nothing English-like about the
>> always expanding bewildering   library namespaces.
>> >>
>>
>> The package names that just use the “project name” can be problematic…
>> too many words. e.g. “Hiedra”? No idea. (there are ideas of how to improve,
>> I will not list them here as this should
>> not turn into discussion about this issue).
>>
>> The way we present packages (and their granularity) is not “right”.
>> Namespaces are a problem in addition…
>>
>> So yes: we have a lot of thing to improve!
>> .
>> >> GT what? Oh a newbie might eventually figure out it means Glamorous
>> Toolkit. These are meaningless brands. In this drive to come up with
>> creative names for "just objects" that explain nothing at all, Smalltalk is
>> becoming like Java or PHP hell.
>> >> Just look at those examples through the eyes of a novice. The purity
>> is nowhere to be found.
>> >> :(
>> >
>> > You are right, but in 'the real world' it is no longer possible to
>> reserve the nice, simple names for just one variant. The prefixes are a
>> poor mans namespace mechanism. You have to read over them.
>> >
>> > Inspector, EyeInspector, GTInspector, ...
>> >
>> > I rather have cool alternatives and the development of new ideas than
>> 'one ring to rule them all' or no/slow progress. Remember that we develop
>> in a live system, changing things while testing them, this is often hard.
>> Alternative subsystems help a lot.
>>
>> It should be clear that what we have is what we managed to do, not what
>> we dreamed about… I, too, would like to have this clean, nice, small,
>> amazing system… but it is not always easy.
>>
>> There is a lot we can (and will!) improve!
>>
>> Marcus
>>
>>
>>
>

Re: [Pharo-users] Where do we go now ?

[Peter Uhnák]

On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe  wrote:

> There are a lot of subsystems in Pharo, and being a bear of
> very little brain, I have a hard time relating Zinc, Calypso,
>   to, well, whatever they are.  I presume there is
> somewhere a list of topic/name/PFX triples for guidance.
> Can some kind soul tell me where it is?
>

Until we have mature package manager (similar to Cargo or npm), you have to
use google.
On the bright side, with the move to git(hub), people are much more likely
to actually describe what their project does, and maybe even a bit of
documentation. This was almost non-existent with SmalltalkHub.

Peter

Re: [Pharo-users] Where do we go now ?

[Denis Kudriashov]

With new Traits we have some issues which we are slowly fixing. Nice thing
that fixes are quite simple and clean and covered by tests. I guess it was
not like that before.
So Pablo did very good job here.

For this concrete case with implementors there is already issue 21652
:
the method allClassesAndTraits includes traits twice.

2018-04-13 11:30 GMT+02:00 Marcus Denker :

>
>
> On 13 Apr 2018, at 11:26, Benoit St-Jean via Pharo-users <
> pharo-users@lists.pharo.org> wrote:
>
>
> *From: *Benoit St-Jean 
> *Subject: **Re: [Pharo-users] Where do we go now ?*
> *Date: *13 April 2018 at 11:26:09 CEST
> *To: *Esteban Lorenzano 
> *Cc: *Any question about pharo is welcome 
> *Reply-To: *Benoit St-Jean 
>
>
> BTW, why put an .exe installer for Windows available when it crashes right
> from the start? It just doesn't work at all.  Period.  For everyone.
>
> And I thought looking for senders of a method was something we mastered a
> long time ago, like starting with Smalltalk-76.  Am I supposed to assume
> that everything, even basic functionalities, are all broken because it's
> labeled "alpha” ?
>
>
> We have already a issue tracker entry with a description of a fix:
>
> https://pharo.fogbugz.com/f/cases/21518/New-Traits-brings-
> wrong-behaviour-to-tagsForMethods
>
> TODO: turn that description into code and make a Pull Request.
>
> Marcus
>
>

Re: [Pharo-users] Where do we go now ?

[Richard O'Keefe]

There are a lot of subsystems in Pharo, and being a bear of
very little brain, I have a hard time relating Zinc, Calypso,
  to, well, whatever they are.  I presume there is
somewhere a list of topic/name/PFX triples for guidance.
Can some kind soul tell me where it is?


On 13 April 2018 at 23:01, Marcus Denker  wrote:

>
>
> > On 13 Apr 2018, at 12:40, Sven Van Caekenberghe  wrote:
> >
> >
> >
> >> On 13 Apr 2018, at 12:19, Joe Shirk  wrote:
> >>
> >> I've been a lurk-fan for a long time but this brings up something that
> distressed me. Richard Eng, Smalltalk Renaissance hero loves to say
> Smalltalk's grammar/syntax fits on a postcard.
> >>
> >> But the vocabulary doesn't. There is nothing English-like about the
> always expanding bewildering   library namespaces.
> >>
>
> The package names that just use the “project name” can be problematic… too
> many words. e.g. “Hiedra”? No idea. (there are ideas of how to improve, I
> will not list them here as this should
> not turn into discussion about this issue).
>
> The way we present packages (and their granularity) is not “right”.
> Namespaces are a problem in addition…
>
> So yes: we have a lot of thing to improve!
> .
> >> GT what? Oh a newbie might eventually figure out it means Glamorous
> Toolkit. These are meaningless brands. In this drive to come up with
> creative names for "just objects" that explain nothing at all, Smalltalk is
> becoming like Java or PHP hell.
> >> Just look at those examples through the eyes of a novice. The purity is
> nowhere to be found.
> >> :(
> >
> > You are right, but in 'the real world' it is no longer possible to
> reserve the nice, simple names for just one variant. The prefixes are a
> poor mans namespace mechanism. You have to read over them.
> >
> > Inspector, EyeInspector, GTInspector, ...
> >
> > I rather have cool alternatives and the development of new ideas than
> 'one ring to rule them all' or no/slow progress. Remember that we develop
> in a live system, changing things while testing them, this is often hard.
> Alternative subsystems help a lot.
>
> It should be clear that what we have is what we managed to do, not what we
> dreamed about… I, too, would like to have this clean, nice, small, amazing
> system… but it is not always easy.
>
> There is a lot we can (and will!) improve!
>
> Marcus
>
>
>

Re: [Pharo-users] Progress bar for ZnClient>>#downloadTo:

[Cyril Ferlicot D.]

On 13/04/2018 13:50, Sven Van Caekenberghe wrote:
> 
> All good and well, I understand your point, but as a general rule, I don't 
> want to add UI code to Zn, it is too fundamental for minimal/kernel//headless 
> images.
> 
> 

Hi,

It could be useful to add this kind of methods via extensions in an UI
package not in the default group of Zinc configuration maybe?

And Pharo 7 could integrate the core of zinc in a low level layer during
the bootstrap and the UI stuff in the tooling layer.

-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-users] Progress bar for ZnClient>>#downloadTo:

[Sven Van Caekenberghe]

> On 12 Apr 2018, at 17:02, Ben Coman  wrote:
> 
> 
> 
> On 12 April 2018 at 18:15, Sven Van Caekenberghe  wrote:
> Ben,
> 
> You disappoint me, as I would expect you to trace senders/users of 
> #signalProgress: ;-)
> 
> :P 
> Yeah I knew I was being slack.  I couldn't really follow its operation and 
> was a bit tired.
> Actually maybe part of my confusion is that #signalProgress feels more like a 
> command than a status.
> I've a slight feeling it would be better as #signallingProgress.
> 
>  
> ZnClient only signals certain Notifications which a UI around it should deal 
> with.
> 
> For example,
> 
> [ :bar |
>   bar title: 'Downloading Sources...'.
>   [
> ZnClient new
>   url: 'http://files.pharo.org/sources/PharoV30.sources';
>   signalProgress: true;
>   downloadTo: FileLocator temp ]
> on: HTTPProgress
> do: [ :progress |
>   progress isEmpty ifFalse: [ bar current: progress percentage ].
>   progress resume ] ] asJob run.
> 
> Thanks, that worked, but its a bit convoluted for my goldfish memory to 
> remember each time.
> I'd expect having that as a convenience method would be useful to many.
> 
> ZnClient 
>   showProgress: 'Downloading sources...'
>   during: [ :znClient | 
>   znClient url: 'http://files.pharo.org/sources/PharoV30.sources'.
>   znClient downloadTo: FileLocator imageDirectory ]. 
> 
> ZnClient class >> showProgress: title during: clientBlock
>   |client|
>   client := ZnClient new.
>   client signallingProgress: true.
>   [ :bar |
>   bar title: title.
>   [clientBlock value: client]
>   on: HTTPProgress
>   do: [ :progress |
>   progress isEmpty ifFalse: [ bar current: 
> progress percentage ].
>   progress resume ] ] asJob run.
> 
> Easily discoverable as the only class-side method of ZnClient, 
> and this would also make a useful howto reference. 

All good and well, I understand your point, but as a general rule, I don't want 
to add UI code to Zn, it is too fundamental for minimal/kernel//headless images.

> But there are other UI approaches as well. 
> 
> Sven
> 
> Thanks for you prompt response.
> cheers -ben
>  
> 
> 
> > On 12 Apr 2018, at 11:25, Ben Coman  wrote:
> >
> > I see ZnClient >> downloadTo:
> > calls  ZnClient >> downloadEntityTo:
> > which uses #withProgressDo:
> > which indicates a progress bar might appear.
> >
> > But...
> > ZnClient new
> > url: ' 
> > https://download.libsodium.org/libsodium/releases/libsodium-1.0.16-msvc.zip'
> >  ;
> > downloadTo: FileLocator imageDirectory.
> > doesn't show a progress bar.  What is the recommended way to display one?
> >
> > cheers -ben

Re: [Pharo-users] Where do we go now ?

[Marcus Denker]

> On 13 Apr 2018, at 12:40, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 13 Apr 2018, at 12:19, Joe Shirk  wrote:
>> 
>> I've been a lurk-fan for a long time but this brings up something that 
>> distressed me. Richard Eng, Smalltalk Renaissance hero loves to say 
>> Smalltalk's grammar/syntax fits on a postcard.
>> 
>> But the vocabulary doesn't. There is nothing English-like about the always 
>> expanding bewildering   library namespaces. 
>> 

The package names that just use the “project name” can be problematic… too many 
words. e.g. “Hiedra”? No idea. (there are ideas of how to improve, I will not 
list them here as this should
not turn into discussion about this issue).

The way we present packages (and their granularity) is not “right”.  Namespaces 
are a problem in addition…

So yes: we have a lot of thing to improve!
.
>> GT what? Oh a newbie might eventually figure out it means Glamorous Toolkit. 
>> These are meaningless brands. In this drive to come up with creative names 
>> for "just objects" that explain nothing at all, Smalltalk is becoming like 
>> Java or PHP hell. 
>> Just look at those examples through the eyes of a novice. The purity is 
>> nowhere to be found.
>> :(
> 
> You are right, but in 'the real world' it is no longer possible to reserve 
> the nice, simple names for just one variant. The prefixes are a poor mans 
> namespace mechanism. You have to read over them.
> 
> Inspector, EyeInspector, GTInspector, ...
> 
> I rather have cool alternatives and the development of new ideas than 'one 
> ring to rule them all' or no/slow progress. Remember that we develop in a 
> live system, changing things while testing them, this is often hard. 
> Alternative subsystems help a lot. 

It should be clear that what we have is what we managed to do, not what we 
dreamed about… I, too, would like to have this clean, nice, small, amazing 
system… but it is not always easy.

There is a lot we can (and will!) improve!

Marcus

Re: [Pharo-users] Where do we go now ?

[aglynn42]

Btw, in my fascination with messing around, the 32 bit version of Pharo 7 for 
Windows runs better on OS/2 v.5 (yes, it still exists, it was released last 
June).  Probably because its Win32 subsystem is more compatible with Win32 apps 
than Windows 10.

 

Andrew

 

From: Benoit St-Jean  
Sent: Friday, April 13, 2018 5:26 AM
To: Esteban Lorenzano 
Cc: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Where do we go now ?

 

BTW, why put an .exe installer for Windows available when it crashes right from 
the start? It just doesn't work at all.  Period.  For everyone.

 

And I thought looking for senders of a method was something we mastered a long 
time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
everything, even basic functionalities, are all broken because it's labeled 
"alpha" ?

 

 

- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

 

 

On Friday, April 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano 
 > wrote: 

 

 

 





On 13 Apr 2018, at 11:07, Benoit St-Jean  > wrote:

 

I'm on Windows 10, using Pharo 7.0 alpha 32 bit.

 

 

and btw… which part of ALPHA you do not get?

 

Esteban

Re: [Pharo-users] Where do we go now ?

[aglynn42]

Maybe I’m missing something, or maybe I’m not ‘everyone’, but I’ve only had a 
few problems with 32 bit Pharo 7 and Windows.  Btw Windows 10 “64 bit” is about 
as 64 bit as Windows 95 was 32 bit.  i.e. not very.  Most of the issues center 
around Moose, not the core Pharo.  But I’m only playing with Pharo 7, mainly on 
Linux where the latest image seems pretty stable.  My actual development is 
still on 61 (and in one case, 5.0 since it requires the old FFI).

 

M$ is supposed to fix the remains of 32 bit Windows next year, but we all know 
what ‘next year’ means to Microsoft, it’s forever ‘next year’.

 

As far as I understood, most of the development of Pharo 7 is focused on the 64 
bit version in any case.  What’s missing from 61 that you absolutely have to 
have ATM?  

 

Andrew

 

 

 

From: Benoit St-Jean  
Sent: Friday, April 13, 2018 5:26 AM
To: Esteban Lorenzano 
Cc: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Where do we go now ?

 

BTW, why put an .exe installer for Windows available when it crashes right from 
the start? It just doesn't work at all.  Period.  For everyone.

 

And I thought looking for senders of a method was something we mastered a long 
time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
everything, even basic functionalities, are all broken because it's labeled 
"alpha" ?

 

 

- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

 

 

On Friday, April 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano 
 > wrote: 

 

 

 





On 13 Apr 2018, at 11:07, Benoit St-Jean  > wrote:

 

I'm on Windows 10, using Pharo 7.0 alpha 32 bit.

 

 

and btw… which part of ALPHA you do not get?

 

Esteban

Re: [Pharo-users] Where do we go now ?

[Sven Van Caekenberghe]

> On 13 Apr 2018, at 12:19, Joe Shirk  wrote:
> 
> I've been a lurk-fan for a long time but this brings up something that 
> distressed me. Richard Eng, Smalltalk Renaissance hero loves to say 
> Smalltalk's grammar/syntax fits on a postcard.
> 
> But the vocabulary doesn't. There is nothing English-like about the always 
> expanding bewildering   library namespaces. 
> 
> GT what? Oh a newbie might eventually figure out it means Glamorous Toolkit. 
> These are meaningless brands. In this drive to come up with creative names 
> for "just objects" that explain nothing at all, Smalltalk is becoming like 
> Java or PHP hell. 
> Just look at those examples through the eyes of a novice. The purity is 
> nowhere to be found.
> :(

You are right, but in 'the real world' it is no longer possible to reserve the 
nice, simple names for just one variant. The prefixes are a poor mans namespace 
mechanism. You have to read over them.

Inspector, EyeInspector, GTInspector, ...

I rather have cool alternatives and the development of new ideas than 'one ring 
to rule them all' or no/slow progress. Remember that we develop in a live 
system, changing things while testing them, this is often hard. Alternative 
subsystems help a lot. 

> On Apr 13, 2018 1:56 AM, "Benoit St-Jean via Pharo-users" 
>  wrote:
> 
> 
> -- Forwarded message --
> From: Benoit St-Jean 
> To: pharo-users@lists.pharo.org
> Cc: 
> Bcc: 
> Date: Fri, 13 Apr 2018 05:53:46 + (UTC)
> Subject: Where do we go now ?
> Hello guys,
> 
> Just a quick word to get some things straight because, quite frankly, I 
> really don't know where we're heading.
> 
> When Pharo started, the goal was to depart from Squeak and do a *major clean 
> up* of all the code, especially Morphic.  The promise of a new, clean & lean 
> Smalltalk attracted a lot of people.  And then...
> 
> I'm looking at the Pharo 7.0 image right now and I just don't get where we're 
> heading.  Every Pharo release gets bigger, and bigger, and bigger.  I don't 
> mind the environment getting bigger if it adds functionalities or new tools 
> but that's not quite the case here. LOTS of stuff is just duplicated.
> 
> Do we really need 2 code completion classes (NECController, NOCController) ?  
> Do we really need 2 system browsers (Nautilus, Calypso)? Do we really need 2 
> compilers (OpalCompiler, Compiler) ?  Do we really need 8 delay schedulers 
> (DelayMicrosecondScheduler, DelayMillisecondScheduler, DelayNullScheduler, 
> DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, 
> DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ?  
> Do we really need 2 inspectors (GTInspector, EyeInspector) ?  Do we really 
> need 2 workspaces (GTPlayground, Workspace) ? Et cetera. Et cetera. Et 
> cetera.  I could go on, and on, and on...
> 
> Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has 
> 7612 classes.  Can you see a trend?
> 
> Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference settings. 
> Pharo 7.0 alpha has 662 preference settings.  Can you see a trend?
> 
> Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0 
> alpha has a 47.97 MB image.  Can you see a trend?
> 
> Add to that the fact that Pharo is a nightmare when you want to port code.  
> Just with the 7.0 release, 61 classes will be deprecated (and lots more to 
> come if you search for the string "deprecated" into the code, most of the 
> time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess 
> classes).
> 
> You have code that deals with sockets, should you use the old Socket classes 
> or convert everything to Zodiac? And why do we keep both "frameworks" in the 
> image ?  Pharo hasn't been backward compatible with "old socket classes" a 
> looong time ago anyway!
> 
> You have code that deals with dependencies, should you use the old dependents 
> mechanism or convert everything to announcements?
> 
> UI speaking, what framework should anyone use ?  Athens?  Something else?
> 
> You have code that deals with streams, should you use the old stream classes 
> or convert everything to Zinc ? And why do we keep both "frameworks" in the 
> image ?  Pharo hasn't been backward compatible with the old stream classes a 
> looong time ago anyway! 
> 
> So what's the plan?  For instance, should I keep using the Nautilus Browser 
> or I should switch to the Calypso browser and get used to it because Nautilus 
> will be deprecated?  Or should I just don't care because a third system 
> browser will be added in Pharo 8 just because "it's cool, let's add this one 
> too!" ?
> 
> Couldn't we just decide on what's "official" and what's a goodie or an 
> external optional tool/package/framework the same way all other Smalltalks 
> do?  If you say Calypso is the official & supported browser, fine!  Then just 
> get Nautilus out of the 

Re: [Pharo-users] Where do we go now ?

[Joe Shirk]

I've been a lurk-fan for a long time but this brings up something that
distressed me. Richard Eng, Smalltalk Renaissance hero loves to say
Smalltalk's grammar/syntax fits on a postcard.

But the vocabulary doesn't. There is nothing English-like about the always
expanding bewildering   library namespaces.

GT what? Oh a newbie might eventually figure out it means Glamorous
Toolkit. These are meaningless brands. In this drive to come up with
creative names for "just objects" that explain nothing at all, Smalltalk is
becoming like Java or PHP hell.
Just look at those examples through the eyes of a novice. The purity is
nowhere to be found.
:(

On Apr 13, 2018 1:56 AM, "Benoit St-Jean via Pharo-users" <
pharo-users@lists.pharo.org> wrote:



-- Forwarded message --
From: Benoit St-Jean 
To: pharo-users@lists.pharo.org
Cc:
Bcc:
Date: Fri, 13 Apr 2018 05:53:46 + (UTC)
Subject: Where do we go now ?
Hello guys,

Just a quick word to get some things straight because, quite frankly, I
really don't know where we're heading.

When Pharo started, the goal was to depart from Squeak and do a *major
clean up* of all the code, especially Morphic.  The promise of a new, clean
& lean Smalltalk attracted a lot of people.  And then...

I'm looking at the Pharo 7.0 image right now and I just don't get where
we're heading.  Every Pharo release gets bigger, and bigger, and bigger.  I
don't mind the environment getting bigger if it adds functionalities or new
tools but that's not quite the case here. LOTS of stuff is just duplicated.

Do we really need 2 code completion classes (NECController, NOCController)
?  Do we really need 2 system browsers (Nautilus, Calypso)? Do we really
need 2 compilers (OpalCompiler, Compiler) ?  Do we really need 8 delay
schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler,
DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler,
DelayTicklessScheduler, DelayExperimentalCourageousScheduler,
DelayExperimentalSemaphoreScheduler) ?  Do we really need 2 inspectors
(GTInspector, EyeInspector) ?  Do we really need 2 workspaces
(GTPlayground, Workspace) ? Et cetera. Et cetera. Et cetera.  I could go
on, and on, and on...

Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has
7612 classes.  Can you see a trend?

Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference
settings. Pharo 7.0 alpha has 662 preference settings.  Can you see a trend?

Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0
alpha has a 47.97 MB image.  Can you see a trend?

Add to that the fact that Pharo is a nightmare when you want to port code.
Just with the 7.0 release, 61 classes will be deprecated (and lots more to
come if you search for the string "deprecated" into the code, most of the
time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess
classes).

You have code that deals with sockets, should you use the old Socket
classes or convert everything to Zodiac? And why do we keep both
"frameworks" in the image ?  Pharo hasn't been backward compatible with
"old socket classes" a looong time ago anyway!

You have code that deals with dependencies, should you use the old
dependents mechanism or convert everything to announcements?

UI speaking, what framework should anyone use ?  Athens?  Something else?

You have code that deals with streams, should you use the old stream
classes or convert everything to Zinc ? And why do we keep both
"frameworks" in the image ?  Pharo hasn't been backward compatible with the
old stream classes a looong time ago anyway!

So what's the plan?  For instance, should I keep using the Nautilus Browser
or I should switch to the Calypso browser and get used to it because
Nautilus will be deprecated?  Or should I just don't care because a third
system browser will be added in Pharo 8 just because "it's cool, let's add
this one too!" ?

Couldn't we just decide on what's "official" and what's a goodie or an
external optional tool/package/framework the same way all other Smalltalks
do?  If you say Calypso is the official & supported browser, fine!  Then
just get Nautilus out of the image, create a nice loadable package for it
and if someone prefers Nautilus, they'll just have to load it into the
image, the same way VW has a gazillion optional tools/packages/frameworks
you can load from a parcel!

Whenever I get asked a simple question by a newbie like "Oh, which system
browser should I use?", quite frankly, I don't know what to answer.  Did we
include Calypso to deprecate Nautilus later?  Is Calypso just a proof of
concept?  Is it just an optional tool?  What about all those delay
schedulers?

"I loaded this code from SqueakSource and it just doesn't work".  Should I
help the guy to fix it or just tell him to convert all the code to the
corresponding framework in Pharo?

Perhaps a little bit of clarity and details about what's coming and what's
the plan would be 

Re: [Pharo-users] Where do we go now ?

[Ben Coman]

On 13 April 2018 at 17:07, Benoit St-Jean via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Benoit St-Jean 
> To: Any question about pharo is welcome ,
> Esteban Lorenzano 
> Cc:
> Bcc:
> Date: Fri, 13 Apr 2018 09:07:16 + (UTC)
> Subject: Re: [Pharo-users] Where do we go now ?
> "You cannot take an alpha version and expect production quality."
>
> I'm on Windows 10, using Pharo 7.0 alpha 32 bit.
>
>
> Can I at least expect to be able to save code in my local Monticello
> repository ? It bombs. I just reported a bug!
>
> Can I expect the Windows installer for Pharo Launcher to work on Windows?
> It doesn't : it crashes.
>

It works fine for me on Windows 10.
There were some issues that depended on how PharoLauncher was installed.

The installer (NSIS) being used at that time doesn't handle non-Admin
installs very well.
Prior to PharoLauncher being promoted as the main download, I guess people
on Windows
using PharoLauncher either ran it as Admin, or worked around it like me -
on Windows I
would just roll my own from a fresh Pharo 6 and the Project Catalog.

To be clear, the problem was heavily influenced by the constraints of an
external tool.
Get PharoLauncher installed in the right location and it works like a dream.
Did you try the proof-of-concept installer I posted previously to the
list...
http://www.mediafire.com/file/3g579bmzqspt8e1/BCPharoLauncher.msi



>
> Can I expect Pharo Launcher (not installed from the .exe installer) to
> work on Windows?  It just doesn't. I get all kinds of error related to
> WindowsStore, bad UTF-8 encoding and other things... (see
> https://twitter.com/smalltalkdev/status/978973863332798464)
>

Yes most people can expect it works perfectly on Windows.  But as always it
depends.
There is always the chance something in your environment triggers a bug.
like maybe non-ascii characters in you username/path?



>
> Can I expect that when looking for implementors of a method things still
> work?  I get duplicates (see attached file).
>

Do you mean only the duplicate "Traited class >> isTrait" in your
screenshot?
I just tried this in "Pharo-7.0+alpha.build.762.sha.0e0fe47c5ccef"
by typing "isTrait" into the Playground, selecting it and pressing Ctrl-M,
and I don't get the duplicate.

Which build of Pharo are you using?


>
> Can I expect reading input from the console to work on Windows?  It
> doesn't.
>

Bit hard to understand your problem from that one-liner.


>
> Can I expect to be able to test my stuff on Windows?  That's kinda hard
> when Windows is always 6 months to 1 year behind VM-wise.
>
I'm not whining about the effort people put into this project : I'm mostly
> whining about duplication of effort and code and *very poor* Windows
> support...
>

AFAIK, Pharo 6.1 32-bit VM is up to date with the other platforms.
Regarding 64-bit Windows.  Yes it is behind.  The specific companies
interested in 64-bit Linux support put money on the table to get it done.
No one has stepped up to do the same for Windows 64-bit, so realistically
it lags behind.

btw, lately it gets harder to run 32-bit apps on Linux and OSX, but there
is no reason to stop using 32-bits VM on Windows.



>
> Can I expect to be able to contribute ?  That is kinda sad but all the
> cool scripts out there are .sh files.
>

huh?



> Just spend 2 weeks working with Pharo on Windows.  You can start with
> version 5.1 if you want and let me know how it goes...  Brace yourself, I'm
> telling you, you're off for a wild & unpleasant ride.
>

Its been a while since I worked with Pharo on Windows, but I've been using
it the last few weeks with no problems. Pharo 6.1 and Pharo 7.

cheers -ben

Re: [Pharo-users] Where do we go now ?

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
For those interested.
Created the issues 21686, 21693, 21695, 21696.
And more to come...



- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)--- End Message ---

Re: [Pharo-users] Where do we go now ?

[Clément Bera]

"Alpha software can be unstable and could cause crashes or data loss" [1]

Experiencing instability, crashes and data loss in the alpha version of a
software, including Pharo alpha, is to be expected and nothing to be
surprised about. The support of the Pharo stable version (currently 6.1)
has significantly improved in the past year. Many fixes and enhancements
were back-ported from Pharo 7 to Pharo 6.1. Based on your comments, it
seems that you have issues because you are not using the version of Pharo
that fits your needs (i.e. the stable version).

Checking the Pharo website [2], it seems there are *no* download links to
the alpha version so far because it's not considered stable enough. Where
did you get a link to download Pharo 7 alpha ?

[1] https://en.wikipedia.org/wiki/Software_release_life_cycle
[2] https://pharo.org/download


On Fri, Apr 13, 2018 at 11:26 AM, Benoit St-Jean via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Benoit St-Jean 
> To: Esteban Lorenzano 
> Cc: Any question about pharo is welcome 
> Bcc:
> Date: Fri, 13 Apr 2018 09:26:09 + (UTC)
> Subject: Re: [Pharo-users] Where do we go now ?
> BTW, why put an .exe installer for Windows available when it crashes right
> from the start? It just doesn't work at all.  Period.  For everyone.
>
> And I thought looking for senders of a method was something we mastered a
> long time ago, like starting with Smalltalk-76.  Am I supposed to assume
> that everything, even basic functionalities, are all broken because it's
> labeled "alpha" ?
>
>
> -
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>
>
> On Friday, April 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano <
> esteba...@gmail.com> wrote:
>
>
>
>
> On 13 Apr 2018, at 11:07, Benoit St-Jean  wrote:
>
> I'm on Windows 10, using Pharo 7.0 alpha 32 bit.
>
>
> and btw… which part of ALPHA you do not get?
>

> Esteban
>
>


-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/

Re: [Pharo-users] Where do we go now ?

[Alistair Grant]

On 13 April 2018 at 11:04, Sven Van Caekenberghe  wrote:
>
>
>> On 13 Apr 2018, at 08:43, p...@highoctane.be wrote:
>>
>> I consider Pharo 7 as a great piece of kit but unusable for my current work. 
>> There are many new things to learn in there. When is too much too much? 
>> Also, simplifications are breaking things in unexpected ways (like the 
>> #atEnd thing).
>
> Phil,
>
> Nothing fundamental will break with #atEnd.
>
> What you are reading in pharo-dev is a constructive discussion that (for me 
> at least) started with the desire to support one very special kind of stream 
> (stdin in C terms), something 99.99% of Pharo users have never seen, used or 
> heard of.


Completely agree (despite one of my later messages to Sven being
overly grumpy).  I've learnt a lot from this exchange.

Cheers,
Alistair


> Zn streams have worked well and as expected for Pharo versions going back to 
> 3, that won't change.

Re: [Pharo-users] Where do we go now ?

[Cyril Ferlicot D.]

On 13/04/2018 11:26, Benoit St-Jean via Pharo-users wrote:

Do you expect a cleaning of the Kernel without any break during alpha
version?

This version introduce a new message browser, new Traits, more
modularization of the kernel and some cleaning of the Kernel. I see a
lot of reason why it might break during the alpha version.

-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-users] Where do we go now ?

[Marcus Denker]

> On 13 Apr 2018, at 11:26, Benoit St-Jean via Pharo-users 
>  wrote:
> 
> 
> From: Benoit St-Jean 
> Subject: Re: [Pharo-users] Where do we go now ?
> Date: 13 April 2018 at 11:26:09 CEST
> To: Esteban Lorenzano 
> Cc: Any question about pharo is welcome 
> Reply-To: Benoit St-Jean 
> 
> 
> BTW, why put an .exe installer for Windows available when it crashes right 
> from the start? It just doesn't work at all.  Period.  For everyone.
> 
> And I thought looking for senders of a method was something we mastered a 
> long time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
> everything, even basic functionalities, are all broken because it's labeled 
> "alpha” ?

We have already a issue tracker entry with a description of a fix:


https://pharo.fogbugz.com/f/cases/21518/New-Traits-brings-wrong-behaviour-to-tagsForMethods
 


TODO: turn that description into code and make a Pull Request.

Marcus

Re: [Pharo-users] Where do we go now ?

[Esteban Lorenzano]

ok, you want to have the last word.
Go ahead. 
You have it.

What you do not have is my attention anymore.

cheers!
Esteban

> On 13 Apr 2018, at 11:26, Benoit St-Jean  wrote:
> 
> BTW, why put an .exe installer for Windows available when it crashes right 
> from the start? It just doesn't work at all.  Period.  For everyone.
> 
> And I thought looking for senders of a method was something we mastered a 
> long time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
> everything, even basic functionalities, are all broken because it's labeled 
> "alpha" ?
> 
> 
> - 
> Benoît St-Jean 
> Yahoo! Messenger: bstjean 
> Twitter: @BenLeChialeux 
> Pinterest: benoitstjean 
> Instagram: Chef_Benito
> IRC: lamneth 
> Blogue: endormitoire.wordpress.com 
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
> 
> 
> On Friday, April 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano 
>  wrote:
> 
> 
> 
> 
>> On 13 Apr 2018, at 11:07, Benoit St-Jean > > wrote:
>> 
>> I'm on Windows 10, using Pharo 7.0 alpha 32 bit.
>> 
> 
> and btw… which part of ALPHA you do not get?
> 
> Esteban

Re: [Pharo-users] Where do we go now ?

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
BTW, why put an .exe installer for Windows available when it crashes right from 
the start? It just doesn't work at all.  Period.  For everyone.

And I thought looking for senders of a method was something we mastered a long 
time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
everything, even basic functionalities, are all broken because it's labeled 
"alpha" ?


- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein) 

On Friday, April 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano 
 wrote:  
 
 


On 13 Apr 2018, at 11:07, Benoit St-Jean  wrote:
I'm on Windows 10, using Pharo 7.0 alpha 32 bit.


and btw… which part of ALPHA you do not get?
Esteban  --- End Message ---

Re: [Pharo-users] Where do we go now ?

[Esteban Lorenzano]

> On 13 Apr 2018, at 11:07, Benoit St-Jean  wrote:
> 
> I'm on Windows 10, using Pharo 7.0 alpha 32 bit.
> 

and btw… which part of ALPHA you do not get?

Esteban

Re: [Pharo-users] Where do we go now ?

[Esteban Lorenzano]

Can I expect a PR to help?

I tell you again: That tone does not helps your case, please calm down.

Esteban

> On 13 Apr 2018, at 11:07, Benoit St-Jean  wrote:
> 
> "You cannot take an alpha version and expect production quality."
> 
> I'm on Windows 10, using Pharo 7.0 alpha 32 bit.
> 
> 
> Can I at least expect to be able to save code in my local Monticello 
> repository ? It bombs. I just reported a bug!
> 
> Can I expect the Windows installer for Pharo Launcher to work on Windows?  It 
> doesn't : it crashes.  
> 
> Can I expect Pharo Launcher (not installed from the .exe installer) to work 
> on Windows?  It just doesn't. I get all kinds of error related to 
> WindowsStore, bad UTF-8 encoding and other things... (see 
> https://twitter.com/smalltalkdev/status/978973863332798464 
> )
> 
> Can I expect that when looking for implementors of a method things still 
> work?  I get duplicates (see attached file).
> 
> Can I expect reading input from the console to work on Windows?  It doesn't.
> 
> Can I expect to be able to test my stuff on Windows?  That's kinda hard when 
> Windows is always 6 months to 1 year behind VM-wise.
> 
> Can I expect to be able to contribute ?  That is kinda sad but all the cool 
> scripts out there are .sh files.
> 
> I'm not whining about the effort people put into this project : I'm mostly 
> whining about duplication of effort and code and *very poor* Windows 
> support...
> 
> Just spend 2 weeks working with Pharo on Windows.  You can start with version 
> 5.1 if you want and let me know how it goes...  Brace yourself, I'm telling 
> you, you're off for a wild & unpleasant ride.
> 
> 
> 
> 
> 
> 
> - 
> Benoît St-Jean 
> Yahoo! Messenger: bstjean 
> Twitter: @BenLeChialeux 
> Pinterest: benoitstjean 
> Instagram: Chef_Benito
> IRC: lamneth 
> Blogue: endormitoire.wordpress.com 
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
> 

Re: [Pharo-users] Where do we go now ?

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
"You cannot take an alpha version and expect production quality."
I'm on Windows 10, using Pharo 7.0 alpha 32 bit.

Can I at least expect to be able to save code in my local Monticello repository 
? It bombs. I just reported a bug!
Can I expect the Windows installer for Pharo Launcher to work on Windows?  It 
doesn't : it crashes.  

Can I expect Pharo Launcher (not installed from the .exe installer) to work on 
Windows?  It just doesn't. I get all kinds of error related to WindowsStore, 
bad UTF-8 encoding and other things... (see 
https://twitter.com/smalltalkdev/status/978973863332798464)
Can I expect that when looking for implementors of a method things still work?  
I get duplicates (see attached file).
Can I expect reading input from the console to work on Windows?  It doesn't.
Can I expect to be able to test my stuff on Windows?  That's kinda hard when 
Windows is always 6 months to 1 year behind VM-wise.
Can I expect to be able to contribute ?  That is kinda sad but all the cool 
scripts out there are .sh files.

I'm not whining about the effort people put into this project : I'm mostly 
whining about duplication of effort and code and *very poor* Windows support...
Just spend 2 weeks working with Pharo on Windows.  You can start with version 
5.1 if you want and let me know how it goes...  Brace yourself, I'm telling 
you, you're off for a wild & unpleasant ride.






- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)--- End Message ---

Re: [Pharo-users] Where do we go now ?

[Sven Van Caekenberghe]

> On 13 Apr 2018, at 08:43, p...@highoctane.be wrote:
> 
> I consider Pharo 7 as a great piece of kit but unusable for my current work. 
> There are many new things to learn in there. When is too much too much? Also, 
> simplifications are breaking things in unexpected ways (like the #atEnd 
> thing).

Phil,

Nothing fundamental will break with #atEnd.

What you are reading in pharo-dev is a constructive discussion that (for me at 
least) started with the desire to support one very special kind of stream 
(stdin in C terms), something 99.99% of Pharo users have never seen, used or 
heard of.

Zn streams have worked well and as expected for Pharo versions going back to 3, 
that won't change.

Sven

Re: [Pharo-users] Where do we go now ?

[Pavel Krivanek]

Moreover, we are increasing the system modularity so more classes in the
IDE does not mean that you need to have them all loaded.

-- Pavel

2018-04-13 10:39 GMT+02:00 Esteban Lorenzano :

> As a general note, I have to say that I find amusing how people are often
> annoyed about the growing size of the image and the amount of classes.
> We have an image that contains a full IDE which incorpores more and more
> modern capabilities. And you want that to stay small and fewer classes? I’m
> sorry but you are missing the point. More tools (or same tools enhanced)
> means more size and classes.
>
> Then… why the fear about classes? This is OOP. Doing classes is what we
> do.
> I prefer a new class to, for example passing same information into a
> dictionary.
> I prefer a new class over a string.
> I prefer a new class over a tuple.
>
> We now have slots instead symbols to express variables. I dream with even
> more classes: Selector, Protocol (we already have it, but we need to use
> it), etc., etc., etc.
> I will always prefer a class that defines a concept than a non-reified
> usage of generic classes.
>
> We need better ways to organise that information? YES! (For example I was
> thinking browser by default should not show “tool packages”, to reduce the
> amount of information).
>
> But I welcome more classes and less esoteric usages of existing ones,
> always.
>
> cheers,
> Esteban
>
> On 13 Apr 2018, at 10:30, Esteban Lorenzano  wrote:
>
>
>
> On 13 Apr 2018, at 10:25, Ben Coman  wrote:
>
> On 13 April 2018 at 13:53, Benoit St-Jean via Pharo-users <
> pharo-users@lists.pharo.org> wrote:
>
>> Just a quick word to get some things straight because, quite frankly, I
>> really don't know where we're heading.
>>
>
>
>> Do we really need 8 delay schedulers (DelayMicrosecondScheduler,
>> DelayMillisecondScheduler, DelayNullScheduler,
>> DelayExperimentalSpinScheduler, DelaySpinScheduler,
>> DelayTicklessScheduler, DelayExperimentalCourageousScheduler,
>> DelayExperimentalSemaphoreScheduler) ?
>>
>
> This should have been cleaned up a while ago.  Thanks for the bump.  I'll
> get to it.
> However note, that half of those have not more than two methods, so are
> not contributing much to the size of the Image.
>
>
> I didn’t know. Thanks :)
>
>
>
>> Perhaps a little bit of clarity and details about what's coming and
>> what's the plan would be beneficial to a lot of us.
>>
>
> I guess you are looking for...
> https://github.com/pharo-project/pharo-workingRoadmaps/
> blob/master/Pharo7/ROADMAP.md
>
>
> cheers -ben
>
>
>
>
>
>

Re: [Pharo-users] Where do we go now ?

[Esteban Lorenzano]

> On 13 Apr 2018, at 10:31, Cyril Ferlicot D.  wrote:
> 
> On 13/04/2018 07:53, Benoit St-Jean via Pharo-users wrote:
> 
> Hi,
> 
> I don't have time to answer to everything but I can give some details:
> 
> - Nautilus will be removed when Calypso will be really stable (During
> the Calypso development if calypso breaks, you need an other browser to
> replace it)
> - The old compiler will be removed as an external project
> (https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md)
> - I think it's planned to remove the EyeInspector
> - Kommiter and Versionner will also be removed in next versions of Pharo
> 
> "Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha
> has 7612 classes."
> 
> In general I do not like metrics in term of number of classes because I
> prefer a system with 7500 classes of 50 lines of code than a system of
> 6000 classes of 300 lines of codes.

amen!

> 
> "Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference
> settings. Pharo 7.0 alpha has 662 preference settings."
> 
> The number of settings is not a bad thing if it's well organized. The
> current problem is not the number of settings, it's more their
> organization.
> 
> Have a nice day. :)
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 

Re: [Pharo-users] Where do we go now ?

[Esteban Lorenzano]

As a general note, I have to say that I find amusing how people are often 
annoyed about the growing size of the image and the amount of classes.
We have an image that contains a full IDE which incorpores more and more modern 
capabilities. And you want that to stay small and fewer classes? I’m sorry but 
you are missing the point. More tools (or same tools enhanced) means more size 
and classes.

Then… why the fear about classes? This is OOP. Doing classes is what we do. 
I prefer a new class to, for example passing same information into a dictionary.
I prefer a new class over a string.
I prefer a new class over a tuple.

We now have slots instead symbols to express variables. I dream with even more 
classes: Selector, Protocol (we already have it, but we need to use it), etc., 
etc., etc.
I will always prefer a class that defines a concept than a non-reified usage of 
generic classes.

We need better ways to organise that information? YES! (For example I was 
thinking browser by default should not show “tool packages”, to reduce the 
amount of information).

But I welcome more classes and less esoteric usages of existing ones, always.

cheers,
Esteban

> On 13 Apr 2018, at 10:30, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 13 Apr 2018, at 10:25, Ben Coman > > wrote:
>> 
>> On 13 April 2018 at 13:53, Benoit St-Jean via Pharo-users 
>> > wrote:
>> Just a quick word to get some things straight because, quite frankly, I 
>> really don't know where we're heading.
>>  
>> Do we really need 8 delay schedulers (DelayMicrosecondScheduler, 
>> DelayMillisecondScheduler, DelayNullScheduler, 
>> DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, 
>> DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ? 
>> 
>> This should have been cleaned up a while ago.  Thanks for the bump.  I'll 
>> get to it.
>> However note, that half of those have not more than two methods, so are not 
>> contributing much to the size of the Image.
> 
> I didn’t know. Thanks :)
> 
>>  
>> Perhaps a little bit of clarity and details about what's coming and what's 
>> the plan would be beneficial to a lot of us.
>> 
>> I guess you are looking for...
>> https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
>>  
>> 
>> 
>> 
>> cheers -ben
>> 
>> 
>> 
> 

Re: [Pharo-users] Where do we go now ?

[Cyril Ferlicot D.]

On 13/04/2018 07:53, Benoit St-Jean via Pharo-users wrote:

Hi,

I don't have time to answer to everything but I can give some details:

- Nautilus will be removed when Calypso will be really stable (During
the Calypso development if calypso breaks, you need an other browser to
replace it)
- The old compiler will be removed as an external project
(https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md)
- I think it's planned to remove the EyeInspector
- Kommiter and Versionner will also be removed in next versions of Pharo

"Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha
has 7612 classes."

In general I do not like metrics in term of number of classes because I
prefer a system with 7500 classes of 50 lines of code than a system of
6000 classes of 300 lines of codes.

"Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference
settings. Pharo 7.0 alpha has 662 preference settings."

The number of settings is not a bad thing if it's well organized. The
current problem is not the number of settings, it's more their
organization.

Have a nice day. :)

-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-users] Where do we go now ?

[Esteban Lorenzano]

> On 13 Apr 2018, at 10:25, Ben Coman  wrote:
> 
> On 13 April 2018 at 13:53, Benoit St-Jean via Pharo-users 
> > wrote:
> Just a quick word to get some things straight because, quite frankly, I 
> really don't know where we're heading.
>  
> Do we really need 8 delay schedulers (DelayMicrosecondScheduler, 
> DelayMillisecondScheduler, DelayNullScheduler, 
> DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, 
> DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ? 
> 
> This should have been cleaned up a while ago.  Thanks for the bump.  I'll get 
> to it.
> However note, that half of those have not more than two methods, so are not 
> contributing much to the size of the Image.

I didn’t know. Thanks :)

>  
> Perhaps a little bit of clarity and details about what's coming and what's 
> the plan would be beneficial to a lot of us.
> 
> I guess you are looking for...
> https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
>  
> 
> 
> 
> cheers -ben
> 
> 
> 

Re: [Pharo-users] Where do we go now ?

[Esteban Lorenzano]

Hi,

> On 13 Apr 2018, at 07:53, Benoit St-Jean via Pharo-users 
>  wrote:
> 
> 
> From: Benoit St-Jean 
> Subject: Where do we go now ?
> Date: 13 April 2018 at 07:53:46 CEST
> To: pharo-users@lists.pharo.org
> Reply-To: Benoit St-Jean 
> 
> 
> Hello guys,
> 
> Just a quick word to get some things straight because, quite frankly, I 
> really don't know where we're heading.
> 
> When Pharo started, the goal was to depart from Squeak and do a *major clean 
> up* of all the code, especially Morphic.  The promise of a new, clean & lean 
> Smalltalk attracted a lot of people.  And then...
> 
> I'm looking at the Pharo 7.0 image right now and I just don't get where we're 
> heading.  Every Pharo release gets bigger, and bigger, and bigger.  I don't 
> mind the environment getting bigger if it adds functionalities or new tools 
> but that's not quite the case here. LOTS of stuff is just duplicated.
> 
> Do we really need 2 code completion classes (NECController, NOCController) ?  
> Do we really need 2 system browsers (Nautilus, Calypso)? Do we really need 2 
> compilers (OpalCompiler, Compiler) ?  Do we really need 8 delay schedulers 
> (DelayMicrosecondScheduler, DelayMillisecondScheduler, DelayNullScheduler, 
> DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, 
> DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ?  
> Do we really need 2 inspectors (GTInspector, EyeInspector) ?  Do we really 
> need 2 workspaces (GTPlayground, Workspace) ? Et cetera. Et cetera. Et 
> cetera.  I could go on, and on, and on…

Pharo 7.0 is a development version.
Before is releases most duplicated things you mention here will be gone: 

- Nautilus 
- Compiler
- EyeInspector

Workspace could be gone but we need a fallback in case the other more potent 
tools fail.
Schedulers are still necessary.

> 
> Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has 
> 7612 classes.  Can you see a trend?
> 
> Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference settings. 
> Pharo 7.0 alpha has 662 preference settings.  Can you see a trend?
> 
> Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0 
> alpha has a 47.97 MB image.  Can you see a trend?

Pharo 5.1 didn’t have : 

- GTTools
- Iceberg
- Epicea
- and many others.

> 
> Add to that the fact that Pharo is a nightmare when you want to port code.  
> Just with the 7.0 release, 61 classes will be deprecated (and lots more to 
> come if you search for the string "deprecated" into the code, most of the 
> time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess 
> classes).

If you do not want we to remove classes, how do you want we to go “smaller" and 
cleaner?

> You have code that deals with sockets, should you use the old Socket classes 
> or convert everything to Zodiac? And why do we keep both "frameworks" in the 
> image ?  Pharo hasn't been backward compatible with "old socket classes" a 
> looong time ago anyway!

Zodiac relies on Sockets, there is not duplication there.

> You have code that deals with dependencies, should you use the old dependents 
> mechanism or convert everything to announcements?

you got me here. 
but removing takes time… you are free to contribute with fixes :)

> 
> UI speaking, what framework should anyone use ?  Athens?  Something else?

yes, I think Athens should not be part of the image but a loadable package.

> 
> You have code that deals with streams, should you use the old stream classes 
> or convert everything to Zinc ? And why do we keep both "frameworks" in the 
> image ?  Pharo hasn't been backward compatible with the old stream classes a 
> looong time ago anyway! 

again, you are mixing pearls and apples here.
(and btw, there was a HUGE refactor of streams on P7)

> So what's the plan?  For instance, should I keep using the Nautilus Browser 
> or I should switch to the Calypso browser and get used to it because Nautilus 
> will be deprecated?  Or should I just don't care because a third system 
> browser will be added in Pharo 8 just because "it's cool, let's add this one 
> too!” ?

The plan is continue improving slowly but steady… things takes time.

> Couldn't we just decide on what's "official" and what's a goodie or an 
> external optional tool/package/framework the same way all other Smalltalks 
> do?  If you say Calypso is the official & supported browser, fine!  Then just 
> get Nautilus out of the image, create a nice loadable package for it and if 
> someone prefers Nautilus, they'll just have to load it into the image, the 
> same way VW has a gazillion optional tools/packages/frameworks you can load 
> from a parcel!
> 
> Whenever I get asked a simple question by a newbie like "Oh, which system 
> browser should I use?", quite frankly, I don't know what to answer.  Did we 
> include Calypso to deprecate Nautilus later?  Is 

Re: [Pharo-users] Where do we go now ?

[Ben Coman]

On 13 April 2018 at 13:53, Benoit St-Jean via Pharo-users <
pharo-users@lists.pharo.org> wrote:

> Just a quick word to get some things straight because, quite frankly, I
> really don't know where we're heading.
>


> Do we really need 8 delay schedulers (DelayMicrosecondScheduler,
> DelayMillisecondScheduler, DelayNullScheduler,
> DelayExperimentalSpinScheduler, DelaySpinScheduler,
> DelayTicklessScheduler, DelayExperimentalCourageousScheduler,
> DelayExperimentalSemaphoreScheduler) ?
>

This should have been cleaned up a while ago.  Thanks for the bump.  I'll
get to it.
However note, that half of those have not more than two methods, so are not
contributing much to the size of the Image.


> Perhaps a little bit of clarity and details about what's coming and what's
> the plan would be beneficial to a lot of us.
>

I guess you are looking for...
https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md


cheers -ben

Re: [Pharo-users] Where do we go now ?

[p...@highoctane.be]

It is true that there are many things in there.

New tools have to be finished before the old ones can be removed (there was
a time where refactorings were not in Calypso).

But for a real project, one is settling for a version and a toolset.

I am not really keen to migrate Pharo projects from one version to another
and some deprecations seems rather gratuitous sometimes.

The world also moves forward and it shows in the image.

I think that Iceberg has swallowed a lot of bandwidth and as a result other
elements are in need of more love.

Pharo7 is unreleased yet. Some say something is great by version 10. 3
versions to go.

I consider Pharo 7 as a great piece of kit but unusable for my current
work. There are many new things to learn in there. When is too much too
much? Also, simplifications are breaking things in unexpected ways (like
the #atEnd thing).

I am glad 6.1 gets backports and new releases for sure.

Phil





On Fri, Apr 13, 2018, 07:53 Benoit St-Jean via Pharo-users <
pharo-users@lists.pharo.org> wrote:

> Hello guys,
>
> Just a quick word to get some things straight because, quite frankly, I
> really don't know where we're heading.
>
> When Pharo started, the goal was to depart from Squeak and do a *major
> clean up* of all the code, especially Morphic.  The promise of a new, clean
> & lean Smalltalk attracted a lot of people.  And then...
>
> I'm looking at the Pharo 7.0 image right now and I just don't get where
> we're heading.  Every Pharo release gets bigger, and bigger, and bigger.  I
> don't mind the environment getting bigger if it adds functionalities or new
> tools but that's not quite the case here. LOTS of stuff is just duplicated.
>
> Do we really need 2 code completion classes (NECController, NOCController)
> ?  Do we really need 2 system browsers (Nautilus, Calypso)? Do we really
> need 2 compilers (OpalCompiler, Compiler) ?  Do we really need 8 delay
> schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler,
> DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler,
> DelayTicklessScheduler, DelayExperimentalCourageousScheduler,
> DelayExperimentalSemaphoreScheduler) ?  Do we really need 2 inspectors
> (GTInspector, EyeInspector) ?  Do we really need 2 workspaces
> (GTPlayground, Workspace) ? Et cetera. Et cetera. Et cetera.  I could go
> on, and on, and on...
>
> Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha
> has 7612 classes.  Can you see a trend?
>
> Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference
> settings. Pharo 7.0 alpha has 662 preference settings.  Can you see a trend?
>
> Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0
> alpha has a 47.97 MB image.  Can you see a trend?
>
> Add to that the fact that Pharo is a nightmare when you want to port
> code.  Just with the 7.0 release, 61 classes will be deprecated (and lots
> more to come if you search for the string "deprecated" into the code, most
> of the time hidden in the comments of the
> soon-to-be-deprecated-in-Pharo-8-I-guess classes).
>
> You have code that deals with sockets, should you use the old Socket
> classes or convert everything to Zodiac? And why do we keep both
> "frameworks" in the image ?  Pharo hasn't been backward compatible with
> "old socket classes" a looong time ago anyway!
>
> You have code that deals with dependencies, should you use the old
> dependents mechanism or convert everything to announcements?
>
> UI speaking, what framework should anyone use ?  Athens?  Something else?
>
> You have code that deals with streams, should you use the old stream
> classes or convert everything to Zinc ? And why do we keep both
> "frameworks" in the image ?  Pharo hasn't been backward compatible with the
> old stream classes a looong time ago anyway!
>
> So what's the plan?  For instance, should I keep using the Nautilus
> Browser or I should switch to the Calypso browser and get used to it
> because Nautilus will be deprecated?  Or should I just don't care because a
> third system browser will be added in Pharo 8 just because "it's cool,
> let's add this one too!" ?
>
> Couldn't we just decide on what's "official" and what's a goodie or an
> external optional tool/package/framework the same way all other Smalltalks
> do?  If you say Calypso is the official & supported browser, fine!  Then
> just get Nautilus out of the image, create a nice loadable package for it
> and if someone prefers Nautilus, they'll just have to load it into the
> image, the same way VW has a gazillion optional tools/packages/frameworks
> you can load from a parcel!
>
> Whenever I get asked a simple question by a newbie like "Oh, which system
> browser should I use?", quite frankly, I don't know what to answer.  Did we
> include Calypso to deprecate Nautilus later?  Is Calypso just a proof of
> concept?  Is it just an optional tool?  What about all those delay
> schedulers?
>
> "I loaded this code from SqueakSource and it just