Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

All your files have been destroyed (sorry). Paul.


devel / comp.lang.forth / Re: Handling unsupported line-endings

SubjectAuthor
* Handling unsupported line-endingsdxforth
+* Re: Handling unsupported line-endingsHeinrich Hohl
|`* Re: Handling unsupported line-endingsdxforth
| `* Re: Handling unsupported line-endingsHeinrich Hohl
|  +* Re: Handling unsupported line-endingsdxforth
|  |`- Re: Handling unsupported line-endingsdxforth
|  +* Re: Handling unsupported line-endingsminf...@arcor.de
|  |`- Re: Handling unsupported line-endingsdxforth
|  `* Re: Handling unsupported line-endingsAnton Ertl
|   +* Re: Handling unsupported line-endingsHeinrich Hohl
|   |`- Re: Handling unsupported line-endingsAnton Ertl
|   `* Re: Handling unsupported line-endingsNickolay Kolchin
|    +* Re: Handling unsupported line-endingsdxforth
|    |+* Re: Handling unsupported line-endingsdxforth
|    ||`* Re: Handling unsupported line-endingsAnton Ertl
|    || `* Re: Handling unsupported line-endingsdxforth
|    ||  +* Re: Handling unsupported line-endingsdxforth
|    ||  |`* Re: Handling unsupported line-endingsAnton Ertl
|    ||  | `* Re: Handling unsupported line-endingsdxforth
|    ||  |  +- Re: Handling unsupported line-endingsdxforth
|    ||  |  `* Re: Handling unsupported line-endingsAnton Ertl
|    ||  |   `* Re: Handling unsupported line-endingsdxforth
|    ||  |    `* Re: Handling unsupported line-endingsAnton Ertl
|    ||  |     `* Re: Handling unsupported line-endingsdxforth
|    ||  |      `* Re: Handling unsupported line-endingsAnton Ertl
|    ||  |       `* Re: Handling unsupported line-endingsdxforth
|    ||  |        `* Re: Handling unsupported line-endingsAnton Ertl
|    ||  |         `* Re: Handling unsupported line-endingsdxforth
|    ||  |          `* Re: Handling unsupported line-endingsAnton Ertl
|    ||  |           `* Re: Handling unsupported line-endingsdxforth
|    ||  |            `* Re: Handling unsupported line-endingsAnton Ertl
|    ||  |             `* Re: Handling unsupported line-endingsdxforth
|    ||  |              +* Re: Handling unsupported line-endingsAnton Ertl
|    ||  |              |`* Re: Handling unsupported line-endingsdxforth
|    ||  |              | `* Re: Handling unsupported line-endingsRuvim
|    ||  |              |  +* Re: Handling unsupported line-endingsdxforth
|    ||  |              |  |`* Re: Handling unsupported line-endingsRuvim
|    ||  |              |  | `* Re: Handling unsupported line-endingsdxforth
|    ||  |              |  |  `- Re: Handling unsupported line-endingsRuvim
|    ||  |              |  `* Re: Handling unsupported line-endingsNickolay Kolchin
|    ||  |              |   `* Re: Handling unsupported line-endingsRon AARON
|    ||  |              |    `* Re: Handling unsupported line-endingsdxforth
|    ||  |              |     `* Re: Handling unsupported line-endingsRon AARON
|    ||  |              |      `* Re: Handling unsupported line-endingsdxforth
|    ||  |              |       `- Re: Handling unsupported line-endingsRon AARON
|    ||  |              `* Re: Handling unsupported line-endingsdxforth
|    ||  |               `- Re: Handling unsupported line-endingsdxforth
|    ||  `* Re: Handling unsupported line-endingsAnton Ertl
|    ||   `* Re: Handling unsupported line-endingsdxforth
|    ||    `- Re: Handling unsupported line-endingsAnton Ertl
|    |`* Re: Handling unsupported line-endingsNickolay Kolchin
|    | +* Re: Handling unsupported line-endingsdxforth
|    | |`* Re: Handling unsupported line-endingsNickolay Kolchin
|    | | +* Re: Handling unsupported line-endingsdxforth
|    | | |`- Re: Handling unsupported line-endingsNickolay Kolchin
|    | | +* Re: Handling unsupported line-endingsAnton Ertl
|    | | |`* Re: Handling unsupported line-endingsNickolay Kolchin
|    | | | `* Re: Handling unsupported line-endingsAnton Ertl
|    | | |  `- Re: Handling unsupported line-endingsdxforth
|    | | `* Re: Handling unsupported line-endingsHeinrich Hohl
|    | |  `* Re: Handling unsupported line-endingsNickolay Kolchin
|    | |   `* Re: Handling unsupported line-endingsRon AARON
|    | |    `* Re: Handling unsupported line-endingsNickolay Kolchin
|    | |     +* Re: Handling unsupported line-endingspahihu
|    | |     |+- Re: Handling unsupported line-endingsNickolay Kolchin
|    | |     |`- Re: Handling unsupported line-endingsRon AARON
|    | |     `* Re: Handling unsupported line-endingsRon AARON
|    | |      +* Re: Handling unsupported line-endingsNickolay Kolchin
|    | |      |`- Re: Handling unsupported line-endingsRon AARON
|    | |      `- Re: Handling unsupported line-endingsdxforth
|    | `- Re: Handling unsupported line-endingsAnton Ertl
|    +* Re: Handling unsupported line-endingsAnton Ertl
|    |`- Re: Handling unsupported line-endingsNickolay Kolchin
|    `* Re: Handling unsupported line-endingsMarcel Hendrix
|     +- Re: Handling unsupported line-endingsNickolay Kolchin
|     `* Re: Handling unsupported line-endingsAnton Ertl
|      `* Re: Handling unsupported line-endingsdxforth
|       `* Re: Handling unsupported line-endingsAnton Ertl
|        `* Re: Handling unsupported line-endingspahihu
|         +* Re: Handling unsupported line-endingsdxforth
|         |`* Re: Handling unsupported line-endingsAnton Ertl
|         | `- Re: Handling unsupported line-endingsdxforth
|         `- Re: Handling unsupported line-endingsAnton Ertl
+* Re: Handling unsupported line-endingsS Jack
|`- Re: Handling unsupported line-endingsdxforth
+* Re: Handling unsupported line-endingsBranimir Maksimovic
|`- Re: Handling unsupported line-endingsdxforth
`* Re: Handling unsupported line-endingsdxforth
 +- Re: Handling unsupported line-endingsRuvim
 `* Re: Handling unsupported line-endingsAnton Ertl
  +* Re: Handling unsupported line-endingsRuvim
  |`* Re: Handling unsupported line-endingsAnton Ertl
  | `* Re: Handling unsupported line-endingsRuvim
  |  `* Re: Handling unsupported line-endingsAnton Ertl
  |   +* Re: Handling unsupported line-endingsRuvim
  |   |`- Re: Handling unsupported line-endingsAnton Ertl
  |   `* Re: Handling unsupported line-endingsdxforth
  |    `* Re: Handling unsupported line-endingsRuvim
  |     `* Re: Handling unsupported line-endingsdxforth
  |      `* Re: Handling unsupported line-endingsRuvim
  |       `* Re: Handling unsupported line-endingsdxforth
  `* Re: Handling unsupported line-endingsdxforth

Pages:1234567
Re: Handling unsupported line-endings

<smdoeb$1ao0$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15196&group=comp.lang.forth#15196

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Handling unsupported line-endings
Date: Tue, 9 Nov 2021 23:09:46 +1100
Organization: Aioe.org NNTP Server
Message-ID: <smdoeb$1ao0$1@gioia.aioe.org>
References: <skjhir$jd9$1@gioia.aioe.org> <slr3k0$ct2$1@dont-email.me>
<slt808$2u9$1@gioia.aioe.org> <slteso$ibs$1@dont-email.me>
<slts1o$u8v$1@gioia.aioe.org> <sm36k3$sb2$1@gioia.aioe.org>
<dc79b2c0-767c-4508-99d2-34ab786e7c86n@googlegroups.com>
<sm5jar$a3c$1@dont-email.me>
<4980ce08-fd38-4f33-9736-ae7f7c13bdc8n@googlegroups.com>
<sm5mk4$u2d$1@dont-email.me> <2021Nov7.162402@mips.complang.tuwien.ac.at>
<fd958973-5910-4b19-b297-42be062ffbcfn@googlegroups.com>
<2021Nov7.193152@mips.complang.tuwien.ac.at>
<3b3d3a78-5509-4d90-8555-7ec088d137fan@googlegroups.com>
<sm9gr9$1cp$1@dont-email.me> <sm9p1r$15f2$1@gioia.aioe.org>
<smapkf$2a1$1@dont-email.me> <smaufu$caa$1@gioia.aioe.org>
<smb1q7$v20$1@dont-email.me> <smb7sh$10mt$1@gioia.aioe.org>
<smbiji$kpf$1@gioia.aioe.org> <smbnd8$esn$1@dont-email.me>
<65ff4f4c-54e5-47da-a9a1-e4e684812fb0n@googlegroups.com>
<smckdh$sc6$1@gioia.aioe.org> <smda4j$a6d$1@dont-email.me>
<smdd8r$1ijc$1@gioia.aioe.org> <smdl91$nft$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="43776"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Tue, 9 Nov 2021 12:09 UTC

On 9/11/2021 22:15, Gerry Jackson wrote:
> On 09/11/2021 08:59, dxforth wrote:
>> On 9/11/2021 19:05, Gerry Jackson wrote:
>>> On 09/11/2021 01:54, dxforth wrote:
>>>> On 9/11/2021 09:30, Marcel Hendrix wrote:
>>>>> On Monday, November 8, 2021 at 6:39:54 PM UTC+1, Gerry Jackson wrote:
>>>>>> On 08/11/2021 16:17, dxforth wrote: > On 9/11/2021 00:14, dxforth
>>>>>> wrote: >> On 8/11/2021 22:31, Ruvim wrote: >>> On 2021-11-08 13:34,
>>>>>> dxforth wrote: >>>>
>>>>> [..]
>>>>>> That's interesting. Given the following code (there's probably a
>>>>>> simpler way to demonstrate the issue but this suffices)
>>>>>> : a 128 32 do i c, loop ; : b 3 0 do a loop ; 0. 2value c here 128
>>>>>> 32 - 3 * to c b : d [ c ] sliteral cr type ;
>>>>>> If the following two lines in a Forth system don't display the same
>>>>>> long string that system is not compliant with ANS/Forth2012.
>>>>>> c cr type d
>>>>>
>>>>> FORTH> : a 128 32 do i c, loop ;  ok
>>>>> FORTH> : b 3 0 do a loop ;  ok
>>>>> FORTH> 0. dvalue c  ok
>>>>> FORTH> here 128 32 - 3 * to c  ok
>>>>> FORTH> b  ok
>>>>> FORTH> : d [ c ] sliteral cr type ;
>>>>> Error -64
>>>>> quoted string should be less than 256 characters ?
>>>>> FORTH> c .s
>>>>>    Data: 20176896 288 ---
>>>>> System: ---
>>>>>   Float: --- ok
>>>>>
>>>>> A bug. Thanks.
>>>>
>>>> Looks fine to me.
>>>
>>>    A warning would be better than a misleading error message given that
>>> it is perfectly valid ANS Forth
>>>
>>
>> The '-64 error' is confusing and I'd leave out 'quoted'.
>
> Yes, in Forth 2012 -64 is the exception code for DELETE-FILE
>
>> I would hope it's valid ANS but couldn't find an SLITERAL length limit
>> in the spec or I missed it.
>
> I don't think there is any limit specified for SLITERAL

A omission perhaps as there seems little use for SLITERAL beyond compiling
relatively short strings; the best known use being the one ANS itself
provided:

A.17.6.1.2212 SLITERAL

The current functionality of 6.1.2165 S" may be provided by the following definition:

: S" ( "ccc<quote>" -- )
[CHAR] " PARSE POSTPONE SLITERAL ; IMMEDIATE

Marcel feels the result he got was a bug. Perhaps he can elucidate.

Re: Handling unsupported line-endings

<2021Nov9.181913@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15198&group=comp.lang.forth#15198

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Handling unsupported line-endings
Date: Tue, 09 Nov 2021 17:19:13 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 37
Message-ID: <2021Nov9.181913@mips.complang.tuwien.ac.at>
References: <skjhir$jd9$1@gioia.aioe.org> <sm5mk4$u2d$1@dont-email.me> <2021Nov7.162402@mips.complang.tuwien.ac.at> <fd958973-5910-4b19-b297-42be062ffbcfn@googlegroups.com> <2021Nov7.193152@mips.complang.tuwien.ac.at> <3b3d3a78-5509-4d90-8555-7ec088d137fan@googlegroups.com> <sm9gr9$1cp$1@dont-email.me> <sm9p1r$15f2$1@gioia.aioe.org> <smapkf$2a1$1@dont-email.me> <smaufu$caa$1@gioia.aioe.org> <smb1q7$v20$1@dont-email.me> <smb7sh$10mt$1@gioia.aioe.org> <smbiji$kpf$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="bacae3137e9aee7843216fa2a248b390";
logging-data="15976"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+sIDV+0NjNuneCHScWzD6u"
Cancel-Lock: sha1:QtJOC86XSFkpMV4V2FfxyV8raXQ=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 9 Nov 2021 17:19 UTC

dxforth <dxforth@gmail.com> writes:
>This test should work on any system:
>
> here 500 dup allot 2constant foo : bar [ foo ] sliteral nip . ; bar

Yes, good test. And for SLITERAL it's more likely that strings longer
than 255 bytes will be used. Examining some likely candidates in the
Gforth image, I found:

see compile-cmd \ output
: compile-cmd $7F94D4C0E080 #299
type c-flags $. c-flags $free " -O -c " type lib-filename $. ".c -o " type lib-filename $. ".lo" type ;

Note a 299-Byte string right at the start. The content of this string
is

libtool --silent --tag=CC --mode=compile gcc -Wimplicit-function-declaration -g -O2 -fomit-frame-pointer -pthread -I./freetype-gl -I/usr/local/include/gforth/0.7.9_20211104/amd64 -Wl,--export-dynamic -pthread -I '/home/anton/gforth/include' -I/home/anton/gforth/include/gforth/0.7.9_20211104/amd64

But this does not occur as S" or ." string, but is assembled during
compilation, as follows:

: compile-cmd ( -- )
[ libtool-command tmp$ $! s" --silent --tag=CC --mode=compile " $type
s" CROSS_PREFIX" getenv $type
libtool-cc $type s" -I '" $type
s" includedir" getenv tuck $type 0= [IF]
pad $100 get-dir $type s" /" $type version-string $type
s" /include" $type [THEN]
s" '" $type s" extrastuff" getenv $type
tmp$ $@ ] sliteral type ...

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Handling unsupported line-endings

<8c186cac-35d5-4045-8f59-b732c0a91156n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15199&group=comp.lang.forth#15199

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:622a:1788:: with SMTP id s8mr11061016qtk.189.1636485101430;
Tue, 09 Nov 2021 11:11:41 -0800 (PST)
X-Received: by 2002:a05:622a:170c:: with SMTP id h12mr11023174qtk.248.1636485101259;
Tue, 09 Nov 2021 11:11:41 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Tue, 9 Nov 2021 11:11:41 -0800 (PST)
In-Reply-To: <smdoeb$1ao0$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:1c05:2f14:600:8886:e67:72f1:efb9;
posting-account=-JQ2RQoAAAB6B5tcBTSdvOqrD1HpT_Rk
NNTP-Posting-Host: 2001:1c05:2f14:600:8886:e67:72f1:efb9
References: <skjhir$jd9$1@gioia.aioe.org> <slr3k0$ct2$1@dont-email.me>
<slt808$2u9$1@gioia.aioe.org> <slteso$ibs$1@dont-email.me>
<slts1o$u8v$1@gioia.aioe.org> <sm36k3$sb2$1@gioia.aioe.org>
<dc79b2c0-767c-4508-99d2-34ab786e7c86n@googlegroups.com> <sm5jar$a3c$1@dont-email.me>
<4980ce08-fd38-4f33-9736-ae7f7c13bdc8n@googlegroups.com> <sm5mk4$u2d$1@dont-email.me>
<2021Nov7.162402@mips.complang.tuwien.ac.at> <fd958973-5910-4b19-b297-42be062ffbcfn@googlegroups.com>
<2021Nov7.193152@mips.complang.tuwien.ac.at> <3b3d3a78-5509-4d90-8555-7ec088d137fan@googlegroups.com>
<sm9gr9$1cp$1@dont-email.me> <sm9p1r$15f2$1@gioia.aioe.org>
<smapkf$2a1$1@dont-email.me> <smaufu$caa$1@gioia.aioe.org>
<smb1q7$v20$1@dont-email.me> <smb7sh$10mt$1@gioia.aioe.org>
<smbiji$kpf$1@gioia.aioe.org> <smbnd8$esn$1@dont-email.me>
<65ff4f4c-54e5-47da-a9a1-e4e684812fb0n@googlegroups.com> <smckdh$sc6$1@gioia.aioe.org>
<smda4j$a6d$1@dont-email.me> <smdd8r$1ijc$1@gioia.aioe.org>
<smdl91$nft$1@dont-email.me> <smdoeb$1ao0$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8c186cac-35d5-4045-8f59-b732c0a91156n@googlegroups.com>
Subject: Re: Handling unsupported line-endings
From: mhx...@iae.nl (Marcel Hendrix)
Injection-Date: Tue, 09 Nov 2021 19:11:41 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 21
 by: Marcel Hendrix - Tue, 9 Nov 2021 19:11 UTC

On Tuesday, November 9, 2021 at 1:09:49 PM UTC+1, dxforth wrote:
[..]
> >>>>> Error -64
> >>>>> quoted string should be less than 256 characters ?
> >>>>> FORTH> c .s
> >>>>> Data: 20176896 288 ---
> >>>>> System: ---
> >>>>> Float: --- ok
> >>>>>
> >>>>> A bug. Thanks.
[..]
> Marcel feels the result he got was a bug. Perhaps he can elucidate.

It is a bug in iForth. I never use SLITERAL and definitely not in the kernel sources,
and in this case I misread the standard. SLITERAL behaves more or less like C" .

The "-64" is not a bug. The implementation document only defined error codes
down to only -58.

I have added these two to our bug tracker for the next release.

-marcel

Re: Handling unsupported line-endings

<b13d6039-f4fe-434a-8941-22df9836f53fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15200&group=comp.lang.forth#15200

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:622a:282:: with SMTP id z2mr11598298qtw.131.1636489032338;
Tue, 09 Nov 2021 12:17:12 -0800 (PST)
X-Received: by 2002:a05:622a:1184:: with SMTP id m4mr11257579qtk.328.1636489032186;
Tue, 09 Nov 2021 12:17:12 -0800 (PST)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Tue, 9 Nov 2021 12:17:12 -0800 (PST)
In-Reply-To: <8c186cac-35d5-4045-8f59-b732c0a91156n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2003:f7:1f26:2cf6:312c:ed94:be81:8694;
posting-account=AqNUYgoAAADmkK2pN-RKms8sww57W0Iw
NNTP-Posting-Host: 2003:f7:1f26:2cf6:312c:ed94:be81:8694
References: <skjhir$jd9$1@gioia.aioe.org> <slr3k0$ct2$1@dont-email.me>
<slt808$2u9$1@gioia.aioe.org> <slteso$ibs$1@dont-email.me>
<slts1o$u8v$1@gioia.aioe.org> <sm36k3$sb2$1@gioia.aioe.org>
<dc79b2c0-767c-4508-99d2-34ab786e7c86n@googlegroups.com> <sm5jar$a3c$1@dont-email.me>
<4980ce08-fd38-4f33-9736-ae7f7c13bdc8n@googlegroups.com> <sm5mk4$u2d$1@dont-email.me>
<2021Nov7.162402@mips.complang.tuwien.ac.at> <fd958973-5910-4b19-b297-42be062ffbcfn@googlegroups.com>
<2021Nov7.193152@mips.complang.tuwien.ac.at> <3b3d3a78-5509-4d90-8555-7ec088d137fan@googlegroups.com>
<sm9gr9$1cp$1@dont-email.me> <sm9p1r$15f2$1@gioia.aioe.org>
<smapkf$2a1$1@dont-email.me> <smaufu$caa$1@gioia.aioe.org>
<smb1q7$v20$1@dont-email.me> <smb7sh$10mt$1@gioia.aioe.org>
<smbiji$kpf$1@gioia.aioe.org> <smbnd8$esn$1@dont-email.me>
<65ff4f4c-54e5-47da-a9a1-e4e684812fb0n@googlegroups.com> <smckdh$sc6$1@gioia.aioe.org>
<smda4j$a6d$1@dont-email.me> <smdd8r$1ijc$1@gioia.aioe.org>
<smdl91$nft$1@dont-email.me> <smdoeb$1ao0$1@gioia.aioe.org> <8c186cac-35d5-4045-8f59-b732c0a91156n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b13d6039-f4fe-434a-8941-22df9836f53fn@googlegroups.com>
Subject: Re: Handling unsupported line-endings
From: minfo...@arcor.de (minf...@arcor.de)
Injection-Date: Tue, 09 Nov 2021 20:17:12 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2986
 by: minf...@arcor.de - Tue, 9 Nov 2021 20:17 UTC

Marcel Hendrix schrieb am Dienstag, 9. November 2021 um 20:11:42 UTC+1:
> On Tuesday, November 9, 2021 at 1:09:49 PM UTC+1, dxforth wrote:
> [..]
> > >>>>> Error -64
> > >>>>> quoted string should be less than 256 characters ?
> > >>>>> FORTH> c .s
> > >>>>> Data: 20176896 288 ---
> > >>>>> System: ---
> > >>>>> Float: --- ok
> > >>>>>
> > >>>>> A bug. Thanks.
> [..]
> > Marcel feels the result he got was a bug. Perhaps he can elucidate.
> It is a bug in iForth. I never use SLITERAL and definitely not in the kernel sources,
> and in this case I misread the standard. SLITERAL behaves more or less like C" .
>

Let's hope we never have overlong strings in interpretation state (eg reading
from json files) because S" should use at least 2 buffers ...

Re: Handling unsupported line-endings

<bd667912-c031-4640-aa30-f48e1bff652cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15201&group=comp.lang.forth#15201

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:7d47:: with SMTP id h7mr11429577qtb.92.1636489359937;
Tue, 09 Nov 2021 12:22:39 -0800 (PST)
X-Received: by 2002:a37:cd1:: with SMTP id 200mr8520512qkm.106.1636489359742;
Tue, 09 Nov 2021 12:22:39 -0800 (PST)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Tue, 9 Nov 2021 12:22:39 -0800 (PST)
In-Reply-To: <smdoeb$1ao0$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:1c05:2f14:600:8886:e67:72f1:efb9;
posting-account=-JQ2RQoAAAB6B5tcBTSdvOqrD1HpT_Rk
NNTP-Posting-Host: 2001:1c05:2f14:600:8886:e67:72f1:efb9
References: <skjhir$jd9$1@gioia.aioe.org> <slr3k0$ct2$1@dont-email.me>
<slt808$2u9$1@gioia.aioe.org> <slteso$ibs$1@dont-email.me>
<slts1o$u8v$1@gioia.aioe.org> <sm36k3$sb2$1@gioia.aioe.org>
<dc79b2c0-767c-4508-99d2-34ab786e7c86n@googlegroups.com> <sm5jar$a3c$1@dont-email.me>
<4980ce08-fd38-4f33-9736-ae7f7c13bdc8n@googlegroups.com> <sm5mk4$u2d$1@dont-email.me>
<2021Nov7.162402@mips.complang.tuwien.ac.at> <fd958973-5910-4b19-b297-42be062ffbcfn@googlegroups.com>
<2021Nov7.193152@mips.complang.tuwien.ac.at> <3b3d3a78-5509-4d90-8555-7ec088d137fan@googlegroups.com>
<sm9gr9$1cp$1@dont-email.me> <sm9p1r$15f2$1@gioia.aioe.org>
<smapkf$2a1$1@dont-email.me> <smaufu$caa$1@gioia.aioe.org>
<smb1q7$v20$1@dont-email.me> <smb7sh$10mt$1@gioia.aioe.org>
<smbiji$kpf$1@gioia.aioe.org> <smbnd8$esn$1@dont-email.me>
<65ff4f4c-54e5-47da-a9a1-e4e684812fb0n@googlegroups.com> <smckdh$sc6$1@gioia.aioe.org>
<smda4j$a6d$1@dont-email.me> <smdd8r$1ijc$1@gioia.aioe.org>
<smdl91$nft$1@dont-email.me> <smdoeb$1ao0$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <bd667912-c031-4640-aa30-f48e1bff652cn@googlegroups.com>
Subject: Re: Handling unsupported line-endings
From: mhx...@iae.nl (Marcel Hendrix)
Injection-Date: Tue, 09 Nov 2021 20:22:39 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2753
 by: Marcel Hendrix - Tue, 9 Nov 2021 20:22 UTC

On Tuesday, November 9, 2021 at 1:09:49 PM UTC+1, dxforth wrote:
[..]
> >>>>> Error -64
> >>>>> quoted string should be less than 256 characters ?
> >>>>> FORTH> c .s
> >>>>> Data: 20176896 288 ---
> >>>>> System: ---
> >>>>> Float: --- ok
> >>>>>
> >>>>> A bug. Thanks.
[..]
> Marcel feels the result he got was a bug. Perhaps he can elucidate.

It is a bug in iForth. I never use SLITERAL and definitely not in the kernel sources,
and in this case I misread the standard. iForth's current SLITERAL behaves
more or less like C" .

The "-64" is an imperfection. The implementation document defined error codes
down to only -58.

-marcel

Re: Handling unsupported line-endings

<smf0k8$16s9$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15204&group=comp.lang.forth#15204

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Handling unsupported line-endings
Date: Wed, 10 Nov 2021 10:35:36 +1100
Organization: Aioe.org NNTP Server
Message-ID: <smf0k8$16s9$1@gioia.aioe.org>
References: <skjhir$jd9$1@gioia.aioe.org> <sm5mk4$u2d$1@dont-email.me>
<2021Nov7.162402@mips.complang.tuwien.ac.at>
<fd958973-5910-4b19-b297-42be062ffbcfn@googlegroups.com>
<2021Nov7.193152@mips.complang.tuwien.ac.at>
<3b3d3a78-5509-4d90-8555-7ec088d137fan@googlegroups.com>
<sm9gr9$1cp$1@dont-email.me> <sm9p1r$15f2$1@gioia.aioe.org>
<smapkf$2a1$1@dont-email.me> <smaufu$caa$1@gioia.aioe.org>
<smb1q7$v20$1@dont-email.me> <smb7sh$10mt$1@gioia.aioe.org>
<smbiji$kpf$1@gioia.aioe.org> <2021Nov9.181913@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="39817"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Tue, 9 Nov 2021 23:35 UTC

On 10/11/2021 04:19, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>This test should work on any system:
>>
>> here 500 dup allot 2constant foo : bar [ foo ] sliteral nip . ; bar
>
> Yes, good test. And for SLITERAL it's more likely that strings longer
> than 255 bytes will be used. Examining some likely candidates in the
> Gforth image, I found:
>
> see compile-cmd \ output
> : compile-cmd $7F94D4C0E080 #299
> type c-flags $. c-flags $free " -O -c " type lib-filename $. ".c -o " type lib-filename $. ".lo" type ;
>
> Note a 299-Byte string right at the start. The content of this string
> is
>
> libtool --silent --tag=CC --mode=compile gcc -Wimplicit-function-declaration -g -O2 -fomit-frame-pointer -pthread -I./freetype-gl -I/usr/local/include/gforth/0.7.9_20211104/amd64 -Wl,--export-dynamic -pthread -I '/home/anton/gforth/include' -I/home/anton/gforth/include/gforth/0.7.9_20211104/amd64
>
> But this does not occur as S" or ." string, but is assembled during
> compilation, as follows:
>
> : compile-cmd ( -- )
> [ libtool-command tmp$ $! s" --silent --tag=CC --mode=compile " $type
> s" CROSS_PREFIX" getenv $type
> libtool-cc $type s" -I '" $type
> s" includedir" getenv tuck $type 0= [IF]
> pad $100 get-dir $type s" /" $type version-string $type
> s" /include" $type [THEN]
> s" '" $type s" extrastuff" getenv $type
> tmp$ $@ ] sliteral type ...

Let's examine that.

- SwiftForth appears to manage without it.

- In GForth the string is physically located in a separate region.
So even GForth acknowledges it would be better were the data located
in its own buffer than embedded in a colon definition.

IMO the greater the amount of data, the stronger becomes the case for not
having it inline. You don't find your example unnecessarily complicated
and unweildly?

Re: Handling unsupported line-endings

<smf0po$16s9$2@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15205&group=comp.lang.forth#15205

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Handling unsupported line-endings
Date: Wed, 10 Nov 2021 10:38:32 +1100
Organization: Aioe.org NNTP Server
Message-ID: <smf0po$16s9$2@gioia.aioe.org>
References: <skjhir$jd9$1@gioia.aioe.org> <slts1o$u8v$1@gioia.aioe.org>
<sm36k3$sb2$1@gioia.aioe.org>
<dc79b2c0-767c-4508-99d2-34ab786e7c86n@googlegroups.com>
<sm5jar$a3c$1@dont-email.me>
<4980ce08-fd38-4f33-9736-ae7f7c13bdc8n@googlegroups.com>
<sm5mk4$u2d$1@dont-email.me> <2021Nov7.162402@mips.complang.tuwien.ac.at>
<fd958973-5910-4b19-b297-42be062ffbcfn@googlegroups.com>
<2021Nov7.193152@mips.complang.tuwien.ac.at>
<3b3d3a78-5509-4d90-8555-7ec088d137fan@googlegroups.com>
<sm9gr9$1cp$1@dont-email.me> <sm9p1r$15f2$1@gioia.aioe.org>
<smapkf$2a1$1@dont-email.me> <smaufu$caa$1@gioia.aioe.org>
<smb1q7$v20$1@dont-email.me> <smb7sh$10mt$1@gioia.aioe.org>
<smbiji$kpf$1@gioia.aioe.org> <smbnd8$esn$1@dont-email.me>
<65ff4f4c-54e5-47da-a9a1-e4e684812fb0n@googlegroups.com>
<smckdh$sc6$1@gioia.aioe.org> <smda4j$a6d$1@dont-email.me>
<smdd8r$1ijc$1@gioia.aioe.org> <smdl91$nft$1@dont-email.me>
<smdoeb$1ao0$1@gioia.aioe.org>
<bd667912-c031-4640-aa30-f48e1bff652cn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="39817"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Tue, 9 Nov 2021 23:38 UTC

On 10/11/2021 07:22, Marcel Hendrix wrote:
> On Tuesday, November 9, 2021 at 1:09:49 PM UTC+1, dxforth wrote:
> [..]
>> >>>>> Error -64
>> >>>>> quoted string should be less than 256 characters ?
>> >>>>> FORTH> c .s
>> >>>>> Data: 20176896 288 ---
>> >>>>> System: ---
>> >>>>> Float: --- ok
>> >>>>>
>> >>>>> A bug. Thanks.
> [..]
>> Marcel feels the result he got was a bug. Perhaps he can elucidate.
>
> It is a bug in iForth. I never use SLITERAL and definitely not in the kernel sources,
> and in this case I misread the standard. iForth's current SLITERAL behaves
> more or less like C" .

In what respect - the common practice of limiting embedded strings to 255 max?

>
> The "-64" is an imperfection. The implementation document defined error codes
> down to only -58.

ANS did reserve values to -255 for its own use.

Re: Handling unsupported line-endings

<2021Nov10.113727@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15212&group=comp.lang.forth#15212

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Handling unsupported line-endings
Date: Wed, 10 Nov 2021 10:37:27 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 88
Message-ID: <2021Nov10.113727@mips.complang.tuwien.ac.at>
References: <skjhir$jd9$1@gioia.aioe.org> <fd958973-5910-4b19-b297-42be062ffbcfn@googlegroups.com> <2021Nov7.193152@mips.complang.tuwien.ac.at> <3b3d3a78-5509-4d90-8555-7ec088d137fan@googlegroups.com> <sm9gr9$1cp$1@dont-email.me> <sm9p1r$15f2$1@gioia.aioe.org> <smapkf$2a1$1@dont-email.me> <smaufu$caa$1@gioia.aioe.org> <smb1q7$v20$1@dont-email.me> <smb7sh$10mt$1@gioia.aioe.org> <smbiji$kpf$1@gioia.aioe.org> <2021Nov9.181913@mips.complang.tuwien.ac.at> <smf0k8$16s9$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="767fd373d30b1831323251d5af3b3430";
logging-data="26971"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/KLd4MBQEvqm0i6DZ5gEcg"
Cancel-Lock: sha1:lIwOHSAROgXT7Od2APBOt6WGj2k=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 10 Nov 2021 10:37 UTC

dxforth <dxforth@gmail.com> writes:
>On 10/11/2021 04:19, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>>This test should work on any system:
>>>
>>> here 500 dup allot 2constant foo : bar [ foo ] sliteral nip . ; bar
>>
>> Yes, good test. And for SLITERAL it's more likely that strings longer
>> than 255 bytes will be used. Examining some likely candidates in the
>> Gforth image, I found:
>>
>> see compile-cmd \ output
>> : compile-cmd $7F94D4C0E080 #299
>> type c-flags $. c-flags $free " -O -c " type lib-filename $. ".c -o " type lib-filename $. ".lo" type ;
>>
>> Note a 299-Byte string right at the start. The content of this string
>> is
>>
>> libtool --silent --tag=CC --mode=compile gcc -Wimplicit-function-declaration -g -O2 -fomit-frame-pointer -pthread -I./freetype-gl -I/usr/local/include/gforth/0.7.9_20211104/amd64 -Wl,--export-dynamic -pthread -I '/home/anton/gforth/include' -I/home/anton/gforth/include/gforth/0.7.9_20211104/amd64
>>
>> But this does not occur as S" or ." string, but is assembled during
>> compilation, as follows:
>>
>> : compile-cmd ( -- )
>> [ libtool-command tmp$ $! s" --silent --tag=CC --mode=compile " $type
>> s" CROSS_PREFIX" getenv $type
>> libtool-cc $type s" -I '" $type
>> s" includedir" getenv tuck $type 0= [IF]
>> pad $100 get-dir $type s" /" $type version-string $type
>> s" /include" $type [THEN]
>> s" '" $type s" extrastuff" getenv $type
>> tmp$ $@ ] sliteral type ...
>
>Let's examine that.
>
>- SwiftForth appears to manage without it.

Just because one can manage without something does not mean that it's
a good idea. Emperor Franz Joseph I of Austria (reigning from
1848-1916) managed without flush toilets.

>- In GForth the string is physically located in a separate region.
> So even GForth acknowledges it would be better were the data located
> in its own buffer than embedded in a colon definition.

In Gforth the major benefit is that the branch around the data is
eliminated.

>IMO the greater the amount of data, the stronger becomes the case for not
>having it inline.

No. The branch around would be needed even for a single-byte string.
On native-code systems with return-address manipulation the return
stack misprediction already happens for a single byt. On native-code
systems there is als a (very small) negative effect on I-cache
utilization that is not present if the string is elsewhere, but this
effect only is relevant at cache line (64-byte granularity). I.e., if
the Forth system does alogn the align the code behind the string to an
I-cache line boundary, strings longer than 64 bytes have no worse
effect than strings of 64 bytes; without such alignment, strings
longer than 128 bytes have no worse effect than strings of 128 bytes.

>You don't find your example unnecessarily complicated
>and unweildly?

No, it's necessarily complicated and unwieldy. Sure it could be
replaced with

libtool-command tmp$ $! s" --silent --tag=CC --mode=compile " $type
s" CROSS_PREFIX" getenv $type
libtool-cc $type s" -I '" $type
s" includedir" getenv tuck $type 0= [IF]
pad $100 get-dir $type s" /" $type version-string $type
s" /include" $type [THEN]
s" '" $type s" extrastuff" getenv $type
tmp$ $@ save-mem-dict 2constant libtool-command-long

: compile-cmd ( -- )
libtool-command-long type ...

That would be at least as unwieldy, and it would consume more memory.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Handling unsupported line-endings

<smgi3a$141h$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=15213&group=comp.lang.forth#15213

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Handling unsupported line-endings
Date: Thu, 11 Nov 2021 00:39:54 +1100
Organization: Aioe.org NNTP Server
Message-ID: <smgi3a$141h$1@gioia.aioe.org>
References: <skjhir$jd9$1@gioia.aioe.org>
<fd958973-5910-4b19-b297-42be062ffbcfn@googlegroups.com>
<2021Nov7.193152@mips.complang.tuwien.ac.at>
<3b3d3a78-5509-4d90-8555-7ec088d137fan@googlegroups.com>
<sm9gr9$1cp$1@dont-email.me> <sm9p1r$15f2$1@gioia.aioe.org>
<smapkf$2a1$1@dont-email.me> <smaufu$caa$1@gioia.aioe.org>
<smb1q7$v20$1@dont-email.me> <smb7sh$10mt$1@gioia.aioe.org>
<smbiji$kpf$1@gioia.aioe.org> <2021Nov9.181913@mips.complang.tuwien.ac.at>
<smf0k8$16s9$1@gioia.aioe.org> <2021Nov10.113727@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="36913"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Wed, 10 Nov 2021 13:39 UTC

On 10/11/2021 21:37, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 10/11/2021 04:19, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>>>This test should work on any system:
>>>>
>>>> here 500 dup allot 2constant foo : bar [ foo ] sliteral nip . ; bar
>>>
>>> Yes, good test. And for SLITERAL it's more likely that strings longer
>>> than 255 bytes will be used. Examining some likely candidates in the
>>> Gforth image, I found:
>>>
>>> see compile-cmd \ output
>>> : compile-cmd $7F94D4C0E080 #299
>>> type c-flags $. c-flags $free " -O -c " type lib-filename $. ".c -o " type lib-filename $. ".lo" type ;
>>>
>>> Note a 299-Byte string right at the start. The content of this string
>>> is
>>>
>>> libtool --silent --tag=CC --mode=compile gcc -Wimplicit-function-declaration -g -O2 -fomit-frame-pointer -pthread -I./freetype-gl -I/usr/local/include/gforth/0.7.9_20211104/amd64 -Wl,--export-dynamic -pthread -I '/home/anton/gforth/include' -I/home/anton/gforth/include/gforth/0.7.9_20211104/amd64
>>>
>>> But this does not occur as S" or ." string, but is assembled during
>>> compilation, as follows:
>>>
>>> : compile-cmd ( -- )
>>> [ libtool-command tmp$ $! s" --silent --tag=CC --mode=compile " $type
>>> s" CROSS_PREFIX" getenv $type
>>> libtool-cc $type s" -I '" $type
>>> s" includedir" getenv tuck $type 0= [IF]
>>> pad $100 get-dir $type s" /" $type version-string $type
>>> s" /include" $type [THEN]
>>> s" '" $type s" extrastuff" getenv $type
>>> tmp$ $@ ] sliteral type ...
>>
>>Let's examine that.
>>
>>- SwiftForth appears to manage without it.
>
> Just because one can manage without something does not mean that it's
> a good idea. Emperor Franz Joseph I of Austria (reigning from
> 1848-1916) managed without flush toilets.

After 25 years of near zero use, a flushing toilet SLITERAL is not.

>
>>- In GForth the string is physically located in a separate region.
>> So even GForth acknowledges it would be better were the data located
>> in its own buffer than embedded in a colon definition.
>
> In Gforth the major benefit is that the branch around the data is
> eliminated.
>
>>IMO the greater the amount of data, the stronger becomes the case for not
>>having it inline.
>
> No. The branch around would be needed even for a single-byte string.
> On native-code systems with return-address manipulation the return
> stack misprediction already happens for a single byt. On native-code
> systems there is als a (very small) negative effect on I-cache
> utilization that is not present if the string is elsewhere, but this
> effect only is relevant at cache line (64-byte granularity). I.e., if
> the Forth system does alogn the align the code behind the string to an
> I-cache line boundary, strings longer than 64 bytes have no worse
> effect than strings of 64 bytes; without such alignment, strings
> longer than 128 bytes have no worse effect than strings of 128 bytes.
>
>>You don't find your example unnecessarily complicated
>>and unweildly?
>
> No, it's necessarily complicated and unwieldy. Sure it could be
> replaced with
>
> libtool-command tmp$ $! s" --silent --tag=CC --mode=compile " $type
> s" CROSS_PREFIX" getenv $type
> libtool-cc $type s" -I '" $type
> s" includedir" getenv tuck $type 0= [IF]
> pad $100 get-dir $type s" /" $type version-string $type
> s" /include" $type [THEN]
> s" '" $type s" extrastuff" getenv $type
> tmp$ $@ save-mem-dict 2constant libtool-command-long
>
> : compile-cmd ( -- )
> libtool-command-long type ...
>
> That would be at least as unwieldy, and it would consume more memory.

Much better. One names non-trivial constants for readability.
No reason string constants would be any different.

Pages:1234567
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor