- Pharo-users - lists.pharo.org

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

by 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 <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] [ANN] breakpoints and watchpoints working

by 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 <marcus.denker(a)inria.fr> 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

Nov. 30, 2015

Re: [Pharo-users] #storeOn: question

by Sven Van Caekenberghe

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

Nov. 30, 2015

#storeOn: question

by 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

Nov. 30, 2015

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

by 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 <i.uhnak(a)gmail.com> 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 > <alexandre.bergel(a)me.com> 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 <i.uhnak(a)gmail.com> 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 >> <alexandre.bergel(a)me.com> 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 <i.uhnak(a)gmail.com> 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-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)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."

Nov. 30, 2015

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

by 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 <alexandre.bergel(a)me.com> 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 <i.uhnak(a)gmail.com> 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 > <alexandre.bergel(a)me.com> 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 <i.uhnak(a)gmail.com> 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-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Nov. 30, 2015

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

by Mariano Martinez Peck

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] graph library in Pharo

by 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 <i.uhnak(a)gmail.com> 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 > <alexandre.bergel(a)me.com> 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 <i.uhnak(a)gmail.com> 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >

Nov. 30, 2015

Help needed: old issues issue tracker entries

by marcus.denker＠inria.fr

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

Nov. 30, 2015

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

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

Nov. 30, 2015