- Pharo-users - lists.pharo.org

Re: [Pharo-users] PharoJS Status

by Noury Bouraqadi

Just tested with a fresh image and it worked. Noury > On 30 Nov 2015, at 16:37, Andy Burnett <andy.burnett(a)knowinnovation.com> 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

Nov. 30, 2015

Re: [Pharo-users] PharoJS Status

by 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

Nov. 30, 2015

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

by 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 <yuriy.tymchuk(a)me.com> 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 <tudor(a)tudorgirba.com> 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.denker(a)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." >> >> >> >> > >

Nov. 30, 2015

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

by Peter UhnÃ¡k

> With Guillaume Larcheveque, we tried to implement in Pharo the graph algorithm implemented in Graphiz. Do you have some WIP code? Maybe I could salvage something? > Would you consider implementing it as part of the Moose-Algos project I will make it a separate project for now, but I can move it to Moose-Algos once it stabilizes. > or part of Roassal? The purpose of those algorithms is for better Roassal layouting, so once it's done it will have to be close. Peter

Nov. 30, 2015

PharoJS Status

by 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

Nov. 30, 2015

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

by Mariano Martinez Peck

On Mon, Nov 30, 2015 at 11:40 AM, Dimitris Chloupis <kilon.alios(a)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 < > marianopeck(a)gmail.com> wrote: > >> On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis <kilon.alios(a)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

Nov. 30, 2015

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

by 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 <marianopeck(a)gmail.com> wrote: > On Mon, Nov 30, 2015 at 8:41 AM, Dimitris Chloupis <kilon.alios(a)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 >

Nov. 30, 2015

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

by Marcus Denker

> On 30 Nov 2015, at 11:23, Ben Coman <btc(a)openinworld.com> 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

Nov. 30, 2015

Re: [Pharo-users] #storeOn: question

by 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 >

Nov. 30, 2015

Re: [Pharo-users] #storeOn: question

by Mariano Martinez Peck

On Mon, Nov 30, 2015 at 11:23 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Werner, > > > On 30 Nov 2015, at 15:15, Werner Kassens <wkassens(a)libello.com> 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

Nov. 30, 2015