Re: [Pharo-users] Pharo productivity

[Norbert Hartl]

Sure but the deployment issue is orchestration.  The distribution of 
functionality works along the available resources. The example machine Sven 
mentioned (32 cores, 96 MB) is worth nothing if you have a lot of instances and 
spindle hard discs. It is an act of finding the balance that uses the maximum 
of all resources. You just need to decrease the role of the weakest link. 
Modern containers are just about making it comfortable but not solving the 
"real" problems.

My 2 cents,

Norbert

> Am 30.11.2015 um 22:52 schrieb "p...@highoctane.be" :
> 
> Yes but are they working as nicely on Macs and Win boxes running 
> Dockermachine?
> 
> Phil
> 
>> On Mon, Nov 30, 2015 at 9:48 PM, Sven Van Caekenberghe  wrote:
>> LXC/LXD containers are much nicer, IMHO, as they look and feel like a 
>> regular VM, yet are way more efficient.
>> 
>> > On 30 Nov 2015, at 21:43, Esteban A. Maringolo  
>> > wrote:
>> >
>> > Do you have a recipe to put Pharo in a Docker container?
>> > Esteban A. Maringolo
>> >
>> >
>> > 2015-11-30 17:34 GMT-03:00 p...@highoctane.be :
>> >> I have been using Pharo somewhat less in my current projects.
>> >>
>> >> Nevertheless, I needed a tool done fast and behaving correctly.
>> >>
>> >> Did it the TDD way with Pharo.
>> >>
>> >> Great experience. Great productivity. No messing around with external
>> >> libraries, modules...
>> >>
>> >> 64-bit Linux compatibility would really help these days. But stuffing 
>> >> Pharo
>> >> and 32 bit on a docker container works nicely too.
>> >>
>> >> Phil
>> >
> 

Re: [Pharo-users] Pharo productivity

[Sven Van Caekenberghe]

> On 30 Nov 2015, at 22:08, Norbert Hartl  wrote:
> 
> true. We use them a lot

Good to know, we're currently deploying an upgrade to our server park, all new 
machines (32 cores, 96 Gb RAM each) will be running many LXC/LXD instances, 
probably using ZFS for their storage. The networking was the biggest challenge, 
but I think we got that covered. In any case, Pharo ran perfectly on them 
(either 32 or 64 bit) !

If we get stuck on something, I will know who I can beg for help ;-)

> +1
> 
> Norbert
> 
>> Am 30.11.2015 um 21:48 schrieb Sven Van Caekenberghe :
>> 
>> LXC/LXD containers are much nicer, IMHO, as they look and feel like a 
>> regular VM, yet are way more efficient.
>> 
>>> On 30 Nov 2015, at 21:43, Esteban A. Maringolo  wrote:
>>> 
>>> Do you have a recipe to put Pharo in a Docker container?
>>> Esteban A. Maringolo
>>> 
>>> 
>>> 2015-11-30 17:34 GMT-03:00 p...@highoctane.be :
 I have been using Pharo somewhat less in my current projects.
 
 Nevertheless, I needed a tool done fast and behaving correctly.
 
 Did it the TDD way with Pharo.
 
 Great experience. Great productivity. No messing around with external
 libraries, modules...
 
 64-bit Linux compatibility would really help these days. But stuffing Pharo
 and 32 bit on a docker container works nicely too.
 
 Phil
>> 
>> 
> 

Re: [Pharo-users] Pharo productivity

[Norbert Hartl]

true. We use them a lot

+1

Norbert

> Am 30.11.2015 um 21:48 schrieb Sven Van Caekenberghe :
> 
> LXC/LXD containers are much nicer, IMHO, as they look and feel like a regular 
> VM, yet are way more efficient.
> 
>> On 30 Nov 2015, at 21:43, Esteban A. Maringolo  wrote:
>> 
>> Do you have a recipe to put Pharo in a Docker container?
>> Esteban A. Maringolo
>> 
>> 
>> 2015-11-30 17:34 GMT-03:00 p...@highoctane.be :
>>> I have been using Pharo somewhat less in my current projects.
>>> 
>>> Nevertheless, I needed a tool done fast and behaving correctly.
>>> 
>>> Did it the TDD way with Pharo.
>>> 
>>> Great experience. Great productivity. No messing around with external
>>> libraries, modules...
>>> 
>>> 64-bit Linux compatibility would really help these days. But stuffing Pharo
>>> and 32 bit on a docker container works nicely too.
>>> 
>>> Phil
> 
> 

Re: [Pharo-users] Pharo productivity

[p...@highoctane.be]

Yes but are they working as nicely on Macs and Win boxes running
Dockermachine?

Phil

On Mon, Nov 30, 2015 at 9:48 PM, Sven Van Caekenberghe  wrote:

> LXC/LXD containers are much nicer, IMHO, as they look and feel like a
> regular VM, yet are way more efficient.
>
> > On 30 Nov 2015, at 21:43, Esteban A. Maringolo 
> wrote:
> >
> > Do you have a recipe to put Pharo in a Docker container?
> > Esteban A. Maringolo
> >
> >
> > 2015-11-30 17:34 GMT-03:00 p...@highoctane.be :
> >> I have been using Pharo somewhat less in my current projects.
> >>
> >> Nevertheless, I needed a tool done fast and behaving correctly.
> >>
> >> Did it the TDD way with Pharo.
> >>
> >> Great experience. Great productivity. No messing around with external
> >> libraries, modules...
> >>
> >> 64-bit Linux compatibility would really help these days. But stuffing
> Pharo
> >> and 32 bit on a docker container works nicely too.
> >>
> >> Phil
> >
>
>
>
>

Re: [Pharo-users] Pharo productivity

[Norbert Hartl]

:) Well, looking at all the isolation containers I still have doubts that 
isolation is working as expected. There are many influences that make 
containers less independent. Prominent candidate is (as always) I/O that has 
the ability to slow down everything.
But let's talk! I always appreciate exchanging thoughts ans experiences with 
you :)

Norbert

> Am 30.11.2015 um 22:28 schrieb Sven Van Caekenberghe :
> 
> 
>> On 30 Nov 2015, at 22:08, Norbert Hartl  wrote:
>> 
>> true. We use them a lot
> 
> Good to know, we're currently deploying an upgrade to our server park, all 
> new machines (32 cores, 96 Gb RAM each) will be running many LXC/LXD 
> instances, probably using ZFS for their storage. The networking was the 
> biggest challenge, but I think we got that covered. In any case, Pharo ran 
> perfectly on them (either 32 or 64 bit) !
> 
> If we get stuck on something, I will know who I can beg for help ;-)
> 
>> +1
>> 
>> Norbert
>> 
>>> Am 30.11.2015 um 21:48 schrieb Sven Van Caekenberghe :
>>> 
>>> LXC/LXD containers are much nicer, IMHO, as they look and feel like a 
>>> regular VM, yet are way more efficient.
>>> 
 On 30 Nov 2015, at 21:43, Esteban A. Maringolo  
 wrote:
 
 Do you have a recipe to put Pharo in a Docker container?
 Esteban A. Maringolo
 
 
 2015-11-30 17:34 GMT-03:00 p...@highoctane.be :
> I have been using Pharo somewhat less in my current projects.
> 
> Nevertheless, I needed a tool done fast and behaving correctly.
> 
> Did it the TDD way with Pharo.
> 
> Great experience. Great productivity. No messing around with external
> libraries, modules...
> 
> 64-bit Linux compatibility would really help these days. But stuffing 
> Pharo
> and 32 bit on a docker container works nicely too.
> 
> Phil
> 
> 

Re: [Pharo-users] Pharo productivity

[p...@highoctane.be]

https://github.com/Geal/pharo-seaside-docker-example
https://www.clever-cloud.com/blog/guests/2015/01/05/smalltalk-in-the-cloud/

Phil


On Mon, Nov 30, 2015 at 9:43 PM, Esteban A. Maringolo 
wrote:

> Do you have a recipe to put Pharo in a Docker container?
> Esteban A. Maringolo
>
>
> 2015-11-30 17:34 GMT-03:00 p...@highoctane.be :
> > I have been using Pharo somewhat less in my current projects.
> >
> > Nevertheless, I needed a tool done fast and behaving correctly.
> >
> > Did it the TDD way with Pharo.
> >
> > Great experience. Great productivity. No messing around with external
> > libraries, modules...
> >
> > 64-bit Linux compatibility would really help these days. But stuffing
> Pharo
> > and 32 bit on a docker container works nicely too.
> >
> > Phil
>
>
>

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

[Christophe Demarey]

Hi,

Le 29 nov. 2015 à 20:00, Dimitris Chloupis a écrit :

> And there lies the trap.
> 
> If you end up making something that works with everything, you will create 
> something that just works with everything instead of something that works 
> very well with one thing.

could be. But we do not want to plug everything. Just having the door opened 
for the next cool VCS.
Even if is only used for git it is good to have a Pharo API that is not the GIT 
API. We do not want git calls mixed everywhere. We want a clean and clear API 
for versioning.
This API also prevents you from git API changes. You will only have one place 
to update and so on.

> Right now Git is by very far the undisputed king of version control and has 
> completely dethroned SVN. 

King because widely used but other are also as valuable if not more.

> Ironically the things that make git integration in pharo so hard is all the 
> thing that are there to decouple it from git , like filetree metadata , or 
> continuous support for mcz and monticello. 

I do not agree on this point. There is no VCS interoperability layer in Pharo. 
Tools are directly manipulating Monticello.

> In the end you cant have your cake and eat it too. We will have to choose 
> between very good integration with git or average / mediocre integration with 
> multiple backends. 

again, I  cannot agree. It is a bad idea to have calls to an external tool / 
library wide spread in the image. We need our own API. It is particularly true 
for git that has an API mixing daily tasks with other power admin commands 
(rewrite of the history with possible code loss).
I do not think we need full support of git in the image, i.e. supporting all 
commands and options, but only what is needed to do correct versioning from 
Pharo (special git commands can still be done with command-line).

> 
> On Sun, Nov 29, 2015 at 8:15 PM stepharo  wrote:
> What I would like for Pharo is to avoid to be bound to a given back-end
> for its versionning.
> This master is a step in the right direction
> 
> http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_54.pdf
> 
> Stef
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

[EuanM]

Well, personally, I far prefer Mercurial.  Which also dethroned SVN.

Mercurial has all the power of Git, while providing a more usable API.
My mind works like a Smalltalker's, not like Linus's.

It's true, some of the more abstruse functions of git require a longer
chain of user actions in Mercurial in order to achieve the same end.
But typically, the more common functions are more memorable in
Mercurial than in git, and my typical use-cases for a DSCM system are
less involved than that of the Linux core.

On 29 November 2015 at 19:00, Dimitris Chloupis  wrote:
> And there lies the trap.
>
> If you end up making something that works with everything, you will create
> something that just works with everything instead of something that works
> very well with one thing. Right now Git is by very far the undisputed king
> of version control and has completely dethroned SVN.
>
> Ironically the things that make git integration in pharo so hard is all the
> thing that are there to decouple it from git , like filetree metadata , or
> continuous support for mcz and monticello.
>
> In the end you cant have your cake and eat it too. We will have to choose
> between very good integration with git or average / mediocre integration
> with multiple backends.
>
> On Sun, Nov 29, 2015 at 8:15 PM stepharo  wrote:
>>
>> What I would like for Pharo is to avoid to be bound to a given back-end
>> for its versionning.
>> This master is a step in the right direction
>>
>>
>> http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_54.pdf
>>
>> Stef
>>
>>
>

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

[EuanM]

We want a system of small objects with loose-coupling, and simple webs
of message-sends.  This allows us power, flexibility, maintainability
*and* the opportunity to accommodate new requirements.

We always need to bear this in mind.  Build for the inevitable changes
of environment and changes of requirement.  You Ain't Gonna Need it
(YAGNI) is often true, but well-factored code is *always* good.

On 30 November 2015 at 17:02, EuanM  wrote:
> Well, personally, I far prefer Mercurial.  Which also dethroned SVN.
>
> Mercurial has all the power of Git, while providing a more usable API.
> My mind works like a Smalltalker's, not like Linus's.
>
> It's true, some of the more abstruse functions of git require a longer
> chain of user actions in Mercurial in order to achieve the same end.
> But typically, the more common functions are more memorable in
> Mercurial than in git, and my typical use-cases for a DSCM system are
> less involved than that of the Linux core.
>
> On 29 November 2015 at 19:00, Dimitris Chloupis  wrote:
>> And there lies the trap.
>>
>> If you end up making something that works with everything, you will create
>> something that just works with everything instead of something that works
>> very well with one thing. Right now Git is by very far the undisputed king
>> of version control and has completely dethroned SVN.
>>
>> Ironically the things that make git integration in pharo so hard is all the
>> thing that are there to decouple it from git , like filetree metadata , or
>> continuous support for mcz and monticello.
>>
>> In the end you cant have your cake and eat it too. We will have to choose
>> between very good integration with git or average / mediocre integration
>> with multiple backends.
>>
>> On Sun, Nov 29, 2015 at 8:15 PM stepharo  wrote:
>>>
>>> What I would like for Pharo is to avoid to be bound to a given back-end
>>> for its versionning.
>>> This master is a step in the right direction
>>>
>>>
>>> http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_54.pdf
>>>
>>> Stef
>>>
>>>
>>

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

[Offray Vladimir Luna Cárdenas]

Hi,

On 29/11/15 14:00, Dimitris Chloupis wrote:

And there lies the trap.

If you end up making something that works with everything, you will 
create something that just works with everything instead of something 
that works very well with one thing. Right now Git is by very far the 
undisputed king of version control and has completely dethroned SVN.




If wisdom of the crowds were the wise path to follow, nobody would be 
using Pharo/Smalltalk. The kingdom of git is because of popularity, not 
from any particular technical superiority. Despite of its popularity, I 
have been able to keep myself away from git/GitHub, using them only for 
cloning and bug reporting, but for everything else I use fossil, a tool 
that tries to be out of my way and doesn't mess a lot with my workflow 
(a big difference with git) and keep metadata (bug reporting, wikis, 
conversations) with me instead of using it for making me depend on 
Central Server Inc. (a big difference with GitHub).


I agree with Christophe and Steph on this and is nice to have people 
making this researching. A very welcomed work.


Cheers,

Offray

Re: [Pharo-users] Sharing data between images

[Offray Vladimir Luna Cárdenas]

Hi,

I'm using STON, precisely for its textual nature, because for 
collaborative writing it would be nice to have a diff friendly storage 
format. Still I haven't had the time to make my ston grafoscopio 
notebooks diff friendly when long lines appear (they're treated by 
fossil as binaries) but seems not to difficult to do (is mostly about 
having time to play with it).


Cheers,

Offray

On 29/11/15 10:56, Sven Van Caekenberghe wrote:

Fuel is binary, faster and store more special kinds of objects. STON is 
textual, you can read and edit it, better suited for model objects.


On 29 Nov 2015, at 16:35, Johan Fabry  wrote:

Hi,

have a look at Fuel, It’s included in the image. See 
http://files.pharo.org/books/enterprisepharo/book/Fuel/Fuel.html for more info.


On Nov 29, 2015, at 11:57, Dimitris Chloupis  wrote:

Just wondering what my options are about sharing data between images, should I 
use Ston ? A database ? something else ?

I would prefer options that have as few dependencies as possible and something 
that does not require from my users to install external stuff.

For now Ston looks like a good option but I am very new to all this so I would 
welcome any advice from the pharo experts.



---> Save our in-boxes! http://emailcharter.org <---

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

Re: [Pharo-users] [Pharo-dev] Pharo Consortium New Gold Member: Thales

[Yuriy Tymchuk]

It is extremely weird that this got into the thread about new consortium 
member, as I was replying to “[Pharo-dev] Java Future”…

> On 30 Nov 2015, at 15:27, Yuriy Tymchuk  wrote:
> 
> You can start a “Future of Pharo” discussion on a Java mailing list :)
> 
> Cheers.
> Uko
> 
>> On 30 Nov 2015, at 12:27, Tudor Girba  wrote:
>> 
>> Great news!
>> 
>> For everyone not directly involved in the Consortium:
>> The money collected from memberships go towards the infrastructure of Pharo 
>> in form of engineering time. This is a key effort to make Pharo a 
>> sustainable platform for the long run.
>> 
>> That is why these pieces of news are so important.
>> 
>> Doru
>> 
>> 
>>> On Nov 26, 2015, at 2:42 PM, marcus.den...@inria.fr wrote:
>>> 
>>> The Pharo Consortium is very happy to announce that Thales 
>>> has joined the Consortium as an Gold Member.
>>> 
>>> About
>>> - Thales: https://www.thalesgroup.com
>>> - Pharo Consortium: http://consortium.pharo.org
>>> 
>>> The goal of the Pharo Consortium is to allow companies and institutions to
>>> support the ongoing development and future of Pharo.
>>> 
>>> Individuals can support Pharo via the Pharo Association:
>>> 
>>> http://association.pharo.org
>>> 
>> 
>> --
>> www.tudorgirba.com
>> 
>> "Value is always contextual."
>> 
>> 
>> 
>> 
> 
> 

[Pharo-users] PharoJS Status

[Craig Johnson]

Hi All,

I'd like to start messing around with PharoJS.  Can anybody tell what 
the status is?  (Stable, broken, etc.)


And, which Pharo version should I use for this?

Craig

Re: [Pharo-users] PharoJS Status

[Noury Bouraqadi]

Just tested with a fresh image and it worked.

Noury
> On 30 Nov 2015, at 16:37, Andy Burnett  
> wrote:
> 
> >>> Craig said
> Hi All,
> 
> I'd like to start messing around with PharoJS.  Can anybody tell what
> the status is?  (Stable, broken, etc.)
> 
> And, which Pharo version should I use for this?
> <<<
> 
> I have just started playing with it. I have had some difficulty getting a 
> running image. Following the instructions - should - work, but I found that I 
> needed to install the NewExternalWebBrowser package separately before it 
> would run.
> Cheers
> Andy

Re: [Pharo-users] PharoJS Status

[Andy Burnett]

>>> Craig said
Hi All,

I'd like to start messing around with PharoJS.  Can anybody tell what
the status is?  (Stable, broken, etc.)

And, which Pharo version should I use for this?
<<<

I have just started playing with it. I have had some difficulty getting a
running image. Following the instructions - should - work, but I found that
I needed to install the NewExternalWebBrowser package separately before it
would run.
Cheers
Andy

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

[Offray Vladimir Luna Cárdenas]

Hi,

On 30/11/15 12:34, Dimitris Chloupis wrote:

let me give you the thinking of someone that comes from another language

"What is this ? Ah Pharo
What features it has ? Ah thats some nice cool features, live coding 
looks sweet
How about version control ? Hmm no its too weak and their website for 
hosting repos is problematic in many cases
Maybe I could use git which I am familiar with ? Ah yes but wait 
there are many limitations

How about big repos that git excels at ? Nope it crashes Pharo VM.



Maybe I could use X because I'm familiar with is the proper argument if 
is not taken too far. Interface with the external world without a 
forceful coupling to X1 should be the approach.




Things get popular not because they have nicely designed APIs, they 
become popular and rightly so and wisely so because they work. Simple 
as that.




Considering that several things work in a particular domain (data bases, 
DVCS, etc) that seems reductive.


I hope at last version control is addressed seriously because its a 
real pity Pharo not to be able to use git when there are toy languages 
like brainfuck that interface better with it or other version control 
system.


I am not against the idea of an abstraction API for Version Control , 
great idea do that, but first let get things working properly so we 
dont get people scratching their heads on git merges or people 
struggling to find out why sthub is down once again.




With that approach we should get Oracle intimately coupled with Pharo 
before having Garage or any DB related advance. In fact I'm using 
NBSQLite for *my* own purposes and needs, but I don't plan it to be the 
default in the language/environment. May be because pharo goes beyond 
the language and has and integrated experience, we think in how we can 
make it smoother for other people, like frameworks which integrate git 
or sqlite by default, but a proper balance to not enforce my particular 
tastes over others should be kept also. So I would advice tightly 
integration for "apps" (Scratch, grafoscopio) and loose one for 
frameworks/environments (Aida, Seaside, and pharo itself).


Cheers,

Offray

Re: [Pharo-users] PharoJS Status

[craig]

I just loaded PharoJS into a fresh v5 image,  and I also had the DNU message 
until I loaded the NewExternalWebBrowser package. 

Craig

Sent from Samsung Mobile

 Original message 
From: Noury Bouraqadi  
Date:2015/11/30  5:48 PM  (GMT+02:00) 
To: Any question about pharo is welcome  
Subject: Re: [Pharo-users] PharoJS Status 

Just tested with a fresh image and it worked.

Noury
On 30 Nov 2015, at 16:37, Andy Burnett  wrote:

>>> Craig said
Hi All,

I'd like to start messing around with PharoJS.  Can anybody tell what
the status is?  (Stable, broken, etc.)

And, which Pharo version should I use for this?
<<<

I have just started playing with it. I have had some difficulty getting a 
running image. Following the instructions - should - work, but I found that I 
needed to install the NewExternalWebBrowser package separately before it would 
run.
Cheers
Andy

Re: [Pharo-users] Sharing data between images

[Offray Vladimir Luna Cárdenas]

I do, but I have not made them diff friendly, because I store 
"documents" on them, so is easy to have long lines inside them that are 
treated as binaries in my DVCS (fossil). Sven have told me some 
approaches to deal with this, but I haven't had the time to explore them.


Cheers,

Offray

On 30/11/15 12:37, Dimitris Chloupis wrote:

you wanna version control your STON files ? sound reasonable.

On Mon, Nov 30, 2015 at 6:56 PM Offray Vladimir Luna Cárdenas 
> wrote:


Hi,

I'm using STON, precisely for its textual nature, because for
collaborative writing it would be nice to have a diff friendly storage
format. Still I haven't had the time to make my ston grafoscopio
notebooks diff friendly when long lines appear (they're treated by
fossil as binaries) but seems not to difficult to do (is mostly about
having time to play with it).

Cheers,

Offray

On 29/11/15 10:56, Sven Van Caekenberghe wrote:
> Fuel is binary, faster and store more special kinds of objects.
STON is textual, you can read and edit it, better suited for model
objects.
>
>> On 29 Nov 2015, at 16:35, Johan Fabry > wrote:
>>
>> Hi,
>>
>> have a look at Fuel, It’s included in the image. See
http://files.pharo.org/books/enterprisepharo/book/Fuel/Fuel.html
for more info.
>>
>>> On Nov 29, 2015, at 11:57, Dimitris Chloupis
> wrote:
>>>
>>> Just wondering what my options are about sharing data between
images, should I use Ston ? A database ? something else ?
>>>
>>> I would prefer options that have as few dependencies as
possible and something that does not require from my users to
install external stuff.
>>>
>>> For now Ston looks like a good option but I am very new to all
this so I would welcome any advice from the pharo experts.
>>
>>
>> ---> Save our in-boxes! http://emailcharter.org <---
>>
>> Johan Fabry   - http://pleiad.cl/~jfabry

>> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  - 
University of Chile

>>
>
>

Re: [Pharo-users] [ANN] breakpoints and watchpoints working

[Marcus Denker]

> On 28 Nov 2015, at 08:03, Marcus Denker  wrote:
> 
>> 
>> 
>> Is there a way to query all breakpoints like a query of senders of #halt?
> 
> you can search for the senders of #break. 
> 
> But as class Breakpoint has a list of all active breakpoints, we add a 
> browseAll method there
> easily. 
> 
browseAll

Re: [Pharo-users] How fuel deals with circular reference ?

[Dimitris Chloupis]

ah this is very good news for me thanks. I really like Fuel, well done
guys, looks very well designed.

Yeah feature wise I dont care about something advanced, If I need something
much more advanced I will use a proper database.

I am slightly surprised that none or at least AFAIK has not create a
lightweight database API based on Fuel . Something similar to SQLite.

https://www.sqlite.org/

About scale, I guess I can brake things to multiple files. On other thread
someone mention that STON is a good choice for version control but that is
not a problem for me either since Git can handle binary files like fuel
files too.

On Mon, Nov 30, 2015 at 4:49 PM Mariano Martinez Peck 
wrote:

> On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis  > wrote:
>
>> Yes I have read the docs on how to use Fuel on how to use it and how to
>> exclude things I dont want to be stored in fuel file, I was just curious.
>> As a matter of fact I like deep copies.
>>
>> Is it ok to use Fuel to make my own , super light, database ? Just a way
>> to manage and port my objects between images. Nothing very sophisticated.
>>
>
> Yes, we did this for Quuve application when it runs (for development)
> under Pharo. Of course, it will only work up to certain scale (since every
> commit will serialize the whole database) and you do not have ACID, nor DB
> users, no security, nor any other features of a real DB.
>
> You may want to take a look to simple persistence to save some of your
> development time since it has a Fuel backend:
> http://smalltalkhub.com/#!/~TorstenBergmann/SimplePersistence
>
>
>> On Mon, Nov 30, 2015 at 3:08 PM Mariano Martinez Peck <
>> marianop...@gmail.com> wrote:
>>
>>> On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis <
>>> kilon.al...@gmail.com> wrote:
>>>
 I have a class A that has an instance variable the references an
 instance of Class B , but also Class B has an instance variable the
 references an instance of Class A. Basically its a GUI that references its
 model and the same model referencing the same instance of GUI.


>>> Dimitris,
>>>
>>> Fuel solves the circular references in the traditional way, that is,
>>> while traversing the graph, after processing each objects it stores it in a
>>> IdentityDictionary. Then, for each object to be processed, it first checks
>>> if the dictionary already includes that object. If true, then it has
>>> already been processed. If not, then lets process/traverse.
>>>
>>>
>>>
 How Fuel deals with such scenario because I saw that it created an
 output of 1.5 mbs for several instances of my model class ? Is there any
 danger of having such circular references or it does not matter because
 afterall they are just pointers ?

>>>
>>> As Sven said, you need to be careful because you cannot be sure exactly
>>> all what Fuel can reach from a certain graph. If the graph was serialized
>>> into a 1.5mb then it has nothing to do to the fact of having circular
>>> references. It's simply the fact of the graph that ended up traversed.
>>>
>>> There are some tools inside Fuel to know what has been
>>> "traversed/processed" and that will next be serialized. This may help you
>>> realize that you are including in the graph things you don't want. We have
>>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging
>>> but I am not sure if that's a bit outdated. Give it a try and if not ask.
>>> The ideally is to at least get the list of classes and instances that are
>>> being serialized. That's quite a help in a first place.
>>>
>>> Finally, if you found parts of the graph that you didn't want to
>>> serialize, then you can use different Fuel hooks to solve that
>>> (substitutions, ignoring certain intsVars, etc etc).
>>>
>>> Best,
>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

[Dimitris Chloupis]

just for the usual note, thats my personal opinion and in no way try to
discourage people just offer a different perspective to this. I always
welcome any effort to improve pharo in any way, even for ways I dont care
about so much. So keep up the amazing work you guys are doing with Pharo.

On Mon, Nov 30, 2015 at 7:34 PM Dimitris Chloupis 
wrote:

> let me give you the thinking of someone that comes from another language
>
> "What is this ? Ah Pharo
> What features it has ? Ah thats some nice cool features, live coding looks
> sweet
> How about version control ? Hmm no its too weak and their website for
> hosting repos is problematic in many cases
> Maybe I could use git which I am familiar with ? Ah yes but wait there
> are many limitations
> How about big repos that git excels at ? Nope it crashes Pharo VM.
>
> Hmm.. ok Pharo looks like  nice toy  will go back to my language of
> choice and use it from time to time for foolish experiments. Notice one
> thing here, the user never cares about the flexibility of the API. Bottom
> line its not about git, or mecurial, or svn. Its about giving something
> that the user can use and right now when it comes to version control Pharo
> is light years behind.
>
> Things get popular not because they have nicely designed APIs, they become
> popular and rightly so and wisely so because they work. Simple as that.
>
> I hope at last version control is addressed seriously because its a real
> pity Pharo not to be able to use git when there are toy languages like
> brainfuck that interface better with it or other version control system.
>
> I am not against the idea of an abstraction API for Version Control ,
> great idea do that, but first let get things working properly so we dont
> get people scratching their heads on git merges or people struggling to
> find out why sthub is down once again.
>
> On Mon, Nov 30, 2015 at 7:07 PM EuanM  wrote:
>
>> We want a system of small objects with loose-coupling, and simple webs
>> of message-sends.  This allows us power, flexibility, maintainability
>> *and* the opportunity to accommodate new requirements.
>>
>> We always need to bear this in mind.  Build for the inevitable changes
>> of environment and changes of requirement.  You Ain't Gonna Need it
>> (YAGNI) is often true, but well-factored code is *always* good.
>>
>> On 30 November 2015 at 17:02, EuanM  wrote:
>> > Well, personally, I far prefer Mercurial.  Which also dethroned SVN.
>> >
>> > Mercurial has all the power of Git, while providing a more usable API.
>> > My mind works like a Smalltalker's, not like Linus's.
>> >
>> > It's true, some of the more abstruse functions of git require a longer
>> > chain of user actions in Mercurial in order to achieve the same end.
>> > But typically, the more common functions are more memorable in
>> > Mercurial than in git, and my typical use-cases for a DSCM system are
>> > less involved than that of the Linux core.
>> >
>> > On 29 November 2015 at 19:00, Dimitris Chloupis 
>> wrote:
>> >> And there lies the trap.
>> >>
>> >> If you end up making something that works with everything, you will
>> create
>> >> something that just works with everything instead of something that
>> works
>> >> very well with one thing. Right now Git is by very far the undisputed
>> king
>> >> of version control and has completely dethroned SVN.
>> >>
>> >> Ironically the things that make git integration in pharo so hard is
>> all the
>> >> thing that are there to decouple it from git , like filetree metadata
>> , or
>> >> continuous support for mcz and monticello.
>> >>
>> >> In the end you cant have your cake and eat it too. We will have to
>> choose
>> >> between very good integration with git or average / mediocre
>> integration
>> >> with multiple backends.
>> >>
>> >> On Sun, Nov 29, 2015 at 8:15 PM stepharo  wrote:
>> >>>
>> >>> What I would like for Pharo is to avoid to be bound to a given
>> back-end
>> >>> for its versionning.
>> >>> This master is a step in the right direction
>> >>>
>> >>>
>> >>>
>> http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_54.pdf
>> >>>
>> >>> Stef
>> >>>
>> >>>
>> >>
>>
>>

Re: [Pharo-users] How fuel deals with circular reference ?

[Dimitris Chloupis]

ah very nice client you had :)

Thank you Mariano very much will take a deep look into it and I am sure
will be back with more questions, its fascinating.

On Mon, Nov 30, 2015 at 7:54 PM Mariano Martinez Peck 
wrote:

> On Mon, Nov 30, 2015 at 2:42 PM, Dimitris Chloupis 
> wrote:
>
>> ah this is very good news for me thanks. I really like Fuel, well done
>> guys, looks very well designed.
>>
>> Yeah feature wise I dont care about something advanced, If I need
>> something much more advanced I will use a proper database.
>>
>> I am slightly surprised that none or at least AFAIK has not create a
>> lightweight database API based on Fuel . Something similar to SQLite.
>>
>> https://www.sqlite.org/
>>
>>
> Well, we did and my client agree to open source it:
> http://smalltalkhub.com/#!/~Debris/DebrisDB
> So...you could either try that or SimplePersistentcy.
>
> About scale, I guess I can brake things to multiple files.
>>
>
> That's what we do in our application. Not necessary as for performance but
> also as for domain logic. We have advisorDB, clientsDB, securitiesDB, etc,
> which are all logic app-dependent databases. And then all these logic
> databases are stored (somehow) into real databases.
>
>
>> On other thread someone mention that STON is a good choice for version
>> control but that is not a problem for me either since Git can handle binary
>> files like fuel files too.
>>
>> On Mon, Nov 30, 2015 at 4:49 PM Mariano Martinez Peck <
>> marianop...@gmail.com> wrote:
>>
>>> On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis <
>>> kilon.al...@gmail.com> wrote:
>>>
 Yes I have read the docs on how to use Fuel on how to use it and how to
 exclude things I dont want to be stored in fuel file, I was just curious.
 As a matter of fact I like deep copies.

 Is it ok to use Fuel to make my own , super light, database ? Just a
 way to manage and port my objects between images. Nothing very
 sophisticated.

>>>
>>> Yes, we did this for Quuve application when it runs (for development)
>>> under Pharo. Of course, it will only work up to certain scale (since every
>>> commit will serialize the whole database) and you do not have ACID, nor DB
>>> users, no security, nor any other features of a real DB.
>>>
>>> You may want to take a look to simple persistence to save some of your
>>> development time since it has a Fuel backend:
>>> http://smalltalkhub.com/#!/~TorstenBergmann/SimplePersistence
>>>
>>>
 On Mon, Nov 30, 2015 at 3:08 PM Mariano Martinez Peck <
 marianop...@gmail.com> wrote:

> On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis <
> kilon.al...@gmail.com> wrote:
>
>> I have a class A that has an instance variable the references an
>> instance of Class B , but also Class B has an instance variable the
>> references an instance of Class A. Basically its a GUI that references 
>> its
>> model and the same model referencing the same instance of GUI.
>>
>>
> Dimitris,
>
> Fuel solves the circular references in the traditional way, that is,
> while traversing the graph, after processing each objects it stores it in 
> a
> IdentityDictionary. Then, for each object to be processed, it first checks
> if the dictionary already includes that object. If true, then it has
> already been processed. If not, then lets process/traverse.
>
>
>
>> How Fuel deals with such scenario because I saw that it created an
>> output of 1.5 mbs for several instances of my model class ? Is there any
>> danger of having such circular references or it does not matter because
>> afterall they are just pointers ?
>>
>
> As Sven said, you need to be careful because you cannot be sure
> exactly all what Fuel can reach from a certain graph. If the graph was
> serialized into a 1.5mb then it has nothing to do to the fact of having
> circular references. It's simply the fact of the graph that ended up
> traversed.
>
> There are some tools inside Fuel to know what has been
> "traversed/processed" and that will next be serialized. This may help you
> realize that you are including in the graph things you don't want. We have
> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging
> but I am not sure if that's a bit outdated. Give it a try and if not ask.
> The ideally is to at least get the list of classes and instances that are
> being serialized. That's quite a help in a first place.
>
> Finally, if you found parts of the graph that you didn't want to
> serialize, then you can use different Fuel hooks to solve that
> (substitutions, ignoring certain intsVars, etc etc).
>
> Best,
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>
>
> --
> 

Re: [Pharo-users] Sharing data between images

[Dimitris Chloupis]

you wanna version control your STON files ? sound reasonable.

On Mon, Nov 30, 2015 at 6:56 PM Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

> Hi,
>
> I'm using STON, precisely for its textual nature, because for
> collaborative writing it would be nice to have a diff friendly storage
> format. Still I haven't had the time to make my ston grafoscopio
> notebooks diff friendly when long lines appear (they're treated by
> fossil as binaries) but seems not to difficult to do (is mostly about
> having time to play with it).
>
> Cheers,
>
> Offray
>
> On 29/11/15 10:56, Sven Van Caekenberghe wrote:
> > Fuel is binary, faster and store more special kinds of objects. STON is
> textual, you can read and edit it, better suited for model objects.
> >
> >> On 29 Nov 2015, at 16:35, Johan Fabry  wrote:
> >>
> >> Hi,
> >>
> >> have a look at Fuel, It’s included in the image. See
> http://files.pharo.org/books/enterprisepharo/book/Fuel/Fuel.html for more
> info.
> >>
> >>> On Nov 29, 2015, at 11:57, Dimitris Chloupis 
> wrote:
> >>>
> >>> Just wondering what my options are about sharing data between images,
> should I use Ston ? A database ? something else ?
> >>>
> >>> I would prefer options that have as few dependencies as possible and
> something that does not require from my users to install external stuff.
> >>>
> >>> For now Ston looks like a good option but I am very new to all this so
> I would welcome any advice from the pharo experts.
> >>
> >>
> >> ---> Save our in-boxes! http://emailcharter.org <---
> >>
> >> Johan Fabry   -   http://pleiad.cl/~jfabry
> >> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -
> University of Chile
> >>
> >
> >
>
>
>

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

[Dimitris Chloupis]

let me give you the thinking of someone that comes from another language

"What is this ? Ah Pharo
What features it has ? Ah thats some nice cool features, live coding looks
sweet
How about version control ? Hmm no its too weak and their website for
hosting repos is problematic in many cases
Maybe I could use git which I am familiar with ? Ah yes but wait there
are many limitations
How about big repos that git excels at ? Nope it crashes Pharo VM.

Hmm.. ok Pharo looks like  nice toy  will go back to my language of
choice and use it from time to time for foolish experiments. Notice one
thing here, the user never cares about the flexibility of the API. Bottom
line its not about git, or mecurial, or svn. Its about giving something
that the user can use and right now when it comes to version control Pharo
is light years behind.

Things get popular not because they have nicely designed APIs, they become
popular and rightly so and wisely so because they work. Simple as that.

I hope at last version control is addressed seriously because its a real
pity Pharo not to be able to use git when there are toy languages like
brainfuck that interface better with it or other version control system.

I am not against the idea of an abstraction API for Version Control , great
idea do that, but first let get things working properly so we dont get
people scratching their heads on git merges or people struggling to find
out why sthub is down once again.

On Mon, Nov 30, 2015 at 7:07 PM EuanM  wrote:

> We want a system of small objects with loose-coupling, and simple webs
> of message-sends.  This allows us power, flexibility, maintainability
> *and* the opportunity to accommodate new requirements.
>
> We always need to bear this in mind.  Build for the inevitable changes
> of environment and changes of requirement.  You Ain't Gonna Need it
> (YAGNI) is often true, but well-factored code is *always* good.
>
> On 30 November 2015 at 17:02, EuanM  wrote:
> > Well, personally, I far prefer Mercurial.  Which also dethroned SVN.
> >
> > Mercurial has all the power of Git, while providing a more usable API.
> > My mind works like a Smalltalker's, not like Linus's.
> >
> > It's true, some of the more abstruse functions of git require a longer
> > chain of user actions in Mercurial in order to achieve the same end.
> > But typically, the more common functions are more memorable in
> > Mercurial than in git, and my typical use-cases for a DSCM system are
> > less involved than that of the Linux core.
> >
> > On 29 November 2015 at 19:00, Dimitris Chloupis 
> wrote:
> >> And there lies the trap.
> >>
> >> If you end up making something that works with everything, you will
> create
> >> something that just works with everything instead of something that
> works
> >> very well with one thing. Right now Git is by very far the undisputed
> king
> >> of version control and has completely dethroned SVN.
> >>
> >> Ironically the things that make git integration in pharo so hard is all
> the
> >> thing that are there to decouple it from git , like filetree metadata ,
> or
> >> continuous support for mcz and monticello.
> >>
> >> In the end you cant have your cake and eat it too. We will have to
> choose
> >> between very good integration with git or average / mediocre integration
> >> with multiple backends.
> >>
> >> On Sun, Nov 29, 2015 at 8:15 PM stepharo  wrote:
> >>>
> >>> What I would like for Pharo is to avoid to be bound to a given back-end
> >>> for its versionning.
> >>> This master is a step in the right direction
> >>>
> >>>
> >>>
> http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_54.pdf
> >>>
> >>> Stef
> >>>
> >>>
> >>
>
>

Re: [Pharo-users] [ANN] breakpoints and watchpoints working

[Marcus Denker]

> 
>>> but a problem you could be aware is setting a break once in 
>>> InputEventFetcher>>signalEvent: , and then moving the mouse, the image 
>>> hangs. 
>>> 
>> Thanks, we will investigate. The “once” breakpoint triggers a recompile 
>> before opening the debugger.
>> but of course the devil is in the details… we will check to see what exactly 
>> is happening here.
>> 
> 
> I think I understand what happens: the method is called because there is an 
> interrupt. Check for interrupt happens on all message sends
> ==> even though we *want* to recompile before calling the method again, the 
> check for interrupt happens and it is called again before the new
> method is installed.

Hmm.. I think it could be fixed by changing priorities of running threads: if 
we lover (temporarily) the input-event fetcher priority and raise
the thread that does the compiling/installing, maybe we can make sure that the 
signalEvent: is not called before the break is removed…

Marcus

[Pharo-users] Pharo productivity

[p...@highoctane.be]

I have been using Pharo somewhat less in my current projects.

Nevertheless, I needed a tool done fast and behaving correctly.

Did it the TDD way with Pharo.

Great experience. Great productivity. No messing around with external
libraries, modules...

64-bit Linux compatibility would really help these days. But stuffing Pharo
and 32 bit on a docker container works nicely too.

Phil

Re: [Pharo-users] Pharo productivity

[Esteban A. Maringolo]

Do you have a recipe to put Pharo in a Docker container?
Esteban A. Maringolo


2015-11-30 17:34 GMT-03:00 p...@highoctane.be :
> I have been using Pharo somewhat less in my current projects.
>
> Nevertheless, I needed a tool done fast and behaving correctly.
>
> Did it the TDD way with Pharo.
>
> Great experience. Great productivity. No messing around with external
> libraries, modules...
>
> 64-bit Linux compatibility would really help these days. But stuffing Pharo
> and 32 bit on a docker container works nicely too.
>
> Phil

Re: [Pharo-users] Pharo productivity

[Sven Van Caekenberghe]

LXC/LXD containers are much nicer, IMHO, as they look and feel like a regular 
VM, yet are way more efficient.

> On 30 Nov 2015, at 21:43, Esteban A. Maringolo  wrote:
> 
> Do you have a recipe to put Pharo in a Docker container?
> Esteban A. Maringolo
> 
> 
> 2015-11-30 17:34 GMT-03:00 p...@highoctane.be :
>> I have been using Pharo somewhat less in my current projects.
>> 
>> Nevertheless, I needed a tool done fast and behaving correctly.
>> 
>> Did it the TDD way with Pharo.
>> 
>> Great experience. Great productivity. No messing around with external
>> libraries, modules...
>> 
>> 64-bit Linux compatibility would really help these days. But stuffing Pharo
>> and 32 bit on a docker container works nicely too.
>> 
>> Phil
> 

Re: [Pharo-users] PharoJS Status

[craig]

 

Can the people that have it working provide some tips please. 

I have the pink PharoJS workspace open, am I correct in understanding
that the results of any evaluation is this workspace should show-up in
the browser? At this point nothing shows-up in the browser. 

Craig 

On 2015-11-30 21:16, craig wrote: 

> I just loaded PharoJS into a fresh v5 image, and I also had the DNU message 
> until I loaded the NewExternalWebBrowser package. 
> 
> Craig 
> 
> Sent from Samsung Mobile 
> 
>  Original message 
> From: Noury Bouraqadi 
> Date:2015/11/30 5:48 PM (GMT+02:00) 
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] PharoJS Status 
> 
> Just tested with a fresh image and it worked. 
> 
> Noury
> 
>> On 30 Nov 2015, at 16:37, Andy Burnett  
>> wrote: 
>> 
> Craig said
>> Hi All,
>> 
>> I'd like to start messing around with PharoJS. Can anybody tell what
>> the status is? (Stable, broken, etc.)
>> 
>> And, which Pharo version should I use for this?
>> <<< 
>> 
>> I have just started playing with it. I have had some difficulty getting a 
>> running image. Following the instructions - should - work, but I found that 
>> I needed to install the NewExternalWebBrowser package separately before it 
>> would run. 
>> Cheers 
>> Andy
 

Re: [Pharo-users] Pharo productivity

[Esteban Lorenzano]

cool :)

but those scripts can be easily improved: 

Gofer it 
url: ‘filetree:///home/deploy’;
package: ‘WebCounter’;
package: ‘HelloWorldApp’;
load.
stdout << 'WebCounter installed'; lf.
ZnZincServerAdaptor startOn: 8080.
WAAdmin register: WebCounter asApplicationAt: 'webcounter’.

(looks a lot easier to understand :P)

cheers, 
Esteban


> On 30 Nov 2015, at 22:51, p...@highoctane.be wrote:
> 
> https://github.com/Geal/pharo-seaside-docker-example
> https://www.clever-cloud.com/blog/guests/2015/01/05/smalltalk-in-the-cloud/
> 
> Phil
> 
> 
> On Mon, Nov 30, 2015 at 9:43 PM, Esteban A. Maringolo  
> wrote:
> Do you have a recipe to put Pharo in a Docker container?
> Esteban A. Maringolo
> 
> 
> 2015-11-30 17:34 GMT-03:00 p...@highoctane.be :
> > I have been using Pharo somewhat less in my current projects.
> >
> > Nevertheless, I needed a tool done fast and behaving correctly.
> >
> > Did it the TDD way with Pharo.
> >
> > Great experience. Great productivity. No messing around with external
> > libraries, modules...
> >
> > 64-bit Linux compatibility would really help these days. But stuffing Pharo
> > and 32 bit on a docker container works nicely too.
> >
> > Phil
> 
> 
> 

Re: [Pharo-users] [ANN] breakpoints and watchpoints working

[Ben Coman]

On Tue, Dec 1, 2015 at 4:32 AM, Marcus Denker  wrote:
>
>>
 but a problem you could be aware is setting a break once in 
 InputEventFetcher>>signalEvent: , and then moving the mouse, the image 
 hangs.

>>> Thanks, we will investigate. The “once” breakpoint triggers a recompile 
>>> before opening the debugger.
>>> but of course the devil is in the details… we will check to see what 
>>> exactly is happening here.
>>>
>>
>> I think I understand what happens: the method is called because there is an 
>> interrupt. Check for interrupt happens on all message sends
>> ==> even though we *want* to recompile before calling the method again, the 
>> check for interrupt happens and it is called again before the new
>> method is installed.
>
> Hmm.. I think it could be fixed by changing priorities of running threads: if 
> we lover (temporarily) the input-event fetcher priority and raise
> the thread that does the compiling/installing, maybe we can make sure that 
> the signalEvent: is not called before the break is removed…

I speculate that changing the priority of input-event fetcher would
have more impact than just raising the installing thread above it, but
then I guess the DelayScheduler timing-priority event loop will be
susceptible to the same problem. Maybe the final part of the install
needs to be done with a primitive like #become: ?
cheers -ben

Re: [Pharo-users] PharoJS Status

[Sebastian Heidbrink]

Hi Craig,

First you should check the tests and run them 1 by 1.
Your default browser should open and you should see a PharoJS logo 
following a websocket log.
If that is working correctly then you have loaded all needed sources and 
your image should be fine.


There is general problem with the JSWorkspace and JSPlayground. If 
timeouts occur then it seems as if the image is busted and no PharoJS 
code works anymore.
In my case it usually helps to just start one of the interactive unit 
tests or to close and open the image.


Please read the class comments of JBBridge and other documented classes. 
This will give you a better understanding of how PharoJS actually works.


If you "doit" a "JbDemoApplication start" then your default web browser 
should open and you should see a green rectangle asking you to click on it.
You can put a "self halt" into the "setupDOM" method and especially into 
the callback handler blocks, see what it does,... you can debug the 
JS app within Pharo and the app changes live in the browser


There is also the class "JbBrowserExamples" which has two scripts on the 
class side. Copy them into a JSPlayground and inspect them.
The action should take place in the browser opened while you opened the 
JSPlayground.
But be aware! Those scripts do not stop the websocket nor the proxy and 
it usually does not take long until you have to restart/reset the image


I hope that helps a little?!

Sebastian







On 2015-11-30 12:56 PM, craig wrote:


Can the people that have it working provide some tips please.

I have the pink PharoJS workspace open, am I correct in understanding 
that the results of any evaluation is this workspace should show-up in 
the browser?  At this point nothing shows-up in the browser.


Craig

On 2015-11-30 21:16, craig wrote:

I just loaded PharoJS into a fresh v5 image,  and I also had the DNU 
message until I loaded the NewExternalWebBrowser package.

Craig
Sent from Samsung Mobile


 Original message 
From: Noury Bouraqadi
Date:2015/11/30 5:48 PM (GMT+02:00)
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] PharoJS Status

Just tested with a fresh image and it worked.
Noury
On 30 Nov 2015, at 16:37, Andy Burnett 
> wrote:


>>> Craig said
Hi All,

I'd like to start messing around with PharoJS.  Can anybody tell what
the status is? (Stable, broken, etc.)

And, which Pharo version should I use for this?
<<<
I have just started playing with it. I have had some difficulty 
getting a running image. Following the instructions - should - work, 
but I found that I needed to install the NewExternalWebBrowser 
package separately before it would run.

Cheers
Andy

Re: [Pharo-users] [Pharo-dev] Machine Learning algorithms

[serge . stinckwich]

Great initiative Klerisson !

This is better to talk on the pharo-users I guess.

There is a project called SciSmalltalk where a lot of mathematics libraries are 
already available that might be useful for ML algorithms.

Please join us on 
https://github.com/SergeStinckwich/SciSmalltalk
Mailing list here:
https://groups.google.com/forum/m/#!forum/scismalltalk
Regards



Sent from my iPhone

> On 1 déc. 2015, at 00:08, Klérisson Paixão  wrote:
> 
> Greetings!
> 
> We're thinking to power up Pharo with some machine learning algorithms (Naive 
> Bayes, Random Forest and so on). I'm wondering if there is anything done 
> already?
> 
> Thanks,
> Klérisson

Re: [Pharo-users] Pharo Consortium New Gold Member: Thales

[Esteban Lorenzano]

can  you try to do it using chrome or firefox? (I’m trying to determine if this 
is an “old time bug” I saw…)
(this sites -association, consortium- need some serious work, I’m afraid… and 
no time right now :( )

cheers, 
Esteban


> On 01 Dec 2015, at 01:14, John Pfersich  wrote:
> 
> I have tried to join the association in the past, but I get an error message 
> every time I try. See the attached picture to see the result. 
> 
> 
> 
> Sent from my iPad
> 
>> On Nov 30, 2015, at 03:27, Tudor Girba  wrote:
>> 
>> Great news!
>> 
>> For everyone not directly involved in the Consortium:
>> The money collected from memberships go towards the infrastructure of Pharo 
>> in form of engineering time. This is a key effort to make Pharo a 
>> sustainable platform for the long run.
>> 
>> That is why these pieces of news are so important.
>> 
>> Doru
>> 
>> 
>>> On Nov 26, 2015, at 2:42 PM, marcus.den...@inria.fr wrote:
>>> 
>>> The Pharo Consortium is very happy to announce that Thales 
>>> has joined the Consortium as an Gold Member.
>>> 
>>> About
>>> - Thales: https://www.thalesgroup.com
>>> - Pharo Consortium: http://consortium.pharo.org
>>> 
>>> The goal of the Pharo Consortium is to allow companies and institutions to
>>> support the ongoing development and future of Pharo.
>>> 
>>> Individuals can support Pharo via the Pharo Association:
>>> 
>>> http://association.pharo.org
>>> 
>> 
>> --
>> www.tudorgirba.com
>> 
>> "Value is always contextual."
>> 
>> 
>> 
>> 

[Pharo-users] When exactly an object gets deleted from the system ?

[Dimitris Chloupis]

I am wondering when an instance of a class is garbage collected and deleted
from the system.

is there a way to manually deleted it ?

Re: [Pharo-users] When exactly an object gets deleted from the system ?

[Ferlicot D. Cyril]

Le 30/11/2015 11:40, Dimitris Chloupis a écrit :
> I am wondering when an instance of a class is garbage collected and
> deleted from the system.
> 
> is there a way to manually deleted it ?

If there is no Object that reference your object you can force a Garbage
collect with "Smalltalk garbageCollect". If your object is still here
you can try to see what point to it with "(X allInstances collectAsSet:
#pointersTo) inspect".

When the reference is spotted you can try to remove it then garbage
collect again.

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] When exactly an object gets deleted from the system ?

[Esteban Lorenzano]

> On 30 Nov 2015, at 11:55, Ferlicot D. Cyril  wrote:
> 
> Le 30/11/2015 11:40, Dimitris Chloupis a écrit :
>> I am wondering when an instance of a class is garbage collected and
>> deleted from the system.
>> 
>> is there a way to manually deleted it ?
> 
> If there is no Object that reference your object you can force a Garbage
> collect with "Smalltalk garbageCollect". If your object is still here
> you can try to see what point to it with "(X allInstances collectAsSet:
> #pointersTo) inspect".
> 
> When the reference is spotted you can try to remove it then garbage
> collect again.

forcing a garbage collection is not a recommended procedure. Of course you can 
do it while testing/developing/etc., but you must not use it as a part of your 
code :)

Esteban

> 
> -- 
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France
> 

Re: [Pharo-users] Pharo Consortium New Gold Member: Thales

[Tudor Girba]

Great news!

For everyone not directly involved in the Consortium:
The money collected from memberships go towards the infrastructure of Pharo in 
form of engineering time. This is a key effort to make Pharo a sustainable 
platform for the long run.

That is why these pieces of news are so important.

Doru


> On Nov 26, 2015, at 2:42 PM, marcus.den...@inria.fr wrote:
> 
> The Pharo Consortium is very happy to announce that Thales 
> has joined the Consortium as an Gold Member.
> 
> About
> - Thales: https://www.thalesgroup.com
> - Pharo Consortium: http://consortium.pharo.org
> 
> The goal of the Pharo Consortium is to allow companies and institutions to
> support the ongoing development and future of Pharo.
> 
> Individuals can support Pharo via the Pharo Association:
> 
>  http://association.pharo.org
> 

--
www.tudorgirba.com

"Value is always contextual."

Re: [Pharo-users] When exactly an object gets deleted from the system ?

[Esteban Lorenzano]

Hi,

> On 30 Nov 2015, at 11:40, Dimitris Chloupis  wrote:
> 
> I am wondering when an instance of a class is garbage collected and deleted 
> from the system. 
> 
> is there a way to manually deleted it ? 

no, that beats the purpose of a garbage collector. 
but… it should be cleaned quite fast, if it is not, most probably you are 
keeping a reference somewhere.

Esteban

Re: [Pharo-users] When exactly an object gets deleted from the system ?

[Dimitris Chloupis]

and of course you are both correct , I have a circular reference, basically
an object A referencing  object  B  which references object A. No wonder
why is not gc. Thanks for helping me out spotting this.

On Mon, Nov 30, 2015 at 12:56 PM Ferlicot D. Cyril 
wrote:

> Le 30/11/2015 11:40, Dimitris Chloupis a écrit :
> > I am wondering when an instance of a class is garbage collected and
> > deleted from the system.
> >
> > is there a way to manually deleted it ?
>
> If there is no Object that reference your object you can force a Garbage
> collect with "Smalltalk garbageCollect". If your object is still here
> you can try to see what point to it with "(X allInstances collectAsSet:
> #pointersTo) inspect".
>
> When the reference is spotted you can try to remove it then garbage
> collect again.
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>
>

Re: [Pharo-users] How fuel deals with circular reference ?

[Sven Van Caekenberghe]

Both Fuel and STON deal correctly with circular references and structure 
sharing.

However, and this is an important difference, since FUEL is saving everything 
it sees (everything your objects point to), it often saves a lot (way more than 
you expect). STON (and JSON, XML, ..) are much less powerful, they require you 
to carefully think about and design the domain model objects that you want to 
serialise/persistent (i.e. make sure they don't point to system stuff, or at 
least skip these). The result will be much cleaner and smaller output.

> On 30 Nov 2015, at 12:41, Dimitris Chloupis  wrote:
> 
> I have a class A that has an instance variable the references an instance of 
> Class B , but also Class B has an instance variable the references an 
> instance of Class A. Basically its a GUI that references its model and the 
> same model referencing the same instance of GUI. 
> 
> How Fuel deals with such scenario because I saw that it created an output of 
> 1.5 mbs for several instances of my model class ? Is there any danger of 
> having such circular references or it does not matter because afterall they 
> are just pointers ?  

[Pharo-users] Help needed: old issues issue tracker entries

[marcus . denker]

Hi,

The issue tracker has 658 open issues. This number is more or less constant.

We are fixing and integrating *a lot*, alone the last 7 days we managed to 
close 89 
issue tracker entries. But the older entries see not much work. Of course one 
reason
is that everything fixable gets fixed and only hard cases remain… but cases can 
be
“difficult” for many reasons.

I would be nice if everyone could help and have a look at older issues:

-> Still relevant?
-> Maybe already fixed?
-> Is the description good? 
-> What is the next action that needs to be done?

And keep in mind that the issue tracker is not a TODO list. If you see 
something odd
and put and issue “oh, this looks odd” but there is no action for a year, does 
it really
make sense to keep that issue open?

Every open issue takes energy away from the others. So please check if issues 
make
sense of this kind:

-> “It would be nice if” but not even important enough for the submitter to do
-> TODO issues that are huge projects in themselves
-> ….

It would be nice if *you* would check the issue that you have been involved 
with the
last months and see what is needed to solve them.

Marcus

Re: [Pharo-users] [Moose-dev] Re: graph library in Pharo

[Peter Uhnák]

I'll look at the GraphViz bridge, however I would prefer direct solution.

So if I don't anything else I will start implementing it myself
(considering the total amount of work I will most likely start with
algos that are (awfully) slow, but easier to implement (I need at lest
something))

Peter

On Mon, Nov 30, 2015 at 2:06 PM, Alexandre Bergel
 wrote:
> Yes, I see your point.
> Some years ago, GraphViz was bridged with Mondrian / Roassal. I do not know
> whether GraphViz would solve your problem or not. OSProcess was used then.
>
> Let us know how you plan to continue on that front. This is very important.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Nov 29, 2015, at 9:42 PM, Peter Uhnák  wrote:
>
> I need at least (mixed/upward)-planarity testing, embedding, spanning
> tree, flow, assignment, ...
>
> I've seen the Moose-Algos, but from what I need it contains only
> Kruskal (spanning tree).
>
> So ideally I would like to just load a project instead having to
> implement them all by myself, because most of them are very complex.
>
> Peter
>
> On Sun, Nov 29, 2015 at 11:35 PM, Alexandre Bergel
>  wrote:
>
> There are a few algorithms in the moose distribution. Maybe you can check
> them.
> Which algo do you really need?
>
> Cheers,
> Alexandre
>
>
> On Nov 29, 2015, at 5:29 PM, Peter Uhnak  wrote:
>
> Hi,
>
> is there any graph library for pharo with algorithms for planarity
> testing, spanning trees, flow costs, etc.?
>
> Thanks,
> --
> Peter
>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

Re: [Pharo-users] [Moose-dev] graph library in Pharo

[Tudor Girba]

Unfortunately, there is nothing else I know about.

But, if you would implement such algorithms, it would be a great addition. 
Would you consider implementing it as part of the Moose-Algos project or part 
of Roassal?

Cheers,
Doru


> On Nov 30, 2015, at 2:43 PM, Peter Uhnák  wrote:
> 
> I'll look at the GraphViz bridge, however I would prefer direct solution.
> 
> So if I don't anything else I will start implementing it myself
> (considering the total amount of work I will most likely start with
> algos that are (awfully) slow, but easier to implement (I need at lest
> something))
> 
> Peter
> 
> On Mon, Nov 30, 2015 at 2:06 PM, Alexandre Bergel
>  wrote:
>> Yes, I see your point.
>> Some years ago, GraphViz was bridged with Mondrian / Roassal. I do not know
>> whether GraphViz would solve your problem or not. OSProcess was used then.
>> 
>> Let us know how you plan to continue on that front. This is very important.
>> 
>> Alexandre
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> On Nov 29, 2015, at 9:42 PM, Peter Uhnák  wrote:
>> 
>> I need at least (mixed/upward)-planarity testing, embedding, spanning
>> tree, flow, assignment, ...
>> 
>> I've seen the Moose-Algos, but from what I need it contains only
>> Kruskal (spanning tree).
>> 
>> So ideally I would like to just load a project instead having to
>> implement them all by myself, because most of them are very complex.
>> 
>> Peter
>> 
>> On Sun, Nov 29, 2015 at 11:35 PM, Alexandre Bergel
>>  wrote:
>> 
>> There are a few algorithms in the moose distribution. Maybe you can check
>> them.
>> Which algo do you really need?
>> 
>> Cheers,
>> Alexandre
>> 
>> 
>> On Nov 29, 2015, at 5:29 PM, Peter Uhnak  wrote:
>> 
>> Hi,
>> 
>> is there any graph library for pharo with algorithms for planarity
>> testing, spanning trees, flow costs, etc.?
>> 
>> Thanks,
>> --
>> Peter
>> 
>> 
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com

"Next time you see your life passing by, say 'hi' and get to know her."

[Pharo-users] #storeOn: question

[Werner Kassens]

Hi,
SortedCollection>>storeOn: seems to have a little problem since it does 
not store sortBlock and the used super-method (in Collection) uses #add: 
which uses sortBlock and their default uses #<=, hence if the elements 
are not comparable via #<=, but need a special sortblock, one gets an 
error on retrieving that collection. of course i can circumvent that 
tiny problem by defining #<= or using fuel, but i wonder whether i 
should report that on the bugtracker? btw perhaps some other collections 
with instanceVariables which do not define their own #storeOn: (eg Heap) 
could also have eventually some problems.

werner

Re: [Pharo-users] How fuel deals with circular reference ?

[Mariano Martinez Peck]

On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis 
wrote:

> I have a class A that has an instance variable the references an instance
> of Class B , but also Class B has an instance variable the references an
> instance of Class A. Basically its a GUI that references its model and the
> same model referencing the same instance of GUI.
>
>
Dimitris,

Fuel solves the circular references in the traditional way, that is, while
traversing the graph, after processing each objects it stores it in a
IdentityDictionary. Then, for each object to be processed, it first checks
if the dictionary already includes that object. If true, then it has
already been processed. If not, then lets process/traverse.



> How Fuel deals with such scenario because I saw that it created an output
> of 1.5 mbs for several instances of my model class ? Is there any danger of
> having such circular references or it does not matter because afterall they
> are just pointers ?
>

As Sven said, you need to be careful because you cannot be sure exactly all
what Fuel can reach from a certain graph. If the graph was serialized into
a 1.5mb then it has nothing to do to the fact of having circular
references. It's simply the fact of the graph that ended up traversed.

There are some tools inside Fuel to know what has been
"traversed/processed" and that will next be serialized. This may help you
realize that you are including in the graph things you don't want. We have
http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging
but I am not sure if that's a bit outdated. Give it a try and if not ask.
The ideally is to at least get the list of classes and instances that are
being serialized. That's quite a help in a first place.

Finally, if you found parts of the graph that you didn't want to serialize,
then you can use different Fuel hooks to solve that (substitutions,
ignoring certain intsVars, etc etc).

Best,



-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] graph library in Pharo

[Alexandre Bergel]

Yes, I see your point. 
Some years ago, GraphViz was bridged with Mondrian / Roassal. I do not know 
whether GraphViz would solve your problem or not. OSProcess was used then. 

Let us know how you plan to continue on that front. This is very important.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Nov 29, 2015, at 9:42 PM, Peter Uhnák  wrote:
> 
> I need at least (mixed/upward)-planarity testing, embedding, spanning
> tree, flow, assignment, ...
> 
> I've seen the Moose-Algos, but from what I need it contains only
> Kruskal (spanning tree).
> 
> So ideally I would like to just load a project instead having to
> implement them all by myself, because most of them are very complex.
> 
> Peter
> 
> On Sun, Nov 29, 2015 at 11:35 PM, Alexandre Bergel
>  wrote:
>> There are a few algorithms in the moose distribution. Maybe you can check 
>> them.
>> Which algo do you really need?
>> 
>> Cheers,
>> Alexandre
>> 
>> 
>>> On Nov 29, 2015, at 5:29 PM, Peter Uhnak  wrote:
>>> 
>>> Hi,
>>> 
>>> is there any graph library for pharo with algorithms for planarity
>>> testing, spanning trees, flow costs, etc.?
>>> 
>>> Thanks,
>>> --
>>> Peter
>>> 
>> 
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> 
> 

Re: [Pharo-users] #storeOn: question

[Sven Van Caekenberghe]

Werner,

> On 30 Nov 2015, at 15:15, Werner Kassens  wrote:
> 
> Hi,
> SortedCollection>>storeOn: seems to have a little problem since it does not 
> store sortBlock and the used super-method (in Collection) uses #add: which 
> uses sortBlock and their default uses #<=, hence if the elements are not 
> comparable via #<=, but need a special sortblock, one gets an error on 
> retrieving that collection. of course i can circumvent that tiny problem by 
> defining #<= or using fuel, but i wonder whether i should report that on the 
> bugtracker? btw perhaps some other collections with instanceVariables which 
> do not define their own #storeOn: (eg Heap) could also have eventually some 
> problems.
> werner

I am not so sure the #storeOn: / #readFrom: mechanism is still being 
maintained. I am not using it in any case, I thought it was mostly broken. I 
would be surprised if someone is still using it for real.

But I might be wrong. In that case there should be a suite of real unit tests 
that defines and maintains the expected behaviour. And then you would be right, 
we should fix it. 

Sven

Re: [Pharo-users] [ANN] breakpoints and watchpoints working

[Ben Coman]

When doing [Add break once] on RubTextEditor>>selectWord, then
double-clicking on any word in the Nautilus code pane, the debugger
that pops up shows all temporary variables are nil, which seems wrong.
Can someone confirm this behaviour?

cheers -ben

On Sat, Nov 28, 2015 at 7:03 PM, Marcus Denker  wrote:
>>
>>
>> Is there a way to query all breakpoints like a query of senders of #halt?
>
> you can search for the senders of #break.
>
> But as class Breakpoint has a list of all active breakpoints, we add a 
> browseAll method there
> easily.
>
>>
>> Any reason for Whatchpoints doesn't work with expressions in the Playground?
>>
> The Playground does not yet support suggestions. This should be fixed.
>
>> Breakpoints seems to work fine (apart from some problem setting up from the 
>> menu method in Nautilus),
> If you find a repeatable case for that , can you add an issue on the tracker?
>
>> but a problem you could be aware is setting a break once in 
>> InputEventFetcher>>signalEvent: , and then moving the mouse, the image hangs.
>>
> Thanks, we will investigate. The “once” breakpoint triggers a recompile 
> before opening the debugger.
> but of course the devil is in the details… we will check to see what exactly 
> is happening here.
>
> Marcus

Re: [Pharo-users] [Pharo-dev] Pharo Consortium New Gold Member: Thales

[Yuriy Tymchuk]

You can start a “Future of Pharo” discussion on a Java mailing list :)

Cheers.
Uko

> On 30 Nov 2015, at 12:27, Tudor Girba  wrote:
> 
> Great news!
> 
> For everyone not directly involved in the Consortium:
> The money collected from memberships go towards the infrastructure of Pharo 
> in form of engineering time. This is a key effort to make Pharo a sustainable 
> platform for the long run.
> 
> That is why these pieces of news are so important.
> 
> Doru
> 
> 
>> On Nov 26, 2015, at 2:42 PM, marcus.den...@inria.fr wrote:
>> 
>> The Pharo Consortium is very happy to announce that Thales 
>> has joined the Consortium as an Gold Member.
>> 
>> About
>> - Thales: https://www.thalesgroup.com
>> - Pharo Consortium: http://consortium.pharo.org
>> 
>> The goal of the Pharo Consortium is to allow companies and institutions to
>> support the ongoing development and future of Pharo.
>> 
>> Individuals can support Pharo via the Pharo Association:
>> 
>> http://association.pharo.org
>> 
> 
> --
> www.tudorgirba.com
> 
> "Value is always contextual."
> 
> 
> 
> 

Re: [Pharo-users] #storeOn: question

[Mariano Martinez Peck]

On Mon, Nov 30, 2015 at 11:23 AM, Sven Van Caekenberghe 
wrote:

> Werner,
>
> > On 30 Nov 2015, at 15:15, Werner Kassens  wrote:
> >
> > Hi,
> > SortedCollection>>storeOn: seems to have a little problem since it does
> not store sortBlock and the used super-method (in Collection) uses #add:
> which uses sortBlock and their default uses #<=, hence if the elements are
> not comparable via #<=, but need a special sortblock, one gets an error on
> retrieving that collection. of course i can circumvent that tiny problem by
> defining #<= or using fuel, but i wonder whether i should report that on
> the bugtracker? btw perhaps some other collections with instanceVariables
> which do not define their own #storeOn: (eg Heap) could also have
> eventually some problems.
> > werner
>
> I am not so sure the #storeOn: / #readFrom: mechanism is still being
> maintained. I am not using it in any case, I thought it was mostly broken.
> I would be surprised if someone is still using it for real.
>
> But I might be wrong. In that case there should be a suite of real unit
> tests that defines and maintains the expected behaviour. And then you would
> be right, we should fix it.
>

Yes, I have the same feeling. And I hate having such a general protocol
like #storeOn: in our kernel objects. Store how? using which serializer?
I think if this protocol is still used it should be much clearer.
But as Sven said, I am not sure if this is still used and if it does, which
code use it, who is the "serializer", etc...

-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] #storeOn: question

[Werner Kassens]

Hi Sven,
i see, then i'll simply forget it (i asked, because i halfway expected 
that). thanks for that info.

werner

On 11/30/2015 03:23 PM, Sven Van Caekenberghe wrote:

I am not so sure the #storeOn: / #readFrom: mechanism is still being 
maintained. I am not using it in any case, I thought it was mostly broken. I 
would be surprised if someone is still using it for real.

But I might be wrong. In that case there should be a suite of real unit tests 
that defines and maintains the expected behaviour. And then you would be right, 
we should fix it.

Sven

Re: [Pharo-users] [ANN] breakpoints and watchpoints working

[Marcus Denker]

> On 30 Nov 2015, at 11:23, Ben Coman  wrote:
> 
> When doing [Add break once] on RubTextEditor>>selectWord, then
> double-clicking on any word in the Nautilus code pane, the debugger
> that pops up shows all temporary variables are nil, which seems wrong.
> Can someone confirm this behaviour?
> 

A break once added to a method means that it stops at the start of the method,
before any temps are assigned.

What seems to be wrong is the highlight… we need to put some more effort into
making sure that highlighting is correct. 

Marcus

Re: [Pharo-users] How fuel deals with circular reference ?

[Dimitris Chloupis]

Yes I have read the docs on how to use Fuel on how to use it and how to
exclude things I dont want to be stored in fuel file, I was just curious.
As a matter of fact I like deep copies.

Is it ok to use Fuel to make my own , super light, database ? Just a way to
manage and port my objects between images. Nothing very sophisticated.

On Mon, Nov 30, 2015 at 3:08 PM Mariano Martinez Peck 
wrote:

> On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis 
> wrote:
>
>> I have a class A that has an instance variable the references an instance
>> of Class B , but also Class B has an instance variable the references an
>> instance of Class A. Basically its a GUI that references its model and the
>> same model referencing the same instance of GUI.
>>
>>
> Dimitris,
>
> Fuel solves the circular references in the traditional way, that is, while
> traversing the graph, after processing each objects it stores it in a
> IdentityDictionary. Then, for each object to be processed, it first checks
> if the dictionary already includes that object. If true, then it has
> already been processed. If not, then lets process/traverse.
>
>
>
>> How Fuel deals with such scenario because I saw that it created an output
>> of 1.5 mbs for several instances of my model class ? Is there any danger of
>> having such circular references or it does not matter because afterall they
>> are just pointers ?
>>
>
> As Sven said, you need to be careful because you cannot be sure exactly
> all what Fuel can reach from a certain graph. If the graph was serialized
> into a 1.5mb then it has nothing to do to the fact of having circular
> references. It's simply the fact of the graph that ended up traversed.
>
> There are some tools inside Fuel to know what has been
> "traversed/processed" and that will next be serialized. This may help you
> realize that you are including in the graph things you don't want. We have
> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging
> but I am not sure if that's a bit outdated. Give it a try and if not ask.
> The ideally is to at least get the list of classes and instances that are
> being serialized. That's quite a help in a first place.
>
> Finally, if you found parts of the graph that you didn't want to
> serialize, then you can use different Fuel hooks to solve that
> (substitutions, ignoring certain intsVars, etc etc).
>
> Best,
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-users] How fuel deals with circular reference ?

[Mariano Martinez Peck]

On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis 
wrote:

> Yes I have read the docs on how to use Fuel on how to use it and how to
> exclude things I dont want to be stored in fuel file, I was just curious.
> As a matter of fact I like deep copies.
>
> Is it ok to use Fuel to make my own , super light, database ? Just a way
> to manage and port my objects between images. Nothing very sophisticated.
>

Yes, we did this for Quuve application when it runs (for development) under
Pharo. Of course, it will only work up to certain scale (since every commit
will serialize the whole database) and you do not have ACID, nor DB users,
no security, nor any other features of a real DB.

You may want to take a look to simple persistence to save some of your
development time since it has a Fuel backend:
http://smalltalkhub.com/#!/~TorstenBergmann/SimplePersistence


> On Mon, Nov 30, 2015 at 3:08 PM Mariano Martinez Peck <
> marianop...@gmail.com> wrote:
>
>> On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis > > wrote:
>>
>>> I have a class A that has an instance variable the references an
>>> instance of Class B , but also Class B has an instance variable the
>>> references an instance of Class A. Basically its a GUI that references its
>>> model and the same model referencing the same instance of GUI.
>>>
>>>
>> Dimitris,
>>
>> Fuel solves the circular references in the traditional way, that is,
>> while traversing the graph, after processing each objects it stores it in a
>> IdentityDictionary. Then, for each object to be processed, it first checks
>> if the dictionary already includes that object. If true, then it has
>> already been processed. If not, then lets process/traverse.
>>
>>
>>
>>> How Fuel deals with such scenario because I saw that it created an
>>> output of 1.5 mbs for several instances of my model class ? Is there any
>>> danger of having such circular references or it does not matter because
>>> afterall they are just pointers ?
>>>
>>
>> As Sven said, you need to be careful because you cannot be sure exactly
>> all what Fuel can reach from a certain graph. If the graph was serialized
>> into a 1.5mb then it has nothing to do to the fact of having circular
>> references. It's simply the fact of the graph that ended up traversed.
>>
>> There are some tools inside Fuel to know what has been
>> "traversed/processed" and that will next be serialized. This may help you
>> realize that you are including in the graph things you don't want. We have
>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging
>> but I am not sure if that's a bit outdated. Give it a try and if not ask.
>> The ideally is to at least get the list of classes and instances that are
>> being serialized. That's quite a help in a first place.
>>
>> Finally, if you found parts of the graph that you didn't want to
>> serialize, then you can use different Fuel hooks to solve that
>> (substitutions, ignoring certain intsVars, etc etc).
>>
>> Best,
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>


-- 
Mariano
http://marianopeck.wordpress.com