[Pharo-users] Rails Express Demo Using Pharo Seaside

[Peter Fisk]

I have added a new blog post showing how I am using Pharo Smalltalk and
Seaside to rapidly create Ruby-on-Rails applications.
https://railsexpress.quora.com/Pharo-Seaside-Express
  There is also a
short video showing a simple application running under Pharo/Seaside and
then being converted to Ruby-on-Rails. The application uses the Qooxdoo
JavaScript framework for the UI. Seaside Express Video
  The blog outlines some of my
thoughts about the development philosophy.And the video gives some idea of
how this works in practice - particularly how quickly (about a minute) an
entire Ruby-on-Rails application can be generated from the Smalltalk
specification.I will release the Seaside-Qooxdoo classes later this year
when the code is more stable.-- Peter



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] NeoJSON and polymorphism

[Juraj Kubelka]

Hi,

By studying the NeoJSON book chapter (Pharo Enterprise), I do not understand 
how to modify the following example:

-=-=-=-=-=-=-=-
"Let us say that we have an Attachment class..."

Object subclass: #Attachment
instanceVariableNames: 'url fileName'
classVariableNames: ''
package: 'NeoJSON-Use-Case'.

"...with url: and fileName: methods."
Attachment compile: 'url: anObject', String cr, String tab, 'url := anObject' 
classified: 'accessing'.
Attachment compile: 'fileName: anObject', String cr, String tab, 'fileName := 
anObject' classified: 'accessing'.

"Let's create a collection of two instances:"
collectionOne := { 
Attachment new 
url: 'http://example.com/random-name.txt' asZnUrl; 
fileName: 'chapter-one.txt'
yourself.
Attachment new 
url: 'http://example.com/random-name.png' asZnUrl; 
fileName: 'image.png';
yourself.
}.

"And let's map it to a JSON structure:"
String streamContents: [ :aStream |
(NeoJSONWriter on: aStream)
for: #CollectionOfAttachments customDo: [ :mapping | 
mapping listOfElementSchema: Attachment ];
mapAllInstVarsFor: Attachment;
for: ZnUrl customDo: [ :mapping |
mapping encoder: [ :aZnUrl |
aZnUrl asString ] ];
nextPut: collectionOne as: #CollectionOfAttachments.
].

"And read the JSON structure:"
(NeoJSONReader on: 
'[{"url":"http://example.com/random-name.txt","fileName":"chapter-one.txt"},{"url":"http://example.com/random-name.png","fileName":"image.png"}]'
 readStream)
for: #CollectionOfAttachments customDo: [ :mapping | 
mapping listOfElementSchema: Attachment ];
for: Attachment do: [ :mapping | 
mapping mapInstVar: 'fileName'.
(mapping mapInstVar: 'url') valueSchema: ZnUrl ];
for: ZnUrl customDo: [ :mapping |
mapping decoder: [ :string |
string asZnUrl ] ];
nextAs: #CollectionOfAttachments.

"==="
“The previous example works perfectly, including the ZnUrl mapping (notice that 
url variables have ZnUrl instances).

Now, let's say that we want to distinguish PNG and TXT attachments.
For that reason we will create two Attachment subclasses..."

Attachment subclass: #PngAttachment
instanceVariableNames: ''
classVariableNames: ''
package: 'NeoJSON-Use-Case'.

Attachment subclass: #TxtAttachment
instanceVariableNames: ''
classVariableNames: ''
package: 'NeoJSON-Use-Case'.

"...with type methods that might be used in a new JSON structure:"
PngAttachment compile: 'type', String cr, String tab, '^ ''png''' classified: 
'accessing'.
TxtAttachment compile: 'type', String cr, String tab, '^ ''txt''' classified: 
'accessing'.

"Let's create a collection with the PNG and TXT instances:"
collectionTwo := { 
TxtAttachment new 
url: 'http://example.com/random-name.txt' asZnUrl; 
fileName: 'chapter-one.txt'
yourself.
PngAttachment new 
url: 'http://example.com/random-name.png' asZnUrl; 
fileName: 'image.png';
yourself.
}.

"How can I modify NeoJSONWriter and NeoJSONReader mappings?

The JSON structure should (ideally) looks like this:"

'[  

{“type”:”txt”,"url":"http://example.com/random-name.txt","fileName":"chapter-one.txt”},

{“type”:”png”,"url":"http://example.com/random-name.png","fileName":"image.png”}
]'
-=-=-=-=-=-=-=-

I would like to keep the mapping isolated (without defining neoJsonOn: methods).

Thank you!
Juraj

[Pharo-users] PharoCloud method sources

[Esteban A. Maringolo]

I recentrly noticed that the examples gently hosted at PharoCloud
don't have any sources available, and since the examples for both
Bootstrap[1] and Rickshaw[2] uses code reflection to display the
sources used to produce each example, they don't work and you get a
`self methodHasNoSourceCode` instad.

Can this be fixed somehow?

[1] http://pharo.pharocloud.com/bootstrap/browser/Alerts
[2] http://pharo.pharocloud.com/rickshaw

Esteban A. Maringolo

Re: [Pharo-users] Pharo 7 license question

[Jose San Leandro]

I wasn't being cynical when I asked if it makes sense to you the fact that
people write free software and give it away for free. I just wanted to know
if there's any obvious reason that explains that to you.

It's not my intention to judge why proponents of "permissive" licenses
think the way they do. My hypothesis is that they see software exclusively
as a way to make money. Economists are still obsessed in simplifying human
behavior as rules of incentives -> results, until it's become part of our
western cultures. It follows that we only act in our own economic interest,
and also that nobody would work for free. That's where some people find
difficult to explain free software. The same people don't think the
end-user's rights to ultimately own the software we provide are valuable.
They are consumers before users.

Regarding the book, you won't find any direct references to software
licenses. I recommend it because it advocates we treat our users
differently.

Anyway, we agree we disagree. That was never an issue.

I wish you a great day too!

2017-09-21 19:36 GMT+02:00 Jimmie Houchin :

> We will have to agree to disagree.
>
> I have been a passionate user of open source software for over 20 years.
> Are you really saying that proponents of permissive licenses don't
> understand why people write free software and give it away for free? Really!
>
> I passionately disagree with the statement of "All software should be GPLd
> in the first place". This is one of the biggest reasons I passionately
> dislike the GPL. GPL is goodness and light. All else is evil incarnate. Ugh!
>
> I am not going to defend unethical business practices. But that is not a
> defense of the GPL or an argument against permissive licenses. I am not a
> fan Microsoft or Apple, et al. I am a fan FreeBSD and Linux. However I do
> not believe all closed source or proprietary software is wrong or evil.
>
> I am working my way through the book you suggested. But so far I fail to
> see where it makes the argument for the GPL and against permissive licenses.
>
> For the record. I am not a professional programmer. All software I am
> working on if I were to release it (or when) will be under a permissive
> license, unless it is a port of GPLd software. I am not in the business of
> software. I am an empowered user. Open source software empowers me more the
> proprietary software. Permissively licensed software empowers me more than
> GPLd software**. That is not currently the case for everyone and every
> situation. One day it we may come closer to that being true. But it takes
> time. And it takes proper motivation and resources.
>
> **There are many situations that I cannot use GPLd source, but can use
> permissively licensed source. MIT/BSD empowers where, GPL does not. Here in
> this community, with this software. GPL is a no go. It is a show stopper.
> MIT/BSD is welcomed and wanted. Many other communities are likewise.
>
> As I said, we will have to agree to disagree. I doubt that anything above
> persuades you in any way.
>
> Regardless, I wish you well and have a great day!
>
> Jimmie
>
>
>
>
>
> On 09/21/2017 10:39 AM, Jose San Leandro wrote:
>
> I personally don't care about the interests of big corporations cheating
> with end-users' rights. If they were my potential customers, or any
> intermediary which is afraid of not being able to do business with them due
> to their obsession with restricting end-users' rights, then I'd probably
> have a conflict of interest. In that case, I could think of sacrificing
> ethics for food temporarily. But I'm not in that business, and I don't want
> to.
>
> I won't blame the GPL instead of the "old culture" of doing business by
> forcing customers to do only what you want them to do, and make them pay
> for any upgrade some of them could do themselves otherwise.
>
> Distributing works with GPL restricts the options to other developers
> using your product or library. No doubt about that. But ethically, that
> "freedom" only helps the old model of doing software. All software should
> be GPLd in the first place.
>
> There's a book that indirectly illustrates my point, and one I
> enthusiastically recommend: Badass users [1].
>
> Anyway, we could go on and on. It's a matter of pragmatism vs ethics of
> software.
>
> Usually, people sharing your "classic" point of view of the business of
> software don't understand why people write free software and give it for
> free.
> Is that your case?
>
> [1] http://shop.oreilly.com/product/0636920036593.do
>
> 2017-09-21 17:16 GMT+02:00 Jimmie Houchin :
>
>> On 09/21/2017 09:47 AM, Ben Coman wrote:
>>
>> [SNIP]
>> Its horses for courses.  No one viewpoint fits all circumstances. Another
>> way to look at it is that permissive licenses give a developer more freedom
>> to combine libraries with different licenses.
>>
>> I do like this radical simplification I bumped into...
>> "Another way of looking at it is that 

Re: [Pharo-users] Pharo 7 license question

[Offray Vladimir Luna Cárdenas]

Hi,

I think that licensing is an important issue and despite of being a
pretty political one (a way to express power and empowerment from/to
users) is not discussed deeply, so I welcome a lot a friendly thread
like this one. I share the views of the free software (which is not the
same as open source), but I think that not all software can be released
as such. Even the people at FSF provided exceptions like the LGPL as a
way to balance practical concerns and liberties. In the case of Pharo,
subclassing is the most common way of reusing (instead of linking), the
LGPL doesn't work (a long rationality about when/where to use it is on
[1] and a interesting analysis is [1a]).

[1] https://www.gnu.org/licenses/why-not-lgpl.html
[1a] http://giovanni.bajo.it/post/56510184181/is-gpl-still-relevant

There are long discussions about how to create cultural (and other)
commons and how licensing plays a role on it. The P2P license[2], for
example, favors cooperatives instead of private corps (I think that a
modification to include small and medium business should be provided).
The idea is that license express a world view (about liberty, sharing,
reciprocity, diversity, fears, etc.) and we should not overseen that. In
my case, what I try to do is to see how a particular license plays a
role in creating a commons and making me part of a community that build
such commons goods. If I chose a different license for Grafoscopio,
instead of MIT, the tool have less probability to be part of the Pharo
commons and community (and is not properly a rising star in popularity
right now!), but I can express my concerns about diversity in licensing
and commons building in other places, like in the Grafoscopio Manual [3].

[2] https://wiki.p2pfoundation.net/Peer_Production_License
[3]
http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/manual.pdf

So I think that we should look at how the licenses have enabled or not
the building of a common world and who is empowered by such licenses as
a complex issue, to balance practical and idealist choices, trying to
make them converge. In my case, having Grafoscopio and its documentation
and related artifacts licensed as Free Cultural Works [4], has given to
me leverage even in negotiations with big entities and they keep such
works and derived ones with the same licenses. So, from my personal
point of view and practices having such mixtures of licenses have not
diminished in any way my own practices in building commons. I would like
to explore (networks of) cooperatives and small/medium business as an
alternative economical practice to enlarge and protect the commons, but
as said, this is a complex issue that requires a lot of field work.

Cheers,

Offray

[4] http://freedomdefined.org/

On 21/09/17 10:39, Jose San Leandro wrote:
> I personally don't care about the interests of big corporations
> cheating with end-users' rights. If they were my potential customers,
> or any intermediary which is afraid of not being able to do business
> with them due to their obsession with restricting end-users' rights,
> then I'd probably have a conflict of interest. In that case, I could
> think of sacrificing ethics for food temporarily. But I'm not in that
> business, and I don't want to.
>
> I won't blame the GPL instead of the "old culture" of doing business
> by forcing customers to do only what you want them to do, and make
> them pay for any upgrade some of them could do themselves otherwise.
>
> Distributing works with GPL restricts the options to other developers
> using your product or library. No doubt about that. But ethically,
> that "freedom" only helps the old model of doing software. All
> software should be GPLd in the first place.
>
> There's a book that indirectly illustrates my point, and one I
> enthusiastically recommend: Badass users [1].
>
> Anyway, we could go on and on. It's a matter of pragmatism vs ethics
> of software.
>
> Usually, people sharing your "classic" point of view of the business
> of software don't understand why people write free software and give
> it for free.
> Is that your case?
>
> [1] http://shop.oreilly.com/product/0636920036593.do
>
> 2017-09-21 17:16 GMT+02:00 Jimmie Houchin  >:
>
> On 09/21/2017 09:47 AM, Ben Coman wrote:
>> [SNIP]
>> Its horses for courses.  No one viewpoint fits all circumstances.
>> Another way to look at it is that permissive licenses give a
>> developer more freedom to combine libraries with different
>> licenses.  
>>
>> I do like this radical simplification I bumped into... 
>> "Another way of looking at it is that you’re picking a license
>> based on what you are afraid of. 
>> * The MIT license is if you’re afraid no one will use your code;
>> you’re making the licensing as short and non-intimidating as
>> possible. 
>> * The Apache License you are somewhat afraid of no one using your
>> code, but you are 

Re: [Pharo-users] Pharo 7 license question

[Jimmie Houchin]

We will have to agree to disagree.

I have been a passionate user of open source software for over 20 years. 
Are you really saying that proponents of permissive licenses don't 
understand why people write free software and give it away for free? Really!


I passionately disagree with the statement of "All software should be 
GPLd in the first place". This is one of the biggest reasons I 
passionately dislike the GPL. GPL is goodness and light. All else is 
evil incarnate. Ugh!


I am not going to defend unethical business practices. But that is not a 
defense of the GPL or an argument against permissive licenses. I am not 
a fan Microsoft or Apple, et al. I am a fan FreeBSD and Linux. However I 
do not believe all closed source or proprietary software is wrong or evil.


I am working my way through the book you suggested. But so far I fail to 
see where it makes the argument for the GPL and against permissive licenses.


For the record. I am not a professional programmer. All software I am 
working on if I were to release it (or when) will be under a permissive 
license, unless it is a port of GPLd software. I am not in the business 
of software. I am an empowered user. Open source software empowers me 
more the proprietary software. Permissively licensed software empowers 
me more than GPLd software**. That is not currently the case for 
everyone and every situation. One day it we may come closer to that 
being true. But it takes time. And it takes proper motivation and 
resources.


**There are many situations that I cannot use GPLd source, but can use 
permissively licensed source. MIT/BSD empowers where, GPL does not. Here 
in this community, with this software. GPL is a no go. It is a show 
stopper. MIT/BSD is welcomed and wanted. Many other communities are 
likewise.


As I said, we will have to agree to disagree. I doubt that anything 
above persuades you in any way.


Regardless, I wish you well and have a great day!

Jimmie





On 09/21/2017 10:39 AM, Jose San Leandro wrote:
I personally don't care about the interests of big corporations 
cheating with end-users' rights. If they were my potential customers, 
or any intermediary which is afraid of not being able to do business 
with them due to their obsession with restricting end-users' rights, 
then I'd probably have a conflict of interest. In that case, I could 
think of sacrificing ethics for food temporarily. But I'm not in that 
business, and I don't want to.


I won't blame the GPL instead of the "old culture" of doing business 
by forcing customers to do only what you want them to do, and make 
them pay for any upgrade some of them could do themselves otherwise.


Distributing works with GPL restricts the options to other developers 
using your product or library. No doubt about that. But ethically, 
that "freedom" only helps the old model of doing software. All 
software should be GPLd in the first place.


There's a book that indirectly illustrates my point, and one I 
enthusiastically recommend: Badass users [1].


Anyway, we could go on and on. It's a matter of pragmatism vs ethics 
of software.


Usually, people sharing your "classic" point of view of the business 
of software don't understand why people write free software and give 
it for free.

Is that your case?

[1] http://shop.oreilly.com/product/0636920036593.do

2017-09-21 17:16 GMT+02:00 Jimmie Houchin >:


On 09/21/2017 09:47 AM, Ben Coman wrote:

[SNIP]
Its horses for courses.  No one viewpoint fits all circumstances.
Another way to look at it is that permissive licenses give a
developer more freedom to combine libraries with different licenses.

I do like this radical simplification I bumped into...
"Another way of looking at it is that you’re picking a license
based on what you are afraid of.
* The MIT license is if you’re afraid no one will use your code;
you’re making the licensing as short and non-intimidating as
possible.
* The Apache License you are somewhat afraid of no one using your
code, but you are also afraid of legal ambiguity and patent trolls.
* With the GPL licenses, you are afraid of someone else profiting
from your work [or profiting off end-users] (and ambiguity, and
patent trolls)."
[https://exygy.com/which-license-should-i-use-mit-vs-apache-vs-gpl
]

...which aligns squarely with Pharo - our greater fear is people
not using it.


I think the GPL one looks right. Fear, anger, offense if someone
has the possibility of using their software and not contributing
back. To me I think it doesn't work as much as they think. It
doesn't take into account the free will of people to walk away and
completely not use their software. I personally don't even look at
GPL licensed sources unless there are none other available which
is very rare. I 

Re: [Pharo-users] (no subject)

[Ben Coman]

Could you clarify where to download from?
I tried PharoLauncher-user-bleedingEdge-2017.09.20.zip
from...
https://ci.inria.fr/pharo/view/Launcher/job/Launcher/149/PHARO=61,VERSION=bleedingEdge,VM=vm,label=linux/

with the Pharo-linux-0.2.13.zip I previously downloaded (limited time
before bed)

cheers -ben


On Thu, Sep 21, 2017 at 9:45 PM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:

> Hi Ben,
>
> Could you test it with the bleedingEdge version of the launcher to see if
> the problem is solved?
>
> Thanks,
> Christophe.
>
> Le 20 sept. 2017 à 08:26, Ben Coman  a écrit :
>
>
>
> On Wed, Sep 20, 2017 at 1:12 PM, Ben Coman  wrote:
>
>> On Thu, Sep 14, 2017 at 8:25 PM, Christophe Demarey <
>> christophe.dema...@inria.fr> wrote:
>> > Hi,
>> >
>> > I published an update of the Launcher yesterday fixing some issues to
>> run
>> > Pharo images from Linux. You can find latest-versions (0.2.13) here:
>> > http://files.pharo.org/platform/launcher/
>> > It already propose to download Pharo 70 images. The VM is now downloaded
>> > automatically if the adequate one is not available.
>> > Let us know if everything is fine.
>>
>> Thanks Christophe for updating PharoLauncher.  I'm trying it with Pharo 7
>> images for the first time.
>> I hit a problem using Iceberg in downloaded images.
>>
>> $ unzip Pharo-linux-0.2.13.zip
>> $ cd pharo
>> $ unzip ../PharoLauncher-user-stable-2017.09.14.zip
>> $ ./pharo
>> + PharoLauncher > Settings > Enable development environment
>> + World > Tools > Iceberg
>> ==>  iceberg opens okay
>> + PharoLauncher > Templates > Pharo 7.0(beta) > latest-32 
>> '7latest32'
>> + '7latest32' 
>> + World > Tools > Iceberg
>> ==>  "Error: EXternal module not found"
>>
>> $ uname -a
>> ==> Linux 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686
>> GNU/Linux
>>
>>
> but this works okay...
> $ curl get.pharo.org/70+vm | bash
> $ ./pharo-ui
> + World > Tools > Iceberg
> ==>  iceberg opens okay
>
>
> while this PharoLauncher alternative fails...
> $  curl get.pharo.org | bash
> $ ./pharo-ui
> + World > Tools > Catalog > PharoLauncher 
> + World > PharoLauncher
> ==> Doesn't show Pharo 7 templates
> + World > Monticello > ...PharoLauncher/main 
> + ConfigurationOfPharoLauncher-ChristopheDemarey.56 
> + World > Playground > "ConfigurationOfPharoLauncher load" 
> + World > PharoLauncher > Settings > Hard reset persistant state
> ==> Pharo 7 templates showing
> + '7latest32'   "i.e. the previously downloaded image"
> + World > Tools > Iceberg
> ==>  "Error: External module not found"
>
> + World > Monticello... load latest mczs...
> * PharoLauncher-Core-ChristopheDemarey.123
> * PharoLauncher-Spec-ChristopheDemarey.51
> + '7latest32'   "i.e. the previously downloaded image"
> ==> "Fetching VM to run Pharo 70 images"
> + World > Tools > Iceberg
> ==>  "Error: External module not found"
>
>
> Version comparison...
>
> direct get.pharo.org/70+vm
>   /home/ben/Pharo/adhoc/Pharo7/Pharo.image
> Pharo7.0alpha.build.132.sha.4ea2f39a9f43185d31b844be5ad33b677f43bf17
>   /home/ben/Pharo/adhoc/Pharo7/pharo-vm/lib/pharo/5.0-201708271955/pharo
> CoInterpreter VMMaker.oscog-eem.2265 uuid: 
> 76b62109-629a-4c39-9641-67b53321df9a
> Aug 27 2017
>
> via PharoLauncher...
>   /home/ben/Pharo/images/7latest32/7latest32.image
> Pharo7.0alpha.build.132.sha.4ea2f39a9f43185d31b844be5ad33b677f43bf17
>   /home/ben/Pharo/vms/70-x86/lib/pharo/5.0-201708271955/pharo
> CoInterpreter VMMaker.oscog-eem.2265 uuid: 
> 76b62109-629a-4c39-9641-67b53321df9a
> Aug 27 2017
>
> Must be something environmental in lookup paths.  Can you reproduce or
> suggest further investigation I can do?
>
> cheers -ben
>
>
>
>
>
>
>

Re: [Pharo-users] Pharo 7 license question

[Jose San Leandro]

I personally don't care about the interests of big corporations cheating
with end-users' rights. If they were my potential customers, or any
intermediary which is afraid of not being able to do business with them due
to their obsession with restricting end-users' rights, then I'd probably
have a conflict of interest. In that case, I could think of sacrificing
ethics for food temporarily. But I'm not in that business, and I don't want
to.

I won't blame the GPL instead of the "old culture" of doing business by
forcing customers to do only what you want them to do, and make them pay
for any upgrade some of them could do themselves otherwise.

Distributing works with GPL restricts the options to other developers using
your product or library. No doubt about that. But ethically, that "freedom"
only helps the old model of doing software. All software should be GPLd in
the first place.

There's a book that indirectly illustrates my point, and one I
enthusiastically recommend: Badass users [1].

Anyway, we could go on and on. It's a matter of pragmatism vs ethics of
software.

Usually, people sharing your "classic" point of view of the business of
software don't understand why people write free software and give it for
free.
Is that your case?

[1] http://shop.oreilly.com/product/0636920036593.do

2017-09-21 17:16 GMT+02:00 Jimmie Houchin :

> On 09/21/2017 09:47 AM, Ben Coman wrote:
>
> [SNIP]
> Its horses for courses.  No one viewpoint fits all circumstances. Another
> way to look at it is that permissive licenses give a developer more freedom
> to combine libraries with different licenses.
>
> I do like this radical simplification I bumped into...
> "Another way of looking at it is that you’re picking a license based on
> what you are afraid of.
> * The MIT license is if you’re afraid no one will use your code; you’re
> making the licensing as short and non-intimidating as possible.
> * The Apache License you are somewhat afraid of no one using your code,
> but you are also afraid of legal ambiguity and patent trolls.
> * With the GPL licenses, you are afraid of someone else profiting from
> your work [or profiting off end-users] (and ambiguity, and patent trolls)."
> [https://exygy.com/which-license-should-i-use-mit-vs-apache-vs-gpl]
>
> ...which aligns squarely with Pharo - our greater fear is people not using
> it.
>
>
> I think the GPL one looks right. Fear, anger, offense if someone has the
> possibility of using their software and not contributing back. To me I
> think it doesn't work as much as they think. It doesn't take into account
> the free will of people to walk away and completely not use their software.
> I personally don't even look at GPL licensed sources unless there are none
> other available which is very rare. I don't want the knowledge or
> understanding of that code tainting other code I write.
>
> MIT often means, we don't care, do what you want, just don't blame us.
> We don't care if you take it and use it in closed source proprietary money
> making big corp software.
> We don't care if you take it and use it and keep it to yourself.
> We don't care ... Just don't blame us for any problems.
>
> However, we would love your buy in on open source philosophy and
> contribute back where you are able. We understand you have software which
> is business critical, proprietary and can not be open sourced. We also know
> that you probably have software which has no business specific (your
> business) code which is releasable. And we see many, many, big and small
> businesses doing so today. Close off what you must, open what you can.
>
> I don't think most of us are afraid of no one using our code. PostgreSQL
> has no such fear. SQLite which is public domain has no such fear. And we
> could go on and on. Python, etc...
>
> I personally am very much in the camp of I want people to contribute
> because they want to contribute. Not because I have a stick called the GPL.
> But rather because I have the carrot of all of the benefits derived from
> open source software. I am carrot oriented, not stick oriented.
>
> Jimmie
>
>
>

Re: [Pharo-users] Pharo 7 license question

[Herby Vojčík]

Jimmie Houchin wrote:

You say it defends rights. It just removed my right to license my
software how I wish. The only way to preserve that option is to not use
GPL software.

Now, should I choose to not use GPL software. How has that benefited
anybody in the GPL ecosystem? Not at all.

We like to talk about the bad big corporation stealing our hard work and
our software and making millions of dollars. Yes big corp. prefers
MIT/BSD. They also prefer to release their own hard work and dollars as
MIT/BSD licensed software. It isn't as if it is all take on big
corporation's side. They prefer the permissive license both as author
and user.

MIT/BSD simply says you the user may do anything you want. Just don't
blame me (author) for anything. And give author(s) credit for what they
have created.

I would rather have people, businesses believe in open source software
and use and release open source software because they are believers and
not because some license forced them to do so. That is how MIT/BSD
software is. And in reality it is how all authors of open source
software are regardless of license. They do it because the believe in
it. It is wrong to think that MIT authors don't believe in the freedoms
of open source software. We do. We want the user to reciprocate because
they believe, not because we forced them. You can't force anybody. They
always have the choice of choosing something different, or writing it
themselves.


+1


Jimmie


Herby

Re: [Pharo-users] Pharo 7 license question

[Jimmie Houchin]

On 09/21/2017 09:47 AM, Ben Coman wrote:

[SNIP]
Its horses for courses.  No one viewpoint fits all circumstances. 
Another way to look at it is that permissive licenses give a developer 
more freedom to combine libraries with different licenses.


I do like this radical simplification I bumped into...
"Another way of looking at it is that you’re picking a license based 
on what you are afraid of.
* The MIT license is if you’re afraid no one will use your code; 
you’re making the licensing as short and non-intimidating as possible.
* The Apache License you are somewhat afraid of no one using your 
code, but you are also afraid of legal ambiguity and patent trolls.
* With the GPL licenses, you are afraid of someone else profiting from 
your work [or profiting off end-users] (and ambiguity, and patent 
trolls)." 
[https://exygy.com/which-license-should-i-use-mit-vs-apache-vs-gpl]


...which aligns squarely with Pharo - our greater fear is people not 
using it.


I think the GPL one looks right. Fear, anger, offense if someone has the 
possibility of using their software and not contributing back. To me I 
think it doesn't work as much as they think. It doesn't take into 
account the free will of people to walk away and completely not use 
their software. I personally don't even look at GPL licensed sources 
unless there are none other available which is very rare. I don't want 
the knowledge or understanding of that code tainting other code I write.


MIT often means, we don't care, do what you want, just don't blame us.
We don't care if you take it and use it in closed source proprietary 
money making big corp software.

We don't care if you take it and use it and keep it to yourself.
We don't care ... Just don't blame us for any problems.

However, we would love your buy in on open source philosophy and 
contribute back where you are able. We understand you have software 
which is business critical, proprietary and can not be open sourced. We 
also know that you probably have software which has no business specific 
(your business) code which is releasable. And we see many, many, big and 
small businesses doing so today. Close off what you must, open what you can.


I don't think most of us are afraid of no one using our code. PostgreSQL 
has no such fear. SQLite which is public domain has no such fear. And we 
could go on and on. Python, etc...


I personally am very much in the camp of I want people to contribute 
because they want to contribute. Not because I have a stick called the 
GPL. But rather because I have the carrot of all of the benefits derived 
from open source software. I am carrot oriented, not stick oriented.


Jimmie

Re: [Pharo-users] PetitParser Mystery

[Sean P. DeNigris]

Peter Kenny wrote
> I would expect the parser which fails to also
> fail, for the same reason, if the input is just 'John Smith' without the
> 'Jr'.

Correct! It did.


Peter Kenny wrote
> The top-level construct in your parser is PPSequenceParser, which works in
> a
> simple-minded way; it just checks whether each of its component parsers
> succeeds. If one of them fails, the whole sequence fails; it does not try
> backtracking.

Ah, okay. That makes sense. It seems I just got lucky in that when I've done
this before, it was the special case you mention below of unique tokens


Peter Kenny wrote
> firstName, ((middleName, lastName)/ lastName), generational optional

That worked for all interesting cases.


Peter Kenny wrote
> If you are going to produce a parser which copes with all the vagaries of
> people's names, especially outside the US, I think you will have some fun.

Ha ha, no doubt. I am not presuming to capture the whole domain, just an
interesting - and thankfully very limited - subset!

Thanks for all the help :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Pharo 7 license question

[Ben Coman]

On Thu, Sep 21, 2017 at 3:57 AM, Jose San Leandro 
wrote:

> Hi,
>
> I was afraid this would hijack the thread, and didn't want to.
>

No worries. Its pertinent to the topic. Licensing is a bit arcane and
various viewpoints are useful.

I support FSF ideals (I have a hardcopy of Stallman's book [
http://a.co/aso0v7W])
and believe the GPL is appropriate for a lot of software - particularly
off-the-shelf / end-user oriented software, but less appropriate for
bespoke software written under contract for a specific company, (e.g. their
business web site) which is the market Pharo is hoping its user-developers
succeed.
[
http://ballardchalmers.com/2016/03/27/bespoke-software-outgunning-off-the-shelf-software/
]

I don't like these metaphors, and my attempt to answer your question may be
> better, or less obvious, but I think "viral" and "infection" only describe
> the GPL when your mindset does not care about the freedoms the GPL tries to
> preserve.
>

The essential MIT/GPL license differences is how they treat free-riders and
downstream user rights. You seem concerned with the latter, which is why
the GPL is suited for end-user / packaged / off-the-shelf software.  But
Pharo's user-developers don't control the views of the companies they
contract to, and forcing the GPL as the only licensing option may have a
chilling effect on the ability gain engagements.  So the Pharo mindset is
to preserve the freedom of its user-developer's to negotiate the terms of
their contracts with their clients.

>From that position, what makes the GPL viral is the clause "You may convey
a work based on the Program ... provided that you ... license the entire
work, as a whole."

So I have the freedom to distribute an application combining three
libraries with separate MIT, BSD and Apache licenses while maintaining
those original licenses. But add a GPL library, and now my application must
distribute the other three libraries also under the GPL. Thats viral.


> I'd say "effective against people trying to restrict the rights the GPL
> defends" instead of "viral".
>

Sorry to be glib, but viral is a lot simpler (for those of a certain
mindset).


> The "infection" interpretation comes from the idea that the GPL restricts
> freedom, which is a trap. We may be used not to care about certain rights,
> or think they are secondary or even worthless. Then, when the GPL forces us
> not to restrict those rights, and we still don't care about what the GPL is
> trying to protect, we can conclude the GPL is a dangerous infection that
> restricts our freedom of choice.
>

GPL is a mechanism to defend users. Software vendors used to limit users'
> rights obviously get their "rights" limited. The GPL does not respect the
> right to restrict others' rights.
>

Its horses for courses.  No one viewpoint fits all circumstances. Another
way to look at it is that permissive licenses give a developer more freedom
to combine libraries with different licenses.

I do like this radical simplification I bumped into...
"Another way of looking at it is that you’re picking a license based on
what you are afraid of.
* The MIT license is if you’re afraid no one will use your code; you’re
making the licensing as short and non-intimidating as possible.
* The Apache License you are somewhat afraid of no one using your code, but
you are also afraid of legal ambiguity and patent trolls.
* With the GPL licenses, you are afraid of someone else profiting from your
work [or profiting off end-users] (and ambiguity, and patent trolls)." [
https://exygy.com/which-license-should-i-use-mit-vs-apache-vs-gpl]

...which aligns squarely with Pharo - our greater fear is people not using
it.


>
> Anyway, I'm not here to judge. MIT may be the most convenient license for
> Pharo nowadays. I'm not discussing that. I just couldn't remain silent
> thinking there's an obvious consensus that GPL is "viral" or an "infection"
> and that should be avoided at all costs.
>

cool.
cheers -ben


>
> 2017-09-20 21:30 GMT+02:00 Jimmie Houchin :
>
>> Hello,
>>
>> As the person who initially used the word viral in this thread, let me
>> ask you a question.
>>
>> Personally I greatly dislike the GPL and variants. I and many believe
>> viral is what describes that nature of the GPL. However, I recognize that
>> there are reasonable people who like the GPL and greatly like that aspect
>> of its license. It is viral and does infect. It is seen by many people
>> something to avoid, just as one would avoid a virus or infection. Yes these
>> are negative terms.
>>
>> You protest our use of these terms but do not offer alternatives that you
>> prefer. In the absence of acceptable alternatives that GPL proponents
>> prefer, then we left to terms that we naturally gravitate toward using. So
>> let me suggest that when you make your opinion heard, please include what
>> you would prefer. Otherwise it doesn't really help you with your expressed
>> desires of us not 

Re: [Pharo-users] (no subject)

[Christophe Demarey]

Hi Ben, 

Could you test it with the bleedingEdge version of the launcher to see if the 
problem is solved?

Thanks,
Christophe.

> Le 20 sept. 2017 à 08:26, Ben Coman  a écrit :
> 
> 
> 
> On Wed, Sep 20, 2017 at 1:12 PM, Ben Coman  > wrote:
> On Thu, Sep 14, 2017 at 8:25 PM, Christophe Demarey 
> > wrote:
> > Hi,
> >
> > I published an update of the Launcher yesterday fixing some issues to run
> > Pharo images from Linux. You can find latest-versions (0.2.13) here:
> > http://files.pharo.org/platform/launcher/ 
> > 
> > It already propose to download Pharo 70 images. The VM is now downloaded
> > automatically if the adequate one is not available.
> > Let us know if everything is fine.
> 
> Thanks Christophe for updating PharoLauncher.  I'm trying it with Pharo 7 
> images for the first time.
> I hit a problem using Iceberg in downloaded images. 
> 
> $ unzip Pharo-linux-0.2.13.zip
> $ cd pharo
> $ unzip ../PharoLauncher-user-stable-2017.09.14.zip
> $ ./pharo
> + PharoLauncher > Settings > Enable development environment
> + World > Tools > Iceberg  
> ==>  iceberg opens okay
> + PharoLauncher > Templates > Pharo 7.0(beta) > latest-32  
> '7latest32'
> + '7latest32' 
> + World > Tools > Iceberg  
> ==>  "Error: EXternal module not found"
> 
> $ uname -a 
> ==> Linux 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 
> GNU/Linux
> 
> 
> but this works okay...
> $ curl get.pharo.org/70+vm  | bash
> $ ./pharo-ui
> + World > Tools > Iceberg  
> ==>  iceberg opens okay
> 
> 
> while this PharoLauncher alternative fails...
> $  curl get.pharo.org  | bash
> $ ./pharo-ui
> + World > Tools > Catalog > PharoLauncher 
> + World > PharoLauncher 
> ==> Doesn't show Pharo 7 templates
> + World > Monticello > ...PharoLauncher/main 
> + ConfigurationOfPharoLauncher-ChristopheDemarey.56 
> + World > Playground > "ConfigurationOfPharoLauncher load" 
> + World > PharoLauncher > Settings > Hard reset persistant state
> ==> Pharo 7 templates showing
> + '7latest32'   "i.e. the previously downloaded image"
> + World > Tools > Iceberg  
> ==>  "Error: External module not found"
> 
> + World > Monticello... load latest mczs...
> * PharoLauncher-Core-ChristopheDemarey.123
> * PharoLauncher-Spec-ChristopheDemarey.51
> + '7latest32'   "i.e. the previously downloaded image"
> ==> "Fetching VM to run Pharo 70 images" 
> + World > Tools > Iceberg  
> ==>  "Error: External module not found"
> 
> 
> Version comparison...
> 
> direct get.pharo.org/70+vm 
>   /home/ben/Pharo/adhoc/Pharo7/Pharo.image
> Pharo7.0alpha.build.132.sha.4ea2f39a9f43185d31b844be5ad33b677f43bf17
>   /home/ben/Pharo/adhoc/Pharo7/pharo-vm/lib/pharo/5.0-201708271955/pharo
> CoInterpreter VMMaker.oscog-eem.2265 uuid: 
> 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017
> 
> via PharoLauncher... 
>   /home/ben/Pharo/images/7latest32/7latest32.image
> Pharo7.0alpha.build.132.sha.4ea2f39a9f43185d31b844be5ad33b677f43bf17  
>   /home/ben/Pharo/vms/70-x86/lib/pharo/5.0-201708271955/pharo
> CoInterpreter VMMaker.oscog-eem.2265 uuid: 
> 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017
> 
> Must be something environmental in lookup paths.  Can you reproduce or 
> suggest further investigation I can do?
> 
> cheers -ben
> 
> 
> 
> 
> 

Re: [Pharo-users] (no subject)

[Christophe Demarey]

> Le 21 sept. 2017 à 13:25, Stephane Ducasse  a écrit :
> 
> Christophe
> 
> which version should we take?

For now, the bleeding edge. I will publish a stable as soon as it gets tested 
enough.

Re: [Pharo-users] (no subject)

[Christophe Demarey]

> Le 20 sept. 2017 à 23:36, Stephan Eggermont  a écrit :
> 
> On 17/09/17 05:21, Sean P. DeNigris wrote:
>> demarey wrote
>>> Let us know if everything is fine.
>> Was this issue [1] fixed:
>>> I think I found it. It seems to be a bug in the way Launcher/Pharo unzips
>>> the downloaded VM.
>>> The symlink libgit2.dylib becomes unlinked and appears as just a regular
>>> file. If I delete the
>>> Pharo.app and unzip 70.zip (which btw maybe should have been deleted
>>> during cleanup after
>>> the dl) to ./vms/70, the error disappears!
> 
> With todays bleedingEdge PharoLauncher on mac I was able to download and 
> start 60510. When trying to load GToolKit
> 
> Iceberg enableMetacelloIntegration: true.
> Metacello new
>   baseline: 'GToolkit';
>   repository: 'github://feenkcom/gtoolkit/src';
>   load.
> 
> I ran into some problem with libgit2 that I could solve by doing the 
> unzipping of the downloaded vm zipfile with the Archive Utility and replacing 
> the vm (and re-adding the sources).

I tried to reproduce the problem with the same configuration without success. 
It works well.
I guess you already downloaded the required VM with a previous version of the 
launcher (using Pharo unzipping). If you delete this VM and use the launcher to 
run the image, it should download the VM and uses your system unzip command to 
extract it.

Re: [Pharo-users] (no subject)

[Stephane Ducasse]

Christophe

which version should we take?

Stef

On Wed, Sep 20, 2017 at 12:17 PM, Christophe Demarey
 wrote:
> Hi Sean, Stephan,
>
> I just updated the PharoLauncher and it should now work fine for 64-bits 
> images.
> I just had time to test it roughly but you can give it a try 
> (https://ci.inria.fr/pharo/view/Launcher/job/Launcher/149/).
>
> Christophe.
>
>
>> Le 20 sept. 2017 à 10:52, stephan  a écrit :
>>
>> On 20-09-17 08:26, Ben Coman wrote:
>>
>>> Must be something environmental in lookup paths.  Can you reproduce or 
>>> suggest further investigation I can do?
>>
>> If I understand it correctly it is a problem with the unzipping. Not 
>> handling symlinks and preserving permissions. Is that a plugin problem?
>>
>> Stephan
>>
>>
>
>

Re: [Pharo-users] PetitParser Mystery

[PBKResearch]

Sean

I'm not an expert on PetitParser, but I think I understand what is
happening. If I am right, I would expect the parser which fails to also
fail, for the same reason, if the input is just 'John Smith' without the
'Jr'. If this is not so, you can disregard the rest of this post.

The top-level construct in your parser is PPSequenceParser, which works in a
simple-minded way; it just checks whether each of its component parsers
succeeds. If one of them fails, the whole sequence fails; it does not try
backtracking. (You can see the code at PPSequenceParser>>#parseOn:) In your
case, the second component parser, which is 'middleName optional', succeeds,
because 'Smith' could be a middle name. The next component, 'lastName',
fails because 'Jr' is not a valid last name, but there is no way for the
sequence parser to recall that the previous component had an optional
element. So the sequence fails.

The only way to cope with this that I can see is to make the options
explicit by using the slash, which does show the parser where to backtrack
to. This is what your second parser does. You could limit the scope of the
backtracking to avoid re-parsing the first name, by writing something like:

firstName, ((middleName, lastName)/ lastName), generational optional

(I'm not sure whether the innermost parentheses are necessary, but at least
they do no harm.)

Thinking about this, I wondered how 'optional' could ever be used except at
the end of a sequence. I think the answer is that it works if the optional
token has a format or structure which identifies it uniquely if it does
occur; in this case, the effect of 'optional' is to say 'forget it if it
doesn't occur'. In your case, there is nothing to distinguish a middle name
from a last name; indeed, I believe in US usage they can be the same - if
Jane Smith marries John Doe, can she become Jane Smith Doe?

If you are going to produce a parser which copes with all the vagaries of
people's names, especially outside the US, I think you will have some fun.
Many people in France would write a surname like yours with a space after
the 'De', and probably a lower-case 'd' as well. In Scotland, a suffix like
'Jr' could appear as 'the Younger'. Some people have more than two
forenames. Some people have double-barrelled surnames, with or without a
hyphen. Those are just a few of the complications I can think of. So good
luck!

Hope this helps

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
Sean P. DeNigris
Sent: 21 September 2017 03:18
To: pharo-users@lists.pharo.org
Subject: [Pharo-users] PetitParser Mystery

Given:
generationalPart := (#space asParser, generational) ==> #second.
middleName := (#space asParser, (generational not,
abbreviatableToken) ==>
#second) ==> #second.
lastName := (#space asParser, (generational not, token) ==> #second)
==> #second.
and
input := 'John Smith Jr'.

The following parser fails:
abbreviatableToken, middleName optional, lastName, generationalPart
optional.

But this one succeeds:
(abbreviatableToken, middleName, lastName, generationalPart
optional) / (abbreviatableToken, nil asParser, lastName, generationalPart
optional)

They look the same to me. What is the difference?

Thanks!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html