- Pharo-users - lists.pharo.org

Re: [Pharo-users] graph library in Pharo

by Peter UhnÃ¡k

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

Re: [Pharo-users] graph library in Pharo

by Alexandre Bergel

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. 29, 2015

graph library in Pharo

by Peter Uhnak

Hi, is there any graph library for pharo with algorithms for planarity testing, spanning trees, flow costs, etc.? Thanks, -- Peter

Nov. 29, 2015

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

by Dimitris Chloupis

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 <stepharo(a)free.fr> 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_… > > Stef > > >

Nov. 29, 2015

Re: [Pharo-users] Spec: Binding widgets how to

by Nicolai Hess

2015-11-26 19:36 GMT+01:00 Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> : > Hi, > > I had tried that before and didn't work. Passing information between > widgets and back in this spec interface seems my stop point now... If > someone could help me with some kind of minimalist example that uses > treeModel, that would be greatly appreciated. > Find attached a minimal example. (I use Morph and its subclasses for generating some tree data, these are just names, renaming a node does not rename the class :)) You can listen on tree node selection by registering with #whenSelectedChanged, on the TreeNode(!) "create the node" t := TreeNodeModel new content: aClass name; hasChildren: [ aClass subclasses notEmpty ]; children: [ subItems ifNil:[subItems:=aClass subclasses collect: [ :s | self buildNodeFor: s ] ]]; yourself. "listen on selection" t whenSelectedChanged: [ :bool | bool ifTrue:[self field text: t content] ]. this will change the text field content with the content of the node (the default label). Changing the label node *Morph* on accepting the text field text is somehow impossible or difficult. I would have expected that Spec would create a MorphicTreeNodeAdapter that represents some Morph, for which the adapter would update/change the state, if you change the TreeNodeModel content. Instead, it creates some strange SpecTreeNodeModel. And the only way to update the NodeLabel and make this change visible is to rebuild the whole tree: tree roots: tree roots. Yes, I did not find another way. Luckily MorphTreeMorph is smart enough to remember the selection and path expansion state, so this works quite well. > > Cheers, > > Offray > > > On 26/11/15 12:47, webwarrior wrote: > >> Try #whenHighlightedItemChanged: method. >> >> I remember that distinction between selection/highlight is not very clear >> in >> TreeModel. >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Spec-Binding-widgets-how-to-tp4863742p4863757.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> > >

Nov. 29, 2015

Re: [Pharo-users] Sharing data between images

by Dimitris Chloupis

" 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." FUEL !!! Lol how I forgot about it ? Nice , I think its exactly what I was looking for , thanks. "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." Yeah both options look very good, I think I may need something fast because I may end up with a lot of data (3d graphics data). So I will go with Fuel. The nice thing about STON is that because is JSON it will be easier to move between different languages. But then nothing stops me from choosing Fuel and making also a JSON exporter with STON. "I used message pack before. Nice thing is that you can easily also integrate to other environments." Thanks will take a look at this as well.

Nov. 29, 2015

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

by stepharo

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_… Stef

Nov. 29, 2015

Re: [Pharo-users] [Pharo5] Semantic Warnings as icons in the editor

by stepharo

I'm happy to see all the pieces coming together. It was thinking about it that we worked with frank and alain on putting rubric in place and now it pays off :). Stef Le 28/11/15 23:01, Marcus Denker a Ã©crit : > Hi, > > One result of Fridayâs Pharo Sprint in Chile: Use the nice icons of > the new text editor > to display some of the semantic errors nicely (instead of breaking > flow with a intrusive dialog): > > This was done by Johan based on the prototype Miguel did in September: > > 1) unused temps: > > > (the âdrag the crosshairâr is an artefact of the snapshot tool) > > 2) temps used that are not initialised: > > > > In a next step, we need to integrate that with the QA toolâ¦ no need to > have this reported > twice. > > What is nice is that this simplified the Compiler: instead of having > an Exception and raising > it, we now just annotate the AST: > > unusedVariable: variableNode > > variableNode propertyAt: #semanticWarning put: 'unused variableâ > > (this is very simple for now, with a node just being able to have one > kind of semanticWarning). > > SemanticWarningIconStyler is what adds the icon. It has 4 methods with > one line each. > > Marcus >

Nov. 29, 2015

Re: [Pharo-users] Sharing data between images

by Sebastian Heidbrink

I used message pack before. Nice thing is that you can easily also integrate to other environments. https://github.com/msgpack/msgpack-smalltalk http://smalltalkhub.com/#!/~MasashiUmezawa/MessagePack Seabstian On 2015-11-29 6:57 AM, 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.

Nov. 29, 2015

Re: [Pharo-users] Sharing data between images

by Sven Van Caekenberghe

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 <jfabry(a)dcc.uchile.cl> 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 <kilon.alios(a)gmail.com> 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 >

Nov. 29, 2015