November 2015 - Pharo-users

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

by Christophe Demarey

Hi, Le 29 nov. 2015 Ã 20:00, Dimitris Chloupis a Ã©crit : > 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. could be. But we do not want to plug everything. Just having the door opened for the next cool VCS. Even if is only used for git it is good to have a Pharo API that is not the GIT API. We do not want git calls mixed everywhere. We want a clean and clear API for versioning. This API also prevents you from git API changes. You will only have one place to update and so on. > Right now Git is by very far the undisputed king of version control and has completely dethroned SVN. King because widely used but other are also as valuable if not more. > 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. I do not agree on this point. There is no VCS interoperability layer in Pharo. Tools are directly manipulating 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. again, I cannot agree. It is a bad idea to have calls to an external tool / library wide spread in the image. We need our own API. It is particularly true for git that has an API mixing daily tasks with other power admin commands (rewrite of the history with possible code loss). I do not think we need full support of git in the image, i.e. supporting all commands and options, but only what is needed to do correct versioning from Pharo (special git commands can still be done with command-line). > > 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. 30, 2015

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

by EuanM

That's great news. It would be really interesting, and really useful to community-enlargement works, to know: Which part of Thales drove this? What is their specific interest in Pharo? Or what is their current (or proposed) use of Pharo? On 26 November 2015 at 13:42, <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 >

Nov. 30, 2015

Re: [Pharo-users] Pharo RDBMS Support Survey

by EuanM

I completed it. (There was one question that I found hard to understand - so I commented my response heavily. I can't remember what my issue was - but my comments would remind me) On 26 November 2015 at 03:02, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hello all, > > I just created this survey (https://goo.gl/pcc9u8) to collect > information about the users of RDBMS in Pharo. > > Please promote it in the social networks, so I can get as many > responses as possible. > > URL: https://goo.gl/pcc9u8 > > I'll share the results in a month or before if I get 100 responses. :) > > > Thank you! > > > > Esteban A. Maringolo >

Nov. 30, 2015

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