Re: [Pharo-users] How to set library path for UFFI on Linux?

[Dan Wilczak]

That pointed me in the right direction, thanks. I've got it working now.

I think there's a bug there which may bite other people ---

If you have both 32-bit and 64-bit versions of the library installed,
Unix64ModuleName can find the 
32-bit version first (depending on your LD_LIBRARY_PATH) and set that as the
lib to use. Then when 
UFFI loads it, it recognizes it as 32-bit and gives up rather than looking
in any more directories. 

Dan



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

Re: [Pharo-users] PharoCloud method sources

[Esteban A. Maringolo]

It's pretty simple for small graphics. Although I'm not using it anymore.

There is also a great Seaside wrapper for Highcharts, which is more
actively used and maintained.

Esteban A. Maringolo


2017-09-22 15:04 GMT-03:00 Stephane Ducasse :
> Cool I did not know about rickshaw
>
>
>
> On Thu, Sep 21, 2017 at 9:40 PM, Esteban A. Maringolo
>  wrote:
>> 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] PharoCloud method sources

[Stephane Ducasse]

Cool I did not know about rickshaw



On Thu, Sep 21, 2017 at 9:40 PM, Esteban A. Maringolo
 wrote:
> 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] How to set library path for UFFI on Linux?

[Stephane Ducasse]

Hi dan

We are sorry that you encounter a problem.

Not sure that this is the solution but check

ffiLibraryName
^ CairoLibrary


CairoLibrary >> unix32ModuleName
"On different flavors of linux the path to library may differ
depending on OS distro or whether system is 32 or 64 bit.
Packages such as snapcraft can also change the path.
Look in a number of known locations, or LD_LIBRARY_PATH."

#('/usr/lib/i386-linux-gnu' '/usr/lib32' '/usr/lib')
, (((OSEnvironment current getEnv: 'LD_LIBRARY_PATH') ifNil: [ '' ])
substrings: ':')
do: [ :path |
| libraryPath |
libraryPath := path asFileReference / 'libcairo.so.2'.
libraryPath exists
ifTrue: [ ^ libraryPath fullName ] ].
self error: 'Cannot locate cairo library. Please check if it installed
on your system'

Better


CairoLibrary >> unix64ModuleName
"On different flavors of linux the path to library may differ
depending on OS distro or whether system is 32 or 64 bit.
Packages such as snapcraft can also change the path.
Look in a number of known locations, or LD_LIBRARY_PATH."

#('/lib/x86_64-linux-gnu' '/usr/lib')
, (((OSEnvironment current getEnv: 'LD_LIBRARY_PATH') ifNil: [ '' ])
substrings: ':')
do: [ :path |
| libraryPath |
libraryPath := path asFileReference / 'libcairo.so.2'.
libraryPath exists
ifTrue: [ ^ libraryPath fullName ] ].
self error: 'Cannot locate cairo library. Please check if it installed
on your system'

On Fri, Sep 22, 2017 at 6:37 PM, Dan Wilczak  wrote:
> I've just installed the 64-bit version of Pharo 6.1 on OpenSuse linux (64
> bit). The Athens demos fail because
> UFFI looks for libcairo in /usr/lib rather the /usr/lib64. I tried setting
> LD_LIBRARY_PATH but that has no effect.
> How can I force it to use lib64?
>
> Dan
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

[Pharo-users] How to set library path for UFFI on Linux?

[Dan Wilczak]

I've just installed the 64-bit version of Pharo 6.1 on OpenSuse linux (64
bit). The Athens demos fail because 
UFFI looks for libcairo in /usr/lib rather the /usr/lib64. I tried setting
LD_LIBRARY_PATH but that has no effect. 
How can I force it to use lib64?

Dan




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

Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems

[Stephane Ducasse]

Hi Jeff

Nice to see you. I do not know anybody running on X11. Esteban is
working on better SDL20 integration.
Did you try having a native window? I asked clement if he could
release the Wizard Battle Arena because it was a game he did in a
couple of days (yes he is good this guy) and that use cairo athens
based for drawing on native window.

stef

On Fri, Sep 22, 2017 at 3:11 PM, J.F. Rick  wrote:
> I'm running a fullscreen Pharo application on Ubuntu and I've noticed that
> Athens rendering gets way worse (maybe 10 updates per second) when I switch
> to fullscreen mode from inside Pharo. Ideally, I'd love for that to be
> fixed.
>
> In lieu of that, it would be cool if I could just maximize Pharo to the size
> of the screen to achieve good performance. Two things stop that: the Unity
> application bar and the title-bar. For the former, I can configure Unity to
> hide it. I noticed a '-notitle' X11 option when I execute pharo -help. I've
> tried using these X11 options and neither -notitle or -fullscreen seem to
> have any effect. Here's the command I run:
>
> ./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE &
>
> Pharo starts fine but neither option seems to have any effect. I've also
> tried this in GNOME, thinking that Unity was the problem. Again, no effect.
>
> Any suggestions?
>
> Jeff
>
>

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[Stephane Ducasse]

Laurent

just for the record, back in 2008-9 the largest web app in south
america in terms of users has been developed by extending
Magritte and done by Esteban (the business model was bad and it died
but not for technical reason).

Stef

On Fri, Sep 22, 2017 at 6:21 PM, Stephane Ducasse
 wrote:
> Diego
>
> I recently restarted to edit a booklet for Magritte. It would be nice
> if we can join forces.
> https://github.com/SquareBracketAssociates/Booklet-Magritte
>
> On Fri, Sep 22, 2017 at 1:27 PM, Diego Lont  wrote:
>> There is actually a tutorial included in the framework itself. One you have
>> it loaded, you can start the webpage to localhost:8080 and there you have
>> your tutorial. But this tutorial should be on a external webpage … one of
>> the things on my todo list.
>>
>> On 22 Sep 2017, at 12:55, H. Hirzel  wrote:
>>
>> On 9/18/17, laurent  wrote:
>>
>> Hi all,
>>
>> it's been a long time :) At work we are currently comparing several
>> technologies to start a business project that will hopefully be used by
>> thousands of people for several years ;)
>>
>> We need a web stack and we put Pharo & co in the comparative process.
>> My team have strong experience in  load-balanced php / mysql deployment
>> that handles millions of records  but we are ready to build on
>> something else though MySQL is still a requirement.
>>
>> Thanks for Garage + Glorp, I can prototype things. I wonder how to
>> handle database schema migrations. With our PHP projects we have
>> versionned PHP scripts that are automatically run given a database
>> revision number ( see
>> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
>> What are the practices with Glorp ?
>>
>>
>> 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. )
>>
>>
>> May be you have some other suggestions on a framework you love ?
>>
>>
>> Maybe you have a look as well at
>> https://railsexpress.quora.com/Pharo-Seaside-Express
>> (referenced in another thread).
>>
>> Use Smalltalk as modeling  / design tool and generator. Then the run
>> time is done with another technology.
>>
>>
>> Best regards,
>>
>> Laurent Laffont
>>
>>

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[Stephane Ducasse]

Laurent

do you need that we send someone to your place to help?

Stef

On Fri, Sep 22, 2017 at 10:28 AM, laurent  wrote:
> Hi Stephan,
>
> actually the difficult part is how to manage correctly Glorp
> sessions/connections and update of objects in database. My team is quite sad
> because QCMagritte and Glorp looks nice but we lack experience glueing both
> together and could not find any documentation on the subject.
>
> Laurent
>
>
> Le mer. 20 sept. 2017 à 11:53, stephan  a écrit :
>
> 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

[Pharo-users] X11 options on Ubuntu VM / Athens rendering problems

[J.F. Rick]

I'm running a fullscreen Pharo application on Ubuntu and I've noticed that
Athens rendering gets way worse (maybe 10 updates per second) when I switch
to fullscreen mode from inside Pharo. Ideally, I'd love for that to be
fixed.

In lieu of that, it would be cool if I could just maximize Pharo to the
size of the screen to achieve good performance. Two things stop that: the
Unity application bar and the title-bar. For the former, I can configure
Unity to hide it. I noticed a '-notitle' X11 option when I execute pharo
-help. I've tried using these X11 options and neither -notitle or
-fullscreen seem to have any effect. Here's the command I run:

./bin/pharo --encoding utf8 -vm-display-X11 -fullscreen PATH_TO_IMAGE &

Pharo starts fine but neither option seems to have any effect. I've also
tried this in GNOME, thinking that Unity was the problem. Again, no effect.

Any suggestions?

Jeff

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[H. Hirzel]

On 9/22/17, Diego Lont  wrote:
> There is actually a tutorial included in the framework itself.

Great!

>One you have
> it loaded, you can start the webpage to localhost:8080 and there you have
> your tutorial. But this tutorial should be on a external webpage … one of
> the things on my todo list.

No problem if the tutorial is included in the framework. I just need to know.

Where is the repository of QCMagritte?


>> On 22 Sep 2017, at 12:55, H. Hirzel  wrote:
>>
>> On 9/18/17, laurent > > wrote:
>>> Hi all,
>>>
>>> it's been a long time :) At work we are currently comparing several
>>> technologies to start a business project that will hopefully be used by
>>> thousands of people for several years ;)
>>>
>>> We need a web stack and we put Pharo & co in the comparative process.
>>> My team have strong experience in  load-balanced php / mysql deployment
>>> that handles millions of records  but we are ready to build on
>>> something else though MySQL is still a requirement.
>>>
>>> Thanks for Garage + Glorp, I can prototype things. I wonder how to
>>> handle database schema migrations. With our PHP projects we have
>>> versionned PHP scripts that are automatically run given a database
>>> revision number ( see
>>> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
>>> What are the practices with Glorp ?
>>>
>>>
>>> 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. )
>>>
>>>
>>> May be you have some other suggestions on a framework you love ?
>>
>> Maybe you have a look as well at
>> https://railsexpress.quora.com/Pharo-Seaside-Express
>> 
>> (referenced in another thread).
>>
>> Use Smalltalk as modeling  / design tool and generator. Then the run
>> time is done with another technology.
>>
>>>
>>> Best regards,
>>>
>>> Laurent Laffont
>
>

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[Diego Lont]

There is actually a tutorial included in the framework itself. One you have it 
loaded, you can start the webpage to localhost:8080 and there you have your 
tutorial. But this tutorial should be on a external webpage … one of the things 
on my todo list.

> On 22 Sep 2017, at 12:55, H. Hirzel  wrote:
> 
> On 9/18/17, laurent  > wrote:
>> Hi all,
>> 
>> it's been a long time :) At work we are currently comparing several
>> technologies to start a business project that will hopefully be used by
>> thousands of people for several years ;)
>> 
>> We need a web stack and we put Pharo & co in the comparative process.
>> My team have strong experience in  load-balanced php / mysql deployment
>> that handles millions of records  but we are ready to build on
>> something else though MySQL is still a requirement.
>> 
>> Thanks for Garage + Glorp, I can prototype things. I wonder how to
>> handle database schema migrations. With our PHP projects we have
>> versionned PHP scripts that are automatically run given a database
>> revision number ( see
>> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
>> What are the practices with Glorp ?
>> 
>> 
>> 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. )
>> 
>> 
>> May be you have some other suggestions on a framework you love ?
> 
> Maybe you have a look as well at
> https://railsexpress.quora.com/Pharo-Seaside-Express 
> 
> (referenced in another thread).
> 
> Use Smalltalk as modeling  / design tool and generator. Then the run
> time is done with another technology.
> 
>> 
>> Best regards,
>> 
>> Laurent Laffont

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[H. Hirzel]

On 9/18/17, laurent  wrote:
> Hi all,
>
> it's been a long time :) At work we are currently comparing several
> technologies to start a business project that will hopefully be used by
> thousands of people for several years ;)
>
> We need a web stack and we put Pharo & co in the comparative process.
> My team have strong experience in  load-balanced php / mysql deployment
> that handles millions of records  but we are ready to build on
> something else though MySQL is still a requirement.
>
> Thanks for Garage + Glorp, I can prototype things. I wonder how to
> handle database schema migrations. With our PHP projects we have
> versionned PHP scripts that are automatically run given a database
> revision number ( see
> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
> What are the practices with Glorp ?
>
>
> 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. )
>
>
> May be you have some other suggestions on a framework you love ?

Maybe you have a look as well at
https://railsexpress.quora.com/Pharo-Seaside-Express
(referenced in another thread).

Use Smalltalk as modeling  / design tool and generator. Then the run
time is done with another technology.

>
> Best regards,
>
> Laurent Laffont
>
>
>
>
>
>
>

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[H. Hirzel]

Hello Diego


What does QC in QCMagritte stand for?

I understand that QCMagritte is an application framework on top of
Seaside and Magritte.

I found this presentation

https://www.slideshare.net/esug/getting-started-with-qcmagritte

Is there a home page with more information?

Regards
Hannes





On 9/22/17, Diego Lont  wrote:
> Hi Laurent,
>
> I am happy that you like QCMagritte. I wrote quite some parts of it, but it
> also has been a while since I last used it. I try to support it in my spare
> time, so I will look into the issue that prevents it from loading into pharo
> 6.
>
> Here some ideas that I think of,
>
> QCMagritte is a stack based on Seaside and Magritte. So you have a choice
> wether you connect Glorp to the session management of Seaside (like Gemstone
> does, I do not know exactly) or to the update mechanism of Magritte.
>
> This updating of the object is done in the memento. You can give your
> objects a custom memento class and override here the pull // push methods
> that update your model. It actually has a commit method that commits the
> changes into the object.
>
> Note the QCMagritte already has a custom memento class, for the AJAX
> liveness, so I suggest subclassing QCAjaxMemento.
>
> Of course, you need to do something in case of a changed object, since you
> plan on running multiple images, so perhaps on validating the object (also
> controlled by the memento), you want to give some error messages, forcing
> the user to reload before committing his changes.
>
> I do not know if implementing this into the memento’s gives you proper
> performance, as potentially multiple objects are updated by one user
> action.
>
> Regards,
> Diego
>
>> On 22 Sep 2017, at 10:28, laurent  wrote:
>>
>> Hi Stephan,
>>
>> actually the difficult part is how to manage correctly Glorp
>> sessions/connections and update of objects in database. My team is quite
>> sad because QCMagritte and Glorp looks nice but we lack experience glueing
>> both together and could not find any documentation on the subject.
>>
>> Laurent
>>
>> Le mer. 20 sept. 2017 à 11:53, stephan  a écrit :
>>> 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] Web stack practices (Glorp / QCMagritte)

[Diego Lont]

Hi Laurent,

I am happy that you like QCMagritte. I wrote quite some parts of it, but it 
also has been a while since I last used it. I try to support it in my spare 
time, so I will look into the issue that prevents it from loading into pharo 6.

Here some ideas that I think of,

QCMagritte is a stack based on Seaside and Magritte. So you have a choice 
wether you connect Glorp to the session management of Seaside (like Gemstone 
does, I do not know exactly) or to the update mechanism of Magritte.

This updating of the object is done in the memento. You can give your objects a 
custom memento class and override here the pull // push methods that update 
your model. It actually has a commit method that commits the changes into the 
object.

Note the QCMagritte already has a custom memento class, for the AJAX liveness, 
so I suggest subclassing QCAjaxMemento.

Of course, you need to do something in case of a changed object, since you plan 
on running multiple images, so perhaps on validating the object (also 
controlled by the memento), you want to give some error messages, forcing the 
user to reload before committing his changes.

I do not know if implementing this into the memento’s gives you proper 
performance, as potentially multiple objects are updated by one user action.

Regards,
Diego

> On 22 Sep 2017, at 10:28, laurent  wrote:
> 
> Hi Stephan,
> 
> actually the difficult part is how to manage correctly Glorp 
> sessions/connections and update of objects in database. My team is quite sad 
> because QCMagritte and Glorp looks nice but we lack experience glueing both 
> together and could not find any documentation on the subject.
> 
> Laurent
> 
> Le mer. 20 sept. 2017 à 11:53, stephan  a écrit :
>> 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] Pharo 7 license question

[Jose San Leandro]

+1 to "recursive"

2017-09-22 11:05 GMT+02:00 Hilaire :

> I am just stating the neutral term to describe GPL license nature is
> "recursive", and why it was designed as this. The "viral" term is
> unnecessary emotionally charged.
>
> I don't fell the discussion turned about MIT vs GPL, Pharo been MIT is
> just fine.
>
> Hilaire
>
> Le 22/09/2017 à 10:40, Thierry Goubier a écrit :
>
>>
>> The appropriate and neutral term to describe GPL licence is
>> "recursive".
>>
>> GPL licence was designed to build a better computing community,
>> where freedom is 1st consideration, even at the expense of a lower
>> acceptance.
>>
>>
>> And the little technical fact that you can't link code in the Smalltalk
>> world, only create a derivative work, has nothing to do with the community
>> stance on MIT versus GPL.
>>
>>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] Pharo 7 license question

[Hilaire]

I am just stating the neutral term to describe GPL license nature is 
"recursive", and why it was designed as this. The "viral" term is 
unnecessary emotionally charged.


I don't fell the discussion turned about MIT vs GPL, Pharo been MIT is 
just fine.


Hilaire

Le 22/09/2017 à 10:40, Thierry Goubier a écrit :


The appropriate and neutral term to describe GPL licence is
"recursive".

GPL licence was designed to build a better computing community,
where freedom is 1st consideration, even at the expense of a lower
acceptance.


And the little technical fact that you can't link code in the 
Smalltalk world, only create a derivative work, has nothing to do with 
the community stance on MIT versus GPL.




--
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Pharo 7 license question

[Hilaire]

From my understanding, GPL is not about "someone else profiting from 
your work", but to enforce freedom and to accumulate contribution on GPL 
licensed code.


Regarding profit you are free to sell GPL licensed code, publicly or 
privately to one person or company, your only restriction is to provide 
the source code too to the recipient.


To protect from someone else profiting from your work there are 
effective variant from the creative commons licenses.


Hilaire


Le 21/09/2017 à 16:47, Ben Coman a écrit :
* 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]




--
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Pharo 7 license question

[Thierry Goubier]

2017-09-22 10:27 GMT+02:00 Hilaire :

> The appropriate and neutral term to describe GPL licence is "recursive".
>
> GPL licence was designed to build a better computing community, where
> freedom is 1st consideration, even at the expense of a lower acceptance.
>

And the little technical fact that you can't link code in the Smalltalk
world, only create a derivative work, has nothing to do with the community
stance on MIT versus GPL.

Thierry


>
> Hilaire
>
>
> Le 20/09/2017 à 21:30, Jimmie Houchin a écrit :
>
>> 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?
>>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[laurent]

Hi Stephan,

actually the difficult part is how to manage correctly Glorp 
sessions/connections and update of objects in database. My team is 
quite sad because QCMagritte and Glorp looks nice but we lack 
experience glueing both together and could not find any documentation 
on the subject.


Laurent

Le mer. 20 sept. 2017 à 11:53, stephan  a écrit :

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] Pharo 7 license question

[Hilaire]

The appropriate and neutral term to describe GPL licence is "recursive".

GPL licence was designed to build a better computing community, where 
freedom is 1st consideration, even at the expense of a lower acceptance.


Hilaire


Le 20/09/2017 à 21:30, Jimmie Houchin a écrit :
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?


--
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[laurent]

Hi Richard,




Laurent, I realize you are asking this on the Pharo list, looking for 
a
Pharo-specific answer. You should also post your requirements on the 
GLASS

list (http://forum.world.st/GLASS-f1460844.html). A number of
people/businesses there use a /develop on Pharo, deploy on GemStone
approach/. They will be able to give you some good advice on using
GemStone/S for your database.



My team build free (AGPL) software and we require a full open stack. 
I've read several testimonials about Gemstone qualities, nevertheless  
it could not be an option for this project.


Regards,

Laurent







 We need a web stack and we put Pharo & co in the comparative 
process.
 My team have strong experience in  load-balanced php / mysql 
deployment

 that handles millions of records  but we are ready to build on
 something else though MySQL is still a requirement.

 Thanks for Garage + Glorp, I can prototype things. I wonder how to
 handle database schema migrations. With our PHP projects we have
 versionned PHP scripts that are automatically run given a database
 revision number ( see
 http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
 What are the practices with Glorp ?


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


 May be you have some other suggestions on a framework you love ?


 Best regards,

 Laurent Laffont






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