Re: [Pharo-users] "Building-With versus Building-on"

[jtuc...@objektfabrik.de]

Am 12.10.17 um 20:04 schrieb Dimitris Chloupis:


Eclispe , which I will disagree with your that is not the worst IDE, 
started as a smalltalk IDE and then it got Eclipsed. I am sure those 
people had a "build on" environment , still it got messy. We can blame 
porting to Java, but can we really blame Java for the mess that is 
called "Eclipse" e nope.


Eclipse was never implemented in Smalltalk. Its predecessor, VisualAge 
for Java (and parts of the other VisualAge family members) was. Eclipse 
was started as a replacement for VisualAge for Java because Java 
develoers didn't like VisualAge for its emulation of an image based 
environement. It was a very nice IDE for Java (the best I've known), but 
it wasn't a nice home for developers who think in files.
These days Eclipse, IMO, does emulate an image as good as possible, but 
nobody cares anymore, because it hides the fact and lets you think in 
files ;-)


Joachim

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

[Dimitris Chloupis]

I don’t care about Python vs Pharo debate. I love both I use both.

My ultimate goal is to unite the two under a single Uber powerful live
coding environment part of my project Atlas. With direct mapping between
Pharo and Python objects and no compromises. A workflow that will be
seamless that you won’t know if you use Python or Pharo libraries as the
Atlas environment will allow you to work with both languages in a symbiotic
relationship.

That was a dream of mine that I did not dear to reveal now slowly and
steadily becomes reality.

I am extending the live coding environment of python and later will tackle
the subject of a python image format.

Already Atlas can use python libraries from Pharo but that’s about it , but
after this revelation I can move to stage 2 of full synchronization between
Python and Pharo. Even now Atlas allows you to use Pharo syntax to fully
access Python libraries. But integration is skin deep and is what is going
to improve the next years.

So it seems something good came out of this very long discussion. Atlas is
going for a big update. This thread has been a huge inspiration for me.
Super excited :)

On Sat, 14 Oct 2017 at 03:40, Andrew Glynn  wrote:

> The first language I played with, I was nearly 5, was a live environment,
> Forth. I used it on an old PDP my mother had bought that was being
> surplused at the company she worked at. I used Forth until I was in my
> early teens, it was far superior to the BASIC that most other kids I knew
> who knew any programming used. It wasn't Smalltalk, but in many of the
> areas it was used (production automation is one major area), the language
> that most often replaced it *was* Smalltalk.
>
> The biggest difference, for me, as I wrote in the article the other day,
> is the ability to build-on rather than build-with, which in turn is based
> on the environment being written in itself. Ruby *looks* very much like
> Smalltalk, but it *works* like Java; Python works *more* like Smalltalk,
> and it's a much better live environment than Java or Ruby, because more of
> it is written in itself, but too much of Python is written in C, and that
> causes problems. If the code that interprets/compiles your code follows the
> same rules, the machine code it generates will usually also follow the same
> rules, and those rules/restrictions are, for the most part, designed to
> make code more reliable.
>
> As well, RVM has proven Smalltalk (specifically Squeak / Pharo, though
> admittedly an older version) can scale to 1024 cores nearly linearly.
>
> Python has a decent developer base but it's almost all OSS and almost all
> on Linux. Very few applications in Python are in areas where reliability is
> absolutely necessary, or even all that important.  Like Smalltalk, it's a
> general purpose language in a niche, but the niches are very different. For
> years, decades really, any good version of Smalltalk cost an arm and a leg
> (some of them both of each), and as a result it tended to be used only
> where things really *had* to work.
>
> Pharo is a great OSS Smalltalk, IMHO by the best to date (Squeak was/is
> good, but the LaF was never professional enough for it to be taken as
> seriously as it deserves, it just looks too much like a toy although in
> reality it's very powerful). Having the capability to build-on a reliable,
> attractive and enjoyable base without signing over my great-grand-child's
> first born is fantastic, and a great achievement for those who accomplished
> it.
>
> Kendrick is an example of what can be done if you build-*on*: it was
> built on Moose, which is built on Glamorous, which is built on Morphic,
> which itself is based on a couple of decades work olving the basic problems
> inherent to UI's and MVC-type UI's in particular. Kendrick itself was
> written in a very short time when you compare it with other epidemiology
> programs, *if* you only count the time spent on Kendrick itself. It's an
> inherently complex problem area, and it's a life or death problem area.
> That an application capable of working reliably enough to be trusted in
> that area was built in a short time, because it was built-on a couple of
> decades of OSS work, is a huge compliment to those who were involved.
>
> Unfortunately for me, I wasn't, ☺. But at least I can take advantage of it
> existence now.
>
> Andrew
>
>
>
>
>
>
>
>
>
> -Original Message-
>
> *Date*: Fri, 06 Oct 2017 21:18:28 +
> *Subject*: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk
> *To*: Any question about pharo is welcome  
> >
> Reply-to: Any question about pharo is welcome  >
> *From*: Dimitris Chloupis  >
> Wise not to mention Ruby and Python and Pick the worst of the worst in
> OOP. Because frankly the competition for 

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

[Andrew Glynn]

The first language I played with, I was nearly 5, was a live
environment, Forth.  I used it on an old PDP my mother had bought that
was being surplused at the company she worked at.  I used Forth until I
was in my early teens, it was far superior to the BASIC that most other
kids I knew who knew any programming used.  It wasn't Smalltalk, but in
many of the areas it was used (production automation is one major
area), the language that most often replaced it was Smalltalk.  
The biggest difference, for me, as I wrote in the article the other
day, is the ability to build-on rather than build-with, which in turn
is based on the environment being written in itself. Ruby looks very
much like Smalltalk, but it works like Java; Python works more like
Smalltalk, and it's a much better live environment than Java or Ruby,
because more of it is written in itself, but too much of Python is
written in C, and that causes problems. If the code that
interprets/compiles your code follows the same rules, the machine code
it generates will usually also follow the same rules, and those
rules/restrictions are, for the most part, designed to make code more
reliable. 
As well, RVM has proven Smalltalk (specifically Squeak / Pharo, though
admittedly an older version) can scale to 1024 cores nearly linearly.  
Python has a decent developer base but it's almost all OSS and almost
all on Linux. Very few applications in Python are in areas where
reliability is absolutely necessary, or even all that important.  Like
Smalltalk, it's a general purpose language in a niche, but the niches
are very different. For years, decades really, any good version of
Smalltalk cost an arm and a leg (some of them both of each), and as a
result it tended to be used only where things really had to work.  
Pharo is a great OSS Smalltalk, IMHO by the best to date (Squeak was/is
good, but the LaF was never professional enough for it to be taken as
seriously as it deserves, it just looks too much like a toy although in
reality it's very powerful). Having the capability to build-on a
reliable, attractive and enjoyable base without signing over my great-
grand-child's first born is fantastic, and a great achievement for
those who accomplished it.
Kendrick is an example of what can be done if you build-on:  it was
built on Moose, which is built on Glamorous, which is built on Morphic,
which itself is based on a couple of decades work olving the basic
problems inherent to UI's and MVC-type UI's in particular.  Kendrick
itself was written in a very short time when you compare it with other
epidemiology programs, if you only count the time spent on Kendrick
itself.  It's an inherently complex problem area, and it's a life or
death problem area. That an application capable of working reliably
enough to be trusted in that area was built in a short time, because it
was built-on a couple of decades of OSS work, is a huge compliment to
those who were involved.  
Unfortunately for me, I wasn't, ☺.  But at least I can take advantage
of it existence now.
Andrew








-Original Message-
Date: Fri, 06 Oct 2017 21:18:28 +Subject: Re: [Pharo-users] Behold
Pharo: The Modern SmalltalkTo: Any question about pharo is welcome Reply-to: Any question about pharo is welcome
From: Dimitris Chloupis Wise not to mention Ruby and Python and Pick the worst of the
worst in OOP. Because frankly the competition for Pharo against those
two behemoths can be quite brutal in the flexibility and power of OOP. 
And no , these language can do live coding with ease. I know because I
currently code live coding style with Python for an app I am making.
Sure it wont provide you with a live system out of the box, but put in
10 lines of code and you already ready to go with hardcore live coding.
At least Python , Ruby being practically a rip off of Smalltalk
language may need even less. 

iPython which by the way is by far the most popular Python tool is the
real deal, a full blow live coding enviroment. 

To my suprise its not even hard to do live coding with C/C++ including
using image format. To my shock live coding is actually supported by
both the OS and the hardware. Hardware has its own exception system ,
OS has an image flie format called "memory mapped files" used for DLLs
and a lot of essential functionality. 

For some weird reason however its well hidden and not that much
utilised by coders. They really love long compile times, dont ask me
why. 

But yeah C++ even though it has come a long way with its template
system, its still the king of ugly. That sytax, oh the horrors of that
syntax. yiaks !!!

I am so enternal greatful that Pharo introduced me to live coding and
opened my eyes to universe of fun and productivity. I cannot imagine
coding an other way ever again. 

I really hope that we take this further though. 

On Wed, Oct 4, 2017 at 1:31 PM horrido 
wrote:
> Behold Pharo: The Modern 

[Pharo-users] Bloc Example Errors & question

[Ricardo Pacheco]

I was reviewing the Bloc examples because I'm looking for a way to connect
several blocks like this:  
. The idea is that if I move the block, the link with other blocks is kept.
I could not find any similar example. Any hint would be appreciated.

Also, while reviewing the examples in the latest Pharo 6, some crashed and a
couple even let Pharo unresponsive:

BlBasicExamples >> example3D  (crash)
BlBasicExamples >> exampleWithImage   
BlBenchmark >> example_821nestedEl_in1000x1000_mouseMove50ms (crash)
BlMobilePhone >> open

Thanks

Ricardo



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

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

[Nicolai Hess]

2017-10-13 22:04 GMT+02:00 Andrew Glynn :

> I understand why it occurs, both the private and the final keyword
> affect the reference rather than the object. However, to quote someone
> else "That the value of a private field can be changed without a public
> setter implies that encapsulation is weak at best, and shouldn't be
> counted on to protect key values, even in combination with the final
> keyword." Even that comment, though, brings in the notion of a 'value'
> that's not an object.
>

and who did you quote ?



>
> My point initially was not about the code, but about the Java API doc
> that also claims attempting to change the *value* will result in a compile
> error. Although keywords affect references, the documentation states
> that it affects 'the value', which is at best ambiguous.
>

I can not see what is wrong here.
You are problably confused by
- the value of a *variable*
- and the value an *object* represents (its object state)
the first can not be changed for a final variables
the last can only be preserved, if the object is immutable.



> There are also numerous issues around type erasure
>

... this seems a bit off topic


> I'd rather have *no* API documentation than documentation of the sort
> represented by the Java API doc.
>

I  think a java api doc like documentation would help.
For newcomers, that not yet know ( or know how to find) the in-image help.
And even so we can easily browse our code with comments and class comments,
an API-doc could provide the help from a different view (group by
collaboration rather
then by class hierarchy or packages), give an "overall" view or provide
additional code examples.



> Not that I think it's all
> intentional, though perhaps the primitives and scalars that are in fact
> objects
>

How are java primitives "in fact" objects ? They are "in fact" primitives.
This is different from
smalltakl where some *objects* like Smallinteger are implemented as
primitives (or immediates)
but still objects on the (smalltalk) code level.


> and collections may have been to muffle wailing from C/C++
> programmers that the lack of primitives and scalars would kill
> performance. I suspect it's more often a result of unsuccessfully
> mode-switching, though, between the rules of the language you're
> implementing and those of the language you're implementing *in*, but that
> only makes the case for languages implemented in themselves stronger.
>
> Andrew
>
>
> -Original Message-
>
> Date: Fri, 13 Oct 2017 18:39:59 +0200
> Subject: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk
> To: Any question about pharo is welcome 
> Reply-to: Any question about pharo is welcome  us...@lists.pharo.org>
> From: Nicolai Hess 
>
>
> Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" :
> I can't remember ever using API docs in any language, dynamic or not.
> They give you the method signatures, but if you have, say, methodX(int,
> int, String), how are you supposed to guess what ints and what String
> the method actually needs,
>
>
> Isn't this exactly what an apidoc is for? Additional documentation to
> describe the methods and   arguments purpose.
>
> Maybe you have just seen poorly documented libraries?
>
>
> One of my favourite language fails can be reproduced by doing this:
>
> Declare a field private final in Java, initializing it either in the
> declaration or the constructor, and provide only a getter. Use the getter
> from another class and change the value of the local variable. Then use the
> getter again, but assign the value to a new local variable, and check the
> value.
>
>
>
> Maybe you should re-read about javas  final keyword.
> It is not to meant making something immutable ,
> you can just not reassign a new value.
>
> Java final != c++ const
>
>
>
>

Re: [Pharo-users] FYI about Pharo MOOC

[Dimitris Chloupis]

I have to confess I am a fan of the french accent english too , it has a
nice musicality in it
+1 for subtitles. I love accents, the more the better :D

On Fri, Oct 13, 2017 at 9:28 PM Stephane Ducasse 
wrote:

> In fact the files have two tracks.
>
>
> On Fri, Oct 13, 2017 at 8:13 PM, Andrew Glynn  wrote:
>
>> Oh good, glad the French version is still there.  I was starting to go
>> through it a couple of weeks ago and plan to continue starting this
>> weekend.  Although my mother tongue is English, at one point I was
>> fluently bilingual (both Quebecois and actual French), and it's a
>> chance to get some of it back while picking up information I've likely
>> missed
>> on less obvious features.
>>
>> I can understand French well enough, but the more I hear it spoken
>> the better. Reading/writing don't get rusty as easily.
>>
>> Of course speaking it would be even better, but I don't get many
>> chances to do so in Toronto ☺.
>>
>> Andrew
>>
>> -Original Message-
>>
>> Date: Fri, 13 Oct 2017 18:06:17 +0200
>> Subject: Re: [Pharo-users] FYI about Pharo MOOC
>> To: Any question about pharo is welcome 
>> Reply-to: Any question about pharo is welcome > us...@lists.pharo.org>
>> From: Stephane Ducasse 
>> The production company told us that it was super strange without our
>> voices.
>> Now you can also have the french + subtitles.
>>
>> On Fri, Oct 13,
>> 2017 at 2:42 PM, Ben Coman  wrote:
>>
>> I played C019SD-
>> W1-S1-EN-V1.mp4
>> and as well as the english voice, in the
>> background I
>> can still hear your
>> original french voice.
>> I'm curious the
>> rea
>> soning for
>> this.
>>
>> cheers -ben
>>
>>
>> On Fri, Oct 13, 2017 at 3:59 AM, Stephane Ducasse > haro.s...@gmail.com>
>> wrote:
>>
>> I'm about to release the en versions.
>> you can
>> find them unofficially on http://www.stephaneducasse.eu/MOOC/
>>
>> Stef
>>
>> On
>> Tue, Oct 10, 2017 at 10:10 PM, Gour  wrote:
>>
>> On Tue,
>> 10 Oct 2017 21:31:55 +0200
>> Stephane Ducasse
>> 
>> wrote:
>>
>> Hello Stef,
>>
>> I will ask one guy thursday and let you know.
>>
>>
>> Thanks a
>> lot!
>>
>> We will release Mooc with english voices (not mine else english
>> nati
>> ves would get an heart attack - I have what they call a sexy
>> french
>> accents ;)
>>
>>
>> I did watch few of your Pharo-related presentations and,
>> although not
>> native,
>> happily survived. :-)
>>
>> Moreover, I'd say that your
>> English is charming! At least, one is sure
>> that the
>> real human is
>> speaking and not some "robot" put on auto-pilot, so if the
>> new
>> Mooc is
>> going to be the same as the  current/old one, I'd prefer to
>> download
>> the
>> current files and watched them along with *.srt subtitles?
>>
>> Iow. my point
>> is that the accent is just one part of the talk/teaching,
>> but the
>> energy
>> behind it is much more imporant - this is, my conviction, based
>> on my
>> own
>> teaching experiences.
>>
>>
>> Sincerely,
>> Gour
>>
>> --
>> From anger, complete delusion
>> arises, and from delusion
>> bewilderment of memory. When memory is
>> bewildered,
>> intelligence is lost, and when intelligence is lost
>> one falls
>> down again into the material pool.
>>
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-users] Is possible to keep some code closed in Pharo?

[Dimitris Chloupis]

If you make a morph maximise and pin it down, it will cover the entire
pharo windows and wont be movable and will make it impossible for the user
to interact with the IDE even via shorcuts. If I am wrong on shortcuts I
hope someone correct me but last time I checked that was the case.

Command line wise, command line api is very elegant, very simple to add and
remove arguments.

Those will block the user from controlling Pharo.

Soruce code visibility:

1) What stef said, delte sources
2) If you use monticello the traditional way ,it saves in mcz files which
are jus zip files with source code files inside. Created every time you
save to a local or remote repo
3) Delete any fileouts, those produce st files too, smalltalk source code
files
4) if you use filetree that uses source files too but generally you would
pick a directory outside pharo
5) changes files also contain source code you modified or added
6) We hava new recovery tool, I forget the name, has its own file format I
dont rememebr if it uses text files like changes, it might, check that out
too.

Generally anywhere you spot a file with st extension its a source code
file, delete it or move it away. We may use an image format but we generate
a ton of source code files for various reason as you can see.

On Fri, Oct 13, 2017 at 8:27 PM Ricardo Pacheco <
ricardo.pacheco.rol...@gmail.com> wrote:

> Wow, that sounds great. Thanks a lot!!
>
> Ricardo
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

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

[Dimitris Chloupis]

Well oh Well, Python is stupid Very, very stupid

To my suprise live coding in Python its actually easier to what I expected
and almost the same, from user perspective to that of pharo.Minus the IDE
conveiniece of course.  But a pain in the hat to find the proper way to do
it.

I was reloading modules, was thining of implementing become to python ,
which basically means replacing references to old instance object with
references to new objects , then I thought that it would be more efficient
to just reference the new methods to the instances and after a TON of
testing I realized this is dead simple and for some reason python hides it
very well. All the above were completely unecessary.

Insance methods are referencing functions in the class object. Apparently
functions in a class are taken as class methods and functions with self as
first argument are considered instance methods. Which means I just copy
paste the code of the method to the debugger, and assign it back to the
existing live class and all instances are updated automagically. No need
for become, no need to update instances manually no need to even reload the
module. Similarly you can delete methods and add methods on the fly always
live. Renaming a method is basically deleting and assigning . Renaming the
class is the same. As is for class and instance variables. So anything can
change on the fly. Names are there for your pleasure, in the end all that
matters are the references.Its objects all the way down.

The equivelant of a python instance method defiition and live updae , the
python way, on Pharo would be

MyClass instanceMethodName:= myMessage firstArg:self arg2: foo1 arg3:
foo2
|locals|
code stuff

and you python "call it" or message it

MyClass insanceMethodName arg2:foo1 arg3: foo2 , no need to use self when
calling it. Self is automatically passed because from the definition python
knows this is suppose to be an insance method.

or you could put a block after the assigment , because the name of the
message is assigned by the assignment anyway,  for class method you ommit
the first argument of self. Calling is the same. This replaces a method or
adds it if does not exist. All instances of that live class are immediately
poitining to the new method. So the class is basically a collection of
references.

So all I have to do now is to wrap the copy paste and assignment in a
single shortcut or button and I am ready to fly to live coding land. Days
wasted chasing my tail but at least I learned a lot about python objects
which are basically dictionaries objects (for variables) plus function
objects (for class and instance methods) wrap inside an object, or rather
referenced, called a class.

Storing the live state , similar to fuel, is supported by the pickle
library.

Why on earth python made it so hard something so simple to understand ? no
idea .I dont even need to make a live coding enviroment library as I
assumed, its already there, hiding under the cover too scared to come out.


Now I know why none or almost none does live coding in Python.

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

[Andrew Glynn]

I understand why it occurs, both the private and the final keyword
affect the reference rather than the object. However, to quote someone
else "That the value of a private field can be changed without a public
setter implies that encapsulation is weak at best, and shouldn't be
counted on to protect key values, even in combination with the final
keyword."  Even that comment, though, brings in the notion of a 'value'
that's not an object.

My point initially was not about the code, but about the Java API doc
that also claims attempting to change the value will result in a
compile
error. Although keywords affect references, the documentation states
that it affects 'the value', which is at best ambiguous. There's
inevitably a conflation of passing by value and passing by reference in
Java by former C/C++ programmers, since it looks like PBV to a C/C++
programmer while always in fact being PBR.  When copying syntax
inverting the meaning of the syntax is counterproductive. 

There are also numerous issues around type erasure (mainly that it
works for
collections, even simple collections such as vectors, but not for
arrays) and the resulting need for Java to allow invalid type casts in
certain cases even though they can result in uncaught runtime
exceptions. Since the fact that they are invalid is explicit in the API
doc, that they are allowed because there's no other way to do it is
problematic.

Using lambdas or the streaming API within Java EE is another
undocumented problem, or set of problems ( it was good fortune for me
personally - when some software using the streaming API in an EE
container consistently failed and the developer had no idea why, the
company gave me the project I implemented it in Pharo, ☺ ).  Oracle did
at one point have a note on the Java EE 7 download page to the effect
that Java EE 7 shouldn't be used with Java SE 8, but that was
'disappeared' when Java SE 7 was no longer supported and Java EE 7 was
still the latest version.  Since Java EE 8 is not even on the horizon,
while SE 9 is due 'any minute now', I have to wonder if EE is simply
dead.  The requests from IBM, SAP and others to take over EE imply they
at least suspect the same.

I'd rather have no API documentation than documentation of the sort
represented by the Java API doc.  Not that I think it's all
intentional, though perhaps the primitives and scalars that are in fact
objects and collections may have been to muffle wailing from C/C++
programmers that the lack of primitives and scalars would kill
performance.  I suspect it's more often a result of unsuccessfully
mode-switching, though, between the rules of the language you're
implementing and those of the language you're implementing in, but that
only makes the case for languages implemented in themselves stronger.

Andrew


-Original Message-

Date: Fri, 13 Oct 2017 18:39:59 +0200
Subject: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk
To: Any question about pharo is welcome 
Reply-to: Any question about pharo is welcome 
From: Nicolai Hess 


Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" :
I can't remember ever using API docs in any language, dynamic or not. 
They give you the method signatures, but if you have, say, methodX(int,
int, String), how are you supposed to guess what ints and what String
the method actually needs,


Isn't this exactly what an apidoc is for? Additional documentation to
describe the methods and   arguments purpose. 

Maybe you have just seen poorly documented libraries?


One of my favourite language fails can be reproduced by doing this: 

Declare a field private final in Java, initializing it either in the
declaration or the constructor, and provide only a getter. Use the
getter from another class and change the value of the local variable.
Then use the getter again, but assign the value to a new local
variable, and check the value.  



Maybe you should re-read about javas  final keyword.
It is not to meant making something immutable ,
you can just not reassign a new value.

Java final != c++ const

Re: [Pharo-users] Zinc release?

[Sven Van Caekenberghe]

Herby,

> On 13 Oct 2017, at 14:37, Herby Vojčík  wrote:
> 
> Sven Van Caekenberghe wrote:
>> 
>>> On 12 Oct 2017, at 15:58, Herby Vojčík  wrote:
>>> 
>>> There are a few fixes out there for Zinc, not to mention convenience like 
>>> ZnEntity class>>  json:. Don't you consider releasing the new version (as I 
>>> tried to update it by hand, it is not that easy, it has more components, to 
>>> load HTTP I had to update Character-Encoding as well, so probably better if 
>>> bumped as a group)?
>>> 
>>> Herby
>> 
>> That's what configurations are for, to track the latest development release 
>> in a consistent way. You just do
>> 
>>   ConfigurationOfZincHTTPComponents project bleedingEdge load.
>> 
>> Provided you loaded a recent configuration.
> 
> I'm nort sure I want the bleeding edge loaded, albeit for recent 
> configuration, for the production code (thought not mission criticial about 
> lives or millions of $$$). Also I don't know if configurations are updated 
> after each change out there (it must be done by hand I presume). So I was 
> asking if there isn't a time to release another stable one.
> 
> If not, and I still want not the true bleeding edge, but a "it works for me" 
> snapshot in time, to load specific version of ConfigurationOf... and the 
> issue ... project bleedingEdge load? Will it load only those version that 
> were bleedingEdge at that time?
> 
>> See the class comment of ConfigurationOfZincHTTPComponents for more info.
>> 
>> Sven

There are only two branches/versions: the latest development branch 
(bleedingEdge, 'head', just all the latest versions of all packages) and 
specific released versions (that get an id that you can refer to). Doing a 
release is a manual process that comes down to fixing the bleedingEdge at a 
moment when I feel it is stable enough.

There are no versions in between releases that you can refer to.

AFAIK this is how most Pharo projects work, it is how I work in all my projects.

Sven

Re: [Pharo-users] FYI about Pharo MOOC

[Stephane Ducasse]

In fact the files have two tracks.


On Fri, Oct 13, 2017 at 8:13 PM, Andrew Glynn  wrote:

> Oh good, glad the French version is still there.  I was starting to go
> through it a couple of weeks ago and plan to continue starting this
> weekend.  Although my mother tongue is English, at one point I was
> fluently bilingual (both Quebecois and actual French), and it's a
> chance to get some of it back while picking up information I've likely
> missed
> on less obvious features.
>
> I can understand French well enough, but the more I hear it spoken
> the better. Reading/writing don't get rusty as easily.
>
> Of course speaking it would be even better, but I don't get many
> chances to do so in Toronto ☺.
>
> Andrew
>
> -Original Message-
>
> Date: Fri, 13 Oct 2017 18:06:17 +0200
> Subject: Re: [Pharo-users] FYI about Pharo MOOC
> To: Any question about pharo is welcome 
> Reply-to: Any question about pharo is welcome  us...@lists.pharo.org>
> From: Stephane Ducasse 
> The production company told us that it was super strange without our
> voices.
> Now you can also have the french + subtitles.
>
> On Fri, Oct 13,
> 2017 at 2:42 PM, Ben Coman  wrote:
>
> I played C019SD-
> W1-S1-EN-V1.mp4
> and as well as the english voice, in the
> background I
> can still hear your
> original french voice.
> I'm curious the
> rea
> soning for
> this.
>
> cheers -ben
>
>
> On Fri, Oct 13, 2017 at 3:59 AM, Stephane Ducasse  haro.s...@gmail.com>
> wrote:
>
> I'm about to release the en versions.
> you can
> find them unofficially on http://www.stephaneducasse.eu/MOOC/
>
> Stef
>
> On
> Tue, Oct 10, 2017 at 10:10 PM, Gour  wrote:
>
> On Tue,
> 10 Oct 2017 21:31:55 +0200
> Stephane Ducasse
> 
> wrote:
>
> Hello Stef,
>
> I will ask one guy thursday and let you know.
>
>
> Thanks a
> lot!
>
> We will release Mooc with english voices (not mine else english
> nati
> ves would get an heart attack - I have what they call a sexy
> french
> accents ;)
>
>
> I did watch few of your Pharo-related presentations and,
> although not
> native,
> happily survived. :-)
>
> Moreover, I'd say that your
> English is charming! At least, one is sure
> that the
> real human is
> speaking and not some "robot" put on auto-pilot, so if the
> new
> Mooc is
> going to be the same as the  current/old one, I'd prefer to
> download
> the
> current files and watched them along with *.srt subtitles?
>
> Iow. my point
> is that the accent is just one part of the talk/teaching,
> but the
> energy
> behind it is much more imporant - this is, my conviction, based
> on my
> own
> teaching experiences.
>
>
> Sincerely,
> Gour
>
> --
> From anger, complete delusion
> arises, and from delusion
> bewilderment of memory. When memory is
> bewildered,
> intelligence is lost, and when intelligence is lost
> one falls
> down again into the material pool.
>
>
>
>
>
>
>

Re: [Pharo-users] FYI about Pharo MOOC

[Andrew Glynn]

Oh good, glad the French version is still there.  I was starting to go
through it a couple of weeks ago and plan to continue starting this
weekend.  Although my mother tongue is English, at one point I was
fluently bilingual (both Quebecois and actual French), and it's a
chance to get some of it back while picking up information I've likely
missed
on less obvious features.

I can understand French well enough, but the more I hear it spoken
the better. Reading/writing don't get rusty as easily.

Of course speaking it would be even better, but I don't get many
chances to do so in Toronto ☺.

Andrew

-Original Message-

Date: Fri, 13 Oct 2017 18:06:17 +0200
Subject: Re: [Pharo-users] FYI about Pharo MOOC
To: Any question about pharo is welcome 
Reply-to: Any question about pharo is welcome 
From: Stephane Ducasse 
The production company told us that it was super strange without our
voices.
Now you can also have the french + subtitles.

On Fri, Oct 13,
2017 at 2:42 PM, Ben Coman  wrote:
> I played C019SD-W1-S1-EN-V1.mp4and as well as the english voice, in
> the
> background Ican still hear youroriginal french voice.I'm curious
> therea
> soning forthis.
> cheers -ben
> 
> On Fri, Oct 13, 2017 at 3:59 AM, Stephane Ducasse  l.com>wrote:
> > I'm about to release the en versions.you canfind them unofficially
> > on http://www.stephaneducasse.eu/MOOC/
> > Stef
> > OnTue, Oct 10, 2017 at 10:10 PM, Gour  wrote:
> > > On Tue,
> > > 10 Oct 2017 21:31:55 +0200
> > > Stephane Ducasse
> > > 
> > > wrote:
> > > 
> > > Hello Stef,
> > > 
> > > > I will ask one guy thursday and let you know.
> > > 
> > > Thanks a
> > > lot!
> > > 
> > > > We will release Mooc with english voices (not mine else english
> > > > nati
> > > > ves would get an heart attack - I have what they call a sexy
> > > > french
> > > > accents ;)
> > > 
> > > I did watch few of your Pharo-related presentations and,
> > > although not
> > > native,
> > > happily survived. :-)
> > > 
> > > Moreover, I'd say that your
> > > English is charming! At least, one is sure
> > > that the
> > > real human is
> > > speaking and not some "robot" put on auto-pilot, so if the
> > > new
> > > Mooc is
> > > going to be the same as the  current/old one, I'd prefer to
> > > download
> > > the
> > > current files and watched them along with *.srt subtitles?
> > > 
> > > Iow. my point
> > > is that the accent is just one part of the talk/teaching,
> > > but the
> > > energy
> > > behind it is much more imporant - this is, my conviction, based
> > > on my
> > > own
> > > teaching experiences.
> > > 
> > > 
> > > Sincerely,
> > > Gour
> > > 
> > > --
> > > From anger, complete delusion
> > > arises, and from delusion
> > > bewilderment of memory. When memory is
> > > bewildered,
> > > intelligence is lost, and when intelligence is lost
> > > one falls
> > > down again into the material pool.
> > > 
> > > 
> > > 

Re: [Pharo-users] Is possible to keep some code closed in Pharo?

[Ricardo Pacheco]

Wow, that sounds great. Thanks a lot!! 

Ricardo



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

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

[Nicolai Hess]

Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" :

I can't remember ever using API docs in *any* language, dynamic or not.
They give you the method signatures, but if you have, say, methodX(int,
int, String), how are you supposed to guess what ints and what String the
method actually needs,


Isn't this exactly what an apidoc is for? Additional documentation to
describe the methods and   arguments purpose.

Maybe you have just seen poorly documented libraries?


One of my favourite language fails can be reproduced by doing this:

Declare a field private final in Java, initializing it either in the
declaration or the constructor, and provide only a getter. Use the getter
from another class and change the value of the local variable. Then use the
getter again, but assign the value to a new local variable, and check the
value.


Maybe you should re-read about javas  final keyword.
It is not to meant making something immutable ,
you can just not reassign a new value.

Java final != c++ const

Re: [Pharo-users] Problem with input to XML Parser - 'Invalid UTF8 encoding'

[Stephane Ducasse]

Tx

On Wed, Oct 11, 2017 at 7:29 AM, monty  wrote:
> I know what the problem is and will have it fixed shortly. Thanks for the 
> report.
>
>> Sent: Monday, October 09, 2017 at 9:03 AM
>> From: "Peter Kenny" 
>> To: pharo-users@lists.pharo.org
>> Subject: Re: [Pharo-users] Problem with input to XML Parser - 'Invalid UTF8 
>> encoding'
>>
>> Correction - I am misrepresenting Sven. What he said was that Zinc would not
>> look inside the HTML  node to find out about coding. It would of
>> course use information in the HTTP headers, if any.
>>
>>
>> Peter Kenny wrote
>> > Henry
>> >
>> > Thanks for the explanations. It's a bit clearer now. I'm still not sure
>> > about how ZnUrl>>retrieveContents manages to decode correctly in this
>> > case;
>> > I'm sure I recall Sven saying it didn't (and in his view shouldn't) look
>> > at
>> > the HTTP declarations in the header. There is also the mystery of how the
>> > string reader in the XML-Parser package (XMLURI>>get) does the same trick,
>> > when it is presumably what XMLHTMLParser>>parseURL: uses and fails.
>> >
>> > However, all these are second order problems. It all begins because the
>> > Corriere web site does strange things with encoding, including using a
>> > UTF8
>> > character in a page coded with 8859-1, as Paul pointed out. In any case,
>> > reading the page as a string and then parsing it solves my problem, so I
>> > shall stick to that as a standard procedure. Most importantly, I don't
>> > think
>> > there is any indication of a problem in the XML package for Monty to worry
>> > about.
>> >
>> > Thanks again
>> >
>> > Peter
>> >
>> >
>> >
>> > --
>> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>>
>

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

[Stephane Ducasse]

epub already works. Now it should be improved.

Doing an pandoc exporter should not be that difficult. If you do it I
will integrate it.

On Fri, Oct 13, 2017 at 12:03 PM, Gour  wrote:
> On Wed, 11 Oct 2017 17:18:54 +
> Dimitris Chloupis 
> wrote:
>
>> Well there is a move towards Pillar for class and method commands so
>> who knows maybe we will have that soon enough ;)
>
> Let me say that I'm very happy seeing that Pillar is moving forward (e.g.
> addition of support for footnotes) as well as plan for the future (*.epub
> support) since I'm considering whether it could serve as single-source markup
> for all of one's writings?
>
> After migrating from Python-powered static-site-generator (to Hugo) and rst
> markup I was considering to use AsciiDoc(tor) markup for all my content, but,
> so far, due to using Emacsm settled to use org-mode instead. Haven't tried 
> with
> slides (yet), but there is Pandoc support for it.
>
> Therefore, I'd rather see Pillar support in Pandoc which would buy us even 
> more
> import/export capabilities for free instead of focusing on single formats like
> *.odt, *.epub etc.
>
> Pillar with 1st class support in Pandoc would, imho, improve status of Pharo
> itself making it along with Pillar exceelent tool for development as well as
> for all writing needs - articles, books, documentation, slide-presentations.
>
> But it would be nice to make it more transparent where/how can one submit
> feature request for Pillar?
>
> Fogbugs issue trakcer is certainly not the ideal place these days...
>
>
> Sincerely,
> Gour
>
> --
> Everyone is forced to act helplessly according to the qualities
> he has acquired from the modes of material nature; therefore no
> one can refrain from doing something, not even for a moment.
>
>
>

Re: [Pharo-users] FYI about Pharo MOOC

[Stephane Ducasse]

The production company told us that it was super strange without our voices.
Now you can also have the french + subtitles.

On Fri, Oct 13, 2017 at 2:42 PM, Ben Coman  wrote:
> I played C019SD-W1-S1-EN-V1.mp4
> and as well as the english voice, in the background I can still hear your
> original french voice.
> I'm curious the reasoning for this.
>
> cheers -ben
>
>
> On Fri, Oct 13, 2017 at 3:59 AM, Stephane Ducasse 
> wrote:
>>
>> I'm about to release the en versions.
>> you can find them unofficially on http://www.stephaneducasse.eu/MOOC/
>>
>> Stef
>>
>> On Tue, Oct 10, 2017 at 10:10 PM, Gour  wrote:
>> > On Tue, 10 Oct 2017 21:31:55 +0200
>> > Stephane Ducasse
>> >  wrote:
>> >
>> > Hello Stef,
>> >
>> >> I will ask one guy thursday and let you know.
>> >
>> > Thanks a lot!
>> >
>> >> We will release Mooc with english voices (not mine else english
>> >> natives would get an heart attack - I have what they call a sexy
>> >> french accents ;)
>> >
>> > I did watch few of your Pharo-related presentations and, although not
>> > native,
>> > happily survived. :-)
>> >
>> > Moreover, I'd say that your English is charming! At least, one is sure
>> > that the
>> > real human is speaking and not some "robot" put on auto-pilot, so if the
>> > new
>> > Mooc is going to be the same as the  current/old one, I'd prefer to
>> > download
>> > the current files and watched them along with *.srt subtitles?
>> >
>> > Iow. my point is that the accent is just one part of the talk/teaching,
>> > but the
>> > energy behind it is much more imporant - this is, my conviction, based
>> > on my
>> > own teaching experiences.
>> >
>> >
>> > Sincerely,
>> > Gour
>> >
>> > --
>> > From anger, complete delusion arises, and from delusion
>> > bewilderment of memory. When memory is bewildered,
>> > intelligence is lost, and when intelligence is lost
>> > one falls down again into the material pool.
>> >
>> >
>> >
>>
>

Re: [Pharo-users] FYI about Pharo MOOC

[Stephane Ducasse]

Superb!

On Fri, Oct 13, 2017 at 5:03 PM, Ricardo Pacheco
 wrote:
> Great, I will have a look at them. I registered to participate in the MOOC
> starting on Oct 16, so look forward to contribute back a bit.
>
> Ricardo
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

Re: [Pharo-users] Is possible to keep some code closed in Pharo?

[Stephane Ducasse]

Hi ricardo

- You can ship pharo without sources. In fact the sources are not used
during execution (just for the human).
- You can ship pharo without debugger. This is one line of code.
- Soon we expect to be able to remove the compiler and the decompiler :).
- You can also control that the commandline does not allow code execution

Now this is not user friendly. We wan with esteban to provide a way to
deploy applications (by opposition of code).
So I can tell you that we want to have a process and tooling to help for that.
I you need help to get you started with Pharo let us know.

stef



On Fri, Oct 13, 2017 at 5:42 PM, Ricardo Pacheco
 wrote:
> IMHO, one important aspect to deliver comercial solutions for customers in an
> environment like Pharo is to be able to protect certain code or algorithms
> developed by the company. It possible to have some clases compiled and
> closed to the eyes of customers? Or it is posible to have some kind of
> access control to edit clases?
>
> A bit of context for my question.
> In the company I work for in Mexico we have been using a similar live coding
> environment for 30 years with great results. The environment we used until a
> couple of years ago is named G2 by Gensym; lisp based internally,  with is
> own natural language like syntax for developers, with a very powerful
> backward ans forwards chaining rule engine, an excellent toolkit to create
> visual components and a wonderful VNC like and lightwaight
> client(Telewindows) that makes visual interactions with a remote G2 very
> easy with a very small bandwidth use. Until a couple of years ago, we
> developed on it tailor made supply chain solutions and mathematical models;
> since then we moved to Java and .NET.
> We wish we could stay with live coding, but the draw back with that platform
> we used is that is really expensive for customers and the company has been
> changing hands to more lawyer oriented owners, because of its installed
> based license fees and IP portfolio. So, getting to know Pharo makes me very
> enthusiastic about the possibility to move back to live coding.
>
> Thanks for the response.
>
> Ricardo
>
>
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

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

[Andrew Glynn]

I can't remember ever using API docs in any language, dynamic or
not.  They give you the method signatures, but if you have, say,
methodX(int, int, String), how are you supposed to guess what ints and
what String the method actually needs, unless the methods are nothing
but getters and setters (which I've never understood the point of)
?  (I know, most give (int somename, int someothername, String
whatever), but how often do are method names well thought through
enough to imply definitively what the method needs?.  
It's my biggest issue with Algol-style syntax - the method caller is
supposed to know how it works, rather than whoever actually wrote
it.  It's probably at least one of the reasons for the amount of OSS in
Java, and more recently in JavaScript (though the latter is more no-
style than Algol-style).  I nearly always download the source to OSS
libs although I rarely ever bother building it, so I know what a method
does with the params, and I can be sure what params to give it.
One of my favourite language fails can be reproduced by doing this: 
Declare a field private final in Java, initializing it either in the
declaration or the constructor, and provide only a getter.  Use the
getter from another class and change the value of the local variable.
Then use the getter again, but assign the value to a new local
variable, and check the value.  
Guess what? The value is whatever you changed it to in your other local
variable, although the API docs claim javac won't compile it. I tested
this with Java 8,  I haven't bothered to see if it was always like that
or if they took the rule out of javac because it interfered with some
syntactic parmesan, such as lambdas.  I should copy my test code into
VisualAge for Java and see if in fact it compiles with JDK 1.4.2, or if
javac was changed in between 4 and 8, since the addition of various
flavours of syntactic parmesan mostly started with Java 5.
Not that it's all that important in one sense.  If 'private' and
'final' were supposed to be guides for other developers to be careful
if they're thinking about changing it, fine, anyone who doesn't isn't
all that good a developer.  But given the number of 'not very good'
developers I've had the misfortune to work with in Java, it's more
problematic than it should be.  It also makes the pattern of a private
field with a public setter even more useless, since the setter isn't
needed to change the value.  I always get dinged by whatever lint
companies use for not bothering with that pattern, though, and pointing
out that declaring the fields public accomplishes exactly the same
thing never helps my case, because whatever lint they use, it has to be
right, there's no way a non-lint developer might be right.
Andrew Glynn
-Original Message-
Date: Wed, 11 Oct 2017 10:01:20 -0500Subject: Re: [Pharo-users] Behold
Pharo: The Modern SmalltalkTo: pharo-users@lists.pharo.orgReply-to: Any
question about pharo is welcome From:
Offray Vladimir Luna Cárdenas 
  

  
  
Yes. I know them. I mean API docs as static files. I don't really
  sold on them compared with a live system and I don't think static
  API docs are critical for Pharo success.
Cheers,
Offray




On 11/10/17 09:52, Dimitris Chloupis
  wrote:



> Ah
>   and my static website was built with Pillar and Bootstrap,
> using
>   bootstrap templates was easy because Pillar supports mustache
> that
>   makes html manipulation much easier 
> 
>   
> 
>   http://www.kilon-alios.com
> 
>   
> 
>   Pillar of course is not made for generating websites but it’s
> an
>   awesome Pharo library that allows for great degree of freedom
> so I
>   thought , why not ?
> 
>   
> On Wed, 11 Oct 2017 at 17:48, Dimitris Chloupis
>    wrote:
> 
> 
> 
> > Docs are
> >   available in static online html format , at least the
> > book I
> >   was working on 
> > 
> >   
> > 
> >   Pharo By Example 
> > 
> >   
> > 
> >   You can find those links here
> > 
> >   
> > 
> >   https://github.com/SquareBracketAssociates/UpdatedPharoBy
> > Example
> > 
> >   
> > 
> >   Our documentation system , Pillar , outputs pdf , html
> > and
> >   markdown files. 
> > 
> >   
> > 
> >   If the book in question is built like PBE with CI of
> > Inria
> >   where most Pharo related official projects are built then
> > it
> >   should have at least pdf and html with online access so
> > you
> >   can easily link to.
> > 
> >   
> > 
> >   Don’t quote me on this but I think the html output of
> > pillar
> >   generate links even for paragraphs you can do an even
> > more
> >   process linking to the documentation. 
> > 
> >   
> > On 

[Pharo-users] Is possible to keep some code closed in Pharo?

[Ricardo Pacheco]

IMHO, one important aspect to deliver comercial solutions for customers in an
environment like Pharo is to be able to protect certain code or algorithms
developed by the company. It possible to have some clases compiled and
closed to the eyes of customers? Or it is posible to have some kind of
access control to edit clases?

A bit of context for my question.
In the company I work for in Mexico we have been using a similar live coding
environment for 30 years with great results. The environment we used until a
couple of years ago is named G2 by Gensym; lisp based internally,  with is
own natural language like syntax for developers, with a very powerful
backward ans forwards chaining rule engine, an excellent toolkit to create
visual components and a wonderful VNC like and lightwaight
client(Telewindows) that makes visual interactions with a remote G2 very
easy with a very small bandwidth use. Until a couple of years ago, we
developed on it tailor made supply chain solutions and mathematical models;
since then we moved to Java and .NET.
We wish we could stay with live coding, but the draw back with that platform
we used is that is really expensive for customers and the company has been
changing hands to more lawyer oriented owners, because of its installed
based license fees and IP portfolio. So, getting to know Pharo makes me very
enthusiastic about the possibility to move back to live coding.

Thanks for the response.

Ricardo



  



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

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

[Esteban A. Maringolo]

You're mixing modularization, namespacing, packaging and parametrization.

If we're speaking about modules/namespaces I rather call them as such,
not Pink Elephant.
Having an agreement on the terms semantic is important for any communication.

To me a module is not a factorization for the bootstrap process nor
the proper packaging to enable partial loading, a module must be
reified as such.

The only Smalltalks I remember had something closer to a module were
VisualSmalltalk and maybe VisualWorks binary parcels can be thought as
modules, but strictly speaking none of them implement modules as such.
Only Modtalk tried to do that, but the project seems defunct now.

Regards,

Esteban A. Maringolo


2017-10-13 12:00 GMT-03:00 Dimitris Chloupis :
> Modularisation is coming whether you like it or not
> its called
>
> Bootstrap
>
> And the more modular the image will get the more will get closer to
> namespaces anyway. So frankly all I have to do is wait and if I can of
> course contribute ;)
>
> You can call it Bootstrap or the Pink Elephant for all I care, in the end
> for me its about having multi layer system. That's all I care.
>
> But you wont get an argument from me the more about the fact that the more
> we wait the harder will get but again, I am not a Bootstrap contributor so I
> have no right to complain. I really admire those people :D
>
> Modularisation for personal project is super easy to do,if you do it from
> the start that is,  its the existing code that is a pain in the hat to
> modularise when until fairly recently even colors were hard coded into the
> IDE.
>
> On Fri, Oct 13, 2017 at 3:55 PM Esteban A. Maringolo 
> wrote:
>>
>> 2017-10-13 5:55 GMT-03:00 Norbert Hartl :
>> >
>> >> Am 13.10.2017 um 10:24 schrieb stephan :
>> >>
>> >> On 13-10-17 09:55, Thierry Goubier wrote:
>> >>> Because namespaces, by essence, come with serious issues. I won't take
>> >>> someone seriously on namespaces until he can cite those faithfully.
>> >>
>> >> Let's start with the misconception that namespaces are about
>> >> modularisation
>> >>
>> > +1
>>
>> +1 to this as well.
>>
>> Having modularization is like having security, very hard to add them
>> later if you didn't include it in the original design.
>>
>> I'm using VisualWorks these days, and I find its namespaces something
>> more of a hassle than a real use.
>>
>> If we could name Classes with a dot, that could solve most of what
>> namespaces are used for in practice: avoiding name colissions.
>> That's why most of the popular frameworks have prefixes like Zn, WA,
>> RB, and so on and so forth. But now I'm used to prefixes, I don't need
>> them. :)
>>
>> Modularity is a different beast, if you look at how some modules work
>> in JS, like AMD, you see that in practice they avoid collisions by
>> importin what they need from a module, and assign it to a "namespace"
>> (it is not, but works as such), so they get modules first, and
>> namespacing later.
>>
>> Regards,
>>
>> Esteban.
>>
>

Re: [Pharo-users] FYI about Pharo MOOC

[Ricardo Pacheco]

Great, I will have a look at them. I registered to participate in the MOOC
starting on Oct 16, so look forward to contribute back a bit.

Ricardo



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

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

[Dimitris Chloupis]

Modularisation is coming whether you like it or not
its called

Bootstrap

And the more modular the image will get the more will get closer to
namespaces anyway. So frankly all I have to do is wait and if I can of
course contribute ;)

You can call it Bootstrap or the Pink Elephant for all I care, in the end
for me its about having multi layer system. That's all I care.

But you wont get an argument from me the more about the fact that the more
we wait the harder will get but again, I am not a Bootstrap contributor so
I have no right to complain. I really admire those people :D

Modularisation for personal project is super easy to do,if you do it from
the start that is,  its the existing code that is a pain in the hat to
modularise when until fairly recently even colors were hard coded into the
IDE.

On Fri, Oct 13, 2017 at 3:55 PM Esteban A. Maringolo 
wrote:

> 2017-10-13 5:55 GMT-03:00 Norbert Hartl :
> >
> >> Am 13.10.2017 um 10:24 schrieb stephan :
> >>
> >> On 13-10-17 09:55, Thierry Goubier wrote:
> >>> Because namespaces, by essence, come with serious issues. I won't take
> >>> someone seriously on namespaces until he can cite those faithfully.
> >>
> >> Let's start with the misconception that namespaces are about
> modularisation
> >>
> > +1
>
> +1 to this as well.
>
> Having modularization is like having security, very hard to add them
> later if you didn't include it in the original design.
>
> I'm using VisualWorks these days, and I find its namespaces something
> more of a hassle than a real use.
>
> If we could name Classes with a dot, that could solve most of what
> namespaces are used for in practice: avoiding name colissions.
> That's why most of the popular frameworks have prefixes like Zn, WA,
> RB, and so on and so forth. But now I'm used to prefixes, I don't need
> them. :)
>
> Modularity is a different beast, if you look at how some modules work
> in JS, like AMD, you see that in practice they avoid collisions by
> importin what they need from a module, and assign it to a "namespace"
> (it is not, but works as such), so they get modules first, and
> namespacing later.
>
> Regards,
>
> Esteban.
>
>

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

[Offray Vladimir Luna Cárdenas]

Hi,

I have created a document in Grafoscopio. The source file is a single
Grafoscopio notebook in STON [1] (~600kb), the output is a single
Pandoc's Markdown file[2] (~500kb), and you can produce the output as a
PDF file like in [3] (~13Mb). Pandoc has a lot of maturity and a
community with a lot of momentum, dedicated mainly to light
documentation. If we have support for Pandoc's Markdown on Pharo, we can
leverage on that knowledge and tools without reinventing the wheel. Of
course using AST and a lot of infrastructure behind Pillar can be used,
without falling in love with its syntax.

[1] http://mutabit.com/repos.fossil/mapeda/doc/tip/mapeda.ston
[2] http://mutabit.com/repos.fossil/mapeda/doc/tip/mapeda.markdown
[3] http://mutabit.com/repos.fossil/mapeda/uv/mapeda.pdf

Cheers,

Offray

On 13/10/17 08:21, H. Hirzel wrote:
> Interoperability with pandoc is desirable
>
> Some people want MSWord documents and they provide input in the form
> of MSWord documents.
> Or LibreOffice ODT.
>
> pandoc handles that well for a subset of MSWord options.
>
> pandoc allows you as well to write a custom output format -- in this
> case Pillar.
>
> E.g. conversion from MSWord docx to Pillar is possible.
>
> It would need somebody to look into the issue of doing some Lua scripting.
> pandoc has Lua embedded for output generation.
>
>
> --Hannes
>
>
> P.S. I will have some time later for Pillar issues (not Lua), but the
> document model and generation of slides. Still open issue on my list
> is rendering Pillar on Morphic, in particular slide.
>
>
> On 10/13/17, Dimitris Chloupis  wrote:
>> Why exporting to latex, html and markdown is not enough for you ?
>>
>> On Fri, Oct 13, 2017 at 1:05 PM Gour  wrote:
>>
>>> On Wed, 11 Oct 2017 17:18:54 +
>>> Dimitris Chloupis 
>>> wrote:
>>>
 Well there is a move towards Pillar for class and method commands so
 who knows maybe we will have that soon enough ;)
>>> Let me say that I'm very happy seeing that Pillar is moving forward (e.g.
>>> addition of support for footnotes) as well as plan for the future (*.epub
>>> support) since I'm considering whether it could serve as single-source
>>> markup
>>> for all of one's writings?
>>>
>>> After migrating from Python-powered static-site-generator (to Hugo) and
>>> rst
>>> markup I was considering to use AsciiDoc(tor) markup for all my content,
>>> but,
>>> so far, due to using Emacsm settled to use org-mode instead. Haven't
>>> tried
>>> with
>>> slides (yet), but there is Pandoc support for it.
>>>
>>> Therefore, I'd rather see Pillar support in Pandoc which would buy us
>>> even
>>> more
>>> import/export capabilities for free instead of focusing on single formats
>>> like
>>> *.odt, *.epub etc.
>>>
>>> Pillar with 1st class support in Pandoc would, imho, improve status of
>>> Pharo
>>> itself making it along with Pillar exceelent tool for development as well
>>> as
>>> for all writing needs - articles, books, documentation,
>>> slide-presentations.
>>>
>>> But it would be nice to make it more transparent where/how can one submit
>>> feature request for Pillar?
>>>
>>> Fogbugs issue trakcer is certainly not the ideal place these days...
>>>
>>>
>>> Sincerely,
>>> Gour
>>>
>>> --
>>> Everyone is forced to act helplessly according to the qualities
>>> he has acquired from the modes of material nature; therefore no
>>> one can refrain from doing something, not even for a moment.
>>>
>>>
>>>
>>>
>

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

[Vitor Medina Cruz]

I completely agree with Ben.

As for Dimitris, I have some points:

There numerous reason why this kind of thinking is fundamental flawed, if
> not completely wrong
>
> 1) How you get people to run in this race ?
>
> 2) What makes you think that people participating in the race doing to get
> first or even finish ?
>
> 3) How you are certain that those barriers are not the very reason people
> participate ?
>
> The fundamental problem is that if you base your assumption that people
> are motivated on avoidance of pain, this is a very popular argument by the
> way, you going to be severely disapointed. From the very first fact that
> there is a 90% chance that right now that you use almost 100% of your time
> one of the worst software to be ever created.
>
> Microsoft Windows.
>
> Of course you can throw claims to me that peope use Windows because that
> is what’s popular and widely available, but then so is MacOS is by far the
> easiest to use OS out there. When you pit Windows vs Macos a such taboo
> subject , fuel to so many flame wars, there is one thing that both sides
> agree on and that is that MacOS is far easier to use , perdiod. The rest of
> the debate which OS is the best is up in the air and frankly not the point
> of my argument.
>

I think you are missing one point here: people get used to Windows, using
windows with all it’s quirks and nonsenses became strong reinforced habits
for most people, and that is something REALLY hard change.

The fact is , we love pain, we love barriers, we love doors that slam into
> our face. We love challange. But only if we find it interesting.
>

See, I think that’s not the point, the point is that people are very
resistant to any change in their habits, so much that’s usually better to
short-circuit into their habits to make a change instead of trying to force
a hard change on them. That is why I think Ben point of view is not flawed
at all, on the contrary, removing barriers is a way to make Pharo seems
more like what people are habituated, short-circuiting peoples habits into
Pharo usage. Withing time, people better understanding of Pharo may trigger
small, but incremental, changes to it’s habits to get the “A-ha!!!” moment
where live code and all wonders of Pharo make sense.

I frankly read very loosely the rest of you answer ( :) :P ), but I get you
are not interested in making Pharo popular rather than get really
interested, open minded people on borad so to make it even more amazing,
but I also disagree here (in part  :) ). There are lot’s of people who
could do better for the community if the entrance were easier, more
popularity could means more opportunity in job field and, in a more
philosophical matter, a way to make the whole current programming field
better. Of course, with more popularity comes disadvantages as well, some
of which you already said, which can be addressed, but if this is price to
pay I personally think it is worth it.

On Fri, Oct 13, 2017 at 4:00 AM, Dimitris Chloupis 
wrote:

>
> That is a familiar path, but still an obstacle for people to get over in
>> trying Pharo - i.e. its a barrier of entry.  I've previously referred to
>> this article by JoelOnSoftware, but to pull out a key part... "Think of
>> these barriers as an obstacle course that people have to run before you can
>> count them as your customers. If you start out with a field of 1000
>> runners, about half of them will trip on the tires; half of the survivors
>> won’t be strong enough to jump the wall; half of those survivors will fall
>> off the rope ladder into the mud, and so on, until only 1 or 2 people
>> actually overcome all the hurdles. With 8 or 9 barriers, everybody will
>> have one non-negotiable deal killer.  This calculus means that eliminating
>> barriers to switching is the most important thing you have to do if you
>> want to take over an existing market, because eliminating just one barrier
>> will likely double your sales. Eliminate two barriers, and you’ll double
>> your sales again."
>>
>>
>
> WARNING LONG POST AHEAD
>
> There numerous reason why this kind of thinking is fundamental flawed, if
> not completely wrong
>
> 1) How you get people to run in this race ?
> 2) What makes you think that people participating in the race doing to get
> first or even finish ?
> 3) How you are certain that those barriers are not the very reason people
> participate ?
>
> The fundamental problem is that if you base your assumption that people
> are motivated on avoidance of pain, this is a very popular argument by the
> way, you going to be severely disapointed. From the very first fact that
> there is a 90% chance that right now that you use almost 100% of your time
> one of the worst software to be ever created.
>
> Microsoft Windows.
>
> Of course you can throw claims to me that peope use Windows because that
> is what's popular and widely available, but then so is MacOS is by far the
> easiest to use OS out there. When you 

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

[H. Hirzel]

Interoperability with pandoc is desirable

Some people want MSWord documents and they provide input in the form
of MSWord documents.
Or LibreOffice ODT.

pandoc handles that well for a subset of MSWord options.

pandoc allows you as well to write a custom output format -- in this
case Pillar.

E.g. conversion from MSWord docx to Pillar is possible.

It would need somebody to look into the issue of doing some Lua scripting.
pandoc has Lua embedded for output generation.


--Hannes


P.S. I will have some time later for Pillar issues (not Lua), but the
document model and generation of slides. Still open issue on my list
is rendering Pillar on Morphic, in particular slide.


On 10/13/17, Dimitris Chloupis  wrote:
> Why exporting to latex, html and markdown is not enough for you ?
>
> On Fri, Oct 13, 2017 at 1:05 PM Gour  wrote:
>
>> On Wed, 11 Oct 2017 17:18:54 +
>> Dimitris Chloupis 
>> wrote:
>>
>> > Well there is a move towards Pillar for class and method commands so
>> > who knows maybe we will have that soon enough ;)
>>
>> Let me say that I'm very happy seeing that Pillar is moving forward (e.g.
>> addition of support for footnotes) as well as plan for the future (*.epub
>> support) since I'm considering whether it could serve as single-source
>> markup
>> for all of one's writings?
>>
>> After migrating from Python-powered static-site-generator (to Hugo) and
>> rst
>> markup I was considering to use AsciiDoc(tor) markup for all my content,
>> but,
>> so far, due to using Emacsm settled to use org-mode instead. Haven't
>> tried
>> with
>> slides (yet), but there is Pandoc support for it.
>>
>> Therefore, I'd rather see Pillar support in Pandoc which would buy us
>> even
>> more
>> import/export capabilities for free instead of focusing on single formats
>> like
>> *.odt, *.epub etc.
>>
>> Pillar with 1st class support in Pandoc would, imho, improve status of
>> Pharo
>> itself making it along with Pillar exceelent tool for development as well
>> as
>> for all writing needs - articles, books, documentation,
>> slide-presentations.
>>
>> But it would be nice to make it more transparent where/how can one submit
>> feature request for Pillar?
>>
>> Fogbugs issue trakcer is certainly not the ideal place these days...
>>
>>
>> Sincerely,
>> Gour
>>
>> --
>> Everyone is forced to act helplessly according to the qualities
>> he has acquired from the modes of material nature; therefore no
>> one can refrain from doing something, not even for a moment.
>>
>>
>>
>>
>

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

[Andrew Glynn]

I agree with you that difficulty is half the fun, assuming you're a
developer - developers solve problems, so if there weren't any we'd be
a bit out of luck.  For myself I've somehow never, in a 26+ year
career, worked on maintaining code. I've only ever written new code. in
fact  I usually wind up with the things nobody, me included, has a clue
of how to do, tending to make them even more difficult.  On a project
last year the 'technical unknowns' could be boiled down from the 5 page
document I was given to one word, 'everything', including what the
customer (the government, unsurprisingly), actually meant by any of the
terms used in the requirements, since even common networking terms like
VPN mean something different to government employees, apparently, than
to anyone else in the world.
It's rewriting the same or incredibly similar rote code because we
start from the same basic point on every project that gets on my
nerves; writing new and often difficult code, or learning new and often
difficult languages, even learning unfamiliar domain specific
terminology, are the reasons I'm still a developer.  Difficulty though
ought to come with a bit of power.  JavaScript can be extremely
difficult, but when it's difficult and the result is that a page widget
appears in the right place, it doesn't feel like much of an
accomplishment.  Electron apps can be difficult, though the difficulty
isn't in writing them, but in building them and getting them to
actually run, especially if you're supporting Mac as well as Windows.
Unless I'm writing a VM (which I haven't done very much of at all) the
difficulties with CLANG, SLANG, along with about a dozen other tools,
just to build a simple application, doesn't feel like much of an
accomplishment either. At least not to me, I guess it does to some
people though.  I have noticed a squeaky wheel effect: technologies
that 'just work' get quickly forgotten, because there aren't 3 million
people on slashdot or wherever asking questions about how to get them
to work. JINI (now Apache River) is a good example (especially in Java,
where not much 'just works'), when the new cars that automagically
connect your cell phone and tablet to their own 4G were designed, they
had to write JINI clients for C and whatever other languages they use,
because that's what does all the automagic.  But not many people even
remember it exists.
One thing I do disagree with you on is that people prefer Windows. It
seems to me that Windows is more popular due to price, and maybe due to
the relative ease of controlling access centrally, more than anything,
and even given the lower prices on (at least as far as obvious specs
go) equivalent machines, I can't think of anyone I know off the top of
my head who would use Windows if they could afford a Mac, and everyone
I know who can, does use one.  I had to write a Mac app for Charles
Schwab that would run on any home Mac (down to G4 based Macs with a
half gig of RAM that could run at best OS X 10.5) with equivalent
features to a Windows app that required 16GB RAM to load and 24GB to
run decently, because the majority of the professional stock traders
who use Windows all day at work have Macs at home (of course they can
largely afford them).  
If I'm not developing or testing I admittedly most often use a Macbook
myself.  I do use Windows on my tablet, since it can run a full version
of Win 10 x64 (not the useless RT version) and therefore nearly any
Windows program.  I won the tablet at HP at the xmas party though, and
with a quad-core Atom CPU and 8GB RAM it's not really an average
tablet. Even then, I only use it if stuck somewhere for a while with
nothing to do. So I have to admit, if I'm not developing I don't enjoy
difficulty much.  Nor do most of the end users I know. 

I do know a few masochists who prefer Linux to Mac, most of whom don't
run a UI.  The few who do use MATE, which while being both ugly and
lacking any notable capabilities, never mind applications, doesn't use
much memory.  Exactly why a third of a GB of RAM is relevant today I'm
not sure, when both Atom and Sublime Text use more memory than Ubuntu,
Kubuntu or OS X for that matter, but they seem to feel it's radically
important.  Sublime Text makes me think of Hegel's definition of The
Sublime: "the night where all cows are black" ☺.

I'll use Linux if my Thinkpad is handier. It runs OEL with KDE, so it's
not difficult (unless you want anything by Adobe, lol), and it's pretty
quick. Though ironically the Macbook is still quicker, though it has
half the RAM and an i7 that's 2 generations older.  
I visited a friend at the IBM lab I used to work at a few months ago,
and since they know me pretty well at security, I had no problem
getting a visitor badge.  Walking through the area where they write
among other things, DB2 UDB, InfoSphere, WebSphere and associated
products, and all of ibm.com I glanced in the cubicles as I went to my
friend's desk, and the majority of the developers were 

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

[Esteban A. Maringolo]

2017-10-13 5:55 GMT-03:00 Norbert Hartl :
>
>> Am 13.10.2017 um 10:24 schrieb stephan :
>>
>> On 13-10-17 09:55, Thierry Goubier wrote:
>>> Because namespaces, by essence, come with serious issues. I won't take
>>> someone seriously on namespaces until he can cite those faithfully.
>>
>> Let's start with the misconception that namespaces are about modularisation
>>
> +1

+1 to this as well.

Having modularization is like having security, very hard to add them
later if you didn't include it in the original design.

I'm using VisualWorks these days, and I find its namespaces something
more of a hassle than a real use.

If we could name Classes with a dot, that could solve most of what
namespaces are used for in practice: avoiding name colissions.
That's why most of the popular frameworks have prefixes like Zn, WA,
RB, and so on and so forth. But now I'm used to prefixes, I don't need
them. :)

Modularity is a different beast, if you look at how some modules work
in JS, like AMD, you see that in practice they avoid collisions by
importin what they need from a module, and assign it to a "namespace"
(it is not, but works as such), so they get modules first, and
namespacing later.

Regards,

Esteban.

Re: [Pharo-users] FYI about Pharo MOOC

[Ben Coman]

I played C019SD-W1-S1-EN-V1.mp4
and as well as the english voice, in the background I can still hear your
original french voice.
I'm curious the reasoning for this.

cheers -ben

On Fri, Oct 13, 2017 at 3:59 AM, Stephane Ducasse 
wrote:

> I'm about to release the en versions.
> you can find them unofficially on http://www.stephaneducasse.eu/MOOC/
>
> Stef
>
> On Tue, Oct 10, 2017 at 10:10 PM, Gour  wrote:
> > On Tue, 10 Oct 2017 21:31:55 +0200
> > Stephane Ducasse
> >  wrote:
> >
> > Hello Stef,
> >
> >> I will ask one guy thursday and let you know.
> >
> > Thanks a lot!
> >
> >> We will release Mooc with english voices (not mine else english
> >> natives would get an heart attack - I have what they call a sexy
> >> french accents ;)
> >
> > I did watch few of your Pharo-related presentations and, although not
> native,
> > happily survived. :-)
> >
> > Moreover, I'd say that your English is charming! At least, one is sure
> that the
> > real human is speaking and not some "robot" put on auto-pilot, so if the
> new
> > Mooc is going to be the same as the  current/old one, I'd prefer to
> download
> > the current files and watched them along with *.srt subtitles?
> >
> > Iow. my point is that the accent is just one part of the talk/teaching,
> but the
> > energy behind it is much more imporant - this is, my conviction, based
> on my
> > own teaching experiences.
> >
> >
> > Sincerely,
> > Gour
> >
> > --
> > From anger, complete delusion arises, and from delusion
> > bewilderment of memory. When memory is bewildered,
> > intelligence is lost, and when intelligence is lost
> > one falls down again into the material pool.
> >
> >
> >
>
>

Re: [Pharo-users] Zinc release?

[Herby Vojčík]

Sven Van Caekenberghe wrote:



On 12 Oct 2017, at 15:58, Herby Vojčík  wrote:

There are a few fixes out there for Zinc, not to mention convenience like ZnEntity 
class>>  json:. Don't you consider releasing the new version (as I tried to 
update it by hand, it is not that easy, it has more components, to load HTTP I had to 
update Character-Encoding as well, so probably better if bumped as a group)?

Herby


That's what configurations are for, to track the latest development release in 
a consistent way. You just do

   ConfigurationOfZincHTTPComponents project bleedingEdge load.

Provided you loaded a recent configuration.


I'm nort sure I want the bleeding edge loaded, albeit for recent configuration, for the production code (thought not mission criticial about lives or millions of $$$). Also I don't know if configurations are updated after each change out there (it must be done by hand I presume). So I was asking if there isn't a time 
to release another stable one.


If not, and I still want not the true bleeding edge, but a "it works for me" 
snapshot in time, to load specific version of ConfigurationOf... and the issue ... 
project bleedingEdge load? Will it load only those version that were bleedingEdge at that 
time?


See the class comment of ConfigurationOfZincHTTPComponents for more info.

Sven

Re: [Pharo-users] How to recover selections in a fastlist after an update

[Steven Costiou]

Hi Ben, sure. 

This is my browser entry point: 

adaptationsBrowser
| browser |
browser := GLMTabulator new.
browser
row: [ :r | 
r
column: #adaptations;
column: #objects;
column: #methods ].
browser row: #diff.
browser transmit
to: #adaptations;
andShow: [ :a :adaptations | self adaptations: adaptations in: a
].
^ browser 

adaptations: adaptations in: composite
| list |
list := composite fastList.
list title: 'Adaptations'.
list display: adaptations.
adaptationsList := list. 

So my problem is that this adaptation list may change overtime. So
periodically the #step method is called, the adaptation collection is
updated and i also call #update to refresh the browser. However, if an
adaptation was selected in the list, then calling #update will reset
this selection. 

Le 2017-10-13 13:33, Ben Coman a écrit :

> On Fri, Oct 13, 2017 at 5:53 PM, Steven Costiou  
> wrote:
> 
>> Hi, 
>> 
>> I am using fastlists in a browser inspired from glmexamples, and when i use 
>> a stepping and that i update the browser (update method) all selections in 
>> lists are lost. 
>> 
>> Is there an automatic way to recover the selections or does it have to be 
>> handled in my code ? If so, i don't understand how to recover my selection, 
>> if i kept the fastlist in a var, doing list selection: myObject does not do 
>> anything. 
>> 
>> Steven.
> Sorry I don't know the answer, I don't know much about this part of Pharo, 
> but I'd like to learn more.  Would it be possible for you to attach a minimal 
> code example, so when an answer does come in, I'll have a chance to learn 
> more about fastlist? 
> 
> cheers -ben

  

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

[Dimitris Chloupis]

I am against the very idea of special syntax. Even python uses special
syntax as nothing more than syntactic sugar to make the code more readable
from the point of view of not everything looking the same. I agree with the
concept of everything being an Object.

I also dont like the idea that we tend to not have a clear cut border
between the IDE and the language/library. Of course I think IDE
functionality as much as namespaces is concerned (within the borders of my
understanding) is essential. But should be seperate and the IDE act mostly
as a visualisation tool and automation tool.

My problem , is that the Pharo operates on a global space , so lets say i
do what I said above I still dont avoid name collisions. Because MyInstance
outside MyModule should diffirent from MyInstance inside MyModule.

It could become possible by masking the names from the user.

So that there is no conflict between

MyModule MyInstance
and
MyModule2 MyInstance

unless you introduce of couse similar to python the optional feature of
collapsing the scope.

We already have Packages which tie in with Metacello, so I was think about
Modules or however we want to call them as a layer between. I am fine with
metacello personally. Its the name collisions that only concerns me and not
forcing me to use unique names. Of course a module can contain other
modules.

I know how to do this for my projects , I would manipulate the IDE into
displaying Modules as a seperate row in System Browswer , Packages will
continue being the the up most container. And for name of a class I would
add the name of the Module to the class , if I wanted to keep supporting
the existing enviroment , but hack it so it appears to the user as 2
seperate things

so for user will see

MyModule MyInsance myMessage:

 but it  Would be for the system
MyModuleMyInstance myMessage:

which would make sense from naming persepctive even to an outsider not
using the module system and would not require for him to install the modue
library
and essentially

MyModule MyInstance
act as you said via Message not understood as a reference to
MyModuleMyInstance . A unary message returning a reference to an instance
or class or other object.

of course you will have a class like ModuleGenerator to handle the
technical details for you

Version control , dependencies and other technicallities would be handled
normally as usually by Metacello with MyModule pointing also to the correct
configuration , baseline, whatever.

At least thats my general idea of it.

On Fri, Oct 13, 2017 at 2:16 PM Thierry Goubier 
wrote:

> Hi Kilon,
>
> then the discussion is a bit different. As your example points out, the
> syntax is already there, but the notion of a module is still open and ties
> into the package management.
>
> I've played a bit with Metacello to have a working "project" concept
> synchronized with Metacello, and I could imagine providing module like
> objects (the baseline itself?) giving access to more generic names instead
> of the internal, prefixed ones.
>
> One suggestion maybe: what about trying it for yourself with one of your
> projects? With a kind of overall class which has the name of the module,
> and automatically adding methods to it (or a #doesNotUnderstand: that
> handles those) for all the classes in the module, removing from the class
> name the prefix? It would allow an experiment, to see how the code looks
> like and if it is understandable, or if a special syntax is necessary.
>
> Thierry
>
>
> 2017-10-13 11:51 GMT+02:00 Dimitris Chloupis :
>
>> to be more specific what I mean because apparently I may know nothing
>> about namespaces , I was talking in terms of Python's module and package
>> system
>>
>> even though python uses special syntax "import" to import a module, a
>> source file, the real functionality is actually a method but of an object
>> dealing with the handling of modules and packages , packages are basically
>> file directories containing mutliple modules
>>
>> as soon as you do the import the syntax is the usual object syntax
>>
>> so
>>
>> Dog.bark()
>>
>> can be anything
>> 1) A class method call, Dog being the class
>> 2) A instance method call, Dog being the instance
>> 3) or a function call, Dog being the function , which is also an object
>> (methods in python are basically function object taking the reference to an
>> instance as first argument, hence why the weird syntax of adding self as
>> first argument when we define instance method) and Dog is the module
>> imported.
>>
>> of course in case (3) you can collapse the module "name" so you can do
>> only bark() if you import via "from Dog import *" which means from module
>> Dog import every object.
>> But from import is frown upon in the python world because obviously it
>> makes it easier to have name collision which is what the module system try
>> to avoid in the first place.
>>
>> So the equivelant of pharo would be
>>
>> MyModule 

Re: [Pharo-users] Pillar

[Gour]

On Fri, 13 Oct 2017 10:43:27 +
Dimitris Chloupis 
wrote:

> Why exporting to latex, html and markdown is not enough for you ?

Well, I usuallyconsider latex/html as more suitable as output formats, while
standard markdown is semantically too poor for input format, but I'll test how
Pillar's outputs are suitable as Pandoc's inputs.


Sincerely,
Gour

-- 
It is far better to discharge one's prescribed duties, even though
faultily, than another's duties perfectly. Destruction in the course
of performing one's own duty is better than engaging in another's
duties, for to follow another's path is dangerous.

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

[Thierry Goubier]

Hi Kilon,

then the discussion is a bit different. As your example points out, the
syntax is already there, but the notion of a module is still open and ties
into the package management.

I've played a bit with Metacello to have a working "project" concept
synchronized with Metacello, and I could imagine providing module like
objects (the baseline itself?) giving access to more generic names instead
of the internal, prefixed ones.

One suggestion maybe: what about trying it for yourself with one of your
projects? With a kind of overall class which has the name of the module,
and automatically adding methods to it (or a #doesNotUnderstand: that
handles those) for all the classes in the module, removing from the class
name the prefix? It would allow an experiment, to see how the code looks
like and if it is understandable, or if a special syntax is necessary.

Thierry


2017-10-13 11:51 GMT+02:00 Dimitris Chloupis :

> to be more specific what I mean because apparently I may know nothing
> about namespaces , I was talking in terms of Python's module and package
> system
>
> even though python uses special syntax "import" to import a module, a
> source file, the real functionality is actually a method but of an object
> dealing with the handling of modules and packages , packages are basically
> file directories containing mutliple modules
>
> as soon as you do the import the syntax is the usual object syntax
>
> so
>
> Dog.bark()
>
> can be anything
> 1) A class method call, Dog being the class
> 2) A instance method call, Dog being the instance
> 3) or a function call, Dog being the function , which is also an object
> (methods in python are basically function object taking the reference to an
> instance as first argument, hence why the weird syntax of adding self as
> first argument when we define instance method) and Dog is the module
> imported.
>
> of course in case (3) you can collapse the module "name" so you can do
> only bark() if you import via "from Dog import *" which means from module
> Dog import every object.
> But from import is frown upon in the python world because obviously it
> makes it easier to have name collision which is what the module system try
> to avoid in the first place.
>
> So the equivelant of pharo would be
>
> MyModule MyInstance myMessage:
>
> or if you include packages as well
>
> MyPackage MyModule MyInstance myMessage:
>
> which follows pharo syntax and OO design. That's my general idea at least.
>
> Please enlighten me :)
>
> On Fri, Oct 13, 2017 at 12:30 PM Dimitris Chloupis 
> wrote:
>
>> On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>> 2017-10-13 10:12 GMT+02:00 Dimitris Chloupis :
>>>
 fair enough you think namespaces are not the right solution, what you
 think is the right solution then ?

>>>
>>> I told you. Namespaces are a solution, but they come with issues.
>>>
>>>
>>
>> Then I misunderstood you but I am geniouly interested in what those
>> problems are and I think the infromation is something others will find
>> interesting as well.
>>
>> No. In the HPC world, a common held position is that Fortran code is 30%
>>> faster than C++.
>>>
>>
>> Cannot even rememeber the last time a 3d graphics developers mentioned
>> Fortran.I occasional frequent forums and mailing lists plus keeping in
>> contact with Blender developers.
>>
>> I have heard that Fortran can outperform C++ in numeric computation
>> around the percentage you mentioned but first time I heard that its
>> generally faster.
>>
>> Language Benchmark seems to strongly disagree
>>
>> http://benchmarksgame.alioth.debian.org/u64q/compare.php?
>> lang=ifc=gpp
>>
>> of its widely criticized but then what benchmark is not
>>
>>
>>> Remember that part of my job is to write compilers.
>>>
>>>
>> I knew that you write compilers (SmaCC) I did not realise you are a pro
>> and especially on ones that generate highly optimised machine code
>>
>>
>>> I'm also consider a guy to talk to when someone has deep issues with
>>> some of the new features of C++... even if I don't do C++, I can often
>>> reframe what the feature means in the overall scheme of programming
>>> languages.
>>>
>>
>> On other hand I have close to zero experience on compilers
>>  .
>>
>>
>>> I find it very interesting. I consider that current compilers are very
>>> good optimising code that is written in a language that obscures the
>>> developper intent in the first place.
>>>
>>
>> I lost you there, you mean compilers for other languages than C++ ?
>>
>> As I told you, I work in a world where performance is paramount and C++
>>> is strongly criticized for the fact its incidental complexity makes it very
>>> very hard to reach or maintain performance levels (compared to Fortran,
>>> say).
>>>
>>> Thierry
>>>
>>>
>>
>> And I "work" in a world that C++ is the undisputed king , that's 3d
>> graphics , though I must admit I 

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

[Dimitris Chloupis]

Why exporting to latex, html and markdown is not enough for you ?

On Fri, Oct 13, 2017 at 1:05 PM Gour  wrote:

> On Wed, 11 Oct 2017 17:18:54 +
> Dimitris Chloupis 
> wrote:
>
> > Well there is a move towards Pillar for class and method commands so
> > who knows maybe we will have that soon enough ;)
>
> Let me say that I'm very happy seeing that Pillar is moving forward (e.g.
> addition of support for footnotes) as well as plan for the future (*.epub
> support) since I'm considering whether it could serve as single-source
> markup
> for all of one's writings?
>
> After migrating from Python-powered static-site-generator (to Hugo) and rst
> markup I was considering to use AsciiDoc(tor) markup for all my content,
> but,
> so far, due to using Emacsm settled to use org-mode instead. Haven't tried
> with
> slides (yet), but there is Pandoc support for it.
>
> Therefore, I'd rather see Pillar support in Pandoc which would buy us even
> more
> import/export capabilities for free instead of focusing on single formats
> like
> *.odt, *.epub etc.
>
> Pillar with 1st class support in Pandoc would, imho, improve status of
> Pharo
> itself making it along with Pillar exceelent tool for development as well
> as
> for all writing needs - articles, books, documentation,
> slide-presentations.
>
> But it would be nice to make it more transparent where/how can one submit
> feature request for Pillar?
>
> Fogbugs issue trakcer is certainly not the ideal place these days...
>
>
> Sincerely,
> Gour
>
> --
> Everyone is forced to act helplessly according to the qualities
> he has acquired from the modes of material nature; therefore no
> one can refrain from doing something, not even for a moment.
>
>
>
>

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

[Cyril Ferlicot]

On ven. 13 oct. 2017 at 12:05, Gour  wrote:

> On Wed, 11 Oct 2017 17:18:54 +
> Dimitris Chloupis 
> wrote:
>
> > Well there is a move towards Pillar for class and method commands so
> > who knows maybe we will have that soon enough ;)
>
> Let me say that I'm very happy seeing that Pillar is moving forward (e.g.
> addition of support for footnotes) as well as plan for the future (*.epub
> support) since I'm considering whether it could serve as single-source
> markup
> for all of one's writings?
>
> After migrating from Python-powered static-site-generator (to Hugo) and rst
> markup I was considering to use AsciiDoc(tor) markup for all my content,
> but,
> so far, due to using Emacsm settled to use org-mode instead. Haven't tried
> with
> slides (yet), but there is Pandoc support for it.
>
> Therefore, I'd rather see Pillar support in Pandoc which would buy us even
> more
> import/export capabilities for free instead of focusing on single formats
> like
> *.odt, *.epub etc.
>
> Pillar with 1st class support in Pandoc would, imho, improve status of
> Pharo
> itself making it along with Pillar exceelent tool for development as well
> as
> for all writing needs - articles, books, documentation,
> slide-presentations.
>
> But it would be nice to make it more transparent where/how can one submit
> feature request for Pillar?


Hi,


I don't have much time so, fast answer:
https://github.com/pillar-markup/pillar/issues



>
> Fogbugs issue trakcer is certainly not the ideal place these days...
>
>
> Sincerely,
> Gour
>
> --
> Everyone is forced to act helplessly according to the qualities
> he has acquired from the modes of material nature; therefore no
> one can refrain from doing something, not even for a moment.
>
>
>
> --
Cyril Ferlicot
https://ferlicot.fr

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

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

[Gour]

On Wed, 11 Oct 2017 17:18:54 +
Dimitris Chloupis 
wrote:

> Well there is a move towards Pillar for class and method commands so
> who knows maybe we will have that soon enough ;)

Let me say that I'm very happy seeing that Pillar is moving forward (e.g.
addition of support for footnotes) as well as plan for the future (*.epub
support) since I'm considering whether it could serve as single-source markup
for all of one's writings?

After migrating from Python-powered static-site-generator (to Hugo) and rst
markup I was considering to use AsciiDoc(tor) markup for all my content, but,
so far, due to using Emacsm settled to use org-mode instead. Haven't tried with
slides (yet), but there is Pandoc support for it.

Therefore, I'd rather see Pillar support in Pandoc which would buy us even more
import/export capabilities for free instead of focusing on single formats like
*.odt, *.epub etc.

Pillar with 1st class support in Pandoc would, imho, improve status of Pharo
itself making it along with Pillar exceelent tool for development as well as
for all writing needs - articles, books, documentation, slide-presentations.

But it would be nice to make it more transparent where/how can one submit
feature request for Pillar?

Fogbugs issue trakcer is certainly not the ideal place these days...


Sincerely,
Gour

-- 
Everyone is forced to act helplessly according to the qualities
he has acquired from the modes of material nature; therefore no
one can refrain from doing something, not even for a moment.

[Pharo-users] How to recover selections in a fastlist after an update

[Steven Costiou]

Hi, 

I am using fastlists in a browser inspired from glmexamples, and when i
use a stepping and that i update the browser (update method) all
selections in lists are lost. 

Is there an automatic way to recover the selections or does it have to
be handled in my code ? If so, i don't understand how to recover my
selection, if i kept the fastlist in a var, doing list selection:
myObject does not do anything. 

Steven. 

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

[Dimitris Chloupis]

to be more specific what I mean because apparently I may know nothing about
namespaces , I was talking in terms of Python's module and package system

even though python uses special syntax "import" to import a module, a
source file, the real functionality is actually a method but of an object
dealing with the handling of modules and packages , packages are basically
file directories containing mutliple modules

as soon as you do the import the syntax is the usual object syntax

so

Dog.bark()

can be anything
1) A class method call, Dog being the class
2) A instance method call, Dog being the instance
3) or a function call, Dog being the function , which is also an object
(methods in python are basically function object taking the reference to an
instance as first argument, hence why the weird syntax of adding self as
first argument when we define instance method) and Dog is the module
imported.

of course in case (3) you can collapse the module "name" so you can do only
bark() if you import via "from Dog import *" which means from module Dog
import every object.
But from import is frown upon in the python world because obviously it
makes it easier to have name collision which is what the module system try
to avoid in the first place.

So the equivelant of pharo would be

MyModule MyInstance myMessage:

or if you include packages as well

MyPackage MyModule MyInstance myMessage:

which follows pharo syntax and OO design. That's my general idea at least.

Please enlighten me :)

On Fri, Oct 13, 2017 at 12:30 PM Dimitris Chloupis 
wrote:

> On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> 2017-10-13 10:12 GMT+02:00 Dimitris Chloupis :
>>
>>> fair enough you think namespaces are not the right solution, what you
>>> think is the right solution then ?
>>>
>>
>> I told you. Namespaces are a solution, but they come with issues.
>>
>>
>
> Then I misunderstood you but I am geniouly interested in what those
> problems are and I think the infromation is something others will find
> interesting as well.
>
> No. In the HPC world, a common held position is that Fortran code is 30%
>> faster than C++.
>>
>
> Cannot even rememeber the last time a 3d graphics developers mentioned
> Fortran.I occasional frequent forums and mailing lists plus keeping in
> contact with Blender developers.
>
> I have heard that Fortran can outperform C++ in numeric computation around
> the percentage you mentioned but first time I heard that its generally
> faster.
>
> Language Benchmark seems to strongly disagree
>
> http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ifc=gpp
>
> of its widely criticized but then what benchmark is not
>
>
>> Remember that part of my job is to write compilers.
>>
>>
> I knew that you write compilers (SmaCC) I did not realise you are a pro
> and especially on ones that generate highly optimised machine code
>
>
>> I'm also consider a guy to talk to when someone has deep issues with some
>> of the new features of C++... even if I don't do C++, I can often reframe
>> what the feature means in the overall scheme of programming languages.
>>
>
> On other hand I have close to zero experience on compilers
>  .
>
>
>> I find it very interesting. I consider that current compilers are very
>> good optimising code that is written in a language that obscures the
>> developper intent in the first place.
>>
>
> I lost you there, you mean compilers for other languages than C++ ?
>
> As I told you, I work in a world where performance is paramount and C++ is
>> strongly criticized for the fact its incidental complexity makes it very
>> very hard to reach or maintain performance levels (compared to Fortran,
>> say).
>>
>> Thierry
>>
>>
>
> And I "work" in a world that C++ is the undisputed king , that's 3d
> graphics , though I must admit I try to stick with Python as much as I can.
>
> In any case my point was that if namespaces can be done in a badly design
> language , should be possible in Pharo and easier. Not ease, just easier.
>
> Of course that's just a wild assumption but I hope this thread do not only
> disaprove my assumption but said a light in the real challanges of
> namespace implementation
>
>

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

[Dimitris Chloupis]

On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier 
wrote:

> 2017-10-13 10:12 GMT+02:00 Dimitris Chloupis :
>
>> fair enough you think namespaces are not the right solution, what you
>> think is the right solution then ?
>>
>
> I told you. Namespaces are a solution, but they come with issues.
>
>

Then I misunderstood you but I am geniouly interested in what those
problems are and I think the infromation is something others will find
interesting as well.

No. In the HPC world, a common held position is that Fortran code is 30%
> faster than C++.
>

Cannot even rememeber the last time a 3d graphics developers mentioned
Fortran.I occasional frequent forums and mailing lists plus keeping in
contact with Blender developers.

I have heard that Fortran can outperform C++ in numeric computation around
the percentage you mentioned but first time I heard that its generally
faster.

Language Benchmark seems to strongly disagree

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ifc=gpp

of its widely criticized but then what benchmark is not


> Remember that part of my job is to write compilers.
>
>
I knew that you write compilers (SmaCC) I did not realise you are a pro and
especially on ones that generate highly optimised machine code


> I'm also consider a guy to talk to when someone has deep issues with some
> of the new features of C++... even if I don't do C++, I can often reframe
> what the feature means in the overall scheme of programming languages.
>

On other hand I have close to zero experience on compilers
 .


> I find it very interesting. I consider that current compilers are very
> good optimising code that is written in a language that obscures the
> developper intent in the first place.
>

I lost you there, you mean compilers for other languages than C++ ?

As I told you, I work in a world where performance is paramount and C++ is
> strongly criticized for the fact its incidental complexity makes it very
> very hard to reach or maintain performance levels (compared to Fortran,
> say).
>
> Thierry
>
>

And I "work" in a world that C++ is the undisputed king , that's 3d
graphics , though I must admit I try to stick with Python as much as I can.

In any case my point was that if namespaces can be done in a badly design
language , should be possible in Pharo and easier. Not ease, just easier.

Of course that's just a wild assumption but I hope this thread do not only
disaprove my assumption but said a light in the real challanges of
namespace implementation

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

[Dimitris Chloupis]

"Let's start with the misconception that namespaces are about modularisation

Stephan "

  Well I can only for speak for Python because is where I used  namespaces
the most and the language I am most experienced with. Namespaces in python
are merely objects that come with a collection of method speciallised in
the handling of source code files , individuals and in collection with all
the objects contained in them , cause everything in python apart from the
core synstax are object.

Last time I checked, objects even in Pharo are abour modularistation so it
stands to reason that at least in Python namespaces are too.

Maybe your refer to something else ?

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

[Norbert Hartl]

> Am 13.10.2017 um 10:24 schrieb stephan :
> 
> On 13-10-17 09:55, Thierry Goubier wrote:
>> Because namespaces, by essence, come with serious issues. I won't take
>> someone seriously on namespaces until he can cite those faithfully.
> 
> Let's start with the misconception that namespaces are about modularisation
> 
+1

Norbert

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

[Thierry Goubier]

2017-10-13 10:12 GMT+02:00 Dimitris Chloupis :

> fair enough you think namespaces are not the right solution, what you
> think is the right solution then ?
>

I told you. Namespaces are a solution, but they come with issues.


>
> As much I hate C++ , no I will have to disagree with your there, bad
> language design sure, but many of the "bad design" choices they make are
> based on the fact that this is a pure performance orientated language. Oh
> and we still wait for the real C++ alternative. Rust people claim they are
> close, D people claim they are close, everyone claims its very close, but
> still no alternative. Well I dont count C becaue its not OO, even if you
> claim C++ an abomination of OOP. I can guarantee that the dude that will
> come up with a language as fast as C++ and much better design he is going
> to make a fortune. In the mean time , those that have to use C++ will
> continue to use C++ and wait for the extemely remote competition to catch
> up. In the mean time C++ is the undisputed king in its speciality.
>

No. In the HPC world, a common held position is that Fortran code is 30%
faster than C++.

Remember that part of my job is to write compilers.

I'm also consider a guy to talk to when someone has deep issues with some
of the new features of C++... even if I don't do C++, I can often reframe
what the feature means in the overall scheme of programming languages.


>
> Unfortunately coming up with a top performance language is a lot more than
> language design, live coding and OOP. Took ages for C and C++ to get to the
> level of optimisation they are nowdays. That's no easy feat even if you or
> I dont find interesting.
>

I find it very interesting. I consider that current compilers are very good
optimising code that is written in a language that obscures the developper
intent in the first place.


>
> So yes the modules that C++ will come up with, will be as ugly as hell,
> templates that suppose to be there as an alternative to dynamic typing etc
> are ugly as hell, but I dont see much protest in getting them removed. And
> there cases you cannot even use these "improvements" because ... well
> performance issues. While other languages worry how many times slower they
> are compared to C++, C++ worries about how much percentage of performance
> it loses with each added feature. C++ exits in a diffirent universe than
> the one that Smalltalk, Python, Ruby etc exist on and is a very lonely one.
>

As I told you, I work in a world where performance is paramount and C++ is
strongly criticized for the fact its incidental complexity makes it very
very hard to reach or maintain performance levels (compared to Fortran,
say).

Thierry


>
> On Fri, Oct 13, 2017 at 10:55 AM Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> Hi Kilon,
>>
>> disclaimer: I've used Parcplace Smalltlk without namespaces, then
>> VisualWorks with namespaces.
>>
>> 2017-10-13 9:08 GMT+02:00 Dimitris Chloupis :
>>
>>> Personally I dont get it, we find the path to bootstrap the pharo image
>>> clear and we cannot see the path to namespaces ?
>>>
>>
>> Because namespaces, by essence, come with serious issues. I won't take
>> someone seriously on namespaces until he can cite those faithfully.
>>
>>
>>>
>>> it makes zero sense to me
>>>
>>> Plus what you say, countless and countless of implementation of
>>> namespaces out there. And again what you say about perfection.
>>>
>>> If C++ can improve, If C++ can dream of namespaces planning the
>>> introduction of modules(in future version) in replacement (not removal) of
>>> his awful header file format I think we got the excuse to be confident
>>> we can come up with something decent.
>>>
>>
>> C++ is about adding incidental complexity to the development process,
>> i.e. how to make something complex where it could be done in a simpler way.
>>
>> So I'd be very wary of any innovation coming from that direction.
>>
>>
>>>
>>> We develop a freaking IDE for crying out loud.
>>>
>>> No it wont be a walk in the park, no it wont get done in one or next
>>> version, and no it cannot be an individual our outside effort. But we have
>>> the community super qualified to do it.
>>>
>>
>> And qualified enough maybe to also see it doesn't make that much of sense.
>>
>> Please remember that the design of a programming language consists not
>> just in a laundry list of features, but also in making judicious choices of
>> what to *omit* and, more importantly, in establishing design principles
>> that are easy to understand [Steele, 2003]
>>
>> Thierry
>>
>>
>>> On Fri, Oct 13, 2017 at 8:51 AM Ben Coman  wrote:
>>>
 On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris <
 s...@clipperadams.com> wrote:

> horrido wrote
> > Having separate namespaces would be really good.
> > VisualWorks has them. Why not Pharo?
>
> I can't remember ever hearing disagreement on this subject. It 

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

[stephan]

On 13-10-17 09:55, Thierry Goubier wrote:

Because namespaces, by essence, come with serious issues. I won't take
someone seriously on namespaces until he can cite those faithfully.


Let's start with the misconception that namespaces are about modularisation

Stephan

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

[Christophe Demarey]

Hi Ben,

> Le 13 oct. 2017 à 06:20, Ben Coman  a écrit :
> 
> On Thu, Oct 12, 2017 at 3:43 PM, Christophe Demarey 
> > wrote:
> Hi Vitor,
> 
>> Le 11 oct. 2017 à 13:44, Vitor Medina Cruz > > a écrit :
>> 
>> Hi Christophe,
>> 
>> Yes, but:
>> 1- I can’t execute it if I don’t have administrative rights
>> 
> 
> ok. That the point I missed.
> I think I will add a zip file with PharoLauncher for windows for user like 
> you not having admin rights.
> 
> Might this be a "portable" app, where downloaded images and VMs are stored 
> next to the PharoLancher application, configured by a startup-setting file?
> 
> 
> Alternatively...
> searching around I found this...
> https://stackoverflow.com/questions/18990418/nsis-require-admin-permission 
> 
> https://github.com/NSIS-Dev/Documentation/blob/master/Reference/RequestExecutionLevel.md
>  
> 

Good catch. probably by using RequestExecutionLevel = highest should solve the 
problem.

> Also, when PharoLauncher is installed by an administrator and later used by a 
> standard user, I guess there may be problems with Pharo needing to write 
> changes to a restricted location??   Maybe that can be dealt with by... when 
> a new user runs PharoLauncher from the start menu, copy it to their user 
> folder $LocalAppdata\Programs\PharoLauncher
> and run PharoLauncher from there where they have privilege to write? 
> https://stackoverflow.com/questions/31641818/install-application-files-to-standard-windows-user-using-nsis
>  
> 

Yes, you could have problems but I do not think that adding more complexity to 
the installer is the way to go. I would rather prefer, in preference order:
1/ Pharo Launcher do not need to write data,
2/ if files need to be written, they should go to a Pharo data folder (e.g. 
$LocalAppdata\Programs\PharoLauncher) or to the user apps setting folder.

What I would like is that a Pharo image writes data where it should

> 
> btw, where are the NSIS source files accessible? 

https://github.com/pharo-project/pharo-build-scripts/tree/master/windows-installer

> Can they be dropped in the PharoLauncher git repo?

No because they are shared and used with other Pharo build scripts.

Thanks for the information.
Cheers,
Christophe

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

[Thierry Goubier]

Hi Kilon,

disclaimer: I've used Parcplace Smalltlk without namespaces, then
VisualWorks with namespaces.

2017-10-13 9:08 GMT+02:00 Dimitris Chloupis :

> Personally I dont get it, we find the path to bootstrap the pharo image
> clear and we cannot see the path to namespaces ?
>

Because namespaces, by essence, come with serious issues. I won't take
someone seriously on namespaces until he can cite those faithfully.


>
> it makes zero sense to me
>
> Plus what you say, countless and countless of implementation of namespaces
> out there. And again what you say about perfection.
>
> If C++ can improve, If C++ can dream of namespaces planning the
> introduction of modules(in future version) in replacement (not removal) of
> his awful header file format I think we got the excuse to be confident
> we can come up with something decent.
>

C++ is about adding incidental complexity to the development process, i.e.
how to make something complex where it could be done in a simpler way.

So I'd be very wary of any innovation coming from that direction.


>
> We develop a freaking IDE for crying out loud.
>
> No it wont be a walk in the park, no it wont get done in one or next
> version, and no it cannot be an individual our outside effort. But we have
> the community super qualified to do it.
>

And qualified enough maybe to also see it doesn't make that much of sense.

Please remember that the design of a programming language consists not just
in a laundry list of features, but also in making judicious choices of what
to *omit* and, more importantly, in establishing design principles that are
easy to understand [Steele, 2003]

Thierry


> On Fri, Oct 13, 2017 at 8:51 AM Ben Coman  wrote:
>
>> On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris 
>> wrote:
>>
>>> horrido wrote
>>> > Having separate namespaces would be really good.
>>> > VisualWorks has them. Why not Pharo?
>>>
>>> I can't remember ever hearing disagreement on this subject. It seems the
>>> only questions have been: 1) how to do them *right*,
>>
>>
>> The default position would be leveraging someone else's experience, so
>> this begs the question, what is wrong in namespace implementations in VW,
>> Gemstone, Squeak (as our immediate neighbours, then plus Dolphin,
>> SmalltalkX, other languages)
>> Are there been any research papers around comparing these?
>>
>> I found the "Pharo on Gemstone VM" talk impressive.  The "develop on
>> Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's
>> commercial future.  So a naive approach would be to do namespaces just like
>> Gemstone.  Maybe its not the best, but would it be "good enough" --
>> perfection being the enemy of done and all that jazz.
>>
>> cheers -ben
>>
>>
>>> and 2) where they fall on the endless prioritized todo list
>>>
>>

Re: [Pharo-users] "Building-With versus Building-on"

[Thierry Goubier]

Hi Andrew, Stephane,

thanks for the read. It was interesting, albeit a bit confusing at times. I
do like your evaluation of the thesis.

2017-10-12 23:10 GMT+02:00 Stephane Ducasse :

> Thanks Andrew I read it fast and I will reread it. It is really
> interesting to me because I never took the time to understand "worse
> is better".
>

Reading through "worse is better", and the follow-up "worse is better is
worse" by the same author, I'm not sure there is much to understand ;)

Apart if you want to study how a misunderstood quote can become a driving
force in software development...

Thierry


>
> On Thu, Oct 12, 2017 at 5:50 PM, Andrew Glynn  wrote:
> > https://medium.com/@dasein42/building-with-versus-building-
> on-c51aa3034c71
> >
> >
> > This is an article not specifically about Pharo, rather on the state of
> the
> > industry
> > in general and how it got that way, but positing Pharo as a way to learn
> > building-on rather than building-with, where in the latter case on
> > every project you start at essentially the same place.
> >
> >
> > As a result it does put in front of people a fair amount of info on
> Pharo,
> > and challenges them to try it.
> >
> >
> > cheers
> >
> > Andrew Glynn
>
>

Re: [Pharo-users] "Building-With versus Building-on"

[Dimitris Chloupis]

What is a VA Java ? and a VA C++ ?

Call me an idiot or insane but I am in favor of combiding languages, though
I only have heard of COBRA never used it.

I am a lawyer by profession, I know fellow lawyers still using DOS and
QBasic databases and yes under windows .. sadly very common for
businesses here. Ah the pleasures of technology but nothing comes close to
the pleasure of rejecting it.

On Fri, Oct 13, 2017 at 12:49 AM Andrew Glynn  wrote:

> I know about personalization being a lot of work, particularly with
> Eclipse.  I copied the text out of the ‘summary’ page in About Eclipse into
> Kate, and it was 1233 lines long, lol.
>
>
>
> I was one of two team leads on what was probably the most complex
> application I’ve worked on, using VA Java and VA C++ with CORBA to exchange
> objects (the need to combine both was due to legacy issues).  Siemens now
> owns the application, which was successful enough to bankrupt its closest
> competitor, but the binary jars in the latest version are still dated 2002,
> and every addition has been made via .the WS* API we included, which if I
> remember correctly, uses version 1.x of WebSphere.  I’m a bit surprised it
> still runs at all tbh, but its security must be horrible by now.
>
>
>
> Eclipse’s only saving grace is EMF/CDO, and a few projects built on them,
> IMHO.
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Dimitris Chloupis 
> *Sent: *Thursday, October 12, 2017 2:05 PM
> *To: *Any question about pharo is welcome 
> *Subject: *Re: [Pharo-users] "Building-With versus Building-on"
>
>
>
> It's a mentality issue, modern programming languages provide the material
> necessary to create innovative environments but their communities just
> simply does not care. A language designer may introduce a feature in a
> language that is super useful. Still people may not use it.
>
>
>
> And let's face it even with Pharo nothing beats a personalized
> environment, of course personalisation is a lot of work. Hence why people
> avoid it.
>
>
>
> Essentially boiling down to cooking your own food instead of getting it
> from a shop. When you begin to learn how to cook , its kinda sucks, but the
> more you cook the better it tastes. Of course it takes time to get there
> and hence why so few people cook.
>
>
>
> Eclispe , which I will disagree with your that is not the worst IDE,
> started as a smalltalk IDE and then it got Eclipsed. I am sure those people
> had a "build on" environment , still it got messy. We can blame porting to
> Java, but can we really blame Java for the mess that is called
> "Eclipse" e nope.
>
>
>
> I once saw a youtube video about a musician using windows sounds (the
> standard sounds we all know of) to make  a very nice music piece. He did
> all that using multiple instances of windows media player. Just pause
> reading think about this for a minute. That's the real essence of creativity
>
>
>
> Use something very limited and come up with something amazing. The
> software industry is not about creativity for the most part. On the other
> hand I that work with 3d its amazing how fast super cool new technologies
> pop around like mushrooms. Every year we have massive improvements in
> libraries and tools. But the coding for 3d graphics is all about creativity
> , artists are not very forgiving for ugly GUI, limited features and
> innovation stagnation. Artists want to be inspired by the tools they use.
> But then that's the creativity realm. Creativity pays the bills in this
> case, lack of it , game is not fun, rendering or animation is not fun, you
> can lose millions.
>
>
>
> Of course in the creativity realm , there is too much innovation and
> unless you keep up you are kicked out the door, yesterday. Which brings
> down to the problem of complexity and how you deal with it. And I don't
> mean about bad complexity , aka web dev, I am talking about good
> complexity. Features you cannot ignore because other will use before you
> and you are left behind etc.
>
>
>
>
>
> On Thu, Oct 12, 2017 at 7:13 PM Peter Fisk  wrote:
>
> Thanks for posting this.
>
>
>
> It is one of the best descriptions of the state of the software industry
> that I have seen.
>
>
>
>
>
> On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn  wrote:
>
> https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71
>
>
>
> This is an article not *specifically* about Pharo, rather on the state of the 
> industry
> in general and how it got that way, but positing Pharo as a way to learn
> building-*on* rather than building-*with*, where in the latter case on
> every project you start at essentially the same place.
>
>
>
> As a result it does put in front of people a fair amount of info on Pharo,
> and challenges them to try it.
>
>
>
> cheers
>
> Andrew Glynn
>
>
>
>
>

Re: [Pharo-users] FYI about Pharo MOOC

[Dimitris Chloupis]

I could help with the Greek subtitles but I am fundamental against the idea
of learning anything code wise in a non english language. It does much more
damage than good. Congrats for making it so accessible and all your hard
work :)

On Fri, Oct 13, 2017 at 9:42 AM Gour  wrote:

> On Thu, 12 Oct 2017 21:59:53 +0200
> Stephane Ducasse
>  wrote:
>
> > I'm about to release the en versions.
> > you can find them unofficially on http://www.stephaneducasse.eu/MOOC/
>
> I've downloaded one and can I safelyassume that the 'new' videos are same
> content as the old ones jsut with the English voice dubbed over?
>
> In that case, I'd prefer to use/watch old ones with the subtitles.
>
>
> Sincerely,
> Gour
>
> --
> He who is satisfied with gain which comes of its own accord, who
> is free from duality and does not envy, who is steady in both
> success and failure, is never entangled, although performing actions.
>
>
>
>

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

[Dimitris Chloupis]

Personally I dont get it, we find the path to bootstrap the pharo image
clear and we cannot see the path to namespaces ?

it makes zero sense to me

Plus what you say, countless and countless of implementation of namespaces
out there. And again what you say about perfection.

If C++ can improve, If C++ can dream of namespaces planning the
introduction of modules(in future version) in replacement (not removal) of
his awful header file format I think we got the excuse to be confident
we can come up with something decent.

We develop a freaking IDE for crying out loud.

No it wont be a walk in the park, no it wont get done in one or next
version, and no it cannot be an individual our outside effort. But we have
the community super qualified to do it.

On Fri, Oct 13, 2017 at 8:51 AM Ben Coman  wrote:

> On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris 
> wrote:
>
>> horrido wrote
>> > Having separate namespaces would be really good.
>> > VisualWorks has them. Why not Pharo?
>>
>> I can't remember ever hearing disagreement on this subject. It seems the
>> only questions have been: 1) how to do them *right*,
>
>
> The default position would be leveraging someone else's experience, so
> this begs the question, what is wrong in namespace implementations in VW,
> Gemstone, Squeak (as our immediate neighbours, then plus Dolphin,
> SmalltalkX, other languages)
> Are there been any research papers around comparing these?
>
> I found the "Pharo on Gemstone VM" talk impressive.  The "develop on Pharo
> deploy on Gemstone" philosophy seems like a nice synergy for Pharo's
> commercial future.  So a naive approach would be to do namespaces just like
> Gemstone.  Maybe its not the best, but would it be "good enough" --
> perfection being the enemy of done and all that jazz.
>
> cheers -ben
>
>
>> and 2) where they fall on the endless prioritized todo list
>>
>

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

[Dimitris Chloupis]

> That is a familiar path, but still an obstacle for people to get over in
> trying Pharo - i.e. its a barrier of entry.  I've previously referred to
> this article by JoelOnSoftware, but to pull out a key part... "Think of
> these barriers as an obstacle course that people have to run before you can
> count them as your customers. If you start out with a field of 1000
> runners, about half of them will trip on the tires; half of the survivors
> won’t be strong enough to jump the wall; half of those survivors will fall
> off the rope ladder into the mud, and so on, until only 1 or 2 people
> actually overcome all the hurdles. With 8 or 9 barriers, everybody will
> have one non-negotiable deal killer.  This calculus means that eliminating
> barriers to switching is the most important thing you have to do if you
> want to take over an existing market, because eliminating just one barrier
> will likely double your sales. Eliminate two barriers, and you’ll double
> your sales again."
>
>

WARNING LONG POST AHEAD

There numerous reason why this kind of thinking is fundamental flawed, if
not completely wrong

1) How you get people to run in this race ?
2) What makes you think that people participating in the race doing to get
first or even finish ?
3) How you are certain that those barriers are not the very reason people
participate ?

The fundamental problem is that if you base your assumption that people are
motivated on avoidance of pain, this is a very popular argument by the way,
you going to be severely disapointed. From the very first fact that there
is a 90% chance that right now that you use almost 100% of your time one of
the worst software to be ever created.

Microsoft Windows.

Of course you can throw claims to me that peope use Windows because that is
what's popular and widely available, but then so is MacOS is by far the
easiest to use OS out there. When you pit Windows vs Macos a such taboo
subject , fuel to so many flame wars, there is one thing that both sides
agree on and that is that MacOS is far easier to use , perdiod. The rest of
the debate which OS is the best is up in the air and frankly not the point
of my argument.

The fact is , we love pain, we love barriers, we love doors that slam into
our face. We love challange. But only if we find it interesting.

Of course Windows is not the only example  (C/C++ , Java , Web dev,
computer games and the list is just endless)of the machocistic nature of
human beings. I dont need to look far, my own story about how I started
coding is more than enough . I am going to ramble about my initiation to
the realm of coding , so feel free to ignore the rest of my post but what
the hell here we go.

>From an early age , no idea when, I was exposed to the idea of the
computer. Never used one before or saw on in person other than what I saw
in the TV I asked my father to get me one and he agreed on the ground that
I wont use it just to play games but to learn how to code. My father had no
idea what coding is, had no idea what technology is, to this day he hates
technology and he refuses to learn even how to close a window. None ,
friend , relative or random stranger I knew used a computer.

So I got this weird thing called computer and turned it on, of course
motivated to play games like any other kind in my age, I was 9 years old at
the time, december 1988. But I had a sense of honor even from that age so I
had to keep my promise. So I did and I was fascinated by it, to the degree
that I was coding as much I was playing games. Problem is that it was
mainly masochistic venture. I had one book and one book alone, none that
had any clue how to show how to turn this thing on and of course no
internet, no schools, no magazines I could afford to buy or even know where
to buy them . So in 3 years, I made nothing special, only tiny fragments of
code and I was still struggling with basic concept like looping.

Yes, looping.

 But I already was doing things that a greek kid did not suppose to do and
I did not even fit the geek stereotype at the time (not that the term
existed at the time, I still does not exist in my language), I had tons of
friends, I was anything but shy , I was the craziest nosiest kid suffering
from the annoying syndrom of hyperactivity and with very lmited attention
span.

I was the absolute worst candidate to learn how to code, yet I did . Sort
of. Then my father decided to send me, after me begging on my knees, on a
prrivate school, that just opened near our neighborhood for learning. At
the time time I only still had the same computer, Amstrad CPC 6128 and knew
the very basics of Locomotive Basic which was used also by the computer as
a bash like language for its OS.

I went 3 years, the first year I did ok, an average student even though I
had by far the most experience than other kids we learned GWBASIC. The
second year I did terrible, we learned DBASE and the third we learned
CLIPPER and blow any other student completely away, I 

Re: [Pharo-users] FYI about Pharo MOOC

[Gour]

On Thu, 12 Oct 2017 21:59:53 +0200
Stephane Ducasse
 wrote:

> I'm about to release the en versions.
> you can find them unofficially on http://www.stephaneducasse.eu/MOOC/

I've downloaded one and can I safelyassume that the 'new' videos are same
content as the old ones jsut with the English voice dubbed over?

In that case, I'd prefer to use/watch old ones with the subtitles.


Sincerely,
Gour

-- 
He who is satisfied with gain which comes of its own accord, who
is free from duality and does not envy, who is steady in both
success and failure, is never entangled, although performing actions.

Re: [Pharo-users] FYI about Pharo MOOC

[Stephane Ducasse]

Hello

It would be super great :)
the files are in the github repo
https://github.com/SquareBracketAssociates/PharoMooc/tree/master/Subtitles

Stef

On Fri, Oct 13, 2017 at 1:25 AM, Ricardo Pacheco
 wrote:
> Hello Stephane, I can help with the Spanish subtitles. You can send me a file
> with the text, if you have it. My french is basic so please send also the
> English fil, to double check.
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>