October 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20324

by Marcus Denker

20324 ----- Issue 6769: Failing Test: HTTPSocketTest http://code.google.com/p/pharo/issues/detail?id=6769 Issue 6768: Implement isTraitMethod in RGCommentDefiniton http://code.google.com/p/pharo/issues/detail?id=6768 Issue 6767: Clean up ColorForm (old MVC / Postscript code) http://code.google.com/p/pharo/issues/detail?id=6767 -- Marcus Denker -- http://marcusdenker.de

Oct. 6, 2012

Re: [Pharo-project] Roassal Survey

by Ben Coman

Ciprian, Thanks for your detailed reply. Some comments inline... Ciprian Teodorov wrote: > Hi Ben, > > Sorry for the delay, I was very bussy these last few days. Attached to this > mail you will find some drawings showing what I mean. > > The first attachement [1] show the two most important graph concepts that > are needed for circuit design: the support for hyper-edges, and the ports > crossing hierarchical nodes. > The hyper-edges are useful to represent physical wires (which are connected > to a source, and then provide input to a number of sinks). > hyper-edges: Can you comment on how close Roassal Easel > #ROMondrianExample > #edges > orthoVerticalLine comes to your need for hyper-edges. Try arranging the nodes in various configurations. Note however... that where you have three "ortho" segments making up an edge and it looks like the first segment is shared by all edges, actually each edge has three segments each and the first segments are being drawn over the top of each other. Would that be significant? > The hierarchical crossings can be thought as the physical pins of an > integrated circuit, that are plugged into a socket in order to integrate > that circuit into a system. > hierarchical-crossing: Check out Roassal Easel > #ROMondrianExample > #edges > attachPoint. Also look at the coding of ROAttachPoint and subclasses, and in particular ROShorterDistanceAttachPoint>>fourFromPointsOfEdge: and >>fourToPointsOfEdge:. I think the way this has been done is quite elegant and building on these to create hierarchical-crossings might not be too hard. You might try it. Perhaps these might be called ROOuterAttachPoint and ROInnerAttachPoint and would respectively check to see if the connecting element is a contained sub-element. Alexandre, I think this example shows what I was badly hinting at with my "ROElement>>mostSpecificParentCommonWith:" thread. This used to decide which level within a hierarchy of sub-element edges are stored. Referring to the first attachement of Cipirian's post "Figure 2(a)", I think in this case the "inner" edges should be stored as part of the "Composite" element, but I think currently they would be stored in the parent of "Composite". Also I had been thinking for a while that it would be nice to be able to have AttachPoints rendered - both as permanently-visible and also visible-on-hover-only, so that when I re-implement the edge rubber-banding to interactive draw lines between elements (which I demoed to you a while ago on Mondrian) the user could drop the edge-end onto a specific AttachPoint. > The second, and third attachement are the same (only the format differs pdf > vs png). They show a detailed example of the hierarchical structure that I > imagine. The main elements of this graphs are: the leaf nodes, the edges, > the hierarchical nodes, the pins, and the ports. > The leaf nodes are just the typical graph nodes. The edges are just links > between nodes. > The hierarchical nodes are graphs themselves, but they can be connected one > to another using edges. However these connections between hierarchical > nodes are done through the pins present on their interface. If such a > hierarchical node wants to be connected to the exterior it has to have pins > so that the layout algorithm can be constrained to route the edges to these > pins (which can be either free or have fixed positions). > The ports in my figure are just ways to group together a number of pins. > > In the figure you will see three graphs (corresponding to three views on > the leftmost graph). > The first one (on the left) just represents the top-level graph with all > hierarchical nodes collapsed. This graph itself has a number of ports so > that it can be embedded in another one. > The second one (in the middle) shows an expanded view of the central > hierarchical node in the top-level graph. This one is expanded into another > view. > The third one (in the right) shows yet another expanded view, this time of > a node in the middle graph. This last graph contains two hierarchical nodes > itself that are expanded in place. > > Now the idea of edges crossing hierarchy boundaries through pins is that > the inner-most hierarchical nodes can be layed out separately and then > collapsed, their containers can be layed out just like a simple graph (in > the case their nodes are collapsed). However if one node is a hierarchical > one, and is expanded, the layout algorithm does not have to layout the > contents inside this hierarchical node, it just layouts the whole graph > considering the pins as fixed nodes to which it will route the links. This > way when expanded the hierarchical nodes retain their initial layout, > moreover this initial layout takes into account the fact that the node will > be embedded into a larger graph and thus it will place the pins on the > boundary. > What do you think of Roassal Easel > Examples > ROExample > #interaction > zooming and ROExample > #interaction > expandableNodesOn: ? > FYI the graphs shown in the last two attachements where automatically > generated from a circuit design, they were imported into the Yed diagram > editor, one by one, layed out semi-automatically (used force-based layout > initially, an then moved a number of nodes manually to align them well - ex > the straight edges were obtained by manually moving the nodes). Just > imagine how boring this process is. Moreover since I had to represent the > pins, and the ports just as plain graph nodes grouped together the layout > algorithms don't have any idea that these nodes are special, thus they > place them everywhere, even more if the groups are expanded their inner > nodes are layouted along with the embedding hierarchy... resulting in a > mess. > > Cheers, > Ciprian > * > * > *References:* > [1] Miro Sponemann, Hauke Fuhrmann, Reinhard von Hanxleden, and Petra > Mutzel. > Port constraints in hierarchical layout of data > flow<http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd09.pdf> > diagrams<http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd09.pdf> > . > In David Eppstein and Emden Gansner, editors, Graph Drawing, volume 5849 of > Lecture Notes in Computer Science, chapter 14. > Springer Berlin / Heidelberg, Berlin, Heidelberg, 2010. > > On Thu, Sep 27, 2012 at 3:35 PM, Ben Coman <btc(a)openinworld.com> wrote: > > >> Ciprian Teodorov wrote: >> >> >>> Another feature that I think it is missing in most (if not all) graph >>> viewers/layout systems/editors is the possibility to have connection ports >>> on the hierarchical nodes in order to preserve the connections passing >>> through the hierarchy. >>> >>> some pointers: >>> >>> http://www.slideshare.net/**teodorov/tools-and-**crossbarbased-nanocmos-* >>> *architectures<http://www.slideshare.net/teodorov/tools-and-crossbarbased-nanocmos-archite…> >>> >>> http://stiff.univ-brest.fr/~**cteodorov/manuscript-teodorov_**FINAL.pdf<http://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf> >>> >>> >>> Cheers, >>> >>> Ciprian Teodorov >>> >>> >>> On Sep 26, 2012 6:16 PM, "Vanessa PeÃ±a Araya" <van.c.pena(a)gmail.com> >>> wrote: >>> >>> >>> >>> >> Ciprian, >> >> I have skimmed through those links but can't quite understand your comment >> "in order to preserve the connections passing through the hierarchy" Can >> you expand some more on that - perhaps with a mock up in a paint program? >> >> If you are interested in following the development of Roassal, perhaps >> move your follow up to https://www.iam.unibe.ch/** >> mailman/listinfo/moose-dev<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>. >> <https://www.iam.unibe.ch/**mailman/listinfo/moose-dev<https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> I have been very encouraged by the clean architecture and the >> responsiveness of the main developers to feature suggestions. >> >> cheers, Ben >> >> >> > > > > > ------------------------------------------------------------------------ >

Oct. 6, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 394 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Oct. 6, 2012

Re: [Pharo-project] Roassal Survey

by Ciprian Teodorov

Hi Ben, Sorry for the delay, I was very bussy these last few days. Attached to this mail you will find some drawings showing what I mean. The first attachement [1] show the two most important graph concepts that are needed for circuit design: the support for hyper-edges, and the ports crossing hierarchical nodes. The hyper-edges are useful to represent physical wires (which are connected to a source, and then provide input to a number of sinks). The hierarchical crossings can be thought as the physical pins of an integrated circuit, that are plugged into a socket in order to integrate that circuit into a system. The second, and third attachement are the same (only the format differs pdf vs png). They show a detailed example of the hierarchical structure that I imagine. The main elements of this graphs are: the leaf nodes, the edges, the hierarchical nodes, the pins, and the ports. The leaf nodes are just the typical graph nodes. The edges are just links between nodes. The hierarchical nodes are graphs themselves, but they can be connected one to another using edges. However these connections between hierarchical nodes are done through the pins present on their interface. If such a hierarchical node wants to be connected to the exterior it has to have pins so that the layout algorithm can be constrained to route the edges to these pins (which can be either free or have fixed positions). The ports in my figure are just ways to group together a number of pins. In the figure you will see three graphs (corresponding to three views on the leftmost graph). The first one (on the left) just represents the top-level graph with all hierarchical nodes collapsed. This graph itself has a number of ports so that it can be embedded in another one. The second one (in the middle) shows an expanded view of the central hierarchical node in the top-level graph. This one is expanded into another view. The third one (in the right) shows yet another expanded view, this time of a node in the middle graph. This last graph contains two hierarchical nodes itself that are expanded in place. Now the idea of edges crossing hierarchy boundaries through pins is that the inner-most hierarchical nodes can be layed out separately and then collapsed, their containers can be layed out just like a simple graph (in the case their nodes are collapsed). However if one node is a hierarchical one, and is expanded, the layout algorithm does not have to layout the contents inside this hierarchical node, it just layouts the whole graph considering the pins as fixed nodes to which it will route the links. This way when expanded the hierarchical nodes retain their initial layout, moreover this initial layout takes into account the fact that the node will be embedded into a larger graph and thus it will place the pins on the boundary. FYI the graphs shown in the last two attachements where automatically generated from a circuit design, they were imported into the Yed diagram editor, one by one, layed out semi-automatically (used force-based layout initially, an then moved a number of nodes manually to align them well - ex the straight edges were obtained by manually moving the nodes). Just imagine how boring this process is. Moreover since I had to represent the pins, and the ports just as plain graph nodes grouped together the layout algorithms don't have any idea that these nodes are special, thus they place them everywhere, even more if the groups are expanded their inner nodes are layouted along with the embedding hierarchy... resulting in a mess. Cheers, Ciprian * * *References:* [1] Miro Sponemann, Hauke Fuhrmann, Reinhard von Hanxleden, and Petra Mutzel. Port constraints in hierarchical layout of data flow<http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd09.pdf> diagrams<http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd09.pdf> . In David Eppstein and Emden Gansner, editors, Graph Drawing, volume 5849 of Lecture Notes in Computer Science, chapter 14. Springer Berlin / Heidelberg, Berlin, Heidelberg, 2010. On Thu, Sep 27, 2012 at 3:35 PM, Ben Coman <btc(a)openinworld.com> wrote: > Ciprian Teodorov wrote: > >> Another feature that I think it is missing in most (if not all) graph >> viewers/layout systems/editors is the possibility to have connection ports >> on the hierarchical nodes in order to preserve the connections passing >> through the hierarchy. >> >> some pointers: >> >> http://www.slideshare.net/**teodorov/tools-and-**crossbarbased-nanocmos-* >> *architectures<http://www.slideshare.net/teodorov/tools-and-crossbarbased-nanocmos-archite…> >> >> http://stiff.univ-brest.fr/~**cteodorov/manuscript-teodorov_**FINAL.pdf<http://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf> >> >> >> Cheers, >> >> Ciprian Teodorov >> >> >> On Sep 26, 2012 6:16 PM, "Vanessa PeÃ±a Araya" <van.c.pena(a)gmail.com> >> wrote: >> >> >> > Ciprian, > > I have skimmed through those links but can't quite understand your comment > "in order to preserve the connections passing through the hierarchy" Can > you expand some more on that - perhaps with a mock up in a paint program? > > If you are interested in following the development of Roassal, perhaps > move your follow up to https://www.iam.unibe.ch/** > mailman/listinfo/moose-dev<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>. > <https://www.iam.unibe.ch/**mailman/listinfo/moose-dev<https://www.iam.unibe.ch/mailman/listinfo/moose-dev> > > > I have been very encouraged by the clean architecture and the > responsiveness of the main developers to feature suggestions. > > cheers, Ben > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Oct. 6, 2012

[Pharo-project] [update 2.0] #20323

by Marcus Denker

20323 ----- Issue 6766: Simplify Debugger Stack menu http://code.google.com/p/pharo/issues/detail?id=6766 Issue 6714: Incorrect bounds in IndentingListItemMorph http://code.google.com/p/pharo/issues/detail?id=6714 -- Marcus Denker -- http://marcusdenker.de

Oct. 6, 2012

Re: [Pharo-project] To try out FileSystem in 2.0 -- which download?

by StÃ©phane Ducasse

On Oct 5, 2012, at 10:57 AM, Sven Van Caekenberghe wrote: > > On 04 Oct 2012, at 08:02, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> I would start with the book chapter: >> >> http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/FileSystem.p… > > To those who helped writing this chapter and bringing FileSystem to Pharo and writing FileSystem in the first place: thanks ! > > One thing though: the public API as described in the high-level documentation should be used to write method comments - this is a contribution that anyone can do ;-) yes with camillo we added method comments too :). Stef

Oct. 5, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 393 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Oct. 5, 2012

[Pharo-project] [update 2.0] #20322

by Marcus Denker

20322 ----- Issue 6764: Fuel out Error / StackTrace http://code.google.com/p/pharo/issues/detail?id=6764 Issue 6717: Workspace Menus Broken http://code.google.com/p/pharo/issues/detail?id=6717 -- Marcus Denker -- http://marcusdenker.de

Oct. 5, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 392 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Oct. 5, 2012

Re: [Pharo-project] Setting a external FTP

by Edgar J. De Cleene

On 10/5/12 9:59 AM, "Camillo Bruni" <camillobruni(a)gmail.com> wrote: > This will only work in 1.4. ServerDirectory is gone in 2.0. > > Maybe someone out there has some excess energy to implement an > FTP Filesystem backend, or even nicer an S3 Filesystem ;) > > best > cami I forget tell is a fresh Pharo-1.4-14557 one click Is important to me and my guess is some could use this also, so I share Edgar

Oct. 5, 2012