Написали многоуровневое меню при помощи функций, работает без проблем все, кроме выхода.
Примерно на 2-3 уровне меню "Exit" не выходит из скрипта, а возвращается на уровень выше.
clear; ./1_1_ipmi_menu.sh ; unem ;;exit внутри скрипта 1_1_ipmi_menu.sh приведёт в возврату в unem, вы же тут отдельный процесс создаёте.exit в функциях приводил к выходу из приложения нужно импортировать (source) функции из этих скриптов и вызывать функции вместо запуска скриптов.#!/bin/bash
unem() {
read b
case $b in
1) clear ; … ; unem ;;
2) clear; PMI ; unem ;;
3) clear ; menu ;;
0) exit 0 ;;
esac
}
source 1_1_ipmi_menu.sh
source 1_1_system_menu.sh
unemasm volatile ("int3"); и это тоже вызовет доставку сигнала, останов и трассировку последующих вызовов write.
-bash: nohub: command not found,
nohup, сокращение от no hangup.
make mario.c
mario.c, но собирать ведь надо не его, mario.c -- это исходник. Пиши make mario чтобы собрать mario из mario.c. И да, это работает без Makefile за счёт втроенных в make правил только для таких простых случаев. Для более сложных надо будет писать Makefile.
обработчик динамически ищет и выполняет функцию
при этапе компоновки и линковки ml.exe /c /coff program.asm
link.exe /subsystem:windows program.obj выдаёт ошибку - This program cannot be run in DOS mode.
call GetWindowReact
…
call GetWindowsDC
GetWindowRect и GetWindowDC.сделать так чтобы изображение окружности было вписано в квадрат
изменения в файле "C" нужно вернуть к изначальному состоянию
Как это сделать?
git checkout HEAD~1 "C"git commit или git commit --amend, в зависимости от того, нужно ли закоммитить отмену изменений С отдельно или убрать изменения С из предыдущего коммита.
Может ли прерывание прервать выполнение конструктора / деструктора в С++?
нужно ли в конструкторах / деструкторах защищать код критическими секциями?
Попробовал git rebase -i HEAD~5
но если в открывшемся списке напротив "коммит 4" ставлю флаг "s"
то у меня объединяются почему-то "фикс 4-го коммита" и "коммит 1"
squash объединяет коммит на котором он стоит с предыдущим в этом списке.
в чем ее суть
как с ней бороться
if(rank == 0){
for(size_t i = 1; i < size; i++){size частей, и скорректировать для size - 1.
Почему компилятор не генерирует конструктор
Почему можно не указывать virtual в файле реализации?
Почему виснет программа на MPI?
if(rank == 0){
for(int i = 0; i < VEC_SIZE; i++){
…
}
for (int i = 1; i < size; ++i) {
int q = -1;
MPI_Send(&q, 1, MPI_INT, i, 0, MPI_COMM_WORLD);
}
}else{
for (;;) {
int index;
MPI_Status status;
MPI_Recv(&index, 1, MPI_INT, 0, 0, MPI_COMM_WORLD, &status);
if (index < 0)
break;
…
}
};for(size_t i = 0; i < VEC_SIZE; i++){ size_t num_process = (i % (size - 1)) + 1; MPI_Send(&i, 1, MPI_INT, static_cast<int>(num_process), 0, MPI_COMM_WORLD);
size_t i может отличаться от размера int, подразумеваемого типом MPI_INT. Этот код точно будет работать неправильно на big-endian архитектурах с LP64 ABI.
Как увеличить FPS в системе?
Основной способ стандартный -- не перерисовывать всё, если можно этого избежать.
VIDEO_BUFFER_SEGMENT = 0xA000
VIDEO_BUFFER_OFFSET = 0xFA00
VIDEO_SEGMENT = 0xA000
VIDEO_OFFSET = 0x0000
diff --git a/lib/video.inc b/lib/video.inc
index 3a26f43e2f79..d7054e194da9 100644
--- a/lib/video.inc
+++ b/lib/video.inc
@@ -3,8 +3,8 @@ VIDEO_INC equ 0
include "memory.inc"
-VIDEO_BUFFER_SEGMENT = 0xA000
-VIDEO_BUFFER_OFFSET = 0xFA00
+VIDEO_BUFFER_SEGMENT = 0x6000
+VIDEO_BUFFER_OFFSET = 0x0000
VIDEO_SEGMENT = 0xA000
VIDEO_OFFSET = 0x0000
VIDEO_SIZE_DB = 0xFA00
@@ -79,11 +79,11 @@ macro video!flip {
mov ax, VIDEO_SEGMENT
mov bx, VIDEO_BUFFER_SEGMENT
mov es, ax
- mov ds, ax
+ mov ds, bx
mov cx, VIDEO_SIZE_DB
cld
mov si, VIDEO_BUFFER_OFFSET
- xor di, VIDEO_OFFSET
+ mov di, VIDEO_OFFSET
rep movsb
pop ds es
}
diff --git a/os.asm b/os.asm
index 1949e95b4e99..e5ebb3d280aa 100644
--- a/os.asm
+++ b/os.asm
@@ -91,9 +91,9 @@ kernel.routine.startup:
kernel.routine.video:
cli
video!fill 0x4E
- ;video!window 30, 40, 100, 60, 0x1A, 0xFF, 13 , 0x1F
- ;video!cursor
- ;video!flip
+ video!window 30, 40, 100, 60, 0x1A, 0xFF, 13 , 0x1F
+ video!cursor
+ video!flip
sti
retmov al, [bp+12] mov bl, al mov cl, 3 shl al, cl sbb dh, dh cbw mov dl, [bp+8] mov al, [bp+10]
kernel.routine.mouse.init:
push es bx
int 0x11
test ax, 4
jz kernel.routine.mouse.init.error
mov ax, 0xC205
mov bh, 3
int 0x15
jc kernel.routine.mouse.init.error
mov ax, 0xC203
mov bh, MOUSE_RESOLUTION
int 0x15
jc kernel.routine.mouse.init.errorНе работает деструктор
что я делаю не так?
strlen(source) байт для вывода, а потом находишь compSize, который может быть и больше чем strlen(source). Ты не возвращаешь compSize после вызова compress, а он может измениться. Ты возвращаешь только char*, как будто это строка, но это не строка, там могут быть нулевые байты.uncompress_char почти те же самые ошибки. Плюс какая-то путаница между length, compSize и ucompSize. На вход uncompress в параметре compSize должен попасть настоящий размер сжатых данных, а не догадка о нём на основе вызова compressBound.char* compress_char(const char* source, size_t *outCompSize, size_t *outUcompSize)
{
uLong ucompSize = strlen(source) + 1;
uLong compSize = compressBound(ucompSize);
char* bytes = malloc(compSize);
compress((Bytef *)bytes, &compSize, (Bytef *)source, ucompSize);
*outCompSize = compSize;
*outUcompSize = ucompSize;
return bytes;
}
char* uncompress_char(const unsigned char source[], size_t inCompSize, size_t inUcompSize)
{
uLong ucompSize = inUcompSize;
uLong compSize = inCompSize;
char* message = malloc(ucompSize);
uncompress((Bytef *)message, &ucompSize, (Bytef *)source, compSize);
return message;
}
void foo(void)
{
size_t a, b;
char *p = compress_char("{\"a2\":\"b\"}", &a, &b);
char *p1 = uncompress_char(p, a, b);
printf("%s, %zd -> %zd\n", p1, b, a);
}compress/uncompress.