Hi,
On request of the mailing list owner, the following lists (but not their
archives) have been removed:
cl-interpol-devel
rdnzl-announce
rdnzl-devel
regex-coach
fm-lisp
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hello everyone, long time no talk!
I hope everyone has been well. I've had... a hectic time of it but I'm settling down finally.
I should apologize for how MIA and hard-to-reach I have been.
Hopefully now that things are more stable in my personal life, I can give more time to CL and other projects.
As a start, I've written a basic design update for Common-Lisp.net. You can view and comment on the code for it here: https://gitlab.common-lisp.net/clo/site/merge_requests/1
This features actual mobile responsiveness (yes, the last design had an embarrassing mistake, I know!) and removes the mtime dependency that was preventing us from upgrading Ruby on CLnet's servers. I think we're still on a very old Ruby version, hopefully this will allow us to upgrade it, or at least remove one more barrier.
Please take your time to review it at your leisure; I know I'm sort of surprising everyone with this.
I've attached a few screenshots so you can see what it looks like at a glance.
Thank you,
- C. Yang
Hi,
Sorry, yes, wrong list!
Thanks for the pointers! Ik use them while mailing the right list.
Regards,
Erik
On Mar 5, 2018 22:22, "Daniel Herring" <dherring(a)tentpost.com> wrote:
Hi Erik,
Did this get sent to the wrong list?
Anyway, I would recommend mimicking Qt's approach to translation. If
possible, re-use their file formats. Then you can use their toolchain for
maintaining translations.
http://doc.qt.io/qt-5/linguist-overview.html
- Daniel
On Mon, 5 Mar 2018, Erik Huelsmann wrote:
Hi,
>
> In our translation catelog, we have the word "To". There are multiple uses
> for this word, which is marked for translation for all uses.
>
> One use is the case of a date range ("From ... To ...."). Another use is
> the case of an address ("To: <address on the next line(s)>".
>
> When translating these to Dutch, these use cases have very different
> translations (Date range: "Tot"; address: "Aan").
>
> It seems we need some context specific translations. However, our
> translation library (which isn't gettext), doesn't cater for them.
>
> Any ideas as to how to approach this problem?
>
> How will we know which domains we need to distinguish?
>
>
>
> --
> Bye,
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
>
Hi,
In our translation catelog, we have the word "To". There are multiple uses
for this word, which is marked for translation for all uses.
One use is the case of a date range ("From ... To ...."). Another use is
the case of an address ("To: <address on the next line(s)>".
When translating these to Dutch, these use cases have very different
translations (Date range: "Tot"; address: "Aan").
It seems we need some context specific translations. However, our
translation library (which isn't gettext), doesn't cater for them.
Any ideas as to how to approach this problem?
How will we know which domains we need to distinguish?
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
There are 107 darcs repositories remaining on common-lisp.net which have
not been converted to Git yet.
I'm looking at what to do with those. These 107 seem to fall into the
following categories:
1. darcs-managed web pages (i.e.: /srv/project/*/public_html/_darcs)
2. project-published repositories (i.e.:
/srv/project/*/public_html/<repository-name>/_darcs) which were not
registered with darcsweb.
The first category I'm thinking of converting to Git, importing in Gitlab
as a 'public_html' project in the associated project group. Then, convert
the project's public_html folder from Darcs repository to Git repository by
replacing the _darcs directory with a .git directory.
The second category I'm thinking of converting to git using the same
procedure as the ones that just moved to GitLab (the published Darcsweb
list).
Comments?
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
As announced before, the darcs repositories listed at
https://common-lisp.net/cgi-bin/darcsweb.cgi will be migrated to
Git+GitLab. At the same time, darcs "support" will be deprecated on
Common-Lisp.net and the darcsweb URL above will be replaced by a rewrite
rule redirecting to GitLab.
Preparations have progressed well enough to be able to announce migration
to take place coming Saturday (Feb 17). common-lisp.net operations will be
available during migration.
Kind regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi all,
The current list of repositories to migrate from darcs to GitLab, is the
list shown on https://common-lisp.net/cgi-bin/darcsweb.cgi .
Are there any other repositories that need to be migrated to GitLab that
this community is aware of?
Thanks!
Regards,
Erik.
On Wed, Jan 31, 2018 at 9:21 AM, Erik Huelsmann <ehuels(a)gmail.com> wrote:
> Hi,
>
> While running the first conversion tests, I ran into the following
> repositories (browsable through https://common-lisp.net/cgi-
> bin/darcsweb.cgi) already have GitLab repositories in place
> (<project>/<repository>):
>
> * adw-charting/adw-charting
> * alexandria/alexandria
> * bordeaux-threads/bordeau-threads
> * cl-store/cl-store
> * editor-hints/named-readtables
> * elephant/elephant
> * gestalt/gestalt
> * mel-base/mel-base
> * parenscript/parenscript
>
>
> Given the age of all of these repositories, I'm planning to archive these
> duplicated repositories and not migrate them to GitLab (as that would mean
> the repositories would be either duplicating other repositories or prior
> repositories would be overwritten).
>
>
> Any comments regarding this plan? Maybe someone knows that some of these
> repositories need to be migrated to GitLab - replacing what's currently
> there?
>
>
> Regards,
>
>
> Erik.
>
>
> On Sat, Jan 27, 2018 at 11:56 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote:
>
>> Hi all,
>>
>> After converting common-lisp.net to LetsEncrypt/certbot, I've taken a
>> bit of time to research the long-overdue move from darcs to Git.
>>
>> Fortunately, taking time away from a task allows for creativity to kick
>> in: I've found an (acceptable to me) way to bulk convert all repositories
>> listed in https://common-lisp.net/cgi-bin/darcsweb.cgi
>>
>> I'm likely to implement a minimal redirect from the existing darcsweb
>> URLs to the resulting GitLab git projects. However, since the commit SHAs
>> don't match, anything more complex requires pretty extensive mapping
>> tables. Please consider this as an invitation to do that work! :-)
>>
>>
>> Final announcement of a cut-over will be done 1 week in advance of the
>> cut-over itself. Cut-over will roughly take 4 hours when the window is
>> there (although I can't imagine anybody actually *using* these repositories
>> other than as read-only sources).
>>
>> --
>> Bye,
>>
>> Erik.
>>
>> http://efficito.com -- Hosted accounting and ERP.
>> Robust and Flexible. No vendor lock-in.
>>
>
>
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi all,
After I complete the migration of all repositories listed in darcsweb
(excluding the ones below), I'll be installing a rewrite rule on the
darcsweb, redirecting to GitLab.
At that time, I'm planning to remove both Darcs and Darcsweb support from
common-lisp.net, unless there are objections from the community, of course.
Regards,
Erik.
On Wed, Jan 31, 2018 at 9:21 AM, Erik Huelsmann <ehuels(a)gmail.com> wrote:
> Hi,
>
> While running the first conversion tests, I ran into the following
> repositories (browsable through https://common-lisp.net/cgi-
> bin/darcsweb.cgi) already have GitLab repositories in place
> (<project>/<repository>):
>
> * adw-charting/adw-charting
> * alexandria/alexandria
> * bordeaux-threads/bordeau-threads
> * cl-store/cl-store
> * editor-hints/named-readtables
> * elephant/elephant
> * gestalt/gestalt
> * mel-base/mel-base
> * parenscript/parenscript
>
>
> Given the age of all of these repositories, I'm planning to archive these
> duplicated repositories and not migrate them to GitLab (as that would mean
> the repositories would be either duplicating other repositories or prior
> repositories would be overwritten).
>
>
> Any comments regarding this plan? Maybe someone knows that some of these
> repositories need to be migrated to GitLab - replacing what's currently
> there?
>
>
> Regards,
>
>
> Erik.
>
>
> On Sat, Jan 27, 2018 at 11:56 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote:
>
>> Hi all,
>>
>> After converting common-lisp.net to LetsEncrypt/certbot, I've taken a
>> bit of time to research the long-overdue move from darcs to Git.
>>
>> Fortunately, taking time away from a task allows for creativity to kick
>> in: I've found an (acceptable to me) way to bulk convert all repositories
>> listed in https://common-lisp.net/cgi-bin/darcsweb.cgi
>>
>> I'm likely to implement a minimal redirect from the existing darcsweb
>> URLs to the resulting GitLab git projects. However, since the commit SHAs
>> don't match, anything more complex requires pretty extensive mapping
>> tables. Please consider this as an invitation to do that work! :-)
>>
>>
>> Final announcement of a cut-over will be done 1 week in advance of the
>> cut-over itself. Cut-over will roughly take 4 hours when the window is
>> there (although I can't imagine anybody actually *using* these repositories
>> other than as read-only sources).
>>
>> --
>> Bye,
>>
>> Erik.
>>
>> http://efficito.com -- Hosted accounting and ERP.
>> Robust and Flexible. No vendor lock-in.
>>
>
>
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
While running the first conversion tests, I ran into the following
repositories (browsable through https://common-lisp.net/cgi-bin/darcsweb.cgi)
already have GitLab repositories in place (<project>/<repository>):
* adw-charting/adw-charting
* alexandria/alexandria
* bordeaux-threads/bordeau-threads
* cl-store/cl-store
* editor-hints/named-readtables
* elephant/elephant
* gestalt/gestalt
* mel-base/mel-base
* parenscript/parenscript
Given the age of all of these repositories, I'm planning to archive these
duplicated repositories and not migrate them to GitLab (as that would mean
the repositories would be either duplicating other repositories or prior
repositories would be overwritten).
Any comments regarding this plan? Maybe someone knows that some of these
repositories need to be migrated to GitLab - replacing what's currently
there?
Regards,
Erik.
On Sat, Jan 27, 2018 at 11:56 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote:
> Hi all,
>
> After converting common-lisp.net to LetsEncrypt/certbot, I've taken a bit
> of time to research the long-overdue move from darcs to Git.
>
> Fortunately, taking time away from a task allows for creativity to kick
> in: I've found an (acceptable to me) way to bulk convert all repositories
> listed in https://common-lisp.net/cgi-bin/darcsweb.cgi
>
> I'm likely to implement a minimal redirect from the existing darcsweb URLs
> to the resulting GitLab git projects. However, since the commit SHAs don't
> match, anything more complex requires pretty extensive mapping tables.
> Please consider this as an invitation to do that work! :-)
>
>
> Final announcement of a cut-over will be done 1 week in advance of the
> cut-over itself. Cut-over will roughly take 4 hours when the window is
> there (although I can't imagine anybody actually *using* these repositories
> other than as read-only sources).
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.