[Clo-devel] Follow up to "proposed direction for common-lisp.net in 2015" -- the steps
ehuels at gmail.com
Mon Feb 16 22:08:44 UTC 2015
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.
On Sun, Feb 15, 2015 at 6:54 AM, Andrew Kirkpatrick <ubermonk at gmail.com>
> 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:
> On 15 February 2015 at 02:02, Erik Huelsmann <ehuels at 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
> > 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
> > 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
> > 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:
> > - 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;
> > propose adding them to the ticket's body; specifically: Reporter and
> > - Fields "Priority" and "Component" can be transformed into Labels (a
> > 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
> > as GitLab, so every text body (comment, wiki page or ticket) probably
> > 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 at common-lisp.net
> > https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/clo-devel
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the clo-devel