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

[Benoit St-Jean via Pharo-dev]

Can you come up with a simple "base case" so we can find the bottleneck/problem?
I'm not sure about what you're trying to do.
What do you get if you try this in a workspace (adjust the value of n to what 
you want, I tested it with 10 million items).
Let's get this one step at a time!


|  floatArray  n  rng t1 t2 t3 r1 r2 r3 |
n := 1000.
rng := Random new.
floatArray := Array new: n. floatArray doWithIndex: [:each :idx | floatArray 
at: idx put: rng next].
t1 := Time millisecondsToRun: [r1 := floatArray sum].t2 := Time 
millisecondsToRun: [| total |  total := 0. floatArray do: [:each | total := 
total + each ]. r2 := total]. t3 := Time millisecondsToRun: [r3 := floatArray 
inject: 0 into:  [: total :each | total + each ]].
Transcript cr.Transcript cr; show: 'Test with ', n printString, ' 
elements'.Transcript cr;show: 'Original #sum -> Time: ', t1 printString, ' 
milliseconds, Total: ', r1 printString.Transcript cr;show: 'Naive #sum -> Time: 
', t2 printString, ' milliseconds, Total: ', r2 printString.  Transcript 
cr;show: 'Inject #sum -> Time: ', t3 printString, ' milliseconds, Total: ', r3 
printString.  
--
Here are the results I get on Squeak 5.3
Test with 1000 elementsOriginal #sum -> Time: 143 milliseconds, Total: 
4.999271889099622e6Naive #sum -> Time: 115 milliseconds, Total: 
4.999271889099622e6Inject #sum -> Time: 102 milliseconds, Total: 
4.999271889099622e6


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

On Thursday, January 6, 2022, 03:38:22 p.m. EST, Jimmie Houchin 
 wrote:  
 
 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] Bug 18632 : Virtual Machine parameters need to be documented

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---

Eliot,

I was referring to VM parameters (aka #vmParameterPut:at:).  But now 
that you mention it, it adds another level of complexity. When you 
specify something in the command line arguments, how do you resolve the 
fact that the command line argument tells you something that is 
different from what is in the image? The mechanics of the VM stuff is 
like black magic to most of us! You see, that's the type of question 
that is kinda "oral tradition" : if no one ever told you, you don't know 
since it's not obvious and rarely documented properly but, eh, it's 
written "somewhere" in the code of the VM! It might seem obvious to a 
very few of you, especially yourself, since you've been working on the 
VM long before my Vassili-Bykov-Days but for most of us, it's a case of 
very-interesting-to-read-but-way-too-complex ! ;)


To make a long story short, I was thinking about experimenting and 
trying to implement "stuff" with something similar to VisualWorks's 
MemoryPolicy (AbstractMemoryPolicy and subclasses to be more precise) 
for Pharo. It did save my/our/TheProjects' ass quite a few times. Yes, 
you can write scripts to customize a few things before you produce the 
"final" image but it is a pain in the as_ (the polite SQL way of 
describing it) and you have to keep track of artifacts (scripts, files, 
workspace code, whatever) to produce the final image.  With custom 
memory policies, everything resides in the image and it is sooo 
much simpler to deal with!


There is no such thing as a one-configuration-fits-all.  That's why 
different types of applications have different needs for GC, memory, 
tenuring, memory-space sizes, etc. And quite frankly, VW' MemoryPolicy 
is so far and by far the best solution I've seen to cope with that. 
There ain't such thing as 2 identical applications that have the exact 
same VM/GC/memory needs!


I was able to build/read a "collection" of articles/posts/PDFs about GC 
and the VM but, quite honestly, I kinda lost track of what is what and 
which is which.  Cog, Spur, stack or not, NewSpeak vs Squeak vs Pharo, 
32 vs 64 bits, jitted or not, and all permutations you can think of, for 
99.9% of us it is like trying to learn Mandarin in 2 days! I do/did read 
your blog as well as the blog of Clément Béra as well as Andres Valloud 
posts/papers on the subject but in the VM world, things quickly get 
complicated unless, like Obélix, you were born in it! I've read a 
gazillion papers on the GC and various Smalltalk memory models written 
by John McIntosh but are those papers/posts/articles still relevant?


In other words Eliot (and your VM wizard friends), the VM (aka GC and 
memory model) do need some "documentation love" for "the average 
Smalltalker" !  ;)


On 2020-02-07 13:59, Eliot Miranda wrote:

Hi Benoit,

On Fri, Feb 7, 2020 at 8:20 AM Nicolas Cellier 
<mailto:nicolas.cellier.aka.n...@gmail.com>> wrote:


Hi Benoit,
for some reason (?), your email was marked as SPAM in gmail...
There is a short description in primitiveVMParameter, which is
found in generated code, for example:

https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/src/vm/gcc3x-cointerp.c
or VMMaker source code (you can also find VMMaker source code in
pharo vm github repo, no time to dig).

Le jeu. 6 févr. 2020 à 12:45, Benoit St-Jean via Pharo-dev
mailto:pharo-dev@lists.pharo.org>> a
écrit :

I was looking for some documentation on VM parameters (are
they read,
read-write or write only as well as the expected argument
type) and came
across that issue on the old FogBugz database.


Are you talking just about vmParameterAt:[put:]/vm parameterAt:[put:] 
or are you also talking about command line arguments (pharos-vm 
--help/squeak -help)?
If the former, there are much more current comments in trunk Squeak 
SmalltalkImage>>vmParameterAt:[put:] than in Pharo; you could usefully 
copy that across. The comments in the two methods accurately specify 
which parameters are read/write, and which persist in the image header.


But I agree, more verbose documentation would be very helpful; the 
current documentation is very terse, and while it describes what the 
parameters are and whether they are writable, it really doesn't 
describe what the systems that they operate on actually do.  I'm happy 
to collaborate with you in developing better documentation.  If you 
will do the writing I will happily consult.  Does that work?




https://pharo.fogbugz.com/f/cases/18632/Virtual-Machine-parameters-need-to-be-documented

I tried looking it up on GitHub but couldn't find it. Am I
missing
something or I should open an issue?  I'm working on something
related
to various memory settings and not having any info on a lot of
these
paramet

[Pharo-dev] Bug 18632 : Virtual Machine parameters need to be documented

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
I was looking for some documentation on VM parameters (are they read, 
read-write or write only as well as the expected argument type) and came 
across that issue on the old FogBugz database.


https://pharo.fogbugz.com/f/cases/18632/Virtual-Machine-parameters-need-to-be-documented

I tried looking it up on GitHub but couldn't find it.  Am I missing 
something or I should open an issue?  I'm working on something related 
to various memory settings and not having any info on a lot of these 
parameters doesn't help.  While I could meticulously read tons of C code 
of the VM and pinpoint exactly what I need to know for each and everyone 
of these undocumented parameters, I'd gladly do it myself if any of the 
VM guys (Clément, Pablo, Alexandre or Eliot) have notes/documents/links 
that could help me do it.


tia

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


--- End Message ---

Re: [Pharo-dev] Pharo4pharo mailing-list announce

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Nobody said we were against such a mailing list! But, just as you, there 
are topics I skip on the mailing list. No harm done, quick & easy to do!


But one should never refrain from talking about other Smalltalk 
environments on a Smalltalk/Pharo list : if VisualAge, or VisualWorks, 
or Dolphin, or Squeak, or ObjectStudio, or VSE or any other Smalltalk 
can inspire us to make Pharo better, I don't think that saying "Dolphin 
really has a great look & feel for Windows app" is equivalent to saying 
"VisualWorks sucks" or "Pharo is crap" ! I could talk for hours at what 
those Smalltalk products rock.  I could also talk for hours at what 
those Smalltalk products suck. I could talk for hours about why product 
X is better that product Y for job Z.  That doesn't mean one product is 
crap and the other one is perfect! Every Smalltalk product has strengths 
and weaknesses.  Why shouldn't we be inspired by great features of other 
products that Pharo doesn't yet have?  Criticism of Pharo (or praise of 
other products) doesn't mean we hate or despise Pharo!  It just means 
that we care. And that we can make it better!


Also, inevitably you'll have non-Pharo & non-Smalltalk related topics 
sometimes popping up on the mailing list. Am I interested by digital 
image formats? Nope.  So if I see a thread about someone who wants to 
develop a library to read the FITS format (Flexible Image Transport 
System, used in astronomy mainly), chances are we'll see posts about 
astronomy & FITS for 2-3 days. I don't mind since, in the end, it still 
is Smalltalk-related!


On the topic of "Why is [insert your favorite non-Smalltalk programming 
language here] better than Smalltalk/Pharo?", I gave up that kind of 
discussion years ago... And on the rare occasions when I have it, I have 
it in private.  You'll always find a moron who thinks GW-BASIC + DOS 4.1 
+ dBase is the way to go.  I don't waste time with those people anymore! 
lol


On 2020-01-30 07:40, ducasse wrote:

You see this is several times that I gently ask if we can move on.
And regularly we get the same.

So I can also live pharo-dev.
At the end of the day we cannot have the cake and eat it too.

So you can consider that I’m an asshole. I’m probably that.
Now I’m super super fedup to have to jump over some thread.
I quit newsgroups in the past because of that. I quit Pharo-users 
because of that.


When I want to read about X Z Y and this is not related to Pharo then 
I google the Web.


S.


On 30 Jan 2020, at 12:05, Benoit St-Jean > wrote:



*From: *Benoit St-Jean mailto:bstj...@yahoo.com>>
*Subject: **Re: [Pharo-dev] Pharo4pharo mailing-list announce*
*Date: *30 January 2020 at 12:05:38 CET
*To: *pharo-dev@lists.pharo.org 


Wow!

That post on Pharo Weekly ( 
https://pharoweekly.wordpress.com/2020/01/30/ann-pharo-4-pharo-mailing-list/ 
) really sets a great welcoming ambiance for any newcomer interested 
by Pharo who'll read that or who'll stumble on it by accident while 
googling "Pharo+mailing+list" !


#Not #Fail #WorstAdvertisingEver

Please, take 30 seconds to remove that crap before too many people 
read it...


P.S. it's one thing to express yourself like that on a mailing list, 
it's another one to put it upfront on a blog...


On 2020-01-30 02:33, Stéphane Ducasse wrote:

Hi

Tired of boring and dull discussions about the past?
Tired and bored about the fact that the discussions are not about 
Pharo but about X, Z, K?

Want to get in touch with other real pharo users?
Want to have positive and nice discussions about Pharo?

This mailing-list is for you

https://lists.gforge.inria.fr/mailman/listinfo/lse-pharo4pharo

I created a new mailing-list for Pharo 4 Pharo.
The idea of this new mailing-list is to exchange between Pharo users 
on Pharo.


If you want to talk about the weather and other cool fishing 
practices or how other languages are super cool,

then you should use another mailing-list.

You can consider that I’m
[ ]  an asshole
[ ]  an arrogant idiot
[ ]  other
This is not my concern.

My concern is: can we respect Pharo and users of Pharo that want to 
share what they are doing

and ask questions about their language?

If you join this mailing-list be warned that I (yes me the 
benevolent dictator of Pharo) will remove you from the mailing-list

when you get on my nerves.

If you do not like it, do not like me, do not appreciate it, do not 
join!


S.

BTW they are plenty of newsgroups about Smalltalk and you can join 
there.




Stéphane Ducasse
http://stephane.ducasse.free.fr  / 
http://www.pharo.org 

03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France


--
-
Benoît St-Jean
Yahoo! Messenger: 

Re: [Pharo-dev] Pharo4pharo mailing-list announce

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---

Wow!

That post on Pharo Weekly ( 
https://pharoweekly.wordpress.com/2020/01/30/ann-pharo-4-pharo-mailing-list/ 
) really sets a great welcoming ambiance for any newcomer interested by 
Pharo who'll read that or who'll stumble on it by accident while 
googling "Pharo+mailing+list" !


#Not #Fail #WorstAdvertisingEver

Please, take 30 seconds to remove that crap before too many people read 
it...


P.S. it's one thing to express yourself like that on a mailing list, 
it's another one to put it upfront on a blog...


On 2020-01-30 02:33, Stéphane Ducasse wrote:

Hi

Tired of boring and dull discussions about the past?
Tired and bored about the fact that the discussions are not about 
Pharo but about X, Z, K?

Want to get in touch with other real pharo users?
Want to have positive and nice discussions about Pharo?

This mailing-list is for you

https://lists.gforge.inria.fr/mailman/listinfo/lse-pharo4pharo

I created a new mailing-list for Pharo 4 Pharo.
The idea of this new mailing-list is to exchange between Pharo users 
on Pharo.


If you want to talk about the weather and other cool fishing practices 
or how other languages are super cool,

then you should use another mailing-list.

You can consider that I’m
[ ]  an asshole
[ ]  an arrogant idiot
[ ]  other
This is not my concern.

My concern is: can we respect Pharo and users of Pharo that want to 
share what they are doing

and ask questions about their language?

If you join this mailing-list be warned that I (yes me the benevolent 
dictator of Pharo) will remove you from the mailing-list

when you get on my nerves.

If you do not like it, do not like me, do not appreciate it, do not join!

S.

BTW they are plenty of newsgroups about Smalltalk and you can join there.



Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France


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

--- End Message ---

Re: [Pharo-dev] Fed up

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---

+1000

I'm with you 110% on this one!

Who, in their right mind, would code like that? Is it a trend among 
younger Smalltalkers while dinosaurs like me just "naturally" still use 
the "old way" and blocks? And do we have statistics about how often that 
"syntax" is used in the current image? In the past, I've complained a 
gazillion times about portability between Pharo and other Smalltalks 
and/or legacy code so you pretty much know my position on this kind of 
semantic twist!  Okay, one might argue that using a symbol instead of a 
Block in your example saves you a big 16 characters to type.  But who 
spends all their day mostly iterating over a collection so that it 
becomes an issue to save 16 characters ???  And then, once we open that 
door, what's next?


aCol do: [:eachItem | eachItem calculateProvincialTax. eachItem 
calculateFederalTax. eachItem calculateRebates. eachItem calculateTotal]


Then, are we going to end up with "keystroke-savers" like:

aCol do: #calculateProvincialTax and: #calculateFederalTax and: 
#calculateRebates and: calculateTotal


Yeah, polymorphism is cool. But "coolness" has never been a reason in 
itself alone to use cool features just because they do exist!




;)


On 2020-01-21 15:10, ducasse wrote:

Hi

I’m fed up. Why?
Because I see lousy code in Pharo and that such lousy code in Pharo is slower, 
and sure that writing a type inferencer
for pharo will be more complex, and probably will make sista more complex too.

I asked the pharo consortium to take a clear position because I want a better 
Pharo not the inverse.
So what is it.

You can write in your code but not in Pharo.

aCol do: #store

in Pharo we should write

aCol do: [ :each | each store ]

Block argument should be blocks else any static analyser will have to check it 
is a block, it is a symbol, is
it a RANDOM object that answer value.

Seriously can be not make the life of people doing program analysis simpler?

So now if I’m wrong then I will shut up and I’m really pissed that we do that 
without paying attention
to the consequence.

I asked the consortium to take position and to take action.
We should have a better code review for REAL.

S.




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


--- End Message ---

Re: [Pharo-dev] BlueInk removal

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---

Stéphane,

You could have said the exact same thing in nicer words, calmly WITHOUT 
SHOUTING and taking it personal.


If people criticize stuff/work/code, it's because 1) they care about 
Pharo 2) they use Pharo. The day no one will complain on the list will 
mean Pharo's dead.


It also means people have to deal with real projects and real apps and 
real customers and real migration problems. We have a tool called 
deprecation, let's use it. It'll save a lot of headaches to everyone. 
And if you remove stuff, give the developers an extra chance by at least 
informing them of the upcoming changes/removals by deprecating stuff, 
not just removing it without warning!


I don't recall one single instance in my professional life when 
VisualWorks or VisualAge Smalltalk didn't provide EVERYTHING that was 
necessary to be compatible with the previous version to facilitate the 
job of their customers, us, the developers. Whether it was in the form 
of deprecated parcels or packages, Cincom & IBM (and now Instantiations) 
understood one thing : you don't migrate apps that generate millions a 
year like a tic-tac-toe project on GitHub. It takes time just to migrate 
from one version to the next, imagine the nightmare when "stuff had just 
been removed" out of the blue. If you want to see more commercial use of 
Pharo, you'll have to understand that!


In the meantime, could you PLEASE stop taking criticism as if it was 
directed towards you and/or the Pharo devs?


On 2019-11-27 15:31, ducasse wrote:

Cyril

there is no deprecation for classes: yes I would have to subclass each class 
and provide old classes.
Sorry but *I*** repackaged, cleaned the tests, cleaned the baseline, 
made sure that the baseline is working …. of
- GTRecorder (not used in Pharo since 3 YEARS).
- Enlumineur

And I do not have nor the time or energy at the end of the day to do that in 
addition
to do all the deprecation and of course fix all the dependencies tests.

Now if your message is that Pharo should stay with all that shit inside then 
perfect, I’m off.
I have plenty of other things (and a lot more exciting to do).

BTW I THE GUY THAT IS PRODUCING MIGRATOR: you see the idiot that is collecting 
all the deprecated methods
and packaged them so that OTHERS than me can migrate.

So now for Blueink then you take 5 min and change your scripts.
So GTEvent recorder you ask alex or milton to see if we can get rid of the 
problem.

I do not see why Moose is loading Roassal with it.
To me this is a bad dependency of Roassal.

If Pharo puts on itself so much constraints then at the end may be I should 
stop and do something and see
how great this super kitchen sink will evolved.

Have you ever dare to look at the BaselineOfPharo, IDE just for the fun.




Yes, this could have been handled much better, I guess (I don't know the 
details).

But for day to day work, you have to use Pharo 7, which should be 100% stable, 
while Pharo 8 is a moving target, an alpha version that is sometimes broken.


Hi,

I agree that the alpha version does not have to be stable all the
time, but I still don't think it justify to not deprecate things.

When you are working on stable version only, it is still better to be
able to migrate your projects from one version to the other via the
deprecation than to have everything broken and not loadable.

If you can't even load your code, it's much harder to fix it. So I
still think that we should go via deprecations. It has really a low
cost and make migrations so much easier. Especially it give us time
instead of giving us an ultimatum "You want to change of version? Then
you need to fix everything now".


Now, we still want users for Pharo 8, else there will be no feedback, so there 
are certainly two sides to this argument.

Sven





--
Cyril Ferlicot
https://ferlicot.fr





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


--- End Message ---

Re: [Pharo-dev] ZnBufferedReadStream and #upToAll:

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
If that was the case, then it makes no sense to implement #upTo: but not 
#upToAll: , right 


On 2019-03-17 10:37, ducasse wrote:

Was there a conscious decision not to include the #upToAll: method 
onZnBufferedReadStream?. This method is really useful for parsing files -- 
finding sub-patterns of bytes, etc. Perhaps #upToAll: is not the idiomatic way 
to do this, but I found it very useful to use in the plain old ReadStream 
classes.
I imagine that sven did not add it because on infinite stream it does not make 
sense.
Now it would be good to see how we can have useful extensions. But I let this 
to sven.



--- End Message ---

Re: [Pharo-dev] Proposal to remove [Stream|Collection]>>#write:

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Trying to be *somewhat* compatible and verifying (even quickly) that 
it's not breaking a gazillion things is the very least someone can 
do...  Backward compatibility is NOT a sin! ;)


On 2019-02-22 13:45, Sven Van Caekenberghe wrote:



On 22 Feb 2019, at 19:39, Stephan Eggermont  wrote:

Sven Van Caekenberghe  wrote:
.

So I propose to remove [Stream|Collection]>>#write:

What say thou ?

Check the selectors used in the latest packages on squeaksource, ss3,
smalltalkhub and decide.

Stephan

You forgot GitHub and all private company repositories in the world.



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


--- End Message ---

Re: [Pharo-dev] [Pharo-users] Class name with diacritic character and Pharo

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
While we're at it, a similar problem arises when the author name (in my 
case BenoîtStJean) contains a French diacritic.


Just tested it with Pharo 7 (64 bit on Windows 10)...

Fileout works fine.  But filing in crashes!

On 2019-01-27 11:03, Sven Van Caekenberghe wrote:

Hi Dominique,


On 27 Jan 2019, at 11:40, Dominique Dartois  wrote:

Hello all.
If a use french diacritic character in a class name, the code runs but I can’t 
fileout the package nor save it with Monticello.
For example, the C cedilla in the class name drive me to an 
‘ZnInvalidUTF8:Illegal byte for utf-8 encoding' when filing out.

Is it a bug or a feature?
Thank you

---
Dominique Dartois

Thanks for reporting this. This is most definitely a bug, I can confirm its 
occurrence.

I'm CC pharo-dev as this is quite important. This will be a long mail.


This is one manifestation of a problem that has been present for quite a while.

I'll start by describing what I did, what went well and where/how this fails, 
some generic points, and two conceptual solutions (that need further 
verification).

Like you, I created a new subclass:

Object subclass: #ClasseFrançaise
instanceVariableNames: ''
classVariableNames: ''
package: '_UnpackagedPackage'

With comment:

I am ClasseFrançaise.

Try:

ClasseFrançaise new élève.
ClasseFrançaise new euro.

And two methods (in the 'test' protocol):

élève
^ 'élève'

euro
^ '€'

I added the euro sign (because that is encoded in UTF-8 with 3 bytes, not 2 
like ç).
Like you said, the system can cope with such class and method names and seems 
to function fine.

Looking at the .changes file, the correct source code was appended:

SNAPSHOT2019-01-26T23:36:18.548555+01:00 work.image priorSource: 339848!

Object subclass: #ClasseFrançaise
 instanceVariableNames: ''
 classVariableNames: ''
 package: '_UnpackagedPackage'!
!ClasseFrançaise commentStamp: 'SvenVanCaekenberghe 1/27/2019 12:25' prior: 0!
I am ClasseFrançaise.!
!ClasseFrançaise methodsFor: 'test' stamp: 'SvenVanCaekenberghe 1/27/2019 
12:26'!
élève
 ^ 'élève'! !
!ClasseFrançaise commentStamp: 'SvenVanCaekenberghe 1/27/2019 12:27' prior: 
33898360!
I am ClasseFrançaise.

Try:

 ClasseFrançaise new élève.
 ClasseFrançaise new euro.
!
!ClasseFrançaise methodsFor: 'test' stamp: 'SvenVanCaekenberghe 1/27/2019 
12:27'!
euro
^ '€'! !


Doing a file out (or otherwise saving the source code) fails. The reason is an 
incorrect manipulation of this source file while looking for what is called the 
method preamble, in SourcFileArray>>#getPreambleFrom:at: position

An programmatic way to invoke the same error is by doing

(ClasseFrançaise>>#élève) timeStamp.
(ClasseFrançaise>>#élève) author.

Both fail with the same error.


The source code of methods is (currently) stored in a .sources or .changes 
file. CompiledMethods know their source pointer, an offset in one of these 
files. Right before the place where the source starts is a preamble that 
contains some meta information (including the author and timestamp). To access 
that preamble, the source code pointer is moved backwards to the beginning of 
the preamble (which begins and ends with a !).


The current approach fails in the presence of non-ASCII characters. More 
specifically because of a mixup between the concept of byte position and 
character position when using UTF-8, a variable length encoding (both the 
.changes and the .sources are UTF-8 encoded).

For example, consider

'à partir de 10 €' size. "16"
'à partir de 10 €' utf8Encoded size. "19"

So although the string contains 16 characters, it is encoded as 19 bytes, à 
using 2 bytes and € using 3 bytes. In general, moving backwards or forwards in 
UTF-8 encoded bytes cannot be done without understanding UTF-8 itself.

ZnUTF8Encoder can do both (moving forward is #nextFromStream: while moving 
backwards is #backOnStream:). However, ZnUTF8Encoder is also strict: it will 
signal an error when forced to operate in between encoded characters, which is 
what happens here.

It is thus not possible to move to arbitrary bytes positions and assume/hope to 
always arrive on the correct character boundaries and it is also wrong to take 
the difference between two byte positions as the count of characters present 
(since their encoding is of variable length).

SourcFileArray>>#getPreambleFrom:at: is doing both of these wrong (but gets 
away with it in 99.99% of all cases since very few people name their classes like 
that).

There are two solutions: operate mostly on the byte level or operate correctly 
on the character level. Here are two conceptual solutions (you must execute 
either solution 1 or 2, not both), with two different inputs.


src := '!ClasseFrançaise methodsFor: ''test'' stamp: ''SvenVanCaekenberghe 
1/27/2019 12:27''!
euro
^ ''€''! !'.

"startPosition := 83"

str := ZnCharacterReadStream on: (src 

Re: [Pharo-dev] New book: Pharo with Style

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Besides, I forgot to add one comment : you should have guidelines for 
protocol naming.  It's not critical per se but I find it quite annoying 
to look for stuff in "enumerating" when it's been put in "printing" !  loll


On 2018-12-31 03:51, Stephane Ducasse wrote:

Thanks! Thanks!
I will go over it (now laying on my back :(( stupid muscles strike back!)

On Mon, Dec 31, 2018 at 2:18 AM Benoit St-Jean  wrote:

On 2018-12-30 16:13, Stephane Ducasse wrote:

Hello Fellow Pharoers

I'm happy to announce a new little book to improve the culture around Pharo.
I will revise it in the future so you can feel free to send feedback
and pull requests
to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle

Stef

"The best way to predict the future is to invent" so I do it.

Stéphane,

You'll find, attached, a revised PDF version with my comments.



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


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


--- End Message ---

Re: [Pharo-dev] Environment variables encoding ?

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
I do remember clearly that while debugging that problem, the %LOCALAPPDATA% 
environment at some point kept that string encoded with Latin-1 (I'm on Windows 
10, french version).  I have not been able to reproduce the exact sequence 
which led to that specific case unfortunately...


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

On Tuesday, April 17, 2018, 3:37:01 a.m. EDT, Sven Van Caekenberghe 
 wrote:  
 
 Hi,

The dictionary 

 OSPlatform current environment

contains a copy of the OS's environment variables (more correctly of the VM 
process), as key/value pairs. 

These are obtained via the following system calls:

on macOS & *nix

  LIBC environ

on Windows

  KERNEL32 GetEnvironmentStrings

It is however a bit unclear how these are encoded. On macOS & *nix that seems 
to be UTF8, on Windows there are some reports that it appears to be Latin1 - 
but both might be locale specific, I don't know either way.

Does anyone know for sure ?

I furthermore think that OSEnvironment and its subclasses, who do this call, 
should be responsible for decoding the C strings into proper Pharo strings, and 
not leave that responsibility to its users.

Fundamentally, in the following, the decoding is still not done correctly and 
that is wrong/confusing IMHO.

$ FOO=benoît ./pharo Pharo.image eval 'OSEnvironment current associations' 
{'TERM_PROGRAM'->'Apple_Terminal'. 'TERM'->'xterm-256color'. 
'SHELL'->'/bin/bash'. 
'TMPDIR'->'/var/folders/sy/sndrtj9j1tq06j0lfnshmrl8gn/T/'. 
'FOO'->'benoît'. 
'Apple_PubSub_Socket_Render'->'/private/tmp/com.apple.launchd.uWk7pivcLT/Render'.
 'TERM_PROGRAM_VERSION'->'404'. 
'TERM_SESSION_ID'->'845BECCD-0AB0-4686-B7F9-3A0FF84BDCB7'. 'USER'->'sven'. 
'SSH_AUTH_SOCK'->'/private/tmp/com.apple.launchd.y5oCwdUyaG/Listeners'. 
'PATH'->'/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/texbin:/opt/X11/bin'.
 'PWD'->'/tmp/benoît'. 'XPC_FLAGS'->'0x0'. 'XPC_SERVICE_NAME'->'0'. 
'HOME'->'/Users/sven'. 'SHLVL'->'2'. 'LOGNAME'->'sven'. 'LC_CTYPE'->'UTF-8'. 
'DISPLAY'->'/private/tmp/com.apple.launchd.lsgASYFiWW/org.macosforge.xquartz:0'.
 'SECURITYSESSIONID'->'186a9'. 'OLDPWD'->'/tmp/benoît'. 
'_'->'/tmp/benoît/pharo-vm/Pharo.app/Contents/MacOS/Pharo'. 
'__CF_USER_TEXT_ENCODING'->'0x1F5:0x0:0x0'}

Of course, if we change this, we will need to fix callers.

Opinions ?

Sven

PS: Furthermore, I note that there is a subtle difference in how $FOO and $PWD 
in the above are UTF-8 encoded. In the former, normalisation was done, in the 
latter not. Maybe that could lead to problems (when comparing/composing them). 
This is a difficult/complex subject 
(https://medium.com/concerning-pharo/an-implementation-of-unicode-normalization-7c6719068f43).


  --- End Message ---

Re: [Pharo-dev] Why String do not implement #displayString?

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
As far as I can remember, yes.  Dolphin has always been like that.
***BUT*** you will also notice that Dolphin has always used #printOn: inside 
#displayOn: ! (Latest image is also like that)


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

On Tuesday, April 10, 2018, 6:33:05 p.m. EDT, Esteban A. Maringolo 
 wrote:  
 
  
Current VisualWorks (8.x) has #Object>>displayString but it is not implemented 
in terms of #displayOn:
 
Dolphin Smalltalk is the one that has #displayString implemented in terms of 
#displayOn: and uses #displayString in all end user presentations of the 
object, so for aPerson, the inspector would show 'a Person('John Doe')' and on 
a end user ListView the same instance would show 'John Doe'.
 
 
It is like that since Dolphin 5 at least (~2003?).
 
 
Regards,
 
 
 On 10/04/2018 19:04, Benoit St-Jean wrote:
  
  In the "old" days, programmers made sure to respect the following conventions 
: you implement #storeOn:, #displayString: and #printOn: .  Eventually, an 
object will be sent #storeString and #printString and will use your 
#whateverOn: implementation.   
  It looks like that good habit that I've learned at university looong ago 
got lost somewhere.  It looks like no one uses #displayString anymore and rely 
solely on #printString instead!  I had a teacher once telling me #displayString 
had a crappy implementation : it just sent #printString and that to be "code 
clean", one should implement  #displayOn: and modify #displayString 
accordingly. 
  But if I recall, VW at the time introduced #displayOn: for widgets and other 
things, hence why #displayString never sent #displayOn:. 
  To make a long story short of what should have been and what it's always 
been, here's an excellent paper on the subject! 
  http://esug.org/data/HistoricalDocuments/TheSmalltalkReport/ST07/04wo.pdf 
  
  - 
 Benoît St-Jean 
 Yahoo! Messenger: bstjean 
 Twitter: @BenLeChialeux 
 Pinterest: benoitstjean 
 Instagram: Chef_Benito
 IRC: lamneth 
 Blogue: endormitoire.wordpress.com 
 "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)  
  
 On Tuesday, April 10, 2018, 11:28:57 a.m. EDT, Esteban A. Maringolo 
 wrote:  
  
   Isn't #displayString implemented in terms of #displayOn: the same way
 #printString is implemented in terms of "printOn:"?
 
 And in the case of String #displayString should return the receiver (it
 is, self), so the following should be true.
 
 | s |
 s := 'Hello, ''Funny'' World'.
 s displayString = s. "true"
 s printString = s. "false"
 
 Regards,
 
 
 On 10/04/2018 12:21, Denis Kudriashov wrote:
 > Hi.
 > 
 > According to the comment of #displayString it should be used as default
 > textual representation of objects in the UI:
 > 
 >    "While printString is about to give a detailled information about an
 >    object, displayString is a message that should return a short
 >    string-based representation to be used by list and related UI
 >    frameworks. By default, simply return printString."
 >    "asString should not be implemented in Object, and kept for
 >    conversion between strings, symbols, text and characters."
 > 
 > But String itself does not respect this message:
 > 
 >    'some string' displayString " ==> '''someString''' "
 > 
 > 
 > Is it bug? Or is there any reason for this?
 > 
 > Best regards,
 > Denis 
 
 -- 
 Esteban A. Maringolo 
 
   
 
 -- 
Esteban A. Maringolo   --- End Message ---

Re: [Pharo-dev] Images, VMs and 32 vs 64bit

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Thanks!
I don't really care about the image format, my question was more oriented 
towards the code itself.  As I don't have a Mac, I was curious as to whether 
there would be code differences between platforms, VMs and 32 vs 64bit 
distributions, code-wise!


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

On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák 
<i.uh...@gmail.com> wrote:  
 
 > images for different platforms (Mac, Linux, Windows)
yesIt is the responsibility of the VM to contain the differences. Note that 
there's some "platform-specific" code, but the image contains the code for all 
platforms at once.Generally speaking you can code on one platform, copy the 
image files to another and continue your work (although doing this can cause 
trouble, as e.g. some file paths may now point to non-existing locations).You 
can download the images independently of the platform too (e.g. Pharo 6 images: 
http://files.pharo.org/image/60/ )
> VMs (32bit, 64bit)

yes?the files are different, but I don't know if there's code difference, or if 
the images are just built with different memory layouts
Peter
On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev 
<pharo-dev@lists.pharo.org> wrote:



-- Forwarded message --
From: Benoit St-Jean <bstj...@yahoo.com>
To: Pharo Development List <pharo-dev@lists.pharo.org>
Cc: 
Bcc: 
Date: Tue, 10 Apr 2018 22:13:18 + (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs 
(32bit, 64bit) are, code-wise, the same?  By "the same", I mean do they all 
have the exact same code base or some classes/methods are in some and not in 
others or different?

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


  --- End Message ---

[Pharo-dev] Images, VMs and 32 vs 64bit

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs 
(32bit, 64bit) are, code-wise, the same?  By "the same", I mean do they all 
have the exact same code base or some classes/methods are in some and not in 
others or different?

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

Re: [Pharo-dev] Why String do not implement #displayString?

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
In the "old" days, programmers made sure to respect the following conventions : 
you implement #storeOn:, #displayString: and #printOn: .  Eventually, an object 
will be sent #storeString and #printString and will use your #whateverOn: 
implementation.  
It looks like that good habit that I've learned at university looong ago 
got lost somewhere.  It looks like no one uses #displayString anymore and rely 
solely on #printString instead!  I had a teacher once telling me #displayString 
had a crappy implementation : it just sent #printString and that to be "code 
clean", one should implement #displayOn: and modify #displayString accordingly.
But if I recall, VW at the time introduced #displayOn: for widgets and other 
things, hence why #displayString never sent #displayOn:.
To make a long story short of what should have been and what it's always been, 
here's an excellent paper on the subject!
http://esug.org/data/HistoricalDocuments/TheSmalltalkReport/ST07/04wo.pdf

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

On Tuesday, April 10, 2018, 11:28:57 a.m. EDT, Esteban A. Maringolo 
 wrote:  
 
 Isn't #displayString implemented in terms of #displayOn: the same way
#printString is implemented in terms of "printOn:"?

And in the case of String #displayString should return the receiver (it
is, self), so the following should be true.

| s |
s := 'Hello, ''Funny'' World'.
s displayString = s. "true"
s printString = s. "false"

Regards,


On 10/04/2018 12:21, Denis Kudriashov wrote:
> Hi.
> 
> According to the comment of #displayString it should be used as default
> textual representation of objects in the UI:
> 
>    "While printString is about to give a detailled information about an
>    object, displayString is a message that should return a short
>    string-based representation to be used by list and related UI
>    frameworks. By default, simply return printString."
>    "asString should not be implemented in Object, and kept for
>    conversion between strings, symbols, text and characters."
> 
> But String itself does not respect this message:
> 
>    'some string' displayString " ==> '''someString''' "
> 
> 
> Is it bug? Or is there any reason for this?
> 
> Best regards,
> Denis

-- 
Esteban A. Maringolo

  --- End Message ---

Re: [Pharo-dev] Getting IP address of machine from Pharo

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
This is probably what you are looking for (one of the code snippets does 
exactly what you want).
http://forum.world.st/Figuring-out-external-IP-addresses-of-network-interfaces-td4937291.html
As for services/websites you can query to get the public ip address, here's a 
short list (you'll have to modify the example above to parse the response 
correctly):
http://checkip.dyndns.com
https://www.whatismypublicip.com/
http://freegeoip.net
https://who.is/
http://www.ipchicken.com/
http://www.whatsmyip.org/
https://api.ipify.org/
https://whatismyipaddress.com/

IMHO, the simplest is api.ipify.org.  However, note that some of those service 
also answer geolocation info!


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

On Wednesday, March 14, 2018, 6:08:41 AM EDT, Denis Kudriashov 
 wrote:  
 
 Hello.
Do we have a way to retrieve IP address from Pharo?I tried to use following 
code:


NetNameResolver addressForName: NetNameResolver localHostName 


But it either not works (dialog with retry give-up options) or returns 
localhost 127.0.0.1.
Best regards,Denis  --- End Message ---

Re: [Pharo-dev] Looking for names for the booklet collection

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Why not simply:

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

On Sunday, March 4, 2018, 10:30:46 AM EST, Ben Coman  
wrote:  
 
 

On 4 March 2018 at 20:21, Stephane Ducasse  wrote:

Hi

I would like to make a distinction between booklet on Pharo
technologies (Smacc, Voyage, Scraping ...) and the booklets more
oriented towards teaching something with pharo (building an
interpreter, a reflective language...)


Pharo Applications / Inside Pharo 
Over Pharo / Under Pharo 

Right now we have The Pharo Booklet Collection.
And I'm looking for two names

the Pharo academic booklet collection ?
and
the Pharo technology booklet collection ?

Pharology / Pharocraft 

cheers -ben 
 
 


  --- End Message ---

Re: [Pharo-dev] Blame support P7

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Just a reminder...
We're only 13 days into the new year...
Let's take a deep breath everyone...
We're all smalltalkers : I'm sure we can discuss all this in a civilized way, 
with arguments and good manners in a joyful and respectful atmosphere!  We're 
not at war : we are exchanging ideas!

If we didn't care about Pharo/Squeak/Cuis/Dolphin/OS/VW/VAST/Whatever, we 
wouldn't criticize at all.
"On critique bien ceux que l'on aime bien"
:) - 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
--- End Message ---

Re: [Pharo-dev] Blame support P7

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
>Then why on /earth/ would one stop using Smalltalk in /the most central part/ 
>of the collaborative programming >process, version control?  This is a huge 
>blunder. 
 +1000
- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)



   --- End Message ---

Re: [Pharo-dev] Blame support P7

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
> So what would be the alternative?
A centralized server (e.g. Cincom Public Repository, SqueakSource, 
SmalltalkHub, SqueakSource 3).  After that, all you need is a detailed 
project/package/framework description.  Google will index it.

The whole "GitHub adventure" was started on the premise that it would give 
Pharo more visibility.  I don't see how it differs from SqueakSource from a 
visibility standpoint unless you specifically search for code only on GitHub.  
Most people just google anyway!
Besides, Smalltalk code on GitHub leaves a very bad impression on newcomers.  I 
was recently told "I just gave up on Smalltalk when I saw 200+ files"...  It 
was too late.  I told the poor guy it was just the way code was *stored* on 
GitHub but in your dev environment, everything resides in the image...  Too 
late : I had lost him solely based on the impression that he was entering into 
a code management nightmare worse than a thousand C header files!

In the current state of things, the whole Cuis/Pharo/Squeak world is a mess.  
Newcomers looking for code end up having to pick between a myriad of links to 
SqueakMap, catalogs, SqueakSource, SmalltalkHub, SS3, GitHub, sar files, mcz 
files, fileOuts, etc.
Ever tried to do some database stuff with Squeak or Pharo?  Just try to pick a 
package that works!  You'll find plenty of code on all platforms (SqueakSource, 
SqueakMap, SS3, GitHub), many ports from one to the other and, in the end, 
you'll have tried to load 8 packages without success...

Wouldn't it be nice to have a centralized server with Cuis, Pharo, Squeak 
(and/or others such as VW, VAST, Dolphin) and share a common import/export 
format (SIXX, Smalltalk Instance eXchange in XML, would be a good start and 
would probably do a decent job) and have the capability to store *other files* 
as well (such as config files, source code in other languages, SQL scripts, 
etc). 

Something with the functionalities/capabilities of Store (VW code management) 
with code store in a portable format.
My 2 cents.
 - 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

  From: Norbert Hartl 
 To: Pharo Dev  
 Sent: Saturday, January 13, 2018 7:13 AM
 Subject: Re: [Pharo-dev] Blame support P7
   



Am 13.01.2018 um 12:39 schrieb Eliot Miranda :
Hi Stephan,



On Jan 13, 2018, at 2:08 AM, Stephan Eggermont  wrote:

Eliot Miranda 
wrote:

Isn't it important to preserve the ability to exchange code

between Pharo,

Squeak and Cuis?  Don't you care that the VM development is directly
affected by this?  Is the VM and plugin support not important to Pharo?


Git support turns out to be much more work than we hoped and expected. Too
many library updates needed, support for different workflows and platforms,
switch to file per class. The Iceberg channel on Discord is one of the
busiest channels. 


You don't say?  One of Clément's themes in recent talks on VM performance is 
that we, as a very small team, are able to develop such a sophisticated 
optimizer because we use Smalltalk.  We are hugely productive in the vm 
simulator.  People using Smalltalk, including the Pharo, Squeak and Cuis 
dialects that constitute our community, report the same in many different 
domains, notably Bloc, GT Toolkit and Rossal.

Then why on /earth/ would one stop using Smalltalk in /the most central part/ 
of the collaborative programming process, version control?  This is a huge 
blunder.  Now a major part of the Pharo community's efforts goes into an 
external component, upon which Pharo is entirely dependent, and slowly but 
surely it is cutting itself off from its sibling communities.  Iceberg is well 
named.  People rearranged the chairs on deck while the Titanic sank.


Can we agree that a class/method/… stops being smalltalk after it has been 
serialized to text? If you can agree to this I don’t know what you are talking 
about. We exchange the to-text-serializer monticello-backend with git-backend. 
The rest (the important part) stays nearly the same. The exchange is necessary 
because the possibilities of collaboration are limited when using monticello 
only. So what would be the alternative?There are even a lot of people that 
don’t like git (including me). But I like the collaboration model because that 
can do what no smalltalk tool can do to my knowledge. 
Or to turn your argument around. You are a small vm team and you have to be 
small because I doubt with the current collaboration model you are able to 
grow. 
Norbert



Stepha


_,,,^..^,,,_ (phone)



   --- End Message ---

Re: [Pharo-dev] Protocol names convention

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Historically, it's always been 'initalize-release'

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

  From: Norbert Hartl 
 To: Pharo Dev  
 Sent: Saturday, January 13, 2018 6:33 AM
 Subject: [Pharo-dev] Protocol names convention
   
I’m not the biggest fan of method categories/protocols but I try to. 
What strikes me is the huge mess in names we have. Everytime I create e.g. an 
initialize method I’m asking myself which is the proper name to choose

initialize
initializing
initialization
….

Do we have a convention for this?

Right now all names starting with init are

initialization-data
initialize-destroy
initialization-filter
initialize - release
initialize
initialization-union
initialize - event
initializing
initialization
initalize-release
initailize-release
initialization widgets
initalize
initialize-release
initialization-release

Norbert


   --- End Message ---

Re: [Pharo-dev] Is Pharo spying on me?

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Let's not panic here!
Funny to see people worry so much about privacy from a tool that collects 
technical data anonymously when a gazillion agencies (especially NSA) keep 
track of every email and phone call we do!!!
 - 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

  From: Tudor Girba 
 To: Pharo Development List  
 Sent: Wednesday, December 6, 2017 1:13 AM
 Subject: Re: [Pharo-dev] Is Pharo spying on me?
   
Hi,

What exactly are we removing?

Cheers,
Doru


> On Dec 5, 2017, at 9:41 PM, Esteban Lorenzano  wrote:
> 
> but you are asked to share it, this is not collected automatically without 
> asking before.
> 
> anyway, we are removing that (if not removed yet) 
> 
>> On 5 Dec 2017, at 21:34, Sean Glazier  wrote:
>> 
>> Personally, I know of work places where this is not going to be allowed. I 
>> understand they need the data, but you need to be able to turn it off. A 
>> secure facility would not allow the transmission out in any case.
>> 
>>  
>> Kind Regards,
>>  
>> Sean Glazier
>>  
>> 
>> On Tue, Dec 5, 2017 at 2:45 PM, Juraj Kubelka  
>> wrote:
>> Check Privacy section in Settings Browser.
>> If you ever send anything, data are anonymized.
>> Developers use it to be able to evaluate their research (PhD) work. It is a 
>> requirement in the research field.
>> By sending the anonymized data, you help developers to understand how their 
>> tools are used.
>> In particular, I am aware of Spotter, Quality Assistant, GT tools, and 
>> Roassal.
>> 
>> Cheers,
>> Juraj
>> 
>> > On Dec 5, 2017, at 16:30, Bernhard Pieber  wrote:
>> >
>> > I just found a file named org.pharo.global-identifiers.ston in my 
>> > preferences folder. It contains a #secretUUID and a #computerUUID. :-( 
>> > What is this information used for? More importantly, how can I turn it off?
>> >
>> > Bernhard
>> 
>> 
>> 
> 

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

"Next time you see your life passing by, say 'hi' and get to know her."






   

|  | Virus-free. www.avg.com  |

--- End Message ---

Re: [Pharo-dev] [Vm-dev] Garbage Collection (was Re: Discussing the roadmap)

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Perhaps the solution resides in settings you can tweak from within Smalltalk?  
Something like MemoryPolicy you have in VisualWorks for memory & garbage 
collection management. I don't think fixing the behavior of memory management & 
garbage collection (marking, sweeping, etc) in the VM is the way to go.  
There's an awful lot of different needs for different applications out there !
 - 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

  From: Clément Bera 
 To: Squeak Virtual Machine Development Discussion 
 
Cc: Pharo Development List 
 Sent: Monday, December 4, 2017 2:49 AM
 Subject: Re: [Pharo-dev] [Vm-dev] Garbage Collection (was Re: Discussing the 
roadmap)
   
hum...
The mail is very long so I did not read all of it.
Here are some ideas/things to say on the tip of my head:- Changing an object to 
a forwarding object is non atomic (we need to maintain at least stack 
invariant)- To decrease the pauses in full GC I have 2 plans:-- incremental 
marking (split the mark pause in multiple small pauses): Not implemented right 
now.-- selective compaction (compacts only part of the heap instead of all the 
heap and sweeps the rest, similar to G1, but uses forwarders instead of lots of 
card marking metadata): I implemented SpurSweeper which only sweeps but works 
very well.- Currently the marking phase removes all forwarders and I would like 
incremental marking to maintain the same invariant (forwarders are always 
white).
- In general, Concurrent marking and sweeping have been implemented everywhere, 
but no concurrent compaction. For compaction you can make it selective (compact 
only part of the heap and the part which needs it the most) like I suggest and 
like in G1, which decreases considerably compaction pause time. Work on 
concurrent compaction is state of the art and not in production everywhere, see 
for example Shenandoah Garbage Collector
A. Shipilev
Pause-Less GC for Improving Java Responsiveness 
C. Gracie
And I will watch at talk on this topic tomorrow for the Android GC.- Some 
runtime, especially now with small servers being rent, are running on single 
core machines. So we need the low-pause GC to work incrementally aside from 
concurrently. So step 1 incremental GC. Step 2 concurrent marking and sweeping 
with low-pause for scavenge/compaction.
No more time right now. 

On Sun, Dec 3, 2017 at 6:33 AM, Ben Coman  wrote:


Hi Eliot, Clement,

On 7 July 2017 at 00:41, Eliot Miranda  wrote:
>
> > - Better support for large heaps (GC tuning API, incremental GC).
> > Pharo 64 bit is now able to manage large heap. However better
> > performance can be proposed by offering better settings for the
> > different GC zone.
>
> The most important thing here is the incremental GC.  Spur has a generation
> scavenger that collects garbage in newly created objects (new space),
> and a mark-compact collector that collects and compacts garbage in old space.
>
> Right now on my 2.3GHz MacMini doing normal development, the generation
> scavenger causes pauses of 1ms or less, and the mark-compact collector
> than causes pauses of around 200ms.  Both account for about 0.75% of
> entire execution time (1.5% total), so the scavenger is invoked frequently
> and the pauses that it creates are not noticeable.  But the occasional
> pauses created by the mark-compact collector /are/ noticeable,
> especially in games and music.
>
> The idea for the incremental collector is to implement a mark-sweep or
> mark-sweep-compact collector for old space that works incrementally,
> doing a little bit of work on each invocation, probably immediately after a 
> scavenge.
> It is intended to avoid the long pauses caused by the non-incremental
> mark-compact collector and make the system more suitable for games, music, 
> etc.

Reading http://www.mirandabanda.org/ cogblog/2013/09/13/lazy- 
become-and-a-partial-read- barrier/
  "An alternative implementation, oft-used in Lisp systems, is to add a
  read barrier to all object access, and mark objects as forwarders.
  This can be used to implement a >>>lazy copying garbage collection
  where objects are copied from one semi-space to another in parallel to the
  main program (the “mutator”).  To become, or move an object one replaces the
  object’s header or first field with a forwarding pointer to the desired target
  or copy in a new location, marking the “corpse” as forwarded.  The program
  checks the forwarded flag on each access.  If there is hardware support,
  as in a Lisp machine, this can work well.  But without hardware support,
  and like the object table representation, it has costs, slowing down
  program 

Re: [Pharo-dev] Pharo and special unary selectors

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Personnally, I against adding those special symbols.  They add close to nothing 
(except complexity in the parser) to what we can actually do!
Besides, what does 30$ + 17$ add up to?  Oh!  Did I tell you it was actually 
$30USD + $17CAN ? :)


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

On Friday, November 17, 2017, 6:41:11 PM EST, Ben Coman 
 wrote:  
 
 If a valid Smalltalk method identifier contains only... 
[a-zA-Z][a-zA-Z0-9]*http://www.osdata.com/programming/firstprograms/valididentifiers.html
then one option could be that unary symbols must touch the previous identifier, 
i.e. no intervening whitespace,
  100%   
  20$
  40€
  12‰   portion%  someMoney$

or pick a new "unary separator/binder" 

  100'%    or  100 '%
  20'$       or  20 '$
  40'€       or  40 '€
  12'‰     or  12 '‰   portion'%  someMoney'$

or re-use the existing colon which indicates an argument to the right, 
to indicate an argument to the left

  100 :%   
  20 :$
  40 :€
  12 :‰  (for promille)  portion :%  someMoney :$
which is unambiguous regarding block variable definitions since no messages are 
valid in the block variable definition area,but this may complicate precedence 
semantics due to its similarity to a keyword selector, and would complicate 
things if the space was missing. 


On 18 November 2017 at 04:02, Nicolas Cellier 
 wrote:



2017-11-17 18:32 GMT+01:00 Thierry Goubier :

Le 17/11/2017 à 10:14, Nicolas Cellier a écrit :



2017-11-17 17:40 GMT+01:00 Gabriel Cotelli >:

    I would really like to see % removed as a binary selector and
    available to use in unary or keyword ones. The only implementor in a
    Pharo 6 image is:

      % aNumber

     ^ self \\ aNumber


+1, such alias has nothing to do in Kernel

    So it's juts aliasing \\ , and % most widespread usage in the real
    world is por percentages (the use in modular arithmetic is more a
    programming thing that math notation I think).

    And for allowing more Unicode code points for selector names I'm
    totally in for Symbols, Arrows, Math Symbols, etc... We just need to
    analyse the ones that makes sense as binary selectors, and the ones
    allowed for unary and keyword ones. This will allow us to write
    pretty cool DSLs.

    Just my opinion.

This could also be the case for punctuation like ! and ?

The idea of Torsten is more generic, any combination of binary char could be 
used.
 From what I understand from https://en.wikipedia.org/wiki/ LR_parser we would 
just have to scan one more token ahead for deciding if unary or binary, and 
could preserve our simple shift reduce steps...


The Smalltalk parsers being handwritten, there wouldn't be shift/reduces to 
contend with, and, anyway, the lexer doesn't shift/reduce; it would simply 
creates a token up to the next separator (that is goble up the next 
space/cr/end of line dot/closing parenthesis/etc...)


I don't have academical cursus, so I may be approximate, but the manually 
written parsers just have to read a single token ahead so far, and linearly 
build the parseNode, to me it was equivalent. 



So it seems doable for resolving the send.


Sort of. The parser difficulty would be this one:

anObject % print






Yes, that's a severe limitation. Context free => it's a binary... Or we have to 
use ( ). 
But then it's unfriendly to have different rules for unary symbols versus unary 
words...It devaluates the idea... 




Is this a binary selector with a print argument or two unary selectors?



Less ambiguous...anObject'% printanObject '% print 
 


Using the symbol table when you parse would solve it, but that is certainly not 
context free...


More problematic would be the declaration of method, if we have both a unary + 
and a binary +, we will need new syntax for marking the difference.









In most cases, distinguishing between unary + declaration and binary + 
declaration would be doable:

+ whatever

is the start of a binary selector

+ ^ self

is the start (or the declaration of) an unary selector.

But writing

+ self

Can be interpreted as either unary plus doing self, or binary + method 
definition...


a "unary binder" could distinguish them...
binary method definition...
+ self
unary method definition...'+ self
  
 issues...

+ b | c | 

a binary plus with unused temp and implicit ^self, or unary + with binary | 
sent to b with unary (c |) parameter etc...

+ b | c |
binary plus, unused temporary c
'+ b | c |unary plus, first | is binary, second | is unary   or maybe it would 
need to be...   '+ b | c'|
 
So we need a new syntax meaning that there is no parameter, like + ][ or 

[Pharo-dev] Re : QualityImprovements assured by tests

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
How about a sprint? I surely am not the most qualified person to comment a 
class I did not create but we can all remove crap ! 

Envoyé à partir de Yahoo Courriel sur Android 
 
  Le ven., mai 19 2017 à 18:26, Torsten Bergmann a écrit :   Hi,

One year later we are close to a final release for Pharo 6 and either with 
Pharo 6 or upcoming Pharo 7 
I would really like to see some checks that ensure a quality image and tests 
who keep us all more 
disciplined in the future. 

Because:

  1. We should not have undocumented classes:

        (Object allSubclasses select: [:cls| cls hasComment not ]) 

    but we have a lot in Pharo 6 now since we introduced new packages in this 
release iteration

  2. We should not have class instance variables in uppercase but:

    (Object allSubclasses select: [:cls| cls isMeta]) select: [:cls| cls  
      instVarNames anySatisfy: [:n | n first isUppercase]]

    is not empty - although this was already discussed back in 2008 (!), see
    
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2008-November/003366.html

  3. We should not have uncategorized methods but:

    (Object allSubclasses select: [:cls| (cls selectorsInProtocol: Protocol 
unclassified) notEmpty ]) 

    we still have them. 

  4. I've seen methods with unused temporary variables. Dont know about unused 
ivars or other.
 
  5. add you own here ...

I know this is often boring to comment or categorize - but we should do our 
homework as we wanted to
better compared to the past. Also if the base image is not following rules how 
should we expect others
to provide quality packages on top of it? 

IMHO we should raise the bar. Either in Pharo 6 or in early Pharo 7. We can fix 
these once and for 
all AND assure with unit tests that we keep the standard image on this quality 
level.

Thx
T.




  
--- End Message ---

Re: [Pharo-dev] immediateByteSubclass: ?

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
If that's of any help, I was able to track it back to Squeak 5.0 and it had no 
sender in that version too!  The author's initials are eem.
 - 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

  From: Clément Bera 
 To: Pharo Development List  
 Sent: Friday, May 12, 2017 1:40 PM
 Subject: Re: [Pharo-dev] immediateByteSubclass: ?
   
This one looks strange and seems indeed to be dead code. 
Maybe it was an attempt to make a specific class definition keyword for 
CompiledMethod / CompiledCode / CompiledBlock. Right now there is a specific 
case in the code somewhere to use the specific compiledCode layout for those 3 
classes instead of the byte layout which is normally used for the keyword 
variableByteSubclass: that those 3 classes use.
I am not sure immediateByteSubclass: makes sense though. I would rather have 
compiledCodeSubclass, variablePointerAndByteSubclass or something like that.
On Fri, May 12, 2017 at 5:39 PM, Stephane Ducasse  
wrote:

Hi 
with guille we are working on a class parser and our game is to make sure that 
we can parse all the crazy class definitions among which 
variableWordSubclass:ephemeronSubclass:weakSubclass:variableByteSubclass:variableSubclass:immediateSubclass:
 subclass: aSubclassSymbol  layout:
And we found this method definition and it has no senders and we wonder if it 
is just plain deadcode?
immediateByteSubclass: className instanceVariableNames: instvarNames 
classVariableNames: classVarNames package: package "Added to allow for a 
simplified subclass creation experience. "
 ^ self immediateSubclass: className instanceVariableNames: instvarNames 
classVariableNames: classVarNames package: package
S & G



   --- End Message ---

[Pharo-dev] Printing numbers in different bases

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Is there a reason why we allow printing numbers in bases greater than 36?  It 
makes no sense to me.
For instance:
1406 printStringBase: 57.  "O]" - 
Benoît St-Jean 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)--- End Message ---

Re: [Pharo-dev] comparison statistics

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
It could also reflect the complexity of the environment.  A lot of stuff can be 
done in waaay less lines of code in Pharo than in C for instance.  
Hence, we need less developers in Pharo/Smalltalk to do more stuff!
 - 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

  From: Ben Coman 
 To: Pharo Development List  
 Sent: Sunday, September 25, 2016 10:29 AM
 Subject: [Pharo-dev] comparison statistics
   
Just bumped into some interesting statistics to consider when the
minor worry occasionally arises that Pharo is not more popular.

One aspect to measure the liveness and success of a project is the
number of developers contributing to it.  From the attached png, here
are the number of developers for some very popular projects...
57 Apache
40 Ant
92 Python
25 Perl
29 PostgrSQL

and from the list of contributors at http://pharo.org/about
91 Pharo

Now some care is the comparison since the first group are from 2006
and Pharo is 2016, and maybe the Pharo is an all-of-time list of
contributors.

But Python's 2016 committers list has 138 names
https://hg.python.org/committers.txt

and Github shows all-of-time list of contributors of 100
https://github.com/python/cpython/graphs/contributors
where you can see from individual graphs that many have not committed
for years..


So with caution I think we can take away that while Pharo does not
*yet* have the hordes of followers some other languages have, the
Pharo project is doing a reasonable job of attracting the interest of
contributing developers, which is a key indicator for future success.

cheers -ben


   --- End Message ---

[Pharo-dev] Problem with accentuated characters

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
I am a bit puzzled by Pharo's (Pharo 5) behavior when having accentuated 
characters inside a string.
I have a method that sends cascaded messages and it automatically gets 
"reformated" with a temp variable.
This is the original code I typed and tried to save:
leCarreEtLes4Coins
    ^ self new
        tiles: #(1 5 7 8 9 12 13 14 17 18 19 21 25);
        name: 'Le carré et les 4 coins'


This is how Pharo reformats my code when I save!
leCarreEtLes4Coins
    | tmp2 |
    tmp2 := self new.
    tmp2 tiles: #(1 5 7 8 9 12 13 14 17 18 19 21 25).
    ^ tmp2 name: 'Le carré et les 4 coins'

Has anyone seen this behavior?

More details:
Pharo5.0
Latest update: #50760Virtual Machine
---
E:\Pharo5-dev\Pharo.exe
CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 
May  4 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: 
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
https://github.com/pharo-project/pharo-vm.git Commit: 
b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: 
Esteban Lorenzano  Jenkins build #589

Win32 built on May  4 2016 12:17:02 Compiler: 4.6.2
VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 
b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: 
Esteban Lorenzano  Jenkins build #589
CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 
May  4 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: 
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
Loaded VM Modules
-
B2DPlugin VMMaker.oscog-eem.1855 (i)
BitBltPlugin VMMaker.oscog-eem.1855 (i)
FT2Plugin Freetype-Plugin-EstebanLorenzano.69 (e)
FilePlugin VMMaker.oscog-eem.1855 (i)
FloatArrayPlugin VMMaker.oscog-eem.1855 (i)
Kernel32
LargeIntegers v2.0 VMMaker.oscog-eem.1855 (i)
LocalePlugin VMMaker.oscog-eem.1855 (i)
Matrix2x3Plugin VMMaker.oscog-eem.1855 (i)
MiscPrimitivePlugin VMMaker.oscog-eem.1855 (i)
SecurityPlugin VMMaker.oscog-eem.1855 (i)
SocketPlugin VMMaker.oscog-eem.1855 (i)
SqueakFFIPrims
SurfacePlugin May  4 2016 (e)
UUIDPlugin VMMaker.oscog-eem.1855 (i)
ZipPlugin VMMaker.oscog-eem.1855 (i)

VM Built-in Modules
---
ADPCMCodecPlugin VMMaker.oscog-eem.1855 (i)
AsynchFilePlugin VMMaker.oscog-eem.1855 (i)
B2DPlugin VMMaker.oscog-eem.1855 (i)
B3DAcceleratorPlugin VMMaker.oscog-eem.1855 (i)
BMPReadWriterPlugin VMMaker.oscog-eem.1855 (i)
BitBltPlugin VMMaker.oscog-eem.1855 (i)
CroquetPlugin VMMaker.oscog-eem.1855 (i)
DSAPrims CryptographyPlugins-rww.10 (i)
DropPlugin VMMaker.oscog-eem.1855 (i)
FFTPlugin VMMaker.oscog-eem.1855 (i)
FilePlugin VMMaker.oscog-eem.1855 (i)
FloatArrayPlugin VMMaker.oscog-eem.1855 (i)
FloatMathPlugin VMMaker.oscog-eem.1855 (i)
HostWindowPlugin VMMaker.oscog-eem.1855 (i)
IA32ABI VMMaker.oscog-eem.1855 (i)
JPEGReadWriter2Plugin VMMaker.oscog-eem.1855 (i)
JPEGReaderPlugin VMMaker.oscog-eem.1855 (i)
JoystickTabletPlugin VMMaker.oscog-eem.1855 (i)
Klatt VMMaker.oscog-eem.1855 (i)
LargeIntegers v2.0 VMMaker.oscog-eem.1855 (i)
LocalePlugin VMMaker.oscog-eem.1855 (i)
MIDIPlugin VMMaker.oscog-eem.1855 (i)
Matrix2x3Plugin VMMaker.oscog-eem.1855 (i)
MiscPrimitivePlugin VMMaker.oscog-eem.1855 (i)
Mpeg3Plugin VMMaker.oscog-eem.1855 (i)
RePlugin VMMaker.oscog-eem.1855 (i)
SDL2DisplayPlugin SDL2DisplayPlugin-RonieSalgado.1 (i)
SecurityPlugin VMMaker.oscog-eem.1855 (i)
SerialPlugin VMMaker.oscog-eem.1855 (i)
SocketPlugin VMMaker.oscog-eem.1855 (i)
SoundCodecPrims VMMaker.oscog-eem.1855 (i)
SoundPlugin VMMaker.oscog-eem.1855 (i)
SqueakFFIPrims
StarSqueakPlugin VMMaker.oscog-eem.1855 (i)
UUIDPlugin VMMaker.oscog-eem.1855 (i)
Win32OSProcessPlugin 
VMConstruction-Plugins-OSProcessPlugin.oscog-EstebanLorenzano.53 (i)
ZipPlugin VMMaker.oscog-eem.1855 (i)

VM Configuration

E:\Pharo5-dev\Pharo.ini
[Global]
DeferUpdate=0
ShowConsole=0
DynamicConsole=1
ReduceCPUUsage=1
ReduceCPUInBackground=1
3ButtonMouse=0
1ButtonMouse=0
UseDirectSound=1
PriorityBoost=0
B3DXUsesOpenGL=0
CaseSensitiveFileMode=0

Operating System/Hardware
-
Win32 6.2 IX86

Operating System Details

Operating System: Windows 10 Home (Build 9200 )
    Registered Owner: ???
    Registered Company: ???
    SP major version: 0
    SP minor version: 0
    Suite mask: 300
    Product type: 1

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

[Pharo-dev] Random number generator bug?

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
I'm having problems understanding why the Integer>>#atRandom sometimes return a 
number greater than the receiver.
This problem only occurs when forking processes that generate random number 
using the above mentioned method.  Obviously, all processes share the same RNG 
from the Collection class.
Code below can reproduce (most of the time) the bug.
| n |
n := 3172918.
5 timesRepeat: [ [n timesRepeat: [ | alea |
                                    alea := n atRandom.
                                    (alea > n) ifTrue: [ self halt]]] forkAt: 
Processor userBackgroundPriority ]. 

I'm on Windows 10, Pharo4.0 Latest update: #40627.
Pertinent System Reporter info below:
Virtual Machine
---
F:\Pharo4\Pharo4.0\Pharo.exe
NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: 
e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: 
e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
https://github.com/pharo-project/pharo-vm.git Commit: 
81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: 
Esteban Lorenzano  Jenkins build #14858

Win32 built on Sep 25 2014 17:47:04 Compiler: 4.6.2
VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 
81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: 
Esteban Lorenzano  Jenkins build #14858
NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: 
e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: 
e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014

Loaded VM Modules
-
B2DPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
FT2Plugin Freetype-Plugin-IgorStasenko.64 (e)
FilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
FloatArrayPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
JPEGReadWriter2Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
Kernel32
LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.783 (i)
LocalePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
Matrix2x3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
NativeBoostPlugin NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 (i)
SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
ZipPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)

VM Built-in Modules
---
ADPCMCodecPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
AsynchFilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
B2DPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
B3DAcceleratorPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
BMPReadWriterPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
CroquetPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
DSAPrims VMMaker.oscog-jeanbaptistearnaud.783 (i)
DropPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
FFTPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
FilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
FloatArrayPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
FloatMathPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
HostWindowPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
IA32ABI VMMaker.oscog-jeanbaptistearnaud.783 (i)
JPEGReadWriter2Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
JPEGReaderPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
JoystickTabletPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
Klatt VMMaker.oscog-jeanbaptistearnaud.783 (i)
LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.783 (i)
LocalePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
MIDIPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
Matrix2x3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
Mpeg3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
NativeBoostPlugin NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 (i)
RePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
SerialPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
SocketPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
SoundCodecPrims VMMaker.oscog-jeanbaptistearnaud.783 (i)
SoundPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
StarSqueakPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
SurfacePlugin Sep 25 2014 (i)
UUIDPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
Win32OSProcessPlugin 
VMConstruction-Plugins-OSProcessPlugin.oscog-EstebanLorenzano.43 (i)
ZipPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)

VM Configuration

F:\Pharo4\Pharo4.0\Pharo.ini
[Global]
DeferUpdate=1
ShowConsole=0
DynamicConsole=1
ReduceCPUUsage=0
ReduceCPUInBackground=0
3ButtonMouse=0
1ButtonMouse=0
UseDirectSound=1
PriorityBoost=0
B3DXUsesOpenGL=0
CaseSensitiveFileMode=0
Operating System/Hardware
-
Win32 6.2 IX86
Hardware Details

Hardware information: 
    Manufacturer: Unknown
   

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

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Amen!
My lastname is St-Jean, like it or not I'm closer to Ducasse than Hollansworth!
I discovered Smalltalk with ObjectWorks on AIX : I'm closer to Pharo than 
Python, C, C++, C#, Ruby, Snobol, Dart, Go or any other language... Like it or 
not, I'm closer to Smalltalk than Java, COBOL or any other retarded programming 
language...

I've been working as a consultant in Smalltalk since the 90s.  I don't care : 
VW, VAST, VSE as long as it's Smalltalk!  I'm closer to Pharo than I am to 
anything else (except Modula-2).
This stupid war is sooo stupid!
If you know what the DNU acronym means, you're a Smalltalker. Period.
Pharo can go its own way (whether I like it nor not), but it's still Smalltalk!
These guys (the Pharoers, and Stéphane Ducasse) have made *tremendous* steps 
forward. Like "how come nobody ever did that for Smalltalk except James 
Robertson" ?
I like Pharo.  I fell in love with VW 2.5.  

Vous êtes si belles, vous toutes!
I love Smalltalk!


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

  From: Dimitris Chloupis 
 To: Pharo Development List  
 Sent: Sunday, March 6, 2016 7:00 AM
 Subject: Re: [Pharo-dev] Call about Numerical Methods in Pharo :)
   
Sorry guys but I dont think this is non sense because you may be coding in 
Pharo and Smalltalk for a long time, but as a beginner I was confused by this, 
and to this day I am still confused why Pharo is not calling itself a modern 
implementation of Smalltalk. Even in Pharo by Example there was no mention at 
all the Pharo is a Squeak fork, nothing, now there is (few week before) , guess 
who added it. No mention about Squeak in our website whatsoever.  Why ? Do we 
just fork and forget about them ? 

Also this whole guilt about the so called "failure" or "death" of smalltalk is 
hilarious. Smalltalk was never popular and we certainly wont be with Pharo, 
because in the end its very unfamiliar and most coders dont like going outside 
their comfort zone. Personally  I am fine with that but this is why I use Pharo 
to get outside my comfort zone and think outside the box, but I dont kid 
myself, I belong to a tiny minority. 

I am sorry if you feel that we derail the thread, but some of us feel very 
uncomfortable by some people trying to mislead newcomers that Pharo will at 
some point brake away from Smalltalk heritage when we all know that wont happen 
for the following reasons 1) Smalltalk is an awesome language and its failure 
to become popular has nothing to do with the IDE and the language and more to 
do with lack of libraries, documentation and third party tool support plus of 
course the all important familiarity b) Most likely a ton of Squeak and older 
Smalltalk code will remain in Pharo because none sane enough would removed code 
that has stood the test of time, is well designed and works c) Even if you have 
a tiny sense or realism you will realize that the reason why people use Pharo 
is because is a modern implementation of smalltalk, trying to connect with 
modern technologies but at same time remaining a smalltalk in the core.

And finally lets take into account that all languages are evolving. 

I was coding C++ till 1996 and was very frustrated with the language, manual 
memory management, inflexible type system, horrible GUI libraries (MFC). Now I 
learn C++ 11 which means an almost fully dynamic type systems (see auto , 
templates etc) , automatic memory management (smart pointers), vast array of 
greatly design GUI and graphics libraries (QT, Unreal, GTK etc). In 20 years 
C++ has become night and day, sure still much more ugly than Pharo but far, far 
better . Did we stop calling it C++ ? 

I totally agree, that this discussion arises few time per year and in the end 
we dont agree. But I dont post here to make you change your mind, I know people 
rarely do that, I post here because I want to make crystal to begineers viewing 
this mailing that for me and many others: 

Pharo IS Smalltalk, Pharo IS a Squeak fork, Pharo is a modern implementation 
that tries to push forward but respects its heritage and pays credit to it.   


 Saying that if this numpy variant library intends to target only Pharo then it 
makes more sense to call it SciPharo. 

On Sun, Mar 6, 2016 at 12:30 PM Volkert  wrote:

  +100
 
 On 06.03.2016 09:48, stepharo wrote:
  
 Why Pharo is not smalltalk and will not be Smalltalk
 
     - First because we make it to free us from the past. 
 
     - In the future we want that people that learned smalltalk in the 90 do 
not discard Pharo because
 
                 - "what killed smalltalk was that we could not work well in 
team"
                 - "smalltalk oh it does not scale"
                 - "I cannot 

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

[Benoit St-Jean via Pharo-dev]

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

  From: Esteban Lorenzano 
 To: Pharo Development List  
Cc: Any question about pharo is welcome 
 Sent: Saturday, March 5, 2016 5:37 AM
 Subject: Re: [Pharo-dev] Call about Numerical Methods in Pharo :)
   
frankly all this zealot mails do not have any sense. 

first, SciSmalltalk is a project made fundamentally by Serge, and is Serge who 
has pointed he wants a change of name for something sexier… what is the 
problem? 
second, by discussing a nonsense (because is subjective and everybody has a 
different opinion) you are highjacking the real purpose of this mail: a call to 
the community to improve the numerical methods support in Pharo. 

So, please, can we stay cool and go back to discuss what is really important?

cheers,
Esteban


> On 02 Mar 2016, at 14:33, stepharo  wrote:
> 
> Hi guys
> 
> I met Didier Besset and we had a great hacking session and discussions with 
> Serge Stinckwich.
> Didier would like to help Pharo and the numerical part of it. ***Big 
> thanks*** Didier.
> 
> We would like to do several things:
> 
>    - Work on "Hows to"
>      The numerical methods in Pharo is good but the gap between us and the 
>math is too large :)
>    so the idea is to have a series of "how to ..."
>            - histomgram (simple, based on distribution)
> 
>    - Improve the SciPharo/NumPha (previously SciSmalltalk) library
>    This morning we started to implement a ComponentPrincipalDecomposition by 
>combining two of the
>    objects available in SciPharo.
>        Then we started to enhance the distributions to make sure that we can 
>plug other distribution for having
>        controlled random number.
> 
>    - Do a public call to know what is missing for you: this is this mail :)
>    Didier would like to work on concrete cases. I love that attitude
>    So tell us :)
> 
>            Hernan ??
>            Alex: ?? pvalue? better distribution?
>            Vincent: covariance? CPA?
>            Philippe: times series
>            Serge R frames?
>            Sami: Better random number and various distributions?
> 
>    - Organise a two day lectures with practices on concrete case in September 
>with a recording session.
>    Either at IRD Bondy or Lille.
> 
>    - Make sure that the Numerical Method book will get on lulu :) with a 
>better cover and title :)
> 
> 
> Stef
> 
> 



  --- End Message ---

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

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Sorry to say Stéphane, but those arguments are just as funny as wrong.
You know what?  I can copy some code from Smalltalk/X, Dolphin Smalltalk, 
VisualAge, ObjectStudio, VisualWorks, ObjectWorks, Smalltalk MT, Squeak, VSE, 
and many others and save it in Pharo and *it will compile* !!
So I guess Pharo is Smalltalk.
It's not because you renamed the workspace to Playground that it's not 
Smalltalk!
If it's not Smalltalk, tell me what it is!
And, btw, I can also take some Pharo code and import it in all the dialects 
mentionned above.  So I guess Pharo, like it or not, with all the fancy names 
and *we don't want no fucking backward compatibility and we try to distance 
ourselves as far as possible from all Smalltalks* is still Smalltalk.
Instead of spending a sh*tload of bytes arguing about this nonsense, let's move 
on to do some coding...
In Pharo, in Squeak, in Dolphin, in VAST, in VW, in ObjectStudio, in Amber in 
whatever...
I'm a Smalltalker : I don't give a f**k about the dialect.
I love Smalltalk, whatever the dialect.


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

  From: stepharo 
 To: pharo-dev@lists.pharo.org 
 Sent: Sunday, March 6, 2016 3:48 AM
 Subject: Re: [Pharo-dev] Call about Numerical Methods in Pharo :)
   
 Why Pharo is not smalltalk and will not be Smalltalk
 
     - First because we make it to free us from the past. 
 
     - In the future we want that people that learned smalltalk in the 90 do 
not discard Pharo because
 
                 - "what killed smalltalk was that we could not work well in 
team"
                 - "smalltalk oh it does not scale"
                 - "I cannot edit my code with emacs"
                 - "oh back in 1993 I got lecture and the system took 10 min to 
boot on our sparc (I got this story yesterday)"
                 - I did not get how you work in team
                 - "with Smalltalk you cannot save your code in svn"
                 - "Smalltalk is monolithic"
                 - "you are in a cage you cannot interact with the outside 
world" a guy organising OOPSLA
                 - "Smalltalk what a dated name! bavardage: tu programmes en 
bavardage, donc les resultats ne doivent pas 
                 etre si super que cela"
 
 I do not care that these statements are right or wrong. 
 I do not care that people are ignorant. And yes with some education we can 
show that they are wrong. 
 There are in the mind of people that got in touch with Smalltalk. 
 No more no less. 
 
 So may be Smalltalkers should read book about marketing in general. 
 
 So you are stuck in your history and I'm dreaming about the future: and the 
future is Pharo not Smalltalk. Face it. 
 There will be no renewal of Smalltalk. Pharo is the chance for Smalltalk to 
exist in 2050.
 The future is much more important that the history. 
 
 You do not make people dreaming telling them that back in the 1940 you add to 
cross the street to fetch water. 
 
 
 
 
 
 
 left blank on purpose
 
 
 
 Le 5/3/16 18:22, Eliot Miranda a écrit :
  
 
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 

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

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Why just don't we honor Didier H. Besset and leave it as it was, Numerical 
Methods in Smalltalk?
That way, regardless of your favorite Smalltalk implementation, there will 
always be a "Numerical Methods in Smalltalk" package somewhere!
The same way there's no GlorpPharo : it's Glorp everywhere!
 - 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

  From: Serge Stinckwich 
 To: Pharo Development List  
 Sent: Wednesday, March 2, 2016 1:43 PM
 Subject: Re: [Pharo-dev] Call about Numerical Methods in Pharo :)
   
On Wed, Mar 2, 2016 at 7:11 PM, Nicolas Cellier
 wrote:
> SciPharo? Not so great news from my POV.
> What is so much pharo specific in this library?
> Is Smalltalk scientific community large enough for yet another split?

We can think of a more neutral name.
Any idea for a new name ?

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



  --- End Message ---

Re: [Pharo-dev] French speaking Pharo company

[Benoit St-Jean via Pharo-dev]

---BeginMessage---
There's also French speaking Smalltalkers on the other side of the ocean!  I've 
worked remotely (telecommute) numerous times on many Smalltalk projects.  Fuly 
bilingual (French  English).  Smalltalker since 1996!
 -
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth
Blogue: endormitoire.wordpress.com
A standpoint is an intellectual horizon of radius zero.  (A. Einstein)

  From: François Stephany tulipe.mouta...@gmail.com
 To: Pharo Development List pharo-dev@lists.pharo.org; Pharo Business 
pharo-busin...@lists.pharo.org 
 Sent: Thursday, April 9, 2015 4:44 AM
 Subject: [Pharo-dev] French speaking Pharo company
   
Hi there,

I'm writing a proposal for a potential customer. Given the complex model, I'd 
like to implement the backend and webservice in Pharo (instead of Ruby on 
Rails).

Is there any of you working in a service company doing Pharo Development for 
backends? The customer is french and might be more comfortable going with Pharo 
if he knows that there are backups in case we disappear. 

Cheers,
Francois


  ---End Message---

Re: [Pharo-dev] About the singleton pattern

[Benoit St-Jean via Pharo-dev]

---BeginMessage---
We should also consider the cases of globals like Processor and Transcript.
 -
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth
Blogue: endormitoire.wordpress.com
A standpoint is an intellectual horizon of radius zero.  (A. Einstein)

  From: Christophe Demarey christophe.dema...@inria.fr
 To: Pharo Development List pharo-dev@lists.pharo.org 
 Sent: Wednesday, April 8, 2015 5:31 AM
 Subject: [Pharo-dev] About the singleton pattern
   
Hi,

We use quite often the singleton pattern but when I need to use one, I always 
need to ask myself What is the selector to get this singleton?.
We use either aClasscurrent, aClassdefault or aClassuniqueInstance.
Could we agree on the selector to use and update existing code?

To get a quick overview, I  searched about these methods in a Pharo4  image and 
get these results:
((SystemNavigation default allImplementorsOf: #default) select: #isMetaSide) 
size. 45
((SystemNavigation default allImplementorsOf: #current) select: #isMetaSide) 
size.  40
((SystemNavigation default allImplementorsOf: #uniqueInstance) select: 
#isMetaSide) size.  19

Your opinion?

Christophe.

  ---End Message---

[Pharo-dev] Pharo 4 Beta, first impressions

[Benoit St-Jean via Pharo-dev]

---BeginMessage---
3 quick things :
1) How can I get the Windows theme (W2K) that was available in Pharo 3 (it's no 
longer there in Pharo 4.0 Beta).  Having the close, maximize  minimize buttons 
to the left of every window is VERY annoying for Windows users!
2) Am I the only one annoyed by the fact that the Collection class still holds 
on to 2 class variables (one of them being an instance of Random, the other a 
mutex) for the sole purpose of accommodating the #atRandom  #atRandom: methods 
?  Even worse, the Integer class' implementation of #atRandom references the 
Collection class to use that random instance!  In other words, 
Integer#atRandom -- Collection#randomForPicking -- Random !  I've always 
been a fan of the mind your own business approach.  Wouldn't it make a lot 
more sense to have the Random class provide a default instance (a singleton) 
whenever other classes need such an object instead of crippling the code with 
class variables and singleton instance all over the place?
3) I'm having a few Could not find disk drive errors on Windows XP ( never 
had that error with Pharo 3 and I've been using it every day since it came 
out).  Am I the only one?  I ran all SUnit tests and the VM crashed real bad. 
 Do you guys need logs/dumps/errors on the console ? -
Benoit St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth
Blogue: endormitoire.wordpress.com
A standpoint is an intellectual horizon of radius zero.  (A. Einstein)---End Message---

Re: [Pharo-dev] Pharo 4 Beta, first impressions

[Benoit St-Jean via Pharo-dev]

---BeginMessage---
To the contrary!  It's way faster and shorter to list what annoys me about 
Pharo 4.0 than write a novel on all its qualities!  ;)
 -
Benoit St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth

Blogue: endormitoire.wordpress.com

A standpoint is an intellectual horizon of radius zero.  (A. Einstein)
  From: Tudor Girba tu...@tudorgirba.com
 To: Benoit St-Jean bstj...@yahoo.com; Pharo Development List 
pharo-dev@lists.pharo.org 
 Sent: Friday, April 3, 2015 8:21 AM
 Subject: Re: [Pharo-dev] Pharo 4 Beta, first impressions
   
Hi,
Thanks for the feedback.
Given that all listed points are negative, does it mean that there was nothing 
positive about Pharo 4? :)
Cheers,Doru


On Fri, Apr 3, 2015 at 2:11 PM, Benoit St-Jean via Pharo-dev 
pharo-dev@lists.pharo.org wrote:





-- Forwarded message --
From: Benoit St-Jean bstj...@yahoo.com
To: Pharo Development List pharo-dev@lists.pharo.org
Cc: 
Date: Fri, 3 Apr 2015 12:08:03 + (UTC)
Subject: Pharo 4 Beta, first impressions
3 quick things :
1) How can I get the Windows theme (W2K) that was available in Pharo 3 (it's no 
longer there in Pharo 4.0 Beta).  Having the close, maximize  minimize buttons 
to the left of every window is VERY annoying for Windows users!
2) Am I the only one annoyed by the fact that the Collection class still holds 
on to 2 class variables (one of them being an instance of Random, the other a 
mutex) for the sole purpose of accommodating the #atRandom  #atRandom: methods 
?  Even worse, the Integer class' implementation of #atRandom references the 
Collection class to use that random instance!  In other words, 
Integer#atRandom -- Collection#randomForPicking -- Random !  I've always 
been a fan of the mind your own business approach.  Wouldn't it make a lot 
more sense to have the Random class provide a default instance (a singleton) 
whenever other classes need such an object instead of crippling the code with 
class variables and singleton instance all over the place?
3) I'm having a few Could not find disk drive errors on Windows XP ( never 
had that error with Pharo 3 and I've been using it every day since it came 
out).  Am I the only one?  I ran all SUnit tests and the VM crashed real bad. 
 Do you guys need logs/dumps/errors on the console ? -
Benoit St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth
Blogue: endormitoire.wordpress.com
A standpoint is an intellectual horizon of radius zero.  (A. Einstein)




-- 
www.tudorgirba.com
Every thing has its own flow

  ---End Message---

Re: [Pharo-dev] Pharo 4 Beta, first impressions

[Benoit St-Jean via Pharo-dev]

---BeginMessage---
It's not so much about the Windows look (whether it's Win98, Win 2K, Win XP, 
Win Me, Win 8, Win Whatever).  Every Windows user *expects* to have the Close, 
Maximize  Minimize buttons at the upper right of the Window.
It might look like a silly detail but try swapping the buttons of a Mac user to 
the right and wait a few seconds before he complains!  ;)
 -
Benoit St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth
Blogue: endormitoire.wordpress.com
A standpoint is an intellectual horizon of radius zero.  (A. Einstein)
  From: Marcus Denker marcus.den...@inria.fr
 To: Benoit St-Jean bstj...@yahoo.com; Pharo Development List 
pharo-dev@lists.pharo.org 
 Sent: Friday, April 3, 2015 8:28 AM
 Subject: Re: [Pharo-dev] Pharo 4 Beta, first impressions
   


On 03 Apr 2015, at 14:11, Benoit St-Jean via Pharo-dev 
pharo-dev@lists.pharo.org wrote:

Date: 3 Apr 2015 14:08:03 CEST
From: Benoit St-Jean bstj...@yahoo.com
Reply-To: Benoit St-Jean bstj...@yahoo.com
To: Pharo Development List pharo-dev@lists.pharo.org
Subject: Pharo 4 Beta, first impressions


3 quick things :
1) How can I get the Windows theme (W2K) that was available in Pharo 3 (it's no 
longer there in Pharo 4.0 Beta).  Having the close, maximize  minimize buttons 
to the left of every window is VERY annoying for Windows users!

Windows 2k is 16 years old. We can not maintain a museum of old windows looks… 
it just makes no sense (at all. At all… I don’t even think how someone can 
think that we should!).Keep in mind that nobody uses it (but you, I guess), so 
it will for sure be broken in subtle ways… 
We need to use it where it makes sense. A windows 2000 look is not one of these 
things.



2) Am I the only one annoyed by the fact that the Collection class still holds 
on to 2 class variables (one of them being an instance of Random, the other a 
mutex) for the sole purpose of accommodating the #atRandom  #atRandom: methods 
?  Even worse, the Integer class' implementation of #atRandom references the 
Collection class to use that random instance!  In other words, 
Integer#atRandom -- Collection#randomForPicking -- Random !  I've always 
been a fan of the mind your own business approach.  Wouldn't it make a lot 
more sense to have the Random class provide a default instance (a singleton) 
whenever other classes need such an object instead of crippling the code with 
class variables and singleton instance all over the place?


The system is very large. I think it is fundamentally wrong to assume that 
something like this (Design level things) will be magically fixed if there was 
no discussion, no issue tracker entry, no nothing.
Why do you think that this will “fix itself magically”? I would really like to 
know your thought process behind this… is there something that makes you think 
that a release process could catchthis? How?
 Marcus

  ---End Message---

Re: [Pharo-dev] Pharo 4 Beta, first impressions

[Benoit St-Jean via Pharo-dev]

---BeginMessage---
Kilon,
I can perfectly understand that not everything has to be in the image and 
that, ultimately, someone has to maintain that code.  The only problem I have 
with the removal of that theme is that more than 55% of users are running some 
flavor of Windows.  It's not as if someone would ask for an OS/2 or a Motif UI 
theme!  There are *LOTS* of people on Windows still !
 -
Benoit St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth
Blogue: endormitoire.wordpress.com
A standpoint is an intellectual horizon of radius zero.  (A. Einstein)
  From: kilon alios kilon.al...@gmail.com
 To: Pharo Development List pharo-dev@lists.pharo.org 
 Sent: Friday, April 3, 2015 9:25 AM
 Subject: Re: [Pharo-dev] Pharo 4 Beta, first impressions
   



The point is, every piece of code needs to be written and maintained which 
takes time and energy from other activities.

I completely agree with you. I have zero issues of main pharo developers 
kicking out libraries that are not so much used by pharo users. Those libraries 
are perfectly capable of existing as third party. 

I also love the plan to make pharo modular, remove libraries from inside and 
make it easy to install. This way each one of us can easily make an image 
tailor made for his/her needs. Each pharo user is an individual with individual 
needs. 

Installing libraries is dead easy with the Configuration Browser , including 
their dependencies , just one click away. 

Of course that leaves whos going to maintain that stuff.  I agree with Marcus 
here, you want it in pharo , code it.The theme support in Pharo is very 
powerful , I know because I created my own custom blue theme and a tool to 
allow easy customization of theme colors with zero coding (Nireas). I expected 
that by now Nireas would be replaced by another way more powerful theme manager 
but it has not. Why ? Not because my theme manager is very good, but because 
the community is just too small. I love using my blue theme and fits perfect to 
my taste and needs ;) 

In the end no code can be more personal than the code you create.

There is no need for everything to exist inside the image , great things can 
exist outside too. All it needs people who really care about pharo by coding 
for it. 


  ---End Message---