Re: [Pharo-users] Pharo and OpenMP

[David Allouche]

> On 26 Jan 2016, at 18:24, Dimitris Chloupis  wrote:
> 
> First my apology for the very long post but I think this will interest a lot 
> of people. 

I found that intriguing.

I wonder whether the lack of response means:
The message was too long.
Nobody cares.
It's too wrong to respond.
It's too clever to respond.
All of the above.

Just curious…

PS: Working hard on concision ;-)

Re: [Pharo-users] Use cases for methods with optional parameters

[David Allouche]

> On 28 Jan 2016, at 21:55, stepharo <steph...@free.fr> wrote:
> Le 25/1/16 09:32, David Allouche a écrit :
>> - Morphic
>> - Morph
>> - addAlarm:*at:
>> - addAlarm:*after:
>> - startStepping*
>> - subMorphNamed:*
>> 
>> - Morphic
>> - MenuMorph
>> - add:*selector:*
>> - addToggle:*
>> - addUpdating:*
>> 
>> Some of those might not be simplified by default arguments, and some of 
>> those may require run-time default values. At least, they make interesting 
>> edge cases.
> Tx for the examples.
> 
> we should also use a fluid api and not these lengthly argument tedious list

That should probably be for another thread, but…

I am all for avoiding lengthy tedious argument lists that break my limited 
short term memory. What do you mean by "fluid api"?

Re: [Pharo-users] Use cases for methods with optional parameters

[David Allouche]

> On 20 Jan 2016, at 16:08, Damien Cassou  wrote:
> 
> Before starting to implement anything, I need to know if it makes sense.
> If you want to help me, please send me all the use cases you have by
> giving me:
> 
> - the library name (and URL if not in Catalog), or "pharo" if it's in
>  Pharo
> - the class where this happens
> - the range of selectors that make sense

- Morphic
- Morph
- addAlarm:*at:
- addAlarm:*after:
- startStepping*
- subMorphNamed:*

- Morphic
- MenuMorph
- add:*selector:*
- addToggle:*
- addUpdating:*

Some of those might not be simplified by default arguments, and some of those 
may require run-time default values. At least, they make interesting edge cases.

Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[David Allouche]

> On 20 Jan 2016, at 19:27, Jimmie Houchin  wrote:
> 
> I will not argue whether or not Smalltalk and Lisp were right all along. 
> However, the fact that Smalltalk and Lisp are where they are is not simply a 
> matter of technical merit. There were many, many, political decisions made by 
> the owners of the technology which participated in its successes and failures.
> 
> Proprietary, commercial, expensive, and the varying corporate entities one 
> had to deal with in order to use this software was a huge factor. Us small 
> guys who would want to use this fantastic enabling technology had our 
> limitations in acquiring this technology. You had to have money and really 
> want to spend it in this manner.
> 
> This is not to make derogatory statements about their decisions. But they did 
> have an impact. Had the best of Smalltalk and Lisp been open sourced 20 to 30 
> years ago. Would this be a very different world? I think so. However, the 
> income and profits of those corporations would have been different also. It 
> wasn't our decision to make and we were not living in their shoes. We would 
> have to become knowledgeable about the economics, the state of the 
> competition, the state of their own business, etc. to become even reasonably 
> qualified to judge. Even then different people make different decisions 
> because they think differently or even possibly are looking for different 
> results. Open source was a different and very foreign world back then. It was 
> a very foreign thought to open source your intellectual property and believe 
> that you could earn a living from it. You do have to think different to be a 
> creator of open source software and to be successful at making a living from 
> it.
> 
> What if Sun put the effort into Strongtalk that they put into Java? Where 
> would we be?
> 
> I personally believe Smalltalk and Lisp had it right. Own the entire 
> environment and machine. Turtles all the way down.
> 
> Unfortunately the world isn't so clean. However, we do have a very nice open 
> source Smalltalk inspired tool in Pharo. While the past was not in our 
> control. We do have a say about the future. :)
> Lets make the future great!

Well spoken!

Free software became a business enabler thanks to the web. Back then, there was 
no web, no ability to build global communities pushing forward a shared 
artefact. I think that is no coincidence that the oldest language that is still 
mainstream is C, which was used to build Unix, which was used to build the web.

Now, let's do something awesome :-)

Re: [Pharo-users] Memory mapped files and Pharo (aka Unreal Engine 4 integration with Pharo)

[David Allouche]

> On 17 Jan 2016, at 22:18, Dimitris Chloupis  wrote:
> 
> Pipes are actually slower than sockets (local UNIX sockets that is) and I 
> dont need sockets if I am using shared memory. 
> 
> I could create an event que and not allow direct access to shared memory, 
> this way I make sure everything happens in order and in sequence. This way I 
> can make sure multiple writes and reads dont happen at the same time. This 
> could be a first implementation and if the need arises for multi threading 
> then I can revise this design but frankly I rather stay away from 
> multithreading and other complexities and keep this simple and easy to learn 
> and code. 

You will still need a signalling channel so either side knows that it has new 
commands to process without having to poll.

Re: [Pharo-users] Memory mapped files and Pharo (aka Unreal Engine 4 integration with Pharo)

[David Allouche]

First a disclaimer, I do not have a lot of experience with inter-process 
communication (I have a bit, though), and no direct experience with mmaped 
files.

> On 17 Jan 2016, at 17:41, Dimitris Chloupis  wrote:
> 
> 1) Do you think this is possible with the current Pharo ?
> 
> 2) Will I be limited by the fact that the VM currently does not multithread 
> or cannot use multithreading libraries ? ( I have no intention of using 
> multithreading but some handling of process access to the data may be 
> necessary to make sure data is safe from concurent modification) 

Communication through mmaped files, or shared memory in general, is inherently 
asynchronous, so lack of multiple OS threads should not be a blocker if the 
protocol is well designed.

> 3) Is there anything else I should be aware of as common pitfalls for such 
> implementation ? 

I expect you would need some sort of out-of-band signalling so polling is not 
necessary. Pipes or sockets could be used for that, slower for data transfer 
(more copying), but they are compatible with select() and other OS polling 
features.

You could build synchronisation primitives on top of sockets, too. But building 
things like mutexes would be inefficient. I guess you could use pipes for all 
the  message sending and memory management, and shared memory for bulk data 
transfer. Large number of messages could be handled in batch this way:

allocate a message area (socket round trip)
fill the message area
signal to process a block of messages (socket one way)
optimistically check for incoming messages in shared memory
wait for socket input

Not very efficient for messages that depend on one another. But I am not sure 
you could do better without things like interprocess semaphores or a FFI.

> 4) Can the current FFI help in this task or would I need to implement this as 
> a C DLL and load it from Pharo
> 
> PS: I have no intention of messing with the Pharo VM and I also want to avoid 
> the use of plugins as I want this to work with standard Pharo distributions. 

Re: [Pharo-users] I am David Allouche, let me introduce myself.

[David Allouche]

>> I can't remember who famous said something like "The only languages
>> worth learning are the ones that changes the way you think about
>> programming..."  and I found that with Smalltalk & Pharo.

Oh, I just found it.

Epigram 19 by Alan J. Perlis.

http://pu.inf.uni-tuebingen.de/users/klaeren/epigrams.html

Re: [Pharo-users] Understanding the role of the sources file

[David Allouche]

> On 13 Jan 2016, at 16:27, Dimitris Chloupis  wrote:
> 
> "The virtual machine (VM) provides the environment where the Pharo system 
> lives. It is different for each operating system and hardware architecture, 
> and runs as a machine language executable in the operating system. It 
> implements the details of managing memory, executing Pharo byte-code, and 
> communicating with the world outside of the Pharo system: files, other 
> operating system process, and the network."
> 
> No the environment is the image, the VM is basically what its names says, a 
> machine emulated by software. The vast majority of tools, even the language 
> itself reside on the image. VM is there in order for the code to be able to 
> execute and to interface with the underlying Operating System. You could 
> completely modify the VM , for example move it to the JVM and still the pharo 
> enviroment would be intact. 

That is indeed the idea I tried to convey by "where the Pharo system lives", 
but I see how that can be misunderstood. However, I try to avoid using "big 
words" like "abstraction".

How about this?

"The virtual machine (VM) provides the portable environment to execute Pharo 
images. Its implementation needs to be different for each operating system and 
hardware architecture, as it runs as a machine language executable in the 
operating system. It implements the details of managing memory, executing Pharo 
byte-code, and communicating with the world outside of the Pharo system: files, 
other operating system process, and the network. 


> "Hi Dimitris,
> your formulation "...Pharo bytcode...and convert it to machine code..."
> is insofar irritating to me as "convert it to machine code" would
> suggest to me that a compiler is at work here. Davids "executing Pharo
> byte-code" seems more understandable to me here."
> 
> Thats correct its a compiler, a byte compiler, it compiles bytecode to 
> machine code and it does it while the code executes, this is why its called 
> JIT , which has the meaning of Just In Time compilation, meaning that machine 
> code is compiled just before the code is executed so several optimizations 
> can be applied that would not be known before the execution of the code. 
> Similar to JAVA's JIT compiler. 
> 
> Note here that a compiler is not just something that produces machine code, a 
> compiler for example can take one language and compile it to another 
> language. 

That's technically true. But most readers will probably unconsciously assume 
that a compiler is something that produces machine language. The document 
should be careful to avoid misunderstandings caused by such common assumptions.

As for the JIT, that is totally an implementation detail, and I believe it is 
only worth mentioning if you want to prevent the reader from assuming that 
Pharo is slow because its VM executes byte-code. But nowadays, JIT compiling 
byte-code to machine language are the norm rather than the exception, so I do 
not think it is worth mentioning.


> 
> On Wed, Jan 13, 2016 at 4:58 PM Werner Kassens  > wrote:
> Hi Dimitris,
> your formulation "...Pharo bytcode...and convert it to machine code..."
> is insofar irritating to me as "convert it to machine code" would
> suggest to me that a compiler is at work here. Davids "executing Pharo
> byte-code" seems more understandable to me here.
> werner
> 
> On 01/13/2016 02:22 PM, Dimitris Chloupis wrote:
> > I assume you have never read a an introduction to C++ then :D
> >
> > here is the final addition for the vm
> >
> > (Vm) is the only component that is different for each operating system.
> > The main purpose of the VM is to take Pharo bytcode that is generated
> > each time user accepts a piece of code and convert it to machine code in
> > order to be executed, but also to generally handle low level
> > functionality like interpreting code, handling OS events (mouse and
> > keyboard), calling C libraries etc. Pharo 4 comes with the Cog VM a very
> > fast JIT VM.
> >
> > I think its clear, precise and does not leave much room for confusion.
> > Personally I think its very important for the absolute begineer to have
> > strong foundations of understanding the fundamental of Pharo and not for
> > things to appear magical and "dont touch this".
> >
> > On Wed, Jan 13, 2016 at 2:54 PM Sven Van Caekenberghe  > 
> > >> wrote:
> >
> >
> >  > On 13 Jan 2016, at 13:42, Dimitris Chloupis
> >  
> > >> wrote:
> >  >
> >  > I mentioned bytecode because I dont want the user to see at some
> > point bytecode and say "What the hell is that" I want the reader to
> > feel confident that at least understands the basic in Pharo. Also
> > very brief explanations about 

Re: [Pharo-users] I am David Allouche, let me introduce myself.

[David Allouche]

Thank you everyone for the kind responses. I will answer some of the questions 
and suggestions here.

> To get faster to the intellectual stimulation, pick a task / project and 
> start asking questions. And have fun :).

That is good advice, but right now I think I will just explore the system, 
review changes, and wait for the tasks to find me. There are already more 
things I want to do than I will probably every be able to accomplish :-)

> I think when people referring to Smalltalk refer to Smalltalk as the language 
> or OOP itself, but thats only the tip of the iceberg, Pharo tries to stay 
> true to vision of smalltalk creating the virtual enviroment where the user 
> can easily create his or her own tools or modifying the existing ones, 
> something that I feel no other language out there can emulate because they 
> follow a non monolithic approach where there is a deep dichotomy between 
> language, libraries and the environment itself. You could say that Smalltalk 
> is the anti-Unix architecture , a great example of monolithic design that 
> works great in practice yet its easy to modify and extend. 

The  fact Smalltalk the language cannot be taken in isolation from Smalltalk 
the environment became clear rather early on: reading the UPBE and other 
materials shows that the language itself does almost nothing: it cannot even 
define classes or packages. It is all part of the environment.

I have seen someone in another thread expressing the desire for namespaces. As 
a newcomer, I also feel that is something important and missing. But since one 
of the goals of Pharo is to produce an environment that can be understood by a 
single person, the lack of namespace might actually be a feature. Namespace are 
essential for languages like C++, designed for large projects, produced by 
large teams, where nobody understands the whole system. They embody an 
industrial approach to programming. In contrast, I have the impression that 
Smalltalk emphasises regularity to minimise system size, rather than modularity 
to manage system size, and that it embodies a craftsmanship approach.

Since I am just old enough to remember a time where computer systems could be 
understood by a single person, I find it an attractive idea to try and produce 
a modern system with that property.

> I can't remember who famous said something like "The only languages
> worth learning are the ones that changes the way you think about
> programming..."  and I found that with Smalltalk & Pharo.

I am familiar with that idea too. And most good languages provide that.

 One day I will have learn some language from the ML family. I choose Smalltalk 
because it clearly had such a strong influence on the thinking of people who 
have used it, I thought I could learn

> A good way to get your hands dirty is to review fixes submitted by others...
> https://pharo.fogbugz.com/default.asp?pgx=LF=45 
> 
> There are never enough hands there :)  (my own action here fluctuates
> from time to time)

I will try to spend some time reviewing code. That is a good way to get exposed 
to things one does not even know they exist.

> Did you look at Seaside?
> Since you should be able to read french there is  a nice tutorial: tinyBlog. 
> In two days you can build a small web app
> with a mongo back end. 

I have no looked at Seaside yet, I have not even read the corresponding chapter 
in UPBE. But I certainly will, eventually. The web is an essential part of 
society today.

> Where are you located ?

Paris, France.

It did occur to me that the Pharo community does have a unusually large 
fraction of french people. But that is not a factor for me.

Thanks again for all the kind words. I am sure this journey is going to be a 
lot of fun. :-)

Re: [Pharo-users] Understanding the role of the sources file

[David Allouche]

> On 13 Jan 2016, at 18:14, Dimitris Chloupis <kilon.al...@gmail.com> wrote:
> 
> Why the Cog VM is mentioned in my documentation is no accident. There is 
> another VM that is called Stackless VM or old VM that was the VM before Cog 
> that had no JIT and its a VM we still use for platforms that Cog VM does not 
> currently run like Raspberry Pi, Android and I think iOS too. 
> 
> 
> "But nowadays, JIT compiling byte-code to machine language are the norm 
> rather than the exception, so I do not think it is worth mentioning."
> 
> Definitely not the norm Python and Ruby VMs are not JIT, generally speaking 
> JIT compilers are rare for Dynamic languages like Pharo. Python has PyPy 
> which is a JIT VM but is nowhere as popular as Cpython. 

You are right. The JIT is worth mentioning there.

> 
> CPython people try to avoid JIT because it makes VM architecture much more 
> complex. At least thats their argument. 

I am getting off-topic, but since I have already written what follows, and I 
think it is informative, I am leaving it there :-)

Python is a rather large language, with a large number of quirks that need to 
be preserved to provide full compatibility. It is also a language with advanced 
introspection, and very dynamic semantics, even more than Smalltalk in some 
aspects. And its main implementation (CPython) has very highly optimised data 
structures and memory management.

That makes it really difficult to implement correctly and and to improve 
performance without slowing down other parts. Before PyPy, Google funded the 
Unladen Swallow project, that tried to produce a Python JIT using LLVM, this 
project was abandoned. Even PyPy needs to make frequent and expensive guard 
tests to ensure that invariants required for JIT are preserved. It does bring a 
significant speed boost (2x-10x), but at the expense of slow startup and 
increased memory footprint (~2x).

However, it seems clear that the long term future of Python lies in PyPy. In 
particular, they have high hopes to solve the lack of multicore support by 
implementing software transactional memory in the medium term, until hardware 
transactional memory is advanced enough to be usable there.

> Another big advantage of Pharo is that it has luxury to come with a JIT 
> included and well tested. 

I guess the simplicity of the language makes it relatively easy to produce a 
JIT. This is indeed a very good thing.

> 
> The only popular JITs out there are Java's and .NET, dont know if Javascript 
> V8 use JIT as well, but thats pretty much it. But bytecode is very popular 
> indeed. 

V8 does use JIT. I believe it was the first widely deployed language 
implementation to use a tracing interpreter to JIT a language with latent 
typing. I believe all the other major Javascript implementations have followed 
suite.

This is also the approach used by PyPy. Java and .Net have static typing, so 
they do not require a tracing interpreter to compile to machine code.

> On Wed, Jan 13, 2016 at 6:43 PM David Allouche <da...@allouche.net 
> <mailto:da...@allouche.net>> wrote:
>> On 13 Jan 2016, at 16:27, Dimitris Chloupis <kilon.al...@gmail.com 
>> <mailto:kilon.al...@gmail.com>> wrote:
>> 
>> "The virtual machine (VM) provides the environment where the Pharo system 
>> lives. It is different for each operating system and hardware architecture, 
>> and runs as a machine language executable in the operating system. It 
>> implements the details of managing memory, executing Pharo byte-code, and 
>> communicating with the world outside of the Pharo system: files, other 
>> operating system process, and the network."
>> 
>> No the environment is the image, the VM is basically what its names says, a 
>> machine emulated by software. The vast majority of tools, even the language 
>> itself reside on the image. VM is there in order for the code to be able to 
>> execute and to interface with the underlying Operating System. You could 
>> completely modify the VM , for example move it to the JVM and still the 
>> pharo enviroment would be intact. 
> 
> That is indeed the idea I tried to convey by "where the Pharo system lives", 
> but I see how that can be misunderstood. However, I try to avoid using "big 
> words" like "abstraction".
> 
> How about this?
> 
> "The virtual machine (VM) provides the portable environment to execute Pharo 
> images. Its implementation needs to be different for each operating system 
> and hardware architecture, as it runs as a machine language executable in the 
> operating system. It implements the details of managing memory, executing 
> Pharo byte-code, and communicating with the world outside of the Pharo 
> system: files, other op

[Pharo-users] Pharo Docs website broken

[David Allouche]

Hello,

It seems the pharodocs website is broken. Pages for classes are rendered, but 
the documentation does not display the messages, only their docstrings. That 
makes it quite unusable.

http://files.pharo.org/doc/4.0/#packageList=package.html=package/Kernel.html=class/ProtoObject.html
 


I remember I looked at it once when I started and thought "whee, that's 
confusing, I'll play around and come back later". Now I understand why that was 
confusing...

Who can fix that?

[Pharo-users] I am David Allouche, let me introduce myself.

[David Allouche]

Hello folks.

Some people have already seen me on Twitter and Slack, but I believe there 
might be some people on the mailing list that did not see those conversations.

As I have done on Slack, I am writing this introduction so people have an idea 
where I come from and what is my business with Pharo.

I am a professional programmer. My current job is tech on a small company I run 
with two associates (by the way, we are hiring a good Python web dev with a 
passion for good code). The product is a SaaS web application for recruiters. 
They call that an Application Tracking System, it is a workflow, communication 
and archival system for job applications and candidates.

I started programming 25 years ago with HyperCard, and since I have at least 
played with Pascal, C, Prograph, asm68k, HP-48 (RPL, Saturn asm), Java, bash, 
C++, LaTeX, XSLT, Delphi, Scheme, elisp, JavaScript.

I have contributed to GNU TeXmacs where I made important contributinos during 
about 2 years, as I completed by training as an software engineer, and worked 
at CNRS in Rennes. Then I got involved in GNU Arch (wrote a Python driver), 
Bazaar (bzr scm) where I worked with the founding team at Canonical while 
working on the version control aspect of launchpad.net . 
After that, I had mostly no contribution to free software, working on financial 
modeling at a bank and then on my current business. I made a presentation on 
SQLAlchemy at PyCon.fr  2015.

I am a fan Design Patterns (GoF) and the Refactoring book. My mentor at 
Canonical (Robert Collins) is heavily influenced by Smalltalk and championed XP 
there. I always had strong interests in software systems design, programming 
language design, typography, and user interface design. I feel strongly for the 
concept of software craftsmanship.

My current job is nice, good pay, lots of independence ; after 6 years working 
on the same project, I need some fresh intellectual stimulation. And I was 
recently impressed by the presentation "Nothing is Something", by Sandi Metz, 
who is heavily influenced by Smalltalk.

http://confreaks.tv/videos/bathruby2015-nothing-is-something 


So, I here I came, bumbling my way around the system, looking for intellectual 
stimulation, and for a way to make a positive contribution.

I was very impressed by the nice welcome I have received. And I see there is 
lots of useful work to do here.

So that's where I come from when you see me chipping in the conversation here.

Regards.

Re: [Pharo-users] Pharo Docs website broken

[David Allouche]

I could argue about how I agree with you, but only in part.

But the simple fact is this: the documentation is advertised in large letter on 
this page: http://pharo.org/documentation

If it's broken, it should be fixed. If the people with the technical access to 
fix it do not care, it should be removed from such a highly visible page.

As it is, it is confusing for new users, who need it most, and reflects badly 
on the state of Pharo in general.

> On 10 Jan 2016, at 22:25, Serge Stinckwich <serge.stinckw...@gmail.com> wrote:
> 
> Dear David,
> 
> yes this maybe broken, but most of the time, a Pharo developer will
> never have a look to such a static documentation.
> You can browse the class and the related methods very easily inside
> the Pharo image, without relying on an external tool.
> 
> Regards,
> 
> On Sun, Jan 10, 2016 at 1:08 PM, David Allouche <da...@allouche.net> wrote:
>> Hello,
>> 
>> It seems the pharodocs website is broken. Pages for classes are rendered,
>> but the documentation does not display the messages, only their docstrings.
>> That makes it quite unusable.
>> 
>> http://files.pharo.org/doc/4.0/#packageList=package.html=package/Kernel.html=class/ProtoObject.html
>> 
>> I remember I looked at it once when I started and thought "whee, that's
>> confusing, I'll play around and come back later". Now I understand why that
>> was confusing...
>> 
>> Who can fix that?
> 
> 
> 
> -- 
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
> 

[Pharo-users] Ctrl-tab not working

[David Allouche]

> On 5 Jan 2016, at 15:03, Thierry Goubier <thierry.goub...@gmail.com> wrote:
> 
> 2016-01-05 14:42 GMT+01:00 David Allouche <da...@allouche.net 
> <mailto:da...@allouche.net>>:
> Strangely, I am not able get any response from Ctrl-TAB, which is essential 
> to tab out of a text widget.
> 
> Looking with the inspector, it looks like it SHOULD do what I need, but it 
> appears that the keyboard event does not get there.
> 
> How can I get a transcript output for every detected keyboard event? I 
> suspect that maybe something system-wide in MacOS is intercepting the event.
> 
> At high level, do
> 
> KMLog setDebug
> 
> (and get a transcript open)
> 
> to stop it, do
> 
> KMLog removeDebug.
> 
> (This will give you Keymapping behavior, but remember that: any app can add a 
> key processing on a morph instance manually, and that many morphs have 
> hardwired shortcuts such as navigation keys)
> 
> At a lower level, you can trace or add a watchpoint inside:
> 
> HandMorph>>#generateKeyboardEvent:
> 
> Use that if you don't see your ctrl+tab at the Keymapping level.
> 
> Thierry
>  

Thanks.

I added some logging statements to HandMorph>>#generateKeyboardEvent: and they 
show that this method is not run at all for Ctrl-Tab keyDown events.

But it is run for Ctrl-Tab  keyUp events, and it returns a keyEvent for those.

It does not look like there is a OS level shortcut override for Ctrl-Tab, since 
it works correctly, in Safari for example (switch tabs).

Could it be a bug in the VM? I am running the Pharo 4.0 release VM and image.

Can anyone else running MacOS can confirm that Ctrl-TAB works for them in Pharo?