<div dir="ltr">Hi Andrew,<div><br></div><div><br></div><div>Thanks for the pointer!</div><div><br></div><div>I've taken a bit of a different approach, I think, by enumerating explicitly which elements exist in every object and making those elements accessible through slots with lispy names. Admittedly, I haven't written a (nearly) complete API mapping yet, but with my approach, SLIME's auto-complete function should work. There's also a value<->mnemonic mapping for API values which should be marshalled as numbers but have nice constants defined on the receiving (Ruby) side. There's a value<->keyword mapping on the Common Lisp side.</div><div><br></div><div>When I feel sufficiently confident in the library -- such as that I'm able to do the things I want to do for this migration -- I'll publish the library in a project on <a href="http://common-lisp.net">common-lisp.net</a> so everybody can enjoy integration with their favorate Common Lisp environment.</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div><br></div><div>Erik.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 15, 2015 at 6:54 AM, Andrew Kirkpatrick <span dir="ltr"><<a href="mailto:ubermonk@gmail.com" target="_blank">ubermonk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Erik,<br>
<br>
I just noticed this elisp gitlab library the other day. Perhaps it<br>
will be helpful in producing cl-gitlab, though it doesn't seem to have<br>
any wiki support:<br>
<br>
<a href="https://github.com/nlamirault/emacs-gitlab" target="_blank">https://github.com/nlamirault/emacs-gitlab</a><br>
<br>
Cheers,<br>
Andy<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 15 February 2015 at 02:02, Erik Huelsmann <<a href="mailto:ehuels@gmail.com">ehuels@gmail.com</a>> wrote:<br>
><br>
>><br>
>> These plans seem awfully ambitious, but I look forward to them.<br>
><br>
><br>
> Ok. Well, we'll take it one step at a time; it's my expectation that each<br>
> step by itself is manageable.<br>
><br>
>> Depending on the difficulty, I think I would rather just migrate all<br>
>> of my Trac stuff to gitlab instead of trying to make Trac work with<br>
>> gitlab in some fashion.  (Unless gitlab and Trac already have some<br>
>> kind of integration.)<br>
><br>
><br>
> Well, if you're up to writing CL code to do the migration, I think it's<br>
> doable:<br>
><br>
> ** Wiki<br>
>  - Raw documents can be dowloaded from Trac, so if you have a list of pages<br>
> to download, you can simply run those through cURL/wget.<br>
>    (URL format:<br>
> <a href="https://trac.common-lisp.net/cmucl/wiki/GitAndCmucl?format=txt" target="_blank">https://trac.common-lisp.net/cmucl/wiki/GitAndCmucl?format=txt</a>)<br>
>  - it looks like [<a href="http://johnmacfarlane.net/pandoc/" target="_blank">http://johnmacfarlane.net/pandoc/</a> PanDoc] is your way to<br>
> go for the conversion of the wiki format<br>
>  - I'm working on a cl-gitlab library which can be used to connect to the<br>
> gitlab API and upload wiki documents<br>
><br>
> Hmm. come to think of it, you probably want to migrate the wiki into a local<br>
> repository and push them to the server as described here:<br>
> <a href="https://gitlab.com/gitlab-org/omnibus-gitlab/wikis/git_access" target="_blank">https://gitlab.com/gitlab-org/omnibus-gitlab/wikis/git_access</a><br>
><br>
> ** Tickets<br>
>  - Tickets can be downloaded in one big XML document (URL:<br>
> <a href="https://trac.common-lisp.net/cmucl/login?referer=%2Fcmucl%2Freport%2F11%3Fasc%3D1%26format%3Drss" target="_blank">https://trac.common-lisp.net/cmucl/login?referer=%2Fcmucl%2Freport%2F11%3Fasc%3D1%26format%3Drss</a>)<br>
>  - After extracting the above URL, cl-gitlab can be used to create the<br>
> milestones used in the extract<br>
>  - cl-gitlab can be used to (re)create the tickets from trac, where I<br>
> suggest to move these fields to the body text<br>
>  - Not all fields available on Trac are available in the GitLab tracker; i'd<br>
> propose adding them to the ticket's body; specifically: Reporter and Version<br>
>  - Fields "Priority" and "Component" can be transformed into Labels (a kind<br>
> of "tags")<br>
>  - Successive comments should be uploaded as comments/notes; this can be<br>
> done using cl-gitlab as well.<br>
><br>
> Note that both the wiki and the tickets can use Wiki markup in Trac as well<br>
> as GitLab, so every text body (comment, wiki page or ticket) probably needs<br>
> to be run through pandoc.<br>
><br>
> If there are more projects that want/need such conversion, we'd probably<br>
> best try to share any efforts automating the process.<br>
><br>
><br>
> --<br>
> Bye,<br>
><br>
> Erik.<br>
><br>
> <a href="http://efficito.com" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.<br>
> Robust and Flexible. No vendor lock-in.<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Clo-devel mailing list<br>
> <a href="mailto:Clo-devel@common-lisp.net">Clo-devel@common-lisp.net</a><br>
> <a href="https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/clo-devel" target="_blank">https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/clo-devel</a><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div>
</div>