July 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] UPnP/IGD implementation

by Henrik Johansen

You don't use SSDP to do the tweaking, but to discover the devices that are available to tweak. Tweaking is subsequently carried out using SOAP/XML. An an uninformed guess, I'd imagine use could look a bit like this: SSDPClient when: IGDServiceAvailable do: [:IGDService | IGDConfigurator configure: IGDService to: [:configurator | configurator ppp natEnabled: true; addPortMapping: srcPort to: dstPort on: targetMachine ] Where IGDConfigurator / ppp is the missing piece, building/sending SOAP messages* to the provided service, corresponding to http://upnp.org/specs/gw/UPnP-gw-WANPPPConnection-v1-Service.pdf Cheers, Henry * the core (messaging parts of http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf) of which can probably be abstracted into a UPnPConfigurator, so all you do in IGD is link the API to which fields to send in the soap messages > On 26 Jul 2016, at 4:19 , Norbert Hartl <norbert(a)hartl.name> wrote: > > Thanks, > > I think I need to read a bit further in order to understand how it works really. Didn't know SSDP ist used when tweaking things with IGD. > > Norbert > >> Am 25.07.2016 um 17:01 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> >> SSDP covers discovery of the services and how they are set up; SOAP and XML are then used to access the service. >> IANAE, but; I think as long as you restrict yourself to implement use of the particular service (IGD) you are interested in, it shouldn't be all that bad; >> the use of SSDP discovery data should be fairly straigh forward the way its modelled; you provide the client with callbacks that run when a service of the type you've specified you're interested in becomes available/unavailable. >> >> The main problem with UPnP (well, other than accessing services involving SOAP and XML instead of REST) is its size; a callback handling "IGD service discovered" should be much simpler than if one wanted to handle "UPnP device discovered" (or, if that's the pattern, restricting UPnP device discovery handling to check if IGD is available). >> >> (You might want a separate Service subclass to ease access / document what the different fields are though, IIRC, the current Service follows the MorphicExtension pattern of putting anything that does not have a well-defined meaning in SSDP in a dictionary) >> >> Cheers, >> Henry >> >>> On 25 Jul 2016, at 3:29 , Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Thanks, >>> >>> am I wrong in assuming the UPnP and IGD are rather huge and complicated things to implement? I just want to figure out if there is a clear answer to the question if implementing a subset or using a library (mini upnp) through FFI is more feasible. >>> >>> Norbert >>>> Am 25.07.2016 um 16:10 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>>> >>>> >>>>> On 25 Jul 2016, at 12:13 , Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> >>>>> Does anyone know some code or person that did something with UPnP/IGD in pharo? >>>>> >>>>> thanks, >>>>> >>>>> Norbert >>>> >>>> >>>> I've done an SSDP client/server, but not gone so far as to build a full UPnP model on top of it, since I just needed a discovery protocol. >>>> http://smalltalkhub.com/#!/~henriksp/SSDP. >>>> >>>> Should be possible to use as a base though; you can make a client with type ssdp:all, and get some fun replies indicating the services available on UPnP routers. >>>> >>>> Caveats apply to the socket init code which is really ugly, it attempts to listen on all the interfaces present at the time of client creation, but the correct primitives aren't really exposed from the plugin, the results can be a bit hit and miss depending on OS/Distribution; nor are there hooks to get notified when interfaces go up/down, so accounting for such currently comes down to manual resets. >>>> >>>> Cheers, >>>> Henry >>> >>> >> > >

July 26, 2016

Re: [Pharo-users] Spec: Capturing changes in a text morph

by Johan Fabry

I think the problem is that when you click on an item in the tree (2), the contents of (4) is changed to a new widget. As a result the configuration that you did in initializePresenter is lost. What you should do is when you change the contents of (4) also configure this new widget with a whenTextChanged: block. I think that will solve your problem. -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Jul 25, 2016, at 18:12, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > I'm migrating my grafoscopio interface from I'm trying to capture some changes in a text morph that is part of a Spec interface. The interface is split in 4 parts, as you can see at [a]: (1) a main menu, (2) a tree, (3) a node header input text and (4) a text morph. When you click any node on the tree (2) the name of the node, called the header is shown in (3) and the node contents, called the body are shown at (4). If you made a change in the header (pressing enter) it's reflected back to the main tree. And the node's body is changed for a text morph [b] or a and embedded playground [c] according to tags in the node. So the reading part is working and I have some partial support for persistence, at least for node headers. > > [a] https://offray.withknown.com/2016/grafoscopio-notebook-interface > [b] https://offray.withknown.com/2016/grafoscopio-text-node > [c] https://offray.withknown.com/2016/grafoscopio-code-node > > Now I would like to extend the persistence for node's body content, so when any changes happens in the (4) panel, be it a text panel or a playground, it is stored in a similar way to what is happening with node headers and the (3) panel, but I'm unsuccessful trying to capture those changes. > > My initializeWidgets and initializePresenter are implemented this way: > > ================= > > GrafoscopioNotebook>>initializeWidgets > > windowMainMenu := self newWindowMainMenu. > tree := TreeModel new. > body := self newText. > header := self newTextInput. > > body disable. > body text: '<-- Select a node in the left panel'. > > tree > childrenBlock: [:node | node children]; > displayBlock: [:node | node title ]. > > ================= > > initializePresenter > > tree whenSelectedItemsChanged: [ :arg | > arg isEmpty ifFalse: [self changeBody: arg ]]. > header whenTextChanged: [ :arg | > Transcript show: arg. > (tree selectedItem content header) = arg > ifFalse: [ > (tree selectedItem) content header: arg. > tree roots: tree roots]]. > body whenTextIsAccepted: [ :arg | > Transcript show: arg > ] > > ================= > > I'm capturing properly the changes in text with whenTextChanged on the header but using the same message on body or whenTextIsAccepted doesn't produce any change on the trascript, and of course I can't update the any tree/node contents properly. > > Any advice on how to solve this will be greatly appreciated. If can happen soon in this week even better, because we could show this to our hackathon/workshop attendees. > > Cheers, > > Offray > > >

July 26, 2016

Re: [Pharo-users] UPnP/IGD implementation

by Norbert Hartl

Thanks, I think I need to read a bit further in order to understand how it works really. Didn't know SSDP ist used when tweaking things with IGD. Norbert > Am 25.07.2016 um 17:01 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > SSDP covers discovery of the services and how they are set up; SOAP and XML are then used to access the service. > IANAE, but; I think as long as you restrict yourself to implement use of the particular service (IGD) you are interested in, it shouldn't be all that bad; > the use of SSDP discovery data should be fairly straigh forward the way its modelled; you provide the client with callbacks that run when a service of the type you've specified you're interested in becomes available/unavailable. > > The main problem with UPnP (well, other than accessing services involving SOAP and XML instead of REST) is its size; a callback handling "IGD service discovered" should be much simpler than if one wanted to handle "UPnP device discovered" (or, if that's the pattern, restricting UPnP device discovery handling to check if IGD is available). > > (You might want a separate Service subclass to ease access / document what the different fields are though, IIRC, the current Service follows the MorphicExtension pattern of putting anything that does not have a well-defined meaning in SSDP in a dictionary) > > Cheers, > Henry > >> On 25 Jul 2016, at 3:29 , Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Thanks, >> >> am I wrong in assuming the UPnP and IGD are rather huge and complicated things to implement? I just want to figure out if there is a clear answer to the question if implementing a subset or using a library (mini upnp) through FFI is more feasible. >> >> Norbert >>> Am 25.07.2016 um 16:10 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>> >>> >>>> On 25 Jul 2016, at 12:13 , Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> Does anyone know some code or person that did something with UPnP/IGD in pharo? >>>> >>>> thanks, >>>> >>>> Norbert >>> >>> >>> I've done an SSDP client/server, but not gone so far as to build a full UPnP model on top of it, since I just needed a discovery protocol. >>> http://smalltalkhub.com/#!/~henriksp/SSDP. >>> >>> Should be possible to use as a base though; you can make a client with type ssdp:all, and get some fun replies indicating the services available on UPnP routers. >>> >>> Caveats apply to the socket init code which is really ugly, it attempts to listen on all the interfaces present at the time of client creation, but the correct primitives aren't really exposed from the plugin, the results can be a bit hit and miss depending on OS/Distribution; nor are there hooks to get notified when interfaces go up/down, so accounting for such currently comes down to manual resets. >>> >>> Cheers, >>> Henry >> >> >

July 26, 2016

Re: [Pharo-users] Pharo and GIT

by Nicolas Passerini

Thanks Peter, I think that is related to the bug we found this morning <https://github.com/npasserini/iceberg/issues/98> with Esteban. I couldn't give a look at it today, but maybe tomorrow I can have a solution and I will ask you to try again if possible. On Tue, Jul 26, 2016 at 4:26 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Also the error is the same both in Pharo 5 and Pharo 6 > > On Tue, Jul 26, 2016 at 4:25 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> * (docs) from readme file it's not clear whether I have to run >>>> the update command; running it will brick the installation >>>> >>> >>> Update is not mandatory, but should be a useful way to get the latest >>> version. I'm not sure of having understood you, is that you tried it and it >>> failed? >>> >> >> Indeed. >> >> First of all, if I try to clone without ssh key I get an error >> >> >> â >> This is non-problem for me as I just forgot to give the key to the agent. >> >> However if I then (in a fresh pharo, so unrelated by the error above) run >> it with the key, I get the following warning >> >> >> â >> If I proceed, the updated finishes, but opening Iceberg gives me this >> error >> >> >> â >> Peter >> > >

July 26, 2016

Re: [Pharo-users] Pharo and GIT

by Peter UhnÃ¡k

Also the error is the same both in Pharo 5 and Pharo 6 On Tue, Jul 26, 2016 at 4:25 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > * (docs) from readme file it's not clear whether I have to run the >>> update command; running it will brick the installation >>> >> >> Update is not mandatory, but should be a useful way to get the latest >> version. I'm not sure of having understood you, is that you tried it and it >> failed? >> > > Indeed. > > First of all, if I try to clone without ssh key I get an error > > > â > This is non-problem for me as I just forgot to give the key to the agent. > > However if I then (in a fresh pharo, so unrelated by the error above) run > it with the key, I get the following warning > > > â > If I proceed, the updated finishes, but opening Iceberg gives me this error > > > â > Peter >

July 26, 2016

Re: [Pharo-users] Pharo and GIT

by Peter UhnÃ¡k

> > * (docs) from readme file it's not clear whether I have to run the >> update command; running it will brick the installation >> > > Update is not mandatory, but should be a useful way to get the latest > version. I'm not sure of having understood you, is that you tried it and it > failed? > Indeed. First of all, if I try to clone without ssh key I get an error â This is non-problem for me as I just forgot to give the key to the agent. However if I then (in a fresh pharo, so unrelated by the error above) run it with the key, I get the following warning â If I proceed, the updated finishes, but opening Iceberg gives me this error â Peter

July 26, 2016

Re: [Pharo-users] Pharo and GIT

by Dimitris Chloupis

I am using the github interface to do so like this https://github.com/kilon/Ephestos/search?utf8=%E2%9C%93&q=ephestos github also provides a set of keywords to refine searches, I think also regex is supported,you can find more info in these links https://help.github.com/articles/searching-github/ https://help.github.com/articles/advanced-search/ https://help.github.com/articles/search-syntax/ https://help.github.com/articles/searching-code/ https://help.github.com/articles/searching-issues/ https://help.github.com/articles/searching-users/ On Tue, Jul 26, 2016 at 3:19 PM Nicolas Passerini <npasserini(a)gmail.com> wrote: > Could you give examples of code searches that you would be able to do in > the history. > > I think that for searching the history of a method or class, it is simpler > (and faster) to do it in git than it is to do it in monticello. > > On Tue, Jul 26, 2016 at 1:31 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> Github has a search code facility , unless you mean something else. We >> could take advantage of that and unite it with our ability to browse >> implementors and classes. There is no limit how deeply we can integrate >> with git and github and we can extend both via Pharo to make them more >> Pharo friendly. >> >> On the subject of smalltalkhub it was always of question who will >> maintain it. But is one thing to want something another to take control and >> responsibility for it. None stoping anyone from contributing to anything. >> Problem is sthub will need a ton of work to be a good alternative to >> github. >> >> On Tue, 26 Jul 2016 at 01:36, Sean Glazier <sglazier456(a)gmail.com> wrote: >> >>> Thank you, Peter for documenting that :-). While I think git tools are >>> OK, my opinion though is that Smalltalk hub should be moved forward as >>> well. At cincom the Store experience started out painful and it has its >>> quirks, but one of the advantages is that I could write tools to do things >>> like browse senders and implementors in the repository. I git you are >>> working with files and text and it does not have the notion of classes and >>> methods and the value of being able to see the history of the class / >>> methods. It is valuable when needing to understand not just the current >>> implementation but where it came from. In Store, I could search and see >>> when a method was present of a class and in what version lets say it got >>> dropped unintentionally for instance. Even more important I think is to >>> also note thing like renames and in cincom namespace renames and moves. >>> I was working a while back on a way to have a persistent diary for a >>> class that could note these histories and maintained and more importantly >>> searchable from the image. >>> I wrote tools too, to attach to a number of databases (repositories) and >>> search for classes and the comments. Helpful when you are searching to see >>> if someone else has solved a problem before. Git tools can tell you a lot >>> about the repository you are publishing to and comparing code etc. But it >>> does not help you to search across repositories and the data. >>> >>> I know this idea is a tall order. If we improved our tools to beable do >>> this, no matter what the repository is behind it, that would be very >>> helpful and powerful. I think it is a challenge in git because it is >>> dealing with text and does not have a notion of what a class is etc. If we >>> continue and put in more powerful search abilities, it will require using >>> different paradigm in representing code so we can do more powerful things >>> with the repository. We can browse the class without loading it but that >>> gets us only so far. >>> >>> Just my 0.02 ;-) >>> >>> >>> >>> Kind Regards, >>> >>> Sean Glazier >>> >>> >>> On Mon, Jul 25, 2016 at 1:28 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>>> Hi Juraj, >>>> >>>> I've finally forced myself to finish a guide on using gitfiletree: >>>> https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… >>>> so hopefully it will be of some use to you. >>>> >>>> Couple of notes: >>>> * GitFileTree loaded from Catalog still doesn't work in Pharo >>>> 6, so use the script Thierry provided >>>> * There's some pain associated with some operations (e.g. >>>> merging, loading), this will be addressed sooner or later by IceBerg, which >>>> is hopefully the future of git in Pharo ( >>>> https://github.com/npasserini/iceberg ) >>>> >>>> Peter >>>> >>>> On Mon, Jul 25, 2016 at 11:47:24AM -0400, Juraj Kubelka wrote: >>>> > Hi Alexandre, >>>> > >>>> > I will first give a try. I think once the Pharo community moves to >>>> GitHub, it will help to all. It could be painful, but SmalltalkHub is also >>>> painful and we are loosing other opportunities that GitHub service offers. >>>> > >>>> > I agree that it could be painful. I am fine using external GIT tools. >>>> Even for Java (or other) projects I use external GIT tools. The important >>>> is that we can easily deploy projects and people can load it (,e.g., >>>> Catalog Browser). >>>> > >>>> > Cheers, >>>> > Juraj >>>> > >>>> > > On Jul 25, 2016, at 09:14, Alexandre Bergel < >>>> alexandre.bergel(a)me.com> wrote: >>>> > > >>>> > > Hi Juraj, >>>> > > >>>> > > Although I find very appealing to work with Git, it is still very >>>> painful. Some of the issues I feel right now: difficult of merging, >>>> checking for source code differences, there is unfortunately a difference >>>> between installing using Metacello and cloning a repository, â¦ >>>> > > We can discuss it if you want (I am back in Chile). >>>> > > >>>> > > Alexandre >>>> > > >>>> > > >>>> > >> On Jul 25, 2016, at 8:41 AM, Juraj Kubelka < >>>> juraj.kubelka(a)icloud.com> wrote: >>>> > >> >>>> > >> Hi, >>>> > >> >>>> > >> can you point me to a latest (best) way to use GitHub for Pharo >>>> projects (Pharo 6)? >>>> > >> >>>> > >> Is the GitFileTree project the way to use it? >>>> > >> >>>> > >> How does ConfigurationOf change? >>>> > >> >>>> > >> Thanks! >>>> > >> Juraj >>>> > > >>>> > > -- >>>> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> > > Alexandre Bergel http://www.bergel.eu >>>> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> > > >>>> > > >>>> > > >>>> > > >>>> > >>>> > >>>> >>>> >>> >

July 26, 2016

Re: [Pharo-users] Pharo and GIT

by Nicolas Passerini

Could you give examples of code searches that you would be able to do in the history. I think that for searching the history of a method or class, it is simpler (and faster) to do it in git than it is to do it in monticello. On Tue, Jul 26, 2016 at 1:31 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Github has a search code facility , unless you mean something else. We > could take advantage of that and unite it with our ability to browse > implementors and classes. There is no limit how deeply we can integrate > with git and github and we can extend both via Pharo to make them more > Pharo friendly. > > On the subject of smalltalkhub it was always of question who will maintain > it. But is one thing to want something another to take control and > responsibility for it. None stoping anyone from contributing to anything. > Problem is sthub will need a ton of work to be a good alternative to > github. > > On Tue, 26 Jul 2016 at 01:36, Sean Glazier <sglazier456(a)gmail.com> wrote: > >> Thank you, Peter for documenting that :-). While I think git tools are >> OK, my opinion though is that Smalltalk hub should be moved forward as >> well. At cincom the Store experience started out painful and it has its >> quirks, but one of the advantages is that I could write tools to do things >> like browse senders and implementors in the repository. I git you are >> working with files and text and it does not have the notion of classes and >> methods and the value of being able to see the history of the class / >> methods. It is valuable when needing to understand not just the current >> implementation but where it came from. In Store, I could search and see >> when a method was present of a class and in what version lets say it got >> dropped unintentionally for instance. Even more important I think is to >> also note thing like renames and in cincom namespace renames and moves. >> I was working a while back on a way to have a persistent diary for a >> class that could note these histories and maintained and more importantly >> searchable from the image. >> I wrote tools too, to attach to a number of databases (repositories) and >> search for classes and the comments. Helpful when you are searching to see >> if someone else has solved a problem before. Git tools can tell you a lot >> about the repository you are publishing to and comparing code etc. But it >> does not help you to search across repositories and the data. >> >> I know this idea is a tall order. If we improved our tools to beable do >> this, no matter what the repository is behind it, that would be very >> helpful and powerful. I think it is a challenge in git because it is >> dealing with text and does not have a notion of what a class is etc. If we >> continue and put in more powerful search abilities, it will require using >> different paradigm in representing code so we can do more powerful things >> with the repository. We can browse the class without loading it but that >> gets us only so far. >> >> Just my 0.02 ;-) >> >> >> >> Kind Regards, >> >> Sean Glazier >> >> >> On Mon, Jul 25, 2016 at 1:28 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >>> Hi Juraj, >>> >>> I've finally forced myself to finish a guide on using gitfiletree: >>> https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… >>> so hopefully it will be of some use to you. >>> >>> Couple of notes: >>> * GitFileTree loaded from Catalog still doesn't work in Pharo 6, >>> so use the script Thierry provided >>> * There's some pain associated with some operations (e.g. >>> merging, loading), this will be addressed sooner or later by IceBerg, which >>> is hopefully the future of git in Pharo ( >>> https://github.com/npasserini/iceberg ) >>> >>> Peter >>> >>> On Mon, Jul 25, 2016 at 11:47:24AM -0400, Juraj Kubelka wrote: >>> > Hi Alexandre, >>> > >>> > I will first give a try. I think once the Pharo community moves to >>> GitHub, it will help to all. It could be painful, but SmalltalkHub is also >>> painful and we are loosing other opportunities that GitHub service offers. >>> > >>> > I agree that it could be painful. I am fine using external GIT tools. >>> Even for Java (or other) projects I use external GIT tools. The important >>> is that we can easily deploy projects and people can load it (,e.g., >>> Catalog Browser). >>> > >>> > Cheers, >>> > Juraj >>> > >>> > > On Jul 25, 2016, at 09:14, Alexandre Bergel <alexandre.bergel(a)me.com> >>> wrote: >>> > > >>> > > Hi Juraj, >>> > > >>> > > Although I find very appealing to work with Git, it is still very >>> painful. Some of the issues I feel right now: difficult of merging, >>> checking for source code differences, there is unfortunately a difference >>> between installing using Metacello and cloning a repository, â¦ >>> > > We can discuss it if you want (I am back in Chile). >>> > > >>> > > Alexandre >>> > > >>> > > >>> > >> On Jul 25, 2016, at 8:41 AM, Juraj Kubelka < >>> juraj.kubelka(a)icloud.com> wrote: >>> > >> >>> > >> Hi, >>> > >> >>> > >> can you point me to a latest (best) way to use GitHub for Pharo >>> projects (Pharo 6)? >>> > >> >>> > >> Is the GitFileTree project the way to use it? >>> > >> >>> > >> How does ConfigurationOf change? >>> > >> >>> > >> Thanks! >>> > >> Juraj >>> > > >>> > > -- >>> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> > > Alexandre Bergel http://www.bergel.eu >>> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> > > >>> > > >>> > > >>> > > >>> > >>> > >>> >>> >>

July 26, 2016

Re: [Pharo-users] Pharo and GIT

by Dimitris Chloupis

Github has a search code facility , unless you mean something else. We could take advantage of that and unite it with our ability to browse implementors and classes. There is no limit how deeply we can integrate with git and github and we can extend both via Pharo to make them more Pharo friendly. On the subject of smalltalkhub it was always of question who will maintain it. But is one thing to want something another to take control and responsibility for it. None stoping anyone from contributing to anything. Problem is sthub will need a ton of work to be a good alternative to github. On Tue, 26 Jul 2016 at 01:36, Sean Glazier <sglazier456(a)gmail.com> wrote: > Thank you, Peter for documenting that :-). While I think git tools are OK, > my opinion though is that Smalltalk hub should be moved forward as well. At > cincom the Store experience started out painful and it has its quirks, but > one of the advantages is that I could write tools to do things like browse > senders and implementors in the repository. I git you are working with > files and text and it does not have the notion of classes and methods and > the value of being able to see the history of the class / methods. It is > valuable when needing to understand not just the current implementation but > where it came from. In Store, I could search and see when a method was > present of a class and in what version lets say it got dropped > unintentionally for instance. Even more important I think is to also note > thing like renames and in cincom namespace renames and moves. > I was working a while back on a way to have a persistent diary for a > class that could note these histories and maintained and more importantly > searchable from the image. > I wrote tools too, to attach to a number of databases (repositories) and > search for classes and the comments. Helpful when you are searching to see > if someone else has solved a problem before. Git tools can tell you a lot > about the repository you are publishing to and comparing code etc. But it > does not help you to search across repositories and the data. > > I know this idea is a tall order. If we improved our tools to beable do > this, no matter what the repository is behind it, that would be very > helpful and powerful. I think it is a challenge in git because it is > dealing with text and does not have a notion of what a class is etc. If we > continue and put in more powerful search abilities, it will require using > different paradigm in representing code so we can do more powerful things > with the repository. We can browse the class without loading it but that > gets us only so far. > > Just my 0.02 ;-) > > > > Kind Regards, > > Sean Glazier > > > On Mon, Jul 25, 2016 at 1:28 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> Hi Juraj, >> >> I've finally forced myself to finish a guide on using gitfiletree: >> https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… >> so hopefully it will be of some use to you. >> >> Couple of notes: >> * GitFileTree loaded from Catalog still doesn't work in Pharo 6, >> so use the script Thierry provided >> * There's some pain associated with some operations (e.g. >> merging, loading), this will be addressed sooner or later by IceBerg, which >> is hopefully the future of git in Pharo ( >> https://github.com/npasserini/iceberg ) >> >> Peter >> >> On Mon, Jul 25, 2016 at 11:47:24AM -0400, Juraj Kubelka wrote: >> > Hi Alexandre, >> > >> > I will first give a try. I think once the Pharo community moves to >> GitHub, it will help to all. It could be painful, but SmalltalkHub is also >> painful and we are loosing other opportunities that GitHub service offers. >> > >> > I agree that it could be painful. I am fine using external GIT tools. >> Even for Java (or other) projects I use external GIT tools. The important >> is that we can easily deploy projects and people can load it (,e.g., >> Catalog Browser). >> > >> > Cheers, >> > Juraj >> > >> > > On Jul 25, 2016, at 09:14, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >> > > >> > > Hi Juraj, >> > > >> > > Although I find very appealing to work with Git, it is still very >> painful. Some of the issues I feel right now: difficult of merging, >> checking for source code differences, there is unfortunately a difference >> between installing using Metacello and cloning a repository, â¦ >> > > We can discuss it if you want (I am back in Chile). >> > > >> > > Alexandre >> > > >> > > >> > >> On Jul 25, 2016, at 8:41 AM, Juraj Kubelka <juraj.kubelka(a)icloud.com> >> wrote: >> > >> >> > >> Hi, >> > >> >> > >> can you point me to a latest (best) way to use GitHub for Pharo >> projects (Pharo 6)? >> > >> >> > >> Is the GitFileTree project the way to use it? >> > >> >> > >> How does ConfigurationOf change? >> > >> >> > >> Thanks! >> > >> Juraj >> > > >> > > -- >> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > > Alexandre Bergel http://www.bergel.eu >> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > > >> > > >> > > >> > > >> > >> > >> >> >

July 26, 2016

Re: [Pharo-users] System Browser "Implementors of..." drill down?

by Dimitris Chloupis

Indeed it has , future looks very promising On Tue, 26 Jul 2016 at 14:05, Norbert Fortelny <norbert.fortelny(a)gmail.com> wrote: > > Hi Norbert, > > > > As a newcomer, just curious about your impression of the double-key > > shortcut "Ctrl/Cmd + B + M" shown against the "Implementers of..." > > menu item? > > Do you think you would have discovered yourself using meta+m like > > Henrik describes if that was what was shown as the menu item shortcut > > instead? > > > > cheers -ben > > > No, I wouldn't have, or rather maybe, if I had tried hard enough. > As it is in 5.0 this is clear and easy. Being on a Mac it even shows me > the â correctly, great! > Pharo has come a long way. > > ------------------------------ > View this message in context: Re: System Browser "Implementors of..." > drill down? > <http://forum.world.st/System-Browser-Implementors-of-drill-down-tp4907380p4…> > Sent from the Pharo Smalltalk Users mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com. >

July 26, 2016