три вопроса

[yGREK Heretix]

1. Есть предложение включить FSL [1] в /lib или /devel.
Реализовано множество полезных алгоритмов. В частности я
использовал вычисление дат в ~ygrek/lib/spec/unixdate.f
Переходник есть - ~diver/fsl-util.f

2. lib/ext/disasm.f портит контекст при загрузке - ничего если
исправить используя MODULE: или лучше обойтись только ANS словами?

3. Прояснить вопрос насчёт лицензии. На сам SPF понятно - GPL. Т.е.
можно писать софт с закрытым исходным кодом который компилируется
spf.exe. А на devel? Раз не указано иначе - получается тоже GPL.
Применимы ли к нему те же рассуждения про корову и молоко? [2] Скорее
всего нет. То есть получается что закрытый софт на spf с использованием
devel (и lib) писать нельзя. Так?

[1] http://www.taygeta.com/fsl/sciforth.html
[2] http://article.gmane.org/gmane.comp.lang.forth.spf/129

--
ygrek

[Andrey Cherezov]

Добрый день, ygrek!

Ваше сообщение от 22.04.2007 20:58:
> 1. Есть предложение включить FSL [1] в /lib или /devel.
> Реализовано множество полезных алгоритмов. В частности я
> использовал вычисление дат в ~ygrek/lib/spec/unixdate.f
> Переходник есть - ~diver/fsl-util.f
>  
Можно включить в devel/~fsl или как-то так. По аналогии с ~clf (или даже
туда же).
Что-то у меня этот [1] второй день не открывается, таймаут.
> 2. lib/ext/disasm.f портит контекст при загрузке - ничего если
> исправить используя MODULE: или лучше обойтись только ANS словами?
>  
Лучше ANS.
> 3. Прояснить вопрос насчёт лицензии. На сам SPF понятно - GPL. Т.е.
> можно писать софт с закрытым исходным кодом который компилируется
> spf.exe. А на devel? Раз не указано иначе - получается тоже GPL.
> Применимы ли к нему те же рассуждения про корову и молоко? [2] Скорее
> всего нет. То есть получается что закрытый софт на spf с использованием
> devel (и lib) писать нельзя. Так?
>  
Я относился к этим либам как к LGPL-лицензируемым. Т.к. закрытый софт
давно не пишу,
то и не задумывался особо. Может быть действительно стоит уточнить и
попросить авторов
написать свои лицензии, если они более либеральные или наоборот строгие.

[Yuriy Zhilovets]

Привет всем!

Как заставить ЦК компилировать в какие-нибудь виртуальные адреса, а не в
реальные?
То есть, в текущее адресное пространство, но чтобы новая ФС считала, что
она работает где-нибудь, например,  в районе 0x8000000
Есть ли там какие-то заготовки для этой цели?
Достаточно ли переопределить HERE , ALLOT
?

Ю. Жиловец

[Andrey Cherezov]

Добрый день, Yuriy Zhilovets!

Ваше сообщение от 23.04.2007 20:08:
> Как заставить ЦК компилировать в какие-нибудь виртуальные адреса, а не в
> реальные?
> То есть, в текущее адресное пространство, но чтобы новая ФС считала, что
> она работает где-нибудь, например,  в районе 0x8000000
> Есть ли там какие-то заготовки для этой цели?
> Достаточно ли переопределить HERE , ALLOT
>  
В ЦК есть исторический пережиток (со времен сборки SPF3 в недрах Win32for) -
он запускает отдельные процедуры в целевом адресном пространстве, т.е.
компилирует
не мертвый код, а полуживой, поэтому этот код с привязками к реальным
адресам.

Хотя вцелом код генерируется перемещабельный (в CALL и JMP относительные
адреса), поэтому менять там не много. Абсолютные адреса компилируются в
словарных заголовках, в некоторых литералах. Там нужно просто вызывать
что-то
типа ABS>REL перед компиляцией этих ссылок.

[Yuriy Zhilovets]

Andrey Cherezov пишет:

>В ЦК есть исторический пережиток (со времен сборки SPF3 в недрах Win32for) -
>он запускает отдельные процедуры в целевом адресном пространстве, т.е.
>компилирует
>не мертвый код, а полуживой, поэтому этот код с привязками к реальным
>адресам.
>  
>
Имеется в виду последний вызов INIT или какие-то куски вызываются в
процессе компиляции?

И еще вопрос: откуда берется место для расширения словаря? Оно ведь в
исполняемом файле не описано.

Ю. Жиловец

[yGREK Heretix]

On Wed, 25 Apr 2007 19:56:32 +0300
Yuriy Zhilovets <[hidden email]> wrote:

> И еще вопрос: откуда берется место для расширения словаря? Оно ведь в
> исполняемом файле не описано.

В заголовке PE поле ImageSize заполняется на основе IMAGE-SIZE,
если в рантайме надо расширять кодофайл то надо увеличивать эту
переменную перед SAVE.

--
ygrek

[yGREK Heretix]

> Можно включить в devel/~fsl или как-то так. По аналогии с ~clf (или
> даже туда же).

Закоммитил в ~clf/fsl

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

Идеально было бы чтобы на весь devel + lib была одинаковая лицензия. Я
не специалист в этих лицензиях но :) в LGPL [1] идётся про software
libraries как a collection of software functions and/or data prepared
so as to be conveniently linked with application programs. Не уверен
что это подходит т.к. никаких obj, lib итп бинарных промежуточных
переносимых файлов у нас нет..

Лично я для своих либ согласен на BSD [2] или MIT [3].

Предлагаю высказываться и приходить к консенсусу если получится.

[1] http://www.gnu.org/licenses/lgpl.html
[2] http://opensource.org/licenses/bsd-license.php
[3] http://opensource.org/licenses/mit-license.php

--
ygrek

[Andrey Cherezov]

Добрый день, ygrek!

Ваше сообщение от 27.04.2007 21:25:
> Идеально было бы чтобы на весь devel + lib была одинаковая лицензия. Я
> не специалист в этих лицензиях но :) в LGPL [1] идётся про software
> libraries как a collection of software functions and/or data prepared
> so as to be conveniently linked with application programs. Не уверен
> что это подходит т.к. никаких obj, lib итп бинарных промежуточных
> переносимых файлов у нас нет..
>  
Тем не менее они все "prepared to be conveniently linked" к любым
форт-программам.
Какая разница в каком формате. Главное, что не требуют никаких внешних
инструментов
для компиляции и линковки. Для форт-программ они куда лучше prepared,
чем dll :)

[Andrey Cherezov]

Some javascript/style in this post has been disabled (why?)

Ваше сообщение от 27.04.2007 21:25:
  

Идеально было бы чтобы на весь devel + lib была одинаковая лицензия. Я
не специалист в этих лицензиях но :) в LGPL [1] идётся про software
libraries как a collection of software functions and/or data prepared
so as to be conveniently linked with application programs. Не уверен
что это подходит т.к. никаких obj, lib итп бинарных промежуточных
переносимых файлов у нас нет..
  
    

Тем не менее они все "prepared to be conveniently linked" к любым 
форт-программам.
Какая разница в каком формате. Главное, что не требуют никаких внешних 
инструментов
для компиляции и линковки. Для форт-программ они куда лучше prepared, 
чем dll :)
  

Кстати, вот, нашел у лисперов такой же подход:
http://opensource.franz.com/preamble.html
A "Library" in Lisp is a collection of Lisp functions, data and foreign modules. The form of the Library can be Lisp source code...
(в частности The Allegro NFS Server source code is licensed under the terms of the Lisp Lesser GNU Public License)

[Yuriy Zhilovets]

ygrek пишет:

>В заголовке PE поле ImageSize заполняется на основе IMAGE-SIZE,
>  
>
Там занесено 512 1024 *
Это выходит всего 512 кб. Не мало?

Ю. Жиловец

[Andrey Cherezov]

Some javascript/style in this post has been disabled (why?)

Добрый день, Yuriy Zhilovets!

Ваше сообщение от 28.04.2007 21:41:

В заголовке PE поле ImageSize заполняется на основе IMAGE-SIZE,
    

Там занесено 512 1024 *
Это выходит всего 512 кб. Не мало?
  

Недавно уперся в Eserv. Просто написал 700000 TO IMAGE-SIZE, и делов :)

[Илья Абдрахимов]

Hello ygrek,

Friday, April 27, 2007, 10:25:34 PM, you wrote:

>> Можно включить в devel/~fsl или как-то так. По аналогии с ~clf (или
>> даже туда же).

> Закоммитил в ~clf/fsl

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

> Идеально было бы чтобы на весь devel + lib была одинаковая лицензия. Я
> не специалист в этих лицензиях но :) в LGPL [1] идётся про software
> libraries как a collection of software functions and/or data prepared
> so as to be conveniently linked with application programs. Не уверен
> что это подходит т.к. никаких obj, lib итп бинарных промежуточных
> переносимых файлов у нас нет..

> Лично я для своих либ согласен на BSD [2] или MIT [3].

> Предлагаю высказываться и приходить к консенсусу если получится.

> [1] http://www.gnu.org/licenses/lgpl.html
> [2] http://opensource.org/licenses/bsd-license.php
> [3] http://opensource.org/licenses/mit-license.php

> --
> ygrek


Актуальная тема!
Вот только, если бы кто объяснил на "пальцах" (по простому) про лицензии!?

P.S.
Ну с аглицким я не очень дружу. ;-)

--
Best regards,
 Илья                            mailto:[hidden email]

[Aleksej Saushev]

  Здравствуйте!

Илья Абдрахимов <[hidden email]> writes:

> Friday, April 27, 2007, 10:25:34 PM, you wrote:
>
>>> Я относился к этим либам как к LGPL-лицензируемым. Т.к. закрытый софт
>>> давно не пишу,
>>> то и не задумывался особо. Может быть действительно стоит уточнить и
>>> попросить авторов
>>> написать свои лицензии, если они более либеральные или наоборот
>>> строгие.
>
>> Идеально было бы чтобы на весь devel + lib была одинаковая лицензия. Я
>> не специалист в этих лицензиях но :) в LGPL [1] идётся про software
>> libraries как a collection of software functions and/or data prepared
>> so as to be conveniently linked with application programs. Не уверен
>> что это подходит т.к. никаких obj, lib итп бинарных промежуточных
>> переносимых файлов у нас нет..
>
>> Лично я для своих либ согласен на BSD [2] или MIT [3].
>
>> Предлагаю высказываться и приходить к консенсусу если получится.
>
>> [1] http://www.gnu.org/licenses/lgpl.html
>> [2] http://opensource.org/licenses/bsd-license.php
>> [3] http://opensource.org/licenses/mit-license.php
>
> Актуальная тема!
> Вот только, если бы кто объяснил на "пальцах" (по простому) про лицензии!?

Объясняю.

По бернской конвенции, всё, что создаётся, сразу попадает под
действие копирайта. По умолчанию действует то, что когда-то
называлось "all rights reserved", то есть "все права оставлены
за мной", читай: "Ты можешь только прочитать, но не переписать
или изменить."  Соответственно, это бесполезно, поскольку не
допускает никакого повторного использования кода.

Для того, чтобы (по закону) была возможность повторного
использования, автор (создатель) должен дать права.
Это соглашение между создателем и посторонним потребителем и
называется лицензией: создатель произведения наделяет
потребителя правом использования произведения помимо
закреплённого в законе "fair use" ("честного использования",
которое включает некоторое ознакомительное цитирование и ещё
что-то по мелочи).  Для нас это слишком мало и неинтересно,
поскольку не даёт возможности использовать чужой код.

Спустя некоторое, постоянно увеличиваемое в законе, время любое
произведение становится общественным достоянием ("public domain"),
и тогда его может использовать каждый как угодно, по собственному
усмотрению.  В том числе --- никак не упоминать имени создателя.
Лично мне это не очень страшно, поэтому я предпочитаю писать
сразу --- общественное достояние.

Соглашение MIT и очень старое BSD (которое уже почти забыто,
но его можно встретить в архивах и исходниках BSD UNIX) защищает
право создателя на признание, то есть право создателя на то, что
его имя не будет просто так забыто.  Короче, единственным
требованием является требование упоминать создателя и условия,
на которых создатель отдал произведение потребителю.

Соглашение BSD, по условиям.

> Copyright (c) 1990, 1993
> The Regents of the University of California.  All rights reserved.

Год создания, имя создателя, устаревшее "все права оставляю себе".

> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:

Разрешается использование и повторное распространение в любом
виде, даже с изменениями, при условиях. (При несоблюдении
условий, незаконно.)

> 1. Redistributions of source code must retain the above copyright
>    notice, this list of conditions and the following disclaimer.

Сохраняется право автора на признание, обеспечивается неизменность
условий распространения, поставленных автором.

> 2. Redistributions in binary form must reproduce the above copyright
>    notice, this list of conditions and the following disclaimer in the
>    documentation and/or other materials provided with the distribution.

Конкретизация того, что надо сделать, чтобы выполнить условия распространения.

> 3. All advertising materials mentioning features or use of this software
>    must display the following acknowledgement:
> This product includes software developed by the University of
> California, Berkeley and its contributors.

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

> 4. Neither the name of the University nor the names of its contributors
>    may be used to endorse or promote products derived from this software
>    without specific prior written permission.

Это требование сперва непонятно, но оно существует не просто так.
Дело вот в чём. Допустим, ты написал какую-то библиотеку, я его
использовал и теперь пишу в рекламном проспекте:
"Покупайте новую софтину, она сделана на основе либы Абдрахимова!"
Хотя ты написал довольно сырую вещь, не готовую для окончательного
использования. А некоторые люди могут подумать: "Блин, что за
уродская софтина, ну и отстойную либу написал Абдрахимов!"
Неприятно, да?  Поэтому поставлено такое условие.

> THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
> ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
> FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> SUCH DAMAGE.

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

[Aleksej Saushev]

  Здравствуйте!

ygrek <[hidden email]> writes:

> 1. Есть предложение включить FSL [1] в /lib или /devel.

Не надо этого делать.
Если надо использовать что-то из FSL лучше оставлять ссылку на
файл, в коде ставить путь к корню FSL и приписывать к нему имя файла.

Объясню, почему не надо этого делать.
Если импортируются исходники, их надо будет поддерживать в
актуальном состоянии. С одним только этим возникают проблемы.
Но куда больше проблем возникает с желанием подправить
импортированные исходники в собственной VCS. Один раз поправишь ---
не развяжешься. Я на прошлой работе еле ASDF так обновил, кто-то
его хорошо поправил без комментариев, что, зачем и почему.
Ещё на одном месте работы пришлось выкинуть хорошо правленные
исходники линукса, потому что ядро версии 2.2 безнадёжно устарело,
из-за чего его уже нельзя было использовать для файервола, как
бы ни заманчиво было иметь встроенные snort и ещё что-то там.

> 3. Прояснить вопрос насчёт лицензии. На сам SPF понятно - GPL. Т.е.
> можно писать софт с закрытым исходным кодом который компилируется
> spf.exe. А на devel? Раз не указано иначе - получается тоже GPL.

Раз не указано иначе, "all rights reserved".
См. бернскую конвенцию.
Все права должны быть отданы _явно_.

Если лень вписывать стандартную шапку, то надо хотя бы положить
документ в корень.

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

> Применимы ли к нему те же рассуждения про корову и молоко? [2] Скорее
> всего нет. То есть получается что закрытый софт на spf с использованием
> devel (и lib) писать нельзя. Так?
>
> [1] http://www.taygeta.com/fsl/sciforth.html
> [2] http://article.gmane.org/gmane.comp.lang.forth.spf/129

[Aleksej Saushev]

  Здравствуйте!

ygrek <[hidden email]> writes:

> 1. Есть предложение включить FSL [1] в /lib или /devel.

Не надо этого делать.
Если надо использовать что-то из FSL лучше оставлять ссылку на
файл, в коде ставить путь к корню FSL и приписывать к нему имя файла.

Объясню, почему не надо этого делать.
Если импортируются исходники, их надо будет поддерживать в
актуальном состоянии. С одним только этим возникают проблемы.
Но куда больше проблем возникает с желанием подправить
импортированные исходники в собственной VCS. Один раз поправишь ---
не развяжешься. Я на прошлой работе еле ASDF так обновил, кто-то
его хорошо поправил без комментариев, что, зачем и почему.
Ещё на одном месте работы пришлось выкинуть хорошо правленные
исходники линукса, потому что ядро версии 2.2 безнадёжно устарело,
из-за чего его уже нельзя было использовать для файервола, как
бы ни заманчиво было иметь встроенные snort и ещё что-то там.

> 3. Прояснить вопрос насчёт лицензии. На сам SPF понятно - GPL. Т.е.
> можно писать софт с закрытым исходным кодом который компилируется
> spf.exe. А на devel? Раз не указано иначе - получается тоже GPL.

Раз не указано иначе, "all rights reserved".
См. бернскую конвенцию.
Все права должны быть отданы _явно_.

Если лень вписывать стандартную шапку, то надо хотя бы положить
документ в корень.

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

> Применимы ли к нему те же рассуждения про корову и молоко? [2] Скорее
> всего нет. То есть получается что закрытый софт на spf с использованием
> devel (и lib) писать нельзя. Так?
>
> [1] http://www.taygeta.com/fsl/sciforth.html
> [2] http://article.gmane.org/gmane.comp.lang.forth.spf/129

[yGREK Heretix]

>
> > 1. Есть предложение включить FSL [1] в /lib или /devel.
>
> Не надо этого делать.
> [...]

Последнее обновление FSL было в апреле 2005 года. Так что проблем с
синхронизацией думаю много не будет. Так как нету никакой инфраструктуры
для contributed code, то проще сделать так.

--
ygrek

[yGREK Heretix]

> > Тем не менее они все "prepared to be conveniently linked" к любым
> > форт-программам.
> > Какая разница в каком формате. Главное, что не требуют никаких
> > внешних инструментов
> > для компиляции и линковки. Для форт-программ они куда лучше
> > prepared, чем dll :)
> >
> Кстати, вот, нашел у лисперов такой же подход:
> http://opensource.franz.com/preamble.html
> A "Library" in Lisp is a collection of Lisp functions, data and
> foreign modules. The form of the Library can be Lisp source code...
> (в частности The Allegro NFS Server source code is licensed under the
> terms of the Lisp Lesser GNU Public License)

Ну формально это отдельная лицензия и бла-бла-бла, но вообщем всё равно.
Пусть так.

Главное чтобы все в devel что нибудь сказали по поводу своих условий
лицензирования чтобы можно было выбрать общий вариант если получится.
Надо соблюсти в этом случае формальности..

--
ygrek

[Илья Абдрахимов]

Hello Aleksej,

Tuesday, May 1, 2007, 12:45:05 PM, you wrote:

>   Здравствуйте!

> Илья Абдрахимов <[hidden email]> writes:



Спасибо за подробный ответ!


--
Best regards,
 Илья                            mailto:[hidden email]

[Илья Абдрахимов]

Hello ygrek,

Tuesday, May 1, 2007, 4:07:49 PM, you wrote:

>> > Тем не менее они все "prepared to be conveniently linked" к любым
>> > форт-программам.
>> > Какая разница в каком формате. Главное, что не требуют никаких
>> > внешних инструментов
>> > для компиляции и линковки. Для форт-программ они куда лучше
>> > prepared, чем dll :)
>> >
>> Кстати, вот, нашел у лисперов такой же подход:
>> http://opensource.franz.com/preamble.html
>> A "Library" in Lisp is a collection of Lisp functions, data and
>> foreign modules. The form of the Library can be Lisp source code...
>> (в частности The Allegro NFS Server source code is licensed under the
>> terms of the Lisp Lesser GNU Public License)

> Ну формально это отдельная лицензия и бла-бла-бла, но вообщем всё равно.
> Пусть так.

> Главное чтобы все в devel что нибудь сказали по поводу своих условий
> лицензирования чтобы можно было выбрать общий вариант если получится.
> Надо соблюсти в этом случае формальности..

> --
> ygrek

Мне, например очень "стремно" высказываться по этому поводу (ну нет у
меня "полезных" либ), а вот творчеством других товарищей приходится
пользоваться достаточно часто. Поэтому поддерживаю мнение по поводу
высказывания сообщества, про лицензию!

--
Best regards,
 Илья                            mailto:[hidden email]

[Aleksej Saushev]

  Здравствуй!

ygrek <[hidden email]> writes:

>> > 1. Есть предложение включить FSL [1] в /lib или /devel.
>>
>> Не надо этого делать.
>> [...]
>
> Последнее обновление FSL было в апреле 2005 года. Так что проблем с
> синхронизацией думаю много не будет. Так как нету никакой инфраструктуры
> для contributed code, то проще сделать так.

Этого не надо делать, несмотря на то, что так проще.
Правда, честно-честно. Потом такие проблемы возникают,
требуется значительно больше времени, чтобы разгребать
последствия, чем для соблюдения простого "не надо этого делать."