spf-dev — SPF developers

Re: [Spf-dev] ARM+spf4 есть?

[ivanov <iv...@ic...>]

Большое спасибо, за наводки и ссылки.
Дело сдвинулось с мертвой точки.
Из-за необходимости многопоточности пришлось перейти на gforth 0.7.9. 
В распространенной версии (0.7.2) предлагается только внутренняя
реализация корпоративной мультизадачности. Она работает, но мне не
подошла, так как нужно запускать фоновый процесс и продолжать кнопить в
основном интерпретаторе. В 0.7.9 есть возможность использовать
системную либу pthread, вот на ее основе и определил TASK:, START,
 STOP  и прочие слова, что используются в моей программе.
Recognizers API позволил реализовать NOTFOUND. 
Создалось впечатление чего-то неуклюжего и тяжеловестного. Не
понравилась необходимость создавать пустой RECTYPE (так как вся
обработка "неправильного" слова делается у меня внутри соответствующего
NOTFOUND) и слежение за RECTYPE-NULL. Либо я не проникся этим API,
"либо одно из двух". 
Возможно Resolver API лучше, но я не смог разобраться, так как не
получилось его прикрутить его к gforth и потыкать.
REQUIRE переделал на манер spf.
Сначала попытался использовать стандартный подход, но моя прога вдруг
стала компилировать соседний проект, ссылка на который присутствует в
путях поиска и где есть файлы с одинаковым названием. Разумеется, можно
было бы разобраться "что, где и как" и выправить ситуацию, но мне нужно
сохранить совместимость с spf и впереди оставалось еще много работы по
переносу... обошелся малой кровью.
Слово VECT  сделать в gforth не получилось.
Слово TO оказалось очень избирательным и отказывалось обслуживать мои
VECTы. Либо я мог сделать слово принимаемым TO, но при этом оно
переставало исполняться. Через неделю бросил попытки и заменил VECT -TO
на DEFER-IS.
Си интерфейс несколько замороченный.
Что бы его использовать потребовалось доустанавливать libtool-bin, дабы
он создавал личные библиотеки функций-оберток на основе декларированных
функций (механически переписал из *.h нужные функции в новой нотации).
Пока прикручивал pthread и libusb, наелся си так, как давно уже не
было. Вышел из квеста с впечатлением, что gforth -  это си окруженный
забором на котором написано FORTH. 
Похоже ANSI forth потихоньку мигрирует к гендерной неопределенности
языка. Возможно это плата за "вездесущность".
OPEN-FILE возвращает странный fileid ( видимо FILE *stream). 
Внутри форта его можно использовать для чтения-записи-закрытия файла,
но нельзя передавать внешним си-функциям (например  tcgetattr из
<termios.h> ), так как они "кушают" только номер файла, который можно
получить fileno(fileid). Spf сразу дает номер файла и о том, что можно
иначе я не подозревал.
Надеюсь, что есть какие-то высшие смыслы, но мне они остались не
понятны (тем более, что сишная open возвращает именно внутренний номер
открытого файла).
Нашел несколько ошибок в своей программе.
Дело в том, что spf иногда может вынуть что-то "из-под прилавка", то
есть извлечь нечто из-под дна стека.
Например:
 Ok
1 over 
 Ok ( 1 3216012460(-1078954836) )
Как оказалось, у меня в нескольких местах (не менее трех) были ошибки,
где я извлекал это "нечто" и радовался, что все работает... 
Gforth ткнул меня носом в такое непотребство, и вот за это ему спасибо.
В общем приключений мне хватило, но и опыта прибавило, стряхнуло пыль с
мозгов (чуть не вывихнув).
На текущий момент удалось добиться полной (насколько смог
протестировать) функциональности моей проги в среде gforth, но на
десктопе.
Сейчас начну громоздить все это на Raspberry Pi, там наверняка будут
свои "грабли".
--
iva
В Ср, 12/12/2018 в 14:03 +0300, Ruvim Pinka пишет:
> Лучше бы конечно использовать текущую версию Gforth, — в Ubuntu она
> собирается без проблем.
> В текущей версии есть не только quotations, но и Recognizers API —
> который позволяет добавить обработу литералов или т.п. или даже
> реализовать интерфейс NOTFOUND.
> 
> Вообще, интерфейс NOTFOUND в SPF/4 "грязный" (в смысле негигееничный,
> как  "unhygienic macros", see "Hygienic macro") — слово "NOTFOUND"
> там зарезервированно, и если кто-то добавит произвольное слово с
> таким именем, то поиск сломается.
> Интерфейс-обертка enqueueNOTFOUND позволяет изменить реализацию на
> гигееничную, не трогая код, который использует этот интерфейс.
> 
> Касательно Recognizers API — у меня к нему ряд существенных
> претензий, поэтому я предложил альтернативу —Resolver API

> Еще, стоит взять на заметку, что слово > REQUIRE>  теперь входит в стандарт и отличается семантикой от > REQUIRE>  в SPF/4. Поэтому, в портабельном коде придется отказаться от этого имени, и, например, определить > REQUIRE-WORD>  (как синоним в SPF/4 и полную реализацию в случае другой форт-системы).> > > Видимо, в следующей мажорной версии SPF надо будет 
>  версии SPF надо будет 
> убрать механизм NOTFOUND (в пользу нового API) и REQUIRE старой семантики (в пользу новой стандартной семантики).> 
>  
> --
> Ruvim


> _______________________________________________
> Spf-dev mailing list
> 
Sp...@li...> 
https://lists.sourceforge.net/lists/listinfo/spf-dev> 

Re: [Spf-dev] ARM+spf4 есть?

[Ruvim P. <ruv...@gm...>]

On Wed, 12 Dec 2018 at 10:55, ivanov <iv...@ic...> wrote:

> Благодарю за подробный ответ.
> С INCLUDE я помирился, не догадался проанализировать его поведение так
> глубоко, до colon-sys.
>
> Отдельное спасибо за quotations, это именно то, что я пытался изобрести.
> Оказывается не мне первому это потребовалось.
> К сожалению версия gforth актуальная на данный момент в ubuntu и raspbian
> (Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.) не
> поддерживает quotations. Возможно попробую прикрутить  LAMBDA{ ... }
> <https://github.com/rufig/spf/blob/master/devel/~pinka/lib/lambda.f>, но
> уже в новой нотации, пока это не первоочередная задача.
>

Сейчас пытаюсь прикрутить NOTFOUND к gforth (или найти его аналоги) для
> дополнительной обработки "неизвестных" слов.
>

Лучше бы конечно использовать текущую версию Gforth
<https://github.com/forthy42/gforth/>, — в Ubuntu она собирается без
проблем.
В текущей версии есть не только quotations, но и Recognizers API
<http://amforth.sourceforge.net/pr/Recognizer-rfc-D.html> — который
позволяет добавить обработу литералов или т.п. или даже реализовать
интерфейс NOTFOUND.

Вообще, интерфейс NOTFOUND в SPF/4 "грязный" (в смысле негигееничный, как
"unhygienic macros", see "Hygienic macro
<https://en.wikipedia.org/wiki/Hygienic_macro>") — слово "NOTFOUND" там
зарезервированно, и если кто-то добавит произвольное слово с таким именем,
то поиск сломается.
Интерфейс-обертка enqueueNOTFOUND
<https://github.com/rufig/spf/blob/master/devel/~pinka/samples/2006/core/trans/nf-ext.f>
позволяет изменить реализацию на гигееничную, не трогая код, который
использует этот интерфейс.

Касательно Recognizers API — у меня к нему ряд существенных претензий,
поэтому я предложил альтернативу — Resolver API
<https://github.com/ruv/forth-design-exp/blob/master/docs/resolver-api.md>

Еще, стоит взять на заметку, что слово REQUIRE
<https://forth-standard.org/standard/file/REQUIRE> теперь входит в стандарт
и отличается семантикой от REQUIRE в SPF/4. Поэтому, в портабельном коде
придется отказаться от этого имени, и, например, определить REQUIRE-WORD
(как синоним в SPF/4 и полную реализацию в случае другой форт-системы).


Видимо, в следующей *мажорной* версии SPF надо будет убрать механизм
NOTFOUND (в пользу нового API) и REQUIRE старой семантики (в пользу новой
стандартной семантики).


--
Ruvim

Re: [Spf-dev] ARM+spf4 есть?

[ivanov <iv...@ic...>]

Благодарю за подробный ответ.
С INCLUDE я помирился, не догадался проанализировать его поведение так
глубоко, до colon-sys.
Отдельное спасибо за quotations, это именно то, что я пытался
изобрести. Оказывается не мне первому это потребовалось.
К сожалению версия gforth актуальная на данный момент в ubuntu и
raspbian (Gforth 0.7.2, Copyright (C) 1995-2008 Free Software
Foundation, Inc.) не поддерживает quotations. Возможно попробую
прикрутить  LAMBDA{ ... }, но уже в новой нотации, пока это не
первоочередная задача.
Сейчас пытаюсь прикрутить NOTFOUND к gforth (или найти его аналоги) для
дополнительной обработки "неизвестных" слов.
--
iva
В Вс, 09/12/2018 в 15:02 +0300, Ruvim Pinka пишет:
> 
> 
> On Sun, 9 Dec 2018 at 12:25, ivanov <iv...@ic...> wrote:
> > Первая трудность с которой столкнулся, обработка пути к
> > подключаемым файлам. В spf путь начинающийся с "~" отправляет в
> > devel, в gforth, это естественно не так. Вставил исправляющую
> > "прокладку" между gforth и моей программой.
> > 
> Переоределить слова INCLUDE* 
>  
> > Вторая, поведение LITERAL. В gforth оно работает только если
> > значение появляется на стеке внутри определения:
> > variable aa
> > : bb [ aa  ] LITERAL  ;
> > а если так:
> > aa  : bb LITERAL ;  выдает ошибку "unstructured".
> > В spf  оба случая работают одинаково. В стандарте нет уточнения на
> > этот счет, так что формально оба поведения "стандартны".
> > 
> Второй вариант нестандартный. См. спецификацию слова ":" https://fort
> h-standard.org/standard/core/Colon
> ( C: "<spaces>name" -- colon-sys ) 
> Т.е. на управляющем стеке (control-flow stack) остается colon-sys
> произвольного размера. А управляющий стек может быть совмещен со
> стеком данных.
> В SPF просто размер colon-sys нулевой, поэтому работает второй
> вариант. Но, в случае :NONAME  уже не работает, т.к. размер colon-sys 
> там ненулевой.
> 
> 
> Тут несколько вариантов решения. 
> 
> 1) добавить свой отдельный стек управления и переопределить
> соответствующие слова типа
> : : ['] : EXECUTE-BALANCE N>Z ;
> : ; NZ> DROP POSTPONE ; [ NZ> DROP ] ; IMMEDIATE
> 
> (и код оставить нестандартным)
> 
> 2) использовать переменные или доп-стек, например
> aa >Z : bb [ Z> ] LITERAL ;
> 
> 3) использовать свои определяющие слова (прозрачные по стеку данных)
> Например:
> `bb def{ lit{ aa } }
> 
> Я делал подобное для noname
> 
> 
> 
> > Третье.
> > У меня определено много слов так сказать "двойного назначения" или
> > "прыгающие".
> > Выглядят они примерно так:
> > : qq body1  up> body2 ; 
> > При исполнении слова qq выполняется часть body1, а потом, в нужное
> > время и в нужном месте исполняется вторая часть body2.
> > С помощью этого нехитрого трюка мои слова могут "перепрыгивать"
> > через свои параметры. Body1 готовит для них почву, что бы они могли
> > спокойно появиться, а body2 их употребляет для своих нужд,
> > доделывая работу.
> > 
> > Слово up> как раз и занимается этим выкрутасом.
> > В spf это выглядит элегантно  : up>  R>  aa  !  ;  Подпрограммный
> > шитый код рулит.
> > 
> > В gforth - ругань нецензурными словами.
> > 
> Логично, такое определение "up>" сильно зависит от реализации.
> 
>  
> > Сначала сделал так:
> > :NONAME body2 ;
> > : qq body1 LITERAL aa ! ; - столкнулся с привередливостью
> > LITERAL...
> > 
> > Ввел доп. переменную специально для передачи параметра, получилось:
> > :NONAME body2 ; xx !
> > : qq body1 [ xx @ ] LITERAL aa ! ;
> > Это заработало, но потребовало переопределить всю кучу моих слов,
> > явно разорвать их на две части. 
> > Выполнимо, но некрасиво.
> > 
> > Сейчас использую вот такой хак:
> > :NONAME ; DUP @  CONSTANT nonam1  CELL+ @ CONSTANT nonam2
> > : qq body1 up> [ noman1 ,  nonam2 ,   ]  body2 ;
> > То есть вставляю перед body2 начальный кусок от :NONAME.
> > То, что это работает, объясняю тем, что видимо в gforth использован
> > прямой или косвенный шитый код и в этом куске есть что-то нужное
> > адресному интерпретатору.
> > Выглядит грязновато, но зато в моем коде ничего менять не нужно
> > (довставку делаю макросом, а его определяю в "прокладке").
> > 
> 
> Для этого лучше использовать quotations (цитаты), которые нетрудно
> реализовать в любой форт-системе. 
> В SPF они доступны в виде LAMBDA{ ... }. На встрече Forth200x в 2017
> был принят синтаксис [: ;]
> > : qq body1  [: body2 ;] aa ! ;

> : up{  postpone [: ; immediate
> : }up  postpone ;] postpone aa postpone ! ; immediate

> 
> 
> : qq body1 up{ body2 }up ;
> > 
> 
> 

> Если переопределить ";" (чтобы проверяло флаг и опционально делало ";] aa !" ) то можно и сделать в виде "> up>> "> > > > Так что, грабли я нашел задолго до многопоточности, с которой пободаюсь чуть позже. 
> > Сейчас разбираюсь как вызывать С-функции, как их декларировать и оборачивать.
> > Это тоже по разному делается в SP-Forth и в Gforth. Последний умеет подключать сишный *.h файлы. См. C Interface> >  
> > > > Мысля переписать ядро spf для ARM меня посетила... посидела и ушла.
> > Прежде чем этим заняться, решил узнать, а правда ли я первый, кому это потребовалось.
> > Видимо правда... 
> > Андрей Черезов делал форт-систему под ARM, но это был встраиваемый вариант (без операционной системы) и вроде как несовместимый с SP-Forth/4
> >  
> > Что-ж, если плотно сяду на arm, придется этим заняться... самоуверенности (или наглости?) мне не занимать.
> > 
> > Когда я об этом думал, то представлял использовать какой-то существующий ассемблер и линкер. Т.е. ассемблером сгенерить объектный файл с низкоуровневыми определениями, из форт-системы сгенерить объектный файл с определениями на форте (подпрограммый код), и слинковать их линкером. > > > --
> Ruvim
> 

> _______________________________________________
> Spf-dev mailing list
> 
Sp...@li...> 
https://lists.sourceforge.net/lists/listinfo/spf-dev> 

Re: [Spf-dev] ARM+spf4 есть?

[Ruvim P. <ruv...@gm...>]

On Sun, 9 Dec 2018 at 12:25, ivanov <iv...@ic...> wrote:

> Первая трудность с которой столкнулся, обработка пути к подключаемым
> файлам. В spf путь начинающийся с "~" отправляет в devel, в gforth, это
> естественно не так. Вставил исправляющую "прокладку" между gforth и моей
> программой.
>

Переоределить слова INCLUDE*


> Вторая, поведение LITERAL. В gforth оно работает только если значение
> появляется на стеке внутри определения:
> variable aa
> : bb [ aa  ] LITERAL  ;
> а если так:
> aa  : bb LITERAL ;  выдает ошибку "unstructured".
> В spf  оба случая работают одинаково. В стандарте нет уточнения на этот
> счет, так что формально оба поведения "стандартны".
>

Второй вариант нестандартный. См. спецификацию слова ":"
https://forth-standard.org/standard/core/Colon
( C: *"<spaces>name"* -- *colon-sys* )
Т.е. на управляющем стеке (control-flow stack) остается colon-sys
произвольного размера. А управляющий стек может быть совмещен со стеком
данных.
В SPF просто размер colon-sys нулевой, поэтому работает второй вариант. Но,
в случае :NONAME  уже не работает, т.к. размер colon-sys там ненулевой.


Тут несколько вариантов решения.

1) добавить свой отдельный стек управления и переопределить соответствующие
слова типа
: : ['] : EXECUTE-BALANCE
<https://github.com/ruv/forth-design-exp/blob/master/lexeme-translator/lib/stack-effect.fth>
N>Z ;
: ; NZ> DROP POSTPONE ; [ NZ> DROP ] ; IMMEDIATE

(и код оставить нестандартным)

2) использовать переменные или доп-стек, например
aa >Z : bb [ Z> ] LITERAL ;

3) использовать свои определяющие слова (прозрачные по стеку данных)
Например:
`bb def{ lit{ aa } }

Я делал подобное
<https://github.com/ruv/forth-design-exp/blob/master/lexeme-translator/advanced.example.fth>
для noname



Третье.
> У меня определено много слов так сказать "двойного назначения" или
> "прыгающие".
> Выглядят они примерно так:
> : qq body1  up> body2 ;
> При исполнении слова qq выполняется часть body1, а потом, в нужное время и
> в нужном месте исполняется вторая часть body2.
> С помощью этого нехитрого трюка мои слова могут "перепрыгивать" через свои
> параметры. Body1 готовит для них почву, что бы они могли спокойно
> появиться, а body2 их употребляет для своих нужд, доделывая работу.
>
> Слово up> как раз и занимается этим выкрутасом.
> В spf это выглядит элегантно  : up>  R>  aa  !  ;  Подпрограммный шитый
> код рулит.
>
> В gforth - ругань нецензурными словами.
>

Логично, такое определение "up>" сильно зависит от реализации.



> Сначала сделал так:
> :NONAME body2 ;
> : qq body1 LITERAL aa ! ; - столкнулся с привередливостью LITERAL...
>
> Ввел доп. переменную специально для передачи параметра, получилось:
> :NONAME body2 ; xx !
> : qq body1 [ xx @ ] LITERAL aa ! ;
> Это заработало, но потребовало переопределить всю кучу моих слов, явно
> разорвать их на две части.
> Выполнимо, но некрасиво.
>
> Сейчас использую вот такой хак:
> :NONAME ; DUP @  CONSTANT nonam1  CELL+ @ CONSTANT nonam2
> : qq body1 up> [ noman1 ,  nonam2 ,   ]  body2 ;
> То есть вставляю перед body2 начальный кусок от :NONAME.
> То, что это работает, объясняю тем, что видимо в gforth использован прямой
> или косвенный шитый код и в этом куске есть что-то нужное адресному
> интерпретатору.
> Выглядит грязновато, но зато в моем коде ничего менять не нужно (довставку
> делаю макросом, а его определяю в "прокладке").
>


Для этого лучше использовать quotations (цитаты), которые нетрудно
реализовать в любой форт-системе.
В SPF они доступны в виде LAMBDA{ ... }
<https://github.com/rufig/spf/blob/master/devel/~pinka/lib/lambda.f> . На
встрече Forth200x <http://www.forth200x.org/> в 2017 был принят синтаксис [:
;]

: qq body1  [: body2 ;] aa ! ;


: up{  postpone [: ; immediate
: }up  postpone ;] postpone aa postpone ! ; immediate

: qq body1 up{ body2 }up ;

Если переопределить ";" (чтобы проверяло флаг и опционально делало ";] aa
!" ) то можно и сделать в виде "up>"


Так что, грабли я нашел задолго до многопоточности, с которой пободаюсь
> чуть позже.
> Сейчас разбираюсь как вызывать С-функции, как их декларировать и
> оборачивать.
>

Это тоже по разному делается в SP-Forth и в Gforth. Последний умеет
подключать сишный *.h файлы. См. C Interface
<https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/C-Interface.html>



>
> Мысля переписать ядро spf для ARM меня посетила... посидела и ушла.
> Прежде чем этим заняться, решил узнать, а правда ли я первый, кому это
> потребовалось.
> Видимо правда...
>

Андрей Черезов делал форт-систему под ARM, но это был встраиваемый вариант
(без операционной системы) и вроде как несовместимый с SP-Forth/4



> Что-ж, если плотно сяду на arm, придется этим заняться... самоуверенности
> (или наглости?) мне не занимать.
>
>
Когда я об этом думал, то представлял использовать какой-то существующий
ассемблер и линкер. Т.е. ассемблером сгенерить объектный файл с
низкоуровневыми определениями, из форт-системы сгенерить объектный файл с
определениями на форте (подпрограммый код), и слинковать их линкером.


--
Ruvim

Re: [Spf-dev] ARM+spf4 есть?

[ivanov <iv...@ic...>]

Первая трудность с которой столкнулся, обработка пути к подключаемым
файлам. В spf путь начинающийся с "~" отправляет в devel, в gforth, это
естественно не так. Вставил исправляющую "прокладку" между gforth и
моей программой.
Вторая, поведение LITERAL. В gforth оно работает только если значение
появляется на стеке внутри определения:
variable aa
: bb [ aa  ] LITERAL  ;
а если так:
aa  : bb LITERAL ;  выдает ошибку "unstructured".
В spf  оба случая работают одинаково. В стандарте нет уточнения на этот
счет, так что формально оба поведения "стандартны".
Третье.
У меня определено много слов так сказать "двойного назначения" или
"прыгающие".
Выглядят они примерно так:
: qq body1  up> body2 ; 
При исполнении слова qq выполняется часть body1, а потом, в нужное
время и в нужном месте исполняется вторая часть body2.
С помощью этого нехитрого трюка мои слова могут "перепрыгивать" через
свои параметры. Body1 готовит для них почву, что бы они могли спокойно
появиться, а body2 их употребляет для своих нужд, доделывая работу.
Слово up> как раз и занимается этим выкрутасом.
В spf это выглядит элегантно  : up>  R>  aa  !  ;  Подпрограммный шитый
код рулит.
В gforth - ругань нецензурными словами.
Сначала сделал так:
:NONAME body2 ;
: qq body1 LITERAL aa ! ; - столкнулся с привередливостью LITERAL...
Ввел доп. переменную специально для передачи параметра, получилось:
:NONAME body2 ; xx !
: qq body1 [ xx @ ] LITERAL aa ! ;
Это заработало, но потребовало переопределить всю кучу моих слов, явно
разорвать их на две части. 
Выполнимо, но некрасиво.
Сейчас использую вот такой хак:
:NONAME ; DUP @  CONSTANT nonam1  CELL+ @ CONSTANT nonam2
: qq body1 up> [ noman1 ,  nonam2 ,   ]  body2 ;
То есть вставляю перед body2 начальный кусок от :NONAME.
То, что это работает, объясняю тем, что видимо в gforth использован
прямой или косвенный шитый код и в этом куске есть что-то нужное
адресному интерпретатору.
Выглядит грязновато, но зато в моем коде ничего менять не нужно
(довставку делаю макросом, а его определяю в "прокладке").
Так что, грабли я нашел задолго до многопоточности, с которой пободаюсь
чуть позже. 
Сейчас разбираюсь как вызывать С-функции, как их декларировать и
оборачивать.
Мысля переписать ядро spf для ARM меня посетила... посидела и ушла.
Прежде чем этим заняться, решил узнать, а правда ли я первый, кому это
потребовалось.
Видимо правда... 
Что-ж, если плотно сяду на arm, придется этим заняться...
самоуверенности (или наглости?) мне не занимать.
--
iva
В Сб, 08/12/2018 в 19:08 +0300, Ruvim Pinka пишет:
> > Часть трудностей получилось преодолеть, но последний взятый рубеж
> > меня
> > несколько расстроил... хоть ЭТО и работает в обоих фортах верно, но
> > само решение мне напоминает "закат солнца вручную".
> Любопытно, что за трудности возникли? Какие фичи SP-Forth трудно
> эмулируются в Gforth?
> 
> На вскидку, — многопоточность только.
>  
> > Идеально было бы перенести мою прогу на ARM вместе с spf, но если
> > не
> > удастся... придется вручную.
> > 
> Для поддержки ARM надо написать ядро SP-Forth/Linux на ассемблере для
> ARM и решить ряд сопутствующих проблем )
> 
> 
> --
> Ruvim
> 
> _______________________________________________
> Spf-dev mailing list
> Sp...@li...
> https://lists.sourceforge.net/lists/listinfo/spf-dev

Re: [Spf-dev] ARM+spf4 есть?

[Ruvim P. <ruv...@gm...>]

On Wed, 5 Dec 2018 at 19:17, ivanov <iv...@ic...> wrote:

> Здравствуйте.
> Потребовалось запустить мою программу на ARM, а точнее на raspberry_pi.
> А там доступен только gforth (и еще несколько ABCD-фортов).
> Компиляция проходит, но сама прога, естественно, не работает.
> Дело в том, что хоть я и старался придерживаться стандарта (для
> портируемости), все равно в нескольких местах воспользовался свойствами
> именно spf.
> Часть трудностей получилось преодолеть, но последний взятый рубеж меня
> несколько расстроил... хоть ЭТО и работает в обоих фортах верно, но
> само решение мне напоминает "закат солнца вручную".
>

Любопытно, что за трудности возникли? Какие фичи SP-Forth трудно
эмулируются в Gforth?

На вскидку, — многопоточность только.


> Идеально было бы перенести мою прогу на ARM вместе с spf, но если не
> удастся... придется вручную.
>

Для поддержки ARM надо написать ядро SP-Forth/Linux на ассемблере для ARM и
решить ряд сопутствующих проблем )


--
Ruvim

[Spf-dev] ARM+spf4 есть?

[ivanov <iv...@ic...>]

Здравствуйте.
Потребовалось запустить мою программу на ARM, а точнее на raspberry_pi.
А там доступен только gforth (и еще несколько ABCD-фортов). 
Компиляция проходит, но сама прога, естественно, не работает.
Дело в том, что хоть я и старался придерживаться стандарта (для
портируемости), все равно в нескольких местах воспользовался свойствами
именно spf.
Часть трудностей получилось преодолеть, но последний взятый рубеж меня
несколько расстроил... хоть ЭТО и работает в обоих фортах верно, но
само решение мне напоминает "закат солнца вручную".

Идеально было бы перенести мою прогу на ARM вместе с spf, но если не
удастся... придется вручную.

Re: [Spf-dev] Создание папок средствами forth?

[Andrey C. <an...@ch...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Re: [Spf-dev] Создание папок средствами forth?</title>
<meta http-equiv="content-type" content="text/html; charset=windows-1251">
</head>
<body>
<p>Да, стандартного варианта не предусмотрено, по крайней мере в ANS94.</p>
<p>Наши самодельные варианты см. в devel\~ac\lib\win\file\utils.f или devel\~pinka\samples\2005\lib\lay-path.f&nbsp;</p>
<hr />
<table>
<tbody>
<tr>
<td colspan="2"><strong>-------- Исходное сообщение --------</strong></td>
</tr>
<tr>
<td>Тема:</td>
<td>[Spf-dev] Создание папок средствами forth?</td>
</tr>
<tr>
<td>Дата:</td>
<td>2018-12-03 20:00:21</td>
</tr>
<tr>
<td>От:</td>
<td><a href="mailto:iv...@ic...">ivanov</a></td>
</tr>
</tbody>
</table>
<p>С некоторым удивлением обнаружил, что не могу создать файл в несуществующей папке.<br /> S" ./hex/foo.f" R/O <a class="forth" href="/CREATE-FILE">CREATE-FILE</a> <a class="forth" href="/THROW">THROW</a><br /> Если папка hex есть в текущей директории, ошибок нет &mdash; это нормально.<br /> Поразмыслив пришел к выводу, что сначала видимо нужно вызывать утилиту<br /> ОС для создания папки (логично, так как файловая система собственность<br /> ОС), а уж потом создавать в ней файл.&nbsp;<br /> Тут проблем, кроме совместимости, нет.<br /> Но остались сомнения: может я чего не знаю или не внимательно читал стандарт? <br /><br /> <span style="text-decoration: underline;">_</span>Spf-dev mailing list<br /> Sp...@li...<br /> <img src="/e4a/web.gif" alt="" border="0" /><a class="outerlink" title="ссылка откроется в новом окне" href="https://lists.sourceforge.net/lists/listinfo/spf-dev" target="_blank">https://lists.sourceforge.net/lists/listinfo/spf-dev</a></p>
</body>
</html>

[Spf-dev] Создание папок средствами forth?

[ivanov <iv...@ic...>]

С некоторым удивлением обнаружил, что не могу создать файл в
несуществующей папке.
S" ./hex/foo.f" R/O CREATE-FILE THROW
Если папка hex есть в текущей директории, ошибок нет - это нормально.
Поразмыслив пришел к выводу, что сначала видимо нужно вызывать утилиту
ОС для создания папки (логично, так как файловая система собственность
ОС), а уж потом создавать в ней файл. 
Тут проблем, кроме совместимости, нет.
Но остались сомнения: может я чего не знаю или не внимательно читал
стандарт?

Re: [Spf-dev] Git repo

[Andrey C. <an...@ch...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Re: [Spf-dev] Git repo</title>
<meta http-equiv="content-type" content="text/html; charset=windows-1251">
</head>
<body>
<p>Да, комментарии к коммитам из cvs в git сконвертировались нормально, несколько замеченных косяков я поправил еще до push.</p>
<p>&gt;&nbsp;<span style="color: #171717;">Про FAR &mdash; это который&nbsp;</span><a style="color: #4483a4; text-decoration-line: none;" href="https://github.com/elfmz/far2l" target="_blank">https://github.com/elfmz/far2l</a><span style="color: #171717;">&nbsp;?</span></p>
<div class="gmail_extra" style="color: #171717;">&gt; А тут кто-нибудь его испытывал?</div>
<div class="gmail_extra" style="color: #171717;">&nbsp;</div>
<div class="gmail_extra" style="color: #171717;">Да, я теперь только в нём под убунтой. Для счастья не хватает только скроллинга консоли (при Ctrl+O).</div>
<div class="gmail_extra" style="color: #171717;">&nbsp;</div>
<hr />
<table>
<tbody>
<tr>
<td colspan="2"><strong>-------- Исходное сообщение --------</strong></td>
</tr>
<tr>
<td>Тема:</td>
<td>Re: [Spf-dev] Git repo</td>
</tr>
<tr>
<td>Дата:</td>
<td>2017-06-28 12:29:39</td>
</tr>
<tr>
<td>От:</td>
<td><a href="mailto:ruv...@gm...">Ruvim Pinka</a></td>
</tr>
</tbody>
</table>
<table class="message" border="1">
<tbody>
<tr>
<td>
<table class="message" border="1">
<tbody>
<tr>
<td>
<table class="message" border="1">
<tbody>
<tr>
<td>
<div dir="ltr">Привет!<br />
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote">2017-06-19 16:30 GMT+03:00 Andrey Cherezov <span dir="ltr">&lt;<a href="mailto:an...@ch..." target="_blank">an...@ch...</a>&gt;</span>:<br />
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div>
<p>Да, история коммитов, конечно, вся сохранена - с 2001 года, когда переехали на <a href="http://sf.net" target="_blank">sf.net</a>. Комментарии к коммитам сконвертированы в utf8, чтобы нормально показываться всеми утилитами git.</p>
<p>Я тоже за то, чтобы перейти с CVS на Git со следующих комитов.</p>
</div>
</blockquote>
<div>я бы предложил вначале выпустить текущую версию, включив туда архив CVS репозитория, и только после этого уже распрощаться с CVS насовсем.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div>
<p>C utf8/cp1251 не всё однозначно. Есть коммиты, где при одной и той же кодировке исходных файлов (cp1251) diff показывается для разных файлов в разной кодировке - для одних читабельно, для других нет. Например, <a href="https://github.com/rufig/spf/commit/3ccf936ae65fdb402d990d39390e6b209ece34de" target="_blank">https://github.com/rufig/spf/commit/3ccf936ae65fdb402d990d39390e6b209ece34de</a> Как ему подсказать, я пока не разобрался. Если кто может сконвертировать лучше - можно будет перейти на его версию repo.</p>
</div>
</blockquote>
<div>Мне кажется, там нет никакого способа подсказать. Видимо, он сам определяет кодировку по тексту в начале файла. Если в начале файла идет много русского, то удается определить верную кодировку, если же русского мало (или нету), то берется дефолтная кодировка.</div>
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div>
<p>Но старые файлы конвертировать в utf8 не хотелось бы - могут быть кириллические литералы, кириллические названия слов где-то были, и т.п.</p>
</div>
</blockquote>
<div>Мне кажется важным читабельность истории.</div>
<div>В принципе, чтобы все были довольны, можно иметь два зеркальных репозитория: один в оригинальных кодировках, другой &mdash; все в utf8. Синхрониировать автоматически, конечно же.</div>
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div>
<p>А для новых предлагаю использовать кому как удобнее.</p>
</div>
</blockquote>
<div>Опять тогда история изменений будет кривая местами.<br />Впрочем, сейчас пишут в репозиторий SP-Forth всего пара человек, и убедить надо только одного из них ;)</div>
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div>
<p>Под Windows давно не проблема работать со смешанными кодировками, FAR всё автоматически определяет, так что разница и не заметна. А так как линуксы и маки традиционо менее гибки, можно подстроиться под них и по умолчанию для новых файлов делать utf8.</p>
</div>
</blockquote>
<div>Да, я давно делаю только utf8.</div>
<div>&nbsp;</div>
</div>
-- <br />
<div class="gmail_signature" data-smartmail="gmail_signature">Ruvim</div>
</div>
</div>
</div>
</div>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td>
<pre class="plain" title="">------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot</pre>
</td>
</tr>
<tr>
<td>
<pre class="plain" title="">_______________________________________________
Spf-dev mailing list
Sp...@li...
https://lists.sourceforge.net/lists/listinfo/spf-dev
</pre>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<p>&nbsp;</p>
<span style="color: #171717; font-family: Trebuchet, Verdana; font-size: 12.96px; background-color: #e3efff;">sp...@li...</span>
</body>
</html>

Re: [Spf-dev] Git repo

[Ruvim P. <ruv...@gm...>]

Про FAR — это который https://github.com/elfmz/far2l ?

А тут кто-нибудь его испытывал?

2017-06-20 2:20 GMT+03:00 Andrey Cherezov <an...@ch...>:

> Пропустил я новость о портировании FAR на Linux/macOS. Теперь и там есть
> нормальный редактор с colorer'ом и поддержкой всех русских кодировок.
>


-- 
Ruvim

Re: [Spf-dev] Git repo

[Ruvim P. <ruv...@gm...>]

Привет!
2017-06-19 16:30 GMT+03:00 Andrey Cherezov <an...@ch...>:

> Да, история коммитов, конечно, вся сохранена - с 2001 года, когда
> переехали на sf.net. Комментарии к коммитам сконвертированы в utf8, чтобы
> нормально показываться всеми утилитами git.
>
> Я тоже за то, чтобы перейти с CVS на Git со следующих комитов.
>
я бы предложил вначале выпустить текущую версию, включив туда архив CVS
репозитория, и только после этого уже распрощаться с CVS насовсем.

C utf8/cp1251 не всё однозначно. Есть коммиты, где при одной и той же
> кодировке исходных файлов (cp1251) diff показывается для разных файлов в
> разной кодировке - для одних читабельно, для других нет. Например,
> https://github.com/rufig/spf/commit/3ccf936ae65fdb402d990d39390e6b
> 209ece34de Как ему подсказать, я пока не разобрался. Если кто может
> сконвертировать лучше - можно будет перейти на его версию repo.
>
Мне кажется, там нет никакого способа подсказать. Видимо, он сам определяет
кодировку по тексту в начале файла. Если в начале файла идет много
русского, то удается определить верную кодировку, если же русского мало
(или нету), то берется дефолтная кодировка.

Но старые файлы конвертировать в utf8 не хотелось бы - могут быть
> кириллические литералы, кириллические названия слов где-то были, и т.п.
>
Мне кажется важным читабельность истории.
В принципе, чтобы все были довольны, можно иметь два зеркальных
репозитория: один в оригинальных кодировках, другой — все в utf8.
Синхрониировать автоматически, конечно же.

А для новых предлагаю использовать кому как удобнее.
>
Опять тогда история изменений будет кривая местами.
Впрочем, сейчас пишут в репозиторий SP-Forth всего пара человек, и убедить
надо только одного из них ;)

Под Windows давно не проблема работать со смешанными кодировками, FAR всё
> автоматически определяет, так что разница и не заметна. А так как линуксы и
> маки традиционо менее гибки, можно подстроиться под них и по умолчанию для
> новых файлов делать utf8.
>
Да, я давно делаю только utf8.


-- 
Ruvim

Re: [Spf-dev] Git repo

[Andrey C. <an...@ch...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Re: [Spf-dev] Git repo</title>
<meta http-equiv="content-type" content="text/html; charset=windows-1251">
</head>
<body>
<p>Пропустил я новость о портировании FAR на Linux/macOS. Теперь и там есть нормальный редактор с colorer'ом и поддержкой всех русских кодировок.</p>
<hr />
<table>
<tbody>
<tr>
<td colspan="2"><strong>-------- Исходное сообщение --------</strong></td>
</tr>
<tr>
<td>Тема:</td>
<td>Re: [Spf-dev] Git repo</td>
</tr>
<tr>
<td>Дата:</td>
<td>2017-06-19 16:32:40</td>
</tr>
<tr>
<td>От:</td>
<td><a href="mailto:an...@ch...">ac</a></td>
</tr>
</tbody>
</table>
<table class="message" border="1">
<tbody>
<tr>
<td>
<table class="message" border="1">
<tbody>
<tr>
<td>
<p>Но старые файлы конвертировать в utf8 не хотелось бы - могут быть кириллические литералы, кириллические названия слов где-то были, и т.п. А для новых предлагаю использовать кому как удобнее. Под Windows давно не проблема работать со смешанными кодировками, FAR всё автоматически определяет, так что разница и не заметна. А так как линуксы и маки традиционо менее гибки, можно подстроиться под них и по умолчанию для новых файлов делать utf8.</p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</body>
</html>

Re: [Spf-dev] Git repo

[Andrey C. <an...@ch...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Re: [Spf-dev] Git repo</title>
<meta http-equiv="content-type" content="text/html; charset=windows-1251">
</head>
<body>
<p>Да, история коммитов, конечно, вся сохранена - с 2001 года, когда переехали на sf.net. Комментарии к коммитам сконвертированы в utf8, чтобы нормально показываться всеми утилитами git.</p>
<p>Я тоже за то, чтобы перейти с CVS на Git со следующих комитов.</p>
<p>C utf8/cp1251 не всё однозначно. Есть коммиты, где при одной и той же кодировке исходных файлов (cp1251) diff показывается для разных файлов в разной кодировке - для одних читабельно, для других нет. Например, https://github.com/rufig/spf/commit/3ccf936ae65fdb402d990d39390e6b209ece34de Как ему подсказать, я пока не разобрался. Если кто может сконвертировать лучше - можно будет перейти на его версию repo.</p>
<p>Но старые файлы конвертировать в utf8 не хотелось бы - могут быть кириллические литералы, кириллические названия слов где-то были, и т.п. А для новых предлагаю использовать кому как удобнее. Под Windows давно не проблема работать со смешанными кодировками, FAR всё автоматически определяет, так что разница и не заметна. А так как линуксы и маки традиционо менее гибки, можно подстроиться под них и по умолчанию для новых файлов делать utf8.</p>
<hr />
<table>
<tbody>
<tr>
<td colspan="2"><strong>-------- Исходное сообщение --------</strong></td>
</tr>
<tr>
<td>Тема:</td>
<td>Re: [Spf-dev] Git repo</td>
</tr>
<tr>
<td>Дата:</td>
<td>2017-06-19 13:58:13</td>
</tr>
<tr>
<td>От:</td>
<td><a href="mailto:iv...@ic...">ivanov</a></td>
</tr>
</tbody>
</table>
<table class="message" border="1">
<tbody>
<tr>
<td>
<table class="message" border="1">
<tbody>
<tr>
<td>
<table class="message" border="1">
<tbody>
<tr>
<td>
<div>Сделал клон у себя.</div>
<div>Git-cola показала историю правок. Например последняя правка от ruv 23 apr 2017, а первая от ygrecs 21dec 2008.</div>
<div>&nbsp;</div>
<div>В Пн, 19/06/2017 в 11:36 +0300, Ruvim Pinka пишет:</div>
<blockquote>
<div dir="ltr">Привет!<br />
<div class="gmail_extra"><br />
<div class="gmail_quote">2017-06-19 4:06 GMT+03:00 Andrey Cherezov <span dir="ltr">&lt;<a href="mailto:an...@ch..." target="_blank">an...@ch...</a>&gt;</span>:<br />
<blockquote>
<div>
<p>Сконвертировал CVS-&gt;GIT, попутно поправив кодировки в сообщениях последних коммитов.</p>
<p><a href="https://git.code.sf.net/p/spf/spf" target="_blank">https://git.code.sf.net/p/spf/spf</a> (<a href="https://sourceforge.net/p/spf/spf/ci/master/tree/" target="_blank">https://sourceforge.net/p/spf/spf/ci/master/tree/</a>)</p>
<p>Копия на github: <a href="https://github.com/rufig/spf" target="_blank">https://github.com/rufig/spf</a></p>
</div>
</blockquote>
<div>&nbsp;</div>
<div>Это весьма полезно. Но, я хочу не только зеркало, а целиком разработку SP-Forth перевести на Git и в UTF-8.</div>
<div>Т.к. нечитаемый текст (<a href="https://github.com/rufig/spf/commit/641804c75fc10fbe27231b87256296a7d22917c1">пример</a>) из-за несогласованности кодировок &mdash; напрягает.<br /><br />И я поставли даже себе задачу &mdash; конвертировать в Git всю историю, включая кодировку содержимого файлов . Но пока руки не дошли ;)</div>
</div>
</div>
<div class="gmail_extra">Может, кто-то хочет повозится? ;)&nbsp; Есть план действий и список подводных камней.</div>
<div class="gmail_extra">--</div>
<div class="gmail_extra">Ruvim</div>
</div>
<pre>------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! <a href="http://sdm.link/slashdot">http://sdm.link/slashdot</a></pre>
<pre>_______________________________________________
Spf-dev mailing list
<a href="mailto:Sp...@li...">Sp...@li...</a>
<a href="https://lists.sourceforge.net/lists/listinfo/spf-dev">https://lists.sourceforge.net/lists/listinfo/spf-dev</a>
</pre>
</blockquote>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td>
<pre class="plain" title="">------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot</pre>
</td>
</tr>
<tr>
<td>
<pre class="plain" title="">_______________________________________________
Spf-dev mailing list
Sp...@li...
https://lists.sourceforge.net/lists/listinfo/spf-dev
</pre>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</body>
</html>

Re: [Spf-dev] Git repo

[ivanov <iv...@ic...>]

Сделал клон у себя.
Git-cola показала историю правок. Например последняя правка от ruv 23
apr 2017, а первая от ygrecs 21dec 2008.
В Пн, 19/06/2017 в 11:36 +0300, Ruvim Pinka пишет:
> Привет!
> 
> 2017-06-19 4:06 GMT+03:00 Andrey Cherezov <an...@ch...>
> :
> > Сконвертировал CVS->GIT, попутно поправив кодировки в сообщениях
> > последних коммитов.
> > https://git.code.sf.net/p/spf/spf
> > (https://sourceforge.net/p/spf/spf/ci/master/tree/)
> > Копия на github: https://github.com/rufig/spf
> > 
> Это весьма полезно. Но, я хочу не только зеркало, а целиком
> разработку SP-Forth перевести на Git и в UTF-8.
> Т.к. нечитаемый текст (пример) из-за несогласованности кодировок —
> напрягает.
> 
> И я поставли даже себе задачу — конвертировать в Git всю историю,
> включая кодировку содержимого файлов . Но пока руки не дошли ;)
> 
> Может, кто-то хочет повозится? ;)  Есть план действий и список
> подводных камней.
> 
> --
> Ruvim
> 
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Spf-dev mailing list
> Sp...@li...
> https://lists.sourceforge.net/lists/listinfo/spf-dev

Re: [Spf-dev] Git repo

[Ruvim P. <ruv...@gm...>]

Привет!

2017-06-19 4:06 GMT+03:00 Andrey Cherezov <an...@ch...>:

> Сконвертировал CVS->GIT, попутно поправив кодировки в сообщениях последних
> коммитов.
>
> https://git.code.sf.net/p/spf/spf (https://sourceforge.net/p/
> spf/spf/ci/master/tree/)
>
> Копия на github: https://github.com/rufig/spf
>

Это весьма полезно. Но, я хочу не только зеркало, а целиком разработку
SP-Forth перевести на Git и в UTF-8.
Т.к. нечитаемый текст (пример
<https://github.com/rufig/spf/commit/641804c75fc10fbe27231b87256296a7d22917c1>)
из-за несогласованности кодировок — напрягает.

И я поставли даже себе задачу — конвертировать в Git всю историю, включая
кодировку содержимого файлов . Но пока руки не дошли ;)

Может, кто-то хочет повозится? ;)  Есть план действий и список подводных
камней.

--
Ruvim

[Spf-dev] Git repo

[Andrey C. <an...@ch...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Git repo</title>
<meta http-equiv="content-type" content="text/html; charset=windows-1251">
</head>
<body>
<p>Привет!</p>
<p>Сконвертировал CVS-&gt;GIT, попутно поправив кодировки в сообщениях последних коммитов.</p>
<p>https://git.code.sf.net/p/spf/spf (https://sourceforge.net/p/spf/spf/ci/master/tree/)</p>
<p>Копия на github: https://github.com/rufig/spf</p>
<p>--<br />Andrey Cherezov</p>
</body>
</html>

[Spf-dev] sf.net and mail.ru issue

[Ruvim P. <ruv...@gm...>]

День добрый!

Проблема с недоставкой некоторых писем раскрыта :)
На mail.ru сделаны такие настройки против фишинга, что письма не могут
корректно доставляться через списки рассылки.

Конкретно, политика DMARC
<http://dig-nslookup.nmonitoring.com/dns-dig-nslookup.html?domain=_dmarc.mail.ru&pingsub=1>
уставлена в reject, прописана политика SPF, и подписи DKIM в письме
отсутствуют. Как следствие, письмо отвергается получателем как фишинговое,
если домен в MAIL FROM (envelope-from) отличается от домена в поле From.

А это как раз случай, когда письма доставляются через спиок рассылки.
Например, здесь у нас envelope-from: <spf...@li...>

Письмо отвергается только теми серверами получателей, которые выполняют
протокол DMARC при приеме (например, GMail).

По идее, если бы поле From было подписано сервером mail.ru по протоколу
DKIM, то отличие доменов envelope-from и From не помешало бы. Но, видимо,
sourceforge в любом случае вырезает цифровые подписи DKIM, т.к. он
модифицирует тело письма, добавляя секции со своим текстом (реклама и
ссылки) — а это нарушает цифровую подпись.

О, в конце нашлось разъяснение от Mail.ru
<https://habrahabr.ru/company/mailru/blog/282602/> на Хабре.
— рекомендуют администраторам рассылок обновить и подстроить Mailman

В SourceForge вроде как работают над этим
<https://sourceforge.net/p/forge/site-support/14557/>.

-- 
Ruvim

Re: [Spf-dev] 2>R в интерпретации

[витя е. <vi...@ma...>]

Для отладки, действительно, самое то. Но если определения используют стек возвратов и написаны на асме, то навряд ли либы пройдут.
А так хорошо отлаживается и слова не приходится плодить
(к примеру, он может стать отдельным в следущей версии ;)
Кстати, когда же наступит это будущее :) ?

>Суббота, 22 апреля 2017, 18:39 +03:00 от Ruvim Pinka <ruv...@gm...>:
>
>Процитированное ниже  сообщение попало в архив spf-dev, но не пришло мне на gmail (почему-то от @ mail.ru перестали приходить из spf-dev):
>>В очередной раз копался в СПФ нашёл чудесненькую фичу ( может, она уже обсуждалась?)
В режиме интерпретации корректно работает стек возвратов ежели согласовать операции с ним на одной линии
Как я понял, всё из-за строения интерпретатора.
т.е пример 10 20 2>R 30 2R> является рабочим

Является ли данный пример задокументированным где-либо?

-- 
>>Виктор Ерыгин Такое поведение не документированно. Документировано, что поведение слов работы со стеком возвратов при интерпретации не определено. Если вдруг это работает сейчас, то может перестать работать в следующей версии.
>
>
>В качестве примера использования Виктор  приводит следующий код:
>: TEST BEGIN [ 2>R ] IF ." HELLO WORD, gudleifr" CR [ 2R> ] AGAIN THEN ;
>
>Этот код плохо портабелен еще и по той причине, что стек управления может быть не совмещен со стеком данных (к примеру, он может стать отдельным в следущей версии ;)
>
>Для таких случае в стандарте есть слово  CS-ROLL . В SP-Forth/4 на данный момент оно отсутствует, и может быть определено в текущей версии как:
>
>: CS-ROLL ( i*x u -- i*y ) 2* 1+ DUP >R ROLL R> ROLL ;
>
>
>Более портабельный способ определить данный TEST будет:
>
>: TEST ( 0 i*x -- ) BEGIN IF ." HELLO WORD, gudleifr" CR [ 1 CS-ROLL ] AGAIN THEN ;
>
>0 1 1 1 TEST
>
>
>Операции со стеком возвратов в  режиме интерпретации могут быть полезны для отладки фрагментов кода. Для такого использования , эти операции могут быть определены так чтобы в режиме интерпретации работать с отдельным стеком, не трогая реальный стек возвратов.
>
>И правильный способ  — переопределить все соответствующие слова, а не полагаться на недокументированные особенности реализации.
>
>
>-- 
>Ruvim
>
>------------------------------------------------------------------------------
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org!  http://sdm.link/slashdot
>_______________________________________________
>Spf-dev mailing list
>Sp...@li...
>https://lists.sourceforge.net/lists/listinfo/spf-dev

[Spf-dev] 2>R в интерпретации

[Ruvim P. <ruv...@gm...>]

Процитированное ниже сообщение
<https://sourceforge.net/p/spf/mailman/spf-dev/thread/1492753480.657951092%40f378.i.mail.ru/#msg35798804>
попало в архив spf-dev, но не пришло мне на gmail (почему-то от @mail.ru
перестали приходить из spf-dev):

> В очередной раз копался в СПФ нашёл чудесненькую фичу ( может, она уже обсуждалась?)
> В режиме интерпретации корректно работает стек возвратов ежели согласовать операции с ним на одной линии
> Как я понял, всё из-за строения интерпретатора.
> т.е пример 10 20 2>R 30 2R> является рабочим
>
> Является ли данный пример задокументированным где-либо?
>
> --
> Виктор Ерыгин
>
> Такое поведение не документированно. Документировано, что поведение слов
работы со стеком возвратов при интерпретации не определено. Если вдруг это
работает сейчас, то может перестать работать в следующей версии.


В качестве примера использования Виктор приводит
<http://fforum.winglion.ru/viewtopic.php?t=1533&p=43356#p43356> следующий
код:
: TEST BEGIN [ 2>R ] IF ." HELLO WORD, gudleifr" CR [ 2R> ] AGAIN THEN ;

Этот код плохо портабелен еще и по той причине, что стек управления может
быть не совмещен со стеком данных (к примеру, он может стать отдельным в
следущей версии ;)

Для таких случае в стандарте есть слово CS-ROLL
<https://forth-standard.org/standard/tools/CS-ROLL>. В SP-Forth/4 на данный
момент оно отсутствует, и может быть определено в текущей версии как:

: CS-ROLL ( i*x u -- i*y ) 2* 1+ DUP >R ROLL R> ROLL ;


Более портабельный способ определить данный TEST будет:

: TEST ( 0 i*x -- ) BEGIN IF ." HELLO WORD, gudleifr" CR [ 1 CS-ROLL ]
AGAIN THEN ;

0 1 1 1 TEST


Операции со стеком возвратов в режиме интерпретации могут быть полезны для
отладки фрагментов кода. Для такого использования, эти операции могут быть
определены так чтобы в режиме интерпретации работать с отдельным стеком, не
трогая реальный стек возвратов.

И правильный способ — переопределить все соответствующие слова, а не
полагаться на недокументированные особенности реализации.


-- 
Ruvim

[Spf-dev] 2>R в интерпретации

[витя е. <vi...@ma...>]

В очередной раз копался в СПФ нашёл чудесненькую фичу ( может, она уже обсуждалась?)
В режиме интерпретации корректно работает стек возвратов ежели согласовать операции с ним на одной линии
Как я понял, всё из-за строения интерпретатора.
т.е пример 10 20 2>R 30 2R> является рабочим

Является ли данный пример задокументированным где-либо?

-- 
Виктор Ерыгин

Re: [Spf-dev] temporary wordlist issue

[витя е. <vi...@ma...>]

Благодарю


>Пятница,  7 апреля 2017, 1:09 +03:00 от Ruvim Pinka <ruv...@gm...>:
>
>Victor__v  пишет на fforum :
>>Нашёл в СПФ лаг
>>При создании временного словаря here указывает на точку в хипе ( штатно)
>>При создании во временном словаре словаря обычного here указывает в кодофайл !!!
>>Смотрел дизассемблером данный фортель. этот лаг никак не экранируется.
>>Кто может предложить экранирование данной неприятности?
>
>
>Это известная проблема, конструктивный недостаток штатной реализации временных словарей.
>
>Проблема была решена (в уже мохнатом 2006 году) внешним расширением.
>
>REQUIRE NEW-STORAGE  ~pinka/spf/storage.f
>
>
>-- 
>Ruvim
>------------------------------------------------------------------------------
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org!  http://sdm.link/slashdot
>_______________________________________________
>Spf-dev mailing list
>Sp...@li...
>https://lists.sourceforge.net/lists/listinfo/spf-dev

Re: [Spf-dev] new support channel

[Ruvim P. <ruv...@gm...>]

Там же ссылка "Don't have *Telegram* yet? Try it now: Get Telegram
<https://telegram.org/>"

Можно поставить приложение на ваше устройство (после этого ссылки по
протоколу tg будут открываться в приложении Telegram). Или можно открыть в
браузере веб-версию клиента https://web.telegram.org/ — после входа (по
номеру мобильного телефона, но он нигде не светится) перейти в чат
  https://web.telegram.org/#/im?p=@spforthchat


2017-04-07 10:30 GMT+03:00 ivanov <iv...@ic...>:

> При попытке перейти по ссылке, Firefox на Ubunte 16.04 (32-разрядная)
> выдает:
> "Неизвестный тип адреса
> Firefox не знает, как открыть данный адрес, так как один из следующих
> протоколов (tg) не связан ни с одной программой или не разрешен в этом
> контексте.
>     Для открытия данного адреса вам, возможно, понадобится установить
> стороннее программное обеспечение."
>
> Похоже у меня чего-то не хватает.
>



> В Пт, 07/04/2017 в 01:31 +0300, Ruvim Pinka пишет:
>
> Привет всем!
>
> В качестве эксперимента открыл чат-группу в Телеграме:
>
> https://t.me/spforthchat
>
> По идее, там задать ворос будет проще, чем подписываться на список
> рассылки или ходить в багтрекер на sourceforge.
>
>

Re: [Spf-dev] new support channel

[ivanov <iv...@ic...>]

При попытке перейти по ссылке, Firefox на Ubunte 16.04 (32-разрядная)
выдает:
"Неизвестный тип адреса
Firefox не знает, как открыть данный адрес, так
как один из следующих протоколов (tg) не связан ни с одной программой
или не разрешен в этом контексте.
    Для открытия данного адреса вам,
возможно, понадобится установить стороннее программное обеспечение."
Похоже у меня чего-то не хватает.
В Пт, 07/04/2017 в 01:31 +0300, Ruvim Pinka пишет:
> Привет всем!
> 
> В качестве эксперимента открыл чат-группу в Телеграме:
> 
> https://t.me/spforthchat
> 
> По идее, там задать ворос будет проще, чем подписываться на список
> рассылки или ходить в багтрекер на sourceforge.
> 
> 
> И еще. Чтобы два раза не вставать.
> 
> Если кого-то вдруг заинтересует подработка Forth+Linux — пишите в
> личку. Надо портировать несколько библиотек (для начала).
> 
> 
> -- 
> Ruvim
> 
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Spf-dev mailing list
> Sp...@li...
> https://lists.sourceforge.net/lists/listinfo/spf-dev

[Spf-dev] new support channel

[Ruvim P. <ruv...@gm...>]

Привет всем!

В качестве эксперимента открыл чат-группу в Телеграме:

https://t.me/spforthchat

По идее, там задать ворос будет проще, чем подписываться на список рассылки
или ходить в багтрекер на sourceforge.


И еще. Чтобы два раза не вставать.

Если кого-то вдруг заинтересует подработка Forth+Linux — пишите в личку.
Надо портировать несколько библиотек (для начала).


-- 
Ruvim