Issue Tracker 开源软件 Trac 在 Ububtu 18 上的安装

$ sudo apt install libmariadbclient-dev python-pymysql
$ sudo pip install trac mysql-python
创建 MySQL 数据库:
MariaDB [(none)]> create database trac_k12 default charset utf8mb4 default collate utf8mb4_bin;
当然接下来是 grant all on … ; flush privileges;
建立项目目录: $ mkdir /opt/trac/k12 (当然你可以任意指定自己想运行的目录)
$ /usr/local/bin/trac-admin /opt/trac/k12 initenv
输入项目名称
输入 MySQL String: mysql://mysql_username:mysql_pass@localhost:3306/trac_k12
成功后就可以看到如下截图了:

添加管理员:
trac-admin /opt/trac/k12 permission add admin TRAC_ADMIN

先看下 nginx 的一个配置,我们姑且写为 /etc/nginx/conf.d/trac.conf
这个 chrome 是干么用的? 不解? 然后 后面整个的是一堆 404

1 server {
2 listen 80;
3 server_name trac.local;
4 access_log /var/log/nginx/trac.log;
5 error_log /var/log/nginx/trac.err;

 6    location ~ /chrome/(.*) {
 7               alias /opt/trac/k12/htdocs/$1;
 8    }

 9    location ~ / {
10              auth_basic "trac realm";
11              auth_basic_user_file /opt/trac/.trac.pass;

12              # socket address
13              fastcgi_pass   unix:/opt/trac/run/k12.sock;

14              # python - wsgi specific
15              # fastcgi_param HTTPS on;

16              ## WSGI REQUIRED VARIABLES
17              # WSGI application name - trac instance prefix.
18              # (Or ``fastcgi_param  SCRIPT_NAME  /some/prefix``.)
19              fastcgi_param  SCRIPT_NAME        "";
20              fastcgi_param  PATH_INFO          $1;

21              ## WSGI NEEDED VARIABLES - trac warns about them
22              fastcgi_param  REQUEST_METHOD     $request_method;
23              fastcgi_param  SERVER_NAME        $server_name;
24              fastcgi_param  SERVER_PORT        $server_port;
25              fastcgi_param  SERVER_PROTOCOL    $server_protocol;
26              fastcgi_param  QUERY_STRING       $query_string;

27              # For Nginx authentication to work - do not forget to comment these
28              # lines if not using Nginx for authentication
29              fastcgi_param  AUTH_USER          $remote_user;
30              fastcgi_param  REMOTE_USER        $remote_user;

31              # for ip to work
32              fastcgi_param REMOTE_ADDR         $remote_addr;

33              # For attchments to work
34              fastcgi_param    CONTENT_TYPE     $content_type;
35              fastcgi_param    CONTENT_LENGTH   $content_length;
36          }
37  }
$ nl /usr/local/lib/python2.7/dist-packages/trac.py

    1  #!/usr/bin/env python
     2  import os
     3  sockaddr = '/opt/trac/run/k12.sock'
     4  os.environ['TRAC_ENV'] = '/opt/trac/k12'

     5  try:
     6       from trac.web.main import dispatch_request
     7       import trac.web._fcgi

     8       fcgiserv = trac.web._fcgi.WSGIServer(dispatch_request,
     9            bindAddress = sockaddr, umask = 7)
    10       fcgiserv.run()

    11  except SystemExit:
    12      raise
    13  except Exception, e:
    14      print 'Content-Type: text/plain\r\n\r\n',
    15      print 'Oops...'
    16      print
    17      print 'Trac detected an internal error:'
    18      print
    19      print e
    20      print
    21      import traceback
    22      import StringIO
    23      tb = StringIO.StringIO()
    24      traceback.print_exc(file=tb)
    25      print tb.getvalue()

然后我们用普通用户手工运行这个 trac.py ,然后重启 Nginx , 就可以通过浏览器 http://trac.local 进入 Trac 了。

下一代编程工具展望

https://www.oreilly.com/ideas/toward-the-next-generation-of-programming-tools
尝试在微信小程序上看下,展示效果。

In a Quora post, Alan Kay lamented the state of tooling for programmers. Every other engineering discipline has built modern computational tools: for computer aided design, simulation and testing, and for manufacturing. But programming hasn’t progressed significantly since the 1970s. We’ve built great tools for others, but not ourselves. The shoemaker’s children have holes in their shoes.

Kay isn’t being entirely fair, but before looking at what he’s missing, it’s important to think about how he’s right. If we don’t understand how he’s right, we certainly won’t understand what to build next, and where the future may be staring us in the face.

Let’s start with programming itself. We’re still using punch cards, now emulated on modern high-resolution monitors. We’re still doing line-oriented programming with an alpha-numeric character set. We’re still using programming languages that, for the most part, behave like C or like LISP, and the biggest debates in the programming community are about which of these ancient paradigms is better. We have IDEs that make it somewhat easier to generate those virtual punch cards, but don’t fundamentally change the nature of the beast. We have some tools for unit testing, but they work by requiring us to write more punch cards (unit tests). We have version control tools for managing changes to those punch cards. And we even have tools for continuous integration, continuous deployment, and container orchestration—all of which are programmed by creating more virtual punch cards.

Database developers are in somewhat better shape. Non-procedural languages like SQL lend themselves more readily to visual programming styles, yielding tools like Tableau, though those tools don’t help much if you’re connecting an enterprise application to a back-end database.

Where can we go from here? I’ve long thought that the real next-generation programming language won’t be a rehash of LISP, C, or Smalltalk syntax. It won’t be character based at all: it will be visual. Rather than typing, we’ll draw what we want. I’ve yet to see a language that fits the bill. Teaching platforms like Alice and Scratch are an interesting attempt, but they don’t go anywhere near far enough: they just take the programming languages we already know and apply a visual metaphor. A C-clamp instead of a loop. Plug-together blocks instead of keywords. Nothing has really changed.

I suspect that the visual programming language we need will borrow ideas from all of our programming paradigms: it will pass messages, it will have objects, it will support concurrency, and so on. What it won’t have is a textual representation; it won’t be a visual sugarcoating(糖衣) to an underlying language like C.

I have some ideas about where such a language might come from. I see two trends that might help us think about the future of programming.

First, I see increasing evidence that there are two kinds of programmers: programmers who build things by connecting other things together, and programmers who create the things that others connect together. The first is the “blue collar” group of programmers; the second is the “academic” group of programmers–for example, the people doing new work in AI. Neither group is more valuable or important than the other. Building trades provide a good analogy. If I need to install a new kitchen sink, I call a plumber. He knows how to connect the sink to the rest of the plumbing; he doesn’t know how to design the sink. There’s a sink designer in an office somewhere who probably understands (in a rudimentary way) how to connect the sink to the plumbing, but whose real expertise is designing sinks, not installing them. You can’t do without either, though the world needs more plumbers than designers. The same holds true for software: the number of people who build web applications is far greater than the number of people who build web frameworks like React or who design new algorithms and do fundamental research.

Should the computational plumber use the same tools as the algorithm designer? I don’t think so; I can imagine a language that is highly optimized for connecting pre-built operations, but not for building the operations themselves. You can see a glimpse of this in languages that apply functions to every element of a list: you no longer need loops. (Python’s map() applies a function to every element of a list; there are languages where functions behave like this automatically.) You can see PHP as a language that’s good for connecting web pages to databases, but horrible for implementing cryptographic algorithms. And perhaps this connective language might be visual: if we’re just connecting a bunch of things, why not use lines rather than lines of code? (Mel Conway is working on “wiring diagrams” that allow consumers to build applications by describing interaction scenarios.)

Second, one of the most interesting research areas in artificial intelligence is the ability to generate code. A couple of years ago, we saw that AI was capable of optimizing database queries. Andrej Karpathy has argued that this ability places us on the edge of Software 2.0, in which AI will generate the algorithms we need. If, in the future, AI systems will be able to write our code, what kind of language will we need to describe the code we want? That language certainly won’t be a language with loops and conditionals; nor do I think it will be a language based on the mathematical abstraction given by functions. Karpathy suggests that the core of this language will be tagged datasets for training AI models. Instead of writing step-by-step instructions, we will show the computer what we want it to do. If you think such a programming paradigm is too radical, too far away from the process of making a machine do your bidding, think about what the machine language programmers of the 1950s would think about a modern optimizing compiler.

So, while I can’t yet imagine what a new visual language will look like, I can sense that we’re on the edge of being able to build it. In fact, we’re building it already. One of Jeremy Howard’s projects at platform.ai is a system that allows subject matter experts to build machine learning applications without any traditional programming. And Microsoft has launched a drag-and-drop machine learning tool that provides a graphical tool for assembling training data, cleaning it, and using it to build a model without any traditional programming. I suppose one could argue that this “isn’t real programming,” but that’s tantamount to defining programming by its dependence on archaic tools.

What about the rest? What about the tools for building, testing, deploying, and managing software? Here’s where Kay underestimates what we have. I’d agree that it isn’t much, but it’s something; it’s a foundation that we can build upon. We have more than 40 years of experience with build tools (starting with make in 1976), and similar experience with automated configuration (CFengine, the precursor to Chef and Puppet, goes back to the ‘90s), network monitoring (Nagiosdates back to 2002), and continuous integration (Hudson, predecessor of Jeeves, dates to 2005). Kubernetes, which handles container orchestration, is the “new kid on the block.” Kubernetes is the robotically automated factory for distributed systems. It’s a tool for managing and operating large software deployments, running across many nodes. That’s really a complete tool suite that runs from automated assembly through automated testing to fully automated production. Lights off; let the computers do the work.

Sadly, these tools are still configured with virtual punch cards (text files, usually in XML, YAML, JSON, or something equally unpleasant), and that’s a problem that has to be overcome. I think the problem isn’t difficulty–creating a visual language for any of these tools strikes me as significantly easier than creating a visual language for programming–it’s tradition.

Software people are used to bad tools. And while we’d hate being forced to use physical punch cards (I’ve done that, it’s no fun), if you virtualize those punch cards, we’re just fine. Perhaps it’s a rite of passage, a sort of industrial hazing. “We survived this suckage, you should too if you’re going to be a real programmer.” We’re happy with that.

Kay is right that we shouldn’t be happy with this state of affairs. The pain of building software using tools that would be immediately understandable to developers in the 1960s keeps us thinking about the bits, rather than the meaning of those bits. As an industry, we need to get beyond that. We have prototypes for some of the tools we need. We just need to finish the job.

We need to imagine a different future for software development.Article image: A punch card with Fortran. (source: Tangopaso via Wikimedia Commons).Tags: O’Reilly Radar Analysis



启动 Odoo 抛错 TypeError: __call__() takes exactly 2 arguments (1 given)

$ /bin/python /home/openerp/odoo/openerp-server -c /etc/odoo-server.conf
Traceback (most recent call last):
File “/home/openerp/odoo/openerp-server”, line 2, in <module>
import openerp
File “/odoo/odoo/openerp/__init__.py”, line 81, in <module>
import report
File “/odoo/odoo/openerp/report/__init__.py”, line 24, in <module>
import interface
File “/odoo/odoo/openerp/report/interface.py”, line 31, in <module>
import render
File “/odoo/odoo/openerp/report/render/__init__.py”, line 23, in <module>
from rml import rml, rml2html, rml2txt, odt2odt , html2html, makohtml2html
File “/odoo/odoo/openerp/report/render/rml.py”, line 28, in <module>
import makohtml2html as makohtml
File “/odoo/odoo/openerp/report/render/makohtml2html/__init__.py”, line 22, in <module>
from makohtml2html import parseNode
File “/odoo/odoo/openerp/report/render/makohtml2html/makohtml2html.py”, line 24, in <module>
from mako.template import Template
File “/usr/lib64/python2.7/site-packages/mako/template.py”, line 10, in <module>
from mako.lexer import Lexer
File “/usr/lib64/python2.7/site-packages/mako/lexer.py”, line 11, in <module>
from mako import parsetree, exceptions, compat
File “/usr/lib64/python2.7/site-packages/mako/parsetree.py”, line 9, in <module>
from mako import exceptions, ast, util, filters, compat
File “/usr/lib64/python2.7/site-packages/mako/exceptions.py”, line 273, in <module>
_install_highlighting()
File “/usr/lib64/python2.7/site-packages/mako/exceptions.py”, line 270, in _install_highlighting
_install_pygments()
File “/usr/lib64/python2.7/site-packages/mako/exceptions.py”, line 255, in _install_pygments
from mako.ext.pygmentplugin import syntax_highlight # noqa
File “/usr/lib64/python2.7/site-packages/mako/ext/pygmentplugin.py”, line 7, in <module>
from pygments.lexers.web import \
File “/usr/lib/python2.7/site-packages/pygments/lexers/__init__.py”, line 18, in <module>
from pygments.plugin import find_plugin_lexers
File “/usr/lib/python2.7/site-packages/pygments/plugin.py”, line 39, in <module>
import pkg_resources
File “/usr/lib/python2.7/site-packages/pkg_resources/__init__.py”, line 72, in <module>
import packaging.requirements
File “/usr/lib/python2.7/site-packages/packaging/requirements.py”, line 59, in <module>
MARKER_EXPR = originalTextFor(MARKER_EXPR())(“marker”)
TypeError: __call__() takes exactly 2 arguments (1 given)

解决办法,降 setuptools 版本

# pip install setuptools==33.1.1
Collecting setuptools==33.1.1
Downloading setuptools-33.1.1-py2.py3-none-any.whl (472kB)
100% |████████████████████████████████| 481kB 852kB/s
Installing collected packages: setuptools
Found existing installation: setuptools 35.0.2
Uninstalling setuptools-35.0.2:
Successfully uninstalled setuptools-35.0.2
Successfully installed setuptools-33.1.1