[Pharo-dev] Re: [ANN] Pharo Launcher 3.0 released!

[Jimmie Houchin]

Hello,

Thanks for all your work. I have only recently started using Pharo 
Launcher. I have been using Pharo a long time and was very accustomed to 
managing my own images. So I am still learning. It is nice to work with 
and it is nice to easily have whichever vm or image you are wanting to 
start with.


However I would like one thing if possible. The advantage I had when 
managing my own and I can do a combination. Is that I always started a 
new terminal and then opened up Pharo and whichever image I wanted. This 
makes it neat and clean when running multiple images like I do, to have 
clean messaging and clean stdio when I write to stdio. With Pharo 
Launcher all stdio goes to its terminal and from whichever image has 
been started. I don't know how difficult this would be. But it would be 
nice if they were an option for Pharo Launcher to startup the new image 
from its own new terminal. Just an idea.


Again. Thanks for all the work you do.

Jimmie


On 4/14/22 07:26, Christophe Demarey wrote:

Hi all,

Pharo Launcher 3.0 has just been released! It is available from 
http://pharo.org/download.

It is based on latest Spec2 and Pharo 10 image.
It now comes with a native Apple Silicon version and Mac OS packages 
are notarized.

Big thanks to all contributors, including issue reports.

Here is the changelog:
Pharo Launcher v3.0

New features:

  * Full rewrite of the UI using Spec 2 and Pharo 10
  * Pharo Launcher can now run natively on Apple Silicon #544

  * Pharo Launcher is now signed with a Mac Os developper account and
notarized #529

  * Windows "portable" package (only an archive without installer)
#534 

Improvements:

  * While importing image .sources and .version are not moved #543

  * recreate the image does not re apply the script if one is provided
#536 
(thanks to @hogoww )
  * Save keybind for scripts #545
 (thanks
to @hogoww  and @Inao0
)

Bug fixes:

  * GitHub releases artefacts download were not always working #535

  * "Basic launch" does not do its job in Pharo 10 #540

  * Proxy settings not applied through settings screen #541



Regards,
The Pharo team.

[Pharo-dev] Re: Helping with documentation

[Jimmie Houchin]

On 1/13/22 06:14, stephane ducasse wrote:

On 12 Jan 2022, at 02:03, Jimmie Houchin  wrote:

I am going to be working my way through some Pharo docs.

As I read the books I sometimes see some English that can be improved.

Yes I noticed it too but I’m running too fast and my english is not my native 
language so
it is not good.


Your English is just fine. Probably better than half of Americans. :)
But there are probably things that are definitely more noticeable to 
native English speakers.



But it is easy to make mistakes and hard to see your own mistakes. I 
regularly create documents and then let the stakeholders review for any 
mistakes. Frequently the stakeholders will sign off on it. Then days 
later come back with corrections. Proofreading is hard.



What is the proper procedure for doing so?

Any pointers to documents to help with this greatly appreciated.

Oh this is easy just send small PRs and I will read and integrate them.
Thanks in advance because this is important to get better documentation.


I have been a lazy Pharo user for a long time. I always found the Pharo 
environment productive and easy to use and never pursued properly 
learning to be a good Pharo user. I want to remedy that and work my way 
through several of the books. I figure that is a good time to contribute 
like this.


I will keep them coming as I work my way through the books.

Good to be a contributing citizen. :)


Jimmie


S


Thanks.


Jimmie

[Pharo-dev] Helping with documentation

[Jimmie Houchin]

I am going to be working my way through some Pharo docs.

As I read the books I sometimes see some English that can be improved.

What is the proper procedure for doing so?

Any pointers to documents to help with this greatly appreciated.


Thanks.


Jimmie

[Pharo-dev] Re: Array sum. is very slow

[Jimmie Houchin]

Thanks for the comments.

They are very true.

Jimmie


On 1/11/22 04:49, Nicolas Anquetil wrote:

Hi,

don'tforget to weight in your time too.

The ease to develop AND evolve a program is an important aspect that
the benchmarks don't show.

Nowdays, developer time count often more than processing time because
you may easily spent days on a nasty bug or an unplanned evolution.

have a nice day

nicolas

On Mon, 2022-01-10 at 14:05 -0600, Jimmie Houchin wrote:

Some experiments and discoveries.
I am running my full language test every time. It is the only way I
can compare results. It is also what fully stresses the language.
The reason I wrote the test as I did is because I wanted to know a
couple of things. Is the language sufficiently performant on basic
maths. I am not doing any high PolyMath level math. Simple things
like moving averages over portions of arrays.
The other is efficiency of array iteration and access. This why #sum
is the best test of this attribute. #sum iterates and accesses every
element of the array. It will reveal if there are any problems.
The default test  Julia 1m15s, Python 24.5 minutes, Pharo 2hour
4minutes.
When I comment out the #sum and #average calls, Pharo completes the
test in 3.5 seconds. So almost all the time is spent in those two
calls.
So most of this conversation has focused on why #sum is as slow as it
is or how to improve the performance of #sum with other
implementations.

  
So I decided to breakdown the #sum and try some things.

Starting with the initial implementation and SequenceableCollection's
default #sum  time of 02:04:03

"This implementation does no work. Only iterates through the array.
It completed in 00:10:08"
  sum
  | sum |
       sum := 1.
  1 to: self size do: [ :each | ].
  ^ sum
  
  
  "This implementation does no work, but adds to iteration, accessing

the value of the array.
It completed in 00:32:32.
Quite a bit of time for simply iterating and accessing."
  sum
  | sum |
  sum := 1.
  1 to: self size do: [ :each | self at: each ].
  ^ sum
  
  
  "This implementation I had in my initial email as an experiment and

also several other did the same in theirs.
A naive simple implementation.
It completed in 01:00:53.  Half the time of the original."
  sum
     | sum |
  sum := 0.
  1 to: self size do: [ :each |
      sum := sum + (self at: each) ].
  ^ sum
  
  
  
  "This implementation I also had in my initial email as an experiment

I had done.
It completed in 00:50:18.
It reduces the iterations and increases the accesses per iteration.
It is the fastest implementation so far."
  sum
  | sum |
  sum := 0.
  1 to: ((self size quo: 10) * 10) by: 10 do: [ :i |
      sum := sum + (self at: i) + (self at: (i + 1)) + (self at:
(i + 2)) + (self at: (i + 3)) + (self at: (i + 4))              +
(self at: (i + 5)) + (self at: (i + 6)) + (self at: (i + 7)) + (self
at: (i + 8)) + (self at: (i + 9))].
  
  ((self size quo: 10) * 10 + 1) to: self size do: [ :i |

      sum := sum + (self at: i)].
        ^ sum
  
Summary

For whatever reason iterating and accessing on an Array is expensive.
That alone took longer than Python to complete the entire test.
  
  I had allowed this knowledge of how much slower Pharo was to stop me

from using Pharo. Encouraged me to explore other options.
  
  I have the option to use any language I want. I like Pharo. I do not

like Python at all. Julia is unexciting to me. I don't like their
anti-OO approach.
  
  At one point I had a fairly complete Pharo implementation, which is

where I got frustrated with backtesting taking days.
  
  That implementation is gone. I had not switched to Iceberg. I had a

problem with my hard drive. So I am starting over.
I am not a computer scientist, language expert, vm expert or anyone
with the skills to discover and optimize arrays. So I will end my
tilting at windmills here.
I value all the other things that Pharo brings, that I miss when I am
using Julia or Python or Crystal, etc. Those languages do not have
the vision to do what Pharo (or any Smalltalk) does.
Pharo may not optimize my app as much as x,y or z. But Pharo
optimized me.
That said, I have made the decision to go all in with Pharo. Set
aside all else.
  In that regard I went ahead and put my money in with my decision and
joined the Pharo Association last week.
Thanks for all of your help in exploring the problem.

Jimmie Houchin
  

[Pharo-dev] Re: Array sum. is very slow

[Jimmie Houchin]

Personally I am okay with Python implementing in C. That is their 
implementation detail. It does not impose anything on the user other 
than knowing normal Python. It isn't cheating or unfair. They are under 
no obligation to handicap themselves so that we can be more comparable.


Are we going to put such requirements on C, C++, Julia, Crystal, Nim?

I expect every language to put forth its best. I would like the same for 
Pharo. And let the numbers fall where they may.


Jimmie



On 1/11/22 03:07, Andrei Chis wrote:

Hi Jimmie,

I was scanning through this thread and saw that the Python call uses
the sum function. If I remember correctly, in Python the built-in sum
function is directly implemented in C [1] (unless Python is compiled
with SLOW_SUM set to true). In that case on large arrays the function
can easily be several times faster than just iterating over the
individual objects as the Pharo code does. The benchmark seems to
compare summing numbers in C with summing numbers in Pharo. Would be
interesting to modify the Python code to use a similar loop as in
Pharo for doing the sum.

Cheers,
Andrei

[1] 
https://github.com/python/cpython/blob/135cabd328504e1648d17242b42b675cdbd0193b/Python/bltinmodule.c#L2461

On Mon, Jan 10, 2022 at 9:06 PM Jimmie Houchin  wrote:

Some experiments and discoveries.

I am running my full language test every time. It is the only way I can compare 
results. It is also what fully stresses the language.

The reason I wrote the test as I did is because I wanted to know a couple of 
things. Is the language sufficiently performant on basic maths. I am not doing 
any high PolyMath level math. Simple things like moving averages over portions 
of arrays.

The other is efficiency of array iteration and access. This why #sum is the 
best test of this attribute. #sum iterates and accesses every element of the 
array. It will reveal if there are any problems.

The default test  Julia 1m15s, Python 24.5 minutes, Pharo 2hour 4minutes.

When I comment out the #sum and #average calls, Pharo completes the test in 3.5 
seconds. So almost all the time is spent in those two calls.

So most of this conversation has focused on why #sum is as slow as it is or how 
to improve the performance of #sum with other implementations.



So I decided to breakdown the #sum and try some things.

Starting with the initial implementation and SequenceableCollection's default 
#sum  time of 02:04:03


"This implementation does no work. Only iterates through the array.
It completed in 00:10:08"
sum
 | sum |
  sum := 1.
 1 to: self size do: [ :each | ].
 ^ sum


"This implementation does no work, but adds to iteration, accessing the value 
of the array.
It completed in 00:32:32.
Quite a bit of time for simply iterating and accessing."
sum
 | sum |
 sum := 1.
 1 to: self size do: [ :each | self at: each ].
 ^ sum


"This implementation I had in my initial email as an experiment and also 
several other did the same in theirs.
A naive simple implementation.
It completed in 01:00:53.  Half the time of the original."
sum
| sum |
 sum := 0.
 1 to: self size do: [ :each |
 sum := sum + (self at: each) ].
 ^ sum



"This implementation I also had in my initial email as an experiment I had done.
It completed in 00:50:18.
It reduces the iterations and increases the accesses per iteration.
It is the fastest implementation so far."
sum
 | sum |
 sum := 0.
 1 to: ((self size quo: 10) * 10) by: 10 do: [ :i |
 sum := sum + (self at: i) + (self at: (i + 1)) + (self at: (i + 2)) + 
(self at: (i + 3)) + (self at: (i + 4))  + (self at: (i + 5)) + 
(self at: (i + 6)) + (self at: (i + 7)) + (self at: (i + 8)) + (self at: (i + 
9))].

 ((self size quo: 10) * 10 + 1) to: self size do: [ :i |
 sum := sum + (self at: i)].
   ^ sum

Summary

For whatever reason iterating and accessing on an Array is expensive. That 
alone took longer than Python to complete the entire test.

I had allowed this knowledge of how much slower Pharo was to stop me from using 
Pharo. Encouraged me to explore other options.

I have the option to use any language I want. I like Pharo. I do not like 
Python at all. Julia is unexciting to me. I don't like their anti-OO approach.

At one point I had a fairly complete Pharo implementation, which is where I got 
frustrated with backtesting taking days.

That implementation is gone. I had not switched to Iceberg. I had a problem 
with my hard drive. So I am starting over.

I am not a computer scientist, language expert, vm expert or anyone with the 
skills to discover and optimize arrays. So I will end my tilting at windmills 
here.

I value all the other things that Pharo brings, that I miss when I am using 
Julia or Python or Crystal, etc. Those languages do not have the vision to do 
what Pharo (or any Smalltalk) does.

Pharo may not optimize my app as much as x,y or 

[Pharo-dev] Re: Array sum. is very slow

[Jimmie Houchin]

Some experiments and discoveries.

I am running my full language test every time. It is the only way I can 
compare results. It is also what fully stresses the language.


The reason I wrote the test as I did is because I wanted to know a 
couple of things. Is the language sufficiently performant on basic 
maths. I am not doing any high PolyMath level math. Simple things like 
moving averages over portions of arrays.


The other is efficiency of array iteration and access. This why #sum is 
the best test of this attribute. #sum iterates and accesses every 
element of the array. It will reveal if there are any problems.


The default test  Julia 1m15s, Python 24.5 minutes, Pharo 2hour 4minutes.

When I comment out the #sum and #average calls, Pharo completes the test 
in 3.5 seconds. So almost all the time is spent in those two calls.


So most of this conversation has focused on why #sum is as slow as it is 
or how to improve the performance of #sum with other implementations.




So I decided to breakdown the #sum and try some things.

Starting with the initial implementation and SequenceableCollection's 
default #sum  time of 02:04:03



/"This implementation does no work. Only iterates through the array.//
//It completed in 00:10:08"/
sum
    | sum |
   sum := 1.
    1 to: self size do: [ :each | ].
    ^ sum


/"This implementation does no work, but adds to iteration, accessing the 
value of the array.//

//It completed in 00:32:32.//
//Quite a bit of time for simply iterating and accessing."/
sum
    | sum |
    sum := 1.
    1 to: self size do: [ :each | self at: each ].
    ^ sum


/"This implementation I had in my initial email as an experiment and 
also several other did the same in theirs.//

//A naive simple implementation.//
//It completed in 01:00:53.  Half the time of the original."/
sum
   | sum |
    sum := 0.
    1 to: self size do: [ :each |
        sum := sum + (self at: each) ].
    ^ sum



/"This implementation I also had in my initial email as an experiment I 
had done.//

//It completed in 00:50:18.//
//It reduces the iterations and increases the accesses per iteration.//
//It is the fastest implementation so far."/
sum
    | sum |
    sum := 0.
    1 to: ((self size quo: 10) * 10) by: 10 do: [ :i |
        sum := sum + (self at: i) + (self at: (i + 1)) + (self at: (i + 
2)) + (self at: (i + 3)) + (self at: (i + 4))  + (self at: (i + 5)) + 
(self at: (i + 6)) + (self at: (i + 7)) + (self at: (i + 8)) + (self at: 
(i + 9))].


    ((self size quo: 10) * 10 + 1) to: self size do: [ :i |
        sum := sum + (self at: i)].
    ^ sum

*Summary
*

For whatever reason iterating and accessing on an Array is expensive. 
That alone took longer than Python to complete the entire test.


I had allowed this knowledge of how much slower Pharo was to stop me 
from using Pharo. Encouraged me to explore other options.


I have the option to use any language I want. I like Pharo. I do not 
like Python at all. Julia is unexciting to me. I don't like their 
anti-OO approach.


At one point I had a fairly complete Pharo implementation, which is 
where I got frustrated with backtesting taking days.


That implementation is gone. I had not switched to Iceberg. I had a 
problem with my hard drive. So I am starting over.


I am not a computer scientist, language expert, vm expert or anyone with 
the skills to discover and optimize arrays. So I will end my tilting at 
windmills here.


I value all the other things that Pharo brings, that I miss when I am 
using Julia or Python or Crystal, etc. Those languages do not have the 
vision to do what Pharo (or any Smalltalk) does.


Pharo may not optimize my app as much as x,y or z. But Pharo optimized me.

That said, I have made the decision to go all in with Pharo. Set aside 
all else.
In that regard I went ahead and put my money in with my decision and 
joined the Pharo Association last week.


Thanks for all of your help in exploring the problem.


Jimmie Houchin

[Pharo-dev] Re: Array sum. is very slow

[Jimmie Houchin]

Hello Sven,

I went and removed the Stdouts that you mention and other timing code 
from the loops.


I am running the test now, to see if that makes much difference. I do 
not think it will.


The reason I put that in there is because it take so long to run. It can 
be frustrating to wait and wait and not know if your test is doing 
anything or not. So I put the code in to let me know.


One of your parameters is incorrect. It is 100 iterations not 10.

I learned early on in this experiment that I have to do a large number 
of iterations or C, C++, Java, etc are too fast to have comprehensible 
results.


I can tell if any of the implementations is incorrect by the final nsum. 
All implementations must produce the same result.


Thanks for the comments.

Jimmie


On 1/7/22 07:40, Sven Van Caekenberghe wrote:

Hi Jimmie,

I loaded your code in Pharo 9 on my MacBook Pro (Intel i5) macOS 12.1

I commented out the Stdio logging from the 2 inner loops (#loop1, #loop2) (not 
done in Python either) as well as the MessageTally spyOn: from #run (slows 
things down).

Then I ran your code with:

[ (LanguageTest newSize: 60*24*5*4 iterations: 10) run ] timeToRun.

which gave me "0:00:09:31.338"

The console output was:

===
Starting test for array size: 28800  iterations: 10

Creating array of size: 28800   timeToRun: 0:00:00:00.031

Starting loop 1 at: 2022-01-07T14:10:35.395394+01:00
Loop 1 time: nil
nsum: 11234.235001659388
navg: 0.39007760422428434

Starting loop 2 at: 2022-01-07T14:15:22.108433+01:00
Loop 2 time: 0:00:04:44.593
nsum: 11245.697629561537
navg: 0.3904756121375534

End of test.  TotalTime: 0:00:09:31.338
===

Which would be twice as fast as Python, if I got the parameters correct.

Sven


On 7 Jan 2022, at 13:19, Jimmie Houchin  wrote:

As I stated this is a micro benchmark and very much not anything resembling a 
real app, Your comments are true if you are writing your app. But if you want 
to stress the language you are going to do things which are seemingly non-sense 
and abusive.

Also as I stated. The test has to be sufficient to stress faster languages or 
it is meaningless.

If I remove the #sum and the #average calls from the inner loops, this is what 
we get.

Julia  0.2256 seconds
Python   5.318  seconds
Pharo3.5seconds

This test does not sufficiently stress the language. Nor does it provide any 
valuable insight into summing and averaging which is done a lot, in lots of 
places in every iteration.

If you notice that inner array changes the array every iteration. So every call 
to #sum and #average is getting different data.

Full Test

Julia 1.13  minutes
Python   24.02 minutes
Pharo2:09:04

Code for the above is now published. You can let me know if I am doing 
something unequal to the various languages.

And just remember anything you do which sufficiently changes the test has to be 
done in all the languages to give a fair test. This isn't a lets make Pharo 
look good test. I do want Pharo to look good, but honestly.

Yes, I know that I can bind to BLAS or other external libraries. But that is 
not a test of Pharo. The Python is plain Python3 no Numpy, just using the the 
default list [] for the array.

Julia is a whole other world. It is faster than Numpy. This is their domain and 
they optimize, optimize, optimize all the math. In fact they have reached the 
point that some pure Julia code beats pure Fortran.

In all of this I just want Pharo to do the best it can.

With the above results unless you already had an investment in Pharo, you 
wouldn't even look. :(

Thanks for exploring this with me.


Jimmie




On 1/6/22 18:24, John Brant wrote:

On Jan 6, 2022, at 4:35 PM, Jimmie Houchin  wrote:

No, it is an array of floats. The only integers in the test are in the indexes 
of the loops.

Number random. "generates a float  0.8188008774329387"

So in the randarray below it is an array of 28800 floats.

It just felt so wrong to me that Python3 was so much faster. I don't care if 
Nim, Crystal, Julia are faster. But...


I am new to Iceberg and have never shared anything on Github so this is all new 
to me. I uploaded my language test so you can see what it does. It is a 
micro-benchmark. It does things that are not realistic in an app. But it does 
stress a language in areas important to my app.


https://github.com/jlhouchin/LanguageTestPharo


Let me know if there is anything else I can do to help solve this problem.

I am a lone developer in my spare time. So my apologies for any ugly code.


Are you sure that you have the same algorithm in Python? You are calling sum 
and average inside the loop where you are modifying the array:

1 to: nsize do: [ :j || n |
n := narray at: j.
narray at: j put: (self loop1calc: i j: j n: n).
nsum := narray sum.
navg := narray average ]

As a result, you are calculating the sum of the 28,800 size array 28,800 times (plus 

[Pharo-dev] Re: Array sum. is very slow

[Jimmie Houchin]

As I stated this is a micro benchmark and very much not anything 
resembling a real app, Your comments are true if you are writing your 
app. But if you want to stress the language you are going to do things 
which are seemingly non-sense and abusive.


Also as I stated. The test has to be sufficient to stress faster 
languages or it is meaningless.


If I remove the #sum and the #average calls from the inner loops, this 
is what we get.


Julia      0.2256 seconds
Python   5.318  seconds
Pharo    3.5    seconds

This test does not sufficiently stress the language. Nor does it provide 
any valuable insight into summing and averaging which is done a lot, in 
lots of places in every iteration.


If you notice that inner array changes the array every iteration. So 
every call to #sum and #average is getting different data.


Full Test

Julia 1.13  minutes
Python   24.02 minutes
Pharo    2:09:04

Code for the above is now published. You can let me know if I am doing 
something unequal to the various languages.


And just remember anything you do which sufficiently changes the test 
has to be done in all the languages to give a fair test. This isn't a 
lets make Pharo look good test. I do want Pharo to look good, but honestly.


Yes, I know that I can bind to BLAS or other external libraries. But 
that is not a test of Pharo. The Python is plain Python3 no Numpy, just 
using the the default list [] for the array.


Julia is a whole other world. It is faster than Numpy. This is their 
domain and they optimize, optimize, optimize all the math. In fact they 
have reached the point that some pure Julia code beats pure Fortran.


In all of this I just want Pharo to do the best it can.

With the above results unless you already had an investment in Pharo, 
you wouldn't even look. :(


Thanks for exploring this with me.


Jimmie




On 1/6/22 18:24, John Brant wrote:

On Jan 6, 2022, at 4:35 PM, Jimmie Houchin  wrote:

No, it is an array of floats. The only integers in the test are in the indexes 
of the loops.

Number random. "generates a float  0.8188008774329387"

So in the randarray below it is an array of 28800 floats.

It just felt so wrong to me that Python3 was so much faster. I don't care if 
Nim, Crystal, Julia are faster. But...


I am new to Iceberg and have never shared anything on Github so this is all new 
to me. I uploaded my language test so you can see what it does. It is a 
micro-benchmark. It does things that are not realistic in an app. But it does 
stress a language in areas important to my app.


https://github.com/jlhouchin/LanguageTestPharo


Let me know if there is anything else I can do to help solve this problem.

I am a lone developer in my spare time. So my apologies for any ugly code.


Are you sure that you have the same algorithm in Python? You are calling sum 
and average inside the loop where you are modifying the array:

1 to: nsize do: [ :j || n |
n := narray at: j.
narray at: j put: (self loop1calc: i j: j n: n).
nsum := narray sum.
navg := narray average ]

As a result, you are calculating the sum of the 28,800 size array 28,800 times (plus 
another 28,800 times for the average). If I write a similar loop in Python, it looks 
like it would take almost 9 minutes on my machine without using numpy to calculate 
the sum. The Pharo code takes ~40 seconds. If this is really how the code should be, 
then I would change it to not call sum twice (once for sum and once in average). This 
will almost result in a 2x speedup. You could also modify the algorithm to update the 
nsum value in the loop instead of summing the array each time. I think the updating 
would require <120,000 math ops vs the >1.6 billion that you are performing.


John Brant

[Pharo-dev] Re: Array sum. is very slow

[Jimmie Houchin]

No, it is an array of floats. The only integers in the test are in the 
indexes of the loops.


Number random. "generates a float  0.8188008774329387"

So in the randarray below it is an array of 28800 floats.

It just felt so wrong to me that Python3 was so much faster. I don't 
care if Nim, Crystal, Julia are faster. But...



I am new to Iceberg and have never shared anything on Github so this is 
all new to me. I uploaded my language test so you can see what it does. 
It is a micro-benchmark. It does things that are not realistic in an 
app. But it does stress a language in areas important to my app.



https://github.com/jlhouchin/LanguageTestPharo


Let me know if there is anything else I can do to help solve this problem.

I am a lone developer in my spare time. So my apologies for any ugly code.


Thanks for your help.

Jimmie


On 1/6/22 15:07, Guillermo Polito wrote:

Hi Jummie,

Is it possible that your program is computing a lot of **very** large integers?

I’m just trying the following with small numbers, and I don’t see the issue. 
#sum executes on a 28k large collection around 20 million times per second on 
my old 2015 i5.

a := (1 to: 28000).
[a sum] bench "'20256552.490 per second’"

If you could share with us more data, we could take a look.
Now i’m curious.

Thanks,
G


El 6 ene 2022, a las 21:37, Jimmie Houchin  escribió:

I have written a micro benchmark which stresses a language in areas which are 
crucial to my application.

I have written this micro benchmark in Pharo, Crystal, Nim, Python, PicoLisp, 
C, C++, Java and Julia.

On my i7 laptop Julia completes it in about 1 minute and 15 seconds, amazing 
magic they have done.

Crystal and Nim do it in about 5 minutes. Python in about 25 minutes. Pharo 
takes over 2 hours. :(

In my benchmarks if I comment out the sum and average of the array. It 
completes in 3.5 seconds.
And when I sum the array it gives the correct results. So I can verify its 
validity.

To illustrate below is some sample code of what I am doing. I iterate over the 
array and do calculations on each value of the array and update the array and 
sum and average at each value simple to stress array access and sum and average.

28800 is simply derived from time series one minute values for 5 days, 4 weeks.

randarray := Array new: 28800.

1 to: randarray size do: [ :i | randarray at: i put: Number random ].

randarrayttr := [ 1 to: randarray size do: [ :i | "other calculations here." 
randarray sum. randarray average ]] timeToRun.

randarrayttr. "0:00:00:36.135"


I do 2 loops with 100 iterations each.

randarrayttr * 200. "0:02:00:27"


I learned early on in this adventure when dealing with compiled languages that 
if you don’t do a lot, the test may not last long enough to give any times.

Pharo is my preference. But this is an awful big gap in performance. When doing 
backtesting this is huge. Does my backtest take minutes, hours or days?

I am not a computer scientist nor expert in Pharo or Smalltalk. So I do not 
know if there is anything which can improve this.


However I have played around with several experiments of my #sum: method.

This implementation reduces the time on the above randarray in half.

sum: col
| sum |
sum := 0.
1 to: col size do: [ :i |
  sum := sum + (col at: i) ].
^ sum

randarrayttr2 := [ 1 to: randarray size do: [ :i | "other calculations here."
 ltsa sum: randarray. ltsa sum: randarray ]] timeToRun.
randarrayttr2. "0:00:00:18.563"

And this one reduces it a little more.

sum10: col
| sum |
sum := 0.
1 to: ((col size quo: 10) * 10) by: 10 do: [ :i |
  sum := sum + (col at: i) + (col at: (i + 1)) + (col at: (i + 2)) + (col 
at: (i + 3)) + (col at: (i + 4))
  + (col at: (i + 5)) + (col at: (i + 6)) + (col at: (i + 7)) + (col 
at: (i + 8)) + (col at: (i + 9))].
((col size quo: 10) * 10 + 1) to: col size do: [ :i |
  sum := sum + (col at: i)].
^ sum

randarrayttr3 := [ 1 to: randarray size do: [ :i | "other calculations here."
 ltsa sum10: randarray. ltsa sum10: randarray ]] timeToRun.
randarrayttr3. "0:00:00:14.592"

It closes the gap with plain Python3 no numpy. But that is a pretty low 
standard.

Any ideas, thoughts, wisdom, directions to pursue.

Thanks

Jimmie

[Pharo-dev] Array sum. is very slow

[Jimmie Houchin]

I have written a micro benchmark which stresses a language in areas 
which are crucial to my application.


I have written this micro benchmark in Pharo, Crystal, Nim, Python, 
PicoLisp, C, C++, Java and Julia.


On my i7 laptop Julia completes it in about 1 minute and 15 seconds, 
amazing magic they have done.


Crystal and Nim do it in about 5 minutes. Python in about 25 minutes. 
Pharo takes over 2 hours. :(


In my benchmarks if I comment out the sum and average of the array. It 
completes in 3.5 seconds.
And when I sum the array it gives the correct results. So I can verify 
its validity.


To illustrate below is some sample code of what I am doing. I iterate 
over the array and do calculations on each value of the array and update 
the array and sum and average at each value simple to stress array 
access and sum and average.


28800 is simply derived from time series one minute values for 5 days, 4 
weeks.


randarray := Array new: 28800.

1 to: randarray size do: [ :i | randarray at: i put: Number random ].

randarrayttr := [ 1 to: randarray size do: [ :i | "other calculations 
here." randarray sum. randarray average ]] timeToRun.


randarrayttr. "0:00:00:36.135"


I do 2 loops with 100 iterations each.

randarrayttr * 200. "0:02:00:27"


I learned early on in this adventure when dealing with compiled 
languages that if you don’t do a lot, the test may not last long enough 
to give any times.


Pharo is my preference. But this is an awful big gap in performance. 
When doing backtesting this is huge. Does my backtest take minutes, 
hours or days?


I am not a computer scientist nor expert in Pharo or Smalltalk. So I do 
not know if there is anything which can improve this.



However I have played around with several experiments of my #sum: method.

This implementation reduces the time on the above randarray in half.

sum: col
| sum |
sum := 0.
1 to: col size do: [ :i |
 sum := sum + (col at: i) ].
^ sum

randarrayttr2 := [ 1 to: randarray size do: [ :i | "other calculations 
here."

    ltsa sum: randarray. ltsa sum: randarray ]] timeToRun.
randarrayttr2. "0:00:00:18.563"

And this one reduces it a little more.

sum10: col
| sum |
sum := 0.
1 to: ((col size quo: 10) * 10) by: 10 do: [ :i |
 sum := sum + (col at: i) + (col at: (i + 1)) + (col at: (i + 2)) + 
(col at: (i + 3)) + (col at: (i + 4))
 + (col at: (i + 5)) + (col at: (i + 6)) + (col at: (i + 7)) + 
(col at: (i + 8)) + (col at: (i + 9))].

((col size quo: 10) * 10 + 1) to: col size do: [ :i |
 sum := sum + (col at: i)].
^ sum

randarrayttr3 := [ 1 to: randarray size do: [ :i | "other calculations 
here."

    ltsa sum10: randarray. ltsa sum10: randarray ]] timeToRun.
randarrayttr3. "0:00:00:14.592"

It closes the gap with plain Python3 no numpy. But that is a pretty low 
standard.


Any ideas, thoughts, wisdom, directions to pursue.

Thanks

Jimmie

Re: [Pharo-dev] Squeak and Pharo why the fork

[Jimmie Houchin]

On 5/16/20 3:56 AM, Shaping wrote:


Hi Jimmie.

On 5/15/20 5:26 AM, Shaping wrote:

I don’t understand the split.  It looks silly.  Maybe someone can
explain the split in terms of technical/architectural advantages,
if any exist.

[snip]

The Pink plane community wanted to begin to clean up Squeak. Break it 
up into parts which could be reloaded. It wanted a much more modular 
environment which allowed you to build the image you want for the 
purpose you intend.


The Blue plane community didn't see any problems with the way it was. 
They liked it and still do. It fit what they wanted to do with 
Squeak/Smalltalk. Frequently more research oriented and less business 
oriented.


Applied basic research is most of what I do.  I still want a clean, 
modular environment.  I don’t see how that interferes with creative 
verve.  It should help if only by limiting confusion and clarifying 
configurational choices.


The Squeak and Pharo communities are not unlimited in size and 
resources. When you have differing priorities and limited resources, you 
have to make choices. Choices you might not rather make. But you make 
them anyway. This is what happened. One group had their priorities and 
the other theirs. They each split and their respective communities and 
resources when the way of their priorities. Most of us did not want a 
split. But if one group constrains the other, there becomes no other option.


Then in the midst of all this you have overlap in individuals who 
understand both. You also had personality differences and 
disagreements which developed over years. Eventually the Pink plane 
community forked and created Pharo. The foundational community of 
Squeak (Blue plane) did not want to make the changes the Pink plane 
community wanted or required.


What are the specific changes that Squeak folks don’t want to make?

Squeak/Pharo is a configurable environment.  We can still have a 
quasi-OS world if we want that.  What specific aspects of the analytic 
and creative experience break or degrade for Squeak users with these 
specific changes, and also cannot be preserved by loading the right 
Smalltalk packages?


This is all true. And most of us do enjoy the quasi-OS world. We want 
that. We just don't want to deploy that with our application. Especially 
server-side apps who want to run well in a limited environment or an 
environment that costs per amount of memory, cpu time, etc.



Pharo is now 12 years or so into its journey. It is not easy losing 
weight and still keep working. But that is the goal of Pharo. Keep 
reducing until the entire system can be built up from a base image. 
And when it gets there. We don't have a problem with from that 
foundation, being able to build it back up into a Squeak-like image.


I have numerous projects which I am doing in Pharo. One is a trading 
application. I personally want as little in my image as possible which 
does not have to do with my trading application. It desires to be as 
fast as possible, run without failure, and as memory and cpu efficient 
as I can make it to be in Pharo. I could make and run this application 
in Squeak. But it would include much that I don't need and don't want. 
And that is the case in Pharo currently as well.


This points to needing more modularity, not less.  We want to unload 
all that we don’t want, in small or big pieces, easily and 
confidently, without breaking anything.  It sounds easy, but it’s not. 
I think this should be one of the Consortium’s main goals.


It is one of the Consortium's goals. However, it take time from highly 
skilled, dedicated people. Again, resources are limited. In people, 
money and time. So the priorities are directed. We will get there. But 
we are not there yet.


But Pharo has its philosophy and its direction that it is moving 
towards. At some point in time my trading application will what I want 
it to be with very little unused code in the image. That might not be 
until Pharo 10+. I don't know. But there is a vision within Pharo for 
people to build such applications.


Image minimization is a useful feature.   A Squeak user would want 
this too, at least when deploying.


Yes, but it is not their priority. They prioritize differently and 
within their limited resources.


I have not used Squeak in years. And nothing I write here is meant to 
speak badly about Squeak. I like the Squeak community. They are full 
of great people. And I do not know how accurate what I write is to the 
current Squeak. My apologies for any inaccuracies or errors.


Pharo in general is much more pro-business. It is an explicit goal of 
Pharo.

https://pharo.org/about
https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf

Both websites give you a feel for who the community is and the 
orientation of their goals.


As much as re-unification would be nice.

Logical and utilitarian.

I don't know that it will happen. At a minimum, not until the Squeak 
community could build Squeak 

[Pharo-dev] Squeak and Pharo why the fork - was: Squeak and Pharo speed differences

[Jimmie Houchin]

aro kernel image. Then it would be possible. But I don't think 
likely.


This is just my generalizations in an effort to answer your question. 
There are people who are in both communities. Both communities in 
general attempt to cooperate when we can. Both are communities with 
friendly, amazing people. And both communities have people who have been 
doing this for a very long time, and that is a very good thing.


Both are completely open source projects which will allow you to do 
whatever you want within your abilities and resources.


Basically it is simply this. Different visions for the direction of the 
project and the pursuit of those directions for an extended period of 
time. This email is an simplification of a lot discussions and debates 
over a period of years which finally lead to a fork of Squeak.


Hope this helps.

Jimmie Houchin

Re: [Pharo-dev] FloatArray

[Jimmie Houchin]

Not a problem. I greatly respective other peoples time and priorities 
and their personal lives.


Just for the record I am using 64bit Pharo on a fast i7, 16gb ram, 
laptop running Xubunut 18.04 64bit.


I do not remember any problems loading. And within the small amount of 
experimenting that I did, it seemed to operate fine.


Again, thanks for your contribution. I know it is a lot of work and a 
pretty large area to cover. Python/Numpy has armies of people working on 
this.


Jimmie


On 5/21/19 2:54 AM, Nicolas Cellier wrote:

Hi Jimmie,
I didn't take time yesterday to analyze your specific example because 
it was quite late, but here are some remarks:
1) First, I recommend using 64bits Pharo, because number crunching and 
Float operations will be faster (not FloatArray though).

2) it would be nice to use a profiler to analyze where time is spent
  I would not be amazed that (Float readFrom:...) takes a non 
neglectable percentage of it

3) ExternalDoubleArray only add overhead if no bulk-operation is performed
  (like reading raw binary data or serving as storage area passed to 
Lapack/blas primitives)

  it does not provide accelerated features by itself indeed.
  I think that it is too low level to serve as a primary interface.
4) LapackXXXMatrix sum has effectively not been optimized to use BLAS, 
and this can be easily corrected, thanks for giving this example.
With some cooperation, we could easily make some progress, there are 
low hanging fruits.

But I understand if you prefer to stick with more mature numpy solution.
Thanks for trying. At least, you were able to load and use Smallapack 
in Pharo, and this is already a good feedback.
If you have time, I'll publish a small enhancement for accelerating 
sum, and ask you to retry.

Thanks again


Le mar. 21 mai 2019 à 05:13, Serge Stinckwich 
mailto:serge.stinckw...@gmail.com>> a écrit :


There is another solution with my TensorFlow Pharo binding:
https://github.com/PolyMathOrg/libtensorflow-pharo-bindings

You can do a matrix multiplication like that :

| graph t1 t2 c1 c2 mult session result |
graph := TF_Graph create.
t1 := TF_Tensor fromFloats: (1 to:100) asArray shape:#(1000 1000).
t2 := TF_Tensor fromFloats: (1 to:100) asArray shape:#(1000 1000).
c1 := graph const: 'c1' value: t1.
c2 := graph const: 'c2' value: t2.
mult := c1 * c2.
session := TF_Session on: graph.
result := session runOutput: (mult output: 0).
result asNumbers

Here I'm doing a multiplication between 2 matrices of 1000X1000
size in 537 ms on my computer.

All operations can be done in a graph of operations that is run
outside Pharo, so could be very fast.
Operations can be done on CPU or GPU. 32 bits or 64 bits float
operations are possible.

This is a work in progress but can already be used.
Regards,



On Tue, May 21, 2019 at 6:54 AM Jimmie Houchin
mailto:jlhouc...@gmail.com>> wrote:

I wasn't worried about how to do sliding windows. My problem
is that using LapackDGEMatrix in my example was 18x slower
than FloatArray, which is slower than Numpy. It isn't what I
was expecting.

What I didn't know is if I was doing something wrong to cause
such a tremendous slow down.

Python and Numpy is not my favorite. But it isn't uncomfortable.

So I gave up and went back to Numpy.

Thanks.



On 5/20/19 5:17 PM, Nicolas Cellier wrote:

Hi Jimmie,
effectively I did not subsribe...
Having efficient methods for sliding window average is
possible, here is how I would do it:

"Create a vector with 100,000 rows filles with random values
(uniform distrubution in [0,1]"
v := LapackDGEMatrix randUniform: #(10 1).

"extract values from rank 10001 to 2"
w1 := v atIntervalFrom: 10001 to: 2 by: 1.

"create a left multiplier matrix for performing average of w1"
a := LapackDGEMatrix nrow: 1 ncol: w1 nrow withAll: 1.0 / w1
size.

"get the average (this is a 1x1 matrix from which we take
first element)"
avg1 := (a * w1) at: 1.

[ "select another slice of same size"
w2 := v atIntervalFrom: 15001 to: 25000 by: 1.

"get the average (we can recycle a)"
avg2 := (a * w2) at: 1 ] bench.

This gives:
 '16,500 per second. 60.7 microseconds per run.'
versus:
[w2 sum / w2 size] bench.
 '1,100 per second. 908 microseconds per run.'

For max and min, it's harder. Lapack/Blas only provide max of
absolute value as primitive:
[w2 absMax] bench.
 '19,400 per second. 51.5 microseconds per run.'

Everything else will be slower, unless we write new
primitives in C and connect them...
[w2 maxOf: [:each | each]] 

Re: [Pharo-dev] FloatArray

[Jimmie Houchin]

I wasn't worried about how to do sliding windows. My problem is that 
using LapackDGEMatrix in my example was 18x slower than FloatArray, 
which is slower than Numpy. It isn't what I was expecting.


What I didn't know is if I was doing something wrong to cause such a 
tremendous slow down.


Python and Numpy is not my favorite. But it isn't uncomfortable.

So I gave up and went back to Numpy.

Thanks.



On 5/20/19 5:17 PM, Nicolas Cellier wrote:

Hi Jimmie,
effectively I did not subsribe...
Having efficient methods for sliding window average is possible, here 
is how I would do it:


"Create a vector with 100,000 rows filles with random values (uniform 
distrubution in [0,1]"

v := LapackDGEMatrix randUniform: #(10 1).

"extract values from rank 10001 to 2"
w1 := v atIntervalFrom: 10001 to: 2 by: 1.

"create a left multiplier matrix for performing average of w1"
a := LapackDGEMatrix nrow: 1 ncol: w1 nrow withAll: 1.0 / w1 size.

"get the average (this is a 1x1 matrix from which we take first element)"
avg1 := (a * w1) at: 1.

[ "select another slice of same size"
w2 := v atIntervalFrom: 15001 to: 25000 by: 1.

"get the average (we can recycle a)"
avg2 := (a * w2) at: 1 ] bench.

This gives:
 '16,500 per second. 60.7 microseconds per run.'
versus:
[w2 sum / w2 size] bench.
 '1,100 per second. 908 microseconds per run.'

For max and min, it's harder. Lapack/Blas only provide max of absolute 
value as primitive:

[w2 absMax] bench.
 '19,400 per second. 51.5 microseconds per run.'

Everything else will be slower, unless we write new primitives in C 
and connect them...

[w2 maxOf: [:each | each]] bench.
 '984 per second. 1.02 milliseconds per run.'

Le dim. 19 mai 2019 à 14:58, Jimmie <mailto:jlhouc...@gmail.com>> a écrit :


On 5/16/19 1:26 PM, Nicolas Cellier wrote:> Any feedback on this?
 > Did someone tried to use Smallapack in Pharo?
 > Jimmie?
 >

I am going to guess that you are not on pharo-users. My bad.
I posted this in pharo-users as I it wasn't Pharo development
question.

I probably should have posted here or emailed you directly.

All I really need is good performance with a simple array of
floats. No
matrix math. Nothing complicated. Moving Averages over a slice of the
array. A variety of different averages, weighted, etc. Max/min of the
array. But just a single simple array.

Any help greatly appreciated.

Thanks.


On 4/28/19 8:32 PM, Jimmie Houchin wrote:
Hello,

I have installed Smallapack into Pharo 7.0.3. Thanks Nicholas.

I am very unsure on my use of Smallapack. I am not a mathematician or
scientist. However the only part of Smallapack I am trying to use
at the
moment is something that would  be 64bit and compare to FloatArray so
that I can do some simple accessing, slicing, sum, and average on
the array.

Here is some sample code I wrote just to play in a playground.

I have an ExternalDoubleArray, LapackDGEMatrix, and a FloatArray
samples. The ones not in use are commented out for any run.

fp is a download from
http://ratedata.gaincapital.com/2018/12%20December/EUR_USD_Week1.zip
and unzipped to a directory.

fp := '/home/jimmie/data/EUR_USD_Week1.csv'
index := 0.
pricesSum := 0.
asum := 0.
ttr := [
     lines := fp asFileReference contents lines allButFirst.
     a := ExternalDoubleArray new: lines size.
     "la := LapackDGEMatrix allocateNrow: lines size ncol: 1.
     a := la columnAt: 1."
     "a := FloatArray new: lines size."
     lines do: [ :line || parts price |
         parts := ',' split: line.
         index := index + 1.
         price := Float readFrom: (parts last).
         a at: index put: price.
         pricesSum := pricesSum + price.
         (index rem: 100) = 0 ifTrue: [
             asum := a sum.
      ]]] timeToRun.
{ index. pricesSum. asum. ttr }.
  "ExternalDoubleArray an Array(337588 383662.562762
383562.295613 0:00:01:59.885)"
  "FloatArray  an Array(337588 383662.562762 383562.2954441309
0:00:00:06.555)"

FloatArray is not the precision I need. But it is over 18x faster.

I am afraid I must be doing something badly wrong. Python/Numpy is
over
4x faster than FloatArray for the above.

If I am using Smallapack incorrectly please help.

Any help greatly appreciated.

Thanks.

Re: [Pharo-dev] FloatArray

[Jimmie Houchin]

Thanks.

I appreciate your working to make this happen. No pressure from me on 
time. I am blessed that you are contributing this to the community and 
that I can benefit from your labors. At your convenience.


I look forward to using Smallapack when available. I am thrilled to be 
able to stay with Pharo and not have to use Python/Numpy. :)


Thanks.

Jimmie


On 4/25/19 12:38 PM, Nicolas Cellier wrote:

Hi Jimmie,
The Metacello Configuration is not ready for Pharo7.
I have succeeded in loading Smallapack yesterday without Metacello, 
and could run some of the tests.
I had to modify a few methods because of Pharo refactorings, and there 
is still some work to make it fully operational.

When ready, I'll update the Metacello configuration and keep you informed.

Le jeu. 25 avr. 2019 à 19:06, Jimmie Houchin <mailto:jlhouc...@gmail.com>> a écrit :


When I attempt to install via Metacello in Pharo 7, I get the
following warning.

This package depends on the following classes:
  Parser
  MessageAsTempNode
  Compiler
  MessageNode


I do not know how to proceed from there. Any help greatly appreciated.

Thanks.

Jimmie


On 4/24/19 12:20 AM, Nicolas Cellier wrote:

Hi,
I recommand inquiring about Smallapack, the Smalltalk interface
to LAPACK, on squeaksource.com <http://squeaksource.com> or
github. You'll get the speed of numpy. There is a Metacello
configuration. I have not checked the port on current
Pharo, but I can reactivate if there is some interest.

Le mer. 24 avr. 2019 à 05:55, Jimmie Houchin mailto:jlhouc...@gmail.com>> a écrit :

I just recently discovered FloatArray by accident.

I was close to having to use Python/Numpy due to considerable
performance differences. Performance is very important.

In one of my test using a 212000 item array of floats and
doing a sum on
each iteration through the array Pharo was taking 17 minutes
verses
Python/Numpy taking 20 seconds. Using FloatArray closes the
gap to 40
seconds. That is acceptable.

However when looking at the FloatArray comment it says it
uses 32bit
floats. I need 64bit. I don't even know where to look to
create 64bit
FloatArrays. I am surprised that they didn't get converted
when moving
to 64bit Pharo.

Would I need to change VM source? Compile a new VM and create
image side
classes? I have not messed with VM in years. I do not know
where the
FloatArray plugin would be.

Any pointers would be a great help. If this needs to be on
the vm-dev
list I can move it there.

Thanks.

Jimmie

Re: [Pharo-dev] FloatArray

[Jimmie Houchin]

When I attempt to install via Metacello in Pharo 7, I get the following 
warning.


This package depends on the following classes:
  Parser
  MessageAsTempNode
  Compiler
  MessageNode


I do not know how to proceed from there. Any help greatly appreciated.

Thanks.

Jimmie


On 4/24/19 12:20 AM, Nicolas Cellier wrote:

Hi,
I recommand inquiring about Smallapack, the Smalltalk interface to 
LAPACK, on squeaksource.com <http://squeaksource.com> or github. 
You'll get the speed of numpy. There is a Metacello configuration. I 
have not checked the port on current

Pharo, but I can reactivate if there is some interest.

Le mer. 24 avr. 2019 à 05:55, Jimmie Houchin <mailto:jlhouc...@gmail.com>> a écrit :


I just recently discovered FloatArray by accident.

I was close to having to use Python/Numpy due to considerable
performance differences. Performance is very important.

In one of my test using a 212000 item array of floats and doing a
sum on
each iteration through the array Pharo was taking 17 minutes verses
Python/Numpy taking 20 seconds. Using FloatArray closes the gap to 40
seconds. That is acceptable.

However when looking at the FloatArray comment it says it uses 32bit
floats. I need 64bit. I don't even know where to look to create 64bit
FloatArrays. I am surprised that they didn't get converted when
moving
to 64bit Pharo.

Would I need to change VM source? Compile a new VM and create
image side
classes? I have not messed with VM in years. I do not know where the
FloatArray plugin would be.

Any pointers would be a great help. If this needs to be on the vm-dev
list I can move it there.

Thanks.

Jimmie

Re: [Pharo-dev] FloatArray

[Jimmie Houchin]

That would be awesome. There is most definitely interest.

Thanks.


On 4/24/19 12:20 AM, Nicolas Cellier wrote:

Hi,
I recommand inquiring about Smallapack, the Smalltalk interface to 
LAPACK, on squeaksource.com <http://squeaksource.com> or github. 
You'll get the speed of numpy. There is a Metacello configuration. I 
have not checked the port on current

Pharo, but I can reactivate if there is some interest.

Le mer. 24 avr. 2019 à 05:55, Jimmie Houchin <mailto:jlhouc...@gmail.com>> a écrit :


I just recently discovered FloatArray by accident.

I was close to having to use Python/Numpy due to considerable
performance differences. Performance is very important.

In one of my test using a 212000 item array of floats and doing a
sum on
each iteration through the array Pharo was taking 17 minutes verses
Python/Numpy taking 20 seconds. Using FloatArray closes the gap to 40
seconds. That is acceptable.

However when looking at the FloatArray comment it says it uses 32bit
floats. I need 64bit. I don't even know where to look to create 64bit
FloatArrays. I am surprised that they didn't get converted when
moving
to 64bit Pharo.

Would I need to change VM source? Compile a new VM and create
image side
classes? I have not messed with VM in years. I do not know where the
FloatArray plugin would be.

Any pointers would be a great help. If this needs to be on the vm-dev
list I can move it there.

Thanks.

Jimmie

[Pharo-dev] FloatArray

[Jimmie Houchin]

I just recently discovered FloatArray by accident.

I was close to having to use Python/Numpy due to considerable 
performance differences. Performance is very important.


In one of my test using a 212000 item array of floats and doing a sum on 
each iteration through the array Pharo was taking 17 minutes verses 
Python/Numpy taking 20 seconds. Using FloatArray closes the gap to 40 
seconds. That is acceptable.


However when looking at the FloatArray comment it says it uses 32bit 
floats. I need 64bit. I don't even know where to look to create 64bit 
FloatArrays. I am surprised that they didn't get converted when moving 
to 64bit Pharo.


Would I need to change VM source? Compile a new VM and create image side 
classes? I have not messed with VM in years. I do not know where the 
FloatArray plugin would be.


Any pointers would be a great help. If this needs to be on the vm-dev 
list I can move it there.


Thanks.

Jimmie

Re: [Pharo-dev] Downloading file with Zinc

[Jimmie Houchin]

On 12/20/18 1:59 PM, Stephane Ducasse wrote:

Hi Sven

I would like download files (pdf) with Zinc (not opening them in Pharo).
I wonder how I can do it with zinc.

Tx


'http://files.pharo.org/books-pdfs/learning-oop/2018-04-01-LearningOOP.pdf' 
asZnUrl saveContentsToFile: '/mypath/mydir/learning-oop.pdf'


Should get you going.

Jimmie

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

[Jimmie Houchin]

hey aren’t our core language thing. And 
it just makes it less frictionless for ourselves and newcomers.


Of course, if we were to move, we would need to translate a lot of 
quality docs to a new format - but I would be up for contributing to 
that if that was a deciding factor.


Tim


On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouc...@gmail.com 
<mailto:jlhouc...@gmail.com>> wrote:


TL;DR

Main points:
Their is no universally accepted markup language.
Other communities use their own markup and  tools and their markup 
and tools choice is not determine by other communities decisions.
We need a language and tool chain that we can control and maintain 
which accomplishes our goals.
Our language and tools already exist and have existed for longer than 
most of the other markup languages. Of course they existed in various 
different forms over the years and have evolved into what they 
currently are.
It might be nice to have a GFM Markdown exporter from Pillar for 
GitHub projects.



I just want to comment on the fact that there is no universal markup 
language that every development community has settled upon. Making 
Markdown or some variant the markup language for Pharo only aligns us 
with a certain part of the development community. Even Markdown is 
not unified as is evident by the discussion.


It is true that GitHub uses their variant of Markdown. And as long as 
we use GitHub we will need to use their variant for documents that 
reside on their system.


However as a significant counter example to lets all use gfm 
Markdown, is the Python community and their documentation.


https://docs.python.org/devguide/documenting.html
"""
7. Documenting Python
The Python language has a substantial body of documentation, much of 
it contributed by various authors. The markup used for the Python 
documentation is reStructuredText, developed by the docutils project, 
amended by custom directives and using a toolset named Sphinx to 
post-process the HTML output.


This document describes the style guide for our documentation as well 
as the custom reStructuredText markup introduced by Sphinx to support 
Python documentation and how it should be used.


The documentation in HTML, PDF or EPUB format is generated from text 
files written using the reStructuredText format and contained in the 
CPython Git repository.

"""

So the Python community uses their own markup language and their own 
tool chain. So therefore, it is not wrong for a community to go their 
own way, for their own reasons. Even within the conventional file 
based languages such as Python.


The fact that you have tools such as Pandoc, suggest that there is 
not true uniformity or unanimity among developers as to the best 
markup language or tool chain.


I believe that a language that we can control and maintain is better 
than adopting some other foreign markup language that is neither 
better, nor unanimously used by all. That would ultimately 
potentially require extensions to accomplish our goals. Then we would 
be maintaining someone else's language with our extensions that may 
or may not be accepted by the larger community. This does not prevent 
but rather encourages fragmentation of the existing Markdown.


Regardless, Pillar markup already exists. The tools in Pharo already 
understand it. Should someone desire to use Pharo which is far more 
different from Python/Ruby/etc. than Pillar syntax is from Markdown. 
Then it should be worth their effort to learn our tools.


Pillar markup is older than Markdown, etc. It's history begins in 
SmallWiki. It isn't as if we jumped up and decided to create 
something new in order to be different. Our markup and tools are 
older. They (and others) are the ones that decided to do their own 
markup and tools. And it is okay that they did so. Nothing wrong with 
doing so. Every community has the right to what they believe is best 
for their community. Even if other communities disagree.


The ability to control and maintain is highly valuable. We can 
understand what our requirements are for today. But we can not know 
what the requirements are in the future. Nor can we know that 
Markdown or whomever will have such requirements when they appear. It 
is easy to see in the beginning with the Squeak Wiki syntax to the 
now Pillar syntax, changes that have been made to accommodate new 
requirements as they became known. We need to maintain that ability. 
Sure we would reserve the right to do so in any language we adopt. 
But the then current standard bearer of said language would determine 
whether what we do is acceptable and incorporate or whether we are 
then in fact adding to their fragmentation. Pillar is ours. There is 
not fragmentation when we evolve.


However, since we have made a decision to use GitHub and GitHub has 
made a decision to use their own GFM Markdown. It might be nice to 
have a GFM Markdown exporter from Pillar for GitHub projects. Th

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

[Jimmie Houchin]

TL;DR

Main points:
Their is no universally accepted markup language.
Other communities use their own markup and  tools and their markup and 
tools choice is not determine by other communities decisions.
We need a language and tool chain that we can control and maintain which 
accomplishes our goals.
Our language and tools already exist and have existed for longer than 
most of the other markup languages. Of course they existed in various 
different forms over the years and have evolved into what they currently 
are.
It might be nice to have a GFM Markdown exporter from Pillar for GitHub 
projects.



I just want to comment on the fact that there is no universal markup 
language that every development community has settled upon. Making 
Markdown or some variant the markup language for Pharo only aligns us 
with a certain part of the development community. Even Markdown is not 
unified as is evident by the discussion.


It is true that GitHub uses their variant of Markdown. And as long as we 
use GitHub we will need to use their variant for documents that reside 
on their system.


However as a significant counter example to lets all use gfm Markdown, 
is the Python community and their documentation.


https://docs.python.org/devguide/documenting.html
"""
7. Documenting Python
The Python language has a substantial body of documentation, much of it 
contributed by various authors. The markup used for the Python 
documentation is reStructuredText, developed by the docutils project, 
amended by custom directives and using a toolset named Sphinx to 
post-process the HTML output.


This document describes the style guide for our documentation as well as 
the custom reStructuredText markup introduced by Sphinx to support 
Python documentation and how it should be used.


The documentation in HTML, PDF or EPUB format is generated from text 
files written using the reStructuredText format and contained in the 
CPython Git repository.

"""

So the Python community uses their own markup language and their own 
tool chain. So therefore, it is not wrong for a community to go their 
own way, for their own reasons. Even within the conventional file based 
languages such as Python.


The fact that you have tools such as Pandoc, suggest that there is not 
true uniformity or unanimity among developers as to the best markup 
language or tool chain.


I believe that a language that we can control and maintain is better 
than adopting some other foreign markup language that is neither better, 
nor unanimously used by all. That would ultimately potentially require 
extensions to accomplish our goals. Then we would be maintaining someone 
else's language with our extensions that may or may not be accepted by 
the larger community. This does not prevent but rather encourages 
fragmentation of the existing Markdown.


Regardless, Pillar markup already exists. The tools in Pharo already 
understand it. Should someone desire to use Pharo which is far more 
different from Python/Ruby/etc. than Pillar syntax is from Markdown. 
Then it should be worth their effort to learn our tools.


Pillar markup is older than Markdown, etc. It's history begins in 
SmallWiki. It isn't as if we jumped up and decided to create something 
new in order to be different. Our markup and tools are older. They (and 
others) are the ones that decided to do their own markup and tools. And 
it is okay that they did so. Nothing wrong with doing so. Every 
community has the right to what they believe is best for their 
community. Even if other communities disagree.


The ability to control and maintain is highly valuable. We can 
understand what our requirements are for today. But we can not know what 
the requirements are in the future. Nor can we know that Markdown or 
whomever will have such requirements when they appear. It is easy to see 
in the beginning with the Squeak Wiki syntax to the now Pillar syntax, 
changes that have been made to accommodate new requirements as they 
became known. We need to maintain that ability. Sure we would reserve 
the right to do so in any language we adopt. But the then current 
standard bearer of said language would determine whether what we do is 
acceptable and incorporate or whether we are then in fact adding to 
their fragmentation. Pillar is ours. There is not fragmentation when we 
evolve.


However, since we have made a decision to use GitHub and GitHub has made 
a decision to use their own GFM Markdown. It might be nice to have a GFM 
Markdown exporter from Pillar for GitHub projects. This way we can use 
our own tools and markup language to accomplish whatever we want to 
accomplish. Including generating a Readme.md for our GitHub projects.


Just wanted to toss out this simple opinion and facts about the situation.

Jimmie


On 08/14/2017 04:10 AM, Tudor Girba wrote:

Hi Tim,

The main benefit of relying on Pillar is that we control its syntax and can 
easily extend it for our purposes. Also, there was quite a 

Re: [Pharo-dev] Running on Ubuntu?

[Jimmie Houchin]

Here is the script I have used for years.

I am currently running it on 16.04.

I have not compared it to Thierry's.

I have this in a file setup-pharo.sh

I make it executable and the sudo setup-pharo.sh


# ARGUMENT HANDLING 
=

if { [ "$1" = "-h" ] || [ "$1" = "--help" ]; }; then
echo "Install libraries required to run Pharo.
"
exit 0;
elif [ $# -gt 0 ]; then
echo "--help/-h is the only argument allowed"
exit 1;
fi

dpkg --add-architecture i386
apt-get update

apt-get --yes install cmake zip bash-completion ruby git xz-utils 
debhelper devscripts
apt-get --yes install libc6-dev:i386 libasound2:i386 libasound2-dev:i386 
libasound2-plugins:i386
apt-get --yes install libssl-dev:i386 libssl1.0.0:i386 libssh2-1:i386 
libfreetype6-dev:i386 libx11-dev:i386 libsm-dev:i386 libice-dev:i386

apt-get --yes install build-essential gcc-multilib g++
apt-get --yes install libgl1-mesa-dev:i386 libgl1-mesa-glx:i386


#Esteban Lorenzano says this is the minimum
#test this

#apt-get -qq install libc6:i386
#apt-get -qq install libuuid1:i386
#apt-get -qq install libkrb5-3:i386 libk5crypto3:i386 zlib1g:i386 
libcomerr2:i386 libkrb5support0:i386 libkeyutils1:i386

#apt-get -qq install libssl1.0.0:i386
#apt-get -qq install libfreetype6:i386



Jimmie Houchin




On 11/22/2016 08:24 AM, Thierry Goubier wrote:

Igor,

I have this script:

https://gist.github.com/ThierryGoubier/3dbef94a959f4f8acb19

Now, I would suggest, if you don't have any need FFI-related (no 
Athens, Roassal, bloc, etc...), use the 64 bits version: runs without 
installing anything on a large variety of Linuxes.


Thierry

2016-11-22 15:00 GMT+01:00 Igor Stasenko <siguc...@gmail.com 
<mailto:siguc...@gmail.com>>:




On 22 November 2016 at 15:06, David T. Lewis <le...@mail.msen.com
<mailto:le...@mail.msen.com>> wrote:

On Tue, Nov 22, 2016 at 12:19:30PM +0200, Igor Stasenko wrote:
> ldd vm-display-X11
> linux-gate.so.1 => (0xf77fd000)
> libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0
(0xf7799000)
> libGL.so.1 => not found
> libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7664000)
> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74b5000)
> /lib/ld-linux.so.2 (0x5664e000)
> libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf7493000)
> libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf748e000)
> libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf748a000)
> libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6
(0xf7482000)
>
>
> seems like i have everyting already except libgl...
> any ideas what package providing it?
>

After some trial and error, this is what I ended up installing
on my Ubuntu system:

  sudo apt-get install libgl1-mesa-dri-lts-utopic:i386
  sudo apt-get install libgl1-mesa-glx-lts-utopic:i386
  sudo apt-get install mesa-common-dev

Dave


meh..

 sudo apt-get install libgl1-mesa-dri-lts-utopic:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 qtdeclarative5-qtfeedback-plugin : Depends: libqt5feedback5 but
it is not going to be installed
 unity-control-center : Depends: libcheese-gtk23 (>= 3.4.0) but it
is not going to be installed
Depends: libcheese7 (>= 3.0.1) but it is
not going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may
be caused by held packages.
:(


-- 
Best regards,

Igor Stasenko.

Re: [Pharo-dev] keeping threads on topic

[Jimmie Houchin]

Thanks for the information. I personally don't have a problem with the 
ability to search. I have the entire mailing list in a single mailbox in 
Thunderbird. However the problem with data and searching is how clean is 
the data, the quality of the metadata, and the constraints you can put 
on your search parameters.


If we can have smaller messages in which the message concerns the topic 
in the subject, and the message contains primarily the context of  the 
prior emails necessary for the topic. Then we are far better off in our 
search efforts. Our search results will be cleaner, have fewer false 
positives and fewer messages to wade through to find what we want.


I took a look at your link. The advanced search does offer some nice 
ways to constrain a search. But if the message and topic of a particular 
message don't match it will be a false positive. Good mailing list 
habits are valuable.


Thanks again for the link. I am not always at my computer with its 
resources. And many people would not do what I do anyway.



Jimmie Houchin



On 10/25/2016 10:22 PM, Dimitris Chloupis wrote:

The forum has a very nice search facility

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


On Wed, 26 Oct 2016 at 06:11, Jimmie Houchin <jlhouc...@gmail.com 
<mailto:jlhouc...@gmail.com>> wrote:


On 10/23/2016 12:11 AM, Tudor Girba wrote:
> Hi,
>
> The communication traffic around Pharo is constantly increasing
and it is harder and harder to keep up with everything that is
happening.
>
> On the one hand this is great because it shows that our project
is growing healthily. On the other hand, it makes it harder for
people to find the relevant thread and participate in discussions.
This is problematic given that this mailing list is for discussing
development issues that require specific expertise.
>
> To address this, I kindly ask everyone to keep a thread as much
as possible on the topic meant by the title of the thread.
>
> Cheers,
> Tudor
>
> --
> www.tudorgirba.com <http://www.tudorgirba.com>
> www.feenk.com <http://www.feenk.com>
>
> "Value is always contextual."

I agree.

We all know frequently threads take unforeseen directions. If you are
going to take a thread in a direction not on topic with the title,
then
give your email a new title appropriate with the new topic.

This helps people to better keep up with the mailing list as they can
better discern what messages are of interest to them or not. It also
helps people with particular knowledge know if messages if the message
is something they may need to respond to.

It also helps the mailing list archives be more valuable for people
searching for answers.

In addition I would like to encourage people to limit the quoted
material of the email to that which is important to or the context of
what they are replying to. So many emails are replies to long and
increasingly longer emails due to quoting of complete emails only to
make brief comments about small portion of the email.

These mailing lists are an incredibly valuable resource. They are the
first place I search to find answers. These few simple things can help
them to be cleaner and more valuable as people will more easily find
what they are looking for.

Thanks.

Jimmie Houchin

Re: [Pharo-dev] [Ann] Stack Android VM

[Jimmie Houchin]

Thanks for working on this.

I greatly look forward to being able to use Pharo on my devices.

Exciting times.


Jimmie Houchin


On 10/23/2016 03:03 PM, Santiago Bragagnolo wrote:
   Still far from production. But since i would happy to have some 
feedback, I'm happy to show you some progress on the android VM. Not 
yet release. But we have already a way of compiling and deploying an 
image into an android device.


  You can check it in this repo github.
https://github.com/sbragagnolo/pharo-vm/

  The building steps are detailed on the README-Android.md file.

[snip]

https://github.com/sbragagnolo/pharo-vm

Re: [Pharo-dev] keeping threads on topic

[Jimmie Houchin]

On 10/23/2016 12:11 AM, Tudor Girba wrote:

Hi,

The communication traffic around Pharo is constantly increasing and it is 
harder and harder to keep up with everything that is happening.

On the one hand this is great because it shows that our project is growing 
healthily. On the other hand, it makes it harder for people to find the 
relevant thread and participate in discussions. This is problematic given that 
this mailing list is for discussing development issues that require specific 
expertise.

To address this, I kindly ask everyone to keep a thread as much as possible on 
the topic meant by the title of the thread.

Cheers,
Tudor

--
www.tudorgirba.com
www.feenk.com

"Value is always contextual."


I agree.

We all know frequently threads take unforeseen directions. If you are 
going to take a thread in a direction not on topic with the title, then 
give your email a new title appropriate with the new topic.


This helps people to better keep up with the mailing list as they can 
better discern what messages are of interest to them or not. It also 
helps people with particular knowledge know if messages if the message 
is something they may need to respond to.


It also helps the mailing list archives be more valuable for people 
searching for answers.


In addition I would like to encourage people to limit the quoted 
material of the email to that which is important to or the context of 
what they are replying to. So many emails are replies to long and 
increasingly longer emails due to quoting of complete emails only to 
make brief comments about small portion of the email.


These mailing lists are an incredibly valuable resource. They are the 
first place I search to find answers. These few simple things can help 
them to be cleaner and more valuable as people will more easily find 
what they are looking for.


Thanks.

Jimmie Houchin

Re: [Pharo-dev] new collaborators in Pharo 5

[Jimmie Houchin]

Hello,

I do not know if I qualify or not. If so, very minimally so. I 
contributed a bug fix of which my code did not end up in the image, but 
the following flurry of activity and corresponding code I believe from 
HenrikNergaard did. And it was a very big help to what I was doing. 
Thanks to all who jumped in.


But I do hope this is but the first of attempts to contribute.
So I guess it depends on how you define collaborator.

jimmiehouchin

Jimmie Houchin


On 04/29/2016 03:25 AM, Esteban Lorenzano wrote:

Hi,

So, according to my script, this are the new collaborators (people who started 
contributing after 1st march 2015):

Maxleske
CyrilFerlicot
Latsabben
Nicolaihess
synectique
BorisSpasojevic
Stef
Bite
hn
SvenVanCaekebenberghe
StefnReichhart
NicoPasserini
DEMAREYChristophe
HenrikNergrd
SkipLentz
Spirita
Fuel
TravisCI
HolgerHansPeterFreyther
SpurBootstrap
qdq
SergioFedi
jeanbaptisteArnaud
AutoGenTutorial
PabloTesone
ThomasHeniart
ValentinRyckewaert
mml
HenrikNergaard
MarcusDenkr
DenisKudriashov
Alexandre
mcamp
Matthieu
w3ertyu
VincentBlondeauAbdelghaniAlidra
TH
MerwanOuddane
ChristopherCoat
AlainRastoul
FranckWarlouzet
AbdelghaniLaidra
ThibaultArloing
pad
RogerStebler
DavidAllouche
RM
tr

Obviously… many are wrong since they started contributing a lot before (like 
Sven and Stef :P … I wonder why the difference gave me this… but well… )

Anyway, I need to know who are this guys:

- synectique (I suppose is Guillome, Usman or Cyril)
- Bite (I hope this is not a french guy, because in that case is soo rude… 
or proud of himself :P)
- hn
- Spirita
- qdq
- mml
- Alexandre (Bergel?)
- mcamp
- Matthieu
- w3ertyu
- TH
- pad
- RM
- tr

So… any hints about authors?

thanks,
Esteban

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

[Jimmie Houchin]

On 03/05/2016 08:33 PM, Eliot Miranda wrote:

Jimmie,


On Mar 5, 2016, at 5:56 PM, Jimmie Houchin <jlhouc...@gmail.com> wrote:

On 03/05/2016 12:57 PM, Ben Coman wrote:
On Sun, Mar 6, 2016 at 2:10 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote:

On 05 Mar 2016, at 18:22, Eliot Miranda <eliot.mira...@gmail.com> wrote:

Stef,


On Mar 5, 2016, at 12:10 AM, stepharo <steph...@free.fr> wrote:

You probably leave in a protected environment but I do not live in the same.
Did you check numPy recently or R? momemtum?
Do you think that people do not know how to count?
In 1980 my students were not even born, so how can it be better than
 python, java, c#, lua, ...

Do you think that it makes me happy to see my old friends leaving our language 
and do node.js.
Seriously.
Why do you blame me? Frankly tell to leave Pharo and I will leave. I can tell 
you.
I think that I need a break in my life in this moment so it would be a good 
opportunity.
Because if each time I do something to improve the wealth and visibility of our 
system
I get such kind of feedback then may be this is the time to do something.
Afterall I may be wrong.
Seriously if you think that I'm not doing a good job and you want to stay with 
old friends
just let me know. but if I stay then do not tell me that I'm an asshole that 
does not want to
promote smalltalk.

I do not blame you.  I am offended by Pharo disavowing the Smalltalk name.  I 
am offended when people state Pharo is not Smalltalk.  I want to refute false 
assumptions about the name Smalltalk, such as the equating it with cobol.  
Instead of taking it personally why don't you address my points about older 
programming languages whose names (AFAICT) are not perceived negatively?


I support this community and am excited to participate in it.  I admire and 
respect your efforts, Stéphane, in developing, organizing and supporting this 
community.  But that does not mean I will keep quiet about something I 
profoundly disagree with and think is wrong.  And that thing is to deny Pharo 
is Smalltalk.

And I do this not because I am a zealot, but because words meaning are 
important, because to understand each other we should call a spade a spade, and 
because I am grateful for and delighted by this thing called Smalltalk, and I 
will not support taking credit away from it.  Ruby is inspired by Smalltalk.  
Pharo is the real thing.

Pharo was started because a certain situation existed in the Squeak community 
that blocked progress for a group of people that had another vision. Pharo was 
started and exists to fulfil that grand vision, a vision that is clearly rooted 
in Smalltalk history, but goes beyond that.

If you want to focus on words, your sentence 'Pharo is Smalltalk' is not so 
innocent or politically free, as you know very well, even if it looks like 
factually correct (it is BTW).

We say it differently because of what I just wrote, because we want to be free 
of backwards compatibility (if necessary), because we want to have a larger 
future than maintaining something old (even though we absolutely respect and 
acknowledge it). Yes, it is a bit of a play of words, but not without reason.

Here is one writeup that tries to describe the same idea:

   http://www.tudorgirba.com/blog/pharo-is-pharo

But the best documents are the Pharo vision documents.

The counter argument is that there was Smalltalk-71, -72, -76, -78,
-80.   Some of these were distinctly different from the last.  So
Smalltalk was an *evolving* system.  Why can't it be so again!?  and
be Smalltalk-Renew, Smalltalk-Next, Smalltalk-Evolved, Smalltalk-16,
Smalltalk-P16 or Smalltalk-P5 "Pharo 5".

As long as the emphasis is on Pharo being an *evolution* of Smalltalk
(which is not in doubt), I think we cover all bases - stimulating the
interest of newcomers and/or detractors of old, as well as Smalltalk
stalwarts without being constrained by the past.  As much as we might
want to promote Pharo being separate from Smalltalk (which I believe
was a reasonable strategy to establish identity at the time of the
fork from Squeak), Smalltalk is always going to be there for anyone
who scratches beneath the surface and they  end up thinking "Oh its
*just* Smalltalk" anyway.  So this remains the "elephant in the room",
*subtly* undermining of our marketing.  Its the sort of weakness that
can be better to hit head on as "Smalltalk-Evolved" (since "Evolved"
is a term with positive connotations in the gaming / sci-fi
communities.)

cheers -ben

I have had this argument also from the pro-Smalltalk side of things. What 
persuaded me to be more liberal and permissive in the argument pro-Pharo is 
simply this. All of the Smalltalks above were done be the creators of 
Smalltalk. They had ownership and rights to the name Smalltalk and the 
directions it had the freedom to pursue. The creators of Pharo do not have such 
ownership to the Smalltalk history, heritage o

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

[Jimmie Houchin]

On 03/05/2016 12:57 PM, Ben Coman wrote:

On Sun, Mar 6, 2016 at 2:10 AM, Sven Van Caekenberghe  wrote:

On 05 Mar 2016, at 18:22, Eliot Miranda  wrote:

Stef,

On Mar 5, 2016, at 12:10 AM, stepharo  wrote:


You probably leave in a protected environment but I do not live in the same.
Did you check numPy recently or R? momemtum?
Do you think that people do not know how to count?
In 1980 my students were not even born, so how can it be better than
 python, java, c#, lua, ...

Do you think that it makes me happy to see my old friends leaving our language 
and do node.js.
Seriously.
Why do you blame me? Frankly tell to leave Pharo and I will leave. I can tell 
you.
I think that I need a break in my life in this moment so it would be a good 
opportunity.
Because if each time I do something to improve the wealth and visibility of our 
system
I get such kind of feedback then may be this is the time to do something.
Afterall I may be wrong.
Seriously if you think that I'm not doing a good job and you want to stay with 
old friends
just let me know. but if I stay then do not tell me that I'm an asshole that 
does not want to
promote smalltalk.

I do not blame you.  I am offended by Pharo disavowing the Smalltalk name.  I 
am offended when people state Pharo is not Smalltalk.  I want to refute false 
assumptions about the name Smalltalk, such as the equating it with cobol.  
Instead of taking it personally why don't you address my points about older 
programming languages whose names (AFAICT) are not perceived negatively?


I support this community and am excited to participate in it.  I admire and 
respect your efforts, Stéphane, in developing, organizing and supporting this 
community.  But that does not mean I will keep quiet about something I 
profoundly disagree with and think is wrong.  And that thing is to deny Pharo 
is Smalltalk.

And I do this not because I am a zealot, but because words meaning are 
important, because to understand each other we should call a spade a spade, and 
because I am grateful for and delighted by this thing called Smalltalk, and I 
will not support taking credit away from it.  Ruby is inspired by Smalltalk.  
Pharo is the real thing.

Pharo was started because a certain situation existed in the Squeak community 
that blocked progress for a group of people that had another vision. Pharo was 
started and exists to fulfil that grand vision, a vision that is clearly rooted 
in Smalltalk history, but goes beyond that.

If you want to focus on words, your sentence 'Pharo is Smalltalk' is not so 
innocent or politically free, as you know very well, even if it looks like 
factually correct (it is BTW).

We say it differently because of what I just wrote, because we want to be free 
of backwards compatibility (if necessary), because we want to have a larger 
future than maintaining something old (even though we absolutely respect and 
acknowledge it). Yes, it is a bit of a play of words, but not without reason.

Here is one writeup that tries to describe the same idea:

   http://www.tudorgirba.com/blog/pharo-is-pharo

But the best documents are the Pharo vision documents.


The counter argument is that there was Smalltalk-71, -72, -76, -78,
-80.   Some of these were distinctly different from the last.  So
Smalltalk was an *evolving* system.  Why can't it be so again!?  and
be Smalltalk-Renew, Smalltalk-Next, Smalltalk-Evolved, Smalltalk-16,
Smalltalk-P16 or Smalltalk-P5 "Pharo 5".

As long as the emphasis is on Pharo being an *evolution* of Smalltalk
(which is not in doubt), I think we cover all bases - stimulating the
interest of newcomers and/or detractors of old, as well as Smalltalk
stalwarts without being constrained by the past.  As much as we might
want to promote Pharo being separate from Smalltalk (which I believe
was a reasonable strategy to establish identity at the time of the
fork from Squeak), Smalltalk is always going to be there for anyone
who scratches beneath the surface and they  end up thinking "Oh its
*just* Smalltalk" anyway.  So this remains the "elephant in the room",
*subtly* undermining of our marketing.  Its the sort of weakness that
can be better to hit head on as "Smalltalk-Evolved" (since "Evolved"
is a term with positive connotations in the gaming / sci-fi
communities.)

cheers -ben


I have had this argument also from the pro-Smalltalk side of things. 
What persuaded me to be more liberal and permissive in the argument 
pro-Pharo is simply this. All of the Smalltalks above were done be the 
creators of Smalltalk. They had ownership and rights to the name 
Smalltalk and the directions it had the freedom to pursue. The creators 
of Pharo do not have such ownership to the Smalltalk history, heritage 
or name. Do they have the rights to say that the direction they take 
Pharo is the direction of Smalltalk? What if Squeak diverges in a 
different direction? Who is to say which is the standard bearer 

Re: [Pharo-dev] Stored Settings

[Jimmie Houchin]

Okay, thanks.

Having not used the settings in 4 and before I do not know what changes 
were made. But I would love for there to be user options as what to name 
the saved settings and what saved settings are loaded.


Shalom Aleichem

Jimmie

On 01/27/2016 01:44 PM, stepharo wrote:
pay attention that settings storage changed in 50 if I'm correct 
(because the saved settings where not refactored when

their image API changed).


Le 27/1/16 19:12, Jimmie Houchin a écrit :

Sorry for the noise.

I think I have found what I am looking for in the Deep Into Pharo book.
I am reading now.

Shalom Aleichem

Jimmie

On 01/27/2016 11:16 AM, Jimmie Houchin wrote:

Hello,

I am learning how to better manage my processes. I have never messed 
with the settings much before. The defaults were generally fine. 
However, with some of my projects I am requiring fonts which are 
best satisfied by a font with a larger character set allowing for 
multiple languages. At the moment I am using Linux Libertine or 
Linux Biolinum.


I would like to easily have these be the default fonts I use in the 
image. I opened a clean image, I made the setting changes. I then 
"Store Settings". I then opened a new clean image and "Load 
Settings". It claims that the Linux Libertine is the new font but it 
is not so. In order for the Linux Libertine font to become active I 
have to "update" the fonts. Then the fonts become visible and the 
Linux Libertine becomes active.


How do I automate the updating of the fonts in order to have the 
system fonts available when I open an image or "Load Settings"?


How do I automate or script as much as possible the initial state of 
an image?


Also in the "Store Settings" and "Load Settings" it would be nice if 
you could name the settings file and be able to choose what file you 
load from as opposed to there being only a single default file.


I have attempted to find answers in the list archives. But I have 
not yet found what I am looking for.


Pointers to documentation or articles if available are greatly 
appreciated.

Also any wisdom or advise.

Thanks.  Shalom Aleichem

Jimmie

[Pharo-dev] Stored Settings

[Jimmie Houchin]

Hello,

I am learning how to better manage my processes. I have never messed 
with the settings much before. The defaults were generally fine. 
However, with some of my projects I am requiring fonts which are best 
satisfied by a font with a larger character set allowing for multiple 
languages. At the moment I am using Linux Libertine or Linux Biolinum.


I would like to easily have these be the default fonts I use in the 
image. I opened a clean image, I made the setting changes. I then "Store 
Settings". I then opened a new clean image and "Load Settings". It 
claims that the Linux Libertine is the new font but it is not so. In 
order for the Linux Libertine font to become active I have to "update" 
the fonts. Then the fonts become visible and the Linux Libertine becomes 
active.


How do I automate the updating of the fonts in order to have the system 
fonts available when I open an image or "Load Settings"?


How do I automate or script as much as possible the initial state of an 
image?


Also in the "Store Settings" and "Load Settings" it would be nice if you 
could name the settings file and be able to choose what file you load 
from as opposed to there being only a single default file.


I have attempted to find answers in the list archives. But I have not 
yet found what I am looking for.


Pointers to documentation or articles if available are greatly appreciated.
Also any wisdom or advise.

Thanks.  Shalom Aleichem

Jimmie

Re: [Pharo-dev] Stored Settings

[Jimmie Houchin]

Sorry for the noise.

I think I have found what I am looking for in the Deep Into Pharo book.
I am reading now.

Shalom Aleichem

Jimmie

On 01/27/2016 11:16 AM, Jimmie Houchin wrote:

Hello,

I am learning how to better manage my processes. I have never messed 
with the settings much before. The defaults were generally fine. 
However, with some of my projects I am requiring fonts which are best 
satisfied by a font with a larger character set allowing for multiple 
languages. At the moment I am using Linux Libertine or Linux Biolinum.


I would like to easily have these be the default fonts I use in the 
image. I opened a clean image, I made the setting changes. I then 
"Store Settings". I then opened a new clean image and "Load Settings". 
It claims that the Linux Libertine is the new font but it is not so. 
In order for the Linux Libertine font to become active I have to 
"update" the fonts. Then the fonts become visible and the Linux 
Libertine becomes active.


How do I automate the updating of the fonts in order to have the 
system fonts available when I open an image or "Load Settings"?


How do I automate or script as much as possible the initial state of 
an image?


Also in the "Store Settings" and "Load Settings" it would be nice if 
you could name the settings file and be able to choose what file you 
load from as opposed to there being only a single default file.


I have attempted to find answers in the list archives. But I have not 
yet found what I am looking for.


Pointers to documentation or articles if available are greatly 
appreciated.

Also any wisdom or advise.

Thanks.  Shalom Aleichem

Jimmie

Re: [Pharo-dev] Right to Left languages and fonts

[Jimmie Houchin]

Hello,

In a brief exploration. I may look more later. But the Linux Libertine 
font has a reasonably nice Latin, Greek, and Hebrew and to my 
understanding many others, set of characters. I like them much better 
than the original Ariel which I used. The Ariel on Linux is not the 
Ariel Unicode MS. They may be nearly identical, but I don't know as I 
have not seen the MS font.


Thanks again.

Jimmie

On 01/11/2016 09:32 AM, Sven Van Caekenberghe wrote:

Jimmy,

Use the right font, for example Ariel Unicode MS, and you'll be able 
to display strings in those languages just fine. Processing these 
strings also works just fine.


[Snip screenshot, see original message]

Now, editing them right-to-left is not possible.

Sven

On 11 Jan 2016, at 15:50, Jimmie Houchin <jlhouc...@gmail.com 
<mailto:jlhouc...@gmail.com>> wrote:


Hello,

I briefly tried to copy/paste, read from file, some Hebrew text. I 
simply get some strange characters.


From a brief search of the archives. I did not find any means of 
doing a right to left language. I also am not sure how to use a 
Hebrew font. Font issues would also apply for when I want to use Greek.


What would be needed to do right to left and use the right Hebrew font?

I believe these issues would also apply to anyone wanting Arabic or 
any other such languages.


The last message I can easily find is in August of 2014. Maybe Pharo 
isn't the right tool for this job at the moment. But I did want to 
explore the potential of it being so.


Thanks for any help.

Jimmie

[Pharo-dev] Right to Left languages and fonts

[Jimmie Houchin]

Hello,

I briefly tried to copy/paste, read from file, some Hebrew text. I 
simply get some strange characters.


From a brief search of the archives. I did not find any means of doing 
a right to left language. I also am not sure how to use a Hebrew font. 
Font issues would also apply for when I want to use Greek.


What would be needed to do right to left and use the right Hebrew font?

I believe these issues would also apply to anyone wanting Arabic or any 
other such languages.


The last message I can easily find is in August of 2014. Maybe Pharo 
isn't the right tool for this job at the moment. But I did want to 
explore the potential of it being so.


Thanks for any help.

Jimmie

Re: [Pharo-dev] Right to Left languages and fonts

[Jimmie Houchin]

Okay. Thanks for the help.

I do not have that particular font. I am on Ubuntu. But it appears that 
the standard Arial does have a version of Hebrew glyphs.


It took me a couple of tries to get it to work. I had to close the 
Playground I had open as it remained in the original font. But when I 
inspected the string. The inspector displayed the correct fonts. After I 
changed fonts and opened a new Playground. The new Playground displayed 
Hebrew and Greek correctly. I would presume when I develop the user 
interface I can select whichever Hebrew or Greek font I want to display 
in that UI element?


It does render them in reverse order. But I would think that I can take 
care of that in my GUI display element. It is challenging to display RTL 
and LTR languages together. When I do so in LibreOffice it is a strange 
experience as to which direction the cursor is operating. :)


Again thanks.

I am encouraged to proceed. :)

Jimmie Houchin


On 01/11/2016 09:32 AM, Sven Van Caekenberghe wrote:

Jimmy,

Use the right font, for example Ariel Unicode MS, and you'll be able 
to display strings in those languages just fine. Processing these 
strings also works just fine.


[snip image of screenshot with settings browser]

Now, editing them right-to-left is not possible.

Sven

On 11 Jan 2016, at 15:50, Jimmie Houchin <jlhouc...@gmail.com 
<mailto:jlhouc...@gmail.com>> wrote:


Hello,

I briefly tried to copy/paste, read from file, some Hebrew text. I 
simply get some strange characters.


From a brief search of the archives. I did not find any means of 
doing a right to left language. I also am not sure how to use a 
Hebrew font. Font issues would also apply for when I want to use Greek.


What would be needed to do right to left and use the right Hebrew font?

I believe these issues would also apply to anyone wanting Arabic or 
any other such languages.


The last message I can easily find is in August of 2014. Maybe Pharo 
isn't the right tool for this job at the moment. But I did want to 
explore the potential of it being so.


Thanks for any help.

Jimmie

Re: [Pharo-dev] Right to Left languages and fonts

[Jimmie Houchin]

For myself and my goals. Yes, I only want to display RTL language and in 
its one container. I do not know if that is the appropriate GUI 
terminology.


I am wanting to do some textual comparison of Hebrew, Greek and English 
texts. Other languages later. They will each need to be synced with each 
other by either row by row (line by line) or with text in columns. Each 
language in its own row or column depending on the desired view.


I will want to edit each language appropriately in its container.

IDE or workspace/playground support is not required at this time.

Is it reasonably achieve this in a Pharo app using the latest Pharo GUI, 
GT, Spec, Bloc, Brick, ...?


If so, then I will start learning and get going. If not I will look 
elsewhere for accomplishing this project. But Pharo is my first choice. 
I would love to not have to move to Qt or JavaFX or some such.


Thanks.

Jimmie



On 01/11/2016 09:06 AM, Max Leske wrote:

Hi Jimmy,

AFAIK there’s no IDE support for RTL languages. You only want to be able to 
display the strings correctly though, right?

I’m pretty sure that it’s already possible to load the font. The problem is 
probably with the editors and workspaces. They would need to be told to display 
the string differently.


Cheers,
Max



On 11 Jan 2016, at 15:50, Jimmie Houchin <jlhouc...@gmail.com> wrote:

Hello,

I briefly tried to copy/paste, read from file, some Hebrew text. I simply get 
some strange characters.

 From a brief search of the archives. I did not find any means of doing a right 
to left language. I also am not sure how to use a Hebrew font. Font issues 
would also apply for when I want to use Greek.

What would be needed to do right to left and use the right Hebrew font?

I believe these issues would also apply to anyone wanting Arabic or any other 
such languages.

The last message I can easily find is in August of 2014. Maybe Pharo isn't the 
right tool for this job at the moment. But I did want to explore the potential 
of it being so.

Thanks for any help.

Jimmie

Re: [Pharo-dev] Java Future

[Jimmie Houchin]

Much truth in what you say. However, what Oracle choose to invest its 
money, time, personnel resource into Java does affect its present and 
future. It has a great affect. But it isn't the whole story. Java has 
enough momentum in what already exists in the language and vm and what 
has been release under its license, for businesses to keep going for 
some time with only what currently exists.


The nice part about the Pharo story is this, as Stef says:
Pharo is yours.

What Pharo is and becomes is up to us, the community. Not what any major 
corporation says it is or is not going to do. Pharo is what we make it 
to be. Pharo will become what we make it to become.


It is nice to have organizations and corporations as part of the 
community, such as INRIA, etc. They offer substantial resources and are 
a blessing. And the nice thing is that Pharo does not need an Oracle 
size corporation to keep it going and viable. Can Java say that? Time 
will tell. Could Java have gotten to where it is without it?


As you say, let's keep Pharo going so that it can empower the little guy 
or smaller business. :)


Shalom.

Jimmie




On 11/25/2015 04:29 AM, Dimitris Chloupis wrote:

Clickbait ! ClickBAIT !

Let me remind you that bloggers have been declaring Java dead for over 
a decade now. Java still goes strong and is the undisputed king of 
Enterprise coding no other language can even remotely touch it, mainly 
because of its huge powerful library made for big businesses. Pharo 
cannot compete with Java, it does not have the resources to, right now 
the only true competitor to java is C# and even C# though backed by 
Micro$oft , still it lags very much behind it in terms of popularity. 
Let me also remind you that Java is the language that mutilated the 
then undisputed king of of programming languages C++ stealing away 
tons of its coders. Probably the biggest migration of coders ever.


Only fools underestimate Java.

Java is big, Java is ugly, Java is powerful and Java is here to stay 
for a long, long time.


My advice to Pharo, keep doing what you know best, helping lone coders 
and small teams compete with large companies in terms of productivity. 
Dont compete, innovate.


On Wed, Nov 25, 2015 at 12:03 PM S Krish 
> wrote:


/Opportunities.. for Pharo..
/

/
/

/The email, sent to InfoWorld on Tuesday by a former high-ranking
Java official, claimed to feature details from inside Oracle. It
said the company was becoming a cloud company, competing with
Salesforce, and “Java has no interest to them anymore.” The
subject line cited “Java – planned obsolescence.”/

/Oracle is not interested in empowering its competitors and
doesn’t want to share innovation, the email further alleges. The
company is slimming down Java EE (Enterprise Edition), but it also
doesn’t want anyone else to work on Java or Java EE and is
sidelining the JCP (Java Community Process). “They have a
winner-take-all mentality and they are not interested in
collaborating,” said the email. “Proprietary product work will be
done on WebLogic, and there’ll be a proprietary microservices
platform.” WebLogic is the Java application server Oracle acquired
when it bought BEA Systems in 2008./


https://dzone.com/articles/even-if-oracle-is-losing-interest-in-java-should-y?edition=115055_source=Spotlight_medium=email_campaign=java%202015-11-24

Re: [Pharo-dev] [Pharo-project] [Vm-dev] Cog issue? Re: StandardFileStream size limit?

[Jimmie Houchin]

This still fails three and a half years later with a default Pharo 4 vm 
and image.

:(

I spent a few hours trying to diagnose why Pharo was telling me that I 
file I knew existed didn't exist. Very frustrating trying to debug this 
and then to find it is a vm and not an image issue. I then to search the 
archives to find this is a known issue for this long and still broken.


The latest linux vm works fine.
http://files.pharo.org/vm/pharo/linux/Pharo-VM-linux-latest.zip

Is there a reason why the "latest" vm isn't the stable vm? Or at least 
this bugfix applied to the stable vm?


Thanks.

Jimmie



On 06/13/2012 05:00 PM, eliot.miranda at gmail.com (Eliot Miranda) wrote:

On Wed, Jun 13, 2012 at 7:40 AM, David T. Lewis  wrote:


On Wed, Jun 13, 2012 at 04:08:14PM +0200, G?ran Krampe wrote:

Hey!

Ok, so the plot thickens:

If I run this in a "oneclick 1.4" I will get a file write error on 2Gb:

| f b |
f := StandardFileStream newFileNamed: 'test'.
b := ByteArray new: 1024*1024*100. "100Mb"
[30 timesRepeat: [f nextPutAll: b]] ensure: [f close] "3Gb"


...but it worked fine using a self built "standard" VM from squeakvm.org
(4.4.7.2357)! Same image btw.

Now, does it work with the bleeding edge Cog? Tried r2556 and nope, same
problem.

So I "guess" it is a Cog thing? I haven't tried building Cog from source.

regards, G?ran

Background on large file support, see especially Bert's summary:


http://forum.world.st/Re-squeak-dev-filesize-reporting-0-for-very-large-files-td4483646.html
http://bugs.squeak.org/view.php?id=7522
http://www.suse.de/~aj/linux_lfs.html

I'm not sure if the Cog VMs are being compiled with the the LFS option,
although
I expect that if you compile it yourself with the build options that Bert
explains,
then it should start working.


I just committed the necessary changes for my branch.  Will rebuild soon.
  G?ran, if you're in a hurry build your own?  You'd need to be in
http://www.squeakvm.org/svn/squeak/branches/Cog/unixbuild/bld and run ./mvm.

Re: [Pharo-dev] Random forest in Pharo

[Jimmie Houchin]

Thanks for the information.

And thank you for all that you do to move Pharo forward.
I know some of this must be tedious. But Pharo is getting more beautiful 
all the time.


Jimmie

On 10/15/2015 10:02 AM, Esteban Lorenzano wrote:


On 15 Oct 2015, at 16:51, Jimmie Houchin <jlhouc...@gmail.com 
<mailto:jlhouc...@gmail.com>> wrote:


Thanks for the example.

On 10/15/2015 09:04 AM, Esteban Lorenzano wrote:



On 15 Oct 2015, at 15:50, Jimmie Houchin <jlhouc...@gmail.com> wrote:

Yes, we need excellent FFI. I would love to see in Pharo FFI as 
easy as Julia [1] or LuaJIT [2]. I am not qualified to do deliver 
such. And I do not know how possible, how much effort or likely it is.


in pharo a FFI call is as easy as:

copy: source to: dest
errorCode>
 self nbCall: #( char * strcpy( char *dest, char *source ) ) module: 
‘libc’.


we can improve performance, but I do not think we will succeed on 
make it easier than that.


of course, someone could do a symbol introspector (and I think 
someone already did something to interpret header files), to be able 
to have things like:


LibC.strcpyWith: dest with: source

but I do not thing is a big win over the first one.

Esteban


That does not look to difficult.

Now my current problem is that we are being told that NativeBoost is 
going away. Then what does FFI look like and with what?


NB is going away in spur, BUT NOT his syntax… you still will do FFI 
calls in the old way. This is going to be 95% compatible (so far, I 
needed to introduce changes on: structures and callbacks… all the rest 
is same… and the changes are not really complicated to adapt).
Now, is a bit frustrating because I have said this millions of times 
(at least once for each one I say we are removing NB… and I’m the only 
one saying it :P)


Esteban



The main problem I had with NativeBoost is that it had problems I 
couldn't understand or fix. And problems that Igor didn't have time 
for. I was writing a wrapper around a proprietary library. The small 
part I had written to test out Pharo and NB worked on Windows and 
crashed in Linux. Exact same code.


This message from April 3, 2013 is my request for help.
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934.html

I never got anywhere with that project. Thus goes my tortured history 
with Pharo and programming. Not a judgment against Igor or Pharo. I 
know the resources of both are stretched to the max. And I am 
complicit in the problem as I have to few skills to help myself. So 
it did and sometimes does, send me on programming journeys to explore 
other languages and tools to empower me within my abilities. I could 
have done that project in LuaJIT or Julia when it matures a little 
more. Julia might be approaching that point.


My torture is pursuing the language/environment I enjoy, Pharo. Which 
sometimes can or sometimes can not easily do what I need within my 
skill set. Or pursuing learning other languages and tools which are 
better at integrating other external libraries. Or do to the much 
larger communities have already ready to use wrappers around most 
anything you want to do.


I am no longer pursuing that project. My requirements have changed 
and I do not require wrapping a proprietary C library.


I am reticent to invest in learning FFI that is changing without an 
idea of the direction of the change. So at the moment I am studying 
SQL and then possibly spend some time learning C so that I can better 
help myself and the community and not be as dependent. That way when 
the dust settles on the FFI as will be in Pharo5/6. I can hopefully 
be better to use and contribute.



Thanks.

Jimmie
Jimmie

[snip]

Re: [Pharo-dev] Random forest in Pharo

[Jimmie Houchin]

Yes, we need excellent FFI. I would love to see in Pharo FFI as easy as 
Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. And I do 
not know how possible, how much effort or likely it is.


Sometimes connecting to an external library is a requirement. It would 
be nice to be able to easily do so. I had problems with NB and it never 
happened.


But, on the other hand. I am a big believer and advocate of keeping as 
much as possible in Pharo. Even if there are libraries available via 
FFI. Now I know being practical and expedient sometimes using the 
libraries is necessary at least initially.


I would love as much as possible in Pharo, in our language. This makes 
it available for us to improve, fix, and learn. It reduces the barrier 
for entry for those who only know Pharo. We can't do any of those things 
if it is in a foreign language in a foreign library. Reinventing the 
wheel so to speak is not always evil. But we do have to know our 
resources, time, people, community, skills. And as a Smalltalk or 
Smalltalk inspired tool. We need to have a long view of the world. We 
already have a longer history than most languages. We should likewise 
look forward to an even longer future. Always keep the big picture in 
front of us to inspire through the tedious minutiae that we may 
currently have to deal with.


And by the way. I would love having Random Forests and other scientific, 
statistic tools in Pharo. I need to look at the SciSmalltalk stuff.


Just a few thoughts.

Jimmie

[1] 
http://docs.julialang.org/en/release-0.4/manual/calling-c-and-fortran-code

[2] http://luajit.org/ext_ffi_tutorial.html


On 10/15/2015 07:51 AM, Esteban Lorenzano wrote:

I agree.
My point was not a “let do all in pharo”, it was more against 
assumptions :)


Esteban

On 15 Oct 2015, at 14:34, philippe.b...@highoctane.be 
 > wrote:


I would see the FFI integration being much more approachable.

In R, Python, Tcl, and now Java with JNA things are going nicely.

Why is it a pain on our platform and why insist on doing all in Pharo?

This is holding us back.

Pharo is super strong at some things.

We just do not need it to be redoing everything when good business is 
at hand and industry standard libs available.


A reason why we try to use libgit2 I guess. Something external.

Phil

Le 15 oct. 2015 14:29, "philippe.b...@highoctane.be 
" > a écrit :


I guess you aren't doing lots of random forests.

RFs training is the best way to turn my PC into a heater.

Phil

Phil

Le 15 oct. 2015 14:19, "Esteban Lorenzano" > a écrit :

yeah but if this is a special case there is no problems on
doing FFI bindings and using an external library.
Precisely for that is FFI.

not that we have to integrate everything into the image :)

but… I would not be so fast in assume pharo performance will
not be enough. Unique form to know it is to do it and then
see how you can optimise, if needed :)

Esteban


On 15 Oct 2015, at 09:51, stepharo > wrote:

We do not want to be bound to install and maintain
connection with fifteen different libs.

Stef

Le 14/10/15 18:01, philippe.b...@highoctane.be
 a écrit :


Not sure you would get enough performance on Pharo per se.
Xe may be better off leveraging a multicore enabled
external lib. Like caret and doMC on R.

Le 14 oct. 2015 17:49, "Serge Stinckwich"
> a écrit :

I don't think so.

I followup your message on SciSmalltalk mailing-list.
This is something that might interested us ;-)



On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou
> wrote:
> Hi,
>
> did anyone implement a Random Forest algorithm in Pharo?
>
> https://en.wikipedia.org/wiki/Random_forest
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st

>
> "Success is the ability to go from one failure to
another without
> losing enthusiasm." --Winston Churchill
>



--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-dev] Random forest in Pharo

[Jimmie Houchin]

Thanks for the example.

On 10/15/2015 09:04 AM, Esteban Lorenzano wrote:


On 15 Oct 2015, at 15:50, Jimmie Houchin <jlhouc...@gmail.com 
<mailto:jlhouc...@gmail.com>> wrote:


Yes, we need excellent FFI. I would love to see in Pharo FFI as easy 
as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. 
And I do not know how possible, how much effort or likely it is.


in pharo a FFI call is as easy as:

copy: source to: dest
errorCode>
 self nbCall: #( char * strcpy( char *dest, char *source ) ) module: 
‘libc’.


we can improve performance, but I do not think we will succeed on make 
it easier than that.


of course, someone could do a symbol introspector (and I think someone 
already did something to interpret header files), to be able to have 
things like:


LibC.strcpyWith: dest with: source

but I do not thing is a big win over the first one.

Esteban


That does not look to difficult.

Now my current problem is that we are being told that NativeBoost is 
going away. Then what does FFI look like and with what?


The main problem I had with NativeBoost is that it had problems I 
couldn't understand or fix. And problems that Igor didn't have time for. 
I was writing a wrapper around a proprietary library. The small part I 
had written to test out Pharo and NB worked on Windows and crashed in 
Linux. Exact same code.


This message from April 3, 2013 is my request for help.
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934.html

I never got anywhere with that project. Thus goes my tortured history 
with Pharo and programming. Not a judgment against Igor or Pharo. I know 
the resources of both are stretched to the max. And I am complicit in 
the problem as I have to few skills to help myself. So it did and 
sometimes does, send me on programming journeys to explore other 
languages and tools to empower me within my abilities. I could have done 
that project in LuaJIT or Julia when it matures a little more. Julia 
might be approaching that point.


My torture is pursuing the language/environment I enjoy, Pharo. Which 
sometimes can or sometimes can not easily do what I need within my skill 
set. Or pursuing learning other languages and tools which are better at 
integrating other external libraries. Or do to the much larger 
communities have already ready to use wrappers around most anything you 
want to do.


I am no longer pursuing that project. My requirements have changed and I 
do not require wrapping a proprietary C library.


I am reticent to invest in learning FFI that is changing without an idea 
of the direction of the change. So at the moment I am studying SQL and 
then possibly spend some time learning C so that I can better help 
myself and the community and not be as dependent. That way when the dust 
settles on the FFI as will be in Pharo5/6. I can hopefully be better to 
use and contribute.



Thanks.

Jimmie
Jimmie

[snip]

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)

[Jimmie Houchin]

On 1/16/2015 12:55 PM, Nicolas Cellier wrote:
2015-01-16 0:48 GMT+01:00 Jimmie Houchin jlhouc...@gmail.com 
mailto:jlhouc...@gmail.com:


Hello,

Yes, I understand this is a micro-benchmark. And yes I know that
micro-benchmarks can be dangerous and sometimes worthless.
However, financial trading, which is the app I am working on, does
this a lot. This is precisely where most of the time is spent.
Adding data (numbers) or accessing data in arrays or matrices.
This is where my app lives. And performance is important.

Regarding my running of the test and the variety of loop sizes.
From what I see in the test there is only one loop size. 1
There are differing initial OrderedCollection sizes. Unless I am
misreading the code.

OrderedCollection new: 100.   (capacity 100).

I don't understand how this could be a capacity of 100 by what
seems to me to be a normal understanding when its initial size is
0 and it can grow infinitely beyond 100.

To me if it has a capacity of 100, immediately after creation its
size should be 100
and its initial 100 elements should be accessible.
oc at: 1 put: 1should work.
So I do not understand where this supposed capacity enters into
anything. It is neither immediately accessible, nor does it limit.


It's not specific to OrderedCollection.
Dictionary new: 100 and Set new: 100 also behave the same.

It's rather Array that behaves differently than the rest of Collection 
zoo, because an Array of capacity 100 is also an Array of size 100, 
same for other ArrayedCollection.


So if you re-think of it, you should always understand new: as 
reserving a certain capacity, which can casually also result in a 
collection of same size.


You should notice the #ofSize: message that was added once upon a time...


Yes, after writing the email when I went back into the image and browsed 
OrderedCollection, I saw the #ofSize: message which does exactly what I 
naively thought #new:   would do.


I ran the tests with   #ofSize:  and  #at:put:  and got a reasonably 
nice improvement over any of the #new:  implementations. It wasn't 
anywhere near the tests done using an Array, but better.


Dictionaries and Sets are very different creatures from Array and 
OrderedCollection. An OrderedCollection could just as easily be named 
GrowableArray or some such. At least from my understanding.


So, yes, I need to change my naive understanding to a now slightly 
better informed understanding.

There is much to learn.

Thanks for your input.

Jimmie

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)

[Jimmie Houchin]

I do not understand what is happening here.

oc := OrderedCollection new: 1.
oc size. 0

a := Array new: 1.
a size. 1

So it seems that the #new: isn't creating an OrderedCollection of the 
size we pass in.


I discovered this when I attempted to do the identical test but with an 
Array instead of an OrderedCollection. Since the Array doesn't #add:   I 
had to change the code to #at:put:.


When I noticed all of the OC code did #add: even if supposedly setting 
its size to 1(0). I tried to use #at:put: in the OrderedCollection 
but it failed because their was no index 1, because the size was still 0.


I naively would have thought that OrderedCollection new: 1 would 
return an OrderedCollection of 1 empty/nil elements and that I could 
#at:put: into any of those 1 slots and #add if I needed to go beyond 
those 1.


Tests done on a laptop with Windows 7, Pharo 4 latest image, latest 
stable vm, 3rd gen i7 processor, 12gb ram.


I did all of the tests in Pharo 4 and added my Array test.
0:00:00:04.37
0:00:00:03.183
0:00:00:03.674
0:00:00:03.753
0:00:00:01.647 and with an Array instead of OrderedCollection

So we can see if we know the max size and create the collection with 
that size it should improve performance.


I also do not understand why Pharo is so slow on this?

With the preallocated Array above it took 1.647 seconds.

Python 3.4.2,   0.003 seconds with 10,000 ints, and 0.17 with 1,000,000 
ints.

Julia 3.5, 0.005 seconds with 1,000,000 Int64.

Now I don't expect Pharo to keep up with Julia. But we aren't even in 
the neighborhood with Python.


I really would like to use Pharo. It really is my favorite language and 
environment. But these performance numbers give me pause.


Jimmie


On 1/14/2015 3:53 AM, Max Leske wrote:

Hi Alex

I thought the following little experiment might interest you.

I was trying to find out (as per your suggestion) how big the difference would 
be between:
- setting the array in OrderedCollection to nil and initializing it to size 10 
on first access
- initializing the array in OrderedCollection to size 0.

Expectation: #grow will take time, ergo, using an empty array should be slower 
than using
a preallocated array.

Experiment (Pharo 1.3 on SqueakVM):


[ 1 timesRepeat: [ | c | c  := OrderedCollection new: 10.
  1 to: 1 do: [ :i | c add: i ] ] ] timeToRun 17566

[ 1 timesRepeat: [ | c | c  := OrderedCollection new: 1.
  1 to: 1 do: [ :i | c add: i ] ] ] timeToRun 19717

[ 1 timesRepeat: [ | c | c  := OrderedCollection new: 0.
  1 to: 1 do: [ :i | c add: i ] ] ] timeToRun 17598



[ 1 timesRepeat: [ | c | c  := OrderedCollection new: 1000.
  1 to: 1 do: [ :i | c add: i ] ] ] timeToRun 18084



Result: growing a collection is always faster (or at least nearly equally fast)!

Explanation: What makes preinitialized collections so slow is the fact the the 
firstIndex variable will be set to
the first third of the array ( in this case). When the last 
position in the array is reached, all elements
are copied to the beginning of the array (2n operations). This copy 
operation is really slow (which can be seen
from the first example with an oversized collection that does not 
require copying because the last position
of the array is never reached).


Experiment (Pharo 4 on PharoVM):
(I’m using bigger numbers here to compensate for the faster VM :) )


[ 1 timesRepeat: [ | c | c  := OrderedCollection new: 100.
  1 to: 10 do: [ :i | c add: i ] ] ] timeToRun 0:00:01:09.225

[ 1 timesRepeat: [ | c | c  := OrderedCollection new: 10.
  1 to: 10 do: [ :i | c add: i ] ] ] timeToRun 0:00:00:37.653

[ 1 timesRepeat: [ | c | c  := OrderedCollection new: 0.
  1 to: 10 do: [ :i | c add: i ] ] ] timeToRun 0:00:00:40.152



[ 1 timesRepeat: [ | c | c  := OrderedCollection new: 1.
  1 to: 10 do: [ :i | c add: i ] ] ] timeToRun 0:00:00:42.121”



Result: growing a collection is easily fast enough, although minute performance 
gains are possible with preinitialized collections.

Explanation: #makeRoomAtLast has been improved. Also: firstIndex is now set to 
the beginning of the array, preventing the copy
operation that made the former measurements so slow.
The run with the oversized collection is only so slow because it 
apparently takes a lot of time to assign the large array (?).


Consequence of my little experiment: My initial implementation of the idea in 
you paper set the array in OrderedCollection to nil
under the assumption that grow operations are very costly. That choice 
leads to many changes in methods of OrderedCollection
where it is necessary to check if the array has been initialized yet. 
This introduces overhead and makes the code more error prone.
I see now that it makes much more sense to use an empty array, the 
performance lost by growing ist neglectable.

Re: [Pharo-dev] 32 bits and 64 bits VM

[Jimmie Houchin]

On 05/19/2014 05:01 PM, Eliot Miranda wrote:

On Mon, May 19, 2014 at 1:01 PM, Damien Cassou damien.cas...@gmail.com
mailto:damien.cassou-re5jqeeqqe8avxtiumw...@public.gmane.org wrote:

On Mon, May 19, 2014 at 8:57 PM, Eliot Miranda
eliot.miranda-re5jqeeqqe8avxtiumw...@public.gmane.org
mailto:eliot.miranda-re5jqeeqqe8avxtiumw...@public.gmane.org wrote:
  Can you point me to this?  I'd like to see if I can use it with
my linux
  installs.

it works in most of the supported Ubuntu releases:
http://www.pharo-project.org/pharo-download/ubuntu

Ah, oh.  Am I right to think the magic command is sudo dpkg
--add-architecture i386? If so is there a dpkg command to check if the
i386 architecture has been installed?

--
Damien Cassou
http://damiencassou.seasidehosting.st

Success is the ability to go from one failure to another
without losing enthusiasm.
Winston Churchill

--
best,
Eliot


I am running Crunchbang #! Linux using the Jessie repositories.
Crunchbang is a Debian distribution with only a number of preconfigured 
items, such as OpenBox, Tint2, etc. to give a nice out of the box Debian 
experience.


The Ubuntu PPAs do not work well or could cause problems for Debian systems.

From the pharo-vm GitHub page I downloaded and modified this script to 
work on my system. It should work on most any 64bit Debian 
Jessie/Testing and probably Sid/Unstable systems. I am not sure about 
Wheezy.


https://github.com/pharo-project/pharo-vm/blob/master/scripts/setup-ubuntu.sh

Download the above and edit. Or copy the below into a file and save. I 
called mine setup-pharo.sh.


Hope this helps.

Jimmie


dpkg --add-architecture i386
apt-get update

# INSTALL BUILD LIBRARIES 
==
apt-get --yes install cmake zip bash-completion ruby git xz-utils 
debhelper devscripts
apt-get --yes install libc6-dev:i386 libasound2:i386 libasound2-dev:i386 
libasound2-plugins:i386
apt-get --yes install libssl-dev:i386 libssl1.0.0:i386 
libfreetype6-dev:i386 libx11-dev:i386 libsm-dev:i386 libice-dev:i386

apt-get --yes install build-essential gcc-multilib g++
# due to https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/949606 we 
cannot directly install libgl1-mesa-dev:i386

apt-get --yes install libgl1-mesa-dev:i386 libgl1-mesa-glx:i386
#ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so 
/usr/lib/i386-linux-gnu/libGL.so
#ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 
/usr/lib/i386-linux-gnu/mesa/libGL.so

Re: [Pharo-dev] The funny side of Pharo : Message Definitely Not Understood

[Jimmie Houchin]

On 05/20/2014 04:00 PM, Esteban A. Maringolo wrote:

2014-05-20 17:21 GMT-03:00 Nicolas Cellier 
nicolas.cellier.aka.nice-re5jqeeqqe8avxtiumw...@public.gmane.org:


If we are prepared to see it failing, it does not really matter, it's in the
contract...
The only problem is to be aware of this contract and avoid negative
impression.
Maybe an advanced menu triggered by some preference?


Or a one liner:
Smalltalk upgrade

Possible with a warning (muteable) to avoid unintended executions, and
enable unattended (i.e. scripted) upgrades.

Regards.


Or even also something like

Smalltalk snapshotAndUpgrade
or
Smalltalk saveImageAndUpgrade

That way the images current state is saved or snapshotted and if the 
upgrade messes everything up, you are back to where you were before the 
upgrade.


Just a thought.

Jimmie

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Jimmie Houchin]

On 05/13/2014 10:45 AM, Craig Latta wrote:

Hoi!

  Eliot wrote:


Pharo isn't inspired by Smalltalk; it /is/ a Smalltalk. Trying to
be mealy-mouthed about it and claiming inspiration, rather than
proudly declaring its a Smalltalk is IMO as bad as apologizing for it
being dead... We don't need to avoid the S word...

  Sean later wrote:


...it's a question of who you're marketing to. Since we're marketing
to non-Smalltalkers (quite wise since 16% market penetration is the
tipping point, and we're not there yet), clearly Pharo is Smalltalk-
inspired is the thing to say. It's not any more or less true than
the latter, just more useful in its context.

  And of course, with apologies to Alan, some of us think the name
Smalltalk was a poor choice from day one (in 1971). Surely there are
names which are suitably innocuous[1] but also convey some of the
magic in providing computer support for the creative spirit in
everyone[2]. Smalltalk is a vague and anemic name. From that weak
starting point, the other baggage is even heavier (perhaps it's helpful
to think of a balloon here? :).

  I would use a new name and not mention Smalltalk at all unless
asked about it. At that point, I would proudly recount accomplishments.
Whenever someone just blurts out that Smalltalk is dead, I always
correct them, and it's not difficult. Smalltalk-inspired is a
non-starter, because it implies (in all contexts) that there isn't a
direct line of descent (there clearly is). I agree that it sounds
mealy-mouthed, disingenuous. Smalltalk-derived would be the honest
phrasing, and also sounds bad. Yeesh, if you have a problem with the
Smalltalk name, don't be the first to mention it. :)

  Let's put more energy into a concise and intriguing description. I
think the primary concepts are programming, dynamism and messaging. The
word livecoding seems to resonate these days. If we're going to repeat
a word twenty times, I would choose that one. :)  It has a nice ring
that draws people in. When they ask what livecoding is, you can describe
dynamism, and then describe how the coding is structured (messaging,
objects, etc.).


  thanks,

-C

[1] http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
[2] http://tinyurl.com/25s52qd (archive.org, Ingalls)

--
Craig Latta
www.netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


I would like to repent of my position that Pharo is Smalltalk vs. Pharo 
is Pharo.


I have been watching videos on Self. I have also given my understanding 
some more thought.


I do strongly dislike and argue against the Pharo is Smalltalk inspired. 
To me it is not accurate. As Craig said, Pharo is Smalltalk derived. It 
still runs Smalltalk code without conversion. It is still born from a 
Smalltalk. Pharo may be Self inspired or ??? inspired. But it is from 
Smalltalk therefore Smalltalk derived.


Here is why I think it is okay to say Pharo is Pharo. And when Smalltalk 
is mentioned, explain that Pharo is Smalltalk derived. Pharo began as a 
Smalltalk with a vision to expand beyond Smalltalk-80 and add features 
inspired by other modern programming languages.


I still believe that none of this makes Pharo not a Smalltalk. But here 
is why I in my current understanding would change to Pharo is Pharo. 
Smalltalk is a language, name, environment and implementation created by 
a certain group of people. Pharo is not that group of people. Pharo 
began with an artifact from those people. So the question could be 
presented, does Pharo have the right to conscript the name Smalltalk and 
extend its vision, implementation and meaning. Conservatively, I would 
say it is fairer to Pharo and to Smalltalk to let Pharo be Pharo and 
have liberty in its vision, implementation, definitions and marketing 
decisions.


Just a few more thoughts to toss into the fray.

Jimmie

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Jimmie Houchin]

On 04/28/2014 11:12 AM, Marcus Denker wrote:

… more a Smalltalk one using Pharo:

MountainWest RubyConf 2014

Noel Rappin: But Really, You Should Learn Smalltalk”

Smalltalk has mystique. We talk about it more than we use it. It seems like it 
should be so similar to Ruby. It has similar Object-Oriented structures, it 
even has blocks. But everything is so slightly different, from the programming 
environment, to the 1-based arrays, to the simple syntax. Using Smalltalk will 
make you look at familiar constructs with new eyes. We’ll show you how to get 
started on Smalltalk, and walk through some sample code. Live coding may be 
involved. You’ll never look at objects the same way again.


http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk


In this thread and many others there is this debate as to whether Pharo 
is a Smalltalk or is Smalltalk Inspired.


I find the Smalltalk Inspired arguments to be unpersuasive. To be 
Smalltalk Inspired is to say that you are not a Smalltalk. It is to say 
that Pharo is not Smalltalk but inspired by it.


I find that reasoning patently false.

First of all everything in Pharo begins from a Smalltalk image. It comes 
from Squeak Smalltalk which comes from Apple Smalltalk. etc.


Pharo has an isA relationship with Smalltalk, not an isInspiredBy 
relationship. It may change and add features, but as has been stated 
before, Smalltalk isn't a static idea or artifact. It has always been a 
dynamic live environment in which to change itself into something it 
believed to be better. By removing features and by growing them.


Smalltalk (an instance of SmalltalkImage), SmalltalkImage, 
SmalltalkImageTest, SmalltalkEditingState are all part of the Pharo 
Smalltalk image.


The Pharo image is a Smalltalk image. It says so inside the image itself.

Where are we hosting are source code?  Would that be SmalltalkHub?
Lets see something.
http://www.smalltalkhub.com/#!/~Pharo

Okay, Pharo might be doing things that would break compatibility with 
other Smalltalks. And that causes some people pain and grief. However 
that does not make Pharo not a Smalltalk. Was Smalltalk 76 constrained 
by backward compatibility with Smalltalk 72? Or Smalltalk 80 with either 
Smalltalk 76 or 72?  No!


Is it a requirement of Pharo to be constrained by other Smalltalk 
implementations in order to still be a Smalltalk. No!


And then there is the argument of the outside worlds perception of 
Smalltalk. Since when does the perception of the outside world change 
whether or not Pharo is a Smalltalk? If the outside world changed their 
mind and decided Smalltalk is wonderful, does Pharo then all of the 
sudden become a Smalltalk? Ugh!


We are who we are. Our roots are our roots. Pharo should be happy and 
proud to be a Smalltalk. A Smalltalk that is continuing the heritage of 
innovation. A Smalltalk that is continuing the heritage of inventing the 
future.


We have decided to be marketing driven. Marketing is important. But 
marketing should determine who we are. And we should engage in 
disingenuous marketing practice trying to hide our roots or who we are.


Why do we things distancing ourselves from Smalltalk advantages us? Just 
because there are lots of uneducated people who have the wrong idea 
about Smalltalk. Clojure embraced its Lisp heritage and is thriving. 
Lisp has every bit as much baggage.


This talk which inspired this thread called Pharo as Smalltalk. He said, 
Pharo Smalltalk throughout the presentation. So in the mind of the 
presenter and now in the mind of the audience at the conference and of 
the video, Pharo is a Smalltalk. So now are we to go about re-educating 
all these people that Pharo is not a Smalltalk but is rather Smalltalk 
Inspired?


We don't require the outside world's permission. We don't need their 
approval. We would like to have a reasonable and sufficient number of 
them to catch the Pharo Smalltalk vision and become a part of the 
family. Do we really desire everybody. No. Do we desire those people who 
are so closed minded that the mention of Smalltalk closes their mind 
because of their ignorance. I don't think so.


Smalltalk is different. Pharo is Smalltalk and is different. There will 
be those who don't like it because of the baggage they bring, not the 
baggage we bring. And that is okay. All of us think different. People 
need to embrace what empowers them and quit complaining about what 
empowers somebody else. We need to embrace empowering people who 
understand Smalltalk not the people who don't get it for whatever 
reason. Let those people go and be empowered somewhere else. We and they 
will both be better off.


Feel free to shred and destroy my arguments. I am proud to use 
Smalltalk. And currently Pharo is the Smalltalk I am choosing to use. 
Currently I am studying C. A C library is required for my project and in 
order to use Pharo and use this library, I need sufficient C skills.


My opinion 

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Jimmie Houchin]

In the Smalltalk heritage. Pharo comes from Smalltalk 80.

But we don't want to be stuck in 1980. We want Smalltalk 2014.
Smalltalk 80 was modern for 1980. They didn't want to be stuck in 1976. ...

And Smalltalk isn't unique to this. Is C11 not a C because it is not 
KR, or C89, C90 or C99?
Is Python 3.x not Python because it is not fully compatible with Python 
2.x which is dominant?


Pharo wants to be a modern Smalltalk able to empower people in this era 
to do things that we do in 2014. We need appropriate modularity in the 
image. We need the image to be clean. We need to learn the lessons we as 
Smalltalker's have learned in the last 24 years and apply them to Pharo 
Smalltalk. And I believe that is much of what Pharo is attempting to do.


Noel in his talk said that Smalltalk doesn't play well with others. And 
with Pharo it still isn't as easy as in other languages like Python, 
Ruby, Lua, etc. But with NativeBoost we have a tool which enables us to 
do much. And NativeBoost isn't finished. I believe when NativeBoost is 
fully mature and the vm/image has sufficiently changed to enable us. We 
will have one of the best plays with others well stories.


I know in the app I am writing, NativeBoost's current condition 
struggled with my library. It often crashed. This library has to deal 
with a C Thread. Which is why I am spending my current time studying C.


Whether or not the Smalltalk Inspired crowd likes it, the moment some 
else declares that Pharo is a Smalltalk the Smalltalk Inspired marketing 
is tanked. The cat is out of the bag.


The Reddit thread demonstrates this. People went to the new website. 
They read the current marketing and were confused. What is this Pharo 
thing. And in the thread it comes out that Pharo is a Smalltalk. Lets 
make that clear up front. Then lets define what it means to be Pharo 
Smalltalk.


Here is an unfortunate quote from that thread.


emaringolo 1 point an hour ago
Pharo is aimed to do serious/business development, and it's been 
reshaping itself since its conception (several years ago when it forked 
from Squeak).
It doesn't want to have any backward or historic compatibility with 
other Smalltalks.
You can see its changelogs and the roadmap for future versions to see 
how it is different, and how it will be different.



This makes it sound like Pharo wants remove compatibility simply for the 
sake of not being a Smalltalk. As opposed to what I believe Esteban 
meant. And yes I understand that English is not his native language, and 
there are many for whom it is, who still use it poorly. What I believe 
he meant, is that Pharo will not be constrained by backward 
compatibility. If a change or feature that is of value to Pharo 
Smalltalk. That feature will be done even if it means breaking backward 
compatibility with other Smalltalk 80 based Smalltalks. We are moving 
forward. But this does not invalidate Pharo being a Smalltalk. As has 
been stated before, breaking changes happened in Smalltalk 76 and 80.


Smalltalk has a wonderful heritage. It is not without its issues. 
However the good of Smalltalk is enormous. Take a look at this chart

http://exploringdata.github.io/vis/programming-languages-influence-network/
Smalltalk is a big influence in the history of programming. This is 
something worth being a part of. Be proud of it.


Pharo needs to define what one vision of a modern Smalltalk is. Let us 
educate people of what our vision for Pharo Smalltalk is. And guess what 
folks its 2014. Before long it wont be. And before long the vision of 
Pharo 2014 will no longer be any more modern than Smalltalk 80. But 
neither Smalltalk 80 nor Pharo 3.0 constrain what it means to be 
Smalltalk. Smalltalk inspires vision and inspires people to do things 
which change the present and the future. Lets build on that heritage and 
take it forward. What does a modern Smalltalk snapshot 2014 mean. Lets 
educate and communicate. Others (non-Smalltalkers) don't get to define 
what Smalltalk is. We do.


Let us learn from them what they think Smalltalk is. Where they are 
wrong, educate them. Where they are right and we have an issue. Let's 
learn a lesson and improve our Smalltalk.


Computer science/art is young. This is a journey. Lets make it a good one.

Jimmie



On 04/30/2014 11:12 AM, p...@highoctane.be wrote:

Pharo := Smalltalk ++





On Wed, Apr 30, 2014 at 5:43 PM, Jimmie Houchin jlhouc...@gmail.com 
mailto:jlhouc...@gmail.com wrote:


On 04/28/2014 11:12 AM, Marcus Denker wrote:

… more a Smalltalk one using Pharo:

MountainWest RubyConf 2014

Noel Rappin: But Really, You Should Learn Smalltalk”

Smalltalk has mystique. We talk about it more than we use it.
It seems like it should be so similar to Ruby. It has similar
Object-Oriented structures, it even has blocks. But everything
is so slightly different, from the programming environment, to
the 1-based arrays, to the simple syntax

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Jimmie Houchin]

On 04/28/2014 11:12 AM, Marcus Denker wrote:

… more a Smalltalk one using Pharo:

MountainWest RubyConf 2014

Noel Rappin: But Really, You Should Learn Smalltalk”

Smalltalk has mystique. We talk about it more than we use it. It seems like it 
should be so similar to Ruby. It has similar Object-Oriented structures, it 
even has blocks. But everything is so slightly different, from the programming 
environment, to the 1-based arrays, to the simple syntax. Using Smalltalk will 
make you look at familiar constructs with new eyes. We’ll show you how to get 
started on Smalltalk, and walk through some sample code. Live coding may be 
involved. You’ll never look at objects the same way again.


http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk


One more thought about Pharo being a Smalltalk.

The Pharo Wikipedia page from day one to today has declared Pharo as a 
Smalltalk.

https://en.wikipedia.org/wiki/Pharo


A quote from the first entry.

Pharo is a fork of Squeak, an implementation of the object-oriented, 
dynamically typed, reflective programming language Smalltalk.



A quote from the current entry.

Pharo is an open-source Smalltalk-environment released under the MIT 
license since 2009.

...
Pharo is a fork of Squeak, an open source Smalltalk environment created 
by the Smalltalk-80 team (Dan Ingalls and Alan Kay). The Pharo team want 
to develop a modern Smalltalk for companies and software engineering 
research.



Smalltalk is mentioned over 20 times. Pharo is listed as being written 
in Smalltalk. Not being written in Pharo.


Also, Smalltalk is the original pure object-oriented language.
If Pharo ditches Smalltalk, are we ditching OO also.

The only and sole reason for not proudly proclaiming Pharo as Smalltalk 
is marketing. That type of marketing cuts both ways. We also lose the 
positive of Smalltalk.


We can't undo our history. We are a Smalltalk. We can invent our future. 
Just as a true Smalltalk should.


Smalltalk has baggage. So does Object-Oriented programming. But just 
because the functional people, the Clojure people flog OO, doesn't mean 
we abandon that terminology. We embrace OO and we educated people that 
C++ and Java do not get to be arbiters of defining what OO means. We 
show them what OO really means.


And so we do not let the Smalltalk detractors define us either.

I think our new website should proudly reflect that Pharo is a 
Smalltalk. The Wikipedia page does, and rightly so.


I have been a part of the Squeak/Pharo community since the 2000. I still 
have much to learn. But this much I know. I am happy to be a 
Smalltalker. I have wandered around much, and I always wander back, 
because nothing else brings the experience and productivity. Not Python, 
Ruby, Lua, ...


Long live Smalltalk.

Jimmie

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Jimmie Houchin]

But that is the point. This kind of marketing is false. It denies who we 
are.


As soon as they look at Pharo. Learn to use and then learn that Pharo is 
a Smalltalk and that we are liars.


Did keeping silent about Pharo help in the Reddit thread. No.
Did the current marketing explain well what Pharo is. No.
Read the thread. People were confused.
And regardless of the marketing attempt, the fact of Pharo being a 
Smalltalk did not remain suppressed. So therefore, those who were closed 
minded against Smalltalk have then been alerted, and they can close 
their minds. Attempting to not make it plain was an abject failure.


People who understand the value of Smalltalk and of a modern open source 
implementation will come.



I guess none of the commercial Smalltalks are alive? Nobody knows of 
them. They are going broke?


Gemstone, VisualWorks, ...

What is this new thing that people are using?

Clojure based on Lisp. Not new.
Python 23 years old.
Lua 21
Ruby 19

Clojure based on Lisp but adding modern functional features disproves 
any thought that an old language with lots of baggage can't attract new 
users.

From the Clojure home page. Clojure is a dialect of Lisp
They embrace their heritage and are better for it. They also detail 
their value proposition and being a Lisp is part of it.



I am all agreeable to attracting people to our community. But falseness 
isn't the way.


Not everybody is closed minded and ignorant. Those that are we can wait 
until they are not.


But Pharo has to offer people the proper value proposition. When it 
does, I believe it will attract sincere people. When the value of Pharo 
meets the needs of the people, it will attact the appropriate people. 
But until then, we can market it however we want and they will not care. 
Right now Pharo is working hard to reach that point that it can offer 
them something they will value. For some it already does. For others not 
yet. That not yet, it a bigger obstacle than Pharo being marketed as a 
Smalltalk and telling the truth.


We need to embrace being a Smalltalk and sell our value proposition in 
terms that mean something to somebody who doesn't already get Smalltalk. 
We failed at that. Too vague, too ambiguous. It confused some of the 
Reddit people. People to whom we are supposedly intending to attract and 
market to.


Jimmie


On 04/30/2014 01:22 PM, Esteban Lorenzano wrote:

Again… you are missing the point.
nobody here doubts Pharo is a Smalltalk.
nobody outside our small world believes Smalltalk is alive.

And yes… you can argue all what you want. But you are scratching where 
it does not itch.


We choose not to *market* Pharo as a Smalltalk, because each time 
someone outside our small world hear about Smalltalk believes that is 
a long time dead language. No matter how much effort you put into 
explain that is not true, people will not believe it. And people is 
always more willing to try something new than something old (except in 
the case of wines and fine alcohols, of course).
So… we prefer to track people to our community and let them notice wat 
WE ALL KNOW: Smalltalk is not dead, and Pharo is a proof of that.


Esteban

On 30 Apr 2014, at 20:07, Jimmie Houchin jlhouc...@gmail.com 
mailto:jlhouc...@gmail.com wrote:



In the Smalltalk heritage. Pharo comes from Smalltalk 80.

But we don't want to be stuck in 1980. We want Smalltalk 2014.
Smalltalk 80 was modern for 1980. They didn't want to be stuck in 
1976. ...


And Smalltalk isn't unique to this. Is C11 not a C because it is not 
KR, or C89, C90 or C99?
Is Python 3.x not Python because it is not fully compatible with 
Python 2.x which is dominant?


Pharo wants to be a modern Smalltalk able to empower people in this 
era to do things that we do in 2014. We need appropriate modularity 
in the image. We need the image to be clean. We need to learn the 
lessons we as Smalltalker's have learned in the last 24 years and 
apply them to Pharo Smalltalk. And I believe that is much of what 
Pharo is attempting to do.


Noel in his talk said that Smalltalk doesn't play well with others. 
And with Pharo it still isn't as easy as in other languages like 
Python, Ruby, Lua, etc. But with NativeBoost we have a tool which 
enables us to do much. And NativeBoost isn't finished. I believe when 
NativeBoost is fully mature and the vm/image has sufficiently changed 
to enable us. We will have one of the best plays with others well 
stories.


I know in the app I am writing, NativeBoost's current condition 
struggled with my library. It often crashed. This library has to deal 
with a C Thread. Which is why I am spending my current time studying C.


Whether or not the Smalltalk Inspired crowd likes it, the moment some 
else declares that Pharo is a Smalltalk the Smalltalk Inspired 
marketing is tanked. The cat is out of the bag.


The Reddit thread demonstrates this. People went to the new website. 
They read the current marketing and were confused. What is this Pharo 
thing

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Jimmie Houchin]

I understand. My apologies for contributing to one of those days.
For me that day was while I was reading this thread and watching Doru 
and Sean arguing with Eliot. It almost made me want to go back to 
Squeak. Not that I am saying there is anything wrong with Squeak.


They were firmly arguing that Pharo is NOT Smalltalk. They contend that 
making changes that make it different than Smalltalk-80 make it not 
Smalltalk.


http://www.tudorgirba.com/blog/pharo-is-pharo

Their contentions were not refuted. I wanted to put forth my 
understanding and opinion that Pharo is a Smalltalk.


And then you reply stating of course everybody here knows Pharo is 
Smalltalk. But that is exactly what Doru is arguing against.


If Pharo is going to distance itself from Smalltalk and be consistent 
about it, then every Pharo reference to Smalltalk in the image or 
website or wikipedia unless historical should be changed.


This inconsistency makes Pharo look bad.

Jimmie

On 04/30/2014 01:58 PM, Esteban Lorenzano wrote:

Some days a I really would love not to love smalltalk...

On 30 Apr 2014, at 20:52, Jimmie Houchin jlhouc...@gmail.com 
mailto:jlhouc...@gmail.com wrote:


But that is the point. This kind of marketing is false. It denies who 
we are.


As soon as they look at Pharo. Learn to use and then learn that Pharo 
is a Smalltalk and that we are liars.


Did keeping silent about Pharo help in the Reddit thread. No.
Did the current marketing explain well what Pharo is. No.
Read the thread. People were confused.
And regardless of the marketing attempt, the fact of Pharo being a 
Smalltalk did not remain suppressed. So therefore, those who were 
closed minded against Smalltalk have then been alerted, and they can 
close their minds. Attempting to not make it plain was an abject failure.


People who understand the value of Smalltalk and of a modern open 
source implementation will come.



I guess none of the commercial Smalltalks are alive? Nobody knows of 
them. They are going broke?


Gemstone, VisualWorks, ...

What is this new thing that people are using?

Clojure based on Lisp. Not new.
Python 23 years old.
Lua 21
Ruby 19

Clojure based on Lisp but adding modern functional features disproves 
any thought that an old language with lots of baggage can't attract 
new users.

From the Clojure home page. Clojure is a dialect of Lisp
They embrace their heritage and are better for it. They also detail 
their value proposition and being a Lisp is part of it.



I am all agreeable to attracting people to our community. But 
falseness isn't the way.


Not everybody is closed minded and ignorant. Those that are we can 
wait until they are not.


But Pharo has to offer people the proper value proposition. When it 
does, I believe it will attract sincere people. When the value of 
Pharo meets the needs of the people, it will attact the appropriate 
people. But until then, we can market it however we want and they 
will not care. Right now Pharo is working hard to reach that point 
that it can offer them something they will value. For some it already 
does. For others not yet. That not yet, it a bigger obstacle than 
Pharo being marketed as a Smalltalk and telling the truth.


We need to embrace being a Smalltalk and sell our value proposition 
in terms that mean something to somebody who doesn't already get 
Smalltalk. We failed at that. Too vague, too ambiguous. It confused 
some of the Reddit people. People to whom we are supposedly intending 
to attract and market to.


Jimmie


On 04/30/2014 01:22 PM, Esteban Lorenzano wrote:

Again… you are missing the point.
nobody here doubts Pharo is a Smalltalk.
nobody outside our small world believes Smalltalk is alive.

And yes… you can argue all what you want. But you are scratching 
where it does not itch.


We choose not to *market* Pharo as a Smalltalk, because each time 
someone outside our small world hear about Smalltalk believes that 
is a long time dead language. No matter how much effort you put into 
explain that is not true, people will not believe it. And people is 
always more willing to try something new than something old (except 
in the case of wines and fine alcohols, of course).
So… we prefer to track people to our community and let them notice 
wat WE ALL KNOW: Smalltalk is not dead, and Pharo is a proof of that.


Esteban

On 30 Apr 2014, at 20:07, Jimmie Houchin jlhouc...@gmail.com 
mailto:jlhouc...@gmail.com wrote:



In the Smalltalk heritage. Pharo comes from Smalltalk 80.

But we don't want to be stuck in 1980. We want Smalltalk 2014.
Smalltalk 80 was modern for 1980. They didn't want to be stuck in 
1976. ...


And Smalltalk isn't unique to this. Is C11 not a C because it is 
not KR, or C89, C90 or C99?
Is Python 3.x not Python because it is not fully compatible with 
Python 2.x which is dominant?


Pharo wants to be a modern Smalltalk able to empower people in this 
era to do things that we do in 2014. We need appropriate modularity 
in the image. We

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Jimmie Houchin]

Let me reply to this as it is my quote you are quoting.

On 04/30/2014 03:34 PM, Sean P. DeNigris wrote:

I was reading this thread and watching... Sean arguing... that Pharo is NOT
Smalltalk

No As I and Esteban (at least, maybe others) have repeated, *we are
NOT saying that Pharo is not Smalltalk*.


I said that because you joined in with Doru who was stating firmly that 
Pharo is not Smalltalk and gave a link to his post.

http://www.tudorgirba.com/blog/pharo-is-pharo

Where he explicitly states,
 Pharo is not Smalltalk. Pharo is Smalltalk-inspired. 

Which makes Pharo is Smalltalk and Pharo is Smalltalk-inspired as 
opposing each other.

Doru is explicit and insistent on this point.
So by association, you engaged after his message in the Pharo is 
Smalltalk Inspired argument.


That is how I arrived at associating you with the claim that Pharo is 
not Smalltalk.

Right or wrong that is how I included you in that aspect of the discussion.


Either we're not explaining ourselves well or (more likely IMHO) everyone is
so emotional over this (and it's a good thing that we care that much) that
they're not actually reading what we're saying.

How can you read either
http://forum.world.st/Pharo-is-Smalltalk-and-Not-td4757342.html or my two
main points at
http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756995.html
and say that I'm saying that?!

I think there is a middle ground where everyone gets what they want. I've
tried to express it in the first link above. Please - I love differences and
discussion, but if you're going to react, react /specifically/ to what I
said (e.g. the two points I made in the second link), because right now, you
are only arguing with yourself ;)


Now in your above discussion.

You state that Smalltalk = Smalltalk-80 to 99.9% of the developers out 
there.


I don't agree. I would be brazen enough to state that a very high 
percent of developers out there know almost nothing about Smalltalk. I 
would wager a high percent weren't even born when Smalltalk-80 came out. 
You might be one for all I know. I would also wager that most developers 
don't know there is a Smalltalk-80. I imagine that there is more 
ignorance than knowledge about Smalltalk.


Those who have heard of Smalltalk have probably heard of Smalltalk from 
someone who doesn't use Smalltalk for whatever reason. And there are 
many reasons, and many are valid. So what they hear is reasons not to 
use Smalltalk or why people in their community who have a cursory 
Smalltalk experience state as their reasons for not using Smalltalk.


I just don't happen to believe that we should allow people who don't use 
Smalltalk to define it. They can express their opinion, and we should 
listen. That which is valid learn, that which is not nicely engage in 
education and communication. They may still choose not to use Pharo or 
Smalltalk, but hopefully they won't engage in disinformation.


In Pharo's four years since 1.0 Pharo has changed much. So Pharo has to 
deal with its own baggage. There are many who used Pharo 1 or 2. They 
encountered whatever challenges inherent in those versions and left 
disappointed. We will have to rebuild Pharo's image to those people. We 
will have to answer for Pharo's history. Unless we are to say, we are 
targeting our marketing to only those people who have never used any 
dialect of Smalltalk. But this Smalltalk-Inspired vs. Smalltalk is a 
very leaky marketing plan. As soon as anybody not in on the game 
declares, Pharo is a Smalltalk, the game is over. We then have to have 
an answer for why we are a modern Smalltalk and how we answer our past 
failures.


However, there are many who have a modest understanding of Smalltalk.

For example, why does Noel Rappin teach that You Should Learn Smalltalk, 
but does not teach that You Should Use Smalltalk? What are his reasons 
for not using Pharo?


For the people who get Smalltalk, Pharo, why do they not use it? Those 
are answers we need so that we can make valuable decisions on providing 
a story that is attractive to both those who have used Pharo/Smalltalk 
and those who have not.


We need to increase the value proposition so that we can increase people 
who say, In order to provide bread, I program in X, but in my spare 
time projects I use Pharo. As that group increases I believe we will 
see an increase in business use of Pharo. And people will then be able 
to make a living programming in Pharo.


Plays well with others is still a big issue. It is the one I struggle 
with. Interfacing a C library and its issues. I love Pharo/Smalltalk and 
I struggle sometimes with whether or not I will get to use it. Because 
my C is lacking. I wrote the NativeBoost wrapper around the library. But 
it crashes. But the intersection of those who have knowledge in this 
area is small. And those who have time to deal with other peoples issues 
is even fewer. So I am spending my time studying C hoping that at some 
point the 

Re: [Pharo-dev] Punishment as an educational method

[Jimmie Houchin]

I agree. I don't believe Igor intended to mean punishment, even if 
punishment is what he said. He is not native to the English language or 
idioms.


When he spoke of the child, he spoke of allowing the consequence of the 
child's actions to occur. Not that the parent punished the child. This 
is very valid and in my opinion often preferred. You can explain and 
teach. But at some point the individual will make a choice to abide by 
what was taught or explained or to possibly test the teaching and see if 
it is true. Children do this all the time. Their prime thought is to 
test what they are taught and to challenge it. Only after a sufficient 
number of confirmations do they give a certain amount of implicit trust 
to the teacher or parent.


Fire in Igor's example is a common example for teaching children. 
Parent's who childproof their home generally do their children and 
themselves a disservice. I am a father of 10 children, 28-4 years of 
age. I have never had a child burn themselves on a heater, or hurt 
themselves significantly falling down the stairs.


Consequences, good and bad are a prime means of learning.

But consequences should be appropriate for action. If we have within our 
power, and sometimes we do and sometimes we don't, have the ability to 
determine the consequences, then we should do so in consideration of 
what we are protecting, rewarding, punishing. How do we want the 
standard of behavior to be in that situation.


Just my thoughts.

Back to lurking.

Jimmie



On 01/09/2014 03:30 PM, Sven Van Caekenberghe wrote:

I don't think Igor meant punishment as a tool, but rather experience something 
negative for yourself.

I am sure that if you think back at your own development, there were instances 
where you did not listen to adults warning you and only learned certain things 
the hard way.

Anyway, we're getting way off topic ;-)

On 09 Jan 2014, at 22:25, Stephan Eggermont step...@stack.nl wrote:


Igor,

The way you describe the role of punishment in education is not in line with 
current research. Most learning happens trough copying the behavior of others, 
and punishment has a number of negative consequences on character development, 
making it a non-suitable instrument. You might want to take a look at the work 
done by Marshall Rosenberg on non-violent communication.

Stephan

Re: [Pharo-dev] Remove Class Category

[Jimmie Houchin]

Hello,

Thanks for the reply.

This does exactly what I wanted. I believe I saw the method while 
browsing the plethora of methods that the Finder pulls up. But I did not 
know automatically how to have the instance of the SystemOrganizer to 
operate on. And since I was not even sure that it was the correct way. I 
finally decided to ask.


Thanks.

Jimmie


On 11/12/2013 2:25 AM, Goubier Thierry wrote:

Hi,

this probably depends on the version of Pharo you're using but, in 
3.0, what you can do is:


Smalltalk globals organization removeCategory: name.

And then you need to update the relevant RPackage tag:

package removeClassTag: name

(Because RPackage class tags are synchronized on some category 
operations, but not all).


In 2.0, you just have to execute the first one.

Nautilus, or Browser, are good places to see that type of code.

Thierry

Le 11/11/2013 23:33, Jimmie Houchin a écrit :

Hello,

I am wanting to write a method which uninstalls all of the Classes which
I have created.

I have one which looks like this:

uninstall

 AllClasses reverse do: [ :c | Smalltalk removeClassNamed: c ]


However the class category which was created to install them into still
remains. I am having a hard time discovering what method I use to remove
the category these classes were in.

There are a lot of methods with category in the name. And is quite
confusing how category and protocol are sometimes used interchangeably.
I can't tell whether or not they are talking about removing the method's
protocol categorization or the classes' category categorization. Its not
until you go read the source that you might learn which you are 
looking at.


Any help pointing to the method I am looking for is greatly appreciated.

Jimmie

[Pharo-dev] Remove Class Category

[Jimmie Houchin]

Hello,

I am wanting to write a method which uninstalls all of the Classes which 
I have created.


I have one which looks like this:

uninstall

AllClasses reverse do: [ :c | Smalltalk removeClassNamed: c ]


However the class category which was created to install them into still 
remains. I am having a hard time discovering what method I use to remove 
the category these classes were in.


There are a lot of methods with category in the name. And is quite 
confusing how category and protocol are sometimes used interchangeably. 
I can't tell whether or not they are talking about removing the method's 
protocol categorization or the classes' category categorization. Its not 
until you go read the source that you might learn which you are looking at.


Any help pointing to the method I am looking for is greatly appreciated.

Jimmie

Re: [Pharo-dev] default monospaced code font

[Jimmie Houchin]

On 10/15/2013 7:46 AM, Camillo Bruni wrote:

processing.org uses monospaced font, these are the art guys that have more 
sense graphics
than any one this mailinglist (BTW, how many of you have visited an art school?)

Besides Smalltalk, I don't know any other language that would use proportial 
fonts.

After that, anybody who really knows how to use Pharo can modify it.
The newcomer is the only one you target...


Regarding Art School. No I haven't but my father-in-law did, one of my 
daughters is. Regardless, it doesn't matter. Not that either do fonts.


Has anybody involved with vim or emacs been to art school?
Two of the most used and fought over editors out there and they are as 
ugly as ...  Yet their ugliness doesn't deter their advocates. Why? 
Because their advocates find value in what you can do with them.


I am very much in the proportional camp. I spend my day typing, and 
writing in proportional fonts.


One of the nice things about Smalltalk and any higher level language in 
theory is that it brings you somewhat closer to natural language. And in 
general most things we do in our natural languages is in a proportional 
font. And no, I don't believe we need a cognitive indicator which tells 
our brain that this is different. We are writing software not an article.


Once upon a time all or almost everything done on a computer was in a 
monospace font. Regardless as to whether or not it was writing software 
or writing a novel.


People who like monospace often prefer underscores and not camelCase. 
They also like 79 character line breaks and all other sorts of 
conventions created due to the environment they operate in.


Other languages do not have fonts. They generally do not have editors. 
They are quite different from the Smalltalk experience. We should not 
impose their constraints into our environment. Users of those languages 
choose editors. Users of those editors choose fonts. The language itself 
imposes no such constraints or opinions outside of community convention.


We do not operate in any of those environments. We should not feel 
compelled to impose any of those constraints.


Yes, I agree. We should not be different for different sake.
But, I find value in proportional fonts. Let me repeat that, I find 
value in the proportional font. Therefore I do not believe that using a 
proportional font is being different just to be different.


I and most people who are not explicitly placing themselves in this 
context, coding, find them to be more readable. Are magazines, 
newspapers, books, websites mainly in monospace? Most of what we read is 
proportional for a reason.


Yes, anybody can change their personal use of the system and choose 
monospace or proportional. There is great value in establishing a good 
community standard for the image. Not necessarily a standard that is 
catering to beginners current comforts. But one that is a good community 
default. A default which experienced Smalltalkers find productive. Then 
provide good learning tools to enable beginners to be on a path of 
increasing productivity. A beginner will often stay with what they start 
with for a very long time. So if our initial image is one that caters to 
beginners, then they may live their a very long time. And not to their 
betterment.


I think we should be comfortable with and embrace who we 
(Smalltalkers/Pharo) are. Not seek to change unnecessarily to conform to 
a different standard which was established based upon different criteria 
and constraints which do not apply to us.


I personally do not understand how so many people find Smalltalk to be 
uncomfortable or difficult. I am far from a pro Smalltalker. But I find 
nothing else to be as comfortable and productive as Smalltalk/Pharo.


My only thoughts is that everybody thinks in different ways. People are 
drawn to languages work like they think. And for some people Smalltalk 
isn't it. I know I find many languages out there to be less than 
pleasant and ugly no matter what font they use. :)


Just my opinions.

Thanks.

Jimmie

Re: [Pharo-dev] default monospaced code font

[Jimmie Houchin]

On 10/15/2013 11:06 AM, Esteban Lorenzano wrote:
*From: *Eliot Miranda eliot.mira...@gmail.com 
mailto:eliot.mira...@gmail.com




Progress is possible,


Indeed it is.  And moving from proportional to mono-spaced fonts is 
not progress, it is regress.


perfection was not achieved in 81 or in 95.


I didn't say it was.  I said that systems designed with a coherent 
aesthetics and philosophy are more coherent, powerful and 
comprehensible than those which are not.


yes, they are, I agree with that, and that's what we are trying to 
achieve... advancing one small step at a time, because we cannot doit 
all together, sadly.
What I do not see is how proportional fonts fits more with a pharo 
coherence (which in my pov does not exists today) than a monospaced one.


But the change is away from proportional to monospace. I think the sale 
must be made as to what does that actually buy us. How does this improve 
our experience, pharo coherence?


It seems that many of us here don't believe that it provides that 
coherence of UI/UX that your hoping to move us towards.


So when changing from what we have, it seems that it needs to 
demonstrated that the change is for the better and not neutral or worse.


I personally don't buy the it is less foreign to non-Smalltalkers 
argument. non-Smalltalkers would just move their distaste of Smalltalk 
somewhere else. Why do we have to use the image? Why can't I use Emacs, 
vim, Eclipse? Its all very personal and sometimes very visceral.


I have seen some visceral comments from Igor regarding Python. I could 
make some from the C++ I've been looking at.


We need to be the best open source Smalltalk-like experience. And not be 
constrained to other languages/editors/environments constraints and 
views on the world.


So those who choose to advocate for a change. Advocate. Make the sale.
Or else lets not make the change.

Jimmie

Re: [Pharo-dev] Please contributors fill up this form...

[Jimmie Houchin]

On 10/9/2013 6:34 AM, Stéphane Ducasse wrote:

Hi guys

I would like to get
contributors.pharo.org a bit more representative of Pharo.

We should have Previous contributors and enhance the current list.
Can you please reply to this mail



PharoContributor new
name: 'Jimmie Houchin';
email: 'jlhouc...@gmail.com';
	description: 'Use Pharo for personal and in house business projects. 
Working on developing Trading Software using Pharo.';
	image: 
'http://www.gravatar.com/avatar/faf295dadadd64dae51be0d62c1a2d9f.png';

yourself

[Pharo-dev] New mailing list on Gmane

[Jimmie Houchin]

Hello,

I frequently read the Pharo list on Gmane. Since the mailing list move 
to a new server, none of the messages are being sent to Gmane.


There have been no new messages since May 15. It would be nice if the 
service to Gmane could be resumed. And if possible to populate the 
missed messages.


Just wanted to let the list know.

Thanks.

Jimmie