Ⅰ 脚本和机器人问题。
第一个问题,脚本是不带POD的,你的CS是带POD插件的么?不带的话,就去下载一个!带的话,加不上人的原因就是你的脚本与CS里的POD插件冲突了!
第二个问题,你进的F有可能是安装的检测,你的脚本与服务器OP相冲突,换个脚本试试!实在不行,就完全卸载,重新安装一次!就不要安那种脚本了!
有什么不明白的继续追问!
Ⅱ 什么是pod类型
Clifton F. Vaughn 答案: 确实如此，在这个方面 C# 与 C++ 是有差别的。在 C++ 中，如果你从构造函数或者析构函数中调用虚拟函数，编译器调用的虚拟函数是定义在这个正在被构造的类实例中的（例如，如果从 Base::Base 中调用 Base::SomeVirtFn ），不是最底层派生的实例（the most derived instance），正像你说的那样，因为在最底层派生的构造函数执行之前，虚表还没有完全被初始化。另一种说法是派生类还没有被创建。
Figure 2 虚拟函数 TestSimilarly
正如你所指出的那样，在 C# 有所不同。托管对象——无论是在 C#，托管 C++ 中，还是任何其它的 .NET 兼容语言中——是作为其最终类型被创建的，也就是说，如果你从构造函数或析构函数中调用虚函数，系统调用的是最末层派生的函数。Figure 1 所示程序举例说明了这一点。如果你编译并运行这个程序，你会看到 Figure 2 所示输出。
这种行为对于 C++ 程序员来说似乎有些奇特。它意味着在派生类被初始化之前，你可以调用某个派生类型的虚拟函数——也就是说在其构造函数运行之前。同样，如果你从基类析构函数中调用虚函数，该函数是在派生类被销毁之后运行的——也就是说在析构函数被调用之后。那么先不说这种差别存在的原因，刚才不是还说从构造函数/析构函数中调用虚函数被认为是糟糕的实践。
为什么微软的家伙们要像这样来设计 C# 呢？因为它简化了内存管理。垃圾收集器为了释放内存，它需要知道对象有多大。如果 C# 像 C++ 那样构造对象，那么你可能会碰到这样一种情况：有两个对象，Obj1 和 Obj2，下面这两条语句都为真：typeof(Obj1)==typeof(Obj2) sizeof(Obj1)!= sizeof(Obj2) 因为对象之一是被部分构造。（不要忘了垃圾收集器是异步运行的。）通过将对象构造成最终类型，垃圾收集器能从其类型决定对象的大小。如果 C# 像 C++ 那样进行部分构造，则垃圾收集器将需要更多的代码来决定部分构造对象的真实大小。这样将带来复杂性和性能下降，首先要解决这个问题很让人气馁，所以为了较快的垃圾收集利益，微软的家伙们决定像上面那样来实现 C#。有关这方面的讨论参见 Raymond Chen 的 blog：“The Old New Thing”。
问题: 在2004 三月的专栏中，你展示了如何改变文件打开对话框的最新视图状态设置，但没有涉及到保存这个用户使用的最新视图设置。我遇到的问题是读取用户已有的打开文件对话框设置。我只找到直接读取列表框信息的方法，但当用户选择缩略图模式时，那样做不能得到正确的信息。对此你有没有解决办法？ Maarten van Dillen 问题: 我正在用公共的 CFileDialog 类做开发，应该不是很难，但事情似乎并不是那样。我想强制文件打开对话框的视图模式为缩略图。我要用 Visual C++ 来做，你能否提供一些建议？ Elliot Leonard
答案: 有几个读者都在问文件打开对话框中的缩略图问题。在我三月份的专栏中，我示范了如果向文件打开对话框中的 SHELLDLL_DefView 专用窗口发送 WM_COMMAND 消息以设置不同的视图模式——但你如何知道当前所处的模式是哪一个呢？你必须获取列表控件并调用 CListCtrl::GetView：// in dialog class HWND hlc = ::FindWindowEx(m_hWnd, NULL, _T("SysListView32"), NULL); CListCtrl* plc = (CListCtrl*)CWnd::FromHandle(hlc); DWORD dwView = plc->GetView(); CListCtrl::GetView 返回 LV_XXX 代码之一，但正像 Maarten 发现的那样，Windows 对图标模式和缩略图模式都返回 LV_VIEW_ICON。
那么如何区分到底是哪种视图模式呢？我绞尽脑汁并钻进头文件查找，最后发现一个叫 LVM_GETITEMSPACING 的消息，该消息是作什么用的呢——用来获取图标间隔。顾名思义，图标间隔是图标视图模式中图标之间的像素间隔。LVM_GETITEMSPACING 不是很好使用，以至于 MFC 都没有对之进行包装（比如说 MFC 中并没有 CListCtrl::GetIconSpacing 这样的函数）。所以在 MFC 中你得自己发送消息：CSize sz = CSize(plc->SendMessage(LVM_GETITEMSPACING)); Windows 按照通常方式返回尺寸，在高位和低位字中编码的 cx/cy，然后CSize很礼貌地为你进行解码。一旦有了图标间隔，你便可以将它与 GetSystemMetrics(SM_CXICONSPACING) 返回的系统间隔值进行比较。如果列表视图的图标间隔与系统的一样，则视图是图标模式。如果大于系统间隔，则视图为缩略图模式：if (sz.cx > GetSystemMetrics(SM_CXICONSPACING)) { // thumbnail view } else { // icon view } 讲了那么多缩略图，接下来的问题是如何持续化不同用户会话的视图状态？对此，当程序终止时，你需要用 Profile 函数在用户配置文件中保存最后使用的模式，并在下一次启动程序时再次恢复它。我写了一个小示范程序，DlgTest。程序使用了一个实现持续化程序行为的类 CPersistOpenDlg。这个类又借助另外一个类 CListViewShellWnd，用它来封装 SHELLDLL_DefView 窗口（参见三月份专栏）。CListViewShellWnd 包含获取和设置视图模式的函数，由这些函数来区分图标和缩略图模式：CListViewShellWnd m_wndLVSW; ... m_wndLVSW.SetViewMode(ODM_VIEW_THUMBS); CListViewShellWnd 的 OnDestroy 处理器在某个数据成员 m_lastViewMode 中保存视图模式。当对话框被销毁时，CPersistOpenDlg 的析构函数调用 WriteProfileInt 将这个值写入用户配置文件。对话框启动时，CPersistOpenDlg 给自己送一个初始化消息；该消息处理例程调用 GetProfileInt 从磁盘读取存储在配置文件中的值并设置视图模式。PostMessage 是必须调用的，因为常规初始化消息 WM_INITDIALOG 和 CDN_INITDONE 在文件对话框被完全初始化之前就会到来——有关这一点的解释参见三月份专栏。
顺便说一下，任何时候你都应该使用 GetProfileXxx 和 WriteProfileXxx 来持续化应用程序的设置。MFC 用 CWinApp 包装了这些函数。如果你在应用程序启动时调用（一般都是在 InitInstance 函数中） CMyApp::SetRegistryKey("KeyName")，MFC 使用注册表来存储用户配置信息，而不是 INI 文件。下面是 DlgTest 用的 INI 文件： [settings] ViewMode=28717问题: 偶尔在一些文字资料和 C++ 文档以及 Microsoft .NET 框架中看到术语“POD 类型”。这个术语是什么意思？
Shelby Nagwitz 答案: 你可以将 POD 类型看作是一种来自外太空的用绿色保护层包装的数据类型，POD 意为“Plain Old Data”（译者：如果一定要译成中文，那就叫“彻头彻尾的老数据”怎么样！）这就是 POD 类型的含义。其确切定义相当粗糙（参见 C++ ISO 标准），其基本意思是 POD 类型包含与 C 兼容的原始数据。例如，结构和整型是 POD 类型，但带有构造函数或虚拟函数的类则不是。 POD 类型没有虚拟函数，基类，用户定义的构造函数，拷贝构造，赋值操作符或析构函数。
为了将 POD 类型概念化，你可以通过拷贝其比特来拷贝它们。此外， POD 类型可以是非初始化的。例如：struct RECT r; // value undefined POINT *ppoints = new POINT[100]; // ditto CString s; // calls ctor ==> not POD 非POD 类型通常需要初始化，不论是调用缺省的构造函数（编译器提供的）还是自己写的构造函数。
过去， POD 对于编写编译器或与C 兼容的 C++ 程序的人来说很重要。现在，POD 来到 .NET 的环境中。在托管 C++ 中，托管类型（包括 __value 和 __gc 两者）能包含嵌入的原生 POD 类型。 Figure 3 展示了例举说明代码。托管的 Circle 类能包含 POINT，但无法包含 CPoint 类。如果你尝试编译 pod.cpp 会报一个 C3633 错误：“Cannot define ''m_center'' as a member of managed ''Circle'' because of the presence of default constructor ''CPoint::CPoint'' on class ''CPoint''.”（译者：意思是由于类 CPoint 有缺省的构造函数‘CPoint::CPoint’，所以不能将‘m_center’定义为托管类‘Circle’的一个成员）
.NET 限定嵌入的本地对象只能为 POD 类型的理由是这样做能安全地拷贝它们，不用担心调用构造函数，初始化虚表，或任何非 POD 类型需要的其它机制。
向Paul 提问和评论请发到 [email protected].
作者简介 Paul DiLascia 是一名自由作家，顾问和 Web/UI 设计者。他是《Writing Reusable Windows Code in C++》书（Addison-Wesley, 1992）的作者。
Ⅲ cs中如何调PODBOT智商是修改脚本的
在进行游戏时，按H键，在弹出的BOT设置菜单里就可以改了
Ⅳ 什么是“脚本文件”
一、啥叫脚本呢？
其实就是一段代码，作用就是：这些代码通过你的浏览器来鼓捣一下你的机器。这样，你就能通过点一下鼠标就可以发点欢迎词、发点情话啥地了。
脚本script是使用一种特定的描述性语言，依据一定的格式编写的可执行文件，又称作宏或批处理文件。脚本通常可以由应用程序临时调用并执行。各类脚本目前被广泛地应用于网页设计中，因为脚本不仅可以减小网页的规模和提高网页浏览速度，而且可以丰富网页的表现，如动画、声音等。举个最常见的例子，当我们点击网页上的E－mail地址时能自动调用Outlook Express或Foxmail这类邮件软件，就是通过脚本功能来实现的。又如洪恩网站�http�／／www．hongen．com一些网页的英文新闻内容旁会有一个三角符号，点击它就可以听到英文诵读，这也是脚本在起作用。 也正因为脚本的这些特点，往往被一些别有用心的人所利用。例如在脚本中加入一些破坏计算机系统的命令，这样当用户浏览网页时，一旦调用这类脚本，便会使用户的系统受到攻击。所以用户应根据对所访问网页的信任程度选择安全等级，特别是对于那些本身内容就非法的网页，更不要轻易允许使用脚本。通过“安全设置”对话框，选择“脚本”选项下的各种设置就可以轻松实现对脚本的禁用和启用。
解释二
动态程序一般有两种实现方式，一是二进制方式，一是脚本方式。
二进制方式是先将我们编写的程序进行编译，变成机器可识别的指令代码（如.exe文件），然后再执行。这种编译好的程序我们只能执行、使用，却看不到他的程序内容。
脚本简单地说就是一条条的文字命令，这些文字命令是我们可以看到的（如可以用记事本打开查看、编辑），脚本程序在执行时，是由系统的一个解释器，将其一条条的翻译成机器可识别的指令，并按程序顺序执行。因为脚本在执行时多了一道翻译的过程，所以它比二进制程序执行效率要稍低一些。
我们上面提到的各种动态语言，如ASP、PHP、CGI、JSP等，都是脚本语言。
按目前的服务规则，虚拟主机网站只能采用脚本语言来实现
Ⅳ cocoapods执行pod install , pod update都出现下面的错误
http://blog.csdn.net/zhangao0086/article/details/39703083
Ⅵ 请教kubernetes部署问题，pod一直处于pending状态
我们先从整体上看一下Kubernetes的一些理念和基本架构，然后从网络、资源管理、存储、服务发现、负载均衡、高可用、rollingupgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解Kubernetes的主要功能，今后在研究和使用这个具的时候有所参考和帮助。1.Kubernetes的一些理念：用户不需要关心需要多少台机器，只需要关心软件（服务）运行所需的环境。以服务为中心，你需要关心的是api，如何把大服务拆分成小服务，如何使用api去整合它们。保证系统总是按照用户指定的状态去运行。不仅仅提给你供容器服务，同样提供一种软件系统升级的方式；在保持HA的前提下去升级系统是很多用户最想要的功能，也是最难实现的。那些需要担心和不需要担心的事情。更好的支持微服务理念，划分、细分服务之间的边界，比如lablel、pod等概念的引入。对于Kubernetes的架构，可以参考官方文档。大致由一些主要组件构成，包括Master节点上的kube-apiserver、kube-scheler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy，以及底层的网络支持（可以用Flannel、OpenVSwitch、Weave等）。看上去也是微服务的架构设计，不过目前还不能很好支持单个服务的横向伸缩，但这个会在Kubernetes的未来版本中解决。2.Kubernetes的主要特性会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性->由于时间有限，只能简单一些了。另外，对于服务发现、高可用和监控的一些更详细的介绍，感兴趣的朋友可以通过这篇文章了解。1）网络Kubernetes的网络方式主要解决以下几个问题：a.紧耦合的容器之间通信，通过Pod和localhost访问解决。b.Pod之间通信，建立通信子网，比如隧道、路由，Flannel、OpenvSwitch、Weave。c.Pod和Service，以及外部系统和Service的通信，引入Service解决。Kubernetes的网络会给每个Pod分配一个IP地址，不需要在Pod之间建立链接，也基本不需要去处理容器和主机之间的端口映射。注意：Pod重建后，IP会被重新分配，所以内网通信不要依赖PodIP；通过Service环境变量或者DNS解决。2）服务发现及负载均衡kube-proxy和DNS，在v1之前，Service含有字段portalip和publicIPs，分别指定了服务的虚拟ip和服务的出口机ip，publicIPs可任意指定成集群中任意包含kube-proxy的节点，可多个。portalIp通过NAT的方式跳转到container的内网地址。在v1版本中，publicIPS被约定废除，标记为deprecatedPublicIPs，仅用作向后兼容，portalIp也改为ClusterIp,而在serviceport定义列表里，增加了nodePort项，即对应node上映射的服务端口。DNS服务以addon的方式，需要安装skydns和kube2dns。kube2dns会通过读取KubernetesAPI获取服务的clusterIP和port信息，同时以watch的方式检查service的变动，及时收集变动信息，并将对于的ip信息提交给etcd存档，而skydns通过etcd内的DNS记录信息，开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain,"tenx.domain"是提前设置的主域名。注意：kube-proxy在集群规模较大以后，可能会有访问的性能问题，可以考虑用其他方式替换，比如HAProxy，直接导流到Service的endpints或者Pods上。Kubernetes官方也在修复这个问题。3）资源管理有3个层次的资源限制方式，分别在Container、Pod、Namespace层次。Container层次主要利用容器本身的支持，比如Docker对CPU、内存、磁盘、网络等的支持；Pod方面可以限制系统内创建Pod的资源范围，比如最大或者最小的CPU、memory需求；Namespace层次就是对用户级别的资源限额了，包括CPU、内存，还可以限定Pod、rc、service的数量。资源管理模型－》简单、通用、准确，并可扩展目前的资源分配计算也相对简单，没有什么资源抢占之类的强大功能，通过每个节点上的资源总量、以及已经使用的各种资源加权和，来计算某个Pod优先非配到哪些节点，还没有加入对节点实际可用资源的评估，需要自己的schelerplugin来支持。其实kubelet已经可以拿到节点的资源，只要进行收集计算即可，相信Kubernetes的后续版本会有支持。4）高可用主要是指Master节点的HA方式官方推荐利用etcd实现master选举，从多个Master中得到一个kube-apiserver保证至少有一个master可用，实现highavailability。对外以loadbalancer的方式提供入口。这种方式可以用作ha，但仍未成熟，据了解，未来会更新升级ha的功能。一张图帮助大家理解：也就是在etcd集群背景下，存在多个kube-apiserver，并用pod-master保证仅是主master可用。同时kube-sheller和kube-controller-manager也存在多个，而且伴随着kube-apiserver同一时间只能有一套运行。5）rollingupgradeRC在开始的设计就是让rollingupgrade变的更容易，通过一个一个替换Pod来更新service，实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc，并逐步减少老的rc的复本、增加新的rc的复本，在老的rc数量为0时将其删除。通过kubectl提供，可以指定更新的镜像、替换pod的时间间隔，也可以rollback当前正在执行的upgrade操作。同样，Kuberntes也支持多版本同时部署，并通过lable来进行区分，在service不变的情况下，调整支撑服务的Pod，测试、监控新Pod的工作情况。6）存储大家都知道容器本身一般不会对数据进行持久化处理，在Kubernetes中，容器异常退出，kubelet也只是简单的基于原有镜像重启一个新的容器。另外，如果我们在同一个Pod中运行多个容器，经常会需要在这些容器之间进行共享一些数据。Kuberenetes的Volume就是主要来解决上面两个基础问题的。Docker也有Volume的概念，但是相对简单，而且目前的支持很有限，Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念：Volume只是一个目录，并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样，后端用什么介质和里面的内容则由使用的特定Volume类型决定。创建一个带Volume的Pod：spec.volumes指定这个Pod需要的volume信息spec.containers.volumeMounts指定哪些container需要用到这个VolumeKubernetes对Volume的支持非常广泛，有很多贡献者为其添加不同的存储支持，也反映出Kubernetes社区的活跃程度。emptyDir随Pod删除，适用于临时存储、灾难恢复、共享运行时数据，支持RAM-backedfilesystemhostPath类似于Docker的本地Volume用于访问一些本地资源（比如本地Docker）。gcePersistentDiskGCEdisk-只有在GoogleCloudEngine平台上可用。awsElasticBlockStore类似于GCEdisk节点必须是AWSEC2的实例nfs-支持网络文件系统。rbd-RadosBlockDevice-Cephsecret用来通过KubernetesAPI向Pod传递敏感信息，使用tmpfs（aRAM-backedfilesystem）persistentVolumeClaim-从抽象的PV中申请资源，而无需关心存储的提供方glusterfsiscsigitRepo根据自己的需求选择合适的存储类型，反正支持的够多，总用一款适合的:)7）安全一些主要原则：基础设施模块应该通过APIserver交换数据、修改系统状态，而且只有APIserver可以访问后端存储（etcd）。把用户分为不同的角色：Developers/ProjectAdmins/Administrators。允许Developers定义secrets对象，并在pod启动时关联到相关容器。以secret为例，如果kubelet要去pull私有镜像，那么Kubernetes支持以下方式：通过dockerlogin生成.dockercfg文件，进行全局授权。通过在每个namespace上创建用户的secret对象，在创建Pod时指定imagePullSecrets属性（也可以统一设置在serviceAcouunt上），进行授权。认证（Authentication）APIserver支持证书、token、和基本信息三种认证方式。授权（Authorization）通过apiserver的安全端口，authorization会应用到所有http的请求上AlwaysDeny、AlwaysAllow、ABAC三种模式，其他需求可以自己实现Authorizer接口。8）监控比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的containermetrics抓取出来。在较新的版本里，cadvior功能被集成到了kubelet组件中，kubelet在与docker交互的同时，对外提供监控服务。Kubernetes集群范围内的监控主要由kubelet、heapster和storagebackend（如influxdb）构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里，也可以单独运行以standalone的方式。注意：heapster目前未到1.0版本，对于小规模的集群监控比较方便。但对于较大规模的集群，heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息，信息在内存的临时存储成为问题，再加上heaspter要支持api获取临时metrics，如果将heapster以pod方式运行，很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。
Ⅶ exec...的docker中的EXEC
我们在应用容器的过程中，无论是在通过Dockerfile在调试构建镜像的过程，还是容器运行一段时间想查看内部结构，我们还是希望能像操作本地机器一样，实时的查看容器内部文件，代码或者日志。或是修改文件，拷贝文件目录等等。
- 访问容器内部，目前有两种方法
1. Docker自带的exec命令2. Nsenter工具- 来说说Docker exec 命令方式访问
- 如图所示，简单的ls命令。Linux系统自带的命令都可以通过这种方式运行。文件放错位置了，mv一下，查看log，就cat log.log一下，等等。
Exec加点料
- 简单的操作不能满足我们对他的好奇...- 我们运行一下 docker exec -ti 61f ps -ef
- 发现只有3个进程，进程1是CMD命令启动的脚本;进程2是脚本启动的程序;进程3是我们运行ps -ef的进程。- 出于好奇，我又docker exec 9fe0 kill 15
- 容器从此就停止了...- 原因是杀掉进程后，Dockerfile指定的CMD[/run.sh]脚本运行结束，CMD入口已经退出，导致容器退出。
问题还没结束
- Kubernetes是一个基于docker的容器集群管理系统，它的一大特点是拥有Replication Controllers，他的作用主要是保持所起动的Pod数量不变（pod里面装的是container）。我猜想如果类似的kill掉容器内部的进程，那么kubernetes应该会让这个container重新启动。于是就来动手试试。- 时速云他们应用了kubernetes，并且提供了客户端tce可以使用exec功能。运行 tce exec bbb-145fv-zkdqz ps -ef
- tce exec bbb-145fv-zkdqz kill 15
没有重启？？
- 再次运行 tce exec bbb-145fv-zkdqz ps -ef
- 又出现了。- 由此可见Kubernentes的Replication Controllers还是很强大的。保证了集群中有指定数量的pod副本在运行。
Ⅷ 怎么hack kubernetes的pod的启动停止
从 Docker 层面有一个可能的思路是在 Dockerfile 指定 ENTRYPOINT 为一个脚本文件，然后在脚本文件里加上特定信号的捕捉器，在捕捉器里面处理 Pod 退出时的逻辑。 例如这个入口脚本就用了类似的功能。 function shutdown { -> 退出时的清理工作... } trap shutdown SIGTERM SIGINT #注册信号捕捉器 不确定 Kubernetes 关闭 Pod 时候，容器的入口程序会不会收到特定的信号。 只是想到这么个点子，提供一个思路，没有实际测试过，不一定可行。