date:20160907

Le 7/9/16 à 08:53, Offray Vladimir Luna Cárdenas a écrit :

Hi,

Nice to see more diversity on license choice and projects in this 
community. We have the permissive MIT license by default in almost all 
Pharo and related project, but seeing GPL and AGPL in projects like 
Spec and now Territorial increase the sense of choice and engagement.

No sorry I cannot let you say such stupid statement.
Spec is not GPL. And GPL is really dangerous for image based system. It 
is a plague.

We do not want to force nice people (the one that could follow a 
license) to have to decide to use another language

just because they do not want to give their work for free.
Open source

Second you do not know what the mess it can be.

In my case as a freelancer, having such licenses as base for the code 
of my works has helped me against big institutions that have 
aggressive practices regarding "Intelectual Property" and want 
everything for them all the time. Even in this community we have seen 
some interesting work that can not be contributed back to the 
community until the community makes something open by default 
(something related Java support comes to mind).

You do not know the story behind. And all Moose is BSD and Pharo 
ecosystem is MIT. So you can run away with them and get rich.

Now none of them force people to open source what they are doing

Having a license that enforce reciprocity by default (GPL, AGPL) 
instead of "do what you want" ones (MIT, BSD) helps to keep the 
commons protected against predatory enclosure,

No it does not protect anything. It binds nice people to act nicely but 
does not do anything against assholes. So this is a lose / lose situation.

even if you're a small freelancer and the ones really interested in 
such enclosure can still contact the author and pay the extra price 
that comes with not reciprocity to the wider community.

You dream. Such license will not protect anyone.
There are millions companies out there using GPL code and not opening 
their work.

Any code in GPL will not be considered for anything in our community.

Thanks Hernán,

Offray

On 07/09/16 06:48, p...@highoctane.be wrote:

In Tiki, there has been such discussions as well.

https://tiki.org/License

But yeah, MIT license is the best thing :-)

Phil

On Wed, Sep 7, 2016 at 12:25 AM, Hernán Morales Durand 
mailto:hernan.mora...@gmail.com>> wrote:

I thought for a while about the license.

Fixing the ASP loophole means trying to escape from companies
using a trick to avoid returning changes to the code back to the
community[1]. I agree with such position. GNU AGPL is free,
copyleft, approved by OSI, FSF, and used by successful projects :
MongoDB, SugarCRM, OTRS, etc. If anyone want to discuss
collaboration or re-licensing, for example to monetize library
services, feel free to contact me privately.

Hernán

[1]
http://www.fabcapo.com/2008/02/we-have-submitted-agpl-to-osi.html

2016-09-06 18:03 GMT-03:00 Tudor Girba mailto:tu...@tudorgirba.com>>:

Hi Hernán,

I believe Stef was asking about the choice of picking a viral
license vs the permissive MIT one that we use in code that
gets into Pharo (and several other larger related projects).

Cheers,
Doru

> On Sep 6, 2016, at 10:28 PM, Hernán Morales Durand
mailto:hernan.mora...@gmail.com>>
wrote:
>
> Hi Stef,
>
> I used the License Differentiator tool at
http://oss-watch.ac.uk/apps/licdiff/

>
> I like it because it fixes the 'ASP (application service
provider) loophole' or 'privacy loophole' problem (See Choice
Six in the tool)
>
> Hernán
>
>
> 2016-09-06 16:47 GMT-03:00 stepharo mailto:steph...@free.fr>>:
> Hi hernan
>
> why do you picked AGPL? We try to protect our community
against license hell.
> Stef
> Le 6/9/16 à 11:40, Hernán Morales Durand a écrit :
>>
>> Hi Stephan,
>>
>> 2016-09-06 2:52 GMT-03:00 Stephan Eggermont
mailto:step...@stack.nl>>:
>> On 06/09/16 06:24, Hernán Morales Durand wrote:
>>
>> I am happy to announce the release of Territorial, a new
Smalltalk
>> library for Geographical Information Retrieval in
geopolitical objects.
>>
>> Nice. Please tell us about your license choice
>>
>>
>> License of the library is AGPL v3 (it is in the Notes and
disclaimers of the manual)
>> License of the documentation is CC BY-SA 3.0
>>
>> Cheers,
>>
>> Hernán
>>
>> Stephan
>>
>>
>>
>>
>
>

--
www.

Re: [Pharo-users] [ANN] Territorial

Hi,

On 07/09/16 09:26, stepharo wrote:

Le 7/9/16 à 08:53, Offray Vladimir Luna Cárdenas a écrit :

Hi,

Nice to see more diversity on license choice and projects in this
community. We have the permissive MIT license by default in almost
all Pharo and related project, but seeing GPL and AGPL in projects
like Spec and now Territorial increase the sense of choice and
engagement.

No sorry I cannot let you say such stupid statement.
Spec is not GPL.

Is not me who is doing the statement, is Benjamin Van Ryseghem, which
was pretty involved in its development, since 2014:

http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html

And GPL is really dangerous for image based system. It is a plague.

We do not want to force nice people (the one that could follow a
license) to have to decide to use another language

just because they do not want to give their work for free.
Open source

Second you do not know what the mess it can be.

Yes, I don't know, but the Spec case shows that dual licensing is
possible, so is not a binary decision.

In my case as a freelancer, having such licenses as base for the code
of my works has helped me against big institutions that have
aggressive practices regarding "Intelectual Property" and want
everything for them all the time. Even in this community we have seen
some interesting work that can not be contributed back to the
community until the community makes something open by default
(something related Java support comes to mind).

You do not know the story behind. And all Moose is BSD and Pharo
ecosystem is MIT. So you can run away with them and get rich.

Now none of them force people to open source what they are doing

Or you can do the work twice, one close source and with legal bindings
for not releasing anything and the second time open source in a
community fashion.

Having a license that enforce reciprocity by default (GPL, AGPL)
instead of "do what you want" ones (MIT, BSD) helps to keep the
commons protected against predatory enclosure,

No it does not protect anything. It binds nice people to act nicely
but does not do anything against assholes. So this is a lose / lose
situation.

Well, in my context it has protected my against big institutions to
close my work. Same for CC-By-SA (which enforces reciprocity and is
behind most of the Pharo books). Licensing is a complex issue, it
doesn't work the same in all the contexts and products. I don't know the
specificity for image base development, but dual license is applicable
here, as the Spec case shows.

even if you're a small freelancer and the ones really interested in
such enclosure can still contact the author and pay the extra price
that comes with not reciprocity to the wider community.

You dream. Such license will not protect anyone.
There are millions companies out there using GPL code and not opening
their work.

Not anyone. See Cisco case [1]. So maybe there are millions companies
misbehaving about the license implications, but there are also companies
with millions behind that are in (forced?) compliance because the GPL
protection is working. This has implications in projects like guifi.net,
which is using Cisco GPLed routers to build one of the biggest p2p WiFi
networks in the world (35,464 nodes covering 58,383 kilometers) [1a].

[1]
http://arstechnica.com/information-technology/2009/05/cisco-settles-fsf-gpl-lawsuit-appoints-compliance-officer/

[1a] http://guifi.net/

Any code in GPL will not be considered for anything in our community.

Except for Spec and its dual license model.

My call is to consider differences. We should not have "The Pharo Way"
(TM) or "No way!"... suddenly Markus talk about feedback loops comes to
mind, particularly the slide on page 53, regarding "An open source
smalltalk ignoring all community contributions"[2]. This is far for
being the case in this community and we can keep that scenario at safe
distance, if we show options. So, dual license is an option, git is an
option, markdown is an option. Pharo as a place with options is one
where Pharo can fulfill its vision for more people. Let's make these
options visible and figure out the way the work better for a wider
community.

[2] http://marcusdenker.de/talks/16ESUG/FeedbackLoopsAnnotated.pdf

Cheers,

Offray

Re: [Pharo-users] [ANN] Territorial

2016-09-07 Thread Tudor Girba

Hi,

A note about Spec: What you are seeing in the announcement from August 2014, on 
the spec.st site is an announcement about a fork of Spec. The Spec from Pharo 
has always been MIT. Even the spec.st related repository on GitHub is now under 
MIT. See here:
https://github.com/spec-framework/spec

People are free to choose what they want with their projects, but in Pharo we 
will only consider code that is MIT. Please do not use the Spec as an example 
for dual licensing because it does not fit :). See above.

Cheers,
Doru


> On Sep 7, 2016, at 10:07 AM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> 
> On 07/09/16 09:26, stepharo wrote:
>> 
>> 
>> 
>> Le 7/9/16 à 08:53, Offray Vladimir Luna Cárdenas a écrit :
>>> 
>>> Hi,
>>> 
>>> Nice to see more diversity on license choice and projects in this 
>>> community. We have the permissive MIT license by default in almost all 
>>> Pharo and related project, but seeing GPL and AGPL in projects like Spec 
>>> and now Territorial increase the sense of choice and engagement.
>>> 
>> No sorry I cannot let you say such stupid statement.
>> Spec is not GPL. 
> 
> Is not me who is doing the statement, is Benjamin Van Ryseghem, which was 
> pretty involved in its development, since 2014:
> 
> http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html
>> And GPL is really dangerous for image based system. It is a plague.
>> 
>> We do not want to force nice people (the one that could follow a license) to 
>> have to decide to use another language
>> just because they do not want to give their work for free.
>> Open source
>> 
>> Second you do not know what the mess it can be.
>> 
> 
> Yes, I don't know, but the Spec case shows that dual licensing is possible, 
> so is not a binary decision.
>>> In my case as a freelancer, having such licenses as base for the code of my 
>>> works has helped me against big institutions that have aggressive practices 
>>> regarding "Intelectual Property" and want everything for them all the time. 
>>> Even in this community we have seen some interesting work that can not be 
>>> contributed back to the community until the community makes something open 
>>> by default (something related Java support comes to mind).
>>> 
>> You do not know the story behind. And all Moose is BSD and Pharo ecosystem 
>> is MIT. So you can run away with them and get rich.
>> Now none of them force people to open source what they are doing
> 
> Or you can do the work twice, one close source and with legal bindings for 
> not releasing anything and the second time open source in a community fashion.
> 
>> 
>>> Having a license that enforce reciprocity by default (GPL, AGPL) instead of 
>>> "do what you want" ones (MIT, BSD) helps to keep the commons protected 
>>> against predatory enclosure,
>>> 
>> No it does not protect anything. It binds nice people to act nicely but does 
>> not do anything against assholes. So this is a lose / lose situation.
>> 
> 
> Well, in my context it has protected my against big institutions to close my 
> work. Same for CC-By-SA (which enforces reciprocity and is behind most of the 
> Pharo books). Licensing is a complex issue, it doesn't work the same in all 
> the contexts and products. I don't know the specificity for image base 
> development, but dual license is applicable here, as the Spec case shows.
> 
>>> even if you're a small freelancer and the ones really interested in such 
>>> enclosure can still contact the author and pay the extra price that comes 
>>> with not reciprocity to the wider community.
>>> 
>> You dream. Such license will not protect anyone.
>> There are millions companies out there using GPL code and not opening their 
>> work.
> 
> Not anyone. See Cisco case [1]. So maybe there are millions companies 
> misbehaving about the license implications, but there are also companies with 
> millions behind that are in (forced?) compliance because the GPL protection 
> is working. This has implications in projects like guifi.net, which is using 
> Cisco GPLed routers to build one of the biggest p2p WiFi networks in the 
> world (35,464 nodes covering 58,383 kilometers) [1a].
> 
> [1] 
> http://arstechnica.com/information-technology/2009/05/cisco-settles-fsf-gpl-lawsuit-appoints-compliance-officer/
> [1a] http://guifi.net/
> 
>> Any code in GPL will not be considered for anything in our community.
>> 
> 
> Except for Spec and its dual license model.
> 
> My call is to consider differences. We should not have "The Pharo Way" (TM) 
> or "No way!"... suddenly Markus talk about feedback loops comes to mind, 
> particularly the slide on page 53, regarding "An open source smalltalk 
> ignoring all community contributions"[2]. This is far for being the case in 
> this community and we can keep that scenario at safe distance, if we show 
> options. So, dual license is an option, git is an option, markdown is an 
> option. Pharo as a place with options is one where Pharo can fulfill its 
> vision for mor

Re: [Pharo-users] [ANN] Territorial


Hi Doru,

As a newcomer to the community, that situation was not clear for me from 
the blog post I linked, and I was referred there following the "News" 
tab on the spec.st site, in my first approach to learning it.


I think that a better explanation on why GPL is not a good fit in the 
Pharo ecosystem is important, because Hernán rationality behind his 
license chose is sound. I switched mine from GLP to MIT quickly to fit 
Pharo, but also without any major explanation. Something similar to 
what, the Smalltalk inspired project, Etoile has done [1], seems a 
position that explains why licensing choosing is confined, avoiding 
GPL/AGPL, and favouring LGPL, 3 clause BSD and MIT and common domain. 
This works better that "GPL is a plague", "only MIT", or "you can't make 
money with Free Software".


[1] http://etoileos.com/dev/licensing/

Maybe the place for linking such explanation is Smalltalkhub, because is 
the place where most people, specially newbies, are releasing/licensing 
their code. So offering choice, while advising which one works better 
for Pharo ecosystem integration seems more inviting a gives people an 
informed overview of the different possibilities to contribute back to 
the community.


So, Hernán, Steph and Doru, thanks for bringing this and teach me with 
the dialogue about it.


Cheers,

Offray


On 07/09/16 10:23, Tudor Girba wrote:

Hi,

A note about Spec: What you are seeing in the announcement from August 2014, on 
the spec.st site is an announcement about a fork of Spec. The Spec from Pharo 
has always been MIT. Even the spec.st related repository on GitHub is now under 
MIT. See here:
https://github.com/spec-framework/spec

People are free to choose what they want with their projects, but in Pharo we 
will only consider code that is MIT. Please do not use the Spec as an example 
for dual licensing because it does not fit :). See above.

Cheers,
Doru



On Sep 7, 2016, at 10:07 AM, Offray Vladimir Luna Cárdenas 
 wrote:

Hi,


On 07/09/16 09:26, stepharo wrote:



Le 7/9/16 à 08:53, Offray Vladimir Luna Cárdenas a écrit :

Hi,

Nice to see more diversity on license choice and projects in this community. We 
have the permissive MIT license by default in almost all Pharo and related 
project, but seeing GPL and AGPL in projects like Spec and now Territorial 
increase the sense of choice and engagement.


No sorry I cannot let you say such stupid statement.
Spec is not GPL.

Is not me who is doing the statement, is Benjamin Van Ryseghem, which was 
pretty involved in its development, since 2014:

http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html

And GPL is really dangerous for image based system. It is a plague.

We do not want to force nice people (the one that could follow a license) to 
have to decide to use another language
just because they do not want to give their work for free.
Open source

Second you do not know what the mess it can be.


Yes, I don't know, but the Spec case shows that dual licensing is possible, so 
is not a binary decision.

In my case as a freelancer, having such licenses as base for the code of my works has 
helped me against big institutions that have aggressive practices regarding 
"Intelectual Property" and want everything for them all the time. Even in this 
community we have seen some interesting work that can not be contributed back to the 
community until the community makes something open by default (something related Java 
support comes to mind).


You do not know the story behind. And all Moose is BSD and Pharo ecosystem is 
MIT. So you can run away with them and get rich.
Now none of them force people to open source what they are doing

Or you can do the work twice, one close source and with legal bindings for not 
releasing anything and the second time open source in a community fashion.


Having a license that enforce reciprocity by default (GPL, AGPL) instead of "do what 
you want" ones (MIT, BSD) helps to keep the commons protected against predatory 
enclosure,


No it does not protect anything. It binds nice people to act nicely but does 
not do anything against assholes. So this is a lose / lose situation.


Well, in my context it has protected my against big institutions to close my 
work. Same for CC-By-SA (which enforces reciprocity and is behind most of the 
Pharo books). Licensing is a complex issue, it doesn't work the same in all the 
contexts and products. I don't know the specificity for image base development, 
but dual license is applicable here, as the Spec case shows.


even if you're a small freelancer and the ones really interested in such 
enclosure can still contact the author and pay the extra price that comes with 
not reciprocity to the wider community.


You dream. Such license will not protect anyone.
There are millions companies out there using GPL code and not opening their 
work.

Not anyone. See Cisco case [1]. So maybe there are millions companies 
misbehaving about the license implicati

Re: [Pharo-users] [ANN] Territorial

GPL is a license that courts have already recognized in many cases.

Not that they have much of a choice

A license is basically a contract and contracts are legally binding as long
as acceptance can be proved for both sides.

As a lawyer I would not advise any client to try to challenge GPL on two
grounds:

a) Infringement of contract makes you liable to compensation and gives the
legal right to the other party to have a court decisions  that forbids you
to keep selling / distributing your software. If you violate the court
decision that entitles the opposing party for further litigation and
compensation. In some cases comes with the gift of prison time depending on
national law

b) Its also an infringement on copyright which is even more litigation and
much more compensations

Also from a practical point of view GPL is the only license that can really
protect open source software on the premise when you have a permitting
license like MIT what you do is open the door to countless of companies
that want to do business with you for selling their closed source but also
countless of threats. A company could easily for example take Pharo close
source it and heavily upgrade , as a result many Pharo users could migrate
to this heavily improved new close source Pharo essentially killing or
shrinking substantially the MIT Pharo. This is actually what Pharo did for
Squeak with the big difference that Pharo is still open source.

Of course MIT license is what most companies would prefer for using your
code , though LGPL is also a favored choice. You can also have modified GPL
license that allows its usage on closed source system which is basically
what LGPL is , but with the difference you can put any term you want in it.
Most popular languages come with their own license anyway.

If what you claimed was true even slightly that would mean that the law
would not protect GPL, which in extension would mean no protection for
licenses which in extension would mean no protection for contracts which as
you can imagine is just not practical and would through the entire global
commerce into a chaos, legal or non legal.

In case of Europe things are better on the legal protection front because
EU law has done an excellent job at harmonizing national legislation and
protecting basic legal rights.

On Wed, Sep 7, 2016 at 10:27 AM stepharo  wrote:

>
>
> Le 7/9/16 à 08:53, Offray Vladimir Luna Cárdenas a écrit :
>
> Hi,
>
> Nice to see more diversity on license choice and projects in this
> community. We have the permissive MIT license by default in almost all
> Pharo and related project, but seeing GPL and AGPL in projects like Spec
> and now Territorial increase the sense of choice and engagement.
>
> No sorry I cannot let you say such stupid statement.
> Spec is not GPL. And GPL is really dangerous for image based system. It is
> a plague.
>
> We do not want to force nice people (the one that could follow a license)
> to have to decide to use another language
> just because they do not want to give their work for free.
> Open source
>
> Second you do not know what the mess it can be.
>
> In my case as a freelancer, having such licenses as base for the code of
> my works has helped me against big institutions that have aggressive
> practices regarding "Intelectual Property" and want everything for them all
> the time. Even in this community we have seen some interesting work that
> can not be contributed back to the community until the community makes
> something open by default (something related Java support comes to mind).
>
> You do not know the story behind. And all Moose is BSD and Pharo ecosystem
> is MIT. So you can run away with them and get rich.
> Now none of them force people to open source what they are doing
>
> Having a license that enforce reciprocity by default (GPL, AGPL) instead
> of "do what you want" ones (MIT, BSD) helps to keep the commons protected
> against predatory enclosure,
>
> No it does not protect anything. It binds nice people to act nicely but
> does not do anything against assholes. So this is a lose / lose situation.
>
> even if you're a small freelancer and the ones really interested in such
> enclosure can still contact the author and pay the extra price that comes
> with not reciprocity to the wider community.
>
> You dream. Such license will not protect anyone.
> There are millions companies out there using GPL code and not opening
> their work.
> Any code in GPL will not be considered for anything in our community.
>
>
>
> Thanks Hernán,
>
> Offray
>
> On 07/09/16 06:48, p...@highoctane.be wrote:
>
> In Tiki, there has been such discussions as well.
>
> https://tiki.org/License
>
> But yeah, MIT license is the best thing :-)
>
> Phil
>
>
>
>
> On Wed, Sep 7, 2016 at 12:25 AM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
>>
>> I thought for a while about the license.
>>
>> Fixing the ASP loophole means trying to escape from companies using a
>> trick to avoid returning ch

Re: [Pharo-users] [ANN] Territorial

Hi,

We do not accept GPL for Pharo because is viral: it enforces GPL to “derivative 
work”, and in OO, where you basically refine classes, is hard to see when your 
work is a separated thing and when is “a derivate” (one could say that in 
smalltalk, everything you do is a derivate… a nightmare that has made possible 
Cincom business models).

Point. 

Now, you are free to license your code under the license you prefer (and 
please, note that you can do that because WE decided to license Pharo as MIT 
:)… but that restricts your program in two ways: 
1) is not eligible for integration into Pharo. Is not even eligible for “look 
at it and pick ideas”, because is a license violation.
2) many people will run away from even look at that code, for same reasons we 
will not look at it (we do not want to infringe license terms… so we are 
basically out of any movement that can happen there).

so that :)

I my self  have code that is not under any copyleft license (custom projects 
for particular clients), but that didn’t avoid me to release Voyage and all the 
frameworks I developed while doing custom apps as MIT. Why? because I wanted a 
community looking at it. 

cheers, 
Esteban 

> On 07 Sep 2016, at 11:03, Dimitris Chloupis  wrote:
> 
> GPL is a license that courts have already recognized in many cases.
> 
> Not that they have much of a choice
> 
> A license is basically a contract and contracts are legally binding as long 
> as acceptance can be proved for both sides. 
> 
> As a lawyer I would not advise any client to try to challenge GPL on two 
> grounds: 
> 
> a) Infringement of contract makes you liable to compensation and gives the 
> legal right to the other party to have a court decisions  that forbids you to 
> keep selling / distributing your software. If you violate the court decision 
> that entitles the opposing party for further litigation and compensation. In 
> some cases comes with the gift of prison time depending on national law
> 
> b) Its also an infringement on copyright which is even more litigation and 
> much more compensations
> 
> Also from a practical point of view GPL is the only license that can really 
> protect open source software on the premise when you have a permitting 
> license like MIT what you do is open the door to countless of companies that 
> want to do business with you for selling their closed source but also 
> countless of threats. A company could easily for example take Pharo close 
> source it and heavily upgrade , as a result many Pharo users could migrate to 
> this heavily improved new close source Pharo essentially killing or shrinking 
> substantially the MIT Pharo. This is actually what Pharo did for Squeak with 
> the big difference that Pharo is still open source. 
> 
> Of course MIT license is what most companies would prefer for using your code 
> , though LGPL is also a favored choice. You can also have modified GPL 
> license that allows its usage on closed source system which is basically what 
> LGPL is , but with the difference you can put any term you want in it. Most 
> popular languages come with their own license anyway. 
> 
> If what you claimed was true even slightly that would mean that the law would 
> not protect GPL, which in extension would mean no protection for licenses 
> which in extension would mean no protection for contracts which as you can 
> imagine is just not practical and would through the entire global commerce 
> into a chaos, legal or non legal. 
> 
> In case of Europe things are better on the legal protection front because EU 
> law has done an excellent job at harmonizing national legislation and 
> protecting basic legal rights. 
> 
> On Wed, Sep 7, 2016 at 10:27 AM stepharo  > wrote:
> 
> 
> Le 7/9/16 à 08:53, Offray Vladimir Luna Cárdenas a écrit :
>> Hi,
>> 
>> Nice to see more diversity on license choice and projects in this community. 
>> We have the permissive MIT license by default in almost all Pharo and 
>> related project, but seeing GPL and AGPL in projects like Spec and now 
>> Territorial increase the sense of choice and engagement. 
> 
> No sorry I cannot let you say such stupid statement. 
> Spec is not GPL. And GPL is really dangerous for image based system. It is a 
> plague. 
> 
> We do not want to force nice people (the one that could follow a license) to 
> have to decide to use another language
> just because they do not want to give their work for free. 
> Open source
> 
> Second you do not know what the mess it can be. 
> 
>> 
>> In my case as a freelancer, having such licenses as base for the code of my 
>> works has helped me against big institutions that have aggressive practices 
>> regarding "Intelectual Property" and want everything for them all the time. 
>> Even in this community we have seen some interesting work that can not be 
>> contributed back to the community until the community makes something open 
>> by default (something related Java support comes

[Pharo-users] Another PunQLite problem?

2016-09-07 Thread PBKResearch

Hello

 

I have been exploring further, following problems mentioned in an earlier
post, and I have identified what looks like a definite bug. I can't say
whether it explains any of my earlier problems, but it seems worth
mentioning in its own right.

 

To be clear, I am using the version posted as TorstenBergmann.28 on 11 May
2016 on the mumez site (https://github.com/mumez/PunQLite), because I
couldn't get Esteban's version to work. I am using Moose 6.0 (Pharo 5.0
Latest update: #50761) on Windows 10. I started with this example from the
mumez site:

 

"Using explicit transaction"

db := PqDatabase open: 'trans.db'.

db disableAutoCommit.

1 to: 100 do: [:idx | | key | 

key := idx asString.

db transact: [db at: key put: ('value-', key)]

].

db close.

 

Because I had observed in my previous failures that the database was only
supplying one buffer-full of data (1024 bytes), I decided to try the effect
of storing longer values in the database. First I created a filler of 900
bytes (the string '123456789' repeated 100 times) and included this in each
of the stored values. The returned value of "db at: '1' " was correct - a
ByteArray of 907 bytes. Then I doubled the length of the filler and tried
again. This time the returned value was only 1024 bytes long - correct as
far as it went, but incomplete. When I included the statement 'db
fetchBufferSize: 2048', the whole record was retrieved correctly. Note that
I did not rewrite the database file to get this correct result; clearly the
data have been written correctly, and the problem lies in the retrieval.

 

All the trials I did earlier included strings of several thousand bytes, so
it seems clear that, even if they were written correctly, they would not be
retrieved. I don't know how much this explains, but it's clearly part of the
problem. Looking at the tests package, all the tests write and retrieve
strings of only a few bytes. It would be a good idea to include a test that
writes and retrieves a value which is longer that the buffer.

 

Hope this is helpful

 

Peter Kenny

[Pharo-users] Planning: Pharo Sprints Lille for the rest 2016

2016-09-07 Thread Marcus Denker

Hi

Here locally we try to organise one “Sprint” per month were we meet to work on 
boring issue tracker entries together. (external visitors are welcome!)

In the past people organised local sprints at other places at the sane time 
(e.g. Santiago/Chile).

The next dates are:

30 September
28 October
25 November
16 December. Pharo Christmas Party!


Marcus

Re: [Pharo-users] [ANN] Territorial

Hi,

No sorry I cannot let you say such stupid statement.
Spec is not GPL.

Is not me who is doing the statement, is Benjamin Van Ryseghem, which
was pretty involved in its development, since 2014:

http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html
P. Ben did it just because he wanted to impact us. Now he cannot
change the license like that because he was paid during the development
of Spec by our team and lawyers explained to him nicely that you cannot
change the license of a software system if all the contributors do not
agree and I did not (because a large part of Spec are my ideas).

And GPL is really dangerous for image based system. It is a plague.

We do not want to force nice people (the one that could follow a
license) to have to decide to use another language

just because they do not want to give their work for free.
Open source

Second you do not know what the mess it can be.

Yes, I don't know, but the Spec case shows that dual licensing is
possible, so is not a binary decision.

No again you do not know the truth on that story
There is not dual licensing. Period.

You do not know the story behind. And all Moose is BSD and Pharo
ecosystem is MIT. So you can run away with them and get rich.

Now none of them force people to open source what they are doing

Or you can do the work twice, one close source and with legal bindings
for not releasing anything and the second time open source in a
community fashion.

This is not our way of doing things.

Having a license that enforce reciprocity by default (GPL, AGPL)
instead of "do what you want" ones (MIT, BSD) helps to keep the
commons protected against predatory enclosure,

No it does not protect anything. It binds nice people to act nicely
but does not do anything against assholes. So this is a lose / lose
situation.

Well, in my context it has protected my against big institutions to
close my work. Same for CC-By-SA (which enforces reciprocity and is
behind most of the Pharo books). Licensing is a complex issue, it
doesn't work the same in all the contexts and products. I don't know
the specificity for image base development, but dual license is
applicable here, as the Spec case shows.

No it does not :)
GPL is a viral license that was not designed with image (shared memory
of programs) in mind.
So this is really simple: if you use GPL then do not imagine one instant
that one sensible guy (and nice) will load your code in his image.

Or he is fool :)

even if you're a small freelancer and the ones really interested in
such enclosure can still contact the author and pay the extra price
that comes with not reciprocity to the wider community.

You dream. Such license will not protect anyone.
There are millions companies out there using GPL code and not opening
their work.

Not anyone. See Cisco case [1]. So maybe there are millions companies
misbehaving about the license implications, but there are also
companies with millions behind that are in (forced?) compliance
because the GPL protection is working. This has implications in
projects like guifi.net, which is using Cisco GPLed routers to build
one of the biggest p2p WiFi networks in the world (35,464 nodes
covering 58,383 kilometers) [1a].

[1]
http://arstechnica.com/information-technology/2009/05/cisco-settles-fsf-gpl-lawsuit-appoints-compliance-officer/

[1a] http://guifi.net/
I do not care! We are not in the world of laywers mess and we do not
want to enter it.

Simple. You can argue I do not care. I want to work and get stuff done.

Any code in GPL will not be considered for anything in our community.

Except for Spec and its dual license model.

No again.

My call is to consider differences.

No in Pharo there is MIT. Period. You do what you want but do not cry if
nobody look at your code.

We should not have "The Pharo Way" (TM) or "No way!"... suddenly
Markus talk about feedback loops comes to mind, particularly the slide
on page 53, regarding "An open source smalltalk ignoring all community
contributions"[2]. This is far for being the case in this community
and we can keep that scenario at safe distance, if we show options.
So, dual license is an option, git is an option, markdown is an
option. Pharo as a place with options is one where Pharo can fulfill
its vision for more people. Let's make these options visible and
figure out the way the work better for a wider community.

It is amazing how you like talking.

[2] http://marcusdenker.de/talks/16ESUG/FeedbackLoopsAnnotated.pdf

Cheers,

Offray

Re: [Pharo-users] [ANN] Territorial




Le 7/9/16 à 10:49, Offray Vladimir Luna Cárdenas a écrit :

Hi Doru,

As a newcomer to the community, that situation was not clear for me 
from the blog post I linked, and I was referred there following the 
"News" tab on the spec.st site, in my first approach to learning it.


I think that a better explanation on why GPL is not a good fit in the 
Pharo ecosystem is important, because Hernán rationality behind his 
license chose is sound. I switched mine from GLP to MIT quickly to fit 
Pharo, but also without any major explanation. 


this has been debated during so many years that we do not want to do it 
anymore.


Something similar to what, the Smalltalk inspired project, Etoile has 
done [1], seems a position that explains why licensing choosing is 
confined, avoiding GPL/AGPL, and favouring LGPL, 3 clause BSD and MIT 
and common domain. This works better that "GPL is a plague", "only 
MIT", or "you can't make money with Free Software".


[1] http://etoileos.com/dev/licensing/


We should do that. I added a short probably bad text under

http://pharo.org/contribute
if someone what to enhance it, feel free.


Maybe the place for linking such explanation is Smalltalkhub, because 
is the place where most people, specially newbies, are 
releasing/licensing their code. So offering choice, while advising 
which one works better for Pharo ecosystem integration seems more 
inviting a gives people an informed overview of the different 
possibilities to contribute back to the community.


So, Hernán, Steph and Doru, thanks for bringing this and teach me with 
the dialogue about it.


Cheers,

Offray


On 07/09/16 10:23, Tudor Girba wrote:

Hi,

A note about Spec: What you are seeing in the announcement from 
August 2014, on the spec.st site is an announcement about a fork of 
Spec. The Spec from Pharo has always been MIT. Even the spec.st 
related repository on GitHub is now under MIT. See here:

https://github.com/spec-framework/spec

People are free to choose what they want with their projects, but in 
Pharo we will only consider code that is MIT. Please do not use the 
Spec as an example for dual licensing because it does not fit :). See 
above.


Cheers,
Doru


On Sep 7, 2016, at 10:07 AM, Offray Vladimir Luna Cárdenas 
 wrote:


Hi,


On 07/09/16 09:26, stepharo wrote:



Le 7/9/16 à 08:53, Offray Vladimir Luna Cárdenas a écrit :

Hi,

Nice to see more diversity on license choice and projects in this 
community. We have the permissive MIT license by default in almost 
all Pharo and related project, but seeing GPL and AGPL in projects 
like Spec and now Territorial increase the sense of choice and 
engagement.



No sorry I cannot let you say such stupid statement.
Spec is not GPL.
Is not me who is doing the statement, is Benjamin Van Ryseghem, 
which was pretty involved in its development, since 2014:


http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html

And GPL is really dangerous for image based system. It is a plague.

We do not want to force nice people (the one that could follow a 
license) to have to decide to use another language

just because they do not want to give their work for free.
Open source

Second you do not know what the mess it can be.

Yes, I don't know, but the Spec case shows that dual licensing is 
possible, so is not a binary decision.
In my case as a freelancer, having such licenses as base for the 
code of my works has helped me against big institutions that have 
aggressive practices regarding "Intelectual Property" and want 
everything for them all the time. Even in this community we have 
seen some interesting work that can not be contributed back to the 
community until the community makes something open by default 
(something related Java support comes to mind).


You do not know the story behind. And all Moose is BSD and Pharo 
ecosystem is MIT. So you can run away with them and get rich.

Now none of them force people to open source what they are doing
Or you can do the work twice, one close source and with legal 
bindings for not releasing anything and the second time open source 
in a community fashion.


Having a license that enforce reciprocity by default (GPL, AGPL) 
instead of "do what you want" ones (MIT, BSD) helps to keep the 
commons protected against predatory enclosure,


No it does not protect anything. It binds nice people to act nicely 
but does not do anything against assholes. So this is a lose / lose 
situation.


Well, in my context it has protected my against big institutions to 
close my work. Same for CC-By-SA (which enforces reciprocity and is 
behind most of the Pharo books). Licensing is a complex issue, it 
doesn't work the same in all the contexts and products. I don't know 
the specificity for image base development, but dual license is 
applicable here, as the Spec case shows.


even if you're a small freelancer and the ones really interested 
in such enclosure can still contact the author and pay the extra 
price that com

Re: [Pharo-users] [ANN] Territorial




Le 7/9/16 à 11:03, Dimitris Chloupis a écrit :

GPL is a license that courts have already recognized in many cases.

Not that they have much of a choice

A license is basically a contract and contracts are legally binding as 
long as acceptance can be proved for both sides.


As a lawyer I would not advise any client to try to challenge GPL on 
two grounds:


a) Infringement of contract makes you liable to compensation and gives 
the legal right to the other party to have a court decisions  that 
forbids you to keep selling / distributing your software. If you 
violate the court decision that entitles the opposing party for 
further litigation and compensation. In some cases comes with the gift 
of prison time depending on national law


b) Its also an infringement on copyright which is even more litigation 
and much more compensations


Also from a practical point of view GPL is the only license that can 
really protect open source software on the premise when you have a 
permitting license like MIT what you do is open the door to countless 
of companies that want to do business with you for selling their 
closed source but also countless of threats. A company could easily 
for example take Pharo close source it and heavily upgrade , as a 
result many Pharo users could migrate to this heavily improved new 
close source Pharo essentially killing or shrinking substantially the 
MIT Pharo. This is actually what Pharo did for Squeak with the big 
difference that Pharo is still open source.

Indeed and we knew the risk.



Of course MIT license is what most companies would prefer for using 
your code , though LGPL is also a favored choice. You can also have 
modified GPL license that allows its usage on closed source system 
which is basically what LGPL is , but with the difference you can put 
any term you want in it. Most popular languages come with their own 
license anyway.


If what you claimed was true even slightly that would mean that the 
law would not protect GPL, which in extension would mean no protection 
for licenses which in extension would mean no protection for contracts 
which as you can imagine is just not practical and would through the 
entire global commerce into a chaos, legal or non legal.


In case of Europe things are better on the legal protection front 
because EU law has done an excellent job at harmonizing national 
legislation and protecting basic legal rights.


On Wed, Sep 7, 2016 at 10:27 AM stepharo > wrote:




Le 7/9/16 à 08:53, Offray Vladimir Luna Cárdenas a écrit :


Hi,

Nice to see more diversity on license choice and projects in this
community. We have the permissive MIT license by default in
almost all Pharo and related project, but seeing GPL and AGPL in
projects like Spec and now Territorial increase the sense of
choice and engagement.


No sorry I cannot let you say such stupid statement.
Spec is not GPL. And GPL is really dangerous for image based
system. It is a plague.

We do not want to force nice people (the one that could follow a
license) to have to decide to use another language
just because they do not want to give their work for free.
Open source

Second you do not know what the mess it can be.


In my case as a freelancer, having such licenses as base for the
code of my works has helped me against big institutions that have
aggressive practices regarding "Intelectual Property" and want
everything for them all the time. Even in this community we have
seen some interesting work that can not be contributed back to
the community until the community makes something open by default
(something related Java support comes to mind).


You do not know the story behind. And all Moose is BSD and Pharo
ecosystem is MIT. So you can run away with them and get rich.
Now none of them force people to open source what they are doing


Having a license that enforce reciprocity by default (GPL, AGPL)
instead of "do what you want" ones (MIT, BSD) helps to keep the
commons protected against predatory enclosure,


No it does not protect anything. It binds nice people to act
nicely but does not do anything against assholes. So this is a
lose / lose situation.


even if you're a small freelancer and the ones really interested
in such enclosure can still contact the author and pay the extra
price that comes with not reciprocity to the wider community.


You dream. Such license will not protect anyone.
There are millions companies out there using GPL code and not
opening their work.
Any code in GPL will not be considered for anything in our community.




Thanks Hernán,

Offray


On 07/09/16 06:48, p...@highoctane.be 
wrote:

In Tiki, there has been such discussions as well.

https://tiki.org/License

But yeah, MIT license is the best thing :-)

P

Re: [Pharo-users] [ANN] Territorial


Hi,


On 07/09/16 13:39, stepharo wrote:


We should not have "The Pharo Way" (TM) or "No way!"... suddenly 
Markus talk about feedback loops comes to mind, particularly the 
slide on page 53, regarding "An open source smalltalk ignoring all 
community contributions"[2]. This is far for being the case in this 
community and we can keep that scenario at safe distance, if we show 
options. So, dual license is an option, git is an option, markdown is 
an option. Pharo as a place with options is one where Pharo can 
fulfill its vision for more people. Let's make these options visible 
and figure out the way the work better for a wider community.

It is amazing how you like talking.



Yes. I like. Is the way to know unwritten history. Not all the people in 
the community know the details as you do, so talking is the way of going 
out of misconceptions, like mine about dual license or state positions, 
like why I don't use Pillar. The "it has been discussed, this is our 
way, take or leave it" doesn't help in understanding way. So yes, I'm 
all about encouraging dialog/talk if it helps to understand.


Bye,

Offray

Re: [Pharo-users] [ANN] Territorial

2016-09-07 Thread PBKResearch

Stef
> We should not have "The Pharo Way" (TM) or "No way!"... suddenly 
> Markus talk about feedback loops comes to mind, particularly the 
slide 
> on page 53, regarding "An open source smalltalk ignoring all 
community 
> contributions"[2]. This is far for being the case in this community 
> and we can keep that scenario at safe distance, if we show options. 
> So, dual license is an option, git is an option, markdown is an 
> option. Pharo as a place with options is one where Pharo can fulfill 
> its vision for more people. Let's make these options visible and 
> figure out the way the work better for a wider community.
It is amazing how you like talking.

We can argue and disagree, but let's do it politely. This is just downright 
rude, and quite unnecessary.

Peter Kenny

Re: [Pharo-users] [ANN] Territorial




Le 7/9/16 à 13:58, Offray Vladimir Luna Cárdenas a écrit :

Hi,


On 07/09/16 13:39, stepharo wrote:


We should not have "The Pharo Way" (TM) or "No way!"... suddenly 
Markus talk about feedback loops comes to mind, particularly the 
slide on page 53, regarding "An open source smalltalk ignoring all 
community contributions"[2]. This is far for being the case in this 
community and we can keep that scenario at safe distance, if we show 
options. So, dual license is an option, git is an option, markdown 
is an option. Pharo as a place with options is one where Pharo can 
fulfill its vision for more people. Let's make these options visible 
and figure out the way the work better for a wider community.

It is amazing how you like talking.



Yes. I like. Is the way to know unwritten history. Not all the people 
in the community know the details as you do, so talking is the way of 
going out of misconceptions, like mine about dual license or state 
positions, like why I don't use Pillar. The "it has been discussed, 
this is our way, take or leave it" doesn't help in understanding way. 
So yes, I'm all about encouraging dialog/talk if it helps to understand.


this is why I added the comment on the pharo contribution page.



Bye,

Offray

Re: [Pharo-users] [ANN] Territorial

Hi, 

Please let me stress this: you can put the license of your choice to your code. 
Is your right and we ensured it continues being your right by choosing MIT 
license for Pharo. 
That means that all frameworks, apps, etc. that runs on Pharo has to be MIT? 
No! YOU CAN DECIDE. 

But then, if it is not MIT, your code will not be considered for inclusion, 
just that (but many times you do not have that in mind, so who cares). 
In my own case, if is not MIT (or some permissive license like BSD, Apache, 
etc.)  I will not even look inside it… why? because I do not want to be 
“infected”: I do not want to have the risk of copying (even innocently) some 
copyrighted ideas. You do not know the mess that was rewrite entire parts of 
Pharo to be able to release it…
So, in the case of contributions to Pharo, yes… is “our way” (which is not a 
personal statement, is how this community choose to work).

Anyway… of course you can always put the license you want to your code (and 
that applies to Territorial too). 

cheers, 
Esteban

ps: and please forgive Stef for being harsh on this… the Spec affaire was 
painful for us, we do not like to put lawyers and that kind of thing in play… 

> On 07 Sep 2016, at 14:08, stepharo  wrote:
> 
> 
> 
> Le 7/9/16 à 13:58, Offray Vladimir Luna Cárdenas a écrit :
>> Hi,
>> 
>> 
>> On 07/09/16 13:39, stepharo wrote:
>>> 
 We should not have "The Pharo Way" (TM) or "No way!"... suddenly Markus 
 talk about feedback loops comes to mind, particularly the slide on page 
 53, regarding "An open source smalltalk ignoring all community 
 contributions"[2]. This is far for being the case in this community and we 
 can keep that scenario at safe distance, if we show options. So, dual 
 license is an option, git is an option, markdown is an option. Pharo as a 
 place with options is one where Pharo can fulfill its vision for more 
 people. Let's make these options visible and figure out the way the work 
 better for a wider community.
>>> It is amazing how you like talking.
>>> 
>> 
>> Yes. I like. Is the way to know unwritten history. Not all the people in the 
>> community know the details as you do, so talking is the way of going out of 
>> misconceptions, like mine about dual license or state positions, like why I 
>> don't use Pillar. The "it has been discussed, this is our way, take or leave 
>> it" doesn't help in understanding way. So yes, I'm all about encouraging 
>> dialog/talk if it helps to understand.
> 
> this is why I added the comment on the pharo contribution page.
> 
>> 
>> Bye,
>> 
>> Offray
>> 
>> 
> 
>

Re: [Pharo-users] [ANN] Territorial

Ironically enough "this is our way , take it or leave it" would not work
for Pharo because its smalltalk and basically smalltalk by architecture
allow you to deeply modify the system from the get go.

This make Pharo technically impossible to control from a dictator and
committee point of view like lets say Python or Linux. CPython is a single
implementation , but with pharo every pharo app is essentially a new pharo
implementation.  The moment you modify or extend the pharo image you make a
new pharo implementation.

I don't like the tone Stef is expressing , he is quite rude and definitely
does not represent the tone of the community which far more open to
dialogue but he is correct , GPL would never have worked for Pharo.
Actually I dont think I have seen a language that is fairly popular under a
GPL license.

There is of course software under GPL which is sucessful commercially,
Blender is an example, but GPL does not cover 3d assets, music and sound.
In that case you use another kind of license like creative commons or
heavily modify GPL to extend beyond code. So it was definitely not GPL that
made Blender popular, actually it caused a problem with game developers
because games using the BGE (Blender Game Engine) were at first considered
data because the code was packaged inside the blend file which had a binary
format so that meant it was not covered by GPL because it considered the
whole game code just data (there is a separate executable for loading the
game code)  but then Blender decided to change this also to GPL with
extending its license and that pretty much killed commercial games made
with Blender.

So technically you could get away with GPLing Pharo because you could argue
that Pharo image is merely data that the VM loads and not real source code,
which is kinda correct but it would be messy and the legal interpretation
very confusing and uncertain ( leaves a lot of room for legal
interpretation ) . As a company you cannot risk this , especially while you
expect to make big profit.

As stef said GPL is like a virus, it spread anywhere it touches. Even if
all you do is add a tiny bit of GPL code inside the Pharo image would turn
the entire Pharo implementation including the VM into GPL and because Pharo
tries to approach as many companies as possible as most other languages do
, because money helps improve the popularity and the quality of the code,
MIT is definitely the way to do.

So its more a "have to" than a "must to".

Also double license or not its kinda pointless, the moment something
becomes MIT you can be rest assured that people will pick MIT over GPL.
This because you can turn MIT to GPL but you cannot turn GPL to MIT. So
even if you want your project GPLed , MIT is still more than enough and of
course most people will pick MIT for commercial apps so they don't need to
open source their code.

So no, it does not matter that Spec is double licensed , or if it is legal
that is double licensed , since its active implementation is MIT this all
you need to know.

So for Pharo and pretty much almost all other programming languages out
there who aspire to be used by as many people as possible and play an
active role in the software market MIT like license is a mandatory choice.
The irony of people not wanting to open source their code but wanting to
use open source code. Its this type of thinking that justifies the
existence of GPL.

On Wed, Sep 7, 2016 at 2:59 PM Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> Hi,
>
>
> On 07/09/16 13:39, stepharo wrote:
> >
> >> We should not have "The Pharo Way" (TM) or "No way!"... suddenly
> >> Markus talk about feedback loops comes to mind, particularly the
> >> slide on page 53, regarding "An open source smalltalk ignoring all
> >> community contributions"[2]. This is far for being the case in this
> >> community and we can keep that scenario at safe distance, if we show
> >> options. So, dual license is an option, git is an option, markdown is
> >> an option. Pharo as a place with options is one where Pharo can
> >> fulfill its vision for more people. Let's make these options visible
> >> and figure out the way the work better for a wider community.
> > It is amazing how you like talking.
> >
>
> Yes. I like. Is the way to know unwritten history. Not all the people in
> the community know the details as you do, so talking is the way of going
> out of misconceptions, like mine about dual license or state positions,
> like why I don't use Pillar. The "it has been discussed, this is our
> way, take or leave it" doesn't help in understanding way. So yes, I'm
> all about encouraging dialog/talk if it helps to understand.
>
> Bye,
>
> Offray
>
>

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano  wrote:
> Hi,
>
> sorry for arriving so late to this, but I was on holidays :)
> this is how autoRelease works:
>
> 1) #autoRelease of an object registers object for finalisation with a 
> particular executor. Then behaviour is divided:
>
> 2.1.1) for ExternalAddresses, it just registers in regular way, who will call 
> #finalize on GC
> 2.1.2) finalize will just call a free assuming ExternalAddress was allocated 
> (which is a malloc)
>
> 2.2.1) for all FFIExternalReference, it will register for finalisation what 
> #resourceData answers (normally, the handle of the object)
> 2.2.2) finalisation process will call the object 
> class>>#finalizeResourceData: method, with the #resourceData result as 
> parameter
> 2.2.3) each kind of external reference can decide how to free that data (by 
> default is also just freeing).
>
> An example of this is how CairoFontFace works (or AthensCairoSurface).

At the bottom of FFIExternalResourceExecutor class comment I read...
"Note that in #finalizeResourceData: you cannot
 access any other properties of your instance,
 since it is already garbage collected."

But in my experiments it seems okay to access instance variables in #finalize.
For example...

CXString >> autoRelease
   self class finalizationRegistry add: self

CXString >> finalize
Transcript crShow: 'Finalizing CXString ' ; show: self private_flags.
self dispose.
Transcript show: ', done!'.

CXString >>private_flags
"This method was automatically generated"
^handle unsignedLongAt: 5

Libclang getClangVersion autoRelease.
Smalltalk garbageCollect.
"==> Finalizing CXString 1, done! "

Is this an unlucky coincidence?   Or maybe something changed from NB
to UFFI?  (There is a reference to NB there)
I am wary of believing my results contrary to the comment.  That old
engineering principle "When things work, it may be only reinforcing
your misconceptions."   :)

cheers -ben

> In you case, you will have something like:
>
> FFIExternalObject subclass: #CXString
>
> CXString class>>#finalizeResourceData: version
> self ffiCall: #(void clang_disposeString(void *version))
>
> notice that here I casted to void*… this is because actually resourceData 
> answers a pointer, not the object.
>
> cheers,
> Esteban

[Pharo-users] UFFI documentation state

Hey Esteban hows the documentation for UFFI going ? I will most likely go
down the Memory Mapped File (Shared Memory) for uniting Pharo with Unreal
instead of making a Pharo to C++ compiler since it will be much simpler for
me but I will need the FFI. Is it stable enough both FFI and its
documentation or should I wait more ?

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)


> On 07 Sep 2016, at 14:56, Ben Coman  wrote:
> 
> On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano  > wrote:
>> Hi,
>> 
>> sorry for arriving so late to this, but I was on holidays :)
>> this is how autoRelease works:
>> 
>> 1) #autoRelease of an object registers object for finalisation with a 
>> particular executor. Then behaviour is divided:
>> 
>> 2.1.1) for ExternalAddresses, it just registers in regular way, who will 
>> call #finalize on GC
>> 2.1.2) finalize will just call a free assuming ExternalAddress was allocated 
>> (which is a malloc)
>> 
>> 2.2.1) for all FFIExternalReference, it will register for finalisation what 
>> #resourceData answers (normally, the handle of the object)
>> 2.2.2) finalisation process will call the object 
>> class>>#finalizeResourceData: method, with the #resourceData result as 
>> parameter
>> 2.2.3) each kind of external reference can decide how to free that data (by 
>> default is also just freeing).
>> 
>> An example of this is how CairoFontFace works (or AthensCairoSurface).
> 
> 
> At the bottom of FFIExternalResourceExecutor class comment I read...
>"Note that in #finalizeResourceData: you cannot
> access any other properties of your instance,
> since it is already garbage collected."
> 
> But in my experiments it seems okay to access instance variables in #finalize.
> For example...
> 
> CXString >> autoRelease
>   self class finalizationRegistry add: self
> 
> CXString >> finalize
>Transcript crShow: 'Finalizing CXString ' ; show: self private_flags.
>self dispose.
>Transcript show: ', done!'.
> 
> CXString >>private_flags
>"This method was automatically generated"
>^handle unsignedLongAt: 5
> 
> Libclang getClangVersion autoRelease.
> Smalltalk garbageCollect.
> "==> Finalizing CXString 1, done! "
> 
> 
> Is this an unlucky coincidence?   Or maybe something changed from NB
> to UFFI?  (There is a reference to NB there)

yes, is a coincidence. 
the idea of using #finalizeResourceData: is that you keep minimal information 
(in general, just the handle)… this way we ensure instances will be collected 
because we will not have circular references (preventing the weakregistry to 
work). 

In general, you can always implement as you did it, but I would prefer the 
#finalizeResourceData: approach, even for structures. 
The only reason it is not implemented is because I didn’t reach the necessity, 
then I just skipped it (not in purpose, it was not in my head :P), but now is a 
good moment to implement it… if you want it :)

Esteban

> I am wary of believing my results contrary to the comment.  That old
> engineering principle "When things work, it may be only reinforcing
> your misconceptions."   :)
> 
> cheers -ben
> 
>> In you case, you will have something like:
>> 
>> FFIExternalObject subclass: #CXString
>> 
>> CXString class>>#finalizeResourceData: version
>>self ffiCall: #(void clang_disposeString(void *version))
>> 
>> notice that here I casted to void*… this is because actually resourceData 
>> answers a pointer, not the object.
>> 
>> cheers,
>> Esteban

Re: [Pharo-users] UFFI documentation state

Hi Kilon,

documentation is “ongoing”, but I think the only way I will actually finish it 
is by answering questions from people (I’ve been pasting there the answers I 
give also in the list). So I would ask you to take a look into the doc and make 
all the questions that you want… so I answer, and I will be closer to finish :)

https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/UnifiedFFI/UnifiedFFI.pillar

cheers, 
Esteban

> On 07 Sep 2016, at 15:01, Dimitris Chloupis  wrote:
> 
> Hey Esteban hows the documentation for UFFI going ? I will most likely go 
> down the Memory Mapped File (Shared Memory) for uniting Pharo with Unreal 
> instead of making a Pharo to C++ compiler since it will be much simpler for 
> me but I will need the FFI. Is it stable enough both FFI and its 
> documentation or should I wait more ?

Re: [Pharo-users] UFFI documentation state

perfect I will take look and ask all the questions I need answered and I
can also document my answers since I am familiar with Pillar as a UPBE
contributor. Thanks :)

On Wed, Sep 7, 2016 at 4:13 PM Esteban Lorenzano 
wrote:

> Hi Kilon,
>
> documentation is “ongoing”, but I think the only way I will actually
> finish it is by answering questions from people (I’ve been pasting there
> the answers I give also in the list). So I would ask you to take a look
> into the doc and make all the questions that you want… so I answer, and I
> will be closer to finish :)
>
>
> https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/UnifiedFFI/UnifiedFFI.pillar
>
> cheers,
> Esteban
>
> On 07 Sep 2016, at 15:01, Dimitris Chloupis  wrote:
>
> Hey Esteban hows the documentation for UFFI going ? I will most likely go
> down the Memory Mapped File (Shared Memory) for uniting Pharo with Unreal
> instead of making a Pharo to C++ compiler since it will be much simpler for
> me but I will need the FFI. Is it stable enough both FFI and its
> documentation or should I wait more ?
>
>
>

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

On Wed, Sep 7, 2016 at 9:09 PM, Esteban Lorenzano  wrote:
>
> On 07 Sep 2016, at 14:56, Ben Coman  wrote:
>
> On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano 
> wrote:
>
> Hi,
>
> sorry for arriving so late to this, but I was on holidays :)
> this is how autoRelease works:
>
> 1) #autoRelease of an object registers object for finalisation with a
> particular executor. Then behaviour is divided:
>
> 2.1.1) for ExternalAddresses, it just registers in regular way, who will
> call #finalize on GC
> 2.1.2) finalize will just call a free assuming ExternalAddress was allocated
> (which is a malloc)
>
> 2.2.1) for all FFIExternalReference, it will register for finalisation what
> #resourceData answers (normally, the handle of the object)
> 2.2.2) finalisation process will call the object
> class>>#finalizeResourceData: method, with the #resourceData result as
> parameter
> 2.2.3) each kind of external reference can decide how to free that data (by
> default is also just freeing).
>
> An example of this is how CairoFontFace works (or AthensCairoSurface).
>
>
>
> At the bottom of FFIExternalResourceExecutor class comment I read...
>"Note that in #finalizeResourceData: you cannot
> access any other properties of your instance,
> since it is already garbage collected."
>
> But in my experiments it seems okay to access instance variables in
> #finalize.
> For example...
>
> CXString >> autoRelease
>   self class finalizationRegistry add: self
>
> CXString >> finalize
>Transcript crShow: 'Finalizing CXString ' ; show: self private_flags.
>self dispose.
>Transcript show: ', done!'.
>
> CXString >>private_flags
>"This method was automatically generated"
>^handle unsignedLongAt: 5
>
> Libclang getClangVersion autoRelease.
> Smalltalk garbageCollect.
> "==> Finalizing CXString 1, done! "
>
>
> Is this an unlucky coincidence?   Or maybe something changed from NB
> to UFFI?  (There is a reference to NB there)
>
>
> yes, is a coincidence.
> the idea of using #finalizeResourceData: is that you keep minimal
> information (in general, just the handle)… this way we ensure instances will
> be collected because we will not have circular references (preventing the
> weakregistry to work).
>
> In general, you can always implement as you did it, but I would prefer the
> #finalizeResourceData: approach, even for structures.
> The only reason it is not implemented is because I didn’t reach the
> necessity, then I just skipped it (not in purpose, it was not in my head
> :P), but now is a good moment to implement it… if you want it :)

Thanks for the offer, but hold off for the moment.  I think I actually
need more than just finalization session management.  To get a real
displayable string requires calling the clang_getCString() library
function.  I imagine I'd like to call this from  CXString>>printOn: --
but this of course this would break after restarting the image.

extern "C" {
const char *clang_getCString(CXString string) {
   
   return static_cast(string.data);
}}

typedef struct {
  const void *data;
  unsigned private_flags;
} CXString;

So I think I need to register CXString with SessionManager to set *data <-- 0
on startup.

An alternative might be adding a session variable to CXString,
FFIExternalStructure subclass: #CXString
instanceVariableNames: 'session'
classVariableNames: ''
poolDictionaries: 'CXStringFlag'
package: 'Libclang'

except doing so crashes when calling
getClangVersion
   ^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang

cheers -ben

[Pharo-users] Spur problem?

2016-09-07 Thread Usman Bhatti

Hi,

While working on a Pharo 5 image for 3-4 hours, I got an image crash and I
was no more able to start the image from the UI interface. When starting
the image from the command line I got the following error:

Pharo(50871,0xa02c91a8) malloc: *** error for object 0x1af7a04: incorrect
checksum for freed object - object was probably modified after being freed.

*** set a breakpoint in malloc_error_break to debug

fish: '/Users/ubhatti/temp/vm-spur/Pha…' terminated by signal SIGBUS
(Misaligned address error).

The image is about 973 Mb (Moose + seaside + a model for a big industrial
software). This message might not go beyond reporting an error that I do
not know how to produce neither can I share the image (it contains client
proprietary software model and hence we are restricted).

Just to let you know that there was a problem and n ask if someone has
encountered it before?


regards.

Usman

Re: [Pharo-users] Planning: Pharo Sprints Lille for the rest 2016

2016-09-07 Thread Marcus Denker


> On 07 Sep 2016, at 13:05, Marcus Denker  wrote:
> 
> Hi
> 
> Here locally we try to organise one “Sprint” per month were we meet to work 
> on 
> boring issue tracker entries together. (external visitors are welcome!)
> 
> In the past people organised local sprints at other places at the sane time 
> (e.g. Santiago/Chile).
> 
> The next dates are:
> 
> 30 September
> 28 October
This has been moved to 4th November due to holidays

> 25 November
> 16 December. Pharo Christmas Party!
> 
> 
>   Marcus
>

Re: [Pharo-users] Spec: InputWidget question

Hi Brad,

the magic of the OK and Cancel buttons is due to the opening of the UI with 
openDialogWithSpec (instead of openWithSpec).

There is info on that in the Spec documentation, in the ‘Managing Windows’ 
chapter (which I finished last week :-) ). You can find a pdf of that chapter 
here: 
https://ci.inria.fr/pharo-contribution/view/Books/job/BuildingUIWithSpec/lastSuccessfulBuild/artifact/book-result/ManagingWindow/ManagingWindow.pdf

HTH
--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please 
see http://emailcharter.org .

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

> On Sep 6, 2016, at 18:14, Brad Selfridge  wrote:
> 
> I've been trying for several days to get the Spec InputWidget to work as
> expected. I've been running the "example2" example.  If you enter text in
> the input field and press the "enter" key, then the input text is returned.
> But, if you click the "Ok" button rather than "enter" key, then the input
> text field is empty. I've tried to dig into why, but I stymied. 
> 
> Can someone please help me with this? 
> 
> 
> 
> -
> Brad Selfridge
> --
> View this message in context: 
> http://forum.world.st/Spec-InputWidget-question-tp4914439.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 
>

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

On Wed, Sep 7, 2016 at 10:42 PM, Ben Coman  wrote:
> On Wed, Sep 7, 2016 at 9:09 PM, Esteban Lorenzano  wrote:
>>
>> On 07 Sep 2016, at 14:56, Ben Coman  wrote:
>>
>> On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano 
>> wrote:
>>
>> Hi,
>>
>> sorry for arriving so late to this, but I was on holidays :)
>> this is how autoRelease works:
>>
>> 1) #autoRelease of an object registers object for finalisation with a
>> particular executor. Then behaviour is divided:
>>
>> 2.1.1) for ExternalAddresses, it just registers in regular way, who will
>> call #finalize on GC
>> 2.1.2) finalize will just call a free assuming ExternalAddress was allocated
>> (which is a malloc)
>>
>> 2.2.1) for all FFIExternalReference, it will register for finalisation what
>> #resourceData answers (normally, the handle of the object)
>> 2.2.2) finalisation process will call the object
>> class>>#finalizeResourceData: method, with the #resourceData result as
>> parameter
>> 2.2.3) each kind of external reference can decide how to free that data (by
>> default is also just freeing).
>>
>> An example of this is how CairoFontFace works (or AthensCairoSurface).
>>
>>
>>
>> At the bottom of FFIExternalResourceExecutor class comment I read...
>>"Note that in #finalizeResourceData: you cannot
>> access any other properties of your instance,
>> since it is already garbage collected."
>>
>> But in my experiments it seems okay to access instance variables in
>> #finalize.
>> For example...
>>
>> CXString >> autoRelease
>>   self class finalizationRegistry add: self
>>
>> CXString >> finalize
>>Transcript crShow: 'Finalizing CXString ' ; show: self private_flags.
>>self dispose.
>>Transcript show: ', done!'.
>>
>> CXString >>private_flags
>>"This method was automatically generated"
>>^handle unsignedLongAt: 5
>>
>> Libclang getClangVersion autoRelease.
>> Smalltalk garbageCollect.
>> "==> Finalizing CXString 1, done! "
>>
>>
>> Is this an unlucky coincidence?   Or maybe something changed from NB
>> to UFFI?  (There is a reference to NB there)
>>
>>
>> yes, is a coincidence.
>> the idea of using #finalizeResourceData: is that you keep minimal
>> information (in general, just the handle)… this way we ensure instances will
>> be collected because we will not have circular references (preventing the
>> weakregistry to work).
>>
>> In general, you can always implement as you did it, but I would prefer the
>> #finalizeResourceData: approach, even for structures.
>> The only reason it is not implemented is because I didn’t reach the
>> necessity, then I just skipped it (not in purpose, it was not in my head
>> :P), but now is a good moment to implement it… if you want it :)
>
> Thanks for the offer, but hold off for the moment.  I think I actually
> need more than just finalization session management.  To get a real
> displayable string requires calling the clang_getCString() library
> function.  I imagine I'd like to call this from  CXString>>printOn: --
> but this of course this would break after restarting the image.
>
> extern "C" {
> const char *clang_getCString(CXString string) {
>
>return static_cast(string.data);
> }}
>
> typedef struct {
>   const void *data;
>   unsigned private_flags;
> } CXString;
>
> So I think I need to register CXString with SessionManager to set *data <-- 0
> on startup.
>
> An alternative might be adding a session variable to CXString,
> FFIExternalStructure subclass: #CXString
> instanceVariableNames: 'session'
> classVariableNames: ''
> poolDictionaries: 'CXStringFlag'
> package: 'Libclang'
>
> except doing so crashes when calling
> getClangVersion
>^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang

So this worked...

  CXString >> resetData
  handle unsignedLongAt: 1 put: 0.

  CXString class >> startUp: resuming
  resuming
  ifTrue: [ self allInstances do: [ :cxs | cxs resetData ] ].

  CXString class >> initialize
  "self initialize"
  SessionManager default registerSystemClassNamed: self name


Now immediate after a save/restart, doing...
CXString allInstances first getString   "==> UndefinedObject(nil)"
instead of crashing the VM.

Can you see/guess any traps hidden from me? Now I wonder early it is
practical to prioritise such a reset.  My first thought is at least
before #printString starts getting called ??

cheers -ben

Re: [Pharo-users] [Pharo-dev] Planning: Pharo Sprints Lille for the rest 2016

I feel experienced enough to join you this time, hope you do slack channel
communication because I wont be able to physical attend but I will be
available online. I am mostly interested in working on GUI things.

On Wed, Sep 7, 2016 at 6:01 PM Marcus Denker  wrote:

>
> > On 07 Sep 2016, at 13:05, Marcus Denker  wrote:
> >
> > Hi
> >
> > Here locally we try to organise one “Sprint” per month were we meet to
> work on
> > boring issue tracker entries together. (external visitors are welcome!)
> >
> > In the past people organised local sprints at other places at the sane
> time (e.g. Santiago/Chile).
> >
> > The next dates are:
> >
> > 30 September
> > 28 October
> This has been moved to 4th November due to holidays
>
> > 25 November
> > 16 December. Pharo Christmas Party!
> >
> >
> >   Marcus
> >
>
>
>

Re: [Pharo-users] UFFI documentation state

On Wed, Sep 7, 2016 at 9:12 PM, Esteban Lorenzano  wrote:
> Hi Kilon,
>
> documentation is “ongoing”, but I think the only way I will actually finish
> it is by answering questions from people (I’ve been pasting there the
> answers I give also in the list). So I would ask you to take a look into the
> doc and make all the questions that you want… so I answer, and I will be
> closer to finish :)
>
> https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/UnifiedFFI/UnifiedFFI.pillar

That doc is certainly off to a good start.  Its what I was using ...
enough to get me far enough along to start asking questions :P
cheers -ben

>
> cheers,
> Esteban
>
> On 07 Sep 2016, at 15:01, Dimitris Chloupis  wrote:
>
> Hey Esteban hows the documentation for UFFI going ? I will most likely go
> down the Memory Mapped File (Shared Memory) for uniting Pharo with Unreal
> instead of making a Pharo to C++ compiler since it will be much simpler for
> me but I will need the FFI. Is it stable enough both FFI and its
> documentation or should I wait more ?
>
>

Re: [Pharo-users] Spur problem?

2016-09-07 Thread Clément Bera

Hi,

I've never seen that error before. That looks interesting.

You need to provide more information. For example the backtrace or
something written in PharoDebug.log.

Else, as suggested, set a breakpoint in malloc_error_break and try to
figure out what is going on.

On Wed, Sep 7, 2016 at 4:56 PM, Usman Bhatti  wrote:

> Hi,
>
> While working on a Pharo 5 image for 3-4 hours, I got an image crash and I
> was no more able to start the image from the UI interface. When starting
> the image from the command line I got the following error:
>
> Pharo(50871,0xa02c91a8) malloc: *** error for object 0x1af7a04: incorrect
> checksum for freed object - object was probably modified after being freed.
>
> *** set a breakpoint in malloc_error_break to debug
>
> fish: '/Users/ubhatti/temp/vm-spur/Pha…' terminated by signal SIGBUS
> (Misaligned address error).
>
> The image is about 973 Mb (Moose + seaside + a model for a big industrial
> software). This message might not go beyond reporting an error that I do
> not know how to produce neither can I share the image (it contains client
> proprietary software model and hence we are restricted).
>
> Just to let you know that there was a problem and n ask if someone has
> encountered it before?
>
>
> regards.
>
> Usman
>

Re: [Pharo-users] UFFI documentation state

Yeap I agree, I have taken a look into documentation in the past when we
discussed how similar is UFFI to Nativeboost, my only concern is whether
things are about to change and what I learn becomes invalidated after a
while which can be quite annoying . When I was playing with Nativeboost and
NBOpenGL Igor was so patient and nice with my 1 million questions :D

Community support is 50% why I stick with Pharo and considering making
professional games with it together with Unreal. Nothing beats the help of
a real person ;)

On Wed, Sep 7, 2016 at 6:45 PM Ben Coman  wrote:

> On Wed, Sep 7, 2016 at 9:12 PM, Esteban Lorenzano 
> wrote:
> > Hi Kilon,
> >
> > documentation is “ongoing”, but I think the only way I will actually
> finish
> > it is by answering questions from people (I’ve been pasting there the
> > answers I give also in the list). So I would ask you to take a look into
> the
> > doc and make all the questions that you want… so I answer, and I will be
> > closer to finish :)
> >
> >
> https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/UnifiedFFI/UnifiedFFI.pillar
>
> That doc is certainly off to a good start.  Its what I was using ...
> enough to get me far enough along to start asking questions :P
> cheers -ben
>
> >
> > cheers,
> > Esteban
> >
> > On 07 Sep 2016, at 15:01, Dimitris Chloupis 
> wrote:
> >
> > Hey Esteban hows the documentation for UFFI going ? I will most likely go
> > down the Memory Mapped File (Shared Memory) for uniting Pharo with Unreal
> > instead of making a Pharo to C++ compiler since it will be much simpler
> for
> > me but I will need the FFI. Is it stable enough both FFI and its
> > documentation or should I wait more ?
> >
> >
>
>

Re: [Pharo-users] [ANN] Territorial

but as everything we do, it has some impact :)

Hi,

Please let me stress this: you can put the license of your choice to your code.
Is your right and we ensured it continues being your right by choosing MIT
license for Pharo.
That means that all frameworks, apps, etc. that runs on Pharo has to be MIT?
No! YOU CAN DECIDE.

But then, if it is not MIT, your code will not be considered for inclusion,
just that (but many times you do not have that in mind, so who cares).
In my own case, if is not MIT (or some permissive license like BSD, Apache,
etc.) I will not even look inside it… why? because I do not want to be
“infected”: I do not want to have the risk of copying (even innocently) some
copyrighted ideas. You do not know the mess that was rewrite entire parts of
Pharo to be able to release it…
So, in the case of contributions to Pharo, yes… is “our way” (which is not a
personal statement, is how this community choose to work).

Anyway… of course you can always put the license you want to your code (and
that applies to Territorial too).

cheers,
Esteban

ps: and please forgive Stef for being harsh on this… the Spec affaire was
painful for us, we do not like to put lawyers and that kind of thing in play…

On 07 Sep 2016, at 14:08, stepharo wrote:

Le 7/9/16 à 13:58, Offray Vladimir Luna Cárdenas a écrit :

Hi,

On 07/09/16 13:39, stepharo wrote:

We should not have "The Pharo Way" (TM) or "No way!"... suddenly Markus talk about
feedback loops comes to mind, particularly the slide on page 53, regarding "An open source smalltalk
ignoring all community contributions"[2]. This is far for being the case in this community and we can
keep that scenario at safe distance, if we show options. So, dual license is an option, git is an option,
markdown is an option. Pharo as a place with options is one where Pharo can fulfill its vision for more
people. Let's make these options visible and figure out the way the work better for a wider community.

It is amazing how you like talking.

Yes. I like. Is the way to know unwritten history. Not all the people in the community
know the details as you do, so talking is the way of going out of misconceptions, like
mine about dual license or state positions, like why I don't use Pillar. The "it has
been discussed, this is our way, take or leave it" doesn't help in understanding
way. So yes, I'm all about encouraging dialog/talk if it helps to understand.

this is why I added the comment on the pharo contribution page.

Bye,

Offray

Re: [Pharo-users] [ANN] Territorial

Yes Peter. I may sound rude but I spent hours, mails in the past for 
example just to have a booth in a conference


to promote squeak and this just because of licensing problems.

So everybody can do whatever it wants but there is a cost and effect 
associated with it.


Now the argument of oh yes this is good we can have choice is a 
non-argument and it is not profitable in the long term.


Stef


Le 7/9/16 à 14:08, PBKResearch a écrit :

Stef
> We should not have "The Pharo Way" (TM) or "No way!"... suddenly
> Markus talk about feedback loops comes to mind, particularly the slide
> on page 53, regarding "An open source smalltalk ignoring all community
> contributions"[2]. This is far for being the case in this community
> and we can keep that scenario at safe distance, if we show options.
> So, dual license is an option, git is an option, markdown is an
> option. Pharo as a place with options is one where Pharo can fulfill
> its vision for more people. Let's make these options visible and
> figure out the way the work better for a wider community.
It is amazing how you like talking.

We can argue and disagree, but let's do it politely. This is just downright 
rude, and quite unnecessary.

Peter Kenny

Re: [Pharo-users] [ANN] Territorial

About my tone may I ask a question? Yes sometimes I feel irritated. I'm 
human and I feel irritated.


May be you know the trick that some smart manager use to control the 
length of meetings...


I experienced in our team in the past meetings with 18 people and one 
guy was always talking a lot more than others. And I was always asking 
myself: does it have conscience that each minute he is taking is in fact 
18 min because we could all spend 1 min doing something else.


After that I heard about team that have strange clock where the clock is 
multiplying by the amount of participants.


So when I participate to meetings I always think about what is the value 
that I bring to other time.


Now we are all busy, you see some people in our team and outside told me 
that they do not have the time to follow Pharo mailing-lists because 
there are too many emails. And we all lose because the insights of such 
people could be really great.


So some alternatives:

- do not care do not read the pharo mailing-list, I would not feel 
happy with such solution.


- be forced to react when something wrong is said because this is 
important for everybody. And yes sometimes I'm irritated because I feel 
forced to say something.I have the impression that not saying anything 
is a kind of luxury that I do not have.


- have a closed contributors only mailing-list (not good does not 
feel nice).



This license point is key and this is why I reacted. And I reacted that 
way because I CARE about our system and I CARE about our communitee.


Out there, there is Java, Lua, Python, Ruby, Swift, Objective-C and many 
more. So we should pay attention to our ecosystem and the license


is an integral part of it.

So sorry to be rude but I'm ***REALLY*** busy. Much more than you can 
imagine. Even more. And I feel responsible.



Stef



Le 7/9/16 à 14:40, Dimitris Chloupis a écrit :
Ironically enough "this is our way , take it or leave it" would not 
work for Pharo because its smalltalk and basically smalltalk by 
architecture allow you to deeply modify the system from the get go.


This make Pharo technically impossible to control from a dictator and 
committee point of view like lets say Python or Linux. CPython is a 
single implementation , but with pharo every pharo app is essentially 
a new pharo implementation.  The moment you modify or extend the pharo 
image you make a new pharo implementation.


I don't like the tone Stef is expressing , he is quite rude and 
definitely does not represent the tone of the community which far more 
open to dialogue but he is correct , GPL would never have worked for 
Pharo. Actually I dont think I have seen a language that is fairly 
popular under a GPL license.


There is of course software under GPL which is sucessful commercially, 
Blender is an example, but GPL does not cover 3d assets, music and 
sound. In that case you use another kind of license like creative 
commons or heavily modify GPL to extend beyond code. So it was 
definitely not GPL that made Blender popular, actually it caused a 
problem with game developers because games using the BGE (Blender Game 
Engine) were at first considered data because the code was packaged 
inside the blend file which had a binary format so that meant it was 
not covered by GPL because it considered the whole game code just data 
(there is a separate executable for loading the game code)  but then 
Blender decided to change this also to GPL with extending its license 
and that pretty much killed commercial games made with Blender.


So technically you could get away with GPLing Pharo because you could 
argue that Pharo image is merely data that the VM loads and not real 
source code, which is kinda correct but it would be messy and the 
legal interpretation very confusing and uncertain ( leaves a lot of 
room for legal interpretation ) . As a company you cannot risk this , 
especially while you expect to make big profit.


As stef said GPL is like a virus, it spread anywhere it touches. Even 
if all you do is add a tiny bit of GPL code inside the Pharo image 
would turn the entire Pharo implementation including the VM into GPL 
and because Pharo tries to approach as many companies as possible as 
most other languages do , because money helps improve the popularity 
and the quality of the code, MIT is definitely the way to do.


So its more a "have to" than a "must to".

Also double license or not its kinda pointless, the moment something 
becomes MIT you can be rest assured that people will pick MIT over 
GPL. This because you can turn MIT to GPL but you cannot turn GPL to 
MIT. So even if you want your project GPLed , MIT is still more than 
enough and of course most people will pick MIT for commercial apps so 
they don't need to open source their code.


So no, it does not matter that Spec is double licensed , or if it is 
legal that is double licensed , since its active implementation is MIT 
this all you need to know.


So for Ph

Re: [Pharo-users] difficult to kill objects - pesky hanging pointersTo


And wht I learned is that we should do


ClassOfObjectsThatMustDie allInstances first become: nil
but really String new.

Le 6/9/16 à 02:22, Ben Coman a écrit :

Ohhh... nice... shiny...

That is much easier to remember.  Thanks Andres.

cheers -ben

On Tue, Sep 6, 2016 at 5:21 AM, Andres Valloud
 wrote:

So why doesn't two-way become: help, e.g.

ClassOfObjectsThatMustDie allInstances first become: String new

As soon as that do-it unwinds there won't be any references to what the new
string became (the new string wasn't referenced further), so...


On 9/5/16 8:50 , Ben Coman wrote:

Sometimes its *really* hard to kill some objects.  It seems that
inspecting a list of pointersTo creates additional hanging references.
This was frustrating me just now, so I finally hacked a way forward.
Sharing it in case its useful to others, and also I can find it again
searching the list.  This needs to run for each object.

Smalltalk garbageCollect.
target := ClassOfObjectsThatMustDie allInstances first.
SystemNavigation default allObjectsDo: [ :e |
(e isKindOf: Association) ifTrue: [ e value = target ifTrue: [ e
value: nil ] ].
(e isKindOf: Array) ifTrue: [ 1 to: e size do: [ :i | (e at: i) =
target ifTrue: [ e at: i put: nil ] ] ]
].
target := nil.
Smalltalk garbageCollect.

cheers -ben

Re: [Pharo-users] [ANN] Territorial

2016-09-07 Thread p...@highoctane.be

Yes, MIT is a key reason Pharo makes sense to use for me.

I can embed it in what I want, no issues.

Phil

On Wed, Sep 7, 2016 at 7:45 PM, stepharo  wrote:

> About my tone may I ask a question? Yes sometimes I feel irritated. I'm
> human and I feel irritated.
>
> May be you know the trick that some smart manager use to control the
> length of meetings...
>
> I experienced in our team in the past meetings with 18 people and one guy
> was always talking a lot more than others. And I was always asking myself:
> does it have conscience that each minute he is taking is in fact 18 min
> because we could all spend 1 min doing something else.
>
> After that I heard about team that have strange clock where the clock is
> multiplying by the amount of participants.
>
> So when I participate to meetings I always think about what is the value
> that I bring to other time.
>
> Now we are all busy, you see some people in our team and outside told me
> that they do not have the time to follow Pharo mailing-lists because there
> are too many emails. And we all lose because the insights of such people
> could be really great.
>
> So some alternatives:
>
> - do not care do not read the pharo mailing-list, I would not feel
> happy with such solution.
>
> - be forced to react when something wrong is said because this is
> important for everybody. And yes sometimes I'm irritated because I feel
> forced to say something.I have the impression that not saying anything is a
> kind of luxury that I do not have.
>
> - have a closed contributors only mailing-list (not good does not feel
> nice).
>
>
> This license point is key and this is why I reacted. And I reacted that
> way because I CARE about our system and I CARE about our communitee.
>
> Out there, there is Java, Lua, Python, Ruby, Swift, Objective-C and many
> more. So we should pay attention to our ecosystem and the license
>
> is an integral part of it.
>
> So sorry to be rude but I'm ***REALLY*** busy. Much more than you can
> imagine. Even more. And I feel responsible.
>
>
> Stef
>
>
>
> Le 7/9/16 à 14:40, Dimitris Chloupis a écrit :
>
> Ironically enough "this is our way , take it or leave it" would not work
> for Pharo because its smalltalk and basically smalltalk by architecture
> allow you to deeply modify the system from the get go.
>
> This make Pharo technically impossible to control from a dictator and
> committee point of view like lets say Python or Linux. CPython is a single
> implementation , but with pharo every pharo app is essentially a new pharo
> implementation.  The moment you modify or extend the pharo image you make a
> new pharo implementation.
>
> I don't like the tone Stef is expressing , he is quite rude and definitely
> does not represent the tone of the community which far more open to
> dialogue but he is correct , GPL would never have worked for Pharo.
> Actually I dont think I have seen a language that is fairly popular under a
> GPL license.
>
> There is of course software under GPL which is sucessful commercially,
> Blender is an example, but GPL does not cover 3d assets, music and sound.
> In that case you use another kind of license like creative commons or
> heavily modify GPL to extend beyond code. So it was definitely not GPL that
> made Blender popular, actually it caused a problem with game developers
> because games using the BGE (Blender Game Engine) were at first considered
> data because the code was packaged inside the blend file which had a binary
> format so that meant it was not covered by GPL because it considered the
> whole game code just data (there is a separate executable for loading the
> game code)  but then Blender decided to change this also to GPL with
> extending its license and that pretty much killed commercial games made
> with Blender.
>
> So technically you could get away with GPLing Pharo because you could
> argue that Pharo image is merely data that the VM loads and not real source
> code, which is kinda correct but it would be messy and the legal
> interpretation very confusing and uncertain ( leaves a lot of room for
> legal interpretation ) . As a company you cannot risk this , especially
> while you expect to make big profit.
>
> As stef said GPL is like a virus, it spread anywhere it touches. Even if
> all you do is add a tiny bit of GPL code inside the Pharo image would turn
> the entire Pharo implementation including the VM into GPL and because Pharo
> tries to approach as many companies as possible as most other languages do
> , because money helps improve the popularity and the quality of the code,
> MIT is definitely the way to do.
>
> So its more a "have to" than a "must to".
>
> Also double license or not its kinda pointless, the moment something
> becomes MIT you can be rest assured that people will pick MIT over GPL.
> This because you can turn MIT to GPL but you cannot turn GPL to MIT. So
> even if you want your project GPLed , MIT is still more than enough and of
> course most p

Re: [Pharo-users] [ANN] Territorial

Personally I dont mind you being rude to me, I am a lawyer , by profession
I am thick skinned. Busy ? being there done that. And we all snap from time
to time and I agree doing is usually more than important that talking , but
, there is always a BUT.

In any case I dont want to drag the issue its just I care for Pharo maybe
not much as you do since I have not invested as much as you have but I do
think talking is also important it helps people get more confident in being
part of a community , this in term can lead to motivation to being active
contributors. When I joined Pharo community I got a lot of encouragement
from people here for my efforts , it may be talk, but emotionally is very
important to know that people appreciate your work and respect you as a
person.

A small advise from a person that happens to see what having too many
responsibilities can do to a person, take care yourself because the effects
of overworking are not immediate , it will get much worse down the road
unless you make yourself a priority.

On Wed, Sep 7, 2016 at 8:46 PM stepharo  wrote:

> About my tone may I ask a question? Yes sometimes I feel irritated. I'm
> human and I feel irritated.
>
> May be you know the trick that some smart manager use to control the
> length of meetings...
>
> I experienced in our team in the past meetings with 18 people and one guy
> was always talking a lot more than others. And I was always asking myself:
> does it have conscience that each minute he is taking is in fact 18 min
> because we could all spend 1 min doing something else.
>
> After that I heard about team that have strange clock where the clock is
> multiplying by the amount of participants.
>
> So when I participate to meetings I always think about what is the value
> that I bring to other time.
>
> Now we are all busy, you see some people in our team and outside told me
> that they do not have the time to follow Pharo mailing-lists because there
> are too many emails. And we all lose because the insights of such people
> could be really great.
>
> So some alternatives:
>
> - do not care do not read the pharo mailing-list, I would not feel
> happy with such solution.
>
> - be forced to react when something wrong is said because this is
> important for everybody. And yes sometimes I'm irritated because I feel
> forced to say something.I have the impression that not saying anything is a
> kind of luxury that I do not have.
>
> - have a closed contributors only mailing-list (not good does not feel
> nice).
>
>
> This license point is key and this is why I reacted. And I reacted that
> way because I CARE about our system and I CARE about our communitee.
>
> Out there, there is Java, Lua, Python, Ruby, Swift, Objective-C and many
> more. So we should pay attention to our ecosystem and the license
>
> is an integral part of it.
>
> So sorry to be rude but I'm ***REALLY*** busy. Much more than you can
> imagine. Even more. And I feel responsible.
>
>
> Stef
>
>
>
> Le 7/9/16 à 14:40, Dimitris Chloupis a écrit :
>
> Ironically enough "this is our way , take it or leave it" would not work
> for Pharo because its smalltalk and basically smalltalk by architecture
> allow you to deeply modify the system from the get go.
>
> This make Pharo technically impossible to control from a dictator and
> committee point of view like lets say Python or Linux. CPython is a single
> implementation , but with pharo every pharo app is essentially a new pharo
> implementation.  The moment you modify or extend the pharo image you make a
> new pharo implementation.
>
> I don't like the tone Stef is expressing , he is quite rude and definitely
> does not represent the tone of the community which far more open to
> dialogue but he is correct , GPL would never have worked for Pharo.
> Actually I dont think I have seen a language that is fairly popular under a
> GPL license.
>
> There is of course software under GPL which is sucessful commercially,
> Blender is an example, but GPL does not cover 3d assets, music and sound.
> In that case you use another kind of license like creative commons or
> heavily modify GPL to extend beyond code. So it was definitely not GPL that
> made Blender popular, actually it caused a problem with game developers
> because games using the BGE (Blender Game Engine) were at first considered
> data because the code was packaged inside the blend file which had a binary
> format so that meant it was not covered by GPL because it considered the
> whole game code just data (there is a separate executable for loading the
> game code)  but then Blender decided to change this also to GPL with
> extending its license and that pretty much killed commercial games made
> with Blender.
>
> So technically you could get away with GPLing Pharo because you could
> argue that Pharo image is merely data that the VM loads and not real source
> code, which is kinda correct but it would be messy and the legal
> interpretation very confusing and unc

Re: [Pharo-users] [ANN] Territorial


Hi,


On 07/09/16 14:37, Esteban Lorenzano wrote:


ps: and please forgive Stef for being harsh on this… the Spec affaire was 
painful for us, we do not like to put lawyers and that kind of thing in play…


Fortunately there is people in community, like you, that do care about 
Pharo, is busy and stressed, but don't use this as a eternal excuse to 
go after every person that doesn't share his views or know "the 
history". Diversity is healthy in a community. Thanks for being here.


Cheers,

Offray

Re: [Pharo-users] Spec: InputWidget question

2016-09-07 Thread Brad Selfridge

Read the chapter. Being new to Spec, I'm still confused because I don't see
clear evidence in the chapter that would fix the problems that are occurring
in the InputWidget. 

I did, however, read your documentation referring to the TextFieldInputModel
example. After reading that, I created a TextPrompterWidget, (which is a
direct copy of InputWidget). I changed the super class to
DynamicComposableModel. I modified the "initializeWidgets" method, removed
the "OK" method, and made a few other small modifications and got the widget
to work as expected. I DID have to open the widget with "openDialogWithSpec"
as that was the only way to auto-magically get the OK-Cancel toolbar widget.
I'd share my code if you want. 



-
Brad Selfridge
--
View this message in context: 
http://forum.world.st/Spec-InputWidget-question-tp4914439p4914673.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Lint Rule for Class-Side Method

2016-09-07 Thread Sean P. DeNigris

Uko2 wrote
> What are you using to obtain critiques?

CriticBrowser



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Lint-Rule-for-Class-Side-Method-tp4914121p4914674.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Spec: InputWidget question

Apologies for not being clear in my mail. The key is that the UI is being 
opened as a dialog box, generating the OK and Cancel buttons. All this logic is 
explained in the section "Opening a dialog box and its configuration options”. 
This also talks about configuring what to do when these buttons are clicked.


--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please 
see http://emailcharter.org .

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

> On Sep 7, 2016, at 18:07, Brad Selfridge  wrote:
> 
> Read the chapter. Being new to Spec, I'm still confused because I don't see
> clear evidence in the chapter that would fix the problems that are occurring
> in the InputWidget. 
> 
> I did, however, read your documentation referring to the TextFieldInputModel
> example. After reading that, I created a TextPrompterWidget, (which is a
> direct copy of InputWidget). I changed the super class to
> DynamicComposableModel. I modified the "initializeWidgets" method, removed
> the "OK" method, and made a few other small modifications and got the widget
> to work as expected. I DID have to open the widget with "openDialogWithSpec"
> as that was the only way to auto-magically get the OK-Cancel toolbar widget.
> I'd share my code if you want. 
> 
> 
> 
> -
> Brad Selfridge
> --
> View this message in context: 
> http://forum.world.st/Spec-InputWidget-question-tp4914439p4914673.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 
>

[Pharo-users] SpecBooklet: Strange behavior of ProtocolBrowser

2016-09-07 Thread Matteo via Pharo-users

--- Begin Message ---
Hi,
I'm playing with the ProtocolBrowser class, as coded in the
"SpecBooklet.pdf" document (release of the 3rd August 2016).
I'm using Pharo 5.

I'm experiencing a strange behavior of the  ProtocolBrowser instance:
-if I open a ProtocolBrowser instance, and I click on a "api"   item, I
do not get any code in the text pane.
-If I open another ProtocolBrowser instance then I do not see any code,
even in the "api" protocol than the "api-events" one.
-If I open a further instance then the widget works correctly, showing
the "api" or "api-events" code in the text pane.

Please note that the ProtocolBrowser is instantiated as follow:
(ProtocolBrowsernew)  openWithSpec

Could my Pharo image be faulty?
Is there some problem with ProtocolBrowser>>initializePresenter?

Thanks,
Matteo Bellotto


--- End Message ---

Re: [Pharo-users] Lint Rule for Class-Side Method

2016-09-07 Thread Yuriy Tymchuk


> On 07 Sep 2016, at 23:41, Sean P. DeNigris  wrote:
> 
> Uko2 wrote
>> What are you using to obtain critiques?
> 
> CriticBrowser

Ok, can you also, please, clarify which version of Pharo are you using?

> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Lint-Rule-for-Class-Side-Method-tp4914121p4914674.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

Re: [Pharo-users] SpecBooklet: Strange behavior of ProtocolBrowser

Hello Matteo,

are you using the ProtocolBrowser class that comes default with Pharo 5? (In 
the Spec-Examples package). This is different from what is in the booklet, the 
code in Pharo 5 is not up to date. For now, you should define a new protocol 
browser class (MyProtocolBrowser for example) and the other classes that are in 
that section. Sorry for that...

--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please 
see http://emailcharter.org  .

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

> On Sep 7, 2016, at 18:57, Matteo via Pharo-users 
>  wrote:
> 
> 
> From: Matteo 
> Subject: SpecBooklet: Strange behavior of ProtocolBrowser
> Date: September 7, 2016 at 18:56:08 GMT-3
> To: pharo-users@lists.pharo.org
> 
> 
> Hi,
> I'm playing with the ProtocolBrowser class, as coded in the
> "SpecBooklet.pdf" document (release of the 3rd August 2016).
> I'm using Pharo 5.
> 
> I'm experiencing a strange behavior of the  ProtocolBrowser instance:
>   -if I open a ProtocolBrowser instance, and I click on a "api"   item, I
> do not get any code in the text pane.
>   -If I open another ProtocolBrowser instance then I do not see any code,
> even in the "api" protocol than the "api-events" one.
>   -If I open a further instance then the widget works correctly, showing
> the "api" or "api-events" code in the text pane.
> 
> Please note that the ProtocolBrowser is instantiated as follow:
>   (ProtocolBrowsernew)  openWithSpec
> 
> Could my Pharo image be faulty?
> Is there some problem with ProtocolBrowser>>initializePresenter?
> 
> Thanks,
> Matteo Bellotto
> 
> 
> 
> 
>

Re: [Pharo-users] [ANN] Territorial

2016-09-07 Thread p...@highoctane.be

Stef latching. Known thing. Get over it. Just happens. Grow a thicker skin.

And s///g

Phil

On Wed, Sep 7, 2016 at 9:44 PM, Dimitris Chloupis 
wrote:

> Personally I dont mind you being rude to me, I am a lawyer , by profession
> I am thick skinned. Busy ? being there done that. And we all snap from time
> to time and I agree doing is usually more than important that talking , but
> , there is always a BUT.
>
> In any case I dont want to drag the issue its just I care for Pharo maybe
> not much as you do since I have not invested as much as you have but I do
> think talking is also important it helps people get more confident in being
> part of a community , this in term can lead to motivation to being active
> contributors. When I joined Pharo community I got a lot of encouragement
> from people here for my efforts , it may be talk, but emotionally is very
> important to know that people appreciate your work and respect you as a
> person.
>
> A small advise from a person that happens to see what having too many
> responsibilities can do to a person, take care yourself because the effects
> of overworking are not immediate , it will get much worse down the road
> unless you make yourself a priority.
>
> On Wed, Sep 7, 2016 at 8:46 PM stepharo  wrote:
>
>> About my tone may I ask a question? Yes sometimes I feel irritated. I'm
>> human and I feel irritated.
>>
>> May be you know the trick that some smart manager use to control the
>> length of meetings...
>>
>> I experienced in our team in the past meetings with 18 people and one guy
>> was always talking a lot more than others. And I was always asking myself:
>> does it have conscience that each minute he is taking is in fact 18 min
>> because we could all spend 1 min doing something else.
>>
>> After that I heard about team that have strange clock where the clock is
>> multiplying by the amount of participants.
>>
>> So when I participate to meetings I always think about what is the value
>> that I bring to other time.
>>
>> Now we are all busy, you see some people in our team and outside told me
>> that they do not have the time to follow Pharo mailing-lists because there
>> are too many emails. And we all lose because the insights of such people
>> could be really great.
>>
>> So some alternatives:
>>
>> - do not care do not read the pharo mailing-list, I would not feel
>> happy with such solution.
>>
>> - be forced to react when something wrong is said because this is
>> important for everybody. And yes sometimes I'm irritated because I feel
>> forced to say something.I have the impression that not saying anything is a
>> kind of luxury that I do not have.
>>
>> - have a closed contributors only mailing-list (not good does not
>> feel nice).
>>
>>
>> This license point is key and this is why I reacted. And I reacted that
>> way because I CARE about our system and I CARE about our communitee.
>>
>> Out there, there is Java, Lua, Python, Ruby, Swift, Objective-C and many
>> more. So we should pay attention to our ecosystem and the license
>>
>> is an integral part of it.
>>
>> So sorry to be rude but I'm ***REALLY*** busy. Much more than you can
>> imagine. Even more. And I feel responsible.
>>
>>
>> Stef
>>
>>
>>
>> Le 7/9/16 à 14:40, Dimitris Chloupis a écrit :
>>
>> Ironically enough "this is our way , take it or leave it" would not work
>> for Pharo because its smalltalk and basically smalltalk by architecture
>> allow you to deeply modify the system from the get go.
>>
>> This make Pharo technically impossible to control from a dictator and
>> committee point of view like lets say Python or Linux. CPython is a single
>> implementation , but with pharo every pharo app is essentially a new pharo
>> implementation.  The moment you modify or extend the pharo image you make a
>> new pharo implementation.
>>
>> I don't like the tone Stef is expressing , he is quite rude and
>> definitely does not represent the tone of the community which far more open
>> to dialogue but he is correct , GPL would never have worked for Pharo.
>> Actually I dont think I have seen a language that is fairly popular under a
>> GPL license.
>>
>> There is of course software under GPL which is sucessful commercially,
>> Blender is an example, but GPL does not cover 3d assets, music and sound.
>> In that case you use another kind of license like creative commons or
>> heavily modify GPL to extend beyond code. So it was definitely not GPL that
>> made Blender popular, actually it caused a problem with game developers
>> because games using the BGE (Blender Game Engine) were at first considered
>> data because the code was packaged inside the blend file which had a binary
>> format so that meant it was not covered by GPL because it considered the
>> whole game code just data (there is a separate executable for loading the
>> game code)  but then Blender decided to change this also to GPL with
>> extending its license and that pretty much killed commercial games made
>>

Re: [Pharo-users] Lint Rule for Class-Side Method

2016-09-07 Thread Sean P. DeNigris

Uko2 wrote
> Ok, can you also, please, clarify which version of Pharo are you using?

Sure, sorry for the vague report. Pharo 5



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Lint-Rule-for-Class-Side-Method-tp4914121p4914682.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] SpecBooklet: Strange behavior of ProtocolBrowser

2016-09-07 Thread Matteo via Pharo-users

--- Begin Message ---
Hello Johan,
I've coded all the examples manually, changing the names to avoid
any conflict with the ProtocolBrowser "bundled" in the Pharo 5 image
(i.e. instead of "ProtocolBrowser" I've named my class as "ProtcolFlipper").
But the result is the same.

Things improve if all the "ifNil: [ text text: '' ]" get removed from
the ProtcolFlipper>>initializePresenter method.
Obviously the text pane is no more "cleaned" when deselecting an "api"
or "api-event" row.

I've tried to substitute the "ifNil: [ text text: '' ]" with "ifNil: [
text text: 'api' ] and ifNil: [ text text: 'api-events' ] , respectively
on the "api" and "event" instances, in the ProtocolBrowser >>
initializePresenter method.
In this way I found that "ifNil:" message is sent improperly, i.e. when
a "api-event" row is selected then the message "ifNil:" of the "api"
instance is triggered, and vice-versa.
In some way this is correct: when a "api-event" row is selected then
none of the "api" rows are selected...

However I'm puzzled by the fact that the behavior seems random: creating
3 instances I can get 3 different behaviors.

have you never experienced this?

Maybe I'll check again my code...

thanks,
Matteo

On 08/09/16 00:09, Johan Fabry wrote:
> Hello Matteo,
> 
> are you using the ProtocolBrowser class that comes default with Pharo 5?
> (In the Spec-Examples package). This is different from what is in the
> booklet, the code in Pharo 5 is not up to date. For now, you should
> define a new protocol browser class (MyProtocolBrowser for example) and
> the other classes that are in that section. Sorry for that...
> 
> --
> Does this mail seem too brief? Sorry for that, I don’t mean to be rude!
> Please see http://emailcharter.org .
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry 
> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -
>  University of Chile
> 
>> On Sep 7, 2016, at 18:57, Matteo via Pharo-users
>> mailto:pharo-users@lists.pharo.org>> wrote:
>>
>>
>> *From: *Matteo mailto:matte...@yahoo.it>>
>> *Subject: **SpecBooklet: Strange behavior of ProtocolBrowser*
>> *Date: *September 7, 2016 at 18:56:08 GMT-3
>> *To: *pharo-users@lists.pharo.org 
>>
>>
>> Hi,
>> I'm playing with the ProtocolBrowser class, as coded in the
>> "SpecBooklet.pdf" document (release of the 3rd August 2016).
>> I'm using Pharo 5.
>>
>> I'm experiencing a strange behavior of the  ProtocolBrowser instance:
>> -if I open a ProtocolBrowser instance, and I click on a "api" item, I
>> do not get any code in the text pane.
>> -If I open another ProtocolBrowser instance then I do not see any code,
>> even in the "api" protocol than the "api-events" one.
>> -If I open a further instance then the widget works correctly, showing
>> the "api" or "api-events" code in the text pane.
>>
>> Please note that the ProtocolBrowser is instantiated as follow:
>> (ProtocolBrowsernew)  openWithSpec
>>
>> Could my Pharo image be faulty?
>> Is there some problem with ProtocolBrowser>>initializePresenter?
>>
>> Thanks,
>> Matteo Bellotto
>>
>>
>>
>>
>>
> 

--- End Message ---

Re: [Pharo-users] SpecBooklet: Strange behavior of ProtocolBrowser

Excellent, you found a bug in my code!

What happens is that when one item is selected in a list, in the other list the 
currently selected item is de-selected. This causes *both* blocks 
(whenAPIChanged: and whenEventChanged:) to be executed, and depending on what 
order they are executed the behavior is different. (A classical concurrent 
programming problem.) This order apparently changes depending on how many 
windows you have open, et cetera, I guess because of how the announcement 
system is implemented. 

So, yes the easiest solution is to remove both ifNil: […] lines. The UI will 
not work as cleanly, but it is a quick fix. Alternatively, and a bit more 
complicated, is to check if the selection in the other list is also empty 
before setting the text to the empty string. 

For the sake of the example, I will simply remove  both ifNil: […] lines from 
the documentation.

Thanks for reporting this, and if you have further issues do not hesitate to 
tell us!

--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please 
see http://emailcharter.org .

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

> On Sep 7, 2016, at 19:51, Matteo  wrote:
> 
> Hello Johan,
>I've coded all the examples manually, changing the names to avoid
> any conflict with the ProtocolBrowser "bundled" in the Pharo 5 image
> (i.e. instead of "ProtocolBrowser" I've named my class as "ProtcolFlipper").
> But the result is the same.
> 
> Things improve if all the "ifNil: [ text text: '' ]" get removed from
> the ProtcolFlipper>>initializePresenter method.
> Obviously the text pane is no more "cleaned" when deselecting an "api"
> or "api-event" row.
> 
> I've tried to substitute the "ifNil: [ text text: '' ]" with "ifNil: [
> text text: 'api' ] and ifNil: [ text text: 'api-events' ] , respectively
> on the "api" and "event" instances, in the ProtocolBrowser >>
> initializePresenter method.
> In this way I found that "ifNil:" message is sent improperly, i.e. when
> a "api-event" row is selected then the message "ifNil:" of the "api"
> instance is triggered, and vice-versa.
> In some way this is correct: when a "api-event" row is selected then
> none of the "api" rows are selected...
> 
> However I'm puzzled by the fact that the behavior seems random: creating
> 3 instances I can get 3 different behaviors.
> 
> have you never experienced this?
> 
> Maybe I'll check again my code...
> 
> thanks,
> Matteo

[Pharo-users] Performance vs Ruby performance

2016-09-07 Thread Vitor Medina Cruz

Hello,

How is Pharo compared with Ruby in terms of performance? Has someone done
some comparison benchmark? If yes, that was done with other platforms?

Regards,
VItor

[Pharo-users] Profiling

2016-09-07 Thread Vitor Medina Cruz

Hello,

While profiling some I/O code that takes ~20 seconds to execute under my
local image, the report says that about ~13 seconds is waste on
OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not
understand what this idleProcess do by looking at the code. First I thought
this could be time waiting the I/O operation to terminate, but that don't
make much sense because I have the same code on a Digital Ocean Doplet and
it takes ~6 seconds to execute.

Can someone help me understand what does this time on idleProcess means?


The full report is:

 - 18407 tallies, 18605 msec.

**Tree**

Process: (40s) Morphic UI Process: nil

25.1% {4663ms} UndefinedObject>>DoIt
  25.1% {4663ms}
TweetsServiceRestConsumer(TweetsService)>>hashesTop:usingLastTweetsUpTo:fromHandler:
25.0% {4656ms}
TweetsServiceRestConsumer>>fetchLastTweetsUpTo:fromHandler:
  14.3% {2653ms} OAuthProvider>>httpGet:
|14.3% {2653ms} ZnOAuth1Service>>httpGet:using:
|  14.3% {2653ms} ZnOAuth1Service>>executeRequest:token:
|14.3% {2653ms}
ZnOAuth1Service>>executeRequest:token:followRedirects:
|  14.2% {2646ms} ZnClient>>execute
|14.2% {2646ms} ZnClient>>withProgressDo:
|  14.2% {2646ms} ZnSignalProgress class(DynamicVariable
class)>>value:during:
|14.2% {2646ms}
ZnSignalProgress(DynamicVariable)>>value:during:
|  14.2% {2646ms} BlockClosure>>ensure:
|14.2% {2646ms}
ZnSignalProgress(DynamicVariable)>>value:during:
|  14.2% {2646ms} ZnClient>>withProgressDo:
|14.2% {2646ms} ZnClient>>execute
|  14.2% {2646ms} ZnClient>>executeWithTimeout
|14.2% {2646ms} ZnClient>>withTimeoutDo:
|  14.2% {2646ms} ZnConnectionTimeout
class(DynamicVariable class)>>value:during:
|14.2% {2646ms}
ZnConnectionTimeout(DynamicVariable)>>value:during:
|  14.2% {2646ms} BlockClosure>>ensure:
|14.2% {2646ms}
ZnConnectionTimeout(DynamicVariable)>>value:during:
|  14.2% {2646ms}
ZnClient>>withTimeoutDo:
|14.2% {2646ms}
ZnClient>>executeWithTimeout
|  14.2% {2646ms}
BlockClosure>>on:do:
|14.2% {2646ms}
ZnClient>>executeWithTimeout
|  14.2% {2646ms}
ZnClient>>executeWithRetriesRemaining:
|14.2% {2644ms}
BlockClosure>>on:do:
|  14.2% {2644ms}
ZnClient>>executeWithRetriesRemaining:
|14.2% {2644ms}
ZnClient>>executeWithRedirectsRemaining:
|  14.2% {2641ms}
ZnClient>>getConnectionAndExecute
|13.8% {2569ms}
BlockClosure>>ensure:
|  13.8%
{2569ms} ZnClient>>getConnectionAndExecute
|13.8%
{2569ms} ZnClient>>executeRequestResponse
|  13.8%
{2569ms} ZnClient>>readResponse
|13.8%
{2569ms} ZnResponse class(ZnMessage class)>>readFrom:
|
 13.8% {2569ms} ZnResponse(ZnMessage)>>readFrom:
|
 13.8% {2559ms} ZnResponse>>readEntityFrom:
|
 13.8% {2559ms} ZnResponse(ZnMessage)>>readEntityFrom:
|
 13.8% {2559ms} ZnEntityReader>>readEntity
|
   13.8% {2559ms} ZnEntityReader>>readEntityFromStream
|
 13.7% {2555ms} ZnEntityReader>>readFrom:usingType:andLength:
|
   13.7% {2555ms} ZnEntity class>>readFrom:usingType:andLength:
|
 13.7% {2555ms} ZnStringEntity>>readFrom:
|
   13.7% {2550ms} BlockClosure>>on:do:
|
 13.7% {2550ms} ZnStringEntity>>readFrom:
|
   13.7% {2550ms}
ZnUTF8Encoder>>readInto:startingAt:count:fromStream:
|
 13.7% {2550ms}
ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream:
|
   13.7% {2550ms}
ZnLimitedReadStream>>readInto:startingAt:count:
|
 13.7% {2547ms}
ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count:
|
   13.7% {2547ms}
ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer
|
 9.0% {1669ms}
ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer
|

Re: [Pharo-users] Profiling

- 9989 tallies, 10003 msec.

**Tree**

Process: other processes

99.2% {9928ms} ProcessorScheduler class>>startUp
  99.2% {9928ms} ProcessorScheduler class>>idleProcess
**Leaves**
99.2% {9928ms} ProcessorScheduler class>>idleProcess

**Memory**
old +0 bytes
young -223,912 bytes
used -223,912 bytes
free +223,912 bytes

**GCs**
full 0 totalling 0ms (0.0% uptime)
incr 2 totalling 6ms (0.0% uptime), avg 3.0ms
tenures 0
root table 0 overflows

On Thu, Sep 8, 2016 at 9:44 AM, Vitor Medina Cruz  wrote:
> Hello,
>
> While profiling some I/O code that takes ~20 seconds to execute under my
> local image, the report says that about ~13 seconds is waste on
> OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not
> understand what this idleProcess do by looking at the code. First I thought
> this could be time waiting the I/O operation to terminate, but that don't
> make much sense because I have the same code on a Digital Ocean Doplet and
> it takes ~6 seconds to execute.
>
> Can someone help me understand what does this time on idleProcess means?

I don't have an exact answer for you, but a comparative example...

Tools > Time Profiler...
 10 seconds wait
Full report...
==
 - 9989 tallies, 10003 msec.

**Tree**

Process: other processes

99.2% {9928ms} ProcessorScheduler class>>startUp
  99.2% {9928ms} ProcessorScheduler class>>idleProcess
**Leaves**
99.2% {9928ms} ProcessorScheduler class>>idleProcess

**Memory**
old +0 bytes
young -223,912 bytes
used -223,912 bytes
free +223,912 bytes

**GCs**
full 0 totalling 0ms (0.0% uptime)
incr 2 totalling 6ms (0.0% uptime), avg 3.0ms
tenures 0
root table 0 overflows
==

Now over that time, Windows 7 Task Manager showed Pharo process CPU load of 0%,
indicating the 9.9 seconds spent in idleProcess has no impact on performance.
Or put another way, for 99.2% of that 10 seconds Pharo was *not* busy.

Applying that to your results, I would guess that for 73.3% of that 20
seconds you were waiting on I/O.

To find your performance issues, follow down the percentages for where
there are big jumps without splits.
That is, ignore jumps where the splits add up to the parent.
For example 14.3 + 10.8 ==> 25.1 - so no lost performance here...
  25.0% {4656ms} TweetsServiceRestConsumer>>fetchLastTweetsUpTo:fromHandler:
14.3% {2653ms} OAuthProvider>>httpGet:
  |
10.8% {2002ms} NeoJSONObject class>>fromString:

Your biggest loss in a linear line seems to be...
5.6% {1041ms} NeoJSONReader>>parseValue
to
1.5% {285ms} NeoJSONReader>>parseMap

I am curious about the recursive calls to
ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer
and multiple accumulations from DelayExperimentalSpinScheduler>>unschedule:
but that method doesn't really do a  lot. I wouldn't expect the
whileTrue loop to be spinning much, but you could examine that by

You might try another scheduler...
World>System>Settings>System>Delay Scheduler

[Pharo-users] [ANN] Territorial Re-Licensing

2016-09-07 Thread Hernán Morales Durand

I consider GNU AGPL v3 a fair license choice which protects somehow
authors. After some talks with friends today, I began to consider it
useless for a niche community like Smalltalk *and* solo projects. I then
read all your mails, many posts in other communities, and finally asked for
advices. Conclusion: The ideal license option for me was not yet invented.

Now about parasite behavior and easy living for freeloaders.

- I doubt Smalltalkers are in position for doing anything valuable against
parasites. GPL scares a niche community. All of us having MIT code
published can be stealed and we have no legal options to defend our
work/authorship. That should be addressed one day.

- However, I would like one day to read people releasing software under
whatever license they want and not to be pointed them. That's a matter of
freedom. I feel we are far away from there.

- I hope we can talk about interesting Territorial features, what do you
need, what could be modeled better, etc. Licensing is boring, really.

I re-licensed Territorial to MIT for the nice Pharo people, for the nice
Smalltalkers, people who helped me here in mailing lists, or sending
supportive private messages, and for cool users with nice intentions.

Hernán

PS: Updated User Manual: http://bit.ly/2c4RrCJ

Re: [Pharo-users] Profiling

Ahhh... gmail pre-emptive send strikes again To continue...


I am curious about the recursive calls to
ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer
and multiple accumulations from DelayExperimentalSpinScheduler>>unschedule:
but that method doesn't really do a lot. I wouldn't expect the
whileTrue loop to be spinning much, but you could examine that by
trying something like...

Object subclass: #SpinCount
   instanceVariableNames: 'counter'
   classVariableNames: ''
   package: 'Play'

SpinCount>>initialize
   counter := 0.

SpinCount>>count
   counter := counter + 1.

SpinCount>>printOn: aStream
   super printOn: aStream.
   aStream nextPut: $=.
   counter printOn: aStream.

DelayMicrosecondScheduler subclass: #DelayExperimentalSpinScheduler
   instanceVariableNames: ''
   classVariableNames: 'Tally'
   package: 'Kernel-Processes'

DelayExperimentalSpinScheduler class >> startTally
   Tally := WaitfreeQueue new.

DelayExperimentalSpinScheduler class >> endTally
   |result finalTally|
   finalTally := Tally.
   Tally := nil.
   result := OrderedCollection new.
   finalTally flush: [ :item | result add: item ].
   ^ result

DelayExperimentalSpinScheduler >> unschedule: aDelay
   |spinCount|
   "self startTally"
   "self endTally inspect"
   spinCount  := SpinCount new.
   Tally ifNotNil: [Tally nextPut: spinCount].
   aDelay schedulerBeingWaitedOn ifTrue: [^self error: 'This Delay has
already been scheduled.'].
   [ Tally ifNotNil: [spinCount count].
  scheduledDelay == nil ifTrue: [
   scheduledDelay := aDelay.
   timingSemaphore signal.
  ^self].
  true.
   ] whileTrue.


Actually, I wonder does the "timingSemaphore signal" invoking the
priority 80 DelaySchedulingProcess to wake up and run above the
priority of the profiler?  So all of that activity gets attributed to
#unschedule:  ???

cheers -ben

Re: [Pharo-users] Profiling

On Thu, Sep 8, 2016 at 11:37 AM, Ben Coman  wrote:
> - 9989 tallies, 10003 msec.
>
> **Tree**
> 
> Process: other processes
> 
> 99.2% {9928ms} ProcessorScheduler class>>startUp
>   99.2% {9928ms} ProcessorScheduler class>>idleProcess
> **Leaves**
> 99.2% {9928ms} ProcessorScheduler class>>idleProcess
>
> **Memory**
> old +0 bytes
> young -223,912 bytes
> used -223,912 bytes
> free +223,912 bytes
>
> **GCs**
> full 0 totalling 0ms (0.0% uptime)
> incr 2 totalling 6ms (0.0% uptime), avg 3.0ms
> tenures 0
> root table 0 overflows
>
> On Thu, Sep 8, 2016 at 9:44 AM, Vitor Medina Cruz  
> wrote:
>> Hello,
>>
>> While profiling some I/O code that takes ~20 seconds to execute under my
>> local image, the report says that about ~13 seconds is waste on
>> OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not
>> understand what this idleProcess do by looking at the code. First I thought
>> this could be time waiting the I/O operation to terminate, but that don't
>> make much sense because I have the same code on a Digital Ocean Doplet and
>> it takes ~6 seconds to execute.
>>
>> Can someone help me understand what does this time on idleProcess means?
>
> I don't have an exact answer for you, but a comparative example...
>
> Tools > Time Profiler...
>  10 seconds wait
> Full report...
> ==
>  - 9989 tallies, 10003 msec.
>
> **Tree**
> 
> Process: other processes
> 
> 99.2% {9928ms} ProcessorScheduler class>>startUp
>   99.2% {9928ms} ProcessorScheduler class>>idleProcess
> **Leaves**
> 99.2% {9928ms} ProcessorScheduler class>>idleProcess
>
> **Memory**
> old +0 bytes
> young -223,912 bytes
> used -223,912 bytes
> free +223,912 bytes
>
> **GCs**
> full 0 totalling 0ms (0.0% uptime)
> incr 2 totalling 6ms (0.0% uptime), avg 3.0ms
> tenures 0
> root table 0 overflows
> ==
>
> Now over that time, Windows 7 Task Manager showed Pharo process CPU load of 
> 0%,
> indicating the 9.9 seconds spent in idleProcess has no impact on performance.
> Or put another way, for 99.2% of that 10 seconds Pharo was *not* busy.
>
> Applying that to your results, I would guess that for 73.3% of that 20
> seconds you were waiting on I/O.
>
> To find your performance issues, follow down the percentages for where
> there are big jumps without splits.
> That is, ignore jumps where the splits add up to the parent.
> For example 14.3 + 10.8 ==> 25.1 - so no lost performance here...
>   25.0% {4656ms} TweetsServiceRestConsumer>>fetchLastTweetsUpTo:fromHandler:
> 14.3% {2653ms} OAuthProvider>>httpGet:
>   |
> 10.8% {2002ms} NeoJSONObject class>>fromString:
>
> Your biggest loss in a linear line seems to be...
> 5.6% {1041ms} NeoJSONReader>>parseValue
> to
> 1.5% {285ms} NeoJSONReader>>parseMap
>
>
> I am curious about the recursive calls to
> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer
> and multiple accumulations from DelayExperimentalSpinScheduler>>unschedule:
> but that method doesn't really do a  lot. I wouldn't expect the
> whileTrue loop to be spinning much, but you could examine that by
>
>
> You might try another scheduler...
> World>System>Settings>System>Delay Scheduler

Another experiment might try could be divide-and-conquer by examining
a sample of what is returned by...
   10.8% {2002ms} NeoJSONObject class>>fromString:

and return a similar constant.

cheers -ben

Re: [Pharo-users] [ANN] Territorial Re-Licensing

Hi Hernan,

Thanks for your balanced response.  Licensing discussion can be boring
but also crucial, hence the sometimes religious views on it.  Like a
lot of things, from a distance it seems easy - but the devil is in the
details.  Consider anyway that "Territorial" may otherwise have been a
single blip in your first [ANN] post, but its now had more exposure.
I hope you don't mind I follow up with one more post that has been
sitting almost complete in Drafts folder a few days, after researching
some interesting points.

cheers -ben

On Thu, Sep 8, 2016 at 12:00 PM, Hernán Morales Durand
 wrote:
>
> I consider GNU AGPL v3 a fair license choice which protects somehow authors.
> After some talks with friends today, I began to consider it useless for a
> niche community like Smalltalk *and* solo projects. I then read all your
> mails, many posts in other communities, and finally asked for advices.
> Conclusion: The ideal license option for me was not yet invented.
>
> Now about parasite behavior and easy living for freeloaders.
>
> - I doubt Smalltalkers are in position for doing anything valuable against
> parasites. GPL scares a niche community. All of us having MIT code published
> can be stealed and we have no legal options to defend our work/authorship.
> That should be addressed one day.
>
> - However, I would like one day to read people releasing software under
> whatever license they want and not to be pointed them. That's a matter of
> freedom. I feel we are far away from there.
>
> - I hope we can talk about interesting Territorial features, what do you
> need, what could be modeled better, etc. Licensing is boring, really.
>
> I re-licensed Territorial to MIT for the nice Pharo people, for the nice
> Smalltalkers, people who helped me here in mailing lists, or sending
> supportive private messages, and for cool users with nice intentions.
>
> Hernán
>
> PS: Updated User Manual: http://bit.ly/2c4RrCJ
>
>
>

Re: [Pharo-users] Performance vs Ruby performance

2016-09-07 Thread Clément Bera

What ruby runtime exactly ? The standard ruby interpreter, rubinius, JRuby ?

What do you mean by performance ? Smallest time to run long computation ?
Latency for web servers ? Pauses in real time applications ?

The standard ruby interpreter is really slow (likely ~100 times slower than
the Pharo 5 VM), now it binds directly multiple C librairies, such as the
regex librairy, while these librairies are written in Smalltalk in Pharo.
So if you measure regex performance I am pretty sure that ruby is at least
10 times faster, if not 100 times.

So basically it depends on what benchmark you are measuring. We don't do
cross languages benchmarks in our servers, only versus other Smalltalks.
That website (http://benchmarksgame.alioth.debian.org/) compares ruby and
JRuby to VW which has similar speed to Pharo 5.

On Thu, Sep 8, 2016 at 1:28 AM, Vitor Medina Cruz 
wrote:

> Hello,
>
> How is Pharo compared with Ruby in terms of performance? Has someone done
> some comparison benchmark? If yes, that was done with other platforms?
>
> Regards,
> VItor
>

Re: [Pharo-users] Performance vs Ruby performance