[Pharo-users] PetitParser Mystery

[Sean P. DeNigris]

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

Re: [Pharo-users] (no subject)

[Stephan Eggermont]

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


Stephan

Re: [Pharo-users] (no subject)

[Stephan Eggermont]

On 20/09/17 12:17, Christophe Demarey wrote:

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/).


Pharo7 64 bit starts fine on Mac.
Good work.

Stephan

Re: [Pharo-users] Pharo 7 license question

[Jimmie Houchin]

Please, feel free to participate. You are not hijacking anything, you 
are voicing your opinion and participating in the community. This is 
good. We don't all have to have the same opinion or values. People 
expressing their opinion is a valuable part of any community. We may 
agree or disagree, but it helps in understanding each other.


Here is how I view this.

GPL restricts my rights as a "user" to preserve the rights of the 
author. I (author) do not want you (user) to use my software in any way 
that I (author) do not approve of.


GPL is viral. It is not viral because of what it wants to preserve. It 
is viral because in many cases it compels (forces) users to change the 
license of the software in their system to the GPL. This is why Pharo 
can not use GPL. Because it would force all of Pharo to become GPL. This 
is expressly what the authors of the GPL wanted. It is expressly what 
the authors of Pharo do not want.


It is viral because of what it does, how it behaves, what it forces. Not 
because of what it preserves. The viral nature isn't preserving the 
original GPL software, but rather infecting somebody else's software. 
Which is why I asked my question. If I ported GPL software would that 
license affect anything more than what I wrote. The most common answer 
was YES. It would affect everything or infect everything.


I don't care about a small piece being GPL. I care about how it impacts 
the bigger piece.


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.


Enough rambling. Even though we very much disagree. Do not be silent. 
Participate. We all learn.


Jimmie



On 09/20/2017 02:57 PM, Jose San Leandro wrote:

Hi,

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

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.
I'd say "effective against people trying to restrict the rights the 
GPL defends" instead of "viral".
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.


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.


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 

Re: [Pharo-users] Continued Fractions

[Stephane Ducasse]

I wish you a lot of luck on this experience!


On Tue, Sep 19, 2017 at 10:51 PM, p...@highoctane.be  wrote:
> I need to match print ads sizes from various publications with a
> standardized list of ratios (e.g. 2:1, 1:1, 2:7...) plus a bunch of other
> metrics.
>
> So  a rect of 1543@331 gives a float value that has can be best approximated
> by a continued fraction approach.
>
> But there are other complications. Now I am using a lookup table and try to
> match with just a distance.
>
> I am using DataFrame and hopefully more Roassal for all of this.
>
> Pharo can be a good tool to manage the object model of this problem space. I
> am prototyping something. We'll see how far I can get.
>
> Phil
>
> On Tue, Sep 19, 2017 at 9:30 PM, Stephane Ducasse 
> wrote:
>>
>> Hi phil
>>
>> just out of sane curiosity do you have a pointer on ratio and
>> rectangle and continued fraction?
>>
>> Stef
>>
>> On Mon, Sep 18, 2017 at 12:40 PM, werner kassens 
>> wrote:
>> > Hi Phil,
>> > yes, in polymath it is the the object PMContinuedFraction.
>> > werner
>> >
>> >
>> > On 09/17/2017 08:38 PM, p...@highoctane.be wrote:
>> >
>> > Ah, I see there is something in the Numerical Methods book. :rolleyes:
>> >
>> > Phil
>> >
>> > On Sun, Sep 17, 2017 at 8:30 PM, p...@highoctane.be 
>> > wrote:
>> >>
>> >> Do we have anything related to continued fractions in Pharo?
>> >>
>> >> https://en.wikipedia.org/wiki/Continued_fraction
>> >>
>> >> I need that to match rectanges to aspect ratios etc.
>> >>
>> >> TIA
>> >> Phil
>> >
>> >
>> >
>>
>>
>

Re: [Pharo-users] Pharo 7 license question

[Jose San Leandro]

Hi,

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

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.
I'd say "effective against people trying to restrict the rights the GPL
defends" instead of "viral".
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.

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.

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 using said terminology.
>
> So my question to you. What words would you use instead of viral and
> infection that equally describe that characteristic of the GPL and variants?
>
> Thanks.
>
> Jimmie
>
> On 09/20/2017 02:10 PM, Jose San Leandro wrote:
>
> Nothing to add to the particular question, but I'm writing to express how
> much I disagree when you use adjectives such as "viral" or nouns such as
> "infection" to describe GPL.
>
> I'm a FSF supporter for a long time, and while I'm used to people choosing
> not to use free software licenses for the sake of reaching as many business
> opportunities as possible, I care about the ethics behind the free software
> movement.
>
> I respect people not caring about that fundamental part of the Free
> Software movement, but I cannot remain silent when everybody seems to share
> the same unfortunate interpretation of what the GPL is about.
>
> 2017-09-17 18:59 GMT+02:00 Ben Coman :
>
>> On Sun, Sep 17, 2017 at 7:00 PM, stephan  wrote:
>> >
>> > On 17-09-17 06:59, Jimmie Houchin wrote:
>> >>
>> >> And the GPL not be viral in my app provided I only use the GPL library
>> and am not modifying it in my app.
>> >>
>> >> Do I understand this wrong?
>> >
>> >
>> > Yes. With GPL everything is now GPL. With LGPL, as long as you only
>> link to it,
>> > the viral aspect is limited to the library. In Pharo, that means you
>> can use UFFI
>> > to connect to LGPL libraries, and you can probably create plugins.
>> Loading
>> > smalltalk libraries that are LGPL is not exactly the same as linking,
>> there is
>> > no clear boundary between compile-time and run-time, as everything is
>> in the image.
>> > That makes the LGPL difficult to interpret in the smalltalk case, and
>> potentially viral.
>>
>> +1.
>>
>>
>> On Sun, Sep 17, 2017 at 6:09 PM, Hilaire  wrote:
>> > Regarding porting GPL software, I guess you mean rewriting with
>> Smalltalk,
>> > you should be free to license it as you want, for example as MIT.
>> > AFAIK there is no evil restriction as "seen the code" under the GPL.
>>
>> It is not as clean as that.  Many consider "seen the code" to
>> implicate "derived code".  Whether a court of law agrees with this or
>> not is not what you should consider.   The best advice I received from
>> a lawyer is that winning in court (sometimes after years of effort) is
>> still a loss, so you should position yourself so that no one even
>> thinks they can take you court.
>>
>>
>> > For library, alternative is LGPL and I read this interesting note:
>> > One should note that subclassing a Java (or other OO) class licensed
>> under the LGPL is regarded as a use of an interface of a library comparable
>> to a function call of a library. 

Re: [Pharo-users] Pharo 7 license question

[Sven Van Caekenberghe]

> On 20 Sep 2017, at 21:10, Jose San Leandro  wrote:
> 
> Nothing to add to the particular question, but I'm writing to express how 
> much I disagree when you use adjectives such as "viral" or nouns such as 
> "infection" to describe GPL.
> 
> I'm a FSF supporter for a long time, and while I'm used to people choosing 
> not to use free software licenses for the sake of reaching as many business 
> opportunities as possible, I care about the ethics behind the free software 
> movement.
> 
> I respect people not caring about that fundamental part of the Free Software 
> movement, but I cannot remain silent when everybody seems to share the same 
> unfortunate interpretation of what the GPL is about.

I agree, well said.

On ethical grounds I would certainly choose a modern GPL (like AGPLv3). I want 
my work to benefit the public and remain like that. The fact that someone can 
take it and sell it goes against the idea of open source.

But for a Smalltalk system aiming to commercial use, MIT is the only way 
forward.

> 2017-09-17 18:59 GMT+02:00 Ben Coman :
> On Sun, Sep 17, 2017 at 7:00 PM, stephan  wrote:
> >
> > On 17-09-17 06:59, Jimmie Houchin wrote:
> >>
> >> And the GPL not be viral in my app provided I only use the GPL library and 
> >> am not modifying it in my app.
> >>
> >> Do I understand this wrong?
> >
> >
> > Yes. With GPL everything is now GPL. With LGPL, as long as you only link to 
> > it,
> > the viral aspect is limited to the library. In Pharo, that means you can 
> > use UFFI
> > to connect to LGPL libraries, and you can probably create plugins. Loading
> > smalltalk libraries that are LGPL is not exactly the same as linking, there 
> > is
> > no clear boundary between compile-time and run-time, as everything is in 
> > the image.
> > That makes the LGPL difficult to interpret in the smalltalk case, and 
> > potentially viral.
> 
> +1.
> 
> 
> On Sun, Sep 17, 2017 at 6:09 PM, Hilaire  wrote:
> > Regarding porting GPL software, I guess you mean rewriting with Smalltalk,
> > you should be free to license it as you want, for example as MIT.
> > AFAIK there is no evil restriction as "seen the code" under the GPL.
> 
> It is not as clean as that.  Many consider "seen the code" to
> implicate "derived code".  Whether a court of law agrees with this or
> not is not what you should consider.   The best advice I received from
> a lawyer is that winning in court (sometimes after years of effort) is
> still a loss, so you should position yourself so that no one even
> thinks they can take you court.
> 
> 
> > For library, alternative is LGPL and I read this interesting note:
> > One should note that subclassing a Java (or other OO) class licensed under 
> > the LGPL is regarded as a use of an interface of a library comparable to a 
> > function call of a library. It is not regarded as a modification of the 
> > original class. Therefore the subclass does not fall under the requirements 
> > of the LGPL.
> 
> The definitive reference of Java + LGPL is
> https://www.gnu.org/licenses/lgpl-java.en.html
> which says: "The typical arrangement for Java is that each library an
> application uses is distributed as a separate JAR (Java Archive) file.
> Applications use Java's “import” functionality to access classes from
> these libraries ... The LGPL permits this distribution ...
> Applications need only follow the requirements in section 6 of the
> LGPL"
> 
> but a Smalltalk Image runs foul of section 6 requiring... "A suitable
> [shared library] mechanism ... that (1) uses at run time a copy of the
> library already present on the user's computer system, rather than
> copying library functions into the executable"  where an Image is
> considered to be the "executable".
> 
> So incorporating LGPL Smalltalk code into an Image causes all code in
> the Image to be infected with the LGPL.
> 
> 
> > So using a LGPL library, even extending it, does not force the user to be 
> > in the GPL family license.
> 
> Using LGPL C libraries is fine and doesn't infect your Smalltalk code.
> Using LGPL Smalltalk libraries does infect all Smalltalk code in your
> Image. The concern is contributing a bug fixed in Pharo code from an
> infected image technically infects the  whole of Pharo - although you
> are free to update a clean image with the same bug fix and contribute
> from there - but thats an awkward process.
> 
> 
> > The only restriction is the receiver should be capable to update
> > the LGPL package independently of the application using the package.
> > Anyway, I don't think you should worried about porting GPL/LGPL libraries 
> > as long
> > as your are rewriting it. You can license it under MIT. Then LGPL is also 
> > possible.
> 
> The term "port" clearly implies "derived" so you cannot arbitrarily
> re-license just by changing implementation languages. Otherwise for
> example a GPL library could be relicensed by one team 

Re: [Pharo-users] Pharo 7 license question

[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 using said terminology.


So my question to you. What words would you use instead of viral and 
infection that equally describe that characteristic of the GPL and variants?


Thanks.

Jimmie


On 09/20/2017 02:10 PM, Jose San Leandro wrote:
Nothing to add to the particular question, but I'm writing to express 
how much I disagree when you use adjectives such as "viral" or nouns 
such as "infection" to describe GPL.


I'm a FSF supporter for a long time, and while I'm used to people 
choosing not to use free software licenses for the sake of reaching as 
many business opportunities as possible, I care about the ethics 
behind the free software movement.


I respect people not caring about that fundamental part of the Free 
Software movement, but I cannot remain silent when everybody seems to 
share the same unfortunate interpretation of what the GPL is about.


2017-09-17 18:59 GMT+02:00 Ben Coman >:


On Sun, Sep 17, 2017 at 7:00 PM, stephan > wrote:
>
> On 17-09-17 06:59, Jimmie Houchin wrote:
>>
>> And the GPL not be viral in my app provided I only use the GPL
library and am not modifying it in my app.
>>
>> Do I understand this wrong?
>
>
> Yes. With GPL everything is now GPL. With LGPL, as long as you
only link to it,
> the viral aspect is limited to the library. In Pharo, that means
you can use UFFI
> to connect to LGPL libraries, and you can probably create
plugins. Loading
> smalltalk libraries that are LGPL is not exactly the same as
linking, there is
> no clear boundary between compile-time and run-time, as
everything is in the image.
> That makes the LGPL difficult to interpret in the smalltalk
case, and potentially viral.

+1.


On Sun, Sep 17, 2017 at 6:09 PM, Hilaire > wrote:
> Regarding porting GPL software, I guess you mean rewriting with
Smalltalk,
> you should be free to license it as you want, for example as MIT.
> AFAIK there is no evil restriction as "seen the code" under the GPL.

It is not as clean as that.  Many consider "seen the code" to
implicate "derived code".  Whether a court of law agrees with this or
not is not what you should consider.   The best advice I received from
a lawyer is that winning in court (sometimes after years of effort) is
still a loss, so you should position yourself so that no one even
thinks they can take you court.


> For library, alternative is LGPL and I read this interesting note:
> One should note that subclassing a Java (or other OO) class
licensed under the LGPL is regarded as a use of an interface of a
library comparable to a function call of a library. It is not
regarded as a modification of the original class. Therefore the
subclass does not fall under the requirements of the LGPL.

The definitive reference of Java + LGPL is
https://www.gnu.org/licenses/lgpl-java.en.html

which says: "The typical arrangement for Java is that each library an
application uses is distributed as a separate JAR (Java Archive) file.
Applications use Java's “import” functionality to access classes from
these libraries ... The LGPL permits this distribution ...
Applications need only follow the requirements in section 6 of the
LGPL"

but a Smalltalk Image runs foul of section 6 requiring... "A suitable
[shared library] mechanism ... that (1) uses at run time a copy of the
library already present on the user's computer system, rather than
copying library functions into the executable"  where an Image is
considered to be the "executable".

So incorporating LGPL Smalltalk code into an Image causes all code in
the Image to be infected with the LGPL.


> So using a LGPL library, even extending it, does not force the
user to be in the GPL family license.

Using LGPL C libraries is 

Re: [Pharo-users] ZnHtmlOutputStream Attributes

[Sven Van Caekenberghe]

> On 20 Sep 2017, at 20:36, Sean P. DeNigris  wrote:
> 
> Any reason to pass as a flat collection of pairs rather than a collection of
> associations or a dictionary? IMHO the former is less intention revealing
> and potentially confusing…

I probably did it because it was the least amount of typing.

Right now,

  html tag: #div attributes: #(class menu id one) with: 'Foo'.

generates

  Foo

Associations would indeed also work, like

  html tag: #div attributes: { #class->#menu. #id->#one } with: 'Foo'.

Since Dictionary>>#do: runs over Associations, a real dictionary would also 
work then.

It is still a bit more to type, but it is clearer.

Sven

Re: [Pharo-users] Pharo 7 license question

[Jose San Leandro]

Nothing to add to the particular question, but I'm writing to express how
much I disagree when you use adjectives such as "viral" or nouns such as
"infection" to describe GPL.

I'm a FSF supporter for a long time, and while I'm used to people choosing
not to use free software licenses for the sake of reaching as many business
opportunities as possible, I care about the ethics behind the free software
movement.

I respect people not caring about that fundamental part of the Free
Software movement, but I cannot remain silent when everybody seems to share
the same unfortunate interpretation of what the GPL is about.

2017-09-17 18:59 GMT+02:00 Ben Coman :

> On Sun, Sep 17, 2017 at 7:00 PM, stephan  wrote:
> >
> > On 17-09-17 06:59, Jimmie Houchin wrote:
> >>
> >> And the GPL not be viral in my app provided I only use the GPL library
> and am not modifying it in my app.
> >>
> >> Do I understand this wrong?
> >
> >
> > Yes. With GPL everything is now GPL. With LGPL, as long as you only link
> to it,
> > the viral aspect is limited to the library. In Pharo, that means you can
> use UFFI
> > to connect to LGPL libraries, and you can probably create plugins.
> Loading
> > smalltalk libraries that are LGPL is not exactly the same as linking,
> there is
> > no clear boundary between compile-time and run-time, as everything is in
> the image.
> > That makes the LGPL difficult to interpret in the smalltalk case, and
> potentially viral.
>
> +1.
>
>
> On Sun, Sep 17, 2017 at 6:09 PM, Hilaire  wrote:
> > Regarding porting GPL software, I guess you mean rewriting with
> Smalltalk,
> > you should be free to license it as you want, for example as MIT.
> > AFAIK there is no evil restriction as "seen the code" under the GPL.
>
> It is not as clean as that.  Many consider "seen the code" to
> implicate "derived code".  Whether a court of law agrees with this or
> not is not what you should consider.   The best advice I received from
> a lawyer is that winning in court (sometimes after years of effort) is
> still a loss, so you should position yourself so that no one even
> thinks they can take you court.
>
>
> > For library, alternative is LGPL and I read this interesting note:
> > One should note that subclassing a Java (or other OO) class licensed
> under the LGPL is regarded as a use of an interface of a library comparable
> to a function call of a library. It is not regarded as a modification of
> the original class. Therefore the subclass does not fall under the
> requirements of the LGPL.
>
> The definitive reference of Java + LGPL is
> https://www.gnu.org/licenses/lgpl-java.en.html
> which says: "The typical arrangement for Java is that each library an
> application uses is distributed as a separate JAR (Java Archive) file.
> Applications use Java's “import” functionality to access classes from
> these libraries ... The LGPL permits this distribution ...
> Applications need only follow the requirements in section 6 of the
> LGPL"
>
> but a Smalltalk Image runs foul of section 6 requiring... "A suitable
> [shared library] mechanism ... that (1) uses at run time a copy of the
> library already present on the user's computer system, rather than
> copying library functions into the executable"  where an Image is
> considered to be the "executable".
>
> So incorporating LGPL Smalltalk code into an Image causes all code in
> the Image to be infected with the LGPL.
>
>
> > So using a LGPL library, even extending it, does not force the user to
> be in the GPL family license.
>
> Using LGPL C libraries is fine and doesn't infect your Smalltalk code.
> Using LGPL Smalltalk libraries does infect all Smalltalk code in your
> Image. The concern is contributing a bug fixed in Pharo code from an
> infected image technically infects the  whole of Pharo - although you
> are free to update a clean image with the same bug fix and contribute
> from there - but thats an awkward process.
>
>
> > The only restriction is the receiver should be capable to update
> > the LGPL package independently of the application using the package.
> > Anyway, I don't think you should worried about porting GPL/LGPL
> libraries as long
> > as your are rewriting it. You can license it under MIT. Then LGPL is
> also possible.
>
> The term "port" clearly implies "derived" so you cannot arbitrarily
> re-license just by changing implementation languages. Otherwise for
> example a GPL library could be relicensed by one team porting from C
> to Python, then a second independent team ports from Python back to C
> subverting the original copyright.
>
>
> ===
> Hmmm... actually refreshing myself with the newer license texts just now
> I notice GPL 3 has added some interesting definitions the GPL 2 lacks...
>
> >  The “Corresponding Source” for a work ... does not include the work's
> System Libraries
> >
> > The “System Libraries” of an executable work include anything, other
> than the work as a 

[Pharo-users] ZnHtmlOutputStream Attributes

[Sean P. DeNigris]

Any reason to pass as a flat collection of pairs rather than a collection of
associations or a dictionary? IMHO the former is less intention revealing
and potentially confusing…



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

[Pharo-users] Call for Participation: SLE 2017 (10th ACM SIGPLAN International Conference on Software Language Engineering)

[Andrei Chis]

** Call for Participation **

10th ACM SIGPLAN International Conference on Software Language Engineering
(SLE 2017)

23-24 October 2017, Vancouver, Canada

(Collocated with SPLASH 2017)

http://conf.researchr.org/track/sle-2017/sle-2017-papers
http://www.sleconf.org/2017
Follow us on twitter: https://twitter.com/sleconf



Software Language Engineering (SLE) is the application of systematic,
disciplined, and measurable approaches to the development, use, deployment,
and maintenance of software languages. The term "software language" is used
broadly, and includes: general-purpose programming languages;
domain-specific languages (e.g. BPMN, Simulink, Modelica); modeling and
metamodeling languages (e.g. SysML and UML); data models and ontologies
(e.g. XML-based and OWL-based languages and vocabularies).


** REGISTRATION **

Friday, 22 September 2017 (Early Registration Deadline)
Contact: i...@splashcon.org
http://2017.splashcon.org/attending/registration

** VENUE **

Hyatt Regency Vancouver
Hotel reservations: https://2017.splashcon.org/venue/hyattregency


## Program Highlights

### Keynote

-  Peter D. Mosses
   Engineering meta-languages for specifying software languages

https://conf.researchr.org/track/sle-2017/sle-2017-papers#Keynote-Peter-D-Mosses

### Awards

During the conference, we will announce the following awards:

- Distinguished paper. Award for most notable paper, as determined by the
PC chairs based on the recommendations of the program committee.

- Distinguished reviewer. Award for distinguished reviewer, as determined
by the PC chairs using feedback from the authors.

- Distinguished artefact. Award for the artifact most significantly
exceeding expectations, as determined by the AEC chairs based on the
recommendations of the artifact evaluation committee. Sponsored by Raincode.


### Accepted Papers

- Metacasanova: an optimized meta-compiler for Domain-Specific Languages,
  Francesco Di Giacomo, Mohamed Abbadi, Agostino Cortesi, Pieter Spronck,
Giuseppe Maggiore

- Safe Modular Parsing,
  Haoyuan Zhang, Huang Li, Bruno C. d. S. Oliveira

- Concrete Syntax: A Multi-Paradigm Approach,
  Yentl Van Tendeloo, Simon Van Mierlo, Bart Meyers, Hans Vangheluwe

- A Domain-Specific Controlled English Language for Automated Regulatory
Compliance,
  Suman Roychoudhury, Sagar Sunkle, Deepali Kholkar, Vinay Kulkarni

- Debugging with Domain-Specific Events,
  Xiangqi Li, Matthew Flatt

- Deep Priority Conflicts in the Wild - A Pilot Study,
  Luís Eduardo de Souza Amorim, Michael J. Steindorfer, Eelco Visser

- Comparison of the Expressiveness and Performance of Template-based Code
Generation Tools,
  Lechanceux Luhunu, Eugene Syriani

- Incremental Packrat Parsing,
  Patrick Dubroy, Alessandro Warth

- Ensuring Non-interference of Composable Language Extensions,
  Ted Kaminski, Eric Van Wyk

- A Formalisation of Parameterised Reference Attribute Grammars,
  Scott Buckley, Anthony Sloane

- A Symbol-based Extension of Parsing Expression Grammars and
Context-Sensitive Packrat Parsing,
  Kimio Kuramitsu

- Structural Model Subtyping with OCL Constraints,
  Artur Boronat

- A Requirements Engineering Approach for Usability-Driven DSL Development,
  Ankica Barisic, Dominique Blouin, Vasco Amaral, Miguel Goulao

- Tool Demonstration: A development environment for the Alf language within
the MagicDraw UML tool,
  Ed Seidewitz

- FlowSpec: Declarative Dataflow Analysis Specification,
  Jeff Smits, Eelco Visser

- Robust Programs with Filtered Iterators,
  Jiasi Shen, Martin Rinard

- Energy Efficiency across Programming Languages: How does energy, time,
and memory relate?,
  Rui Pereira, Marco Couto, Francisco Ribeiro, Rui Rua, Jácome Cunha, João
Paulo Fernandes, João Saraiva

- Concurrent Circular Reference Attribute Grammars,
  Jesper Öqvist, Görel Hedin

- Better Call the Crowd. Using Crowdsourcing to Shape your Domain-Specific
Languages,
  Marco Brambilla, Jordi Cabot, Javier Luis Canovas Izquierdo, Andrea Mauri

- Robust Projectional Editing,
  Friedrich Steimann, Marcus Frenkel, Markus Voelter

- Towards a Taxonomy of Grammar Smells,
  Mats Stijlaart, Vadim Zaytsev

- Red Shift: Procedural Shift-Reduce Parsing,
  Nicolas Laurent

- Virtual Textual Model Composition for Supporting Maintenance and
Aspect-Orientation,
  Robert Bill, Patrick Neubauer, Manuel Wimmer

- A Chrestomathy of DSL implementations,
  Simon Schauss, Ralf Lämmel, Johannes Härtel, Marcel Heinz, Kevin Klein,
Lukas Härtel, Thorsten Berger

Re: [Pharo-users] (no subject)

[Christophe Demarey]

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] Web stack practices (Glorp / QCMagritte)

[stephan]

On 18-09-17 12:22, laurent wrote:
We try QCMagritte and we enjoy what we see so far. What are the best 
practices to glue Magritte and Glorp together ? Especially when you 
load-balance requests on several images. Some examples ?


( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable 
version, MADescriptionBuilder missing. For #development versions of 
Magritte and QCMagritte, QCConfiguration missing ). So actually I use 
the one built on CI. )


I really like describing domain objects with Magritte and using chains 
of visitors to add cross-cutting concerns like translations, styling and 
access control. The resulting domain code is very clean and DRY. To map 
to database/Glorp I would just add properties to the description 
wherever needed, and add a visitor creating the mappings. We didn't need 
that as we developed in Pharo and deployed on Gemstone.


At the moment QC generates applications using jQuery, and the live 
updating needs a round-trip to the server. You might want to substitute 
that with something that does more client side. I haven't looked in 
detail at what Johan Brichau is doing.


An open issue is live updates that update each other. That needs 
automatically calculating dependencies and update order.


I've copied the latest configuration and added #'pharo6.x' but that is 
not enough.


Stephan

Re: [Pharo-users] (no subject)

[stephan]

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] Smalltalk gets a reference in fastcompany Kay interview

[Bruce O'Neel]

Hi,  
  
I believe this is the same article:  
  
[https://www.fastcompany.com/40435064/what-alan-kay-thinks-about-the-iphone-and-technology-now](https://www.fastcompany.com/40435064/what-alan-kay-thinks-about-the-iphone-and-technology-now)
  
  
which requires no login.  
  
cheers  
  
bruce  

> Yes I also used the one time email link or the iPhone app as I don't use 
> Facebook or a google login either.   
>   
>  Sent from my iPhone   
>   
>  > On 20 Sep 2017, at 02:54, Holger Freyther  wrote:   
>  >   
>  >   
>  >> On 20. Sep 2017, at 06:43, Offray  wrote:   
>  >   
>  > Hey!   
>  >   
>  >   
>  >   
>  >> Its a shame nog being able to read the article, because it is not posted 
> in the open web and I don't have Facebook or Google to pay with my privacy 
> for the "privilege" of reading Fast Company.   
>  >   
>  >   
>  > sign-up by email is possible as well, probably with a one time email 
> address? The link is below their google sign-in button.   
>  >   
>  >   
>  > cheers   
>  >holger
  
  

Re: [Pharo-users] Smalltalk gets a reference in fastcompany Kay interview

[Tim Mackinnon]

Yes I also used the one time email link or the iPhone app as I don't use 
Facebook or a google login either.

Sent from my iPhone

> On 20 Sep 2017, at 02:54, Holger Freyther  wrote:
> 
> 
>> On 20. Sep 2017, at 06:43, Offray  wrote:
> 
> Hey!
> 
> 
> 
>> Its a shame nog being able to read the article, because it is not posted in 
>> the open web and I don't have Facebook or Google to pay with my privacy for 
>> the "privilege" of reading Fast Company.
> 
> 
> sign-up by email is possible as well, probably with a one time email address? 
> The link is below their google sign-in button.
> 
> 
> cheers
>holger

Re: [Pharo-users] (no subject)

[Ben Coman]

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