Hi Andrew,


Thanks for the pointer!

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.

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 common-lisp.net so everybody can enjoy integration with their favorate Common Lisp environment.


Regards,


Erik.




On Sun, Feb 15, 2015 at 6:54 AM, Andrew Kirkpatrick <ubermonk@gmail.com> wrote:
Hi Erik,

I just noticed this elisp gitlab library the other day. Perhaps it
will be helpful in producing cl-gitlab, though it doesn't seem to have
any wiki support:

https://github.com/nlamirault/emacs-gitlab

Cheers,
Andy


On 15 February 2015 at 02:02, Erik Huelsmann <ehuels@gmail.com> wrote:
>
>>
>> These plans seem awfully ambitious, but I look forward to them.
>
>
> Ok. Well, we'll take it one step at a time; it's my expectation that each
> step by itself is manageable.
>
>> Depending on the difficulty, I think I would rather just migrate all
>> of my Trac stuff to gitlab instead of trying to make Trac work with
>> gitlab in some fashion.  (Unless gitlab and Trac already have some
>> kind of integration.)
>
>
> Well, if you're up to writing CL code to do the migration, I think it's
> doable:
>
> ** Wiki
>  - Raw documents can be dowloaded from Trac, so if you have a list of pages
> to download, you can simply run those through cURL/wget.
>    (URL format:
> https://trac.common-lisp.net/cmucl/wiki/GitAndCmucl?format=txt)
>  - it looks like [http://johnmacfarlane.net/pandoc/ PanDoc] is your way to
> go for the conversion of the wiki format
>  - I'm working on a cl-gitlab library which can be used to connect to the
> gitlab API and upload wiki documents
>
> Hmm. come to think of it, you probably want to migrate the wiki into a local
> repository and push them to the server as described here:
> https://gitlab.com/gitlab-org/omnibus-gitlab/wikis/git_access
>
> ** Tickets
>  - Tickets can be downloaded in one big XML document (URL:
> https://trac.common-lisp.net/cmucl/login?referer=%2Fcmucl%2Freport%2F11%3Fasc%3D1%26format%3Drss)
>  - After extracting the above URL, cl-gitlab can be used to create the
> milestones used in the extract
>  - cl-gitlab can be used to (re)create the tickets from trac, where I
> suggest to move these fields to the body text
>  - Not all fields available on Trac are available in the GitLab tracker; i'd
> propose adding them to the ticket's body; specifically: Reporter and Version
>  - Fields "Priority" and "Component" can be transformed into Labels (a kind
> of "tags")
>  - Successive comments should be uploaded as comments/notes; this can be
> done using cl-gitlab as well.
>
> Note that both the wiki and the tickets can use Wiki markup in Trac as well
> as GitLab, so every text body (comment, wiki page or ticket) probably needs
> to be run through pandoc.
>
> If there are more projects that want/need such conversion, we'd probably
> best try to share any efforts automating the process.
>
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
> _______________________________________________
> Clo-devel mailing list
> Clo-devel@common-lisp.net
> https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/clo-devel
>



--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.