Proof of Concept: FileTree and Fossil
Locked
Proof of Concept: FileTree and Fossil
 
|
Hi all,
I have written a simple integration of FileTree with Fossil to avoid the 2-step Pharo- and shell-level work to add/delete/commit files. At the operating system command prompt, init a new Fossil project: os% mkdir ~/repo os% cd ~/repo os% fossil init myproject.fossil project-id: 3c05c3016eeabf8e87816ee218c6a86d3c87b950 server-id: ff42bc86dba1a26b1d94b64685f7c09d02581617 admin-user: laptop-user (initial password is "1fe2ff") Open the repository: os% mkdir ~/myproject os% cd ~/myproject os% fossil open ~/repo/myproject.fossil In a fresh Pharo 6 image - I used v60411 - install FossilFileTree: Metacello new baseline: 'FossilFileTree'; repository: 'github://PierceNg/FossilFileTree'; load. Write code in Pharo. Open Monticello Browser. Add a "fossilfiletree" repository, using ~/myproject as the directory. Save to said repository from within Monticello Browser. Done. Full blog post here: http://www.samadhiweb.com/blog/2017.02.28.fossil.filetree.html Pierce |
Re: Proof of Concept: FileTree and Fossil
|
|
This is cool.
I'm curious to see if we could manage fossil back-end via iceberg. Stef On Tue, 28 Feb 2017 01:19:50 +0100, Pierce Ng <[hidden email]> wrote: > Hi all, > I have written a simple integration of FileTree with Fossil to avoid the > 2-step > Pharo- and shell-level work to add/delete/commit files. > At the operating system command prompt, init a new Fossil project: > os% mkdir ~/repo > os% cd ~/repo > os% fossil init myproject.fossil > project-id: 3c05c3016eeabf8e87816ee218c6a86d3c87b950 > server-id: ff42bc86dba1a26b1d94b64685f7c09d02581617 > admin-user: laptop-user (initial password is "1fe2ff") > Open the repository: > os% mkdir ~/myproject > os% cd ~/myproject > os% fossil open ~/repo/myproject.fossil > In a fresh Pharo 6 image - I used v60411 - install FossilFileTree: > Metacello new > baseline: 'FossilFileTree'; > repository: 'github://PierceNg/FossilFileTree'; > load. > Write code in Pharo. Open Monticello Browser. Add a "fossilfiletree" > repository, using ~/myproject as the directory. Save to said repository > from within Monticello Browser. Done. > Full blog post here: > http://www.samadhiweb.com/blog/2017.02.28.fossil.filetree.html > Pierce -- Using Opera's mail client: http://www.opera.com/mail/ |
Re: Proof of Concept: FileTree and Fossil
|
|
I'm also curious about iceberg integration. I'm also an advocate for
fossil: I like its lightness as process and software, offering full stack distributed collaboration in just 2 Mb (wiki, tickets, DVCS, etc.) I can not catch up with upcoming Pharo 6, but hopefully after being released I will be able to test fossil stuff, particularly because is the chosen collaboration backend for Grafoscopio. BTW, when installing Grafoscopio you get a FossilRepo object that is used to query Fossil repositories via the JSON API and update documentation. Still in early stages, but I will experiment how Pierce's Fossil support give a more cohesive user experience when working with publication and collaboration of interactive notebooks. Cheers, Offray On 28/02/17 02:12, stepharong wrote: > This is cool. > I'm curious to see if we could manage fossil back-end via iceberg. > > Stef > > > On Tue, 28 Feb 2017 01:19:50 +0100, Pierce Ng <[hidden email]> > wrote: > >> Hi all, >> I have written a simple integration of FileTree with Fossil to avoid >> the 2-step >> Pharo- and shell-level work to add/delete/commit files. >> At the operating system command prompt, init a new Fossil project: >> os% mkdir ~/repo >> os% cd ~/repo >> os% fossil init myproject.fossil >> project-id: 3c05c3016eeabf8e87816ee218c6a86d3c87b950 >> server-id: ff42bc86dba1a26b1d94b64685f7c09d02581617 >> admin-user: laptop-user (initial password is "1fe2ff") >> Open the repository: >> os% mkdir ~/myproject >> os% cd ~/myproject >> os% fossil open ~/repo/myproject.fossil >> In a fresh Pharo 6 image - I used v60411 - install FossilFileTree: >> Metacello new >> baseline: 'FossilFileTree'; >> repository: 'github://PierceNg/FossilFileTree'; >> load. >> Write code in Pharo. Open Monticello Browser. Add a "fossilfiletree" >> repository, using ~/myproject as the directory. Save to said repository >> from within Monticello Browser. Done. >> Full blog post here: >> http://www.samadhiweb.com/blog/2017.02.28.fossil.filetree.html >> Pierce > > |
Re: Proof of Concept: FileTree and Fossil
|
|
In reply to this post by Pierce Ng-3
2017-02-28 1:19 GMT+01:00 Pierce Ng <[hidden email]>: Hi all, Congratulations! This was one of my objectives with GitFileTree: open up the Pharo infrastructure to other DVCS such as Fossil. How does Fossil handles merging the FileTree format? Regards, Thierry |
Re: Proof of Concept: FileTree and Fossil
|
|
In reply to this post by stepharong
2017-02-28 8:12 GMT+01:00 stepharong <[hidden email]>: This is cool. It is a nice use case to check on an architecture for Iceberg with multiple back-ends. Thierry
|
Re: Proof of Concept: FileTree and Fossil
|
|
In reply to this post by Offray Vladimir Luna Cárdenas-2
Hi Offray,
is your FossilRepo object using a JSON over HTTP API to Fossil? It could make Fossil an interesting candidate, because it could mean a single http API (and not one API per git hosting provider...) Regards, Thierry 2017-02-28 16:09 GMT+01:00 Offray Vladimir Luna Cárdenas <[hidden email]>: I'm also curious about iceberg integration. I'm also an advocate for fossil: I like its lightness as process and software, offering full stack distributed collaboration in just 2 Mb (wiki, tickets, DVCS, etc.) I can not catch up with upcoming Pharo 6, but hopefully after being released I will be able to test fossil stuff, particularly because is the chosen collaboration backend for Grafoscopio. |
Re: Proof of Concept: FileTree and Fossil
|
|
Hi Thierry, What I'm using is the Fossil JSON API as described in [1].
Managing Grafoscopio documentation with it is pretty easy and yes
I believe it could help in bringing a unified API across several
repositories (I have not tested that though). Cheers, Offray On 28/02/17 10:26, Thierry Goubier
wrote:
|
Re: Proof of Concept: FileTree and Fossil
|
|
2017-02-28 16:43 GMT+01:00 Offray Vladimir Luna Cárdenas <[hidden email]>:
You probably intended [2], isn't it? I wasn't thinking much about multiple repos, but it could be one target. I was just thinking that there was/is one attempt to have a close integration to github API over HTTP in Pharo, and that this effort would have to b partially redone for, say GitLab, or Bitbucket because git does not defines a HTTP API and every hosting company creates one, whereas in Fossil everybody uses the JSON API. Regards, Thierry
|
Re: Proof of Concept: FileTree and Fossil
|
|
On 28/02/17 10:56, Thierry Goubier
wrote:
Yep, I meant that one. :-)
Ohh I understand now. Well is useful in both scenarios, and a showcase of the power of simplicity and being late in the game :-). Cheers, Offray |
Socket, network, testing and coding
|
|
In reply to this post by Thierry Goubier
Hi guys, Quick question regarding sockets and testing. I'm trying to implement a simple communication protocol to exchange data (strings) between 2 images and I was wondering what was the easiest way to test/develop my code? I want to be able to do something similar to a chat client between 2 images where none of those 2 images acts as a server. So data can originate from any of those 2 images and both images have to "listen" to each other. Besides, both images would have to transmit/receive on the same port. 1) Is this possible (the way I want to do/test it)? 2) How do I simulate something like this on a *single* machine running those 2 images? 3) Do I need to have one of those 2 images act as a "server" ? 4) Any helpful tip and/or interesting link to propose? 5) Can you think of any simple code or example I could look at to understand what I need to do? ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein) |
Re: Proof of Concept: FileTree and Fossil
|
|
In reply to this post by Offray Vladimir Luna Cárdenas-2
it means that we could also use the same setup to store pillar books
-- Using Opera's mail client: http://www.opera.com/mail/ |
Re: Socket, network, testing and coding
|
|
In reply to this post by Pharo Smalltalk Users mailing list
Hi,
Yes, you can test it.
Something like this: | listener clientSocket serverSocket | listener := Socket newTCP. [ listener listenOn: 0 backlogSize: 4. clientSocket := Socket newTCP. clientSocket connectTo: #[127 0 0 1] port: listener localPort. clientSocket waitForConnectionFor: 1. serverSocket := listener waitForAcceptFor: 1. ] ensure: [ listener destroy ]. since then you have client and server socket. You can call it clientOne, clientTwo.
At least one image has to serve as a server (listen to connections). Maybe you could use a discovery service protocol. I do not have any experience about it.
There is a Trantor project where you could learn from: http://smalltalkhub.com/#!/~EvanDonahue/Trantor You can check an example here: TRNLog exampleOpenChatWithUserIdUsingTrantor But you are going to be more interested in testing: TrantorNodeTest Download it using: Gofer it smalltalkhubUser: 'EvanDonahue' project: 'Trantor'; configuration; loadBleedingEdge. And maybe Zinc (part of the Pharo image) has also good test examples. Cheers, Juraj
|
Re: Socket, network, testing and coding
|
|
In reply to this post by Pharo Smalltalk Users mailing list
Hi,
Depending on what exactly you are doing, you could either use or look at the source of: http://smalltalkhub.com/#!/~EvanDonahue/P2P It is basically a simple API for setting up image-to-image networked communication. You make a server object, set it running, and then open a connection from a client image. The threading etc is all handled. A simple chat system only takes a couple lines, and there is a well commented example of a simple multi (3+) person chat server in the examples package. Yes, one image does need to be the "server," but it only matters for setting up the initial connection. After that, they are essentially peer to peer, and either party can send to the other. I would imagine that this still fits your requirements, unless you have a very special use case like UDP hole punching, which I ultimately plan to implement one day when I return to this project. But the current form is very stable and complete. Let me know if you have any questions. Cheers, Evan |
Re: Proof of Concept: FileTree and Fossil
|
|
In reply to this post by Thierry Goubier
On Tue, Feb 28, 2017 at 04:23:12PM +0100, Thierry Goubier wrote:
> 2017-02-28 1:19 GMT+01:00 Pierce Ng <[hidden email]>: > > I have written a simple integration of FileTree with Fossil to avoid the > Congratulations! This was one of my objectives with GitFileTree: open up > the Pharo infrastructure to other DVCS such as Fossil. And indeed runOSSubprocessFossilCommand is basically runOSSubprocessGitCommand, so thank you for GitFileTree. I've only implemented #basicStoreVersion: and it is simply this: basicStoreVersion: aVersion super basicStoreVersion: aVersion (MCFossil new repoDir: self directory fullName) addRemove; commit: aVersion info message The last 3 lines is of course just the Smalltalk way of saying "fossil addremove; fossil commit ..." Currently that's all it does. > How does Fossil handles merging the FileTree format? Just to be sure I get your question, do you mean whether FossilFileTree sees the changes if I edit the .st files using vi, say? Right now, after committing in Monticello Browser, when I click 'refresh' or 'changes' everything shows up as new again. That can't be right. Which part of GitFileTree deals that? Pierce |
Re: Proof of Concept: FileTree and Fossil
|
|
In reply to this post by Offray Vladimir Luna Cárdenas-2
On Tue, Feb 28, 2017 at 10:09:06AM -0500, Offray Vladimir Luna Cárdenas wrote:
> BTW, when installing Grafoscopio you get a FossilRepo object that is > used to query Fossil repositories via the JSON API and update > documentation. Still in early stages, but I will experiment how > Pierce's Fossil support give a more cohesive user experience when > working with publication and collaboration of interactive notebooks. Currently FossilFileTree runs Fossil "at the command line". But certainly talking JSON with a Fossil server is another avenue to explore, similar to having gitfiletree:// and remote git repository. Pierce |
Re: Proof of Concept: FileTree and Fossil
|
|
In reply to this post by Pierce Ng-3
2017-03-01 13:15 GMT+01:00 Pierce Ng <[hidden email]>: On Tue, Feb 28, 2017 at 04:23:12PM +0100, Thierry Goubier wrote: Great!
No, it is a bit more in depth. FileTree, by default, will save some metadata with the packages (method timestamps, package version history) and this, with git, creates conflicts when merging (and cherry picking and a few other operations). GitFileTree introduced a variant of the format, called metadata-less, to avoid that and recover the metadata from the git history itself (and convert it to Monticello).
The all new again is the default FileTree approach. In GitFileTree, it recovers all the versions with git log and rebuild them for the repository browser. It is done starting with MCFileTreeRepository>>#gitVersionsForPackage:, then MCFileTreeGitRepository>>#getVersionsForPackageDirectoryName:, tied with a specific class to register the data for all entries (GitFileTreePackageEntry -> other repositories uses only strings to track all the versions). In there you also see the bridge which converts from git log metatadata to Monticello metadata (MCVersion and ancestry). Side question then: is Iceberg factoring out some of that out of GitFileTree, since it supports/supported the libgit and GitFileTree backends? Factoring out could also be of benefit to Fossil. Regards, Thierry
|
Re: Socket, network, testing and coding
|
|
In reply to this post by Pharo Smalltalk Users mailing list
Hi. Look also on these projects (in order from low level to high): 2017-02-28 18:27 GMT+01:00 Benoit St-Jean via Pharo-users <[hidden email]>:
|
Re: Socket, network, testing and coding
|
|
In reply to this post by Evan Donahue
2017-03-01 5:09 GMT+01:00 Evan Donahue <[hidden email]>:
I look at P2P code. It is very close to my Basys framework. If you interesting to compare look at doc https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastBuild/artifact/book-result/BasysNetwork/BasysNetwork.pdf. One difference for example is that basys peers maintain connection pools on each network side. |
Re: Socket, network, testing and coding
|
|
In reply to this post by Juraj Kubelka
2017-03-01 4:39 GMT+01:00 Juraj Kubelka <[hidden email]>:
Finally I look at Trantor too (I read about it in past) So I see that kind of remote Smalltalk was implemented there but with special idea on Replicated Datatypes which I not understand from code. But I am sure if it would be implemented on top of Seamless many things will be simplified a lot and we will have very nice network stack: TCPServer -> BasysNetwork -> SeamlessNetwork -> "Replicated object network". Look at Basys and Seamless docs if you are interesting in such solution |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |