November 2015 - Pharo-users

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

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