KDE Akademy is meeting this week in Würzburg.
We just had a BoF session where we discussed..
Plasma Wayland Protocols 1.14.0 is now available for packaging.
This adds features needed for the Plasma 6.2 beta.
URL: https://download.kde.org/stable/plasma-wayland-protocols/
SHA256: 1a4385ecfc79f7589f07381cab11c3ff51f6e2fa4b73b78600d6ad096394bf81
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Riddell jr@jriddell.org
Full changelog:
https://openuk.uk/openuk-september-2024-newsletter-1/
https://www.linkedin.com/feed/update/urn:li:activity:7238138962253344769/
Our 5th annual Awards are open for nominations and our 2024 judges are waiting for your nominations! Hannah Foxwell, Jonathan Riddell, and Nicole Tandy will be selecting winners for 12 categories. ?
The OpenUK Awards 2024 are open for nominations until Sunday, September 15.. Our 5th Awards again celebrate the UK’s leadership and global collaboration in open technology!
Nominate now! https://openuk.uk/awards/openuk-awards-2024/
Up to 3 shortlisted nominees will be selected in each category by early October and each nominee will be given one place at the Oscars of Open Source, the black tie Awards Ceremony and Gala Dinner for our 5th Awards held at the House of Lords on 28 November, thanks to the sponsorship of Lord Wei.
Today, we bring you a report on the brand-new release of the Maui Project.
We are excited to announce the latest release of MauiKit version 4.0.0, our comprehensive user interface toolkit specifically designed for convergent interfaces, the complying frameworks, and an in-house developed set of convergent applications.
Built on the solid foundations of Qt Quick Controls, QML, and the power and stability of C++, MauiKit empowers developers to create adaptable and seamless user interfaces across a range of devices, and with this release, we have finally migrated to Qt6 and made available the documentation for the frameworks.
Join us on this journey as we unveil the potential of MauiKit 4 for building convergent interfaces, and finally discover the possibilities offered by the enhanced Maui App stack.
To follow the Maui Project’s development or to just say hi, you can join us on our Telegram group @mauiproject
We are present on X and Mastodon:
Thanks to the KDE contributors who have helped to translate the Maui Apps and Frameworks!
You can get the stable release packages [APKs, AppImage, TARs] directly from the KDE downloads server at https://download.kde.org/stable/maui/
All of the Maui repositories have the newly released branches and tags. You can get the sources right from the Maui group: https://invent.kde.org/maui
With this version bump the Maui team has finalized the migration over to Qt6, which implies more stability and better performance coming from Qt upgraded QQC engine; but also means that some features have been removed or did not make the cut and still need more time to be brought back in posterior releases.
Currently, there are over 10 frameworks, with two new ones recently introduced. They all, for the most part, have been fully documented, and although, the KDE doxygen agent has some minor issues when publishing some parts, you can find the documentation online at https://api.kde.org/mauikit/ (and if you find missing parts, confusing bits, or overall sections to improve – you can open a ticket at any of the framework repos and it shall be fixed shortly after)
fav filemanager and music player. minimal modern & convergent @maui_project
— Camilo Higuita (@cmhiguita) May 6, 2024
Maui Apps 4.0 coming out soon. pic.twitter.com/OVLM2HWv6v
A script element has been removed to ensure Planet works properly. Please find it in the original post.
MauiKit Core controls also include the Mauikit Style, which along with the core controls has been revised and improved in the migration. New features have been introduced and some minor changes in the API have been made.
A good way to test the new changes made visually is via the MauiDemo application, when building MauiKit from the source, just add the -DBUILD_DEMO=ON flag and then launch it as MauiDemo4
All of the other frameworks have also been fully ported and reviewed, and some features are absent – for example, for ImageTools the image editor is missing for Android due to KQuickImageEditor problems.
Comic book support is missing in MauiKit-Documents, due to a big pending refactoring.
Finally, TextEditor new backend rendering engine migration is yet to be started.
Most of these pending issues will be tackled in the next releases bit by bit.
More details can be found in the previous blog posts:
Maui Release Briefing # 4
Maui Release Briefing #5
MauiKit-Archiver is a new framework, and it was created to share components and code between different applications that were duplicating the same code: Index, Arca, and Shelf.
The same goes for MauiKit-Git, which will help unify the code base for implementations made in Index, Bonsai, and Strike, so all of those apps can benefit from a single cohesive and curated code base in the form of a framework.
Archiver is pending to be documented, and Git is pending to be finished for its first stable release.
I have now finished porting all the Maui Apps and MauiKit frameworks to Qt6.
— Camilo Higuita (@cmhiguita) May 1, 2024
Vvave music player mini mode is back.@maui_project @Nitrux_NX pic.twitter.com/Mal3RU87O2
A script element has been removed to ensure Planet works properly. Please find it in the original post.
@maui_project looking good. after the port to qt6 the next goal is to put out a stable version of Maui Shell with a tight integration to the app ecosystem and the HIG #mauikit pic.twitter.com/BkR9ecTzMT
— Camilo Higuita (@cmhiguita) May 6, 2024
A script element has been removed to ensure Planet works properly. Please find it in the original post.
Although Maui Shell has been ported over to Qt6 and is working with the latest MauiKit4, a lot of pending issues are still present and being worked on. The next release will be dedicated fully on Maui Shell and all of its subprojects, such as Maui Settings, Maui Core, CaskServer, etc.
That’s it for now. Until the next blog post, that will be a bit closer to the 4.0.1 stable release.
The post Maui Release Briefing #6 appeared first on MauiKit — #UIFramework.
After years and years of working together on KPhotoAlbum, a considerable part of the devs team (Johannes and me ;-) finally met in-person, at Akademy in Würzburg!
It was a very nice and pleasurable meeting, with lots of information around KDE, e.g. community goals, where we stand with Qt 5 and 6 and where we want to go, programming, sustainability and so on. Thoroughly nice and friendly people (esp. the two of us of course ;-), with whom one could have nice and productive conversations. If you can, go to Akademy – it's worth it!
Also, we hopefully again could emphasize – in person – the importance a Qt6/KF6 port of Marble for KPhotoAlbum and also KGeoTag. We now actively work on porting KPA to Qt6/KF6, but we need Marble to be able to finally release it. But we're confident everything will work out.
Hopefully, this won't be the last time we meet!
The KDE community has charted its course for the coming years, focusing on three interconnected paths that converge on a single point: community. These paths aim to improve user experience, support developers, and foster community growth.
This goal focuses on improving the application development process. By making it easier for developers to create applications, KDE hopes to attract more contributors and deliver better software for both first-party and third-party applications. A notable task within this goal is enhancing the experience of building KDE apps with languages beyond C++, such as Rust or Python.
Champions: Nicolas Fella and Nate Graham
KDE has a diverse users base with unique input needs: artists using complex monitor and drawing tablet setups; gamers with controllers, fancy mice, and handhelds; users requiring accessibility features or using a language optimally types with complex input methods; students with laptops, 2-in-1s, and tablets — and more! While KDE has made significant progress in supporting these diverse sources of input over the years, there are still gaps to be addressed. This goal aims to close those gaps and deliver a truly seamless input experience for everyone.
Champions: Gernot Schiller, Jakob Petsovits and Joshua Goins
KDE’s growth depends on new contributors, but a lack of fresh involvement in key projects like Plasma, Kdenlive, Krita, GCompris, and others is a concern. This goal focuses on formalizing and enhancing recruitment processes, not just for individuals but also for institutions. Ensuring that bringing in new talent becomes a continuous and community-wide priority, vital for KDE's long-term sustainability.
Champions: Aniqa Khokhar, Johnny Jazeix and Paul Brown
Your voice, your code, and your ideas are what will shape the KDE of tomorrow — whether you're a user, developer, or contributor. Let’s go on this journey together and make these goals a reality!
Join the Matrix room and keep an eye on the website for the latest KDE Goals updates.
In April we had the combined goals sprint, where a fine group of KDE people working on things around Automation & Systematization, Sustainable Software, and Accessibility got together. It was a nice cross-over of the KDE goals, taking advantage of having people in one room for a weekend to directly discuss topics of the goals and interactions between them. David, Albert, Nate, Nico, and Volker wrote about their impressions from the sprint.
So what happened regarding the Sustainable Software goal at the sprint and where are we today with these topics? There are some more detailed notes of the sprint. Here is a summary of some key topics with an update on current progress.
The Opt-Green project is the second funded project of the KDE Eco team. The first one was the Blue Angel for Free Software project, where we worked on creating material helping Free Software projects to assess and meet the criteria for the Blue Angel certification for resource and energy-efficient software products.
The Opt Green project is about promotion of extending the operating life of hardware with Free Software to reduce electronic waste. It's funded for two years by the German Federal Environment Agency and the Federal Ministry for the Environment, Nature Conservation, Nuclear Safety and Consumer Protection and is running from April 2024 to March 2026.
Joseph introduced the project, why it's important, how the environment is suffering from software-induced hardware obsolescence, and how Free Software in general and KDE specifically can help with fighting it. The approach of the project is to go beyond our typical audience and introduce people who are environmentally aware but not necessary very technical to the idea of running sustainable, up-to-date Free Software on their computers, even devices they may think are no longer usable due to lack of vendor support. In many cases this is a perfectly fine solution, and it's surprisingly attractive to a number of people who care about sustainability but haven't really been introduced to Free Software yet.
The project is in full swing. The project has already been present at quite a number of events to motivate people to install Free Software on their (old) devices and support them in how to do it. See for example the report about the Academy of Games for upcoming 9th graders in Hannover, Germany.
We had a great session putting together ideas and concepts about how we could improve the KDE Eco website. From brainstorming ideas to sketching a wireframe as a group, we discussed and agreed on a direction of how to present what we are doing in the KDE Eco team.
The key idea is to focus on three main audiences (end users, advocates, and developers) and present specific material targeted at these groups. This nicely matches what we already have, e.g., the KDE Eco handbook for how to fulfill the Blue Angel criteria for developers, or the material being produced for events reaching out to end users, and while giving it a much more focused presentation.
The first iteration of the new design is now live on eco.kde.org. There is more to come, but it already gives an impression where this is going. Anita created a wonderful set of design elements which will help to shape the visual identity of KDE Eco going forward.
Making use of old hardware by installing sustainable free software on it is a wide field. There are many different variations of devices and what users do with them also varies a lot. What are the factors that might encourage users to reuse old hardware, what is holding them back?
To get a bit more reliable answers to these questions we came up with a concept for a user survey which can be used at events where we present the Opt Green project. This includes questions about what hardware people have and what is holding them back from installing new software on it.
The concept has been implemented with an online survey on KDE's survey service. It's available in English and German and is being used at the events where the Opt Green project is present.
One of the big hype topics of the last two years has been Generative AI and the Large Language Models which are behind this technology. They promise to bring revolutionary new features, much closer to how humans interact in natural language, but they also come with new challenges and concerns.
One of the big questions is how this new technology affects our digital freedoms. How does it relate to Free Software? How does licensing and openness work? How does it fit KDE's values? Where does it make sense to use its technology? What are the ethical implications? What are the implications in terms of sustainability?
We had a discussion around the possible idea of adopting something like Nextcloud's Ethical AI rating in KDE as well. This would make it more transparent to users how use of AI features affects their freedoms and gives them a choice to use what they consider to be satisfactory.
This is still pretty much an open question. The field is moving fast, there are legal questions around copyright and other aspects still to be answered. Local models are becoming more and more an option. But what openness means in AI has become very blurry. KDE still has to find a position here.
A while ago a colleague of mine asked about our crash infrastructure in Plasma and whether I could give some overview on it. This seems very useful to others as well, I thought. Here I am, telling you all about it!
Our crash infrastructure is comprised of a number of different components.
We’ve already looked at KCrash and coredumpd. Now it is time to look at DrKonqi.
DrKonqi is the UI that comes up when a crash happens. We’ll explore how it integrates with coredumpd and Sentry.
When I outlined the functionality of coredumpd, I mentioned that it starts an instance of systemd-coredump@.service. This not only allows the core dumping itself to be controlled by systemd’s
resource control and configuration systems, but it also means other systemd units can tie into the crash handling as well.
That is precisely what we do in DrKonqi. It installs drkonqi-coredump-processor@.service which, among other things, contains the rule:
@jriddell:kde.org
WantedBy=systemd-coredump@.service
…meaning systemd will not only start systemd-coredump@unique_identifier but also a corresponding drkonqi-coredump-processor@unique_identifier. This is similar to how services start as part of the system boot sequence: they all are “wanted by” or “want” some other service, and that is how systemd knows what to start and when (I am simplifying here 😉). Note that unique_identifier is actually a systemd feature called “instances” — one systemd unit can be instantiated multiple times this way.
When drkonqi-coredump-processor@unique_identifier runs, it first has some synchronization to do.
As a brief recap from the coredumpd post: coredumpd’s crash collection ends with writing a journald entry that contains all collected data. DrKonqi needs this data, so we wait for it to appear in the journal.
Once the journal entry has arrived, we are good to go and will systemd-socket-activate a helper in the relevant user.
The way this works is a bit tricky: drkonqi-coredump-processor runs as root, but DrKonqi needs to be started as the user the crash happened to. To bridge this gap a new service drkonqi-coredump-launcher comes into play.
Every user session has a drkonqi-coredump-launcher.socket systemd unit running that provides a socket. This socket gets connected to by the processor (remember: it is root so it can talk to the user socket). When that happens, an instance of drkonqi-coredump-launcher@.service is started (as the user) and the processor starts streaming the data from journald to the launcher.
The crash has now traveled from the user, through the kernel, to system-level systemd services, and has finally arrived back in the actual user session.
Having been started by systemd and initially received the crash data from the processor, drkonqi-coredump-launcher
will now augment that data with the KCrash metadata originally saved to disk by KCrash.
Once the crash data is complete, the launcher only needs to find a way to “pick up” the crash. This will usually be DrKonqi, but technically other types of crash pickup are also supported. Most notably, developers can set the environment variable KDE_COREDUMP_NOTIFY=1 to receive system notifications about crashes with an easy way to open gdb for debugging. I’ve already written about this a while ago.
When ready, the launcher will start DrKonqi itself and pass over the complete metadata.
the crashed application
└── kernel
└── systemd-coredumpd
├── systemd-coredumpd@unique_identifier.service
└── drkonqi-coredump-processor@unique_identifier.service
├── drkonqi-coredump-launcher.socket
└── drkonqi-coredump-launcher@unique_identifier.service
└── drkonqi
What a journey!
DrKonqi kicks off crash processing. This is hugely complicated and probably worth its own post. But let’s at least superficially explore what is going on.
The launcher has provided DrKonqi with a mountain of information so it can now utilize the CLI for systemd-coredump, called
coredumpctl, to access the core dump and attach an instance of the debugger GDB to it.
GDB runs as a two step automated process:
As part of this automation, we run a service called the preamble: a Python program that interfaces with
the Python API of GDB.
Its most important functionality is to create a well-structured backtrace that can be converted to a
Sentry payload.
Sentry, for the most part, doesn’t ingest platform specific core dumps or crash reports, but instead relies on an abstract
payload format that is generated by so called Sentry SDKs. DrKonqi essentially acts as such an SDK for us.
Once the preamble is done, the payload is transferred into DrKonqi and the next step can continue.
After the preamble, DrKonqi executes an actual GDB trace (i.e. the literal backtrace command in gdb) to generate the developer output. This is also the trace that gets sent to KDE’s Bugzilla instance at bugs.kde.org if the user chooses to file a bug report. The reason this is separate from the already
created backtrace is mostly for historic reasons. The trace is then routed through a text parser to figure out if it is of sufficient
quality; only when that is the case will DrKonqi allow filing a report in Bugzilla.
With all the trace data assembled, we just need to send them off to Bugzilla or Sentry, depending on what the user chose to do.
The Bugzilla case is simply sending a very long string of the backtrace to the Bugzilla API (albeit surrounded by some JSON).
The Sentry case on the other hand requires more finesse. For starters, the Sentry code also works when offline. The trace and optional user message get converted into a Sentry envelope tagged with a receiver address — a Sentry-specific URL for ingestion so it knows under which project to file the crash. The envelope is then written to ~/.cache/drkonqi/sentry-envelopes/. At this point, DrKonqi’s job is done; The actual transmission happens in an auxiliary service.
Writing an envelope to disk triggers drkonqi-sentry-postman.service which will attempt to send all pending envelopes to Sentry using the URL inside the payload. It will try to do so every once in a while in case there are pending envelopes as well, thereby making sure crashes that were collected while offline still make it to Sentry eventually. Once sent successfully, the envelopes are archived in ~/.cache/drkonqi/sentry-sent-envelopes/.
This concludes DrKonqi’s activity. There’s much more detail going on behind the scenes but it’s largely inconsequential to the overall flow. Next time we will look at the final piece in the puzzle — Sentry itself.
在客户端因某些原因异常退出时，服务端将无法正常处理其他请求.
GSoCrecv一直在阻塞着读取，且无法处理其他请求如何往线程池中传入类的成员函数.
auto task = [](){ 类的成员函数 } m_pool.submit(task);1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
* `Tcp`传输为字节流传输，采用在每条消息前面加上`长度`来正确接收每条请求.
* 在代码中往`redis`数据库中添加好友申请数据时，没有正确插入.
* 由于好友申请当中包含时间，姓名等信息，中间含有**空格**，在redis的哈希表中无法插入.
* 经过查阅在redis哈希表中，**空格**可以用`+`代替，在遇到`+`时会被转义为**空格**，或者存储为**十六进制**，但是这种方法在终端中的**空格**为灰色.
* 在聊天界面如果输入带有`%`，服务器直接挂掉.
* ```c++
int redisAsyncContext::Lpush(const std::string &key, const std::string &value)
{
//std::string cmd = "lpush " + key + " " + value;
this->m_reply = (redisReply *)redisCommand(this->m_connettion, "LPUSH %s %s", key.c_str(), value.c_str());
// 检查 m_reply 是否为 NULL
if (this->m_reply == NULL) {
std::cerr << "Error: redisCommand returned NULL" << std::endl;
return -1; // 或其他合适的错误值
}
// 检查 m_reply 类型
if (this->m_reply->type != REDIS_REPLY_INTEGER) {
std::cerr << "Error: Expected integer reply" << std::endl;
freeReplyObject(this->m_reply);
return -1; // 或其他合适的错误值
}
int num = this->m_reply->integer;
freeReplyObject(this->m_reply);
std::cout << "G" << std::endl;
return num;
}
在执行下面两句是，%会被替换为cmd.c_str(),导致无法将消息插入历史记录表，导致出现错误.
1 | std::string cmd = "lpush " + key + " " + value; |
只要更改为下面即没有问题
1 | this->m_reply = (redisReply *)redisCommand(this->m_connettion, "LPUSH %s %s", key.c_str(), value.c_str()); |
在某次测试时，新注册账号id为0614897828,导致与该账号聊天的账号进入聊天界面时，0614897828发送的消息会在他人界面显示为通知消息.
0614897828聊天时，数据库中记录账号为614897828.score字段字符串中的0去除.将从字符串的首位非0开始存储.在进入好友私聊界面时，客户端新建了来接收消息，同时主线程发消息，主线程通过判断用户是否键入Esc来退出聊天界面，在输入Esc时，接收消息线程无法正确回收，无法退出聊天界面.
Esc时，将标志位设置为false,但由于客户端的recv为阻塞，导致无法及时获取到标志位的更改.Esc时，服务器向客户端发送退出信号，这样就可以正确及时的获取到标志位的更改，从而正确退出.在进行发送文件时，服务器会先将文件存储在本地，但是服务器存储的文件会多写入一些信息，导致接收文件大小偏大.
实现后台发送文件，由于会有实时刷新的存在，会导致文件发送不准确.
socket连接到服务器，在将发送这个文件交给另外一个线程socket发送文件后，服务器不用手动断开连接，服务器有心跳检测，会在一段时间后断开.是一个Linux系统调用，也是一种进程间通信(IPC)机制，主要通过使用文件描述符生成和使用事件通知.
提供了一种在不同进程之间或同一进程内的线程之间的同步事件的方法.
异常是程序在执行期间产生的问题。c++异常是指在程序运行时发生的特殊情况.
异常提供了一种转移程序控制权的方式。C++ 异常处理涉及到三个关键字：try、catch、throw
关键字：try、catch、throw。
catch: 在您想要处理问题的地方，通过异常处理程序捕获异常。catch 关键字用于捕获异常
try: try 块中的代码标识将被激活的特定异常。它后面通常跟着一个或多个 catch 块
1 | try |
SIGPIPE 是一种信号，当一个进程尝试向一个已经关闭的或不可写的管道或套接字写数据时，会触发这个信号。默认情况下，接收到 SIGPIPE 信号的进程会终止。这在网络编程中会导致一些问题，因为如果客户端断开连接，服务器进程在写入数据时会因为这个信号而意外退出。
在网络编程中，特别是使用套接字进行通信时，忽略 SIGPIPE 信号是一个常见的做法。这样可以防止进程因为 SIGPIPE 信号而意外终止。相反，程序可以通过检测 send 或 write 操作的返回值来处理错误，从而使程序更加健壮。
初始客户端构思方面的缺陷，导致实时消息没有线程及时接收。
当前处理方式为服务端将通知消息放入数据库当中，客户端在登陆之后，增加一个线程来定时执行刷新函数，刷新数据库中的通知消息
可以优化为在客户端登陆之后，采用多线程的方式来处理相关操作.
目前只有在历史消息这一操作涉及到redis+mysql的处理方式.
可以将一些重要信息也采用redis+mysql的处理方式(涉及到redis的存储方式，redis存储于内存当中，会造成数据丢失的情况)
可以考虑将redis全部做为缓存的形式，将重要信息与历史消息类似，达到一定情况下放入mysql,使数据更加的持久化.
继续学习epoll的相关内容.
了解其余网络框架，使得该项目的服务端更加的健壮.
了解消息队列的信息同步的问题.
熟悉零拷贝的过程，以及零拷贝的具体实现.
序列化的相关协议，json与其他序列化的区别、json的优点，以及为什么不用其他的序列化
数据库的深入学习，了解redis的缓存穿透、缓存雪崩、缓存击穿。加强对mysql数据库的学习.
加强对网络协议相关知识的学习.
C++提供了四个强制类型转换的关键字：
static_castconst_castreinterpret_cast1 | static_cast<目标类型>(表达式) |
1 | int num = 2; |
该运算符将表达式转换为目标类型。但没有进行运行时类型检查来保证转换的安全性。
主要用法
int与char，安全性也需要程序员来保证1 | class Person |
const_cast是c++中专用于处理与const相关的强制类型转换的关键字
其功能为：为一个变量重新设定其const描述.
即：const_cast可以为一个变量强行增加或删除其const限定.
需要明确的是，即使用户通过const_cast强行去除了const属性，也不代表当前变量从不可变变为了可变。const_cast只是使得用户接管了编译器对于const限定的管理权，故用户必须遵守“不修改变量”的承诺。如果违反此承诺，编译器也不会因此而引发编译时错误，但可能引发运行时错误。
volatile和__unaligned属性。1 | class Student |
在const成员函数fun()中，编译器将“this”视为“ const student const this”，即“this”是指向常量对象的常量指针，因此编译器不允许通过以下方式更改数据成员“这个”指针。const_cast将“this”指针的类型更改为“student const this”。
const_cast比简单类型转换更安全。从某种意义上讲，如果强制类型与原始对象不相同，则强制转换不会发生，这是比较安全的。
1 | int a=20; |
reinterpret,即重新解释.
该强制类型转换的作用是提供某个变量在底层数据上的重新解释.
当我们对一个变量使用reinterpret_cast后，编译器将无视任何不合理行为，强行将被转换变量的内存数据重解释为某个新的类型。用于进行各种不同类型的指针之间、不同类型的引用之间以及指针和能容纳指针的整数类型之间的转换。转换时，执行的是逐个比特复制的操作。 它不检查指针类型和指针所指向的数据是否相同。
需要注意的是，reinterpret_cast要求转换的两个数据所占用的内存大小一致，否则会引发编译时错误.
1 | data_type *var_name = reinterpret_cast <data_type *>(pointer_variable); |
使用 reinterpret_cast 的目的：
1 | class A { |
dynamic用于在运行时实现向下类型转换。
1 | dynamic_cast <type-id> (expression) |
将expression转换为type-id类型,type-id必须是类的指针，类的引用或者是void,
如果type-id是一个指针，那么expression也是一个指针，是引用的话同为引用
特点如下：
nullptr。static_cast的效果是一样的。在进行父类指针向子类指针的转换时，dynamic_cast具有类型检查的功能，比static_cast更安全。dynamic_cast操作符则可以在运行期对可能产生问题的类型转换进行测试。1 | class AA { |