[Pharo-users] 2019: Call for Papers & Call for Workshop Proposals

[Fabio Niephaus]

 2019 : The Art, Science, and Engineering of Programming

April 1-4, 2019, Genova, Italy
http://2019.programming-conference.org

The International Conference on the Art, Science, and Engineering of
Programming is a new conference focused on programming topics including the
experience of programming. We have named it  for short.
 seeks for papers that advance knowledge of programming on any
relevant topic, including programming practice and experience.
Paper submissions and publications are handled by the the Art, Science, and
Engineering of Programming journal (http://programming-journal.org).
Accepted papers must be presented at the conference.


  CALL FOR PAPERS


 2019 accepts scholarly papers that advance knowledge of
programming. Almost anything about programming is in scope, but in each
case there should be a clear relevance to the act and experience of
programming.

PAPER SUBMISSIONS: June 1, 2018
URL FOR SUBMISSIONS: http://programming-journal.org/submission/

Submissions covering several areas of expertise are accepted, including but
not limited to:

• General-purpose programming
• Distributed systems programming
• Parallel and multi-core programming
• Graphics and GPU programming
• Security programming
• User interface programming
• Database programming
• Visual and live programming
• Data mining and machine learning programming
• Interpreters, virtual machines and compilers
• Modularity and separation of concerns
• Model-based development
• Metaprogramming and reflection
• Testing and debugging
• Program verification
• Programming education
• Programming environments
• Social coding


  CALL FOR WORKSHOP PROPOSALS


To build a community and to foster an environment where participants can
exchange ideas and experiences related to practical software development,
 will host a number of workshops, during the days before the
main conference. The workshops will provide a collaborative forum to
exchange recent and/or preliminary results, to conduct intensive
discussions on a particular topic, or to coordinate efforts between
representatives of a technical community. They are intended as a forum for
lively discussion of innovative ideas, recent progress, or practical
experience on programming and applied software development in general for
specific aspects, specific problems, or domain-specific needs. We also
encourage practical, hands-on workshops in which participants actually
experience one or several aspects of practical software development.

WORKSHOP PROPOSAL SUBMISSIONS:
First Deadline: July 1st, 2018
Second Deadline: September 1st, 2018

The duration of workshops is in general one day, but we encourage the
submission of half-day workshop proposals on focused topics as well. In
exceptional situations, e.g., for workshops that involve actual practice of
programming-related activities, workshop organizers can request a 2 day
workshop slot. If desired, the workshop proceedings can be published in the
ACM Digital Library.


  IMPORTANT DATES


Research paper submissions: June 1, 2019
Research paper first notifications: August 1, 2018
Research paper final notifications: September 7, 2018

Workshop proposals: July 1st, 2018 (first deadline)
Workshop proposals: September 1st, 2018 (second deadline)



  ORGANIZATION


General Chair:
Davide Ancona, University of Genova

Local Organizing Chair:
Elena Zucca, University of Genova

Program Chair:
Matthew Flatt, University of Utah


Organizing Committee:

Walter Cazzola (Workshops Co-Chair), Università degli Studi di Milano
Stefan Marr (Workshops Co-Chair), University of Kent
Fabio Niephaus (Publicity Co-Chair), Hasso Plattner Institute, University
of Potsdam
Tobias Pape (Web Technology Chair), Hasso Plattner Institute, University of
Potsdam


Program Committee:

Mehdi Bagherzadeh, Oakland University
Walter Cazzola, Università degli Studi di Milano
Ravi Chugh, University of Chicago
Joeri De Koster, Vrije Universiteit Brussel
Christos Dimoulas, Northwestern University
Susan Eisenbach, Imperial College London
Richard P. Gabriel, Dream Songs, Inc. & HPI
Jeremy Gibbons, University of Oxford
Michael Greenberg, Pomona College
Philipp Haller, KTH Royal Institute of Technology
Robert Hirschfeld, HPI, University of Potsdam
Eunsuk Kang, Carnegie Mellon University
Stephen Kell, University of Cambridge
Stefan Marr, University of Kent
Tamara Rezk, Inria
Joshua Sunshine, Carnegie Mellon University
Steffen Zschaler, King's College London



 2019 is kindly supported by A

Re: [Pharo-users] reading from a named pipe in Pharo

[Siemen Baader]

Wow, thanks for your help, Alistair! I'll try it out.

cheers,
Siemen


On Sun, May 6, 2018 at 7:47 PM, Alistair Grant 
wrote:

> Hi Siemen & Mariano,
>
> On 5 May 2018 at 16:26, Mariano Martinez Peck 
> wrote:
> > Hi Siemen,
> >
> > You may want to check the pipe support code in OSSubprocess [1]. Note
> that
> > the pipes should work outside of OSSubprocess. You can read the
> > documentation as well as the unit tests for the pipes.
> >
> > Cheers,
> >
> > [1] https://github.com/marianopeck/OSSubprocess
>
> OSSPipe seems to assume that is controlling both ends of the pipe,
> while it may be that Siemen just wants to read from the pipe.  Anyway,
> Mariano mentioned that pipes should work outside of OSSubprocess, and
> I've made some modifications to FilePlugin which should facilitate
> that, so thought I'd have a go.  This still doesn't completely meet
> Siemen's requirements as it polls the stream, but...  I've attached a
> little demo class, tested only on Ubuntu 16.04.  Be warned, I've never
> used Unix pipes before, so feel free to critique the code:
>
>
> NamedPipeEcho provides sample code showing how to read from a Unix
> named pipe and echo the contents to stdout.
>
> Interesting attributes of the sample code include:
>
> - It is just a sample, it isn't intended to be production ready.
> - It marks the pipe non-blocking so that multiple pipes can be
> processed without the image blocking when reading.
> - It's polling, rather than event driven.
> - It doesn't have any external dependencies outside the core Pharo
> image and standard Pharo VM.
> - It defines a method that directly calls a primitive - I consider
> this bad practice and would like to make the primitive generally
> available through FilePlugin.
>
>
> The simplest way to run this is in one terminal (bash shell):
>
> $ mkfifo /dev/shm/pharopipe
> $ pharo --headless Pharo.image eval "(NamedPipeEcho on:
> '/dev/shm/pharopipe') run"
>
> and in a second terminal (bash shell):
>
> $ pharo --headless Pharo.image eval "NamedPipeEcho sampleWriteTo:
> '/dev/shm/pharopipe'"
>
> You should see:
>
> Hello World
> Line 2
>
> in the first terminal, with a 15 second delay between the lines and exit.
>
>
> There's also AsyncFile, which should make it event driven instead of
> polled, but I haven't had a chance to look at that yet.
>
> This is tested with:
>
>
> Pharo7.0alpha
> Build information:
> Pharo-7.0+alpha.build.839.sha.675decd24230e0ef7d1579af07c2112c104c6d7b
> (64 Bit)
>
>
> 5.0-20180416  Thu Apr 12 22:34:48 UTC 2018 gcc 4.8 [Production
> Spur 64-bit VM]
> CoInterpreter VMMaker.oscog-eem.2361 uuid:
> 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 12 2018
> StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid:
> 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 12 2018
> VM: 20180416 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> Date: Thu Apr 12 15:26:17 2018 -0700 $ CommitHash: 07c6dc3 $
> Plugins: 20180416 https://github.com/OpenSmalltalk/opensmalltalk-
> vm.git $
> Linux travis-job-b95e67e4-9fb2-4d69-a59f-1fbf859b912c
> 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017
> x86_64 x86_64 x86_64 GNU/Linux
> plugin path: /home/alistair/pharo7/Issue21692/vm/pharo-vm/lib/
> pharo/5.0-20180416
> [default: /home/alistair/pharo7/Issue21692/vm/pharo-vm/lib/
> pharo/5.0-20180416/]
>
>
> Earlier VMs probably won't work as #atEnd will always return true or
> false (I forget which).
>
> Cheers,
> Alistair
>

Re: [Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

Thanks for your quick answer.  I have only a fleeting knowledge of Pharo 
but liked what I saw. The Squeak class library has seen organic growth 
since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo 
kernel was a minimal image with a minimal class library. The rest of the 
functionality was partitioned into packages that could be added to the 
kernel image as required. Beautiful. But only my dream?


   /Matthew 7:24-27: And the rain fell, and the floods came, and the
   winds blew and beat on that house, but it did not fall, because it
   had been founded on the rock. And  everyone who hears these words of
   mine and does not do them will be like a foolish man who built his
   house on the sand."/

I am developing an IDE for non-programmers  called BabyIDE, a 
non-intrusive extension of Squeak. Where the Class Browser in Squeak is 
used to work with one class at the time, the BabyIDE browser is used to 
work with structures of collaborating objects, ignoring their classes. I 
would like to develop a BabyIDE image that gets broad usage and long 
life. I'm looking for a rock to build on and hoped it could be what I 
thought was the Pharo kernel+ a few selected packages. In your answer, I 
read that if I build BabyIDE on Pharo, I will be building on sand.


pharo.org writes: "/Pharo is a pure object-oriented programming 
language.../".  The only language I can see is defined by the release 
image. A Pharo programmer builds application programs in this language. 
He or she can add new classes, change existing ones, subclass them, add 
or change methods, change the Smalltalk dictionary, etc. etc.  An 
extremely flexible and powerful language.


A tale from the future when Pharo is a mainstream language: Business 
customers benefit from end users using applications that are written by 
Pharo programmers who built on the Pharo language and environment that 
had been developed by the Pharo community. One day there is a happy 
announcement: A new version of Pharo will be launched tomorrow. It is 
truly cool and includes any number of improvements, some of them 
documented. And, by the way, applications written in the current Pharo 
will no longer work. So please inform your customers that you will not 
be able to serve them for a while. We are confident that all your 
application programmers will be happy to drop whatever they are doing in 
order to adapt their applications to the new Pharo so that you can start 
serving your customers again.


Cheers
--Trygve



On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are always 
things moving in the pharo world. The last years the virtual machine 
got some iterations and it is still not fully stable. For pharo it is 
hard to have it stable because we feel the need that a lot of the 
existing parts need to be replaced to be useful in these times. 
Furthermore pharo is also prototyping platform for programming 
language features. All of these are counter-stability measures. So if 
you need a stable kernel from native ground up to UI pharo won‘t be 
that thing you are looking for the coming years (if at all). You 
always need to adopt to change so you need to define your required 
scope better in order to get an estimate.


Norbert

Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug >:


I'm working on a programing paradigm and IDE for the personal 
programmer who wants to control his or her IoT. The size of the 
target audience I have in mind is >100 million. I gave up Squeak long 
ago as a platform because they obsolete my code faster than I can 
write it.  I have now frozen Squeak 3.10.2 and hope its runtime will 
survive until I find a better foundation. My hope is that Pharo has a 
stable kernel that I can build on.  According to Stephan, this is not 
so. Is there any plan for creating a stable Pharo kernel that people 
can use for building software of lasting value for millions of 
non-expert users?

--Thanks, Trygve

On 05.05.2018 13:53, Stephan Eggermont wrote:

I’ve taken a look at what would be needed to
support magma on pharo a few years ago. Chris always told us he uses it
professionally on squeak and/*has not enough capacity to keep up with changes in pharo without 
having a customer/maintainer for it.*/  Twice a year

or so someone asks about magma on pharo and takes a look. AFAIK there are
no real obstacles to a port, but magma uses a lot of deep implementation
specifics that will take an experienced smalltalker to deal with, and a lot
of mailing list archeology as pharo changed a lot since magma worked on
pharo last

Stephan


--

/The essence of object orientation is that objects collaborateto 
achieve a goal. /
Trygve Reenskaug mailto: tryg...@ifi.uio.no 


Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 22 49 57 27



--

/The essence of object orientation is that obje

Re: [Pharo-users] Personal Programming onPharo

[Norbert Hartl]

I understand what you are saying but it contains some misconceptions about the 
modern software world. 

„The earth is not stopping to turn just because you want to stay on the sunny 
side“

There is two funny concepts going on in the modern software industry. The one 
tells you that because you want to do a product everything else around you 
should come to a full stop so can comfortably build your software not disturbed 
by other things. The second one tells you that you _have to upgrade_ … there is 
this magical force preventing you from staying where you are. Both notions are 
funny alone but they come combined and then they turn out to be a non-sensical 
monster.

Let’s take a different approach. Put in everything you say about software, 
libraries, etc the word version. So you can build upon Pharo version 3 your own 
product. You can stay at that version and it won’t change. If the software you 
sell is not 80% pharo but your own you should not have a problem just to stay 
on that version because you develop your own stuff. But still the world did not 
stop turning and there is pharo 4. You decide there are a few nice features but 
the work to adjust is too big to take the risk. Then there is pharo 5 and you … 
nahhh not this time….Then there is pharo6 and they not only changed the image 
but also the way source code is managed. That prevents you further from 
adjusting. But hey you can still be happy with pharo3 and it does not change. 

So what is the real problem? Yes, money/time is not enough. I think there are a 
lot of people risking their health to promote pharo and now we have a 
consortium that can pay engineers to do work on pharo. So let me tell you a 
future story:

You see what pharo is doing and you think it is good. You can also see that 
there are too less resources to proceed in the way you need it to go. So you 
decide to show pharo to the world inspiring people with some kind of a vision. 
The result is that more people pay into the consortium and we hire more 
engineers. And then one day the consortium has enough money to pay engineers 
that can care about a LTS (long term support) version of pharo. So you can stay 
on pharo version 3 and still get those annoying bugs fixed. And hey this team 
has also enough time to provide you with tools that make a migration to pharo 
version 4 more easy and less annoying for you. And then you have your own 
product based on pharo version 4. And then for version 5, version 6,…. Sounds 
like a dream…but hey…it is indeed realistic. It just depends on how the people 
approach it

How does this sound?

Norbert

> Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug :
> 
> Thanks for your quick answer.  I have only a fleeting knowledge of Pharo but 
> liked what I saw. The Squeak class library has seen organic growth since 1978 
> or earlier. Pharo gave it a thorough overhaul. At the Pharo kernel was a 
> minimal image with a minimal class library. The rest of the functionality was 
> partitioned into packages that could be added to the kernel image as 
> required. Beautiful. But only my dream?
> Matthew 7:24-27: And the rain fell, and the floods came, and the winds blew 
> and beat on that  house, but it did not fall, because it had been founded on 
> the rock. And  everyone who hears these words of mine and does not do them 
> will be like a foolish man who built his house on the sand."
> I am developing an IDE for non-programmers  called BabyIDE, a non-intrusive 
> extension of Squeak. Where the Class Browser in Squeak is used to work with 
> one class at the time, the BabyIDE browser is used to work with structures of 
> collaborating objects, ignoring their classes. I would like to develop a 
> BabyIDE image that gets broad usage and long life. I'm looking for a rock to 
> build on and hoped it could be what I thought was the Pharo kernel+ a few 
> selected packages. In your answer, I read that if I build BabyIDE on Pharo, I 
> will be building on sand.
> 
> pharo.org  writes: "Pharo is a pure object-oriented 
> programming language...".  The only language I can see is defined by the 
> release image. A Pharo programmer builds application programs in this 
> language. He or she can add new classes, change existing ones, subclass them, 
> add or change methods, change the Smalltalk dictionary, etc. etc.  An 
> extremely flexible and powerful language.
> 
> A tale from the future when Pharo is a mainstream language: Business 
> customers benefit from end users using applications that are written by Pharo 
> programmers who built on the Pharo language and environment that had been 
> developed by the Pharo community. One day there is a happy announcement: A 
> new version of Pharo will be launched tomorrow. It is truly cool and includes 
> any number of improvements, some of them documented. And, by the way, 
> applications written in the current Pharo will no longer work. So please 
> inform your customers that you will not be able 

[Pharo-users] Package extension. Adding instance variables to classes

[Alidra Abdelghani via Pharo-users]

--- Begin Message ---
Hi,

I am working on a package named ClassNamesAnalyzer and I need to add code to 
third party classes in other packages (for instance the FAMIX-Core package).
“Extending” third party classes with methods is easy; I just need to categorise 
my methods under the *ClassNamesAnalyzer protocole so that loading my package 
will load them in the image.
However, if I want to add instance variables to theses classes, they are not 
there when I load the package in a new image.

So my question is : is there a way to include instance variables addition to 
other packages in my package?
Another question is : is it good practice to add instance variables to classes 
in third party packages and is there a way to avoid it (because I am not very 
confortable with that idea)?

Thanks in advance,
Abdelghani--- End Message ---

Re: [Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

Please tell me when Java, C, C++, etc programs stopped working because 
their runtime systems had changed.
Please tell me when Java, C, C++, etc compilers stopped compiling old 
code because the languages had changed.


On 07.05.2018 11:57, Norbert Hartl wrote:
I understand what you are saying but it contains some misconceptions 
about the modern software world.


„The earth is not stopping to turn just because you want to stay on 
the sunny side“


There is two funny concepts going on in the modern software industry. 
The one tells you that because you want to do a product everything 
else around you should come to a full stop so can comfortably build 
your software not disturbed by other things. The second one tells you 
that you _have to upgrade_ … there is this magical force preventing 
you from staying where you are. Both notions are funny alone but they 
come combined and then they turn out to be a non-sensical monster.


Let’s take a different approach. Put in everything you say about 
software, libraries, etc the word version. So you can build upon Pharo 
version 3 your own product. You can stay at that version and it won’t 
change. If the software you sell is not 80% pharo but your own you 
should not have a problem just to stay on that version because you 
develop your own stuff. But still the world did not stop turning and 
there is pharo 4. You decide there are a few nice features but the 
work to adjust is too big to take the risk. Then there is pharo 5 and 
you … nahhh not this time….Then there is pharo6 and they not only 
changed the image but also the way source code is managed. That 
prevents you further from adjusting. But hey you can still be happy 
with pharo3 and it does not change.


So what is the real problem? Yes, money/time is not enough. I think 
there are a lot of people risking their health to promote pharo and 
now we have a consortium that can pay engineers to do work on pharo. 
So let me tell you a future story:


You see what pharo is doing and you think it is good. You can also see 
that there are too less resources to proceed in the way you need it to 
go. So you decide to show pharo to the world inspiring people with 
some kind of a vision. The result is that more people pay into the 
consortium and we hire more engineers. And then one day the consortium 
has enough money to pay engineers that can care about a LTS (long term 
support) version of pharo. So you can stay on pharo version 3 and 
still get those annoying bugs fixed. And hey this team has also enough 
time to provide you with tools that make a migration to pharo version 
4 more easy and less annoying for you. And then you have your own 
product based on pharo version 4. And then for version 5, version 6,…. 
Sounds like a dream…but hey…it is indeed realistic. It just depends on 
how the people approach it


How does this sound?

Norbert

Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug >:


Thanks for your quick answer.  I have only a fleeting knowledge of 
Pharo but liked what I saw. The Squeak class library has seen organic 
growth since 1978 or earlier. Pharo gave it a thorough overhaul. At 
the Pharo kernel was a minimal image with a minimal class library. 
The rest of the functionality was partitioned into packages that 
could be added to the kernel image as required. Beautiful. But only 
my dream?


/Matthew 7:24-27: And the rain fell, and the floods came, and the
winds blew and beat on that  house, but it did not fall, because
it had been founded on the rock. And  everyone who hears these
words of mine and does not do them will be like a foolish man who
built his house on the sand."/

I am developing an IDE for non-programmers  called BabyIDE, a 
non-intrusive extension of Squeak. Where the Class Browser in Squeak 
is used to work with one class at the time, the BabyIDE browser is 
used to work with structures of collaborating objects, ignoring their 
classes. I would like to develop a BabyIDE image that gets broad 
usage and long life. I'm looking for a rock to build on and hoped it 
could be what I thought was the Pharo kernel+ a few selected 
packages. In your answer, I read that if I build BabyIDE on Pharo, I 
will be building on sand.


pharo.org writes: "/Pharo is a pure 
object-oriented programming language.../". The only language I can 
see is defined by the release image. A Pharo programmer builds 
application programs in this language. He or she can add new classes, 
change existing ones, subclass them, add or change methods, change 
the Smalltalk dictionary, etc. etc.  An extremely flexible and 
powerful language.


A tale from the future when Pharo is a mainstream language:Business 
customers benefit from end users using applications that are written 
by Pharo programmers who built on the Pharo language and environment 
that had been developed by the Pharo community. One day there is a 
happy announcement: A new version of Pharo

Re: [Pharo-users] Package extension. Adding instance variables to classes

[Pavel Krivanek]

2018-05-07 12:25 GMT+02:00 Alidra Abdelghani via Pharo-users <
pharo-users@lists.pharo.org>:

>
>
> -- Přeposlaná zpráva --
> From: Alidra Abdelghani 
> To: pharo-users@lists.pharo.org
> Cc:
> Bcc:
> Date: Mon, 7 May 2018 11:25:49 +0100
> Subject: Package extension. Adding instance variables to classes
> Hi,
>
> I am working on a package named ClassNamesAnalyzer and I need to add code
> to third party classes in other packages (for instance the FAMIX-Core
> package).
> “Extending” third party classes with methods is easy; I just need to
> categorise my methods under the *ClassNamesAnalyzer protocole so that
> loading my package will load them in the image.
> However, if I want to add instance variables to theses classes, they are
> not there when I load the package in a new image.
>
> *So my question is* : is there a way to include instance variables
> addition to other packages in my package?
>

Currently not, you should use privateState


> *Another question is* : is it good practice to add instance variables to
> classes in third party packages and is there a way to avoid it (because I
> am not very confortable with that idea)?
>

It is not, see FAMIXContainerEntity>>#definedAnnotationTypes how this issue
is currently being solved using the privateState.

Cheers,
-- Pavel


>
> Thanks in advance,
> Abdelghani
>
>

Re: [Pharo-users] Personal Programming onPharo

[Norbert Hartl]

> Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug :
> 
> Please tell me when Java, C, C++, etc programs stopped working because their 
> runtime systems had changed.
> Please tell me when Java, C, C++, etc compilers stopped compiling old code 
> because the languages had changed.
> 
If we talk about C/C++ the runtime is the operating system. Everytime I update 
it the linked libraries are suspect to be invalid from then. If you have in the 
same system update a new version of the C compiler you are doomed. You cannot 
link your binary with the new libs. And the new C compiler quirks about your 
code. So what you have then? Staying on an old C language standard? Statically 
link everything. Ah no that won’t work because you would have to care about all 
your dependencies being compilable with the new compiler. But you don’t update 
the compiler meaning you don’t update the operating system. It is the same as 
staying on pharo 3.

For Java the situation is slightly different because if you use new programming 
language features you can only do when switching the compiler to the new 
standard. There is a lot of effort that went into making the java vm recognize 
the language version and execute regarding that making version compatible. We 
are in sync here. I told you it is about manpower. Do you know how much 
manpower it needed and how long it took to add something like closures to the 
java language? Do you consider java closure to be en par with other languages?

We are sorry not everything is to your liking. It is not even to our own liking 
because we have dreams far beyond. But we will never get there if we don’t take 
the effort. And the point of open source (did I mention pharo is open source?? 
) is that the ones that do it decide what to do. Nuff said!

Norbert

> On 07.05.2018 11:57, Norbert Hartl wrote:
>> I understand what you are saying but it contains some misconceptions about 
>> the modern software world. 
>> 
>> „The earth is not stopping to turn just because you want to stay on the 
>> sunny side“
>> 
>> There is two funny concepts going on in the modern software industry. The 
>> one tells you that because you want to do a product everything else around 
>> you should come to a full stop so can comfortably build your software not 
>> disturbed by other things. The second one tells you that you _have to 
>> upgrade_ … there is this magical force preventing you from staying where you 
>> are. Both notions are funny alone but they come combined and then they turn 
>> out to be a non-sensical monster.
>> 
>> Let’s take a different approach. Put in everything you say about software, 
>> libraries, etc the word version. So you can build upon Pharo version 3 your 
>> own product. You can stay at that version and it won’t change. If the 
>> software you sell is not 80% pharo but your own you should not have a 
>> problem just to stay on that version because you develop your own stuff. But 
>> still the world did not stop turning and there is pharo 4. You decide there 
>> are a few nice features but the work to adjust is too big to take the risk. 
>> Then there is pharo 5 and you … nahhh not this time….Then there is pharo6 
>> and they not only changed the image but also the way source code is managed. 
>> That prevents you further from adjusting. But hey you can still be happy 
>> with pharo3 and it does not change. 
>> 
>> So what is the real problem? Yes, money/time is not enough. I think there 
>> are a lot of people risking their health to promote pharo and now we have a 
>> consortium that can pay engineers to do work on pharo. So let me tell you a 
>> future story:
>> 
>> You see what pharo is doing and you think it is good. You can also see that 
>> there are too less resources to proceed in the way you need it to go. So you 
>> decide to show pharo to the world inspiring people with some kind of a 
>> vision. The result is that more people pay into the consortium and we hire 
>> more engineers. And then one day the consortium has enough money to pay 
>> engineers that can care about a LTS (long term support) version of pharo. So 
>> you can stay on pharo version 3 and still get those annoying bugs fixed. And 
>> hey this team has also enough time to provide you with tools that make a 
>> migration to pharo version 4 more easy and less annoying for you. And then 
>> you have your own product based on pharo version 4. And then for version 5, 
>> version 6,…. Sounds like a dream…but hey…it is indeed realistic. It just 
>> depends on how the people approach it
>> 
>> How does this sound?
>> 
>> Norbert
>> 
>>> Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug >> >:
>>> 
>>> Thanks for your quick answer.  I have only a fleeting knowledge of Pharo 
>>> but liked what I saw. The Squeak class library has seen organic growth 
>>> since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo 
>>> kernel was a minimal image with a minimal class library. The rest of

Re: [Pharo-users] Personal Programming onPharo

[Stephan Eggermont]

Trygve Reenskaug  wrote:
> Please tell me when Java, C, C++, etc programs stopped working because 
> their runtime systems had changed.
> Please tell me when Java, C, C++, etc compilers stopped compiling old 
> code because the languages had changed.
> 

Oracle lists 24 behavioral incompatibilities between Java SE 7 and SE 6. 

Stephan

Re: [Pharo-users] Personal Programming onPharo

[Sean P. DeNigris]

Trygve Reenskaug wrote
> I am developing an IDE for non-programmers  called BabyIDE

I remember seeing this in a screencast - it was very cool!


Trygve Reenskaug wrote
> In your answer, I read that if I build BabyIDE on Pharo, I will be
> building on sand.

Sorry I took so long to reply to your OP. It does indeed *sound* like that
but AFAICT (myself included with dozens of projects), porting to new
versions has been relatively painless. That said, a project like you
described may have additional hurdles because it hooks so deeply into the
inner guts of the IDE. Also, there are continually new techniques to ease
these transitions. For example, there is now a deprecation message which
auto-rewrites sender on first send; this is even more powerful if one has
tests with good coverage because running the tests magically updates your
project.


Trygve Reenskaug wrote
> A tale from the future… drop whatever they are doing in 
> order to adapt their applications to the new Pharo so that you can start 
> serving your customers again.

It's a hard problem because we have a big vision, which means a natural
tension with backward compatibility. In fact, IMHO that was one of the major
reasons for the fork from Squeak, so I guess it's unfortunate that now
Squeak seems to be a moving target as well. Again, just to reiterate,
AFAICT, most of the changes are generally deep in the system and will not
affect the average customer facing project. Even then, there's no need to be
on the latest, greatest version if the cost doesn't seem worth it. There are
plenty of production systems happily running on Pharo 1.x.

Suggestions are very welcome about how to move toward a bright future with
minimum impact on existing users/projects!!



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

Re: [Pharo-users] #ast vs. #parseTree

[Richard Sargent]

>
> I know it. But my stupid question is why it's still called abstract while
> it is implemented for concrete language?
>

I finally got around to running an image and extracting a screen print.
Hopefully, it will attach and be visible to you.

The classes of objects in the inspector show the abstract syntax: a method
node comprised of a sequence node, etc. Each abstract syntax node is bound
with the actual source code that it represents.

Abstract is not about the language something is implemented in, but rather
the syntactic structure of the code.


On Fri, May 4, 2018 at 12:13 PM, Denis Kudriashov 
wrote:

>
> 2018-05-04 21:10 GMT+03:00 Richard Sargent  gemtalksystems.com>:
>
>> On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov 
>> wrote:
>>
>>>
>>> 2018-05-04 19:45 GMT+03:00 Sean P. DeNigris :
>>>
 Ramon Leon-5 wrote
 > And my point made; I don't even know what that means.

 Ha ha, I googled it and even after seeing the definition still didn't
 understand - we must be getting old ;-)

 Regarding the use of acronyms - while I agree with you as a general
 principle, I wonder about this case. Since the argument IIUC is that "a
 general user won't know the domain well enough to understand the
 acronym",
 would they understand "abstractSyntaxTree"?!
>>>
>>>
>>> Now I am wonder: is it really correct to call syntax tree as abstract
>>> when it is really implemented?
>>> AST is very known term but now when I read it word by word I have such
>>> questions :).
>>>
>>
>> In computer science, an *abstract syntax tree* (AST), or just *syntax
>> tree*, is a *tree* representation of the *abstract syntactic *structure
>> of source code written in a programming language.
>> [Wikipedia]
>>
>
> I know it. But my stupid question is why it's still called abstract while
> it is implemented for concrete language?
>
>
>>
>>
>>>
>>>
 That, to me, is as opaque as
 the acronym for one not acquainted with the domain, and may buy us
 little at
 the cost of a good amount of extra typing. Maybe keep the acronym and
 add a
 good method comment…



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


>>>
>>
>

Re: [Pharo-users] #ast vs. #parseTree

[Richard Sargent]

On Sat, May 5, 2018 at 3:08 AM, Sean P. DeNigris 
wrote:

> Richard Sargent wrote
> > No. Please, really no.
>
> As much as I appreciate (and share) the passion for Smalltalk, you did not
> AFAICT address my reasoning for not applying the no-acronym *guideline* in
> this case, namely:
>
> >> Since the argument IIUC is that "a
> >> general user won't know the domain well enough to understand the
> >> acronym",
> >> would they understand "abstractSyntaxTree"?! That, to me, is as opaque
> as
> >> the acronym for one not acquainted with the domain, and may buy us
> little
> >> at the cost of a good amount of extra typing.
>

I care a lot less about typing than reading. Some years ago, a colleague of
mine conducted a brief and informal survey of the developers working in our
team. "What fraction of time do you spend reading code versus writing
code?" Some people answered 50:50. In effect, saying that for every method
they read, they wrote a new one!

The truth is that we all spend substantially more time reading than
writing. Consequently, we need to emphasize how we communicate to readers.
Alan Knight said it best: (paraphrasing) Trust the implementation does what
it says it does. (In other words, message names should do what they say
they do without creating the need to look inside the method to understand
it.)


>
>
> Richard Sargent wrote
> > a disambiguation page with a lengthy list
>
> IMHO this is irrelevant. My proposal included a method comment, which would
> provide the google-able term, as well as potentially a good enough summary
> that one wouldn't have to leave the image. The fact that the method belongs
> to CompiledMethod is the disambiguation. The internet is meaningless and
> flat compared to the context and structure of a ST image.
>
>
> Richard Sargent wrote
> > Do not use comments embedded *inside* methods to cover for naming the
> > method badly… Also, if one Googles an acronym
>
> How is a harder-to-type thing that the user doesn't understand but is
> easier
> to google better than a comment that gives the necessary context right in
> the image? My ideal image would avoid the need to Google as much as
> possible, suggesting a comment either way, so nothing lost. There's nothing
> inherently "bad" about an acronym. For example, no one's been banging down
> the door to rename "JPEGReadWriter" to
> "JointPhotographicExpertsGroupReadWriter". In that case, it's because the
> acronym is so well-known, but what I'm asking whether #ast is a similar
> candidate for exception because it is so unknown (i.e. compiler
> domain-specific) that a user is likely to know either the term and the
> acronym or neither.
>

The thing is that a well named concept doesn't need Googling in order to
have at least some understanding of its meaning. I would be willing to bet
that, even if you had never heard of the topic before, you would have *some*
idea what the phrase abstract syntax tree meant. Conversely, the first time
one might encounter the concept presented as "ast", you might suspect it
was a kind of snake. I'm being a bit extreme here, of course.


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

Re: [Pharo-users] #ast vs. #parseTree

[Ramon Leon]

On 05/05/2018 03:08 AM, Sean P. DeNigris wrote:

and may buy us little at the cost of a good amount of extra typing.


Auto-completion killed that argument long ago. Method names are for
reading, not writing; the computer will do most of the writing for you.

If you're optimizing key strokes when deciding a method name, you're 
doing it wrong.


--
Ramon Leon

Re: [Pharo-users] How to LAN feature

[Hilaire]

Le 06/05/2018 à 13:31, Norbert Hartl a écrit :

If it is on a single network this should be doable by using UDP broadcast 
announcements. The share server can announce some information and its IP in a 
UDP packet being broadcasted. Every client receives that and then knows the 
address of the server to connect to

Hope this helps, Norbert


Yep, then I can I set up a FTP server to run on the Pharo teacher 
instance. I already wrote a facade for user friendly FTP client.

Does any one know about FTP server on Pharo, for example this one[1]?

Thanks

Hilaire

[1] http://map.squeak.org/package/f84afa9e-c2ea-4d4c-bc65-aea93701753d

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

Re: [Pharo-users] #ast vs. #parseTree

[webwarrior]

If you guys are to get rid of acronyms in method names, cosider the
following:

#onDNU:do:
#gcd:
#lcm:
#rem:
#quo:
#ulp
#ln
#theta
#r
#g
#b

and others.
Then if you get bored again there are a lot of contractions, too, especially
in Number and subclasses. 
Like #abs, #sqrt, #sin, #cos, ...



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

Re: [Pharo-users] How to LAN feature

[Norbert Hartl]

> Am 07.05.2018 um 18:08 schrieb Hilaire :
> 
>> Le 06/05/2018 à 13:31, Norbert Hartl a écrit :
>> If it is on a single network this should be doable by using UDP broadcast 
>> announcements. The share server can announce some information and its IP in 
>> a UDP packet being broadcasted. Every client receives that and then knows 
>> the address of the server to connect to
>> 
>> Hope this helps, Norbert
> 
> Yep, then I can I set up a FTP server to run on the Pharo teacher instance. I 
> already wrote a facade for user friendly FTP client.
> Does any one know about FTP server on Pharo, for example this one[1]?
> 
For what do you need an FTP server? For browsing and downloading usually a HTTP 
server is as good as. You implement a handler that returns a directory list for 
directories and the file content for files. Can be used with every web browser 
and zinc you have already in the image,

Norbert

> Thanks
> 
> Hilaire
> 
> [1] http://map.squeak.org/package/f84afa9e-c2ea-4d4c-bc65-aea93701753d
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

Re: [Pharo-users] How to LAN feature

[Hilaire]

As described previously, students may also upload their work at the end 
of a teaching session.


Hilaire


Le 07/05/2018 à 18:57, Norbert Hartl a écrit :

For what do you need an FTP server? For browsing and downloading usually a HTTP 
server is as good as. You implement a handler that returns a directory list for 
directories and the file content for files. Can be used with every web browser 
and zinc you have already in the image,

Norbert


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

Re: [Pharo-users] How to LAN feature

[Sven Van Caekenberghe]

Uploading can be done using an HTTP POST or PUT, just like Playground does its 
Remote Publish, or Monticello its Save operation.

> On 7 May 2018, at 19:15, Hilaire  wrote:
> 
> As described previously, students may also upload their work at the end of a 
> teaching session.
> 
> Hilaire
> 
> 
> Le 07/05/2018 à 18:57, Norbert Hartl a écrit :
>> For what do you need an FTP server? For browsing and downloading usually a 
>> HTTP server is as good as. You implement a handler that returns a directory 
>> list for directories and the file content for files. Can be used with every 
>> web browser and zinc you have already in the image,
>> 
>> Norbert
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

[Pharo-users] Browse dependencies to a package

[Cyril Ferlicot D.]

Hi,

In Pharo we have the dependency analyzer to get the dependencies of a
package. But is it easily possible to find the dependencies to a package?

I did not found the option in the interface.

-- 
Cyril Ferlicot
https://ferlicot.fr



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] How to LAN feature

[Hilaire]

Computer should be on a same network, however not sure about swtich in 
between.


Does UDP broadcast required particular privilege on the host?

Thanks

Hilaire

Le 06/05/2018 à 13:31, Norbert Hartl a écrit :

If it is on a single network this should be doable by using UDP broadcast 
announcements. The share server can announce some information and its IP in a 
UDP packet being broadcasted. Every client receives that and then knows the 
address of the server to connect to


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

[Pharo-users] How to pretty print a dynamic array

[Davide Varvello via Pharo-users]

--- Begin Message ---
Hi guys,
I have a dynamic array that the formatter put on a column like this:
{self meth1.
self meth2.
self meth3}

instead I want it in a single row, like this:
{self meth1. self meth2. self meth3}

But I can't find any settings to pretty print in the last way.
Can you help me, please?


Davide



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

--- End Message ---

Re: [Pharo-users] #ast vs. #parseTree

[Richard O'Keefe]

#onDNU:do:

That one's not so good.  Not so much because of the acronym, but because
it's unclear about what the argument is.  A better name would be
#onUndefinedSelector:do:

#gcd:
#lcm:

These come from elementary (primary school in my day) mathematics.  They
are the standard names.

#rem:
#quo:

These are not acronyms.  They are more intelligible than // and \\.  But
yes,
{floor,ceiling,rounded,truncated}{Quotient,Remainder}:
would be clearer.  #quo: and #rem: are sufficiently rare
that it wouldn't hurt if they were longer.
BUT they are in the Blue Book and in the standard.

#ulp

This is indeed an acronym, and it's probably obscure
to many programmers.  But practically every paper I have read about
floating-point issues uses this; it is
a technical term of art.  Spelling it out as #unitOfLeastPrecision as
VisualWorks does, and as
both Squeak and Pharo do in their comments, is the
reverse of helpful, because that is not what 'ulp'
stands for. It's Unit in the Last Place.  Now there IS
a case for giving #ulp a long name, but that's not it.
There are some subtleties in the definition.
http://www.ens-lyon.fr/LIP/Pub/Rapports/RR/RR2005/RR2005-09.pdf
lists, by my count, five definitions.  The first is obsolete,
The fifth is a hybrid of some of the others.  It turns out
that I knew less about ULPs than I thought I did.

#ln

#NaperianLogarithm won't help anyone who doesn't
know who Napier was or what a logarithm is.  I
suppose #logarithmToBaseE might work.

#theta

That is not an acronym.  It is spelled out in full.
Using Greek letters for arbitrary angles goes back
roughly two thousand years.  To the Greeks, in fact.
Blame them, not Pharo.

#r
#g
#b

I can think of at least two meanings for each of these, so granted.


Click here to Reply or Forward
0.2 GB (1%) of 15


On 8 May 2018 at 04:57, webwarrior  wrote:

> If you guys are to get rid of acronyms in method names, cosider the
> following:
>
> #onDNU:do:
> #gcd:
> #lcm:
> #rem:
> #quo:
> #ulp
> #ln
> #theta
> #r
> #g
> #b
>
> and others.
> Then if you get bored again there are a lot of contractions, too,
> especially
> in Number and subclasses.
> Like #abs, #sqrt, #sin, #cos, ...
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] How to LAN feature

[Henrik Sperre Johansen]

HilaireFernandes wrote
> Computer should be on a same network, however not sure about swtich in 
> between.
> 
> Does UDP broadcast required particular privilege on the host?
> 
> Thanks
> 
> Hilaire
> 
> Le 06/05/2018 à 13:31, Norbert Hartl a écrit :
>> If it is on a single network this should be doable by using UDP broadcast
>> announcements. The share server can announce some information and its IP
>> in a UDP packet being broadcasted. Every client receives that and then
>> knows the address of the server to connect to
> 
> -- 
> Dr. Geo
> http://drgeo.eu

No, but it does involve setting certain options on the socket, etc.
You could check if http://smalltalkhub.com/#!/~henriksp/SSDP is
appropriate/works for you.

Cheers,
Henry



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

Re: [Pharo-users] Personal Programming onPharo

[Trygve Reenskaug]

Norbert,
I stand corrected because I have not followed the mainstream languages 
as well as I probably should. Thank you for your candid answer, it 
clearly outlines what I can and cannot expect from Pharo and any other 
ST project.


I go back to Alan Kay's vision of a Dynabook: A /personal /computer for 
children of all ages. It should contain all its owner's /personal /data, 
including  his or her /personal /programs, as they evolve through the 
years.  Continuity is a must; the owner shall never loose data.


Again, thank you for your answers. They have given invaluable 
contributions to my thinking.

--Trygve.


On 07.05.2018 14:14, Norbert Hartl wrote:


Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug >:


Please tell me when Java, C, C++, etc programs stopped working 
because their runtime systems had changed.
Please tell me when Java, C, C++, etc compilers stopped compiling old 
code because the languages had changed.


If we talk about C/C++ the runtime is the operating system. Everytime 
I update it the linked libraries are suspect to be invalid from then. 
If you have in the same system update a new version of the C compiler 
you are doomed. You cannot link your binary with the new libs. And the 
new C compiler quirks about your code. So what you have then? Staying 
on an old C language standard? Statically link everything. Ah no that 
won’t work because you would have to care about all your dependencies 
being compilable with the new compiler. But you don’t update the 
compiler meaning you don’t update the operating system. It is the same 
as staying on pharo 3.


For Java the situation is slightly different because if you use new 
programming language features you can only do when switching the 
compiler to the new standard. There is a lot of effort that went into 
making the java vm recognize the language version and execute 
regarding that making version compatible. We are in sync here. I told 
you it is about manpower. Do you know how much manpower it needed and 
how long it took to add something like closures to the java language? 
Do you consider java closure to be en par with other languages?


We are sorry not everything is to your liking. It is not even to our 
own liking because we have dreams far beyond. But we will never get 
there if we don’t take the effort. And the point of open source (did I 
mention pharo is open source?? ) is that the ones that do it decide 
what to do. Nuff said!


Norbert


On 07.05.2018 11:57, Norbert Hartl wrote:
I understand what you are saying but it contains some misconceptions 
about the modern software world.


„The earth is not stopping to turn just because you want to stay on 
the sunny side“


There is two funny concepts going on in the modern software 
industry. The one tells you that because you want to do a product 
everything else around you should come to a full stop so can 
comfortably build your software not disturbed by other things. The 
second one tells you that you _have to upgrade_ … there is this 
magical force preventing you from staying where you are. Both 
notions are funny alone but they come combined and then they turn 
out to be a non-sensical monster.


Let’s take a different approach. Put in everything you say about 
software, libraries, etc the word version. So you can build upon 
Pharo version 3 your own product. You can stay at that version and 
it won’t change. If the software you sell is not 80% pharo but your 
own you should not have a problem just to stay on that version 
because you develop your own stuff. But still the world did not stop 
turning and there is pharo 4. You decide there are a few nice 
features but the work to adjust is too big to take the risk. Then 
there is pharo 5 and you … nahhh not this time….Then there is pharo6 
and they not only changed the image but also the way source code is 
managed. That prevents you further from adjusting. But hey you can 
still be happy with pharo3 and it does not change.


So what is the real problem? Yes, money/time is not enough. I think 
there are a lot of people risking their health to promote pharo and 
now we have a consortium that can pay engineers to do work on pharo. 
So let me tell you a future story:


You see what pharo is doing and you think it is good. You can also 
see that there are too less resources to proceed in the way you need 
it to go. So you decide to show pharo to the world inspiring people 
with some kind of a vision. The result is that more people pay into 
the consortium and we hire more engineers. And then one day the 
consortium has enough money to pay engineers that can care about a 
LTS (long term support) version of pharo. So you can stay on pharo 
version 3 and still get those annoying bugs fixed. And hey this team 
has also enough time to provide you with tools that make a migration 
to pharo version 4 more easy and less annoying for you. And then you 
have your own product based on pharo version 4. And then