[Pharo-dev] AbstractLayout class comment

[Ben Coman]

Minor thing...
AbstractLayout class comment says...

  "There are special cases of layouts without slots, like NilLayout or
BitsLayout."

but I see no NilLayout in the system. Did this become EmptyLayout?

cheers -ben

Re: [Pharo-dev] comparison statistics

[Ben Coman]

Of course the saying goes "There are three types of lies: lies, damn
lies and statistics"
But assuming some estimate with no data is equally fallible.
Yes the committers list is obviously just "main developers" but
equally as I consider the
names on the Pharo About page, these are not drive-by one-bug-fix
contributors.

One significant difference between contributing to Pharo and
contributing to Python
is the additional barrier of entry to *stop* developing you
application and "invest the time
to learn the tool chain(s)(make, ReST, regrtest, svnmerge/svndiff,
sphinx, etc)" [1].

Python users are more likely to workaround an issue [2].  Whereas in
Pharo, the system comes
ready to debug by default.  Your workaround with Pharo is as likely to
change something in
core system code as change something in your app code.

[1] http://jessenoller.com/2010/04/22/why-arent-you-contributing-to-python
[2] 
https://tech.blog.aknin.name/2010/04/23/why-dont-i-contribute-to-python-often/

cheers -ben

On Mon, Sep 26, 2016 at 12:26 AM, Dimitris Chloupis
 wrote:
> Allow me to be very skeptical, are you sure your numbers is not main
> contributors because I find it hard to believe that Python that has around 2
> million coders world wide
>
> https://blog.pythonanywhere.com/67/
>
> has ONLY 92 total contributors ? I would assume an estimate of around 1000
> including those that have just one simple bug fix.
>
> On Sun, Sep 25, 2016 at 5:31 PM Ben Coman  wrote:
>>
>> 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

Re: [Pharo-dev] comparison statistics

[Dimitris Chloupis]

Allow me to be very skeptical, are you sure your numbers is not main
contributors because I find it hard to believe that Python that has around
2 million coders world wide

https://blog.pythonanywhere.com/67/

has ONLY 92 total contributors ? I would assume an estimate of around 1000
including those that have just one simple bug fix.

On Sun, Sep 25, 2016 at 5:31 PM Ben Coman  wrote:

> 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
>

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] comparison statistics

[Ben Coman]

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

Re: [Pharo-dev] [ANN] FFI Tutorial, Pharo5 / Libclang

[Esteban Lorenzano]

this is super good… thanks for doing this. 
once finished I would like to use it as tutorial reference :)

cheers, 
Esteban
 
> On 24 Sep 2016, at 19:25, Ben Coman  wrote:
> 
> hi all,
> 
> Just announcing that I'm writing a series of posts on using FFI in
> Pharo 5 to interface to libclang, the interface library for the LLVM C
> compiler.
> 
> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-1-preamble/
> 
> I'm writing this from the perspective of a FFI newbie progressively
> learning the system.  I've left in a few mis-steps since I think it
> can be useful seeing what didn't work.
> 
> cheers -ben
> 

Re: [Pharo-dev] FFI callout arguments - references to internal objects

[Esteban Lorenzano]

Hi Ben, 

I will take a better look tomorrow morning, but as first sight, seems to be 
that you want to declare SomeObject and receive it as argument to the callback, 
while you are receiving just an ExternalAddress. 
If is that the problem what happens is that callbacks do not handle *any type* 
as the rest of UFFI… they just handle standard C types, so you will receive an 
ExternalAddress isn’t?
You need to obtain the actual object as you need it. I see two strategies: 

1) just create the object using SomeObject>>#fromHandle: This work fine if 
object is stateless and just want to access it’s defined vocabulary. 
2) or… you can just caché the data someplace and then find it using the 
ExternalAddress as index.
 
(I hope I interpreted the problem correctly… I’m a bit sleep here :P) 

cheers,
Esteban


> On 24 Sep 2016, at 19:40, Ben Coman  wrote:
> 
> I'm seeking some support for Part 5 of my FFI tutorial
> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-5-client-data-and-recursive-visitorcallbacks/
> 
> where I'm trying to replicate some C code where:
> * client_data is a void pointer, and an argument to a callout function
> * a reference to some data (an int, or a struct) is passed to the
> callout function as the client_data
> * the callout function passes that same client_data to a callback
> function which casts the client-data to the required type
> 
> How can I replicate that with UFFI?  The key thing is that *any* type
> can be passed via client_data.  So for a normal Pharo object defined
> like...
> 
> Object subclass: MyObject
>instanceVariables: 'x y'
> 
> myobject := MyObject new x:3 y:4.
> 
> I want to pass a reference to myobject to the callout, and in the
> callback dereference client_data to get myobject that I can operate on
> normally.
> 
> Is this possible with current infrastructure, or would it need
> something new like FFIInternalPinnedReference to wrap myobject for the
> callout and unwrap it in the callback?
> 
> cheers -ben
> 

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60240
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] d5075d: 60240

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: d5075d407114ba1d3b529fb2740cbb34a4eaa50b
  
https://github.com/pharo-project/pharo-core/commit/d5075d407114ba1d3b529fb2740cbb34a4eaa50b
  Author: Jenkins Build Server 
  Date:   2016-09-25 (Sun, 25 Sep 2016)

  Changed paths:
M Kernel.package/Object.class/instance/accessing/yourself.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60239.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60240.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60239.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60240.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A ScriptingExtensions.package/extension/String/instance/asClass.st
A ScriptingExtensions.package/extension/String/instance/asClassIfAbsent_.st
A ScriptingExtensions.package/extension/String/instance/asClassIfPresent_.st
A 
ScriptingExtensions.package/extension/String/instance/asClassInEnvironment_.st
A 
ScriptingExtensions.package/extension/String/instance/asClassInEnvironment_ifAbsent_.st
R System-Support.package/extension/String/instance/asClass.st
R System-Support.package/extension/String/instance/asClassIfAbsent_.st
R System-Support.package/extension/String/instance/asClassIfPresent_.st
R System-Support.package/extension/String/instance/asClassInEnvironment_.st
R 
System-Support.package/extension/String/instance/asClassInEnvironment_ifAbsent_.st

  Log Message:
  ---
  60240
19140 asClass should be packaged in ScriptingExtensions
https://pharo.fogbugz.com/f/cases/19140

19139 Method comment of yourself should be really improved
https://pharo.fogbugz.com/f/cases/19139

http://files.pharo.org/image/60/60240.zip

Re: [Pharo-dev] glitches in text selection

[stepharo]

Hi sean


What I mentioned what really worse. You would select a piece of text and 
you would lose some characters


at the end. So I do not think that it is link with your report.

Did you try on latest Pharo 60 to know if your problem is still there?

Stef


Le 25/9/16 à 05:50, Sean P. DeNigris a écrit :

Nicolai Hess-3-2 wrote

Yes, see case 19113, fixed in 60233

Is this related to
https://pharo.fogbugz.com/f/cases/19036/Bizarre-Text-Selection-in-Pharo-5-0
? If so, I strongly suggest we backport it. The inaccurate text selection in
5.0 is a workflow killer!!



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/glitches-in-text-selection-tp4916366p4917003.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.